정답 · 해설

해설

【핵심 용어】 ▸ Amazon GuardDuty — 위협 감지 및 네트워크 포트 스캔 감지 ▸ EC2 및 포트 스캔 발견 — GuardDuty의 네트워크 활동 모니터링 ▸ CloudWatch 알람 — GuardDuty 발견 기반 경고 ▸ SNS 알림 — 실시간 알림 전달 【정답 포인트】 정답은 A입니다. Amazon GuardDuty는 AWS 계정 내 위협을 감지하는 종합 위협 감지 서비스로, 특히 'UnauthorizedActivity' 및 'CryptoCurrency:EC2/BitcoinTool.B' 같은 발견과 함께 포트 스캔 같은 네트워크 정찰 활동을 감지합니다. GuardDuty는 'Recon.EC2' 패밀리의 발견으로 포트 스캔 활동을 보고합니다. CloudWatch 이벤트를 기반으로 SNS 알람을 설정하면 포트 스캔 감지 시 실시간 알림을 받을 수 있습니다. 이는 네트워크 침입 시뮬레이션과 포트 스캔 감지에 최적화된 솔루션입니다. 【오답 체크】 (B) Amazon Inspector는 CVE 및 소프트웨어 취약점 발견에 초점을 맞추고 포트 스캔 같은 외부 네트워크 활동 감지는 기본 기능이 아닙니다. (C) CVE는 취약점이고 포트 스캔 감지와 무관합니다. (D) CloudTrail은 API 호출 로그이며 네트워크 포트 스캔 활동 감지에 부적절합니다. 【시험 포인트】 - GuardDuty: 포트 스캔 및 네트워크 위협 감지 - Recon 발견: 정찰 활동(포트 스캔) 감지 - CloudWatch 통합: 발견 기반 경보 - SNS 실시간 알림

해설

【핵심 용어】 ▸ Horizontal Pod Autoscaler(HPA) — 메트릭 기반 Pod 수 조정 ▸ Vertical Pod Autoscaler(VPA) — Pod 리소스 요청/제한 자동 조정 ▸ 비정상 스케일링 — 트래픽 없이 최대 Pod 수로 확장 ▸ 리소스 부족 — CPU/메모리 요청이 부족하여 과다 스케일링 【정답 포인트】 정답은 B입니다. 문제 설명에서 애플리케이션이 트래픽 없이 즉시 최대 Pod 수로 확장된다는 것은 정상적인 메트릭 기반 스케일링이 아닙니다. 이는 Pod의 리소스 요청(resource requests)이 너무 높거나, 스케줄링 알고리즘이 Pod을 여러 노드에 분산시키려 하거나, 리소스 부족 문제입니다. Vertical Pod Autoscaler(VPA)는 Pod의 CPU 및 메모리 요청을 실제 사용률에 맞게 자동으로 조정하고 재시작합니다. 올바른 리소스 요청을 설정하면 Pod 스케줄링이 정상화되고 불필요한 확장을 방지합니다. 【오답 체크】 (A) HPA는 메트릭 기반 확장으로 리소스 요청 문제를 해결하지 못합니다. (C) Cluster Autoscaler는 노드 수를 조정하며 Pod 리소스 문제와 무관합니다. (D) AWS Load Balancer Controller는 로드 밸런싱 역할로 스케일링 동작에 영향을 주지 않습니다. 【시험 포인트】 - VPA: Pod 리소스 요청 자동 최적화 - HPA: 메트릭 기반 Pod 수 확장 - 리소스 요청 부족: 비정상 스케일링 원인 - Recommendation 모드: VPA 동작 방식

해설

