정답 · 해설

해설

【핵심 용어】 ▸ AWS Organizations — 다중 AWS 계정 중앙 관리 (청구, 정책) ▸ IAM Identity Center (SSO) — Azure AD와 연동하는 페더레이션 서비스 ▸ Permission Sets — IAM Identity Center의 권한 관리 (임시 자격증명) ▸ AWS Managed Microsoft AD — AWS 내 AD 배포 (온프레미스 통합용) 【정답 포인트】 ▸ (A) 중앙 청구 + 관리 → Organizations 필수 (신규 관리 계정 + 기존 계정 초대) ▸ (C) ID 페더레이션 → IAM Identity Center + Azure AD 연동 ▸ 자동 동기화 → Azure AD의 사용자/그룹 자동 반영 ▸ (E) 임시 자격증명 → Permission Sets로 각 계정별 권한 할당 【오답 체크】 (B) 이메일 주소 통합은 청구 편의일 뿐 중앙화 솔루션 아님 (D) Managed Microsoft AD는 AWS 내 AD 배포로 Azure AD 통합 복잡, IAM Identity Center와 다른 방식 (F) 각 계정마다 개별 설정 필요 → 중앙화 아님, 수작업 증가 【시험 포인트】 다중 계정 통합 3단계: (1)Organizations (청구/관리 중앙화) (2)IAM Identity Center + 외부 IdP 연동 (3)Permission Sets로 임시 자격증명 할당. Azure AD와의 연동은 IAM Identity Center의 전문 분야.

해설

【핵심 용어】 ▸ ECS on EC2 — 컨테이너 기반 오케스트레이션, 세분화된 스케일링 ▸ Task Scaling — 개별 애플리케이션별 독립 스케일링 ▸ Memory-based Metrics — 메모리 사용률 75% 목표로 비용-성능 균형 ▸ Multi-language Support — Java + Node.js 동시 지원 【정답 포인트】 ▸ 20개 이질적 애플리케이션 → 단일 배포 방법론 필요 → ECS 컨테이너화 ▸ 거의 사용되지 않음 + 버스트 부하 → Auto Scaling으로 비용 최소화 ▸ 메모리 1~2.5GB 범위 → 75% 메모리 사용률 목표로 적정 인스턴스 선택 ▸ 중요 Java 애플리케이션(장시간 실행) → 컨테이너 작업 단위로 관리 ▸ 비용 효율: 온디맨드 + 자동 축소 (Lambda는 3시간 제한, Beanstalk은 개별 배포 오버헤드, Reserved Instance는 활용도 낮음) 【오답 체크】 (A) Lambda는 15분 실행 시간 제한 → 장시간 청구 보고서 불가 (C) Beanstalk 20개 = 개별 관리 오버헤드 극대, 표준화 이점 상실 (D) Reserved Instance 3년 선구입은 거의 사용하지 않는 리소스에 부적합, 메모리 임계값 공유는 버스트 대응 어려움 【시험 포인트】 다양한 이질적 애플리케이션 그룹: ECS (표준화) + Task Auto Scaling (개별 제어) + 메모리 기반 메트릭 (비용-성능 최적). Lambda/Beanstalk은 특정 사용 사례용으로 일괄 관리에 부적합.

해설

【핵심 용어】 ▸ EMR Master/Core Nodes — 클러스터 상태 유지, 안정성 필수 (온디맨드) ▸ EMR Task Nodes — 처리 병렬화, 스팟 인스턴스 적합 ▸ Instance Fleet — 스팟 + 온디맨드 혼합 배치 ▸ Spot Instances — 온디맨드 대비 70~90% 할인 【정답 포인트】 ▸ Master + Core 노드: 클러스터 안정성 필수 → 온디맨드 유지 ▸ Task 노드: 병렬 처리만 담당, 중단 가능 → 스팟 인스턴스 적합 ▸ Savings Plans: 온디맨드 Master/Core 예측 가능한 6시간 × 7일 → 비용 추가 절감 ▸ 클러스터 완전 종료: 임시 작업이므로 인스턴스 재사용 불필요 ▸ 전체 비용: 온디맨드(마스터/코어) + 스팟(작업) + Savings Plans = 최저 비용 【오답 체크】 (A) 마스터 노드 스팟 인스턴스는 중단 위험 → 클러스터 데이터 손실 가능성 (C) 작업 노드까지 온디맨드는 비용 낭비, Savings Plans만으로 부족 (D) Task 노드만 종료하면 마스터/코어는 계속 비용 발생 → 리소스 낭비 【시험 포인트】 EMR 비용 최적화: (1)노드 역할별 분리 (2)Master/Core는 안정성(온디맨드) (3)Task는 비용(스팟) (4)예측 가능한 부하 → Savings Plans (5)임시 클러스터 → 완전 종료.

