정답 · 해설

해설

【핵심 용어】 ▸ RDS Proxy — 연결 풀링, 쿼리 캐싱, 연결 수 감소 ▸ Secrets Manager — 자동 회전, 감사 로깅 【정답 포인트】 ▸ 연결 과부하: RDS Proxy 필수, 연결 풀 관리 ▸ 자격 증명 회전: Secrets Manager는 자동 회전, Parameter Store는 수동 ▸ 조합: RDS Proxy (연결) + Secrets Manager (회전) 【오답 체크】 (B) Parameter Store: 자동 회전 기능 없음 (C) Aurora Replica: 읽기 복제본, 쓰기 연결 과부하 미해결 (D) Replica + Parameter Store: 2개 미충족 【시험 포인트】 패턴: "연결 과부하 + 자동 회전" → RDS Proxy + Secrets Manager 매핑: 연결 풀 = Proxy, 자격 증명 관리 = Secrets Manager

해설

【핵심 용어】 ▸ RPO 30초 — 데이터 손실 최소 ▸ RTO 10분 — 빠른 복구 ▸ Elastic Disaster Recovery — 지속 복제, 빠른 장애 조치 【정답 포인트】 ▸ AWS Elastic Disaster Recovery: 지속 복제로 RPO 달성 ▸ 교차 리전 읽기 복제본: DB RPO 충족 ▸ 최소 용량 실행: 대기 비용 절감, 필요 시 스케일업 ▸ Route 53 장애 조치: 자동 장애 조치 【오답 체크】 (A) 30초 cron: 비현실적, AWS DMS는 해당 RPO 미지원 (C) 수동 복구: RTO 10분 미충족 (D) 전체 용량 대기: 비용 낭비, 최소 비용 미충족 【시험 포인트】 패턴: "RPO/RTO 요구사항" → Elastic DR + 읽기 복제본 매핑: 지속 복제 = RPO 달성, 최소 용량 = 비용 절감

해설

【핵심 용어】 ▸ Snowball Edge — 100TB/디바이스, 온프레미스 처리 가능 ▸ AWS DMS — S3 소스 지원, 데이터베이스 마이그레이션 【정답 포인트】 ▸ 60TB 대용량: Direct Connect 설치 시간 > Snowball 배송 ▸ Snowball Edge: 물리적 배송, 빠른 데이터 이동 ▸ DMS S3 소스: S3 > Aurora 직접 마이그레이션 ▸ 최단 시간: 물리적 운반 + 병렬 처리 【오답 체크】 (A) Direct Connect: 설치/활성화 시간 + 네트워크 구성 (B) DataSync: 여전히 인터넷 의존, 대역폭 제한 미해결 (D) Snowball (표준): Edge보다 느림, Application Migration Service는 DB 마이그레이션용 아님 【시험 포인트】 패턴: "대용량 오프라인 마이그레이션" → Snowball 시리즈 매핑: 60TB = Snowball Edge + DMS S3 소스

해설

【핵심 용어】 ▸ AWS Backup — EC2/EBS 통합 백업, 교차 리전 복사 ▸ 운영 효율성 — 자동 백업 & 복구 ▸ RPO 1일 — 일일 백업 충분 【정답 포인트】 ▸ AWS Backup: EC2 인스턴스 + EBS 볼륨 통합 관리 ▸ 자동 교차 리전 복사: 운영 부담 최소 ▸ 통합 복구: 볼륨 + 구성 한 번에 복구 ▸ 비용 효율: 자동화로 관리 비용 절감 【오답 체크】 (A) Systems Manager runbook: 수동 스냅샷 관리 필요 (B) DLM: EBS만 관리, EC2 인스턴스 구성 미지원 (D) DataSync: 데이터만 복사, 구성 미지원, 인스턴스 사전 배포 필요 【시험 포인트】 패턴: "EC2/EBS 통합 DR" → AWS Backup 매핑: 운영 효율성 = 관리형 서비스 자동화

해설

