정답 · 해설

해설

【핵심 용어】 ▸ Amazon ECR + Scan on Push — 푸시 시 이미지 취약점 자동 스캔 ▸ Repository Policy(리소스 기반) — 특정 AWS 계정의 접근 허용/제한 ▸ Identity-based Policy — 특정 IAM 프린시펄 접근 제한 【정답 포인트】 ▸ "심각 취약점 없음 + 특정 IAM 역할·계정만 접근" + "관리 최소" → ECR에 scan on push로 취약점 검사, 리포지토리 정책(계정)과 자격 증명 기반 정책(프린시펄) 병행으로 접근 통제 【오답 체크】 (A) 자격 증명 기반 정책만으로는 "특정 계정" 접근 통제(리소스 기반)가 빠져 요건 부족. (B) EC2 자체 호스팅 레지스트리 + 호스트 스캐너는 관리 오버헤드가 큼. (D) CodeArtifact는 패키지 저장소로 컨테이너 이미지 스캔·배포에 부적합. 【시험 포인트】 컨테이너 이미지 스캔 + 계정/프린시펄 접근 통제 → ECR scan on push + repository policy + identity policy.

해설

【핵심 용어】 ▸ Systems Manager Patch Manager — 누락 패치(취약점 식별자) 조회 및 패치 자동화 ▸ 패치 베이스라인/Maintenance Window — 자동 패치 적용 ▸ GuardDuty/Inspector/Shield — 각각 위협탐지/취약점평가/DDoS 방어로 패치 자동화 아님 【정답 포인트】 ▸ "어떤 인스턴스가 위험한지 확인 + 자동 패치 적용" → Patch Manager로 누락 패치의 취약점 식별자를 확인하고 동일 도구로 패치 자동화 【오답 체크】 (B) Shield Advanced는 DDoS 방어로 패치 취약점 조회와 무관. (C) GuardDuty는 위협 탐지, Inspector는 패치 적용 기능이 없음. (D) Inspector는 취약점 평가만 하고 패치 적용(자동화)은 수행하지 않음. 【시험 포인트】 누락 패치 식별 + 자동 적용 → Systems Manager Patch Manager 단일 서비스.

해설

【핵심 용어】 ▸ Amazon Cognito Hosted UI — 관리형 로그인 UI로 인증 처리 ▸ Lambda@Edge — CloudFront 요청 단계에서 인증 여부에 따라 콘텐츠 제공 또는 로그인 리다이렉트 ▸ SPA 소스 노출 문제 — 비인증 사용자가 index.html 접근 【정답 포인트】 ▸ "비인증 사용자에게 소스 노출 방지" → Cognito hosted UI 로그인 + Lambda@Edge가 인증 토큰 검사해 인증 시 콘텐츠 제공, 미인증 시 로그인 페이지로 리다이렉트 【오답 체크】 (A) WAF web ACL로 index.html을 무조건 차단하면 인증 사용자도 앱을 못 씀(로직상 인증 판별 불가). (B) Cognito는 API Gateway용 Lambda 오소라이저를 CloudFront/S3 정적 콘텐츠에 그대로 쓸 수 없음. (D) OAI는 S3 오리진을 CloudFront로만 접근하게 할 뿐 최종 사용자 인증 통제가 아님. 【시험 포인트】 CloudFront 정적 SPA 인증 게이트 → Cognito Hosted UI + Lambda@Edge.

해설