【핵심 용어】 ▸ AWS Control Tower 블루프린트 — Control Tower 통합 customization ▸ Service Catalog — self-service 상품 카탈로그 ▸ AWSControlTowerBlueprintAccess — Control Tower 커스터마이제이션 역할 ▸ CloudFormation 템플릿 — 인프라 코드화 【정답 포인트】 정답은 B, C, F입니다. AWS Control Tower에서 사용자 정의를 제공하려면 먼저 각 CloudFormation 템플릿에 대한 Service Catalog 제품을 생성합니다 (C) . 각 사용자 정의 리소스를 포함하는 CloudFormation 템플릿을 작성합니다(F). Control Tower 관리 계정에서 AWSControlTowerBlueprintAccess 역할을 생성하고 적절한 신뢰 정책과 권한을 설정합니다 (B) . 이 역할은 제어 타워가 계정에 Service Catalog 제품을 배포할 때 사용됩니다. 이 조합으로 계정이 Control Tower를 통해 승인된 사용자 정의를 요청할 수 있습니다. 【오답 체크】 (A) Organizations의 신뢰할 수 있는 액세스는 필수가 아니며 Service Catalog 제품 배포와 무관합니다. (D) Stack Sets 사용은 Control Tower 블루프린트 패턴에 부적절하며 자동 배포 구성 복잡성이 높습니다. (E) Customizations for AWS Control Tower(CfCT)는 Legacy 접근 방식이고 현재 블루프린트가 권장됩니다. 【시험 포인트】 - Service Catalog: 사용자 정의 제품 제공 - CloudFormation 템플릿: 자동화 정의 - Blueprint 역할: Control Tower 통합 권한 - Control Tower 커스터마이제이션: 셀프서비스 배포

해설

【핵심 용어】 ▸ AWS Config 관리형 규칙 — IMDSv2 필수 여부 확인 ▸ IMDSv1 방지 — ec2:MetadataHttpTokens: required 설정 ▸ Systems Manager Automation — 비준수 인스턴스 자동 종료 ▸ 보안 규정 준수 — 정책 시행 및 교정 【정답 포인트】 정답은 A입니다. 이 요구사항은 두 가지 부분으로 나뉩니다: (1) IMDSv2를 필수로 설정하여 IMDSv1 사용 방지, (2) 기존 인스턴스 중 IMDSv1을 허용하는 인스턴스 자동 종료. AWS Config의 'EC2_IMDSV2_CHECK' 관리형 규칙은 인스턴스가 IMDSv2를 필수로 설정했는지 확인합니다. 비준수 인스턴스를 감지하면 Systems Manager Automation runbook을 실행하여 인스턴스를 자동으로 종료합니다. 이는 자동 규정 준수 시행(auto-remediation)의 표준 패턴입니다. 【오답 체크】 (B) 권한 경계는 새로운 인스턴스 시작만 제어하며 기존 비준수 인스턴스는 처리하지 못합니다. (C) Amazon Inspector는 CVE 및 소프트웨어 취약점 스캔이며 IMDSv2 설정 감지 기능이 없습니다. (D) EventBridge와 Lambda 조합은 수동적이며 Config의 자동 교정 기능만큼 강력하지 않습니다. 【시험 포인트】 - AWS Config: IMDSv2 규정 준수 모니터링 - 관리형 규칙: EC2_IMDSV2_CHECK - 자동 교정: Systems Manager 통합 - 보안 정책 시행: 비준수 인스턴스 종료

해설

