정답 · 해설

해설

【핵심 용어】 ▸ Gateway Load Balancer — Layer 4 트래픽을 가상 어플라이언스(보안 도구)로 라우팅 ▸ 실시간 패킷 검사 — 모든 인/아웃바운드 트래픽이 보안 도구를 통과해야 함 ▸ 고가용성 — AZ마다 GWLB 배포 【정답 포인트】 ▸ 보안 도구를 Auto Scaling 그룹에 배포 (A) → 자동 확장, 고가용성 ▸ Gateway Load Balancer (D) → 각 AZ에서 트래픽 가로채기 (GLBP 표준 구조) ▸ VPC Flow → GLBP가 ENI 트래픽을 가상 어플라이언스로 전달 【오답 체크】 (B) Network Load Balancer는 웹 app용 - 보안 도구 검사 구조 아님 (C) ALB는 Layer 7 - 패킷 레벨 검사에 부적합 (E) 단일 VPC이므로 transit gateway 불필요 【시험 포인트】 Gateway Load Balancer + 보안 어플라이언스 조합은 SAP-C02의 고급 네트워킹. 모든 인/아웃 트래픽 검사 → GLBP 사용, ALB/NLB 아님을 명확히.

해설

【핵심 용어】 ▸ AWS IoT Core — IoT 기기/센서의 중앙 허브 (MQTT/HTTP 프로토콜) ▸ AWS Glue — 비정형 데이터의 메타데이터 카탈로그화 ▸ Amazon Athena — S3의 데이터에 대한 SQL 쿼리 (서버리스) ▸ QuickSight — 시각화 및 BI 【정답 포인트】 ▸ 실시간 데이터 수집 → IoT Core (하루 1회가 아님) ▸ 파싱 자동화 → Lambda 함수 (벤더별 형식 지원) ▸ 비용 최적화 → S3 + Athena (관리 오버헤드 최소, 스캔 기반 비용) ▸ 빠른 분석 → 온디맨드 SQL 쿼리 【오답 체크】 (B) Fargate는 지속적 실행 - 24h 비용, 하루 1회 배치 처리에 과도 (C) SFTP는 레거시 - 실시간 센서 데이터 수집 구조 아님 (D) Snowball Edge는 물리적 - IoT 센서 직접 연결 불가능 【시험 포인트】 IoT Core + Lambda + S3 + Athena는 '저비용 실시간 데이터 파이프라인'의 표준 패턴. 관계형 DB 언급은 함정 - 서버리스 분석이 더 비용 효율적임을 인지할 것.

해설

【핵심 용어】 ▸ Transit Gateway — 중앙 허브로 모든 VPC 및 온프레미스 연결 (수백 개 계정 확장 가능) ▸ Direct Connect Gateway — DX와 Transit Gateway/VGW 간 연결 ▸ Transit VIF — DXG와 TGW를 연결하는 가상 인터페이스 ▸ Transit Gateway Sharing — RAM 사용하여 다른 계정과 공유 【정답 포인트】 ▸ DXG + TGW (B) → 온프레미스와 모든 VPC 연결의 중앙화 ▸ 다른 계정과 공유 (D) → RAM 통해 TGW 공유, 각 계정이 VPC 연결 ▸ 인터넷 라우팅 (F) → 프라이빗 서브넷 + NAT 서비스 통한 아웃바운드 【오답 체크】 (A) 각 계정별 VGW 생성 → VPC 수백 개에 부적합, TGW보다 관리 복잡 (C) IGW 사용 → 인터넷 직접 노출, 온프레미스 경로 지정 요구사항 위반 (E) VPC 피어링 → 메시 구조, 수백 개 VPC 관리 불가능 【시험 포인트】 대규모 다중 계정 아키텍처: DXG + TGW + RAM 공유 + 프라이빗 서브넷 + NAT는 SAP-C02의 최신 권장 구조. VGW 및 VPC 피어링은 과거 패턴임을 인식할 것.

해설

