정답 · 해설

해설

【핵심 용어】 ▸ AWSSecurityHubReadOnlyAccess — Security Hub 조회에 필요한 권한을 포함한 AWS 관리형 정책 ▸ Lambda 실행 역할 — Lambda가 다른 서비스에 접근하기 위한 IAM 역할 ▸ Security Hub — Inspector 등 findings를 집계, 조회에는 GetFindings 등 권한 필요 【정답 포인트】 ▸ "Lambda가 Security Hub의 Inspector findings 조회 실패" → 실행 역할에 Security Hub 읽기 권한 부재 ▸ AWSSecurityHubReadOnlyAccess 관리형 정책을 실행 역할에 부착해 조회 권한 부여 (B) 【오답 체크】 (A) 리소스 기반 정책으로 Security Hub에 Lambda ARN 접근 허용은 방향이 반대(Lambda가 Security Hub를 호출). (C) Inspector와 Security Hub 읽기 권한을 함께 준다고 표현했으나, findings는 Security Hub에서 조회하므로 불필요하게 광범위하고 부정확. (D) 특정 Inspector 제품 ARN에만 Get*/List* 등 부여는 필요한 Security Hub API 범위를 충분히 커버하지 못함. 【시험 포인트】 Lambda가 Security Hub 조회 실패 = 실행 역할에 Security Hub 읽기 권한(관리형 read-only) 부착.

해설

【핵심 용어】 ▸ AWS Config 관리형 규칙 restricted-ssh — 보안 그룹의 무제한 SSH(22) 인바운드를 탐지 ▸ Config 자동 수정(Remediation) — 비준수 시 자동 조치, SNS 메시지 게시 가능 ▸ 준-실시간 탐지 — 보안 그룹 구성 변경 시 규칙이 트리거되어 즉시 평가 【정답 포인트】 ▸ "무제한 SSH 인바운드 위반의 준-실시간 탐지·알림 + 최고 운영 효율" → restricted-ssh 관리형 규칙 사용 ▸ 구성 변경으로 규칙 트리거 → 수정 기능으로 SNS 토픽에 알림 게시 (B) 【오답 체크】 (A) Inspector 일일 평가는 준-실시간이 아니고 Lambda 파이프라인 구축 오버헤드가 큼. (C) VPC Flow Logs + Lambda 파싱은 구성 위반이 아닌 실제 연결을 탐지, 복잡도 높음. (D) Inspector Best Practices 일일 실행도 준-실시간이 아니며 커스텀 Lambda 로직 필요. 【시험 포인트】 보안 그룹 SSH 개방 위반 준-실시간 탐지 = Config 관리형 규칙 restricted-ssh + 수정→SNS.

해설

【핵심 용어】 ▸ AWS Control Tower — 다중 계정 랜딩 존 설정·거버넌스 자동화, 대규모 계정 관리 ▸ AWS IAM Identity Center(구 SSO) — 기존 IdP 연동, 계정 전반에 페더레이션 접근 제공 ▸ 확장성/운영 효율 — 계정별 IAM 사용자 대신 중앙 페더레이션이 표준 【정답 포인트】 ▸ "수백 개 계정 + 확장성·운영 효율 극대화" → Control Tower로 다중 계정 관리 ▸ IAM Identity Center(SSO)를 기존 IdP와 통합, IdP가 assume할 IAM 역할 구성 (C) 【오답 체크】 (A) 계정마다 전용 IAM 사용자 생성은 확장성이 낮고 관리 부담이 큼. (B) 커스텀 오소라이저를 SDK로 자체 구축은 불필요한 개발·운영 오버헤드. (D) 계정마다 신뢰 정책을 수동 설정하는 방식은 수백 개 계정에서 확장성 저하. 【시험 포인트】 수백 계정 접근 + 확장/효율 = Control Tower + IAM Identity Center(SSO) IdP 페더레이션.

해설

