정답 · 해설

해설

【핵심 용어】 ▸ 컴퓨팅 절감 플랜 — 인스턴스 크기/패밀리 변경 자유 ▸ 유연성 — 3년 약정 시 가장 큰 할인 ▸ 초기화 비용 — 미리 결정 불필요 【정답 포인트】 ▸ 변경 유연성 필요 → Compute Savings Plan ▸ 3년 장기 약정 → 최대 할인율 확보 ▸ 인스턴스 패밀리 변경 가능 → CSP 고유의 장점 【오답 체크】 ▸ (B) EC2 Instance Savings Plan는 인스턴스 크기만 변경 가능 ▸ (C) (D) RI는 고정 인스턴스, 변경 시 비용 손실 【시험 포인트】 ▸ 크기 + 패밀리 모두 변경 → Compute Savings Plan ▸ 장기 약정 + 유연성 필요 → CSP 최적 선택

해설

【핵심 용어】 ▸ 프로비저닝 모드 — 사전 할당 용량 ▸ 예측 가능한 워크로드 — 정확한 용량 계획 ▸ 비용 최소화 — 정확한 예상치 필요 【정답 포인트】 ▸ 일정/예측 가능 → 프로비저닝 모드 최적 ▸ 고정 워크로드 → RCU/WCU 예약으로 비용 절감 ▸ 예산 내 유지 → 정확한 용량 계획 【오답 체크】 ▸ (A) Standard-IA는 액세스 빈도 낮은 용도 ▸ (C) 주문형은 변동성 큰 워크로드용, 고비용 ▸ (D) 주문형 + 예약 용량은 비효율적 조합 【시험 포인트】 ▸ 예측 가능 워크로드 → 프로비저닝 모드 ▸ 정확한 용량 추정 → 비용 최적화 달성

해설

【핵심 용어】 ▸ KMS 고객 관리형 키 — 명시적 권한 필요 ▸ 스냅샷 공유 — 키 정책 수정으로 접근성 부여 ▸ 보안 유지 — 암호화 상태로 공유 【정답 포인트】 ▸ KMS 암호화 스냅샷 → 키 정책 수정 필수 ▸ 크로스 계정 공유 → 대상 계정을 정책에 추가 ▸ 보안성 + 편의성 → 암호화된 상태로 전달 【오답 체크】 ▸ (A) 암호화 해제는 보안 위험 ▸ (C) KMS 키 별칭은 권한 관리 불가 ▸ (D) S3 다운로드는 복잡, 보안 노출 증가 【시험 포인트】 ▸ 크로스 계정 KMS 스냅샷 → KMS 정책 수정 ▸ 기밀 데이터 공유 → 암호화 상태 유지

해설

【핵심 용어】 ▸ 다중 AZ — 고가용성 + 자동 복구 ▸ 읽기 복제본 — 보고서 워크로드 분리 ▸ 성능 격리 — 트랜잭션/분석 분리 【정답 포인트】 ▸ HA 요구 → 다중 AZ 배포 (A) ▸ 보고서 성능 → 읽기 복제본 활용 (C) ▸ 두 요구사항 동시 충족 → A + C 조합 【오답 체크】 ▸ (B) 스냅샷 복원은 일회성, 계속 동기화 불가 ▸ (D) RDS Custom은 관리 오버헤드 증가 ▸ (E) RDS Proxy는 연결 풀링, 성능 분리 아님 【시험 포인트】 ▸ HA + 보고 성능 → 다중 AZ + 읽기 복제본 ▸ 읽기 워크로드 분리 → 복제본으로 성능 보호

해설

【핵심 용어】 ▸ Global Accelerator — 글로벌 네트워크 최적화 ▸ UDP 지원 — 게임 프로토콜 네이티브 지원 ▸ 저지연 + 패킷 손실 최소 → Anycast 라우팅 【정답 포인트】 ▸ 8개 리전 게임 배포 → Global Accelerator ▸ UDP 프로토콜 필수 → 네이티브 지원 필요 ▸ 저지연 경로 → 글로벌 가속 엣지 네트워크 【오답 체크】 ▸ (A) Transit Gateway는 네트워크 허브용, 게임에 비최적 ▸ (C) CloudFront는 HTTP/HTTPS, UDP 미지원 ▸ (D) VPC 피어링은 직접 연결, 최적화 경로 없음 【시험 포인트】 ▸ 글로벌 게임 + UDP → Global Accelerator ▸ 멀티 리전 저지연 → Anycast 라우팅 활용

해설

