정답 · 해설

해설

【핵심 용어】 ▸ CloudFormation—Lambda 커스텀 리소스 응답 메커니즘 【정답 포인트】 ▸ B번 옵션—핵심 요구사항 충족 ▸ E번 옵션—핵심 요구사항 충족 【오답 체크】 (A) 첫 번째 검토 대상—부분적 조건 충족하나 완전하지 않음 (C) 세 번째 옵션—자동화 부족 또는 보안 취약점 발생 (D) 네 번째 선택—오버헤드 증가 또는 비효율적 솔루션 【시험 포인트】 ▸ 다중 선택 (2개)—조합 문제: 각 요소의 역할 구분

해설

【핵심 용어】 ▸ 주요 서비스 개념 【정답 포인트】 ▸ A번 옵션—핵심 요구사항 충족 ▸ D번 옵션—핵심 요구사항 충족 ▸ E번 옵션—핵심 요구사항 충족 【오답 체크】 (B) 두 번째 선택지—요구사항의 일부만 해결 (C) 세 번째 옵션—자동화 부족 또는 보안 취약점 발생 (F) 여섯 번째 선택—완전 자동화 미확보 【시험 포인트】 ▸ 다중 선택 (3개)—조합 문제: 각 요소의 역할 구분

해설

【핵심 용어】 ▸ 주요 서비스 개념 【정답 포인트】 ▸ B번 옵션—핵심 요구사항 충족 【오답 체크】 (A) 첫 번째 검토 대상—부분적 조건 충족하나 완전하지 않음 (C) 세 번째 옵션—자동화 부족 또는 보안 취약점 발생 (D) 네 번째 선택—오버헤드 증가 또는 비효율적 솔루션 【시험 포인트】 ▸ 단일 정답 선택—최적 솔루션 식별 능력

해설

【핵심 용어】 ▸ 주요 서비스 개념 【정답 포인트】 ▸ B번 옵션—핵심 요구사항 충족 【오답 체크】 (A) 첫 번째 검토 대상—부분적 조건 충족하나 완전하지 않음 (C) 세 번째 옵션—자동화 부족 또는 보안 취약점 발생 (D) 네 번째 선택—오버헤드 증가 또는 비효율적 솔루션 【시험 포인트】 ▸ 단일 정답 선택—최적 솔루션 식별 능력

해설

【핵심 용어】 ▸ 주요 서비스 개념 【정답 포인트】 ▸ A번 옵션—핵심 요구사항 충족 【오답 체크】 (B) 두 번째 선택지—요구사항의 일부만 해결 (C) 세 번째 옵션—자동화 부족 또는 보안 취약점 발생 (D) 네 번째 선택—오버헤드 증가 또는 비효율적 솔루션 【시험 포인트】 ▸ 단일 정답 선택—최적 솔루션 식별 능력

해설

【핵심 용어】 ▸ CloudWatch Agent — EC2 내 시스템 로그 수집 ▸ CloudWatch Logs — 로그 중앙화 및 메트릭 필터 ▸ Metric Filter — "login" 키워드 실시간 감지 ▸ "15분 내" → 실시간 모니터링 필수 【정답 포인트】 ▸ CloudWatch Agent → 모든 사용자 로그인(/var/log/auth.log) 수집 ▸ Metric Filter → 로그인 패턴 감지(예: "Failed password" or "Accepted") ▸ CloudWatch Alarm → 메트릭 > 0 시 Lambda/SNS 트리거 ▸ 즉시 알림 가능 (CloudWatch 기반 경보) 【오답 체크】 (A) Inspector는 취약점 스캔 → 로그인 모니터링 도구 아님 (C) CloudTrail은 AWS API만 기록 → EC2 시스템 로그 아님 (D) S3 이벤트 → Athena 쿼리 → 느림 (15분 초과) 【시험 포인트】 "EC2 로그인 모니터링" + "15분 내" → CloudWatch Agent + Logs + Metric Filter + CloudWatch Alarm. S3는 너무 느리고, CloudTrail/Inspector는 대상이 아님.

해설