【핵심 용어】 ▸ Amazon GuardDuty Malware Protection — EC2 감염 탐지, 발견 시 자동 대응 연계 ▸ AWS Well-Architected 사고 대응 — 증거 보존(포렌식) 후 격리/종료가 원칙 ▸ EBS 볼륨 보존 — 인스턴스 종료 전 볼륨 분리·태깅으로 포렌식 증거 확보 【정답 포인트】 ▸ "감염 탐지 시 자동 대응 + 사고 대응 지침 준수" → EventBridge/GuardDuty 트리거로 Lambda 실행 ▸ Lambda가 EBS 볼륨 분리 → 볼륨에 "Infected" 태그 → 이후 인스턴스 종료 (C): 증거 보존 후 위협 제거 【오답 체크】 (A) OS에서 네트워크 어댑터 제거는 불안정하고 포렌식 증거(볼륨) 보존이 없음. (B) ENI 삭제만으로는 감염 인스턴스가 계속 실행되어 위협 완화가 불완전. (D) 별도 VPC로 인스턴스 이동은 실행 중 인스턴스를 다른 VPC로 옮길 수 없어 구현 비현실적. 【시험 포인트】 감염 인스턴스 자동 대응 = 볼륨 분리·태깅(증거 보존) 후 인스턴스 종료.

해설

【핵심 용어】 ▸ 네트워크 ACL — 스테이트리스(stateless), 인바운드·아웃바운드를 별도 규칙으로 명시해야 함 ▸ 규칙 번호 우선순위 — 낮은 번호부터 평가, 먼저 매치되는 규칙 적용 ▸ 임시 포트(Ephemeral 1024-65535) — 스테이트리스 특성상 아웃바운드 응답 수신용 인바운드 허용 필요 【정답 포인트】 ▸ "3306 인바운드 거부" → 인바운드 규칙 100에서 3306 Deny (먼저 평가) ▸ "443 아웃바운드 TLS 허용" → 아웃바운드 규칙 100에서 443 Allow ▸ 스테이트리스라 아웃바운드 443 응답 수신 위해 인바운드 임시 포트(1024-65535) 허용 필요 (B) 【오답 체크】 (A) 인바운드 443 허용은 요구와 무관하고, 아웃바운드 응답 수신용 임시 포트 허용이 없음. (C) 임시 포트를 먼저 허용(규칙100)하면 3306 Deny(규칙200)보다 앞서 평가돼 우선순위상 명확성이 떨어짐. (D) 임시 포트(1024-65535) 인바운드 허용이 없어 아웃바운드 443 응답을 받지 못함. 【시험 포인트】 NACL은 스테이트리스 → 아웃바운드 허용 시 인바운드 임시 포트(1024-65535)도 허용해야 응답 수신.

해설

【핵심 용어】 ▸ AWS Config 커스텀 규칙 — 리소스별 조직 정책 준수 여부를 사용자 정의 로직으로 평가 ▸ AWS Config 레코딩 — 리소스 구성 기록 활성화 후 규칙 평가 가능 ▸ Amazon SNS — 비준수 발견 시 지정 수신자에게 알림 【정답 포인트】 ▸ "스테이징 미경유로 프로덕션 배포 탐지(모니터링·알림)" → Config 레코딩 켜고 커스텀 규칙으로 파이프라인 준수 검사 ▸ 비준수(스테이징 미경유) 발견 시 SNS 알림, 수신자를 SNS 구독으로 등록 (C) 【오답 체크】 (A) GuardDuty는 위협 탐지용이며 CodePipeline 배포 순서 정책 준수를 평가하지 않음. (B) CDK로 참조 아키텍처 모델링은 배포 정의일 뿐 위반 탐지·알림 기능이 아님. (D) Inspector는 취약점 평가용으로 파이프라인 배포 순서 준수 검사에 부적합. 【시험 포인트】 리소스 구성 정책 준수 여부 모니터링·알림 = AWS Config 커스텀 규칙 + SNS.

해설

【핵심 용어】 ▸ IAM 역할 세션 폐기(Revoke Sessions) — 인스턴스 프로파일의 활성 임시 자격 증명 즉시 무효화 ▸ S3 버킷 정책 Deny — 특정 IAM 역할의 접근을 즉시 차단 ▸ 인스턴스 프로파일 — EC2에 부착된 IAM 역할, 제거 시 신규 자격 증명 발급 중단 【정답 포인트】 ▸ "인스턴스 종료 없이 가장 빠르게 데이터 노출 방지" → 역할 활성 세션 권한 폐기 ▸ S3 버킷 정책으로 해당 역할 Deny + 인스턴스 프로파일에서 역할 제거 (C): 즉시 접근 차단 【오답 체크】 (A) 데이터 이관·재암호화·재업로드는 시간이 오래 걸려 "가장 빠름" 요건 위배. (B) 호스트 방화벽으로 S3 IP 차단은 관리 어렵고 우회 가능, 근본 접근 차단 아님. (D) 키 비활성화·전체 재암호화는 대량 작업으로 느리고 즉각적 노출 방지에 부적합. 【시험 포인트】 탈취 위험 자격 증명 즉시 차단 = IAM 역할 세션 폐기 + 버킷 정책 Deny + 프로파일 제거.

