정답 · 해설

해설

【핵심 용어】 ▸ AWS IoT Core — MQTT 프로토콜 기본 지원 ▸ Kinesis Data Firehose — 자동 스케일링 배치 전달 ▸ Kinesis Data Analytics — 스트림 기반 실시간 분석 ▸ 최소 운영 오버헤드 — 완전 관리형 서비스 【정답 포인트】 ▸ IoT Core = MQTT 차량 연결 (마이그레이션 간단) ▸ Firehose = 자동 스케일링 (피크 트래픽 처리) ▸ S3 자동 저장 (원격 측정 데이터) ▸ Data Analytics = 5분 간격 배치 분석 ▸ 관리형 서비스로 운영 부담 최소 【오답 체크】 (A) IoT Greengrass + MSK = 복잡한 설정, 운영 오버헤드 (C) IoT FleetWise는 차량 신호 데이터 전문 (원격 측정 신호), 범용 데이터 처리 아님 (D) Amazon MQ는 메시지 브로커 (데이터 수집 비효율), Lookout for Metrics는 시계열 이상 전용 【시험 포인트】 스마트 차량 MQTT → AWS IoT Core (프로토콜 호환) 자동 스케일링 필요 → Kinesis Firehose 배치 분석 (5분) → Kinesis Data Analytics 최소 운영 = 모두 관리형 서비스

해설

【핵심 용어】 ▸ CodeCommit Trigger — 푸시 이벤트 자동 감지 ▸ Real-time Detection — 즉시 대응 ▸ IAM Credential Disable — 자격증 무효화 ▸ Prevention-First — 사전 차단 전략 【정답 포인트】 ▸ CodeCommit 트리거 = 코드 푸시 시점에 즉시 감지 ▸ Lambda 함수로 자동 검사 (Secrets 라이브러리) ▸ 자격증 발견 → IAM에서 즉시 비활성화 ▸ 사용자 알림 (감사 추적) ▸ 가장 빠른 대응 시간 (리포지토리 커밋 직후) 【오답 체크】 (A) 야간 검사는 지연, Systems Manager는 인스턴스 기반 (B) Lambda 예약 = 주기적이므로 실시간 아님 (C) Macie는 민감 정보 발견에 초점 (자격증 자동 비활성화 불가) 【시험 포인트】 CodeCommit 자격증 노출 = CodeCommit 트리거 + Lambda 조합 Real-time Detection이 핵심 (사전 차단) IAM에서 즉시 비활성화 (피해 최소화)

해설

【핵심 용어】 ▸ S3 Access Point — 정책 기반 VPC 제한 ▸ Interface Endpoint for S3 — 프라이빗 VPC 연결 ▸ VPC-Only Access Point — 공용 인터넷 차단 ▸ Gateway Endpoint — S3에는 부적합 【정답 포인트】 (A) S3 액세스 포인트 ▸ 단일 계정(데이터 레이크 소유 계정)에 액세스 포인트 생성 ▸ VPC 제한으로 특정 애플리케이션만 접근 ▸ 버킷 정책 = AccessPoint 필수 ▸ 최소 권한 + 공용 인터넷 차단 (C) Gateway Endpoint 활용 ▸ 각 애플리케이션 VPC의 게이트웨이 엔드포인트 ▸ 프라이빗 라우팅으로 S3 액세스 ▸ AccessPoint 정책으로 필터링 ▸ 공용 인터넷 우회 【오답 체크】 (B) Interface Endpoint는 S3 액세스 포인트 직접 지원 불충분 (D) 각 계정에 액세스 포인트 = 크로스 계정 복잡성, 불필요 (E) 데이터 레이크 VPC 엔드포인트 = 애플리케이션 VPC 미포함 【시험 포인트】 크로스 계정 프라이빗 S3 액세스 = AccessPoint + Gateway/Interface Endpoint 최소 권한 = 각 애플리케이션별 액세스 포인트 VPC-Only 액세스 = 공용 인터넷 완전 차단

