정답 · 해설

해설

【핵심 용어】 ▸ PrivateLink 교차 리전 — VPC 피어링으로 연결된 리전 간 서비스 제공 ▸ 기존 리소스 활용 — eu-west-2의 NLB 재활용 ▸ 최소 배포 → us-east-1에 새 EC2 인스턴스 불필요 【정답 포인트】 ▸ 교차 리전 VPC 피어링 → 두 리전 VPC 연결 완료 ▸ eu-west-2 NLB 활용 → 기존 인프라로 충분 ▸ us-east-1 엔드포인트 서비스 → 피어링된 연결 통해 NLB 제공 ▸ 신규 인스턴스 배포 불필요 → 비용 절감 【오답 체크】 (B) IP 대상 그룹은 교차 리전 NLB 참조 불가능 (C) ALB 추가는 불필요한 복잡성, 교차 리전 ALB 미지원 (D) RAM은 EC2 인스턴스 공유 불가능 (사용 불가 서비스) 【시험 포인트】 PrivateLink 엔드포인트 서비스를 통해 VPC 피어링된 리전의 NLB를 다른 리전의 고객에게 제공할 수 있습니다. 이는 새로운 리소스 배포 없이 기존 인프라를 재활용하는 효율적인 방법입니다. NLB는 기존 eu-west-2 인스턴스를 계속 서빙하며, us-east-1의 고객은 PrivateLink를 통해 비공개적으로 접근합니다.

해설

【핵심 용어】 ▸ S3 Storage Lens — S3 메트릭 모니터링 ▸ 기본 대시보드 — 다중 리전 지원 ▸ 최소 오버헤드 → 기본 제공 기능 활용 【정답 포인트】 ▸ 다중 리전 메트릭 → Storage Lens 기본 지원 ▸ 암호화 추적 → Storage Lens에 포함된 지표 ▸ 직접 S3 콘솔 접근 → 추가 도구 불필요 ▸ 운영 오버헤드 최소 → 구성만으로 완료 【오답 체크】 (A) 각 리전 대시보드 + QuickSight = 추가 복잡성 (B) Lambda 개발 및 관리 필요 (D) EventBridge/Lambda/DynamoDB = 과도한 구성 【시험 포인트】 S3 Storage Lens 기본 대시보드는 기본적으로 모든 리전의 모든 S3 버킷을 모니터링하며 암호화 메트릭을 포함합니다. 추가 개발이나 외부 도구 구성 없이 S3 콘솔에서 직접 접근할 수 있어 운영 오버헤드가 최소입니다.

해설

【핵심 용어】 ▸ Blue/Green 배포 — 두 개의 동일한 환경(파란색/초록색)에서 한 버전씩 실행하여 무중단 배포와 즉각적인 롤백 가능 ▸ In-Place 배포 — 기존 인스턴스에서 직접 업데이트하여 다운타임 발생 가능 ▸ CodeDeploy — EC2, 온프레미스, 람다에 대한 자동 배포 서비스 【정답 포인트】 ▸ "최소한의 다운타임" + "빠른 롤백" → Blue/Green이 표준 ▸ Blue/Green은 이전 환경(Blue)을 유지한 채 새 환경(Green)에 배포하므로 트래픽 전환 후 즉시 롤백 가능 ▸ 롤백 시간: In-Place는 다시 배포해야 하므로 지연, Blue/Green은 트래픽 재전환만으로 초단위 ▸ 빠른 롤백 가능 = CodeDeploy의 Blue/Green 필수 선택 【오답 체크】 (A) In-Place 배포는 다운타임 발생, 롤백 시 재배포 필요로 시간 소요 (C) CloudFormation은 배포 속도가 느림, 다운타임 동안 스택 교체 필요 (D) OpsWorks는 레거시 서비스, In-Place는 롤백 시간 문제 【시험 포인트】 CodeDeploy 배포 유형 구분이 핵심 → Blue/Green(무중단, 빠른 롤백) vs In-Place(중단, 느린 롤백)

해설

