정답 · 해설

해설

【핵심 용어】 ▸ CloudTrail Data Events(Lambda) — Lambda 함수 호출(Invoke) 기록, 호출 프린시펄 포함 ▸ 언어 무관 — 코드 변경 없이 로깅(런타임 다양성 대응) ▸ 기본 트레일 — 관리 이벤트만 기록하므로 데이터 이벤트 활성화 필요 【정답 포인트】 ▸ "특정 Lambda 호출과 호출 프린시펄 기록 + 언어 다양 + 최소 오버헤드" → 기존 CloudTrail 트레일을 수정해 Lambda를 데이터 이벤트로 모니터링(코드 변경 불필요) 【오답 체크】 (A) 함수 코드 수정은 다양한 언어별 구현 필요로 오버헤드 큼. (B) EventBridge lambda:invoke 사용자 패턴 + 별도 Lambda 기록은 복잡하고 비표준. (D) 호출 컨텍스트를 로깅하는 Lambda 레이어를 모든 함수에 붙이는 것도 오버헤드 크고 CloudTrail 동작 방식과 다름. 【시험 포인트】 Lambda 호출·프린시펄 로깅 최소 오버헤드 → CloudTrail 데이터 이벤트.

해설

【핵심 용어】 ▸ SSM 프라이빗 접근 인터페이스 엔드포인트 — ssm, ec2messages, ssmmessages 필요 ▸ S3 Gateway VPC Endpoint — 패치 다운로드(패치 소스가 S3) 경로 제공 ▸ 라우트 테이블 — 게이트웨이 엔드포인트로 향하는 경로 추가 【정답 포인트】 ▸ 인터넷 불가 환경에서 Patch Manager/SSM 연결 ▸ (B) com.amazonaws.[region].ec2messages 및 .ssm 인터페이스 엔드포인트 생성 ▸ (A) com.amazonaws.[region].s3 게이트웨이 엔드포인트 생성(패치 콘텐츠 접근) ▸ (E) 라우트 테이블에 게이트웨이 VPC 엔드포인트 경로 추가 【오답 체크】 (C) NAT 게이트웨이는 인터넷 경유라 "인터넷 불가" 요건 위배. (D) NAT 게이트웨이로 SSM 트래픽 라우팅도 인터넷 사용이라 부적합. (F) 업데이트 트래픽을 NAT로 라우팅하는 것도 인터넷 경유라 요건 위배. 【시험 포인트】 인터넷 없는 SSM/Patch → ssm·ec2messages·ssmmessages 인터페이스 + S3 게이트웨이 엔드포인트 + 라우트.

해설

【핵심 용어】 ▸ Route 53 Resolver Query Logging — VPC 내부 리소스의 DNS 쿼리 로깅 ▸ CloudWatch Logs 대상 — 쿼리 로그 저장 ▸ CloudWatch Contributor Insights — 시계열로 상위 기여자(가장 흔한 DNS 쿼리) 분석 【정답 포인트】 ▸ "VPC 내부 DNS 쿼리 전부 로깅 + 가장 흔한 쿼리 시간대별 목록" → Route 53 Resolver 쿼리 로깅을 CloudWatch Logs로 보내고 Contributor Insights로 상위 쿼리 시계열 생성 【오답 체크】 (A) CloudWatch 에이전트는 애플리케이션 로그용이며 DNS 쿼리를 표준 수집하지 않음(수작업 과다). (B) BIND 서버 자체 구축 + bash 스크립트는 운영 부담 크고 관리형 요건과 상충. (C) VPC 플로우 로그는 IP/포트 흐름이지 DNS 쿼리 이름을 기록하지 않음. 【시험 포인트】 VPC DNS 쿼리 로깅 + 상위 쿼리 분석 → Route 53 Resolver query logging + Contributor Insights.

해설

