정답 · 해설

해설

【핵심 용어】 ▸ CloudFront + S3 — 정적 프런트엔드 글로벌 배포(관리 최소, 안전) ▸ API Gateway + Lambda — 마이크로서비스 서버리스 백엔드(운영 부담↓) ▸ Amazon RDS for MySQL — 관리형 MySQL(EC2 자체 호스팅 대비 운영 부담↓) 【정답 포인트】 ▸ "글로벌 + 보안 + 최소 운영" → 정적 프런트는 CloudFront + S3, 백엔드는 Lambda + API Gateway, DB는 RDS for MySQL로 이전(B) ▸ 전 구간 관리형/서버리스로 운영 부담 최소, CloudFront로 글로벌·보안 【오답 체크】 (A) MySQL을 EC2 예약 인스턴스로 옮기면 DB를 직접 관리해야 해 운영 부담이 큼. (C) Lambda를 NLB 타겟 그룹에 두는 구성은 부자연스럽고 API Gateway 대비 관리 복잡. (D) 프런트에 CloudFront 없이 S3만 두고 DB를 EC2에 두면 글로벌·운영 최소 요구 미흡. 【시험 포인트】 정적 프런트+마이크로서비스 최소 운영·글로벌 → S3+CloudFront, Lambda+API Gateway, RDS(MySQL). DB를 EC2로 두면 오답.

해설

【핵심 용어】 ▸ Amazon ElastiCache for Redis — 인메모리 초저지연, 리더보드/랭킹에 최적이며 디스크 지속성(persistence, AOF/스냅샷) 지원 ▸ ElastiCache for Memcached — 지속성 없음(재시작 시 데이터 소실) ▸ 준실시간 랭킹 + 재시작 후 데이터 유지 요구 【정답 포인트】 ▸ "준실시간 랭킹 빠른 접근 + 재시작 후 디스크 지속 + 최소 운영" → ElastiCache for Redis 클러스터에 데이터 저장(C) ▸ Redis는 인메모리 고속 + 지속성 옵션으로 재시작 후에도 데이터 유지 【오답 체크】 (A) CloudFront + S3는 정적 콘텐츠 배포용으로 준실시간 랭킹 데이터 스토어에 부적합. (B) 여러 리전 EC2에 데이터 저장 + Route 53은 운영 부담 크고 관리형이 아님. (D) Memcached는 디스크 지속성이 없어 재시작 시 데이터가 소실됨. 【시험 포인트】 초저지연 랭킹/세션 + 지속성 필요 → ElastiCache for Redis. 지속성 불필요 단순 캐시 → Memcached(재시작 시 소실).

해설

【핵심 용어】 ▸ AWS KMS 고객별 KMS 키(per-customer key) — 고객마다 별도 키로 데이터 분리 암호화, 세분화 접근 제어·CloudTrail 로깅 ▸ 중앙 집중 키 관리(KMS) + 규정 준수(고객별 분리) ▸ 단일 키/외부 어플라이언스 대비 KMS 관리형 【정답 포인트】 ▸ "고객마다 별도로 저장 암호화 + 중앙 키 관리 + 최소 운영" → 고객별 KMS 키 생성, 세분화 접근 제어·로깅 활성화(D) ▸ KMS 관리형으로 키 저장·회전·감사를 처리, 고객별 분리 규정 충족 【오답 체크】 (A) S3에 자체 키 저장은 안전한 중앙 키 관리(KMS)가 아니며 보안 취약. (B) 하드웨어 보안 어플라이언스 배치·운영은 오버헤드가 크고 KMS 관리형 취지에 반함. (C) 단일 KMS 키로 전체 암호화는 고객별 분리 규정 요구를 충족하지 못함. 【시험 포인트】 고객/테넌트별 분리 암호화 + 중앙 관리 + 감사 → 고객별 KMS 키(세분화 접근 제어·로깅). 단일 키·자체 키 저장은 오답.

해설