【핵심 용어】 ▸ Tag Policy — 태그 키/값 형식을 조직 수준에서 강제하는 정책 ▸ SCP (Service Control Policy) — IAM 권한을 제어하는 권한 정책 ▸ Organizations 루트 — 모든 계정에 정책 적용 가능 【정답 포인트】 ▸ 태그 정책은 태그 형식만 관리 → 태그 미적용 리소스 생성 차단 불가능 ▸ SCP는 IAM 작업 자체를 거부 가능 → ec2:RunInstances 태그 조건부 실행 거부 가능 ▸ "미래에 태깅 요구사항 적용" = 인스턴스 생성 시 태그 없이는 실패하도록 강제 ▸ SCP를 루트에 연결 = 모든 하위 계정에 적용 ▸ SCP는 태그 없이 ec2:RunInstances 호출 거부하는 Deny 정책 포함 【오답 체크】 (A) (B) 태그 정책은 형식만 강제, 태그 미적용을 막지 못함 (D) 관리 계정만 적용 → 멤버 계정 영향 없음 【시험 포인트】 태그 정책 vs SCP 구분 중요 → 태그 강제는 SCP 필수 (DenyAction with tag condition)

해설

【핵심 용어】 ▸ Egress-Only IGW — IPv6 아웃바운드만 허용, 인바운드는 차단 ▸ NAT Gateway — IPv4 전용, IPv6 지원 불가 ▸ Amazon-provided IPv6 CIDR — AWS 관리 IPv6 블록 【정답 포인트】 ▸ IPv6 마이그레이션 요구사항 = Egress-Only IGW 필수 ▸ 프라이빗 서브넷은 외부에서 접근 불가 → IPv6도 마찬가지 ▸ Egress-Only IGW = 아웃바운드만 허용 (인바운드 비상태 필터링) ▸ NAT Gateway는 IPv6 미지원 → IPv6에만 사용 불가 ▸ Amazon-provided CIDR이 권장 (커스텀은 복잡함) 【오답 체크】 (A) 커스텀 CIDR 사용, 모든 서브넷에 ::/0 → 프라이빗 서브넷도 인터넷 노출 (B) NAT Gateway는 IPv6 미지원 (D) NAT Gateway IPv6 지원 없음, 불필요 【시험 포인트】 IPv6 + 프라이빗 서브넷 = Egress-Only IGW가 표준 패턴

해설

【핵심 용어】 ▸ Interface VPC Endpoint — EC2에서 AWS 서비스를 프라이빗으로 접근 ▸ execute-api:Invoke — API 호출 권한 (apigateway:*보다 세분화) ▸ Private DNS naming — VPC 엔드포인트에 기본 DNS 매핑 【정답 포인트】 ▸ 프라이빗 API + VPC 내 EC2 접근 = Interface VPC Endpoint 필수 ▸ 권한: apigateway:* (과도함) → execute-api:Invoke (적절함) ▸ Private DNS 활성화 = API의 기본 DNS 이름으로 접근 가능 ▸ 리소스 정책 = VPC 엔드포인트 특정 권한 허용 ▸ 이로써 EC2 → VPC Endpoint → API 경로 확보 【오답 체크】 (A) Private DNS 비활성화 → 별도 DNS 이름 필요, 복잡함 (A) apigateway:* → 과도한 권한 (execute-api:Invoke만 필요) (C) (D) VPC Link는 API → 백엔드 서비스용 (역방향) 【시험 포인트】 프라이빗 API + VPC 접근 = Interface Endpoint + execute-api:Invoke + Private DNS enabled

해설

【핵심 용어】 ▸ OrganizationAccountAccessRole — Organizations에 자동 생성되는 신뢰 역할 ▸ Cross-account access — 다른 계정의 역할 가정 ▸ Trust relationship — 역할을 가정할 수 있는 주체 정의 【정답 포인트】 ▸ Organizations 초대 수락 후 = 각 멤버 계정에 OrganizationAccountAccessRole 자동 생성됨 ▸ 관리 계정 = 이 역할을 가정(assume)해서 멤버 계정 관리 ▸ 신뢰 관계 설정 = 관리 계정 원본 ID/루트에 AssumeRole 권한 부여 ▸ 결과: 관리 계정 → assume role → 멤버 계정 full access 【오답 체크】 (A) IAM Group은 Organizations와 무관, 그룹 기반 관리는 확장성 낮음 (B) 정책만으로는 충분, 역할 신뢰 관계 필요 (D) 관리 계정에 역할 생성 → 멤버 계정에서 가정 불가능 (방향 역) 【시험 포인트】 Organizations + 멤버 계정 접근 = 각 멤버의 OrganizationAccountAccessRole assume role pattern

