정답 · 해설

해설

【핵심 용어】 ▸ IMDSv2 마이그레이션 — 토큰 기반 요청 강제, IMDSv1(토큰 없는 요청) 사용 여부 확인 필요 ▸ MetadataNoToken CloudWatch 메트릭 — 토큰 없이(IMDSv1) 메타데이터에 접근한 호출 수 ▸ 확인 방법 — 이 메트릭이 0이면 IMDSv1이 더 이상 사용되지 않음 【정답 포인트】 ▸ "IMDSv1 엔드포인트가 더는 사용되지 않음을 확인" → CloudWatch 대시보드에서 모든 EC2의 EC2:MetadataNoToken 메트릭이 0인지 확인·모니터링 (B). 이 메트릭은 IMDSv1(토큰 없는) 호출을 카운트. 【오답 체크】 (A) CloudWatch Agent로 IMDSv1 로깅을 부팅 시 구성하는 방식은 복잡하고 표준 지표(MetadataNoToken)를 두고 우회. (C) 보안 그룹으로 IMDS(169.254.169.254 링크 로컬)를 차단할 수 없음 → 구성 불가. (D) user data로 CloudTrail에 IMDSv1 사용을 로깅하는 것은 표준 방법이 아님(CloudTrail은 IMDS 호출을 기록하지 않음). 【시험 포인트】 "IMDSv1 사용 여부 확인" → CloudWatch MetadataNoToken 메트릭이 0인지 점검.

해설

【핵심 용어】 ▸ AWS IAM Identity Center(구 AWS SSO) — 외부 IdP를 자격증명 소스로 연동, 조직 전 계정·애플리케이션 접근 중앙 관리 ▸ 권한 세트(Permission Set) + 계정 할당 — 사용자/그룹에 계정별 접근을 중앙에서 부여 ▸ 관리 계정 중앙 관리 — Organizations와 통합 【정답 포인트】 ▸ "외부 IdP 사용자 관리 통합 + 전 계정·앱 접근 중앙 관리" → IAM Identity Center를 켜고 외부 IdP를 자격증명 소스로 설정, 권한 세트와 계정 할당으로 접근 관리 (B) 【오답 체크】 (A) Directory Service는 디렉터리 제공용으로 조직 전 계정 접근 중앙 관리(권한 세트) 기능이 아님. (C) IAM에 외부 IdP를 직접 연동해 사용자마다 정책을 붙이는 방식은 다계정 중앙 관리에 확장성·운영성이 떨어짐. (D) Cognito는 애플리케이션 최종 사용자 인증용이지 AWS 계정 접근 중앙 관리 도구가 아님. 【시험 포인트】 "외부 IdP + 다계정 접근 중앙 관리" → IAM Identity Center(권한 세트·계정 할당).

해설

【핵심 용어】 ▸ ECR 향상된 스캔(Enhanced Scanning) — Amazon Inspector 기반으로 이미지 취약점 탐지 ▸ Amazon Inspector findings → EventBridge → SNS — 취약점 finding을 이벤트로 라우팅 ▸ AWS Chatbot(Slack 연동) — SNS 토픽을 구독해 Slack 채널로 알림 【정답 포인트】 ▸ "ECR 향상된 스캔 취약점을 Slack으로 자동 알림 + 최고 운영 효율" → Inspector 스캔 활성화, Inspector findings용 EventBridge 규칙을 만들어 SNS로 보내고, AWS Chatbot이 SNS를 구독해 Slack에 게시 (A). 관리형 서비스만으로 서버리스 파이프라인 구성. 【오답 체크】 (B) EC2에서 스크립트로 finding을 폴링·전송하는 방식은 인스턴스 운영 부담이 큼. (C) Step Functions로 ListFindings를 호출하는 커스텀 워크플로는 불필요하게 복잡하고, SNS는 Slack을 직접 타깃으로 삼지 못함(Chatbot 필요). (D) "Security Hub scans for ECR"는 정확한 기능명이 아니며 Slack 직접 리디렉션도 부정확. 【시험 포인트】 "AWS findings를 Slack 알림" → EventBridge + SNS + AWS Chatbot(Slack).

해설

【핵심 용어】 ▸ AWS Config aggregator (org-wide) — 조직 전체 계정·리전의 구성/규정준수 데이터를 집계 ▸ 자동 교정(remediation) — findings에 반응해 리소스를 수정/삭제 【정답 포인트】 ▸ organization-wide aggregation으로 전 계정·리전을 커버(현재+미래 계정 포함) ▸ Lambda가 비규정 S3 findings에 반응해 삭제/재구성 → 기존 위반도 교정 【오답 체크】 (B) SCP Deny는 신규 생성만 예방, 이미 존재하는 비규정 버킷은 교정 못함 (C) 현재 계정·리전만 스코프 → 미래 계정 누락 (D) 스코프 한정 + SCP(예방만) → 기존 교정·미래 커버 모두 미흡 【시험 포인트】 ▸ 기존 교정 = 자동 remediation(Lambda), 신규 예방 = SCP ▸ 조직 전체 = org-wide aggregator

