정답 · 해설

해설

【핵심 용어】 ▸ Security Group — stateful, 인바운드/아웃바운드 규칙 별도지만 반환 트래픽은 자동 허용 ▸ 애플리케이션→DB 통신 — 발신 측(app) 아웃바운드 + 수신 측(DB) 인바운드 확인이 핵심 ▸ 통신 방향 진단 — 요청 방향: app SG 아웃바운드 → DB SG 인바운드 【정답 포인트】 ▸ app와 DB 간 통신 문제 진단 → DB SG의 인바운드(app로부터 허용?) + app SG의 아웃바운드(DB로 나감 허용?) 확인 → A가 정답 ▸ (SG는 stateful이라 이 두 방향만 맞으면 반환은 자동) 【오답 체크】 (B) DB 아웃바운드/app 인바운드는 응답·역방향으로 요청 흐름 진단에 부적합. (C) 양쪽 모두 인바운드만 보면 app의 발신(아웃바운드) 점검 누락. (D) DB 아웃바운드 중심 점검은 요청 방향(app→DB)과 어긋남. 【시험 포인트】 SG 통신 진단은 요청 방향 기준 → 발신 측 아웃바운드 + 수신 측 인바운드. stateful이라 반환은 자동.

해설

【핵심 용어】 ▸ 전 구간 전송 암호화 — 클라이언트~로드밸런서~EC2까지 평문 노출 없이 암호화 유지 ▸ ALB SSL 종료 + 재암호화 — ALB에서 SSL 종료 후 백엔드로 HTTPS로 재암호화 연결 ▸ NLB TCP passthrough — NLB가 복호화 없이 TCP를 통과시켜 EC2에서 SSL 종료 【정답 포인트】 ▸ 항상 전송 암호화 → (A) ALB에서 클라이언트 SSL 종료 후 ALB→EC2를 HTTPS로 연결(재암호화) ▸ (C) NLB TCP passthrough로 받아 EC2에서 SSL 종료 → EC2까지 암호화 유지 → A,C가 정답 【오답 체크】 (B) NLB SSL 리스너 + TCP passthrough 혼합 서술은 SSL을 NLB에서 종료하는 구성과 모순되어 전 구간 암호화 보장 부적합. (D) SSL을 ALB에서 종료하면 ALB→EC2 구간이 평문이 되어 PII 평문 노출 위험. (E) ALB에서 TCP passthrough를 설정한다는 구성 자체가 부정확하고 흐름이 성립하지 않음. 【시험 포인트】 전 구간 암호화 = ALB SSL 종료 후 백엔드 HTTPS 재암호화, 또는 NLB TCP passthrough로 EC2에서 SSL 종료. LB에서만 종료하면 백엔드 평문.

해설

【핵심 용어】 ▸ AWS owned key — AWS가 소유·관리, 고객이 순환·제어·교체 불가 ▸ CMK alias — 키를 가리키는 안정적 별칭, 실제 키를 바꿔도 애플리케이션은 alias 참조 유지 ▸ Customer managed CMK — 고객이 생성·on-demand 교체 가능한 키 【정답 포인트】 ▸ AWS owned 키는 고객이 새 키 자료로 교체 불가 → alias 생성 후, 교체 요청 시마다 새 customer managed CMK 생성해 alias를 새 키에 연결 ▸ 신규 파일은 새 키로 암호화되고 애플리케이션은 alias만 참조 → C가 정답 【오답 체크】 (A) customer managed 키의 순환 스케줄은 임의 시점 수동 발동 개념이 아니며(자동 주기), 요구된 "원할 때 즉시 새 키" 시나리오에 alias 교체가 더 적합. (B) AWS managed CMK는 순환 주기·발동을 고객이 제어할 수 없음. (D) AWS managed CMK를 임의 생성·교체할 수 없어 alias 연결 대상이 될 수 없음. 【시험 포인트】 "원할 때 새 키 자료로 교체" + 애플리케이션 무중단 → alias를 새 customer managed CMK로 재지정. AWS owned/managed 키는 고객 제어 불가.

해설