해설

【핵심 용어】 ▸ CloudWatch Logs Subscription — 실시간 스트림 필터 ▸ Kinesis Data Firehose — Splunk 네이티브 통합 ▸ VPC Flow Logs — 네트워크 연결 추적 ▸ Lambda Preprocessing — 로그 이벤트 추출 【정답 포인트】 ▸ Firehose = Splunk 직접 통합 (최소 설정) ▸ CloudWatch Logs Subscription = 실시간 이벤트 스트림 ▸ Lambda 전처리 = 개별 이벤트 추출 (배치 아님) ▸ VPC Flow Logs = DB 연결 추적 ▸ 거의 실시간 전달 (Splunk 분석) 【오답 체크】 (A) S3 주기적 내보내기 = 지연, 실시간 아님 (C) Athena 쿼리 = 배치 처리, 실시간 모니터링 불가 (D) SQL이상 감지는 불필요, Firehose가 더 간단 【시험 포인트】 CloudWatch → Splunk 전달 = Firehose 표준 VPC Flow Logs → 실시간 모니터링 = Subscription Filter 필수 개별 이벤트 처리 = Lambda 전처리 (배치 아님)

해설

【핵심 용어】 ▸ AWS Organizations — 중앙화된 계정 관리 ▸ SCP (Service Control Policy) — 리전 제한 정책 ▸ Cost and Usage Reports — 통합 청구 보고서 ▸ IAM Role Cross-Account — 중앙 계정 접근 【정답 포인트】 (B) AWS Organizations 설정 ▸ 새 관리 계정 생성 ▸ 모든 기능 활성화 (SCP 필수) ▸ 모든 개발 계정 초대 ▸ 중앙화된 거버넌스 기반 (D) 리전 제한 SCP ▸ Deny로 US 외부 차단 (명확한 정책) ▸ 각 OU에 적용 ▸ 기존 리소스도 이후 미지원 (E) 중앙 계정 IAM 역할 ▸ 단일 신원 관리 (재무팀) ▸ Cost Explorer 접근 ▸ 모든 계정 비용 조회 가능 ▸ 수동 로그인 불필요 【오답 체크】 (A) Cost and Usage Reports만으로는 SCP 제한 기능 없음 (C) Allow 정책은 제한적 (Deny가 더 명확) (F) 각 계정 역할 = 분산 관리, 효율성 낮음 【시험 포인트】 AWS Organizations = 다중 계정 거버넌스 필수 SCP Deny 방식 = 리전 제한 표준 Cross-Account IAM Role = 중앙화 비용 추적 Cost and Usage Reports = Organizations 자동 통합

해설

【핵심 용어】 ▸ OrganizationAccountAccessRole — 조직 내 크로스 계정 액세스 역할 ▸ Trust Policy — 역할 가정 권한 정의 ▸ AssumeRole — 다른 계정의 역할 활용 ▸ 읽기 전용 액세스 — 최소 권한 원칙 【정답 포인트】 ▸ 각 멤버 계정에 새 IAM 역할 생성 ▸ 읽기 전용 권한 설정 ▸ 신뢰 정책: 보안 계정 사용자에게 AssumeRole 허용 ▸ 보안팀이 역할을 가정하여 액세스 ▸ OrganizationAccountAccessRole은 템플릿 역할로만 사용 【오답 체크】 (A) 정책(Policy) vs 역할(Role) — 크로스 계정은 역할 필수 (C) 관리 계정 = 멤버 계정 리소스 직접 액세스 불가 (D) AssumeRole은 보안팀 계정 → 멤버 계정이 아님 【시험 포인트】 AWS Organizations 크로스 계정 읽기 전용 패턴: 1. 각 멤버 계정에 역할 생성 2. 신뢰 정책에 보안 계정 명시 3. 보안팀이 AssumeRole 호출 4. 멤버 계정 리소스 읽기 가능

해설