해설

【핵심 용어】 ▸ NAT Gateway — 프라이빗 인스턴스의 아웃바운드 트래픽 변환 (고정 IP) ▸ Elastic IP — NAT Gateway에 할당되는 고정 공인 IP ▸ Single Point of Failure — 단일 NAT 게이트웨이 실패 시 대책 ▸ Automatic Failover — Lambda + CloudWatch로 자동 재생성 【정답 포인트】 ▸ 고정 IP 필수 (온프레미스 방화벽 화이트리스트) → NAT Gateway + Elastic IP ▸ 고가용성 vs 단일 IP → 3개 NAT는 각각 다른 Elastic IP (불가능) ▸ 자동 완화 → CloudWatch 모니터링 + Lambda 자동 재생성 ▸ 선택지 C만 단일 Elastic IP 유지 + 자동 장애 조치 구현 【오답 체크】 (A) 3개의 서로 다른 Elastic IP 생성됨 → 온프레미스 방화벽에 3개 IP 모두 등록 필요 (요구사항 위반) (B) ALB는 HTTP(S) 로드 밸런싱, NAT Gateway의 역할 담당 불가, NLB는 고정 IP 미지원 (D) ALB에 Elastic IP 할당 불가 (ALB는 EIP 미지원), Route 53 레코드는 DNS 레이턴시 문제 【시험 포인트】 온프레미스 연동 아키텍처: (1)고정 IP 필수 (2)NAT Gateway로 구현 (3)단일 IP만 가능 → 단일 NAT (4)HA 요구 → Lambda 자동 재생성. NAT Gateway 다중화에서 Elastic IP 개수 제약을 이해할 것.

해설

【핵심 용어】 ▸ RemoveAccountFromOrganization — 현재 조직에서 계정 제거 (기존 조직의 관리 계정에서 실행) ▸ InviteAccountToOrganization — 대상 조직으로 초대 (신규 조직의 관리 계정에서 실행) ▸ Account Acceptance — 이동 대상 계정에서 초대 수락 필수 ▸ MoveAccount Operation — 존재하지 않음 (AWS Organizations에는 직접 이동 API 없음) 【정답 포인트】 ▸ (B) 기존 조직의 관리 계정 → 개발자 계정들을 제거 ▸ (E) 신규 조직의 관리 계정 → 제거된 개발자 계정들에 초대 ▸ (F) 각 개발자 계정 → 초대 수락하여 신규 조직 가입 【오답 체크】 (A) MoveAccount 작업은 Organizations API에 존재하지 않음 (C) RemoveAccountFromOrganization은 대상 계정이 아닌 현재 조직의 관리 계정에서 실행해야 함 (D) 자리 표시자 계정은 마이그레이션 프로세스에 불필요 【시험 포인트】 계정 이동 3단계: (1)RemoveAccountFromOrganization (기존 조직) (2)InviteAccountToOrganization (신규 조직) (3)계정 수락 (개발자). 각 단계의 실행 주체(어느 조직의 관리 계정)를 구분할 것.

해설

