정답 · 해설

해설

【핵심 용어】 】 ▸ S3 Transfer Acceleration — CloudFront 엣지를 통한 S3 업로드 가속 ▸ Edge-optimized API Gateway — CloudFront를 통한 API 요청 최적화 ▸ Global Accelerator — Anycast IP로 최적 경로 제공 ▸ 유럽 외부 지연시간 → CloudFront 엣지 활용 필요 【정답 포인트】 트】 ▸ (A) S3 Transfer Acceleration = 문서 업로드 가속 (CloudFront 엣지) ▸ (C) Edge-optimized API Gateway = API 요청 경로 최적화 (CloudFront) ▸ 두 가지 모두 CloudFront 엣지 네트워크 활용 ▸ 비용 효율적이고 기존 CloudFront와 통합 【오답 체크】 】 (B) Global Accelerator는 CloudFront를 대체하지 않음, 함께 사용 불가 (D) 다중 리전 배포는 복잡하고 높은 비용 (E) RDS Proxy는 지연시간 개선과 무관 【시험 포인트】 트】 지역별 지연시간 → CloudFront 엣지 활용 업로드 가속 → S3 Transfer Acceleration API 지연시간 → Edge-optimized 엔드포인트 엣지 기술 조합 → 비용 효율적 글로벌 확대

해설

【핵심 용어】 】 ▸ S3 Intelligent-Tiering — 접근 패턴에 따라 자동으로 스토리지 클래스 전환 ▸ Millisecond retrieval — 즉시 접근 가능 (Glacier는 시간 소요) ▸ 접근 빈도 차이 → 자동 최적화 필요 【정답 포인트】 트】 ▸ "일부는 자주, 일부는 거의" → 자동 티어링 필요 ▸ "밀리초 검색" → Glacier Deep Archive는 부적합 ▸ S3 Intelligent-Tiering = 접근 패턴 자동 감지 및 최적 클래스 선택 ▸ 수동 정책 불필요, 자동 최적화로 비용 절감 【오답 체크】 】 (B) Glacier Deep Archive는 밀리초 검색 불가능 (시간 단위 복원) (C) EFS는 S3보다 비싼 파일 시스템 (D) Cache-Control은 CloudFront 캐시만 제어, S3 스토리지 비용 미감소 【시험 포인트】 트】 혼합 접근 패턴 → S3 Intelligent-Tiering 즉시 접근 + 비용 최적화 → 자동 티어링 밀리초 가용성 → Glacier 제외

해설

【핵심 용어】 】 ▸ S3 Storage Lens — S3 스토리지 메트릭 및 분석 도구 ▸ 고급 메트릭 — 12개월 기록, 접근 패턴 분석 ▸ 스토리지 클래스 최적화 → 접근 데이터 필수 【정답 포인트】 트】 ▸ "지난 12개월 데이터 추세" → 장기 메트릭 필요 ▸ "스토리지 클래스 식별" → 접근 패턴 분석 필요 ▸ S3 Storage Lens + Advanced Metrics = 접근 빈도 및 크기 추적 ▸ 일반 대시보드 업그레이드로 완전한 분석 【오답 체크】 】 (A) Cost and Usage Report는 비용만 추적, 접근 패턴 분석 불가 (B) Storage Class Analysis는 기본 기능이지만 고급 분석 부족 (D) Access Analyzer는 접근 권한 분석, 메트릭 분석 아님 【시험 포인트】 트】 장기 S3 메트릭 → S3 Storage Lens 고급 분석 → Advanced Metrics 업그레이드 스토리지 비용 최적화 → 접근 데이터 기반 결정

해설

