정답 · 해설

해설

【핵심 용어】 ▸ Network Load Balancer(NLB) — 정적 IP 지원, Layer 4 로드밸런싱 ▸ ALB-type Target Group — ALB를 NLB의 대상으로 사용 ▸ 경로 기반 라우팅 — ALB에서 처리 (NLB는 전달만) 【정답 포인트】 ▸ NLB는 여러 AZ에서 정적 IP 제공 → 방화벽 허용 목록 가능 ▸ ALB-type 대상 그룹으로 기존 ALB 유지 → 경로 기반 라우팅 보존 ▸ 클라이언트는 NLB IP 사용 → ALB 변경 불필요 ▸ TLS는 ALB에서 계속 종료 【오답 체크】 (A) ALB는 정적 IP 지원 안함 (동적 IP) (C) ALB 삭제 → 경로 기반 라우팅 손실 (D) GWLB는 보안 어플라이언스용 (로드밸런싱 목적 아님) 【시험 포인트】 정적 IP 요구사항 + 경로 기반 라우팅 유지 → NLB + ALB 조합

해설

【핵심 용어】 ▸ AWS Managed Prefix List — CloudFront IP 범위 (동적 관리) ▸ Security Group — ALB 트래픽 필터링 ▸ Origin 보호 — CloudFront만 ALB 액세스 【정답 포인트】 ▸ AWS 관리 접두사 목록 사용 → IP 변경 자동 반영 ▸ 수동 IP 관리 불필요 → 최소 운영 오버헤드 ▸ CloudFront 원본이 자동으로 보호됨 ▸ WAF 규칙 복제 불필요 (단일 위치 관리) 【오답 체크】 (A) WAF 규칙 복제는 오버헤드 증가 (유지보수 부담) (B) WAF만으로는 비CloudFront 트래픽 직접 접근 방지 불가 (D) 고정 IP 범위 → CloudFront IP 변경 시 수동 업데이트 필요 【시험 포인트】 ALB 원본 보호 → 관리 접두사 목록 자동화 → 최소 운영 오버헤드

해설

【핵심 용어】 ▸ AUTH Token — Redis 인증 (암호 기반) ▸ In-Transit Encryption — TLS로 전송 데이터 보호 ▸ Secrets Manager — 민감한 자격증명 관리 (자동 회전) 【정답 포인트】 ▸ AUTH 토큰은 인증에만 사용 (SSL 아님) ▸ Secrets Manager는 credentials 관리 전문 (자동 회전, 감사) ▸ 기존 클러스터에서 설정 가능 (새 클러스터 불필요) ▸ 종단 간 암호화 + 인증 모두 충족 【오답 체크】 (A) Parameter Store는 credentials 관리에 부적절 (C) SSL 인증서는 인증 목적 아님 (암호화만) (D) Parameter Store + SSL 조합 부적절 (AUTH 토큰이 올바른 방식) 【시험 포인트】 Redis 보안 강화 → AUTH 토큰 + 암호화 중 사용 → Secrets Manager

해설

【핵심 용어】 ▸ Attribute-Based Instance Type Selection — 속성(CPU, RAM 등)로 인스턴스 선택 ▸ Spot Instance Diversification — 여러 인스턴스 유형으로 가용성 증가 ▸ 배치 그룹 — 인스턴스 배치 전략 【정답 포인트】 ▸ 단일 인스턴스 유형 → 수급 부족 시 실패 가능성 ▸ 속성 기반 선택 → 유사 사양 여러 유형 자동 선택 ▸ Spot 가용성 향상 → 안정성 증가 ▸ 시작 템플릿 버전으로 관리 → 기존 구성 유지 【오답 체크】 (A) 시작 구성은 구식 (시작 템플릿 권장) (C) 배치 그룹 수 증가는 실패 원인 해결 안함 (D) 더 큰 인스턴스는 비용 증가 (원인 해결 아님) 【시험 포인트】 Spot Instance 안정성 → 속성 기반 다양화 → 시작 템플릿 업데이트

해설