해설

【핵심 용어】 ▸ KMS Grant — 키 사용 권한의 임시 위임, 생성 직후 최종적 일관성(전파 지연) 존재 ▸ Grant token — CreateGrant 응답에 반환, 전파 지연을 우회해 즉시 사용 가능 【정답 포인트】 ▸ CreateGrant가 반환한 grant token을 사용자에게 전달 ▸ encrypt 호출 시 그 grant token을 사용 → 전파 지연과 무관하게 즉시 권한 반영, AccessDenied 제거 【오답 체크】 (A) 2분 재시도는 근본 해결이 아니며 UX 저하 (B) 무작위 grant token은 유효하지 않음 (C) 무작위 이름은 grant token이 아님 【시험 포인트】 ▸ grant 생성 직후 즉시 사용 → 반드시 CreateGrant 응답의 grant token 사용

해설

【핵심 용어】 ▸ WAF string match rule — User-Agent 등 요청 구성요소의 문자열을 매칭해 차단 ▸ rate-based / IP set / geo match — 요청률 / 특정 IP / 국가 기반 규칙 【정답 포인트】 ▸ IoT 기기가 고유한 User-Agent를 가짐 → string match로 해당 UA 문자열 차단 ▸ 현재 공격과 미래 공격을 함께 차단하면서 정상 고객 요청은 영향 없음 【오답 체크】 (A) DDoS라 IP가 다수·가변 → IP set 부적합 (B) geo 차단은 같은 국가의 정상 고객까지 차단 (C) rate-based는 IoT 기기 특정 불가, 정상 트래픽도 걸릴 수 있음 【시험 포인트】 ▸ 고유 User-Agent 기반 정밀 차단 = string match statement

해설

【핵심 용어】 ▸ Gateway VPC Endpoint — S3/DynamoDB 프라이빗 접근, 라우트 테이블 기반(보안그룹 없음) ▸ Endpoint policy — 엔드포인트를 통한 접근을 제어하는 리소스 정책 【정답 포인트】 ▸ IAM 인스턴스 프로파일·버킷 정책·SG·NACL 모두 확인됨 ▸ 남은 것은 VPC endpoint policy → S3 접근을 허용하는지 확인 필요 【오답 체크】 (A) SG는 stateful, 응답 트래픽에 implicit inbound deny 개념 무관 (B) gateway endpoint는 보안그룹이 없음(SG는 interface endpoint만) (C) 엔드포인트 경유 S3 트래픽은 인터넷 게이트웨이를 거치지 않음 【시험 포인트】 ▸ gateway endpoint 문제 → endpoint policy 확인, gateway endpoint엔 SG 없음

해설

【핵심 용어】 ▸ SCP — Organizations에서 계정/OU의 최대 권한 경계, member 계정의 root까지 제한 가능 ▸ management 계정은 SCP의 영향을 받지 않음 【정답 포인트】 ▸ OU 생성 + root 사용을 제어하는 SCP attach + 멤버 계정을 OU에 추가 ▸ 조직 전반의 member root 사용 제한 달성 【오답 체크】 (A) "조직 root에서 root 비활성화" 같은 기능은 없음 (B) IAM user 정책은 root user에 적용되지 않음 (D) CloudTrail 메트릭 필터는 탐지일 뿐 제한(restrict)이 아님 【시험 포인트】 ▸ root 사용 제한 = SCP (IAM 정책은 root에 미적용)

해설

【핵심 용어】 ▸ CloudWatch Logs data protection policy — 로그의 민감정보를 자동 마스킹 ▸ account-wide 정책 — 미래 생성되는 로그 그룹에도 자동 적용 ▸ logs:Unmask — 마스킹을 해제하는 권한 【정답 포인트】 ▸ account-wide data protection policy + 적절한 data identifier 지정 ▸ 개발자에게 logs:Unmask 미부여 → 민감정보 마스킹, 미래 로그 그룹까지 자동 커버 【오답 체크】 (B)(C) S3 export + Macie는 구현 오버헤드 크고 실시간·미래 자동 적용이 아님 (D) per-log-group 정책은 미래에 생성되는 로그 그룹에 자동 적용되지 않음 【시험 포인트】 ▸ "미래 로그 그룹 자동" + 마스킹 = account-level data protection policy

