정답 · 해설

해설

【핵심 용어】 ▸ SCP (Service Control Policy) — 조직 수준의 권한 제한 ▸ IAM Permission Boundary — IAM 사용자/역할의 최대 권한 한계 ▸ aws:SourceAccount — S3 정책 조건(SourceAccount는 S3 버킷 정책과 무관) 【정답 포인트】 ▸ 다중 계정 환경에서 S3 액세스 차단은 일반적으로 두 가지 원인: 1) SCP가 리소스 접근 차단 2) IAM Permission Boundary가 권한 제한 ▸ 문제를 진단하려면 두 가지 모두 확인해야 합니다. ▸ 변경 사항을 CodeCommit → CloudFormation으로 관리(IaC 원칙 준수) 【오답 체크】 (A) Block Public Access 해제는 보안 위험이고, aws:SourceAccount는 S3 버킷 정책과 무관합니다. (B) Config 기록기로 되돌리는 것은 복잡하고, SCP 확인이 빠졌습니다. (C) SCP로 IAM 수정 중단은 문제 해결과 무관하고, aws:SourceAccount 추가는 효과가 없습니다. (D) SCP + Permission Boundary 확인 + CloudFormation 배포 = 완전한 진단 및 수정 【시험 포인트】 다중 계정 S3 액세스 → SCP 확인 → Permission Boundary 확인 → IaC 배포

해설

【핵심 용어】 ▸ CodeArtifact Domain — 리포지토리 컨테이너 및 액세스 제어 경계 ▸ Upstream Repository — 패키지 의존성 해결 체인 ▸ Resource-based Policy — 리포지토리별 세밀한 액세스 제어 【정답 포인트】 (B) 공유 서비스 계정에 중앙 도메인 생성 → 조직 수준 권한 관리 간소화 (C) 각 애플리케이션 팀 계정에 자체 리포지토리 → 팀별 독립적 패키지 관리 (D) 공유 서비스의 리포지토리를 업스트림으로 설정 → 팀이 공유 패키지에 자동 액세스 이 조합으로: - 팀별 독립성 보장 (C) - 공유 패키지 중앙화(B, D) - 최소 권한 정책 관리(Upstream으로 의존성 해결) - 리소스 정책 추가 불필요 【오답 체크】 (A) 각 계정에 도메인을 만들면 조직 수준 권한 관리가 복잡해집니다. (E) 팀별 리소스 정책은 관리 오버헤드를 증가시킵니다. (F) Upstream은 D에서만 설정하면 충분하고, F는 추가 복잡도입니다. 【시험 포인트】 다중 계정 CodeArtifact → 중앙 도메인 + 팀 리포지토리 + Upstream → 최소 오버헤드

해설

【핵심 용어】 ▸ AppSpec.yml files section — 소스 경로 및 대상 경로(destination) 매핑 ▸ Multiple Destinations — 단일 파일이 여러 위치로 배포 가능 【정답 포인트】 ▸ appspec.yml의 files 섹션에서 동일한 소스 파일이 여러 destination으로 매핑될 수 있습니다. ▸ config.txt 파일은 두 개의 서로 다른 destination으로 배포됩니다: 1) /usr/local/src/config.txt 2) /var/www/html/config/config.txt ▸ 각 destination 항목이 독립적으로 처리됩니다. 【오답 체크】 (A) 첫 번째 destination만 선택 (틀림) (C) 두 번째 destination만 선택 (틀림) (D) 경로 변환 오류 (web 폴더는 존재하지 않음) 【시험 포인트】 CodeDeploy appspec.yml → 다중 destination 매핑 → 단일 파일 다중 배포

해설

