정답 · 해설

해설

【핵심 용어】 ▸ KMS 키 정책(key policy) — 키에 대한 최상위 권한 소스, 특정 주체에 직접 권한 부여 가능 ▸ IAM 정책 위임 — 키 정책에 "Enable IAM policies"(Principal: 계정 루트, kms:* 허용) 문이 있어야 IAM 정책으로 접근 가능 ▸ [이미지] 키 정책·IAM 정책 세부 내용은 이미지로 제시됨 【정답 포인트】 ▸ EC2RoleA는 IAM 정책이 없지만 키 정책에서 직접 접근이 부여됨 → EC2A는 사용 가능 ▸ EC2RoleB는 IAM 정책이 있으나, 키 정책이 IAM 정책 위임(계정 루트 허용)을 열어두지 않으면 IAM 정책만으로는 접근 불가 → EC2B는 사용 불가 【오답 체크】 (A) 둘 다 가능은 EC2B의 IAM 정책이 키 정책 위임 없이는 무효라는 점을 놓침. (B) 둘 다 불가는 키 정책이 EC2RoleA에 직접 부여한 점을 무시. (C) 관계가 반대 → EC2A(키 정책 직접 부여)가 가능한 쪽. 【시험 포인트】 KMS 접근은 키 정책이 관문. 키 정책에 직접 명시된 주체는 IAM 정책 없이도 가능, IAM 정책만 있는 주체는 키 정책이 위임을 열어야 유효.

해설

【핵심 용어】 ▸ Amazon GuardDuty — 지속적 위협 탐지 서비스, 조직 단위 배포 및 신규 계정 자동 등록 지원 ▸ 위임 관리자(delegated administrator) — 보안 계정을 지정해 조직 전체 GuardDuty를 중앙 관리, 모범 사례 ▸ 자동 등록(auto-enable) — 신규 멤버 계정을 자동으로 분석 대상에 포함 【정답 포인트】 ▸ "지속적 위협 탐지 + 신규 계정 자동 분석" → GuardDuty가 정확히 부합 ▸ "보안 계정에서 findings 검토" + 모범 사례 → 관리 계정이 아닌 보안 계정을 위임 관리자로 지정(GuardDuty 활성화 후 콘솔에서 지정) 【오답 체크】 (B) 관리 계정을 관리자로 지정하는 것은 모범 사례에 어긋남(전용 보안 계정 위임이 권장). (C) Security Hub는 위협 탐지 서비스가 아니라 findings 집계·표준 준수 서비스 → 요건 불일치. (D) Control Tower는 거버넌스 도구로 위협 탐지 서비스가 아님. 【시험 포인트】 조직 전체 위협 탐지 + 최소 노력 + 모범 사례 → GuardDuty를 켜고 보안 계정을 위임 관리자로.

해설

【핵심 용어】 ▸ CloudFront 서명된 URL(signed URL) — 커스텀 도메인(example.com)으로 배포되는 콘텐츠에 시간 제한·조건부 접근 제어 ▸ S3 presigned URL — S3 버킷 도메인 기반, 커스텀 도메인 요구를 직접 충족하지 못함 ▸ 오리진 액세스 제어 — CloudFront가 S3 앞단에서 접근을 중개 【정답 포인트】 ▸ "커스텀 도메인 example.com에서 다운로드" + "권한 검증 후 접근 허용" → CloudFront 서명된 URL이 커스텀 도메인과 세분화된 접근 제어를 동시 제공 ▸ 애플리케이션이 회원 검증 후 서명된 URL 발급 → 가장 안전한 방식 【오답 체크】 (A) 버킷 ACL 읽기 허용 후 시간 뒤 제거는 수동적·비정밀하며 커스텀 도메인 요건 미충족. (B) IAM 정책으로 사용자에게 읽기 권한 부여는 최종 사용자(외부)에게 부적합하고 도메인 요건 미충족. (C) S3 presigned URL은 S3 도메인 기반이라 example.com 커스텀 도메인 요구를 충족하지 못함. 【시험 포인트】 커스텀 도메인 + 조건부/시간 제한 접근 → CloudFront 서명된 URL. S3 도메인만 필요하면 presigned URL.

