정답 · 해설

해설

【핵심 용어】 ▸ Route 53 Inbound Resolver — 온프레미스에서 AWS로 들어오는 DNS 쿼리를 처리하며, 프라이빗 호스팅 영역과 통합됨 ▸ Route 53 Outbound Resolver — AWS에서 온프레미스 DNS로 나가는 쿼리를 포워드할 때 사용 ▸ Transit Gateway — 다중 VPC와 온프레미스를 연결하는 중앙 라우팅 허브 【정답 포인트】 ▸ 모든 VPC가 cloud.example.com을 해석해야 하므로 → 프라이빗 호스팅 영역을 모든 VPC에 연결 필수 ▸ 온프레미스에서 AWS로의 DNS 해석 경로 필요 → Inbound Resolver 사용 (아웃바운드는 역방향 포워딩용) ▸ Direct Connect를 통한 하이브리드 연결 극대화 → 모든 VPC를 Transit Gateway에 연결하여 허브 구조 확보 【오답 체크】 (B) EC2 조건부 포워더는 마네지드 Route 53 리솔버에 비해 운영 부담이 크고 성능이 떨어짐 (C) 아웃바운드 리솔버는 AWS→온프레미스 방향용이며, 프라이빗 호스팅 영역을 모든 VPC에 연결하지 않음 (D) 공유 서비스 VPC만 Transit Gateway에 연결하면 다른 VPC는 cloud.example.com을 해석할 수 없음 【시험 포인트】 하이브리드 DNS 아키텍처 → Route 53 Resolver + Transit Gateway + 프라이빗 호스팅 영역 연결 조합이 최고 성능

해설

【핵심 용어】 ▸ Route 53 Failover Record — Primary 리소스 상태 확인 후 unhealthy면 Secondary로 자동 전환 ▸ Multivalue Answer — 모든 정상 값을 동시에 반환하며 로드 밸런싱이 클라이언트 측에서 발생 ▸ DynamoDB Global Tables — 다중 Region에서 자동으로 복제 및 동기화 【정답 포인트】 ▸ "자동 장애 조치" 요구사항 → Route 53 Failover Record만 자동으로 Primary/Secondary 전환 가능 ▸ Multivalue는 모든 값을 반환하므로 Primary Region 장애 시 여전히 요청이 계속됨 ▸ 대상 상태 모니터링 + Lambda/API Gateway 상태 확인으로 신뢰할 수 있는 자동 조치 구현 【오답 체크】 (A) Edge-optimized API는 여러 Region을 동시에 대상으로 할 수 없으며 자동 장애 조치 미지원 (B) Multivalue는 로드 밸런싱만 수행하며 장애 조치(failover) 개념 없음 (D) Lambda 글로벌 함수는 존재하지 않으며, Multivalue는 자동 장애 조치가 아님 【시험 포인트】 Route 53 라우팅 정책 구분 → Failover(Active-Standby) vs Multivalue(로드밸런싱)

해설

【핵심 용어】 ▸ Deny List SCP — 명시적으로 거부한 작업만 차단하고 나머지는 허용 (기본 거부 아님) ▸ Allow List SCP — 명시적으로 허용한 작업만 가능하고 나머지는 거부 ▸ OU(Organization Unit) — 계정을 계층적으로 그룹화하고 SCP를 선택적으로 적용 【정답 포인트】 ▸ 새 계정은 AWS Config 접근 제한을 받지만 다른 기존 정책은 유지해야 함 → 임시 OU 격리 필수 ▸ 루트 SCP를 Production OU로 이동하면 Onboarding OU는 루트 SCP 미적용 → Config 접근 가능 ▸ 조정 완료 후 계정을 Production으로 이동하면 루트 SCP가 다시 적용됨 → 장기 유지보수 최소화 【오답 체크】 (A) Service Catalog는 SCP 대체가 아니며 모든 계정에 일괄 배포는 비효율적 (B) Onboarding OU의 SCP는 루트 SCP와 결합되어 여전히 거부 제약 작용 가능 (C) Deny List를 Allow List로 전환하면 기존 정책 전체가 변경되어 장기 유지보수 부담 증가 【시험 포인트】 AWS Organizations SCP 전략 → OU 격리 + 임시 허용 규칙 + 루트 정책 재배치

