정답 · 해설

해설

【핵심 용어】 ▸ Interface VPC Endpoint (PrivateLink) — Secrets Manager 등 대부분 AWS API에 인터넷 없이 프라이빗 접근, ENI 생성 ▸ Gateway VPC Endpoint — S3와 DynamoDB에만 지원 (Secrets Manager 미지원) ▸ Lambda in VPC — VPC 내 실행 시 AWS API 접근에 엔드포인트 또는 NAT 필요 【정답 포인트】 ▸ "인터넷 없는 VPC" + "가장 안전하게 Secrets Manager 통신" → 인터페이스 VPC 엔드포인트로 프라이빗 접근 ▸ 인터넷 경유 없이 AWS 네트워크 내부로만 통신 【오답 체크】 (A) NAT 게이트웨이는 인터넷 경유 접근을 열어 가장 안전한 방식 아님(요건은 인터넷 없음). (B) 게이트웨이 엔드포인트는 S3/DynamoDB 전용, Secrets Manager 미지원. (D) 인터넷 게이트웨이는 퍼블릭 노출 증가 → 보안 요건 위반. 【시험 포인트】Secrets Manager/대부분 API의 프라이빗 접근 = Interface Endpoint. Gateway Endpoint는 S3·DynamoDB 전용.

해설

【핵심 용어】 ▸ Gateway VPC Endpoint for S3 — VPC에서 인터넷 없이 S3에 프라이빗 접근 (교차 계정 버킷도 접근 가능) ▸ S3는 리전 서비스 — 게이트웨이 엔드포인트는 동일 리전 S3에 라우팅 ▸ VPC Peering / Transit Gateway — VPC 간 연결용, S3는 VPC 리소스가 아님 【정답 포인트】 ▸ "Account A 앱이 Account B의 S3에 쓰기" + "퍼블릭 인터넷 금지" + 권한은 이미 있음 ▸ S3는 리전 서비스이므로 Account A에 S3 게이트웨이 엔드포인트만 만들어 라우팅 → 인터넷 없이 교차 계정 버킷 접근 가능 【오답 체크】 (A) Transit Gateway는 VPC 간 연결용, S3(VPC 밖 서비스) 접근에는 불필요·과도. (B) 소프트웨어 VPN은 복잡·불필요, S3 접근 문제 해결과 무관. (C) VPC 피어링은 VPC 간 통신용이며 S3는 VPC 리소스가 아니라 부적합. 【시험 포인트】VPC에서 S3(교차 계정 포함) 프라이빗 접근 = S3 게이트웨이 엔드포인트. S3는 VPC가 아니라 피어링·TGW 불필요.

해설

【핵심 용어】 ▸ Network ACL — 서브넷 경계에서 즉시 트래픽 차단(스테이트리스), 격리에 유용 ▸ 포렌식 격리 절차 — 증거 보존 상태로 인스턴스 분리 후 별도 진단 도구로 조사 ▸ 진단용 별도 인스턴스·보안 그룹 — 오염된 인스턴스에 직접 로그인 대신 격리 조사 【정답 포인트】 ▸ "즉시 공격 완화 + 근본 원인 조사" → 먼저 NACL로 아웃바운드 전면 차단해 악성 통신 중단 ▸ 이후 진단 전용 SG로 교체, NACL 완화 후 진단 도구 인스턴스로 조사 → 증거 보존하며 격리 조사 【오답 체크】 (A) 오염 인스턴스에 로그인·도구 설치는 증거 훼손 위험, SG에는 DENY 규칙이 없음(허용만 가능). (C) 인스턴스를 종료하면 메모리·실행 상태 등 휘발성 증거가 소실 → 근본 원인 조사에 불리. (D) WAF는 웹 요청 필터용이라 EC2 인스턴스에 직접 부착 불가, 아웃바운드 악성 연결 차단에 부적합. 【시험 포인트】사고 대응 = 즉시 NACL로 격리(스테이트리스 차단) + 증거 보존 후 별도 진단 인스턴스로 조사. 종료·직접 로그인은 지양.

해설

