정답 · 해설

해설

【핵심 용어】 ▸ S3 Gateway VPC Endpoint — VPC 라우팅 테이블 경유로 S3에 프라이빗 접근(퍼블릭 엔드포인트/인터넷 미경유), 추가 비용 없음 ▸ 퍼블릭 엔드포인트 회피 — 트래픽이 인터넷을 타지 않도록 ▸ 라우팅 테이블 — 서브넷에서 엔드포인트로 경로 지정 【정답 포인트】 ▸ "S3 트래픽이 퍼블릭 엔드포인트를 사용하지 않도록" → S3 Gateway Endpoint 생성 후 서브넷 라우팅 테이블에서 이를 경유하도록 설정 【오답 체크】 (B) S3 버킷을 VPC 내부로 이동하는 것은 불가능한 개념. (C) S3 Access Point만으로는 프라이빗 경로가 생기지 않아(엔드포인트 없이는) 여전히 퍼블릭 접근. (D) Direct Connect는 온프레미스 전용 연결로 이 시나리오에 부적합. 【시험 포인트】 "VPC에서 S3 프라이빗 접근 + 비용" → Gateway Endpoint + 라우팅 테이블.

해설

【핵심 용어】 ▸ Amazon ElastiCache for Redis — 인메모리 캐시로 DB 부하 오프로드, 읽기 위주·자주 안 바뀌는 데이터에 적합 ▸ Lazy loading(지연 로딩) — 캐시 미스 시에만 DB 조회 후 캐시 적재 ▸ 제품 카탈로그 검색 시 DB CPU 급증 — 읽기 부하 문제 【정답 포인트】 ▸ "제품 카탈로그(자주 업데이트 안 됨) 검색 시 DB CPU 높음" → ElastiCache for Redis로 카탈로그를 캐싱(lazy loading)해 DB 읽기 부하 제거, 응답 개선 【오답 체크】 (A) Redshift는 분석용 데이터 웨어하우스로 OLTP 검색 캐싱 목적에 부적합. (C) 웹 계층 EC2 스케일은 DB CPU 병목을 해소하지 못함. (D) Multi-AZ는 가용성용이지 읽기 성능 개선이 아니며, 쿼리 스로틀은 사용자 경험 저하. 【시험 포인트】 "읽기 위주 + 자주 안 바뀜 + DB CPU 병목" → ElastiCache 캐싱. Multi-AZ=가용성이지 성능 아님.

해설

【핵심 용어】 ▸ Storage Gateway Volume Gateway (cached volumes) — 주 데이터는 S3에 저장, 자주 접근하는 데이터만 온프레미스에 캐시해 저지연 제공, iSCSI 블록 제공 ▸ stored volumes — 전체 데이터를 온프레미스에 보관(S3는 백업본)으로 공간 문제 해소 못함 ▸ 온프레미스 블록 스토리지 공간 부족 → 클라우드 확장 필요 【정답 포인트】 ▸ "온프레미스 공간 부족 + 자주 접근 데이터 저지연 + 클라우드 스토리지" → Cached Volume Gateway로 주 데이터는 S3, 핫 데이터는 로컬 캐시(iSCSI) 【오답 체크】 (A) S3 File Gateway는 SMB/NFS 파일 인터페이스로 블록(iSCSI) 요건과 다름. (C) Stored volumes는 전체 데이터를 로컬에 유지해 온프레미스 공간 부족 문제를 해결하지 못함. (D) Tape Gateway는 백업/아카이브용 가상 테이프로 저지연 접근용이 아님. 【시험 포인트】 "블록 + 로컬 저지연 캐시 + 주 데이터는 S3" → Cached Volume Gateway. Stored는 로컬 상주.

해설

