정답 · 해설

해설

【핵심 용어】 ▸ GuardDuty → EventBridge — findings의 표준 이벤트 통합 경로, 이벤트 패턴으로 High severity 필터 ▸ Kinesis Data Firehose → OpenSearch Service — 관리형 네이티브 전달, OpenSearch Dashboards로 시각화 ▸ SNS — 보안팀 이메일 알림 【정답 포인트】 ▸ "High severity findings 이메일 알림 + 시각화 도구 전달" → GuardDuty를 EventBridge로 보내고 두 대상 구성 ▸ 대상1: Firehose → OpenSearch(Dashboards 시각화), 대상2: SNS(이메일), EventBridge 이벤트 패턴으로 High만 필터 【오답 체크】 (A) GuardDuty는 CloudWatch 알람이 아닌 EventBridge로 findings를 보냄; Kinesis Data Streams는 Firehose 대비 OpenSearch 네이티브 전달이 아님. (B) GuardDuty가 CloudTrail로 알림을 보낸다는 것은 잘못된 통합. (D) Kinesis Data Streams → OpenSearch는 Firehose 관리형 전달만큼 간단하지 않음. 【시험 포인트】 GuardDuty findings 라우팅 = EventBridge. OpenSearch로의 관리형 전달 = Kinesis Data Firehose.

해설

【핵심 용어】 ▸ S3 Object Lock 규정 준수 모드(compliance mode) — 보존 기간 동안 루트 사용자 포함 누구도 덮어쓰기·삭제 불가(WORM) ▸ 거버넌스 모드(governance mode) — 특정 권한 보유자는 보호 우회 가능 ▸ Glacier Vault Lock — Glacier 볼트용이며 S3 버킷 객체 배치 방식이 아님 【정답 포인트】 ▸ "루트 포함 누구도 덮어쓰기/삭제 불가 WORM" → Object Lock을 compliance 모드로 활성화한 새 버킷 생성 후 객체 저장 ▸ compliance 모드만이 루트 사용자까지 보존 기간 내 변경/삭제를 차단 【오답 체크】 (B) Glacier Vault Lock은 Glacier 볼트 대상으로, S3 버킷에 객체를 넣는 시나리오와 맞지 않음. (C) governance 모드는 권한 있는 사용자가 보존을 우회할 수 있어 루트 차단 요건 미충족. (D) governance 모드 + legal hold도 특권 사용자 우회 가능성이 있어 compliance만큼 엄격하지 않음. 【시험 포인트】 루트 포함 절대 삭제 불가 WORM = S3 Object Lock compliance 모드. governance는 우회 가능.

해설

【핵심 용어】 ▸ 엔드투엔드 암호화 — 클라이언트↔ALB, ALB↔EC2 두 구간 모두 인증서 필요 ▸ ACM 발급 인증서 — export 불가라 EC2에 직접 설치 불가 ▸ ACM에 서드파티 인증서 import — ALB 연결 가능 + 동일 인증서를 EC2에 설치 가능 【정답 포인트】 ▸ "외부 사용자↔애플리케이션 전 구간 암호화" → 서드파티 인증서를 ACM에 import ▸ ACM 인증서를 ALB에 연결하고, 동일(서드파티) 인증서를 EC2 인스턴스에 설치해 백엔드 구간까지 암호화 【오답 체크】 (A) Secrets Manager는 인증서 발급/관리 서비스가 아님. (B) ACM이 발급한 Amazon 인증서는 export할 수 없어 EC2에 설치 불가. (C) IAM 인증서 저장은 레거시 방식이며, ACM import가 표준 경로. 【시험 포인트】 ALB→EC2 백엔드까지 암호화하려면 EC2에 설치 가능한 인증서 필요 → 서드파티 인증서를 ACM에 import(발급 인증서는 export 불가).

해설