【핵심 용어】 ▸ Patch Manager 패치 베이스라인 — 제품·분류·자동 승인일 지정, 자동 승인 0일이면 신규 보안 패치 즉시 적용 ▸ Patch Now (스캔·설치) — 콘솔에서 온디맨드 즉시 패치, S3에 패치 로그 저장으로 중앙 증거 확보 ▸ Systems Manager Patch Manager — 다수 노드 패치 및 규정 준수 리포트 【정답 포인트】 ▸ "즉시 패치 배포" → 자동 승인 0일 보안 베이스라인 생성·기본 지정 (A) ▸ "중앙 증거" → Patch Now 스캔·설치로 즉시 적용하고 S3 버킷에 패치 로그 저장 (B) 【오답 체크】 (C) 자동 승인 1일 설정은 "즉시" 요건에 부합하지 않음(하루 지연). (D) 시간별 커스텀 스캔은 즉시 배포가 아니라 주기적 방식이라 사고 대응 즉시성 미흡. (E) Application Manager는 애플리케이션 리소스 관리용이지 패치 설치 검증의 중앙 증거 수단으로 부적합. 【시험 포인트】"즉시 패치" = 자동 승인 0일 베이스라인 + Patch Now, 증거는 S3 패치 로그. 승인 1일·주기 스캔은 즉시성 탈락.

해설

【핵심 용어】 ▸ ReadOnlyAccess 관리형 정책 — 조회 권한은 많으나 kms:Decrypt 미포함 ▸ SSE-KMS 암호화 객체 조회 — s3:GetObject 외에 kms:Decrypt 권한 필수 ▸ 인라인 정책 — 특정 역할에 추가 권한 부여 (AWS 관리형 정책 편집 대신 권장) 【정답 포인트】 ▸ 버킷 정책·ACL 정상인데 AccessDenied → 암호화 객체 복호화 권한(kms:Decrypt) 누락 ▸ AWS 관리형 ReadOnlyAccess는 직접 편집 불가하므로, 역할에 kms:Decrypt 인라인 정책을 추가 【오답 체크】 (A) AWS 관리형 정책(ReadOnlyAccess)은 편집 불가 → 실행 불가능한 방법. (B) 버킷 정책은 이미 계정 전체 접근 허용, 문제는 KMS 복호화 권한이라 무관. (D) S3:* 부여는 최소 권한 위반이며, 실제 원인(kms:Decrypt 누락)도 해결 못함. 【시험 포인트】SSE-KMS 객체 AccessDenied = kms:Decrypt 누락. AWS 관리형 정책은 편집 불가 → 인라인 정책으로 추가.

해설

【핵심 용어】 ▸ EKS control plane 로깅 — api, audit, authenticator 등 컴포넌트 로그를 CloudWatch Logs로 전송해야 pod 이벤트 확인 가능 ▸ CloudTrail — AWS API 호출 기록용이며 Kubernetes 내부(pod 생성 등) 이벤트는 미포함 ▸ Kubernetes API server 로그 — pod 생성 등 클러스터 내부 활동 기록 【정답 포인트】 ▸ CloudTrail에 pod 생성 이벤트가 안 보이는 이유는 그것이 AWS API가 아닌 Kubernetes 이벤트이기 때문 ▸ 각 클러스터의 Kubernetes API 서버 컴포넌트 로그를 활성화해야 CloudWatch에서 pod 이벤트 조회 가능 【오답 체크】 (A) S3 VPC 엔드포인트·버킷 로깅은 pod 이벤트 노출과 무관. (C) S3 CORS는 브라우저 교차 출처 설정이지 로그 수집과 무관. (D) 단순 CloudWatch 구성만으로는 EKS 컨트롤 플레인 로깅을 켜지 않으면 pod 이벤트 안 보임. 【시험 포인트】pod 생성 등 Kubernetes 이벤트는 CloudTrail이 아니라 EKS control plane(API server) 로깅을 켜야 CloudWatch에 표시.

해설

