정답 · 해설

해설

【핵심 용어】 ▸ SCP + aws:RequestedRegion — 지정 리전 외 액션을 조직/계정 차원에서 Deny ▸ 리전 제한 가드레일 — 사용자·주체별 IAM 관리 없이 계정 전체 강제 ▸ 최소 운영 부담 — 조직 SCP 하나로 통일 적용 【정답 포인트】 ▸ "다른 리전 리소스 시작 방지" + "최소 운영 부담" → aws:RequestedRegion이 지정 리전이 아니면 Deny하는 SCP를 Organizations의 계정에 부착 → D가 정답 【오답 체크】 (A) 모든 사용자에게 IAM 정책을 붙이는 방식은 주체마다 관리해야 해 운영 부담·누락 위험. (B) IAM 정책은 AWS 계정 자체에 부착할 수 없음(SCP가 계정/OU에 부착). (C) 특정 사용자에게만 Allow 정책을 붙이는 방식은 커버리지·운영성이 낮음. 【시험 포인트】 리전 사용 제한 + 최소 운영 → SCP + aws:RequestedRegion Deny(계정/OU 부착). IAM 정책은 계정에 직접 부착 불가.

해설

【핵심 용어】 ▸ 크로스 계정 S3 접근 — 리소스(버킷) 측의 리소스 기반 정책과 요청자 측 IAM 정책이 모두 필요 ▸ S3 bucket policy — Account B(리소스 소유 계정)에서 Account A 사용자에게 접근 허용 ▸ 양방향 권한 — Account A IAM만으로는 부족, Account B 버킷 정책이 있어야 함 【정답 포인트】 ▸ Account A IAM 권한을 줬는데도 접근 불가 → 리소스 계정(B)의 허용이 없기 때문 ▸ Account B에서 버킷 정책으로 Account A 사용자에게 접근 허용 → C가 정답 【오답 체크】 (A) 버킷 ACL은 레거시·제한적 수단이며 사용자 단위 세밀한 크로스 계정 접근 부여에 부적합. (B) 객체 ACL 역시 레거시 방식으로 권장되지 않고 요구를 안정적으로 충족 못 함. (D) "user policy in Account B"는 Account A 사용자에게 적용되지 않음(주체가 다른 계정 소속). 【시험 포인트】 크로스 계정 S3 접근 = 요청자 계정 IAM 정책 + 리소스 계정 버킷 정책(둘 다). 리소스 소유 계정의 버킷 정책이 핵심.

해설

【핵심 용어】 ▸ Amazon GuardDuty — C2/봇넷 통신 등 의심스러운 통신 탐지 ▸ AWS Network Firewall — 네트워크 레벨에서 특정 IP 트래픽(수신·발신) 차단, IP 기반 규칙 그룹 ▸ DynamoDB + Lambda + Step Functions — 악성 IP 목록 관리 및 방화벽 규칙 자동 갱신 오케스트레이션 【정답 포인트】 ▸ 알려진 C2 서버 IP로/에서의 트래픽을 대규모 자동 차단 → GuardDuty 탐지 + DynamoDB에 악성 IP 저장 + Lambda가 Network Firewall 규칙 그룹을 갱신해 차단 → B가 정답 ▸ (IP 기반 in/out 차단은 네트워크 레벨의 Network Firewall이 적합) 【오답 체크】 (A)(C) WAF web ACL은 웹(HTTP/S) 레이어 차단으로, 임의 IP의 수신·발신 네트워크 트래픽 차단에 부적합. (C) Inspector는 취약점 평가로 의심 통신 탐지 도구가 아님. (D) Traffic Mirroring + Inspector 에이전트 구성은 과도하고 Inspector가 C2 통신 탐지용이 아님(탐지는 GuardDuty). 【시험 포인트】 악성 IP(C2) in/out 차단 → GuardDuty 탐지 + Network Firewall 규칙(네트워크 레벨). WAF는 웹 레이어라 임의 IP 트래픽 차단에 부적합.