【핵심 용어】 ▸ UPDATE_ROLLBACK_FAILED — 롤백 중단 상태 (수동 개입 필요) ▸ ContinueUpdateRollback — CloudFormation 도움말 제공 ▸ Drift Detection — 리소스 수동 변경 감지 및 동기화 ▸ Manual Resource Adjustment — 템플릿과 리소스 맞추기 【정답 포인트】 ▸ (C) ContinueUpdateRollback → 롤백 재개 ▸ (D) 롤백 중 실패한 리소스 수동 수정 ▸ 롤백이 완료된 후에야 스택 사용 가능 【오답 체크】 (A) 권한 추가만으로는 롤백 재개 불가 (B) Drift 감지는 동기화 도구, 롤백 복구 도구 아님 (E) 업데이트는 현재 상태를 악화시킬 수 있음 【시험 포인트】 UPDATE_ROLLBACK_FAILED = ContinueUpdateRollback + 수동 리소스 조정. 롤백 재개 → 리소스 일관성 확인 → 재개의 순서.

해설

【핵심 용어】 ▸ CodePipeline — 배포 진행 추적 및 자동화 ▸ CodeBuild — 아티팩트 자동 빌드 ▸ CodeDeploy — EC2 배포 + 롤백 기능 ▸ AppSpec Lifecycle Hooks — 배포 단계별 커스텀 작업 【정답 포인트】 ▸ (B) BeforeInstall 훅 → 캐시 지우기 자동화 ▸ (D) CodePipeline → 진행 상황 추적 (핵심) ▸ (E) CodeBuild + CodeDeploy → 완전 자동화 + 롤백 ▸ "배포 실패 시 중지 및 롤백" → CodeDeploy 자동 【오답 체크】 (A) EventBridge + Lambda → pull 이벤트는 신뢰성 낮음 (C) 사용자 데이터 + 수동 테스트 → CI/CD 아님 (F) Systems Manager → 배포 추적 미지원 【시험 포인트】 CI/CD 자동화 + 롤백 = CodePipeline (D) + CodeBuild (E) + BeforeInstall 훅 (B) . AppSpec + Lifecycle hooks가 배포 단계별 제어의 핵심.

해설

【핵심 용어】 ▸ Secrets Manager/Parameter Store — 민감 데이터 저장 ▸ SecureString — KMS 암호화된 파라미터 ▸ IAM Role — 자격증명 대신 권한 부여 ▸ Systems Manager Session Manager — SSH 직접 접근 제한 【정답 포인트】 ▸ (B) IAM 역할 권한 + 자격증명 제거 → 보안 표준 ▸ (C) DB_PASSWORD → Parameter Store SecureString ▸ (E) SSH/SCP → Systems Manager Session Manager (감사 추적) 【오답 체크】 (A) 임시 파일 정리는 이차적 → 근본 문제 아님 (D) S3에 환경 변수 저장 → Parameter Store보다 낮은 보안 (F) XOR + Base64 = 난독화, 암호화 아님 (보안 불충분) 【시험 포인트】 CodeBuild 보안 = IAM 역할 (B) + Parameter Store SecureString (C) + Session Manager (E) . buildspec.yaml에 자격증명 노출 금지 (이미지 레이어 레지스트리에 남음).

해설

【핵심 용어】 ▸ AWS CodeBuild — 완전 관리형 빌드 서비스 (운영 오버헤드 0) ▸ Custom Docker Image — 종속성 캡슐화 ▸ ECR — 이미지 저장소 ▸ "가장 운영적으로 효율적" → 관리 최소화 【정답 포인트】 ▸ CodeBuild → 자동 스케일, 자동 정리, no ops ▸ 커스텀 Docker 이미지 → 빌드 환경 캡슐화 ▸ ECR 저장 → 버전 관리 및 재사용 【오답 체크】 (B) EC2 수동 관리 → 운영 오버헤드(패치, 모니터링) (C) Image Builder → 이미지 빌드용, 아티팩트 빌드 아님 (D) EKS/Fargate → 과도한 복잡성(Kubernetes 관리) 【시험 포인트】 "가장 운영적으로 효율적" = 관리 최소 = CodeBuild + Docker 이미지. CodeBuild는 EC2와 달리 자동 스케일, 자동 정리, 비용 효율성 모두 제공.

해설

