정답 · 해설

해설

【핵심 용어】 ▸ CloudTrail 관리 이벤트(management events) — 제어 평면 API(버킷 정책 변경 등) 기록 ▸ CloudTrail 데이터 이벤트(data events) — 객체 수준 작업(s3:PutObjectAcl, GetObject 등) 기록, 기본 비활성 ▸ EventBridge → SNS — CloudTrail 이벤트 패턴 매칭 시 알림 【정답 포인트】 ▸ s3:PutObjectAcl은 "객체 수준" 작업이라 관리 이벤트에는 안 잡히고, PutBucketPolicy/DeleteBucketPolicy는 관리 이벤트로 잡힘 → CloudTrail에서 S3 데이터 이벤트(읽기/쓰기)를 모니터링하도록 활성화해야 PutObjectAcl 이벤트 발생 【오답 체크】 (A) EventBridge 패턴을 All Events로 바꿔도 CloudTrail이 데이터 이벤트를 기록하지 않으면 근본 해결 안 됨(오탐 가능). (B) Bucket Level Operations 선택도 객체 수준 데이터 이벤트를 기록하지 못함. (C) CloudTrail Insights는 비정상 API 활동 탐지용, 특정 이벤트 캡처와 무관. 【시험 포인트】 객체 수준 API(PutObjectAcl 등)는 CloudTrail 데이터 이벤트를 켜야 기록됨. 버킷 정책 변경은 관리 이벤트.

해설

【핵심 용어】 ▸ Secrets Manager — 비밀 암호화 저장(평문 미노출), 자동 회전 기본 지원 ▸ ECS 컨테이너 정의 secrets 통합 — 태스크 정의에서 Secrets Manager/Parameter Store 값을 안전 참조해 주입 ▸ Parameter Store SecureString — 암호화 저장은 되나 자체 자동 회전 기능 없음(Lambda 별도 필요) 【정답 포인트】 ▸ "평문 저장·전송 금지" + "API 키 자동 회전" → Secrets Manager에 저장하고 컨테이너 정의에서 참조. Secrets Manager는 암호화·자동 회전을 관리형으로 제공 【오답 체크】 (A) Parameter Store SecureString은 자동 회전 기능이 없음(요건 미충족). (B) EC2 user data 저장은 평문 노출 위험 + 자동 회전 아님. (C) Fargate는 컴퓨팅 실행 환경이지 비밀 저장소가 아님. 【시험 포인트】 "암호화 + 자동 회전 + 컨테이너 주입" → Secrets Manager(컨테이너 정의 참조). Parameter Store는 자동 회전 없음.

해설

【핵심 용어】 ▸ SCP + FullAWSAccess — 기본 허용 상한 위에 Deny SCP로 특정 액션 차단(가드레일) ▸ Deny 전략 — SCP는 명시적 Deny로 GuardDuty/Security Hub 비활성 액션(예: guardduty:DeleteDetector, securityhub:DisableSecurityHub 등) 차단 ▸ SCP는 권한을 부여하지 않음 — Deny만 추가하면 기존 IAM 허용을 덮어쓰지 않음 【정답 포인트】 ▸ [이미지] 정답 SCP는 GuardDuty·Security Hub 비활성화/삭제 관련 액션을 명시적 Deny하는 정책. Deny만 하므로 다른 IAM 허용 권한은 그대로 유지하며 요구를 충족 【오답 체크】 (B)(C)(D) [이미지] 나머지는 필요한 GuardDuty/Security Hub 비활성 액션을 온전히 Deny하지 못하거나, 과도하게 광범위한 Deny로 다른 권한까지 침해하는 구성으로 요건 미충족. 【시험 포인트】 "특정 서비스 비활성화 방지 + 기타 권한 불변" → 해당 비활성/삭제 액션만 겨냥한 명시적 Deny SCP. SCP는 부여가 아닌 상한 제한임.

해설

