정답 · 해설

해설

【핵심 용어】 ▸ IAM 역할 + 신뢰 정책(trust policy) — 외부 계정에 임시 자격증명(AssumeRole)으로 교차 계정 접근 허용 ▸ sts:ExternalId — confused deputy(혼동된 대리인) 방지, 외부 ID로 특정 서드파티만 역할 위임 가능 ▸ IAM Identity Center — 내부 사용자 SSO용 【정답 포인트】 ▸ "서드파티 임시 자격증명 + 두 외부 계정이 같은 자격증명 공유 방지 + 최소 운영 노력" → 계정별 IAM 역할 + 신뢰 정책에 sts:ExternalId 조건 ▸ ExternalId는 서드파티 교차 계정 접근의 표준 신뢰 강화 메커니즘 【오답 체크】 (A) Cognito/OAuth/SAML + API Gateway는 애플리케이션 사용자 인증용으로 AWS 교차 계정 접근과 무관. (B) IAM Identity Center는 조직 내부 사용자 SSO용, 서드파티 외부 계정 대상 아님. (C) Secrets Manager 랜덤 키 방식은 비표준이며 ExternalId만큼 신뢰를 강제하지 못함. 【시험 포인트】 서드파티 교차 계정 접근 + confused deputy 방지 → 역할 신뢰 정책의 sts:ExternalId 조건.

해설

【핵심 용어】 ▸ AWS WAF 로깅 → CloudWatch Logs — 웹 ACL 액세스 로그를 CloudWatch로 직접 전송 가능 ▸ CloudWatch Logs Insights — 로그를 쿼리로 필터링(호스트 등), 별도 인프라 없이 즉시 분석 ▸ Athena/Redshift Spectrum — S3 기반 쿼리로 추가 파이프라인 필요 【정답 포인트】 ▸ "중앙에서 WAF 로그 처리 + 호스트별 필터 + 최고 운영 효율" → CloudWatch를 로그 대상으로 지정하고 CloudWatch Logs Insights로 호스트 필터 쿼리 ▸ 단일 서비스로 수집·검색이 완결돼 가장 적은 단계 【오답 체크】 (A) Redshift + Athena Redshift 커넥터 조합은 인프라·운영 복잡도가 큼. (C) CloudWatch → S3 익스포트 → Athena는 중간 단계가 늘어나 효율 저하. (D) Redshift Spectrum도 별도 Redshift/외부 스키마 구성이 필요해 오버헤드 증가. 【시험 포인트】 로그 즉시 검색·필터의 최소 운영 = CloudWatch Logs + Logs Insights. S3+Athena/Redshift는 추가 단계.

해설

【핵심 용어】 ▸ CloudTrail 데이터 이벤트 — S3 객체 수준 접근을 IAM 자격증명·시간 포함 구조화(JSON)로 기록, 근실시간 ▸ S3 서버 액세스 로그 — 베스트 에포트, 지연 발생·구조화/식별정보 약함 ▸ AWS Config — 리소스 구성 변경 추적, 객체 접근 로깅 아님 ▸ Amazon Macie — 민감데이터 분류/탐지, 접근 로깅 아님 【정답 포인트】 ▸ "요청한 IAM 자격증명 + 접근 시간 + 구조화 + 근실시간" → CloudTrail 데이터 이벤트 로깅 ▸ 데이터 이벤트가 객체 수준 접근을 상세 구조화 로그로 근실시간 제공 【오답 체크】 (A) S3 서버 액세스 로그는 근실시간이 아니고(지연), IAM 자격증명 등 상세도가 부족. (C) AWS Config는 구성 변경을 추적하며 객체 접근 로그를 남기지 않음. (D) Macie는 데이터 분류/민감정보 탐지용으로 접근 로깅 목적이 아님. 【시험 포인트】 "누가·언제 S3 객체에 접근" 상세·근실시간 로그 → CloudTrail 데이터 이벤트.

해설