해설

【핵심 용어】 ▸ Amazon GuardDuty Runtime Monitoring — ECS/EKS/EC2 런타임 동작을 관찰해 위협 탐지 ▸ ECS 컨테이너 보안 태세 — 런타임 위협 탐지로 침해 지표 식별 ▸ Amazon Inspector — 취약점 스캔용으로 런타임 위협 탐지와 목적 상이 【정답 포인트】 ▸ "컨테이너 워크로드의 잠재 위협 탐지 + 클러스터 보안 태세 개선" → GuardDuty Runtime Monitoring 활성화 ▸ ECS 클러스터에서 런타임 이상 행위를 관찰해 위협 탐지 (B) 【오답 체크】 (A) Inspector는 취약점 평가용이며 런타임 위협 탐지 목적에 맞지 않음. (C) CloudWatch Logs로 API 접근 감사는 인가 접근 확인일 뿐 워크로드 위협 탐지가 아님. (D) 동일 VPC + Flow Logs 네트워크 모니터링만으로는 컨테이너 내부 위협 탐지 불가. 【시험 포인트】 컨테이너(ECS/EKS) 런타임 위협 탐지 = GuardDuty Runtime Monitoring.

해설

【핵심 용어】 ▸ Amazon GuardDuty — 암호화폐 채굴(CryptoCurrency) 관련 위협을 기본 탐지, findings 생성 ▸ Amazon EventBridge — GuardDuty finding을 조건 매칭해 SNS로 알림 ▸ Amazon SNS — 알림 전달 대상 【정답 포인트】 ▸ "EC2의 암호화폐 채굴 여부 판별 + SNS 알림" → GuardDuty 활성화(암호화폐 관련 finding 기본 지원) ▸ EventBridge 규칙으로 해당 finding을 SNS 토픽에 전달 (B) 【오답 체크】 (A) Config 커스텀 규칙(Guard 정책)으로 DNS 조회 탐지는 복잡하고 채굴 탐지 정확도가 낮음. (C) Inspector는 취약점 평가용으로 암호화폐 채굴 활동 finding을 생성하지 않음. (D) Flow Logs + Athena 쿼리는 구축·운영 오버헤드가 크고 관리형 위협 탐지가 아님. 【시험 포인트】 암호화폐 채굴 등 위협 탐지 = GuardDuty + EventBridge → SNS.

해설

【핵심 용어】 ▸ IAM 자격 증명 보고서(Credential Report) — 모든 사용자의 액세스 키 마지막 사용 시각 등 포함, CSV 다운로드 ▸ 액세스 키 노출 영향 평가 — 마지막 사용 시각 확인이 최소 오버헤드 ▸ CloudTrail vs 자격 증명 보고서 — 상세 활동은 CloudTrail, 사용 시각 요약은 보고서 【정답 포인트】 ▸ "노출 키 영향 평가 + 관리 오버헤드 최소" → IAM 자격 증명 보고서에서 액세스 키 마지막 사용 시각 확인 (D) ▸ 보고서 하나로 키 사용 여부/시점을 즉시 파악 【오답 체크】 (A) Trusted Advisor는 자격 증명 보고서를 대체하는 "IAM use report"를 제공하지 않아 부정확한 경로. (B) CloudWatch Logs에는 기본적으로 액세스 키별 활동이 없어 검색 대상이 아님. (C) VPC Flow Logs는 네트워크 흐름 로그로 액세스 키 사용 활동을 담지 않음. 【시험 포인트】 액세스 키 마지막 사용 시점 확인(최소 오버헤드) = IAM 자격 증명 보고서.

해설