【핵심 용어】 ▸ Amazon OpenSearch Service VPC 접근 — 클러스터를 VPC 내부에 배치해 퍼블릭 노출 차단 ▸ 보안 그룹 — 인스턴스/ENI 레벨 상태 저장 방화벽, 소스 SG로 접근 제어 ▸ 네트워크 ACL / VPC 피어링 / 플로우 로그 — 각각 서브넷 필터, 네트워크 연결, 사후 모니터링(접근 제한 아님) 【정답 포인트】 ▸ "애플리케이션 서버만 클러스터 접근 허용" → OpenSearch를 VPC 접근 전용으로 구성하고 보안 그룹으로 애플리케이션 서버 SG만 허용 (가장 안전·직접적) 【오답 체크】 (A) 네트워크 ACL은 무상태·IP 기반으로 세밀한 애플리케이션 서버 한정에 부적절, SG가 표준. (B) VPC 피어링은 네트워크 연결일 뿐 접근 제한(허용 대상 한정) 자체를 하지 않음. (C) 플로우 로그 모니터링은 사후 탐지일 뿐 접근을 차단하지 못함. 【시험 포인트】 "특정 리소스만 접근 허용" → VPC 접근 전용 + 보안 그룹 소스 제한. NACL/플로우 로그/피어링은 접근 제어 수단이 아님.

해설

【핵심 용어】 ▸ 크로스 계정/서비스 접근에서 실제 호출 주체는 EC2 인스턴스 프로파일 역할 ▸ S3 + KMS 암호화 객체 접근 — S3 버킷/객체 접근 권한 + KMS kms:Decrypt 권한 모두 필요 ▸ Access Denied 진단 — 실행 주체(EC2 역할)의 권한을 점검해야 함(엔지니어 본인 IAM이 아님) 【정답 포인트】 ▸ 서드파티 도구가 EC2에서 실행되므로 실제 주체는 EC2 인스턴스 프로파일 역할 → 이 역할이 KMS CMK로 복호화 권한 + S3 버킷/객체 접근 권한을 모두 갖는지 확인해야 함 【오답 체크】 (A)(B) 접근 주체는 EC2 인스턴스 프로파일 역할이지 보안 엔지니어가 사용하는 역할이 아님. (D) EC2 역할 관점은 맞으나 KMS 복호화만 언급하고 S3 버킷/객체 접근 권한을 빠뜨려 불완전. 【시험 포인트】 EC2에서 도구 실행 시 실제 주체 = 인스턴스 프로파일 역할. SSE-KMS S3 접근에는 S3 권한 + kms:Decrypt 둘 다 필요.

해설

【핵심 용어】 ▸ Amazon WorkSpaces — 관리형 클라우드 데스크톱(DaaS), 비용·운영 부담 낮음 ▸ WorkSpaces 신뢰 디바이스(Trusted Devices) — 클라이언트 인증서를 신뢰 기기에 배포, 디렉터리 레벨에서 제한 접근 활성화해 회사 기기만 허용 ▸ EC2/커스텀 VDI — 직접 구축·관리 부담 큼 【정답 포인트】 ▸ "회사 제공 기기에서만 접근" + "비용·운영 최소화" → WorkSpaces 배포 후 클라이언트 인증서를 신뢰 기기에 배포하고 디렉터리 레벨에서 제한 접근 활성화 (신뢰 디바이스 인증서 방식이 표준) 【오답 체크】 (A) 커스텀 VDI 구축은 관리 오버헤드·비용이 큼. (B) EC2를 직원마다 할당하는 방식은 비용·관리 과다, DaaS 취지에 반함. (C) IP 차단 방식은 기기 자체(회사 기기)를 식별하지 못해 요건(디바이스 한정) 미충족. 【시험 포인트】 "회사 기기 한정 클라우드 데스크톱" → WorkSpaces 신뢰 디바이스(클라이언트 인증서) + 디렉터리 레벨 제한 접근.

해설

【핵심 용어】 ▸ Lambda 실행 역할 CloudWatch Logs 권한 — logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents 필요 ▸ "error loading Log Streams" — 로그 스트림 생성 권한(logs:CreateLogStream) 부재 시 흔한 증상 ▸ 최소 권한 — 필요한 로그 액션만 부여 【정답 포인트】 ▸ 로그 스트림을 못 불러오는 원인 → 실행 역할에 logs:CreateLogStream 권한이 없어 스트림 생성 실패. 두 번째 Allow 문에 logs:CreateLogStream 액션을 추가하면 해결 【오답 체크】 (A) CreateLogGroup을 옮기는 것은 스트림 생성 문제 해결과 무관. (B) logs:PutDestination은 크로스 계정 로그 목적지용, 이 문제와 무관. (C) logs:GetLogEvents는 이벤트 조회용으로 스트림이 존재해야 의미가 있으며 근본 원인(스트림 생성)이 아님. 【시험 포인트】 Lambda 로그 미표시/스트림 로드 실패 → 실행 역할에 logs:CreateLogStream(+PutLogEvents) 권한 필요.