【핵심 용어】 ▸ aws ecr get-login-password — 임시 인증 토큰 생성 ▸ docker login — ECR 저장소 인증 ▸ docker push — 이미지 업로드 ▸ IAM Role + ECR Repository Policy — 권한 체계 【정답 포인트】 ▸ (A) get-login-password → docker login 인증 토큰 생성 ▸ 이미 IAM 역할 권한 있음 (문제 설명 참고) ▸ Docker는 인증 토큰 필요 (IAM 역할만으로 불충분) 【오답 체크】 (B) SECRETS_MANAGER 환경 변수는 ARN만 담음 → 실제 토큰 아님 (C) 공개 저장소 → 보안 문제 (D) 역할 가정 추가 → 이미 역할 있음, 토큰만 필요 【시험 포인트】 Docker CLI는 IAM 역할 인식 불가 → get-login-password로 토큰 생성 후 docker login 필수. IAM 권한 있어도 Docker 로그인 토큰은 별도 생성.

해설

【핵심 용어】 ▸ External SAML 2.0 IdP — 이미 구성됨 ▸ IAM Identity Center — 자동 프로비저닝 주체 ▸ SCIM — 사용자/그룹 동기화 표준 프로토콜 ▸ Group Sync — Active Directory 그룹 → IAM 【정답 포인트】 ▸ 기존 SAML 2.0 IdP 있음 → 외부 IdP로 구성 ▸ "그룹을 IAM에서 사용" → SCIM이 그룹 동기화 지원 ▸ "자동 프로비저닝" → SCIM 프로토콜 사용 【오답 체크】 (B) AWS Directory Service → 온프레미스 AD 아님 (C) AD Connector는 동기화 미지원 → SCIM 불가 (D) SAML은 그룹 동기화 미지원 → 그룹 매핑 불가 【시험 포인트】 External SAML + 그룹 동기화 = External IdP (A) + SCIM. SAML은 인증(SSO), SCIM은 프로비저닝(자동화). 그룹 매핑을 위해서는 SCIM 필수.

해설

【핵심 용어】 ▸ AWS Config — 리소스 구성 변경 감지 + 자동 수정 ▸ Config Conformance Packs — 정책 기반 규칙 + 자동 수정 ▸ Security Hub — 크로스 계정 중앙화 대시보드 ▸ "개발 오버헤드 최소" → 관리형 서비스 최대한 【정답 포인트】 ▸ (C) Config Recorder → 구성 변경 감지 ▸ Managed/Custom Rules → 비준수 식별 ▸ Conformance Packs → 자동 수정 (15분 내) ▸ Security Hub → 크로스 계정 중앙화 + 타임스탬프 【오답 체크】 (A) Drift 감지만으로는 자동 수정 불가 → Custom Lambda 필요 (B) CloudTrail + Athena → 복잡한 쿼리 (개발 오버헤드 높음) (D) CloudWatch 필터 → 로그 분석 복잡 (CloudFormation/Config 미지원) 【시험 포인트】 "Console 수정 감지" + "15분 내 자동 수정" + "중앙화 대시보드" = AWS Config(감지) + Conformance Packs(자동) + Security Hub(대시보드). Config가 드리프트 감지의 표준 서비스.

해설

【핵심 용어】 ▸ SCP (Service Control Policy) — Organizations에서 계정의 최대 권한을 설정하는 정책 ▸ FullAWSAccess — 모든 AWS 서비스에 대한 전체 접근 권한 【정답 포인트】 ▸ SCP는 명시적 Deny를 포함하지 않으면 Allow 범위를 제한하는 역할 ▸ Development OU에 EC2만 허용하는 정책을 적용하면, 그 범위가 최대 권한(permission boundary)이 됨 ▸ IAM 정책과 달리 SCP는 "누가 할 수 있는가"를 정의하지 않고 "최대 어디까지 할 수 있는가"를 정의 ▸ EC2 Action만 Allow하는 정책은 다른 서비스는 implicit deny 【오답 체크】 (A) FullAWSAccess를 제거했으므로 모든 API 작업이 가능한 것은 아님 (C) SCP가 EC2 Action을 Allow하므로 모두 거부되는 것은 틀림 (D) 정책의 Allow/Deny 논리를 역으로 이해한 오답 【시험 포인트】 ▸ SCP의 기본 원칙: Allow 범위 내에서만 작동하며, 범위 밖은 암묵적 거부 ▸ FullAWSAccess 제거 = 다른 정책으로 최대 권한 재정의 ▸ EC2만 명시적 Allow = 다른 서비스는 암묵적 Deny