【핵심 용어】 ▸ SCP(Service Control Policy) — 계정/OU의 유효 권한 상한, 어느 계층에서든 허용되지 않으면 최종 거부 ▸ 유효 권한 = IAM 정책 ∩ 루트 SCP ∩ OU SCP (모든 계층에서 허용돼야 함) ▸ IAM 정책 — SES ses:* 허용, OU SCP도 SES 허용 【정답 포인트】 ▸ IAM·OU SCP가 SES를 허용해도 not-authorized → 루트 SCP가 SES를 허용/포함하지 않아 상위 계층에서 차단 ▸ 루트 SCP에서 SES 제한을 제거(허용)해야 유효 권한 교집합에 SES가 포함되어 접근 가능 【오답 체크】 (A) 리소스 정책은 SCP의 거부를 우회하지 못함. (B) 그룹 ARN을 Principal로 지정하는 리소스 정책은 SCP 제약을 극복하지 못하고 유효하지도 않음. (C) Control Tower 가드레일은 문제에서 명시된 원인(루트 SCP)이 아님. 【시험 포인트】 SCP는 모든 계층에서 허용돼야 유효. 상위(루트) SCP가 서비스를 막으면 하위 허용/IAM 허용도 무효.

해설

【핵심 용어】 ▸ Security Group — 인스턴스 방화벽, 소스 IP/포트 기반 최소 개방이 보안 모범 ▸ HTTPS(443) — 공개 웹사이트라 전체(0.0.0.0/0) 허용 필요 ▸ SSH(22) — 관리 목적이라 관리 서브넷(192.168.100.0/24)만 허용 【정답 포인트】 ▸ (B) 공개 웹사이트 → 443을 0.0.0.0/0에서 허용 ▸ (C) SSH 관리 → 22를 관리 서브넷 192.168.100.0/24에서만 허용해 가장 안전 【오답 체크】 (A) 22를 0.0.0.0/0에 개방하면 전 세계 SSH 노출로 심각한 보안 위험. (D) 22를 웹 서브넷(10.0.1.0/24)에서 허용하는 것은 관리 소스가 아니라 잘못됨. (E) 443을 10.0.1.0/24로 제한하면 공개 접근이 불가해 웹사이트 요건 위반. 【시험 포인트】 공개 서비스 포트는 0.0.0.0/0, 관리 포트(SSH)는 관리 네트워크 CIDR로 최소 개방.

해설

【핵심 용어】 ▸ CloudWatch 에이전트 — EC2 커스텀 로그를 CloudWatch Logs로 전송, 인스턴스 IAM 역할 권한 필요 ▸ CloudWatchAgentServerPolicy — 에이전트가 로그/메트릭을 전송하는 데 필요한 AWS 관리형 정책 ▸ 인스턴스 프로파일/역할 — EC2가 AWS API를 호출할 권한 부여 【정답 포인트】 ▸ 에이전트 설치·설정·서비스 실행은 정상인데 로그 미수신 → IAM 권한 부재가 원인 ▸ CloudWatchAgentServerPolicy를 EC2 인스턴스 역할에 연결하면 로그 전송 권한 확보 【오답 체크】 (A) CloudTrail을 신뢰 정책에 추가한다는 것은 개념적으로 맞지 않고 커스텀 로그 대상도 아님. (B) S3를 신뢰 정책에 추가하는 방식은 CloudWatch 에이전트 로그 수집과 무관. (C) Amazon Inspector는 취약점 스캐너로 커스텀 로그 수집 도구가 아님. 【시험 포인트】 CloudWatch 에이전트 로그 미수신 → 인스턴스 역할에 CloudWatchAgentServerPolicy 부여 확인.

해설

【핵심 용어】 ▸ Source/Destination Check(소스/대상 확인) — EC2가 자신 IP가 아닌 트래픽을 포워딩하려면 비활성화 필요 ▸ 인라인 가상 보안 어플라이언스 — NAT/방화벽처럼 트래픽을 경유·라우팅 ▸ 보안 그룹/NACL — 어플라이언스와 병행 사용 가능 【정답 포인트】 ▸ 어플라이언스가 자신 앞으로 오지 않은 트래픽을 라우팅(포워딩)하려면 ENI의 Source/Destination Check를 비활성화해야 함 ▸ 기본값(활성)에서는 목적지/출발지가 자기 자신이 아닌 패킷을 폐기하므로 라우팅 불가 【오답 체크】 (A) NACL 비활성화는 불필요하고 보안을 약화; 병행 사용 가능. (B) promiscuous 모드는 AWS ENI에서 지원되지 않으며 라우팅 문제 해결책이 아님. (D) 퍼블릭 서브넷/IGW 배치는 인라인 라우팅 동작과 직접 관련 없음. 【시험 포인트】 인라인 어플라이언스가 트래픽 포워딩 → ENI의 Source/Destination Check 비활성화.