【핵심 용어】 ▸ archived — 패키지 버전을 아카이브 상태로 변경 (다운로드 차단, 메타데이터 유지) ▸ Origin Control — 패키지 게시 및 업스트림 소스 제어 ▸ Direct Publishing — 리포지토리에 직접 패키지 게시 【정답 포인트】 (C) archived 상태: - 취약한 버전을 다운로드할 수 없음 - 버전 기록은 유지됨 (감사 목적) - 기존 다운로드된 패키지는 영향 없음 (D) Origin Control 설정: - Direct Publishing 활성화 → 보안 팀이 패치 버전 직접 게시 가능 - Upstream Operations 차단 → 공개 리포지토리의 취약 버전 자동 동기화 방지 【오답 체크】 (A) unlisted — 검색 결과에서만 숨겨지고, 직접 요청하면 다운로드 가능 (불충분) (B) deleted — 버전 기록이 제거되어 감사 추적 손실 (E) Direct Publishing 차단은 보안 팀의 패치 버전 게시를 방지합니다. 【시험 포인트】 취약 패키지 차단 → archived 상태 + Origin Control (Direct 활성화/Upstream 차단)

해설

【핵심 용어】 ▸ AWS Step Functions — 상태 머신 기반 워크플로우 오케스트레이션 ▸ Task Retry Logic — 개별 작업 재시도 (상태 추적) ▸ Decoupled Processing — 각 단계 독립 실행 【정답 포인트】 ▸ Step Functions는 워크플로우 상태를 자동 추적합니다. ▸ 각 단계(Task)는 독립적으로 재시도 가능합니다. ▸ 실패한 단계에서 재개 가능 (처음부터 재처리 불필요) ▸ Lambda 함수로 각 5분 이내 단계 구현 ▸ 내장된 재시도, 오류 처리, 모니터링 【오답 체크】 (A) S3 + SNS + EC2: 수동으로 상태 추적을 구현해야 하고, 실패 시 처음부터 재처리할 가능성이 높습니다. (B) Fargate 자체 호출: 컨테이너 자체 상태 관리 복잡하고, 재시도 로직을 수동 구현해야 합니다. (C) Kinesis + Lambda: 단계 간 순차성 보장 어려우며, 상태 추적을 별도로 구현해야 합니다. 【시험 포인트】 다단계 순차 작업 → Step Functions 상태 머신 → 개별 단계 재시도 → 최소 운영 오버헤드

해설

【핵심 용어】 ▸ FSx for NetApp ONTAP — Windows(SMB) + Linux(NFS) 동시 지원 ▸ SnapMirror — NetApp 네이티브 동기식 복제 ▸ Pilot Light DR — 최소 리소스 DR 환경 【정답 포인트】 ▸ FSx for NetApp ONTAP은 SMB(Windows) 및 NFS(Linux)를 동시에 지원합니다. ▸ SnapMirror는 블록 레벨 동기식 복제로 실시간 복제를 제공합니다. ▸ 자동화를 통한 EC2 인스턴스 구성과 완벽히 호환됩니다. ▸ Pilot Light 환경에서 빠른 페일오버 가능 (스토리지 이미 복제됨) 【오답 체크】 (A) S3는 객체 스토리지이고, SMB/NFS 프로토콜을 지원하지 않습니다. (B) EBS 스냅샷은 서버 독립적이지만, SMB/NFS 공유 스토리지 역할을 하지 못합니다. (C) Volume Gateway는 블록 스토리지로 SMB/NFS 동시 지원 불가능합니다. 【시험 포인트】 Windows + Linux 공유 스토리지 → FSx for NetApp ONTAP → SnapMirror DR 복제

해설

【핵심 용어】 ▸ Warm Pool — 미리 준비된 인스턴스로 scale-out 레이턴시 단축 ▸ Spot Instances — 비용 효율적이지만 중단 가능 ▸ Target Tracking — 메트릭 기반 자동 확장 【정답 포인트】 B: 중요 데이터는 reliability가 필수이므로 On-Demand + warm pool로 빠른 확장성 보장. E: 비중요 데이터는 메모리 메트릭 기반 자동 확장으로 별도 관리. 두 개의 target group으로 트래픽 분리 【오답 체크】 A는 Spot Instances로 중요 데이터 처리 불가. C는 lifecycle hook이 레이턴시 증가. D는 CloudWatch agent 수동 설정으로 overhead 증가 【시험 포인트】 multi-workload 시나리오에서 각 워크로드의 특성(reliability vs cost)에 맞는 인스턴스 타입 선택 필수. warm pool은 빠른 provision을 위한 핵심 메커니즘.

