정답 · 해설

해설

【핵심 용어】 ▸ AWS Cost Explorer — 자동 리소스 최적화 권장 사항 제공 (ML 기반) ▸ CloudWatch 에이전트 — EC2 메트릭 수집 ▸ 관리 계정 권장사항 — Organizations 조직 수준의 통합 권장 사항 ▸ 리소스 최적화 — CPU, 메모리, EBS, RDS 등 multi-resource optimization 【정답 포인트】 ▸ "가장 적은 노력" → AWS가 제공하는 자동 권장 사항 활용 ▸ "관리 계정" → Organizations 환경에서 모든 멤버 계정의 데이터 중앙 분석 ▸ CloudWatch 에이전트 필수 → Cost Explorer가 상세 메트릭 필요 ▸ 축소 옵션 권장 → Cost Explorer가 인스턴스 크기 다운사이징 자동 제안 【오답 체크】 (A) Marketplace 도구 + Python 스크립트 → 수동 분석 필요. 권장 사항 생성도 직접 수행 → 노력 많음 (C) 각 멤버 계정마다 개별 확인 → Organizations 중앙 관리 이점 상실. 각 계정마다 분석 필요 → 노력 증가 (D) Lambda + Athena → 수동 쿼리 작성, 가격 정보 수작업 조회 → "가장 적은 노력" 아님 【시험 포인트】 AWS Cost Explorer의 "리소스 최적화" 기능은 CloudWatch 메트릭을 기반으로 자동으로 권장 사항 생성. Organizations 환경에서는 관리 계정의 Cost Explorer가 모든 멤버 계정의 데이터 통합 분석하여 중앙 집중식 권장 사항 제공.

해설

【핵심 용어】 ▸ 프로세스 메트릭 — 애플리케이션 소프트웨어 실행 상태 모니터링 ▸ 커스텀 메트릭 — CloudWatch에 애플리케이션 상태 전송 ▸ SNS 트리거 Lambda — 실패 감지 후 자동 대응 ▸ 라우트 업데이트 — 네트워크 라우팅 테이블 즉시 변경 【정답 포인트】 ▸ (B) 프로세스 메트릭 모니터링 → 소프트웨어 실행 상태 감지 (EC2 상태 체크보다 정확) ▸ (D) 애플리케이션 실패 커스텀 메트릭 알람 → CloudWatch에서 실패 감지 시 SNS 발행 ▸ (E) Lambda 함수 → SNS 메시지 수신 후 라우팅 테이블 즉시 업데이트 ▸ 이 조합이 "소프트웨어 멈춤" 감지 → "라우트 업데이트" 자동화 【오답 체크】 (A) EC2 상태 체크 → 물리 하드웨어 문제만 감지. 소프트웨어 멈춤은 감지 불가능 (C) Systems Manager Agent → CloudWatch Agent와 동일하지만 선택지 B가 더 일반적. 둘 중 하나면 충분 (F) CloudFormation 조건문 → "대체 인스턴스가 시작될 때"라고 하지만 CloudFormation은 스택 배포 시점의 조건만 평가. 런타임 인스턴스 교체 시점의 조건문 작동 불가 【시험 포인트】 EC2 상태 체크(하드웨어) vs 프로세스 메트릭(소프트웨어)의 구분이 핵심. 애플리케이션 소프트웨어 실패는 EC2 상태 체크로 감지 불가능하므로 CloudWatch 프로세스 메트릭 + 커스텀 메트릭 알람 + Lambda 자동화가 필요.

해설

【핵심 용어】 ▸ Service Auto Scaling — 작업 수를 CloudWatch 메트릭 기반으로 자동 조정 ▸ Application Load Balancer — HTTP/HTTPS 레이어 7 로드 밸런싱 ▸ 블루/그린 배포 — ECS의 네이티브 배포 전략 (무중단 배포) 【정답 포인트】 ▸ "CloudWatch 알람에 대응하여 작업 수 자동 조정" → Service Auto Scaling 필수 ▸ "HTTPS 프로토콜" → Application Load Balancer가 HTTP/HTTPS 지원 ▸ "블루/그린 배포" → ECS 서비스 설정에서 선택 ▸ "5백만 → 3천만 사용자" → 탄력적 확장 필요 【오답 체크】 (A) 할당량 증가만으로는 자동 확장 불가능 (B) Cluster Autoscaler는 EC2 기반 ECS용. Fargate는 자동 확장 필요 없음 (C) Cluster Autoscaler는 Fargate에서 작동 안 함 【시험 포인트】 Fargate 기반 ECS에서 탄력적 확장은 Service Auto Scaling (작업 레벨)으로 처리. EC2 기반이면 Cluster Autoscaler (노드 레벨) 추가 필요.

