정답 · 해설

해설

【핵심 용어】 ▸ CloudFront 서명 URL — 시간 제한 접근 ▸ 주문형 콘텐츠 — 일회 또는 기간 제한 배포 ▸ 프리미엄 고객 인증 — URL 기반 임시 접근 【정답 포인트】 ▸ 서명 URL → 시간 제한으로 주문형 구현 ▸ CloudFront 단계 — S3 전면 배치 ▸ 개인별 접근 제어 → URL 기반 최적 【오답 체크】 (A) S3 서명 쿠키는 CloudFront 미사용 (C) OAC는 S3 프라이빗 접근 (개인 인증 아님) (D) 필드 암호화는 차단 메커니즘 아님 【시험 포인트】 CloudFront 콘텐츠 제한 → 서명 URL ▸ 쿠키 vs URL → URL이 주문형에 최적 ▸ OAC는 S3 무단 접근 방지용

해설

【핵심 용어】 ▸ 할인 공유 — Savings Plan을 조직 전체 사용 ▸ AWS Organizations — 마스터 계정 통합 관리 ▸ 빌링 기본 설정 — Savings Plan 호환 활성화 【정답 포인트】 ▸ A) 마스터 계정 할인 공유 활성화 필수 ▸ E) 조직 구조 생성 (마스터 + 멤버 계정) ▸ 두 단계 → 조직 + 할인 공유 설정 【오답 체크】 (B) 구매 계정 설정은 마스터 아님 (C) AWS RAM은 Savings Plan 공유 불가 (D) 새 계정 생성은 기존 계정 활용 위배 【시험 포인트】 Savings Plan 공유 → Organizations + 할인 공유 ▸ 마스터 계정에서 공유 활성화 필수 ▸ AWS RAM은 공유 리소스용

해설

【핵심 용어】 ▸ 카나리아 배포 — 일부 트래픽만 새 버전으로 ▸ 점진적 롤아웃 — 위험 최소화 ▸ 단일 도메인 — Route 53 재설정 불필요 【정답 포인트】 ▸ 카나리아 단계 → API Gateway 네이티브 기능 ▸ 트래픽 분산 → 점진적 검증 가능 ▸ 프로덕션 승격 → 자동 장애조치 지원 【오답 체크】 (B) YAML 병합은 정의 수정 (배포 전략 아님) (C) JSON 덮어쓰기는 기존 API 삭제 위험 (D) Route 53 변경 → 다운타임 위험 【시험 포인트】 최소 영향 배포 → 카나리아 (단일 API 내) ▸ 새 엔드포인트 생성은 도메인 전환 필요

해설

【핵심 용어】 ▸ 활성-수동 장애 조치 — ALB 상태 실패 시 S3 전환 ▸ Route 53 상태 확인 — ALB 헬스 모니터링 ▸ 최소 변경 — 기존 기본 웹사이트 유지 【정답 포인트】 ▸ 활성-수동 → ALB 우선 (정상 시) ▸ 상태 확인 실패 → S3 오류 페이지 자동 전환 ▸ 수동 대기 → 인프라 오버헤드 최소 【오답 체크】 (A) 지연시간 라우팅 → 성능 최적화 (장애조치 아님) (C) 활성-활성 + EC2는 오버헤드 증가 (D) 다중값은 모든 응답 반환 【시험 포인트】 라우팅 정책: 활성-수동 (failover) vs 활성-활성 ▸ 상태 확인 기반 자동 전환 필수

해설

【핵심 용어】 ▸ VTL (Virtual Tape Library) — 테이프 대체 서비스 ▸ iSCSI 인터페이스 — 기존 백업 앱 호환 ▸ AWS Storage Gateway — 온프레미스-AWS 연동 【정답 포인트】 ▸ 테이프 제거 → VTL 에뮬레이션 활용 ▸ 기존 워크플로우 보존 → iSCSI 인터페이스 ▸ 백업 애플리케이션 수정 불필요 → VTL 투명성 【오답 체크】 (A) NFS는 파일 저장소 (테이프 대체 아님) (B) EFS NFS는 클라우드 파일시스템 (C) EFS iSCSI는 미지원 【시험 포인트】 테이프 백업 → VTL (가상 테이프 라이브러리) ▸ Storage Gateway VTL = 테이프 자동화 대체

해설