【핵심 용어】 ▸ 가져온 키 자료(Imported Key Material) — 고객이 제공하는 키 자료, 만료 시각(expiration) 지정 가능 ▸ 고객 관리형 CMK — 키 정책·로테이션 제어, 가져온 자료 사용 시 자동 만료 설정 ▸ AWS 관리형 CMK — 키 자료 만료·수명 제어 불가 【정답 포인트】 ▸ "키 자료가 90일 후 자동 만료" → 고객이 제공한 키 자료를 가져온(customer provided) 고객 관리형 CMK ▸ 가져온 키 자료에만 만료 시각을 지정할 수 있음 (A) 【오답 체크】 (B) AWS 제공 키 자료의 고객 관리형 CMK는 키 자료 만료를 지정할 수 없음. (C) AWS 관리형 CMK는 키 자료 수명·만료를 제어할 수 없음. (D) OS 네이티브 GnuPG는 KMS 요구(관리형 키 관리)와 무관하고 자동 만료 관리가 표준화되지 않음. 【시험 포인트】 KMS 키 자료 자동 만료(만료일 지정) = 가져온(customer provided) 키 자료의 고객 관리형 CMK.

해설

【핵심 용어】 ▸ SAML 자격 증명 공급자(IAM IdP 엔터티) — 서명 인증서 포함 메타데이터 파일로 신뢰 구성 ▸ SAML 메타데이터 갱신 — IdP 서명 인증서 갱신 시 새 메타데이터를 IAM에 업데이트 ▸ AWS CLI 업데이트 — 최소 오버헤드로 IdP 엔터티 메타데이터 교체 【정답 포인트】 ▸ "서명 인증서 갱신 후 로그인 오류 + 오버헤드 최소" → IdP에서 갱신된 SAML 메타데이터 파일 다운로드 ▸ IAM의 SAML IdP 엔터티 메타데이터를 CLI로 업데이트 (C) 【오답 체크】 (A) SAML 신뢰는 메타데이터의 서명 인증서(공개키)로 검증, "개인키 업로드"는 잘못된 절차. (B) 메타데이터에 새 공개키로 서명 후 업로드는 SAML IdP 갱신 방식이 아님. (D) IAM SAML IdP는 공개키를 동적으로 fetch하는 구성이 없음(메타데이터 수동 업데이트 필요). 【시험 포인트】 SAML 서명 인증서 갱신 오류 = IdP의 새 SAML 메타데이터 파일을 IAM IdP 엔터티에 업데이트.

해설

【핵심 용어】 ▸ CloudWatch 지표 필터(Metric Filter) — 로그에서 특정 패턴(API 오류 코드) 매칭해 지표 생성 ▸ CloudWatch 경보(Alarm) — 지표가 임계값 초과 시 SNS 알림 ▸ CloudTrail → CloudWatch Logs — API 호출 로그를 지표화해 자동 알림 【정답 포인트】 ▸ "비인가 API 요청 일정 수 탐지 시 즉시 알림" → 오류 코드(AccessDenied 등) 패턴 지표 필터 생성 ▸ 해당 지표 비율 기반 경보로 임계값 초과 시 SNS 알림 (A) 【오답 체크】 (B) Kinesis Data Streams + Lambda 구성은 지표 필터 대비 불필요한 복잡도·오버헤드. (C) Athena 쿼리 + QuickSight 대시보드는 배치 분석이지 실시간 자동 알림이 아님. (D) Personal Health Dashboard는 AWS 서비스 상태 알림용으로 비인가 API 호출 탐지와 무관. 【시험 포인트】 비인가 API 호출 자동 알림 = CloudWatch Logs 지표 필터(오류 코드) + 경보 → SNS.

해설

