정답 · 해설

해설

【핵심 용어】 ▸ Systems Manager Default EC2 Instance Management Role — Systems Manager 자동 관리용 역할 ▸ default-ec2-instance-management-role — SSM 서비스 설정 ▸ AmazonSSMManagedEC2InstanceDefaultPolicy — 필요한 최소 권한 정책 【정답 포인트】 ▸ Systems Manager의 "기본 instance management role" 설정을 사용하면 새 인스턴스가 자동으로 관리됩니다. ▸ AmazonSSMManagedEC2InstanceDefaultPolicy는 Systems Manager 기본 작업에 필요한 최소 권한을 포함합니다. ▸ 이 방식은 AWS Config, Patch Manager, 수동 remediation 없이 자동 관리를 제공합니다. ▸ 모든 새 인스턴스가 자동으로 Systems Manager에 등록됩니다. 【오답 체크】 (B) AWS Config는 규정 준수 모니터링이며, 자동 관리 설정이 아닙니다. (C) Patch Manager는 패치 관리용이지, SSM Agent 설치 자동화를 위한 도구가 아닙니다. (D) EC2 인스턴스 역할을 별도로 생성하고 수동으로 연결하는 것은 자동화가 아닙니다. 【시험 포인트】 Systems Manager automatic enrollment: "기본 instance management role" 서비스 설정이 가장 효율적입니다.

해설

【핵심 용어】 ▸ Lambda Resource Policy — Lambda 함수를 호출할 수 있는 주체(Principal) 명시 ▸ S3 Event Source — S3가 Lambda를 호출하기 위해 필요한 권한 ▸ Principal Policy vs Resource Policy — 호출 주체 vs 피호출 대상 【정답 포인트】 ▸ S3가 Lambda 함수를 호출하려면 Lambda의 리소스 정책에서 S3 권한이 필요합니다. ▸ S3 버킷 정책은 S3 버킷에 대한 액세스를 제어하며, Lambda 호출 권한과는 무관합니다. ▸ Lambda 리소스 정책에 S3 서비스와 해당 S3 버킷에 Lambda를 호출할 권한을 추가합니다. ▸ 실행 역할(IAM role)은 Lambda가 S3, DynamoDB에 접근할 권한이지, S3가 Lambda를 호출할 권한이 아닙니다. 【오답 체크】 (A) S3 버킷 정책은 S3 버킷 자체에 대한 액세스 권한이며, Lambda 호출과는 무관합니다. (C) (D) OnFailure 대상이나 SQS를 통한 우회는 근본 문제(리소스 정책)를 해결하지 못합니다. 【시험 포인트】 S3 → Lambda 호출: Lambda 리소스 정책에서 S3의 호출 권한을 명시해야 합니다.

해설

【핵심 용어】 ▸ AWS Control Tower — AWS Organizations의 관리형 환경 설정 ▸ AWSControlTowerExecution 역할 — 새 계정이 Control Tower 기능을 사용하기 위해 필요 ▸ AWS Service Catalog ProvisionProduct — Control Tower 제품(계정 생성)을 프로비저닝 【정답 포인트】 ▸ (C) 새 계정에 AWSControlTowerExecution 역할을 생성하여 Control Tower 관리자 계정이 임시 관리할 수 있도록 합니다. ▸ (D) AWS Service Catalog ProvisionProduct API는 Control Tower 상품(제품)인 "AWS Control Tower를 사용한 계정 생성"을 프로비저닝합니다. ▸ 이 두 단계로 새 계정이 Control Tower에 자동으로 등록됩니다. ▸ EventBridge 이벤트를 발행하는 것은 아니며, Service Catalog API를 호출하는 것이 올바른 방식입니다. 【오답 체크】 (A) CreateManagedAccount 이벤트는 EventBridge의 반응형 이벤트이지, 정의해야 할 이벤트가 아닙니다. (B) SetupLandingZone은 이미 Control Tower가 설정되어 있을 때 사용하는 것이며, 새 계정 생성과는 무관합니다. (E) EnableAWSServiceAccess는 조직 차원의 서비스 액세스를 활성화하는 것이며, 개별 계정 프로비저닝과는 무관합니다. 【시험 포인트】 Control Tower account enrollment: AWSControlTowerExecution 역할 + Service Catalog ProvisionProduct API.