【핵심 용어】 ▸ 시작 템플릿 — Auto Scaling 그룹 인스턴스 구성 정의 ▸ AMI ID — 시작 템플릿의 기본 이미지 ▸ Auto Scaling 그룹 업데이트 — 새로운 구성 적용 ▸ AMI 복제 — 실행 중인 인스턴스에서 이미지 생성 【정답 포인트】 정답은 A, B, E입니다. Auto Scaling 그룹이 삭제된 AMI로 인해 인스턴스를 시작할 수 없으므로 먼저 새로운 AMI가 필요합니다. 옵션 E(Auto Scaling 그룹의 실행 중인 인스턴스에서 새로운 AMI 생성)는 현재 인스턴스의 구성이 유효하면 이를 스냅샷할 수 있습니다. 새로운 AMI 생성 후 새로운 시작 템플릿을 생성하여 이 AMI를 지정합니다 (A) . 마지막으로 Auto Scaling 그룹을 새로운 시작 템플릿을 사용하도록 업데이트합니다 (B) . 이를 통해 Auto Scaling 그룹이 다시 인스턴스를 시작할 수 있습니다. 【오답 체크】 (C) 원하는 용량을 0으로 줄이면 현재 인스턴스가 종료되어 AMI 생성 기회를 잃습니다. (D) 용량 증가는 여전히 삭제된 AMI를 사용하므로 실패합니다. (F) 공용 AMI는 사용자 정의 애플리케이션 구성이 없어 부적절합니다. 【시험 포인트】 - 시작 템플릿: AMI 변경 적용 - AMI 복제: 실행 중인 인스턴스 스냅샷 - Auto Scaling 그룹 업데이트: 새로운 구성 전환 - 상태 비저장 애플리케이션: 인스턴스 스냅샷 기반 복제 가능

해설

【핵심 용어】 ▸ AWS CodePipeline — CI/CD 자동화 오케스트레이션 ▸ AWS CodeDeploy — 배포 자동화 및 일관성 보장 ▸ 순차적 파이프라인 — 빌드 > 테스트 > 배포 순서 ▸ 배포 그룹 — 대상 EC2 인스턴스 관리 【정답 포인트】 정답은 B와 C입니다. 현재 문제는 Lambda와 Systems Manager Run Command를 사용한 ad-hoc 배포로 일관성과 신뢰성이 부족합니다. CodePipeline (B) 으로 자동화된 파이프라인을 구축하여 빌드와 테스트를 순차적 단계로 구성하면 품질 제어가 강화됩니다. CodeDeploy (C) 를 사용하면 배포 그룹 내 모든 인스턴스에 일관되게 코드를 배포하고, ALB와의 통합으로 배포 중 트래픽 제어를 자동화할 수 있습니다. CodeDeploy는 배포 롤백, 헬스 체크, 동기화 등을 자동으로 처리하여 신뢰성을 높입니다. 【오답 체크】 (A) CodeBuild를 병렬로 실행하면 빌드와 테스트 순서가 부정확할 수 있습니다. (D) Lambda와 Systems Manager 조합은 현재 문제를 반복하며 CodeDeploy의 자동화 기능을 활용하지 못합니다. (E) CodeArtifact를 S3로 변경하면 아티팩트 관리 기능이 감소합니다. 【시험 포인트】 - CodePipeline: 자동화 오케스트레이션 - CodeDeploy: 신뢰할 수 있는 배포 구현 - 순차적 파이프라인: 빌드 > 테스트 > 배포 - 배포 그룹: 인스턴스 일관성 보장

해설

【핵심 용어】 ▸ EventBridge 크로스 계정 공유 — 다른 계정의 이벤트 버스로 이벤트 라우팅 ▸ 기본 이벤트 버스 — 자동 생성되는 계정별 이벤트 버스 ▸ 이벤트 버스 정책 — 크로스 계정 액세스 허용 ▸ CloudTrail 이벤트 — CreateAccount API 호출 감지 【정답 포인트】 정답은 A입니다. 자동화 계정의 CloudTrail이 CreateAccount 이벤트를 감지하면 EventBridge 규칙이 이 이벤트를 감지하고 서비스 계정의 기본 이벤트 버스로 라우팅합니다. 서비스 계정의 기본 이벤트 버스는 리소스 기반 정책(resource-based policy)을 통해 자동화 계정의 이벤트를 허용하도록 구성됩니다. 이는 표준 EventBridge 크로스 계정 이벤트 라우팅 패턴으로, 간단하고 권장되는 구현 방식입니다. 【오답 체크】 (B) CloudTrail 이벤트는 자동화 계정에만 저장되므로 서비스 계정이 자동화 계정의 CloudTrail을 직접 구독할 수 없습니다. (C) 양쪽에서 사용자 지정 버스를 생성하는 것은 불필요한 복잡성을 추가합니다. (D) 사용자 지정 이벤트 버스는 필요하지 않으며 기본 버스로 충분합니다. 【시험 포인트】 - EventBridge 크로스 계정: 다른 계정의 기본 버스로 이벤트 라우팅 - 이벤트 버스 정책: 허용 기반 액세스 제어 - CloudTrail 이벤트 통합: EventBridge를 통한 전파 - 간단한 구현: 기본 버스 사용