【핵심 용어】 ▸ S3 File Gateway — NFS/SMB로 S3 액세스 (파일 인터페이스) ▸ FSx for Lustre — 고성능 HPC 파일 시스템 (초당 5개 문서는 과도) ▸ 로컬 파일 액세스 — 기존 Linux 애플리케이션 호환성 【정답 포인트】 ▸ File Gateway는 NFS로 로컬 마운트 가능 → 기존 코드 변경 불필요 ▸ S3 투명 백엔드 → 파일 수정 즉시 반영 ▸ 캐싱 → 로컬 성능 최적화 ▸ 최소 노력 — 애플리케이션 수정 불필요 ▸ 30분 내 공개 가능 → RefreshCache로 동기화 【오답 체크】 (A) Lambda 마이그레이션 복잡 (모든 코드 재작성) (C) FSx for Lustre는 HPC용 (과도한 비용, 설정 복잡) (D) DataSync는 일방향 동기화 (양방향 파일 수정 미지원) 【시험 포인트】 기존 파일 인터페이스 유지 → S3 File Gateway 선택

해설

【핵심 용어】 ▸ EventBridge — 이벤트 기반 아키텍처 (마이크로서비스 간 통신) ▸ 즉시성 — 동기 호출 가능 ▸ Loose Coupling — 서비스 간 독립성 【정답 포인트】 ▸ EventBridge 이벤트 버스 → 중앙화된 이벤트 채널 ▸ 여러 구독자 지원 → 모든 마이크로서비스에 즉시 전달 ▸ 이벤트 패턴 매칭 → 선택적 구독 가능 ▸ 즉시 데이터 삭제 → 동기 호출로 보장 ▸ 확장성 → 마이크로서비스 추가 용이 【오답 체크】 (A) DynamoDB Streams → Lambda → SQS는 비동기 (즉시성 보장 안함) (B) SNS는 DynamoDB 이벤트 직접 지원 안함 (DynamoDB Streams 필요) (D) SQS 이벤트 필터는 미지원 (메시지 필터링만 가능) 【시험 포인트】 마이크로서비스 간 즉시 이벤트 전파 → EventBridge 선택

해설

【핵심 용어】 ▸ Global Accelerator — 정적 IP 제공 (다중 리전) ▸ WAF 호환성 — CloudFront/ALB와 함께 작동 ▸ Elastic IP — ALB에 직접 할당 불가 【정답 포인트】 ▸ Global Accelerator는 정적 IP 제공 → 고객에게 안정적 ▸ ALB 앞에 배치 → WAF 기능 유지 ▸ 최소 운영 오버헤드 → 리소스 간단 (ALB 교체 불필요) ▸ 자동 장애조치 및 지역 최적화 【오답 체크】 (A) ALB를 NLB로 교체 → WAF 지원 안함 (또는 재설정 필요) (B) ALB는 정적 IP 할당 불가 (동적 IP만 가능) (D) CloudFront는 DNS 기반 (고정 IP 제공 안함) 【시험 포인트】 고정 IP 제공 + ALB + WAF → Global Accelerator 조합

해설

【핵심 용어】 ▸ AWS Control Tower — 멀티 계정 거버넌스 (guardrails) ▸ Guardrail — 자동 준수 규칙 ▸ OU(Organizational Unit) — 계정 그룹화 【정답 포인트】 ▸ Control Tower 랜딩 존 → 관리 계정에서 생성 (C) ▸ 프로덕션/개발 OU 분리 (C에 포함) ▸ 프로덕션 OU에만 EBS 암호화 가드레일 (F) ▸ Guardrail은 블루프린트/자동 준수 제공 【오답 체크】 (A) CloudFormation StackSets는 수동 배포 (guardrail 아님) (B) 개발자 계정에서 랜딩 존 생성 불가 (관리 계정만 가능) (E) 관리 계정에 가드레일 → 모든 계정에 적용 (프로덕션만 원함) 【시험 포인트】 멀티 계정 거버넌스 → Control Tower 랜딩 존 → OU별 guardrail

해설