해설

【핵심 용어】 ▸ S3 버킷 정책 Principal — 접근을 허용할 주체 지정, 리소스 기반 정책의 필수 요소 ▸ IAM 사용자 ARN — Principal로 사용 가능 (예: arn:aws:iam::account:user/User1) ▸ IAM 그룹 — Principal로 사용 불가(그룹 ARN은 리소스 정책 Principal 미지원) 【정답 포인트】 ▸ "User1, User2, User3만 읽기(최소 권한)" → Principal에 세 IAM 사용자 ARN을 명시적으로 나열 ▸ 이미지 문제이므로 개념 기준: 개별 사용자 ARN을 Principal로 지정한 정책이 정답 【오답 체크】 (B) IAM 그룹 ARN을 Principal로 사용하는 정책은 유효하지 않음(그룹은 Principal 미지원). (C) 와일드카드/과도한 범위는 최소 권한 위반. (D) 잘못된 Principal 형식 또는 그룹 참조로 세 사용자만 허용하지 못함. 【시험 포인트】 리소스 정책 Principal에는 IAM 그룹 사용 불가 → 개별 사용자/역할 ARN을 나열.

해설

【핵심 용어】 ▸ IAM 자격증명 보고서(credential report) — 최대 4시간마다 한 번만 재생성, 그 사이 캐시된(오래된) 데이터 반환 ▸ mfa/access-keys-rotated 등 Config 규칙 — 자격증명 보고서 데이터를 근거로 평가 【정답 포인트】 ▸ 키를 방금 교체했는데 모두 noncompliant → 자격증명 보고서가 4시간 내 이미 생성돼 이전(교체 전) 상태를 반영 ▸ 보고서는 4시간 주기로만 갱신되므로 최신 변경이 즉시 반영되지 않아 규칙이 옛 데이터로 평가 【오답 체크】 (B) GenerateCredentialReport 권한이 없으면 오류가 나지 보고서/평가가 noncompliant로 나오지 않음. (C) GetCredentialReport 권한 부재도 접근 오류이지 규정 위반 결과의 원인이 아님. (D) MaximumExecutionFrequency 24시간은 정상 설정값으로 noncompliant의 근본 원인이 아님. 【시험 포인트】 IAM 자격증명 보고서는 4시간 캐시 → 방금 변경한 상태가 반영 안 돼 Config가 옛 데이터로 평가.

해설

【핵심 용어】 ▸ AWS WAF Count 액션 — 규칙을 차단 대신 카운트로 전환해 서비스 복구하며 어떤 규칙이 매칭되는지 로그로 확인 ▸ WAF 로깅 → CloudWatch Logs — 매칭 규칙 진단 ▸ WAF 로깅 구성 삭제 방지 — PutLoggingConfiguration API는 IAM 권한으로 제어(리소스 정책 아님) 【정답 포인트】 ▸ 관리형 규칙이 정상 요청까지 차단 → 규칙을 Count 액션으로 바꿔 즉시 서비스 복구 + 로그로 문제 규칙 식별 ▸ 향후 로깅 비활성화 방지 → WAF 관리자 IAM 정책에서 로깅 구성 제거 권한을 거부(로깅 설정은 IAM으로 통제) 【오답 체크】 (B) "WAF 리소스 정책"으로 로깅 구성 제거를 막는 방식은 해당 제어 지점이 아님(IAM 권한이 통제). (C) Challenge 액션은 CAPTCHA 유형 대응으로 이 진단 목적에 부적합하고 리소스 정책 접근도 부정확. (D) Challenge 액션 포함이 불필요하며 진단에는 Count가 적절. 【시험 포인트】 WAF 규칙 오차단 진단 = Count 액션. 로깅 비활성화 방지는 IAM 권한 제한(리소스 정책 아님).

해설