해설

【핵심 용어】 ▸ Zonal Shift — 가용 영역 간 트래픽 이동 (무중단) ▸ Cross-Zone Load Balancing — ALB가 여러 AZ에 트래픽을 분산 ▸ 정적 안정성 — 애플리케이션 가용성 유지 【정답 포인트】 ▸ Zonal Shift는 특정 AZ에서 트래픽을 즉시 제거하는 기능입니다. ▸ 크로스 영역 로드 밸런싱을 비활성화하면 각 AZ가 독립적으로 작동합니다. ▸ Zonal Shift를 시작하면 영향받는 AZ의 대상이 ALB에서 제거됩니다. ▸ 롤백 중에 다른 AZ의 인스턴스에서 트래픽을 처리합니다. ▸ 무중단 전환으로 애플리케이션 가용성을 유지합니다. 【오답 체크】 (B) 수동으로 인스턴스를 제거하는 것은 느리고 오류가 발생하기 쉽습니다. (C) 크로스 영역 로드 밸런싱을 활성화하면 다른 AZ의 인스턴스도 영향받는 AZ의 트래픽을 처리하므로, Zonal Shift의 효과가 제한됩니다. (D) 서브넷 제거는 영구적이며, 임시 롤백 상황에 부적합합니다. 【시험 포인트】 Zonal Shift: 가용 영역 수준의 무중단 트래픽 전환 메커니즘.

해설

【핵심 용어】 ▸ EventBridge 크로스 계정 이벤트 라우팅 — 소스 계정에서 대상 계정의 이벤트 버스로 이벤트 전송 ▸ 리소스 기반 정책 — 이벤트 버스가 다른 계정의 이벤트 수신 허용 【정답 포인트】 ▸ 중앙 수집 구조 → DevOps 계정이 수신자(receiver) ▸ 각 소스 계정에서 규칙 생성 → DevOps 계정의 이벤트 버스를 대상으로 지정 ▸ DevOps 계정의 정책 → 다른 계정(source-account)의 이벤트 수신 허용 【오답 체크】 (A) 재생(replay)은 이벤트 라우팅이 아니라 저장된 이벤트 재전송 (B) 소스 계정이 받는 쪽이 되어야 하는데 역방향 설정 (D) 정책은 수신 기능이지 재생이 아님 【시험 포인트】 ▸ EventBridge 크로스 계정: 수신 계정의 정책 수정 → 송신 계정의 규칙 생성 ▸ 중앙 집중식 모니터링 아키텍처 패턴

해설

【핵심 용어】 ▸ CloudWatch 에이전트 — 메트릭 수집(CPU, 메모리, 노드) ▸ Fluent Bit — 로그 스트리밍(CloudWatch Logs로 전송) ▸ 메트릭 로그 필터 — 로그에서 패턴 추출하여 메트릭 생성 【정답 포인트】 ▸ (A) 메트릭/로그 수집: CloudWatch 에이전트 + Fluent Bit 필수 ▸ (C) 메트릭 모니터링: 기본 알람으로 임계값 기반 SNS 알림 ▸ (F) Autoscaler 오류 감지: 로그 필터로 에러 패턴 매칭 후 알람 【오답 체크】 (B) OpenTelemetry는 선택사항, 기본 수집에는 CloudWatch 에이전트+Fluent Bit (D) 복합 알람은 여러 알람 결합용, 로그 필터로 이상 감지 불가 (E) 로그 직접 모니터링은 비효율, 로그 필터로 메트릭화 필요 【시험 포인트】 ▸ EKS 모니터링 3계층: 수집(에이전트) → 저장(CloudWatch) → 알림(알람+SNS) ▸ 로그 필터로 메트릭화 패턴

해설