【핵심 용어】 】 ▸ CloudFormation StackSets — 여러 계정과 리전에 스택 배포 ▸ AWS Organizations — 다중 계정 관리 ▸ 다중 리전 + 다중 계정 배포 【정답 포인트】 트】 ▸ "여러 리전" + "여러 AWS 계정" → StackSets 필수 ▸ Organizations와 StackSets 조합 ▸ 권한이 있는 계정에서 배포하면 자동으로 다른 계정에 복제 ▸ 단일 템플릿으로 모든 배포 관리 【오답 체크】 】 (A) IAM 정책만으로는 계정 간 배포 자동화 불가 (B) Control Tower는 계정 생성/관리용, 템플릿 배포 전담 아님 (D) 중첩된 스택은 단일 스택 내 계층 구조, 다중 계정 배포 불가능 【시험 포인트】 트】 다중 계정 + 다중 리전 → StackSets IaC 중앙 관리 → Organizations + StackSets 확장 가능한 배포 → 단일 템플릿 + StackSets

해설

【핵심 용어】 】 ▸ CloudFormation StackSets — 여러 계정과 리전에 스택 배포 ▸ AWS Organizations — 다중 계정 관리 ▸ 권한 위임 — 중앙에서 다중 계정 배포 제어 【정답 포인트】 트】 ▸ "여러 리전" + "여러 AWS 계정" → StackSets 필수 ▸ StackSets는 권한 위임으로 대규모 배포 관리 ▸ 단일 템플릿으로 모든 계정과 리전 제어 ▸ Organizations와 함께 사용하면 조직 구조 활용 【오답 체크】 】 (A) IAM 정책만으로 자동 배포 불가 (B) Control Tower는 거버넌스 도구, 배포 자동화 미담당 (D) 중첩 스택은 단일 계정/리전 내에서만 작동 【시험 포인트】 트】 대규모 인프라 배포 → StackSets 다중 계정 조직 → Organizations + StackSets 중앙 관리 + 분산 배포 → StackSets 권한 위임

해설

【핵심 용어】 】 ▸ Elastic Beanstalk 환경 교환 — 스테이징과 프로덕션 URL 스왑 ▸ Blue/Green 배포 — 새 버전과 이전 버전 동시 준비 ▸ 빠른 롤백 — URL 교환으로 즉시 이전 버전으로 복원 【정답 포인트】 트】 ▸ "시간당 여러 번 변경" → 빠른 배포 기능 ▸ "최대한 빠른 롤백" → URL 교환 방식 (초 단위) ▸ Elastic Beanstalk Blue/Green = 두 환경 준비 후 URL 교환 ▸ 무중단 배포 + 즉시 롤백 가능 【오답 체크】 】 (A) AMI 기반 배포는 느리고 롤백 복잡 (C) Systems Manager는 배포 자동화 불충분, Route 53 교환도 느림 (D) Auto Scaling은 점진적 배포로 빠른 롤백 불가 【시험 포인트】 트】 고속 배포 + 빠른 롤백 → Blue/Green 패턴 Elastic Beanstalk → 환경 교환 기능 무중단 배포 → URL 스왑 (즉시 적용)

해설

【핵심 용어】 】 ▸ 보안 그룹 방향 — 인바운드(수신), 아웃바운드(송신) ▸ 양방향 통신 — EC2→DB(요청), DB→EC2(응답) ▸ 최소 권한 — 필수 포트만 개방 【정답 포인트】 트】 ▸ (B) EC2 아웃바운드 = EC2에서 DB로 요청 전송 ▸ (C) DB 인바운드 = DB가 EC2 요청 수신 ▸ 두 규칙 모두 필요: 요청 (B) + 수신 (C) ▸ 기본 Aurora 포트 = 3306 ▸ 최소 권한 = 필요한 포트만 지정 【오답 체크】 】 (A) EC2 인바운드는 DB→EC2 응답용이 아님 (D) DB 아웃바운드는 EC2로 응답을 보낼 필요 없음 (E) 임시 포트는 응답용이지만 DB는 응답 아웃바운드 불필요 【시험 포인트】 트】 EC2 → DB 통신 → EC2 아웃바운드 + DB 인바운드 양방향 규칙 이해 → 요청과 수신 분리 Stateful 보안 그룹 → 응답은 자동 허용

해설

