정답 · 해설

해설

【핵심 용어】 ▸ VPC 피어링 + 보안 그룹 크로스 리전 참조 제약 — 서로 다른 리전 간에는 SG를 소스로 참조 불가 ▸ 크로스 리전 VPC 피어링 접근 — 원격 리전의 SG ID 대신 서브넷/IP CIDR을 소스로 지정해야 함 ▸ Aurora DB SG 인바운드 — 접근을 허용할 소스(서브넷 CIDR)를 인바운드에 추가 【정답 포인트】 ▸ us-east-1 DB와 us-west-2 ASG가 크로스 리전 피어링 상태 → SG 크로스 리전 참조 불가하므로, DB 인스턴스 SG 인바운드에 us-west-2 ASG가 사용하는 서브넷(CIDR)을 추가하는 것이 최소 노력의 방법 (인스턴스가 계속 교체돼도 서브넷 범위로 커버) 【오답 체크】 (A) DB SG ID를 EC2 SG 인바운드에 넣는 것은 방향·논리가 반대이고 크로스 리전 SG 참조도 불가. (C) 개별 EC2 사설 IP를 추가하는 방식은 인스턴스가 계속 추가/삭제되므로 유지 불가(최소 노력 아님). (D) EC2 SG ID를 DB SG 인바운드에 참조하는 방식은 크로스 리전 SG 참조 불가로 동작하지 않음. 【시험 포인트】 크로스 리전 VPC 피어링에서는 SG ID 참조 불가 → 원격 서브넷 CIDR을 SG 인바운드에 지정. 개별 IP는 ASG 변동으로 비현실적.

해설

【핵심 용어】 ▸ IAM 액세스 키 노출(AWS Abuse 통지) — 무효화 + 신규 키 발급 + 애플리케이션 갱신 필요 ▸ 다운타임 최소화 순서 — 새 키를 만들고 앱을 먼저 갱신한 뒤 노출 키를 비활성화해야 서비스 중단 방지 ▸ STS 임시 자격 증명 취소 — 노출 키로 발급된 임시 세션 무효화 【정답 포인트】 ▸ 정답(A) 순서: (1) 노출 IAM 사용자의 콘솔 자격 증명 삭제 → (2) 새 액세스 키/시크릿 키 쌍 생성 → (3) 애플리케이션을 새 자격 증명으로 업데이트 → (4) 노출된 IAM 액세스 키 비활성화 → (5) 관련 STS 임시 자격 증명 취소. 새 키로 앱을 먼저 전환한 뒤 노출 키를 비활성화해 프로덕션 다운타임을 최소화 【오답 체크】 (B)(C)(D) 노출 키를 앱 갱신 이전에 비활성화하거나, 새 키 적용 순서가 뒤엉켜 애플리케이션이 유효 자격 증명 없이 동작하는 구간이 생김 → 다운타임 발생으로 요건 위배. 【시험 포인트】 노출 키 대응(무중단): 새 키 생성 → 앱 갱신 → 그 다음 노출 키 비활성화 → STS 세션 취소. 앱 갱신 전 비활성화는 다운타임 유발.

해설

【핵심 용어】 ▸ 하이브리드 연결 요건 — 온프렘 DB + AWS 앱, 지연 민감 + IPsec 암호화 필요 ▸ AWS Direct Connect — 전용 회선으로 낮고 일관된 지연(latency) 제공 (단, 자체로는 암호화 아님) ▸ AWS Site-to-Site VPN — IPsec 암호화 터널 제공 (인터넷/DX 위에 구성 가능) 【정답 포인트】 ▸ (B) Direct Connect → 지연에 민감한 DB 트래픽에 낮고 안정적인 네트워크 지연 제공 ▸ (A) Site-to-Site VPN → IPsec 암호화 요건 충족. DX 위에 VPN을 얹으면 "낮은 지연 + IPsec 암호화"를 동시에 달성 【오답 체크】 (C) VPN CloudHub는 다수 지점 간 허브형 VPN용, 단일 온프렘-AWS 저지연 요건에 부적합. (D) VPC 피어링은 AWS VPC 간 연결로 온프렘 연결 수단이 아님. (E) NAT 게이트웨이는 아웃바운드 인터넷용, 암호화·저지연 하이브리드 연결과 무관. 【시험 포인트】 "저지연 + IPsec" 하이브리드 = Direct Connect(저지연) + Site-to-Site VPN(IPsec 암호화) 조합.