해설

【핵심 용어】 ▸ Aurora Auto Scaling (Read Replicas) — 읽기 전용 인스턴스 수를 자동으로 조정하여 읽기 부하 분산 ▸ Application Load Balancer — L7 레이어에서 작동하며 애플리케이션 수준 라우팅 지원 ▸ Sticky Sessions — 동일 클라이언트 요청을 같은 서버로 라우팅하여 상태 유지 애플리케이션 지원 【정답 포인트】 ▸ 상태 유지 애플리케이션 → Sticky Sessions 필수 (모든 옵션에 있음) ▸ 읽기 부하 확장 → Aurora Writer는 단일이므로 Auto Scaling 불가 → Aurora Replica Auto Scaling 필요 ▸ 애플리케이션 계층은 ALB (Layer 7)로 스티키 세션 + 라운드 로빈으로 효율적 분산 【오답 체크】 (A) NLB는 Layer 4 로드 밸런서로 connection 기반 라우팅만 가능하며 애플리케이션 수준 제어 부족 (B) Aurora Writer Auto Scaling은 불가능 (Writer는 항상 단일) (D) Writer 기반 확장 불가능하고 NLB는 Layer 4만 지원 【시험 포인트】 Aurora 아키텍처 → Reader 확장(Auto Scaling) + ALB 스티키 세션 조합

해설

【핵심 용어】 ▸ CloudFront Function — Edge 로케이션에서 실행되어 요청/응답 헤더 조작 가능 (User-Agent 기반 조건 처리) ▸ Lambda@Edge — 클라우드프론트 이벤트에서 요청/응답 변환 가능하지만 함수 실행 비용 높음 ▸ API Gateway Response Mapping — REST/HTTP API 응답 변환하지만 CloudFront 엣지에서 실행되지 않음 【정답 포인트】 ▸ User-Agent 기반 헤더 제거 → 요청/응답 시점에 조건 처리 필요 ▸ 가장 비용 효율적 + 엣지 실행 → CloudFront Function (Lambda@Edge보다 저비용) ▸ 서버리스 + 전 지역 엣지 기능 → CloudFront + ALB + Lambda 조합이 운영 부담 최소 【오답 체크】 (B) API Gateway 기본 응답으로는 조건부 헤더 제거 불가능 (User-Agent 체크 로직 없음) (C) HTTP API 응답 매핑은 Lambda에서만 실행되므로 엣지 성능 이점 없음 (D) Lambda@Edge는 기능 목표 달성 가능하지만 비용이 CloudFront Function보다 훨씬 높음 【시험 포인트】 CloudFront 기반 응답 변환 → Function (저비용) vs Lambda@Edge (고기능)

해설

【핵심 용어】 ▸ 교차 계정 S3 액세스 — 버킷 정책(리소스 기반) + IAM 정책(보안 주체 기반) 양쪽 필요 ▸ S3 Bucket Policy — 리소스 소유자(계정 A)가 다른 계정 사용자를 명시적으로 허용 ▸ IAM Policy — 사용자 소유 계정(계정 B)에서 해당 사용자에게 권한 부여 【정답 포인트】 ▸ 교차 계정 접근 → 버킷 정책과 IAM 정책 양쪽 모두 필수 (Allow 조건 충족 필요) ▸ 계정 A(C 옵션): Principal을 계정 B의 User_DataProcessor로 지정하는 S3 버킷 정책 ▸ 계정 B(D 옵션): User_DataProcessor에게 S3 GetObject 권한 부여하는 IAM 정책 【오답 체크】 (A) CORS는 브라우저 기반 교차 출처 요청용이며, API/SDK 호출에는 불필요 (B) 부분적으로 정책이 설정되었을 수 있으나 (C) 가 정확한 정책 구성 (E) IAM 정책만으로는 부족하며 버킷 정책도 필수 【시험 포인트】 교차 계정 S3 액세스 → 버킷 정책(Principal) + IAM 정책(Action) 조합

해설

