정답 · 해설

해설

【핵심 용어】 ▸ IAM Identity Center — AWS Organizations 통합 SSO 솔루션 ▸ SAML 2.0 — 온프레미스 AD와 통합하는 표준 페더레이션 프로토콜 ▸ SCIM v2.0 — 자동 사용자 프로비저닝 프로토콜 ▸ ABAC — 사용자 속성(그룹, 역할)을 기반으로 접근 제어 【정답 포인트】 ▸ Organizations 통합 + 여러 계정 접근 → IAM Identity Center 필수 ▸ 온프레미스 AD 연동 → SAML 2.0 페더레이션 사용 ▸ 자동 사용자 관리 → SCIM v2.0 프로토콜 ▸ 조건부 접근(그룹, 역할) → ABAC 정책 활용 【오답 체크】 (B) IAM Identity Center 자체를 ID 소스로 하면 온프레미스 AD 연동 불가능 (C) 단일 계정의 SAML 구성은 Multiple Organizations 계정 접근에 부적합 (D) OIDC는 OpenID Connect용이며, SAML 기반 AD 연동에 적합하지 않음 【시험 포인트】 Organizations + 페더레이션 → IAM Identity Center / AD 연동 → SAML 2.0

해설

【핵심 용어】 ▸ API 스로틀링(Throttling) — API Gateway에서 요청 속도 제한 ▸ 사용 계획(Usage Plan) — API 키별 요청 할당량 관리 ▸ 429 상태 코드 — Too Many Requests (클라이언트 제한됨) ▸ 재시도 로직 — 실패한 요청을 자동으로 다시 시도 【정답 포인트】 ▸ 특정 클라이언트로부터의 과다 요청 → 스로틀링으로 제한 ▸ 낮은 우선순위 API → 재시도 가능 ▸ 429 응답을 클라이언트가 처리 → 오류 표시 안 함 ▸ API Gateway 사용 계획 → API 키 단위의 세분화된 제어 【오답 체크】 (A) 재시도 로직은 근본 원인(과다 요청)을 해결하지 못함. 같은 오류 반복 (C) API 캐싱은 PUT 요청(변경 작업)에 효과적이지 않음. 조회 API용 (D) Lambda 예약 동시성은 Lambda 수행 속도를 높이지만, 클라이언트의 과다 요청 문제 미해결 【시험 포인트】 클라이언트 과다 요청 → API Gateway 스로틀링 / 클라이언트 재시도 처리 → 429 상태 코드

해설

【핵심 용어】 ▸ FSx for Lustre — 고성능 병렬 파일 시스템, S3와 네이티브 통합 ▸ 지연 로딩(Lazy Loading) — 필요할 때만 S3에서 데이터 로드 ▸ 배치 로딩(Batch Loading) — 사전에 모든 데이터를 로드 ▸ S3 Intelligent-Tiering — 접근 패턴에 따라 자동으로 스토리지 클래스 전환 【정답 포인트】 ▸ 월 1회 72시간 작업 → 필요한 기간만 파일 시스템 생성 후 삭제 ▸ 200TB 데이터, 월별 접근 → S3 저장소는 항상 존재, 필요시만 FSx 비용 ▸ 지연 로딩 → 필요한 데이터만 로드 (일부 파일만 필요하므로 효율적) ▸ S3 Intelligent-Tiering → 저비용 장기 저장소 【오답 체크】 (B) Multi-Attach EBS는 비용이 높고, EC2 인스턴스 종료 시 데이터 손실 위험 (C) 배치 로딩은 필요 없는 모든 데이터를 사전 로드하여 지연 로딩보다 비효율적 (D) Storage Gateway는 온프레미스 환경용이며, 클라우드 환경에서는 FSx for Lustre가 우수 【시험 포인트】 월간 배치 작업 + 고성능 접근 → FSx for Lustre / 저장소 비용 최소화 → S3 + 지연 로딩

해설

