정답 · 해설

해설

【핵심 용어】 ▸ EC2 Image Builder — 자동화된 AMI 빌드, 테스트, 배포 서비스 ▸ Vulnerability Scanning — 빌드 프로세스에 통합된 보안 검사 ▸ Custom Recipe — Image Builder에서 사용자 정의 설치/구성 정의 【정답 포인트】 ▸ "정기적 업데이트 + vulnerability scan"→Image Builder가 양쪽 모두 네이티브 지원 ▸ Image Builder는 빌드 단계에서 자동으로 vulnerability scan 수행 ▸ Weekly 업데이트를 scheduled recipe로 자동화 가능 ▸ Operational efficient: 매뉴얼 작업 최소, 테스트 자동화, 배포 자동화 【오답 체크】 (A) Packer + Cron — vulnerability scan 기능 없음, 스크립트 관리 오버헤드, 테스트 자동화 부족 (B) 수동 AMI 생성 — 일회성, 정기 업데이트 자동화 불가, vulnerability scan 없음 (D) EventBridge + CreateImage — AMI 생성만 가능, vulnerability scan 미지원 【시험 포인트】 ▸ EC2 Image Builder는 빌드 → 테스트 → 배포의 전체 파이프라인 자동화 ▸ "Operational efficient" 키워드 → 자동화, 테스트, 모니터링이 통합된 서비스 필요 ▸ Vulnerability scan이 요구사항인 경우 Image Builder 또는 AWS Inspector 통합 필요

해설

【핵심 용어】 ▸ Network Load Balancer (NLB) — Layer 4(전송 계층) 로드 밸런싱, 초고성능 ▸ Ultra-high performance — 초당 수백만 요청 처리 가능 ▸ Static IP — 각 AZ에 고정 IP 할당 가능 【정답 포인트】 ▸ "매초 수백만 요청"→NLB가 ALB보다 훨씬 높은 처리량 제공 ▸ "단일 정적 IP per AZ"→NLB는 각 AZ별로 static elastic IP 지정 가능 ▸ "갑작스럽고 변동성 있는 트래픽"→NLB의 ultra-low latency와 connection-based scaling이 최적 【오답 체크】 (A) SQS Queue — 로드 밸런싱 아님, 비동기 메시지 큐, 직접 분산 불가 (B) Application Load Balancer — Layer 7 기반, 초당 수백만 요청 처리 어려움, 정적 IP 할당 불가 (C) AWS Global Accelerator — 지리적 분산 최적화, 단순 로드 밸런싱이 아님, 복잡성 증가 【시험 포인트】 ▸ "정적 IP per AZ" 요구사항 → NLB만 가능 ▸ "초고성능" + "변동성 있는 트래픽" → NLB의 connection-draining과 flow hash algorithm 이해 ▸ ALB vs NLB: ALB(Layer 7, 콘텐츠 기반) vs NLB(Layer 4, 성능 극대화)

해설

【핵심 용어】 ▸ Sticky Session — 같은 클라이언트의 요청을 같은 백엔드에 라우팅 ▸ Cookie Forwarding — CloudFront가 쿠키를 캐시 키에 포함, 서버로 전달 ▸ Stateful Application — 세션 상태를 서버에 저장하는 애플리케이션 【정답 포인트】 ▸ "Stateful + 임의 로그아웃"→세션 쿠키가 다른 인스턴스로 이동하는 문제 ▸ Cookie Forwarding (B): CloudFront가 기본적으로 쿠키를 제거함 → 명시적으로 쿠키를 캐시 및 서버로 전달 ▸ Sticky Sessions (E): ALB가 같은 클라이언트를 같은 target으로 계속 라우팅 ▸ 두 가지 모두 필요: CloudFront에서 쿠키 보존 + ALB에서 세션 고정 【오답 체크】 (A) Least outstanding requests — 알고리즘 변경이 세션 문제 해결 안 함 (C) Header forwarding — 쿠키가 아닌 HTTP 헤더 포함, 인증/세션에 영향 작음 (D) Group-level stickiness — ALB에 "group-level" stickiness 없음, 문법 오류 【시험 포인트】 ▸ CloudFront 뒤의 stateful application은 쿠키 포워딩 필수 ▸ ALB의 sticky sessions는 target group 수준에서 설정 ▸ 분산 시스템에서 세션 관리의 두 계층: CDN(쿠키 전달) + LB(라우팅 유지)