【핵심 용어】 ▸ CloudTrail 로그 파일 검증(log file validation) — 로그 무결성(변조 여부) 보장 ▸ S3 Object Lock — WORM, 객체 불변 저장(immutable evidence) ▸ 이벤트 셀렉터(event selector) — 특정 API(CreateKey, KMS key ARN 참조) 필터링 【정답 포인트】 ▸ "KMS 키 생성·기원·사용에 대한 불변 증거 수집·저장 + 감사자 제공" → CloudTrail(무결성 검증) + S3 Object Lock(불변 저장) ▸ CreateKey 및 키 ARN 참조 호출을 Object Lock 버킷에 저장하고 감사자에게 버킷 접근 부여 【오답 체크】 (B) CloudWatch Logs 로그 그룹은 불변(immutable) 보장이 없어 증거 요건 미충족. (C) DynamoDB 테이블은 수정 가능하므로 불변 증거 저장에 부적합. (D) CloudWatch 메트릭/대시보드는 실시간 모니터링용으로 불변 감사 증거가 아님. 【시험 포인트】 불변·무결성 감사 증거 = CloudTrail 로그 파일 검증 + S3 Object Lock(WORM).

해설

【핵심 용어】 ▸ Amazon OpenSearch Service — 로그 근실시간 수집·검색, API로 쿼리 ▸ OpenSearch Security Analytics — 탐지 규칙(detection rules) 매칭 및 알림, SNS 연동 ▸ CloudWatch Logs Insights — 수동 쿼리 검색, 탐지 규칙 매칭 제한적 ▸ Security Hub / QuickSight — findings 집계 / BI 시각화 【정답 포인트】 ▸ "다중 서비스 로그 근실시간 분석 + 검색 + 탐지 규칙 매칭 시 SNS 알림" → OpenSearch Service + Security Analytics ▸ Security Analytics가 탐지 규칙으로 로그를 매칭하고 SNS로 알림 발송 【오답 체크】 (B) Security Hub는 보안 findings 집계용으로 범용 로그 검색 도구가 아님. (C) CloudWatch Logs Insights는 수동 검색이며 subscription filter의 탐지 규칙 표현이 제한적. (D) QuickSight는 BI 시각화 도구로 근실시간 로그 탐지·알림에 부적합. 【시험 포인트】 로그 검색 + 탐지 규칙 기반 알림 = OpenSearch Service + Security Analytics.

해설

【핵심 용어】 ▸ Break glass 사용자 — SAML 장애 등 비상 시 사용하는 로컬 IAM 계정(페더레이션에 의존하지 않음) ▸ CloudTrail + CloudWatch Logs + EventBridge — 활동 로깅·모니터링·알림 ▸ Systems Manager Session Manager — SSH 없이 EC2 접근, 세션 로깅 【정답 포인트】 ▸ (A) SAML 실패 시에도 동작하도록 로컬 IAM break glass 사용자 생성 + CloudTrail(CloudWatch Logs) + EventBridge로 활동 로깅/모니터링 ▸ (E) immutable 인프라(사람 접근 없음)에는 Session Manager로 인스턴스 접근하고 CloudTrail 필터 → SNS로 로그를 보안팀에 전달 【오답 체크】 (B) EC2 키페어(SSH)는 사람 접근 없는 immutable 인프라 원칙에 반하고 키페어 활동 모니터링이 미약. (C) AssumeRoleWithSAML 기반 역할은 SAML이 깨진 상황에서 무용지물이라 break glass 목적 위배. (D) 인스턴스 OS 레벨 로컬 사용자 + 무제한 보안 그룹은 심각한 보안 취약. 【시험 포인트】 Break glass는 페더레이션 비의존(로컬 IAM), 인스턴스 접근은 Session Manager, 모든 활동은 CloudTrail로 로깅.

해설