해설

【핵심 용어】 ▸ Amazon Inspector — EC2·ECR 컨테이너의 소프트웨어 취약점 및 의도치 않은 네트워크 노출 자동 스캔, Security Hub 연동 ▸ 위임 관리자(delegated administrator) — 조직 전체 Inspector 중앙 관리, 신규 계정 자동 활성화 지원 ▸ SSM Agent — Inspector가 EC2 취약점 평가에 활용 【정답 포인트】 ▸ "소프트웨어 취약점 + 네트워크 노출" → Amazon Inspector의 핵심 기능과 정확히 일치 ▸ "신규 계정 포함 자동 배포 + 신규 워크로드 자동 스캔" → 위임 관리자 지정 후 신규 멤버 계정 자동 스캔 활성화 【오답 체크】 (A) SCP는 권한 경계 제어용이지 취약점 스캔을 구성하지 못함. (B) GuardDuty는 위협 탐지이며 소프트웨어 취약점 스캔이 주 기능이 아님. EventBridge 수동 트리거도 자동 배포 요건과 거리 있음. (D) Inspector는 ECR 스캔을 자체 자동화하므로 Config 규칙으로 별도 트리거할 필요 없음(자동 스캔 설정이 정답). 【시험 포인트】 EC2·ECR 취약점 + 네트워크 노출 + 조직 자동 스캔 → Amazon Inspector 위임 관리자 + 자동 스캔.

해설

【핵심 용어】 ▸ 액세스 키 로테이션 — 새 키 생성 → 애플리케이션 갱신 → 기존 키 비활성화 순으로 무중단 교체 ▸ 비활성화(deactivate) vs 삭제(delete) — 비활성화는 필요 시 롤백 가능, 즉시 삭제는 되돌릴 수 없음 ▸ 레거시 애플리케이션 — IAM 사용자 액세스 키에 의존, 가동 중단 최소화 필요 【정답 포인트】 ▸ "최소 다운타임" → 먼저 새 키를 만들어 애플리케이션에 적용한 뒤, 검증되면 손상된 키를 비활성화 → 서비스 끊김 없이 교체 【오답 체크】 (A) 손상된 키를 즉시 삭제하면 새 키 적용 전까지 애플리케이션이 중단됨. (C) 세션 취소 정책은 임시 자격 증명(역할 세션)에 적용되며 장기 액세스 키 무효화에는 부적합. (D) IAM 역할 전환은 바람직한 최종 상태지만 즉각적 침해 대응·최소 다운타임 요구엔 재작업 부담이 큼. 【시험 포인트】 손상된 키 + 무중단 → 새 키 생성 → 앱 갱신 → 구 키 비활성화. "먼저 삭제"는 항상 오답.

해설

【핵심 용어】 ▸ KMS 키의 리전 종속성 — CMK는 생성된 리전에서만 유효, 다른 리전에서 직접 사용 불가 ▸ 암호화 스냅샷 교차 리전 복사 — 대상 리전의 KMS 키로 재암호화 필요 ▸ 키 정책 principal — arn으로 임의 리전/서비스를 principal로 지정할 수 없음 【정답 포인트】 ▸ us-east-1 CMK는 us-west-1에서 접근 불가 → us-west-1에 새 고객 관리형 키를 만들어 그 키로 대상 스냅샷을 암호화 【오답 체크】 (A) Secrets Manager는 비밀 저장용이지 KMS 키를 저장·이전하는 용도가 아님, 스냅샷 암호화 키로 쓸 수 없음. (C) 리전 ARN을 principal로 지정하는 방식이 잘못됨(리전을 principal로 삼을 수 없고 키의 리전 종속성 미해결). (D) rds 리전 ARN을 principal로 지정하는 방식도 유효한 IAM/키 정책 구조가 아님. 【시험 포인트】 암호화 스냅샷을 다른 리전으로 복사 → 대상 리전에 새 KMS 키를 만들어 복사 시 재암호화. 키는 리전을 넘지 못함.