【핵심 용어】 ▸ Service Control Policy (SCP) — Organizations 수준에서 모든 계정의 권한을 중앙에서 제한 ▸ AWS Organizations (All Features) — SCP 및 consolidation billing 지원 ▸ IAM Policy — 단일 계정 수준의 권한 제어 (중앙 집중화 불가) 【정답 포인트】 ▸ 수백 개 계정 → 중앙 집중식 통제 필요 → SCP (D) 사용 ▸ All Features Organization (A) → SCP 활성화 필수 전제 조건 ▸ SCP를 각 OU에 연결 (D) → 모든 비즈니스 단위에 정책 적용 ▸ 개별 IAM 정책 → 각 계정마다 관리 필요, 중앙화 불가능 【오답 체크】 (B) AWS Config는 감시만 하고 강제 불가 - 컴플라이언스 점검용 (C) 각 계정 IAM 정책 → 수백 계정 관리 복잡, 누락 위험 (E) Consolidated Billing은 비용 관리용 - 권한 제어 기능 없음 【시험 포인트】 Organizations + SCP는 SAP-C02의 '대규모 권한 강제' 표준 패턴. 개별 IAM 정책은 확장성 없고, SCP는 계정 간 검증 불가능한 정책 편차를 원천 차단.

해설

【핵심 용어】 ▸ RDS Proxy — DB 연결 풀링, 페일오버 시 기존 연결 유지 (투명한 재라우팅) ▸ Aurora MySQL — 빠른 페일오버 (1-2초), 자동 스토리지 확장 ▸ Aurora Replica — 동기식 스탠바이 (즉시 승격) 【정답 포인트】 ▸ RDS Proxy (C) → 기존 클라이언트 연결 유지, 페일오버 재연결 시간 제거 ▸ Aurora MySQL (D) → Multi-AZ보다 빠른 페일오버 (1-2초 vs 40초) ▸ Aurora Replica (E) → 동기식 복제, 즉시 읽기 전용 이용 가능 ▸ 조합 효과: Aurora (빠른 페일오버) + RDS Proxy (연결 투명화) + Replica (높은 가용성) 【오답 체크】 (A) (B) 캐시는 페일오버 시간 단축 불가 - 데이터 일관성 문제만 추가 (F) MySQL 읽기 복제본 → 비동기식, 페일오버 자동화 안됨 【시험 포인트】 RDS Multi-AZ 페일오버 개선 → Aurora + RDS Proxy + Replica의 조합이 표준. Multi-AZ에서 Aurora로의 마이그레이션이 근본 해결, Proxy가 연결 투명화의 핵심.

해설

【핵심 용어】 ▸ Cross-Account Role Assumption — 다른 조직/계정의 리소스 접근 ▸ External ID — 역할 신뢰 정책의 추가 검증 요소 (혼동 권한 공격 방지) ▸ AssumeRole — STS API로 역할 임시 자격증명 획득 【정답 포인트】 ▸ ARN만 사용 (C) → External ID 없음 → 혼동 권한 공격(confused deputy) 가능 ▸ External ID 포함 (D) → 파트너 회사만 해당 ID를 알고 있음 → 보안 강화 ▸ 신뢰 정책: Principal(org1), Action(sts:AssumeRole), Condition(aws:ExternalId) 【오답 체크】 (A) (B) 액세스 키/IAM 사용자 자격증명 공유 → 최소 권한 원칙 위반, 순환 사용 불가 (C) External ID 없음 → 보안 취약점 【시험 포인트】 교차 조직 액세스 → External ID 필수. AWS 권장 구조: AssumeRole + External ID는 '임시 자격증명 + 추가 검증'의 최소 권한 패턴.

해설

