정답 · 해설

해설

【핵심 용어】 ▸ AWS Verified Access — VPN 없이 애플리케이션 접근, 신원 + 기기 posture 등 조건 기반 허용 ▸ ALB용 endpoint 생성으로 앱 등록 【정답 포인트】 ▸ Verified Access 구성 + ALB endpoint 생성 → VPN 없이, 기기 posture 등 조건 충족 시에만 접근 【오답 체크】 (A) WAF는 기기 posture 기반 접근 제어가 아님 (C)(D) Verified Permissions는 앱 내 인가(권한) 서비스지 네트워크 접근/기기 posture가 아님 【시험 포인트】 ▸ VPN 없는 조건부(기기 posture) 접근 = AWS Verified Access

해설

【핵심 용어】 ▸ Permissions boundary — 생성되는 role의 최대 권한 상한 ▸ dev role에 boundary를 참조시켜 위임 권한을 보안팀이 통제 【정답 포인트】 ▸ 필요한 권한의 관리형 정책을 permissions boundary로 만들고 dev role에 참조 ▸ 개발자가 role을 직접 생성하되 보안팀이 상한 통제 → 권한상승 방지, 최소 관리 【오답 체크】 (A) CloudTrail 모니터링은 탐지이지 예방이 아님 (C) iam:CreateUser SCP는 role 위임 통제가 아님 (D) 티켓 방식은 오버헤드↑ 【시험 포인트】 ▸ role 자체 생성 허용 + 권한상승 방지 = permissions boundary

해설

【핵심 용어】 ▸ Security Hub 표준(CIS/FSBP)은 AWS Config 기반으로 리소스를 평가 ▸ Config 미활성 시 평가 결과가 나오지 않음 【정답 포인트】 ▸ AWS Config 활성화 + 필요한 Config 규칙 생성 → Security Hub가 CIS 평가 수행 【오답 체크】 (A) Inspector 권한은 무관 (B) Trusted Advisor 기반이 아님 (D) CloudTrail 트레일은 CIS 평가의 전제가 아님 【시험 포인트】 ▸ Security Hub 결과 없음 = AWS Config 활성화 확인(표준은 Config 의존)

해설

【핵심 용어】 ▸ 교차계정 AssumeRole에 MFA 강제 = role 신뢰(trust) 정책에 aws:MultiFactorAuthPresent 조건 ▸ 권한/세션/버킷 정책이 아님 【정답 포인트】 ▸ role 신뢰 정책에 aws:MultiFactorAuthPresent=true 조건 → MFA 인증 시에만 assume 허용 【오답 체크】 (A) 권한 정책은 assume 조건을 제어하지 못함 (C) 세션 정책은 위임 후 권한 축소용 (D) 버킷 정책은 S3 접근 제어지 assume 조건이 아님 【시험 포인트】 ▸ AssumeRole MFA 강제 = trust policy의 aws:MultiFactorAuthPresent

해설

【핵심 용어】 ▸ 전송 중 암호화 = ACM 인증서(ALB) + 백엔드 TLS / 저장 암호화 = RDS 암호화 + EBS 암호화 ▸ ACM 인증서는 무료 【정답 포인트】 ▸ ALB에 ACM 인증서(무료), EC2엔 self-signed(내부 구간), RDS TLS 연결 ▸ RDS·EBS 암호화 → 전송·저장 암호화, 최소 비용·오버헤드 【오답 체크】 (B) 서드파티 인증서는 비용·관리↑ (C) CloudHSM은 고비용·과도 (D) origin에 HTTP(평문)는 전송 중 암호화 위배 【시험 포인트】 ▸ 저비용 전송+저장 암호화 = ACM(무료) + RDS/EBS 암호화

해설

【핵심 용어】 ▸ L3/L4 DDoS 방어 = AWS Shield(자동 L3/4 완화) + ELB(트래픽 흡수·분산) + Route 53(견고한 DNS) 【정답 포인트】 ▸ (A) Route 53, (D) Shield, (E) Elastic Load Balancer → L3/L4 DDoS 완화 【오답 체크】 (B) ACM은 인증서 관리 (C) S3는 정적 스토리지 (F) GuardDuty는 위협 탐지이지 DDoS 완화가 아님 【시험 포인트】 ▸ L3/4 DDoS = Shield + ELB + Route 53(엣지·인프라 보호)

해설