해설

【핵심 용어】 ▸ Transit Gateway — Region 내 또는 Region 간 VPC, 온프레미스 네트워크를 연결하는 허브 ▸ Resource Sharing — AWS Resource Access Manager로 계정 간 리소스 공유 ▸ Transit Gateway Peering — 여러 Region의 transit gateway 연결 【정답 포인트】 ▸ "5개 Region + 각 Region별 계정 + 중앙 shared VPC"→각 Region의 TGW를 중앙에 집중시킬 수 없음 ▸ 옵션 B: 각 Region의 TGW를 생성하고, 각 Region의 workload + shared VPC를 연결 ▸ Region 간 연결: Transit Gateway Peering으로 해결 ▸ 확장성과 관리성: 지역별 분산으로 네트워크 복잡도 감소 【오답 체크】 (A) 중앙 단일 TGW — Region 간 전송 비용 증가, 지연 시간 증가, 확장성 제한 (C) VPN + Virtual Private Gateway — 복잡한 구성, 다대다 연결 관리 어려움, 성능 저하 (D) VPC Peering — 메쉬 구조로 관리 복잡도 급증(5 Region × 2 shared = 12개 VPC 쌍) 【시험 포인트】 ▸ "다중 Region + 다중 계정" 구조 → Transit Gateway가 표준 솔루션 ▸ 각 Region별 TGW 생성 후 Peering이 가장 확장 가능한 설계 ▸ VPC Peering은 n×m 메쉬로 인해 관리 부담 증가

해설

【핵심 용어】 ▸ RDS Performance Insights — 데이터베이스 성능 분석 및 병목 지점 식별 도구 ▸ RDS Proxy — Connection pooling을 통한 데이터베이스 연결 관리 ▸ Connection Pooling — 여러 클라이언트 연결을 데이터베이스 연결로 재사용 【정답 포인트】 ▸ "높은 CPU + query latency + connection 급증"→두 가지 문제: 비효율적 쿼리 + 과다 연결 ▸ Performance Insights (A): CPU 집약적 쿼리 식별 → 최적화 통해 리소스 절약 ▸ RDS Proxy (E): 연결 풀링으로 과다 연결 문제 해결, idle 연결 정리 ▸ 두 가지 모두 필요: 쿼리 최적화 + 연결 관리 【오답 체크】 (B) CloudWatch Logs Insights — 일반 로그 분석용, Performance Insights보다 데이터베이스 성능 분석에 부족 (C) 단일 AZ — 가용성 저하, 성능 개선 X, read replica 활용 불가 (D) Connection pooling 비활성화 — 성능 악화, 연결 타임아웃 증가, 역효과 【시험 포인트】 ▸ "높은 CPU + connection 급증" → 두 가지 독립적 문제 해결 필요 ▸ RDS Proxy는 application 수정 없이 connection 관리 개선 ▸ Performance Insights는 "쿼리 최적화" 관점의 성능 개선

해설