【핵심 용어】 ▸ Route 53 서브도메인 위임 — 부모 존(example.com)에 서브도메인(dev.example.com)의 NS 레코드 필요 ▸ ACM DNS 검증 — CNAME이 실제 조회되려면 위임이 완성되어야 함 ▸ pending validation — 서브도메인 위임 누락으로 검증 CNAME 미조회 【정답 포인트】 ▸ dev.example.com 존이 별도 계정(B)에 있지만 부모(A)에 NS 위임이 없어 외부에서 dev 존의 검증 CNAME이 조회 안 됨 → 부모 존 example.com(계정 A)에 dev.example.com의 NS 레코드 추가로 해결 【오답 체크】 (A) 인증서를 별도 구매·임포트하는 것은 관리형 갱신 요건·근본 원인과 무관. (C) Private CA는 퍼블릭 도메인 검증 문제와 관계없음. (D) DNS 검증을 쓰고 있으므로 이메일 소유 검증 재발송은 무관. 【시험 포인트】 서브도메인 ACM DNS 검증 pending → 부모 존에 NS 위임 레코드 확인.

해설

【핵심 용어】 ▸ AWS Config 관리형 규칙 — 미암호화 RDS 스토리지 탐지 ▸ 자동 수정(Automatic Remediation) — 비준수 리소스에 자동으로 조치(SSM Automation) ▸ SNS(이메일 + Lambda 구독) — 이메일 알림 + Lambda가 리소스 삭제 【정답 포인트】 ▸ "미암호화 DB 생성 시 이메일 알림 + 자동 종료" + "운영 효율 최대" → Config 관리형 규칙으로 탐지, 자동 수정으로 SNS 발행(Lambda·이메일 구독), Lambda가 미암호화 리소스 삭제 【오답 체크】 (B) 수동(manual) 수정은 자동 종료 요건에 어긋나 효율 낮음. (C) EventBridge RDS 이벤트 패턴 방식도 가능하나 Config 규칙 기반 자동 수정 대비 요건 매핑이 약하고 삭제 흐름이 부정확. (D) 마찬가지로 EventBridge→Lambda 구조는 이 문제에서 Config 자동 수정보다 운영 효율이 낮게 평가. 【시험 포인트】 미암호화 리소스 알림+자동 조치 → Config 규칙 + 자동 remediation + SNS + Lambda.

해설

【핵심 용어】 ▸ IAM Access Analyzer(정책 생성/last accessed 정보) — 지난 기간 실제 사용된 권한 분석으로 미사용 권한 제거 ▸ Last Accessed Information — 서비스/액션 최근 접근 정보(최대 마지막 접근 시점) ▸ 최소권한 감사 — 미사용 권한 정리 【정답 포인트】 ▸ "각 IAM 자격 증명이 지난 365일간 사용한 권한 확인 후 미사용 제거" → IAM Access Analyzer의 last accessed(사용 이력) 정보를 검토해 미사용 권한 제거 【오답 체크】 (A) CloudTrail 로그 수동 분석은 방대하고 비효율적(관리형 last accessed 정보가 존재). (B) AWS Config는 리소스 구성 변경 추적으로 IAM 권한 사용 분석 목적이 아님. (D) Trusted Advisor는 권장사항 점검이지 자격 증명별 권한 사용 이력 분석 도구가 아님. 【시험 포인트】 미사용 권한 감사/제거 → IAM Access Analyzer의 last accessed 정보.

해설

【핵심 용어】 ▸ 임포트된 키 자료(Imported Key Material) — KMS 자동 로테이션 미지원 ▸ 수동 로테이션 — 새 CMK 생성 + 새 키 자료 임포트 + 별칭(alias) 전환 ▸ Key Alias — 애플리케이션이 별칭을 참조하도록 해 무중단 키 전환 【정답 포인트】 ▸ "임포트된 키 자료 CMK를 매년 로테이션" → 자동 로테이션 불가하므로 새 CMK 생성, 새 키 자료 임포트, 별칭을 새 키로 가리키도록 전환(수동 로테이션) 【오답 체크】 (A) 임포트된 키 자료 키는 자동 로테이션을 켤 수 없음. (B) Lambda로 CMK를 임의 로테이션하는 것은 지원되는 메커니즘이 아님. (C) 기존 키에 새 자료를 임포트하는 것은 지원되지 않음(키 자료는 재임포트 불가/동일 자료만). 【시험 포인트】 임포트 키 자료 로테이션 → 새 키 생성 + 자료 임포트 + alias 전환(자동 로테이션 불가).

해설