【핵심 용어】 】 ▸ AWS Budgets — 예산 설정 및 알림 기능 ▸ 조직 레벨 관리 — 관리 계정에서 통합 관리 ▸ Cost Explorer — 청구 데이터 조회 및 분석 ▸ 중앙화된 청구 관리 → Organizations 활용 【정답 포인트】 트】 ▸ "중앙화된 솔루션" → 관리 계정 중심 ▸ "월간 보고서" + "임계값 알림" → Budgets + Cost Explorer ▸ Organizations의 관리 계정에서 모든 계정 통합 관리 ▸ 태그별 Budgets 그룹화로 사업부별 세분화 ▸ 가장 비용 효율적 = 중복 설정 없음 【오답 체크】 】 (A) 각 계정별 개별 설정은 운영 복잡도 높음 (C) Billing and Cost Management는 기본 기능만 제공 (D) Lambda 함수 개발 비용 + CUR 설정 복잡도 【시험 포인트】 트】 다중 계정 청구 → 관리 계정 중심 관리 Organizations + Budgets → 중앙화 태그 기반 분석 → 비용 카테고리

해설

【핵심 용어】 】 ▸ DeletionPolicy — CloudFormation 리소스 삭제 정책 ▸ 보존 옵션 — "Retain", "Delete", "Snapshot" ▸ 스택 삭제 시 리소스 보호 메커니즘 【정답 포인트】 트】 ▸ CloudFormation 스택 삭제 → 템플릿의 DeletionPolicy로 제어 ▸ RDS와 EBS에 "Retain" 정책 설정 ▸ 스택 삭제 시에도 리소스 유지 ▸ 템플릿 레벨 설정이 가장 직접적이고 안전 【오답 체크】 】 (B) 스택 정책은 스택 업데이트 시에만 적용, 삭제 시 미적용 (C) CloudFormation 태그 기반 IAM 정책은 과하고 복잡 (D) AWS Config는 사후 규정 준수, 삭제 방지 불가 【시험 포인트】 트】 CloudFormation 스택 삭제 방지 → DeletionPolicy 중요 리소스 보호 → Retain 정책 템플릿 레벨 보안 → 가장 효과적

해설

【핵심 용어】 】 ▸ VPC Flow Logs — CloudWatch Logs에 저장됨 (CloudTrail 아님) ▸ NAT 게이트웨이 인바운드 → 프라이빗 인스턴스로 향하는 트래픽 ▸ 출발지(Source) = 198.51.100.2 (외부 IP) ▸ 목적지(Destination) = 203.0.x.x (내부 VPC IP) 【정답 포인트】 트】 ▸ "VPC Flow Logs" → CloudWatch Logs 조회 ▸ CloudTrail은 API 로깅용이므로 오답 ▸ 인바운드 트래픽 = 외부(198.51.100.2) → 내부(203.0.x.x) ▸ 필터: 소스=198.51.100.2, 목적지=203.0으로 설정 【오답 체크】 】 (A) CloudTrail 사용 - VPC Flow Logs는 CloudWatch Logs 저장 (C) CloudTrail 사용 + 소스/목적지 역순 (D) 소스/목적지 역순 - 외부에서 내부로의 인바운드 올바르게 분석 불가 【시험 포인트】 트】 VPC Flow Logs 위치 → CloudWatch Logs 인바운드 방향 → 소스(외부) → 목적지(내부) NAT 게이트웨이 분석 → 트래픽 흐름 이해

해설