【핵심 용어】 ▸ Amazon SQS + Auto Scaling — 큐의 메시지 수(ApproximateNumberOfMessages)로 백로그 기반 스케일링, 데이터 유실 없이 비동기 처리 ▸ 수집/처리 분리 — 두 개의 큐로 각 단계 독립 확장 ▸ 예측 불가 피크 — 큐 깊이 기반 자동 스케일이 적합 【정답 포인트】 ▸ "수집·처리 모두 적절히 스케일 + 데이터 유실 방지" → 수집용/처리용 SQS 큐 2개를 두고 각 ASG를 큐의 메시지 수에 따라 스케일 【오답 체크】 (A) 최소 용량을 피크에 맞추면 상시 과다 프로비저닝으로 비효율. (B) CloudWatch 알람으로 ASG를 온디맨드로 생성하는 방식은 비표준·오버헤드. (C) SQS 큐는 스케일링 "알림"을 보내지 않음. 큐 깊이 메트릭 기반 스케일(D)이 올바른 방식. 【시험 포인트】 큐 기반 워커 스케일 = ApproximateNumberOfMessages(큐 깊이) 메트릭. CPU/알림 방식은 함정.

해설

【핵심 용어】 ▸ DynamoDB Global Tables — 다중 Region 자동 양방향 복제, 관리형으로 지속 가용·복원력 제공 ▸ Provisioned capacity + Auto Scaling — 예측 가능한 워크로드에서 on-demand 대비 비용 효율 ▸ on-demand capacity — 관리 편하나 지속 고부하엔 비용 높을 수 있음 【정답 포인트】 ▸ "지속 가용·복원력 + MOST cost-effective" → 다중 Region Global Tables(관리형 복제) + 프로비저닝 용량 + Auto Scaling으로 비용 최적 【오답 체크】 (A) 단일 Region인데 "global tables 복제"라는 설명이 모순 + on-demand는 비용 최적 아님. (B) DAX + 수동 교차 리전 복제는 오버헤드·복원력 부족(Global Tables 미활용). (C) 다중 테이블 + DynamoDB Streams 수동 복제는 Global Tables 대비 관리 오버헤드 큼. 【시험 포인트】 "DynamoDB 다중 Region 지속 가용" = Global Tables(관리형). 지속 부하 비용 최적 = 프로비저닝 + Auto Scaling.

해설

【핵심 용어】 ▸ Amazon S3 File Gateway — 온프레미스에서 S3를 파일(NFS/SMB)로 접근하며 로컬 캐시로 저지연 제공, 데이터는 S3에 저장(스토리지 비용 절감) ▸ 온프레미스 저지연 접근 + S3 비용 절감 — 캐시형 게이트웨이가 최적 ▸ Mountpoint for S3 — S3를 파일처럼 마운트하나 로컬 캐싱이 없어 반복 접근 저지연에 불리 【정답 포인트】 ▸ "데이터는 S3, 온프레미스 앱은 저지연 접근 + MOST cost-effective" → S3 File Gateway로 로컬 캐시 기반 저지연 파일 접근 【오답 체크】 (A) Mountpoint for S3는 로컬 캐시 기반 저지연 제공이 약해 반복 접근 성능에 불리. (C) S3→FSx 복사 + FSx File Gateway는 스토리지 중복으로 비용 증가. (D) 온프레미스 파일 서버 + S3 API 커스텀 구성은 운영 오버헤드 큼. 【시험 포인트】 "온프레미스 저지연 + 데이터는 S3 + 비용" → S3 File Gateway(로컬 캐시).

해설

【핵심 용어】 ▸ AWS Global Accelerator — AWS 글로벌 네트워크·애니캐스트 IP로 TCP/UDP 트래픽을 최적 경로로 라우팅, 캐시 불가한 동적 API 응답 시간 개선에 적합 ▸ 공개 API(EC2 호스팅) — 동적 응답이라 캐싱 이점 제한 ▸ CloudFront — 캐싱 CDN, 정적/캐시 가능 콘텐츠에 강점 【정답 포인트】 ▸ "국제 고객의 느린 API 응답 개선 + MOST cost-effective" → Global Accelerator로 엣지 진입 + AWS 백본 경유로 지연 단축(동적 API에 적합) 【오답 체크】 (A) 고객마다 Direct Connect 퍼블릭 VIF 구성은 비용·복잡도 과다. (B) CloudFront CachingOptimized는 동적 API 응답에 캐시 이점이 제한적. (D) 지역·고객마다 Site-to-Site VPN 구성은 관리 오버헤드 크고 비효율. 【시험 포인트】 "동적 API 글로벌 지연 개선" → Global Accelerator. 캐시 가능 콘텐츠면 CloudFront.