【핵심 용어】 ▸ AWS Config 관리형 규칙 + 자동 교정 — 비준수 감지 시 SSM 자동화 문서로 자동 복구 ▸ AWS-EnableCloudTrail — CloudTrail을 다시 켜는 SSM 자동화 remediation 문서 ▸ EventBridge/Lambda — 커스텀 코드 필요, Config 자동 교정보다 오버헤드 큼 【정답 포인트】 ▸ "여러 리전에서 CloudTrail이 꺼지면 다시 켜기" + "가장 효율적" → 코드 없는 관리형 조합 ▸ AWS Config 관리형 규칙으로 비준수 감지 + AWS-EnableCloudTrail 자동 교정 실행 【오답 체크】 (B) EventBridge+Lambda는 커스텀 함수 작성·유지 필요로 오버헤드 큼(Config 자동 교정이 더 효율적). (C) CloudWatch 알람은 메트릭 기반이라 API 이벤트 소스 지정 방식이 부정확, Lambda 유지 부담. (D) Trusted Advisor는 권고·모니터링일 뿐 자동으로 CloudTrail을 다시 켜지 못함. 【시험 포인트】"비준수 자동 복구, 최소 개발" = AWS Config 관리형 규칙 + SSM 자동 교정(AWS-EnableCloudTrail).

해설

【핵심 용어】 ▸ Application Load Balancer — 레이어7, HTTP/HTTPS 리스너, ACM 인증서로 TLS 종료, HTTP→HTTPS 리다이렉트 ▸ ACM 퍼블릭 인증서 — HTTPS 리스너(443)에 연결해 TLS 종료 ▸ HTTP→HTTPS 리다이렉트 규칙 — 80 포트 요청을 443으로 전환 【정답 포인트】 ▸ "인터넷발 HTTP/HTTPS(80·443) + TLS 종료(엔드투엔드 불필요)" → ALB로 TLS 종료 ▸ 443 리스너에 ACM 인증서 연결, 80 리스너는 443으로 리다이렉트 【오답 체크】 (B) 인증서를 80 포트 리스너에 부착하는 것은 잘못됨(TLS는 443에서 종료). (C) NLB는 레이어4라 HTTP 리다이렉트 규칙을 만들 수 없고, ACM 통합 TLS 종료는 ALB가 적합. (D) 80 포트 처리·HTTP 요건이 빠졌고 NLB로는 HTTP 계층 처리·리다이렉트 불가. 【시험 포인트】HTTP/HTTPS + TLS 종료(엔드투엔드 아님) = ALB, ACM 인증서는 443 리스너, 80은 443으로 리다이렉트.

해설

【핵심 용어】 ▸ S3 Object Lock compliance 모드 — 루트·관리자도 보존 기간 내 삭제·덮어쓰기 불가, WORM ▸ S3 Replication — 객체를 보조 리전으로 복제 (Object Lock 상태 포함 가능) ▸ Governance 모드 — 특별 권한 사용자는 우회 가능 (관리자 삭제 방지엔 부족) 【정답 포인트】 ▸ "관리자도 영구 삭제 불가" → compliance 모드가 필수(governance는 우회 가능) ▸ 기본 리전에 Object Lock compliance 적용 후 보조 리전으로 복제 → DR + 삭제 불가 동시 충족 【오답 체크】 (A) Backup Vault Lock governance 모드는 권한 있는 사용자가 우회 가능해 "관리자도 삭제 불가" 요건 미충족. (C) s3:ReplicateDelete 거부는 삭제 마커 복제만 막을 뿐 보조 리전에서의 직접 삭제를 막지 못함. (D) 버전 관리만으로는 관리자가 버전까지 영구 삭제 가능 → 요건 미충족. 【시험 포인트】"관리자도 영구 삭제 불가" = Object Lock compliance 모드. governance·버전 관리는 우회·삭제 가능.

해설

【핵심 용어】 ▸ Cognito pre sign-up Lambda 트리거 — 가입 시 커스텀 검증 로직으로 요청 수락/거부 ▸ AWS WAF geo match + Cognito 사용자 풀 — 특정 국가 외 요청 차단 (Cognito 사용자 풀에 WAF 연결 지원) ▸ Cognito Hosted UI — 관리형 가입/로그인 UI 【정답 포인트】 ▸ "가입 시 커스텀 검증으로 수락/거부" → pre sign-up Lambda 트리거 (A) ▸ "프랑스 외 사기 가입 차단" → WAF geo match 규칙을 Cognito 사용자 풀에 연결 (B) 【오답 체크】 (C) 앱 클라이언트 ID 검증은 클라이언트 식별용이지 지리·사기 검증 기능 아님. (D) Cognito 사용자 풀에 국가 제한 설정이라는 기본 기능은 존재하지 않음 → WAF로 처리해야 함. (E) 소셜 IdP 연동은 로그인 수단 추가일 뿐 사기 가입 검증·차단과 무관. 【시험 포인트】Cognito 가입 커스텀 검증 = pre sign-up Lambda, 지리 기반 차단 = WAF geo match를 사용자 풀에 연결.