해설

【핵심 용어】 ▸ Secure String 파라미터 — Parameter Store에서 KMS로 암호화되는 값, 업데이트 시 kms:Encrypt 필요 ▸ 고객 관리형 키 상태 — Disabled 상태면 암호화/복호화 작업 실패 ▸ Standard tier — 고객 관리형 키 사용 가능(기본 지원) 【정답 포인트】 ▸ (A) 애플리케이션이 kms:Encrypt 권한이 없으면 secure string 값을 암호화(업데이트)할 수 없어 오류 ▸ (D) 지정된 고객 관리형 키가 Disabled 상태면 KMS 작업이 실패 → 두 요인 모두 업데이트 오류의 원인 【오답 체크】 (B) 하나의 KMS 키를 여러 파라미터가 공유해도 문제되지 않음 → 오류 원인 아님. (C) Standard tier도 고객 관리형 키를 사용할 수 있음 → 사실과 다름. (E) 키 별칭(alias) 사용은 정상적으로 지원됨 → 오류 원인 아님. 【시험 포인트】 Secure String 업데이트 오류 → kms:Encrypt 권한 누락 또는 KMS 키 Disabled 상태부터 확인.

해설

【핵심 용어】 ▸ AWS Systems Manager Session Manager — 인바운드 포트·배스천·SSH 키 없이 EC2 접속, 모범 사례 원격 접근 ▸ 세션 로그 업로드(upload session logs) — 세션 활동을 CloudWatch Logs/S3에 저장, 암호화된 로그 그룹만 허용 옵션 ▸ CloudWatch Logs 암호화 — KMS로 로그 그룹 암호화 【정답 포인트】 ▸ "인바운드 포트 없음 + 배스천/SSH 키 불필요" → Session Manager ▸ "세션 활동 로그를 저장·접근 + 암호화" → 세션 로그 업로드 옵션에서 암호화된 CloudWatch Logs 로그 그룹만 허용하도록 설정 【오답 체크】 (A) Control Tower는 거버넌스 도구이지 EC2 접속 수단이 아님. (B) Security Hub는 findings 집계 서비스이지 인스턴스 접속 수단이 아님. (C) Session Manager는 맞지만 "store session logs"만으로는 암호화 로그 그룹 강제 요건을 명확히 충족하지 못함 → 암호화된 로그만 허용하는 업로드 옵션(D)이 요건에 부합. 【시험 포인트】 포트 개방·배스천·SSH 키 없이 접속 + 암호화 세션 로그 → Session Manager + 암호화 CloudWatch Logs 강제.

해설

【핵심 용어】 ▸ 네트워크 ACL(NACL) — 서브넷 단위 상태 비저장 방화벽, 명시적 deny로 즉시 격리 가능 ▸ 보안 그룹 교체 — 진단 SG만 허용해 포렌식 접근 통로 유지 ▸ 격리 후 조사 — 공격 즉시 차단하면서 근본 원인 분석용 진단 인스턴스 별도 기동 【정답 포인트】 ▸ "즉시 완화 + 근본 원인 조사" → 먼저 NACL 아웃바운드 전면 deny로 악성 통신 즉시 차단 ▸ 이후 SG를 진단 SG만 허용하도록 교체하고 NACL deny 제거 → 진단 도구 탑재 신규 인스턴스로 의심 인스턴스를 안전하게 조사 【오답 체크】 (A) 의심 인스턴스에 직접 로그인·도구 설치는 증거 오염·위험, netstat/SG deny 규칙(SG는 deny 규칙 없음) 접근도 부정확. (C) 인스턴스를 종료하면 메모리 등 휘발성 포렌식 데이터가 사라져 근본 원인 조사에 불리. (D) WAF는 웹 애플리케이션 계층 보호용이며 EC2 인스턴스에 직접 붙여 아웃바운드 악성 연결을 막는 도구가 아님. 【시험 포인트】 침해 EC2 즉시 격리 → NACL deny로 차단 후 진단 전용 SG·별도 인스턴스로 조사. 직접 로그인/종료는 증거 훼손.