【핵심 용어】 ▸ gp2 EBS — 범용 SSD, 1,000~3,000 IOPS ▸ RDS 다중 AZ — 고가용성 + 자동 복구 ▸ 비용 절감 — io2에서 gp2로 전환 【정답 포인트】 ▸ 1,000 IOPS 수요 → gp2로 충분 (1,000~3,000) ▸ 2배 여유 유지 → gp2 범위 내 가능 ▸ HA + 관리형 → RDS 다중 AZ ▸ 비용 최소화 → io2 대신 gp2 선택 【오답 체크】 ▸ (A) io2는 고성능이지만 비용 높음 ▸ (C) S3는 데이터베이스 대체 불가 ▸ (D) EC2 자관은 운영 부담, HA 불충분 【시험 포인트】 ▸ 워크로드에 맞는 EBS 타입 선택 → gp2 최적 ▸ 비용 + 성능 + HA → RDS 다중 AZ + gp2

해설

【핵심 용어】 ▸ DynamoDB — NoSQL 온디맨드 확장 ▸ 예측 불가능한 트래픽 → 자동 확장 ▸ 서버리스 완성도 → 완전 관리형 데이터층 【정답 포인트】 ▸ 트래픽 예측 불가 → DynamoDB 온디맨드 ▸ 자동 확장 → 트래픽 급증 대응 ▸ 연결 고갈 없음 → HTTP API 기반 접근 【오답 체크】 ▸ (A) 동시성 제한은 가용성 손상 ▸ (B) RDS는 여전히 연결 한계 있음 ▸ (C) 프로비저닝은 비용만 증가 【시험 포인트】 ▸ 예측 불가 워크로드 → DynamoDB 온디맨드 ▸ 서버리스 완성도 → RDS 대신 NoSQL

해설

【핵심 용어】 ▸ DynamoDB — NoSQL 온디맨드 확장 ▸ 예측 불가능한 트래픽 → 자동 확장 ▸ 서버리스 완성도 → 완전 관리형 데이터층 【정답 포인트】 ▸ 트래픽 예측 불가 → DynamoDB 온디맨드 ▸ 자동 확장 → 트래픽 급증 대응 ▸ 연결 고갈 없음 → HTTP API 기반 접근 【오답 체크】 ▸ (A) 동시성 제한은 가용성 손상 ▸ (B) RDS는 여전히 연결 한계 있음 ▸ (C) 프로비저닝은 비용만 증가 【시험 포인트】 ▸ 예측 불가 워크로드 → DynamoDB 온디맨드 ▸ 서버리스 완성도 → RDS 대신 NoSQL

해설

【핵심 용어】 ▸ AWS Batch — 배치 컴퓨팅 관리형 서비스, 대용량 CPU 집약 작업을 EC2에 스케줄링·실행 ▸ AWS Lambda — 서버리스, 최대 실행 15분·메모리 10GB·6 vCPU 한계 (64 vCPU/512GB 불가) ▸ ECS on Fargate — 컨테이너 서버리스이나 대규모 vCPU/메모리 프로비저닝·이미지화 필요 ▸ Amazon Lightsail — 소규모 고정 워크로드용 간편 VPS, 대형 배치엔 부적합 【정답 포인트】 ▸ "64 vCPU + 512 GiB + CPU 집약 배치" → Lambda 리소스 한계 초과, EC2급 인스턴스 필요 ▸ "매시간 배치 + 15분 내 완료 + 최소 운영 오버헤드" → 스케줄·큐·컴퓨팅을 관리형으로 처리하는 AWS Batch on EC2가 최적 【오답 체크】 (A) Lambda는 15분 타임아웃 및 메모리·vCPU 한계로 64 vCPU/512GB 작업 수용 불가. (B) Fargate는 대형 사양 지정과 컨테이너화 작업이 필요해 오버헤드 증가, 초대형 vCPU 제약도 있음. (C) Lightsail은 정형화된 소규모 워크로드용으로 대형 배치·오토스케일 처리에 부적합. 【시험 포인트】 대형 리소스(수십 vCPU) + 정기 배치 → AWS Batch. Lambda는 15분/10GB 한계면 즉시 탈락.

해설

