정답 · 해설

해설

【핵심 용어】 ▸ alias — 애플리케이션이 키를 참조하는 별칭, 뒤의 키를 바꿔도 앱 변경 불필요 ▸ 자동 키 회전 — 연 1회, 앱 관점에서 투명 【정답 포인트】 ▸ 앱 변경 없이 연간 회전 → 애플리케이션이 alias로 참조하도록 구성 ▸ 키에 연간 회전을 설정하고 alias가 이를 가리키게 함 【오답 체크】 (B)(D) 애플리케이션 라이브러리가 새 key ID를 쓰도록 "코드 변경"을 요구 → "앱 변경 없이" 요건 위반 【시험 포인트】 ▸ 앱 변경 없는 키 회전 = alias 참조 + 자동 회전(코드에 key ID 하드코딩 금지)

해설

【핵심 용어】 ▸ 동일 계정 접근 = IAM(자격증명) 정책 ∪ 리소스(버킷) 정책의 합집합 ▸ 명시적 Deny가 없으면 어느 한쪽이 Allow면 접근 허용 【정답 포인트】 ▸ alice의 IAM 정책이 두 버킷 접근을 허용(+ bucket1 정책도 허용) ▸ 명시적 deny가 없으므로 both(두 버킷 모두) 접근 가능 【오답 체크】 (A)(B) 한쪽만 접근으로 제한할 근거 없음 (D) IAM 정책 허용이 있으므로 접근 불가가 아님 【시험 포인트】 ▸ 동일 계정 = IAM 또는 버킷 정책 중 하나만 Allow해도 접근(명시 Deny 우선)

해설

【핵심 용어】 ▸ CloudTrail log file integrity validation — 해시로 로그 변조 탐지 ▸ SSE-KMS — 저장 시 암호화 / 최소권한 버킷 정책 — 무단 접근 차단 【정답 포인트】 ▸ (A) SSE-KMS 암호화, (D) 최소권한 버킷 정책, (E) 로그 파일 무결성 검증 ▸ 무단 접근과 변조를 함께 방지 【오답 체크】 (B) gzip 압축은 보안 수단이 아님 (C) 수정 알림은 탐지이지 예방이 약함(핵심 3개엔 무결성 검증 우선) (F) Access Analyzer는 보조적 【시험 포인트】 ▸ CloudTrail 변조 방지 = 무결성 검증 + SSE-KMS + 최소권한

해설

【핵심 용어】 ▸ Systems Manager Parameter Store — 자격증명 저장, 표준 파라미터는 무료(저비용) ▸ Secrets Manager — 회전 내장이나 시크릿당 과금 【정답 포인트】 ▸ 회전·감사·서드파티 연동은 기존 pw 시스템이 담당 → AWS는 저장만 필요 ▸ Parameter Store 통합이 5,000개 자격증명 저장에 최저 비용 【오답 체크】 (B) Secrets Manager는 시크릿당 비용↑ (C) S3 저장은 비표준·관리 어려움 (D) CloudHSM은 고비용 【시험 포인트】 ▸ 회전은 외부 시스템, 최저비용 저장 = Parameter Store

해설

【핵심 용어】 ▸ CloudFront origin custom header — CloudFront만 보내는 비밀 헤더로 origin 직접 접근 차단 ▸ viewer/origin protocol policy — 뷰어·오리진 구간 프로토콜 강제 【정답 포인트】 ▸ custom header 추가, viewer는 HTTP→HTTPS 리다이렉트, origin protocol HTTPS only ▸ 앱이 custom header 검증 → CloudFront 경유만 허용 + 전 구간 HTTPS(가장 안전) 【오답 체크】 (A) viewer "HTTP and HTTPS" 허용 = 평문 허용 (B) origin "match viewer"는 뷰어가 HTTP면 오리진도 평문 위험 (C) origin protocol "HTTP only"는 오리진 구간이 평문 【시험 포인트】 ▸ CloudFront 전용 + 전구간 HTTPS = custom header + redirect-to-HTTPS + origin HTTPS only + 앱 검증