【핵심 용어】 ▸ 저장 시 암호화 — S3 SSE ▸ 전송 중 암호화 — HTTPS/TLS, CloudFront HTTP→HTTPS 【정답 포인트】 ▸ (A) S3 SSE: 저장 시 암호화 표준 ▸ (C) 버킷 정책: SecureTransport 필수로 강제 ▸ (E) CloudFront HTTPS 강제: 전송 중 암호화 ▸ 조합: 저장 + 전송 암호화 완벽 보장 【오답 체크】 (B) ACL "aws:SecureTransport": ACL은 권한 아님, 버킷 정책 필요 (D) CloudFront SSE-KMS: CloudFront 간선(엣지)는 암호화 불필요, 오버엔지니어링 (F) RequireSSL: 사전 서명 URL에서 거의 사용 안 함 【시험 포인트】 패턴: "S3 + CloudFront 암호화" → SSE + Bucket Policy + HTTPS Redirect 매핑: 저장 = SSE, 전송 = HTTP → HTTPS

해설

【핵심 용어】 ▸ Secrets Manager — 자동 회전, 감사 로깅, 베스트 프랙티스 ▸ 환경 변수 암호화 — Lambda에서 암호화하지만 평문 노출 위험 【정답 포인트】 ▸ Secrets Manager: 자동 회전("정기적으로 회전" 요구사항) ▸ Lambda 역할 연결: 최소 권한 원칙 ▸ KMS 고객 관리형 키: IT 보안팀만 제어 ▸ 감사: Secrets Manager는 CloudTrail 자동 로깅 【오답 체크】 (A) Parameter Store: SecureString도 가능하지만 자동 회전 미흡 (B) 환경 변수: 로그에 노출, 감사 어려움, 회전 수동 (C) 환경 변수 암호화: 여전히 평문 로드/접근 가능성 【시험 포인트】 패턴: "자동 회전 + 감사" → Secrets Manager 매핑: 환경 변수 < Secrets Manager (보안 & 회전)

해설

【핵심 용어】 ▸ Babelfish — PostgreSQL에서 T-SQL 호환성, SQL Server 마이그레이션 최적 ▸ 라이센싱 비용 — SQL Server 비용 제거 ▸ 재작성 불필요 — 애플리케이션 코드 변경 최소 【정답 포인트】 ▸ Aurora PostgreSQL + Babelfish: .NET 애플리케이션 호환, SQL Server 라이센싱 제거 ▸ EC2 + ALB + ASG: 웹/앱 서버 스케일 가능 ▸ 비용 절감: SQL Server 라이센싱 제거 >> 다른 비용 【오답 체크】 (B) DMS로 EC2 이미지: 관리형 서비스 활용 미흡, DynamoDB 부적합 (C) EKS + RDS SQL Server: 여전히 SQL Server 라이센싱 비용 (D) Lambda + API Gateway: .NET 대규모 마이그레이션에 부적합, 재설계 필요 【시험 포인트】 패턴: "SQL Server 라이센싱 비용 최소화" → Aurora PostgreSQL + Babelfish 매핑: T-SQL 호환성 = Babelfish, 비용 절감 = 라이센싱 제거

해설

【핵심 용어】 ▸ 비표준 REST 메서드 (LINK, UNLINK 등) — CloudFront/API Gateway 캐싱 불가 ▸ Global Accelerator — 비표준 프로토콜, 모든 HTTP 메서드 지원 【정답 포인트】 ▸ Global Accelerator: 비표준 메서드 지원 (CloudFront/API Gateway는 제한) ▸ Anycast IP: 글로벌 사용자를 가장 가까운 엣지로 라우팅 ▸ 낮은 지연: 글로벌 네트워크 활용 ▸ 운영 오버헤드 최소: 단일 ALB 유지 【오답 체크】 (A) CloudFront: HTTP 메서드 제한, 비표준 LINK/UNLINK 미지원 (B) API Gateway: 엣지 최적화도 메서드 제한 (D) 다중 리전: 운영 복잡성 증가, 동기화 어려움 【시험 포인트】 패턴: "비표준 메서드 + 글로벌" → Global Accelerator 매핑: 모든 메서드 지원 = Global Accelerator 필수