해설

【핵심 용어】 ▸ Systems Manager Session Manager — SSM Agent가 아웃바운드로 SSM 서비스에 연결해 셸 접속 제공 (인바운드 포트/키페어 불필요) ▸ VPC Interface Endpoint (ssmmessages/ssm/ec2messages) — 프라이빗 서브넷에서 인터넷 없이 SSM 연결하려면 필요 ▸ ssmmessages 엔드포인트 — Session Manager 세션 데이터 채널 담당 【정답 포인트】 ▸ "프라이빗 서브넷 + 새 VPC + IAM 프로파일 정상" → 남은 원인은 SSM으로 나가는 경로 ▸ Session Manager는 ssmmessages 엔드포인트(또는 NAT/IGW)가 있어야 연결 → 신규 VPC에 엔드포인트 미구성이 근본 원인 【오답 체크】 (A) Session Manager는 키페어를 사용하지 않으므로 무관. (B) Session Manager는 인바운드 22번 포트가 필요 없음 (아웃바운드 연결). (D) Amazon Linux 2는 SSM Agent가 기본 설치되어 있음. 【시험 포인트】 프라이빗 서브넷 Session Manager 연결 실패 → ssmmessages/ssm/ec2messages VPC 엔드포인트 확인.

해설

【핵심 용어】 ▸ CloudTrail Organizational Trail — Organizations 전체 계정의 API 활동을 단일 트레일로 로깅 ▸ CloudWatch Logs Metric Filter + Alarm — 로그 패턴 매칭 후 임계값 알람 생성 ▸ Amazon SNS — 이메일 배포 목록으로 알림 전달 (SQS는 이메일 미지원) 【정답 포인트】 ▸ "Organizations 전 계정 로깅" → organizational trail ▸ "거의 실시간 이메일 알림" → CloudWatch Logs 전달 + 메트릭 필터 + 알람 → SNS(이메일) 【오답 체크】 (B) organizational trail이 아니라 전 계정 커버 불가, SQS는 이메일 배포 부적합. (C) EC2가 S3를 파일시스템 마운트해 폴링하는 방식은 복잡·비실시간. (D) 매시간 Glue+Athena 쿼리는 배치성이라 실시간 알림 요건 미충족. 【시험 포인트】 "전 계정 + 실시간 알림 이메일" → organizational trail + CloudWatch metric filter/alarm + SNS.

해설

【핵심 용어】 ▸ CloudTrail → CloudWatch Logs — API 이벤트(보안 그룹 변경 등)를 로그로 전달 ▸ Metric Filter + CloudWatch Alarm — 특정 이벤트 패턴 감지 시 알람 ▸ AWS Config Remediation — 규정 준수 평가/수정용이나 알림에는 수동 단계 필요 【정답 포인트】 ▸ "보안 그룹 변경 시 특정 이메일로 알림" + "운영 효율 최대" → CloudTrail→CloudWatch Logs 메트릭 필터→알람→SNS가 직접적·자동 【오답 체크】 (A) Config의 수동(manual) 수정 액션은 자동 알림이 아니며 SNS 전달 구조가 우회적. (B) 수동 수정 + SQS는 이메일 알림에 부적합. (D) CloudTrail→S3→Glue→Athena 쿼리 후 SQS는 배치성·비효율, 실시간 알림 아님. 【시험 포인트】 리소스 변경 실시간 이메일 알림 → CloudTrail + CloudWatch Logs metric filter + alarm + SNS.

해설