해설

【핵심 용어】 ▸ 스캔온푸시 — ECR 이미지 업로드 시 자동 취약점 스캔 ▸ EventBridge — 이벤트 기반 자동화 (스캔 완료 감지) ▸ Step Functions — 복잡한 워크플로우 오케스트레이션 【정답 포인트】 ▸ "새 이미지 버전 업로드 시" → 스캔온푸시로 즉시 스캔 ▸ "중대도/높음 결과" → 스캔 완료 후 EventBridge 이벤트 발행 ▸ "자동 삭제" → Step Functions에서 ECR 이미지 태그 삭제 로직 ▸ "개발 팀 알림" → SNS로 알림 【오답 체크】 (B) SQS 폴링은 지연 가능 + SES는 일반 이메일용 (SNS가 더 직접적) (C) 매시간 스캔은 업로드 즉시 대응 불가능 (D) 정기적 스캔은 "새 이미지 버전 시" 요구사항 위배 【시험 포인트】 스캔온푸시 + EventBridge 트리거가 ECR 이미지 보안 검증의 표준 패턴. Step Functions로 복잡한 삭제/알림 로직 처리.

해설

【핵심 용어】 ▸ Compute Savings Plan — EC2, Fargate, Lambda 통합 할인 (1년/3년) ▸ 관리 계정 권장사항 — Organizations 전체 사용 패턴 분석 ▸ 예측 불가능 수요 — Reserved Instances보다 Savings Plan 유리 【정답 포인트】 ▸ "예측 불가능 수요" + "월별 변동" → Reserved Instances 부적합 ▸ "3년 최적화" → Compute Savings Plan이 가장 큰 할인율 ▸ "조직 전체" → 관리 계정의 중앙 권장사항 활용 ▸ "EC2 + Fargate + Lambda" → Compute Savings Plan이 통합 대상 【오답 체크】 (A) Reserved Instances는 구체적 인스턴스 타입/크기 필요 + 유연성 낮음 (C) 각 계정별 RI 구매는 중복 가능성 + 관리 복잡도 증가 (D) EC2 Instance Savings Plan은 Lambda/Fargate 커버 안 함 【시험 포인트】 예측 불가능 수요에는 Compute Savings Plan > EC2 Instance Savings Plan > Reserved Instances 순으로 유리. 조직 전체 분석으로 최대 할인 달성.

해설

【핵심 용어】 ▸ AWS Budgets — 비용 예산 설정 및 모니터링 (실시간) ▸ 예산 경고 — 임계값 도달 시 SNS 알림 ▸ 일일 예산 — 매일 비용 추적 【정답 포인트】 ▸ "일일 예산" → Budgets의 일일 기간 옵션 ▸ "80% 초과 시 알림" → 경고 임계값 설정 ▸ "조직 수준" → 관리 계정에서 모든 계정 통합 추적 ▸ "SNS 알림" → Budgets에서 직접 SNS 연동 【오답 체크】 (B) Trusted Advisor는 비용 최적화 권장용이지 실시간 예산 추적 안 함 (C) Control Tower는 거버넌스용이지 비용 추적 도구 아님 (D) 수동 Athena 쿼리는 자동화 복잡 + 지연 발생 【시험 포인트】 AWS Budgets는 비용 추적 + 임계값 기반 알림의 표준 솔루션. Organizations 환경에서 관리 계정이 모든 비용 통합 관리.

해설