해설

【핵심 용어】 ▸ Security Hub 위임 관리자 + 커스텀 탐지 — 조직 전반 커스텀 보안 탐지·자동 조치 ▸ Security Hub Custom Actions — 발견 항목에 대해 EventBridge로 커스텀 액션 트리거해 Lambda 자동 조치 ▸ EventBridge + Lambda + SNS — 근실시간 탐지·평가·자동 교정·알림 파이프라인 【정답 포인트】 ▸ "조직 전체 커스텀 보안 탐지의 근실시간 자동 교정" → 위임 관리자 계정에서 Security Hub Custom Actions를 만들고, EventBridge 규칙으로 Lambda를 호출해 리소스 구성을 평가·비준수 항목을 Security Hub로 보내고, 다시 EventBridge/Lambda로 자동 교정 후 SNS 알림·Security Hub 발견 항목 업데이트 【오답 체크】 (B)(C) Security Hub Insights(그룹화된 발견 요약)를 자동 교정 트리거로 파싱하는 방식은 근실시간 커스텀 탐지·조치 흐름에 부적합. (D) AWS Config 위임 관리자·집계기·커스텀 규칙 방식은 Config 중심으로, 문항이 요구하는 Security Hub 기반 커스텀 탐지·근실시간 자동 대응 구조와 다름. 【시험 포인트】 "Security Hub 커스텀 탐지 근실시간 자동 교정" → Custom Actions + EventBridge + Lambda(+SNS). Insights는 요약 뷰로 자동화 트리거에 부적합.

해설

【핵심 용어】 ▸ KMS 키 관리 분리 — 보안팀이 관리자(key administrators), 앱팀은 일시적 사용만 필요 ▸ KMS Grant(키 그랜트) — 특정 principal에 CMK 사용을 임시 위임, 필요 없을 때 revoke로 회수 (최소 오버헤드) ▸ 키 정책 vs 그랜트 — 잦은 임시 부여/회수에는 그랜트가 적합 【정답 포인트】 ▸ "앱팀에 CMK 임시 사용 부여, 최소 오버헤드" → key grant를 생성해 앱팀이 CMK를 사용하게 하고, 불필요 시 grant를 revoke. 관리자 권한은 보안팀에 유지되며 임시 사용만 위임(가장 가벼움) 【오답 체크】 (A) 키 자료를 온프렘 HSM으로 내보내는 것은 관리형 CMK에서 불가·부적절하고 오버헤드 큼. (B) 키 정책에 앱팀 principal을 넣고 되돌리는 방식은 정책 수정 반복으로 오버헤드·위험 큼. (D) 온프렘 키 자료 생성·임포트 반복은 매우 번거롭고 요건(최소 오버헤드)에 정반대. 【시험 포인트】 "CMK 임시 사용 위임, 최소 오버헤드" → KMS Grant 생성 후 필요 없으면 revoke. 키 정책 수정은 오버헤드 큼.

해설

【핵심 용어】 ▸ SSH 키 사용 방지 + 비상 시 접근 + 명령 감사 로깅 ▸ Systems Manager Session Manager — 키 없이 접근, 세션 명령을 S3/CloudWatch Logs에 기록(감사) ▸ SSM 인스턴스 역할 — 인스턴스가 SSM 관리 대상이 되도록 역할 부여, 사용자에겐 Session Manager IAM 권한 【정답 포인트】 ▸ "SSH 키 사용 방지 + 비상 접근 + 실행 명령 기록" → Session Manager 사용, 세션 로깅을 S3 버킷에 저장하도록 구성, 인스턴스에 SSM 관리 IAM 역할 부여, 관리자 IAM 계정에 Session Manager 사용 권한 부여 【오답 체크】 (A) EC2 시리얼 콘솔은 비상 콘솔 접근용으로 명령 감사 로깅을 S3에 저장하는 구성이 성립하지 않음. (B) EC2 Instance Connect는 결국 임시 SSH 키를 주입하는 방식이라 "SSH 키 사용 방지"에 부합하지 않음. (C) EC2 키 페어를 사용하는 방식 자체가 SSH 키 사용 방지 요건 위배. 【시험 포인트】 "SSH 키 없이 접근 + 명령 감사" → Session Manager + 세션 로깅(S3/CloudWatch Logs). Instance Connect는 SSH 키 주입이라 부적합.