【핵심 용어】 ▸ 소용량 파일 그룹화(archive/집계) — 10KB 수백만 개는 요청·최소 과금 비효율 → 큰 객체로 묶어 비용↓ ▸ S3 Glacier Instant Retrieval — 즉시 접근 아카이브(첫 1년, 드문 접근·즉시성) ▸ S3 Glacier Deep Archive — 최저가 장기 보관(1년 후 7년 아카이브) 【정답 포인트】 ▸ "10KB 수백만 파일 + 1년간 즉시 접근 + 이후 7년 아카이브 + 최저 비용" → 아카이브 툴로 큰 객체로 묶어 전송, 1년간 Glacier Instant Retrieval, 이후 Lifecycle로 Deep Archive 전환(7년 보관)(A) ▸ 소용량 파일 그룹화로 요청·최소 스토리지 오버헤드 제거 + 계층별 최저가 【오답 체크】 (B) 1년 후 GIR로 전환은 장기 아카이브 최저가(Deep Archive)보다 비쌈. (C) 그룹화 없이 저장하면 소용량 파일 오버헤드가 크고, Flexible Retrieval도 Deep Archive보다 비쌈. (D) 소용량 파일 그룹화 없이 Standard-IA로 두면 최소 객체 크기 과금·요청 비용이 커 비효율. 【시험 포인트】 초소형 파일 대량 → 큰 객체로 그룹화(오버헤드 제거). 즉시 접근 아카이브 → GIR, 장기 최저가 → Deep Archive.

해설

【핵심 용어】 ▸ EBS 볼륨 스트라이핑(LVM RAID 0) — 여러 io1 볼륨을 묶어 IOPS·처리량 합산으로 성능 향상 ▸ 단일 io1 볼륨 IOPS 상한 및 인스턴스 EBS 대역폭 한계 ▸ 온프레미스보다 느린 스토리지 성능 개선 【정답 포인트】 ▸ "단일 io1 볼륨(64,000 IOPS)으로 성능 부족" → io1 볼륨을 추가하고 OS에서 LVM 스트라이프로 묶어 IOPS·처리량 합산(A) ▸ 여러 볼륨 병렬화로 단일 볼륨 한계를 넘어 성능 향상 【오답 체크】 (B) 단일 io1 볼륨의 최대 IOPS 한계를 넘길 수 없어 단순 증설로 해결 불가. (C) 볼륨 크기(2TB) 증가만으로는 IOPS 성능이 개선되지 않음(io1은 IOPS를 별도 지정). (D) 스토리지 최적화 인스턴스로 변경(로컬 스토어)은 io1 유지 조건과 성능 개선 방식이 맞지 않음. 【시험 포인트】 단일 EBS 볼륨 IOPS/처리량 한계 초과 필요 → 여러 볼륨 + LVM/RAID 0 스트라이핑으로 성능 합산.

해설

【핵심 용어】 ▸ Amazon SNS — 발행/구독(pub/sub) 패턴 표준, 다수 구독자에 팬아웃 ▸ API Gateway HTTP API — REST API보다 저렴한 서버리스 API(비용 효율) ▸ 이벤트 기반 느슨한 결합 + pub/sub + 최저 비용 【정답 포인트】 ▸ "pub/sub + 이벤트 기반 + 최저 비용" → 저렴한 API Gateway HTTP API가 Lambda 호출, Lambda가 SNS 토픽에 발행, 다수 구독자 수신(D) ▸ SNS는 pub/sub 팬아웃의 정석, HTTP API로 비용 절감 【오답 체크】 (A) SQS는 pub/sub이 아니라 큐(1:1 소비) 모델이라 발행/구독 요구에 부적합. (B) SNS는 맞으나 REST API가 HTTP API보다 비싸 최저 비용 목표에 덜 부합. (C) API Gateway WebSocket + Kinesis(향상된 팬아웃)는 과도하고 비용이 높음. 【시험 포인트】 pub/sub 팬아웃 → SNS. 비용 최적 서버리스 API → API Gateway HTTP API(REST보다 저렴). SQS는 큐(pub/sub 아님).

해설