【핵심 용어】 ▸ EKS control plane logging — API server 등 컨트롤 플레인 로그를 CloudWatch Logs로 전송 ▸ Kubernetes API server logs — 파드 생성 등 Kubernetes 이벤트/감사 로그 소스 ▸ CloudTrail 한계 — AWS API 호출은 기록하나 클러스터 내부 Kubernetes 이벤트는 미포함 【정답 포인트】 ▸ CloudTrail에 파드 생성 이벤트가 안 보임 → 파드 생성은 Kubernetes 컨트롤 플레인 이벤트이지 AWS API 이벤트가 아님 ▸ 각 클러스터에서 Kubernetes API server 컴포넌트 로그를 활성화하면 CloudWatch에서 확인 → B가 정답 【오답 체크】 (A) S3 VPC 엔드포인트/로깅 구성은 Kubernetes 이벤트 가시성과 무관. (C) S3 CORS는 브라우저 교차 출처 설정으로 로그 수집과 무관. (D) CloudWatch만 구성한다고 EKS 컨트롤 플레인 로그가 자동 흐르지 않음 — 클러스터에서 로깅 활성화 필요. 【시험 포인트】 EKS 파드/Kubernetes 이벤트가 CloudTrail에 없음 → EKS control plane(API server) 로깅 활성화 → CloudWatch Logs로 전송.

해설

【핵심 용어】 ▸ kms:CreateGrant — 서비스(EC2/Auto Scaling)가 CMK로 볼륨을 복호화·사용하도록 위임하는 grant 생성 권한 ▸ 암호화 부트 볼륨 시작 — EC2가 부팅 시 CMK로 볼륨을 사용하려면 grant 필요 ▸ "launch 성공 후 종료" — grant 부재로 볼륨 사용 권한 위임 실패 시 인스턴스 즉시 종료 【정답 포인트】 ▸ 시작은 성공했다 곧 종료 → 암호화 볼륨용 CMK에 대한 kms:CreateGrant 권한 누락이 원인 ▸ EC2가 CMK를 사용하도록 grant를 만들어야 하므로 B(kms:CreateGrant)가 정답 【오답 체크】 (A) kms:GetKeyRotationStatus는 순환 상태 조회로 볼륨 사용과 무관. (C) kms:GenerateRandom은 난수 생성 API로 무관. (D) kms:EnableKey는 키 활성화용으로 grant 위임 문제와 무관. 【시험 포인트】 암호화 볼륨 인스턴스가 뜨자마자 종료 + KMS 권한 부족 → kms:CreateGrant 누락(서비스가 CMK를 대신 사용하도록 위임).

해설

【핵심 용어】 ▸ GuardDuty → Security Hub → EventBridge — finding을 수집·라우팅해 자동 대응 트리거 ▸ AWS Network Firewall — VPC 네트워크 레벨 방화벽, 규칙 그룹으로 의심 인스턴스 트래픽 차단 ▸ RDP brute force from EC2 — 인스턴스 발신/수신 통신을 네트워크 레벨에서 차단 필요 【정답 포인트】 ▸ EC2발 RDP 무차별 대입을 조사 전까지 차단 → Security Hub로 GuardDuty finding 수집 → EventBridge → Lambda가 Network Firewall 정책 규칙 추가로 해당 인스턴스 트래픽 차단 → C가 정답 【오답 체크】 (A) NACL 규칙 추가 방식은 가능해 보이나 Kinesis Data Analytics/Flink까지 끼운 과한 구성으로 요구와 부합도 낮음. (B) WAF는 웹(HTTP/S) 레이어 보호로 RDP 같은 비웹 트래픽 차단에 부적합. (D) Kinesis를 Security Hub 이벤트 대상으로 두는 구성이 부정확하고 SG 교체만으로는 요구 흐름과 어긋남. 【시험 포인트】 GuardDuty 위협 → 자동 대응: Security Hub/EventBridge로 라우팅. 비웹(RDP 등) 트래픽 차단은 Network Firewall(WAF 아님).

해설

【핵심 용어】 ▸ CloudFront custom origin — AWS 외부 오리진(오브젝트 스토어)도 배포 오리진으로 사용 가능 ▸ Cache policy header whitelist — Authorization 등 특정 헤더를 오리진으로 전달하도록 포함 ▸ Authorization 헤더 전달 — 오리진 인증에 필요한 헤더를 CloudFront가 포워딩 【정답 포인트】 ▸ 외부 오리진 + Authorization 헤더 전달 필요 + 최소 시간 → CloudFront 배포 생성 후 cache policy에 Authorization 헤더 화이트리스트 추가해 오리진에 전달 → C가 정답 ▸ (오브젝트를 S3로 옮길 필요 없음) 【오답 체크】 (A) Global Accelerator는 헤더 전달 요구와 무관하고 S3 마이그레이션도 불필요. (B) X-Amz-Authorization 커스텀 헤더는 원 요청의 Authorization 헤더 전달과 다른 개념, 요구 미충족. (D) 오브젝트를 S3로 마이그레이션하는 추가 작업으로 "최소 시간"에 반함. 【시험 포인트】 CloudFront가 특정 요청 헤더(Authorization)를 오리진에 전달 → cache policy 헤더 화이트리스트. 외부 오리진은 그대로 사용, 불필요한 마이그레이션 배제.