해설

【핵심 용어】 ▸ SQS 표준 큐 — 최소 1회 배송 보장 ▸ ReportBatchItemFailures — 일부 메시지 실패 시 부분 롤백 ▸ 이벤트 소스 매핑 — Lambda와 SQS 연결 설정 ▸ 멱등성 — 중복 처리 방지 ▸ 메시지 가시성 타임아웃 — 처리 중인 메시지 visibility 【정답 포인트】 정답은 C입니다. Lambda 함수가 SQS 배치를 처리할 때, 일부 메시지가 성공하고 일부가 실패할 수 있습니다. ReportBatchItemFailures를 FunctionResponseTypes에 포함하면 Lambda가 배치 전체가 아닌 실패한 메시지만 명시적으로 보고할 수 있습니다. 이렇게 하면 SQS는 성공한 메시지를 자동으로 삭제(처리 완료)하고 실패한 메시지만 재시도합니다. 이는 확장성(배치 처리)과 정확성(중복 처리 방지)을 모두 달성합니다. 배치 크기를 1로 줄이면 확장성이 떨어지고, 배치 윈도우와 가시성 타임아웃은 이 문제의 해결책이 아닙니다. 【오답 체크】 (A) 배치 윈도우를 줄이면 레이턴시는 개선되지만 확장성 목표를 방해합니다. (B) 배치 크기를 1로 설정하면 배치의 이점을 완전히 제거하여 확장성을 해치고 API 호출 비용이 증가합니다. (D) 가시성 타임아웃만으로는 부분 실패를 처리하지 못합니다. 【시험 포인트】 - SQS 배치 처리: Lambda 확장성 극대화 - ReportBatchItemFailures: 부분 성공/실패 구분 - 메시지 삭제 제어: 명시적 성공 보고 - 정확성과 확장성 균형

해설

【핵심 용어】 ▸ Amazon Macie — 데이터 보안 및 개인정보 탐지 서비스 ▸ 자동 검색(Automated Discovery) — Macie의 정기적인 버킷 스캔 ▸ 검색 비용 최적화 — 불필요한 스캔 제외 ▸ CloudTrail 로그 — 감사 목적으로 저장된 로그 파일 【정답 포인트】 정답은 A와 D입니다. Macie의 자동 검색 비용을 최적화하려면 민감한 데이터가 거의 없거나 검색할 필요가 없는 버킷을 제외해야 합니다. CloudTrail 로그 버킷 (A) 은 시스템 생성 감사 데이터로 이미 암호화되고 접근 제어되므로 Macie 스캔이 불필요합니다. 또한 마지막 수정 기준에 따라 검색 대상을 필터링 (D) 하면, 최근에 변경되지 않은 오래된 객체는 스캔하지 않아 비용을 절감합니다. 이 두 조치로 검색 범위를 축소하여 비용을 최적화합니다. 【오답 체크】 (B) 공개 읽기 액세스 버킷은 보안 위험도가 높아 Macie 스캔이 필요합니다. (C) 일일 검색 작업은 오히려 비용을 증가시킵니다. (E) 프로덕션 태그만 포함하면 개발/테스트 환경의 민감 데이터를 놓칠 수 있습니다. 【시험 포인트】 - Macie 자동 검색: 스캔 대상 선택적 제외 - 감사 데이터 제외: CloudTrail 로그 버킷 - 수정 기준 필터링: 구성된 검색 작업 - 비용 최적화: 스캔 범위 축소