해설

【핵심 용어】 ▸ ACM DNS 검증 — 도메인 DNS에 특정 CNAME 레코드를 등록해 소유권 검증, 갱신 시에도 이 레코드로 자동 재검증 ▸ 자동 갱신 실패(pending validation) — DNS CNAME 검증 레코드가 삭제·변경되면 자동 갱신 검증 실패 ▸ ACM 자동 갱신 — DNS 검증 레코드가 유지되는 한 관리형 자동 갱신 【정답 포인트】 ▸ DNS 검증 인증서가 pending validation → 도메인 DNS의 CNAME 레코드가 ACM이 요구하는 검증 CNAME과 일치하는지 확인. 레코드가 없거나 어긋나면 자동 갱신 검증 실패이므로 이를 바로잡아야 함 【오답 체크】 (A) DNS 검증 방식에서 콘솔 수동 검증은 해당 흐름이 아님(CNAME 레코드가 핵심). (C) 내보내기/재가져오기는 ACM 관리형 갱신 대상에서 벗어나며 문제 해결책 아님. (D) 이미 DNS 검증을 사용 중인데 이메일 검증으로 전환하는 것은 불필요·부적절. 【시험 포인트】 ACM DNS 검증 자동 갱신 실패 → DNS의 검증용 CNAME 레코드가 그대로 존재·일치하는지 확인.

해설

【핵심 용어】 ▸ Lambda 실행 역할 — 함수가 다른 AWS 서비스(IAM 태깅) 및 CloudWatch Logs에 접근할 권한 ▸ CloudWatch Logs 권한 — logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents (로그 미생성 원인) ▸ IAM 태깅 권한 — iam:TagUser, iam:TagRole (태깅 동작 수행) ▸ 최소 권한 원칙 — 필요한 리소스/액션만 부여 【정답 포인트】 ▸ [이미지] 정답은 IAM 태깅(iam:TagUser/iam:TagRole)과 CloudWatch Logs 쓰기(CreateLogGroup/CreateLogStream/PutLogEvents) 권한을 최소 범위로 함께 부여하는 정책. 로그 미생성(로그 권한 부재)과 태깅 실패(태깅 권한 부재)를 모두 해결 【오답 체크】 (A)(B)(C)(D) 중 [이미지] 오답은 로그 권한 또는 IAM 태깅 권한 중 하나가 빠졌거나, 과도하게 넓은 권한(예: iam:* 또는 와일드카드 리소스)을 부여해 최소 권한 원칙에 위배됨. 【시험 포인트】 "함수 동작 실패 + 로그도 없음" → 실행 역할에 대상 액션 권한 + CloudWatch Logs 쓰기 권한을 최소 범위로 둘 다 부여.

해설

【핵심 용어】 ▸ 크로스 계정 S3 접근 — 다른 계정 사용자가 버킷 접근 시 IAM 역할 assume가 표준·확장적 ▸ IAM 역할 + 신뢰 정책 — 팀 계정을 principal로 지정, 각 팀이 역할을 assume해 읽기/쓰기 ▸ 버킷 ACL / 액세스 키 공유 — 각각 세밀 제어 어렵고, 키 공유는 안티패턴 【정답 포인트】 ▸ "여러 팀이 다른 계정에서 S3 객체 읽기/쓰기" → 버킷 소유 계정에 적절 권한 IAM 역할을 만들고 신뢰 정책에 팀 계정들을 principal로 지정, 팀은 역할을 assume해 접근 (크로스 계정 표준·안전) 【오답 체크】 (A) 버킷 ACL + canonical ID 방식은 관리 어렵고 AWS가 지양(권장 아님). (C) 버킷 정책만으로도 가능은 하나, 객체 소유권/크로스 계정 쓰기 이슈가 있어 역할 assume가 더 견고 (문항 정답은 역할 방식). (D) 계정별 IAM 사용자·액세스 키 생성·공유는 심각한 안티패턴(자격 증명 공유 금지). 【시험 포인트】 크로스 계정 S3 공유 → 리소스 소유 계정의 IAM 역할 + 신뢰 정책으로 타 계정 principal이 assume. 액세스 키 공유는 절대 금지.

해설