【핵심 용어】 ▸ EC2 수직 확장(더 큰 인스턴스 타입) — 단일 인스턴스만 실행 가능한 앱의 CPU 병목 완화 ▸ ASG min=max=1 — 단일 인스턴스 유지하며 자동 복구 ▸ RDS Read Replica — 읽기 요청을 복제본으로 분리해 성능 개선 【정답 포인트】 ▸ "높은 CPU + 단일 인스턴스만 가능 + 읽기 성능 저하" → EC2를 더 큰 타입으로 리사이즈, ASG(min=max=1)로 유지, RDS read replica로 읽기 분리(A) ▸ 앱이 단일 인스턴스 제약이라 수평 확장 대신 수직 확장, 읽기 부하는 복제본으로 오프로딩 【오답 체크】 (B) 모든 읽기/쓰기를 복제본으로 리다이렉트하면 복제본은 읽기 전용이라 쓰기가 실패함. (C) ASG max=2는 단일 인스턴스만 가능한 앱 제약을 위반, RDS 리사이즈만으론 읽기 분리 이점 없음. (D) RDS를 더 큰 타입으로만 키우는 것은 읽기 분리(복제본) 대비 비용 효율·확장성이 낮음. 【시험 포인트】 단일 인스턴스 제약 앱 CPU 병목 → 수직 확장(더 큰 타입) + ASG(1). DB 읽기 부하 → Read Replica(쓰기는 기본 인스턴스 유지).

해설

【핵심 용어】 ▸ Auto Scaling group + ALB(수평 확장) — 인스턴스를 여러 대로 확장·분산해 100% CPU 병목·가용성 해결 ▸ AMI + Launch Template — ASG가 동일 구성 인스턴스를 기동하기 위한 이미지·템플릿 ▸ 수평 확장(scale horizontally)이 비용 효율·가용성에 유리 【정답 포인트】 ▸ "피크 시 CPU 100% + 성능·가용성 개선 + 비용 효율" → 웹 서버 AMI 생성 후 시작 템플릿에 참조(B), Auto Scaling group + ALB로 수평 확장(E) ▸ AMI→시작 템플릿→ASG→ALB로 부하에 따라 인스턴스 수평 확장, 단일 병목 제거 【오답 체크】 (A) Compute Optimizer로 수직 확장 타입 추천은 단일 인스턴스 한계·가용성 문제를 근본 해결 못함. (C) Auto Scaling group + ALB는 맞지만 "수직 확장(scale vertically)"이라는 설명이 잘못됨(ASG는 수평 확장). (D) Compute Optimizer는 인스턴스 타입 추천 도구로 "수평 확장" 추천을 제공하지 않음. 【시험 포인트】 CPU 병목 + 가용성 + 비용 효율 → 수평 확장(ASG + ALB), AMI+Launch Template로 기동. 수직 확장(더 큰 인스턴스)은 단일 장애·한계로 오답.

해설

【핵심 용어】 ▸ IAM Access Analyzer — 정책·접근 분석, 사용되지 않은 권한/과도한 권한을 식별(정책 검토 자동화) ▸ 최소 권한 검토 → 필요 이상 권한을 가진 IAM 사용자 식별 ▸ 최소 관리 부담으로 권한 검토 【정답 포인트】 ▸ "IAM 사용자가 필요 이상의 권한을 가졌는지 검토 + 최소 관리" → IAM Access Analyzer로 리소스·계정 접근 권한 분석(C) ▸ 관리형으로 과도 권한·미사용 접근을 식별해 최소 권한 검토 자동화 【오답 체크】 (A) Network Access Analyzer는 네트워크 경로 분석용으로 IAM 권한 검토와 무관. (B) CloudWatch 알람은 리소스 변경 이벤트 감지일 뿐 권한 과다 여부를 검토하지 못함. (D) Amazon Inspector는 워크로드 취약점 스캔용으로 IAM 정책 권한 검토 도구가 아님. 【시험 포인트】 IAM 권한 과다/미사용 접근 검토 + 최소 관리 → IAM Access Analyzer. 네트워크 경로는 Network Access Analyzer, 취약점은 Inspector.

해설

【핵심 용어】 ▸ S3 Object Lock — WORM(Write Once Read Many) 방식으로 객체의 삭제·변경을 일정 기간 방지 ▸ Compliance 모드 — 보존 기간 동안 root 계정 포함 누구도 삭제·기간단축 불가 (규제 준수용) ▸ Governance 모드 — 특별 권한(s3:BypassGovernanceRetention) 사용자는 우회·삭제 가능 【정답 포인트】 ▸ "규제 준수" + "고정 기간 동안 삭제·변경 방지" → 어떤 사용자도 우회 불가한 Compliance 모드 ▸ 규제(regulatory compliance) 요구는 우회 가능한 Governance가 아닌 Compliance가 표준 【오답 체크】 (A) Governance 모드는 권한 있는 사용자가 우회·삭제 가능 → 규제 준수 요건 미충족. (C) 버전 관리 + 수명주기 삭제는 오히려 자동 삭제하는 구조 → 삭제 방지 목적에 정반대. (D) Glacier 전환은 스토리지 계층 이동일 뿐 삭제·변경을 막지 못함. 【시험 포인트】 "규제 준수 + 절대 삭제/변경 불가" → Object Lock Compliance. 관리자 우회 허용이면 Governance.

