정답 · 해설

해설

【핵심 용어】 ▸ EFS — NFS 호환, 다중 AZ, 자동 확장 공유 스토리지 ▸ EBS Multi-Attach — 최대 16개 인스턴스, 단일 AZ만 지원 ▸ Elastic Beanstalk — 자동 확장 및 배포 관리 ▸ Aurora MySQL — RDS보다 고성능 및 안정성 【정답 포인트】 ▸ NFS 호환 필요 → EFS 선택(EBS Multi-Attach는 NFS 아님) ▸ 2~30 인스턴스 확장 → EFS는 무제한 확장 가능 ▸ Elastic Beanstalk + .ebextensions로 EFS 마운트 자동화 ▸ 별도 데이터베이스 → Beanstalk 환경과 독립적 관리 ▸ Aurora MySQL: 자동 백업, 고가용성, 데이터 손실 방지 【오답 체크】 (B) EBS Multi-Attach: 최대 16개 인스턴스만 지원, 30개 확장 불가 (C) 축소 수명 주기 후크로 마운트 → 복잡, EFS 마운트에 부적절 (D) EBS Multi-Attach: 다시 16개 제한, ElastiCache는 데이터베이스 교체 아님 【시험 포인트】 NFS + 대규모 확장 → EFS + Elastic Beanstalk 패턴

해설

【핵심 용어】 ▸ RDS Read Replica — 읽기 전용 복사본, 다른 리전 가능 ▸ Cross-Region Replication(CRR) — S3 객체 자동 복제 ▸ AMI — Amazon Machine Image, 재해 복구 준비 【정답 포인트】 ▸ 재무팀 쿼리 분리 → 읽기 복제본으로 성능 문제 해결 ▸ 읽기 복제본은 비동기 복제 → 데이터 손실 최소(RPO 짧음) ▸ 재해 시 읽기 복제본 승격 → RTO/RPO 만족 ▸ AMI 사전 생성 → 빠른 프론트엔드 복구 ▸ CRR → S3 자동 복제, 별도 Lambda 불필요 ▸ 비용 효율적: 읽기 복제본만 운영 【오답 체크】 (A) DynamoDB 마이그레이션 필요 → 시간/비용 증가, 복잡함 (B) ALB 리전 간 추가 불가 → 별도 ALB 필요한데 명시 안 됨 (D) 시간별 스냅샷 → RPO 1시간, 읽기 복제본(거의 실시간)보다 나쁨 【시험 포인트】 재해 복구 + 성능 개선 → RDS 읽기 복제본 + CRR 조합

해설

【핵심 용어】 ▸ VPC Endpoint Service — AWS 고객에게 프라이빗 액세스 제공 ▸ PrivateLink — 인터넷을 통과하지 않는 비공개 연결 ▸ Network Load Balancer — Layer 4, TCP/UDP 프로토콜 지원 ▸ Direct Connect — 프라이빗 전용선 【정답 포인트】 ▸ "인터넷을 통과할 수 없음" → PrivateLink 필수 ▸ VPC Endpoint Service → 고객사가 별도 VPC에서 PrivateLink로 연결 ▸ TCP 기반 서비스 → Network Load Balancer(Layer 4) ▸ DX를 통한 연결 → PrivateLink 경로 지원 ▸ 고객사도 인터넷 경유 없이 DX 또는 VPN으로 접근 【오답 체크】 (B) ALB: HTTP/HTTPS만 지원, TCP 기반 서비스 제약 (C) IGW: 인터넷 노출 → "인터넷 통과 불가" 위배 (D) NAT: 인터넷 통과 필요 → 요구사항 위배 【시험 포인트】 프라이빗 서비스 제공 + DX → VPC Endpoint Service + NLB

해설