【핵심 용어】 ▸ ECS Fargate — 컨테이너 기반 서버리스 컴퓨팅으로 EC2 관리 불필요 ▸ EKS Fargate — Kubernetes 기반이므로 추가 운영 복잡성 존재 ▸ Lambda Container Image — 15분 실행 제한으로 장기 실행 워크로드 부적합 ▸ Elastic Beanstalk — 자동 확장 지원하지만 컨테이너 네이티브보다는 덜 효율적 【정답 포인트】 ▸ 서버리스 + 컨테이너 → ECS Fargate (EC2 관리 없음) ▸ 예상 부하 범위 알려짐 → Auto Scaling으로 자동 확장 + 운영 부담 최소 ▸ 가장 비용 효율적 → Fargate는 필요한 만큼만 리소스 소비 【오답 체크】 (A) Lambda 동시성 제한은 예상 최대 부하를 정적으로만 처리 가능 (Auto Scaling 없음) (C) EKS는 Kubernetes 관리 오버헤드로 운영 복잡성 증가 (D) Elastic Beanstalk은 서버리스가 아니며 ECS보다 유연성 낮음 【시험 포인트】 서버리스 + 컨테이너 아키텍처 → ECS Fargate + Auto Scaling 조합

해설

【핵심 용어】 ▸ Route 53 Failover Policy — 기본 리소스 상태 확인 후 실패 시 자동 전환 ▸ Route 53 Latency Policy — 모든 리소스가 정상이어야 하므로 하나 실패 시 계속 요청 전송 가능 ▸ RTO 15분 이내 — 자동 조치(Lambda + 상태 확인) 필수 【정답 포인트】 ▸ "자동 장애 조치" → Route 53 Failover Policy만 지원 ▸ "RTO 15분" → CloudWatch 알람(기반부족) vs Route 53 상태 확인(자동 조치) ▸ 읽기 복제본 + Lambda 승격 → 상태 확인이 실패 감지 시 자동 조치 ▸ Latency Policy는 로드 밸런싱만 하며 하나 실패 시 여전히 요청 전송 【오답 체크】 (A) Latency Policy는 자동 장애 조치 미지원 (모든 대상이 정상이어야 함) (C) Active-Active 구성으로 비용 증가 + 수동 스냅샷 RTO 요구사항 미충족 (D) Global Accelerator + Latency 조합도 자동 장애 조치 미지원 【시험 포인트】 자동 장애 조치 아키텍처 → Route 53 Failover + 상태 확인 + Lambda 자동화

해설

【핵심 용어】 ▸ EC2 + Auto Scaling + Load Balancer — 인스턴스 장애 시 자동 복구 및 교체 ▸ RDS Multi-AZ — 동기식 복제로 주 인스턴스 장애 시 자동 장애 조치 (수동 승격 불필요) ▸ ElastiCache Replication Group + Multi-AZ — Redis 싱글 노드 장애 시 자동 장애 조치 【정답 포인트】 ▸ (A) 다중 EC2 + Auto Scaling 최소 2개 → 인스턴스 자동 교체 및 복구 ▸ (D) RDS Multi-AZ → 2개 AZ에서 동기식 복제 + 자동 장애 조치 (RTO 1~2분) ▸ (F) ElastiCache Multi-AZ → 싱글 노드 장애 시 자동으로 다른 AZ 복제본 승격 【오답 체크】 (B) 무제한 모드는 버스트 성능용이며 자동 복구와 무관 (C) 동일 AZ 복제본은 AZ 장애 시 보호 불가 + 수동 승격으로 RTO 길어짐 (E) Auto Scaling 그룹은 ElastiCache와 통합되지 않으며 복제 그룹 + Multi-AZ만 유효 【시험 포인트】 고가용성 아키텍처 → EC2(ALB+ASG) + RDS(Multi-AZ) + ElastiCache(Replication+Multi-AZ)

해설