【핵심 용어】 ▸ AWS Config 규칙 + 자동 수정 — 액세스 키 로테이션 미준수 자동 조치 ▸ Systems Manager Automation Runbook — 키 로테이션 자동화 실행 단위 ▸ CloudFormation StackSets — 다계정에 runbook/규칙 일괄 배포 【정답 포인트】 ▸ "20개 계정 90일 키 로테이션 강제" → Config 규칙에 자동 수정 옵션 추가, SSM Automation runbook 생성, StackSets로 다계정 배포, 규칙 활성화 후 runbook을 자동 수정 단계로 연결 【오답 체크】 (B) change sets는 단일 스택 변경 미리보기용으로 다계정 배포에 부적합(StackSets 필요). (C) "Systems Manager rule"이라는 자동 수정 규칙 개념은 없음(자동 수정은 Config 규칙 기반). (D) change sets 사용 + Lambda로 runbook 연결은 구성상 부정확하고 다계정 배포 부적합. 【시험 포인트】 다계정 자동 remediation 배포 → Config 규칙 + SSM Automation runbook + CloudFormation StackSets.

해설

【핵심 용어】 ▸ S3 Server Access Logs — 객체/버킷 접근 상세(요청자 IP, 다운로드 등) 기록 ▸ Amazon Athena — S3 접근 로그를 SQL로 쿼리(가장 많이 접근된 버킷/객체 등) ▸ Amazon QuickSight — SQL 결과를 대시보드로 시각화 【정답 포인트】 ▸ "객체·버킷 접근 패턴을 단순 SQL로 대시보드화" ▸ (B) S3 서버 액세스 로그로 접근 상세 수집 ▸ (F) Athena로 접근 로그를 SQL 쿼리 ▸ (E) QuickSight로 결과 대시보드 표시 【오답 체크】 (A) CloudWatch Logs Insights는 S3 서버 액세스 로그의 표준 분석 경로가 아니며 SQL 대시보드 요건과 맞지 않음. (C) CloudWatch Logs는 S3 객체 접근 상세 로그 소스가 아님. (D) GuardDuty는 위협 탐지로 접근 패턴 대시보드 목적이 아님. 【시험 포인트】 S3 접근 패턴 SQL 대시보드 → 서버 액세스 로그 + Athena + QuickSight.

해설

【핵심 용어】 ▸ Cognito Pre Sign-up Lambda 트리거 — 가입 요청을 커스텀 검증해 수락/거부 ▸ AWS WAF Geo Match — 지리 기반 요청 필터(프랑스 외 차단), Cognito 사용자 풀에 web ACL 연결 ▸ Hosted UI 사기 가입 대응 — 지역/커스텀 검증 결합 【정답 포인트】 ▸ (A) pre sign-up Lambda 트리거를 사용자 풀에 연결해 가입 시 커스텀 검증으로 수락/거부 ▸ (B) 지리 매치 규칙의 WAF web ACL을 Cognito 사용자 풀에 연결해 프랑스 외 요청 차단 【오답 체크】 (C) 앱 클라이언트 ID 검증은 사기 가입의 지역·커스텀 검증 요건을 충족하지 못함. (D) Cognito 사용자 풀에는 "지리 제한" 설정이 없음(WAF로 처리). (E) 소셜 IdP 구성은 사기 가입 차단·커스텀 검증과 무관. 【시험 포인트】 Cognito 가입 커스텀 검증 → pre sign-up Lambda + WAF geo match(사용자 풀 연결).

해설

【핵심 용어】 ▸ 업무 분리(Separation of Duties) — 버킷 접근(운영팀)과 암호화 키(보안팀) 통제를 분리 ▸ SSE-KMS 고객 관리 키 — 데이터 접근에 버킷 권한 + KMS 키 정책 둘 다 필요 ▸ Key Policy — 보안팀이 키 사용 권한을 독립 통제 【정답 포인트】 ▸ "한 팀의 설정 오류만으로 평문 데이터 노출 방지" → 운영팀은 버킷 정책으로 고객 관리 SSE-KMS 사용 강제, 보안팀은 키 정책으로 키 접근 통제 → 양쪽 승인 필요라 단일 팀 실수로 노출 불가 【오답 체크】 (A) SSE-S3는 KMS 키 정책 계층이 없어 IAM 정책만으로는 진정한 업무 분리·이중 통제가 안 됨. (C) SSE-S3 + IAM 정책도 KMS 키 정책 기반 분리 통제가 없어 요건 미달. (D) SSE-C 키를 KMS에 저장한다는 구성은 개념 오류(SSE-C는 클라이언트 제공 키). 【시험 포인트】 버킷 vs 키 업무 분리 → SSE-KMS(CMK) + 버킷 정책(운영) + 키 정책(보안) 이중 통제.