【핵심 용어】 ▸ ECS on Fargate — 서버리스 컨테이너 (인스턴스 관리 불필요) ▸ Cost-Effective Resource Allocation — 컨테이너 수에 따라 자동 스케일링 ▸ enableECSManagedTags — ECS가 태그 기반 비용 추적 자동화 【정답 포인트】 ▸ 최소 운영 오버헤드 → Fargate (EC2 관리 없음) ▸ ECS vs EKS → ECS가 더 간단 (Kubernetes 오버헤드 없음) ▸ enableECSManagedTags → 태그별 비용 분석 자동화 ▸ run-task → 일회성 작업에 적합 【오답 체크】 (A) (C) EC2 기반 → 인스턴스 관리 필요, 운영 오버헤드 증가 (B) EKS → Kubernetes 복잡도, ECS보다 관리 부담 큼 【시험 포인트】 "최소 운영 오버헤드" + "비용 추적" → ECS on Fargate + enableECSManagedTags 조합이 표준. EKS는 복잡한 오케스트레이션 필요할 때만 선택.

해설

【핵심 용어】 ▸ VPC Peering CIDR Overlap — 피어링되는 두 VPC의 CIDR 범위가 겹칠 수 없음 ▸ Cross-Account Peering — IAM 권한 필요 (피어 수락자 계정) ▸ Cross-Region Peering — 지원 가능 (리전 제한 없음) 【정답 포인트】 ▸ CIDR 겹침 (A) → 10.10.0.0/16과 10.10.10.0/24 겹침 → 피어링 실패 ▸ IAM 권한 (E) → 피어 수락자(공유 서비스 VPC 계정)가 승인/수락 권한 필요 ▸ 라우팅 테이블 수락 → CloudFormation에서 AcceptVpcPeeringConnection 리소스 필요 【오답 체크】 (B) 교차 리전 피어링 → 완전히 지원됨 (us-east-1 ↔ us-east-2 가능) (C) IGW → VPC 피어링에 필수 아님 (프라이빗 통신 가능) (D) Resource Access Manager → VPC 피어링에 필요 없음 (피어링은 계정 간 합의만) 【시험 포인트】 VPC Peering 실패 원인: CIDR 겹침은 기술적 제약, IAM 권한은 정책 제약. 교차 리전은 문제 없고, IGW 필요 없음을 명확히할 것.

해설

【핵심 용어】 ▸ IAM Access Analyzer — CloudTrail 로그에서 실제 API 사용 패턴 분석 → 정책 생성 자동화 ▸ Policy Generation — 실제 활동만 기반으로 최소 권한 정책 생성 ▸ CloudTrail — 모든 API 호출의 감시 로그 【정답 포인트】 ▸ CloudTrail 로깅 필요 → 실제 API 호출 기록 ▸ Access Analyzer (B) → 자동 정책 생성, 최소 노력 ▸ 생성된 정책 검토 → 비즈니스 요구사항 확인 ▸ 자동화 + 검증 조합 → 정확성과 효율성 【오답 체크】 (A) CodeGuru → 성능 프로파일링용, 권한 분석 아님 (C) 수동 스크립트 → 많은 개발 노력 필요 (수백 함수) (D) EMR 사용 → 과도한 인프라, 간단한 분석에 불필요 【시험 포인트】 IAM 권한 최소화 → CloudTrail + Access Analyzer 자동 정책 생성은 SAP-C02의 권장 패턴. 수동 분석은 지양, 자동화 도구 활용을 우선시할 것.

해설

【핵심 용어】 ▸ AWS Compute Optimizer — 머신 러닝 기반 EC2/EBS 사이징 권장사항 ▸ CloudWatch Agent — OS 레벨 메트릭(메모리, CPU, 디스크) 수집 ▸ 활용률 분석 → 12시간 데이터로 충분 (패턴 파악) 【정답 포인트】 ▸ CloudWatch Agent (C) → OS 레벨 메트릭 (CPU, 메모리 활용률) 수집 ▸ Compute Optimizer → 자동 ML 분석, 정확한 권장사항 ▸ 12시간 데이터 충분 → 빠른 의사결정 ▸ 비용 최적화 + 최소 운영 노력 → 자동화 도구 선택 【오답 체크】 (A) OpsCenter → 관찰 중심, 분석/권장사항 아님 (B) 상세 모니터링만 → 수동 분석 필요, 권장사항 없음 (D) Trusted Advisor → 구성 권장사항만 제공, EC2 사이징 권장 아님 【시험 포인트】 EC2 사이징 최적화 → Compute Optimizer가 표준. CloudWatch Agent로 실제 OS 메트릭 수집이 핵심, 자동 ML 분석으로 최소 노력 원칙 충족.