【핵심 용어】 ▸ Target Tracking Scaling Policy — 특정 메트릭 목표를 유지하도록 자동 조정 ▸ Scheduled Scaling Policy — 사전에 정한 시간에 인스턴스 추가/제거 ▸ Auto Scaling Group — 인스턴스 수를 자동으로 조정하는 관리형 서비스 【정답 포인트】 ▸ "임의의 트래픽 증가"→예측 불가능 → Scheduled (D)는 부적합 ▸ "성능 저하 해결"→Target Tracking으로 latency 기준 자동 조정 ▸ Target Tracking: CPU, 요청 수, ALB target group latency 등 메트릭 기반 자동 스케일 ▸ 인스턴스 추가/제거 자동화 → 비용 절감 + 성능 최적화 【오답 체크】 (A) Cloudwatch alarm + 수동 크기 조정 — 실시간 대응 어려움, latency 증가 후 조치 (B) EventBridge — 복잡한 구성, 트래픽에 따른 자동 조정 불가, 수동 개입 필요 (D) Scheduled Scaling — 고정 시간표, 임의 트래픽 패턴 대응 불가 【시험 포인트】 ▸ "임의의/변동성 있는" 트래픽 → Target Tracking Scaling ▸ "정규적/예측 가능한" 트래픽 → Scheduled Scaling ▸ Auto Scaling Group이 수평적 확장의 표준 솔루션

해설

【핵심 용어】 ▸ RDS Read Replica — 읽기 전용 복제본, 읽기 부하 분산 ▸ Reader Endpoint — read replica들의 자동 부하 분산 엔드포인트 ▸ IOPS — 초당 입출력 작업 수, 읽기 성능의 핵심 지표 【정답 포인트】 ▸ "Read IOPS 높음"→읽기 집약적 작업(reporting) 때문 ▸ "보고서 실행 안 할 때도 높음"→다른 애플리케이션도 읽기 수행 ▸ Read Replica (B): 읽기 부하를 replica로 분산 → 주 인스턴스 IOPS 절감 ▸ Reader Endpoint: 여러 replica 간 자동 부하 분산 【오답 체크】 (A) ElastiCache — 캐싱용, 기존 데이터 동기화 복잡, 캐시 무효화 관리 필요 (C) CloudFront--일반적으로 데이터베이스 캐싱용 아님, HTTP 응답 캐싱만 가능 (D) 인스턴스 크기 증가--비용 증가, IOPS 문제의 근본 해결 아님, 수평 확장 불가 【시험 포인트】 ▸ "읽기 부하 높음" → Read Replica가 표준 솔루션 ▸ Reader Endpoint로 애플리케이션 수정 최소화 ▸ 보고서 쿼리도 read replica로 지정하면 write operation 최소화

해설

【핵심 용어】 ▸ Route 53 Resolver DNS Firewall — DNS-based threats 탐지 및 필터링 전용 서비스 ▸ Threat Detection — DNS 쿼리 수준에서 악의적 도메인 차단 ▸ DNS-based Attacks — DNS 쿼리 조작, DNS spoofing, DNS amplification 【정답 포인트】 ▸ "DNS-based threat protection"→Route 53 Resolver DNS Firewall이 유일한 전문 솔루션 ▸ DNS Firewall: 사전 정의된 threat 규칙, 커스텀 블록 리스트 지원 ▸ 모든 DNS 쿼리에서 자동으로 위협 탐지 ▸ Route 53 Resolver 통합으로 VPC 전체에 적용 【오답 체크】 (A) AWS Shield Advanced — DDoS 공격 방어, DNS-기반 위협 전문성 부족 (B) AWS WAF — Layer 7(HTTP/HTTPS) 방화벽, DNS 프로토콜(Layer 4) 검사 불가 (D) AWS Config + Lambda — 구성 모니터링용, 실시간 DNS 필터링 불가, 성능 저하 【시험 포인트】 ▸ "DNS-based" 키워드 → Route 53 Resolver DNS Firewall 선택 ▸ Shield(DDoS) vs WAF(웹 공격) vs DNS Firewall(DNS 위협) 구분 ▸ Route 53 Resolver는 VPC의 기본 DNS 해석기, Firewall 통합 가능

해설