해설

【핵심 용어】 ▸ Network ACL — stateless, 서브넷 레벨, 기존(활성) 연결까지 즉시 차단 ▸ Security group — stateful, 기존 established 연결엔 즉시 반영 안 됨 【정답 포인트】 ▸ 인바운드/아웃바운드 Deny인 새 NACL을 인스턴스 서브넷에 연결 ▸ 활성 연결 포함 즉시 격리(인스턴스는 실행 유지, 해당 서브넷의 유일 리소스) 【오답 체크】 (A)(B) SG는 stateful → 기존 established 연결이 유지되어 즉시 차단 아님 (D) 새 VPC/AMI 방식은 즉시성·실행 유지 위배 【시험 포인트】 ▸ "즉시" 격리(기존 연결 포함) = NACL Deny (SG는 기존 연결 유지)

해설

【핵심 용어】 ▸ Security group — 허용 규칙만 존재(암묵적 전체 deny), deny 규칙 없음 ▸ ALB의 인바운드 SG가 실질적으로 수신 포트를 제어 【정답 포인트】 ▸ 443만 허용하는 단일 인바운드 규칙 SG를 ALB의 유일한 SG로 설정 ▸ 실수로 HTTP(80) 리스너를 켜도 SG에 80 허용이 없어 차단됨 【오답 체크】 (A) SG는 deny 규칙이 없음 (B)(C) NACL은 인터넷 게이트웨이에 연결 불가(서브넷에 연결) 【시험 포인트】 ▸ SG는 allow-only(암묵 deny) → 443만 허용 SG가 80 차단, NACL은 IGW에 못 붙임

해설

【핵심 용어】 ▸ 교차계정 IAM role — 신뢰 정책 principal에 상대 계정 지정, 상대가 AssumeRole(임시 자격증명) ▸ 신뢰 정책에 aws:MultiFactorAuthPresent로 MFA 강제 【정답 포인트】 ▸ 회사(프로덕션) 계정에 role 생성, 신뢰 정책 principal = 컨설턴트 계정 + MFA 요구 ▸ 컨설턴트가 자기 계정에서 MFA로 assume → 장기 자격증명 불필요 【오답 체크】 (A) 컨설턴트별 IAM user는 장기 자격증명(금지) (B) Cognito는 앱 사용자 인증용 (C) role을 컨설턴트 계정에 만들면 회사 리소스 접근 불가(방향 반대) 【시험 포인트】 ▸ 교차계정 + MFA + 장기자격증명 금지 = 리소스 소유 계정 role + 신뢰정책(principal=상대, MFA 조건)

해설

【핵심 용어】 ▸ AWS Systems Manager — Inventory/Run Command로 인스턴스에 설치된 소프트웨어·버전 조회 ▸ 특정 버전의 프레임워크 식별에 적합 【정답 포인트】 ▸ SSM으로 전 EC2 인스턴스를 스캔 → 취약 버전 웹 프레임워크가 설치된 인스턴스 식별 【오답 체크】 (A) Config/CloudTrail은 소프트웨어 버전 인벤토리가 아님 (B) Inspector Network Reachability는 포트/도달성이지 설치 버전이 아님 (D) RAM은 리소스 공유 서비스 【시험 포인트】 ▸ 인스턴스 설치 소프트웨어/버전 식별 = Systems Manager(Inventory)

해설

【핵심 용어】 ▸ 교차계정 role 사용 = 사용자에게 sts:AssumeRole(대상 role ARN) 허용 정책 필요 ▸ role측 신뢰 정책과 사용자측 권한 정책이 양방향으로 필요 【정답 포인트】 ▸ 각 사업부 계정의 IAM user에 "top-level 계정 role assume 허용" 정책(role ARN 지정) attach ▸ 이를 통해 자기 사업부 로그를 읽음 【오답 체크】 (B) SCP는 권한 부여가 아니라 경계 (C) root로 assume는 금지·부적절 (D) 자격증명 전달(공유)은 보안 위반 【시험 포인트】 ▸ 교차계정 role 사용 = 사용자 정책에 sts:AssumeRole + role ARN