해설

【핵심 용어】 ▸ OrganizationAccountAccessRole — 관리 계정의 새 계정 인수용 역할 ▸ AWS Security Hub — 보안 발견 통합 및 규정 준수 모니터링 ▸ 위임된 관리자 — 조직 내 특정 계정의 관리 권한 ▸ 멀티 계정 통합 — Organizations 기반 중앙화 【정답 포인트】 정답은 B와 C입니다. 인수된 계정을 조직에 통합하려면 먼저 각 계정에서 OrganizationAccountAccessRole을 생성하고 관리 계정이 이를 인수할 수 있도록 권한을 부여합니다 (B) . 이를 통해 관리 계정이 invited 계정의 리소스를 제어할 수 있습니다. 보안 발견 수집 및 그룹화는 AWS Security Hub (C) 를 사용하며, Security Hub는 조직에 추가된 새로운 계정을 자동으로 감지하고 중앙 대시보드에 모든 계정의 발견을 통합합니다. 이는 멀티 계정 보안 관리를 위한 표준 패턴입니다. 【오답 체크】 (A) SCP는 권한 제어용이며 계정 통합 메커니즘이 아닙니다. (D) Firewall Manager는 WAF 및 방화벽 정책 관리용으로 보안 발견 수집과 무관합니다. (E) Amazon Inspector는 CVE 취약점 스캔 전담이며 Security Hub 같은 포괄적 발견 통합 기능이 없습니다. 【시험 포인트】 - OrganizationAccountAccessRole: 멀티 계정 액세스 - Security Hub: 발견 통합 및 규정 준수 - 자동 계정 감지: 새 계정 추가 시 자동 포함 - 중앙화된 보안 관리

해설

【핵심 용어】 ▸ CodeBuild 보고서 그룹 — 테스트 보고서의 구조화된 저장 ▸ EventBridge — 빌드 완료 이벤트 감지 ▸ S3 Lifecycle 정책 — 자동 객체 만료 ▸ 보고서 보존 — 90일 데이터 보관 【정답 포인트】 정답은 B입니다. CodeBuild는 buildspec 파일에서 보고서 그룹을 정의하여 테스트 결과를 구조화된 형식으로 저장할 수 있습니다. 이 보고서를 S3에 영구 저장하려면 빌드 완료 시 EventBridge 규칙이 트리거되어 Lambda 함수가 보고서를 S3로 복사합니다. S3 Lifecycle 정책을 설정하면 90일 후 자동으로 객체가 만료되어 저장 비용을 관리합니다. 이는 보고서 보존 요구사항을 효율적으로 충족하는 표준 패턴입니다. 【오답 체크】 (A) 배포 작업 유형은 코드 배포용이며 보고서 저장에 최적화되어 있지 않습니다. (C) CodePipeline 테스트 작업 유형은 보고서 만료 기능이 없습니다. (D) 보고서 그룹을 CodeBuild 아티팩트로 설정하면 빌드 시마다 아티팩트가 변경되어 이전 보고서가 덮어써질 수 있습니다. 【시험 포인트】 - CodeBuild 보고서 그룹: 테스트 결과 구조화 - EventBridge + Lambda: 빌드 후 처리 - S3 Lifecycle: 자동 만료 정책 - 장기 보관 전략: 보존 기간 설정

해설