【핵심 용어】 ▸ KMS Key Policy — KMS 키 사용 권한 제어, cross-account 공유 가능 ▸ Cross-Account Snapshot — KMS 암호화된 스냅샷 공유 및 복원 ▸ Minimum Administrative Overhead — 가장 간단하고 자동화된 방법 【정답 포인트】 ▸ "KMS 암호화 RDS snapshot"→KMS 키 정책 수정이 필수 ▸ 옵션 A: KMS key policy에 migration account root 추가 → snapshot 공유 → 자동 복원 ▸ 최소 오버헤드: 스냅샷 생성/공유만으로 완료, 복잡한 설정 불필요 ▸ KMS 정책 수정으로 migration account가 스냅샷 복원 시 키 자동 사용 가능 【오답 체크】 (B) Read Replica to migration account--KMS 키 복제 불가, 다른 계정의 KMS는 암호화 불가, 개념 오류 (C) 새로운 KMS key 생성--기존 데이터를 새 키로 다시 암호화해야 함, 복잡성 증가 (D) S3를 통한 export/import--네이티브 RDS 도구 필요, 데이터 이동 시간 증가, 중간 저장소 필요 【시험 포인트】 ▸ Encrypted RDS snapshot 공유 = KMS key policy 수정 ▸ Root user 권한: 모든 권한 암시, 최소 권한 원칙보다 구현 단순성 ▸ Cross-account KMS 사용의 가장 간단한 패턴: snapshot share + KMS policy

해설

【핵심 용어】 ▸ CloudWatch Logs Insights — CloudWatch Logs의 쿼리 및 분석 엔진 ▸ stats command — 집계 함수(count, sum, avg 등) 사용 ▸ Groupby — 집계 결과를 특정 필드별로 그룹화 【정답 포인트】 ▸ "모든 log groups의 errors count by type"→multiple log groups 전체 쿼리 필요 ▸ CloudWatch Logs Insights: 여러 log group 동시 쿼리 가능 ▸ stats count() by error_type 문법 → error type별 카운트 집계 ▸ 실시간 분석, 추가 ETL/storage 불필요 【오답 체크】 (B) CloudWatch Logs search with groupby--CloudWatch search는 단순 검색, 집계 함수 미지원 (C) Athena--CloudWatch Logs를 S3로 내보내야 함, 추가 파이프라인 필요, 지연 시간 증가 (D) RDS--로그 데이터를 RDS로 로드해야 함, 과도한 설정, 부적절한 도구 【시험 포인트】 ▸ "CloudWatch Logs에서 바로 분석" → CloudWatch Logs Insights 사용 ▸ Multiple log group query → Insights의 고유 기능 ▸ stats + groupby의 조합으로 복잡한 집계 가능 ▸ "1GB/day × multiple functions" → 빠른 쿼리 성능 필요

해설

【핵심 용어】 ▸ CloudWatch Alarm EC2 Action — Alarm에서 직접 EC2 작업(reboot, terminate) 트리거 ▸ SNS Notification — Alarm 상태 변화 시 자동 알림 ▸ Least Administrative Effort — 최소한의 구성 요소 사용 【정답 포인트】 ▸ "Reboot + Notify"→CloudWatch Alarm이 두 가지 모두 직접 지원 ▸ 알람 직접 EC2 action: Lambda 오버헤드 없음 ▸ 알람 직접 SNS 발행: 자동으로 notification 전송 ▸ 구성 최소: CloudWatch + SNS만 필요, Lambda 불필요 【오답 체크】 (A) Lambda 함수 구성--불필요한 복잡성, EC2 권한 설정 필요, Lambda 비용 증가 (C) Systems Manager incident--수동 개입 필요, "자동" reboot 불가, incident 생성만 함 (D) Systems Manager runbook--Runbook 작성 필수, CloudWatch에서 runbook 호출 방식 복잡 【시험 포인트】 ▸ CloudWatch Alarm의 직접 EC2 action 지원 = 가장 간단한 해결책 ▸ "Least administrative effort" → 기본 기능만 사용, 추가 통합 불필요 ▸ Lambda (A)는 "자동화"가지만 이 경우 과도한 구성

해설