해설

【핵심 용어】 ▸ CloudWatchAgentServerPolicy — EC2에서 CloudWatch 메트릭 전송 권한 ▸ pod_memory_utilization — Pod 레벨 메모리 메트릭 ▸ node_memory_utilization — Node 레벨 메모리 메트릭 【정답 포인트】 A: EC2 인스턴스 프로파일에 policy 연결. C: CloudWatch agent 설치로 상세 메트릭 수집. E: pod 레벨 메모리 분석으로 애플리케이션 성능 진단 【오답 체크】 B는 service account role이 아닌 EC2 인스턴스 프로파일 필요. D는 로그 수집(메트릭 아님). F는 node 레벨이 아닌 pod 레벨 필요 【시험 포인트】 EKS + 메모리 문제 = CloudWatch agent를 EC2에 설치하고 pod 메트릭을 ContainerInsights로 분석. IAM 권한 설정은 EC2 인스턴스 프로파일에만 적용.

해설

【핵심 용어】 ▸ GuardDuty — 악의적 활동 탐지 ▸ Detective — 보안 조사 및 관계 분석 ▸ EKS Audit Log — API 호출 기록 【정답 포인트】 Detective는 GuardDuty 발견사항과 EKS audit log를 통합하여 악의적 동작의 근본 원인을 빠르게 조사할 수 있는 최적의 솔루션. 로그 관리 오버헤드 최소화 + 조사 용이성 제공 【오답 체크】 A는 수동으로 Athena/QuickSight 관리 필요(overhead 높음). C는 Container Insights로 메트릭만 수집, 보안 조사 제한. D는 3개 서비스 활성화만 하고 연관 분석 불가 【시험 포인트】 보안 이벤트 조사 필요 시 Detective 사용. GuardDuty + Detective + EKS audit logs 조합은 자동화된 threat investigation 제공.

해설

【핵심 용어】 ▸ Delegated Administrator — 관리 계정이 아닌 다른 계정에서 Identity Center 관리 ▸ AWSSSODirectoryAdministrator — management account에서만 사용 가능 ▸ AWSSSOMemberAccountAdministrator — member account 관리용 【정답 포인트】 B: 관리 계정에서 Identity Center 활성화(필수). D: AWSSSOMemberAccountAdministrator 정책으로 member account 권한만 제한. F: 새 IAM team 계정에만 권한 세트 할당하여 관리 계정 접근 차단 【오답 체크】 A는 delegated admin 설정을 위해 관리 계정에 Identity Center 활성화 필요. C는 DirectoryAdministrator로 management account 관리 가능(권한 과다). E는 관리 계정에 할당하면 IAM team의 관리 계정 접근 허용 【시험 포인트】 IAM Identity Center + Organizations = delegated admin 패턴. member account에서만 관리하도록 권한 세트 할당 필수.

해설

【핵심 용어】 ▸ Cross-Account Backup — 다른 계정의 backup vault에 백업 복사 ▸ Backup Vault Policy — vault 액세스 제어 ▸ KMS Key Policy — 암호화 키 액세스 제어 【정답 포인트】 A: 새 계정의 backup vault가 기본 계정의 백업을 수신하도록 정책 구성. E: 새 계정의 KMS 키가 기본 계정의 암호화된 백업을 복호화할 수 있도록 key policy 업데이트 【오답 체크】 B는 잘못된 방향(기본 계정 vault 정책). C는 기본 계정 vault가 새 계정 KMS 키 접근 불필요. D는 기본 계정 KMS 키를 새 계정과 공유할 필요 없음(새 계정 키 사용) 【시험 포인트】 Cross-account backup 흐름: 원본 계정 → 대상 vault(액세스 허용) → 대상 KMS 키(decrypt 허용). 양쪽 권한 모두 필요.