【핵심 용어】 ▸ Network Load Balancer(NLB) — TCP/UDP 기반 초고성능 로드 밸런싱 ▸ Elastic IP — 고정 공용 IP 주소 ▸ NLB 별칭 레코드 — Route 53에서 NLB를 가리키는 DNS 레코드 ▸ 다중 AZ — 각 AZ에서 하나의 Elastic IP 보유 【정답 포인트】 ▸ TCP 고정 포트 → NLB 필수 (ALB는 HTTP/HTTPS용) ▸ 고정 주소 기반 허용 목록 → NLB에 할당된 Elastic IP ▸ 다중 AZ 고가용성 → 각 AZ당 1개의 Elastic IP ▸ DNS 레코드 → Route 53 별칭 레코드로 NLB 가리킴 (EC2 IP 직접 사용 안 함) 【오답 체크】 (A) EC2 IP를 Route 53에 직접 할당하면, NLB의 자동 로드 밸런싱 이점 상실 (B) ECS 클러스터는 동적 포트 할당으로 고정 주소 사용 불가 (D) ALB는 TCP가 아닌 HTTP/HTTPS 기반이며 CNAME 레코드는 별칭이 아님 【시험 포인트】 TCP 고정 포트 → NLB / 고정 주소 → NLB Elastic IP / 다중 AZ 고가용성 → 각 AZ당 IP

해설

【핵심 용어】 ▸ Spot Instance — 최대 90% 할인의 가변 가격 인스턴스 (종료 위험) ▸ On-Demand + 용량 예약 — SLA 보장 가능한 비용 절감 ▸ Savings Plan — 1년/3년 약정으로 할인 (질문에서 제외) ▸ 다중 AZ — 장애 격리를 통한 고가용성 【정답 포인트】 ▸ SLA 65% (스케줄 작업) → On-Demand + 용량 예약으로 보장 ▸ 비필수 35% (사용자 작업) → Spot으로 비용 절감 ▸ 3개 AZ 분산 → 단일 AZ 장애 시에도 운영 가능 ▸ 각 AZ당 3개 On-Demand + 1개 Spot → 3개 실패 시에도 9개 유지 【오답 체크】 (A) 2개 AZ만으로는 1개 AZ 장애 시 용량 부족 가능 (B) 1개 AZ에만 On-Demand 배치하면 해당 AZ 장애 시 SLA 미충족 (C) Savings Plan은 장기 약정(1년/3년)으로 질문의 "장기 약정 없음" 조건 위배 【시험 포인트】 SLA 필수 + 비용 절감 → On-Demand + Spot 혼합 / 다중 AZ 배치 → 장애 격리

해설

【핵심 용어】 ▸ AWS Secrets Manager — 데이터베이스 암호 관리 및 자동 회전 기능 제공 ▸ RotationSchedule — Secrets Manager 내장 자동 회전 메커니즘 ▸ Lambda 함수 — 커스텀 회전 로직 구현 ▸ Parameter Store — 설정 값 저장용 (회전 기능 제한적) 【정답 포인트】 ▸ Secrets Manager 네이티브 RotationSchedule → 최소 운영 오버헤드 ▸ Lambda 함수 자동 호출 → CloudFormation에서 통합 관리 ▸ 90일 회전 → RotationSchedule에서 직접 설정 ▸ RDS 암호 관리 → Secrets Manager가 전문 서비스 【오답 체크】 (B) Parameter Store는 회전 기능이 불충분하며, RotationSchedule 리소스 없음 (C) EventBridge는 추가 설정 필요로 운영 복잡도 증가 (D) AppSync는 GraphQL 쿼리용이며 자동 암호 회전 기능 없음 【시험 포인트】 데이터베이스 암호 회전 → Secrets Manager RotationSchedule / 최소 운영 오버헤드 → 네이티브 기능 활용

해설

