정답 · 해설

해설

【핵심 용어】 ▸ AWS IAM Identity Center — 외부 IdP 연동, 다계정에 권한 세트(permission set) 기반 SSO 접근 중앙 관리 ▸ Permission set — 계정별 역할을 자동 프로비저닝, 100+ 계정 확장에 최적 ▸ 외부 IdP 페더레이션 — SAML/OIDC로 기업 디렉터리 연동 【정답 포인트】 ▸ "100+ 계정 + 외부 IdP + 역할 기반 + 확장성·운영 효율 극대" → IAM Identity Center ▸ IdP 연동 후 권한 세트를 만들어 계정·그룹에 할당 → 계정마다 수동 역할 생성 불필요 【오답 체크】 (A) 계정마다 전용 IAM 사용자 생성은 확장성·관리 최악. (B) 중앙 계정 역할 + 계정별 역할 수동 배포·편집은 100+ 계정에서 운영 부담 큼. (D) 계정마다 IAM 역할·신뢰 정책을 수동 배포·유지하는 방식은 확장성·효율이 낮음. 【시험 포인트】다계정 + 외부 IdP + 확장성 = IAM Identity Center 권한 세트. 계정별 수동 IAM 역할/사용자는 오답.

해설

【핵심 용어】 ▸ AWS WAF web ACL (ALB 연결) — 요청 문자열·헤더 기반 커스텀 규칙으로 차단 ▸ User-Agent 문자열 매칭 — 공격에 쓰인 특정 에뮬레이터 UA를 차단 ▸ 크리덴셜 스터핑 — 다수 IP에서의 자동화 로그인 시도 【정답 포인트】 ▸ "다수 IP + 특정 에뮬레이터 UA 문자열" → IP 차단은 무의미, UA 문자열이 공통 지표 ▸ WAF 커스텀 규칙으로 해당 device emulator UA를 포함한 요청 차단 → 정상 로그인은 허용 【오답 체크】 (A) CloudWatch 알람+SNS는 알림일 뿐 공격을 차단하지 못함. (B) 다수 IP라 SG로 IP 차단은 실효성 없고 정상 사용자까지 막을 위험. (D) 정상 UA만 허용하는 화이트리스트는 정상 사용자의 다양한 UA를 차단해 정상 로그인 방해. 【시험 포인트】특정 지표(UA 문자열) 기반 공격 완화 = WAF 커스텀 규칙으로 해당 요청 차단. IP 차단은 다수 IP에서 무력.

해설

【핵심 용어】 ▸ SNS message data protection policy — 메시지 내 민감 데이터 탐지·마스킹(De-identify) 정책 ▸ De-identify 작업 — 메시지 페이로드의 민감 정보를 마스킹해 로그 노출 방지 ▸ 인바운드 데이터 보호 정책 — 게시(publish) 시점에 메시지 검사·마스킹 【정답 포인트】 ▸ "SNS 메시지의 민감 데이터가 로그에 우발 노출" → 메시지 자체를 마스킹해야 함 ▸ 인바운드 메시지 데이터 보호 정책에 De-identify 작업을 넣어 SNS 토픽에 적용 → 민감 데이터 마스킹 【오답 체크】 (A) Macie는 S3 데이터 스캔용, SNS 토픽 메시지를 스캔·마스킹하지 않음. Lambda 조합도 실시간 마스킹에 부적합. (C) KMS 암호화는 저장·전송 보호일 뿐, 구독자가 복호화 후 로그에 남기는 우발 노출을 막지 못함. (D) GuardDuty는 민감 데이터 탐지·SNS 메시지 차단 기능이 없음(위협 탐지용). 【시험 포인트】SNS 메시지 민감 데이터 마스킹 = 메시지 데이터 보호 정책의 De-identify 작업.

해설

【핵심 용어】 ▸ S3 Gateway VPC Endpoint — VPC에서 인터넷·NAT 없이 AWS 네트워크로 S3 접근 ▸ Lambda in VPC(프라이빗 서브넷) — VPC 내 실행 시 게이트웨이 엔드포인트로 S3 프라이빗 접근 ▸ NAT 게이트웨이 — 인터넷 경유(요건 위반) 【정답 포인트】 ▸ "S3 트래픽이 인터넷 경유 금지, AWS 네트워크만 사용" → S3 게이트웨이 엔드포인트 ▸ Lambda를 프라이빗 서브넷에 배치하고 S3 게이트웨이 엔드포인트로 라우팅 → 인터넷 미경유 【오답 체크】 (A) NAT 게이트웨이 경유는 인터넷을 통하므로 "인터넷 미경유" 요건 위반. (C) S3는 서브넷에 배포할 수 있는 리소스가 아님(리전 서비스) → 전제 오류. (D) SQS 경유 구조는 불필요하게 복잡하고 여전히 S3로의 프라이빗 경로를 보장하지 못함. 【시험 포인트】"S3 트래픽 인터넷 미경유" = S3 게이트웨이 엔드포인트. NAT는 인터넷 경유라 탈락.