【핵심 용어】 ▸ S3 전송 중 암호화 강제 — 버킷 정책에서 aws:SecureTransport 조건 사용 ▸ Deny + aws:SecureTransport=false — HTTPS(TLS)가 아닌 요청(HTTP)을 거부하는 표준 패턴 ▸ 대상: 모든 S3 작업(s3:*), 버킷 및 객체(/*) 리소스 【정답 포인트】 ▸ [이미지] 정답 정책은 Effect Deny + Action s3:* + Condition Bool aws:SecureTransport=false 구조. 암호화(TLS)되지 않은 전송 요청을 모두 거부해 "전송 중 암호화 강제" 요건 충족 【오답 체크】 (A)(C)(D) 중 [이미지] 오답은 조건 키(aws:SecureTransport)를 잘못 사용하거나(true 지정 등), Allow로 표현하거나, 리소스/액션 범위가 부적절해 전송 중 암호화를 올바르게 강제하지 못함. 【시험 포인트】 S3 전송 중 암호화 강제 = Deny + Bool aws:SecureTransport=false (버킷과 객체 ARN 모두 대상).

해설

【핵심 용어】 ▸ AWS SSO(IAM Identity Center) + AD 페더레이션 — 온프렘 AD ID로 IAM 역할 assume ▸ 침해된 페더레이션 ID 대응 — 소스(온프렘 AD) 계정 비활성화 + 이미 발급된 STS 토큰 무효화 ▸ STS 토큰 조기 무효화 — 역할에 aws:TokenIssueTime 기반 Deny(발급 시각 이전 토큰 거부) 정책 부착 【정답 포인트】 ▸ (B) 온프렘 AD에서 침해된 ID 접근 취소 → 새 세션 발급 차단(근본 원인 제거) ▸ (C) 역할에 현재 시각 이전 발급 STS 토큰을 모두 Deny하는 정책 부착 → 이미 탈취된 임시 자격 증명 즉시 무효화, 운영 워크로드는 새 토큰으로 계속 동작(다운타임 최소화) 【오답 체크】 (A) 역할에는 액세스 키가 없음(역할은 임시 자격 증명 사용), 부적절. (D) 특정 AD ID ARN을 Deny해도 여러 프로덕션 워크로드가 같은 역할을 쓰므로 정상 워크로드까지 차단될 수 있어 부적절. (E) 역할에는 콘솔 로그인 프로파일이 없음(사용자 개념 혼동). 【시험 포인트】 침해된 페더레이션 역할 대응 = 소스 ID 취소(AD) + aws:TokenIssueTime 이전 STS 토큰 Deny(기존 세션 무효, 신규는 정상).

해설

【핵심 용어】 ▸ AWS Signer — 코드 무결성 검증용 디지털 서명, 배포 전 변조 여부 확인 ▸ Lambda Code Signing — 서명된 코드만 배포 허용해 변조 방지 ▸ S3 zip 배포 — 서명된 코드 아티팩트를 배포하는 경로 【정답 포인트】 ▸ (B) AWS Signer로 서명 작업 실행 후 서명된 코드를 Lambda에 배포 → 배포 전 코드가 변조되지 않았음을 검증(요건 핵심) ▸ (A) 새 코드를 zip으로 S3 버킷에 배포 → Signer 서명/배포 워크플로의 아티팩트 준비 단계 【오답 체크】 (C) KMS 암호화는 기밀성 보호일 뿐 무결성(변조 검증)을 보장하지 않음. (D) CodeGuru는 코드 품질/성능 분석 도구, 서명/무결성 검증과 무관. (E) Secrets Manager 비밀 저장은 코드 무결성 검증과 무관. 【시험 포인트】 "코드가 변조되지 않았음을 배포 전 검증" → AWS Signer 서명 + 서명 코드 배포(S3 아티팩트).

해설

【핵심 용어】 ▸ SCP + 리전 제한 — 리소스 리전 제한에는 aws:RequestedRegion 조건과 S3 액션 조합 사용 ▸ S3 리전 외 접근 차단 — Deny s3:* + Condition StringNotEquals aws:RequestedRegion 미국 리전 ▸ SCP는 조직 전체 가드레일 — 계정/OU에 적용 【정답 포인트】 ▸ [이미지] 정답 SCP는 요청 리전이 미국 리전이 아닌 경우 S3 액션을 Deny하는 구조(Deny s3:* + aws:RequestedRegion 조건으로 US 리전 외 차단). 미국 외 리전의 S3 버킷 접근을 차단 【오답 체크】 (A)(C)(D) 중 [이미지] 오답은 조건 키/연산자를 잘못 사용하거나(허용/거부 반전, 리전 값 오류), 액션·효과 구성이 부정확해 "미국 외 리전 S3 차단"을 정확히 구현하지 못함. 【시험 포인트】 리전 기반 S3 차단 SCP = Deny + aws:RequestedRegion 조건으로 허용 리전만 예외. 조건 연산자(StringNotEquals) 방향 주의.

해설

【핵심 용어】 ▸ Amazon GuardDuty — CloudTrail, VPC 플로우 로그, DNS 로그를 자동 분석하는 관리형 위협 탐지(근실시간) ▸ 탐지 대상 — 비정상 DNS/네트워크/인스턴스 트래픽, 이상 S3 API 등 다양한 위협을 지속 모니터링 ▸ 중앙 계정 위임 관리자 — 조직 전체 GuardDuty 통합 관리 【정답 포인트】 ▸ "DNS 피크·비정상 트래픽·이상 S3 API 등 다양한 위협을 근실시간 지속 탐지" → GuardDuty를 중앙 계정에서 활성화하면 CloudTrail/VPC 플로우/DNS 로그를 자동 수집·분석해 위협 탐지 (별도 로그 파이프라인 불필요) 【오답 체크】 (A) 로그를 CloudWatch Logs로 모으는 것만으로는 위협 탐지·분석 자체가 자동으로 되지 않음(수동 분석 필요). (B) Macie는 S3 민감 데이터(PII) 탐지 전용, 다양한 위협 탐지 도구 아님. (D) Inspector는 EC2/컨테이너 취약점·네트워크 노출 평가용, 실시간 위협 탐지가 아님. 【시험 포인트】 "CloudTrail+VPC플로우+DNS 로그 기반 근실시간 위협 탐지" → Amazon GuardDuty. Macie=데이터 분류, Inspector=취약점 평가.

해설

【핵심 용어】 ▸ EBS 기본 암호화(Encryption by default) — 리전별 EC2 설정으로 신규 EBS 볼륨을 자동 암호화 ▸ Auto Scaling 인스턴스 리프레시(instance refresh) — ASG의 기존 인스턴스를 새 인스턴스로 순차 교체 ▸ Launch Template Encrypted 플래그 — 볼륨별 지정 가능하나 리전 기본 암호화가 전역적으로 확실 【정답 포인트】 ▸ "현재와 미래의 모든 EBS 암호화 보장" → EC2 콘솔에서 리전별 신규 EBS 기본 암호화를 활성화(미래 볼륨 자동 암호화)하고, ASG 인스턴스 리프레시로 기존 인스턴스를 교체해 미암호화 볼륨을 새 암호화 볼륨으로 대체 【오답 체크】 (A)(B) 런치 템플릿의 Encrypted 플래그만으로는 해당 ASG에 국한되고 "미래의 모든" 전역 보장이 약함(정답은 리전 기본 암호화 + 리프레시가 더 포괄적). (D) 기본 암호화 활성화는 맞으나 "ASG가 자동으로 인스턴스를 교체"하는 설정은 존재하지 않음(인스턴스 리프레시를 수동 트리거해야 함). 【시험 포인트】 "모든 EBS 지금+미래 암호화" → 리전 기본 EBS 암호화 활성화 + Auto Scaling 인스턴스 리프레시로 기존 인스턴스 교체.

해설

【핵심 용어】 ▸ Systems Manager Session Manager — SSH 키·개방 포트 없이 온프렘/EC2에 관리형 셸, 하이브리드(온프렘) 활성화 지원 ▸ SSM 하이브리드 액티베이션 — 온프렘 서버를 관리형 인스턴스로 등록해 Session Manager 사용 ▸ 임시 연결 시에만 비용 — 상시 실행 배스천 없이 필요 시점에만 세션 【정답 포인트】 ▸ "SSH 키 미유지 + 필요 시에만 접속 + 접속 시간만 과금 + 나머지 시간 격리" → Session Manager 설정으로 임시 연결 허용. 키·인바운드 포트 개방 없이 필요 시점에만 세션, 온프렘도 하이브리드로 지원 【오답 체크】 (A) 배스천 호스트는 SSH 키 유지 + 상시 실행 비용 발생으로 요건 위배. (C) CloudShell은 브라우저 기반 AWS CLI 셸이지 개별 머신 SSH 접속 수단이 아님. (D) 머신마다 인터페이스 VPC 엔드포인트를 두는 것은 접속 방식·비용 요건과 무관. 【시험 포인트】 "SSH 키 없이, 필요 시에만, 온프렘 포함 접속" → Systems Manager Session Manager(+하이브리드 액티베이션).

해설

【핵심 용어】 ▸ AWS Certificate Manager (ACM) — SSL/TLS 인증서 저장·관리, ALB/CloudFront/API Gateway 등과 통합 ▸ 커스텀 인증서 저장 위치 — ACM(또는 IAM 인증서 저장소)이 유효, KMS/S3는 인증서 저장소 아님 ▸ HTTPS 웹사이트 — ACM 인증서를 통합 리소스에 연결 【정답 포인트】 ▸ "SSL/TLS 인증서 저장 유효 옵션" → 커스텀 SSL 인증서를 ACM에 저장하는 것이 정답 (ACM이 인증서 관리 표준 서비스) 【오답 체크】 (A) KMS는 암호화 키 관리 서비스로 SSL/TLS 인증서 저장소가 아님. (B) CloudFront에 "기본 인증서"를 저장한다는 개념은 부정확(*.cloudfront.net 기본 도메인용일 뿐 커스텀 저장소 아님). (D) S3는 객체 스토리지로 SSL/TLS 인증서 저장·관리 서비스가 아님. 【시험 포인트】 SSL/TLS 인증서 저장·관리 = ACM. KMS(키)·S3(객체)는 인증서 저장소가 아님.

해설

【핵심 용어】 ▸ S3 Gateway Endpoint — VPC 라우트 테이블에 프리픽스 경로 추가, 엔드포인트 정책으로 접근 대상 버킷 제한(무료) ▸ aws:PrincipalOrgID / 엔드포인트 정책 — 조직 내 S3 버킷만 허용하도록 제한 ▸ S3 데이터 유출 방지 — 애플리케이션이 조직 소유 버킷에만 접근하도록 강제 【정답 포인트】 ▸ "AWS에 배포된 앱이 조직 내 S3 버킷에만 접근" + "팀이 새 버킷을 자유 생성" → 각 프라이빗 서브넷에 S3 Gateway 엔드포인트를 만들고, 엔드포인트 정책으로 허용 버킷을 제한. 모든 S3 요청을 이 엔드포인트로 라우팅해 외부 버킷 유출 차단 (Gateway 엔드포인트가 S3용 표준·무료) 【오답 체크】 (A) S3 액세스 포인트를 서브넷마다 두고 라우팅하는 구성은 부정확(액세스 포인트는 라우팅 대상이 아님). (C) S3에는 인터페이스 엔드포인트도 있으나 데이터 유출 차단·표준 라우팅 목적에는 Gateway 엔드포인트가 정답(비용·구성 측면). (D) Gateway Load Balancer 엔드포인트는 인라인 어플라이언스용이지 S3 접근 제어 수단이 아님. 【시험 포인트】 "VPC에서 S3 접근 대상 버킷 제한(유출 방지)" → S3 Gateway Endpoint + 엔드포인트 정책(조직/버킷 제한).

해설

【핵심 용어】 ▸ AWS Config 관리형 규칙(restricted-ssh) — 0.0.0.0/0의 SSH(22) 허용 SG를 비준수로 평가 ▸ EventBridge 규칙 — Config의 컴플라이언스 변경 이벤트를 트리거로 SNS 등에 근실시간 알림 ▸ SNS — 알림 발송 【정답 포인트】 ▸ "규정 준수 상시 모니터링 + 위반 시 근실시간 알림" → Config restricted-ssh 규칙의 컴플라이언스 변경 이벤트로 EventBridge 규칙을 트리거하고 SNS 토픽을 타깃으로 지정 → 위반 발생 즉시 알림 (가장 단순·근실시간) 【오답 체크】 (A) Config 스냅샷을 S3에 저장 후 Lambda 파싱은 근실시간이 아니고 과도하게 복잡. (B) CloudWatch Logs 메트릭 필터 방식은 지연·복잡하고 불필요. (D) restricted-ssh 규칙에 대한 CloudWatch 메트릭/알람 방식은 직접적 컴플라이언스 이벤트 알림보다 부정확·비표준. 【시험 포인트】 "Config 규칙 위반 근실시간 알림" → Config 컴플라이언스 변경 이벤트 → EventBridge 규칙 → SNS.