【핵심 용어】 ▸ RPO(Recovery Point Objective) — 허용 가능한 데이터 손실 시간(10분) ▸ NetApp SnapMirror — FSx for ONTAP의 네이티브 복제 기술 ▸ 볼륨 수준 복제 — 전체 스토리지 계층의 동기화 【정답 포인트】 ▸ FSx for ONTAP은 NetApp ONTAP 기반 → SnapMirror 직접 지원 ▸ 5분 스케줄 < 10분 RPO 요구사항 충족 ▸ 볼륨 수준 복제 = 가장 효율적이고 신뢰할 수 있는 방식 ▸ 스토리지 전용(EC2는 CloudFormation으로 재배포) 【오답 체크】 (A) S3 CRR은 애플리케이션 데이터 아님, Lambda 수동 개입 필요 (B) Backup은 EC2 전체 백업 불필요, 스토리지만 필요 (C) 인스턴스 저장소는 문제 언급 안 함, 실제 스토리지는 FSx 【시험 포인트】 ▸ FSx for ONTAP 전용 기능: SnapMirror로 매끄러운 DR 구성 ▸ RPO 계산: 복제 빈도 = 5분 ≤ 목표 RPO 10분

해설

【핵심 용어】 ▸ AWS Config 커스텀 규칙 — 사용자 정의 논리로 리소스 준수 평가 ▸ 구성 변경 트리거 — 보안 그룹 변경 즉시 감지 ▸ Lambda 자동 수정 — 비준수 리소스 자동 치료 【정답 포인트】 ▸ 커스텀 규칙 → restricted-ssh 패턴 정의 가능 ▸ 구성 변경 트리거 → 실시간 감지(폴링 불필요) ▸ 자동 수정 → Lambda로 규칙 삭제 자동화 ▸ Organizations 전체 계정 대상 가능 【오답 체크】 (A) vpe-sg-port-restriction-check는 VPE 전용, SSH 보안 그룹 감지 불가 (B) 모든 규칙 삭제는 과도(허용된 규칙도 삭제), 특정 규칙만 제거 필요 (D) 1시간마다 폴링은 지연, 변경 감지 실시간성 부족 【시험 포인트】 ▸ Config 커스텀 규칙 + 구성 변경 트리거 = 실시간 준수 자동화 ▸ SSH 0.0.0.0/0 감지 패턴: 프로토콜 + 포트 + CIDR 조합 검증

해설

【핵심 용어】 ▸ SSM Agent — 온프레미스 및 클라우드 인스턴스의 통합 관리 ▸ AWS Systems Manager — 구성 관리 및 자동화 플랫폼 ▸ AWS Config — 구성 드리프트 감지 및 추적 【정답 포인트】 ▸ SSM Agent 설치 → 온프레미스+EC2 통합 관리(45개 시스템) ▸ SSM으로 패키지 배포 → 감사 가능하고 중앙 집중식 ▸ AWS Config 모니터링 → 드리프트 자동 감지 ▸ SNS 알림 → 문제 발생 시 즉시 통보 ▸ Direct Connect 활용 → 안정적인 연결 【오답 체크】 (A) 스크립트 수동 관리 비효율, 감사 추적 불완전 (C) 수동 프로세스, 드리프트 모니터링 불가 (D) 각 VM 수동 접근 확장성 없음, 온프레미스 Config 모니터링 불가 【시험 포인트】 ▸ SSM의 온프레미스 기능: Systems Manager Hybrid Activation ▸ 45개 이상 규모 관리: 중앙화 필수 vs 스크립트 수동화 ▸ 감사 추적 + 드리프트 감지 = 운영 효율성 핵심

해설

【핵심 용어】 ▸ CodePipeline 아티팩트 저장소 — 각 리전별 독립적 S3 저장 ▸ 크로스 리전 배포 — 리전별 배포 작업 추가 ▸ 아티팩트 전달 — 파이프라인이 리전별 S3에서 읽음 【정답 포인트】 ▸ (C) us-east-1 S3 생성 → 리전 내 아티팩트 저장 ▸ (E) 파이프라인에 us-east-1 S3를 아티팩트 저장소로 추가 ▸ 새로운 CloudFormation 배포 작업 → us-east-1 아티팩트 사용 ▸ 이미 준비된 추가 아티팩트 활용 【오답 체크】 (A) 템플릿 매개변수로 .zip 위치 전달은 비효율, 각 리전 아티팩트 저장소 분리 필요 (B) 배포 작업만으로 불충분, 아티팩트 저장소 구성 필수 (D) CRR은 선택사항, 파이프라인이 리전별 저장소 설정하면 불필요 【시험 포인트】 ▸ CodePipeline 다중 리전: 각 리전별 아티팩트 저장소 + 배포 작업 ▸ 아티팩트 저장소 = 리전별 독립적 S3(자동 선택)