【핵심 용어】 ▸ KMS 접근 = 키 정책 + IAM 정책, 명시적 Deny가 우선 ▸ 키 정책에 encryption context 조건이 있으면 호출 시 해당 context가 필수 【정답 포인트】 ▸ (B) KMSUser의 IAM 정책에 GenerateDataKey에 대한 명시적 Deny가 없는지 확인 ▸ (D) 키 정책이 요구하는 encryption context 키-값을 GenerateDataKey 호출에 포함 【오답 체크】 (A) Resource에 key ID를 넣는 것은 무관 (C) IAM 정책의 "encryption context 허용" 표현은 부정확 (E) grant deny가 원인이 아님(키 정책의 context 조건 문제) 【시험 포인트】 ▸ KMS AccessDenied = 명시적 Deny 여부 + 요구되는 encryption context 포함 확인

해설

【핵심 용어】 ▸ 저장 암호화(RDS/EBS) + 자격증명은 Secrets Manager(자동 회전) + 전송 TLS ▸ 지원팀이 인프라에 접근하더라도 데이터 보호 【정답 포인트】 ▸ RDS·EBS 암호화 + Secrets Manager 자동 회전으로 DB 자격증명 저장 + RDS TLS ▸ 유출 대비 + 정기 회전, 최소 관리 오버헤드 【오답 체크】 (A) 자격증명을 EC2 user data에 두는 것은 노출 위험 (B) CloudHSM에 DB 자격증명 저장은 부적합·과도 (D) Parameter Store도 회전 가능하나 CloudHSM 조합은 과도, 표준 통합은 Secrets Manager 【시험 포인트】 ▸ 자격증명 자동 회전 + 저장/전송 암호화 = Secrets Manager + RDS/EBS 암호화 + TLS

해설

【핵심 용어】 ▸ AWS Backup backup plan — 백업 규칙·보존기간을 중앙 관리 ▸ RDS 스냅샷 보존기간은 백업 플랜의 retention으로 설정 【정답 포인트】 ▸ AWS Backup에 백업 플랜 생성 + 5년 보존 기간 구성 → RDS 스냅샷 수명주기 관리 【오답 체크】 (A) 태그만으론 보존을 강제하지 못함 (B) S3 버전관리는 스냅샷 보존 메커니즘이 아님 (C) S3 Lifecycle은 AWS Backup 스냅샷 보존을 제어하지 않음(백업 볼트가 관리) 【시험 포인트】 ▸ 백업 보존 = AWS Backup 백업 플랜의 retention 설정

해설

【핵심 용어】 ▸ CloudWatch Logs 구독 필터 → Kinesis Data Firehose(관리형 S3 전달)로 교차계정 집계 ▸ CloudTrail은 계정별로 S3에 전달 【정답 포인트】 ▸ 보안팀 계정에 Firehose(→S3), 각 계정 로그 그룹의 구독을 그 Firehose로 연결 ▸ 각 계정 CloudTrail→S3 → 중앙 집계, 운영 효율(Firehose는 관리형이라 오버헤드↓) 【오답 체크】 (A)(C) 각 계정마다 스트림을 두면 관리가 분산 (C)(D) Kinesis Data Streams는 소비자를 직접 관리해야 해 Firehose보다 오버헤드↑ 【시험 포인트】 ▸ 로그 중앙 집계(관리형) = 중앙 계정 Firehose + 구독 필터

해설

【핵심 용어】 ▸ Security Hub central configuration — 위임 관리자 계정에서 구성 정책을 조직 root에 연결 ▸ 신규 계정이 자동으로 멤버가 됨(최소 개발) 【정답 포인트】 ▸ 위임 관리자 지정 + Security Hub 활성 구성 정책을 org root에 연결 ▸ 신규 계정이 자동 온보딩 → 코드/워크플로 불필요 【오답 체크】 (A) Step Functions/EventBridge는 개발 필요 (B) 자동 온보딩은 central configuration 설정이 전제(그냥 대기로는 안 됨) (C) Lambda + Control Tower 훅은 개발·유지보수↑ 【시험 포인트】 ▸ 신규 계정 Security Hub 자동 = central configuration policy(위임 관리자 + org root)

해설

【핵심 용어】 ▸ GuardDuty EKS Protection(감사 로그 모니터링)은 EKS 컨트롤 플레인(감사) 로그가 CloudWatch로 수집돼야 분석 가능 【정답 포인트】 ▸ EKS 컨트롤 플레인 로그를 활성화하고 CloudWatch로 수집 → GuardDuty가 쿠버네티스 애플리케이션 모니터링 【오답 체크】 (A) VPC flow logs는 EKS 감사 로그가 아님 (B)(C) 관리형 정책 추가는 원인이 아님 【시험 포인트】 ▸ GuardDuty EKS 모니터링 = EKS 컨트롤 플레인(감사) 로그 활성화 + CloudWatch 수집

해설