해설

【핵심 용어】 ▸ AWS Config 전달 채널 S3 — Config가 로그를 쓰려면 버킷 정책이 config.amazonaws.com에 쓰기 허용해야 함 ▸ IAM 엔티티 권한 — Config를 설정하는 사용자가 s3:GetBucketAcl, s3:PutObject* 권한 필요 ▸ 오류 메시지 — "unable to write to bucket" → S3 쓰기 권한 문제 【정답 포인트】 ▸ 오류는 버킷 쓰기 실패 → 두 측면 점검: ▸ (A) S3 버킷 정책이 config.amazonaws.com 서비스의 버킷 쓰기를 허용하는지 확인 ▸ (B) 설정 작업을 수행하는 IAM 엔티티가 s3:GetBucketAcl, s3:PutObject* 권한을 가지는지 확인 【오답 체크】 (C) s3:GetBucketAcl/PutObject*는 "버킷 정책의 권한"이 아니라 호출 주체(IAM 엔티티)의 권한이어야 함 → 주체 혼동. (D) config.amazonaws.com에 쓰기를 허용하는 것은 IAM 정책이 아니라 S3 버킷 정책의 몫 → 대상 혼동. (E) BatchGetResourceConfig 관련 서술은 오류(버킷 쓰기 실패)의 원인과 무관한 액션 혼동. 【시험 포인트】Config S3 쓰기 실패 = 버킷 정책이 config 서비스 허용(A) + 설정 IAM 주체의 s3:PutObject*/GetBucketAcl 권한(B).

해설

【핵심 용어】 ▸ AWS Shield — 레이어3/4 DDoS 보호 (Standard 기본, Advanced 강화) ▸ Amazon Route 53 — DNS, Shield로 보호되는 관리형·확장형 서비스로 L3/4 공격 흡수 ▸ Network Load Balancer — 레이어4, 고성능·확장으로 대규모 연결 흡수 【정답 포인트】 ▸ "레이어3/4 DDoS 방어" 조합: ▸ (D) AWS Shield — L3/4 DDoS 완화의 핵심 서비스 ▸ (A) Route 53 — 확장형 DNS로 공격 트래픽 흡수·Shield 보호 대상 ▸ (E) NLB — L4에서 대규모 트래픽 처리·확장으로 방어에 기여 【오답 체크】 (B) ACM은 인증서 관리용, DDoS 방어와 무관. (C) S3는 객체 스토리지로 웹서버 L3/4 DDoS 방어 구성 요소 아님. (F) GuardDuty는 위협 탐지용이지 DDoS 완화(방어) 서비스가 아님. 【시험 포인트】L3/4 DDoS = Shield + 확장형 엣지/네트워크 서비스(Route 53, NLB). GuardDuty는 탐지, ACM은 인증서로 오답.

해설

【핵심 용어】 ▸ Amazon Inspector 위임 관리자 — 조직 전체 EC2·ECR·Lambda 취약점 및 네트워크 노출 자동 스캔, 신규 계정 자동 활성화 ▸ 자동 스캔 — 신규 워크로드 온라인 시 자동 평가 ▸ Security Hub — findings 집계 【정답 포인트】 ▸ "SW 취약점 + 의도치 않은 네트워크 노출" + "신규 계정 포함 조직 전체 자동" → Inspector 위임 관리자 + 신규 계정 자동 스캔 ▸ Inspector가 SSM 관리 EC2·ECR을 자동 스캔하고 findings를 Security Hub로 전송 【오답 체크】 (A) SCP는 권한 가드레일이지 취약점 스캔 기능이 없음. (B) GuardDuty는 위협 탐지용이며 SW 취약점 스캔이 목적이 아니고, EventBridge 방식은 신규 계정 자동화에 미흡. (D) AWS Config 규칙은 구성 준수 평가용, ECR 취약점 스캔 트리거로 부적합. 【시험 포인트】취약점+네트워크 노출 스캔, 신규 계정 자동 = Amazon Inspector 위임 관리자 + 자동 활성화.

해설