해설

【핵심 용어】 ▸ Fargate — 서버 관리 없는 컨테이너 실행(ECS), 정상 상태 워크로드의 안정적 용량 확보 ▸ Fargate Spot — 최대 70% 저렴한 여유 용량, 중단 가능하므로 버스트·비핵심 트래픽에 적합 ▸ ECS Capacity Provider — 태스크를 Fargate/Fargate Spot에 비율로 배분하는 용량 전략 【정답 포인트】 ▸ "24/7 가용" 기본 부하 → 안정적인 Fargate로 상시 처리 ▸ "짧은 고트래픽 버스트" + "비용 최적화" → 버스트분만 저렴한 Fargate Spot으로 흡수 【오답 체크】 (A) 부하 테스트·라이트사이징만으로는 버스트 비용 절감 전략이 없음. (C) 정상 상태를 Spot에 두면 중단 위험으로 24/7 가용성 훼손 → 역할이 뒤바뀜. (D) Compute Optimizer 라이트사이징만으로 버스트 대응·비용 최적화 부족. 【시험 포인트】 "상시 부하 = Fargate, 버스트/비핵심 = Fargate Spot" 조합이 ECS 비용 최적화 정석.

해설

【핵심 용어】 ▸ AWS Shield Advanced — 관리형 DDoS 보호, SRT(Shield Response Team) 사전 참여(proactive engagement) 제공 ▸ AWS WAF — L7 웹 요청 필터링, DDoS 전용 사전 대응팀 참여는 제공하지 않음 ▸ Route 53 / ALB — Shield Advanced 보호 대상 리소스로 등록 가능 【정답 포인트】 ▸ "관리형" + "사전 참여(proactive engagement)로 DDoS 탐지" → Shield Advanced의 SRT 사전 참여가 유일한 부합 ▸ ALB·Route 53 hosted zone을 보호 리소스로 등록해 종합 방어 【오답 체크】 (A) AWS Config는 구성 규정 준수 평가 도구 → DDoS 탐지·방어 기능 아님. (B) WAF는 L7 필터링 가능하나 "사전 참여(managed proactive engagement)" 요건 미충족. (C) GuardDuty는 위협 탐지 서비스, DDoS 자동 방어·사전 참여 제공 아님. 【시험 포인트】 "관리형 + proactive engagement + DDoS" 키워드 = Shield Advanced (SRT).

해설

【핵심 용어】 ▸ AWS Shield Advanced — 관리형 고급 DDoS 보호, 최소 아키텍처 변경으로 리소스에 보호 적용 ▸ NLB(Network Load Balancer) — L4 TCP 처리, WAF 직접 연결 불가 ▸ Security Group / IP 허용목록 — NLB 재생성이나 추가 구성이 필요해 변경 규모 증가 【정답 포인트】 ▸ "최소 아키텍처 변경" + "관리형으로 무단 접근 시도 방어" → 기존 리소스에 구독만 추가하는 Shield Advanced ▸ NLB 재생성·병렬 배포 없이 보호 계층을 얹어 요건 충족 【오답 체크】 (A) WAF는 NLB(L4)에 직접 연결 불가 → 구성 자체가 성립하지 않음. (B) 보안 그룹 적용은 NLB 재생성이 필요 → "최소 아키텍처 변경"에 반함. (C) 두 번째 NLB 병렬 배포는 아키텍처 변경·비용이 큼. 【시험 포인트】 "NLB + 최소 변경 + 관리형 보호" → Shield Advanced. WAF는 L4 NLB에 못 붙는다는 점이 판별 핵심.

해설