【핵심 용어】 ▸ Standard-IA — 저장 비용 낮음, 즉시 액세스 ▸ 고가용성 + 복원력 — 다중 AZ ▸ 생명주기 정책 — 30일 후 자동 이동 【정답 포인트】 ▸ 즉시 액세스 필요 → Glacier 아님 ▸ 고가용성 필수 → One Zone-IA 아님 (단일 AZ) ▸ 30일 후 저 접근 → Standard-IA 최적 ▸ 비용 최소화 → IA 티어 활용 【오답 체크】 ▸ (A) Glacier는 검색 시간 필요 ▸ (C) One Zone-IA는 가용성 낮음 ▸ (D) 초기 이동은 최소 저장 기간 조건 위반 【시험 포인트】 ▸ 즉시 액세스 + 비용 절감 → Standard-IA ▸ 생명주기 정책 → 액세스 패턴 맞춰 이동

해설

【핵심 용어】 ▸ 정적 파일 — S3 + CloudFront CDN ▸ 동적 코드 — FSx for Windows (Windows 호환) ▸ 고가용성 — 공유 스토리지 필수 【정답 포인트】 ▸ 정적 파일 배포 → S3 + CloudFront (A) ▸ Windows 동적 코드 → FSx for Windows (D) ▸ Windows 인스턴스 → FSx 네이티브 호환성 【오답 체크】 ▸ (B) ElastiCache는 캐싱용, CDN 아님 ▸ (C) EFS는 Linux 기반, Windows 미지원 ▸ (E) EBS는 인스턴스당 탑재, 공유 불가 【시험 포인트】 ▸ 정적/동적 분리 → S3 + 공유 파일시스템 ▸ Windows + 공유 필요 → FSx for Windows

해설

【핵심 용어】 ▸ Lambda@Edge — 엣지에서의 실시간 변환 ▸ 동적 리사이징 — 요청 시 이미지 처리 ▸ User-Agent 기반 — 디바이스별 형식 제공 【정답 포인트】 ▸ 동적 이미지 변환 → Lambda@Edge 필수 ▸ 엣지 처리 → 저지연 + 부하 분산 ▸ 이미지 라이브러리 필요 → Lambda@Edge에 통합 ▸ 오버헤드 최소 → EC2 관리 제외 【오답 체크】 ▸ (A) EC2 자관은 운영 부담 ▸ (B) 정책은 이미지 처리 불가 ▸ (D) 응답 헤더 정책은 변환 기능 없음 【시험 포인트】 ▸ 동적 이미지 처리 → Lambda@Edge ▸ 엣지 컴퓨팅 → 저지연 + 확장성

해설

【핵심 용어】 ▸ 전송 암호화 — HTTPS/TLS + aws:SecureTransport ▸ 저장 암호화 — SSE-KMS (고객 관리형) ▸ 키 관리 — 규정 준수 팀이 제어 【정답 포인트】 ▸ 전송 중 암호화 → SecureTransport 정책 필수 ▸ 저장 중 암호화 → KMS 고객 관리형 키 ▸ 키 관리 필요 → SSE-S3는 AWS 관리, 불충분 ▸ 규정 준수 통제 → KMS 고객 키만 가능 【오답 체크】 ▸ (A) ACM 인증서는 S3에 불필요 ▸ (B) SSE-S3는 AWS 관리, 제어권 없음 ▸ (D) Macie는 데이터 발견용, 암호화 아님 【시험 포인트】 ▸ PHI 보호 + 키 제어 → KMS 고객 키 ▸ 의료 규정 준수 → 전송 + 저장 암호화 필수

해설

【핵심 용어】 ▸ VPC 엔드포인트—인터넷 거치지 않는 통신 ▸ 인터페이스 엔드포인트—API Gateway용 ▸ PrivateLink—프라이빗 연결 【정답 포인트】 ▸ 같은 VPC 내 API 호출→VPC 엔드포인트 필요 ▸ API Gateway→인터페이스 엔드포인트 ▸ 코드 변경 최소→엔드포인트만 추가 ▸ 인터넷 경유→엔드포인트로 직접 통신 【오답 체크】 (A)API 키는 인증용, 경로 변경 안 함 ▸ (C)게이트웨이 엔드포인트는 S3/DynamoDB용 ▸ (D)SQS는 통신 방식 변경 없음 【시험 포인트】 ▸ VPC 내 API 통신→VPC 엔드포인트 ▸ API Gateway→인터페이스 엔드포인트

해설