【핵심 용어】 ▸ CloudTrail → CloudWatch Logs — ConsoleLogin 이벤트를 로그로 전달 ▸ Metric Filter — eventName=ConsoleLogin, errorMessage="Failed authentication" 패턴 매칭 ▸ CloudWatch Alarm — 임계값 3, 기간 5분으로 로그인 실패 감지 【정답 포인트】 ▸ "5분 내 3회 이상 콘솔 로그인 실패 알림" → CloudTrail을 CloudWatch Logs로 보내고 메트릭 필터로 실패 이벤트 카운트, 알람 threshold 3 / period 5분 【오답 체크】 (A) CloudTrail Insights는 API 호출량 이상 탐지용이지 특정 실패 로그인 카운트 알람에 부적합. (C) Athena는 쿼리 기반이며 "쿼리에서 알림 액션 생성" 기능이 없음. (D) IAM Access Analyzer는 외부 접근 리소스 분석용이지 로그인 실패 알림 기능 없음. 【시험 포인트】 임계값/기간 기반 로그인 실패 알림 → CloudWatch Logs metric filter + alarm.

해설

【핵심 용어】 ▸ S3 Block Public Access — 버킷/계정 수준 퍼블릭 액세스 차단, 퍼블릭 노출 방지의 핵심 ▸ SSE-KMS — KMS 키로 서버측 암호화, 키 정책으로 접근 통제 계층 추가 ▸ S3 Storage Lens / Macie — 가시성·민감정보 탐지용(예방 아님) 【정답 포인트】 ▸ "데이터 퍼블릭 노출 방지" 조합 → (A) Block Public Access로 퍼블릭 접근 원천 차단 ▸ (B) SSE-KMS로 암호화 + KMS 키 정책 접근 통제를 강제해 무단 노출 방지 계층 강화 【오답 체크】 (C) SSE-S3는 키 정책 기반 접근 통제 계층이 없어 노출 방지 강화 효과가 SSE-KMS보다 약함. (D) Storage Lens는 사용 현황 분석 대시보드로 예방 조치가 아님. (E) Macie는 민감정보 탐지·모니터링이지 노출 예방 조치가 아님. 【시험 포인트】 S3 퍼블릭 노출 방지 → Block Public Access가 1순위, 암호화 강제(SSE-KMS)가 보완.

해설

【핵심 용어】 ▸ aws:SecureTransport 조건 키 — 요청이 HTTPS(TLS)인지 여부 (false면 HTTP) ▸ S3 Bucket Policy Deny — 조건 기반으로 비암호화 전송 요청 차단 ▸ 전송 중 암호화(encryption in transit) — TLS로 데이터 보호 【정답 포인트】 ▸ "전송 중 암호화되지 않은 업로드 방지" → 버킷 정책에 aws:SecureTransport=false 조건으로 모든 S3 액션 Deny → HTTP 요청 강제 차단 【오답 체크】 (A) 클라이언트 구현 규약은 강제성이 없어 우회 가능, 기술적 통제 아님. (B) s3-bucket-ssl-requests-only Config 규칙은 탐지(감사)일 뿐 차단하지 못함. (D) WRITE 권한을 AllUsers에게 부여하는 ACL은 오히려 위험하고 secureTransport 조건도 ACL에 없음. 【시험 포인트】 HTTPS 강제 → 버킷 정책 Deny + "aws:SecureTransport": "false".

해설

【핵심 용어】 ▸ Service Control Policy (SCP) — Organizations OU/계정에 최대 권한 경계(가드레일) 강제 ▸ aws:RequestedRegion 조건 — 허용 리전 제한 ▸ NotAction/Condition/Resource 요소 — 특정 서비스·리전만 허용하도록 범위 지정 【정답 포인트】 ▸ "각 계정이 특정 리전·특정 서비스만 사용" + "운영 오버헤드 최소" → SCP로 조직 전체 가드레일 한 번에 강제, 계정별 개별 정책 관리 불필요 【오답 체크】 (A) service-linked role은 사용자가 임의 정책을 붙이는 대상이 아니며 리전 제한 수단이 아님. (B) STS 리전 비활성화는 리전/서비스 세분 제한이 불가하고 관리 부담 큼. (D) 계정마다 SSO 자격 증명 기반 정책을 개별 작성하면 오버헤드가 큼. 【시험 포인트】 다계정 리전·서비스 가드레일 최소 오버헤드 → SCP.