【핵심 용어】 ▸ SCP(Service Control Policy) — Organizations 레벨에서 최상위 권한 제어 ▸ Explicit Deny — "모든 사용자 제외"로 설정한 명확한 거부 ▸ 루트 OU — 조직의 모든 계정에 자동 상속 【정답 포인트】 ▸ 모든 계정에 동일 정책 적용 필요 → SCP 사용 ▸ "관리자만 허용" → 부정 구조(Deny All Except Admin)로 표현 ▸ 루트 OU에 적용 → 모든 계정 즉시 적용, 계정별 작업 불필요 ▸ 개별 계정 액세스 불필요 → Organizations 레벨 정책만 관리 ▸ 운영 오버헤드 최소: 한 번의 SCP 설정 후 자동 상속 【오답 체크】 (A) "allow" 구조 → explicit deny 규칙 우선, 비관리자가 다른 정책으로 IAM 작업 가능 (B) CloudTrail + Lambda → 이벤트 후 거부, 사후 검증, 운영 복잡함 (D) 권한 경계: 개별 역할마다 연결 필요, 모든 계정 접근 필수 【시험 포인트】 Organizations + 모든 계정 제어 → 루트 OU의 Explicit Deny SCP

해설

【핵심 용어】 ▸ Transit Gateway Attachment — 네트워크 간 연결 ▸ AWS RAM(Resource Access Manager) — 조직 간 리소스 공유 ▸ Automatic Acceptance — 연결 자동 승인 【정답 포인트】 ▸ 리소스 자주 삭제/재생성 → 개발팀이 독립적으로 관리해야 함 ▸ RAM으로 Transit Gateway 공유 → 개발 계정이 자체 Attachment 생성 가능 ▸ 자동 수락 활성화 → Attachment 요청 시 자동 승인 ▸ 개발팀이 별도 관리자 승인 없이 자율적으로 연결 재생성 ▸ 운영 오버헤드 최소: 일회성 공유 설정 후 자동화 【오답 체크】 (A) 개발계정에서 별도 Transit Gateway 생성 → 피어링만 하면 됨, 비효율 (C) VPC Endpoint: Transit Gateway 공유가 아님, 다른 용도 (D) EventBridge + Lambda: 수동 개입 필요, 자동화 미흡 【시험 포인트】 Organizations + 리소스 공유 + 자동 관리 → RAM + Transit Gateway

해설

【핵심 용어】 ▸ Migration Evaluator — 비용 분석 및 TCO 보고서 생성 도구 ▸ Agentless Collector — VM에 에이전트 설치 없이 SNMP로 수집 ▸ AWS Migration Hub — 마이그레이션 중앙 관리 【정답 포인트】 ▸ 소프트웨어 설치 불가 → Migration Evaluator의 에이전트리스 수집기 필요 ▸ SNMP 활성화 → 에이전트리스 수집기가 SNMP로 VM 정보 수집 ▸ 별도 EC2에 수집기 배포 → 온프레미스 네트워크 스캔 ▸ TCO 보고서 생성 → Migration Evaluator 전문 도구 ▸ Migration Hub 자동 import → 수집기가 발견 데이터 푸시 【오답 체크】 (A) Application Migration Service: 실제 마이그레이션용, TCO 분석 아님 (C) Migration Hub는 TCO 보고서 생성 기능 없음 → Migration Evaluator 필수 (D) Migration Readiness Assessment: 준비 상태 평가, TCO 도구 아님 【시험 포인트】 SNMP + 에이전트 설치 불가 → Migration Evaluator Agentless Collector

해설