해설

【핵심 용어】 ▸ Cross-Account Role Assumption — DBA 계정 역할이 애플리케이션 계정 역할 가정 ▸ Secrets Manager 교차 계정 액세스 → AssumeRole + KMS 권한 조합 ▸ Trust Policy — DBA-Admin → DBA-Secret 【정답 포인트】 ▸ 애플리케이션 계정: DBA-Secret 역할 (Secrets 읽기 권한) ▸ DBA 계정: DBA-Admin 역할 (AssumeRole 권한) ▸ 신뢰 정책: DBA-Secret이 DBA-Admin의 AssumeRole을 허용 ▸ 결과: EC2(DBA-Admin) → AssumeRole → DBA-Secret → Secrets 접근 【오답 체크】 (A) RAM 공유 → Secrets 리소스 공유 미지원 (C) KMS 키 권한 + 리소스 기반 정책 → 복잡도 높음, AssumeRole이 표준 (D) SCP → 권한 거부만 가능, 허용 설정 불가 【시험 포인트】 교차 계정 Secrets 접근 → AssumeRole 체인 패턴이 표준. RAM은 Secrets 공유 불가, KMS 정책은 추가 복잡도, SCP는 정책 도구 아님을 명확히.

해설

【핵심 용어】 ▸ SCP (Service Control Policy) — Organizations 레벨 권한 제어 ▸ aws:RequestedRegion — 모든 AWS 서비스에 적용되는 조건 ▸ ec2:InstanceType — EC2 특화 조건 【정답 포인트】 ▸ 리전 제한 (모든 리소스) → aws:RequestedRegion SCP (C) ▸ 루트 OU에 적용 → Research, DataOps 모두 포함 ▸ EC2 인스턴스 유형 제한 (DataOps만) → ec2:InstanceType SCP (E) ▸ DataOps OU에만 적용 → Research에는 미적용 【오답 체크】 (A) IAM 역할 (1계정) → 조직 전체 관리 불가, 확장성 없음 (B) IAM 사용자 → 개별 관리, SCP보다 복잡 (D) ec2:Region 조건 → EC2 전용, 다른 서비스(S3, RDS 등) 미적용 【시험 포인트】 조직 전체 규제: aws:RequestedRegion + 루트 OU (모든 계정). 특정 OU 규제: 특화 조건 + 해당 OU. SCP 기본 구조 이해가 핵심.

해설

【핵심 용어】 ▸ SNS-SQS Fan-Out — SNS 주제가 여러 SQS 큐에 메시지 전달 ▸ Cross-Region SNS Subscription — SQS가 여러 리전의 SNS 구독 ▸ Lambda 멀티 리전 처리 → 각 리전에서 독립 실행 【정답 포인트】 ▸ URL 발행 → 기존 리전의 SNS (변경 없음) ▸ SQS + Lambda → 각 리전에 배포 (A) ▸ SNS → 각 리전의 SQS 구독 (C) ▸ 각 리전의 Lambda는 로컬 S3에 결과 저장 ▸ 구조: SNS (기존) → 각 리전 SQS → 각 리전 Lambda → 로컬 S3 【오답 체크】 (B) SNS 구독 역방향 (SNS가 SQS 구독) → SNS → SQS 흐름 지원 안함 (D) SQS가 주제에 게시 → 역할 전환 불가 (E) SNS를 다른 리전에 배포 → "URL은 기존 리전에서 발행"정책 위반 【시험 포인트】 멀티 리전 SNS-SQS 팬아웃: 중앙 SNS → 각 리전 SQS 구독 → 각 리전 Lambda가 로컬 처리. 구독 방향(SNS →SQS)과 배포 대상(SQS+Lambda만)을 명확히.

해설