【핵심 용어】 ▸ Transit Gateway — 중앙화된 라우팅 허브 ▸ Hub-and-Spoke — 중앙 Egress VPC를 중심으로 스포크 VPC 연결 ▸ Resource Sharing — 다중 계정/리전 지원 ▸ Transitive Routing — 다단계 라우팅 【정답 포인트】 ▸ Transit Gateway 생성 (중앙 계정) ▸ AWS Resource Sharing으로 다른 계정과 공유 ▸ 모든 Spoke VPC를 TGW에 연결 ▸ 라우팅: Spoke → TGW → Egress NAT → 인터넷 ▸ 수백 개 계정 확장 가능 【오답 체크】 (A) VPC Peering = 메시 토폴로지, 수백 개 연결 불가 (C) 모든 계정에 TGW = 비효율, 중앙화 미달성 (D) PrivateLink = VPC 엔드포인트 서비스용, 라우팅 미지원 【시험 포인트】 다중 계정 Hub-and-Spoke = Transit Gateway + Resource Sharing Egress 중앙화 = NAT 단일 지점 관리 확장성 = TGW로 수백 개 VPC 지원 Transit Routing = TGW의 핵심 기능

해설

【핵심 용어】 ▸ Rate-based rule — 일정 기간 동안 단일 클라이언트로부터 수신한 요청 수를 기반으로 트래픽을 제한 ▸ AWS WAF — Application Load Balancer에 연결 가능한 웹 애플리케이션 방화벽 【정답 포인트】 ▸ IP 주소가 매주 변경 → IP 필터링 불가능 (D 제거) ▸ 약 500개의 서로 다른 IP → rate-based rule이 적합 ▸ Rate-based rule은 IP 변경과 무관하게 요청 빈도 기반으로 차단 가능 ▸ Firewall Manager는 보안 그룹 정책 관리용으로 ALB 직접 보호에 부적합 【오답 체크】 (A) Firewall Manager는 조직 전체의 보안 그룹을 중앙 관리하는 도구로, 개별 ALB 보호에 운영 오버헤드 증가 (C) 고정된 IP 범위 허용은 정당한 사용자 IP도 포함되어야 하는데 정보 부족 (D) IP 주소가 매주 변경되므로 IP 세트 규칙으로는 추적 불가능 【시험 포인트】 WAF rate-based rule은 DDoS 방어와 빈번한 실패 시도 차단에 최적화. IP 변경이 있는 공격 시나리오에서는 IP 필터링보다 rate limiting이 효율적.

해설

【핵심 용어】 ▸ Customer-Owned IP Address — 고객이 소유한 퍼블릭 IP 블록을 AWS에서 사용 가능하게 등록 ▸ AWS Transfer for SFTP — 완전 관리형 SFTP 서비스로 탄력적 IP 할당 가능 ▸ Elastic IP — AWS Transfer for SFTP에 할당되어 고정된 IP 주소 제공 【정답 포인트】 ▸ IP 주소 고정 필수 → 고객 소유 IP 블록을 등록하고 탄력적 IP로 활용 ▸ AWS Transfer for SFTP는 완전 관리형 SFTP 서비스로 운영 오버헤드 최소 ▸ S3 통합으로 스토리지 확장성과 내구성 확보 ▸ 고객 IP 블록 등록(Bring Your Own IP) → 운영 효율성 최고 【오답 체크】 (B) ALB는 HTTP(S) 기반으로 SFTP 프로토콜 미지원, EBS는 확장성 제한 (C) Route 53는 IP 블록 등록 불가, DNS 레코드만 관리 (D) S3 VPC 엔드포인트는 SFTP 프로토콜 미지원 【시험 포인트】 Customer-Owned IP + AWS Transfer for SFTP 조합은 고정 IP 요구사항과 관리형 서비스의 운영 효율성을 동시에 충족하는 최적 솔루션.

해설