【핵심 용어】 ▸ Route 53 Latency Routing — 클라이언트 지연 시간 최소 리전으로 라우팅 ▸ Failover Routing — 주 리소스 장애 시 보조로 전환 ▸ Evaluate Target Health — ALB 상태 확인 자동 평가 【정답 포인트】 ▸ "가장 가까운 리전 우선" → 지연 시간 기반 라우팅 ▸ 장애 시 다른 리전으로 자동 전환 → Evaluate Target Health로 구현 ▸ Route 53 Latency Alias: 두 리전 ALB 모두 구성 ▸ 상태 확인 + 지연 시간: 가장 가까운 건강한 리전 선택 ▸ 운영 간단: CloudFront 추가 불필요 【오답 체크】 (A) CloudFront: 캐시 기반, 실시간 게임 에셋(빠른 갱신)에 부적절 (B) Failover: 두 리전 모두 접근 가능할 때 "가장 가까운" 선택 불가 (C) CloudFront 2개: 불필요한 복잡성 + 캐시 문제 【시험 포인트】 다중 리전 + 최소 지연 + 자동 장애조치 → Route 53 Latency + Health Check

해설

【핵심 용어】 ▸ Apache Parquet — 컬럼 기반 데이터 형식, 압축률 높음 ▸ Partition — 데이터 분할로 스캔 범위 축소 ▸ Athena Query Performance — Parquet + 파티션으로 획기적 개선 【정답 포인트】 ▸ 성능 개선의 가장 큰 요인 → 파일 형식 및 파티션 구조 ▸ 텍스트 로그(csv) → Parquet: 스토리지 50% 이상 감소 ▸ 시간별 파티션 → Athena가 필요한 시간 범위의 파일만 스캔 ▸ 저장 공간 + 쿼리 성능 동시 개선 ▸ VPC 플로우 로그는 Parquet 지원 가능 【오답 체크】 (A) bzip2 압축: 스토리지 개선 적음, 쿼리 성능 영향 없음 (B) Transfer Acceleration: 업로드 속도만 개선, 쿼리/스토리지 미개선 (D) Athena 작업 그룹: 쿼리 최적화 아님, 기존 데이터 형식 유지 【시험 포인트】 대규모 로그 분석 최적화 → Parquet 형식 + 파티셔닝

해설

【핵심 용어】 ▸ Transit VIF — Virtual Interface, 다중 VPC 및 온프레미스 연결 ▸ BGP Route Propagation — 네트워크 프리픽스 상호 보급 ▸ Direct Connect Gateway — VPC 및 온프레미스 통합 【정답 포인트】 ▸ Transit VIF 통해 VPC 리소스 접근 → 양방향 라우팅 설정 필요 ▸ 온프레미스 → VPC: 온프레미스 프리픽스 보급(BGP) ▸ VPC → 온프레미스: VPC 프리픽스를 Direct Connect Gateway에서 보급 ▸ 두 단계 모두 필요: 완전한 양방향 연결 【오답 체크】 (A) 대역폭 업그레이드: 연결 자체는 가능, 프리픽스 보급 아님 (D) (E) MACsec: 암호화 설정, 라우팅과 무관 【시험 포인트】 Transit VIF + 다중 VPC 연결 → BGP 프리픽스 양방향 보급 필수

해설

【핵심 용어】 ▸ IP Access Control Group — WorkSpaces 레벨 IP 화이트리스트 ▸ WorkSpaces Directory — 중앙 관리 지점 【정답 포인트】 ▸ "회사 지점만" → IP 기반 액세스 제어 ▸ "향후 지점 추가" → 추가 공개 IP 주소만 규칙에 추가 ▸ 중앙 관리: 한 곳의 디렉토리에서 모든 WorkSpaces 제어 ▸ 운영 효율성: IP 주소 변경 시 규칙 업데이트만 필요 ▸ 비용 효율적: 별도 이미지나 인증서 관리 불필요 【오답 체크】 (B) Firewall Manager: 조직/계정 간 정책 관리, WorkSpaces 액세스 제어 아님 (C) 인증서 방식: 디바이스 관리 복잡, 이미지 유지보수 필요 (D) 커스텀 이미지: 각 WorkSpace에 규칙 적용, 관리 복잡, 추가 시 이미지 재배포 【시험 포인트】 WorkSpaces IP 제한 → IP Access Control Group 사용

해설