해설

【핵심 용어】 ▸ 침해 액세스 키 대응 — 즉시 비활성화/삭제 후 장기 액세스 키 사용 중단이 모범 사례 ▸ IAM 역할 전환 — Lambda 등 서비스는 액세스 키 대신 IAM 역할(임시 자격 증명) 사용 권장 ▸ Abuse 리포트 응답 — 지원 케이스 신설이 아니라 받은 abuse 리포트에 직접 회신 【정답 포인트】 ▸ 손상된 키 비활성화/삭제 + 액세스 키 사용 자체 중단 → 근본적 모범 사례 ▸ Lambda 배포 프로세스에 IAM 역할 부여로 키 없는 인증 전환 + abuse 리포트에 직접 회신하여 조치 내역 전달 【오답 체크】 (A) 새 액세스 키를 다시 발급·사용하는 방식은 키 기반 위험을 그대로 남김, 별도 지원 케이스 신설도 불필요. (C) IAM 사용자 삭제는 과도하고, 새 키를 Secrets Manager에 넣어도 여전히 액세스 키에 의존 + 지원 케이스 신설 방식. (D) 새 키를 Lambda 환경 변수에 저장은 비밀 노출 위험이 큰 안티패턴. 【시험 포인트】 침해 액세스 키 → 즉시 무효화 + 액세스 키 폐기하고 IAM 역할로 전환 + abuse 리포트에 직접 회신.

해설

【핵심 용어】 ▸ KMS 키 정책 — SSE-KMS 버킷 객체 복호화에 사용자의 kms:Decrypt 접근 허용 필요 ▸ S3 버킷 정책 — 특정 IAM 주체의 s3:GetObject 접근을 좌우 ▸ IAM 정책 — 해당 IAM 사용자에 부여된 권한, 개별 사용자 차이의 근원 【정답 포인트】 ▸ "같은 계정의 다른 사용자는 다운로드 가능, 특정 사용자만 실패" → 그 사용자 개별 권한 계층을 점검 ▸ (A) KMS 키 정책, (C) S3 버킷 정책, (E) IAM 정책 — 이 세 계층 중 하나가 해당 사용자를 막고 있어 다운로드 실패 가능 【오답 체크】 (B) S3 VPC 엔드포인트 정책은 콘솔 다운로드(엔드포인트 미경유 가능성)와 특정 사용자만 실패하는 정황을 설명하기 어려움. (D) S3 ACL은 레거시 접근 제어로, 계정 내 특정 IAM 사용자 차등을 설명하는 핵심 계층이 아님. (F) KMS VPC 엔드포인트 정책도 특정 사용자만의 실패 원인으로 부적합. 【시험 포인트】 KMS 암호화 S3 다운로드 실패 → IAM 정책 + S3 버킷 정책 + KMS 키 정책 세 계층을 함께 확인.

해설

【핵심 용어】 ▸ API Gateway 액세스 로깅(access logging) — 스테이지 단위로 요청 접근 로그를 CloudWatch Logs로 전송 ▸ CloudWatch Logs Insights — 로그 파일 직접 파싱 없이 쿼리로 접근 패턴 분석 ▸ CloudTrail/S3+Athena — 별도 파싱·쿼리 인프라가 필요해 노력 증가 【정답 포인트】 ▸ (A) 필요한 API 스테이지에 액세스 로깅 구성 → 접근 로그를 CloudWatch Logs로 수집 ▸ (D) CloudWatch Logs Insights로 로그 파일을 직접 파싱하지 않고 쿼리로 접근 패턴 분석 → 최소 노력 【오답 체크】 (B) CloudTrail은 관리 이벤트 중심이며 필드 필터 구성·해석에 추가 작업이 큼. (C) S3 저장 후 Athena 쿼리는 파싱/스키마 설정 등 오히려 노력이 큼. (E) 상세 CloudWatch 지표는 집계 메트릭만 제공, 접근 "패턴" 분석 요구를 충족하지 못함. 【시험 포인트】 로그 파싱 없이 API 접근 패턴 분석 → 스테이지 액세스 로깅 + CloudWatch Logs Insights.