【핵심 용어】 ▸ CloudFront Custom Error Page — 특정 HTTP 상태 코드(예: 502)에 대해 사용자 정의 응답 반환 ▸ S3 Static Hosting — CloudFront 오류 응답용 사용자 지정 페이지 호스팅 백엔드 ▸ Lambda-based Failover — 복잡한 로직이 필요하지 않으면 불필요한 운영 부담 【정답 포인트】 ▸ CloudFront 레벨에서 502 오류 감지 → 사용자 정의 오류 페이지 반환 (재라우팅 없음) ▸ 운영 부담 최소 → 자동 메커니즘(CloudFront) 사용, Lambda 자동화 불필요 ▸ (A) S3 버킷으로 호스팅 (정적 콘텐츠) + (E) CloudFront 오류 페이지 연결 【오답 체크】 (B) CloudWatch 알람은 CloudFront에서 감지 전 시간 지연 발생 가능 + 운영 복잡성 (C) Route 53 상태 확인은 원본 상태만 확인하며 오류 응답 커스터마이징 불가 (D) Elb.InternalError는 ALB 내부 오류용이며 Lambda 자동화 운영 부담 증가 【시험 포인트】 CloudFront 오류 처리 → Custom Error Page + S3 Static Content 조합

해설

【핵심 용어】 ▸ AWS Resource Access Manager (RAM) — 리소스 소유 계정에서 다른 계정/OU와 VPC 서브넷 공유 ▸ Resource Share — 조직 OU 단위로 서브넷 리소스를 공유하는 메커니즘 ▸ Subnet Sharing — 소유 계정이 네트워크 관리하고 다른 계정이 리소스만 생성 가능 【정답 포인트】 ▸ (B) 관리 계정에서 리소스 공유 활성화 → Organizations 차원의 공유 기능 활성화 ▸ (D) RAM 리소스 공유 + OU 선택 + 서브넷 연결 → 각 계정이 서브넷 내 리소스 생성 가능 ▸ 인프라 계정의 VPC 소유권 유지 + 다른 계정은 서브넷만 사용 가능 【오답 체크】 (A) Transit Gateway는 VPC 간 라우팅용이며 서브넷 공유 메커니즘 아님 (C) VPC 피어링은 네트워크 관리 권한을 각 계정에 부여하므로 요구사항 위배 (E) Prefix List는 라우팅 대상이며 서브넷 공유와 무관 【시험 포인트】 멀티 계정 네트워크 아키텍처 → Organizations + RAM Subnet Sharing

해설

【핵심 용어】 ▸ PrivateLink Interface VPC Endpoint — 서비스 제공자의 엔드포인트 서비스에 프라이빗으로 연결 ▸ 프라이빗 연결 — 인터넷 경유 없이 AWS 백본 네트워크를 통한 안전한 통신 ▸ 최소 권한 원칙 — 필요한 만큼만 보안 그룹으로 트래픽 제어 【정답 포인트】 ▸ 인터넷 경유 금지 + 프라이빗 연결 필수 → PrivateLink Interface Endpoint만 만족 ▸ 제3자 SaaS가 제공하는 엔드포인트 서비스 사용 → 단방향 연결로 보안 강화 ▸ 보안 그룹으로 최소 권한 구현 → 필요한 포트/프로토콜만 허용 【오답 체크】 (B) Site-to-Site VPN은 인터넷 경유 가능성 있음 + 인프라 관리 부담 증가 (C) VPC 피어링은 프라이빗 연결이지만 양 계정이 네트워크 관리 → 확장성 부족 (D) 방향이 역이며 회사가 엔드포인트 서비스를 제공하는 구조 【시험 포인트】 SaaS 통합 아키텍처 → PrivateLink Interface Endpoint + Security Group

해설

【핵심 용어】 ▸ AWS Systems Manager Patch Manager — 온프레미스 + EC2 통합 패칭 관리 ▸ Systems Manager 준수 보고서 — 모든 호스트의 패치 상태를 중앙에서 확인 ▸ Hybrid 환경 지원 — SSM Agent로 온프레미스 서버 통합 관리 가능 【정답 포인트】 ▸ 단일 보고서 요구 → Systems Manager만 온프레미스 + EC2 통합 지원 ▸ 다양한 패칭 도구 사용 중 → Systems Manager Patch Manager로 통합 ▸ Systems Manager Compliance로 준수 상태 레포팅 【오답 체크】 (B) OpsWorks는 Chef/Puppet 기반 구성 관리이며 패칭 도구 통합 부족 (C) EventBridge + Systems Manager는 패칭 예약만 가능하며 Inspector는 취약점 평가용 (D) OpsWorks + X-Ray는 패칭 통합 관리에 부적합 【시험 포인트】 Hybrid 패칭 통합 → AWS Systems Manager Patch Manager + Compliance