【핵심 용어】 ▸ Gateway Load Balancer — 방화벽 등 네트워크 어플라이언스용 ▸ GWLB Endpoint Service — PrivateLink로 분산된 방화벽 제공 ▸ Auto Scaling + Launch Template — 자동 확장 및 자동 구성 【정답 포인트】 ▸ (A) Gateway Load Balancer: 방화벽 어플라이언스 전용 로드 밸런서 ▸ (C) Auto Scaling + Launch Template: 자동 확장 + 시작 스크립트 ▸ (F) 중앙 계정 엔드포인트 + 멤버 계정 라우팅: PrivateLink 구성 ▸ 3개 조합: GWLB로 분산 → 멤버가 엔드포인트로 액세스 → 자동 확장 【오답 체크】 (B) NLB: 방화벽 어플라이언스에 부적절, GWLB 필수 (D) Launch Wizard: 자동 구성 미흡, Launch Template이 더 적절 (E) 멤버 계정 엔드포인트: 역방향, 중앙에서만 엔드포인트 필요 【시험 포인트】 방화벽 자동 확장 + PrivateLink 제공 → GWLB + Auto Scaling + Endpoint

해설

【핵심 용어】 ▸ Cross-Region Read Replica — 비동기 복제, RTO 짧음 ▸ Failover Routing — Route 53의 자동 장애 조치 ▸ RTO 15분 / RPO 2시간 — 요구사항 【정답 포인트】 ▸ (A) 읽기 복제본: 거의 실시간 복제 → RPO 만족(~0), RTO 빠름 ▸ (A) Lambda 승격: 자동 장애 조치 → RTO 15분 달성 가능 ▸ (D) Route 53 Failover: 데이터베이스 엔드포인트 자동 전환 ▸ 읽기 복제본 + 자동 라우팅 = 완벽한 다중 리전 HA 【오답 체크】 (B) 스냅샷 복원: RTO 길어짐(15분 내 불가), 수동 작업 (C) 2시간마다 복사: RPO 2시간 충족하지만 RTO는 여전히 길다 (E) 핫 스탠바이 + Lambda 복원: Lambda 복원 시간 → RTO 초과 【시험 포인트】 다중 리전 + RTO/RPO 요구사항 → Read Replica + Failover Routing

해설

【핵심 용어】 ▸ RDS Proxy — 데이터베이스 연결 풀링, 연결 재사용 ▸ Connection Pooling — 새 연결 생성 오버헤드 제거 ▸ Lambda Cold Start — 핸들러 외부 코드 최적화 【정답 포인트】 ▸ "데이터베이스 연결 크게 증가" → 연결 풀링 필요 ▸ RDS Proxy: Lambda 함수마다 새 연결 대신 풀에서 재사용 ▸ CPU 높음 → 연결 생성 오버헤드로 인한 리소스 낭비 ▸ RDS Proxy 하나로 다수의 Lambda가 공유 가능 ▸ 즉각적 효과: 연결 수 제한 + CPU 사용률 감소 【오답 체크】 (A) Lambda 메모리: 컴퓨팅 성능 증가만, 연결 문제 미해결 (B) ElastiCache: 추가 구성 필요, RDS Proxy가 먼저 적용 (D) Lambda 최적화: 개별 함수 개선, 조직 차원 연결 관리 불가 【시험 포인트】 다중 Lambda + DB 연결 폭증 → RDS Proxy로 풀링

해설