【핵심 용어】 ▸ MetadataNoToken 인스턴스 지표 — 토큰 없이(IMDSv1) 메타데이터 접근한 횟수 카운트 ▸ CloudWatch 대시보드 — 지표 0 여부 모니터링 ▸ IMDSv2 마이그레이션 검증 — IMDSv1 실사용 확인 【정답 포인트】 ▸ "IMDSv1 엔드포인트 미사용 확인" → CloudWatch 대시보드에서 EC2 MetadataNoToken 지표가 모든 인스턴스에서 0인지 확인(0이면 IMDSv1 미사용) 【오답 체크】 (A) CloudWatch 에이전트로 IMDSv1 로깅을 별도 구현하는 것은 불필요한 오버헤드, 기본 지표가 존재. (C) 보안 그룹으로 IMDS(링크로컬) 차단은 불가능하며 "사용 여부 확인"도 아님. (D) user data 스크립트로 CloudTrail 전송은 IMDS 호출을 정확히 포착하지 못하고 복잡함. 【시험 포인트】 IMDSv1 사용 여부 확인 → MetadataNoToken 지표(0이면 미사용).

해설

【핵심 용어】 ▸ ACM DNS 검증 — CNAME 레코드로 도메인 소유 검증 ▸ CAA(Certification Authority Authorization) 레코드 — 특정 CA만 인증서 발급 허용하도록 제한 ▸ 검증 실패(Failed) — CAA가 Amazon CA를 미허용하면 발급 실패 【정답 포인트】 ▸ "CNAME 추가 후 상태 Failed" → 도메인의 CAA 레코드가 특정(타사) CA만 허용하고 Amazon을 배제 → ACM이 발급 못 해 실패 → CAA에 Amazon 허용 필요 【오답 체크】 (A) DNS 검증은 Route 53 호스팅을 요구하지 않음(타사 DNS 가능). (B) 자동 갱신도 Route 53 필수 아님. (D) ACM DNS 검증은 CNAME 레코드를 사용하며 TXT가 아님. 【시험 포인트】 ACM DNS 검증 Failed → CAA 레코드가 Amazon CA를 막고 있는지 확인.

해설

【핵심 용어】 ▸ SSE-KMS(CMK) — S3 저장 데이터를 고객 관리 KMS 키로 암호화 ▸ CloudFront OAI 한계 — OAI는 SSE-KMS 암호화 객체를 직접 복호화·서빙 불가(SigV4/KMS 미지원) ▸ Lambda@Edge — 오리진 요청 시 CMK로 S3 객체를 읽어 복호화 처리 【정답 포인트】 ▸ (A) S3 버킷을 고객 관리 KMS 키로 서버측 암호화 ▸ (D) OAI로는 SSE-KMS 객체 서빙이 안 되므로 OAI 구성 제거 ▸ (F) Lambda@Edge(origin request)가 CMK로 S3 객체를 읽어 제공 → 운영 오버헤드 최소로 CMK 암호화 콘텐츠 서빙 【오답 체크】 (B) SSE-C는 고객 제공 키 방식으로 요건(KMS 고객 관리 키)과 다르고 관리 부담 큼. (C) OAI를 사용하는 구성은 SSE-KMS 객체 복호화가 불가해 콘텐츠 서빙 실패. (E) CloudFront 캐시 자체를 CMK로 암호화하는 옵션은 존재하지 않음. 【시험 포인트】 CloudFront + SSE-KMS S3 → OAI 불가, Lambda@Edge로 CMK 복호화 서빙.

해설

【핵심 용어】 ▸ aws ecr get-login-password — ECR 인증 토큰 발급(리전별, 12시간 유효) ▸ 리전 불일치 — CLI 리전이 리포지토리 리전과 다르면 인증 토큰이 해당 리포지토리에 무효 ▸ "no basic auth credentials" — 도커 인증 정보 부재/불일치 오류 【정답 포인트】 ▸ 토큰은 4시간 전 발급으로 유효(12시간 미만), 권한도 정상 → 남은 원인은 CLI 리전이 us-east-1이 아니어서 토큰이 대상 리포지토리에 맞지 않음 → CLI를 us-east-1로 구성 【오답 체크】 (A) 토큰은 12시간 유효라 4시간 경과로는 만료 아님. (C) aws-auth-cm.yaml은 EKS 클러스터 인증용으로 ECR 푸시와 무관. (D) STS 리전 활성화는 이 오류(basic auth)와 관계없음. 【시험 포인트】 ECR 푸시 "no basic auth" + 토큰 유효 → CLI 리전을 리포지토리 리전과 일치.