해설

【핵심 용어】 ▸ EKS + Fargate — 완전 관리형 Kubernetes, 서버 관리 불필요 ▸ Amazon MSK — 완전 관리형 Kafka, 운영 오버헤드 최소 ▸ Aurora 읽기 복제본 vs RDS — Aurora는 즉시 자동 확장 ▸ CloudFront — CDN으로 정적 콘텐츠 캐싱 성능 향상 【정답 포인트】 ▸ 운영 오버헤드 최소화 = 완전 관리형 서비스 선택 ▸ 자체 관리 Kubernetes → EKS + Fargate (서버리스) ▸ 자체 관리 Kafka → Amazon MSK (관리형) ▸ 읽기 복제본 → Aurora Auto Scaling (즉시, RDS는 느림) ▸ CloudFront = 정적 콘텐츠 성능 최적화 ▸ 결합: 최대 자동 확장 + 최소 운영 오버헤드 【오답 체크】 (A) Kinesis (Kafka 아님), 정적 콘텐츠 직접 제공 (CDN 없음) (B) 자체 관리 EC2 Kubernetes, RDS 읽기 복제본 느림 (C) 자체 관리 EC2 Kubernetes는 운영 오버헤드 많음 【시험 포인트】 운영 오버헤드 최소화 + 대규모 트래픽 = EKS Fargate + MSK + Aurora + CloudFront

해설

【핵심 용어】 ▸ FSx for Windows File Server — Windows 파일 공유 (SMB), 홈 디렉토리용 최적화 ▸ AWS Client VPN — 개별 원격 직원 VPN 접근 (AWS의 네이티브 VPN) ▸ Storage Gateway — 캐싱 기능, 온프레미스 스토리지용 ▸ FSx for Lustre — HPC 워크로드, 홈 디렉토리 아님 【정답 포인트】 ▸ 홈 디렉토리 마이그레이션 = FSx for Windows (Windows 네이티브 공유) ▸ 원격 직원 VPN 접근 = AWS Client VPN (대역폭 오프로드) ▸ 결합 효과: 데이터 → AWS 저장 + VPN 연결 AWS에서 종료 = 온프레미스 대역폭 급감 ▸ 최소 운영 오버헤드 = 완전 관리형 서비스 (B, D) 【오답 체크】 (A) Storage Gateway는 캐싱만 지원, 홈 디렉토리 완전 마이그레이션 아님 (C) FSx Lustre는 HPC용, 정적 홈 디렉토리에 부적절 (E) Direct Connect는 최소 1 Gbps, 비용 높음 【시험 포인트】 VPN 대역폭 문제 + 원격 근무 = FSx Windows + Client VPN 패턴

해설

【핵심 용어】 ▸ AWS Control Tower — 조직 관리 자동화 + 가드레일(정책) ▸ Strongly Recommended vs Mandatory guardrails — 권장(규정 준수) vs 필수(강제) ▸ Snapshot-based 암호화 — 기존 볼륨 암호화 유일한 방법 ▸ EventBridge — 탐지용 (자동 암호화는 불가능) 【정답 포인트】 ▸ 다중 계정 규정 준수 중앙 관리 = AWS Control Tower (A 필수) ▸ 현재 암호화되지 않은 볼륨 = 스냅샷 복제 후 암호화 (C 필수) ▸ Control Tower 권장 가드레일 = 향후 암호화 강제 (중앙 정책) ▸ (A) + (C) 조합: 현재 수정 + 미래 자동화 【오답 체크】 (B) CLI 스크립트는 일회성, 다중 계정 미지원 (D) 필수 가드레일은 권장보다 낮은 수준 (필수만으로는 부족) (E) EventBridge는 탐지만 가능, 자동 암호화 불가능 【시험 포인트】 다중 계정 규정 준수 + 자동화 = Control Tower + Snapshot-based 암호화

해설