【핵심 용어】 ▸ AWS Elastic Disaster Recovery — 자동 장애조치 (분 단위 RTO) ▸ Cross-Region Read Replica — RDS 복제 (자동 장애조치) ▸ Global Accelerator — 최적 지연 라우팅 【정답 포인트】 ▸ Elastic Disaster Recovery → EC2 자동 복제 (RTO 30분 충족) ▸ RDS Cross-Region Read Replica → 자동 승격 (RTO 몇 분, RPO 5분) ▸ Global Accelerator → 지역별 최적 ALB 자동 선택 ▸ DNS 업데이트 → Route 53 failover ▸ 애플리케이션 변경 최소 【오답 체크】 (B) DLM + 백업 복제 → 수동 복구 (RTO 30분 미충족 가능) (C) CloudFront는 CDN (상태 저장 애플리케이션 미지원) (D) DNS 레코드 업데이트 누락 → 자동 장애조치 불완전 【시험 포인트】 자동 장애조치 + RTO/RPO 요구사항 → Disaster Recovery 서비스 선택

해설

【핵심 용어】 ▸ AWS Compute Optimizer — 머신러닝 기반 인스턴스 크기 권장 ▸ CloudWatch Agent — CPU, 메모리, 네트워크 메트릭 수집 ▸ Trusted Advisor — 제한적 권장사항 (Compute Optimizer가 더 정확) 【정답 포인트】 ▸ Compute Optimizer → CPU/메모리/네트워크 종합 분석 ▸ CloudWatch Agent → 메모리 메트릭 수집 (기본 미포함) ▸ 두 가지 조합 → 정확한 크기 조정 가능 ▸ 자동화된 권장사항 (Trusted Advisor 보다 정교함) 【오답 체크】 (A) Support 플랜은 권장사항 생성 안함 (조언 제공만) (B) Trusted Advisor는 CPU만 (메모리 미포함) (E) Savings Plan은 최적화 아님 (비용 할인만) 【시험 포인트】 EC2 크기 조정 최적화 → Compute Optimizer + CloudWatch 메트릭

해설

【핵심 용어】 ▸ CodeCommit — Git 호환 코드 저장소 ▸ EventBridge — 이벤트 기반 트리거 ▸ CodeBuild — 완전 관리형 빌드 서비스 【정답 포인트】 ▸ EventBridge 푸시 이벤트 감지 → 자동 백업 (스케줄 불필요) ▸ CodeBuild로 저장소 복제 → .zip 생성 ▸ 크로스 리전 S3 복사 → 지역 분산 백업 ▸ 변경 발생 시 즉시 백업 → 데이터 손실 최소 【오답 체크】 (A) Elastic Disaster Recovery는 CodeCommit 지원 안함 (B) AWS Backup은 CodeCommit 지원 안함 (EC2, RDS 등만) (D) Step Functions 스케줄은 비효율 (푸시 기반이 낫음) 【시험 포인트】 CodeCommit 백업 → 이벤트 기반 자동화 → EventBridge + CodeBuild

해설

【핵심 용어】 ▸ PrivateLink — 프라이빗 IP로 AWS 서비스/애플리케이션 공유, 인터넷 노출 없음 ▸ 인터페이스 VPC 엔드포인트 — 다른 계정에서 PrivateLink 서비스에 접근 【정답 포인트】 ▸ PrivateLink 기술 → 프라이빗 IP만 사용하며 계정 간 통신 가능 ▸ 엔드포인트 서비스 + 인터페이스 엔드포인트 → 최소 운영 오버헤드 ▸ CIDR 겹침 → 관계없음 (프라이빗 네트워크 격리) 【오답 체크】 (A) VPC 피어링 — CIDR 겹침으로 불가능, NAT는 추가 복잡성 (B) Site-to-Site VPN — 높은 운영 오버헤드, 관리 부담 (D) API Gateway + IAM — 인터넷 기반, 프라이빗 IP 전용 요구사항 미충족 【시험 포인트】 여러 계정 간 프라이빗 통신 → PrivateLink 선택 낮은 운영 오버헤드 → 관리형 서비스 우선

해설