【핵심 용어】 ▸ Lambda@Edge (viewer-response) — CloudFront 클라이언트 응답 전 실행 (지연 시간 증가) ▸ Lambda@Edge (origin-response) — S3 응답 후 실행 (검증 타이밍 지연) ▸ S3 Event Notification — S3 업로드 직후 Lambda 즉시 호출 (최소 지연) ▸ Corruption Detection — 업로드 직후 손상 감지 필수 【정답 포인트】 ▸ 최소 지연 시간 → 업로드 직후 즉시 검증 필요 ▸ S3 Event Notification → 객체 생성 이벤트 감지 → Lambda 즉시 호출 ▸ Lambda가 손상 감지 시 → 객체 삭제 또는 격리 처리 ▸ 서빙 시점(viewer-response)에는 이미 검증 완료 → 손상 객체 제공 안 함 【오답 체크】 (A) viewer-response는 모든 요청에 실행 → 오버헤드 증가, 손상 검증 후 제공 불가 (이미 전송) (B) origin-response는 캐시 미스 시만 실행 → 첫 업로드 후 접근까지 지연, 캐시되면 재검증 불가 (D) Step Functions는 오케스트레이션용으로 단순 손상 감지보다 복잡, 지연 시간 증가 【시험 포인트】 데이터 품질 관리: "수집 → 검증 → 제공" 순서. S3 Event Notification은 업로드 직후 처리의 표준 패턴. Lambda@Edge는 배포 후 클라이언트-서버 경로 최적화용이지, 원본 데이터 품질 관리용 아님.

해설

【핵심 용어】 ▸ CodeDeploy — EC2 인스턴스 배포 자동화 서비스 ▸ AMI(Amazon Machine Image) — 미리 구성된 이미지 ▸ Auto Scaling group — 자동 확장 그룹 【정답 포인트】 ▸ 운영 오버헤드 최소화 → AMI에 에이전트 사전 설치 ▸ 배포 그룹과 Auto Scaling 직접 연결 → 새 인스턴스 자동 등록 ▸ 수동 개입 제거 → 배포 프로세스 완전 자동화 【오답 체크】 (A) EventBridge + Lambda는 추가 로직 필요, 복잡함 (B) 스케일링 일시 중지로 인한 가용성 영향 (C) CodeBuild는 배포 자동화가 아닌 빌드 도구 【시험 포인트】 최소 오버헤드 + Auto Scaling 패턴 → AMI 기반 해결책 선택

해설

【핵심 용어】 ▸ Auto Scaling group — 동적 인스턴스 관리 ▸ ALB (Application Load Balancer) — 트래픽 분배 ▸ Launch template — 인스턴스 시작 설정 【정답 포인트】 ▸ 다운타임 최소화 → 기존 ALB 유지 ▸ 기존 인스턴스 점진적 전환 → 호환성 보장 ▸ 워크플로우 순서 → ASG 생성 → ALB 연결 → 기존 인스턴스 추가 【오답 체크】 (A) ALB 삭제하면 기존 서비스 중단 (C) 삭제 작업으로 인한 완전 다운타임 (D) "기존 ALB가 등록" 오류 — ALB는 수동으로 연결 필요 【시험 포인트】 Blue-Green 전환 패턴 → 기존 리소스 유지하며 단계적 마이그레이션

해설

【핵심 용어】 ▸ AWS Service Catalog — 승인된 템플릿 제공 ▸ S3 gateway endpoint — 데이터 전송 비용 절감 ▸ Launch constraint — IAM 역할로 접근 제어 【정답 포인트】 ▸ 속도 저하 최소화 → Service Catalog로 사전 구성 ▸ 승인된 패턴 강제 → 포트폴리오 제공으로 자동화 ▸ 비용 효율성 → S3 gateway endpoint 포함 ▸ 개발자 경험 개선 → IAM 권한 단순화 【오답 체크】 (A) S3 인터페이스 엔드포인트는 추가 요금 발생 (B) 사후 모니터링으로 비용 낭비 불가피 (D) Config 규칙은 검출만, 속도 저하 유발 【시험 포인트】 속도 + 비용 + 준수 → Service Catalog 패턴 매칭

해설