【핵심 용어】 ▸ sts:AssumeRole — 교차 계정 역할 위임, 양측 구성 필요 ▸ 소스 역할(identity) 정책 — LambdaAuditRole이 대상 역할에 대한 sts:AssumeRole 권한 보유 ▸ 대상 역할 신뢰 정책(trust policy) — AcmeAuditFactoryRole이 LambdaAuditRole의 위임을 신뢰 【정답 포인트】 ▸ AssumeRole AccessDenied는 양방향 구성 누락이 원인 ▸ (A) LambdaAuditRole 자격증명 정책에 AcmeAuditFactoryRole 대상 sts:AssumeRole 권한 부여 ▸ (C) AcmeAuditFactoryRole 신뢰 정책이 LambdaAuditRole의 sts:AssumeRole을 허용 【오답 체크】 (B) AWSLambdaBasicExecutionRole은 CloudWatch Logs 기록용으로 AssumeRole 오류와 무관. (D) LambdaAuditRole이 lambda.amazonaws.com을 신뢰하게 하는 것은 Lambda가 역할을 사용하는 설정이지 이 오류 원인이 아님. (E) us-east-1 엔드포인트 여부는 AccessDenied 원인이 아님(STS는 전역/리전 무관). 【시험 포인트】 교차 계정 AssumeRole = 소스의 sts:AssumeRole 권한 + 대상의 신뢰 정책, 양쪽 모두 필요.

해설

【핵심 용어】 ▸ AWS Organizations 조직 CloudTrail 트레일(organization trail) — 모든 멤버 계정 활동을 자동 수집해 중앙 버킷으로 전달(최소 운영) ▸ S3 Object Lock 규정 준수 모드 + 2년 보존 — 변경·삭제 불가 불변 저장 ▸ 관리 계정 — 조직 트레일 생성 주체 【정답 포인트】 ▸ (D) 조직 CloudTrail 트레일 생성으로 전 계정 활동을 중앙 보안 계정 버킷에 전달(계정별 개별 설정 불필요, 최소 오버헤드) ▸ (A) 보안 계정 버킷에 Object Lock compliance 모드 + 2년 보존으로 변경/삭제 차단, 관리 계정 쓰기 허용 【오답 체크】 (B) 조직 트레일은 CloudTrail 서비스 전달을 사용하므로 멤버 계정 직접 쓰기 허용 구성이 맞지 않음. (C) Lifecycle 만료는 객체를 삭제(2년 후)하는 것으로 "삭제 불가" 요건과 배치되고 불변성도 없음. (E) 계정별 CloudTrail + Lambda/Firehose 전달은 운영 오버헤드가 커 "최소" 위반. 【시험 포인트】 전 계정 로그 중앙화 최소운영 = 조직 CloudTrail 트레일, 변경·삭제 금지 = Object Lock compliance.

해설

【핵심 용어】 ▸ Secrets Manager 로테이션 Lambda — DB에 로그인해 자격증명을 교체(setSecret 단계에서 DB 접속) ▸ "setSecret: Unable to log into database" — Lambda가 DB에 네트워크로 접속하지 못함(로그인 실패) ▸ 보안 그룹 — Lambda↔EC2(DB) 간 인바운드/아웃바운드 허용 필요 【정답 포인트】 ▸ VPC 엔드포인트는 정상 = Secrets Manager 통신은 되지만 DB 로그인 실패 ▸ Lambda가 DB 인스턴스에 접속하도록 SG 구성: Lambda SG 아웃바운드가 EC2로, EC2 SG 인바운드가 Lambda SG를 허용 【오답 체크】 (A) 시크릿 JSON 구조 문제라면 다른 오류가 발생하며 "로그인 실패"의 원인이 아님. (C) rotate-secret 강제 실행은 근본 네트워크 원인을 해결하지 못함. (D) VPC 엔드포인트가 이미 동작하고 DB가 로컬(같은 서브넷)이라 IGW/NAT 추가는 불필요. 【시험 포인트】 "Unable to log into database"는 Lambda↔DB 네트워크 문제 → 보안 그룹 인/아웃바운드 상호 허용.

해설