해설

【핵심 용어】 ▸ 권한 경계(Permission Boundary) — IAM 역할이 가질 수 있는 최대 권한 제한 ▸ CDK 부트스트래핑 — CDK 배포 환경 초기화 ▸ 최소 권한(Least Privilege) — 필요한 작업만 허용 【정답 포인트】 ▸ 권한 경계 정책 생성 → AWS CDK가 필요로 하는 최대 권한만 정의 ▸ CDK 부트스트래핑에 경계 적용 → 배포 역할의 최대 권한 제한 ▸ CDK 애플리케이션 설정 → 생성되는 역할에 기본 경계 자동 적용 ▸ Lambda 역할도 자동으로 경계 제한됨 ▸ 개발자의 권한 위임 불가 【오답 체크】 (A) SCP는 조직 정책(거부 강제), 개발자가 우회 불가하나 중앙 역할 생성 필요(오버헤드) (C) 수동 개입 필요, 개발자가 의도적/실수로 경계 미적용 가능 (D) SCP + Access Analyzer는 사후 검증, 자동 강제 불가 【시험 포인트】 ▸ 권한 경계 = 역할 생성 시 자동으로 최대 권한 제한(기술적 강제) ▸ CDK 부트스트래핑 통합 = 배포 자동화 유지(낮은 오버헤드) ▸ 개발자 의도적 상향 권한 위임 원천 차단

해설

【핵심 용어】 ▸ Enhanced Scanning — ECR의 고급 취약점 스캔(Inspector 기반) ▸ Basic Scanning — 기본 취약점 데이터베이스 스캔 ▸ Continuous Scanning — 푸시 시점과 푸시 후 지속적 스캔 【정답 포인트】 ▸ Enhanced Scanning 활성화 → 고급 취약점 감지(CVE, 의존성) ▸ 프라이빗 레지스트리 지원 ▸ 자동 스캔(푸시 시점 + 지속적) ▸ 별도 구현 불필요(관리형 서비스) 【오답 체크】 (B) Basic Scanning은 기본 기능, 정기적 스캔에 불충분 (C) 수동 자동화 문서 관리 필요, 복잡함 (D) Lambda + EventBridge는 커스텀 개발 필요, 오버헤드 증가 【시험 포인트】 ▸ ECR Enhanced Scanning = Amazon Inspector 통합 ▸ 프라이빗 레지스트리 자동 취약점 감지 ▸ 최소 운영 오버헤드 솔루션

해설

【핵심 용어】 ▸ EventBridge 스키마 검색 — 이벤트 구조 검증 ▸ CloudWatch 메트릭 — 이벤트 처리 통계 추적 ▸ 실패한 호출(Failed Invocations) — EventBridge 메트릭 ▸ IAM 권한 — 이벤트 전송 권한 확인 【정답 포인트】 ▸ (A) 스키마 검색 → 이벤트 패턴과 스키마 매칭 확인 ▸ (B) CloudWatch 메트릭 + 알림 → 비정상적 이벤트/호출 패턴 감지 ▸ (E) 실패한 호출 메트릭 검토 → IAM 권한 문제 식별 【오답 체크】 (C) Lambda 로깅은 이벤트 추적이지만, 패턴 분석에 직접 도움 안 됨 (D) Step Functions 실행 이력 검토는 호출된 경우만 유용(호출 자체가 문제면 무의미) (F) 권한 확인은 좋으나 문제 식별 방법 아님, (E) 와 중복 【시험 포인트】 ▸ 3가지 근본 원인: (1) 이벤트 패턴 매칭 실패 (2) 메트릭 이상 (3) IAM 권한 ▸ 체계적 진단: 스키마 검증 → 메트릭 모니터링 → 권한 확인

해설