【핵심 용어】 ▸ AWS Fargate — 컨테이너 오케스트레이션 서비스로 서버 관리 불필요 ▸ EventBridge — 예약된 규칙으로 반복 작업 트리거 ▸ 상태유지 안 함(Stateless) — 외부 의존성 없이 독립적 실행 가능 【정답 포인트】 ▸ Linux 바이너리 + 수정 불가 → 컨테이너화 필요(Lambda 불가) ▸ 4시간 주기 + 20분 실행 → EventBridge 일정 트리거 이상적 ▸ 2GB RAM + CPU 집약적 → Fargate의 확장성과 비용 효율성 제공 ▸ Stateless → 기존 인프라(EC2) 필요 없음, 관리 오버헤드 최소화 【오답 체크】 (A) Lambda는 바이너리 실행 불가, 15분 실행 시간 제한 초과 불가능 (B) Step Functions는 트리거 메커니즘이 아니며 Batch도 과도한 오버헤드 (D) Spot Instances는 비용 절감 효과 있으나 관리 복잡도 높음, CodeDeploy는 부적절 【시험 포인트】 Linux 바이너리 실행 + 정기적 일정 트리거 패턴 → Fargate + EventBridge 조합이 최적 솔루션

해설

【핵심 용어】 ▸ S3 교차 리전 복제(CRR) — 여러 리전 간 자동 복제 ▸ DynamoDB 글로벌 테이블 — 다중 리전 읽기/쓰기 가능 ▸ CloudFront 오리진 장애 조치 — 다중 오리진으로 자동 페일오버 【정답 포인트】 ▸ 교차 리전 배포 + 지연 시간 최소화 → 다중 리전 자산 필수 ▸ CloudFront 오리진 장애 조치 → 복수 오리진(다중 리전 S3) ▸ 글로벌 테이블 + DynamoDB Streams → 양방향 복제, 일관성 보장 ▸ CRR 구성 → 자동 복제, 구현 최소 노력 【오답 체크】 (A) 교차 리전 복제는 맞으나 오리진 장애 조치 없이 단순 구성(효율성 저하) (B) 동일 리전 복제는 역효과, DMS는 실시간성 약함 (D) 동일 리전 복제는 다중 리전 목표와 모순, 지연 시간 개선 불가능 【시험 포인트】 다중 리전 고속 응답 + 글로벌 테이블 패턴 → CRR + CloudFront 장애 조치 + 글로벌 테이블 조합

해설

【핵심 용어】 ▸ Amazon DocumentDB — MongoDB 호환 관리형 데이터베이스 ▸ MongoDB 호환성 — 애플리케이션 코드 변경 최소화 ▸ 다중 가용 영역 — 고가용성 아키텍처 【정답 포인트】 ▸ MongoDB 사용 중 → DocumentDB 호환성으로 코드 변경 없음 ▸ 애플리케이션 수정 불가 → 기존 구조와 호환 필요 ▸ 고가용성 → 다중 AZ 배포 필수 ▸ 적절한 크기 인스턴스 → 온디맨드보다 비용 효율적이고 예측 가능 【오답 체크】 (A) Aurora는 MySQL/PostgreSQL이므로 MongoDB 호환성 없음, 마이그레이션 작업 필요 (B) 단일 AZ는 고가용성 요구사항 위반 (D) 온디맨드 용량 모드는 프로비저닝 비용이 높고 비용 최적화 안 됨 【시험 포인트】 NoSQL → 관리형 호환 서비스 패턴: DocumentDB는 MongoDB 호환성으로 마이그레이션 최소화

해설