해설

【핵심 용어】 ▸ SCP Condition — 특정 계정을 예외 처리해 가드레일 적용 범위 조정 ▸ aws:PrincipalAccount / aws:PrincipalOrgID 등 조건 키 — 마케팅 계정 제외 ▸ SCP는 Allow로 권한 부여 불가 — 오직 상한(Deny) 통제, 실제 권한은 IAM이 부여 【정답 포인트】 ▸ "마케팅 계정만 외부 공유 허용, 나머지는 계속 차단" → 기존 Deny SCP에 Condition으로 마케팅 계정 예외 ▸ 조건문으로 마케팅 계정을 제외하면 그 계정만 제약에서 벗어나고 나머지는 유지 【오답 체크】 (A) 개별 계정에 Allow SCP를 만들어도 상위 Deny SCP를 무효화하지 못함(SCP Allow는 권한 부여가 아님). (C) SCP의 Allow 문은 실제 권한을 부여하지 못하며 기존 Deny를 되돌리지도 못함. (D) 권한 경계는 개별 IAM 주체 상한일 뿐 조직 차원 SCP Deny를 우회하지 못함. 【시험 포인트】SCP는 Allow로 예외 못 만듦 → Deny SCP에 Condition으로 특정 계정 제외.

해설

【핵심 용어】 ▸ AWS Config 커스텀 규칙 + Lambda 교정 — 리소스 구성 변경 탐지 후 위임 관리자 계정에서 자동 remediation ▸ Security Hub 커스텀 액션 + EventBridge — findings에 대한 근실시간 대응 트리거 ▸ EventBridge 규칙 + Lambda — AWS 리소스에 직접 조치(remediation) 【정답 포인트】 ▸ SCP 변경 없이 근실시간 탐지·교정·중앙 로깅: ▸ (A) Config 커스텀 규칙으로 구성 변경 탐지 + Lambda로 위임 관리자 계정에서 교정 ▸ (C) Security Hub 커스텀 액션을 EventBridge 규칙에서 참조 ▸ (D) EventBridge 규칙이 Lambda를 호출해 리소스에 조치 【오답 체크】 (B) Change Manager는 변경 승인·추적 워크플로용이지 자동 탐지·근실시간 교정 파이프라인에 부적합. (E) 이미 Config/Security Hub가 있는데 Lambda로 별도 평가·finding 생성은 중복·비효율. (F) 스케줄 기반 평가는 "근실시간" 요건에 부합하지 않음(주기 실행). 【시험 포인트】근실시간 자동 교정 = Config 규칙 + Security Hub 커스텀 액션 + EventBridge→Lambda. 스케줄/Change Manager는 근실시간 아님.

해설

【핵심 용어】 ▸ Amazon GuardDuty RDS Protection — Aurora/RDS 로그인 활동을 분석해 미지의 사용자 로그인 시도 등 위협 탐지 ▸ EventBridge + SNS — GuardDuty findings 필터 후 이메일 알림 ▸ 최소 운영 오버헤드 — 관리형 탐지로 커스텀 코드 최소화 【정답 포인트】 ▸ "미지의 사용자 DB 로그인 시도에 이메일 알림 + 최소 운영 오버헤드" → GuardDuty RDS Protection 활성화 ▸ findings를 EventBridge로 필터 → SNS 이메일 알림 【오답 체크】 (B) 감사 로그 활성화 + Lambda 주기 스캔은 커스텀 코드·유지 부담으로 운영 오버헤드 큼. (C) RDS Custom AMI + 서드파티 에이전트는 마이그레이션·운영 부담이 매우 큼. (D) 저장 프로시저·DB 내 잡 구현은 커스텀 개발·유지 부담 커서 최소 오버헤드 아님. 【시험 포인트】RDS/Aurora 이상 로그인 탐지 최소 오버헤드 = GuardDuty RDS Protection + EventBridge → SNS.

해설