해설

【핵심 용어】 ▸ S3 RTC — 15분 내 복제 보장 ▸ Multi-Region Access Point — 여러 region의 bucket 접근 단일 endpoint ▸ SubmitMultiRegionAccessPointRoutes — 장애 조치 제어 【정답 포인트】 A: S3 RTC로 15분 내 복제 SLA 보장. B: Multi-Region Access Point 활성-수동 구성으로 자동 failover. C: SubmitMultiRegionAccessPointRoutes로 manual failover 제어 【오답 체크】 D는 Transfer Acceleration이 replication 속도와 무관. E/F는 Route 53 Recovery Controller가 S3 bucket 직접 관리 불가 【시험 포인트】 S3 multi-region: RTC(시간 보장) + Multi-Region Access Point(단일 endpoint) + route 제어. Transfer Acceleration은 client upload 속도 향상용.

해설

【핵심 용어】 ▸ OnFailure ABORT — 실패 시 파이프라인 중단 ▸ hasResourceProperties — CDK assertion으로 리소스 속성 검증 ▸ test enforcement — 테스트 실패 시 배포 차단 【정답 포인트】 A: CodeBuild에서 test → deploy 실행하고 OnFailure ABORT로 테스트 실패 시 배포 차단. D: CDK assertions으로 infrastructure as code 속성 검증 【오답 체크】 B는 rollback이 배포 후 롤백(사전 차단 아님). C는 approval이 배포 승인(테스트 강제 아님). E는 cdk diff로 변경 감지(테스트 아님) 【시험 포인트】 CDK pipeline에서 test enforcement = test 스크립트 + OnFailure ABORT + assertions module. 단위 테스트 통과만이 배포 진행 조건.

해설

【핵심 용어】 ▸ Cross-Zone Load Balancing — ALB가 모든 AZ의 healthy target 사용 ▸ Zonal Shift — Route 53 Recovery Controller로 특정 AZ 트래픽 차단 ▸ Application Recovery Controller — 장애 조치 제어 【정답 포인트】 A: Cross-zone balancing 해제로 각 AZ 내부 트래픽만 처리 → Zonal shift로 장애 AZ 트래픽 차단. 이 조합이 ALB가 장애 AZ로 트래픽 전송 방지 【오답 체크】 B는 target group 단위가 아닌 ALB 전체 설정 필요. C는 DNS hostname으로 resource set 생성 불가. D는 readiness check가 실제 traffic shift 수행 안 함 【시험 포인트】 AZ 장애 대응 = cross-zone balancing OFF + zonal shift. 단순히 AZ 제거가 아닌 traffic flow 제어 핵심.

해설

【핵심 용어】 ▸ Kinesis Data Firehose — 실시간 스트림 데이터 저장소 전달 ▸ Lambda Transformer — Firehose 내 데이터 변환 ▸ Network Firewall 로깅 통합 【정답 포인트】 D: 최소 overhead로 구현. Network Firewall → Firehose → Lambda transformer → S3. 기존 bucket을 그대로 사용하면서 data transformation 자동화 【오답 체크】 A는 recursive invocation 문제(S3 trigger 다시 발동). B는 이미 S3에 저장된 로그를 처리 안 함(future logs만 가능). C는 input transformation이 간단한 매핑만 가능(복잡한 data enrichment 불가) 【시험 포인트】 Network Firewall + data transformation = Kinesis Firehose + Lambda transformer. 로깅 대상을 직접 Firehose로 변경하는 것이 cleanest solution.

해설