【핵심 용어】 ▸ Cluster Placement Group — 인스턴스들을 낮은 지연 시간의 고대역폭 네트워크로 그룹화 ▸ Enhanced Networking — SR-IOV 기술로 높은 처리량과 낮은 지연 시간 제공 ▸ Partition Placement Group — 분산 처리용으로 레플리카 간 물리적 분리 ▸ Spread Placement Group — 최대 가용성을 위해 각각 다른 하드웨어에 배치 【정답 포인트】 ▸ 높은 처리량 + 낮은 지연 시간 → Cluster Placement Group 필수 ▸ Enhanced Networking 지원 인스턴스 유형 필수 (c5, m5, r5, c6, m6, r6 등) ▸ 클러스터 배치 그룹은 단일 AZ 내에서 인스턴스 간 최단 거리 보장 【오답 체크】 (B) Auto Scaling 그룹만으로는 네트워크 최적화 불가, ENI 추가는 지연 시간 개선 미흡 (C) Partition Placement Group은 대규모 분산 처리용으로 지연 시간 최적화 아님 (D) Spread Placement Group은 가용성 최대화로 지연 시간 증가 【시험 포인트】 배치 그룹 선택: Cluster(저지연+고처리량) vs Partition(분산처리) vs Spread(가용성). 고성능 컴퓨팅/HPC 시나리오는 Cluster 배치 그룹이 정석.

해설

【핵심 용어】 ▸ Usage Plan — API Gateway에서 요청 제한(throttling)과 API 키 관리를 제공 ▸ API Key — 합법적인 클라이언트를 식별하고 사용 계획 적용 ▸ WAF Allow List — 신뢰할 수 있는 파트너 IP만 허용 ▸ CloudFront — 캐싱으로 인한 비용 증가 및 불필요한 복잡성 【정답 포인트】 ▸ 6개 파트너 IP만 허용 → WAF로 화이트리스팅 ▸ 일일 5회 이상 요청 정상 범위 → 사용 계획으로 throttling 설정 ▸ API 키로 정당한 클라이언트 식별 및 추적 가능 ▸ CloudFront 제거 → 비용 최소화, 직접 API Gateway 보호 【오답 체크】 (A) OAI는 S3 콘텐츠용으로 API Gateway에 부적합, 과도한 구성 (B) CloudFront 추가로 비용 증가, API 키는 CloudFront 레벨에서 검증 불가 (C) Resource Policy는 request limit 기능 없음, throttling은 사용 계획에서만 제공 【시험 포인트】 API Gateway 보호: WAF(화이트리스팅) + 사용 계획(throttling) + API 키(추적)의 3층 방어. CloudFront는 캐싱 시나리오에서만 추가.

해설

【핵심 용어】 ▸ Database Activity Stream — Aurora가 제공하는 모든 데이터베이스 활동 모니터링 기능 ▸ Kinesis Data Stream — 실시간 데이터 스트림 처리 ▸ Kinesis Data Firehose — 자동 스케일링, S3 전달 자동화 ▸ DMS CDC — 테이블 수준의 데이터 변경만 캡처, 쿼리 활동 미포함 【정답 포인트】 ▸ 모든 데이터 활동 모니터링 → Database Activity Stream 필수 ▸ Activity Stream은 모든 SQL, 권한 변경, 연결 활동 포함 ▸ Kinesis Data Stream으로 실시간 스트림 수신 ▸ Firehose로 자동 S3 전달 및 분석 용이 【오답 체크】 (A) DMS CDC는 테이블 데이터 변경만 추적, 쿼리/권한 활동 모니터링 불가 (B) EventBridge는 Activity Stream 직접 지원 안 함, 복잡한 Lambda 처리 필요 (D) Redshift로 변환하면 원본 활동 데이터 손실, 분석 목적에 부적합 【시험 포인트】 Aurora Activity Stream은 모니터링/감시/규정 준수 목적의 전용 솔루션. DMS CDC와 혼동하지 말 것. Activity Stream → Kinesis → Firehose → S3 파이프라인이 표준.

해설