【핵심 용어】 ▸ AWS Control Tower — 조직 거버넌스 통합 ▸ SCP (Service Control Policy) — 조직 수준 권한 제어 ▸ OU (Organizational Unit) — 계정 그룹화 【정답 포인트】 ▸ 수백 계정 관리 → Control Tower로 중앙 통제 ▸ 리전 제한 → SCP로 조직 전체 적용 가능 ▸ 확장성 → 모든 계정에 통일된 정책 【오답 체크】 (A) IAM 역할은 계정당 개별 설정 필요 (B) IAM 사용자는 개인 수준, 비용 및 관리 오버헤드 높음 (D) Security Hub는 모니터링만, 접근 제어 불가 【시험 포인트】 다중 계정 + 리전 제한 → Control Tower + SCP 조합

해설

【핵심 용어】 ▸ DLQ (Dead-Letter Queue) — 실패 메시지 격리 ▸ Lambda — 서버리스 컴퓨팅 ▸ S3 — 정적 호스팅 【정답 포인트】 ▸ 분리된 아키텍처 → SQS로 주문 큐잉 ▸ 비용 최소화 → Lambda + S3 서버리스 ▸ 실패 주문 보존 → DLQ로 명확한 처리 ▸ 확장성 → 자동 스케일링 【오답 체크】 (A) 긴 폴링은 실패 주문 미보존 (B) S3 Glacier는 접근 속도 느림, MQ 추가 관리 (D) SES는 주문 큐잉 용도 아님, EKS 오버킬 【시험 포인트】 Decoupled + 비용 최소화 → Serverless + DLQ 패턴

해설

【핵심 용어】 ▸ Aurora Global Database — 자동 동기화 ▸ RTO (Recovery Time Objective) — 5분 미만 ▸ RPO (Recovery Point Objective) — 1분 미만 【정답 포인트】 ▸ 교차 리전 복제 필수 → Aurora Global Database ▸ RTO/RPO 충족 → 밀리초 동기화 ▸ 자동 장애 조치 지원 → Route 53과 통합 【오답 체크】 (A) RDS 읽기 복제본은 비동기, RPO 1분 미만 불가 (C) Multi-AZ는 단일 리전, 교차 리전 불가 (D) EC2 기반 수동 복제는 RPO 보장 불가 【시험 포인트】 RTO<5분 + RPO<1분 → Aurora Global Database 필수

해설

【핵심 용어】 ▸ SCP (Service Control Policy) — 리전 제한 ▸ Tag Policy — 태그 강제 ▸ OU (Organizational Unit) — 계정 그룹 【정답 포인트】 ▸ 최소 구성 → OU 생성으로 정책 한 번 적용 ▸ 중앙 관리 → 조직 수준 정책 ▸ 태그 + 리전 제한 → 정책 조합 【오답 체크】 (A) Config 규칙은 개별 계정 설정, 중앙 관리 불가 (B) Billing 콘솔로 리전 비활성화 불가 (C) 루트 연결은 아키텍처 최적화 아님 【시험 포인트】 Centralized + Minimal config → OU + Policies 조합

해설

【핵심 용어】 ▸ Block Public Access — S3 공개 접근 차단 ▸ IgnorePublicAcls — 공개 ACL 무시 ▸ Signed URL — 사전 서명된 URL 【정답 포인트】 ▸ 즉시 해결 → Block Public Access 설정 ▸ 앱 워크플로우 유지 → 서명된 URL 작동 ▸ 공개 접근 전 차단 → ACL 무시 옵션 【오답 체크】 (A) Lambda + 예약 이벤트는 복잡함 (B) Trusted Advisor는 권장사항만, 자동 적용 불가 (C) ACL 변경은 기존 공개 접근 허용 【시험 포인트】 즉시 + 최소 개입 → Block Public Access 일괄 설정

해설

【핵심 용어】 ▸ AWS SCT — 스키마 변환 ▸ AWS DMS — 데이터 마이그레이션 + CDC ▸ CDC (Change Data Capture) — 증분 동기화 【정답 포인트】 ▸ A: 스키마 변환 도구 필수 ▸ C: VPC 피어링으로 안전한 연결 ▸ E: Full Load + CDC로 다운타임 제거 【오답 체크】 (B) SCT는 인스턴스 생성 불가 (D) 공개 접근은 보안 위험 (F) CDC만으로는 초기 데이터 미포함 【시험 포인트】 No-downtime + Schema 변환 → SCT + DMS(Full+CDC) + Peering