【핵심 용어】 ▸ Alias Record — AWS 리소스(ALB, CloudFront, S3)에 대한 Route 53 전용 레코드 ▸ A Record — IPv4 주소에 매핑 (고정 IP 주소) ▸ CNAME Record — 다른 도메인 이름에 매핑, apex domain 불가 【정답 포인트】 ▸ "ALB URL → example.com"→ALB는 IP가 아닌 DNS 이름 제공 ▸ Alias Record: Route 53에서 ALB를 직접 대상으로 가능 ▸ ALB는 동적 IP, 따라서 A record 불가능 ▸ Alias는 추가 요금 없음, health check 지원 【오답 체크】 (A) A Record--ALB는 고정 IP 없음, 동적 IP, 작동 불가 (B) AAAA Record--IPv6 주소 매핑, ALB가 IPv6만 제공하는 경우 드문 경우 (D) CNAME Record--ALB 도메인에 매핑 가능하지만, example.com (apex)에는 CNAME 불가 【시험 포인트】 ▸ "ALB" + "Route 53" → Alias Record가 표준 답 ▸ Alias vs CNAME: Alias는 AWS 리소스, CNAME은 일반 도메인 ▸ Apex domain (example.com)은 CNAME 불가, Alias는 가능

해설

【핵심 용어】 ▸ Slow Start Duration — 인스턴스가 full traffic 받기 전 점진적 증가 기간 ▸ Health Check — 인스턴스가 healthy한지 확인, 통과 후 즉시 traffic 배치됨 ▸ Gradual Traffic Increase — 캐시 준비 시간 확보 【정답 포인트】 ▸ "2분 캐시 + 몇 초 건강 검사" → Health check 통과 후 바로 full traffic 문제 ▸ slow_start.duration_seconds: 120초 설정 → health check 후 2분에 걸쳐 traffic 증가 ▸ Deregister/Register: 기존 연결 정리 후 새로 시작 → slow start 메커니즘 활성화 【오답 체크】 (B) HealthCheckTimeoutSeconds--timeout 조정, 점진적 증가 제공 안 함 (C) CloudWatch alarm + weighted_random--health check 실패 재시작, 복잡성 증가, 근본 해결 아님 (D) Auto Scaling lifecycle hook--가능하지만 애플리케이션 수정 필요, 복잡한 상태 관리 【시험 포인트】 ▸ "점진적 증가" 요구 → slow_start.duration_seconds가 표준 기능 ▸ slow start는 deregister → reboot → register 사이클에서 활성화 ▸ 120초 설정으로 2분 캐시 준비 시간 완벽 대응

해설

【핵심 용어】 ▸ Aurora Backtrack — 시간 내에서 롤백 가능, 같은 database 유지 ▸ Point-in-Time Recovery — 특정 시점으로 복원, 새로운 인스턴스 생성 ▸ RTO/RPO — 복구 시간/복구점 목표 【정답 포인트】 ▸ "Data 복구 + 애플리케이션 정상 작동"→기존 database 복원 불가 (table drop됨) ▸ Point-in-time recovery + 새로운 database: drop 전 상태로 완벽 복원 ▸ 새로운 endpoint: 애플리케이션이 지정된 새 database 사용 ▸ 기존 database 손상 상태 유지 방지 【오답 체크】 (A) Aurora Backtrack--같은 database에서만 작동, table drop은 되감기되지만 ongoing 작업 영향 (B) 기존 database 복원--table drop 상태가 유지, 애플리케이션 정상화 불가 (D) S3에서 복원--데이터가 S3에 미리 내보내져 있어야 함, 현재 상황에 부적용 【시험 포인트】 ▸ "Table drop" = 데이터 손실 = Point-in-time recovery 필수 ▸ Backtrack은 동일 database, PITR은 새로운 database 생성 ▸ Application endpoint 수정이 복구의 일부 (C만 명시) ▸ Aurora의 point-in-time recovery는 최대 35일까지 가능

해설