해설

【핵심 용어】 ▸ ALB TLS 종료 — ALB 리스너에 인증서 지정해 데이터 전송 암호화 종료 ▸ ACM 인증서 획득 경로 — (1) ACM에서 직접 공용 인증서 요청, 또는 (2) 외부 CA 서명 인증서를 ACM으로 임포트 ▸ ALB 리스너 인증서 지정 — ACM에 있는 인증서를 TLS 리스너에 연결 【정답 포인트】 ▸ (B) ACM에서 인증서를 요청하고 ALB TLS 리스너에 지정 → 가장 단순한 관리형 경로 ▸ (A) TLS 도구로 CSR 생성 → CA 서명 인증서 획득 → ACM에 임포트 → ALB 리스너에 지정 → 외부 CA 인증서를 사용하는 유효 경로 【오답 체크】 (C) KMS 도구로 CSR을 생성한다는 것은 부정확(KMS는 인증서/CSR 생성 도구가 아님). (D) ECS 클러스터의 "자동 TLS" 후 ALB가 TLS 연결을 컨테이너로 통과시키는 구성은 존재하지 않음/부정확. (E) ECS 클러스터 생성 중 인증서를 생성한다는 것은 성립하지 않는 개념. 【시험 포인트】 ALB TLS 인증서 = ACM에서 요청(공용) 또는 외부 CA 서명 후 ACM 임포트. KMS로 CSR 생성/ECS 자동 TLS는 오답.

해설

【핵심 용어】 ▸ CloudFront Origin Access Identity(OAI) — CloudFront 전용 특수 아이덴티티, S3 버킷을 OAI에만 허용해 직접 접근 차단 ▸ S3 버킷 정책 — OAI를 principal로 허용, 퍼블릭 접근 차단 ▸ (OAC가 신형이나 문항 선택지 기준 OAI가 정답) 【정답 포인트】 ▸ "S3 파일 직접 퍼블릭 접근 불가 + CloudFront로만 제공" → OAI를 만들어 CloudFront 배포에 연결하고, S3 버킷 권한을 OAI만 접근 가능하도록 설정 → CloudFront 경유만 허용 【오답 체크】 (A) 개별 파일 권한 설정은 관리 부담이 크고 CloudFront 전용 접근 보장 방식이 아님. (C) CloudFront 배포가 IAM 역할을 assume하는 방식은 S3 오리진 접근 메커니즘이 아님. (D) 버킷 정책에서 배포 ID를 principal로 쓰는 것은 유효한 principal 형식이 아님(OAI/OAC ARN이어야 함). 【시험 포인트】 "S3 직접 접근 차단 + CloudFront로만 서빙" → OAI(또는 OAC) 생성 후 버킷 정책으로 해당 아이덴티티만 허용.

해설