해설

【핵심 용어】 ▸ DLQ (Dead-Letter Queue) — 실패 메시지 격리 ▸ SQS Standard — 메시지 순서 보장 안함 ▸ Visibility timeout — 처리 중 메시지 숨김 【정답 포인트】 ▸ 문제 메시지 격리 → DLQ 사용 ▸ Standard 큐로 계속 처리 → 다른 메시지 진행 ▸ 분석 후 재처리 가능 → DLQ로 저장 【오답 체크】 (A) 시간 제한 증가는 문제 해결 안함 (B) 가시성 시간 단축은 재시도만, 격리 안됨 (C) FIFO DLQ는 Standard 큐와 호환 불가 【시험 포인트】 Blocked message + Analysis → Standard DLQ 설정

해설

【핵심 용어】 ▸ SNS — 알림 배포 ▸ States.ALL — 모든 에러 캡처 ▸ Catch field — Step Functions 에러 핸들링 【정답 포인트】 ▸ A: 메일링 리스트 알림 채널 구성 ▸ B: SNS로 메시지 전송 ▸ C: 모든 에러 타입 캡처 【오답 체크】 (D) (E) SES는 Step Functions에 부적절 (F) States.Runtime은 부분 에러만 캡처 【시험 포인트】 All failure types + Notifications → SNS + States.ALL

해설

【핵심 용어】 ▸ Route 53 Resolver — DNS 조건부 포워딩 ▸ Outbound endpoint — VPC에서 외부 DNS로 쿼리 ▸ Resolver rule — 도메인별 포워딩 규칙 【정답 포인트】 ▸ VPC에서 온프레미스 DNS 쿼리 필요 → Outbound endpoint ▸ company.example만 온프레미스로 → Resolver rule ▸ 확장성 → 모든 VPC 인스턴스 자동 적용 【오답 체크】 (A) 비공개 영역은 온프레미스 DNS 미동기 (C) Inbound endpoint는 반대 방향 (온프레미스→VPC) (D) 호스트 파일은 수동 관리, 확장 불가 【시험 포인트】 Hybrid DNS resolution → Route 53 Resolver Outbound endpoint

해설

【핵심 용어】 ▸ Transit Gateway route table — VPC 간 경로 제어 ▸ VPC attachment — 라우팅 정책 적용 단위 ▸ Routing isolation — 특정 VPC 간만 통신 【정답 포인트】 ▸ 기본 경로 테이블 → 모든 VPC 상호 연결 (보안 위험) ▸ 전용 경로 테이블 생성 → 각 VPC별 제한 ▸ 선택적 라우팅 → 승인된 VPC만 경로 추가 【오답 체크】 (A) Network ACL은 CIDR 기반, VPC 식별 복잡 (B) Security group는 아웃바운드 방향만, 양방향 제어 불가 (D) 각 VPC 경로 테이블 관리는 오버헤드 높음 【시험 포인트】 Multi-VPC isolation → Dedicated TGW route tables per attachment

해설

【핵심 용어】 ▸ AppStream 2.0 — Windows 애플리케이션 스트리밍 ▸ Cross-platform — Linux/Windows 모두 접근 ▸ Zero-client — 브라우저 기반 접근 【정답 포인트】 ▸ Windows 앱 실행 가능 → AppStream 2.0 ▸ Linux 머신에서 접근 가능 → 브라우저 스트리밍 ▸ 최소 개발 → 이미지 빌더로 자동 구성 ▸ Active Directory 통합 가능 【오답 체크】 (A) Workspaces는 VDI, Linux 클라이언트 지원 부족 (B) Linux 머신 직접 지원 불가, RDP 필요 (D) 리팩토링으로 개발 노력 증가 【시험 포인트】 Windows app + Linux client + Min dev → AppStream 2.0