【핵심 용어】 ▸ SCP — 조직 계정의 최대 권한 경계, root 포함해 CloudTrail 변경 금지를 강제 가능 ▸ IAM 정책은 root나 다른 경로 우회를 막지 못함 【정답 포인트】 ▸ 특정 CloudTrail 변경을 금지하는 SCP를 해당 OU/계정에 적용 ▸ DevOps 팀원(root 포함)이 트레일을 수정·비활성화하지 못함 【오답 체크】 (A) IAM 정책은 root user에 적용 불가 (B) 대상 계정의 버킷 정책은 소스 트레일 설정 변경을 막지 못함 (D) IAM group 방식은 root/다른 경로로 우회 가능 【시험 포인트】 ▸ 계정 전반(root 포함) 행위 금지 = SCP

해설

【핵심 용어】 ▸ aws:MultiFactorAuthPresent — 요청에 MFA 인증이 있는지 나타내는 글로벌 조건 키 (Bool/BoolIfExists) ▸ IAM 그룹 정책 — 그룹에 Deny를 붙이면 소속 사용자 전원에 일괄 적용, 유지보수 최소화 ▸ BoolIfExists — 키가 없는 요청도 안전하게 평가, MFA 미인증(false) 시 Deny 트리거 【정답 포인트】 ▸ "그룹 사용자 전원 + 유지보수 최소" → 개별 사용자(A)가 아닌 그룹(B)에 Deny 정책 부착 ▸ "MFA 인증 후에만 S3 허용" → 조건 { BoolIfExists: { aws:MultiFactorAuthPresent: false } } 로 MFA 없을 때 Deny (D) ▸ 이미 S3 Full Access가 있으므로 명시적 Deny + MFA 조건 조합으로 MFA 강제 【오답 체크】 (A) 사용자마다 개별 정책 부착은 유지보수 오버헤드 증가, 그룹 정책이 더 효율적. (C) Allow 정책 추가는 이미 부여된 접근을 막지 못함, MFA 강제와 무관. (E) Bool 사용 시 키가 없는 요청 평가에서 예외가 생길 수 있어 BoolIfExists가 권장. 【시험 포인트】 "MFA 인증 후에만 허용" → 그룹에 Deny + aws:MultiFactorAuthPresent(BoolIfExists false) 조건.

해설

【핵심 용어】 ▸ AWS Config 관리형 규칙 — 리소스 구성 준수 여부 지속 평가, 규정 위반 탐지 ▸ Amazon EventBridge — Config 규칙의 컴플라이언스 상태 변경 이벤트를 SNS로 라우팅 ▸ RDS 암호화 — 기존 인스턴스는 암호화 활성화 불가, 스냅샷 복사 시 암호화 후 복원 필요 【정답 포인트】 ▸ "미래 정책 이탈 탐지" → Config 규칙 + EventBridge 상태 변경 트리거 + SNS 알림 (A) ▸ "기존 미암호화 DB 암호화" → 스냅샷 생성 → 복사하며 암호화 활성화 → 암호화 스냅샷에서 복원 → 원본 삭제 (D) 【오답 체크】 (B) State Manager는 구성 관리/자동화용으로 RDS 암호화 드리프트 탐지에 부적합. (C) RDS는 미암호화 소스에서 암호화 읽기 복제본을 만들 수 없음(암호화 상태가 소스와 일치해야 함). (E) 기존 RDS 인스턴스의 구성 변경만으로 저장 데이터 암호화를 켤 수 없음. 【시험 포인트】 기존 RDS 암호화 = 암호화 스냅샷 복사 후 복원. 지속 탐지 = Config 규칙 + EventBridge + SNS.

해설

【핵심 용어】 ▸ AWS Systems Manager Session Manager — SSH 포트/베스천 없이 브라우저·콘솔 기반 셸 접근, 최소 권한 ▸ SSM Agent — EC2에 설치되어 Systems Manager와 통신, Session Manager 접근 전제 조건 ▸ AmazonEC2RoleforSSM — EC2가 SSM과 통신하기 위한 인스턴스 역할 【정답 포인트】 ▸ "콘솔에서 대화형 CLI 접근 + 최소 권한" → Session Manager로 포트 개방 없이 접근 ▸ SSM 활성화 + Agent 설치 + Session Manager 사용 권한을 IAM 사용자에 부여 (A) 【오답 체크】 (B) EC2 콘솔의 "SSH 접근 활성화"라는 기능은 존재하지 않음, 구성 불가. (C) 22번 포트를 모든 IP에 개방하면 최소 권한/보안 원칙 위배. (D) EC2 콘솔 접근 권한만 부여하면 Session Manager 세션을 시작할 수 없음. 【시험 포인트】 포트 개방 없이 EC2 대화형 접근 = Systems Manager Session Manager + SSM Agent.

해설