【핵심 용어】 ▸ API Gateway REST API — 전통적 API 제공, 모든 HTTP 메서드 지원 ▸ API Gateway HTTP API — 현대적 API, 더 빠른 성능, 저렴한 비용 ▸ AWS 통합 타입 — API Gateway에서 AWS 서비스로 직접 요청 전송 ▸ Lambda 통합 — API Gateway에서 Lambda 함수 호출 【정답 포인트】 ▸ 서버리스 + 자동 확장 → API Gateway + DynamoDB/Lambda ▸ REST API + DynamoDB 직접 통합 → 가능하고 비용 효율적 ▸ HTTP API + DynamoDB 직접 통합 → 가능하고 더 빠르고 저렴 ▸ Lambda 통합 → 복잡한 로직이 필요할 때 사용 가능 【오답 체크】 (B) 정답이지만, A와 C를 조합하는 것이 더 나음 (HTTP API 자체는 맞지만 REST API도 동작) (D) Global Accelerator + Lambda@Edge는 CDN/캐싱용이며 DynamoDB 직접 접근에 부적합 (E) Network Load Balancer는 서버리스가 아니며 관리 오버헤드 증가 【시험 포인트】 공개 API + DynamoDB → REST/HTTP API + AWS 통합 또는 Lambda / 서버리스 중심

해설

【핵심 용어】 ▸ Lambda@Edge — CloudFront와 통합된 엣지 함수로 리다이렉트 수행 ▸ CloudFront 배포 — 전역 콘텐츠 전달 및 HTTPS 지원 ▸ AWS Certificate Manager(ACM) — SSL 인증서 관리 및 Subject Alternative Names ▸ API Gateway + Lambda — 서버리스 API (CloudFront와 함께는 비효율적) 【정답 포인트】 ▸ CloudFront + Lambda@Edge → 엣지에서 빠른 리다이렉트 처리 ▸ Lambda 함수 → JSON 문서 기반 URL 조회 로직 ▸ ACM SSL 인증서 → HTTPS 지원 및 다중 도메인(SANs) ▸ 최소 운영 오버헤드 → EC2 인스턴스 관리 불필요 【오답 체크】 (A) EC2 인스턴스는 관리 오버헤드 증가 및 자동 확장 불가 (B) ALB는 필요 없음 (Lambda@Edge로 충분) (D) API Gateway는 CloudFront 없이 리다이렉트용으로는 오버 엔지니어링 【시험 포인트】 다중 도메인 리다이렉트 → CloudFront + Lambda@Edge / HTTPS + 다중 도메인 → ACM SANs

해설

【핵심 용어】 ▸ Cost and Usage Report(CUR) — 상세한 비용 데이터와 리소스별 태그 분석 ▸ 사용자 정의 태그 활성화 — 관리 계정에서 조직 태그 활성화 ▸ 태그 분석 — CUR 내에서 특정 태그로 비용 필터링 ▸ 조직 구조 — 관리 계정이 CUR 생성 및 태그 활성화 담당 【정답 포인트】 ▸ 관리 계정 태그 활성화 → 모든 멤버 계정에 적용 ▸ CUR 생성 위치 → 관리 계정 (조직 전체 비용 포함) ▸ 태그 분석 → CUR 내장 기능으로 비용 계산 ▸ 최고 정확도 → CUR의 상세 태그 필터링 【오답 체크】 (B) Lambda 함수로 처리하면 불필요한 복잡도 증가 (CUR이 충분) (C) 멤버 계정 태그 활성화는 필요 없음 (관리 계정에서만 활성화) (D) Trusted Advisor는 CUR 수준의 상세 태그 분석 제공 불가 【시험 포인트】 조직 태그 관리 → 관리 계정에서만 활성화 / Organizations CUR → 관리 계정에서 생성

해설

【핵심 용어】 ▸ Transit Gateway — VPC 및 온프레미스 네트워크를 중앙에서 연결 ▸ AWS Resource Access Manager(RAM) — 리소스 공유 서비스 ▸ CloudFormation StackSets — 여러 계정/리전에 스택 배포 ▸ SCP — 권한 제어용이며 리소스 공유 용도 아님 【정답 포인트】 ▸ Transit Gateway 공유 → AWS RAM (전용 기능) ▸ VPC + 첨부 자동 생성 → CloudFormation StackSets ▸ Transit Gateway ID 참조 → 멤버 계정에서 관리 계정 TGW에 첨부 ▸ 자동화 → StackSets로 스케일러블 배포 【오답 체크】 (B) SCP는 권한 정책이며 리소스 공유 기능 없음 (D) 피어링 첨부는 TGW 간 연결이 아닌 VPC 간 피어링용 (E) Service Catalog는 자체 서비스 카탈로그 제공용이며 TGW 공유 메커니즘 아님 【시험 포인트】 Transit Gateway 공유 → AWS RAM / 멀티 계정 자동화 → CloudFormation StackSets