【핵심 용어】 ▸ r6g.16xlarge — 512GB 메모리, r6g.4xlarge — 128GB 메모리 (1/4 규모) ▸ c6g (컴퓨팅 최적화) vs m6g (범용) vs r6g (메모리 최적화) ▸ Auto Scaling — CPU/메모리 메트릭 기반 동적 스케일링 【정답 포인트】 ▸ 원래 r6g.16xlarge 사용 → 메모리 최적화 인스턴스 계속 필요 ▸ 실제 사용량 = 예상량의 1/4 → 인스턴스 크기 1/4 축소 (r6g.4xlarge) ▸ 메모리 사용률이 스케일링 메트릭 → 메모리 최적화 인스턴스 유지 ▸ 비용 효율적: 같은 r6g 계열에서 다운사이징 → 호환성 유지, 비용 최소 【오답 체크】 (A) c6g는 컴퓨팅 최적화로 메모리 부족 가능, 메모리 메트릭 기반 스케일링에 부적합 (B) m6g 범용은 메모리 임계값 설정 어려움, r6g 비용 대비 이점 없음 (D) r6g.8xlarge는 과도한 크기, 2-6 용량 범위는 12개에서 축소된 수요 대응 부족 【시험 포인트】 AutoScaling 문제에서는 (1)현재 사용률 vs 프로비저닝 비율 분석 → (2)같은 계열 내 적정 크기 선택 → (3)Capacity 범위는 최대 수요+여유. 여기서는 1/4 사용 = 1/4 크기 인스턴스 + 같은 메모리 최적화 계열.

해설

【핵심 용어】 ▸ DynamoDB Accelerator(DAX) — 인메모리 캐시로 반복 읽기 최적화 ▸ On-Demand vs Provisioned — 비용 vs 성능 트레이드오프 ▸ Savings Plans — 프로비저닝 모드의 비용 추가 절감 (1년/3년) ▸ Auto Scaling — 프로비저닝 모드에서 동적 용량 조정 【정답 포인트】 ▸ 매일 일괄 로드(쓰기 버스트) → 프로비저닝 모드에서 온디맨드 요금 낭비 ▸ 제한된 키 반복 조회 → DAX 캐싱으로 극적 비용 절감 ▸ 예측 가능한 패턴(자정 로드) → 프로비저닝 모드 + 자동 스케일링 적합 ▸ Savings Plans로 프로비저닝 모드 비용 추가 절감 (20~40%) 【오답 체크】 (A) ElastiCache는 별도 관리 오버헤드, DAX보다 비효율적 (B) DAX만으로는 쓰기 버스트 비용 미해결, 프로비저닝 모드 전환 필요 (C) Auto Scaling 없으면 버스트 대응 어려움, DAX 캐싱 이점 미활용 【시험 포인트】 DynamoDB 비용 최적화 4단계: (1)읽기 패턴 분석 → DAX 캐싱 (2)쓰기 패턴 분석 → 온디맨드/프로비저닝 선택 (3)프로비저닝 선택 시 → 자동 스케일링 설정 (4)예측 가능한 부하 → Savings Plans 구매. 이 경우 모두 해당.

해설

【핵심 용어】 ▸ Interface Endpoint (PrivateLink) → NLB → EC2 로깅 서비스 경로 ▸ NACL — 서브넷 간 통신 제어 (상태 유지 안 함) ▸ Security Group — 인스턴스 수준 트래픽 제어 (상태 유지) ▸ Traffic Flow — 클라이언트 → 인터페이스 엔드포인트 → NLB → EC2 【정답 포인트】 ▸ (A) NLB ↔ EC2 로깅 서비스 간 NACL/SG 확인: 트래픽이 NLB에서 로깅 EC2로 이동하는 경로 ▸ (C) EC2 로깅 서비스 보안 그룹: NLB 서브넷(또는 NLB SG)에서 온 트래픽 허용 필수 ▸ NACL은 양방향 규칙 필요 (요청+응답), SG도 NLB 사이드에서 필요 【오답 체크】 (B) 인터페이스 엔드포인트 ↔ 로깅 서비스 NACL은 이미 통신 성공했으므로 문제 아님 (PrivateLink 자동 라우팅) (D) "클라이언트"는 인터페이스 엔드포인트의 클라이언트 IP, 직접 로깅 EC2에 도달하지 않음 (E) NLB는 Layer 4 로드 밸런서, 엔드포인트 서브넷 ↔ NLB 간 통신은 NLB가 관리 【시험 포인트】 PrivateLink 흐름: 클라이언트 → 인터페이스 엔드포인트(ENI) → NLB → 타겟 EC2. NACL은 경로상 모든 서브넷(NLB, EC2 로깅), SG는 각 리소스(NLB, EC2)에서 확인. 선택지는 NLB↔EC2 경로에 초점.