해설

【핵심 용어】 ▸ CloudHSM 접근 방식 — HSM은 VPC 내 ENI(프라이빗 IP)로 접근, 클라이언트가 네트워크 경로 필요 ▸ AWS RAM(Resource Access Manager) — VPC 서브넷을 다른 계정과 공유해 크로스 계정 리소스 배치 허용 ▸ CloudHSM security group — 클라이언트 인스턴스의 프라이빗 IP에서 인바운드 허용 【정답 포인트】 ▸ 중앙 계정 HSM을 새 계정과 공유 → AWS RAM으로 HSM이 위치한 서브넷을 새 계정에 공유 ▸ CloudHSM 보안 그룹이 새 계정 클라이언트 인스턴스의 프라이빗 IP 인바운드를 허용하도록 구성 → A가 정답 【오답 체크】 (B) 크로스 계정 IAM role은 CloudHSM 클러스터 네트워크 접근(ENI 기반)을 제공하지 못함. (C) SSO/STS 토큰으로 HSM에 크로스 계정 "작업 호출"하는 방식은 CloudHSM 접근 모델과 맞지 않음. (D) "HSM의 ID"를 RAM으로 공유하는 것은 CloudHSM 공유 방식이 아님(공유 대상은 서브넷). 【시험 포인트】 CloudHSM 크로스 계정 공유 → RAM으로 HSM 서브넷 공유 + SG에서 클라이언트 프라이빗 IP 허용. HSM은 VPC ENI(네트워크)로 접근.

해설