【핵심 용어】 ▸ 상호 TLS(mTLS) — 클라이언트와 서버 양쪽이 인증서를 검증하는 양방향 인증 ▸ 신뢰 저장소 — API Gateway에서 클라이언트 인증서 검증에 사용할 CA 인증서 모음 【정답 포인트】 ▸ API Gateway mTLS는 클라이언트 인증서를 신뢰할 수 있는 CA의 공개 인증서가 필요합니다(개인 키 아님) ▸ (A) ACM 프라이빗 CA를 사용하여 클라이언트 인증서 발급 — 프라이빗 인프라에서 권장 ▸ (E) S3에 루트 CA 공개 인증서 저장 — API Gateway 신뢰 저장소로 사용 가능 ▸ S3의 인증서는 신뢰 저장소 구성 시 PEM 형식이어야 함 【오답 체크】 (B) 공개 CA도 가능하지만 문제에서 내부 팀용 상호 TLS를 구축하려면 프라이빗 CA (A) 가 더 적절 (C) 클라이언트 "인증서"를 신뢰 저장소에 저장 — 틀림. 신뢰 저장소에는 CA의 공개 인증서 필요 (D) 개인 키를 신뢰 저장소에 저장 — 절대 금지. S3에 개인 키 노출은 보안 위반 【시험 포인트】 상호 TLS 설정: mTLS(A-신뢰 저장소용 CA) + (E-S3 저장소) → 클라이언트 인증 검증

해설

【핵심 용어】 ▸ AWS-JoinDirectoryServiceDomain — Systems Manager Automation Runbook으로 EC2를 도메인에 자동 조인 ▸ SSM Association — 태그 기반으로 여러 인스턴스에 SSM 문서 자동 적용 ▸ 운영 효율성 — 자동화 수준과 관리 오버헤드 최소화 【정답 포인트】 ▸ (B) CloudFormation 네이티브 솔루션: 태그 → SSM Association → AWS 관리형 Runbook 사용 ▸ EC2 시작 시 태그가 자동 전파되면, SSM Association이 자동으로 인스턴스 감지 ▸ AWS-JoinDirectoryServiceDomain는 AWS 기본 제공 Runbook으로 관리 오버헤드 최소 ▸ CloudFormation만으로 전체 인프라 + 도메인 조인 자동화 가능 【오답 체크】 (A) 커스텀 SSM 문서 작성 필요 → 개발 오버헤드 증가 (C) Auto Scaling 그룹 연결 불가능, Secrets Manager의 ARN 전달 방식 부적절 (D) 관리자 자격증명을 user data에 노출 → 보안 위험, 도메인 조인 실패 시 복구 어려움 【시험 포인트】 ClouddFormation + SSM 도메인 조인: 태그 기반 Association + AWS 관리형 Runbook = 최대 자동화

해설

【핵심 용어】 ▸ SCP(Service Control Policy) — Organizations 수준의 권한 경계. IAM 정책과 독립적으로 작동 ▸ 권한의 교집합 — IAM 정책 AND SCP 정책 모두 허용해야 액션 수행 가능 ▸ OU 계층 — 루트 OU의 SCP는 모든 자식 OU/계정에 상속 【정답 포인트】 ▸ 문제: 자식 OU의 SCP가 DynamoDB, Lambda만 허용 → EC2는 명시적으로 거부됨 ▸ IAM의 Administrator Access 정책 있어도, SCP가 거부하면 액션 불가 ▸ (C) 자식 OU의 SCP를 수정하여 EC2 추가 → SCP 제약 해제 ▸ SCP는 명시적 Allow가 없으면 모든 것을 암시적으로 거부 【오답 체크】 (A) IAM 정책만 추가 → SCP 거부 정책은 이미 적용 중. SCP가 우선 (B) 계정 수준 SCP → 루트 OU의 Allow all 정책이 이미 있으므로 불필요 (D) 루트 OU에 SCP 추가 → 자식 OU의 명시적 거부가 이미 있으면 작동 안 함 【시험 포인트】 SCP 계층 구조: 자식 OU의 제한적 정책이 우선 적용됨 → 자식 OU SCP 수정 필요

해설