해설

【핵심 용어】 ▸ awslogs 로그 드라이버 — ECS 태스크 정의의 LogConfiguration에서 컨테이너 stdout/stderr을 CloudWatch Logs로 직접 전송 ▸ Fargate — 서버리스 컨테이너, 컨테이너 인스턴스(호스트) 접근 불가 → 에이전트 설치 불가 ▸ awslogs-group / awslogs-region — 로그 드라이버 파라미터로 대상 로그 그룹·리전 지정 【정답 포인트】 ▸ Fargate는 호스트 접근이 없으므로 태스크 정의에서 awslogs 드라이버를 켜고 awslogs-group·awslogs-region을 지정 → 기존 CloudWatch 로그 그룹으로 수집 【오답 체크】 (B) Fargate는 컨테이너 인스턴스가 없어 CloudWatch 에이전트를 호스트에 설치할 수 없음. (C) Fluent Bit/FluentD DaemonSet는 노드 접근이 있는 EKS/EC2 방식으로, Fargate 태스크의 표준 로그 수집법이 아님(설정 노력도 큼). (D) logs:CreateLogGroup 권한을 인스턴스에 부여하는 것만으로는 로그가 전송되지 않고, Fargate엔 컨테이너 인스턴스도 없음. 【시험 포인트】 ECS Fargate 컨테이너 로그 → 태스크 정의의 awslogs 로그 드라이버(호스트 에이전트 불가).

해설

【핵심 용어】 ▸ S3 버킷 정책 — 특정 principal(연동 사용자)에 대한 Deny 문으로 세분화 접근 거부 ▸ 명시적 Deny의 범위 — 버킷 정책 Deny는 해당 버킷 리소스에만 적용, 다른 권한은 유지 ▸ [이미지] 각 보기의 정책 JSON은 이미지로 제시됨 【정답 포인트】 ▸ "Bob의 S3 권한만 거부, 나머지 권한 유지" → 해당 버킷을 리소스로 한 Deny 문에서 Bob(연동 사용자)을 정확히 대상으로 지정한 정책 ▸ Deny 대상·리소스 범위가 Bob과 DOC-EXAMPLE-BUCKET에 한정된 보기가 정답 【오답 체크】 (정답 외 보기) principal 지정이 잘못되었거나(다른 사용자까지 포함/미스매치), Deny 범위가 특정 버킷을 넘어서거나, Allow/Deny 구조가 요구와 어긋나 Bob의 다른 권한까지 영향을 주거나 Bob을 정확히 차단하지 못함. 【시험 포인트】 특정 연동 사용자만 특정 버킷 거부 → principal을 정확히 Bob으로, 리소스를 해당 버킷으로 한정한 Deny 버킷 정책.

해설

【핵심 용어】 ▸ SSE-KMS + 4KB 한계 — KMS Encrypt/Decrypt는 최대 4KB, 그보다 큰 데이터는 봉투 암호화(envelope encryption) 사용 ▸ kms:GenerateDataKey — 데이터 키를 생성해 대용량 데이터를 로컬에서 암호화(봉투 암호화의 핵심) ▸ [이미지] 각 보기의 KMS Action 목록은 이미지로 제시됨 【정답 포인트】 ▸ 4KB 초과 파일은 kms:Encrypt만으로 불가 → GenerateDataKey로 데이터 키를 받아 로컬 암호화, 읽을 때 Decrypt ▸ 4KB 초과 암복호화에 필요한 최소 Action(GenerateDataKey + Decrypt 계열)을 포함한 보기가 정답 【오답 체크】 (정답 외 보기) kms:Encrypt/Decrypt만 포함해 봉투 암호화용 GenerateDataKey가 빠졌거나, 불필요한 관리 액션(CreateKey, PutKeyPolicy 등)을 포함해 "최소 권한" 요구를 위배. 【시험 포인트】 4KB 초과 데이터 암호화 오류 → kms:GenerateDataKey(봉투 암호화)가 필요. Encrypt 단독은 4KB까지만.