【핵심 용어】 ▸ AWS Health 이벤트 — scheduled maintenance 알림(EC2 종료, 폐기 예정) ▸ Systems Manager Automation 런북 — AWS-RestartEC2Instance ▸ EventBridge 규칙 — Health 이벤트 감지 + 자동 재시작 실행 【정답 포인트】 ▸ AWS Health 이벤트 소스 필수 (scheduled instance termination/retirement) ▸ AWS-RestartEC2Instance 런북 직접 타겟 (신뢰할 수 있고 권장) ▸ 예약된 유지보수 기간 조정 (Health 이벤트 감지 → 즉시 재시작) ▸ Lambda 래핑 불필요 (직접 호출 가능) 【오답 체크】 (B) Systems Manager 이벤트 소스는 Health 알림 아님 (C) Lambda 래핑은 불필요한 복잡성 추가 (D) EC2 인스턴스 상태 이벤트는 Health 알림이 아님 【시험 포인트】 ▸ AWS Health → EventBridge → Systems Manager 자동화 통합 ▸ 예약된 유지보수: Health 이벤트 감지 패턴 ▸ 최적화: Lambda 없이 직접 런북 호출

해설

【핵심 용어】 ▸ 헬스 체크 자동화 — 배포 후 URL 상태 확인 ▸ CodePipeline 작업 — 파이프라인 단계에서 실행되는 작업 단위 ▸ Lambda 함수 — HTTP 응답 코드 검증 로직 【정답 포인트】 ▸ Lambda 함수로 URL 응답 코드 확인 (200 OK 검증) ▸ CodePipeline 작업으로 Lambda 호출 ▸ 성공/실패를 CodePipeline에 보고 (파이프라인 진행/중단) ▸ 간단하고 확장 가능한 구조 【오답 체크】 (A) CloudWatch 카나리는 모니터링 도구, CodePipeline 작업 타입 아님 (C) CodeDeploy는 배포 도구, 헬스 체크가 아님 (D) API Gateway는 필요 없음, Device Farm은 모바일 테스트 【시험 포인트】 ▸ CodePipeline 작업 선택: Lambda 작업이 커스텀 검증에 최적 ▸ 배포 후 검증 패턴: Lambda로 헬스 체크 → 상태 보고 ▸ 파이프라인 게이트: 응답 코드 검증 → 자동 진행/중단

해설

【핵심 용어】 ▸ 메트릭 필터(Metric Filter) — 로그에서 패턴 추출 후 메트릭 생성 ▸ 로그 그룹(Log Group) — 모든 스트림의 로그 집계 ▸ 차원(Dimension) — 메트릭의 분류 기준(응답 코드, 앱 이름) 【정답 포인트】 ▸ 메트릭 필터는 로그 그룹 수준에서 생성 필수 ▸ 응답 코드 범위 패턴 매칭 (범위 필터링) ▸ 응답 코드 + 애플리케이션 이름을 차원으로 설정 ▸ 메트릭 자동 증가 (카운트) 【오답 체크】 (A) 로그 스트림 수준은 개별 스트림만 대상(로그 그룹 수준 필요) (C) Contributor Insights는 상위 N 기여자 식별용(범위 기반 메트릭 아님) (D) Logs Insights는 ad-hoc 쿼리(자동 메트릭 생성 불가) 【시험 포인트】 ▸ 메트릭 필터 = 로그 그룹 + 패턴 매칭 + 메트릭 생성 ▸ 구조: 로그 그룹 → 필터 규칙 → 메트릭 값 추출 → 차원 설정

해설

【핵심 용어】 ▸ EBS CSI 드라이버 — EBS 볼륨을 Kubernetes Pod에 마운트 ▸ IAM 역할 — AWS API(EC2) 호출 권한 ▸ OIDC 발급자 — Pod Identity 인증 메커니즘 ▸ UnauthorizedOperation — IAM 권한 부족 【정답 포인트】 ▸ EBS CSI 드라이버가 EC2:CreateVolume 등 권한 필요 ▸ OIDC 발급자 이미 연결됨 → IRSA(IAM Roles for Service Accounts) 활용 ▸ EBS CSI 드라이버용 IAM 역할 생성 필수 ▸ 역할을 애드온에 연결 → CSI 드라이버가 역할 가정 ▸ EC2 권한(create, delete, attach, modify) 포함 【오답 체크】 (A) Kubernetes RBAC는 AWS 권한 아님, IAM 권한이 근본 문제 (C) 주석은 gp3 타입 지정(이미 적용된 문제 아님) (D) StorageClass 설정은 프로비저닝 방식이지, 권한 문제 해결 안 됨 【시험 포인트】 ▸ EBS CSI 드라이버 + OIDC = IAM 역할 필수 ▸ PVC 프로비저닝 실패 원인: CSI 드라이버의 AWS 권한 부족 ▸ 해결: 신뢰 관계(OIDC) + IAM 역할(EC2 권한) 구성