【핵심 용어】 ▸ Image Builder 배포 설정 — AMI 빌드 후 배포 대상 자동 구성 ▸ 시작 템플릿 버전 관리 — $Latest, $Default 등으로 최신 버전 참조 가능 ▸ 자동화 수준 — 운영 오버헤드 최소화 【정답 포인트】 ▸ (D) Image Builder 자체 기능으로 직접 시작 템플릿 업데이트 ▸ Distribution configuration에서 AWS EC2 Auto Scaling launch template 대상 지정 가능 ▸ Auto Scaling 그룹이 $Latest 또는 $Default 버전 참고 → 자동 최신 AMI 사용 ▸ EventBridge, Lambda, Parameter Store 같은 추가 리소스 불필요 ▸ Image Builder의 네이티브 기능으로 한 단계에 해결 【오답 체크】 (A) EventBridge + Run Command → 과도한 자동화. Image Builder 배포 설정이 더 간단 (B) EventBridge + Lambda → 별도 Lambda 함수 개발 필요. 복잡도 높음 (C) Parameter Store 참조 → Image Builder 배포 설정으로 직접 업데이트 불가능. 추가 단계 필요 【시험 포인트】 자동화: Image Builder 배포 설정 활용이 가장 효율적 → EventBridge/Lambda보다 간단

해설

【핵심 용어】 ▸ 리소스 정책(Resource Policy) — Lambda 함수 측에서 누가 호출할 수 있는지 명시 ▸ S3 이벤트 알림 — S3에서 Lambda를 invoke할 권한 필요 ▸ 실행 역할(Execution Role) vs 리소스 정책 — 서로 다른 권한 검증 단계 【정답 포인트】 ▸ S3 → Lambda 호출 흐름: (1) S3에서 Lambda invoke API 호출 (2) Lambda 리소스 정책으로 S3 권한 검증 ▸ 실행 역할은 Lambda가 "내부적으로" 다른 서비스(S3, DynamoDB) 호출할 권한 ▸ 리소스 정책은 "외부에서" Lambda를 호출할 권한 ▸ (B) Lambda 리소스 정책이 누락되면, S3이 Lambda를 invoke할 수 없음 ▸ Permission 추가: s3:ObjectCreated:*, s3:ObjectUpdated:* 이벤트 → Lambda 호출 【오답 체크】 (A) 메모리는 함수 실행 속도와 관련. 호출되지 않는 문제와 무관 (C) OnFailure 대상 — 함수가 이미 실행 중이어야 의미 있음. 호출 단계 실패와 무관 (D) /tmp 디스크 공간 — 함수 실행 능력과 무관. 호출 권한 문제 해결 안 됨 【시험 포인트】 S3 → Lambda: 리소스 정책 필수 → Lambda AddPermission (S3 principal 명시)

해설

【핵심 용어】 ▸ Safety Rule (안전 규칙) — 라우팅 제어의 제어되지 않은 변경을 방지 ▸ Assertion Rule — 지정된 라우팅 제어 중 N개 이상이 켜져있어야 함 ▸ Gating Rule — 다른 라우팅 제어 상태에 따라 변경 제한 【정답 포인트】 ▸ 문제: DR 테스트 중 실수로 두 라우팅 제어를 모두 끔 ▸ 요구사항: 최소 1개 라우팅 제어는 항상 켜짐 (ATLEAST 1) ▸ (A) Assertion Rule로 "최소 1개 ON" 강제 ▸ ATLEAST 타입은 "이 조건을 반드시 만족해야 함" 의미 ▸ 규칙이 위반되면 추가 제어 변경을 자동으로 차단 【오답 체크】 (B) Gating Rule은 "다른 규칙을 제어"할 때 사용. 여기서는 Assertion이 필요 (C) HealthCheck 리소스 유형은 라우팅 제어 자체를 모니터링하지 않음 (D) DNSTargetResource는 DNS 가용성 검사용. 라우팅 제어 상태 제어와 무관 【시험 포인트】 Route 53 ARC Safety Rule: Assertion (최소값 강제) vs Gating (조건부 제어)

해설