해설

【핵심 용어】 ▸ AWS IoT Core — MQTT 브로커 관리형 서비스, 확장성, 신뢰성 ▸ 기존 MQTT 브로커 → AWS IoT Core 마이그레이션 【정답 포인트】 ▸ AWS IoT Core: 완전 관리형, 자동 스케일, 센서 손실 방지 ▸ 사용자 정의 도메인: 기존 iot.example.com 유지 ▸ AWS IoT 규칙: DynamoDB 자동 저장 ▸ 신뢰성: EC2 단일 지점 실패 제거 【오답 체크】 (A) ALB + MQTT: 상태 유지 프로토콜, ALB 부적합 (C) NLB + Global Accelerator: 기존 MQTT 브로커 유지, 근본 해결 아님 (D) Greengrass: 엣지 기기용, 클라우드 수집용이 아님 【시험 포인트】 패턴: "MQTT 브로커 신뢰성" → AWS IoT Core 매핑: 완전 관리형 MQTT = IoT Core (EC2 자체 브로커 제거)

해설

【핵심 용어】 ▸ Secrets Manager — 암호화된 시크릿 저장 및 자동 교체 기능 제공 ▸ Lambda 함수 — 키 페어 생성 및 교체 로직 실행 ▸ EC2 SSH 키 페어 — 각 머신의 공개/개인 키 쌍 【정답 포인트】 ▸ "자동으로 교체" → Secrets Manager의 네이티브 rotation schedule이 최적 ▸ "암호화된 안전한 위치" → Secrets Manager가 기본적으로 암호화 제공 ▸ Lambda 함수 → 새 키 쌍 생성, 공개 키를 EC2에 배포, 개인 키를 Secrets Manager 업데이트 ▸ 1분 미만 다운타임 → Secrets Manager rotation은 신속한 교체 가능 【오답 체크】 (B) Parameter Store는 encryption 기능이 있지만 rotation 메커니즘이 Secrets Manager만큼 강력하지 않음 (C) KMS는 데이터 암호화 키를 관리하지만, EC2 SSH 키 페어 자체를 KMS로 직접 관리할 수 없음. KMS rotation은 데이터 키 교체이지 SSH 키 페어 교체가 아님 (D) Fleet Manager는 인스턴스 관리용이지 키 페어 교체 자동화에 부적합. 모든 인스턴스의 공개 키를 동시에 업데이트하면 연결 끊김 위험 【시험 포인트】 Secrets Manager의 rotation schedule은 Lambda 함수와 통합되어 시크릿 교체를 완전 자동화. SSH 키 교체는 공개 키만 EC2에 배포하고 개인 키는 안전하게 관리하는 구조가 핵심.

해설

【핵심 용어】 ▸ Migration Evaluator — 에이전트 없는 방식으로 VM 인벤토리 및 활용도 수집 ▸ Agentless collector — 각 VM에 에이전트 설치 불필요, ESXi 하이퍼바이저에만 배포 ▸ AWS Migration Hub — 마이그레이션 계획 및 추적 중앙화 【정답 포인트】 ▸ "최소 운영 오버헤드" → 에이전트 없는 방식이 수천 개 VM에 가장 효율적 ▸ "정확한 인벤토리" → Migration Evaluator는 CPU, 메모리, 네트워크, 스토리지 등 모든 메트릭 수집 ▸ ESXi 하이퍼바이저에만 배포 → 각 VM마다 설정 불필요 ▸ 비활성 서버 식별 가능 → 활용도 데이터로 마이그레이션 대상 최적화 【오답 체크】 (A) Patch Manager는 패치 관리용이지 마이그레이션 평가용이 아님. Migration Evaluator는 Systems Manager 통합이 아님 (B) 수동 .csv 내보내기는 오버헤드 많고 부정확함. SMS는 물리 서버용이지 VMware용 도구가 아님 (D) Application Migration Service Agent는 각 VM에 설치 필요 → 오버헤드 증가. Redshift는 분석용이지 인벤토리 수집용이 아님 【시험 포인트】 Migration Evaluator의 핵심은 "agentless"로 대규모 VM 환경의 인벤토리를 신속하게 수집하는 것. 하이퍼바이저 레벨의 읽기만으로 충분하므로 수천 개 VM 환경에 최적화됨.

