정답 · 해설

해설

【핵심 용어】 ▸ S3 Bucket Policy — 버킷 수준에서 리소스 접근을 제어하는 정책 ▸ Resource ARN — 정책이 적용되는 AWS 리소스의 식별자 【정답 포인트】 ▸ Lambda가 S3 객체를 읽으려면 s3:GetObject 권한이 필요합니다 ▸ Resource는 버킷 자체(arn:aws:s3:::bucket-name)가 아니라 버킷 내 객체(arn:aws:s3:::bucket-name/*)를 지정해야 합니다 ▸ 버킷 정책의 Resource 요소는 버킷의 객체에 대한 권한을 명시해야 함 【오답 체크】 (A) Condition 제거는 정책 제약을 약화시킬 뿐 근본 문제를 해결하지 못함 (B) Action 변경만으로는 Resource 범위 부족 문제를 해결하지 못함 (D) Lambda ARN은 S3 버킷 정책의 Resource로 부적절하며, Principal 변경도 필요하지 않음 【시험 포인트】 ▸ S3 버킷 정책에서 객체 접근은 "/*" 와일드카드로 지정 ▸ 정책 구조: Principal(누가) → Action(무엇) → Resource(어디에) ▸ GetObject 권한은 객체 수준이므로 Resource에 /* 필수

해설

【핵심 용어】 ▸ AWS Certificate Manager (ACM) — SSL/TLS 인증서 프로비저닝·저장·갱신 관리형 서비스, CloudFront·ALB 등에 연결 ▸ AWS KMS — 암호화 키 관리용, TLS 인증서 저장소가 아님 ▸ CloudFront 기본 인증서 — *.cloudfront.net 도메인용, 커스텀 도메인(example.com)에는 부적합 【정답 포인트】 ▸ "example.com HTTPS" + "SSL/TLS 인증서 저장" → 커스텀 인증서를 ACM에 저장/관리하는 것이 표준 ▸ ACM은 인증서를 발급·저장하고 CloudFront/ELB에 연결해 HTTPS 제공 【오답 체크】 (A) KMS는 암호화 키 관리용이며 SSL/TLS 인증서를 저장·서빙하는 저장소가 아님. (B) CloudFront 기본 인증서는 *.cloudfront.net 도메인 전용으로 커스텀 도메인 example.com에 사용 불가. (D) S3는 객체 스토리지로 웹사이트용 SSL/TLS 인증서 저장/제공 대상이 아님. 【시험 포인트】 AWS에서 SSL/TLS 인증서 저장·관리는 ACM. 커스텀 도메인 HTTPS면 ACM 커스텀 인증서.

해설

【핵심 용어】 ▸ STS (Security Token Service) — 임시 보안 자격증명을 발급하는 서비스 ▸ aws:MultiFactorAuthPresent — MFA 인증 여부를 검증하는 정책 조건 ▸ get-session-token — MFA 기기의 코드로 임시 자격증명을 얻는 명령어 【정답 포인트】 ▸ MFA를 요구하는 정책은 aws:MultiFactorAuthPresent가 true일 때만 권한 부여 ▸ CLI에서 직접 API 호출 시 이 조건을 만족할 수 없음 (임시 토큰 없음) ▸ get-session-token으로 MFA 인증 후 임시 자격증명을 얻어 사용해야 함 ▸ 임시 토큰에는 MFA 시간 정보가 포함되어 정책 조건을 만족 【오답 체크】 (A) 값을 true로 변경해도 MFA 인증 없이는 조건을 만족할 수 없음 (C) 페더레이션은 별도 인프라 필요하고 복잡도 증가 (D) 역할 가정도 get-session-token 사용과 동일하게 MFA 요구, 더 복잡한 추가 단계 【시험 포인트】 ▸ MFA 요구 정책으로 인한 CLI 실패 = get-session-token 사용 필수 ▸ get-session-token은 mfa_serial과 token_code로 임시 자격증명 발급 ▸ 발급된 토큰(AWS_ACCESS_KEY_ID 등)을 환경변수로 설정하여 사용

해설

【핵심 용어】 ▸ Service Control Policy (SCP) — Organizations 계정에 대한 최대 권한을 정의하는 정책 ▸ aws:RequestedRegion — API 요청이 타겟팅하는 리전을 나타내는 조건 키 ▸ Deny 효과 — 명시적으로 권한을 거부하는 SCP 문 【정답 포인트】 ▸ SCP는 eu-west-1 리전의 작업만 허용하고 나머지는 거부해야 함 ▸ 글로벌 서비스(IAM, CloudFront 등)는 리전 조건이 적용되지 않음 ▸ Condition에 aws:RequestedRegion 조건을 사용하여 리전 제한 구현 ▸ Action은 모든 서비스("*")에 적용되지만 특정 글로벌 서비스는 제외 ▸ NotAction을 사용하여 글로벌 서비스를 예외 처리 【오답 체크】 (A) (B) (D) — 리전 기반 제약이 부족하거나 글로벌 서비스 예외 처리 미흡 【시험 포인트】 ▸ SCP는 Deny 기반으로 최대 권한 설정 (화이트리스트 방식) ▸ RequestedRegion 조건으로 리전 제한 구현 ▸ NotAction으로 글로벌 서비스(iam:*, cloudfront:* 등) 제외 ▸ OU와 계정 모두에 적용되는 조직 정책 구조

해설

【핵심 용어】 ▸ AWS Direct Connect — 온프레미스↔AWS 전용 물리 회선, 일관된 저지연·고대역폭 (단, 자체 암호화 없음) ▸ AWS Site-to-Site VPN — IPsec 암호화 터널로 온프레미스↔VPC 연결 ▸ VPN CloudHub — 여러 사이트 간 허브 연결용 ▸ VPC Peering — VPC↔VPC 연결, 온프레미스 대상 아님 【정답 포인트】 ▸ "네트워크 지연에 민감" → Direct Connect가 일관된 저지연 제공 (B) ▸ "IPsec 암호화 필요" → Site-to-Site VPN이 IPsec 터널 제공 (A) ▸ 두 요구를 함께 충족하려면 Direct Connect 회선 위에 Site-to-Site VPN을 얹어 저지연 + IPsec 동시 확보 【오답 체크】 (C) VPN CloudHub는 다중 원격 사이트 간 연결 구성용으로 이 시나리오와 무관. (D) VPC Peering은 VPC 간 연결이며 온프레미스 데이터센터 연결 불가. (E) NAT gateway는 프라이빗 서브넷의 아웃바운드 인터넷 접속용, 하이브리드 연결/암호화와 무관. 【시험 포인트】 "저지연 + IPsec 암호화" 하이브리드 → Direct Connect(성능) + Site-to-Site VPN(암호화) 조합.

해설

【핵심 용어】 ▸ KMS Key Policy — KMS 키에 대한 접근을 제어하는 리소스 기반 정책 ▸ Condition — 정책이 적용되기 위한 추가 조건(서비스, 리전 등) ▸ kms:ViaService — 특정 AWS 서비스를 통한 접근만 허용 【정답 포인트】 ▸ 키 정책의 Principal은 ExampleRole 역할을 지정 ▸ Condition은 kms:ViaService로 WorkMail 또는 SES만 가능 ▸ Condition은 aws:RequestedRegion으로 특정 리전만 허용 ▸ 이 세 가지 조건이 모두 충족될 때만 암호화/복호화 가능 ▸ "위임된 권한"이 아니라 "조건부 직접 권한" 【오답 체크】 (A) "위임된" 권한이라는 표현은 정확하지 않음. WorkMail/SES가 독립적으로 권한 갖는 것이 아님 (B) ExampleRole과 AWS 간 직접 암호화는 정책 조건과 맞지 않음 (D) 계정 전체 키에 대한 권한이 아니라 특정 키에만 적용되고, 조건이 모두 만족해야 함 【시험 포인트】 ▸ KMS 키 정책: Principal + Action + Condition의 조합으로 접근 제어 ▸ kms:ViaService 조건으로 특정 AWS 서비스 경로만 허용 ▸ 리전 조건도 포함되어 지정된 리전에서만 작동 ▸ 모든 조건이 AND 논리로 조합됨

해설

【핵심 용어】 ▸ Bucket Policy — S3 버킷 수준에서 리소스 접근을 제어하는 정책 ▸ Explicit Deny — 명시적 거부로, 모든 Allow보다 우선순위가 높음 ▸ Principal — 페더레이션 사용자를 AWS principal ARN으로 지정 【정답 포인트】 ▸ 버킷 정책만으로 특정 사용자를 거부하려면 명시적 Deny 사용 ▸ Effect: "Deny"로 설정하여 Bob의 모든 S3 액션을 거부 ▸ Principal은 Bob의 페더레이션 사용자 ARN으로 지정 ▸ Resource는 버킷 및 객체(bucket, bucket/*)를 포함 ▸ IAM 정책이 아닌 버킷 정책이므로 Bob의 다른 권한에 영향 없음 【오답 체크】 (A) (C) (D) — 명시적 Deny 없이 Allow 정책만으로는 거부 효과 제한적 【시험 포인트】 ▸ 버킷 정책의 Deny는 IAM 정책과 무관하게 작동 ▸ 페더레이션 사용자의 Principal은 arn:aws:iam::account:federated-user/name 형식 ▸ Explicit Deny가 모든 Allow를 오버라이드함 (우선순위 최고) ▸ 다른 권한에 영향 주지 않으려면 리소스를 특정 버킷으로 제한

해설

【핵심 용어】 ▸ Amazon GuardDuty — 위협 탐지, RDP 브루트포스 등 findings 생성 → EventBridge로 자동화 연계 ▸ AWS Network Firewall — VPC 트래픽 필터링 관리형 방화벽, 정책 규칙으로 특정 인스턴스 통신 차단 가능 ▸ AWS Security Hub — GuardDuty findings 집계, EventBridge로 전달 ▸ EventBridge + Lambda — 이벤트 기반 자동 대응(remediation) 파이프라인 【정답 포인트】 ▸ "의심 인스턴스의 통신을 조사·조치 시까지 차단" → Network Firewall 정책에 차단 규칙을 Lambda로 추가하는 자동화 ▸ Security Hub가 GuardDuty findings 수집 → EventBridge → Lambda가 Network Firewall 규칙 삽입 【오답 체크】 (A) Kinesis Data Analytics(Flink)로 처리 후 NACL 규칙 추가는 과도하게 복잡하고 실시간 자동 차단에 비효율. (B) AWS WAF는 HTTP/L7 웹 트래픽용으로 RDP(TCP 3389) 차단에 부적합. (D) Security Hub는 Kinesis data stream을 이벤트 대상으로 직접 지원하지 않음(EventBridge 경유가 정상 경로). 【시험 포인트】 GuardDuty 자동 대응 = EventBridge 트리거. 네트워크 계층 차단은 Network Firewall/SG/NACL, WAF는 L7 전용.

해설

【핵심 용어】 ▸ S3 Object Lock — S3 객체를 WORM(Write-Once-Read-Many) 모델로 보호 ▸ Compliance Mode — 관리자도 설정된 보유 기간 전에 삭제할 수 없음 ▸ S3 Replication — 한 버킷의 객체를 다른 버킷으로 자동 복제 【정답 포인트】 ▸ Object Lock compliance mode는 root 사용자도 삭제 불가 ▸ 복제 대상 버킷에 Object Lock 설정되면 같은 WORM 보호 유지 ▸ 관리자 권한을 가져도 retention 기간 전 삭제 불가능 ▸ 재해 복구와 데이터 보호를 동시에 만족 【오답 체크】 (A) Backup Vault Lock governance mode는 관리자가 잠금 해제 가능 (insufficient) (C) 버킷 정책은 IAM 정책으로 우회 가능하며, 버킷 정책 변경으로 삭제 가능 (D) 버전 관리만으로는 영구 삭제를 완전히 방지할 수 없음 【시험 포인트】 ▸ 데이터 불변성 요구 = S3 Object Lock compliance mode ▸ Compliance mode가 유일한 "관리자도 변경 불가" 옵션 ▸ Object Lock은 복제 시 자동으로 대상에도 적용됨 ▸ 거버넌스 모드(governance)는 관리자가 변경 가능 → 부족

해설

【핵심 용어】 ▸ Multi-Region Key (mrk-) — 여러 리전에서 사용 가능한 KMS 키 ▸ Key Deletion Waiting Period — KMS 키 삭제 시 7~30일 대기 기간 필수 ▸ Replica Key — 다른 리전의 동일 키 복사본 【정답 포인트】 ▸ ARN의 mrk- 접두사는 Multi-Region Key를 나타냄 ▸ Multi-Region Key는 모든 복제 리전에서 동시에 삭제해야 함 ▸ 한 리전에서만 삭제 요청 시 다른 리전의 복제가 남아있을 수 있음 ▸ 모든 리전에서 7일 대기 기간으로 삭제 예약하면 동시 삭제 가능 【오답 체크】 (A) Root 사용자로도 대기 기간을 우회할 수 없음, 7일은 필수 (C) 키 정책 수정으로는 삭제 가능성 없음, 이미 kms:* 권한 있음 (D) 비활성화만으로는 보안 요구사항 미충족, 완전 삭제 필요 【시험 포인트】 ▸ Multi-Region Key 식별: mrk- 접두사가 있는 ARN ▸ MRK 삭제 시 모든 복제 리전 확인 필수 ▸ KMS 삭제 대기 기간은 우회 불가능 (보안 메커니즘) ▸ 인시던트 응답 시 모든 리전의 악성 리소스 제거 필수

해설

【핵심 용어】 ▸ Session Manager — IAM 역할 기반으로 EC2/온프레미스 서버에 접근 (SSH 키 불필요) ▸ Bastion Host — SSH 키를 관리해야 하고, 계속 실행 필요 ▸ Systems Manager Agent — Session Manager 사용을 위한 필수 에이전트 【정답 포인트】 ▸ SSH 키 유지보수 불필요 → Session Manager (IAM 기반) ▸ 임시 연결 → Session Manager로 on-demand 세션 생성 ▸ 네트워크 격리 → Session Manager는 최소 권한으로 접근 제어 ▸ 비용 최적화 → 연결 시간만 비용 발생 (베이션은 24/7 실행) ▸ EC2 + 온프레미스 모두 지원 → Hybrid Activations 사용 【오답 체크】 (A) Bastion Host는 SSH 키 관리 필요하고, 항상 실행 → 비용 낭비 (C) CloudShell은 AWS Management Console 내 셸로, 온프레미스 직접 접근 불가 (D) Interface VPC Endpoint는 SSH 액세스 제공하지 않음 (API 엔드포인트용) 【시험 포인트】 ▸ SSH 키 없음 = Session Manager (IAM 기반 인증) ▸ 임시/on-demand 접근 = Session Manager의 강점 ▸ EC2 + 온프레미스 모두 = Hybrid Activations으로 해결 ▸ 비용 최적화 = 연결 시간만 청구되는 Session Manager 활용

해설

【핵심 용어】 ▸ GuardDuty — AWS 전체의 위협 탐지 서비스 ▸ EKS Protection — GuardDuty의 EKS 특화 기능 ▸ Runtime Monitoring — 런타임 동작 감시 (파일, 네트워킹 등) ▸ EventBridge → SNS → Email — 자동 알림 흐름 【정답 포인트】 ▸ EKS 감사 로그 모니터링 = GuardDuty EKS Protection ▸ 운영체제/네트워킹/파일 이벤트 = GuardDuty Runtime Monitoring ▸ 실시간 위협 탐지 = GuardDuty의 기계학습 기반 탐지 ▸ 자동 알림 = EventBridge + SNS + 메일링 리스트 ▸ AWS 관리형 서비스 = 최소 운영 오버헤드 【오답 체크】 (A) Security Hub는 설정 규정 준수 중심이고, 런타임 위협 탐지 부족 (B) Inspector는 이미지 취약성 스캔 중심, 감사 로그/런타임 모니터링 부족 (D) 수동 CloudWatch 로그 처리는 Lambda 필요하고, 복잡도 높음 【시험 포인트】 ▸ EKS + 감사 로그 + 런타임 모니터링 = GuardDuty 선택 ▸ GuardDuty EKS Protection은 감사 로그 + 런타임 이벤트 종합 분석 ▸ Runtime Monitoring으로 파일/네트워킹/프로세스 감지 ▸ 실제 위협 탐지(Threat Detection) = GuardDuty, 규정 준수(Compliance) = Security Hub

해설

【핵심 용어】 ▸ IoT Thing Name — IoT Core의 보안 주체로 등록된 안전한 식별자 ▸ Client ID — MQTT 연결 시 클라이언트가 제공하는 ID (공격자 조작 가능) ▸ Policy Variable — iot:ClientId vs iot:Connection.Thing.ThingName 【정답 포인트】 ▸ (A) IoT Thing Name 사용 → 클라이언트 ID 조작 방지 (안전한 인증) ▸ (E) iot:Connection.Thing.ThingName 사용 → Thing 검증된 이름으로 권한 확인 ▸ (A) + (E) 조합: 인증(Thing Name) + 인가(Thing Name 기반 정책) ▸ ClientId 대신 Thing Name을 사용하면 특수 문자 주입 불가능 【오답 체크】 (B) 애플리케이션 검증은 부족하고, Trojan 탐지 어려움 (C) AWSIoTWirelessDataAccess는 LoRaWAN용으로 MQTT 주제와 무관 (D) iot:ClientId 기반 정책은 ClientId 조작으로 권한 범위 우회 가능 【시험 포인트】 ▸ IoT 보안: Thing 기반 인증이 ClientId 기반보다 안전 ▸ iot:Connection.Thing.ThingName은 AWS가 검증한 안전한 값 ▸ ${iot:ClientId}는 클라이언트 제공 값으로 신뢰할 수 없음 ▸ 두 가지 조치 (인증+인가) 모두 필요 → defense in depth

해설

【핵심 용어】 ▸ AWS Config — 리소스 설정의 스냅샷을 기록하고 변경 추적 ▸ Configuration Snapshot — 리소스의 현재 상태를 자동 기록 ▸ Change Aggregation — 빠른 변경 여러 개를 하나로 집계 【정답 포인트】 ▸ Config는 "최신 설정만 기록" 하는 것이 핵심 기능 ▸ 빠른 연속 변경 시에도 마지막 상태만 저장 (자동 집계) ▸ 규정 준수 평가에 최적화된 서비스 ▸ 운영 효율성 높음 (자동 추적, 별도 처리 불필요) 【오답 체크】 (A) CloudTrail은 모든 API 호출을 기록하므로 중복 분석 필요 (C) CloudWatch는 메트릭/로그 모니터링 중심으로 설정 추적 부적합 (D) Cloud Map은 서비스 디스커버리 서비스로 설정 감시 목적이 아님 【시험 포인트】 ▸ 리소스 설정 추적 = AWS Config (전문 서비스) ▸ "최신 상태만" 요구사항 = Config의 기본 동작 ▸ 규정 준수 중심 = Config가 최적 (Compliance 평가 내장) ▸ CloudTrail은 감사/인증 추적용이지, 설정 상태 추적용 아님

해설

【핵심 용어】 ▸ AWS KMS Custom Key Store — CloudHSM 클러스터로 백업되는 KMS 키 ▸ CloudHSM — 고객 관리형 HSM으로 키 자료를 완전 제어 ▸ CloudTrail — KMS API 호출 및 키 사용을 감시하는 감사 로그 【정답 포인트】 ▸ 커스텀 키 스토어 = KMS (CloudHSM 백엔드 옵션) ▸ 키 감시 = CloudTrail (KMS API 로그 기록) ▸ CloudHSM은 물리적 보안과 키 제어, KMS는 관리 계층 ▸ 규정/감사 요구사항 = CloudTrail이 표준 【오답 체크】 (A) Amazon Athena는 데이터 분석 도구로 감사 로그 전용 아님 (B) Amazon S3은 키 저장소가 아니라 데이터 저장소 (C) Amazon GuardDuty는 위협 탐지 서비스로 KMS 감시 목적 아님 【시험 포인트】 ▸ CloudHSM 기반 KMS = Custom Key Store 필수 ▸ KMS 키 감사 = CloudTrail (표준 감시) ▸ HSM + KMS 조합으로 최고 수준의 암호화 키 보안 ▸ KMS API 호출 추적 = CloudTrail 로그에 기록됨

해설

【핵심 용어】 ▸ CloudWatch Logs — 중앙화된 로그 스토리지로 인스턴스 독립적 ▸ CloudWatch Agent — EC2에 설치되어 로그를 CloudWatch Logs로 전송 ▸ Auto Scaling 라이프사이클 — 인스턴스 시작/종료 시 자동 처리 【정답 포인트】 ▸ 로그 손실 방지 = 중앙 로그 수집 (CloudWatch Logs) ▸ 자동화 = CloudWatch Agent가 자동으로 로그 전송 ▸ 내구성 = AWS 관리형 스토리지 (1년 보관 정책 설정 가능) ▸ 스케일링 무관 = 인스턴스가 아닌 CloudWatch에 저장 ▸ 가용성 = CloudWatch Logs 자동 복제 【오답 체크】 (A) EBS 재연결은 복잡하고, 스케일 아웃 시 대응 불가 (B) EFS 마운트는 복잡하고, 매일 복사 자동화도 필요 (D) 수동 검토는 자동화 부족, 로그 손실 완전 방지 불가 【시험 포인트】 ▸ Auto Scaling 환경 = 중앙 로그 수집 (CloudWatch Logs 필수) ▸ CloudWatch Agent = AMI 한 번 추가로 자동 적용 ▸ 1년 보관 = CloudWatch Logs 보관 정책으로 자동 관리 ▸ 인스턴스 독립적 = 스케일 인 후에도 로그 유지

해설

【핵심 용어】 ▸ S3 Gateway Endpoint — VPC 내에서 인터넷 없이 S3 접근 가능 ▸ aws:ResourceOrgID — 리소스가 속한 AWS Organizations ID ▸ aws:PrincipalOrgID — 요청자가 속한 Organizations ID ▸ Endpoint Policy — VPC 엔드포인트 수준의 접근 제어 【정답 포인트】 ▸ 게이트웨이 엔드포인트 정책은 VPC 내 모든 트래픽을 제어 ▸ 두 OrgID 조건으로 Organizations 내부 버킷만 허용 ▸ 외부 버킷 접근 자동 차단 (엔드포인트 수준) ▸ IAM 정책은 이미 최소 권한 설정됨 ▸ 엔드포인트 정책이 더 효과적한 통제점 【오답 체크】 (B) ResourceOrgID만으로는 PrincipalOrgID 검증 부족 (C) 포트 443 차단은 S3 데이터 플레인 영향, 관리 작업 차단 가능 (D) SCP는 조직 전체에 영향, 계정 내 조직이 없으면 비효과적 【시험 포인트】 ▸ Organizations 내부 리소스만 허용 = 양쪽 OrgID 조건 필수 ▸ VPC 엔드포인트 정책이 첫 번째 방어선 (가장 가까운 지점) ▸ 아웃바운드 필터링 = 포트 차단(L4)보다 리소스 수준(L7) 통제 선호 ▸ EC2 프로세스 계속 작동 = 내부 리소스만 허용하면 OK

해설

【핵심 용어】 ▸ Point-in-Time Recovery (PITR) — 특정 시간으로 데이터베이스 복구 ▸ Automated Backup — RDS가 자동으로 생성하는 백업 ▸ Backup Retention Period — 백업이 유지되는 기간 (14일) 【정답 포인트】 ▸ 공격이 오후 3:15에 발생 → 그 직전(3:14)로 복구 필요 ▸ PITR은 자동 백업 기반으로 초 단위 복구 가능 ▸ 5일 < 14일 보관 기간 → 자동 백업으로 충분 ▸ ARN 사용 → 특정 클러스터 지정 필수 ▸ 정확한 시간 지정 가능 (3:14 vs 3:15) 【오답 체크】 (B) 스냅샷은 자동 생성되지 않고 수동 생성/정기 생성 필요 (C) 전체 스냅샷 목록은 비효율적, 특정 클러스터만 필요 (D) 14일 전은 공격 발생 전 너무 오래전 상태 (공격 후 변경사항 포함) 【시험 포인트】 ▸ RDS PITR = 자동 백업 기반, 보관 기간 내 가능 ▸ 정확한 타이밍 = 공격 발생 직전 시간으로 복구 ▸ 초 단위 정밀도 = 3:14 vs 3:15 차이 중요 ▸ 클러스터 ARN = 특정 리소스 복구 보장

해설

【핵심 용어】 ▸ IAM Identity Center — 조직 전체 사용자 접근 관리 (federated user) ▸ Organizational Event Data Store — CloudTrail의 이벤트 데이터베이스 (쿼리 가능) ▸ Organization Trail — 조직의 모든 계정 이벤트 기록 ▸ CloudTrail Insights Query — 이벤트 데이터 스토어 조회 【정답 포인트】 ▸ 즉시 비활성화 = IAM Identity Center에서 사용자 비활성화 (모든 계정 영향) ▸ 모든 AWS 계정 차단 = Identity Center 비활성화가 가장 효과적 ▸ 과거 7일 활동 조회 = 이미 구성된 조직 이벤트 데이터 스토어 사용 ▸ CloudTrail 쿼리 = CloudTrail 서비스로 이벤트 데이터 스토어 직접 쿼리 【오답 체크】 (A) 조직 관리 계정만 비활성화로는 다른 계정 영향 없음 (B) 정책 제거만으로는 사용자 완전 비활성화 보장 불가 (C) 권한 집합 제거는 부분적, CloudWatch Logs Insights는 S3 직접 쿼리로 느림 【시험 포인트】 ▸ IAM Identity Center 사용 = Identity Center 비활성화로 조직 전체 영향 ▸ 조직 이벤트 데이터 스토어 = 이미 존재하므로 바로 쿼리 가능 ▸ CloudTrail 서비스 쿼리 = S3 → Athena보다 직관적, 빠름 ▸ 가장 효율적 = Identity Center + 이미 구성된 이벤트 데이터 스토어 활용

해설

【핵심 용어】 ▸ Amazon Inspector — 취약점 스캔 도구 (EC2, ECR, Lambda 지원) ▸ AWS Systems Manager Patch Manager — OS 패치 적용 자동화 ▸ GuardDuty Malware Protection — 악성코드 탐지 (취약점 아님) 【정답 포인트】 ▸ 소프트웨어 취약점 탐지 = Amazon Inspector 전문 ▸ 취약점 평가 + 패치 적용 = Inspector + Patch Manager 조합 ▸ 자동화 = Patch Manager로 패치 자동 배포 ▸ 규모 확장 = Patch Manager가 EC2 플릿 관리 【오답 체크】 (B) 호스트 기반 방화벽/안티바이러스는 취약점 관리 아님 (C) CloudWatch 로깅은 모니터링이지 취약점 탐지 아님 (D) GuardDuty Malware Protection은 악성코드 탐지 (취약점 스캔 아님) 【시험 포인트】 ▸ 취약점 탐지 = Amazon Inspector 유일한 선택 ▸ Inspector + Patch Manager = SCS 표준 조합 ▸ GuardDuty = 위협 탐지 (악성코드, 행위 기반) ▸ Inspector = 취약점 관리 (CVSS 기반 스캔)