【핵심 용어】 ▸ CloudFront geo restriction(지리 제한) — 배포 자체 기능으로 국가 단위 허용/차단, 추가 비용 없음 ▸ AWS WAF geo match — 국가 차단 가능하나 WAF web ACL 비용 발생 ▸ 비용 효율 — 내장 기능 우선 【정답 포인트】 ▸ "특정 국가 차단 + 가장 비용 효율" → CloudFront 내장 geo restriction 사용 (WAF 추가 비용 없음) ▸ CloudFront에서 국가를 지정해 차단 【오답 체크】 (A) WAF IP 매칭으로 국가 IP 범위 관리는 부정확·관리 부담·WAF 비용 발생. (B) WAF geo match는 기능적으로 가능하나 WAF 비용이 추가되어 "가장 비용 효율"이 아님. (D) CloudFront에 국가 차단을 위한 geolocation 헤더 차단이라는 표준 방식은 없음 → 부적합. 【시험 포인트】국가 차단 최저 비용 = CloudFront 내장 geo restriction. WAF geo match는 기능은 되나 비용 추가로 탈락.

해설

【핵심 용어】 ▸ ECS Exec — 실행 중 Fargate/EC2 컨테이너에 대화형 셸 접근, 로그·메모리 덤프 등 조사 가능 ▸ ECS task role + SSM 권한 — ECS Exec는 SSM 세션 기반으로 동작 ▸ Fargate — 관리형이라 호스트 직접 접근 불가, ECS Exec가 조사 수단 【정답 포인트】 ▸ "실행 중 컨테이너에서 로그·메모리 덤프 조회 + 최소 운영 노력" → ECS Exec 활성화 ▸ task role에 SSM 권한 부여하고 ECS Exec로 컨테이너 내부 조사 【오답 체크】 (A) EC2 launch type으로 마이그레이션은 큰 운영 변경으로 "최소 노력" 위반. (B) STDOUT→CloudWatch Logs는 로그만 볼 뿐 메모리 덤프 조사 불가. (C) Container Insights는 메트릭·모니터링용, 메모리 덤프 등 컨테이너 내부 직접 조사 불가. 【시험 포인트】실행 중 Fargate 컨테이너 조사(로그·메모리) = ECS Exec + task role SSM 권한.

해설

【핵심 용어】 ▸ SSE-C (customer-provided keys) — 요청 시 클라이언트가 키 제공, x-amz-server-side-encryption-customer-algorithm 헤더로 식별 ▸ SCP Deny + Condition — 조건 미충족 PutObject 거부로 SSE-C 강제 ▸ 조건 키 — s3:x-amz-server-side-encryption-customer-algorithm 등 SSE-C 관련 헤더 조건 (보기 A~D는 이미지(정책 JSON)라 텍스트 없음) 【정답 포인트】 ▸ "SSE-C 강제" → SSE-C 사용 시 전송되는 고객 제공 키 알고리즘 헤더가 존재하지 않을 때 PutObject를 Deny ▸ 즉 s3:x-amz-server-side-encryption-customer-algorithm 조건 키가 없는(null) 업로드를 거부하는 조건이 정답 ▸ 정답(A)은 SSE-C 헤더 부재 시 거부하는 조건을 담은 정책 【오답 체크】 (B)(C)(D) 이미지 기반이라 정확한 조건 문구는 확인 불가하나, SSE-C가 아닌 다른 암호화 방식(SSE-S3의 x-amz-server-side-encryption, SSE-KMS 등) 헤더를 조건으로 삼거나 조건 논리가 SSE-C 강제와 어긋나는 정책으로 판단. 【시험 포인트】SSE-C 강제 = s3:x-amz-server-side-encryption-customer-algorithm 조건. SSE-S3/KMS 조건 키(x-amz-server-side-encryption)와 혼동 주의.

해설