【핵심 용어】 ▸ IAM Access Analyzer — 리소스 공개 여부 검증하는 분석 도구 ▸ Access Analyzer Finding — S3 공개 상태 감지 ▸ EventBridge — Access Analyzer 이벤트를 SNS로 라우팅 【정답 포인트】 ▸ Access Analyzer 분석기 생성 → S3 공개 상태 자동 감지 ▸ EventBridge 'isPublic: true' 필터 → 공개 버킷만 알림 ▸ SNS 대상 → 보안 팀에 즉시 통지 【오답 체크】 (A) S3 이벤트 알림 — isPublic 이벤트 없음 (S3 네이티브 이벤트는 권한 변경만) (C) CloudTrail PutBucketPolicy — 정책 변경 모든 경우 감지, 과도한 알림 (D) AWS Config — 선택적 규칙, Access Analyzer만큼 효율적이지 않음 【시험 포인트】 S3 공개 감지 → Access Analyzer 기본 솔루션 지속적 모니터링 → EventBridge 자동화

해설

【핵심 용어】 ▸ Migration Evaluator — 온프레미스 서버 인벤토리 및 비즈니스 사례 생성 ▸ AWS Migration Hub — 마이그레이션 포트폴리오 중앙 관리 ▸ Application Discovery Service — 애플리케이션 종속성 맵핑 【정답 포인트】 ▸ Migration Evaluator → 비즈니스 사례 및 서버 목록 (미지원 환경 평가) ▸ Migration Hub → 포트폴리오 시각화 ▸ Application Discovery Service → 애플리케이션/데이터베이스 종속성 파악 【오답 체크】 (A) SMS/DMS — 마이그레이션 실행 도구, 평가 목적 아님 (B) Application Migration Service — 에이전트 방식은 최초 검색에 부적합 (D) Control Tower — 랜딩 존 설정 도구, 포트폴리오 평가 아님 【시험 포인트】 문서 부족한 환경 → Migration Evaluator부터 시작 종속성 파악 → Application Discovery Service 필수

해설

【핵심 용어】 ▸ EFS — 다중 가용 영역, 고성능 공유 파일 시스템 ▸ Multi-AZ 마운트 대상 — 여러 노드 간 공유 스토리지 ▸ AWS Backup — 자동 백업 및 보관 관리 【정답 포인트】 ▸ EFS → 여러 파드/인스턴스 간 공유 접근 가능 ▸ 다중 AZ 지원 → 고가용성, 작은 파일에 최적 ▸ AWS Backup → 1년 보관 자동화 【오답 체크】 (B) EBS Multi-Attach — 단일 AZ 제한, 확장성 낮음 (C) S3 — 객체 스토리지, 작은 파일 성능 저하, Lifecycle는 삭제만 (백업 아님) (D) 로컬 스토리지 + 타사 도구 — 운영 오버헤드 높음, 파드 재시작 시 데이터 손실 【시험 포인트】 다중 파드 공유 + 높은 성능 → EFS 선택 1년 백업 → AWS Backup 필수

해설

【핵심 용어】 ▸ Amazon Connect — 관리형 콜센터/IVR 솔루션 ▸ Amazon Pinpoint — SMS/이메일 마케팅 캠페인 서비스 ▸ 자동화된 양방향 경험 — 콜+설문조사 통합 【정답 포인트】 ▸ Amazon Connect → 전화 통화 처리, IVR 구축 (콜센터 교체) ▸ Amazon Pinpoint → 양방향 SMS 설문조사 자동화 ▸ 통합 솔루션 → 낮은 운영 오버헤드 【오답 체크】 (B) SNS — SMS 발송만 가능, 양방향 설문조사 기능 없음 (C) EC2 마이그레이션 — 기존 하드웨어 문제 반복, 운영 부담 증가 (D) Pinpoint만 — 콜센터 기능 없음 (전화 수신 불가) 【시험 포인트】 Connect + Pinpoint = 콜센터 완전 관리형 솔루션 최소 운영 오버헤드 → AWS 네이티브 서비스 결합

해설