해설

【핵심 용어】 ▸ SSE-KMS — AWS KMS 관리 암호화 (요청당 비용 청구) ▸ SSE-S3 — S3 관리 암호화 (추가 비용 없음) ▸ SSE-C — 고객 관리 키 (애플리케이션 코드 수정 필수) ▸ S3 Batch Operations — 기존 객체 대량 복사 【정답 포인트】 ▸ KMS 비용 증가 원인 → SSE-KMS 요청당 비용 ▸ SSE-S3로 변경 → KMS 호출 0건, 비용 대폭 절감 ▸ S3 배치 작업 → 기존 객체 자동 마이그레이션, 운영 간단 ▸ 애플리케이션 코드 변경 불필요 (투명한 암호화) 【오답 체크】 (A) SSE-C는 고객이 모든 요청과 함께 키 제공 필수 → 애플리케이션 코드 수정 필수 (C) CloudHSM은 별도 관리/운영 오버헤드 증가, SSE-S3와 비용 차이 크지 않음 (D) Intelligent-Tiering은 접근 가능한 데이터이므로 스토리지 비용은 절감하지만 KMS 요청 비용은 해결 안 함 【시험 포인트】 S3 암호화 비용 최적화: SSE-KMS(고비용) → SSE-S3(무료) 마이그레이션 시 배치 작업 활용. SSE-C는 애플리케이션 통합 필수 조건만으로는 부적합.

해설

【핵심 용어】 ▸ Lambda Concurrency Limit — 동시 실행 인스턴스 수 제한 ▸ DynamoDB WCU — 쓰기 처리량, 사진 처리 후 상태 저장 시 필요 ▸ SQS Decoupling — Lambda 트리거 레이트 제한으로 버스트 완화 ▸ RCU vs WCU — 읽기 vs 쓰기 성능 【정답 포인트】 ▸ (B) WCU 부족 → 사진 처리 후 상태 저장 시 쓰기 실패 가능성 높음 ▸ (D) SQS 추가 → Lambda 동시성 초과 시 큐에서 관리, 처리 레이트 제어 ▸ SQS는 Lambda를 S3와 완전히 분리하여 버스트 트래픽 완화 ▸ 두 가지 문제 동시 해결: 동시성(SQS) + 쓰기 성능(WCU) 【오답 체크】 (A) RCU는 읽기용, 사진 처리는 주로 쓰기 성능 문제 (C) ElastiCache는 Lambda 함수 내부 처리 성능 개선이지, 동시성/DynamoDB 이슈 미해결 (E) Transfer Acceleration은 업로드 속도이지, Lambda 처리 능력/DynamoDB 성능 미관련 【시험 포인트】 미디어 처리 아키텍처: 대량 업로드 → 버스트 Lambda → DynamoDB 쓰기 병목. SQS(동시성 제어) + WCU 증가(쓰기 처리량)로 2중 해결.

해설