해설

【핵심 용어】 ▸ VPC Flow Logs — 네트워크 트래픽(RDP 포트 3389) 캡처 ▸ 메트릭 필터 — 로그에서 패턴 추출 후 메트릭화 ▸ RDP 세션 = 포트 3389 통신(TCP 연결) 【정답 포인트】 ▸ (C) VPC Flow Logs 생성 → RDP 트래픽(포트 3389) 수집 ▸ (D) CloudWatch Logs로 흐름 로그 저장 ▸ (E) 메트릭 필터로 RDP 포트 (3389) 패턴 추출 → 세션 수 메트릭 【오답 체크】 (A) EventBridge EC2 상태 변경은 RDP 세션 감지 안 함 (B) EventBridge는 RDP 트래픽 감지 불가 (F) 구독 필터는 로그를 다른 대상으로 전달, 메트릭 생성 아님 【시험 포인트】 ▸ RDP 세션 추적 = 네트워크 수준 흐름 분석 ▸ 구조: VPC Flow Logs → CloudWatch Logs → 메트릭 필터 ▸ 포트 3389 기반 패턴 매칭으로 세션 수 계산

해설

【핵심 용어】 ▸ EKS Pod Identity — Pod가 AWS 권한 자동으로 취득(새로운 방식) ▸ EKS Pod Identity Agent — Pod Identity 활성화 애드온 ▸ EKS Auth API — Pod의 임시 자격증명 발급 ▸ 노드 IAM 역할 — Pod Identity 에이전트가 사용 【정답 포인트】 ▸ 노드 IAM 역할 업데이트 완료 → Pod Identity 권한 있음 ▸ EKS Auth API 연결 확인 → 노드가 자격증명 엔드포인트 접근 ▸ EKS Pod Identity Agent 애드온 추가 → Pod Identity 기능 활성화 ▸ 애드온이 자동으로 Pod의 임시 자격증명 관리 【오답 체크】 (A) OIDC 공급자는 IRSA(구식), Pod Identity는 OIDC 불필요 (C) 액세스 항목은 kubectl 인증용, Pod Identity와 무관 (D) STS 엔드포인트 수동 구성은 불필요(애드온이 자동 처리) 【시험 포인트】 ▸ EKS Pod Identity = 신규 방식(IRSA 대체) ▸ 구성 3단계: (1) 노드 역할 업데이트 (2) Auth API 접근 (3) 애드온 활성화 ▸ 애드온만으로 자동화 완성

해설

【핵심 용어】 ▸ 조직 추적(Organization Trail) — 모든 계정의 CloudTrail 이벤트 중앙화 ▸ Contributor Insights — 로그에서 상위 기여자 자동 식별 ▸ userIdentity.arn — 사용자/역할 식별자(CloudTrail 표준 필드) 【정답 포인트】 ▸ 조직 추적 생성 → 모든 계정의 활동 수집 ▸ CloudWatch Logs로 저장 → 메타데이터 검색 가능 ▸ Contributor Insights 규칙 → userIdentity.arn 분석 (상위 사용자/역할) ▸ 즉시 결과 시각화 (추가 쿼리 불필요) 【오답 체크】 (B) Access Analyzer는 미사용 권한 감지, 상위 사용자 식별 아님 (C) Athena는 수동 쿼리 필요, 자동화 부족 (D) 서비스 액세스 보고서는 서비스별 활동, 사용자별 분석 제한적 【시험 포인트】 ▸ 다중 계정 모니터링: 조직 추적 + CloudWatch Logs ▸ 자동 분석: Contributor Insights가 상위 N 자동 추출 ▸ 낮은 운영 오버헤드: 추가 ETL/쿼리 불필요