【핵심 용어】 ▸ SNS 리소스 정책(access policy) — 어떤 주체가 토픽에 Publish 가능한지 정의 ▸ KMS 키 정책(resource policy) — 고객 관리형 키(CMK) 사용 권한을 주체에게 부여 ▸ Lambda 실행 역할 — Lambda가 다른 AWS 서비스(KMS 등)를 호출할 IAM 권한 보유 【정답 포인트】 ▸ (A) SNS 토픽 리소스 정책으로 Lambda의 Publish 허용 → 토픽 접근 권한 확보 ▸ (C) SNS가 쓰는 CMK의 키 정책에 필요한 KMS 권한 부여 → 암호화 토픽 발행 가능 ▸ (F) Lambda 실행 역할에 CMK 사용(kms:GenerateDataKey 등) IAM 권한 → 암호화 처리 가능 【오답 체크】 (B) CMK 대신 SSE-KMS 기본키 사용은 "고객 관리형 키" 요건을 바꿔버리는 회피책. (D) Lambda ARN을 SNS 정책에 넣는 것은 구독자 지정 개념, Publish 권한 부여 구조가 아님(A로 충족). (E) API Gateway HTTP API 연동은 불필요한 계층 추가, 권한 요건과 무관. 【시험 포인트】 암호화 토픽 발행은 "SNS 리소스 정책 + KMS 키 정책 + Lambda 실행 역할" 3중 권한이 모두 필요.

해설

【핵심 용어】 ▸ EC2 Auto Scaling group — 100% 가용성이 필요한 웹 포털의 상시·확장 실행 ▸ AWS Lambda — 간헐적·온디맨드 문서 추출 작업에 이벤트 기반으로 실행(유휴 시 비용 0) ▸ 이벤트 기반 호출 — 업로드 시 Lambda 트리거로 기존 포털 코드 변경 없이 신규 기능 추가 【정답 포인트】 ▸ "포털 100% 가동" → EC2 On-Demand ASG로 상시 가용 ▸ "간헐적 온디맨드 추출" + "코드 변경 없이 최소 노력" → 업로드 이벤트로 Lambda 호출 【오답 체크】 (B) Spot은 중단 가능 → 100% 가용 포털에 부적합, 인스턴스 기동 방식도 번거로움. (C) Savings Plan 자체는 아키텍처가 아니라 요금 약정 → 확장·트리거 설계 부재. (D) S3 정적 호스팅 + API Gateway 재구성은 기존 포털을 뜯어고쳐야 함 → "코드 변경 없음"에 위배. 【시험 포인트】 "상시 가용 = ASG, 간헐적 처리 = Lambda(이벤트 트리거)"가 최소 노력 조합.

해설

【핵심 용어】 ▸ SNS 교차 계정 구독 — 프로덕션 계정 토픽을 관리자 계정 Lambda가 구독하려면 양쪽 권한 필요 ▸ Lambda 리소스 정책 — SNS가 함수를 호출(invoke)하도록 허용하는 권한 ▸ SNS 토픽 정책 — 다른 계정 주체(Lambda)가 subscribe 하도록 허용 【정답 포인트】 ▸ (A) Lambda 리소스 정책에 SNS의 lambda:InvokeFunction 허용 → SNS가 함수 호출 가능 ▸ (C) SNS 토픽 정책에 Lambda의 구독 허용 → 교차 계정 구독 성립 【오답 체크】 (B) SQS 버퍼 추가는 요구되지 않은 계층 → 직접 구독으로 충분, 불필요한 복잡성. (D) EventBridge로 SNS를 캡처·전달하는 구조는 과설계, 직접 SNS→Lambda 구독이 정석. (E) S3 저장 + Athena 분석은 실시간 호출 요건(메트릭 시 함수 호출)과 무관. 【시험 포인트】 교차 계정 SNS→Lambda는 "Lambda 리소스 정책(호출 허용) + SNS 토픽 정책(구독 허용)" 쌍.

해설