해설

【핵심 용어】 ▸ AWSPrivateMarketplaceAdminFullAccess — Private Marketplace 관리 권한 ▸ SCP (Service Control Policy) — 조직 전체의 권한 제어 ▸ 공유 서비스 계정 — 조달 관리자가 속한 계정 ▸ Organizations 루트 수준 SCP — 모든 계정에 영향 【정답 포인트】 ▸ 공유 서비스 계정에만 역할 생성 → 조달 관리자 전용 ▸ SCP로 전조직 제어 → 다른 계정에서의 접근 차단 ▸ 역할 생성 거부 SCP → 다른 계정에서 동명 역할 생성 불가 ▸ 최소 권한 원칙 → 필요한 계정에서만 생성 【오답 체크】 (A) 모든 계정에 역할 생성 (분산) + PowerUserAccess는 과도한 권한 (B) AdministratorAccess는 권한 경계보다 우선 (권한 경계 무의미) (D) SCP가 공유 서비스 계정에만 적용되어 다른 계정 제어 불가 【시험 포인트】 특정 역할 제한 → Organizations 루트 SCP / 공유 서비스 → 중앙 집중식 관리

해설

【핵심 용어】 ▸ SCP (Service Control Policy) — Allow 리스트 기반의 권한 제어 ▸ FullAWSAccess SCP — 모든 서비스 접근 허용 (기본값) ▸ Allow 명시적 선언 — 명시된 서비스만 접근 가능 ▸ SCP 평가 논리 — 모든 SCP가 Allow해야만 접근 가능 【정답 포인트】 ▸ FullAWSAccess SCP가 여전히 적용 중 → 새 Allow SCP와 함께 OR 평가 ▸ FullAWSAccess 제거 → 새 Allow SCP만 평가 (EC2, S3, DynamoDB만 허용) ▸ SCP 평가 로직 — 모든 적용된 SCP가 Allow해야 접근 가능 ▸ 기본 정책 제거 → 명시적 제한만 적용 【오답 체크】 (A) 허용할 수 있는 서비스가 너무 많아서 모두 거부할 수 없음 (C) FullAWSAccess를 수정하면 다른 OU 영향 (D) 와일드카드 거부는 Allow 명시문과 함께 평가되므로 효과 없음 【시험 포인트】 SCP Allow 리스트 → Allow 명시 + 기본 정책 제거 / 기본 FullAWSAccess 주의

해설

【핵심 용어】 ▸ API Gateway + Lambda — 서버리스 기반 무제한 자동 확장 ▸ 모놀리식 → 마이크로서비스 분리 → Lambda 함수 재사용성 증가 ▸ 다중값 응답 → 정적 IP 관리 (탄력성 제한) ▸ Auto Scaling + Lambda 함수 → 불필요한 복잡성 【정답 포인트】 ▸ 급격한 트래픽 변화 → 서버리스 자동 확장 필수 ▸ 모놀리식 → Lambda로 분리 → 개별 스케일링 가능 ▸ API Gateway → 관리형 서비스, 자동 확장 ▸ Route 53 DNS → API Gateway 엔드포인트로 변경 ▸ 최소 운영 오버헤드 → Lambda + API Gateway만 필요 【오답 체크】 (B) EKS는 클러스터 관리 복잡도 높음 + EC2 비용 지속 (C) Lambda + Lambda 함수 불필요 조합 + Route 53 동적 관리 복잡 (D) ALB는 기본 로드 밸런싱만 제공 (급격한 증가 시 EC2 용량 한계) 【시험 포인트】 급격한 트래픽 증가 → 서버리스 자동 확장 / 모놀리식 → 마이크로서비스 분리

해설