해설

【핵심 용어】 ▸ KMS Key Policy — kms:Decrypt를 특정 서비스(S3/DynamoDB/Lambda/EKS)만 허용해 최소권한 ▸ AWS Config 규칙 — 키로 암호화되지 않은 리소스 탐지·알림 ▸ ViaService 조건 — 지정 서비스 경유 복호화만 허용 【정답 포인트】 ▸ "모든 데이터 저장 시 암호화 + 최소권한 접근" → 키 정책에서 kms:Decrypt를 S3·DynamoDB·Lambda·EKS로만 허용(데이터 접근 경로 전체 포함)하고, Config 규칙으로 키 미암호화 리소스 알림 【오답 체크】 (A) Decrypt 허용을 S3/DynamoDB만으로 제한하면 Lambda/EKS의 읽기 경로가 막혀 애플리케이션이 데이터 접근 불가. (B) 모든 역할에 Decrypt Deny를 자동 부착하는 방식은 정상 접근까지 차단·운영 부담 큼. (C) SCP로 미암호화 S3/DynamoDB 생성을 막는 방향은 맞지만, 이 문제의 정답 구성은 Config 규칙 알림 기반(SCP 대신). 【시험 포인트】 최소권한 KMS 접근 → 키 정책에 데이터 접근 서비스만 Decrypt 허용 + Config 규칙 준수 모니터링.

해설

【핵심 용어】 ▸ CloudFront 관리형 응답 헤더 정책 SecurityHeadersPolicy — HSTS 등 보안 헤더를 코드 없이 자동 추가 ▸ 중간자 공격(MITM) 방어 — Strict-Transport-Security(HSTS) 등 보안 헤더로 HTTPS 강제 ▸ 관리형 정책 — 운영 오버헤드 최소 【정답 포인트】 ▸ "CloudFront로 MITM 방어 + 최소 오버헤드" → 관리형 SecurityHeadersPolicy 응답 헤더 정책을 적용하면 HSTS 등 보안 헤더가 자동 부여되어 코드/커스텀 구성 없이 방어 【오답 체크】 (A) SimpleCORS는 CORS 헤더용으로 MITM(HSTS) 방어와 무관. (B) Lambda@Edge로 HSTS를 직접 추가하면 동작하나 관리형 정책 대비 운영 오버헤드가 큼. (D) X-XSS-Protection 커스텀 헤더는 XSS 관련이며 MITM 방어의 핵심(HSTS)이 아님. 【시험 포인트】 CloudFront MITM(HSTS) 방어 최소 오버헤드 → 관리형 SecurityHeadersPolicy.

해설

【핵심 용어】 ▸ iam:PassRole — 서비스/함수가 다른 리소스(EC2 등)에 IAM 역할을 넘겨줄 때 필요한 권한, 위임 주체가 반드시 보유해야 함 ▸ IAM instance profile — EC2에 IAM 역할을 부착하는 컨테이너, EC2 실행 시 지정 ▸ Lambda execution role — Lambda가 AWS API를 호출할 때 사용하는 역할 【정답 포인트】 ▸ Lambda가 "IAM 역할을 가진 EC2 인스턴스를 프로비저닝" → EC2에 역할(instance profile)을 전달하는 동작 발생 ▸ 다른 리소스에 역할을 넘기려면 호출 주체(Lambda 실행 역할)에 iam:PassRole 권한 필수 → 누락 시 access denied 【오답 체크】 (A) KMS 암호화 AMI라도 CreateGrant/Decrypt 누락은 인스턴스 시작 시점의 KMS 오류이지, 역할 전달 access denied의 가장 유력한 원인이 아님. (C) 서비스 쿼터 초과는 access denied가 아니라 별도의 한도 초과 오류 메시지가 반환됨. (D) CloudWatch 에이전트 권한은 EC2 인스턴스 역할 문제이며 Lambda 실행 역할의 프로비저닝 실패와 무관. 【시험 포인트】 서비스/함수가 EC2·리소스에 IAM 역할을 부여할 때 access denied → 호출 주체의 iam:PassRole 권한부터 확인.