【핵심 용어】 ▸ S3 Transfer Acceleration — CloudFront의 엣지 로케이션 활용하여 업로드 속도 향상 ▸ 지리적 분산 → 유럽 사용자의 긴 레이턴시 극복 【정답 포인트】 ▸ "유럽 사용자 느린 업로드" → us-east-1까지 거리 문제 ▸ "Transfer Acceleration" → 글로벌 엣지 로케이션 경유 빠른 경로 ▸ "멀티파트 업로드와 무관" → 이미 적용되어 있을 가능성 ▸ "대규모 고해상도 이미지" → CloudFront 읽기용 (업로드 아님) 【오답 체크】 (A) 멀티파트 업로드는 이미 적용되어 있고 지리적 거리 문제 해결 안 함 (B) CloudFront는 읽기용 (다운로드). 업로드는 Transfer Acceleration 필요 (D) Auto Scaling은 업로드 성능과 무관 【시험 포인트】 S3 업로드의 지리적 거리 문제는 Transfer Acceleration으로 해결. CloudFront의 엣지를 경유하여 네트워크 경로 최적화.

해설

【핵심 용어】 ▸ 세션 지속성 → DynamoDB에 저장하여 모든 인스턴스 공유 ▸ 자주 액세스 데이터 → EFS로 모든 팟에서 접근 ▸ Service Auto Scaling → 트래픽 증가에 자동 대응 【정답 포인트】 ▸ "최소 운영 오버헤드" → EKS 관리형 노드 그룹 ▸ "세션 지속성" → DynamoDB (서버 무상태) ▸ "자주 액세스 데이터" → EFS 공유 스토리지 ▸ "Kubernetes 배포" → Pod 자동 확장 가능 【오답 체크】 (A) SQS는 세션 저장용이 아님. Fargate는 관리 덜 필요하지만 설명상 선택지 아님 (B) EBS Multi-Attach는 복잡도 높음. ElastiCache는 정상이나 ECS/EC2 조합은 관리 부담 (C) EFS만으로 세션 저장은 성능 떨어짐 (DynamoDB 필요) 【시험 포인트】 EKS + DynamoDB (세션) + EFS (공유 데이터) 조합이 다층 애플리케이션 마이그레이션의 최적 구조. 관리형 노드와 Kubernetes 배포로 자동 확장 실현.

해설

【핵심 용어】 ▸ Native Database Replication — 기본 데이터베이스 기술을 이용한 동기화 ▸ RDS for SQL Server — AWS의 관리형 SQL Server 인스턴스 【정답 포인트】 ▸ '거의 무중단' 요구사항 → 데이터베이스 네이티브 고가용성 기능 활용 ▸ SQL Server AlwaysOn 또는 Mirroring 같은 기본 복제 메커니즘 사용 ▸ 소스-대상 간 동기 복제로 RPO 0 달성 ▸ 복제 완료 후 빠른 전환 가능 【오답 체크】 (A) SCT와 in-place 업그레이드는 불필요하고, Aurora는 SQL Server 호환이 아님 (B) S3을 중간 대상으로 사용하면 데이터 손실 위험과 추가 단계 증가 (D) EC2로 먼저 재호스팅 후 RDS 이동은 2단계 전환으로 복잡도 증가 【시험 포인트】 SQL Server 마이그레이션에서 무중단을 원할 때 → 네이티브 복제 > DMS/SCT 조합 RDS에서 지원하는 기본 HA 기능 이해 필수

해설

【핵심 용어】 ▸ Cross-Zone Data Transfer — AZ 간 데이터 이동 비용 ▸ Zonal Endpoint DNS — 특정 AZ의 엔드포인트 로컬 접근 ▸ Cross-zone Load Balancing — NLB가 모든 AZ에 분산 라우팅 【정답 포인트】 (C) 교차 영역 로드 밸런싱 비활성화 ▸ NLB의 교차 영역 로드 밸런싱이 활성화되면 다른 AZ로 트래픽 분산 ▸ 비활성화하면 같은 AZ 내에서만 처리 → AZ 간 전송 비용 0 (D) Zonal endpoint DNS 사용 ▸ PrivateLink 엔드포인트의 로컬 DNS 이름 활용 ▸ 소비자가 같은 AZ의 엔드포인트로 직접 접근 → 데이터 전송 비용 제거 【오답 체크】 (A) RAM으로 서브넷 공유는 조직 간 비용 문제와 무관 (B) 같은 조직 내 AZ 간 비용은 조직 구조 변경으로 해결 불가 (E) Savings Plan은 비용 감소 아닌 선결제만 가능 【시험 포인트】 PrivateLink 데이터 전송 비용 최소화 = AZ 간 통신 최소화 로컬 엔드포인트 + 단일 AZ 라우팅이 핵심 전략