【핵심 용어】 ▸ Cost and Usage Report(CUR) — Organizations 전체의 통합 비용 데이터 ▸ 관리 계정 CUR — 모든 멤버 계정의 비용 포함 ▸ AWS Resource Access Manager — 리소스 공유 (CUR용 아님) ▸ QuickSight — BI 대시보드 시각화 【정답 포인트】 ▸ 조직 전체 비용 → 관리 계정에서 CUR 생성 ▸ CUR에 모든 계정 포함 → 태그/OU별 필터링 가능 ▸ 각 OU 팀 접근 → QuickSight 공유 ▸ Organizations 구조 → OU 태그로 비용 분석 가능 【오답 체크】 (A) Resource Access Manager는 CUR 공유 메커니즘 아님 (대시보드 공유만 가능) (C) 각 멤버 계정별 CUR은 자신의 계정 비용만 포함 (OU 전체 비용 불가) (D) Systems Manager는 비용 관리 서비스 아님 【시험 포인트】 조직 전체 비용 분석 → 관리 계정 CUR / OU별 분석 → 태그 기반 필터링

해설

【핵심 용어】 ▸ AWS DataSync — 온프레미스↔AWS 간 데이터 동기화 (Direct Connect 지원) ▸ Amazon FSx — Windows 파일 공유 용 관리형 파일 시스템 ▸ Amazon EFS — Linux 기반 파일 시스템 (NFS) ▸ AWS Storage Gateway — 온프레미스 애플리케이션의 AWS 클라우드 접근 【정답 포인트】 ▸ Windows 파일 서버 → Windows 환경에 맞는 FSx 선택 ▸ 매일 5GB 데이터 → DataSync의 일일 스케줄 작업 ▸ Direct Connect 활용 → 안정적인 대역폭 보장 ▸ FSx → Windows 파일 공유 프로토콜(SMB) 지원 【오답 체크】 (A) Storage Gateway는 마이그레이션이 아닌 하이브리드 접근용 (C) EFS는 NFS 기반으로 Windows 워크로드 부적합 (D) DataSync + EFS는 Linux용 (Windows 워크로드와 불일치) 【시험 포인트】 Windows → AWS 마이그레이션 → DataSync + FSx / Linux 환경 → EFS

해설

【핵심 용어】 ▸ S3 복제(Replication) — us-east-1에서 두 번째 리전으로 자동 복제 ▸ CloudFront 오리진 그룹 — 다중 원본의 자동 페일오버 ▸ 정적 자산 — 불변 콘텐츠로 복제 최적화 ▸ 오버헤드 최소화 → 자동 메커니즘 활용 【정답 포인트】 ▸ S3 복제 → 자동으로 데이터 동기화 ▸ CloudFront 오리진 그룹 → 자동 페일오버 ▸ 복원력 + 성능 → CloudFront 캐싱 ▸ 최소 운영 → Lambda 함수나 애플리케이션 코드 변경 불필요 【오답 체크】 (A) 애플리케이션 수정 필요 + Route 53 가중치 라우팅은 CloudFront보다 느림 (B) Lambda 함수 관리 오버헤드 + 이벤트 기반 호출 지연 가능 (D) 수동 페일오버 (애플리케이션 코드 수정) → 운영 복잡도 높음 【시험 포인트】 다중 리전 복원력 → S3 복제 + CloudFront 오리진 그룹 / 자동 페일오버

해설

【핵심 용어】 ▸ Application Load Balancer(ALB) — HTTP/HTTPS 기반 로드 밸런싱 ▸ Amazon Aurora MySQL — 고가용성 다중 AZ 데이터베이스 ▸ Multi-AZ 배포 — 자동 페일오버로 고가용성 보장 ▸ CloudFormation — Infrastructure as Code로 반복 가능한 배포 ▸ 3개 AZ — 가용성 영역 간 장애 격리 【정답 포인트】 ▸ 200,000명 일일 사용자 → 확장 가능한 인프라 필수 ▸ 3계층 웹 앱(.NET) → ALB + Auto Scaling 그룹 ▸ MySQL 데이터베이스 → Aurora MySQL Multi-AZ로 안정성 보장 ▸ CloudFormation → 재현 가능한 배포 ▸ Retain 정책 → 스택 삭제 시 DB는 유지 【오답 체크】 (A) Elastic Beanstalk + NLB는 TCP 트래픽용이며, HTTP 앱에 비효율적 (C) 2개 리전은 요구 사항 범위 초과 + 지리근처성은 복잡성 증가 (D) ECS + Spot 인스턴스는 신뢰성 낮음 + RDS(Aurora 아님)는 안정성 부족 【시험 포인트】 .NET 웹앱 + 고가용성 → CloudFormation + ALB + Aurora / 3개 AZ 확산