【핵심 용어】 】 ▸ SSE-S3 — AWS 관리형 암호화 키 (비용 없음, 간단함) ▸ SSE-KMS — 고객 관리형 또는 AWS 관리형 KMS 키 ▸ S3 Batch Operations — 대규모 개체 작업 자동화 ▸ "가장 운영 효율적" → 간단하고 저비용 【정답 포인트】 트】 ▸ "SSE-S3 사용" 요구사항 명확 ▸ SSE-S3은 관리형이므로 운영 오버헤드 최소 ▸ S3 Batch Operations로 수백만 개체 효율적 처리 ▸ "동일한 위치에서 복사" = 인프라 비용 최소화 ▸ 기존 개체 암호화: 새로운 암호화 정책 설정 + Batch Operations 【오답 체크】 】 (B) KMS는 관리 복잡도 증가, 비용 추가 (C) AWS CLI로 수백만 개체 처리는 느리고 운영 부담 (D) KMS 사용으로 불필요한 복잡도 【시험 포인트】 트】 대규모 암호화 마이그레이션 → S3 Batch Operations SSE-S3 활성화 → Bucket 정책 설정 기존 개체 암호화 → 복사를 통한 재암호화 운영 효율성 → 관리형 암호화 + 자동화

해설

【핵심 용어】 】 ▸ AWS Glue Data Catalog — 테이블 메타데이터 관리 ▸ Amazon Athena — S3 데이터에 대한 SQL 쿼리 ▸ S3 Glacier Deep Archive — 장기 아카이브 (규정 준수용) ▸ "비정형 데이터" + "쿼리" + "스케일"→ 서버리스 분석 【정답 포인트】 트】 ▸ 비정형 데이터 → Glue Catalog로 메타데이터 추출 ▸ SQL 쿼리 필요 → Athena (비용 효율적) ▸ S3 Select는 단순 쿼리만, Redshift Spectrum은 비쌈 ▸ Glue + Athena = 자동 스케일링, 사용한 만큼만 비용 ▸ 1년 후 Glacier Deep Archive → 규정 준수 저비용 보관 【오답 체크】 】 (A) S3 Select는 복잡한 분석 미지원 (B) Redshift Spectrum은 초기 설정 비용과 운영 오버헤드 (D) Intelligent-Tiering은 정기적 접근 시에만 경제적 【시험 포인트】 트】 대규모 비정형 데이터 분석 → Glue Catalog + Athena 규정 준수 장기 보관 → Glacier Deep Archive 비용 최적화 → Lifecycle + 아카이브 계층 전환

해설

【핵심 용어】 】 ▸ AWS Snowball Edge — 물리적 데이터 전송 어플라이언스 ▸ 600TB + 100Mbps 인터넷 = 약 55,555시간 (불가능) ▸ "3주" + "암호화" + "물리적 디바이스" → Snowball 【정답 포인트】 트】 ▸ 600TB 대규모 데이터 + 3주 제약 → 인터넷 전송 불가능 ▸ 100Mbps로 600TB = 약 5,787시간 필요 ▸ Snowball Edge = 물리적 전송, 암호화 포함 ▸ 일회성 전송 → Snowball 최적 ▸ 보안: Snowball 자체가 암호화된 전송 【오답 체크】 】 (B) Direct Connect는 설정에 시간 + 초기 비용 높음 (C) 100Mbps VPN은 시간 부족 (D) Storage Gateway는 지속적 동기화용, 대규모 초기 전송 미흡 【시험 포인트】 트】 대규모 초기 데이터 마이그레이션 → AWS Snowball 물리적 전송 → 시간 제약 해결 일회성 + 3주 → Snowball이 유일한 선택지

해설

【핵심 용어】 】 ▸ Amazon Textract — OCR 및 문서 추출 관리형 서비스 ▸ Amazon Comprehend — 자연언어 처리 (NLP) ▸ AWS Step Functions + Lambda — 워크플로 자동화 ▸ "정확한 양식 추출" + "시장 출시 시간" → 관리형 AI/ML 【정답 포인트】 트】 ▸ "정확한 형식 추출" → Textract (전문가용 OCR) ▸ "시장 출시 시간 최소화" → 관리형 서비스 (개발 시간 절약) ▸ "장기 운영 오버헤드 최소화" → 서버리스 (Step Functions + Lambda) ▸ Textract + Comprehend = AWS 기본 제공 문서 처리 ▸ S3에 저장 → 감사 추적 및 규정 준수 【오답 체크】 】 (A) 사용자 정의 라이브러리 = 개발 시간 + 운영 부담 (B) EC2 호스팅 ML 모델 = 운영 오버헤드 높음, Textract만큼 정확하지 않음 (C) SageMaker는 수동 모델 구축 필요, ElastiCache는 출력 저장소 부적합 【시험 포인트】 트】 문서 처리 자동화 → Amazon Textract 자동 워크플로 → Step Functions + Lambda 관리형 AI → 빠른 출시 + 낮은 운영비 NLP 분석 → Amazon Comprehend 추가 가능