해설

【핵심 용어】 ▸ API Gateway + SQS + Lambda — 서버리스 수집·완충·처리 파이프라인, 시간당 수천 건에도 자동 확장 ▸ Amazon Comprehend — 텍스트 감정 분석(NLP) 관리형 서비스 ▸ DynamoDB TTL — 레코드 자동 만료(365일 보존 후 삭제) 【정답 포인트】 ▸ "설문 자동화 + 감정 분석 + 12개월 보존 + MOST scalable" → API Gateway→SQS 완충→Lambda가 Comprehend로 감정 분석 후 DynamoDB 저장, TTL 365일로 보존 【오답 체크】 (B) EC2 기반 API는 서버리스 대비 확장성·운영 효율이 낮음. (C) Rekognition은 이미지/영상 분석이라 텍스트 감정 분석에 부적합. (D) Lex는 대화형 챗봇용이며 감정 분석 서비스가 아님. 【시험 포인트】 텍스트 감정 분석 = Comprehend(이미지=Rekognition, 챗봇=Lex). 서버리스 스케일 = API GW + SQS + Lambda.

해설

【핵심 용어】 ▸ SSM Automation 문서(AWSEC2-PatchLoadBalancerInstance 계열) — 패치 중 대상 인스턴스를 ALB 대상 그룹에서 자동 등록 해제/재등록해 무중단 패치 ▸ Systems Manager Maintenance Windows — 패치 작업을 예약 창에서 자동 실행, 서비스 제외/복귀 자동화 ▸ IP 유형 대상 그룹 + ALB — 패치 시 트래픽 차단 필요 【정답 포인트】 ▸ (C) AWSEC2-PatchLoadBalancerInstance Automation 문서로 로드밸런서에서 인스턴스를 빼고 패치하는 프로세스 관리 ▸ (D) Maintenance Windows로 인스턴스를 서비스에서 자동 제외하고 패치 스케줄 자동화 → 패치 중 오류 해소 【오답 체크】 (A) 대상 그룹 유형을 IP→instance로 바꾸는 것은 요구되지도 않고 오류 원인 해결과 무관. (B) 기존 문서를 그대로 두는 선택은 문제 미해결. (E) State Manager로 서비스 제외를 처리한다는 설명은 부정확한 사용 방식. 【시험 포인트】 ALB 뒤 인스턴스 무중단 패치 = 등록 해제 Automation 문서 + Maintenance Windows 자동화.

해설

【핵심 용어】 ▸ AWS Glue — 서버리스 ETL, 관리형이라 클러스터 운영 부담이 EMR보다 작음, 잡별 보안 구성 부착 가능 ▸ CSE-KMS(Client-Side Encryption with KMS) — 데이터를 처리하는 클라이언트 측에서 KMS 키로 암호화 후 S3 저장(고객별 키 = KMS 키) ▸ SSE-* — S3 저장 시점 서버측 암호화(처리 중 암호화 아님) 【정답 포인트】 ▸ "처리되는 곳에서 암호화 + 고객별 키 + LEAST effort" → Glue 잡(고객별)에 CSE-KMS 보안 구성 부착 → 처리 단계에서 KMS 키로 클라이언트측 암호화 【오답 체크】 (A) SSE-S3는 S3 관리 키로 저장 시 암호화라 "처리 중 암호화"·고객별 키 요건 불충족. (B) EMR + CSE-Custom은 커스텀 루트 키·클러스터 운영으로 관리 노력 큼. (D) EMR + SSE-KMS는 S3 저장 시점 암호화이며 EMR 클러스터 관리 오버헤드 큼. 【시험 포인트】 "처리 중(client-side) 암호화 + 고객별 KMS 키" = CSE-KMS. 서버리스 최소 운영 = Glue(EMR 대비).