【핵심 용어】 ▸ SSM Parameter Store SecureString — KMS 암호화로 토큰 저장(at rest), 표준 파라미터는 무료로 저비용 ▸ Secrets Manager — 유사 기능이나 시크릿당 과금(회전 불필요 시 상대적 고비용) ▸ Lambda 런타임 조회 — SDK로 파라미터 값 조회해 사용 【정답 포인트】 ▸ "액세스 토큰을 저장 시 암호화하고 런타임에 Lambda로 전달 + 가장 비용 효율적" → SSM Parameter Store에 SecureString으로 저장하고 Lambda에서 SDK로 값 조회 (회전 불필요·저비용) 【오답 체크】 (A) Secrets Manager도 가능하나 시크릿당 과금으로 회전 불필요 시 비용 효율성이 낮음. (B) 토큰 기반 Lambda authorizer는 API 호출자 인증용이지 SaaS 토큰을 암호화 저장·전달하는 용도가 아님. (D) KMS로 암호화한 토큰을 환경 변수로 전달하는 방식은 관리 복잡·환경 변수 노출 위험이 있어 Parameter Store보다 부적절. 【시험 포인트】 "토큰 암호화 저장 + 런타임 조회, 최저 비용" → SSM Parameter Store SecureString. 회전 필요 시에만 Secrets Manager.

해설

【핵심 용어】 ▸ AWS Glue Data Catalog 리소스 정책 — 크로스 계정으로 특정 테이블/S3 객체 접근 부여 ▸ Glue + Athena 크로스 계정 — Data Catalog 리소스 정책으로 대상 .csv만 공유 ▸ 세밀 제어 — 같은 폴더 내 다른 파일은 접근 불가하도록 특정 객체만 부여 【정답 포인트】 ▸ "다른 계정 사용자가 Glue+Athena로 특정 .csv만 접근, 같은 폴더 다른 파일은 불가" → Glue에서 Data Catalog 리소스 정책을 정의해 해당 .csv 객체에 대한 크로스 계정 S3 접근을 부여 (테이블/객체 단위 세밀 제어) 【오답 체크】 (A) 다른 계정에 사용자 정책만 적용해서는 크로스 계정 Glue 카탈로그/S3 접근이 성립하지 않음. (B) S3 Select는 객체 내 부분 조회 기능이지 접근 제어·Glue 소스 지정 방식이 아님(부정확). (D) 조직 전체를 principal로 하는 리소스 정책은 특정 .csv만이 아닌 광범위 접근을 허용해 "다른 파일 차단" 요건 위배. 【시험 포인트】 "Glue+Athena 크로스 계정 특정 객체만 공유" → Glue Data Catalog 리소스 정책으로 해당 객체에 크로스 계정 접근 부여.

해설

【핵심 용어】 ▸ 크로스 계정 접근 표준 — 리소스가 있는 계정(프로덕션)에 IAM 역할 생성, 다른 계정 사용자가 assume ▸ IAM 역할 assume — 임시 자격 증명 사용으로 장기 키 공유 불필요(가장 안전) ▸ 신뢰 정책 — 개발 계정을 신뢰해 역할 위임 【정답 포인트】 ▸ "개발 계정 사용자가 프로덕션 리소스 접근, 가장 안전" → 프로덕션 계정에 적절 권한 IAM 역할을 만들고 개발 계정 사용자가 그 역할을 assume (역할은 리소스가 있는 대상 계정에 존재해야 함) 【오답 체크】 (A) 프로덕션에 IAM 사용자 하나를 만들어 비밀번호를 공유하는 방식은 자격 증명 공유 안티패턴. (B) 역할을 개발 계정에 만드는 것은 방향이 잘못됨(리소스가 있는 프로덕션 계정에 역할이 있어야 함). (C) 크로스 계정 IAM 사용자 계정 공유 방식은 장기 자격 증명 공유로 안전하지 않음. 【시험 포인트】 크로스 계정 접근 = 리소스 소유 계정(프로덕션)에 역할 생성 + 타 계정에서 assume. 사용자/키 공유는 오답.

해설