해설

【핵심 용어】 ▸ EC2 Image Builder 빌드 인스턴스 — 실제 작업은 EC2 인스턴스 프로파일 권한으로 수행 ▸ Instance Profile 정책 — EC2InstanceProfileForImageBuilder 등 + 로그 대상 S3 접근 권한 ▸ AccessDenied 403(로그 S3) — 인스턴스 프로파일의 s3:PutObject 부재 【정답 포인트】 ▸ Image Builder는 빌드 EC2의 인스턴스 프로파일 권한으로 동작하므로 ▸ (B) 인스턴스 프로파일에 EC2InstanceProfileForImageBuilder/ECRContainerBuilds/AmazonSSMManagedInstanceCore 부착 ▸ (E) 인스턴스 프로파일에 로그 버킷 s3:PutObject 권한 부여로 403 해소(최소권한) 【오답 체크】 (A) 권한은 엔지니어의 IAM 역할이 아니라 빌드 EC2의 인스턴스 프로파일에 필요. (C) AWSImageBuilderFullAccess는 과도한 권한으로 최소권한 위배. (D) s3:PutObject는 엔지니어 IAM 역할이 아니라 인스턴스 프로파일에 있어야 함. 【시험 포인트】 Image Builder 권한 문제 → 빌드 EC2의 인스턴스 프로파일에 부여.

해설

【핵심 용어】 ▸ Amazon Macie — S3 객체의 PII 등 민감정보 자동 탐지 ▸ Amazon Athena — S3에 저장된 CloudTrail 로그를 SQL로 쿼리(접근 API 호출 분석) ▸ CloudTrail 로그(S3) — CloudWatch Logs 미구성이라 Athena 쿼리가 적합 【정답 포인트】 ▸ (D) DOC-EXAMPLE-BUCKET2의 CloudTrail 로그를 Athena로 쿼리해 지난 60일간 해당 액세스 키의 GetObject 접근 여부 확인 ▸ (A) Macie로 BUCKET1의 객체 중 PII를 포함한(.txt 등) 객체 식별 【오답 체크】 (B) CloudWatch Logs Insights는 CloudWatch Logs가 필요한데 미구성이며 PII 탐지 기능도 없음. (C) OpenSearch로 로그 쿼리는 가능하나 구성 오버헤드가 크고 여기선 Athena가 표준. (E) IAM Access Analyzer는 접근 로그 쿼리·PII 탐지 도구가 아님. 【시험 포인트】 S3 로그 접근 분석 → Athena, S3 객체 PII 탐지 → Macie.

해설

【핵심 용어】 ▸ CloudWatch Agent — Auto Scaling으로 뜨는 EC2의 시스템/앱 로그를 CloudWatch Logs로 전송(스케일인 시 손실 방지) ▸ CloudWatch Logs 보존 기간 — 로그 그룹 retention을 정확히 설정(7년) ▸ IAM 역할(런치 템플릿) — 로그 전송 권한 부여 【정답 포인트】 ▸ (A) 모든 인스턴스에 CloudWatch 에이전트 설치·구성해 로그를 CloudWatch Logs로 실시간 전송(스케일링 중 손실 방지) ▸ (C) 런치 구성/템플릿의 IAM 역할에 CloudWatch Logs 전송 권한 부여 ▸ (B) 로그 그룹 보존 기간을 7년으로 설정(불필요한 초과 보관 방지) 【오답 체크】 (D) S3 전송 권한 역할은 CloudWatch Logs 기반 해법(A/B/C) 조합과 맞지 않음. (E) 서드파티 로그 포워더를 S3로 주기 번들 전송은 실시간 손실 방지·관리 측면에서 부적합. (F) S3 Lifecycle 만료는 S3 저장 경로를 전제하므로 선택된 CloudWatch Logs 조합과 불일치. 【시험 포인트】 Auto Scaling 로그 손실 방지 → CloudWatch Agent + IAM 역할 + 로그 그룹 retention.