해설

【핵심 용어】 ▸ 교차 계정 KMS 접근 — 키 소유 계정의 키 정책 + 사용 계정의 IAM 정책 양쪽 필요 ▸ Key Policy — KMS 키의 기본 권한 원천, 외부 계정 프린시펄 허용은 여기서 ▸ IAM Policy(사용 계정) — 프린시펄이 키를 호출할 수 있도록 위임 【정답 포인트】 ▸ "security 계정 KMS 키를 development 계정 새 Lambda가 사용" → 이중 승인 필요 ▸ (C) development 계정에서 Lambda 역할에 KMS 키 사용을 허용하는 IAM 정책 부여 ▸ (E) security 계정 키 정책에서 development 계정의 Lambda 역할을 허용 【오답 체크】 (A) 새 Lambda의 IAM 역할은 실행되는 development 계정에 있어야 함(security 계정 아님). (B) 개발 계정 역할에 "key policy"를 붙일 수 없음(키 정책은 키에 부착). (D) security 계정 내 역할을 허용하는 것으로는 development 계정 Lambda가 접근 불가. 【시험 포인트】 교차 계정 KMS → 키 소유 계정 key policy + 사용 계정 IAM policy 둘 다.

해설

【핵심 용어】 ▸ IAM Policy Deny + Condition — 특정 조건 외 접근 거부로 강제 ▸ aws:SourceVpce 조건 키 — 지정 VPC 엔드포인트 경유 여부 검사 ▸ StringNotEquals — 지정 엔드포인트가 아니면 Deny 【정답 포인트】 ▸ "vpce-11aa22bb 엔드포인트를 통하지 않으면 DynamoDB 거부" → Deny 효과 + aws:SourceVpce가 지정 값과 다를 때(StringNotEquals) DynamoDB 액션 거부하는 정책 【오답 체크】 (정답이 아닌 보기) 이미지 정책들은 Effect(Allow/Deny) 방향이 반대이거나, 조건 키/연산자(예: StringEquals vs StringNotEquals)가 요건과 어긋나거나, 리전 조건이 누락되어 "엔드포인트 미경유 시 거부" 로직을 정확히 강제하지 못함. 【시험 포인트】 특정 엔드포인트만 허용 → Deny + StringNotEquals aws:SourceVpce 조합 확인.

해설

【핵심 용어】 ▸ iam:DeleteVirtualMFADevice — 가상 MFA 디바이스 삭제 권한 ▸ MFA 조건(aws:MultiFactorAuthPresent) — 사용자 정책이 MFA 인증 상태에서만 자기 디바이스 삭제 허용 ▸ 고장난 MFA — 사용자가 MFA로 로그인할 수 없어 자기 정책의 삭제 권한을 쓸 수 없음 【정답 포인트】 ▸ 보안 엔지니어 역할은 삭제/조회/생성 권한이 있으나 오류 발생 → CLI/API로 가상 MFA 디바이스의 ARN을 조회해 삭제하면 엔지니어 역할 권한으로 처리 가능 【오답 체크】 (A) 사용자 정책의 MFA 조건 완화는 보안 약화이며 근본 해결이 아님. (B) 루트로 QR 재생성은 고장 디바이스 교체 요건과 어긋남. (D) 루트 로그인은 최소권한 위배이며 굳이 필요 없음(엔지니어 역할로 가능). 【시험 포인트】 권한 있는 역할이 콘솔에서 막힐 때 → CLI/API로 ARN 지정 삭제.

해설