【핵심 용어】 ▸ Amazon Cognito 사용자 풀 — SAML IdP 페더레이션, IdP 속성을 사용자 풀 속성에 매핑 ▸ SAML relying party(신뢰 당사자) — IdP가 Cognito 사용자 풀을 신뢰 당사자로 등록 ▸ API Gateway COGNITO_USER_POOLS authorizer — 사용자 풀 토큰으로 API 인가 【정답 포인트】 ▸ (B) Cognito 사용자 풀에 SAML IdP를 구성하고 속성을 사용자 풀 속성에 매핑 ▸ (C) SAML IdP가 Cognito 사용자 풀을 relying party로 추가해 신뢰 관계 성립 ▸ (F) API Gateway를 COGNITO_USER_POOLS authorizer로 설정해 인증된 사용자만 API 호출 【오답 체크】 (A) Lambda 커스텀 오소라이저는 Cognito 사용자 풀 방식이 이미 요구를 충족하므로 불필요. (D) Cognito 자격증명 풀 + 소셜 로그인은 SAML 디렉터리 사용자 요구와 무관. (E) DynamoDB에 이메일/비밀번호 저장은 자체 자격증명 관리로 보안 안티패턴. 【시험 포인트】 SAML 디렉터리 → 웹앱/API 인증 = Cognito 사용자 풀(SAML 페더레이션) + API Gateway Cognito authorizer.

해설

【핵심 용어】 ▸ IAM Access Analyzer — 외부/교차 계정 접근을 허용하는 정책 findings 생성 ▸ EventBridge — Access Analyzer findings 매칭 → 자동 대응 트리거 ▸ Step Functions + SNS — 리소스 유형 판별 후 명시적 Deny 추가 + 알림 【정답 포인트】 ▸ (C) EventBridge 규칙이 활성 Access Analyzer findings를 매칭해 Step Functions 호출 ▸ (A) Step Functions가 리소스 유형 확인 후 신뢰 정책에 명시적 Deny 추가 + SNS 알림 발행 ▸ (F) 외부/교차 계정 접근 통지용 SNS 토픽에 보안팀 이메일 구독 【오답 체크】 (B) AWS Batch는 배치 컴퓨팅용으로 이벤트 기반 자동 대응에 부적합. (D) CloudWatch 메트릭 필터 + Batch 조합은 Access Analyzer findings 자동 대응 경로로 부적절. (E) SQS 큐는 이메일 알림을 직접 전송하지 못함(SNS가 담당). 【시험 포인트】 findings 자동 대응 = EventBridge(트리거) + Step Functions/Lambda(remediation) + SNS(알림).

해설

【핵심 용어】 ▸ CloudTrail → CloudWatch Logs — 콘솔 로그인 이벤트를 로그 그룹으로 전달 ▸ CloudWatch 메트릭 필터 + 알람 — 특정 패턴(ConsoleLogin, Failed authentication) 카운트 → 임계치·기간 기반 경보 ▸ CloudTrail Insights — API 호출량 이상 탐지(특정 카운트 경보 아님) 【정답 포인트】 ▸ "5분 내 실패 로그인 3회 이상 경보" → CloudTrail을 CloudWatch Logs로 보내고 eventName=ConsoleLogin, errorMessage="Failed authentication" 메트릭 필터 + 임계치 3/기간 5분 알람 【오답 체크】 (A) CloudTrail Insights는 비정상 API 활동량 탐지용이며 특정 로그인 실패 카운트 경보 메커니즘이 아님. (C) Athena는 배치 쿼리로 5분 윈도우 실시간 카운트 경보에 부적합. (D) IAM Access Analyzer는 리소스 접근 분석용으로 로그인 실패 모니터링과 무관. 【시험 포인트】 CloudTrail 이벤트 패턴 카운트 경보 = CloudWatch Logs 메트릭 필터 + CloudWatch 알람.

해설

【핵심 용어】 ▸ Amazon GuardDuty — 다중 리전 위협 탐지 관리형 서비스, 비용 효율적으로 광범위 가시성 ▸ EventBridge + SNS — findings에 반응해 알림 발행 ▸ Amazon Detective — 조사(investigation) 심화 도구로 추가 비용 발생 【정답 포인트】 ▸ (B) 가능한 많은 리전 가시성을 비용 효율적으로 → GuardDuty를 모든 리전에서 활성화 ▸ (D) EventBridge 규칙이 findings에 반응해 SNS 토픽으로 통지 【오답 체크】 (A) 모든 VPC의 Flow Logs 활성화는 비용 증가·관리형 탐지 대비 비효율. (C) Detective는 findings 심층 조사 애드온으로 비용이 더 들어 "가장 비용 효율" 위반. (E) Lambda + SES 조합은 SNS 대비 구현 복잡도가 높음. 【시험 포인트】 다중 리전 위협 탐지의 비용 효율 표준 = GuardDuty + EventBridge → SNS 알림.