【핵심 용어】 ▸ AWS Config — 리소스 구성 및 규정 준수 지속적 모니터링 ▸ Config Rule — 리소스가 원하는 상태인지 자동 검증 ▸ Dedicated Host 속성 — EC2 인스턴스의 tenancy 필드로 확인 가능 【정답 포인트】 ▸ (C) AWS Config가 규정 준수 감시에 가장 적합한 도구 ▸ Config Recording으로 EC2 리소스 상태 지속적 캡처 ▸ Config Rule으로 "Dedicated Host tenancy" 조건 검증 ▸ Lambda 함수가 evaluateCompliance() 실행 → NON_COMPLIANT 판정 ▸ AWS Config 대시보드에서 규정 준수율 및 비규정 리소스 목록 즉시 확인 가능 ▸ 최소 관리 오버헤드 + 자동화된 감사 【오답 체크】 (A) Configuration Compliance는 패치 관리 중심. 커스텀 상태 검증에는 부적절 (B) 복잡한 아키텍처(Java, SQS, Lambda, DynamoDB) → 관리 오버헤드 높음 (D) CloudTrail은 API 호출 기록. 현재 리소스 상태 쿼리에 부적절 【시험 포인트】 규정 준수 감시: AWS Config (자동 모니터링) > CloudTrail (감사 로그) > 커스텀 코드

해설

【핵심 용어】 ▸ Elastic Beanstalk RDS 배포 — 환경 및 앱과 함께 또는 별도로 배포 ▸ 불변 배포(Immutable) — 새 인스턴스 세트 배포 후 트래픽 전환. 자동 롤백 지원 ▸ 롤링 배포(Rolling) — 기존 인스턴스 점진적 업데이트. 배포 중 가동 중단 위험 【정답 포인트】 ▸ (B) RDS를 별도로 배포: 애플리케이션 스택과 독립적 → DB 데이터 보존 보장 ▸ Beanstalk 내 RDS 배포 (A) → 환경 삭제 시 DB도 함께 삭제될 위험 ▸ (C) Elastic Beanstalk 알림 설정 → 배포 실패 시 이메일 경고 ▸ (E) 불변 배포 → 새 환경 배포 후 실패 시 자동 롤백 ▸ 롤링(F)은 배포 중 다운타임 가능 → 고가용성 요구에 부적절 【오답 체크】 (A) Beanstalk 내 RDS → 스택 삭제 시 데이터 손실 위험. "데이터 지속" 요구사항 위반 (D) AWS Health는 AWS 인프라 건강 상태 감시. 애플리케이션 배포 실패는 감시 안 함 (F) 롤링 배포 → 자동 롤백 지원 부족. 불변 배포 (E) 가 더 나음 【시험 포인트】 Elastic Beanstalk: 불변 배포 + 별도 RDS + 알림 = 안전한 자동 배포 및 롤백

해설

【핵심 용어】 ▸ CodePipeline 수동 승인 — 승인자의 수동 조치 필요 ▸ CloudTrail — AWS API 호출 및 사용자 활동의 완벽한 감시 추적 ▸ 승인 기록 — 누가, 언제, 무엇을 승인했는지 기록 필요 【정답 포인트】 ▸ (C) CloudTrail 활성화 → CodePipeline의 모든 작업(승인 포함) S3에 기록 ▸ CloudTrail이 가장 신뢰할 수 있고 규정 준수 기록 ▸ (E) 수동 승인 작업 → 보안 팀 승인 권한 부여 ▸ 수동 승인 단계가 실행되면 CloudTrail에 기록됨 ▸ 이 두 조합으로: (1) 승인 강제 (2) 기록 및 감시 【오답 체크】 (A) CloudWatch Logs → 애플리케이션 로그용. 승인 기록에는 부적절 (B) S3에 파이프라인 작업 저장 → CodePipeline 자체 기능 아님. 정책만으로 불가능 (D) Lambda 커스텀 작업 → 승인 자동화. "수동 승인" 요구사항과 맞지 않음 【시험 포인트】 감시 + 승인: CloudTrail (감시/기록) + Manual Approval (승인 강제) = 규정 준수