【핵심 용어】 ▸ 동일 VPC 서브넷 간 통신 — 라우팅은 로컬로 자동, SG(상태 저장)와 NACL(무상태) 규칙이 핵심 ▸ 보안 그룹 아웃바운드 — 앱 인스턴스 SG가 아웃바운드를 막으면 DB로 연결 요청 자체가 불가(타임아웃) ▸ 네트워크 ACL — 서브넷 레벨에서 앱↔DB 트래픽을 막으면 통신 실패 【정답 포인트】 ▸ (A) 앱 인스턴스 SG가 아웃바운드 트래픽을 허용하지 않음 → DB로의 연결 요청 차단(타임아웃) ▸ (B) 앱 서브넷의 네트워크 ACL이 앱-DB 간 트래픽을 허용하지 않음 → 통신 차단 【오답 체크】 (C) 동일 VPC 내 서브넷 간에는 로컬 라우트가 자동 존재하므로 라우트 테이블 오구성은 일반적 원인 아님. (D) 같은 VPC 내부이므로 피어링 연결은 애초에 필요 없음. (E) DB SG 아웃바운드는 응답 트래픽에 영향을 주지 않음(SG는 상태 저장이라 인바운드 허용 시 응답 자동 허용). 【시험 포인트】 동일 VPC 연결 타임아웃 → 앱 SG 아웃바운드 + 서브넷 NACL 점검. 라우트/피어링은 동일 VPC에서 원인 아님, SG는 상태 저장이라 응답용 아웃바운드 불필요.

해설

【핵심 용어】 ▸ AWS Config 관리형 규칙(restricted-ssh) — SG가 0.0.0.0/0에서 SSH(22)를 허용하는지 준수 평가 ▸ EventBridge + Config 컴플라이언스 변경 이벤트 — 규칙 준수 상태 변경 시 근실시간 트리거 ▸ SNS — 알림 발송 타깃 【정답 포인트】 ▸ "상시 모니터링 + 위반 시 근실시간 알림" → Config restricted-ssh 규칙의 컴플라이언스 변경 이벤트로 EventBridge 규칙을 만들고 SNS 토픽을 타깃으로 지정 → 비준수 발생 즉시 알림 (가장 단순·근실시간) 【오답 체크】 (A) Config 스냅샷을 S3로 보내 Lambda로 파싱하는 방식은 지연·복잡해 근실시간 아님. (C) CloudWatch Logs 메트릭 필터 + 알람 방식은 우회적이고 지연 발생. (D) restricted-ssh에 대한 CloudWatch 지표/알람 방식은 부정확·비표준(Config 이벤트 기반이 정답). 【시험 포인트】 "Config 규칙 위반 근실시간 통지" → Config 컴플라이언스 변경 이벤트 → EventBridge → SNS.

해설

【핵심 용어】 ▸ Network ACL — 서브넷 단위의 stateless 방화벽, 인바운드/아웃바운드 규칙 별도 필요, source는 CIDR로만 지정(다른 NACL 참조 불가) ▸ Ephemeral ports (1024-65535) — 클라이언트 응답 트래픽이 사용하는 임시 포트, stateless NACL에서는 반환 트래픽용으로 명시 허용 필요 ▸ RDS PostgreSQL 포트 5432 — DB로 향하는 인바운드는 5432, 응답은 ephemeral 포트로 나감 【정답 포인트】 ▸ RDS의 NACL3만 강화하면 최소 권한 달성 → app 서브넷 CIDR에서 5432 인바운드 허용 + app 서브넷으로 ephemeral 아웃바운드 허용, 기본 allow-all 제거 ▸ NACL은 다른 NACL을 source로 참조할 수 없고 CIDR 블록으로 지정해야 하므로 B가 정답 【오답 체크】 (A) source/destination을 "NACL2"로 지정 — NACL은 다른 NACL을 참조할 수 없고 CIDR만 사용 가능. (C) NACL2(app)에 아웃바운드 5432만 추가하고 인바운드 응답 처리 누락 + 정작 DB 계층(NACL3)은 미보호. (D) NACL2에 규칙을 넣지만 stateless 반환(ephemeral) 처리가 어긋나고 DB 계층 강화가 아님. 【시험 포인트】 NACL은 stateless라 반환 트래픽(ephemeral 포트)을 반드시 명시 허용하고, source는 CIDR로만 지정. 보호 대상 계층의 NACL을 강화하는 보기가 정답.

해설