해설

【핵심 용어】 ▸ Storage Gateway File Gateway — 온프레미스 애플리케이션에 S3 액세스 제공 ▸ Direct Connect — 전용 네트워크 연결 (비용 절감) ▸ SMB 파일 공유 — 윈도우 환경에서 표준 파일 공유 【정답 포인트】 ▸ 파일 게이트웨이 = S3에 직접 기록 (중간 스토리지 불필요) ▸ SMB 인터페이스로 윈도우 애플리케이션 호환성 ▸ Direct Connect 활용으로 일반 인터넷 비용 절감 ▸ 자동으로 S3로 데이터 지속 (추가 스크립트 불필요) 【오답 체크】 (B) (C) FSx는 완전 관리형 파일 시스템으로 스토리지 비용 높음 ▸ Multi-AZ (C) 는 추가 복제 비용 발생 (D) 볼륨 게이트웨이는 블록 기반으로 파일 공유에 부적합 【시험 포인트】 온프레미스 → S3 백업 시나리오 = File Gateway 최적 선택 파일 기반 아카이빙 = 파일 게이트웨이 용도 FSx = 고성능 공유 파일 시스템 (비용 높음)

해설

【핵심 용어】 ▸ Direct Connect Gateway — 다중 리전 Direct Connect 연결 중앙화 ▸ Transit VIF — Transit Virtual Interface로 라우팅 확장 ▸ Transit Gateway — 크로스 리전 VPC 통신 허브 ▸ Transitive Routing — 다단계 라우팅 경로 지원 【정답 포인트】 ▸ 온프레미스 → DX 연결 (일반 인터넷 아님) ▸ DX 게이트웨이로 다중 리전 확장 가능 ▸ 각 리전 Transit Gateway로 로컬 VPC 집계 ▸ 추이적 라우팅 구현 (Hub-and-Spoke 토폴로지) 【오답 체크】 (A) VPN + VPC Peering은 추이적 라우팅 미지원 (피어링은 직접 연결만) (C) Site-to-Site VPN은 비용 높고 낮은 대역폭 (D) VPN + Peering 조합은 복잡하고 확장성 낮음 【시험 포인트】 온프레미스 ↔ 다중 리전 VPC = DX + Transit Gateway 조합 추이적 라우팅 필요 = Transit Gateway 필수 DX 게이트웨이 = 리전 간 통합의 핵심

해설

【핵심 용어】 ▸ Cross-Account Role — 다른 계정의 리소스 액세스용 역할 ▸ Trust Policy — 역할을 가정할 수 있는 엔터티 정의 ▸ AssumeRole — 역할 자격 증명으로 전환 【정답 포인트】 ▸ 관리 계정에 IAM 사용자 생성 (단일 신원 관리) ▸ 각 멤버 계정에 크로스 계정 역할 생성 ▸ 역할의 신뢰 정책에 관리 계정 사용자 명시 ▸ 사용자가 AssumeRole로 멤버 계정 역할 가정 【오답 체크】 (A) 관리 계정 내 역할은 멤버 계정 리소스 액세스 불가 (B) 각 멤버 계정의 IAM 사용자는 별도 관리 필요 (중복) (C) IAM 그룹은 크로스 계정 권한 부여 불가 【시험 포인트】 AWS Organizations 크로스 계정 액세스 패턴: 1. 중앙 계정에 사용자 생성 2. 개별 계정에 역할 생성 3. 신뢰 정책으로 링크 4. AssumeRole로 리소스 액세스

해설