해설

【핵심 용어】 ▸ CloudWatch 에이전트 로그 전송 — EC2 인스턴스 역할에 logs:CreateLogStream, logs:PutLogEvents 권한 필요 ▸ 인라인 정책 vs 관리형 정책 — 인라인은 특정 주체에만 붙는 1:1 정책, 관리형은 여러 주체에 공유 ▸ SCP / VPC 엔드포인트 정책 — 계정·엔드포인트 단위로 적용되어 여러 역할에 동시 영향 【정답 포인트】 ▸ frontend-instance-role만 전송 중단, backend는 정상 → 두 역할 공통 요소가 아닌 frontend 전용 요소가 원인 ▸ 오직 frontend 역할에만 붙은 인라인 정책에서 logs:PutLogEvents allow가 제거됨 → 딱 그 역할만 영향받는 정황과 일치 【오답 체크】 (B) SCP를 계정에 적용하면 backend 인스턴스 로그도 함께 끊겨야 함 → 정황 불일치. (C) VPC 엔드포인트 정책 변경도 같은 엔드포인트를 쓰는 backend까지 영향 → 불일치. (D) 두 역할 모두에 붙은 관리형 정책을 수정하면 backend 로그도 중단되어야 함 → 불일치. 【시험 포인트】 "한쪽 역할만 영향" 정황 → 그 역할에만 적용되는 인라인 정책을 의심. 계정/공유 리소스 단위 변경은 전부에 영향.

해설

【핵심 용어】 ▸ DynamoDB Encryption Client — 항목을 클라이언트 측에서 암호화하고 서명(sign)하는 라이브러리, DynamoDB 항목 구조에 특화 ▸ 클라이언트 측 암호화 — 데이터가 클라이언트를 떠나기 전 암호화 → 종단 간(end-to-end) 보호 ▸ 항목 서명(signing) — 저장 후 무단 변경 탐지, 무결성 검증 【정답 포인트】 ▸ "종단 간 데이터 보호" → 클라이언트 측 암호화로 DynamoDB 도달 전부터 보호 ▸ "무단 데이터 변경 탐지" → 항목 서명으로 변조 감지 → DynamoDB Encryption Client가 두 요건 모두 충족 【오답 체크】 (A) KMS 저장 시 암호화는 at-rest만 보호, 종단 간·변경 탐지 요건 미충족. (B) Private CA로 전송 중 암호화만 다룸, 무결성/변경 탐지 없음. (D) AWS Encryption SDK는 범용 암호화·서명이 가능하나 DynamoDB 항목 구조에 최적화된 것은 DynamoDB Encryption Client → 이 시나리오의 표준 솔루션. 【시험 포인트】 DynamoDB + 종단 간 보호 + 항목 변경 탐지 → DynamoDB Encryption Client(클라이언트 암호화 + 서명).

해설

【핵심 용어】 ▸ CloudWatch Logs 게시 권한 — EC2 인스턴스 역할의 IAM 정책에 로그 게시용 API 액션이 있어야 함 ▸ 커스텀 지표 vs 로그 — 기존 정책은 PutMetricData(지표)만 허용, 로그 게시 액션은 별도 ▸ 인스턴스 역할(IAM role) — CloudWatch 에이전트가 API 호출 시 사용하는 자격 증명 【정답 포인트】 ▸ 에이전트 정상 동작·네트워크 통신 정상 확인됨 → 남은 원인은 IAM 권한 ▸ 현재 정책은 커스텀 지표 게시 권한만 보유 → 로그를 게시하는 데 필요한 CloudWatch(Logs) API 액션을 역할의 IAM 정책에 추가해야 함 【오답 체크】 (B) Auto Scaling 서비스 연결 역할은 인스턴스 시작 관리용이지 애플리케이션 로그 게시 권한과 무관. (C) 로그 게시에 필요한 액션 추가라는 방향은 유사하나, 이 문제에서 권한 부여 대상으로 채택된 보기는 A → C는 동일 취지의 함정 변형. (D) NAT 게이트웨이로 인터넷·AWS 통신이 이미 정상이라 인터페이스 엔드포인트 추가는 불필요. 【시험 포인트】 "에이전트·네트워크 정상인데 로그만 안 올라감" → 인스턴스 역할의 IAM 정책에 로그 게시 권한 추가.