【핵심 용어】 ▸ Route 53 DNS 쿼리 로깅 — 쿼리 로그를 저장 대상으로 내보내 보관 ▸ Amazon S3 + Lifecycle policy — 고내구성(11 9's) 저장 + 수명 주기로 1년 초과 객체 자동 삭제 ▸ 비용 효율 — S3 저장 + lifecycle 자동 삭제가 관리 부담·비용 최소 【정답 포인트】 ▸ "고내구성 저장 + 1년 초과 로그 자동 삭제 + 가장 비용 효율" → S3로 로그 내보내고 S3 Lifecycle 정책으로 1년 초과 객체 자동 삭제 → A가 정답 【오답 체크】 (B) Lambda를 매시간 실행해 오래된 로그 삭제는 불필요한 커스텀 운영·비용, lifecycle으로 대체 가능. (C) CloudWatch Logs 보존 기간 설정도 가능하나 대량 로그 장기 보관에는 S3 대비 비용 효율이 낮음. (D) CloudWatch Logs Insights로 오래된 항목을 식별·삭제하는 것은 수작업/쿼리 비용이 크고 자동 삭제 수단이 아님. 【시험 포인트】 대량 로그 장기 저장 + 자동 만료 + 비용 효율 → S3 + Lifecycle policy. CloudWatch Logs는 보존 설정은 되나 장기 대량 보관 비용이 큼.

해설

【핵심 용어】 ▸ Gateway VPC endpoint policy — 엔드포인트에 부착된 리소스 정책, S3 접근 허용 범위를 별도 제한 ▸ 엔드포인트 정책 기본값 vs 제한 — 제한적 정책이면 IAM·버킷 정책이 맞아도 접근 차단 ▸ 진단 순서 — IAM/버킷 정책/SG/NACL 모두 정상이면 남은 것은 엔드포인트 정책 【정답 포인트】 ▸ IAM·버킷 정책·SG·NACL 모두 정상인데 실패 → 게이트웨이 VPC 엔드포인트 정책이 S3 접근을 허용하는지 확인 → D가 정답 【오답 체크】 (A) 보안 그룹에는 "암묵적 인바운드 deny for S3" 개념이 없고 이미 SG는 검증됨. (B) 게이트웨이 VPC 엔드포인트에는 보안 그룹이 없음(인터페이스 엔드포인트에만 SG). (C) 인터넷 게이트웨이는 게이트웨이 엔드포인트 경유 S3 접근 경로와 무관하며 인바운드 규칙 개념도 없음. 【시험 포인트】 IAM·버킷·SG·NACL 다 맞는데 S3 접근 실패 → 게이트웨이 VPC 엔드포인트 정책 확인. 게이트웨이 엔드포인트에는 SG가 없다.

해설

【핵심 용어】 ▸ Amazon GuardDuty — 지속적 위협 탐지, 신속 활성화 가능(추가 인프라 최소) ▸ SNS 토픽 + 이메일 구독 — 고심각도 finding을 이메일 배포 그룹으로 알림 ▸ EventBridge 규칙 — GuardDuty 고심각도 finding을 매칭해 SNS로 발행 【정답 포인트】 ▸ 신속한 지속 모니터링 + 고심각도 이메일 알림 → (B) GuardDuty 활성화 + (C) SNS 토픽 생성·이메일 배포 그룹 구독 + (E) 고심각도 GuardDuty finding용 EventBridge 규칙으로 SNS 발행 → B,C,E가 정답 【오답 체크】 (A) Security Hub는 이 시나리오에서 필수가 아니며 GuardDuty만으로 탐지·알림 구성 가능(신속성 우선). (D) SQS 큐에는 이메일 배포 그룹을 직접 구독시킬 수 없음(이메일 구독은 SNS). (F) Security Hub finding + SQS 큐 발행 조합은 이메일 알림 요구·신속 구성과 어긋남. 【시험 포인트】 신속 위협 탐지+이메일 알림 → GuardDuty + EventBridge + SNS(이메일 구독). 이메일 구독은 SNS이지 SQS가 아님.

해설

【핵심 용어】 ▸ KMS key policy 기본 명령문 — "AWS 계정 root에 전체 접근" 문이 있어야 IAM 정책이 키에 효력 발생 ▸ IAM + KMS 연동 — IAM 정책으로 KMS 권한을 주려면 키 정책이 계정에 위임을 허용해야 함 ▸ SSE-KMS 객체 읽기 — 객체 복호화에 CMK 접근 필요, 키 정책이 없으면 IAM만으로 부족 【정답 포인트】 ▸ 동일 계정 + IAM에 kms:Decrypt·s3 get/list 부여 + 버킷 정책 없음인데 Access Denied ▸ 원인: 키 정책이 편집되어 계정 root의 전체 접근 문이 제거됨 → IAM 정책 위임이 무효 → 복호화 불가 → D가 정답 【오답 체크】 (A) kms:DescribeKey는 복호화에 필수가 아니며 이미 Decrypt가 있음. (B) AWS managed 키로 바뀌었어도 IAM 사용자 권한 문제와 직접 원인이 아님(문제는 키 정책 위임). (C) 동일 계정에서는 버킷 정책 없이도 IAM 권한으로 접근 가능하므로 버킷 정책 부재가 원인이 아님. 【시험 포인트】 IAM에 KMS 권한이 있어도 접근 거부 → 키 정책이 계정에 위임(root full access)을 허용하는지 확인. KMS는 키 정책이 IAM 위임의 전제.

해설

【핵심 용어】 ▸ Service Control Policy (SCP) — 조직/OU 계정에 걸쳐 특정 액션 강제 차단 ▸ cloudtrail:StopLogging Deny — 어떤 계정도 CloudTrail 로그 전송을 중지하지 못하게 함 ▸ 조직 전역 가드레일 — 20+ 계정에 SCP 하나로 일괄 적용 【정답 포인트】 ▸ "어떤 계정도 CloudTrail 로그 전송 중지 불가" → cloudtrail:StopLogging을 Deny하는 SCP를 OU 내 모든 계정에 적용 → B가 정답 【오답 체크】 (A) --is-multi-region-trail은 로그 범위(리전) 설정일 뿐 중지 차단과 무관. (C) StopLogging을 Allow하는 SCP는 정반대로 중지를 허용해 요구 위반. (D) SSM으로 "항상 켜짐 보장"은 강제 방지 메커니즘이 아니며 우회 가능. 【시험 포인트】 로그 중지 등 특정 액션 조직 전역 금지 → SCP Deny(cloudtrail:StopLogging). Allow가 아니라 Deny여야 함.

해설

【핵심 용어】 ▸ ECR KMS 암호화 — 리포지토리 생성 시에만 설정 가능, 기존 리포에 사후 활성화 불가 → 재생성 필요 ▸ ECR image scanning — CVE 등 취약점을 이미지 대상으로 네이티브 스캔 ▸ 이미지 push 후 스캔 — 스캔 활성화 후 다음 push된 이미지에서 결과 확인 【정답 포인트】 ▸ ECR 리포 KMS 암호화 + 컨테이너 이미지 CVE 분석 → KMS 암호화·ECR 스캐닝 켠 상태로 리포 재생성 후, 다음 이미지 push 시 스캔 리포트 분석 → B가 정답 【오답 체크】 (A) 기존 리포에 KMS 암호화를 사후 활성화할 수 없음 + Inspector 에이전트는 이미지 CVE 스캔 방식이 아님(여기선 ECR 스캔). (C) SSM 인벤토리 리포트는 CVE 이미지 스캔이 아님. (D) Trusted Advisor는 CVE 이미지 스캔 도구가 아니며 KMS 사후 활성화도 불가. 【시험 포인트】 ECR 암호화는 생성 시 지정(사후 불가, 재생성) + 이미지 CVE는 ECR image scanning. Inspector/SSM/Trusted Advisor는 ECR 이미지 CVE 스캔용 아님.

해설

【핵심 용어】 ▸ AWS WAF 로깅 — 웹 ACL 로그를 Amazon Kinesis Data Firehose 전송 스트림으로 전달 ▸ Kinesis Data Firehose — 로그를 목적지(S3)로 전달, WAF 로깅의 공식 대상 ▸ 리전 일치 — Firehose 전송 스트림은 웹 ACL과 같은 리전이어야 함 【정답 포인트】 ▸ WAF 모든 요청 로깅 → (B) 웹 ACL 로깅 활성화하고 Kinesis Data Firehose 전송 스트림에 연결 + (E) 웹 ACL과 같은 리전에 Firehose 전송 스트림 생성해 S3를 목적지로 지정 → B,E가 정답 【오답 체크】 (A) WAF 로깅은 Kinesis "data stream"이 아니라 Data Firehose에 연결. (C) 로그 필터링은 "모든 요청 로깅" 요구에 불필요(전체 캡처). (D) Kinesis data stream을 만들어 S3로 지정하는 방식은 WAF 로깅 대상이 아님(Firehose 사용). 【시험 포인트】 WAF 로깅 대상 = Kinesis Data Firehose(동일 리전) → S3. data stream이 아니라 Firehose임에 주의.

해설

【핵심 용어】 ▸ Private API Gateway — VPC 엔드포인트를 통해서만 접근, endpoint type PRIVATE 유지 ▸ REST API resource policy — 어떤 VPC/VPC 엔드포인트에서 접근 허용할지 aws:SourceVpc/SourceVpce로 지정 ▸ 최소 접근 — endpoint type을 REGIONAL로 바꾸지 않고 정책으로 vpc-2 허용 【정답 포인트】 ▸ vpc-2에 엔드포인트는 만들었으나 접근 불가 → API resource policy가 vpc-2(엔드포인트/VPC)를 허용하지 않음 ▸ endpoint type을 PRIVATE로 유지한 채 resource policy에 vpc-2 접근 허용 추가 → 최소 접근 → D가 정답 【오답 체크】 (A) VPC 피어링은 프라이빗 API 접근 방식이 아니며 불필요. (B) "vpc-2의 엔드포인트를 vpc-1에 설정"은 구성 개념이 부정확. (C) endpoint type을 REGIONAL로 바꾸면 API가 더 넓게 노출되어 "최소 접근" 원칙 위반. 【시험 포인트】 Private REST API를 추가 VPC에 허용 → endpoint type PRIVATE 유지 + resource policy에 해당 VPC/엔드포인트 허용. REGIONAL 전환은 과노출.

해설

【핵심 용어】 ▸ 최소 권한(least privilege) — 기능 유지하며 과도한 권한 제거 ▸ S3 버킷 정책 / IAM 실행 role 정책 — 크로스 계정 로그 집계에 필요한 최소 권한만 부여 ▸ [이미지] 정책 문서 — 화면상 JSON이라 일반 원칙 위주로 판단 【정답 포인트】 ▸ 중앙 S3 버킷으로 로그 복사 기능은 유지하되 과잉 권한 제거 → (B) 필요한 주체·액션만 남긴 버킷 정책으로 갱신 + (D) Lambda 실행 role을 필요한 S3 액션·리소스로 최소화한 정책으로 갱신 → B,D가 정답 ▸ (정책 본문은 이미지라 세부 대신 최소 권한 원칙으로 판별) 【오답 체크】 (A) 다른 버킷 정책안은 과잉/부적합 권한을 남겨 최소 권한 요구에 어긋남. (C) 다른 Lambda role 정책안은 필요 이상 권한을 유지해 부적합. (E) 또 다른 role 정책안 역시 기능 유지·최소 권한 균형에 맞지 않음. 【시험 포인트】 크로스 계정 로그 집계에서 "과잉 권한 제거" → 기능에 필요한 액션·리소스만 남긴 버킷 정책 + Lambda role 정책 조합. 이미지 정책은 최소 권한 원칙으로 판별.

해설

【핵심 용어】 ▸ AWS Config managed rule access-keys-rotated — maxAccessKeyAge 초과 키를 NON_COMPLIANT로 평가 ▸ 주기 평가(24h) — Config 규칙을 주기적으로 실행 ▸ EventBridge + SNS — NON_COMPLIANT 이벤트를 매칭해 보안팀에 알림 【정답 포인트】 ▸ "액세스 키 90일 미순환 자동 알림" + "최소 노력" → Config 관리형 규칙 access-keys-rotated(maxAccessKeyAge=90)로 평가 + EventBridge가 NON_COMPLIANT 매칭 → SNS 알림 → A가 정답 【오답 체크】 (B) Trusted Advisor CSV + Lambda + S3 + Athena 조합은 과도한 커스텀 파이프라인. (C) 자격 증명 리포트를 스크립트로 다운로드·파싱하는 Lambda는 관리형 규칙 대비 노력 큼. (D) IAM API 순회 + CreateDate 기준 판별은 커스텀 코드 부담이 크고 CreateDate는 마지막 순환 시점과 다름. 【시험 포인트】 IAM 액세스 키 순환 규정 준수 알림 + 최소 노력 → Config managed rule(access-keys-rotated) + EventBridge(NON_COMPLIANT) + SNS.

해설

【핵심 용어】 ▸ S3 버킷 정책 IP 제한 — aws:SourceIp 조건으로 특정 IP 대역만 허용/그 외 거부 ▸ Deny + NotIpAddress — 허용 대역(10.24.34.0/23) 외 소스를 명시적으로 거부하는 패턴 ▸ [이미지] 정책 — 보기 JSON이 이미지라 일반 원칙으로 판별 【정답 포인트】 ▸ 10.24.34.0/23만 버킷·객체 접근 허용하고 그 외 IP 거부 → aws:SourceIp가 해당 CIDR이 아닐 때(NotIpAddress) Deny하는 올바른 조건 구조의 정책 → B가 정답 ▸ (IAM 정책이 액션을 통제하므로 버킷 정책은 IP 경계만 담당) 【오답 체크】 (A)(C)(D) 조건 연산자·Effect 조합이 어긋나(예: 잘못된 Allow/Deny 논리나 IpAddress/NotIpAddress 오용) 지정 대역 외를 정확히 거부하지 못함. 정책이 이미지라 세부는 일반 원칙으로 판별. 【시험 포인트】 "특정 IP 대역만 허용, 그 외 거부" → Deny + NotIpAddress(aws:SourceIp) 패턴이 정석. IP 경계는 버킷 정책, 액션 통제는 IAM.

해설

【핵심 용어】 ▸ 침해 대응(자격 증명) — 비밀번호 변경, 액세스 키 순환/삭제로 무단 접근 무효화 ▸ 무단 리소스 제거 — 인식되지 않는/무단 생성 리소스 삭제로 피해 최소화 ▸ 피해 최소화 우선순위 — 탐지 도구 활성화보다 즉각적 접근 차단·정리 【정답 포인트】 ▸ 무단 IAM 사용자가 생성한 악성 호스팅 S3 버킷 → 피해 최소화 → (C) 모든 IAM 사용자 비밀번호 변경 + (D) 모든 액세스 키 순환/삭제 + (F) 인식되지 않는/무단 리소스 삭제 → C,D,F가 정답 【오답 체크】 (A) CloudTrail 로그 암호화는 사후 보호일 뿐 진행 중 침해 피해를 즉시 줄이지 못함. (B) GuardDuty 활성화는 탐지 개선이지 즉각적 피해 최소화 조치가 아님. (E) EBS 스냅샷은 포렌식 보존용으로 이 시나리오의 피해 최소화 핵심 조치가 아님. 【시험 포인트】 계정 침해 피해 최소화 = 자격 증명 무효화(비밀번호 변경·키 순환) + 무단 리소스 제거. 탐지 도구 활성화·로그 암호화는 최소화 핵심 아님.