해설

【핵심 용어】 ▸ Session Manager 연결 요건 — SSM Agent + 아웃바운드 443 + Systems Manager 인터페이스 VPC 엔드포인트(인터넷 게이트웨이 없을 때) ▸ 인터페이스 VPC 엔드포인트 — 인터넷 없이 프라이빗 경로로 Systems Manager(ssm, ssmmessages, ec2messages) 도달 ▸ 엔드포인트 보안 그룹 — 인바운드 443 허용으로 인스턴스가 엔드포인트에 도달 【정답 포인트】 ▸ (A) 인스턴스 SG에 아웃바운드 443 허용 → SSM Agent가 엔드포인트로 나갈 통로 확보 ▸ (D) 인터넷 게이트웨이가 없으므로 Systems Manager용 인터페이스 VPC 엔드포인트 생성 ▸ (E) 엔드포인트 SG에 VPC CIDR로부터 인바운드 443 허용 → 인스턴스→엔드포인트 통신 성립 【오답 체크】 (B) 인스턴스에 인바운드 443 허용은 Session Manager(아웃바운드 개시)에 불필요. (C) EC2 키 페어는 SSH 방식으로, Session Manager 접속과 무관하며 포렌식 접근 요건과 상관없음. (F) "EC2 인스턴스용" 인터페이스 엔드포인트라는 개념은 없음(필요한 것은 Systems Manager 엔드포인트). 【시험 포인트】 인터넷 없는 서브넷에서 Session Manager → 아웃바운드 443 + Systems Manager 인터페이스 엔드포인트 + 엔드포인트 SG 인바운드 443.

해설

【핵심 용어】 ▸ CloudWatch 에이전트 로그 수집 — 커스텀 로그 파일을 CloudWatch Logs로 근실시간 전송, 대화형 세션 불필요 ▸ SSM Run Command — 인스턴스에 접속하지 않고 명령을 실행해 로그 파일 내용 조회 ▸ 대화형 세션 배제 — Session Manager 접속은 대화형이라 요건 위배 【정답 포인트】 ▸ (B) CloudWatch 에이전트 설정에 커스텀 로그 파일을 등록 → 운영진이 CloudWatch Logs 로그 그룹에서 조회(대화형 접속 없음) ▸ (C) SSM Run Command로 로그 파일을 원격 조회 → 인스턴스 대화형 세션 없이 최신 로그 확인 【오답 체크】 (A) 시간당 cron으로 S3 복사는 최대 1시간 지연 → "30분 내" 요건 미충족. (D) Session Manager는 대화형 세션 접속이라 "대화형 세션 미사용" 요건 위배. (E) 시간당 cron + Athena도 최대 1시간 지연 및 파싱 오버헤드로 부적합. 【시험 포인트】 30분 내 로그 가시성 + 대화형 접속 금지 → CloudWatch 에이전트 또는 SSM Run Command. cron 시간당 복사는 지연 초과.

해설