【핵심 용어】 ▸ Amazon VPC CNI plugin — EKS 파드에 VPC IP를 직접 할당, 커스텀 서브넷 지정 가능 ▸ Custom networking — CNI 설정으로 파드를 별도 지정 서브넷에 배치 ▸ VPC 내 통신 — 파드가 VPC 네이티브 IP를 가져 보안 그룹·라우팅으로 안전 통신 【정답 포인트】 ▸ "파드용 커스텀 서브넷" + "VPC 내 안전 통신" → VPC CNI 플러그인으로 커스텀 서브넷 정의가 정확한 해법 ▸ 파드가 VPC IP를 직접 사용해 네이티브 네트워크 정책 적용 【오답 체크】 (A) Transit Gateway는 VPC/온프렘 간 라우팅용, 파드 서브넷 관리 기능 없음. (B) Direct Connect는 온프레미스 연결용, 파드 서브넷 요건과 무관. (D) anti-affinity 네트워크 정책은 파드 배치 제어일 뿐 커스텀 서브넷 IP 할당과 다름. 【시험 포인트】 "EKS 파드에 커스텀/전용 서브넷 IP" → VPC CNI custom networking.

해설

【핵심 용어】 ▸ RDS Multi-AZ — 다른 AZ에 동기 대기 인스턴스 유지, 장애 시 자동 페일오버로 SPOF 제거 ▸ 단일 장애점(SPOF) — 단일 인스턴스 구조의 위험, Multi-AZ로 완화 ▸ 유지관리 창(maintenance window) — 인스턴스 수정을 최소 영향으로 적용 【정답 포인트】 ▸ "SPOF 완화" + "최소 구현 노력" → 기존 인스턴스를 Multi-AZ로 수정하기만 하면 됨(데이터 이전 불필요) 【오답 체크】 (B) DynamoDB로 이기종 마이그레이션은 대규모 재설계 → 노력 과다. (C) 새 Multi-AZ 인스턴스 생성 후 스냅샷 수동 복원은 다운타임·수작업 발생. (D) EC2 ASG + Route 53으로 DB를 스케일아웃하는 구조는 RDS 관리형 특성에 맞지 않고 복잡. 【시험 포인트】 "기존 RDS의 SPOF 제거, 최소 노력" → Multi-AZ 전환(설정 수정) 한 방.

해설

【핵심 용어】 ▸ Amazon FSx for NetApp ONTAP — NFS·SMB·iSCSI 다중 프로토콜 지원, 프로토콜 간 동일 데이터 공유 ▸ Multi-AZ 배포 — AZ 수준 이중화 제공 ▸ FSx for Lustre — 고성능 컴퓨팅용(NFS), SMB 미지원 【정답 포인트】 ▸ "NFS+SMB 동시 지원" + "프로토콜 간 공유" + "AZ 이중화" → FSx for NetApp ONTAP 멀티프로토콜이 유일 부합 【오답 체크】 (B) EC2 두 대로 파일서버 구성은 관리형 아님 + AZ 이중화·자동화 부재. (C) FSx for Lustre는 SMB 미지원 → NFS/SMB 통합 요건 불충족. (D) S3 File Gateway는 단일 프로토콜 게이트웨이로 NFS/SMB 통합 공유·AZ 이중화 요건에 부적합. 【시험 포인트】 "NFS + SMB 동시 + 프로토콜 간 공유" 관리형 = FSx for NetApp ONTAP.

해설

【핵심 용어】 ▸ Auto Scaling group + ALB — 다중 AZ에 EC2를 프라이빗 배치해 확장성·고가용성 확보 ▸ Aurora MySQL 클러스터 — Primary + Reader를 서로 다른 AZ에 두어 HA + 읽기 지연 감소 ▸ Reader 엔드포인트 — 읽기 부하 분산으로 read latency 완화 【정답 포인트】 ▸ (B) 다중 AZ ASG + ALB → 웹 계층 확장성·고가용성 ▸ (C) Aurora MySQL Primary/Reader를 별도 AZ 배치 → DB HA + 리더로 읽기 지연 감소 【오답 체크】 (A) 두 번째 리전 단일 EC2 + 페일오버는 확장성 부재 + 단일 인스턴스 한계. (D) ASG를 여러 리전에 걸쳐 한 ALB 뒤에 두는 구성은 불가능(ALB는 단일 리전). (E) 교차 리전 리드 리플리카는 지연·복잡도↑, 동일 리전 리더가 읽기 지연 감소에 더 적합. 【시험 포인트】 "웹 확장·HA = 멀티 AZ ASG+ALB", "읽기 지연 감소 = Aurora 리더(별도 AZ)".