해설

【핵심 용어】 】 ▸ "주요 변경 없음" → 기존 아키텍처 유지 ▸ AMI = VM 호스트 그대로 마이그레이션 ▸ Amazon MQ = RabbitMQ 호환성 높음 ▸ Amazon EKS = Kubernetes 클러스터 관리형 서비스 ▸ "가장 적은 운영 오버헤드" → 관리형 서비스 【정답 포인트】 트】 ▸ (A) 웹 프런트: AMI + Auto Scaling (VMs 그대로) ▸ (A) 메시징: Amazon MQ (RabbitMQ 호환) ▸ (A) 백엔드: Amazon EKS (Kubernetes 관리형) ▸ 최소 변경으로 클라우드 전환 ▸ 모든 계층을 관리형 서비스로 최적화 【오답 체크】 】 (B) Lambda 사용자 정의 런타임은 복잡하고 웹 서버 호환성 미흡 (C) 자체 Kubernetes = 관리 부담 증가, EKS의 이점 상실 (D) SQS는 RabbitMQ와 호환성 낮음, 큐 구조 변경 필요 【시험 포인트】 트】 최소 코드 변경 → 기존 아키텍처 보존 Lift and Shift → AMI 기반 마이그레이션 메시징 호환성 → Amazon MQ (RabbitMQ API) Kubernetes 관리 → Amazon EKS

해설

【핵심 용어】 】 ▸ kms:GenerateDataKey — 클라이언트 측 암호화 시 데이터 암호화 키 생성 ▸ CMK — Customer Master Key로 KMS의 기본 암호화 키 ▸ S3 클라이언트 측 암호화 — 클라이언트가 S3 업로드 전 데이터 암호화 【정답 포인트】 트】 ▸ "새 객체 업로드 실패" + "기존 객체 조회 성공" → 읽기(복호화)는 되지만 쓰기(암호화)가 안 됨 ▸ 클라이언트 측 암호화는 GenerateDataKey로 데이터 암호화 키를 생성해야 함 ▸ 업로드 시에만 실패 → 암호화 작업(GenerateDataKey) 권한 부재 【오답 체크】 】 (B) GetKeyPolicy — 키 정책 조회용, 암호화 작업과 무관 (C) GetPublicKey — 비대칭 암호화, 클라이언트 측 S3 암호화 불필요 (D) Sign — 서명 생성용, S3 객체 암호화와 무관 【시험 포인트】 트】 암호화 실패 ← 권한 부족 인식 → "업로드 시 암호화 필요" → GenerateDataKey S3 클라이언트 측 암호화의 핵심 KMS 권한은 GenerateDataKey

해설

【핵심 용어】 】 ▸ Count 모드 — 요청을 차단하지 않고 매칭 여부만 로깅 ▸ 거짓 양성 — 정상 요청이 악의적으로 잘못 분류되는 경우 ▸ 점진적 마이그레이션 — Count → Block으로 단계적 전환 【정답 포인트】 트】 ▸ "정상 트래픽에 부정적 영향 X" → 초기에 Block하면 안 됨 ▸ "점진적 배포" 원칙 → Count로 시작해 분석 후 Block 전환 ▸ AWS WAF 베스트 프랙티스 — 로깅 활성화 후 거짓 양성 검증 【오답 체크】 】 (B) 비율 기반 규칙만 사용 — 웹 공격 방어는 광범위 규칙 필요 (C) 즉시 Block + 관리형 규칙 — 거짓 양성 검증 없이 정상 요청 차단 위험 (D) 사용자 정의 규칙만 → AWS 관리형 규칙 활용 불가, 유지보수 부담 【시험 포인트】 트】 WAF 배포 패턴: 계획 → Count로 측정 → 규칙 검증 → Block 전환 거짓 양성 최소화가 핵심 고려 사항