해설

【핵심 용어】 ▸ AWS Config recorder는 서비스 role로 리소스 구성을 기록·전달 ▸ role에 AWSConfigRole 관리형 정책 필요, S3 기록엔 버킷 정책 허용 필요 【정답 포인트】 ▸ (B) 버킷 정책이 AWS Config의 기록을 허용하도록 구성 ▸ (E) AWS Config role에 AWSConfigRole 관리형 정책 부여 → 정상 기록·전달(SNS 알림 발생) 【오답 체크】 (A) S3 ACL은 해당 사안 아님 (C) AmazonS3ReadOnlyAccess를 IAM user에 붙이는 것은 무관 (D) 엔지니어 IAM 권한은 Config 동작과 무관 【시험 포인트】 ▸ Config 미동작 = 서비스 role(AWSConfigRole) + 리소스 접근(버킷 정책) 확인

해설

【핵심 용어】 ▸ KMS imported key material — 사용자가 키 자료 반입, DeleteImportedKeyMaterial로 즉시 삭제 ▸ 즉시 암호화 소거(crypto-shredding) 가능 / 일반 CMK 삭제는 7~30일 대기 【정답 포인트】 ▸ imported key material 사용 → 필요 시 키 자료 즉시 삭제로 15분 이내 암호화 소거 【오답 체크】 (B)(C)(D) 일반 KMS CMK(관리형/고객관리)는 삭제 대기기간이 있어 즉시 소거 불가 【시험 포인트】 ▸ 즉시 암호화 소거(빠른 키 파기) = imported key material

해설

【핵심 용어】 ▸ Network ACL — Deny 규칙 지원(stateless), 특정 소스 IP + 포트만 차단 가능 ▸ Security group — deny 불가, 포트 제거 시 모든 사용자 차단 【정답 포인트】 ▸ 인스턴스 서브넷 NACL에 해당 포트 + 소스 IP Deny 추가 ▸ 그 외부 소스만 차단, 다른 사용자에겐 애플리케이션 계속 제공 【오답 체크】 (B) SG에서 포트 제거는 모든 사용자 차단 (C) SG에는 Deny 규칙이 없음 (D) 전체 트래픽 차단은 가용성 위배 【시험 포인트】 ▸ 특정 소스만 차단(나머지 유지) = NACL Deny (SG는 deny 불가)

해설

【핵심 용어】 ▸ EventBridge — CloudTrail의 ConsoleLogin 이벤트를 실시간 규칙으로 감지 → SNS 즉시 알림 【정답 포인트】 ▸ EventBridge로 콘솔 로그인(특히 root) 이벤트를 감지해 SNS 알림 ▸ 실시간이라 "가능한 빨리" 요건 충족 【오답 체크】 (A) Lambda 주기 폴링은 지연 발생 (C) Athena는 배치 쿼리(실시간 아님), Identity Center 로그는 root가 아님 (D) RAM은 무관 【시험 포인트】 ▸ root 로그인 즉시 알림 = EventBridge(ConsoleLogin) → SNS

해설

【핵심 용어】 ▸ CloudTrail StopLogging 이벤트 = 로깅이 비활성화된 시점 ▸ 이를 트리거로 Lambda가 StartLogging API를 호출해 재활성화 【정답 포인트】 ▸ StopLogging 이벤트에 반응 → Lambda로 StartLogging 호출 → 꺼지면 자동 재개 【오답 체크】 (A) Config 리메디에이션도 가능하나 이벤트 기반 재개가 직접적 (B) StartLogging 이벤트 감지는 "켜질 때" 반응이라 목적과 반대 (D) Trusted Advisor는 모니터링일 뿐 자동 재개가 아님 【시험 포인트】 ▸ CloudTrail 자동 재활성화 = StopLogging 이벤트 감지 → StartLogging 호출

해설