【핵심 용어】 ▸ AWS Elastic Disaster Recovery — 서버 레벨 복제 및 장애 조치 ▸ RTO 15분 + RPO 5분 — 지속적 복제 필요 ▸ FSx for Windows — Windows 공유 파일 시스템 ▸ DataSync — 온프레미스 ↔ AWS 데이터 동기화 【정답 포인트】 ▸ Elastic Disaster Recovery는 서버 인스턴스 및 데이터 자동 복제 ▸ 지속적 블록 기반 복제로 RPO 5분 달성 ▸ FSx for Windows는 Windows 서버 공유 마운트 지원 ▸ DataSync는 안정적 대용량 파일 동기화 ▸ 기본 장애 조치/복구 기능 포함 【오답 체크】 (A) 일일 백업은 RPO 5분 미충족 (B) CloudFormation + 수동 배포는 RTO 15분 초과 위험 (C) s3 sync는 파일 기반으로 블록 복제 아님, 구성 복잡 【시험 포인트】 엄격한 RTO/RPO 요구사항 = Elastic Disaster Recovery 온프레미스 서버 + 공유 스토리지 = EDR + FSx 조합 Windows 환경 파일 공유 = FSx for Windows 필수

해설

【핵심 용어】 ▸ Elastic Fabric Adapter — 저지연 고대역폭 네트워크 인터페이스 ▸ FSx for Lustre — HPC 최적화 병렬 파일 시스템 ▸ Single AZ — 네트워크 지연 최소화 ▸ EFS 병목 — 메타데이터 작업 많을 시 성능 저하 【정답 포인트】 (A) 단일 AZ 배포 ▸ 다중 AZ는 AZ 간 지연 추가 ▸ 빠듯한 결합 워크로드는 낮은 지연 필요 (C) Elastic Fabric Adapter ▸ EFA는 HPC 최적화 네트워킹 ▸ 낮은 지연, 높은 처리량 ▸ 1,000개 인스턴스 스케일에 필수 【오답 체크】 (B) ENI 4의 배수 = 특정 요구사항 없음 (D) 다중 AZ = 크로스 AZ 트래픽 지연 증가 (E) EBS RAID는 네트워크 병렬화 미지원 【시험 포인트】 HPC 스케일링 문제 = 네트워크 지연 + 스토리지 처리량 EFA + FSx for Lustre = HPC 1,000+ 노드 표준 구성

해설

【핵심 용어】 ▸ Service Control Policy (SCP) — AWS Organizations 정책으로 권한 제어 ▸ Tag Policy — 태그 규정 준수 정책 ▸ OU (Organization Unit) — 조직 단위 【정답 포인트】 ▸ SCP로 거부(Deny)는 명확한 정책 구현 ▸ 태그 정책은 태그 값 규정 기능 ▸ OU 레벨 적용으로 하위 계정 자동 적용 ▸ 각 OU가 고유 태그 값 설정 가능 【오답 체크】 (B) 관리 계정에 적용하면 자식 OU의 태그 값 다양성 불가 (C) Allow는 제한적, Deny가 더 효과적 (화이트리스트 vs 블랙리스트) (D) 태그 정책 없이 SCP만으로는 태그 값 규정 불가 【시험 포인트】 AWS Organizations 태그 거버넌스: 1. SCP로 거부 정책 설정 2. 태그 정책으로 값 규정 3. OU 레벨에서 계층적 적용 OU별 서로 다른 태그 값 = OU 레벨 정책 연결 필수

해설

【핵심 용어】 ▸ AWS IoT Core — MQTT 프로토콜 기본 지원 ▸ Kinesis Data Firehose — 자동 스케일링, 관리형 데이터 전달 ▸ Lambda — 데이터 변환 처리 ▸ 관리형 서비스 — 운영 부담 최소 【정답 포인트】 ▸ IoT Core는 MQTT 프로토콜 네이티브 지원 (마이그레이션 불필요) ▸ Kinesis Firehose는 자동 스케일링 (10,000+ 센서 수용) ▸ Lambda로 데이터 변환 (온프레미스 Kafka 로직 대체) ▸ S3 자동 저장 (Firehose 기본 기능) ▸ 완전 관리형으로 고가용성 보장 【오답 체크】 (A) EC2 Kafka는 관리 부담, 고가용성 제한 (B) MSK는 고가용성이지만 복잡한 설정, NLB 오버헤드 (D) EC2 Kafka는 단일 장애점 (D의 설계는 여전히 위험) 【시험 포인트】 IoT 센서 데이터 수집 = AWS IoT Core + Firehose 표준 패턴 MQTT + 대규모 스케일 + 자동 변환 = IoT Core + Firehose + Lambda 관리형 서비스 조합 = 최소 운영 오버헤드