【핵심 용어】 ▸ AWS Config 관리형 규칙 — 미암호화 RDS 저장소 탐지(rds-storage-encrypted 등) ▸ Config 자동 수정(Automatic Remediation) — 비준수 리소스에 자동 조치(Lambda 호출) 수행 ▸ Amazon SNS — Lambda·이메일 대상을 구독으로 등록해 알림·삭제 트리거 【정답 포인트】 ▸ "미암호화 DB 생성 시 이메일 알림 + 자동 종료 + 운영 효율 최상" → Config 관리형 규칙 + 자동 수정 ▸ SNS 토픽에 Lambda(삭제)와 이메일 대상 구독 → 자동으로 알림 및 미암호화 리소스 삭제 (A) 【오답 체크】 (B) 수동 수정(manual remediation)은 자동 개입이 필요해 운영 효율이 떨어짐. (C) EventBridge RDS 이벤트 패턴은 "암호화 여부" 준수 평가가 아니라 생성 이벤트만 감지, Config 규칙이 준수 판별에 적합. (D) 마찬가지로 EventBridge 생성 이벤트 기반은 암호화 준수 상태를 정확히 평가하지 못함. 【시험 포인트】 암호화 준수 위반 자동 탐지·조치 = Config 관리형 규칙 + 자동 수정 + SNS(Lambda·이메일).

해설

【핵심 용어】 ▸ GuardDuty 일시 중단(Suspend) — 탐지기 데이터 소스 비활성화 + 멤버 계정 연결 해제 필요 ▸ 관리자-멤버 구성 — 조직 GuardDuty는 멤버 계정 연결을 먼저 정리해야 중단 가능 ▸ 선택적 데이터 소스 — 모든 리전의 모든 탐지기에서 비활성화 【정답 포인트】 ▸ "GuardDuty 일시 중단" → 모든 리전·탐지기의 선택적 데이터 소스 비활성화 (A) ▸ 멤버 계정 연결 해제 또는 삭제 (B): 중단 전 멤버 관계 정리 필요 【오답 체크】 (C) "연계 모니터링 서비스 비활성화"는 GuardDuty 중단 절차의 요구 단계가 아님. (D) 기존 findings 삭제는 중단과 무관(중단해도 findings는 유지 가능). (E) findings 내보내기는 백업 성격일 뿐 중단 필수 단계가 아님. 【시험 포인트】 GuardDuty 중단 = 모든 리전 탐지기의 데이터 소스 비활성화 + 멤버 계정 연결 해제/삭제.

해설

【핵심 용어】 ▸ AWS CloudTrail — 계정 내 API 호출 기록, 실패한 API 호출과 원인 파악의 1차 근거 ▸ CloudFormation 배포 실패(IAM 권한 부족) — 어떤 API가 거부됐는지 로그로 확인이 우선 ▸ SCP vs IAM 권한 — 원인 규명 전 무작정 제거/변경은 부적절 【정답 포인트】 ▸ "IAM 권한 부족 오류의 첫 번째 troubleshoot 단계" → Production 계정 CloudTrail 로그 검토 ▸ 배포 시점 CloudFormation의 실패 API 호출을 검색해 정확한 원인 식별 (A) 【오답 체크】 (B) SCP를 모두 제거하고 재실행은 위험한 변경이며 원인 규명 없는 시행착오. (C) 역할 권한 확인은 유효한 조치이나, "첫 번째 단계"는 실패 API를 로그로 특정하는 것이 우선. (D) Production SCP를 Testing과 동일화하는 것은 근거 없는 성급한 변경. 【시험 포인트】 권한 부족 배포 실패의 첫 단계 = CloudTrail에서 실패한 API 호출 확인(원인 특정).

해설

【핵심 용어】 ▸ SSE-KMS — KMS의 고객 관리형 CMK로 S3 서버 측 암호화, 회사가 키 완전 통제 ▸ 고객 관리형 CMK — 키 정책·로테이션·사용 감사까지 회사가 제어 ▸ 기존 객체 재암호화 — 버킷 설정 변경은 신규 객체에만 적용, 기존 객체는 새 키로 재암호화 필요 【정답 포인트】 ▸ "모든 암호화 키를 회사가 통제" → 고객 관리형 CMK 생성 (A) ▸ S3 버킷 암호화를 SSE-S3에서 SSE-KMS로 변경 (E) ▸ 기존 모든 객체를 새 키로 재암호화하여 통제 대상 키로 전환 (F) 【오답 체크】 (B) SSE-C는 클라이언트가 키를 매 요청 전달하는 방식으로 KMS 중앙 키 통제 요건에 부합하지 않고 운영 부담 큼. (C) SSE-S3 키로 클라이언트 암호화한다는 것은 성립하지 않고 회사 키 통제와 무관. (D) S3용 AWS 관리형 CMK는 AWS가 관리하므로 "회사가 키 통제" 요건 위배. 【시험 포인트】 회사가 키 완전 통제 + S3 서버 측 암호화 = 고객 관리형 CMK로 SSE-KMS + 기존 객체 재암호화.