해설

【핵심 용어】 ▸ 예약된 동시성(Reserved Concurrency) — Lambda 함수의 동시 실행 개수 제한 ▸ SQS — 비동기 메시지 큐로 요청 완충 ▸ 연결 풀(Connection Pool) 문제 — 온프레미스 DB의 제한된 동시 연결 【정답 포인트】 ▸ "제한된 동시 연결" → SQS로 요청 완충하여 Lambda가 제어된 속도로 DB 접근 ▸ "예약된 동시성" → Lambda 함수의 최대 동시 실행 수 = DB 연결 수로 제한 ▸ "마이크로서비스는 계속 작동" → SQS는 메시지 저장하여 처리 지연 가능 ▸ Direct Connect 유지 → 온프레미스 DB와의 연결 구조 변경 불필요 【오답 체크】 (B) Aurora로 마이그레이션은 "온프레미스 SQL 데이터베이스"를 버리는 것 → 요구사항 불부합. DataSync는 시간이 걸림 (C) RDS Proxy는 AWS RDS 데이터베이스용이지 온프레미스 DB용이 아님. 온프레미스 SQL DB에 RDS Proxy 사용 불가 (D) SNS는 메시징 서비스이지 큐가 아님. SNS 알림은 Lambda 중복 호출 가능성 있음. 동시성 제어 메커니즘 없음 【시험 포인트】 Lambda 동시성 제어와 SQS 완충의 조합이 온프레미스 DB 연결 풀 문제의 표준 솔루션. 예약된 동시성으로 DB 연결 수를 초과하지 않으면서, SQS로 요청 급증을 처리.

해설

【핵심 용어】 ▸ Amazon Managed Grafana — AWS에서 관리하는 Grafana 서비스 (완전 관리형) ▸ 대시보드 호환성 — 기존 Grafana 대시보드를 그대로 이전 가능 ▸ CloudWatch 데이터 소스 — Grafana에서 CloudWatch 메트릭 직접 시각화 【정답 포인트】 ▸ "대시보드 보존" → Managed Grafana는 기존 대시보드 JSON export/import 지원 ▸ "최소 운영 오버헤드" → AWS가 Grafana 인프라 관리 (패치, 업데이트, HA) ▸ "높은 가용성" → Managed Grafana는 기본적으로 다중 AZ 배포 ▸ "10분 이내 복구" → Managed 서비스이므로 자동 failover 지원 ▸ CloudWatch 통합 → 대시보드에서 CloudWatch 메트릭 직접 사용 【오답 체크】 (A) CloudWatch 대시보드로 마이그레이션 → "대시보드를 다시 만든다" = 높은 운영 오버헤드. 기존 대시보드 일부는 CloudWatch에서 지원 불가능할 수 있음 (C) Auto Scaling 그룹 + EFS → 여전히 Grafana 인스턴스를 직접 관리해야 함. 패치, 업데이트, 모니터링 필요 → 오버헤드 증가 (D) AWS Backup 복원 → RTO 10분 이내 달성 어려움. 복원 완료 후 재시작, 대시보드 로드 등 시간 소요 【시험 포인트】 "최소 운영 오버헤드"와 "기존 대시보드 보존" 두 요구사항 모두 충족하려면 완전 관리형 서비스 필수. Amazon Managed Grafana는 AWS의 공식 Grafana 호스팅 서비스로 모든 운영 복잡성 제거.

해설