【핵심 용어】 ▸ Kinesis Data Firehose — 관리형 스트림 배달 ▸ 자동 확장 — 운영 오버헤드 최소 ▸ S3 저장소 — 배치 처리/보고용 【정답 포인트】 ▸ 대용량 스트리밍 → Firehose 자동 확장 ▸ 거의 실시간 → 초 단위 배달 설정 ▸ 서버리스 → 관리 부담 없음 【오답 체크】 (B) Glue는 배치 ETL (실시간 아님) (C) Lambda는 동시성 제한 (스케일링 제약) (D) DMS는 데이터베이스 마이그레이션용 【시험 포인트】 실시간 스트림 → Firehose 필수 ▸ Kinesis Streams vs Firehose → Stream: 커스텀 처리, Firehose: S3 직배

해설

【핵심 용어】 ▸ NAT 게이트웨이 — 관리형 아웃바운드 게이트웨이 ▸ 프라이빗 서브넷 → 인터넷 접근 (숨겨진 출발지) ▸ 보안 + 운영효율 — 자동 고가용성 【정답 포인트】 ▸ 프라이빗 MySQL → NAT 게이트웨이 경유 ▸ 아웃바운드만 허용 → 외부에서 진입 불가 ▸ 관리형 → 패치/모니터링 자동 【오답 체크】 (A) NAT 인스턴스는 운영 오버헤드 증가 (C) IGW + 프라이빗 = 보안 위반 (D) VGW는 VPN/Direct Connect용 【시험 포인트】 프라이빗 → 인터넷 아웃바운드 → NAT 게이트웨이 ▸ NAT 인스턴스 vs 게이트웨이: 자동화 우위

해설

【핵심 용어】 ▸ Lambda 실행 역할 — 함수 실행 권한 (IAM) ▸ KMS 키 정책 — 암호화 키 접근 제어 ▸ 양방향 권한 — 역할 + 키 정책 필수 【정답 포인트】 ▸ B) 실행 역할 → kms:Decrypt 권한 추가 ▸ D) KMS 키 정책 → 실행 역할 허용 ▸ 양쪽 모두 필요 → 최소 권한 원칙 【오답 체크】 (A) 리소스 정책은 외부 접근용 (C) Lambda 함수 정책은 비표준 위치 (E) 리소스 정책을 KMS에서 허용 불가 【시험 포인트】 KMS 암호화 해제 → IAM (역할) + KMS 정책 ▸ 실행 역할 + 키 정책 양쪽 확인 필수

해설

【핵심 용어】 ▸ 7일 경계 — 고빈도 접근 마감 ▸ Glacier Flexible Retrieval — 6시간 검색 가능 ▸ 장기 보관 비용 최적화 【정답 포인트】 ▸ 초반 7일 → S3 Standard (빈번 접근) ▸ 7일 후 → Glacier (6시간 검색 가능, 저비용) ▸ 몇 년 저장 → Glacier 비용 효과적 【오답 체크】 (B) IA는 50KB 작은 파일에 비용 비효율 (C) Intelligent-Tiering은 크기 작아서 오버헤드 (D) Deep Archive는 6시간 검색 초과 【시험 포인트】 검색 시간 제약 → Glacier Flexible (6h) ▸ Deep Archive (12h) 제외 ▸ 작은 파일 → IA 스토리지 비용 초과

해설

【핵심 용어】 ▸ Compute Savings Plan — 인스턴스 유형/패밀리 변경 가능 ▸ 예약 인스턴스 — 특정 인스턴스 유형 고정 【정답 포인트】 ▸ 2~3개월마다 유형 변경 → 유연성 필요 ▸ Compute Savings Plan은 패밀리 자유롭게 변경 가능 ▸ 1년 약정 + 선결제 없음 = 유연성 + 비용 최적 【오답 체크】 (A) 부분 예약 인스턴스는 특정 유형 고정 (C) All Upfront 예약은 변경 불가 (D) All Upfront 선결제 부담 크고 고정 【시험 포인트】 비용 최적화 + 유연성 조건 → Compute Savings Plan ▸ 선결제 없음 = Savings Plan 시사

해설

【핵심 용어】 ▸ Amazon Macie — S3의 PII/민감정보 자동 탐지 ▸ 멀티리전 — 각 리전별 독립 구성 필요 【정답 포인트】 ▸ Macie는 S3 데이터에서 PII 패턴 자동 감지 ▸ 멀티리전 요구 → 각 리전에 별도 활성화 ▸ 최소 오버헤드 → 관리형 서비스로 자동화 【오답 체크】 (B) Security Hub + Config는 규정 준수 중심 (C) Inspector는 EC2/컨테이너 취약점 분석 (D) GuardDuty는 위협 탐지, PII 탐지 기능 없음 【시험 포인트】 S3 + PII 탐지 조건 → Macie 즉시 선택 ▸ 멀티리전은 각각 구성하되 발견 통합 가능