해설

【핵심 용어】 ▸ Auto Scaling group + Launch Template — 부하에 따라 인스턴스 자동 확장/축소, 원활한 스케일 ▸ Spot Fleet — 스팟 인스턴스 활용으로 비용 최적(무상태·복원력 있는 앱에 적합) ▸ Application Load Balancer — 다중 인스턴스로 트래픽 분산, 5xx 오류·성능 저하 완화 【정답 포인트】 ▸ "무상태·복원력 있는 앱 + 원활히 스케일 + MOST cost-effective" → AMI 기반 Launch Template + ASG + Spot Fleet + ALB로 자동 확장하며 스팟으로 비용 절감 【오답 체크】 (A) On-Demand 인스턴스 2대 고정은 자동 스케일이 아니고 비용도 높음. (B) Route 53 weighted + 고정 2대도 자동 스케일이 아님. (C) Lambda로 인스턴스 중지·타입 변경은 다운타임 발생으로 "seamless"에 반함. 【시험 포인트】 "무상태 앱 원활 스케일 + 비용 최적" → ASG + ALB + Spot. 고정 인스턴스 2대는 스케일 아님.

해설

【핵심 용어】 ▸ S3 Bucket Key — SSE-KMS 사용 시 버킷 단위 데이터 키를 도입해 KMS 호출 횟수·비용 대폭 절감 ▸ SSE-KMS — 객체마다 KMS 호출 발생(Bucket Key로 완화) ▸ 자주 접근하는 객체 + KMS 유지 요건 — KMS 호출 비용이 부담 【정답 포인트】 ▸ "KMS 암호화 유지 + 추가 KMS 호출 없이 비용 최적화" → 신규 객체에 SSE-KMS + S3 Bucket Key 적용으로 KMS 호출 감소 【오답 체크】 (A) SSE-S3는 KMS를 사용하지 않아 "KMS 사용" 요건과 상충. (C) 클라이언트측 KMS 암호화는 오히려 KMS 호출을 늘림. (D) SSE-C는 고객 제공 키를 직접 관리해야 하며 요건과 부합하지 않음. 【시험 포인트】 "SSE-KMS 유지 + KMS 호출/비용 절감" → S3 Bucket Key.

해설

【핵심 용어】 ▸ AWS Application Migration Service (MGN) — 리프트 앤 시프트 마이그레이션 표준, VM에 Replication Agent 설치 후 블록 복제 ▸ 마이그레이션 흐름 — 초기 복제 → 테스트 인스턴스로 검증 → 컷오버 인스턴스 실행 ▸ 시간 민감 + 비핵심 워크로드 리호스팅 — MGN 자동화 【정답 포인트】 ▸ (B) MGN 사용 + VM에 AWS Replication Agent 설치로 복제 시작 ▸ (C) 초기 복제 완료 후 테스트 인스턴스로 인수 테스트 수행 ▸ (D) VM 작업 중지 후 컷오버 인스턴스 실행으로 최종 전환 【오답 체크】 (A) SCT는 데이터베이스 스키마 변환 도구로 VM 리프트 앤 시프트와 무관. (E) App2Container는 앱 컨테이너화 도구로 VM 통째 이전(리호스팅)과 다름. (F) DMS는 데이터베이스 마이그레이션용으로 VM 이전에 부적합. 【시험 포인트】 VM 리프트 앤 시프트 = MGN(Replication Agent→복제→테스트→컷오버). SCT/DMS=DB, A2C=컨테이너화.

해설