해설

【핵심 용어】 ▸ Git Mirror — 원본 리포지토리를 다른 리포지토리로 완전 동기화 ▸ Cross-Region Replication — 여러 리전의 코드 동기화 ▸ Event-driven Automation — CodeCommit 병합 이벤트로 자동 동기화 트리거 【정답 포인트】 ▸ 보조 리전에서 "추가 원격 URL 추가"가 가능해야 하므로, 보조 리전에도 CodeCommit 리포지토리 필요 ▸ 자동 동기화: 기본 리전 병합 → EventBridge 감지 → Lambda 호출 → CodeBuild 실행 → Git Mirror ▸ CodeBuild는 git clone --mirror로 완전한 리포지토리 동기화 가능 ▸ Lambda + CodeBuild 조합이 비용 효율적이고 관리 용이 【오답 체크】 (B) S3 버킷은 Git 리포지토리로 사용될 수 없음 (개발자가 원격 URL로 사용 불가) (C) CodeArtifact는 패키지 저장소이지 Git 리포지토리 아님 (D) Cloud9 환경은 일시적 개발 환경이며 지속적 DR 솔루션 아님 【시험 포인트】 ▸ 멀티 리전 CodeCommit 설정 시 EventBridge + Lambda + CodeBuild 패턴 ▸ Git mirror의 목적: bare repository로 완전 동기화 ▸ 개발자는 local git remote add로 두 리포지토리 모두 push 가능

해설

【핵심 용어】 ▸ RDS Snapshot — 프로덕션 DB의 시점 복구 이미지 ▸ Integration Test — 배포 전 변경사항 검증 ▸ CI/CD Pipeline — 자동화된 테스트 및 배포 프로세스 【정답 포인트】 ▸ "변경사항을 프로덕션에 배포하기 전에 테스트"가 핵심 요구사항 ▸ 스냅샷 복원 → 테스트 → 삭제의 자동화가 CI/CD의 정석 ▸ CodeBuild buildspec 파일에서 전체 workflow 구성 가능 ▸ 프로덕션 데이터로 통합 테스트하되, 프로덕션 DB에는 영향 없음 【오답 체크】 (B) 프로덕션에 먼저 배포 후 감사 로그로 확인 = 위험한 방식 (C) Update requires:Replacement는 무중단 배포용이 아니며, 테스트와 무관 (D) Failover는 재해복구이지 테스트 메커니즘이 아님 【시험 포인트】 ▸ RDS Multi-AZ 환경에서 안전한 테스트: snapshot restore → test → drop ▸ CI/CD 파이프라인에 RDS 스냅샷 기반 테스트 통합 ▸ 프로덕션 데이터를 사용한 테스트지만 프로덕션 DB는 무영향 ▸ buildspec에서 복잡한 데이터베이스 작업 오케스트레이션 가능

해설

【핵심 용어】 ▸ Network Firewall — VPC 수준의 네트워크 보호 ▸ GuardDuty — 위협 탐지 서비스 ▸ Security Hub — 보안 결과 중앙 집중화 【정답 포인트】 ▸ "VPC 전체에서 트래픽을 자동으로 거부" = Network Firewall 필요 ▸ Network Firewall은 VPC 레벨에서 모든 네트워크 트래픽 제어 가능 ▸ Lambda → EventBridge 이벤트 → Network Firewall 정책 업데이트 ▸ Drop action으로 의심 소스의 트래픽 완전 차단 【오답 체크】 (A) GuardDuty 위협 목록은 GuardDuty 자신의 탐지만 변경하고 트래픽 차단 안함 (B) WAF는 애플리케이션 레벨(Layer 7)이므로 VPC 전체 트래픽 차단 불가 (D) GuardDuty 억제 규칙은 경고를 숨기기만 하고 실제 트래픽 차단 안함 【시험 포인트】 ▸ VPC 레벨 보안: Network Firewall (Layer 3~7) ▸ WAF는 ALB/CloudFront 레벨 (Layer 7) ▸ GuardDuty → Security Hub → EventBridge → Lambda → Network Firewall 자동화 파이프라인 ▸ Network Firewall 정책의 Drop action으로 트래픽 즉시 차단

해설