해설

【핵심 용어】 ▸ CloudFront geo restriction — 국가 단위 허용/거부 목록으로 콘텐츠 배포 제한 ▸ Origin Access Control (OAC) — S3 버킷을 CloudFront 경유로만 접근하도록 제한(S3 직접 접근 차단) ▸ Route 53 geolocation — DNS 라우팅용이며 접근 제어가 아님 【정답 포인트】 ▸ (C) CloudFront geo restriction 거부 목록으로 라이선스 없는 국가의 이미지 접근 차단 ▸ (A) OAC로 S3 버킷 정책을 제한해 이미지가 CloudFront를 통해서만 제공되도록(직접 S3 접근 우회 방지) 【오답 체크】 (B) Route 53 geolocation은 DNS 응답 라우팅용으로 접근 차단 수단이 아님. (D) S3 버킷 정책의 국가 거부는 CloudFront 경유 배포에 신뢰성 있게 적용되지 않음. (E) "Restrict Viewer Access"는 서명된 URL/쿠키용 옵션으로 국가 기반 제한과 무관. 【시험 포인트】 CloudFront 국가별 배포 제한 = geo restriction, S3 우회 방지 = OAC(버킷을 CloudFront 전용으로).

해설

【핵심 용어】 ▸ Network ACL — 서브넷 수준, 상태 비저장(stateless) → 응답 트래픽을 위한 아웃바운드 규칙 별도 필요 ▸ Security Group — 인스턴스 수준, 상태 저장(stateful) → 인바운드 허용 시 응답 자동 허용 ▸ Ephemeral ports(임시 포트) — 응답 트래픽이 사용하는 1024–65535 범위 【정답 포인트】 ▸ SG/NACL 인바운드는 이미 허용됐으나 접속 실패 → NACL이 stateless라 응답(아웃바운드)이 막힘 ▸ 새 CIDR의 NACL에 아웃바운드 임시 포트(ephemeral) 허용 규칙 추가로 응답 트래픽 통과 【오답 체크】 (A) SG는 stateful이라 아웃바운드=인바운드로 맞출 필요 없음. (C) 인터넷 게이트웨이에는 인바운드 규칙 개념이 없음(라우팅 요소). (D) NACL 아웃바운드를 인바운드와 동일 포트로 두면 응답용 임시 포트가 열리지 않아 여전히 실패. 【시험 포인트】 SG 정상인데 연결 실패 → stateless NACL의 아웃바운드 ephemeral 포트(1024-65535) 허용 확인.

해설

【핵심 용어】 ▸ AWS CloudFormation Guard — 정책-as-code(policy-as-code) 검증 도구, 템플릿을 규칙셋으로 배포 전 검사 ▸ AWS Config — 배포 후(post-deploy) 규정 준수 평가/탐지 ▸ SCP — 계정/OU 권한 상한, 템플릿 내용 검증용 아님 【정답 포인트】 ▸ "정책 위반 인프라(암호화 안 된 EBS 등) 배포 자체를 CI/CD에서 차단" → CloudFormation Guard 규칙셋으로 파이프라인 단계에서 템플릿 검증 ▸ 배포 전(pre-deploy) 검사로 위반 스택 배포를 방지 【오답 체크】 (A) Trusted Advisor는 사후 권고이며 배포 차단 게이트가 아님. (B) AWS Config는 배포된 리소스를 탐지·평가할 뿐 배포 자체를 사전 차단하지 못함. (D) SCP는 API 액션 권한을 제한할 뿐 CloudFormation 템플릿 내용(암호화 속성 등)을 검증하지 못함. 【시험 포인트】 템플릿 배포 전 정책 검증(policy-as-code) = CloudFormation Guard를 CI/CD 게이트로.