【핵심 용어】 ▸ SCP Deny 문 — 특정 액션(guardduty:Disable*, securityhub 비활성화 등)을 명시적으로 거부, 다른 IAM 허용은 건드리지 않음 ▸ FullAWSAccess + Deny SCP — 기본 허용 위에 Deny만 얹어 특정 액션만 제한(다른 권한 유지) ▸ Allow-list SCP — 나열되지 않은 모든 것을 제한(다른 권한을 덮어써 부적합) 【정답 포인트】 ▸ "GuardDuty·Security Hub 비활성화 금지 + 다른 IAM 권한은 유지" → 해당 비활성화 액션에 대한 Deny SCP를 루트에 부착 ▸ Deny SCP는 권한을 부여하지 않고 특정 액션만 차단하므로 다른 허용을 침해하지 않음 【오답 체크】 (B) Allow 기반 SCP는 나열되지 않은 다른 권한을 모두 차단해 "다른 권한 유지" 요건 위반. (C) 구성이 특정 비활성화 액션 Deny가 아니어서 요구를 정확히 충족하지 못함. (D) 잘못된 효과/액션 조합으로 GuardDuty·Security Hub 보호를 달성하지 못함. 【시험 포인트】 특정 액션만 막고 나머지 권한 유지 = Deny SCP(Allow-list SCP는 나머지를 모두 차단).

해설

【핵심 용어】 ▸ CloudFormation 동적 참조(dynamic reference) — {{resolve:secretsmanager:...}}로 배포 시 Secrets Manager 값을 안전하게 참조(템플릿에 평문 노출 없음) ▸ Secrets Manager — DB 자격증명 저장, KMS 암호화 【정답 포인트】 ▸ "CloudFormation에서 민감 DB 자격증명 구성 + 이미 KMS/Secrets Manager 사용" → 템플릿의 동적 참조로 Secrets Manager 시크릿 참조 ▸ 동적 참조는 자격증명을 템플릿/파라미터에 노출하지 않고 배포 시 해석 【오답 체크】 (B) 파라미터로 자격증명을 참조하면 값이 노출되고, 템플릿 자체 KMS 암호화는 지원 방식이 아님. (C) SecureString 파라미터는 SSM Parameter Store용이며 Secrets Manager 참조 메커니즘이 아님. (D) SecureString으로 KMS 암호화 값을 참조하는 방식은 CloudFormation의 표준 시크릿 참조가 아님. 【시험 포인트】 CloudFormation에서 시크릿 안전 참조 = Secrets Manager 동적 참조({{resolve:secretsmanager}}).

해설

【핵심 용어】 ▸ Security Hub 위임 관리자(delegated administrator) + Organizations — 다중 계정/리전 findings 중앙 집계 ▸ EventBridge → Kinesis Data Firehose → S3 — findings를 관리형으로 단일 S3에 전달 ▸ Glue + Athena + QuickSight — S3 데이터 스키마 크롤링·쿼리·대시보드 시각화 【정답 포인트】 ▸ (B) Organizations 위임 관리자 지정 + EventBridge로 findings 이벤트 발행(다계정/다리전 집계) ▸ (D) 리전별 EventBridge 규칙 → Firehose delivery stream → 단일 S3 버킷으로 관리형 전달 ▸ (F) S3 파티셔닝 + Glue 크롤러로 스키마 구축 + Athena 뷰(중첩 속성 평탄화) + QuickSight 대시보드 【오답 체크】 (A) CloudWatch로 이벤트 발행은 findings 집계·분석 파이프라인에 덜 적합. (C) Kinesis Data Stream을 S3로 출력하려면 추가 구성이 필요; 관리형 전달은 Firehose가 적합. (E) DataBrew + Glue Data Catalog 크롤 조합은 F의 표준 Glue 크롤러 → Athena 뷰 흐름 대비 부정확. 【시험 포인트】 다계정/다리전 Security Hub 집계 = 위임 관리자 + EventBridge → Firehose → S3, 분석 = Glue+Athena+QuickSight.

해설

【핵심 용어】 ▸ aws:MultiFactorAuthPresent 조건 — 세션에 MFA가 있어야 액션 허용, CLI 장기 자격증명에는 MFA 컨텍스트 없음 ▸ aws sts get-session-token — MFA 시리얼/토큰으로 MFA가 포함된 임시 자격증명 발급 ▸ 임시 자격증명 — 이후 API/CLI 호출에 사용해 MFA 조건 충족 【정답 포인트】 ▸ MFA 강제 정책 때문에 일반 CLI 호출이 MFA 조건을 만족 못 해 실패 ▸ get-session-token에 --serial-number, --token-code로 MFA를 전달해 임시 자격증명 발급 후 그 값으로 EC2 CLI 호출 【오답 체크】 (A) MultiFactorAuthPresent 값을 true로 바꾸는 것은 MFA를 무력화해 보안 요건 위반. (C) SAML 2.0 페더레이션 전환은 인증 모델을 크게 바꾸는 과도한 대응. (D) assume-role + NotAction 방식은 불필요하게 복잡하고 MFA 강제 CLI 해결의 표준이 아님. 【시험 포인트】 MFA 강제 정책 하 CLI 사용 = sts get-session-token으로 MFA 포함 임시 자격증명 발급.