해설

【핵심 용어】 ▸ Amazon Macie — S3의 민감정보를 자동 발견·분류(관리형 data identifier) ▸ EventBridge — 서비스 이벤트를 SNS 등으로 라우팅 【정답 포인트】 ▸ Macie(관리형 식별자)로 S3 민감정보 식별 + EventBridge 규칙으로 기존 SNS 토픽 알림 ▸ 최소 구현 노력으로 요건 충족 【오답 체크】 (A) AWS Config는 민감데이터 스캔 도구가 아님 (B) Lambda 커스텀 스캔은 구현 노력이 큼 (D) GuardDuty는 위협 탐지이지 민감데이터 분류가 아님 【시험 포인트】 ▸ S3 민감데이터 발견 = Macie (GuardDuty=위협, Config=구성)

해설

【핵심 용어】 ▸ Service Catalog launch constraint — 제품 시작 시 사용할 IAM role 지정, 사용자에게 elevated 권한 불필요 ▸ template constraint — 파라미터(입력값) 제약 【정답 포인트】 ▸ 각 제품에 launch constraint 추가 → 지정된 role로 리소스 프로비저닝 ▸ 사용자는 자신의 상승 권한 없이도 제품 launch 가능 【오답 체크】 (A) template constraint는 입력값 제약일 뿐 권한과 무관 (C) update constraint는 업데이트 규칙 (D) 서비스 롤은 launch constraint로 지정하는 것이 표준 방식 【시험 포인트】 ▸ 사용자 권한 최소화하며 제품 launch = launch constraint(role 지정)

해설

【핵심 용어】 ▸ Security group 참조 — 소스로 IP가 아닌 다른 SG를 지정, SG 멤버십으로 접근 제어 ▸ 동적으로 생성·종료되는 인스턴스에 이상적 【정답 포인트】 ▸ app VPC에 인바운드 없는 SG, db VPC SG에 "app SG 소스, 1521 허용" 인바운드 ▸ DB 접근이 필요한 app 인스턴스에만 app SG를 붙임 → 그 인스턴스만 접근 【오답 체크】 (A)(D) IP 범위 기반은 VPC 내 모든 인스턴스 허용, "필요한 것만" 불가 / NACL은 서브넷 전체 (B) IP 범위 기반이라 특정 인스턴스만 세밀 제어 불가 【시험 포인트】 ▸ "특정 인스턴스만" 접근 = SG 참조(소스에 SG 지정), IP/NACL 아님

해설

【핵심 용어】 ▸ CloudWatch agent — EC2 로컬 로그를 CloudWatch Logs로 전송 ▸ ASG scale-in 시 로컬 로그 유실 → 중앙 저장 필요 【정답 포인트】 ▸ AMI에 CloudWatch agent 내장 + CloudWatch Logs로 전송 ▸ scale-in에도 로그가 durable·available, 보존기간 설정으로 1년+ 유지 【오답 체크】 (A) EBS 재부착은 운영 복잡, 자동 durability 약함 (B) EFS 일 1회 복사는 유실 위험·복잡 (D) 종료 대기 훅은 수동 검토용이지 durability 해결이 아님 【시험 포인트】 ▸ ASG 로그 유실 방지 = CloudWatch Logs(agent)로 중앙화

해설

【핵심 용어】 ▸ S3 Glacier — 장기 아카이브용 최저 비용 스토리지 ▸ Vault Lock policy — WORM(변경 불가) 규정준수 잠금, 삭제 방지 【정답 포인트】 ▸ Glacier + Vault Lock → 최저 비용 + 불변(규정 준수) 보관 ▸ 더 이상 사용하지 않지만 수년 보존해야 하는 로그에 최적 【오답 체크】 (A) S3 Standard + 버킷 정책은 정책 변경으로 우회 가능, 비용도 높음 (C) 복제 + Standard-IA는 비용↑, 불변성 약함 (D) EBS 스냅샷은 아카이브 용도로 비효율·고비용 【시험 포인트】 ▸ 규정 장기 불변 아카이브 최저비용 = Glacier Vault Lock

해설

【핵심 용어】 ▸ AWS Client VPN — 원격 사용자(노트북)가 VPC에 안전하게 접속(권한/authorization 규칙) ▸ Site-to-Site VPN — 네트워크 대 네트워크(사용자 노트북용 아님) 【정답 포인트】 ▸ VPC와 같은 리전에 Client VPN endpoint + 적절한 서브넷/authorization rule ▸ 컨설턴트 노트북이 피어링된 두 VPC만 접근, 불필요한 접근 배제 【오답 체크】 (A) Site-to-Site는 개별 사용자 노트북 접속용이 아님 (B) VPC sharing(RAM)은 리소스 공유이지 원격 접속이 아님 (D) gateway endpoint는 S3/DynamoDB용 【시험 포인트】 ▸ 개별 사용자 원격 VPC 접속 = Client VPN endpoint