【핵심 용어】 ▸ AWS Directory Service for Microsoft AD — 엔터프라이즈 Active Directory ▸ Amazon Cognito — 사용자 풀 + 페더레이션 ▸ authenticate-cognito — ALB에서 Cognito 사용자 풀 인증 ▸ IDP (Identity Provider) — 사용자 인증 제공자 【정답 포인트】 ▸ Active Directory → Cognito 사용자 풀 = 표준 페더레이션 패턴 ▸ ALB의 authenticate-cognito 작업 사용 ▸ Cognito 사용자 풀 = SAML/OIDC IDP 지원 (Active Directory 매핑) ▸ 앱 클라이언트 = Cognito 내 클라이언트 등록 ▸ 이로써 AD 사용자 → Cognito 동기화 → ALB 인증 【오답 체크】 (A) Active Directory 직접 OIDC는 미지원 (authenticate-oidc 사용 불가) (C) IAM IDP + SAML은 ALB 리스너와 통합 미지원 (D) Identity Center는 내부 직원 SSO용, ALB 리스너 통합 비표준 【시험 포인트】 AD + ALB 인증 = Cognito 사용자 풀 페더레이션 + authenticate-cognito

해설

【핵심 용어】 ▸ CloudFront Origin Group — 두 개 이상의 원본으로 자동 페일오버 ▸ Origin Failover — CloudFront 수준의 빠른 전환 (DNS TTL 우회) ▸ Route 53 TTL — DNS 캐시 시간 (60초면 느림) ▸ Route 53 페일오버 — DNS 수준 페일오버 (지연 존재) 【정답 포인트】 ▸ 1분 이상 지연 = Route 53 TTL + 상태 확인 대기 시간 ▸ CloudFront Origin Group 사용 = Route 53을 우회, CloudFront 캐시 레이어에서 즉시 전환 ▸ 페일오버 시간 = DNS TTL 무관 (CloudFront 내부 전환) ▸ 결과: 초 단위 페일오버 (분 단위 → 초 단위) ▸ D가 가장 빠른 솔루션 【오답 체크】 (A) CloudFront 2개 + Route 53 페일오버 = 여전히 DNS TTL 지연 (B) TTL을 4초로 줄여도 Route 53 상태 확인 + DNS 전파 = 여전히 10~20초 (C) 레이턴시 라우팅은 페일오버 아님 【시험 포인트】 빠른 페일오버 = Origin Failover (Route 53 우회) vs TTL 단축

해설

【핵심 용어】 ▸ SCP (Service Control Policy) — Organizations 수준의 권한 필터 ▸ Access Advisor — IAM에서 최근 서비스 사용 기록 추적 ▸ Trusted Advisor — 일반 AWS 권장사항 (사용 서비스 추적 아님) ▸ OU (Organizational Unit) — 계정 그룹화 및 정책 적용 ▸ Deny 리스트 — Allow 기본, 특정 서비스만 Deny 【정답 포인트】 ▸ "사용하는 서비스 = Allow, 미사용 = Deny" = Deny 리스트 전략 (A) ▸ 어떤 서비스 사용하는지 파악 = Access Advisor (B) (Trusted Advisor는 일반 권장) ▸ 다중 계정 관리 = OU 생성 + SCP 적용 (E) ▸ (A) + (B) + (E) = 완전한 구성 【오답 체크】 (C) Trusted Advisor는 서비스 사용 추적 미지원 (D) FullAWSAccess 제거 → 모든 서비스 차단 (Allow 정책 필요) (F) DenyAWSAccess는 명시적 거부, Deny 리스트에 맞지 않음 【시험 포인트】 Organizations + SCP + Deny 리스트 = Access Advisor + OU 구성

해설

【핵심 용어】 ▸ Predictive scaling — 과거 데이터 기반 자동 확장 (예측) ▸ Scheduled scaling — 미리 정해진 시간에 확장 (일회성 이벤트 최적) ▸ Aurora Serverless v2 — 자동 확장, RDS는 수동 관리 ▸ Aurora Replica — 읽기 복제본, 即時 자동 확장 지원 【정답 포인트】 ▸ "미리 일정이 정해진" 이벤트 = Scheduled scaling (일회성, 일정 시간 확장) ▸ Predictive는 과거 패턴 학습 필요 (일회성 이벤트 부적절) ▸ Aurora Multi-AZ 클러스터 = 자동 읽기 복제본 확장 ▸ EventBridge 규칙 = 세일 시작 전 확장, 종료 후 축소 트리거 ▸ 결과: 예측 가능한 시간에 최적의 리소스 할당 【오답 체크】 (A) Predictive scaling은 일회성 이벤트에 부적절, Serverless는 자동 확장 과다 (B) RDS 읽기 복제본은 자동 확장 미지원, 수동 페일오버 필요 (C) Predictive + RDS = 부적절한 조합 【시험 포인트】 일회성 예약 이벤트 = Scheduled Scaling + Aurora (자동 확장 지원)