【핵심 용어】 ▸ NAT Gateway — 프라이빗 서브넷의 아웃바운드 인터넷 접근용, 반드시 퍼블릭 서브넷에 배치 ▸ Internet Gateway (IGW) — VPC의 인터넷 진입/진출점, 퍼블릭 서브넷 라우트 테이블의 0.0.0.0/0 대상 ▸ Route Table — 서브넷별 트래픽 경로 결정, 프라이빗 서브넷은 NAT를 default route로 가리켜야 함 【정답 포인트】 ▸ 네 서브넷 모두 IGW로 향하는 문제 → 프라이빗 서브넷 라우트 테이블이 IGW를 가리키고 있는 것 ▸ (A) 각 AZ 퍼블릭 서브넷에 NAT 게이트웨이 프로비저닝 확인 + (D) 프라이빗 서브넷 라우트 테이블의 0.0.0.0/0을 같은 AZ의 NAT로 지정 → 프라이빗은 NAT 경유, 퍼블릭만 IGW 경유 【오답 체크】 (B) NAT 게이트웨이를 프라이빗 서브넷에 두면 인터넷 접근 불가 — NAT는 퍼블릭 서브넷에 있어야 함. (C) local 대상 라우트는 VPC 생성 시 자동 존재하며 수동 추가 불필요, 문제 해결과 무관. (E) 프라이빗 서브넷 default route를 IGW로 지정하면 여전히 퍼블릭 노출, 잘못된 대상. 【시험 포인트】 프라이빗 서브넷 = NAT(퍼블릭 서브넷 소재)로 아웃바운드, 퍼블릭 서브넷 = IGW. AZ별 NAT를 두고 같은 AZ NAT를 default route로 지정.

해설

【핵심 용어】 ▸ Customer managed CMK — 고객이 생성·관리하는 KMS 키, 자동 키 순환(automatic key rotation) 지원 ▸ Automatic key rotation — 활성화 시 KMS가 백킹 키 자료를 약 365일(≈12개월)마다 자동 교체 ▸ AWS managed CMK — AWS가 자동 순환(과거 3년 → 현재 1년), 순환 주기 고객 제어 불가 【정답 포인트】 ▸ "고객 관리 CMK" + "가져오기 안 함" + "12개월마다 순환" → 생성 후 각 CMK에서 자동 키 순환 활성화(365일 주기) ▸ 자동 순환은 키 정책이 아니라 키의 순환 설정으로 켜므로 D가 정답 【오답 체크】 (A) 자동 순환은 키 정책(key policy)이 아니라 별도 rotation 설정으로 활성화 — 키 정책 변경으로는 켜지지 않음. (B) AWS managed CMK로 바꾸면 요구된 "customer managed" 조건 위반 + 순환 주기 제어 불가. (C) Lambda로 백킹 키를 수동 순환하는 것은 불필요한 운영 부담, 내장 자동 순환으로 충분. 【시험 포인트】 가져오지 않은 customer managed CMK의 12개월 순환 → automatic key rotation 활성화(365일). 가져온(imported) 키 자료는 자동 순환 미지원.

해설

【핵심 용어】 ▸ KMS Custom Key Store — CloudHSM 클러스터로 백킹되는 키 저장소, 키 자료가 HSM 내에서 생성·사용 ▸ CloudHSM — 전용 하드웨어 HSM, FIPS 140-2 Level 3, KMS custom key store의 백엔드 ▸ AWS CloudTrail — 모든 KMS API 호출(키 사용 포함) 감사 로그 기록 【정답 포인트】 ▸ "CloudHSM 백킹 custom key store에서 대칭 키 생성" → KMS + custom key store 조합 ▸ "키 사용 감사" → KMS 작업은 CloudTrail에 기록되므로 CloudTrail 사용 → D가 정답 【오답 체크】 (A) Athena는 S3 데이터 쿼리 도구로 KMS 키 사용 감사에 직접 부적합. (B) S3로는 KMS 키를 생성할 수 없음 — 키 생성은 KMS custom key store가 담당. (C) GuardDuty는 위협 탐지 서비스로 키 사용 감사 로그 소스가 아님. 【시험 포인트】 CloudHSM 백킹 키 생성·제어 → KMS custom key store. API 호출 감사는 항상 CloudTrail.