해설

【핵심 용어】 ▸ Secrets Manager 인터페이스 VPC 엔드포인트(PrivateLink) — 인터넷 없이 VPC 내부에서 Secrets Manager 프라이빗 접근 ▸ 인터넷 게이트웨이/NAT gateway — 인터넷 경유 접근(요구사항 "인터넷 트래픽 금지" 위반) 【정답 포인트】 ▸ "VPC가 인터넷 트래픽 불가" + "Lambda가 Secrets Manager와 통신 못 함" → Secrets Manager 인터페이스 VPC 엔드포인트 구성 ▸ Lambda의 프라이빗 서브넷을 엔드포인트에 포함해 인터넷 없이 API 호출 가능 【오답 체크】 (A) egress-only 인터넷 게이트웨이는 IPv6 아웃바운드 인터넷용으로 "인터넷 금지" 위반. (B) NAT gateway는 인터넷 경유 접근이라 요구사항 위반. (C) "Secrets Manager용 default VPC와 피어링"은 존재하지 않는 구성으로 성립 불가. 【시험 포인트】 인터넷 없는 VPC에서 AWS 서비스 프라이빗 접근 = 인터페이스 VPC 엔드포인트(PrivateLink).

해설

【핵심 용어】 ▸ Amazon Inspector — EC2/컨테이너의 알려진 취약점(CVE) 자동 스캔 ▸ Security Group — 필요한 포트만 개방해 공격 표면(attack surface) 축소 ▸ ACM/KMS — 전송/저장 암호화용(취약점·공격표면 축소와 별개) 【정답 포인트】 ▸ (D) Amazon Inspector로 백엔드 인스턴스를 주기적으로 스캔해 알려진 취약점 점검 ▸ (B) 애플리케이션 보안 그룹을 검토해 필요한 포트만 열어 공격 표면 최소화 【오답 체크】 (A) ACM으로 전송 암호화는 취약점 점검/공격표면 축소와 무관. (C) ELB로 SSL 오프로드는 성능/암호화 처리 관련이지 취약점 점검 아님. (E) KMS는 클라이언트↔서버 트래픽을 암호화하는 용도가 아니며 요구와 무관. 【시험 포인트】 알려진 취약점 점검 = Amazon Inspector, 공격 표면 축소 = 보안 그룹 포트 최소 개방.

해설

【핵심 용어】 ▸ Amazon ECR scan on push — 이미지 푸시 시 심각 취약점 자동 스캔 ▸ ECR 리포지토리 정책(resource-based) — 특정 AWS 계정의 교차 계정 접근 제어 ▸ 자격증명 기반(identity-based) 정책 — 특정 IAM principal 접근 제어 【정답 포인트】 ▸ "심각 취약점 없음 + 특정 IAM 역할 및 특정 계정만 접근 + 최소 관리" → ECR(scan on push) + 리포지토리 정책 + 자격증명 기반 정책 ▸ 리포지토리 정책이 교차 계정(어느 계정)까지, 자격증명 정책이 어떤 principal까지 제한 【오답 체크】 (A) 자격증명 기반 정책만으로는 다른 계정 접근을 리소스 측에서 제어하지 못함. (B) EC2 자가 호스팅 레지스트리는 스캔 도구 배포·유지로 관리 오버헤드가 큼. (D) CodeArtifact는 소프트웨어 패키지 저장소로 컨테이너 이미지 레지스트리가 아님. 【시험 포인트】 컨테이너 이미지 취약점+접근제어 최소관리 = ECR scan on push + 리포지토리 정책(계정) + 자격증명 정책(principal).

해설