해설

【핵심 용어】 】 ▸ Prefix List — 보안 그룹에서 CIDR 범위를 관리하는 중앙 집중식 메커니즘 ▸ Customer-managed Prefix List — 사용자가 생성하고 관리 ▸ Resource Access Manager(RAM) — AWS Organizations 계정 간 리소스 공유 【정답 포인트】 트】 ▸ "모든 계정에 배포" + "운영 오버헤드 최소" → 중앙에서 관리 ▸ Prefix List 공유 시 일반적인 변경으로 모든 계정에 자동 반영 ▸ RAM으로 공유하면 수동 동기화 불필요 ▸ "보안 팀 중앙 관리" → 단일 소스 데이터 (Single Source of Truth) 【오답 체크】 】 (A) SNS + Lambda — 각 계정 Lambda 유지보수 필요, 확장성 낮음 (B) 각 계정별 Prefix List — 수동 동기화 필요, 불일치 위험 (D) Lambda Cross-Account — 복잡한 권한 관리, 높은 운영 부담 【시험 포인트】 트】 다중 계정 공유: RAM을 통한 Prefix List 공유 = 중앙 관리 + 자동 배포 AWS Organizations + RAM 조합은 최소 오버헤드 솔루션

해설

【핵심 용어】 】 ▸ Client VPN — 개인 사용자의 원격 VPN 연결 서비스 ▸ VPC Peering — 두 VPC 간 직접 연결 ▸ Transit Gateway — 중앙 허브로 다중 VPC/네트워크 연결 【정답 포인트】 트】 ▸ "이미 VPC 피어링 설정됨" → 주 계정의 VPC로 트래픽 흐름 가능 ▸ Client VPN은 하나의 엔드포인트로 충분 (라우팅으로 타 계정 접근) ▸ "가장 비용 효율적" → Transit Gateway 불필요 (피어링으로 이미 연결됨) ▸ 주 계정 중앙 집중식 관리 → 단순한 구조 【오답 체크】 】 (A) 각 계정 엔드포인트 — VPN 비용 N배 증가, 복잡성 증가 (C) Transit Gateway 추가 — 불필요한 비용 (피어링으로 충분) (D) Site-to-Site VPN 연결 — 아키텍처 오류, Client VPN용이 아님 【시험 포인트】 트】 기존 피어링 활용 → 중앙 엔드포인트 + 라우팅 = 최적 비용 Client VPN은 단순성과 비용 효율성 강조

해설

【핵심 용어】 】 ▸ 분리(Decoupling) — 직접 동기 호출 제거, 중간 큐 도입 ▸ SQS — 메시지 대기열, 신뢰성 있는 전달 보장 ▸ 재시도 메커니즘 — SQS의 visibility timeout으로 자동 재시도 【정답 포인트】 트】 ▸ "응답 시간 불일치" + "오류율 증가" → 동기식 문제 ▸ "모든 호출 최종 완료" → 신뢰성 높은 대기열 필요 ▸ SQS의 메시지 영속성 + 재시도 → "eventually completed" 보장 ▸ 큐를 통한 버퍼링 → 트래픽 스파이크 대응 【오답 체크】 】 (B) Step Functions — 상태 머신용, SQS보다 복잡하고 비용 높음 (C) EventBridge — 실시간 이벤트 라우팅, 신뢰성 재시도 약함 (D) SNS — pub/sub 모델, 메시지 저장소 없음, 손실 위험 【시험 포인트】 트】 분리 + 신뢰성 재시도 = SQS 선택 기준 제3자 서비스의 지연 → 큐 버퍼링으로 해결