해설

【핵심 용어】 ▸ CloudFormation StackSets — 다중 계정/리전 배포 ▸ 서비스 관리 권한 — Organizations 통합으로 자동 배포 ▸ 자체 서비스 권한 — 수동으로 각 계정별 배포 (불편) ▸ Organizations 배포 — 조직의 모든 계정에 적용 ▸ 자동 배포 — 새 계정 추가 시 자동 스택 생성 【정답 포인트】 ▸ 관리 계정 StackSets → Organizations 통합 필수 ▸ 서비스 관리 권한 → 신뢰할 수 있는 접근 활성화와 맞음 ▸ 조직 배포 옵션 → 모든 멤버 계정 대상 ▸ 자동 배포 → 새 계정 자동 생성 【오답 체크】 (A) 멤버 계정에서 StackSets 생성 불가능 (관리 계정에서만) (B) 자체 서비스 권한은 각 계정에서 수동으로 권한 설정 필요 (D) "스택" 생성이 아닌 "StackSets" 필요 + 드리프트 감지는 자동 배포 아님 【시험 포인트】 Organizations + StackSets → 관리 계정에서 생성 / 서비스 관리 + 자동 배포

해설

【핵심 용어】 ▸ AWS Application Discovery Agent — 온프레미스 서버의 상세 정보(CPU, RAM, 프로세스, 네트워크) 수집 ▸ AWS Migration Hub — 마이그레이션 프로젝트 중앙 관리, 서버 그룹화, EC2 권장사항 생성 ▸ AWS Systems Manager Agent — 인스턴스 관리 용도(평가 아님) 【정답 포인트】 ▸ "시스템 구성, 성능, 프로세스" → Application Discovery Agent (A) ▸ "애플리케이션으로 그룹화" → Migration Hub (D) ▸ "EC2 인스턴스 타입 권장사항" → Migration Hub (E) 【오답 체크】 (B) Systems Manager Agent는 인스턴스 관리/패치 용도이며, 세부 성능 메트릭 수집에는 부적합 (C) Application Manager는 실시간 애플리케이션 모니터링 및 관리 도구로, 마이그레이션 그룹화 기능 없음 (F) Trusted Advisor는 비용 최적화 검토 도구이지, 마이그레이션 데이터 분석 용도가 아님 【시험 포인트】 AWS 마이그레이션 도구의 역할 구분: Discovery Agent(수집) → Migration Hub(분석/그룹화/권장사항)

해설

【핵심 용어】 ▸ S3 Gateway VPC Endpoint — S3 접근 시 NAT 게이트웨이 우회, 데이터 전송료 제로 ▸ NAT Gateway — 시간당 비용 + 데이터 처리 비용 (1TB/일 = 매월 ~30TB) ▸ VPC Endpoint Policy — 엔드포인트 레벨 접근 제어 【정답 포인트】 ▸ "1TB/일 데이터 S3 검색" + "비용 절감" → NAT 게이트웨이 우회 필수 ▸ S3 Gateway Endpoint는 NAT를 거치지 않으므로 NAT 비용 전액 절감 ▸ 보안 유지: 엔드포인트 정책으로 특정 버킷만 접근 제한 【오답 체크】 (A) NAT 인스턴스도 결국 데이터 전송료 발생 + 운영 부담 증가 (B) EC2를 퍼블릭으로 이동하면 보안 태세 악화(인스턴스 직접 노출) (D) EFS는 S3 대체 스토리지가 아니며, 데이터 전송료 절감 효과 없음 【시험 포인트】 S3 대용량 접근 시나리오 → Gateway Endpoint 선택, 보안 유지하면서 NAT 비용 제거