【핵심 용어】 ▸ AWS Config 전송 채널 — Config가 S3 버킷에 기록하려면 버킷 정책이 config.amazonaws.com에 쓰기 허용 필요 ▸ IAM 엔티티 권한 — Config를 구성하는 주체가 s3:GetBucketAcl, s3:PutObject* 권한 보유해야 설정 가능 ▸ 전송 정책 오류 — "unable to write to bucket"은 버킷 쓰기 권한/정책 문제 【정답 포인트】 ▸ (A) S3 버킷 정책이 config.amazonaws.com 서비스의 대상 버킷 쓰기를 허용하는지 확인 ▸ (B) 설정을 수행하는 IAM 엔티티가 s3:GetBucketAcl 및 s3:PutObject* 권한을 갖는지 확인 → 두 계층 모두 필요 【오답 체크】 (C) 버킷 정책에 s3:GetBucketAcl/PutObject* "권한"을 부여한다는 서술은 주체(IAM 엔티티) 권한과 혼동한 표현 → 부정확. (D) IAM 엔티티에 붙은 정책이 config.amazonaws.com "서비스"에 쓰기를 허용한다는 건 principal 개념 혼동(서비스 허용은 버킷 정책 몫). (E) BatchGetResourceConfig 관련 서술은 이 전송 오류의 원인과 무관한 함정. 【시험 포인트】 Config의 S3 전송 실패 → 버킷 정책이 config 서비스 쓰기 허용 + IAM 엔티티의 s3:GetBucketAcl/PutObject* 권한 둘 다 확인.

해설

【핵심 용어】 ▸ 종단 간 암호화(ELB↔EC2) — ELB와 백엔드 EC2 모두에 인증서가 필요, 백엔드까지 HTTPS 유지 ▸ ACM 발급 vs 가져온(imported) 인증서 — ACM이 발급한 공인 인증서는 내보내기 불가라 EC2에 설치 불가, 서드파티 가져온 인증서는 EC2에도 설치 가능 ▸ ACM 인증서를 ELB에 연결 — 프론트 리스너 암호화 【정답 포인트】 ▸ EC2와 ELB 모두 암호화하려면 EC2에도 설치 가능한 서드파티 인증서를 ACM에 가져와, EC2에 설치하고 같은 ACM 가져온 인증서를 ELB에 연결 → 종단 간 암호화를 최소 운영 노력으로 구성 【오답 체크】 (A) ACM이 발급한 인증서는 내보낼 수 없어 EC2 인스턴스에 설치할 수 없음 → 종단 간 구성 불가. (C) CloudHSM 도입은 인증서 관리 오버헤드가 크고 요구되지 않음. (D) B와 거의 동일하나 "certificate bundle" 표현의 함정 변형 → 이 문제에서 채택된 표준 표현은 B(서드파티 SSL 인증서 가져오기). 【시험 포인트】 ELB↔EC2 종단 간 암호화 → 서드파티 인증서를 ACM에 가져와 EC2 설치 + ELB 연결. ACM 발급 인증서는 EC2에 못 심음.

해설

【핵심 용어】 ▸ EBS 기본 키(aws/ebs) 암호화 스냅샷 — AWS 관리형 기본 키로 암호화된 스냅샷은 다른 계정과 공유 불가 ▸ 고객 관리형 키 재암호화 — 스냅샷을 복사하며 CMK로 재암호화하면 공유 가능 ▸ 키 정책 교차 계정 허용 — 대상(포렌식) 계정 principal에 키 사용 권한 부여 필요 【정답 포인트】 ▸ (A) 새 고객 관리형 키를 만들고 스냅샷을 복사하며 그 키로 재암호화 → 기본 키 공유 제약 해소 ▸ (B) 키 정책을 수정해 포렌식 계정 주체가 CMK를 사용하도록 허용 → 교차 계정 복호화 가능 ▸ (F) 재암호화된 암호화 스냅샷을 포렌식 계정과 공유 → 공유 완료 【오답 체크】 (C) 데이터를 복호화해 비암호화 EBS로 옮기는 방식은 "항상 암호화" 요건 위배. (D) "복호화된 스냅샷으로 복사"는 비암호화 상태를 만들어 요건 위배·모호. (E) 비암호화 EBS 볼륨 생성 역시 상시 암호화 요건 위배. 【시험 포인트】 EBS 기본 키 스냅샷은 공유 불가 → CMK로 복사·재암호화 + 키 정책 교차 계정 허용 + 공유. 비암호화 경로는 오답.