【핵심 용어】 ▸ S3 버킷 정책 Deny + Principal 지정 — 특정 페더레이션 사용자만 대상 지정 거부 ▸ aws:userId / 역할 세션 ARN 조건 — 페더레이션 사용자 Bob을 정확히 식별 ▸ 최소 영향 — Bob의 S3 권한만 거부, 다른 권한은 유지 (보기 A~D는 이미지(정책 JSON)라 텍스트 없음) 【정답 포인트】 ▸ "Bob만 이 버킷 접근 거부 + 다른 권한 유지" → 해당 버킷 정책에 Bob(페더레이션 주체)을 지정한 Deny 문 ▸ 페더레이션 사용자는 IAM 사용자 ARN이 아니라 assumed-role 세션이므로, Bob을 정확히 지정하는 조건(예: aws:userId 또는 역할 세션 ARN)으로 Deny하는 정책이 정답 ▸ 정답(B)은 Bob에 한정된 Deny로 다른 권한에 영향 없음 【오답 체크】 (A)(C)(D) 이미지 기반이라 정확 문구 확인 불가하나, Principal/조건 지정이 부정확해 Bob 외 사용자까지 영향을 주거나(과도한 Deny), 페더레이션 주체 식별 방식이 맞지 않아 Bob을 정확히 겨냥하지 못하는 정책으로 판단. 【시험 포인트】특정 페더레이션 사용자만 버킷 거부 = 버킷 정책에서 Bob을 정확히 식별하는 Deny(과도한 범위 금지). 페더레이션은 assumed-role 세션으로 식별.

해설

【핵심 용어】 ▸ Amazon Cognito user pool + 서드파티 IdP 페더레이션 — 소셜 IdP 등으로 로그인, 비밀번호 관리·재설정 부담을 IdP로 이전 ▸ 관리형 인증 — 자격 증명 보안·비밀번호 재설정을 Cognito·IdP가 처리 ▸ 소셜 로그인 — 사용자가 기존 소셜 계정으로 로그인 【정답 포인트】 ▸ "다른 로그인 수단 제공 + 비밀번호 재설정·로그인 지원 부담 제거 + 자격 증명 안전 보호" → Cognito로 서드파티(소셜) IdP 페더레이션 ▸ Cognito로 인증 이관 시 비밀번호 관리 부담이 IdP로 넘어가 고객 지원 부담 감소 【오답 체크】 (A) 플레이어에게 IAM 액세스 키 발급은 IAM 사용 목적 위반·심각한 보안 위험, 부적합. (B) Secrets Manager는 앱 시크릿 저장용이지 대규모 최종 사용자 인증·로그인 관리 용도가 아님. (D) API 키는 인증 수단으로 부적합하며 비밀번호 재설정 부담 문제를 해결하지 못함. 【시험 포인트】대규모 최종 사용자 인증·비밀번호 부담 경감 = Cognito user pool + 소셜/서드파티 IdP 페더레이션.

해설

【핵심 용어】 ▸ GuardDuty InstanceCredentialExfiltration finding — EC2 인스턴스 역할 자격 증명이 외부 계정/외부에서 사용될 때 탐지 ▸ EC2 인스턴스 메타데이터 자격 증명 탈취 — 과도한 역할 권한 악용 시나리오 ▸ CloudTrail/CloudWatch — 로그 저장이나 이 특정 판단은 GuardDuty가 즉시 제공 【정답 포인트】 ▸ "탈취된 인스턴스 자격 증명이 외부 계정에서 사용됐는지 판단" → GuardDuty의 InstanceCredentialExfiltration finding이 정확히 이 상황을 탐지 ▸ GuardDuty findings 검토로 외부 사용 여부 확인 【오답 체크】 (B) Audit Manager는 규정 준수 감사 리포트용이며 InstanceCredentialExfiltration 이벤트를 생성하지 않음. (C) GetSessionToken은 STS 세션 토큰 발급 호출로 인스턴스 자격 증명 외부 탈취·사용 판단의 직접 지표가 아님(정확도 낮음). (D) CloudWatch 로그에서 GetSessionToken을 뒤지는 방식도 부정확하며, 이 판단은 GuardDuty가 전용 finding으로 제공. 【시험 포인트】EC2 인스턴스 자격 증명이 외부에서 사용됨 = GuardDuty InstanceCredentialExfiltration finding.

해설

【핵심 용어】 ▸ IAM Access Analyzer 정책 생성 — CloudTrail 활동 기반으로 최소 권한 IAM 정책을 자동 생성 ▸ CloudFormation 서비스 역할(Service Role) — 스택 배포 시 CloudFormation이 assume하는 역할, 사용자 권한과 분리 ▸ iam:PassRole — 사용자가 서비스에 역할을 넘겨줄 수 있게 하는 권한 (직무 분리의 핵심) 【정답 포인트】 ▸ "최소 권한" → Access Analyzer 정책 생성으로 스택 운영에 필요한 권한만 담은 정책 작성 ▸ "보안 엔지니어 계정과 CloudFormation 간 직무 분리" → 정책을 별도 IAM 역할에 부여하고, 엔지니어에게는 그 역할을 CloudFormation에 PassRole하는 권한만 부여 (엔지니어 본인은 인프라 권한을 직접 갖지 않음) 【오답 체크】 (B) ec2:*·rds:* 와일드카드는 최소 권한 위배. assume role 방식은 엔지니어가 직접 권한을 갖게 되어 직무 분리 미흡. (C) Access Analyzer는 맞지만 엔지니어가 자기 권한으로 스크립트를 실행 → PassRole/서비스 역할 분리가 없어 직무 분리 실패. (D) ec2:*·rds:* 와일드카드로 최소 권한 위배. Policy Simulator로 검증해도 과도한 권한은 그대로. 【시험 포인트】 "최소 권한 + CloudFormation 직무 분리" → Access Analyzer 생성 정책 + 전용 서비스 역할 + PassRole 조합.