【핵심 용어】 ▸ Trusted Advisor — AWS 계정 리소스 확인, service quota 포함 ▸ Service Quota — 각 서비스별 리소스 제한 ▸ CloudWatch Alarm + SNS — 메트릭 기반 notification 설정 【정답 포인트】 ▸ "Service quota metric 모니터링" → CloudWatch Alarm이 표준 ▸ Trusted Advisor 메트릭은 CloudWatch에 자동 발행됨 ▸ CloudWatch Alarm: 60% threshold 설정 가능 ▸ SNS: Email notification 기본 지원, SQS는 email 미지원 【오답 체크】 (B) SNS 대신 SQS--SQS는 메시지 큐, email subscription 지원 안 함 (C/D) AWS Health Dashboard--실시간 quota 모니터링 미지원, 이벤트 기반 알림만 가능 【시험 포인트】 ▸ CloudWatch Alarm + SNS = Notification 조합의 표준 ▸ "Email notification" → SNS만 가능 ▸ AWS Health Dashboard는 이벤트/권장사항용, 실시간 threshold 모니터링 아님

해설

【핵심 용어】 ▸ VPC Endpoint — VPC에서 AWS 서비스로의 Private 연결 ▸ Interface Endpoint — ENI 기반, CloudWatch 등 대부분 서비스 ▸ Gateway Endpoint — Route 테이블 기반, S3/DynamoDB만 ▸ DNS Resolution — VPC가 DNS 이름을 해석 가능하도록 활성화 【정답 포인트】 ▸ "Private VPC + Internet access 없음" → VPC Endpoint 필수 ▸ CloudWatch Synthetics: CloudWatch API 호출 필요 → Interface Endpoint ▸ S3 전송: S3 Gateway Endpoint 필요 ▸ DNS Options 켜야 함: 도메인 이름 해석 필요 ▸ 두 endpoints 모두 필요: CloudWatch (모니터링) + S3 (결과 저장) 【오답 체크】 (A) DNS 켜기만--Endpoint 없으면 private VPC에서 외부 서비스 접근 불가 (B) DNS 끄기--Endpoint 구성해도 DNS 해석 불가, 연결 실패 (C) DNS 끄기 + Security Group--DNS port(53) 열어도 DNS resolution 자체가 불가 【시험 포인트】 ▸ Private VPC + 외부 서비스 = VPC Endpoint 조합 필요 ▸ Interface (CloudWatch) + Gateway (S3) 구분 필수 ▸ DNS resolution/hostnames 활성화가 전제 조건 ▸ CloudWatch Synthetics는 CloudWatch API와 S3 동시 필요

해설

【핵심 용어】 ▸ VPC-Connected Lambda — Private subnet에 배포된 Lambda ▸ NAT Gateway — Private subnet의 아웃바운드 인터넷 접근 ▸ VPC Endpoint — AWS 서비스로의 Private 연결 【정답 포인트】 ▸ "Private subnet Lambda + SQS 접근 timeout" → 인터넷 연결 부족 ▸ 옵션 C: NAT gateway → 모든 아웃바운드 트래픽 인터넷 경로 ▸ 옵션 D: SQS Interface Endpoint → 인터넷 거치지 않고 SQS 접근 ▸ 양쪽 모두 작동: NAT는 일반적 해결, Endpoint는 SQS 특화 【오답 체크】 (A) VPC 연결 해제--DB instance 접근 불가, RDS는 private subnet에 있음 (B) RDS Proxy--SQS 문제 해결 안 함, 불필요한 추가 구성 (E) SQS Gateway Endpoint--SQS는 interface endpoint만 지원, gateway endpoint 미지원 【시험 포인트】 ▸ Private Lambda → SQS: NAT (인터넷 경로) 또는 VPC Endpoint (Private 경로) ▸ Endpoint 선택: Interface (SQS, Lambda, CloudWatch) vs Gateway (S3, DynamoDB) ▸ "2개 선택" → 두 가지 독립적 솔루션 가능 (일반 + 특화)

해설