해설

【핵심 용어】 ▸ AWS Backup — 통합 백업 관리 서비스 ▸ Cross-Region Copy — 자동 리전 간 복제 ▸ SNS Notification — 백업 작업 상태 알림 ▸ 단일 정보원 — 중앙화된 모니터링 【정답 포인트】 (A) AWS Backup 계획 ▸ 다양한 리소스 유형 지원 (EC2, EFS, RDS) ▸ 일간/주간/월간 규칙 설정 가능 ▸ 단일 인터페이스에서 관리 (B) 크로스 리전 복사 ▸ AWS Backup 계획 내장 기능 ▸ 자동 리전 복제 (캡처 후 즉시) ▸ 추가 도구 불필요 (D) SNS 알림 ▸ 실패 시 즉시 알림 (BACKUP_JOB_COMPLETED 제외) ▸ AWS Backup 네이티브 기능 ▸ 추가 Lambda 함수 불필요 【오답 체크】 (C) Lambda 함수는 추가 운영 오버헤드 (E) DLM은 EBS/스냅샷 전용, 통합 관리 불가 (F) RDS 스냅샷 수동 설정은 다른 리소스 미포함 【시험 포인트】 통합 백업 관리 = AWS Backup (단일 정보원) 다중 리소스 + 크로스 리전 = AWS Backup 필수 최소 운영 오버헤드 = 관리형 서비스 (Lambda 불필요)

해설

【핵심 용어】 ▸ Kinesis Data Streams — 준 실시간 스트림 처리 ▸ Kinesis Clients — 스트림 데이터 소비 및 분석 ▸ Amazon Redshift — 분석 데이터 웨어하우스 ▸ Amazon EMR — Spark/Hadoop 기반 처리 【정답 포인트】 ▸ Kinesis Data Streams = 실시간 스트림 수집 ▸ 초당 8KB 지속적 흐름 → Firehose 아님 (준실시간) ▸ Kinesis 클라이언트로 직시 분석 (Lambda 아님) ▸ EMR + Redshift로 데이터 웨어하우스 통합 ▸ 유연성/병렬성 보장 (스트림 기반 아키텍처) 【오답 체크】 (A) Firehose는 배치 전달, RDS는 데이터 웨어하우스 아님 (C) S3 + SQS는 비효율적, 분석 지연 (D) API Gateway + Lambda는 처리 부하 높음, 확장성 제한 【시험 포인트】 준 실시간 스트림 분석 = Kinesis Data Streams IoT/센서 데이터 + 지속적 처리 = Streams 필수 데이터 웨어하우스 = Redshift (EMR 통합) 유연성/병렬성 = 스트림 기반 아키텍처

해설

【핵심 용어】 ▸ Route 53 Failover Routing — 1분 이내 장애 조치 ▸ DynamoDB Global Tables — 다중 리전 동기화 ▸ Auto Scaling + Reserved/On-Demand — 비용 최적화 ▸ Hot Standby — 사전 준비된 인프라 【정답 포인트】 (B) Route 53 Failover Routing ▸ TTL 30초 = 빠른 DNS 업데이트 ▸ 주→DR 자동 장애 조치 ▸ 1분 이내 요구사항 충족 (C) DynamoDB Global Tables ▸ 다중 리전 자동 복제 ▸ 동기식 데이터 동기화 ▸ 지속적 RPO 0 (DR 준비 완료) (E) Hot Standby + Reserved/On-Demand ▸ 사전 배포된 인프라 (빠른 전환) ▸ Reserved Instance = 기본 용량 ▸ On-Demand = 스파이크 대응 ▸ Spot은 불안정 (중단 위험) 【오답 체크】 (A) 가중치 라우팅 + 1시간 TTL = 느린 장애 조치 (D) 60분 백업 + 수동 복구 = 1분 요구사항 미충족 (F) Spot Instances = 중단 가능성, 신뢰성 낮음 【시험 포인트】 1분 이내 RTO = Failover Routing + Hot Standby 필수 다중 리전 DR = Global Tables (자동 복제) 비용 최적화 = Reserved + On-Demand 믹스 (Spot 제외)