【핵심 용어】 ▸ EventBridge — 이벤트 기반 아키텍처의 중심, 거의 실시간 처리 ▸ Aurora Serverless — 자동 확장 데이터베이스, 운영 최소화 ▸ Redshift Serverless — 분석 및 OLAP 전문 엔진 ▸ EKS + Fargate — 마이크로서비스 오케스트레이션 【정답 포인트】 ▸ "이벤트 기반" → EventBridge(중앙 이벤트 라우터) ▸ "서버리스" → Aurora Serverless + Redshift Serverless ▸ "거의 실시간" → EventBridge의 즉시 이벤트 처리 ▸ ETL 주간 배치 제거 → EventBridge로 실시간 이벤트 전달 ▸ 마이크로서비스 → EKS (ECS보다 확장성 높음) ▸ OLAP 분석 → Redshift(데이터 웨어하우스 전문) 【오답 체크】 (A) EC2 데이터베이스 유지 → 서버리스 아님, SQS는 실시간 분석 미지원 (B) EC2 Auto Scaling: 서버리스 아님, SNS는 이벤트 라우팅 약함 (D) AppStream: UI 스트리밍, 데이터 처리 아님, IoT Core 부적절 【시험 포인트】 이벤트 기반 실시간 분석 → EventBridge + Aurora Serverless + Redshift Serverless

해설

【핵심 용어】 ▸ Organization CloudTrail — 조직 레벨 CloudTrail ▸ SCP(Service Control Policy) — 조직 정책으로 트레일 보호 【정답 포인트】 ▸ "조직의 모든 AWS 계정" → Organization CloudTrail(관리 계정에서) ▸ "계정 추가 시 자동" → Organization CloudTrail은 새 계정 자동 추적 ▸ 중앙 관리 계정에서 하나의 트레일만 관리하면 됨 ▸ 모든 계정의 로그가 중앙 S3 버킷에 수집됨 ▸ 운영 효율성: 계정별 설정 불필요, 자동 상속 【오답 체크】 (B) 오답 설명 정정: (A) 가 올바른 답입니다. 조직의 관리 계정 CloudTrail (C) 런북 + State Manager: 수동 작업 여전히 필요, 자동화 불완전 (D) Lambda + EventBridge: 일회성 함수, 새 계정 추가 시 재호출 필요 【시험 포인트】 Organization 레벨 CloudTrail 활성화 → 모든 계정 자동 추적

해설

【핵심 용어】 ▸ Client VPN Endpoint — 원격 사용자를 위한 클라이언트 VPN ▸ AD Connector — 온프레미스 AD DS와 AWS 통합 ▸ MFA Support — AD Connector에서 기본 지원 【정답 포인트】 ▸ "원격 엔지니어" → Client VPN Endpoint(개인 사용자용) ▸ "VPC 비공개 서비스 액세스" → Client VPN으로 VPC 접근 ▸ "AD DS 통합" → AD Connector로 기존 AD 활용 ▸ "MFA 필수" → AD Connector는 MFA 기본 지원 ▸ 엔지니어는 AD 자격증명으로 MFA와 함께 Client VPN 로그인 【오답 체크】 (A) Site-to-Site VPN: 사이트 간 연결용, 개인 원격 사용자 부적절 (C) VPN CloudHub: 여러 온프레미스 사이트 연결, 사용 사례 맞지 않음 (D) WorkLink: 웹 애플리케이션 원격 액세스용, VPC 리소스 직접 액세스 아님 【시험 포인트】 원격 사용자 + AD DS + MFA → Client VPN + AD Connector

해설

【핵심 용어】 ▸ Auto Scaling — 자동으로 리소스를 확장/축소 ▸ Aurora Auto Scaling — 읽기 복제본 자동 확장 ▸ CloudFront — 정적 콘텐츠 글로벌 배포 【정답 포인트】 ▸ (A) 정적 자산 S3+CloudFront: 프론트엔드 성능 최대화, 운영 오버헤드 최소화 ▸ (C) Elastic Beanstalk: 애플리케이션 자동 확장, 배포 간편화 ▸ (E) DMS+Aurora Auto Scaling: 데이터베이스 읽기 성능, 읽기 용량 자동 관리 【오답 체크】 (B) EFS는 공유 스토리지이지만, 정적 자산 제공에는 CloudFront가 더 효율적 (D) 리팩토링이 필요하므로 운영 노력 증대 (F) 단순 용량 확대로는 확장성 제한, 자동 확장 불가 【시험 포인트】 이 문제는 "최대 확장성" + "최소 운영 노력" 요구사항을 동시에 만족하는 조합을 선택하는 문제입니다. 정적 콘텐츠, 애플리케이션, 데이터베이스 각 계층에서 AWS의 관리형 서비스를 활용한 자동 확장 솔루션을 선택해야 합니다.