해설

【핵심 용어】 ▸ KMS 키 정책 — 키 접근을 통제하는 최종 권한, "Enable IAM User Permissions" 문(root 위임)으로 계정 IAM 정책이 접근 허용 가능 ▸ 최소 권한 키 정책 — root 위임 문 제거 시 키 정책에 명시된 주체만 접근 ▸ 의도치 않은 역할 접근 — 계정 IAM 정책 경유 접근을 차단해야 함 【정답 포인트】 ▸ "InfrastructureDeployment 외 역할이 키 사용" → 계정 IAM 정책 경유 접근을 허용하던 "Enable IAM User Permissions" 문 제거 ▸ 키 관리 정책을 KMS 정책에 명시해 키 정책만으로 접근 통제 (B) 【오답 체크】 (A) StringEquals→StringLike 변경은 조건을 오히려 느슨하게 만들어 문제 악화. (C) kms:ViaService 값 변경은 서비스 제한일 뿐 다른 역할의 접근 차단이 핵심이 아님. (D) 보안 엔지니어 역할에 kms:Disable* 부여는 관리 권한 추가일 뿐 문제 해결과 무관. 【시험 포인트】 키를 IAM 정책 경유로 다른 주체가 쓸 때 = 키 정책의 root 위임(Enable IAM User Permissions) 문 제거.

해설

【핵심 용어】 ▸ NAT 게이트웨이(AZ별) — 프라이빗 서브넷 아웃바운드용, 고정 EIP로 외부 결제사 IP 허용 목록에 안정적 소스 제공 ▸ 프라이빗 서브넷 배치 — DB·EC2를 프라이빗에 두어 인터넷 직접 노출 차단 ▸ ALB(퍼블릭) — HTTP/HTTPS 인바운드만 인터넷에서 수신 【정답 포인트】 ▸ "결제사 IP 허용 목록이 스케일링에도 끊기지 않음" → AZ별 프라이빗 서브넷에 NAT 게이트웨이 배치(고정 EIP) (A) ▸ DB 인스턴스를 프라이빗 서브넷에 배치 (C) ▸ Auto Scaling EC2를 프라이빗 서브넷에 배치 (E): 확장돼도 NAT의 고정 IP로 통신 【오답 체크】 (B) DB를 퍼블릭 서브넷에 두면 불필요한 노출로 보안 위배. (D) EC2를 퍼블릭 서브넷에 두면 인스턴스별 IP가 변동/노출되어 결제사 허용 목록 유지 곤란. (F) ALB를 프라이빗 서브넷에 두면 인터넷 HTTP/HTTPS 인바운드를 받을 수 없음. 【시험 포인트】 스케일링해도 외부 IP 허용 목록 유지 = 프라이빗 서브넷 + AZ별 NAT 게이트웨이(고정 EIP 소스).

해설

【핵심 용어】 ▸ AWS KMS 커스텀 키 스토어(CloudHSM 지원) — FIPS 140-2 Level 3 검증 HSM에 키 자료 보관 ▸ Amazon RDS 암호화 — 관리형 DB로 운영 오버헤드 최소, KMS 키로 저장 암호화 ▸ FIPS 140-2 Level 3 — CloudHSM 기반 커스텀 키 스토어로 충족 【정답 포인트】 ▸ "저장 암호화 + FIPS 140-2 Level 3 + 운영 오버헤드 최소" → RDS(MySQL) 관리형 사용 ▸ CloudHSM 지원 KMS 커스텀 키 스토어로 키 관리해 Level 3 준수 (A) 【오답 체크】 (B) AWS 관리형 CMK는 FIPS 140-2 Level 3 검증 요건(전용 HSM)을 보장하지 않음. (C) EC2 자체 호스팅 DB는 관리형 대비 운영 오버헤드가 큼(패치·HA 직접 관리). (D) EC2 + TDE 자체 관리는 운영 부담이 크고 Level 3 HSM 요건 충족을 별도 구성해야 함. 【시험 포인트】 FIPS 140-2 Level 3 키 관리 = CloudHSM 지원 KMS 커스텀 키 스토어. 오버헤드 최소 = RDS.