【핵심 용어】 ▸ Lambda Execution Role — 각 Lambda 함수가 assume하는 IAM 역할, 함수별 권한 격리 ▸ KMS Key 사용 권한(kms:Decrypt 등) — 실행 역할에 부여 ▸ SSE-KMS 고객 관리 키 — S3 데이터 암호화 【정답 포인트】 ▸ "함수마다 독립된 프로그램적 접근 제어로 KMS 키 사용" → 함수별 Lambda 실행 역할에 KMS 키 사용 권한을 세분 부여 【오답 체크】 (A) Lambda는 IAM 사용자로 실행하지 않음(실행 역할 사용) — 부적합. (B) 서비스 프린시펄 대상 grant는 함수별 개별 접근 제어가 되지 않음. (D) S3용 AWS 관리형 KMS 키는 문제의 고객 관리 키가 아니며 세분 통제 불가. 【시험 포인트】 Lambda 권한 격리 → 함수별 실행 역할(execution role).

해설

【핵심 용어】 ▸ AWS IoT Core Policy 변수 ${iot:Connection.Thing.ThingName} — 등록된 Thing 이름으로 client ID 강제 바인딩 ▸ ${iot:ClientId} — 클라이언트가 임의로 지정 가능해 위조/특수문자 주입에 취약 ▸ iot:Connect 리소스 제한 — 연결 시 client ID를 Thing 이름과 일치하도록 정책 통제 【정답 포인트】 ▸ (A) 앱이 IoT thing name을 client ID로 사용해 연결 ▸ (E) iot:Connect 정책의 리소스를 client/${iot:Connection.Thing.ThingName}으로 제한 → 등록된 Thing 이름과 일치하는 client ID만 연결 허용, 특수문자 위조 차단 【오답 체크】 (B) 앱 측 클라이언트 검사는 트로이목마가 앱을 위장하면 우회됨(신뢰 불가). (C) AWSIoTWirelessDataAccess는 무선(LoRaWAN) 데이터 접근용으로 MQTT client 통제와 무관. (D) ${iot:ClientId}는 클라이언트가 임의 지정 가능해 정책 통제 효과가 없음. 【시험 포인트】 IoT client ID 위조 방지 → Thing 이름 기반 ${iot:Connection.Thing.ThingName} 정책 변수.

해설

【핵심 용어】 ▸ CloudFront Custom Origin Header — CloudFront가 오리진(ALB)에 비밀 커스텀 헤더 주입 ▸ ALB Listener Rule — 특정 커스텀 헤더 포함 요청만 전달, 나머지 거부 ▸ 오리진 보호 — CloudFront 우회 직접 접근 차단 【정답 포인트】 ▸ (B) CloudFront가 ALB로 보내는 요청에 커스텀 HTTP 헤더 추가 ▸ (C) ALB가 해당 커스텀 헤더가 있는 요청만 전달하도록 규칙 구성 → CloudFront 경유 트래픽만 EC2 도달 【오답 체크】 (A) cache key policy는 캐시 키 구성용이지 오리진 접근 통제 수단이 아님. (D) X-Forwarded-For 클라이언트 IP 확인은 위조 가능하고 직접 접근 차단이 안 됨. (E) 동일 ACM 인증서 공유는 오리진 직접 접근을 막지 못함. 【시험 포인트】 CloudFront만 오리진 접근 → 비밀 커스텀 헤더 주입 + 오리진(ALB/WAF)에서 헤더 검증.

해설

【핵심 용어】 ▸ Amazon CloudFront — EC2/S3 오리진 앞단 CDN, 저지연 전송 + TLS ▸ Lambda@Edge — 엣지에서 응답 헤더 조작(HTTP 보안 헤더 추가), 앱 코드 변경 불필요 ▸ HTTP 보안 헤더 — 감사 통과를 위한 보안·프라이버시 헤더 추가 【정답 포인트】 ▸ (D) CloudFront 배포를 만들어 EC2·S3 오리진 앞단에 두어 저지연 전송 ▸ (C) Lambda@Edge로 오리진 응답에 HTTP 보안 헤더 추가 → 코드 변경 없이 보안 감사 요건 충족 【오답 체크】 (A) API Gateway 캐싱은 저지연 콘텐츠 전송/보안 헤더 요건과 초점이 다름. (B) API Gateway Lambda 오소라이저는 인증용이며 보안 헤더 추가 용도가 아님. (E) ALB의 connection 헤더 처리는 보안 헤더 추가·저지연 CDN 요건과 무관. 【시험 포인트】 코드 변경 없이 보안 헤더 + 저지연 → CloudFront + Lambda@Edge(응답 헤더).