해설

【핵심 용어】 ▸ Auto Scaling Lifecycle Hook — 종료 전 일정 시간 인스턴스를 보류하는 메커니즘 ▸ Systems Manager SendCommand — 인스턴스 상태와 무관하게 원격 명령 실행 가능 ▸ CONTINUE 신호 — 라이프사이클 호 완료 후 정상 종료 진행 【정답 포인트】 ▸ (B) Lifecycle Hook → Lambda → Systems Manager SendCommand로 안정적 실행 ▸ SendCommand는 인스턴스가 종료되기 직전에 명령 실행 보장 ▸ CONTINUE 신호로 정상적 라이프사이클 진행 【오답 체크】 (A) ABANDON 신호는 라이프사이클 진행을 정지하므로 인스턴스가 계속 실행되는 문제 발생 (C) 5분 주기로도 누락 가능성 있으며 사용자 데이터는 종료 시점에 실행 불가 (D) SNS는 비동기이므로 메시지 처리 중 인스턴스 종료될 수 있음 【시험 포인트】 Auto Scaling 라이프사이클 관리 → Lifecycle Hook + Lambda + Systems Manager

해설

【핵심 용어】 ▸ Cross-Account Private Hosted Zone Association — 다른 계정의 VPC와 호스팅 영역 연결 ▸ Authorization Creations — 호스팅 영역 소유자가 권한 부여 ▸ Association Request — VPC 소유 계정이 연결 요청 【정답 포인트】 ▸ (C) 계정 A(호스팅 영역 소유)에서 계정 B(VPC 소유) VPC 연결 권한 생성 ▸ (E) 계정 B의 새 VPC를 계정 A 호스팅 영역과 연결 (VPC 소유 계정에서 실행) ▸ 2단계 프로세스: 권한 부여 → 연결 신청 【오답 체크】 (A) RDS 대신 EC2 배포는 아키텍처 변경이며 근본 원인 미해결 (B) /etc/resolv.conf 수동 설정은 부팅 시 초기화되며 임시 해결책 (D) Route 53 계정 간 복제 기능 없음 (직접 연결만 지원) 【시험 포인트】 교차 계정 Route 53 연결 → Authorization + Association 양단계 필수

해설

【핵심 용어】 ▸ EFS 성능 한계 — 동영상 같은 대용량 파일 트래픽에 부적합 (I/O 병목) ▸ S3 + CloudFront — 대용량 콘텐츠 분산 및 엣지 캐싱으로 성능 향상 ▸ 비용 효율성 — S3 저장료 저렴 + CloudFront 엣지 캐싱으로 출력 대역폭 감소 【정답 포인트】 ▸ 트래픽 10배 증가 → EFS I/O 병목 명확 ▸ 동영상은 정적 콘텐츠 → CloudFront + S3 최적 구성 ▸ EFS는 블로그 문서용으로 유지, 동영상만 S3로 분리 【오답 체크】 (A) EFS 최대 I/O도 대규모 동영상 스트리밍 트래픽 감당 불가 (B) Instance Store는 임시 스토리지이며 영속성 부족 + 부팅 오버헤드 (D) ALB를 원본으로 하는 CloudFront는 동적 콘텐츠용이며 비효율적 【시험 포인트】 대용량 미디어 배포 → S3 + CloudFront 아키텍처

해설

【핵심 용어】 ▸ Direct Connect Gateway — 다중 VPC와 온프레미스를 Direct Connect로 연결 ▸ Redundancy — 2개 이상의 Direct Connect 연결로 고가용성 구현 ▸ Scalability — Direct Connect Gateway를 통해 다중 Region 확장 가능 【정답 포인트】 ▸ (A) Direct Connect 게이트웨이로 다중 연결 집계 ▸ 각 연결의 새 VIF를 게이트웨이에 연결 → Region 확장 시 게이트웨이에 연결만 추가 ▸ 기존 VIF 삭제로 단일 경로 집약 【오답 체크】 (B) 두 개의 직접 VPC 연결은 확장성 부족 (다른 Region 추가 시 각각 VIF 필요) (C) Public VIF는 인터넷 라우팅이며 프라이빗 온프레미스 연결 아님 (D) Transit Gateway도 가능하지만 Direct Connect 게이트웨이가 권장 (dedicated 목적) 【시험 포인트】 Direct Connect Redundancy + Multi-Region → Direct Connect Gateway 아키텍처