【핵심 용어】 ▸ KMS import key material — customer managed CMK(origin=EXTERNAL) + 기본 key store 사용 ▸ custom key store는 CloudHSM 연동 용도 / AWS managed CMK는 자료 반입 불가 【정답 포인트】 ▸ 기본 key store + customer managed CMK(키 자료 없음) 생성 후 자사 키 자료 import ▸ 만료일 설정·즉시 삭제 가능 요건 충족 【오답 체크】 (A)(D) custom key store는 CloudHSM용(import 시나리오가 아님) (B)(D) AWS managed CMK는 키 자료 import 불가 【시험 포인트】 ▸ 자체 키 자료 반입 = 기본 key store + customer managed CMK(EXTERNAL)

해설

【핵심 용어】 ▸ RDS 암호화는 생성 시에만 설정, 기존 인스턴스 in-place 활성화 불가 ▸ 스냅샷 → 암호화 복사 → 복원으로 마이그레이션 + CMK 지정 【정답 포인트】 ▸ (A) 스냅샷 생성 후 암호화를 켜서 복사 → 그 복사본으로 인스턴스 복원 ▸ (D) 새 CMK를 암호화 키로 사용 → 기존 + 신규 데이터 암호화 【오답 체크】 (B) 기존 인스턴스에 암호화 활성화 불가 (C) aws/rds 기본키도 가능하나 감사·제어는 CMK가 우수(문제는 D 선택) (E) 기존 스냅샷에 직접 암호화 활성화 불가(복사 시에만 가능) 【시험 포인트】 ▸ 기존 RDS 암호화 = 스냅샷 복사 시 암호화 + CMK → 복원

해설

【핵심 용어】 ▸ 리전 제한 SCP = aws:RequestedRegion 조건으로 eu-west-1 외 Deny ▸ 글로벌 서비스(IAM, CloudFront, Route 53 등)는 NotAction으로 예외 처리 【정답 포인트】 ▸ eu-west-1 외 리전의 액션을 Deny하되 글로벌 서비스는 예외로 두는 SCP ▸ OU에 적용해 기존·신규 계정 모두에 리전 제한 적용 【오답 체크】 (그 외) 글로벌 서비스 예외를 누락하거나 조건/구문이 부정확 → 리전 강제 실패 또는 글로벌 서비스까지 차단 【시험 포인트】 ▸ 리전 강제 = aws:RequestedRegion Deny + 글로벌 서비스 NotAction 예외

해설

【핵심 용어】 ▸ WAF rate-based rule — IP별 요청률 초과 시 자동 차단, IP가 바뀌어도 대응(수작업 최소) ▸ ALB/CloudFront에 연결 【정답 포인트】 ▸ WAF rate-based rule을 ALB에 연결 → 소수·가변 IP의 DoS를 자동 차단 ▸ 지속적 관리 노력 최소 【오답 체크】 (B) SG로 IP 차단은 IP가 바뀔 때마다 수동 (C) NACL도 수동·서브넷 레벨 (D) WAF는 SG가 아니라 ALB/CloudFront에 연결 【시험 포인트】 ▸ 가변 IP DoS 자동 차단 = WAF rate-based rule(ALB)

해설

【핵심 용어】 ▸ NACL은 stateless → 아웃바운드 443의 응답은 인바운드 ephemeral 포트(1024-65535)로 수신 ▸ 응답 트래픽을 위해 인바운드 ephemeral 허용이 별도로 필요 【정답 포인트】 ▸ (B) 인바운드 3306 Deny + 인바운드 ephemeral(1024-65535) 허용 + 아웃바운드 443 허용 ▸ MySQL(3306) 인바운드 차단 + TLS(443) 아웃바운드 및 그 응답 수신 가능 【오답 체크】 (A) 인바운드 443 허용은 요구와 무관, ephemeral 응답 허용 없음 (C) 인바운드 ephemeral만으론 규칙 순서·3306 deny 구성 부적절 (D) ephemeral 응답 허용 누락 → 아웃바운드 443 응답 수신 실패 【시험 포인트】 ▸ NACL stateless → 아웃바운드 허용 시 인바운드 ephemeral(1024-65535)도 허용해야 응답 수신