해설

【핵심 용어】 ▸ CloudFormation StackSets — 여러 계정·리전에 표준 템플릿을 중앙에서 배포/공유 ▸ SCP(Service Control Policy) — Organizations에서 계정의 최대 권한을 제한하는 예방적 가드레일 ▸ Permissions Boundary — IAM 주체의 최대 권한 상한 (계정 내부용, 조직 전역 강제엔 부적합) 【정답 포인트】 ▸ "모든 인프라는 CloudFormation 템플릿으로 배포" → 관리자 계정에서 StackSets를 만들어 애플리케이션 계정에 공유하고 사용을 제한 (A) ▸ "승인된 계정에서만 EC2 시작 + DynamoDB 명명 규칙" 같은 조건부 제약 → SCP로 조건을 만족하지 않는 리소스 프로비저닝을 차단 (D) 【오답 체크】 (B) 애플리케이션 계정에서 템플릿을 만들어 출력만 공유하는 방식은 표준화·강제와 무관. (C) Permissions Boundary는 계정 내 IAM 상한 제어용으로 조직 전역 예방 통제로는 SCP보다 부적합. (E) AWS Config 관리형 규칙은 탐지적 통제라 배포를 사전 차단하지 못함. 【시험 포인트】 조직 전역 예방적 강제 = SCP, 표준 인프라 배포 = CloudFormation StackSets 공유.

해설

【핵심 용어】 ▸ Gateway VPC Endpoint — S3·DynamoDB 전용, 라우팅 테이블 기반으로 인터넷 없이 접근 (무료) ▸ Interface VPC Endpoint(PrivateLink) — KMS 등 대부분 서비스용 ENI 기반 엔드포인트, Private DNS로 기본 엔드포인트 이름 사용 ▸ Private DNS — 서비스의 표준 DNS 이름을 VPC 내에서 엔드포인트로 해석 (코드 변경 없이 사용 가능) 【정답 포인트】 ▸ "EC2의 어떤 API 호출도 인터넷 경유 금지 + 코드 변경 없음" → S3는 Gateway 엔드포인트로 프라이빗 접근 (A) ▸ KMS 키로 암복호화하므로 KMS도 프라이빗 경로 필요 → KMS Interface 엔드포인트 + Private DNS 켜서 표준 엔드포인트 이름 그대로 사용, 코드 무변경 (C) 【오답 체크】 (B) S3용 Interface 엔드포인트는 이 시나리오의 표준이 아님(S3는 Gateway가 정석), 불필요. (D) Private DNS를 끄면 표준 KMS 엔드포인트 이름이 해석되지 않아 코드 변경이 필요 → 요구사항 위배. (E) S3 Gateway 엔드포인트는 맞으나 KMS 프라이빗 경로가 빠져 KMS 호출이 인터넷 경유. 【시험 포인트】 "인터넷 경유 금지" → S3=Gateway 엔드포인트, KMS·기타=Interface 엔드포인트(+Private DNS 켬).

해설

【핵심 용어】 ▸ IAM Access Analyzer 정책 생성 — CloudTrail에 기록된 실제 API 활동을 분석해 최소 권한 정책을 자동 생성 ▸ CloudTrail 관리 이벤트 트레일 — 정책 생성의 입력이 되는 활동 로그 소스 ▸ AWS 관리형 정책(FullAccess) — 광범위 권한으로 최소 권한과 배치 【정답 포인트】 ▸ "관리형 FullAccess를 최소 권한 정책으로 교체 + 가장 운영 효율적" → CloudTrail 트레일 생성 후 기존 권한으로 스크립트를 실행해 실제 사용 활동을 수집하고, Access Analyzer가 그 활동 기반으로 정책 자동 생성 → 교체 (A) 【오답 체크】 (B) "Access Analyzer Role Policy Generator를 역할에 연결"은 실제로 존재하지 않는 절차. 권한을 먼저 제거하면 스크립트 실패로 활동 수집 불가. (C) 아카이브 규칙은 외부 액세스 발견물 관리용으로 최소 권한 정책 생성과 무관. (D) CloudTrail의 인가 실패를 하나씩 찾아 수작업 반복하는 방식은 운영 부담이 큼. 【시험 포인트】 "실사용 기반 최소 권한 정책 자동 생성" → CloudTrail 활동 + IAM Access Analyzer 정책 생성.