【핵심 용어】 ▸ RTO(Recovery Time Objective) — 복구 시간 최소화 ▸ 웜 스탠바이(Warm Standby) — 대부분 미리 구성, 일부만 온디맨드 ▸ Route 53 상태 확인 + CloudWatch → 자동 장애조치 【정답 포인트】 ▸ 사용자 + 연락처 흐름 미리 배포 → RTO 최소 (수동 구성 제거) ▸ 청구된 번호만 온디맨드 → 빠른 추가만 필요 ▸ Route 53 상태 확인 → 자동 감지 및 장애조치 【오답 체크】 (A) 수동 프로비저닝 지시 → RTO 길음, 모든 요소 수동 (B) 사용자만 미리 배포 → 연락처 흐름 배포 시 시간 소요 (C) 흐름만 미리 배포 → 사용자 배포 시 시간 소요, 기존 사용자 설정 유실 【시험 포인트】 가장 빠른 복구 → 가장 많은 사전 배포 병목 최소화 → 청구된 번호만 CloudFormation 이용

해설

【핵심 용어】 ▸ AWS Data Exchange datashare — Redshift 클러스터 간 직접 데이터 공유 ▸ 구독 확인(Subscription Verification) — 고객 신원 검증 ▸ 실시간 데이터 → 최신 Redshift 데이터 자동 반영 【정답 포인트】 ▸ Datashare + Data Exchange 통합 → 직접 Redshift 접근, FTP 제거 ▸ 구독 확인 → 고객 신원 검증 (요구사항) ▸ 최신 데이터 자동 → Redshift 테이블 변경 즉시 반영 ▸ 낮은 운영 오버헤드 → 다운로드/전송 작업 제거 【오답 체크】 (A) API 통합 → 실시간성 및 최신 데이터 보장 약함 (C) S3 주기적 다운로드 → 운영 오버헤드 (스케줄 관리, 동기화) (D) Open Data 공개 → 고객 신원 확인 불가능, 보안 위험 【시험 포인트】 Redshift 데이터 판매 → AWS Data Exchange datashare 표준 신원 확인 필수 → 공개 Data Exchange 불가

해설

【핵심 용어】 ▸ SQS 큐 — 이벤트 버퍼링 및 분리 ▸ Auto Scaling 기반 대기열 깊이 — 동적 확장/축소 ▸ 데드-레터 큐(DLQ) — 실패 메시지 자동 처리 【정답 포인트】 ▸ SQS + EC2 Auto Scaling → ApproximateAgeOfOldestMessage 메트릭으로 자동 확장 ▸ 데드-레터 큐 → 실패한 이벤트 별도 처리 ▸ 높은 확장성 + 오류 처리 모두 충족 【오답 체크】 (A) SNS + Lambda → Lambda 동시성 제한, 확장 제한적, DLQ는 비동기만 (C) DynamoDB 스트림 → 배치 처리 불가, 확장성 낮음 (D) EventBridge → ALB는 확장 메트릭 부적합, 높은 운영 오버헤드 【시험 포인트】 이벤트 버퍼링 필수 → SQS 선택 유연한 확장 → EC2 Auto Scaling이 Queue 깊이 기반으로 동작

해설

【핵심 용어】 ▸ API Gateway + SQS 통합 — 트래픽 스파이크 완충 ▸ HTTP API — REST보다 빠르고 저비용 ▸ Lambda — 자동 확장, 지연 처리 【정답 포인트】 ▸ API Gateway → RESTful API 엔드포인트 제공 ▸ SQS 통합 → API에서 직접 SQS로 메시지 전송 (즉시 응답) ▸ Lambda → 비동기 처리, 자동 확장, 데이터 손실 없음 (SQS 내구성) ▸ 트래픽 급증 → SQS 버퍼링으로 완전 흡수 【오답 체크】 (A) ALB + SQS — ALB는 SQS와 직접 통합 불가 (라우팅만 가능) (C) REST API + EC2 → 수동 스케일링, 높은 복잡성 (D) CloudFront + Kinesis — 즉시 응답 불가 (스트림 전송 지연), 불필요한 캐싱 【시험 포인트】 데이터 손실 방지 + 트래픽 스파이크 → SQS 필수 API 응답성 + 자동 확장 → Lambda 기반 처리