해설

【핵심 용어】 ▸ AWS Shield Advanced — DDoS 방어, DDoSDetected 등 CloudWatch 지표 제공 ▸ CloudWatch Alarm — Shield Advanced 지표 기반 DDoS 발생 알림 ▸ Macie/Inspector/Firewall Manager — 각각 민감정보/취약점/정책관리로 DDoS 탐지 아님 【정답 포인트】 ▸ "DDoS 공격 발생 알림" → Shield Advanced의 DDoS 지표를 모니터링하는 CloudWatch 알람 생성 【오답 체크】 (A) Macie는 S3 민감정보 탐지로 DDoS 이벤트를 감지하지 않음. (B) Inspector는 취약점 평가이며 실시간 DDoS 이벤트 탐지 불가. (C) Firewall Manager는 정책 중앙관리로 DDoS "활성 이벤트" 지표를 제공하지 않음. 【시험 포인트】 DDoS 발생 알림 → Shield Advanced 지표 기반 CloudWatch 알람.

해설

【핵심 용어】 ▸ EBS 루트 볼륨 분리/재부착 — 인스턴스 중지 후 루트 볼륨을 다른 인스턴스에 데이터 볼륨으로 붙임 ▸ authorized_keys — 새 키페어의 공개 키(public key)를 등록해 접속 복구 ▸ 키페어 — AWS는 공개 키를 인스턴스에 저장, 사용자는 프라이빗 키 보관 【정답 포인트】 ▸ (A) 인스턴스를 중지하고 루트 볼륨 분리, 새 키페어 생성 ▸ (C) 분리한 볼륨을 다른 인스턴스에 데이터 볼륨으로 붙여 authorized_keys에 새 공개 키 추가 후 원래 인스턴스에 재부착하고 시작 【오답 체크】 (B) 실행 중 인스턴스는 루트 볼륨을 분리할 수 없음(중지 필요). (D) authorized_keys에는 프라이빗 키가 아니라 공개 키를 넣어야 함. (E) 실행 중 인스턴스에 루트 볼륨을 다시 붙일 수 없음(중지 상태여야 함). 【시험 포인트】 키 분실 복구 → 중지 → 루트 볼륨 분리 → authorized_keys에 새 public key → 재부착.

해설

【핵심 용어】 ▸ S3 Bucket Policy + aws:SourceVpce — 지정 VPC 엔드포인트 경유만 접근 허용 ▸ Deny + StringNotEquals — 지정 엔드포인트가 아니면 모든 접근 거부 ▸ vpce-1a2b3c4d — 허용 엔드포인트 【정답 포인트】 ▸ "vpce-1a2b3c4d 경유만 허용, 미경유 시 전면 거부" → 버킷 정책에 Deny 효과 + aws:SourceVpce가 해당 값과 다를 때(StringNotEquals) 모든 S3 액션 거부 로직이 정확한 보기 【오답 체크】 (정답이 아닌 보기) 이미지 정책들은 Effect 방향이 반대이거나, 조건 연산자(StringEquals/StringNotEquals) 또는 조건 키(aws:SourceVpc vs aws:SourceVpce)가 요건과 어긋나 "엔드포인트 미경유 시 거부" 로직을 정확히 강제하지 못함. 【시험 포인트】 특정 VPC 엔드포인트만 허용 → Deny + StringNotEquals aws:SourceVpce.

해설