해설

【핵심 용어】 ▸ Amazon Inspector — EC2 인스턴스, ECR 이미지의 취약점 지속 검사 ▸ Security Hub — 보안 검사 통합 관리 ▸ 운영 오버헤드 — 관리 작업 최소화 【정답 포인트】 ▸ Inspector는 EKS 관리형 노드(EC2 기반)와 ECR 이미지 모두에 대한 자동 취약점 검사 제공 ▸ 설정 간단하고 관리형 서비스로 운영 노력 최소 ▸ ECR push 시 자동 검사로 정책 준수 가능 【오답 체크】 (A) Security Hub는 검사 도구가 아니라 통합 관리 플랫폼 (C) 별도 EC2 인스턴스 관리로 오버헤드 증대 (D) CloudWatch는 모니터링 도구이지 취약점 검사 도구가 아님 【시험 포인트】 이 문제는 "최소 운영 오버헤드"라는 핵심 조건과 "EKS 노드+ECR" 조합 검사를 동시에 충족할 수 있는 서비스를 찾는 것입니다. Inspector는 AWS 관리형 서비스로 자동화된 검사를 제공합니다.

해설

【핵심 용어】 ▸ CloudFront Function — 엣지에서 요청/응답 필터링 ▸ JWT(JSON Web Token) — 암호화된 사용자 인증 정보 ▸ 높은 부하 — 서비스 분리로 독립 스케일링 필요 【정답 포인트】 ▸ CloudFront Function이 JWT를 검사하여 요청을 최상단에서 분기 처리 ▸ 애플리케이션 로직이 아닌 엣지에서 라우팅하므로 애플리케이션 부하 감소 ▸ 별도의 ECS 서비스로 대기실과 티켓팅 각각 독립 스케일링 가능 ▸ ECS 변경만으로 요구사항 충족, EKS 이전 불필요 【오답 체크】 (A) ECS 서비스 분리만으로는 요청이 여전히 애플리케이션으로 라우팅 (B) 불필요한 EKS 마이그레이션으로 복잡성 증가 (D) App Mesh와 mTLS는 과도한 오버헤드 【시험 포인트】 "높은 부하 기간 동안 가장 안정적" 요구사항은 애플리케이션 진입 전에 요청을 필터링해야 함을 의미합니다. CloudFront Function은 엣지에서 처리하므로 오리진 부하를 효과적으로 분산시킵니다.

해설

【핵심 용어】 ▸ 신뢰 정책(Trust Policy) — 어느 보안 주체가 역할을 수임할 수 있는지 정의 ▸ AssumeRole — 다른 계정에서 역할 수임 권한 ▸ 인스턴스 프로필 — EC2가 IAM 역할 사용 【정답 포인트】 ▸ 문제: 자식 계정의 EC2 인스턴스(새 역할)가 부모 계정의 역할을 수임할 수 없음 ▸ 근본 원인: 부모 계정의 역할 신뢰 정책이 자식 계정의 EC2 역할 ARN을 명시하지 않음 ▸ 해결책: 부모 계정에서 신뢰 정책의 대상 역할 ARN 확인 및 수정 ▸ 기존 명령문이 올바른 ARN을 가져야 CrossAccount AssumeRole 가능 【오답 체크】 (B) 루트 보안 주체 추가는 과도한 권한 부여 (C) (D) CloudFormation capability는 IAM 역할 생성 권한과 무관 【시험 포인트】 CrossAccount IAM 역할 수임 문제는 신뢰 정책의 보안 주체(Principal) 설정이 핵심입니다. 자식 계정의 새 역할 ARN이 부모 계정의 신뢰 정책에 정확히 명시되어야 수임 가능합니다.