【핵심 용어】 ▸ KMS Customer Managed Key — 사용자 정의 암호화 키 ▸ Least Privilege — 최소 권한 원칙 ▸ Key Policy + IAM Policy — KMS 접근 제어의 이중 구조 【정답 포인트】 ▸ KMS 접근: 1) Key Policy 허용 AND 2) IAM Policy 허용 모두 필요 ▸ (B) CMK 생성 + Lambda 역할에 decrypt 권한 = Least Privilege ▸ (D) Lambda 역할의 KMS 권한을 "decrypt" 액션으로 리소스 레벨 제한 ▸ 기본 KMS 키 수정은 위험하고 다른 서비스에 영향 가능 【오답 체크】 (A) 기본 KMS 키 수정은 모범 사례 아님 (다른 서비스 영향) (C) 루트 주체만 복호화는 Lambda가 접근 불가능 (E) KMS 권한 완전 제거는 Lambda가 암호 복호화 불가능 【시험 포인트】 ▸ KMS 접근 제어: Key Policy (allow) + IAM Policy (allow) 양쪽 필요 ▸ CMK 생성하면 Key Policy에서 Secrets Manager 신뢰 설정 필수 ▸ Lambda IAM role에 decrypt:decrypt 권한을 "arn:aws:kms:region:account:key/key-id" 리소스로 제한 ▸ 최소 권한: decrypt만 허용, encrypt는 불필요

해설

【핵심 용어】 ▸ Dead-Letter Queue (DLQ) — 처리 실패한 메시지 저장소 ▸ Message Durability — 메시지 손실 방지 ▸ SNS → SQS → Lambda — 신뢰할 수 있는 메시징 패턴 【정답 포인트】 ▸ (C) SNS DLQ: SNS에서 Lambda 처리 실패 시 메시지 보존 ▸ (D) SNS → SQS → Lambda: SQS는 메시지를 대기열에 보관하여 Lambda 재시도 시간 확보 ▸ SQS의 기본 특성: 메시지 도착 보장, 여러 번 재시도 가능 ▸ DB 다운 시에도 SQS는 메시지를 계속 보관하고 있다가 DB 복구 후 처리 【오답 체크】 (A) DynamoDB 사용도 도움이 되지만, 메시지 손실 방지와 무관 (B) Lambda 함수의 대상으로 SQS 사용은 Lambda → SQS이지만, SNS → Lambda 직접 실패 시 보호 안됨 (E) EventBridge는 SNS와 유사한 문제 (Lambda 직접 호출, 실패 시 메시지 손실) 【시험 포인트】 ▸ SNS 메시지 손실: SNS DLQ로 Lambda 실패 메시지 보존 ▸ SNS → SQS 구독: SQS는 본질적으로 내구성 높음, 여러 재시도 지원 ▸ SQS에서 Lambda 호출 시 배치 처리 + 실패 분리(BISECT_BATCH_ON_FUNCTION_ERROR) ▸ RDS 다운 → Lambda 재시도 실패 → SQS 대기 → RDS 복구 후 처리 완료

해설

【핵심 용어】 ▸ Multi-Region Deployment — 여러 리전에 순차적 배포 ▸ Health Check — 배포 후 상태 확인 ▸ Deployment Gate — 배포 진행 전 조건 확인 【정답 포인트】 ▸ "다음 리전으로 이동하기 전에 애플리케이션이 정상 상태인지 확인" ▸ Step Functions: 각 배포 단계 사이의 검증 로직 구현 ▸ CloudWatch 알람이 ALARM 상태 = 배포 실패, 다음 리전 진행 중단 ▸ Step Functions으로 CloudWatch 알람 모니터링 후 조건부 진행 【오답 체크】 (B) CodeDeploy는 배포 도구이지 상태 검사 게이트 아님 (C) "CloudWatch 알람 작업"은 CodePipeline에 존재하지 않음 (검증 불가) (D) CloudWatch 에이전트는 메트릭 수집용이지 파이프라인 게이트용 아님 【시험 포인트】 ▸ CodePipeline 내 각 배포 후 상태 확인 메커니즘 필요 ▸ Step Functions: Lambda로 CloudWatch 알람 상태 조회 가능 ▸ 알람 상태에 따라 파이프라인 진행/중단 제어 ▸ Multi-region 배포 시 각 리전 확인 후 다음 진행하는 패턴