해설

【핵심 용어】 ▸ SAP — 고메모리 요구 엔터프라이즈 애플리케이션 ▸ 메모리 최적화 인스턴스(R/X) — RAM 집약 워크로드 전담 【정답 포인트】 ▸ "애플리케이션과 데이터베이스 모두 메모리 사용률 높음" → 핵심 증거 ▸ SAP는 인메모리 데이터베이스(HANA) 선호 ▸ 메모리 최적화면 애플리케이션/DB 모두 최적 【오답 체크】 (A) Compute 최적화는 CPU 집약 (SAP 부적합) (B) 스토리지 최적화는 I/O 집약 (메모리 문제 미해결) (D) HPC는 고성능 컴퓨팅/시뮬레이션 전용 【시험 포인트】 "메모리 사용률 높음" 키워드 → 메모리 최적화 패밀리 ▸ SAP/HANA/ERP = 메모리 최적화 필수

해설

【핵심 용어】 ▸ 인터페이스 VPC 엔드포인트 — ENI 생성, 보안 그룹 적용 가능 ▸ 게이트웨이 엔드포인트 — 라우팅 테이블만 수정, S3/DynamoDB만 지원 【정답 포인트】 ▸ SQS → 인터페이스 엔드포인트 필수 (게이트웨이 미지원) ▸ 프라이빗 EC2에서 프라이빗 서브넷 엔드포인트로 직통 연결 ▸ 보안 그룹으로 EC2↔SQS 트래픽 제어 【오답 체크】 (B) 퍼블릭 서브넷 엔드포인트는 프라이빗 EC2 접근 불가 (C) 퍼블릭 + SQS 정책만으로는 라우팅 구성 필요 (D) SQS는 게이트웨이 엔드포인트 미지원 【시험 포인트】 SQS + VPC 보안 = 인터페이스 엔드포인트 + 프라이빗 + 보안 그룹 ▸ 엔드포인트 배치 위치 = EC2와 동일 VPC 서브넷에

해설

【핵심 용어】 ▸ IAM 역할 + 인스턴스 프로필 — 자격증명 노출 없이 EC2에 권한 부여 ▸ 애플리케이션 요구 — 읽기 + 쓰기 권한 필요 【정답 포인트】 ▸ "API 자격 증명 노출하지 않음" → IAM 역할 필수 ▸ "읽고 쓰는 데 필요한 권한" → PutItem, GetItem 권한 포함 ▸ 인스턴스 프로필 = EC2↔IAM 역할 연결 메커니즘 【오답 체크】 (A) 읽기만 → 쓰기 권한 부족 (C) 파라미터 입력 + 액세스키 = 자격증명 노출 (D) 템플릿에서 사용자 생성 + 키 노출 = 최악 【시험 포인트】 CloudFormation + EC2 + DynamoDB = IAM 역할 + 인스턴스 프로필 ▸ 자격증명 보안 원칙 = 하드코딩 절대 금지

해설

【핵심 용어】 ▸ Amazon EMR — 병렬 분산 처리(Spark/Hadoop) 엔진 ▸ Amazon Redshift — 분석용 데이터웨어하우스, 외부 조인 지원 【정답 포인트】 ▸ "병렬 데이터 처리" → EMR (Spark/Hadoop) 최적화 ▸ "Redshift 데이터로 보강" → EMR에서 Redshift 직접 쿼리/조인 가능 ▸ EMR이 처리 + 보강 모두 수행 (일관성 있음) 【오답 체크】 (A) Athena는 SQL 쿼리만, 병렬 처리 능력 약함 (C) Kinesis는 스트림 처리, 배치 보강 비효율 (D) Glue는 메타데이터/카탈로그만 담당 【시험 포인트】 S3 + 병렬 처리 + 외부 데이터 조인 = EMR + Redshift ▸ EMR은 분산 컴퓨팅의 표준 답변 선택지

해설