해설

【핵심 용어】 ▸ S3 Static Hosting — 웹 애플리케이션 호스팅 ▸ S3 Event Notification → SQS — 파일 업로드 이벤트 자동 트리거 ▸ Lambda + Rekognition — 서버리스 비디오 분석 및 분류 ▸ No Third-party Software — Rekognition으로 AI 서비스 통합 【정답 포인트】 ▸ 운영 부담 최소 → EC2 자동 관리 제거 (S3+Lambda) ▸ 정적 콘텐츠 호스팅 → S3가 가장 경제적 ▸ 사용자 정의 소프트웨어 제거 → Rekognition API 사용 ▸ 이벤트 기반 워크플로우 → S3 이벤트 + Lambda 【오답 체크】 (A) ECS는 컨테이너이지만 웹 호스팅에는 S3가 효율적 (B) EFS는 블로그 문서 공유용이며 동영상 저장에는 S3 권장 (D) Elastic Beanstalk은 여전히 EC2 관리 필요 【시험 포인트】 풀 서버리스 아키텍처 → S3 + Lambda + SQS + Rekognition

해설

【핵심 용어】 ▸ AWS SAM (Serverless Application Model) — Lambda 배포 자동화 및 버전 관리 ▸ AWS CodeDeploy — 점진적 트래픽 전환 (Linear, Canary, All-at-once) ▸ Pre/Post Traffic Hooks — 배포 전후 검증 함수 ▸ CloudWatch Alarms — 자동 롤백 트리거 【정답 포인트】 ▸ 자동화된 배포 + 점진적 전환 → CodeDeploy Traffic Shifting ▸ 자동 검증 + 롤백 → Pre/Post Traffic Test Functions + CloudWatch ▸ 시간 단축 + 오류 감지 시간 최소화 【오답 체크】 (A) CloudFormation 변경 세트는 수동 개입 필요 + 점진적 트래픽 전환 미지원 (C) 단순 스크립트는 자동화 부족 + 테스트 후 롤백 실행 (감지 후 시간 소모) (D) API Gateway 원본 변경은 CloudFront 캐시 무효화 필요 + 수동 개입 【시험 포인트】 Serverless 배포 자동화 → AWS SAM + CodeDeploy Traffic Shifting

해설

【핵심 용어】 ▸ S3 One Zone-IA — 단일 AZ에서 낮은 비용으로 저장되는 스토리지 클래스 ▸ S3 Glacier Deep Archive — 가장 저렴한 스토리지이지만 검색까지 12시간 소요 ▸ S3 인터페이스 엔드포인트 — VPC 내부에서만 S3 접근을 가능하게 하는 보안 방식 【정답 포인트】 ▸ 적은 요청 + 속도 무관 → S3 기반 저장소 필요 ▸ 비용 최소화 + 즉시 접근 필요 → S3 One Zone-IA 선택 (Glacier 제외) ▸ EC2 인스턴스 필요 없음 → 운영 오버헤드 증가 ▸ S3 인터페이스 엔드포인트 → VPN 통해 안전하게 접근 가능 【오답 체크】 (B) EFS는 높은 대역폭과 낮은 지연시간이 필요한 워크로드용. 아카이브 데이터 저장과 EC2 인스턴스 유지로 비용이 높음 (C) EBS Cold HDD는 EC2에 연결된 블록 스토리지로, EC2 실행 비용이 계속 발생하여 비효율적 (D) Glacier Deep Archive는 비용이 가장 저렴하지만 검색 시간이 12시간으로 실용적이지 않음 【시험 포인트】 아카이브 접근 빈도 → 스토리지 클래스 선택 / EC2 vs S3 → 운영 복잡도와 비용 고려