해설

【핵심 용어】 ▸ AWS Nitro Enclaves — EC2 내부에 격리된 CPU/메모리 실행 환경, 외부 네트워크·영구 저장소·SSH 접근 불가 ▸ 토큰화(Tokenization) — 민감 데이터(카드번호)를 토큰으로 대체해 다른 구성요소가 원본에 접근 못 하게 함 ▸ Attestation — Enclave 무결성 증명으로 KMS 등과 안전하게 연동 【정답 포인트】 ▸ "격리 환경에서 암호화·저장·복호화, 다른 구성요소는 카드번호 접근/저장 불가" → Nitro Enclaves가 부모 인스턴스와도 완전히 격리되어 민감 데이터 처리에 최적 (D) 【오답 체크】 (A) Dedicated Instances는 물리적 하드웨어 격리일 뿐 프로세스/데이터 접근을 차단하지 못함. (B) Partition placement group는 하드웨어 장애 격리용 배치 전략이지 데이터 보안과 무관. (C) 별도 VPC로 나눠도 네트워크 분리일 뿐, 구성요소가 카드번호에 접근하는 것을 근본 차단 못 함. 【시험 포인트】 "민감 데이터의 완전 격리 처리(암복호화·토큰화)" → AWS Nitro Enclaves.

해설

【핵심 용어】 ▸ 역할 신뢰 정책(Trust Policy) — 누가 이 역할을 assume할 수 있는지 정의, sts:AssumeRole에 조건 부여 가능 ▸ aws:MultiFactorAuthPresent — 요청에 MFA 인증이 포함됐는지 검사하는 조건 키 ▸ 권한 정책 vs 세션 정책 — 권한 정책은 역할이 할 수 있는 행동, 세션 정책은 세션 범위 축소용 【정답 포인트】 ▸ "MFA로 인증한 경우에만 역할을 assume 가능" → assume 자체를 통제하는 곳은 신뢰 정책이므로 신뢰 정책에 aws:MultiFactorAuthPresent 조건 추가 (B). 최소 위험·노력으로 요구 충족. 【오답 체크】 (A) 권한 정책은 이미 assume한 뒤의 행동을 통제 → assume 자체를 MFA로 막지 못함. (C) 세션 정책은 assume 시점에 전달되는 것으로, MFA 강제의 표준 위치가 아니며 관리 부담 큼. (D) S3 버킷 정책은 S3 접근만 제어, 역할 assume 통제와 무관. 【시험 포인트】 "역할 assume에 MFA 강제" → 역할 신뢰 정책에 aws:MultiFactorAuthPresent 조건.

해설

【핵심 용어】 ▸ Amazon GuardDuty — 위협 탐지 서비스, 자격증명 유출 등 findings 생성 ▸ InstanceCredentialExfiltration.OutsideAWS — 인스턴스 자격증명이 AWS 외부(코드 저장소 등)에서 사용된 정황 탐지 finding ▸ EventBridge + SNS — findings를 이벤트로 받아 이메일 알림 전송 【정답 포인트】 ▸ "개발 계정의 AWS 액세스 키가 코드 저장소에 노출되면 자동 이메일 알림" → GuardDuty의 UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS finding을 EventBridge 규칙으로 잡아 SNS 이메일 전송 (A) 【오답 체크】 (B) 계정 연락처 이메일을 폴링하는 방식은 키 유출 탐지 기능이 아니며 자동 알림도 아님. (C) AWS Health 이벤트는 서비스 상태·유지보수 알림용으로 자격증명 노출 탐지와 무관. (D) ConsoleLogin 모니터링은 콘솔 로그인 이상 탐지용으로 코드 저장소의 키 노출을 직접 잡지 못함. 【시험 포인트】 "노출된 자격증명/키 탐지" → GuardDuty Credential Exfiltration finding + EventBridge + SNS.