【핵심 용어】 ▸ 교차 계정 액세스 — 신뢰 관계와 권한 이중 검증 ▸ S3 버킷 정책 — 버킷 수준 액세스 제어 ▸ KMS 키 정책 — 암호화 키 사용 권한 관리 【정답 포인트】 ▸ (A) 버킷 정책 — 전략 계정(principal)에 읽기 권한 명시 필수 ▸ (C) KMS 키 정책 — 역할이 암호화된 객체 복호화 권한 필요 ▸ (F) 역할 권한 — S3 읽기 + KMS 복호화(최소 권한 원칙) ▸ 세 가지 모두 필수 — 단계적 검증 구조 【오답 체크】 (B) 전체 권한(full permissions)은 최소 권한 원칙 위반 (D) 익명 사용자는 보안 위험, 인증 필요 (E) 읽기만 필요하므로 암호화 권한은 불필요 【시험 포인트】 교차 계정 + 암호화 객체 액세스 패턴 → 버킷 정책 + KMS 정책 + 역할 권한 3단 구성

해설

【핵심 용어】 ▸ AWS DataSync — 온프레미스에서 AWS로 대규모 데이터 고속 전송 ▸ AWS Batch — 장시간 컴퓨팅 작업 처리 ▸ Amazon ECR — Docker 컨테이너 이미지 저장소 ▸ Step Functions — 워크플로우 오케스트레이션 【정답 포인트】 ▸ Direct Connect + 대규모 데이터 → DataSync 최적(고속, 안정적) ▸ 장시간 작업(몇 시간) → Lambda 불가(15분 제한), Batch 필수 ▸ Docker 컨테이너 기존 사용 → ECR + Batch로 현 구조 유지 ▸ 이벤트 기반 트리거 → S3 이벤트 + Step Functions 조합 【오답 체크】 (A) Snowball은 배치 처리, 정기적 전송에 비효율적, Lambda는 처리 시간 초과 (B) Data Pipeline은 지원 중단, EC2 Auto Scaling은 관리 오버헤드 높음 (D) Storage Gateway는 실시간이 아니며 Batch 연결 구조 부정확 【시험 포인트】 온프레미스 + 대용량 데이터 + 장시간 처리 패턴 → DataSync + Batch + ECR 조합

해설

【핵심 용어】 ▸ FSx for Windows File Server — Windows ACL 지원 관리형 파일 시스템 ▸ 원활한 도메인 조인(Seamless domain join) — AD 통합 ▸ 컨텐츠 일관성 — 모든 인스턴스 간 동기화 【정답 포인트】 ▸ Windows ACL 요구 → EFS는 POSIX 권한만 지원, FSx Windows 필수 ▸ AD 도메인 조인 필수 → FSx for Windows는 내장 AD 통합 ▸ 다중 AZ 고가용성 → FSx 자동 다중 AZ 지원 ▸ 콘텐츠 동기화 → FSx 공유 스토리지로 모든 인스턴스가 동일 파일 접근 【오답 체크】 (A) EFS는 Windows ACL 미지원(POSIX 권한만), Linux/NFS 전용 (B) FSx Lustre는 HPC용, Windows ACL 미지원, AD 통합 없음 (D) EFS는 Windows ACL 미지원, 원활한 도메인 조인 불가 【시험 포인트】 Windows + AD + ACL + 고가용성 패턴 → FSx for Windows File Server 필수

해설

【핵심 용어】 ▸ Amazon SES — 관리형 이메일 전송 서비스 ▸ SendTemplatedEmail API — 내장 템플릿 기능 ▸ 서버리스 구조 — 운영 오버헤드 최소화 【정답 포인트】 ▸ 최소 운영 오버헤드 → SES(관리형) vs EC2 SMTP(관리 필요) ▸ SES 내장 템플릿 → 별도 S3 검색/병합 불필요(D가 가장 간단) ▸ SendTemplatedEmail API → 단일 호출로 템플릿+데이터 처리 ▸ 비용 효율성 → EC2 인스턴스 운영 비용 제거 【오답 체크】 (A) EC2 SMTP 서버는 관리 오버헤드 높음, S3에서 매번 검색/병합 필수 (B) SES 사용하나 S3 템플릿은 비효율적, B보다 D가 SES 기능 활용 (C) EC2 SMTP는 여전히 관리 필요, SendTemplatedEmail 미사용 【시험 포인트】 이메일 전송 + 템플릿 + 최소 오버헤드 패턴 → SES + SendTemplatedEmail API