【핵심 용어】 ▸ AWS Config Auto Remediation — 규격 위반을 자동 탐지하고 지정된 수정 작업으로 즉시 교정하는 기능입니다. ▸ AWS-DisablolncomingSSHOnPort22 — SSH 포트 22의 제한 없는 접근을 자동 차단하는 관리형 수정 작업입니다. 【정답 포인트】 ▸ "자동 수정 작업"→Auto Remediation이 핵심. ▸ "관리형 수정 작업"→AWS Config가 제공하는 기본 제공 수정 작업으로 즉시 배포 가능. ▸ 운영상 효율성 — 수동 개입 없이 자동으로 비규격 리소스 교정. 【오답 체크】 (A) CloudWatch 알람은 메트릭 기반이며 구성 변경 감지에 부적합; 수동 Lambda 구성 필요. (C) EventBridge는 변경 이벤트 기반이므로 원인 분석 후 수정으로 지연 발생. (D) 1시간 주기는 실시간 수정이 아니며, 새로운 비규격 리소스가 생성되는 동안 보안 갭 존재. 【시험 포인트】 ▸ AWS Config Auto Remediation은 규격 위반의 자동화된 해결책. ▸ 관리형 수정 작업(AWS-XXX)은 빠른 배포와 유지보수 최소화. ▸ CloudOps 시험에서 '자동화', '즉시', '운영 효율' 키워드 시 이 패턴 확인.

해설

【핵심 용어】 ▸ HTTP Layer 7 상태 코드 — 응용 계층 HTTP 응답 코드(200, 404, 500 등)입니다. ▸ ALB 접근 로그 — 요청/응답 메타데이터를 기록하는 Application Layer 로그입니다. ▸ CloudFront 접근 로그 — 엣지 로케이션에서의 클라이언트 요청/응답 로그입니다. 【정답 포인트】 ▸ ALB 접근 로그는 Load Balancer 수준의 HTTP 상태 코드 포함. ▸ CloudFront 접근 로그는 CDN 엣지에서의 HTTP 상태 코드 포함. ▸ 두 가지 모두 Layer 7(Application) 정보 수록. 【오답 체크】 (A) VPC Flow Logs는 Layer 3/4 정보만 기록; 상태 코드 없음. (B) CloudTrail은 API 호출 기록; HTTP 응답 상태 코드 미포함. (E) RDS 로그는 데이터베이스 수준 활동; HTTP 상태 코드 미포함. 【시험 포인트】 ▸ "HTTP 상태 코드" 언급 시 Application Layer 로그(ALB, CloudFront) 선택. ▸ VPC Flow Logs는 Layer 3/4 트래픽 메타데이터만. ▸ CloudTrail은 API 거버넌스용. ▸ Layer 7 정보는 Application 로그에서만 조회.

해설

【핵심 용어】 ▸ 기본 모니터링 — 5분 간격으로 메트릭을 수집합니다. ▸ 상세 모니터링 — 1분 간격으로 세밀한 메트릭 수집(상세 모니터링 활성화 필요). ▸ CPU 사용률 — CloudWatch 기본 메트릭으로 자동 제공됩니다. 【정답 포인트】 ▸ "2분 이상"→1분 단위 세분화 필요. ▸ 상세 모니터링만 1분 간격 데이터 제공. ▸ CloudWatch 알람의 평가 기간을 2분(2개 1분 주기)으로 설정 가능. ▸ 기본 모니터링(5분)은 2분 요구사항 충족 불가. 【오답 체크】 (A) 기본 모니터링은 5분 간격으로 "2분 이상" 조건 감지 불가. (C) 정기 호출은 실시간 CPU 스파이크 감지 안 함. (D) EC2 상태 검사는 인스턴스 도달 가능성만 체크; CPU 메트릭 기반 아님. 【시험 포인트】 ▸ "분 단위" 응답 요구사항 → 상세 모니터링 필수. ▸ 기본 vs 상세 모니터링 선택은 시간 세분화(5분 vs 1분) 기준. ▸ 알람 평가 기간 설정으로 "X분 동안" 조건 구현.