【핵심 용어】 ▸ AWS SSO(IAM Identity Center) + 외부 IdP — 중앙 자격 증명원으로 다계정 접근 통합, IAM 사용자 개별 관리 제거 ▸ Organizations 연동 — SSO가 조직 계정에 자동 접근 프로비저닝 ▸ SSO 콘솔 계정 할당 — 사용자를 계정에 지정 【정답 포인트】 ▸ (A) 상위(부모) 회사용 외부 IdP를 두고 이를 SSO의 자격 증명원으로 연동 → 중앙 관리로 관리·프로비저닝 부담 감소 ▸ (D) SSO 콘솔에서 클라이언트 계정 접근이 필요한 사용자를 선택해 계정에 할당 【오답 체크】 (B) 클라이언트마다 IdP를 두면 관리 복잡도가 오히려 증가. (C) IAM 역할을 SSO 자격 증명원으로 삼는 구성은 개념상 부정확. (E) IAM 콘솔에서 사용자를 계정에 개별 할당하는 방식은 기존 문제(오버헤드)를 그대로 유지. 【시험 포인트】 다계정 접근 관리 간소화 → 외부 IdP + AWS SSO(중앙), SSO 콘솔에서 계정 할당.

해설

【핵심 용어】 ▸ Amazon Detective — 로그(CloudTrail/VPC/GuardDuty) 상관분석으로 행위자·활동 추적 및 근본원인 조사 ▸ GuardDuty CloudTrailLoggingDisabled 파인딩 — CloudTrail 비활성화 탐지 ▸ Detective 통합 — GuardDuty 파인딩에서 바로 심층 조사 【정답 포인트】 ▸ "누가 CloudTrail을 껐고 비활성 동안 무슨 활동이 있었는지" → Detective로 CloudTrailLoggingDisabled 파인딩의 사용자명 및 관련 활동을 상관분석으로 추적 【오답 체크】 (A) AWS Config는 리소스 구성 이력용이며 "비활성 동안 활동" 상세 추적에 부적합. (B) Inspector는 취약점 평가로 이벤트 조사 기능이 없음. (D) GuardDuty는 파인딩 생성까지, Security Hub는 파인딩 집계로 활동 추적(상관분석)은 Detective 역할. 【시험 포인트】 GuardDuty 파인딩 심층 조사(누가·무엇) → Amazon Detective.

해설

【핵심 용어】 ▸ AWS Config 관리형 규칙 rds-instance-public-access-check — RDS 퍼블릭 접근 여부 준수 평가 ▸ EventBridge 규칙 — Config 준수 변경 이벤트를 트리거로 감지 ▸ SNS — 보안 엔지니어에게 근실시간 알림 【정답 포인트】 ▸ (B) rds-instance-public-access-check Config 관리형 규칙으로 RDS 모니터링 ▸ (E) 해당 규칙의 준수 변경 이벤트로 트리거되는 EventBridge 규칙 구성 ▸ (C) EventBridge 규칙 타깃을 SNS 토픽으로 지정해 근실시간 알림 【오답 체크】 (A) RDS 이벤트 알림 → Lambda가 Config에 변경을 알리는 구조는 불필요·부정확. (D) SQS→SNS 구독 방식은 근실시간 알림에 우회적이고 요건 흐름과 불일치. (F) Lambda가 Config에 알린 뒤 EventBridge 트리거하는 구조는 필요 없는 우회. 【시험 포인트】 RDS 퍼블릭 접근 준수 알림 → Config 관리형 규칙 + EventBridge(준수 변경) + SNS.

해설

【핵심 용어】 ▸ SSE-KMS 객체 복호화 — GetObject 시 KMS 키에 대한 kms:Decrypt 권한 필요 ▸ 새 KMS 키 전환 — 기존 aws/s3 기본 키에서 신규 키로 변경 ▸ 여러 버킷 동일 오류 — 버킷 정책 아닌 KMS 키 권한 문제 시사 【정답 포인트】 ▸ 신규 키로 암호화한 다른 버킷들에서도 동일 AccessDenied → 버킷별 문제가 아니라 IAM 사용자가 새 KMS 키에 대한 암호화/복호화(kms:Encrypt/Decrypt) 권한이 없음이 근본 원인 【오답 체크】 (B) 관리(administrative) 권한이 아니라 데이터 사용을 위한 Decrypt 권한이 필요. (C) 여러 버킷 공통 오류라 특정 버킷 정책 문제가 아님. (D) 변경 전 객체는 접근되므로 버킷의 객체 접근(버킷 정책) 문제가 아니라 새 키 권한 문제. 【시험 포인트】 KMS 키 교체 후 AccessDenied(여러 버킷 공통) → 신규 키의 kms:Decrypt 권한 확인.