【핵심 용어】 ▸ VPC 인터페이스 엔드포인트(AWS PrivateLink) — 서비스에 프라이빗 IP로 접근, 트래픽이 AWS 네트워크 내부에 머묾 ▸ Kinesis Data Firehose — 스트리밍 데이터 전송 관리형 서비스, VPC 엔드포인트 지원 ▸ Direct Connect — 온프레미스-VPC 전용 회선, 엔드포인트와 결합해 프라이빗 경로 완성 【정답 포인트】 ▸ "프라이빗 네트워크로 전송 중 암호화" → Firehose용 VPC(인터페이스) 엔드포인트 생성 ▸ 애플리케이션이 엔드포인트로 연결 → 퍼블릭 인터넷 미경유 + TLS로 암호화된 프라이빗 경로 (A) 【오답 체크】 (B) IAM 소스 IP 조건은 접근 제어일 뿐 프라이빗 경로·전송 암호화를 보장하지 않음. (C) 퍼블릭 NLB는 인터넷 노출 경로로 "프라이빗 네트워크" 요건 위배, Firehose를 NLB 타깃으로 둘 수도 없음. (D) "Firehose VPC와 피어링"은 불가능한 구성(관리형 서비스는 고객 VPC 피어링 대상 아님). 【시험 포인트】 관리형 서비스로 프라이빗·전송 암호화 접근 = VPC 인터페이스 엔드포인트(PrivateLink).

해설

【핵심 용어】 ▸ AWS WAF Rate-based Rule — 소스 IP별 요청 속도 임계값 초과 시 자동 차단, L7 DDoS 방어 ▸ AWS Managed Rules — 일반 위협 패턴 규칙 그룹, 속도 제한 기능은 별도 ▸ CloudFront + WAF — 엣지에서 요청 필터링, DDoS는 엣지에서 차단이 효율적 【정답 포인트】 ▸ "대규모 L7 DDoS + 엣지 방어" → WAF에 rate-based 규칙 추가로 임계값 초과 요청 자동 차단 (C) ▸ 기존 WAF web ACL에 규칙만 추가하므로 엣지에서 즉시 완화 【오답 체크】 (A) Lambda@Edge로 자체 속도 제한 구현은 개발·운영 오버헤드가 크고 WAF 기본 기능으로 대체 가능. (B) WAF 용량 단위(WCU) 증가는 규칙 처리 용량일 뿐 DDoS 차단과 무관. (D) CloudFront 오리진을 "WAF로" 설정하는 구성은 존재하지 않음(WAF는 오리진이 아님). 【시험 포인트】 L7 요청 폭주(레이어7 DDoS) = AWS WAF rate-based rule.

해설

【핵심 용어】 ▸ AWS KMS CMK 상태 — 존재 여부·활성화(Enabled) 상태가 아니면 암호화/복호화 실패 ▸ Parameter Store SecureString — KMS CMK로 암복호화, 유효한 활성 키 필요 ▸ CMK 식별 — 키 ID/ARN/별칭 모두 유효하게 참조 가능 【정답 포인트】 ▸ "각 시도마다 오류" → 참조하는 CMK가 존재하지 않음 (A) ▸ 또는 CMK가 비활성화(Disabled) 상태여서 암복호화 불가 (D) 【오답 체크】 (B) 키 로테이션 필요 여부는 오류 원인이 아님(로테이션은 자동/백그라운드). (C) 키 ID로 참조해도 정상 동작, ARN 대신 ID 사용이 오류 원인이 아님. (E) 별칭(alias) 사용도 유효한 CMK 참조 방식이므로 오류 원인이 아님. 【시험 포인트】 KMS 암복호화 실패 원인 = 키가 없음(존재하지 않음) 또는 비활성화 상태.

해설

【핵심 용어】 ▸ Amazon Verified Permissions — Cedar 정책 기반 세분화(fine-grained) 권한 부여 관리형 서비스 ▸ Amazon Cognito — 사용자 인증/속성 저장(사용자 풀·자격 증명 풀) ▸ 정책 스토어(Policy Store) — Cognito를 자격 증명 소스로 연동, 토큰의 사용자 속성으로 인가 【정답 포인트】 ▸ "Cognito 사용자 속성 기반 세분화 인가" → Verified Permissions 정책 스토어 생성 ▸ Cognito를 자격 증명 소스로 구성, Cognito 액세스 토큰을 Verified Permissions 스키마에 매핑 (B) 【오답 체크】 (A) IAM 역할/정책은 AWS 리소스 접근 제어용으로 커스텀 앱 내부 리소스의 세분화 인가에 부적합. (C) AWS RAM은 계정 간 리소스 공유용이며 앱 사용자 인가와 무관. (D) IAM 사용자를 Cognito 사용자 풀에 매핑하는 구성은 존재하지 않고 세분화 인가 목적에 맞지 않음. 【시험 포인트】 애플리케이션 내부 리소스의 세분화 인가 + Cognito 연동 = Amazon Verified Permissions.