해설

【핵심 용어】 ▸ KMS 가져온 키 재료(imported key material) — 외부에서 가져온 키 재료, 삭제 시 키가 사용 불가 상태가 됨 ▸ 키 재료 재가져오기(reimport) — 원본과 동일한 키 재료를 다시 가져오면 키가 복구되어 기존 암호문 복호화 가능 ▸ EBS 암호화 데이터 키 — 볼륨 데이터 키가 CMK로 래핑됨, CMK 사용 불가 시 볼륨 접속 실패 【정답 포인트】 ▸ 데이터를 살려야 함 → 기존 EBS 데이터 키를 복호화할 수 있는 것은 원래 키 재료뿐 ▸ 삭제된 것과 동일한 키 재료를 재가져오기 → 키가 다시 활성화되고 기존 데이터 키 복호화 및 볼륨 연결 가능 【오답 체크】 (A) 새 키 재료를 가져오면 기존 암호문을 복호화할 수 없어 데이터 손실. (B) 이전 스냅샷 복원은 삭제 시점 이후 데이터를 잃고, "해당 볼륨 데이터" 요구와 불일치. (D) 새 키 + 새 키 재료는 기존 데이터 키를 복호화하지 못해 요건 미충족. 【시험 포인트】 가져온 키 재료 삭제로 데이터 접근 불가 → 동일 키 재료 재가져오기만이 복호화 가능(새 재료는 절대 안 됨).

해설

【핵심 용어】 ▸ AWS Control Tower — 멀티 계정 거버넌스 자동화, 신규 계정 자동 등록 및 가드레일(예방/탐지) 적용 ▸ 가드레일 — Config 설정 변경 금지 같은 정책을 기존·신규 계정에 자동 강제 ▸ 중앙 대시보드 — 조직 전체 계정의 규정 준수 상태를 한 곳에서 조회 【정답 포인트】 ▸ "신규 계정 생성 시 자동으로 정책 적용 + 1,000개 이상 확장" → 계정 자동 등록·거버넌스 자동화가 필요 → Control Tower ▸ "중앙 집중식 규정 준수 뷰" → Control Tower 대시보드가 조직 전체 준수 상태 제공 【오답 체크】 (A) Config 신뢰 액세스만으로는 신규 계정 자동 강제·중앙 뷰 요건 미충족. (C) 각 계정을 수동 검토하는 방식은 1,000개 확장·자동화 요건과 정반대. (D) 루트에 Config API 전면 거부 SCP를 걸면 Config 자체를 못 써서 준수 뷰도 불가. 【시험 포인트】 대규모 신규 계정 자동 거버넌스 + 중앙 준수 뷰 → AWS Control Tower.

해설

【핵심 용어】 ▸ KMS 키 재료 가져오기(import) — 온프레미스 HSM에서 생성한 키 재료를 KMS 고객 관리형 키(customer managed key)로 가져와 사용 ▸ 고객 관리형 키 vs AWS 관리형 키 — 키 재료 가져오기는 고객 관리형 키에서만 가능, AWS 관리형 키는 불가 ▸ DynamoDB 저장 시 암호화 — 테이블 생성 시 KMS 키 지정, 서비스가 키 사용 권한 필요 【정답 포인트】 ▸ "온프레미스 HSM 키 재료 사용" → 키 재료 가져오기가 가능한 고객 관리형 키를 생성해 가져와야 함 ▸ DynamoDB가 그 키로 암호화하려면 서비스에 키 사용 권한 부여 + 테이블 생성 시 해당 키를 암호화 키로 선택 【오답 체크】 (B) 테이블 생성 후 KMS 키를 비활성화하면 암호화/복호화 자체가 불가 → 데이터 접근 불가. (C) AWS 관리형 키는 키 재료 가져오기가 불가능 → HSM 키 사용 요건 위배. (D) AWS 관리형 키 가져오기 불가 + 키 비활성화까지 겹쳐 이중으로 부적합. 【시험 포인트】 외부 HSM에서 만든 키 재료를 쓰려면 → 고객 관리형 키 + 키 재료 가져오기(AWS 관리형 키는 가져오기 불가).