해설

【핵심 용어】 ▸ Elastic Disaster Recovery (DRS) — 온프레미스 → AWS 복제 ▸ Site-to-Site VPN — 암호화된 VPN 터널 (대역폭 제한) ▸ AWS Direct Connect — 전용 네트워크 연결 (대역폭 보장) ▸ 프라이빗 IP 복제 — 공용 인터넷 우회 【정답 포인트】 ▸ "공용 인터넷 통과하지 않음" = 온프레미스 → VPC 프라이빗 경로 필수 ▸ VPC 구성 = 프라이빗 서브넷 (A) (공용 서브넷 노출, 부적절) ▸ 접근성 = Site-to-Site VPN (C) 또는 Direct Connect (D) 중 선택 ▸ Direct Connect = 전용 연결, 대역폭 일정, 비용 높음 ▸ VPN = 공유 인터넷, 변동 가능, 경제적 ▸ 그러나 "모든 대역폭 소비 안 함" → Direct Connect (D) 대역폭 제어 가능 ▸ 복제 설정 = 프라이빗 IP 사용 (E) → 공용 IP 노출 방지 ▸ (A) 프라이빗 VPC + (D) Direct Connect + (E) 프라이빗 IP 복제 【오답 체크】 (B) 공용 서브넷 = 복제 트래픽 인터넷 노출 (C) VPN은 공용 인터넷 사용 (Direct Connect가 전용) (F) IP 주소 일치는 복제 대역폭과 무관 【시험 포인트】 DRS + 프라이빗 복제 = Private VPC + Direct Connect (또는 VPN) + Private IP 복제

해설

【핵심 용어】 ▸ S3 Event Notifications — 실시간 이벤트, 일부 손실 가능 ▸ EventBridge — 비 S3 서비스 연동, 이벤트 재시도 제한 ▸ Step Functions — 상태 머신, 복잡한 오케스트레이션 ▸ SQS — 메시지 큐, 확실한 전달 + 실패 처리 재시도 ▸ S3 Standard-IA → Glacier Deep Archive — 비용 최적화 단계 【정답 포인트】 ▸ "처리 작업 재실행 능력" = 메시지 큐 필수 (SQS) ▸ "상당한 수요 변동" = 비동기 처리 (SQS 디커플링) ▸ "엔터프라이즈 규모 신뢰성" = SQS Dead-Letter Queue 재시도 ▸ 비용 최적화 = S3 Standard-IA 시작 + Glacier Deep Archive 최종 (콜드 스토리지) ▸ Step Functions는 오버 엔지니어링 (복잡함) ▸ Event Notifications는 손실 가능성 (신뢰성 부족) 【오답 체크】 (A) Step Functions는 불필요히 복잡 (B) EventBridge는 실패 재시도 능력 약함 (C) Event Notifications는 신뢰성 약함, 비용 비효율 (원본 계속 저장) 【시험 포인트】 확실한 재시도 + 비용 최적화 = SQS + Tiered Storage (Standard → IA → Glacier)

해설

【핵심 용어】 ▸ Consolidated Billing — Organizations 수준의 통합 결제 + 비용 집계 ▸ EC2 Instance Savings Plans — EC2 전용, 인스턴스 타입 유연성 제한 ▸ Compute Savings Plans — EC2, Fargate, Lambda 공통, 최대 유연성 ▸ Tag Editor — 대규모 태그 일괄 적용 ▸ SCP — 정책 강제 (태그 강제는 복잡함) 【정답 포인트】 ▸ "부서 간 비용 관리" = Consolidated Billing (Organizations) ▸ "비용 가시성" = 태깅 전략 + Cost Explorer/Billing 분석 ▸ "운영 유연성 유지" = Compute Savings Plans (모든 컴퓨팅 서비스 지원) ▸ EC2 Instance Plans는 유연성 제한 (EC2만, 타입 고정) ▸ Tag Editor = 효율적 태깅 (SCP는 복잡함) ▸ (C) = 모든 요구사항 충족 【오답 체크】 (A) Budgets는 경고만 (청구 통합 아님), EC2 Instance Plans는 유연성 제한 (B) SCP는 태깅 강제에 복잡, EC2 Instance Plans는 유연성 제한 (D) Budgets만으로는 통합 청구 아님, SCP는 태깅에 비효율 【시험 포인트】 다중 계정 + 비용 관리 + 유연성 = Consolidated Billing + Tag Editor + Compute Savings Plans