해설

【핵심 용어】 ▸ S3 Lifecycle expiration — 프리픽스별로 지정 기간 경과 객체 자동 삭제, 관리형·비용 효율 ▸ S3 Intelligent-Tiering — 스토리지 클래스 자동 전환(삭제 아님) ▸ 프로젝트 프리픽스(dedicated prefix) — 프로젝트별 데이터 격리 【정답 포인트】 ▸ "프로젝트 종료(최대 60일) 후 데이터 잔류 금지 + 최고 비용 효율" → 프로젝트 프리픽스별 S3 Lifecycle 구성으로 60일 후 객체 만료(삭제) ▸ 관리형 규칙이라 코드/운영 없이 저비용으로 삭제 강제 【오답 체크】 (A) EventBridge 스케줄 + Lambda로 "60일 미접근" 삭제는 커스텀 코드 오버헤드 + 기준(접근 vs 생성일)이 부정확. (B) 새 버킷 + Intelligent-Tiering 복사는 삭제가 아니라 전환이며 목적과 무관. (D) Intelligent-Tiering 아카이브 이벤트 기반 Lambda 삭제는 복잡하고 삭제 시점 제어가 부정확. 【시험 포인트】 프리픽스별 기간 경과 자동 삭제 = S3 Lifecycle expiration. Intelligent-Tiering은 전환일 뿐 삭제 아님.

해설

【핵심 용어】 ▸ S3 Block Public Access(PublicAccessBlock) — 버킷을 즉시 비공개로 전환 ▸ SCP deny s3:PutPublicAccessBlock — 누구도 Block Public Access 설정을 변경/해제하지 못하게 해 향후 공개화 방지 ▸ Organizations OU — SCP 적용 범위 【정답 포인트】 ▸ (즉시) 버킷에 PublicAccessBlock 활성화로 공개 접근 차단 ▸ (향후) OU에 SCP로 s3:PutPublicAccessBlock 액션을 거부해 아무도 Block Public Access를 해제하지 못하게 함 【오답 체크】 (A) s3:GetObject 거부 SCP는 정상 접근까지 막고 공개화 자체를 방지하지 못함. (B) GetObject 거부는 공개 여부 제어가 아니라 데이터 접근 차단으로 요구와 다름. (D) Object Lock 거버넌스 모드는 객체 불변성용이지 버킷 공개 여부 제어와 무관. 【시험 포인트】 버킷 공개 차단 = Block Public Access, 향후 해제 방지 = SCP로 s3:PutPublicAccessBlock 거부.

해설

【핵심 용어】 ▸ EBS 기본 암호화(default encryption) + Auto Scaling 인스턴스 새로 고침(instance refresh) — 신규 인스턴스가 암호화 볼륨으로 교체 ▸ Aurora 저장 암호화 — 기존 클러스터는 제자리 암호화 불가, 스냅샷에서 암호화 클러스터 재생성 필요 ▸ KMS — EBS/RDS 저장 암호화 키 【정답 포인트】 ▸ (A) 대상 리전 EBS 기본 암호화 활성화 + ASG instance refresh로 새 EC2가 암호화된 EBS로 재배포 ▸ (C) Aurora는 제자리 암호화 불가 → 기존 클러스터 스냅샷에서 KMS 암호화된 새 DB 클러스터 생성 【오답 체크】 (B) ACM은 인증서(전송 암호화)용으로 EBS 볼륨 저장 암호화를 하지 못함. (D) 기존 DB 클러스터에 KMS 암호화를 제자리로 적용할 수 없음(스냅샷 재생성 필요). (E) ACM은 DB 저장 암호화에 사용되지 않음. 【시험 포인트】 EBS 저장 암호화 = 기본 암호화 + instance refresh. Aurora는 스냅샷→암호화 클러스터 재생성(제자리 불가).