해설

【핵심 용어】 ▸ Permissions boundary — IAM 엔티티가 가질 수 있는 최대 권한 상한 ▸ SCP로 "boundary가 붙지 않은 role 생성 금지"를 강제 가능 【정답 포인트】 ▸ SCP + permissions boundary 생성, root OU에 SCP 적용 ▸ boundary가 붙은 role만 생성 가능 → 팀이 self-service로 role 생성하되 범위 제한·권한상승 방지, 최소 오버헤드 【오답 체크】 (A) IAM group/user는 self-service role 생성이 아님 (B) 위임 + 분기 검토는 오버헤드·escalation 위험 (C) 서비스 제한 SCP만으론 role 권한 범위·escalation 통제 부족 【시험 포인트】 ▸ self-service role 생성 + 권한상승 방지 = permissions boundary(+SCP 강제)

해설

【핵심 용어】 ▸ 자격증명 우선순위 — CLI 명령행 옵션 > 환경변수 > 공유 config/credentials 파일 ▸ 명령행 옵션은 최우선이며 일시적(다른 설정과 충돌 없음) 【정답 포인트】 ▸ CLI command line options로 자격증명 지정 → 최우선 평가 ▸ 기존 환경변수/config 자격증명과 충돌 없이 이번 호출에만 적용 【오답 체크】 (A) 로컬 config 파일 / (D) 공유 config 파일은 기존 설정과 섞이며 영구적 (B) 환경변수는 기존 환경변수와 충돌 가능 【시험 포인트】 ▸ 기존 자격증명 안 건드리고 일시 적용 = CLI 명령행 옵션(최우선)

해설

【핵심 용어】 ▸ Amazon Macie — S3의 PHI/PII 발견(PERSONAL_INFORMATION 관리형 식별자) ▸ AWS Audit Manager — 프레임워크 기반 감사 증거 자동 수집 ▸ Security Hub FSBP — S3 Block Public Access 등 제어 평가 【정답 포인트】 ▸ (A) Macie로 개인 건강정보 식별 ▸ (C) Audit Manager로 프레임워크 평가·증거 수집 ▸ (E) Security Hub FSBP로 공개 S3(Block Public Access 실패) 식별 【오답 체크】 (B) Glue Detect PII는 구현 노력↑, 감사 증거 목적 아님 (D) GuardDuty S3는 의심 접근 탐지이지 PHI 식별/공개버킷 목적 아님 (F) Config write-prohibited는 read 공개를 못 잡음 【시험 포인트】 ▸ PHI 식별=Macie, 감사 증거=Audit Manager, 공개 S3=Security Hub

해설

【핵심 용어】 ▸ Customer managed CMK — 키 정책 제어 + CloudTrail로 키 사용 감사 가능 ▸ AWS managed CMK — 키 정책 커스터마이즈 불가 ▸ encryption context — 추가 인증 데이터 【정답 포인트】 ▸ 팀별 별도 버킷 + 별도 customer managed CMK ▸ 키 정책으로 각 팀만 암복호화 허용 + encryption context 강제 → 데이터 분리 + 키 사용 감사 【오답 체크】 (A)(B) AWS managed CMK는 키 정책 제한으로 팀별 격리·감사 제어 어려움 (D) 단일 CMK는 팀 데이터 분리 요건 위반 【시험 포인트】 ▸ 팀별 격리 + 키 사용 감사 = 별도 customer managed CMK + 키 정책

해설

【핵심 용어】 ▸ CloudWatch agent — OS 로그 수집 ▸ metric filter + CloudWatch alarm — 실패 로그인 임계치(5분 5회) 탐지 ▸ SNS message filter — 구독자별 알림 라우팅 【정답 포인트】 ▸ CloudWatch agent로 OS 로그 수집 → metric filter 기반 CloudWatch alarm(임계 초과) ▸ SNS 알림 + 메시지 필터로 담당 관리자만 수신 【오답 체크】 (A) EventBridge는 metric-filter alarm 개념이 아님 (B)(D) SSM Run Command AWS-ConfigureCloudWatch 방식은 비표준/구식 구성 【시험 포인트】 ▸ OS 로그 임계 알림 = CloudWatch agent + metric filter + CloudWatch alarm