【핵심 용어】 ▸ AWS Amplify — 풀스택 웹/모바일 앱 개발 프레임워크 (개발 가속화) ▸ Amplify Hosting — CloudFront 통합 호스팅 (자동 스케일링) ▸ Application Migration Service — 레거시 물리/가상 머신 마이그레이션 ▸ Refactoring vs Rehosting — 아키텍처 재설계 vs 기존 유지 【정답 포인트】 ▸ "애플리케이션 리팩터링 고려" → 기존 코드 재사용 최소화, 새로 설계 선호 ▸ "애플리케이션 개발 가속화" → Amplify (IDE, 백엔드 자동화) 최적 ▸ 정적 웹사이트 + S3 + Cognito → 운영 오버헤드 최소 (서버리스) ▸ Amplify Hosting + CloudFront → 지역별 배포, 자동 스케일링 【오답 체크】 (A) EC2 + ALB + Auto Scaling = 운영 오버헤드 증가, 전통적 마이그레이션 (B) IAM Identity Center는 SSO/엔터프라이즈 인증용, Cognito가 최종 사용자 인증에 더 적합 (C) AppSync + Lambda는 GraphQL용으로, REST API 요구사항보다 복잡 【시험 포인트】 "가속화" + "리팩터링" + "운영 효율" = 서버리스 + 저코드 플랫폼. Amplify는 개발 생산성 극대화 (IAC, CI/CD 자동화, Cognito 통합). EC2 기반은 "Rehost" 전략.

해설

【핵심 용어】 ▸ CloudWatch Logs Agent — EC2 인스턴스에서 로그를 중앙 저장소로 푸시 ▸ ALB Access Logs — ALB 트래픽 로그만 기록 (애플리케이션 로그 아님) ▸ Auto Scaling Group — 인스턴스 종료 시 로컬 로그 삭제 ▸ Centralized Logging — 인스턴스 수명주기와 무관하게 로그 보존 【정답 포인트】 ▸ 개발팀이 필요한 것: 애플리케이션 로그 (ALB 로그 아님) ▸ 인스턴스 축소 후 로그 접근 → 중앙 저장소 필수 (로컬 디스크 소멸) ▸ CloudWatch Logs는 EC2 생명주기와 독립적 → 장기 보존 가능 ▸ 통합 에이전트 → 메트릭 + 로그 동시 수집 【오답 체크】 (A) ALB 접근 로그는 HTTP(S) 트래픽만 기록, 애플리케이션 stdout/stderr 미포함 (C) 단계 스케일링은 스케일링 정책이지, 로그 보존과 무관 (D) X-Ray는 분산 추적용으로 전체 로그 분석에 부적합 【시험 포인트】 Auto Scaling 환경에서 로그 보존: 로컬 디스크 + 인스턴스 종료 = 로그 손실. CloudWatch Logs 중앙 집중화가 표준 패턴. ALB vs App 로그의 구분 필수.

해설

【핵심 용어】 ▸ CORS (Cross-Origin Resource Sharing) — 다른 도메인의 요청 허용 정책 ▸ API Gateway CORS — HTTP OPTIONS preflight 요청 자동 처리 ▸ S3 CORS — S3에서 직접 호스팅되는 콘텐츠 전용 ▸ CloudFront CORS — 원본 응답 헤더 투명 전달 【정답 포인트】 ▸ 문제 흐름: S3(www.example.com) → CloudFront → API Gateway → Lambda ▸ 브라우저 CORS 검사는 API 응답의 Access-Control-Allow-Origin 필요 ▸ API Gateway가 응답의 최종 관문 → API Gateway CORS 설정 필수 ▸ CloudFront는 원본 헤더만 투명 전달 (추가 설정 불필요) 【오답 체크】 (A) S3 CORS는 S3 직접 호출 시만 필요, API Gateway 거치는 경우 불필요 (B) WAF는 트래픽 필터링 도구, CORS 헤더 생성 불가 (D) Lambda는 API Gateway 뒤에 숨어있음, Lambda 응답 헤더는 API Gateway가 감싸서 전달 【시험 포인트】 CORS 오류 해결 경로: (1)브라우저 요청 원본 확인 (2)요청 대상 서비스 확인 (3)해당 서비스의 CORS 설정. CloudFront 뒤의 API Gateway CORS가 최종 책임자.