【핵심 용어】 ▸ AWS Secrets Manager — 데이터베이스 자격증명 저장 및 자동 교체 기능 ▸ Amazon RDS for Oracle — AWS에서 관리하는 Oracle 데이터베이스 ▸ 자동 암호 교체 — Secrets Manager의 네이티브 rotation 기능 【정답 포인트】 ▸ "Oracle DB 인스턴스" → RDS for Oracle이 최적 선택 (완전 관리형) ▸ "최소 운영 오버헤드" → RDS 자체 관리 + Secrets Manager 자동 rotation ▸ "매년 교체" → Secrets Manager에서 rotation schedule 설정 (자동화) ▸ "자격증명 보안" → Secrets Manager는 암호화 및 접근 제어 제공 ▸ "Oracle 호환성" → RDS for Oracle은 온프레미스 Oracle과 호환성 높음 【오답 체크】 (A) DynamoDB로 변환 → "고객 거래 데이터베이스" = 관계형 데이터 필요. DynamoDB는 NoSQL로 부적합. SCT로 Oracle→DynamoDB 변환은 복잡하고 스키마 변경 필요 (C) EC2로 마이그레이션 → 여전히 Oracle 인스턴스 직접 관리 필요 (패치, 백업, HA). "최소 운영 오버헤드" 미충족 (D) Neptune으로 변환 → 그래프 데이터베이스로 거래 데이터 구조 부적합. 스키마 변환 복잡함 【시험 포인트】 RDS for Oracle + Secrets Manager 자동 rotation은 데이터베이스 암호 관리의 표준 솔루션. RDS는 Oracle 라이선스, 패치, 백업을 모두 관리하므로 "최소 운영 오버헤드" 달성.

해설

【핵심 용어】 ▸ VPC 공유 — AWS Resource Access Manager로 다중 계정 간 리소스 공유 ▸ Site-to-Site VPN — 인터넷 기반 연결 (낮은 비용) ▸ Transit Gateway — 중앙 라우팅 허브 (다중 VPC/계정 관리) ▸ Direct Connect — 전용 네트워크 연결 (높은 비용) 【정답 포인트】 ▸ "다중 팀" + "공유 리소스" → Resource Access Manager로 중앙 관리 ▸ "50Mbps 미만" → Site-to-Site VPN 충분 (비용 효율적) ▸ "B: 공유 서비스 계정" → 하나의 VPC에 모든 서브넷 생성, 여러 계정이 공유 ▸ "D: Site-to-Site VPN" → 50Mbps 저대역폭이므로 VPN으로 충분 ▸ Transit Gateway는 필요 없음 → 단일 리전, 한 번의 VPN 연결로 충분 【오답 체크】 (A) 각 계정마다 VPC 배포 → 여러 개의 온프레미스 연결 필요 (비용 증가) (C) Transit Gateway + Site-to-Site VPN → 오버엔지니어링. 단일 VPC 공유로 충분할 때 \Transit Gateway 추가 비용 발생 (E) Direct Connect → 50Mbps 저대역폭에 불필요하게 높은 비용. AWS Direct Connect 연결 비용은 월 고정비 + 데이터 전송료로 VPN보다 훨씬 비쌈 【시험 포인트】 비용 효율성 + 다중 계정 요구사항의 조합 → B(VPC 공유) + D(Site-to-Site VPN) = 중앙화된 VPC를 여러 계정이 공유하면서 낮은 대역폭은 VPN으로 연결. Transit Gateway와 Direct Connect는 모두 오버스펙.

해설

【핵심 용어】 ▸ AWS Network Firewall — 관리형 방화벽 서비스 (25Gbps 처리 가능) ▸ Firewall endpoints — 각 AZ의 Firewall 진입점 ▸ 중앙화된 아웃바운드 필터링 — 모든 트래픽을 중앙 인터넷 이그레스 VPC로 라우팅 ▸ Transit Gateway — 100개 계정의 아웃바운드 트래픽을 중앙으로 수렴 【정답 포인트】 ▸ "중앙 관리 규칙 기반 필터링" → Network Firewall이 최적 (완전 관리형) ▸ "100개 이상 계정" → 각 계정마다 방화벽 설치 불가능 (관리 오버헤드 극대) ▸ "25Gbps 최대 부하" → Network Firewall은 25Gbps 처리 가능 (스펙 정확히 일치) ▸ "각 AZ에 엔드포인트" → 고가용성 및 분산 처리 ▸ "새 VPC" + "Transit Gateway" → 모든 계정의 트래픽을 중앙 인터넷 이그레스로 수렴 【오답 체크】 (A) EC2 기반 프록시 → 25Gbps 처리하려면 고비용의 대규모 Auto Scaling 그룹 필요. 관리 복잡도 높음. 신뢰성 떨어짐 (C) 각 계정마다 Firewall → 100개 계정 = 100개 Firewall 인스턴스. 중앙 관리 불가능 → "중앙 관리 규칙" 요구사항 위배 (D) 각 계정마다 EC2 프록시 → (C) 의 오류와 동일. 중앙화 불가능. 관리 오버헤드 극대. 비용 증가 【시험 포인트】 Network Firewall은 AWS가 관리하는 완전 관리형 방화벽으로 대역폭 처리능력과 중앙화된 정책 관리에 최적화됨. Transit Gateway 아키텍처에서 중앙 인터넷 이그레스 VPC에 배포하여 모든 아웃바운드 트래픽 필터링.