【핵심 용어】 ▸ Amazon ECS deploy action — CloudFormation/ECS 배포 ▸ imagedefinitions.json — ECR 이미지 태그 참조 ▸ Lambda integration test — 연결성 및 API 검증 【정답 포인트】 A: ECS deploy action으로 최소 overhead 배포. D: imagedefinitions.json으로 새 ECR 이미지 자동 참조. E: Lambda로 connectivity + API 검증 【오답 체크】 B는 CodeDeploy (EC2용, ECS 직접 배포 아님). C는 CodeDeploy용 appspec.yml (ECS deploy action 불필요). F는 S3 action이 script 실행 불가 【시험 포인트】 ECS CI/CD workflow: ECR push → imagedefinitions.json → ECS deploy → Lambda integration test. 최소 overhead = native ECS deploy action 사용.

해설

【핵심 용어】 ▸ FSx for NetApp ONTAP — SMB/NFS 모두 지원, sub-millisecond latency ▸ User data — EC2 시작 시 초기화 ▸ Instance refresh — Auto Scaling 그룹 업데이트 【정답 포인트】 B: NetApp ONTAP은 SMB(Windows) + NFS(Linux) 모두 지원하고 sub-ms latency 제공. D: 사용자 데이터로 launch time에 파일 시스템 마운트 자동화. E: 기존 인스턴스에 새로운 user data 적용 【오답 체크】 A는 EFS가 NFS only (SMB 미지원). C는 EBS 단일 인스턴스 전용(공유 스토리지 아님). F는 인스턴스 업데이트 메커니즘 아님 【시험 포인트】 SMB + NFS 양쪽 필요 = FSx for NetApp ONTAP 유일한 선택. User data + instance refresh 조합으로 자동 적용.

해설

【핵심 용어】 ▸ Identity Center Permission Set — 여러 계정 걸친 권한 정의 ▸ aws:SourceAccount — 특정 계정 제한 ▸ sso:*, sso-directory:* — IAM Identity Center 관리 API 【정답 포인트】 D: DevOps permission set에서 sso-* API에 Deny + SourceAccount 조건으로 관리 계정에서만 거부. SCP는 permission set 내 deny를 overpower할 수 없으므로 identity-based policy에서 제어 【오답 체크】 A는 SCP 구조 변경만(기본 문제 미해결). B는 SCP 효과 없음(permission set이 우선). C는 모든 계정에 제한 (관리 계정에만 필요). 【시험 포인트】 IAM Identity Center vs SCP: permission set(identity-based)이 SCP(resource-based)보다 우선. 특정 계정 제한 = SourceAccount condition 조합.

해설

【핵심 용어】 ▸ State Manager Association — 자동화된 configuration management ▸ Tag query — 태그 기반 자동 target selection ▸ Command document — 실행할 configuration script 【정답 포인트】 B: State Manager association이 launch 후 자동으로 tag query로 새 인스턴스를 선택하고 configuration document 실행. "immediately" 옵션으로 인스턴스 생성 직후 자동 적용 【오답 체크】 A는 Compliance가 준수 확인만(자동 수정 아님). C는 maintenance window로 정기 실행(launch 직후 구성 안 함). D는 patch baseline만 적용(OS configuration 아님) 【시험 포인트】 Auto Scaling launch 직후 자동 configuration = State Manager + tag query. 최소 friction 요구사항 충족.

해설

【핵심 용어】 ▸ SCP(Service Control Policy) — Organizations 정책으로 모든 권한의 상한선 ▸ Permission boundary — SCP와 identity policy의 교집합 ▸ Effective permissions — min(identity policy, SCP) 【정답 포인트】 Department OU의 SCP가 EC2만 Allow로 변경되면, Engineering OU 및 그 아래 계정의 모든 권한은 SCP의 상한선 제약. AdministratorAccess(identity policy)가 있어도 SCP가 EC2만 허용하므로 EC2만 가능 【오답 체크】 A는 SCP가 없는 경우. C는 SCP가 모두 거부하는 경우. D는 SCP 논리 역전 【시험 포인트】 Organizational policies(SCP)는 모든 권한의 "필터". identity policy < SCP를 모두 만족해야 최종 권한 결정. Principle of least privilege for organizations.