해설

【핵심 용어】 ▸ API Gateway resource policy — API에 붙는 리소스 기반 정책, aws:SourceIp 등 조건으로 접근 제어 ▸ AWS WAF — API Gateway에 연결 가능한 웹 방화벽, IP set 매치 규칙으로 특정 IP 대역 허용/차단 ▸ Security Group / Network ACL — EC2·서브넷용 네트워크 제어, API Gateway에는 직접 연결 불가 【정답 포인트】 ▸ 퍼블릭 API를 사내 테스터 IP 대역으로만 제한 → (C) WAF web ACL의 IP 매치 규칙으로 회사 IP만 허용 + (D) API Gateway resource policy에 IP 조건으로 허용 ▸ 두 방식 모두 퍼블릭 API에 대해 소스 IP 기반 제한을 구현 【오답 체크】 (A) Security Group은 API Gateway에 연결할 수 없음. (B) Network ACL은 API Gateway 서브넷 개념이 없어 적용 불가. (E) 인터페이스 VPC 엔드포인트는 프라이빗 API용이며, 퍼블릭 API의 IP 기반 제한 요구와 맞지 않음. 【시험 포인트】 퍼블릭 API Gateway의 IP 제한 → WAF IP 규칙 또는 resource policy의 aws:SourceIp. SG/NACL은 API Gateway에 붙지 않음.

해설

【핵심 용어】 ▸ Service Control Policy (SCP) — Organizations의 가드레일, OU/계정의 최대 권한 상한 설정(계정 관리자도 초과 불가) ▸ Developer OU — 개발자가 전체 관리자 권한을 가진 계정들의 묶음 ▸ ec2:RunInstances — EC2 인스턴스 시작 API, 인스턴스 타입 조건으로 제한 가능 【정답 포인트】 ▸ "개발자가 각 계정 full admin" → IAM 정책은 관리자가 수정·삭제 가능하므로 무력화됨 ▸ SCP는 관리자도 넘을 수 없는 상한 → 승인 외 인스턴스 타입에 대해 RunInstances Deny하는 SCP를 Developer OU에 부착 → D가 정답 【오답 체크】 (A) launch template은 접근 제어 수단이 아니며 IAM 주체에 연결하는 개념이 아님, 강제력 없음. (B) IAM 정책은 full admin 개발자가 스스로 수정/제거 가능하여 강제력 없음. (C) SCP를 조직 root에 부착하면 Developer OU뿐 아니라 Test/Production 등 전체에 영향 — 범위 과다. 【시험 포인트】 계정 관리자를 넘어서는 강제 제한은 SCP. 특정 OU에만 적용하려면 root가 아니라 해당 OU에 부착.

해설

【핵심 용어】 ▸ KMS key policy — CMK에 대한 접근을 결정하는 리소스 기반 정책, 주체별 사용 권한 명시 ▸ 암호화 AMI 실행 — 인스턴스가 부팅 시 EBS 볼륨 복호화를 위해 KMS 키의 Decrypt 권한 필요 ▸ 즉시 종료(launch then terminate) — 부팅 시 볼륨 복호화 실패 = KMS 접근 권한 부족의 전형적 증상 【정답 포인트】 ▸ 인스턴스가 시작 직후 종료 → 암호화 AMI/EBS 복호화 실패가 원인 ▸ 포렌식 AMI를 암호화한 KMS 키 정책에서 federated IAM role에 kms:Encrypt/kms:Decrypt 허용 → C가 정답 【오답 체크】 (A) ec2:DescribeImages는 조회 권한으로 종료 원인(복호화 실패)과 무관. (B) ec2:StartInstances는 시작 자체가 성공했으므로 원인이 아님. (D) kms:DescribeKey는 메타데이터 조회일 뿐 실제 복호화 권한이 아니어서 부팅 복호화 실패 해결 못 함. 【시험 포인트】 암호화 인스턴스가 뜨자마자 종료 → KMS 키 정책의 Decrypt(및 CreateGrant) 권한 확인. 원인은 EC2 권한이 아니라 KMS 접근.