【핵심 용어】 ▸ S3 Lifecycle 규칙(expiration) — 지정 기간 경과 객체 자동 삭제, 관리형·무코드 ▸ S3 Intelligent-Tiering — 스토리지 클래스 자동 전환(삭제 아님) 【정답 포인트】 ▸ "45일 초과 데이터 자동 삭제(데이터 보존 정책)" → S3 Lifecycle 규칙으로 45일 후 객체 만료(삭제) ▸ 완전 관리형이라 별도 코드/운영 없이 정책 강제 【오답 체크】 (B) PutObject마다 Lambda 호출은 트리거가 부적절하고 불필요하게 복잡. (C) 월 1회 Lambda로 last-modified 검사·삭제는 커스텀 코드 오버헤드 + 45일 경계 부정확. (D) Intelligent-Tiering은 스토리지 클래스 전환일 뿐 객체를 삭제하지 않음. 【시험 포인트】 기간 경과 객체 자동 삭제 = S3 Lifecycle expiration. Intelligent-Tiering은 삭제가 아니라 전환.

해설

【핵심 용어】 ▸ S3 버킷 정책 Resource ARN — 버킷 자체(arn:aws:s3:::bucket)와 객체(arn:aws:s3:::bucket/*)는 구분됨 ▸ GetObject 권한 — 객체 수준 작업이라 Resource에 /* (객체) 포함 필요 【정답 포인트】 ▸ Lambda가 객체를 읽으려면(GetObject) Resource가 객체 ARN(bucket/*)이어야 함 ▸ Resource를 "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"로 변경해 객체 수준 접근 허용 【오답 체크】 (A) Condition 제거·Principal 변경은 읽기 실패의 원인(Resource 범위)이 아님. (B) Action 변경만으로는 Resource가 객체를 가리키지 않으면 여전히 실패. (D) Resource를 Lambda 함수 ARN으로 바꾸는 것은 S3 버킷 정책 문맥상 무의미. 【시험 포인트】 객체 작업(GetObject/PutObject)의 Resource는 반드시 버킷/* (객체 ARN). 버킷 ARN만으로는 객체 접근 불가.

해설

【핵심 용어】 ▸ KMS 키 정책(key policy) — KMS 키 접근의 최종 권한 원천, 계정 루트 full access를 제거하면 IAM 정책만으로 접근 위임 불가 ▸ SSE-KMS + 고객 관리형 키(CMK) — S3 객체 복호화 시 kms:Decrypt 권한 + 키 정책 허용 모두 필요 【정답 포인트】 ▸ IAM 정책에 kms:Decrypt, s3:Get/List가 있음에도 Access Denied → KMS 키 정책이 편집되어 계정의 full access가 제거된 것이 원인 ▸ KMS는 키 정책이 없으면 IAM 정책만으로 접근을 위임할 수 없어 복호화 실패 【오답 체크】 (A) kms:DescribeKey는 객체 복호화(Decrypt)에 필수 권한이 아님. (B) AWS 관리형 키로 바뀌었다는 것은 문제에서 고객 관리형 키로 명시돼 전제와 배치. (C) 동일 계정 내에서는 IAM 정책만으로 접근 가능해 버킷 정책 추가가 필수 아님. 【시험 포인트】 동일 계정 SSE-KMS인데 IAM에 권한이 있어도 Denied → KMS 키 정책에서 계정 접근이 제거됐는지 확인.

해설

【핵심 용어】 ▸ aws:SecureTransport 조건 키 — 요청이 HTTPS(TLS)인지 여부, 전송 중 암호화 강제에 사용 ▸ S3 버킷 정책 Deny + Condition — SecureTransport가 false일 때(비암호화 HTTP) 모든 S3 작업 거부 【정답 포인트】 ▸ "전송 중 미암호화 시 S3 작업 거부" → Effect Deny + Condition {"Bool": {"aws:SecureTransport": "false"}} 구성의 정책 ▸ 이미지 문제이므로 개념 기준: 올바른 정책은 Deny 효과에 SecureTransport=false 조건을 적용한 것 【오답 체크】 (A) 효과/조건 논리가 전송 암호화 강제에 부합하지 않음. (C) SecureTransport 조건 또는 Deny 구성이 요구와 맞지 않음. (D) 조건 값/효과 조합이 비암호화 요청 거부를 올바르게 구현하지 못함. 【시험 포인트】 전송 중 암호화 강제 = Deny + Condition aws:SecureTransport:false (비HTTPS 요청 거부).