해설

【핵심 용어】 ▸ AWS WAF — 웹 애플리케이션 방화벽 (공통 취약점 필터링) ▸ AWS Managed Rules — AWS가 관리하는 OWASP Top 10 등 공격 방지 규칙 ▸ Kinesis Data Firehose — 거부된 요청 로그를 제3자 애플리케이션으로 전송 ▸ Multi-AZ Auto Scaling — 높은 가용성 【정답 포인트】 ▸ "공통 취약점 공격 필터" → AWS WAF + AWS Managed Rules (OWASP Top 10 커버) ▸ "거부된 요청 제3자 전송" → Kinesis Firehose로 WAF 로그 자동 전송 ▸ "높은 가용성" → Multi-AZ Auto Scaling 그룹 ▸ "인바운드 요청 필터" → WAF를 ALB에 직접 연결 ▸ AWS Managed Rules 필수 → 공통 취약점 방지의 최선의 방법 【오답 체크】 (A) Amazon Inspector는 EC2 인스턴스의 취약점 평가용이지 WAF가 아님. 인바운드 요청 필터링에 부적합 (B) CloudWatch Logs로 로깅 → Kinesis Firehose처럼 직접 제3자 애플리케이션 연결 불가능. Lambda를 거쳐야 하므로 복잡함. AWS Managed Rules 없음 (C) Single AZ만 있음 → 높은 가용성 요구사항 미충족 【시험 포인트】 공통 취약점 방어 → AWS WAF + AWS Managed Rules. 거부 로그 제3자 전송 → Kinesis Firehose (가장 효율적). 높은 가용성 → Multi-AZ Auto Scaling. 세 요구사항 모두 충족하는 것은 D만 가능.

해설

【핵심 용어】 ▸ VPC 엔드포인트 — VPC 내에서 AWS 서비스에 프라이빗 접근 ▸ 인터페이스 엔드포인트 — API Gateway용 엔드포인트 타입 ▸ 엔드포인트 정책 + 리소스 정책 — 이중 보안 (VPC 엔드포인트만 허용) ▸ 프라이빗 API — 공개 인터넷 액세스 차단 【정답 포인트】 ▸ "공개 인터넷 액세스 불가" → VPC 엔드포인트로 프라이빗 연결 ▸ "독점 데이터 공개 인터넷 금지" → VPC 엔드포인트는 AWS 내부 네트워크 사용 ▸ "특정 API만 액세스" → 엔드포인트 정책으로 제어 ▸ "프라이빗 엔드포인트" → API Gateway 엔드포인트 타입을 Private으로 설정 ▸ "리소스 정책" → VPC 엔드포인트에서만의 요청만 허용 【오답 체크】 (A) Site-to-Site VPN → API Gateway와 VPC 간 VPN 불필요. VPC 엔드포인트로 충분 (C) IAM 인증 + Transit Gateway → Transit Gateway는 VPC 간 라우팅용이지 API Gateway 액세스 제어용이 아님. 이미 같은 리전이면 Transit Gateway 불필요 (D) Global Accelerator → 공개 인터넷 가속용이지 프라이빗 액세스 제어용이 아님. API 키만으로는 보안 부족 【시험 포인트】 VPC 엔드포인트 (Interface Endpoint) 는 AWS 서비스에 VPC 내에서 프라이빗 액세스하는 표준 방법. API Gateway의 프라이빗 엔드포인트 + 엔드포인트 정책 + 리소스 정책의 조합으로 "공개 인터넷 액세스 차단" 달성.