해설

【핵심 용어】 ▸ KMS 고객 관리 키(CMK) — 기본(aws 관리) 키와 달리 교차 계정 공유 가능 ▸ RDS 스냅샷 공유 — 암호화 스냅샷 공유 시 대상 계정에 KMS 키 접근 필요 ▸ 키 정책/IAM 프린시펄 공유 — 대상 계정이 복호화하도록 권한 부여 【정답 포인트】 ▸ "암호화 스냅샷을 두 계정이 복호화" → CMK로 스냅샷 생성 후, 각 계정이 적절한 KMS 권한을 가진 IAM 프린시펄로 키를 사용할 수 있도록 공유(기본 키는 교차 계정 공유 불가) 【오답 체크】 (A) 기본 AWS 관리형 키는 공유·교차 계정 사용 불가, 키를 복사하는 개념도 없음. (B) KMS 키는 다른 계정으로 "import"하는 방식이 아님. (C) 기본(aws 관리) 키는 교차 계정 공유가 불가능해 요건 미충족. 【시험 포인트】 암호화 스냅샷 교차 계정 공유 → 반드시 고객 관리 KMS 키(CMK).

해설

【핵심 용어】 ▸ Interface VPC Endpoint(PrivateLink) — CodeDeploy 같은 API 서비스에 프라이빗 연결 제공 ▸ Gateway Endpoint — S3/DynamoDB 전용(다른 서비스 불가) ▸ CodeDeploy API 프라이빗 접근 — 인터넷 미경유 요구 【정답 포인트】 ▸ "CodeDeploy API를 인터넷 없이 VPC 내 인스턴스와 통신" → CodeDeploy용 인터페이스 VPC 엔드포인트로 프라이빗 접근 【오답 체크】 (A) NAT 게이트웨이는 인터넷(퍼블릭)을 경유하므로 요건 위배. (C) 게이트웨이 엔드포인트는 S3/DynamoDB만 지원, CodeDeploy 불가. (D) VPN은 온프레미스 연결용으로 CodeDeploy API 프라이빗 접근 표준이 아님. 【시험 포인트】 AWS API 서비스 프라이빗 접근 → 인터페이스 VPC 엔드포인트(S3/DynamoDB만 게이트웨이).

해설

【핵심 용어】 ▸ RDS 스토리지 암호화 — 기존 미암호화 인스턴스는 제자리 활성화 불가, 새 암호화 인스턴스로 이전 필요 ▸ AWS DMS(full load + CDC) — 최소 다운타임으로 데이터 이전(변경분 실시간 반영) ▸ 가용성 영향 최소화 — 무중단에 가까운 컷오버 【정답 포인트】 ▸ "가용성 중단 최소화로 암호화 미준수 해결" → DMS full load + CDC로 미암호화 DB에서 암호화된 새 DB로 지속 복제, full load 완료 후 엔드포인트 컷오버(변경분도 CDC로 반영되어 다운타임 최소) 【오답 체크】 (B) 스냅샷→암호화 복사→복원은 스냅샷 시점 이후 변경분 손실·다운타임 발생(가용성 영향 큼). (C) 미암호화 DB에 제자리 암호화 활성화는 불가능하며 앱 쓰기 중단도 필요. (D) 암호화되지 않은 소스의 리드 리플리카는 암호화 상태를 바꿀 수 없음(리플리카는 소스 암호화 상속). 【시험 포인트】 무중단 RDS 암호화 전환 → DMS full load + CDC 후 컷오버.