해설

【핵심 용어】 ▸ KMS 고객 관리 키(CMK) — 연 1회 자동 키 로테이션 지원 (SSE-S3는 매년 로테이션 구성 불가, 자동 3년 주기) ▸ SSE-KMS — S3 버킷 기본 암호화 ▸ S3 Batch Operations COPY — 기존 객체를 새 키로 재암호화(제자리 복사) 【정답 포인트】 ▸ "버킷·객체 암호화 + 연 1회 키 로테이션" → CMK 생성 후 연간 자동 로테이션 활성화, SSE-KMS 버킷 암호화 ▸ 기존 객체는 S3 Batch Operations COPY로 CMK 재암호화, EC2 인스턴스 프로파일에 키 사용 권한 부여 【오답 체크】 (A) SSE-S3는 "연간 자동 키 로테이션" 구성이 불가하며 "S3 data events 암호화" 표현도 부정확. (B) 기존 객체를 재암호화하는 단계가 없어 "모든 객체 암호화" 요건 미충족. (D) SSE-S3는 연간 로테이션 구성 불가, CLI 제자리 복사 방식도 요건과 어긋남. 【시험 포인트】 연 1회 키 로테이션 요구 → SSE-KMS CMK(자동 로테이션) + 기존 객체 Batch Operations COPY.

해설

【핵심 용어】 ▸ IMDSv2 강제 — SCP의 ec2:MetadataHttpTokens 조건으로 IMDSv1 인스턴스 차단 ▸ Service Control Policy — Organizations 전체에 IMDSv1 사용 금지 가드레일 ▸ 인스턴스 메타데이터 옵션 — HttpTokens=required면 IMDSv2 강제 【정답 포인트】 ▸ "IMDSv1 자격 증명을 절대 사용하지 못하게" + Organizations → 루트 OU에 SCP를 붙여 IMDSv1로 실행되는 인스턴스를 조직 전역 차단(정답 D 정책이 요건에 맞는 조건 구성) 【오답 체크】 (A) 169.254.169.254 대상 보안 그룹 규칙은 링크로컬 주소라 SG로 통제 불가(무효). (B) 콘솔/CLI로 개별 비활성화는 강제성이 없고 조직 전체 보장 불가. (C) 동일 SCP 첨부이나 정책 조건이 IMDSv1 차단 요건을 정확히 강제하지 못함(D가 올바른 조건). 【시험 포인트】 조직 전역 IMDSv1 금지 → SCP + ec2:MetadataHttpTokens=required 조건.

해설

【핵심 용어】 ▸ DNSSEC 신뢰 체인 — 상위(부모) 존이 하위 존의 KSK를 신뢰하도록 DS 레코드로 연결 ▸ KSK(Key-Signing Key) — 존의 키 세트에 서명, 이 해시가 DS 레코드로 부모에 등록됨 ▸ DS(Delegation Signer) 레코드 — 부모 호스팅 존에 생성해 신뢰 체인 완성 【정답 포인트】 ▸ "broken trust chain" → 하위 존 KSK에 대응하는 DS 레코드가 부모 존에 없어서 발생 → 부모 호스팅 존에 DS 레코드 생성으로 해결 【오답 체크】 (A) Route 53은 ZSK를 자동 관리하며 KSK를 ZSK로 대체하는 것은 개념 오류. (B) KSK 비활성/활성 토글은 신뢰 체인 미연결 문제를 해결하지 못함. (D) DS 레코드는 하위(subdomain) 존이 아니라 부모 존에 생성해야 함. 【시험 포인트】 DNSSEC 신뢰 체인 깨짐 → 부모 호스팅 존에 DS 레코드 추가.