해설

【핵심 용어】 ▸ AWS Config — 리소스의 구성 변경 추적 및 규정 준수 평가 ▸ Config Rules — 규정 미준수 상태 감지 ▸ EventBridge/SNS — 변경 이벤트 감지 시 즉시 알림 ▸ CloudTrail vs Config — CloudTrail은 API 로깅, Config는 규정 준수 평가 【정답 포인트】 ▸ "변경 사항 추적" → AWS Config가 리소스 구성 변경 기록 ▸ "규정 미준수 변경 경고" → AWS Config Rules로 EC2 보안 그룹 규정 준수 평가 ▸ "가장 빠른 방법" → AWS Config는 설정만으로 자동 추적, CloudTrail 분석 + Lambda보다 빠름 ▸ SNS 알림 → Config Rules 규정 미준수 시 자동 SNS 알림 ▸ "최소 설정 복잡도" → CloudFormation, SCP, CloudTrail+CloudWatch 보다 간단 【오답 체크】 (A) AWS Organizations + SCP → Organizations은 "규정 미준수 변경 방지" 목적이지 "변경 추적 + 경고" 목적이 아님. SCP는 정책 기반 접근 제어이지 모니터링 도구가 아님 (B) CloudTrail + CloudWatch → CloudTrail은 API 로깅만 함. CloudWatch Logs로 분석하려면 Lambda 함수 별도 작성 필요 → "가장 빠른 방법" 아님 (C) SCP → 정책 기반 제어로 "변경 방지" 목적이지 "변경 추적 + 경고" 목적이 아님. 이미 규정 미준수 변경이 발생했을 때는 추적 불가능 【시험 포인트】 AWS Config는 "변경 추적" + "규정 준수 평가" + "자동 알림"을 한 번에 처리하는 완전한 규정 준수 모니터링 솔루션. EC2 보안 그룹 특정 구성에 대한 규정 준수 규칙을 설정하면 자동으로 위반 감지 및 SNS 알림 발송.

해설

【핵심 용어】 ▸ ReadProvisionedThroughputExceeded — Kinesis 샤드의 읽기 처리량 초과 ▸ Shard — Kinesis 스트림의 처리 단위 (1Mbps 읽기, 1000 records/sec) ▸ Enhanced Fan-Out — 각 소비자 독립적인 처리량 할당 ▸ 지수 백오프 — API throttling 대응 재시도 전략 【정답 포인트】 ▸ (A) 샤드 증가 → 전체 처리량 증가로 throttling 해결의 직접 방법 ▸ (C) 향상된 팬아웃 → 각 소비자가 독립적인 2Mbps 처리량 할당받음. 여러 소비자의 동시 읽기 가능 ▸ (E) 오류 재시도 + 지수 백오프 → 재시도 시 대기 시간 증가로 안정적 복구 【오답 체크】 (B) KPL은 Producer 라이브러리로 데이터 배치 전송 최적화. 하지만 "읽기 throttling" 문제는 Consumer 쪽이므로 효과 없음. 폴링 빈도 조정도 읽기 처리량 문제와 무관 (D) 샤드 감소 → 처리량이 더 줄어들어 throttling 악화 (역효과) (F) 동적 분할 → 온디맨드 billing 모드에서 자동 scaling하지만, 프로비저닝 모드에서는 작동 안 함. 또한 여러 소비자의 동시 읽기 문제는 해결 안 함 【시험 포인트】 Kinesis 읽기 throttling 해결책: (1) 샤드 증가 (처리량↑), (2) 향상된 팬아웃 (소비자별 독립 처리량), (3) 재시도 로직 (일시적 throttling 대응). 세 가지의 조합으로 안정적 해결.