【핵심 용어】 ▸ DAX—마이크로초 지연 인메모리 캐시 ▸ DynamoDB 테이블 내보내기—자동 S3 내보내기 ▸ Athena—S3 데이터 애드혹 쿼리 【정답 포인트】 ▸ 마이크로초 지연→DynamoDB+DAX ▸ 역사 데이터 쿼리→S3 내보내기+Athena ▸ 운영 오버헤드 최소→자동 내보내기 ▸ 두 요구사항 모두 충족→완전 관리형 【오답 체크】 (A)RDS는 밀리초 단위 지연 ▸ (B)S3는 sub-ms 지연 불가 ▸ (D)Firehose는 복잡, 오버헤드 증가 【시험 포인트】 ▸ 초저지연+분석→DynamoDB+DAX+Athena ▸ 자동 내보내기→관리형 솔루션

해설

【핵심 용어】 ▸ FIFO(First-In-First-Out)—메시지 순서 보장 ▸ 파티션 키—같은 값의 데이터를 단일 파티션에 저장 【정답 포인트】 ▸ B(Kinesis)—파티션 키로 지불 ID 지정 시 동일 ID의 메시지는 같은 샤드로 라우팅되어 순서 보장 ▸ E(SQS FIFO)—메시지 그룹 ID로 지불 ID 사용 시 그룹 내 FIFO 보장 【오답 체크】 (A)DynamoDB는 순서 보장 불가능(비순서 저장소) ▸ (C)Memcached는 캐시로 영속성/순서 보장 없음 ▸ (D)표준 SQS는 순서 보장 안 함 【시험 포인트】순서 보장 필요 시→Kinesis(파티션 키) 또는 SQS FIFO(메시지 그룹) 조합이 정답

해설

【핵심 용어】 ▸ KMS 고객 관리 키—사용자가 제어하는 암호화 키 ▸ 키 정책—특정 보안 주체의 키 사용 권한 제한 【정답 포인트】 ▸ (B)SNS용 KMS 키 적용으로 전송 중 메시지 암호화+인증 직원만 접근 제어 ▸ (D)SQS용 KMS 키 적용으로 저장 데이터 암호화+TLS 조건으로 전송 보안 강화 【오답 체크】 (A)기본 키 정책 사용 시 세분화된 접근 제어 불가능 ▸ (C)주제 정책 조건은 접근 제어 역할(TLS만 확인, 권한 검증 불충분) ▸ (E)IAM 정책은 키 정책이 아니므로 부적절 【시험 포인트】의료 데이터 보안→SNS/SQS 각각 KMS+키 정책 조합이 정답

해설

【핵심 용어】 ▸ PITR(Point-in-Time Restore)—특정 시점으로 복원 ▸ 자동 백업—RDS 기본 기능, 최대 35일 보관 【정답 포인트】 ▸ 자동 백업은 PITR 지원으로 30일 이내 임의 시점(예: 5분 전) 복구 가능 ▸ 트랜잭션 로그 자동 유지로 정확한 시점 복원 제공 【오답 체크】 (A)읽기 복제본은 고가용성용, 복구 목적 아님 ▸ (B)수동 스냅샷은 사후 조치 필요(자동성 부족) ▸ (D)다중 AZ는 재해 복구용, 데이터 복원 기능 없음 【시험 포인트】시간 기준 데이터 복구→RDS 자동 백업+PITR 조합이 정답

해설

【핵심 용어】 ▸ API 사용 계획—특정 사용자에 대한 API 접근 제어 ▸ API 키—사용자 식별 및 할당량 관리 도구 【정답 포인트】 ▸ API 사용 계획으로 구독 고객만 프리미엄 API 엔드포인트 접근 허용 ▸ API 키 할당으로 사용자별 접근 권한 관리 가능(운영 오버헤드 최소) 【오답 체크】 (A)캐싱/제한은 접근 제어 아님(성능 관련만) ▸ (B)WAF는 SQL 주입 같은 공격 방어용, 사용자 인증 기능 아님 ▸ (C)IAM은 AWS 권한 관리용, API 수준 구독 제어 아님 【시험 포인트】API 수준 접근 제어→사용 계획+API 키 조합이 정답

해설

【핵심 용어】 ▸ NLB—UDP 지원 로드 밸런서 ▸ Global Accelerator—지연 시간 기반 라우팅+성능 최적화 【정답 포인트】 ▸ UDP 애플리케이션은 ALB 불가→NLB만 지원 ▸ Global Accelerator는 Route 53보다 성능/가용성 우수(애니캐스트 IP) 【오답 체크】 (B)ALB는 HTTP/HTTPS 전용, UDP 미지원 ▸ (C) (D)CloudFront는 HTTP/HTTPS 콘텐츠 전용, UDP 미지원 【시험 포인트】UDP+온프레미스+글로벌 성능→NLB+Global Accelerator 조합이 정답