【핵심 용어】 ▸ KMS 키 정책 — 어떤 주체가 키를 사용할 수 있는지 정의, 서비스별 kms:Decrypt 허용 ▸ SCP — 조직 계정에 예방적 가드레일, 미암호화 리소스 생성 자체를 거부(Deny) ▸ 데이터 접근 경로 — S3, DynamoDB(저장) + Lambda, EKS(읽기 주체) 【정답 포인트】 ▸ "모든 데이터 암호화 + 최소 권한" → 데이터를 읽는 모든 주체(S3, DynamoDB, Lambda, EKS)에만 kms:Decrypt 허용 ▸ SCP로 키로 암호화되지 않은 S3 버킷·DynamoDB 테이블 생성 자체를 거부 → 예방적 강제 【오답 체크】 (A) 키 정책이 S3/DynamoDB에만 Decrypt 허용하면 데이터를 읽는 Lambda·EKS가 접근 못해 동작 실패. (B) IAM Deny+스케줄 Lambda 방식은 복잡·우회 여지, Config 알림은 예방(강제)이 아니라 사후 탐지. (D) 키 정책은 맞지만 Config 알림만으로는 미암호화 리소스 생성을 예방(강제)하지 못함(SCP 필요). 【시험 포인트】암호화 강제 = 읽기 주체 전부에 kms:Decrypt + SCP Deny로 미암호화 생성 예방. Config는 탐지일 뿐 예방 아님.

해설

【핵심 용어】 ▸ Lambda 실행 역할(execution role) — CloudWatch Logs에 로그 쓰기(logs:CreateLogGroup/Stream, PutLogEvents) 권한 필요 ▸ CloudWatch Logs — Lambda 로그 저장 위치 ▸ 로그 부재 원인 — 실행 역할 권한 누락 시 로그 미생성 【정답 포인트】 ▸ Lambda 로그가 CloudWatch Logs에 전혀 없음 → 실행 역할에 로그 쓰기 권한이 없어 로그가 생성되지 않음 ▸ 실행 역할에 CloudWatch Logs 쓰기 권한 부여가 로그 생성 전제 【오답 체크】 (B) API Gateway 호출 여부와 Lambda 자체 로그의 CloudWatch Logs 저장은 무관 → 잘못된 설명. (C) CloudWatch Logs는 S3에 로그를 저장하지 않음 → 전제부터 틀림. (D) 호출된 버전이 최신이 아니라도 로그는 생성됨 → 로그 부재 원인 아님. 【시험 포인트】Lambda 로그 미생성 = 실행 역할의 CloudWatch Logs 쓰기 권한 누락.

해설

【핵심 용어】 ▸ CloudFront — 엣지 캐싱·Shield Standard 기본 제공으로 DDoS 흡수, S3 정적 콘텐츠 오리진 ▸ ELB + Auto Scaling — 트래픽 분산·수평 확장으로 부하·공격 흡수 ▸ AWS Shield Standard — 모든 계정 기본 제공(추가 비용 없음), CloudFront/Route 53에서 강력 【정답 포인트】 ▸ "DDoS 회복력 + 가장 비용 효율" → 관리형 확장 아키텍처 ▸ EC2를 ELB+Auto Scaling 뒤에 두고, CloudFront(S3 오리진)로 엣지에서 트래픽 흡수 → 추가 비용 큰 Shield Advanced 없이 방어 【오답 체크】 (A) CPU 90%에 포트 차단은 정상 트래픽까지 막고 가용성을 스스로 훼손하는 잘못된 대응. (C) 웜 스탠바이 DR은 비용이 크고 DDoS 완화의 표준·비용 효율 해법 아님. (D) Shield Advanced는 월정액이 비싸 "가장 비용 효율" 요건에 부합하지 않음. 【시험 포인트】비용 효율 DDoS 회복력 = CloudFront + ELB + Auto Scaling(무료 Shield Standard 활용). Shield Advanced는 고비용.

해설