【핵심 용어】 ▸ VPC 피어링 — 무료, 동일 리전 내 직통 연결 ▸ Transit Gateway — 월 비용, 여러 VPC/온프레미스 복잡 구조용 【정답 포인트】 ▸ "동일 계정 + 동일 리전" → 피어링 조건 만족 ▸ "가장 비용 효율적" → 피어링 무료, TGW는 월 비용 청구 ▸ 500GB 전송 → 피어링 데이터 전송 요금 없음 【오답 체크】 (A) TGW는 4개 이상 VPC나 온프레미스 필요시 과도한 비용 (B) VPN은 암호화 오버헤드, 성능/비용 비효율 (D) Direct Connect는 초기 비용 + 월 비용 높음 【시험 포인트】 "2개 VPC + 같은 계정/리전 + 비용" = VPC 피어링 ▸ 피어링은 "가장 저렴한 연결" 선택지

해설

【핵심 용어】 ▸ 사용자 정의 태그 — 비용 할당 위해 AWS 청구에서 활성화 필수 ▸ 태그 활성화 — 마스터/관리 계정에서 조직 전체 설정 【정답 포인트】 ▸ 제품군별 비용 분석 → 사용자 정의 태그(product-family) 필요 ▸ 멀티 계정 조직 → 마스터 계정에서 한 번만 활성화 ▸ 결제 콘솔에서 사용자 정의 태그 선택 + 마스터 활성화 필수 【오답 체크】 (A) AWS 생성 태그는 비용 할당에 제약 (C) 리소스 그룹은 리소스 조직용, 청구 분석 미지원 (D) 개별 계정에서 활성화 → 마스터 계정만 인정 【시험 포인트】 멀티계정 조직 + 비용 분석 = 마스터에서 태그 활성화 + 청구 콘솔 ▸ 태그 활성화는 "마스터" 키워드 필수

해설

【핵심 용어】 ▸ AWS Control Tower—다중 계정 거버넌스 + 드리프트 자동 감지 및 알림 ▸ 드리프트—OU/정책 변경 감지 【정답 포인트】 ▸ OU 변경 감지→Control Tower 드리프트 기능 정확히 매칭 ▸ "운영 팀에 알림"→드리프트 알림 자동 발송 ▸ "최소 오버헤드"→Control Tower 완전 관리형 서비스 【오답 체크】 (B) Config 집계 규칙은 리소스 규정 준수, OU 구조 변경 감지 미전문 (C) CloudTrail은 API 감시만, 자동 알림 기능 없음 (D) CloudFormation 드리프트는 스택 내부만, OU 미지원 【시험 포인트】 ▸ OU+드리프트+알림=Control Tower 드리프트 알림 조합 ▸ "자동 거버넌스"=Control Tower의 핵심 가치

해설

【핵심 용어】 ▸ DAX(DynamoDB Accelerator)—DynamoDB 전담 인메모리 캐시, 자동 무효화 ▸ 마이크로초 지연—메모리 캐시의 초저지연 달성 【정답 포인트】 ▸ "DynamoDB 지연 시간 최소화"→DAX는 DynamoDB 최적화 캐시 ▸ "최소 운영 오버헤드"→DAX는 자동 캐시 일관성 유지 ▸ 수백만 요청→DAX로 응답 시간 대폭 감소 【오답 체크】 (B) ElastiCache Redis는 DynamoDB 독립, 수동 캐시 관리 필요 (C) Memcached도 캐시 일관성 수동 관리, DAX 만큼 자동화 안됨 (D) Streams+Lambda는 복잡하고 실시간성 보장 어려움 【시험 포인트】 ▸ DynamoDB+캐싱=DAX 우선선택 ▸ DAX는 "최소 관리+최고 성능" 조합

해설

【핵심 용어】 ▸ 게이트웨이 엔드포인트—S3/DynamoDB 무료, 라우팅 테이블로 제어 ▸ 인터페이스 엔드포인트—다른 서비스용, ENI 필수 【정답 포인트】 ▸ DynamoDB→게이트웨이 엔드포인트만 지원 ▸ 게이트웨이 동작→라우팅 테이블 항목 필수 ▸ "인터넷 통과 없음"→엔드포인트+라우팅만으로 충분 【오답 체크】 (C) EC2용 인터페이스 불필요, EC2는 엔드포인트 대상 아님 (D) 게이트웨이는 ENI 생성 안함, 라우팅 테이블만 사용 (E) 게이트웨이는 보안그룹 불필요, 라우팅만 제어 【시험 포인트】 ▸ DynamoDB+VPC 비공개=게이트웨이엔드포인트+라우팅테이블 ▸ 게이트웨이는 "ENI/보안그룹 없음" 특징 암기