해설

【핵심 용어】 ▸ S3 Transfer Acceleration — CloudFront의 엣지 로케이션을 통한 빠른 업로드 ▸ Presigned URL — 인증 없이 시간 제한 업로드 권한 ▸ Multipart Upload — 대용량 파일을 병렬 청크로 업로드 ▸ API Gateway S3 Proxy — 추가 지연 유발 ▸ CloudFront — 다운로드 최적화, 업로드는 미지원 【정답 포인트】 ▸ "100 MB 이상 느린 업로드" = 직접 S3 업로드 최적화 필요 ▸ S3 Transfer Acceleration = CloudFront 엣지 노드 활용 → 빠른 업로드 ▸ Multipart Upload = 병렬 청크 전송 → 대역폭 최대 활용 ▸ Presigned URL 유지 = 인증된 사용자만 접근 ▸ API Gateway 프록시는 추가 홉 → 더 느림 ▸ CloudFront는 업로드 비최적화 (다운로드용) 【오답 체크】 (A) 엣지 최적화 + API Gateway = 거리 더 가까워도 프록시 지연 (B) 지역 엔드포인트 + Lambda = 추가 레이턴시 (D) CloudFront는 업로드 최적화 없음 【시험 포인트】 대용량 업로드 성능 = S3 Transfer Acceleration + Multipart Upload

해설

【핵심 용어】 ▸ AWS Organizations — 다중 계정 중앙 관리 (Consolidated Billing + SCP) ▸ Service Control Policy (SCP) — Organizations 수준의 IAM 권한 필터 ▸ Consolidated Billing — 중앙 결제 + 비용 추적 ▸ CloudFormation — 각 계정별 IAM 구성 (확장성 낮음) 【정답 포인트】 ▸ "중앙 결제" + "비용 가시성" + "IAM 중앙 제어" = Organizations 필수 ▸ (B) Organizations = 조직 생성 + 기존 계정 초대 + 새 계정 생성 ▸ (D) "모든 기능 활성화" + SCP = IAM 중앙 제어 (Deny 정책으로 제한) ▸ 최소 노력 = Organizations + SCP 조합 【오답 체크】 (A) CloudFormation은 일회성, 신규 계정 추가 시 수동 스택 배포 필요 (확장성 낮음) (C) Cost Explorer만으로는 중앙 결제 아님, IAM 제어 없음 (E) 단일 계정 = 부서별 격리 불가, 보안 위험 【시험 포인트】 다중 계정 + 중앙 청구 + IAM 제어 = Organizations All-features + SCP

해설

【핵심 용어】 ▸ SQS — 메시지 큐, 확실한 전달 + 재시도 ▸ Dead-Letter Queue (DLQ) — 실패 메시지 저장 ▸ EventBridge — 이벤트 버스, 재시도 제한 ▸ API 직접 → Lambda — 동기 호출, 실패 = 데이터 손실 【정답 포인트】 ▸ "데이터 손실 방지" = 메시지 큐 필수 (비동기 처리) ▸ "실패 시 나중에 처리" = DLQ 필수 ▸ SQS 기본 큐 = API 메시지 수신, 확실한 저장 ▸ SQS DLQ 보조 큐 = 처리 실패 메시지 재저장 ▸ Lambda = 기본 큐에서 메시지 가져와 처리 ▸ 처리 실패 → DLQ에 자동 이동 → 나중에 재처리 【오답 체크】 (A) SQS만 생성, DLQ 설정 없음 → DLQ 구성 부재 (C) EventBridge는 재시도 능력 약함, 실패 대상 미흡 (D) EventBridge DLQ만으로는 충분하지 않음 (재시도 메커니즘 약함) 【시험 포인트】 데이터 손실 방지 + 실패 처리 = SQS 기본 큐 + DLQ 패턴