【핵심 용어】 ▸ Amazon Cognito Identity Pool — 인증된 사용자에게 임시 AWS 자격 증명(STS)을 발급해 S3 등 AWS 리소스 직접 접근 허용 ▸ Cognito User Pool — 사용자 인증(로그인)용이며 AWS 자격 증명 발급 기능은 아님 ▸ S3 VPC Endpoint — 프라이빗 서브넷에서 S3로 프라이빗 접근 【정답 포인트】 ▸ (A) Identity Pool로 로그인 성공 사용자에게 S3 접근용 임시 자격 증명 발급 ▸ (C) 앱이 있는 VPC에 S3 VPC 엔드포인트를 만들어 프라이빗 서브넷에서 안전하게 S3 접근 【오답 체크】 (B) User Pool은 인증용이며 S3 접근 자격 증명(토큰)을 발급하지 못함(Identity Pool 역할). (D) NAT gateway + "Cognito에서 시작되지 않은 요청 거부" 정책은 비용·비현실적 구성. (E) 사용자 IP 기반 버킷 제한은 모바일 사용자에게 비현실적·비안전. 【시험 포인트】 Cognito로 AWS 리소스(S3) 접근 자격 = Identity Pool(User Pool은 인증만). 프라이빗 접근 = S3 VPC Endpoint.

해설

【핵심 용어】 ▸ EC2 Auto Scaling 대상 추적(target tracking) — 지정 메트릭을 목표값으로 유지하도록 자동 확장/축소 ▸ SQS ApproximateNumberOfMessages — 큐 백로그 지표로 처리 계층 스케일 판단에 적합 ▸ 예측 불가 가변 피크 + 큐 적체 + 100% CPU — 큐 깊이 기반 스케일 필요 【정답 포인트】 ▸ "가변·예측 불가 피크에 처리 계층 성능 개선" → SQS ApproximateNumberOfMessages를 대상 추적 메트릭으로 처리 계층 ASG를 스케일 아웃 【오답 체크】 (A) 예약(scheduled) 스케일은 피크 시간이 예측 가능해야 하는데 여기선 불규칙. (B) ElastiCache는 DynamoDB 읽기용이며 처리 계층 CPU·큐 적체를 해결하지 못함. (C) CloudFront는 웹 계층 캐싱용으로 처리 계층 병목과 무관. 【시험 포인트】 SQS 소비자(처리 계층) 스케일 = 큐 깊이(ApproximateNumberOfMessages) 대상 추적. 예측 불가 피크에 scheduled는 부적합.

해설

【핵심 용어】 ▸ Scheduled Reserved Instances — 정기적으로 반복되는 특정 시간대(일요일 12시간)에 예약 실행, 중단 없이 비용 절감 ▸ Standard Reserved Instances — 상시 가동(월~토 연속) 인스턴스에 최대 할인 ▸ Spot Instances — 중단 가능성이 있어 "중단 불가" 요건에 부적합 【정답 포인트】 ▸ "일요일 12시간만 실행 + 중단 불가" → 반복 스케줄엔 Scheduled RI ▸ "월~토 상시 가동" → Standard RI로 최대 할인 【오답 체크】 (B) Sunday에 Convertible RI는 반복 시간대 대상 Scheduled RI보다 비용 최적성이 낮음. (C) Spot은 중단 가능성으로 "중단 불가" 요건 위배(Sunday 워크로드). (D) 마찬가지로 Sunday에 Spot 사용은 중단 불가 요건 위배. 【시험 포인트】 "정기 반복 특정 시간대 + 중단 불가" → Scheduled RI. 상시 가동 → Standard RI. 중단 불가면 Spot 배제.

해설

【핵심 용어】 ▸ AWS Batch — 대량 배치 작업(이미지 처리 잡) 큐잉·스케일링을 완전관리, 인프라 관리 불필요 ▸ AWS Step Functions — 워크플로 오케스트레이션으로 수동 작업 감소 ▸ Amazon S3 — 처리 결과 대용량 파일 저장에 적합·확장성 【정답 포인트】 ▸ "증가하는 이미지 처리 잡 관리 + 수동 작업 감소 + 인프라 비관리 + LEAST overhead" → AWS Batch로 잡 처리, Step Functions로 워크플로 오케스트레이션, 결과는 S3 저장 【오답 체크】 (A) ECS on EC2 Spot은 EC2 인프라 관리가 남고 Spot 중단 고려 필요. (C) Lambda는 대용량·장시간 처리에 제약(시간/자원)이고 EC2 Spot 혼용은 관리 부담. (D) EC2 인스턴스 직접 운영 + EBS 저장은 인프라 관리 오버헤드 큼. 【시험 포인트】 "대량 배치 잡 + 인프라 비관리 + 오케스트레이션" → AWS Batch + Step Functions + S3.