【핵심 용어】 ▸ IAM Access Analyzer — 외부(신뢰 영역 밖) 주체에 접근을 허용하는 역할·버킷 정책 등 식별 ▸ Zone of trust — 조직/계정을 신뢰 경계로 설정, 그 밖의 외부 접근을 findings로 보고 ▸ 교차 계정 역할·S3 버킷 정책 — 외부 주체 접근 경로 【정답 포인트】 ▸ "어떤 외부 주체가 어떤 계정에 접근하는지 식별" → IAM Access Analyzer가 정확히 이 용도 ▸ 조직을 신뢰 영역으로 설정하면 조직 외부 주체 접근을 findings로 보고, 계정 ID로 필터 【오답 체크】 (B) Config 커스텀 규칙은 구성 준수 평가용이며 외부 접근 관계를 직접 식별하지 못함. (C) Inspector는 취약점 스캐너지 외부 접근 권한 분석 도구가 아님. (D) GuardDuty는 위협/이상 행위 탐지용이지 외부 주체 접근 범위 식별 용도가 아님. 【시험 포인트】"외부 주체의 리소스 접근 식별" = IAM Access Analyzer + 조직을 zone of trust로 설정.

해설

【핵심 용어】 ▸ AWS Config 관리형 규칙 ec2-managedinstance-applications-required — 필수 SW 미설치 인스턴스 탐지 ▸ EventBridge + Lambda + SSM Run Command — 비준수 감지 시 자동으로 SW 설치 ▸ Systems Manager Run Command — 관리 노드에 원격 명령 실행 【정답 포인트】 ▸ "필수 SW 미설치 탐지 + 자동 설치" → Config 규칙으로 탐지, EventBridge가 이벤트에 반응해 Lambda→SSM Run Command로 설치 ▸ 조직 전체 계정에 Config 중앙 활성화 【오답 체크】 (A) 태그된 AMI만 허용하는 SCP는 신규 실행만 통제, 기존/누락 인스턴스 자동 설치·탐지를 못함. (B) Patch Manager는 패치용이며 임의 기업 SW 설치·미설치 탐지 자동화 용도가 아님. (D) Distributor로 한 번 설치할 뿐, 미설치 상태를 지속 탐지하고 자동 재설치하는 순환 구조가 없음. 【시험 포인트】"미설치 탐지 + 자동 설치" = Config 규칙 탐지 + EventBridge → Lambda → SSM Run Command.

해설

【핵심 용어】 ▸ IAM 액세스 키 비활성화(Deactivate) — 노출된 키의 추가 사용 즉시 차단 ▸ IAM Access Analyzer / CloudTrail — 노출 자격 증명이 접근한 리소스·사용자 식별 ▸ 노출 자격 증명 대응 — 사용 중단 + 오용 여부 조사 【정답 포인트】 ▸ "추가 사용 방지" → 노출된 IAM 액세스 키 비활성화 (B) ▸ "무단 사용 여부 식별" → IAM Access Analyzer로 해당 자격 증명이 접근한 리소스·사용 주체 파악 (A) 【오답 체크】 (C) GuardDuty에 특정 액세스 키를 차단하는 규칙을 만드는 기능은 없음(탐지 서비스). (D) 새 키 생성은 사용자 계속 사용을 위한 조치일 뿐 오용 조사·기존 키 차단과 직접 무관. (E) 자격 증명 리포트의 마지막 로그인은 콘솔 로그인 정보라 액세스 키 오용(무단 사용) 식별에 부적합. 【시험 포인트】노출 키 대응 = 즉시 키 비활성화(차단) + Access Analyzer/CloudTrail로 오용 조사.

해설

【핵심 용어】 ▸ Amazon Security Lake — 조직·AWS 서비스·서드파티·온프레미스 로그를 OCSF로 정규화·집계하는 중앙 데이터 레이크 ▸ 위임 관리자 — 조직 전체 Security Lake 관리 ▸ Amazon Athena — Security Lake 데이터 쿼리 【정답 포인트】 ▸ "조직 전체 + AWS Marketplace 제품 + 온프레미스 이벤트 집계·정규화" → Security Lake가 다양한 소스를 표준화(OCSF)해 통합 ▸ 위임 관리자 설정 후 조직에 활성화, Athena로 쿼리 【오답 체크】 (A) S3+Glue+Athena 수동 구성은 정규화·다양 소스(마켓플레이스·온프레미스) 통합을 자동 제공하지 않음. (B) CloudWatch Logs 구독+OpenSearch는 온프레미스·마켓플레이스 소스 정규화·집계 요건에 미흡. (D) SCP로 로그 전달을 강제한다는 방식은 실제 동작 방식이 아니며 정규화 기능도 없음. 【시험 포인트】"다양한 소스 로그 집계 + 정규화" = Amazon Security Lake(OCSF) + Athena.