해설

【핵심 용어】 ▸ Amazon CloudFront — 엣지 캐싱으로 다운로드(뷰) 성능 개선, S3 버킷을 오리진으로 사용 ▸ S3 Transfer Acceleration — 엣지 로케이션 경유로 글로벌 업로드 속도 향상 ▸ 최소 구현 노력 — 기존 S3 정적 사이트에 기능만 추가 【정답 포인트】 ▸ "업로드·다운로드 지연 개선 + LEAST implementation effort" → CloudFront(다운로드 가속) + S3 Transfer Acceleration(업로드 가속)만 활성화 【오답 체크】 (B) 다중 Region EC2 마이그레이션 + ALB + Global Accelerator는 구현 노력이 큼. (C) 다중 Region 버킷 복제 + 위치 기반 리다이렉트는 구현 복잡도 과다. (D) Global Accelerator를 S3 오리진에 직접 붙이는 방식은 이 시나리오의 표준 해법이 아님. 【시험 포인트】 "S3 다운로드 가속=CloudFront, 업로드 가속=Transfer Acceleration". 최소 노력 조합.

해설

【핵심 용어】 ▸ S3 Gateway Endpoint — VPC 라우팅 테이블 경유 S3 프라이빗 접근, 추가 요금 없음(가장 비용 효율) ▸ S3 Interface Endpoint — ENI 기반이라 시간당·데이터 처리 요금 발생 ▸ NAT gateway — 인터넷 경유(정책상 금지) + 비용 발생 【정답 포인트】 ▸ "S3 API 호출 트래픽이 인터넷을 경유하지 않도록 + MOST cost-effective" → 무료인 S3 Gateway Endpoint 구성 후 VPC 라우팅 테이블에서 경유 【오답 체크】 (A) Interface Endpoint는 동작하지만 시간·데이터 요금이 있어 Gateway 대비 비용 비효율. (C) NAT gateway EIP 허용은 트래픽이 여전히 인터넷을 경유해 정책 위반. (D) 두 번째 NAT gateway 역시 인터넷 경유 + 추가 비용으로 부적합. 【시험 포인트】 "VPC→S3 프라이빗 + 최저 비용" → Gateway Endpoint(무료). Interface는 유료, NAT는 인터넷 경유.

해설

【핵심 용어】 ▸ IAM Roles for Service Accounts (IRSA) — EKS의 Kubernetes 서비스 어카운트에 IAM 역할을 매핑해 Pod별 세분 권한 부여 ▸ Kubernetes Service Account — Pod가 특정 IAM 역할을 assume하는 단위 ▸ 요구 매핑 — UI Pod → DynamoDB만, 데이터 서비스 Pod → S3만 【정답 포인트】 ▸ "UI Pod는 DynamoDB만, 데이터 서비스 Pod는 S3만" → 서비스 어카운트별로 IAM 역할을 assume하게 하고 데이터 서비스에 S3, UI에 DynamoDB 정책을 부착(매핑이 요구사항과 정확히 일치) 【오답 체크】 (A) 두 정책을 EC2 인스턴스 프로파일에 함께 부착하면 노드의 모든 Pod가 S3·DynamoDB에 접근 가능해 격리 실패. (B) IAM 정책을 Pod에 직접 부착하는 방식은 불가능(IAM은 Pod에 직접 attach되지 않음). (D) IRSA 방식 자체는 맞지만 매핑이 반대(UI→S3, 데이터 서비스→DynamoDB)로 되어 있어 요구사항에 위배. 【시험 포인트】 EKS Pod별 권한 = 서비스 어카운트 기반 IAM 역할(IRSA). 정답 선택 시 서비스↔권한 매핑 방향까지 확인(반대면 오답).