정답 · 해설

해설

【핵심 용어】 ▸ Transit Gateway — 다중 VPC/계정 간 중앙 라우팅 ▸ AWS RAM — Transit Gateway를 여러 계정에 공유 ▸ VPC 첨부 — Transit Gateway에 VPC 연결 【정답 포인트】 ▸ Transit Gateway (OU당 1개) → OU 내 모든 VPC 상호 연결 ▸ AWS RAM으로 OU 내 공유 → 계정별 추가 구성 불필요 ▸ 자동 격리 → 다른 OU와 분리 (라우팅 규칙으로) ▸ 100+ 계정도 관리 간편 (VPC 피어링은 O(N²)) 【오답 체크】 (A) VPC 피어링 → 100+ 계정 × O(N²) = 운영 오버헤드 극대 (B) 공유 VPC + 피어링 → 여전히 피어링 필요, 복잡 (D) VPN + 타사 라우팅 → 높은 복잡성, 관리 부담 【시험 포인트】 다중 계정 간 대규모 연결 → Transit Gateway 기본 OU별 격리 + 공유 → OU당 Transit Gateway + RAM

해설

【핵심 용어】 ▸ S3 + KMS — 객체 저장소 + 암호화 키 관리 ▸ 버킷 정책 (HTTPS 강제) — 전송 중 암호화 ▸ 서버 측 암호화 (KMS) — 저장 시 암호화, 키 로테이션 자동 【정답 포인트】 ▸ S3 → 관리형 서비스, 높은 내구성 (99.999999999%) ▸ HTTPS 버킷 정책 → 전송 중 암호화 강제 ▸ KMS 기반 암호화 → 회사 관리 키, 자동 로테이션 지원 ▸ 대용량 문서 → S3 최적 (대용량 객체 저장) 【오답 체크】 (A) Storage Gateway — 온프레미스 연결용, 관리형도 아님, 파일 크기 제한 (C) DynamoDB → 키-값 데이터베이스, 대용량 문서 부적합 (D) EBS → 인스턴스 관리 필요, 관리형 아님, 내구성 낮음 【시험 포인트】 관리형 서비스 + 큰 문서 → S3 기본 암호화 (전송+저장) + 키 관리 → KMS + HTTPS

해설

【핵심 용어】 ▸ AWS WAF SQL Injection 규칙 그룹 — SQL 주입 탐지/차단 (AWS 관리) ▸ 웹 ACL → WAF 정책 적용 ▸ ALB 연결 → 앞단에서 공격 차단 【정답 포인트】 ▸ WAF SQL 데이터베이스 규칙 그룹 → SQL 주입 시그니처 자동 감지 ▸ 명확한 규칙 → SQL 주입 차단, 정상 트래픽 허용 ▸ ALB 직접 보호 → CPU 사용률 증가 전에 공격 차단 ▸ AWS 관리 규칙 → 운영 효율성 (자동 업데이트) 【오답 체크】 (A) WAF만 — 차단 규칙 없음 (모니터링만) (B) Bot Control — 봇 공격 탐지, SQL 주입 탐지 아님 (D) IP 블랙리스트 → 공격자 IP 회피 가능, 반응형 (사후 대응) 【시험 포인트】 SQL 주입 공격 → WAF SQL Injection 규칙 그룹 표준 차단이 아닌 모니터링 → 실질적 보호 안 됨

해설

【핵심 용어】 ▸ AWS IoT Core 도메인 구성 — 각 리전에 독립적 엔드포인트 ▸ Route 53 상태 확인 → 리전 간 장애조치 ▸ DynamoDB 글로벌 테이블 — 다중 리전 데이터 복제 【정답 포인트】 ▸ 도메인 구성 (양 리전) → 독립적 IoT 수집 ▸ Route 53 페일오버 라우팅 → 장애 시 자동 전환 ▸ 상태 확인 → IoT Core 가용성 모니터링 ▸ DynamoDB 글로벌 테이블 → 자동 다중 리전 복제 【오답 체크】 (A) 페일오버만 → 일반적 DR, Route 53 상태 확인 없음, Aurora 필요 없음 (B) 지연 시간 기반 → 페일오버 아님 (능동), MemoryDB는 캐시 (DynamoDB 대체 아님) (D) 도메인 구성 없음 → IoT 데이터 엔드포인트 부족, DynamoDB 스트림 복잡 【시험 포인트】 비즈니스 연속성 = 2리전 수집 + 자동 장애조치 DynamoDB 글로벌 테이블 = 관리형 다중 리전 동기화

해설

【핵심 용어】 ▸ 교차 계정 역할 가정 — Organizations의 다중 계정 접근 ▸ 세분화된 접근 제어 (속성 수준) — DynamoDB LeadingKeys, AttributeNames ▸ IAM 정책 조건 → 특정 속성만 허용 【정답 포인트】 ▸ 재무 팀 계정에 IAM 역할 (세분화 조건 포함) ▸ 신뢰 설정 → 마케팅 팀 계정에서 가정 가능 ▸ 마케팅 팀이 역할 가정 → 제한된 속성만 접근 ▸ 정책 기반 세분화 → DynamoDB 수준 제어 【오답 체크】 (A) SCP — 정책 제어, DynamoDB 세분화 속성 필터링 불가 (C) 리소스 기반 정책 — 대상이 명시되어야 하는데, 마케팅 팀의 역할 ARN 필요 (번거로움) (D) 권한 경계 — 상한선만 설정, 적극적 허용 불가, 역할 신뢰 구성 미흡 【시험 포인트】 교차 계정 + 속성 수준 제어 → 역할 신뢰 + IAM 정책 조건 DynamoDB 세분화 → 정책 조건으로 속성 명시

해설

【핵심 용어】 ▸ Multi-Region Access Point — 다중 리전 자동 라우팅 ▸ Cross-Region Replication (CRR) — 양방향 동기화 ▸ S3 Versioning — CRR 버전 추적 【정답 포인트】 ▸ (A) Multi-Region Access Point → 단일 엔드포인트로 리전 자동 선택 ▸ (B) 양방향 CRR → 두 버킷 간 자동 동기화 ▸ (E) Versioning → CRR 필수 (버전 추적, 충돌 해결) ▸ 세 조합만으로 완전 자동화, 낮은 오버헤드 【오답 체크】 (C) 애플리케이션 수정 → 낮은 가용성 (하나 버킷 장애 시 데이터 손실) (D) Lifecycle 규칙 — 스케줄 기반, 실시간 동기화 아님 (F) Lambda + 이벤트 — CRR보다 복잡, 운영 오버헤드 증가 【시험 포인트】 다중 리전 동시 접근 → Multi-Region Access Point 필수 자동 동기화 → CRR (Lambda/Lifecycle은 대안) CRR은 Versioning 필수 기능

해설

【핵심 용어】 ▸ AWS IoT Core — MQTT 프로토콜 지원, 디바이스 수집 ▸ Amazon DocumentDB — MongoDB 호환, 관리형 ▸ AWS Step Functions + Lambda — 주기적 배치 작업 ▸ CloudFront + S3 — 정적 보고서 제공 【정답 포인트】 ▸ (B) AWS IoT Core → MQTT 직접 지원, 관리형, 5분 주기 수집 최적 ▸ (D) DocumentDB → MongoDB 호환 (앱 변경 최소), 관리형 ▸ (E) Step Functions + Lambda → 주기적 배치 (120-600초), 낮은 비용 ▸ CloudFront 제공 → 항상 실행 웹앱 대체 (가용성) 【오답 체크】 (A) Lambda 직접 연결 — MQTT 연속 연결 부적합 (C) EC2 MongoDB — 관리형 아님, 운영 오버헤드 (F) EKS + EC2 — 배치 작업에 과한, 높은 비용/오버헤드 【시험 포인트】 IoT 수집 → AWS IoT Core (MQTT 표준) 주기적 배치 → Step Functions (서버리스) 관리형 우선 → DocumentDB (자체 관리 MongoDB 불가)

해설

【핵심 용어】 ▸ AWS Outposts — 온프레미스에 AWS 인프라 설치 (규제/지연) ▸ Snowball Edge Compute — 제한된 네트워크 환경에서 컴퓨팅 ▸ 일관된 개발자 경험 → 동일한 AWS 도구/API 【정답 포인트】 ▸ Outposts → 규제 (데이터 위치) + 지연 (단일 숫자 ms) 해결 ▸ AWS 관리형 인프라 → 개발자 경험 일관성 유지 ▸ Snowball Edge Compute → 공장(제한 네트워크)에서 AWS 워크로드 실행 ▸ 하이브리드 + 엣지 모두 커버 【오답 체크】 (A) Direct Connect — 규제/지연 해결 안 함 (여전히 클라우드) (B) Snowball Storage — 스토리지만, 컴퓨팅 아님, Wavelength는 공장(이동식 불가) (D) Local Zone — 특정 도시만 가용, 모든 국가 지원 안 함 【시험 포인트】 온프레미스 규제 요구 → Outposts (AWS를 지점에 설치) 공장 엣지 환경 → Snowball Edge Compute 일관된 개발자 경험 = AWS API/도구 동일

해설

【핵심 용어】 ▸ CloudFront + 커스텀 헤더 — 봇 공격 필터링 ▸ AWS WAF + 규칙 그룹 — 공격 탐지/차단 ▸ 비용 효율성 — DynamoDB 부하 감소 【정답 포인트】 ▸ (A) CloudFront + 커스텀 헤더 → 직접 ALB 접근 차단, 봇 공격 완화 ▸ (E) WAF 규칙 그룹 → CloudFront에서 공격 패턴 차단 (SQL 주입 등) ▸ 두 조합 → 공격 전 DDoS/봇 필터링, 인프라 보호 ▸ 낮은 비용 (CloudFront 캐싱, WAF 기본 규칙) 【오답 체크】 (B) 다중 리전 → 공격 방지 아님, 비용 증가 (매니저+동기화) (C) ECS Auto Scaling + DAX — 공격은 막지 못함, 부하 증가 (D) ElastiCache — DynamoDB 부하 감소만, 공격 방지 아님 【시험 포인트】 공격 방지 우선 → WAF는 필수 비용 효율성 + 공격 경감 → CloudFront 자체 필터링 A+E 조합 = 공격 전 필터링 + 정책 기반 차단

해설

【핵심 용어】 ▸ CloudFront 원본 그룹 — 다중 원본 자동 장애조치 ▸ 원점 장애조치 → HTTP 오류 시 자동 전환 ▸ S3 정적 웹사이트 — 커스텀 오류 페이지 【정답 포인트】 ▸ 원본 그룹 (ALB + S3) → ALB 503 감지 시 S3로 자동 전환 ▸ CloudFront 레벨에서 오류 처리 → 즉각적 응답 (Route 53 상태 확인보다 빠름) ▸ 운영 오버헤드 최소 → 자동화된 장애조치 ▸ Route 53은 DNS 레벨 (느림), CloudFront는 HTTP 레벨 (빠름) 【오답 체크】 (A) Route 53 페일오버 — DNS 레벨 (느린 전환), 사용자 정의 오류 페이지 지연 (B) 별도 배포 → 관리 복잡성 (두 개 배포), 비용 증가 (D) CloudFront 함수 — 응답 검증만, 원본 전환 불가 【시험 포인트】 503 오류 → CloudFront 원본 그룹 자동 장애조치 표준 즉시 응답 → CloudFront HTTP 레벨 감지 필수

해설

【핵심 용어】 ▸ ECS Fargate — 서버리스 컨테이너 실행, 인프라 관리 불필요 ▸ NFS 호환성 — EFS는 NFS v4 지원, EBS/FSx Lustre는 미지원 【정답 포인트】 ▸ 요구사항: "기반 인프라 프로비저닝/관리 불필요" → Fargate 필수 ▸ NFS 호환: EFS만 NFS v4 파일 공유 지원 ▸ Fargate는 EFS 네이티브 통합, 작업 정의로 직접 마운트 가능 【오답 체크】 (B) FSx Lustre는 HPC 워크로드용, NFS 지원 안 함 (C) EC2 시작 유형은 인프라 관리 필요 → 요구사항 미충족 (D) Multi-Attach EBS는 블록 스토리지, 파일 공유 용도 부적합 【시험 포인트】 패턴: "서버리스 + NFS 파일 공유" → Fargate + EFS 조합 매핑: 컨테이너 + 파일 공유 = EFS의 황금 패턴

해설

【핵심 용어】 ▸ 가중 라우팅 — 목표 그룹/레코드에 트래픽 비율 할당(10%:90%) ▸ 고정성(Stickiness) — 같은 고객이 세션 내 동일 버전 유지 【정답 포인트】 ▸ 요구사항: 10% 트래픽만 신규 로직 + 고객별 버전 일관성 ▸ 가중 대상 그룹: ALB 레벨에서 트래픽 분산(10%:90%) ▸ 고정성: 쿠키 기반 세션 유지로 고객 버전 일관성 보장 【오답 체크】 (A) ALB 2개 + Route 53 가중 라우팅은 과복잡, ALB 레벨에서 처리 가능 (C) 롤링 업데이트는 배포 전략일뿐, 트래픽 비율 제어 불가 (D) 새 ASG + LOR은 버전 고정성 보장 불가, 라운드로빈만 제공 【시험 포인트】 패턴: "트래픽 비율 + 고객 일관성" → 가중 대상 그룹 + Stickiness 매핑: ALB 레벨 가중치 분배는 Route 53보다 유연

해설

【핵심 용어】 ▸ FSx for Windows File Server — 인-플레이스 업그레이드 지원 ▸ 처리량 스케일링 — 다운타임 동안 스토리지 타입/처리량 변경 가능 【정답 포인트】 ▸ FSx Windows는 인-플레이스 변경 지원: 유지보수 기간 중 직접 업그레이드 ▸ 최소 관리 노력: 단순 콘솔 업데이트, 재배포 불필요 ▸ DNS 별칭 유지: 파일 시스템 재생성 없음 【오답 체크】 (A) Backup/복원: 불필요한 추가 단계, 비용 증가, 관리 복잡 (C) DataSync: 대용량 데이터 이동 오버헤드, 관리 비용 증가 (D) 섀도 복사: 백업 목적일뿐, 성능 업그레이드 불가 【시험 포인트】 패턴: "FSx 성능 업그레이드" → 인-플레이스 변경 먼저 확인 매핑: 최소 노력 = 관리형 서비스의 네이티브 기능 활용

해설

【핵심 용어】 ▸ S3 Multi-Region Access Point — 다중 리전 S3 버킷 통합 액세스 ▸ 양방향 CRR — 양쪽 리전에서 쓰기 가능, 자동 동기화 【정답 포인트】 ▸ 다중 리전 읽기/쓰기: Multi-Region Access Point 필수 ▸ 양방향 CRR: 리전 간 데이터 일관성 자동 유지 ▸ 운영 오버헤드 최소: 데이터 동기화 자동화, 리전별 애플리케이션 로직만 필요 【오답 체크】 (A) CloudFront는 읽기 전용, 쓰기 불가 → 요구사항 미충족 (C) 단방향 CRR: 한 리전만 쓰기 가능 → 양쪽 리전 쓰기 불가 (D) 게이트웨이 엔드포인트는 VPC 내부용, 리전 간 통신 불가 【시험 포인트】 패턴: "다중 리전 읽기/쓰기" → Multi-Region Access Point 매핑: 양방향 동기화 = 양방향 CRR + MRAP

해설

【핵심 용어】 ▸ HPC — 고성능 컴퓨팅, 컴퓨팅 최적화 인스턴스(c5) 필수 ▸ Spot vs On-Demand — Spot은 수시 중단, 게임은 안정성 중요 ▸ 자주 변경 리더보드 — Redis 캐시 필요 【정답 포인트】 ▸ 컴퓨팅 최적화: HPC 워크로드는 c5 시리즈 (m5는 범용) ▸ On-Demand 선택: Spot은 게임 가용성 위험 → 안정성 필요 ▸ 리더보드: 자주 변경 데이터 → Redis 캐시, DynamoDB 미적합 【오답 체크】 (A) m5.large: 범용, 컴퓨팅 최적화 아님 (B) OpenSearch: 검색 엔진, 리더보드 추적에 부적합 (D) DynamoDB: 높은 지연 시간, 실시간 리더보드에 부적합 【시험 포인트】 패턴: "HPC + 실시간 데이터" → c5 + On-Demand + Redis 매핑: 게임 가용성 > 비용 → Spot 배제

해설

【핵심 용어】 ▸ 서버리스 — 운영 오버헤드 최소화 ▸ 버스트 트래픽 — 금요일 집중, 예약 스케일링 어려움 ▸ 분석 쿼리 — 월간 보고서, 실시간 아님 【정답 포인트】 ▸ (C) CloudFront + Lambda: 서버리스, 자동 스케일, 관리 최소 ▸ (E) S3 + Athena: 저비용 분석, 월간 보고서 적합 ▸ 조합: 프론트엔드 정적, 백엔드 서버리스, 데이터 저가 스토리지 【오답 체크】 (A) EC2 On-Demand: 수동 스케일링 필요, 관리 부담 (B) ECS + 예약 스케일: 버스트 패턴 예측 어려움 (D) Redshift: 지속적 비용, 월간 분석에 과도함 【시험 포인트】 패턴: "버스트 + 분석" → 서버리스 + 저비용 데이터레이크 매핑: 프론트엔드 정적/백엔드 서버리스/분석 Athena

해설

【핵심 용어】 ▸ CloudTrail — S3 API 레벨 감사, 5년 보관 ▸ 삭제 이벤트 알림 — EventBridge + SNS (S3 네이티브 이메일 없음) ▸ 5년 보관 — Lifecycle 정책으로 자동 관리 【정답 포인트】 ▸ (A) CloudTrail: S3 데이터 이벤트 감사 로깅, 규정 준수 ▸ (D) EventBridge + SNS: 객체 삭제 감지 → 알림 (S3 native) ▸ (F) 별도 버킷 + Lifecycle: 로그 자동 보관/아카이브 ▸ 비용 효율: CloudTrail < S3 Access Log, Lifecycle로 오래 보관 【오답 체크】 (B) S3 Access Log: 기본 로깅, CloudTrail보다 낮음 (C) SES 직접: S3 네이티브 메일 기능 없음 (E) Timestream: 비용 높음, 5년 보관에 부적합 【시험 포인트】 패턴: "감사 + 알림 + 장기 보관" → CloudTrail + EventBridge+SNS + Lifecycle 매핑: 삭제 감지 = 이벤트 기반, S3 서비스 직접 이메일 없음

해설

【핵심 용어】 ▸ Direct Connect 게이트웨이 — 단일 DX로 다중 리전 VPC 연결 ▸ 공개 VIF — AWS 퍼블릭 서비스(S3, DynamoDB 등) 액세스 【정답 포인트】 ▸ (A) DX Gateway: 기존 DX 재사용, 다른 2개 리전 연결, 비용 효율 ▸ (D) 공개 VIF: 퍼블릭 서비스 접근, AWS 내부 라우팅 ▸ 최소 비용: 추가 DX 불필요, 게이트웨이로 통합 【오답 체크】 (B) 추가 DX: 고비용, 유지보수 복잡 (C) 프라이빗 VIF 위 VPN: 비효율적, 지연 시간 증가 (E) VPC 피어링: 리전 간 피어링 가능하지만 DX 게이트웨이가 더 효율적 【시험 포인트】 패턴: "다중 리전 하이브리드 + 퍼블릭 서비스" → DX Gateway + Public VIF 매핑: 하나의 연결로 다중 리전 = 게이트웨이 패턴

해설

【핵심 용어】 ▸ Firewall Manager — 중앙에서 다중 계정 WAF 정책 배포 ▸ AWS Config — 리소스 설정 추적, 규정 준수 확인 ▸ 조직 전체 기능 — Firewall Manager 전제 조건 【정답 포인트】 ▸ (A) AWS Config: 리소스 상태 감시, 규정 준수 기록 ▸ (C) 조직 기능 활성화: Firewall Manager 전제 ▸ (D) Firewall Manager: 중앙 WAF 규칙 배포, OWASP 보호 ▸ 조합: 규정 준수 기록 + 중앙 정책 + 다중 계정 【오답 체크】 (B) GuardDuty: 위협 탐지, WAF 규칙 배포 아님 (E) Shield Advanced: DDoS 보호, WAF 규칙 배포 아님 (F) Security Hub: 보안 이슈 수집, 규칙 배포 기능 없음 【시험 포인트】 패턴: "다중 계정 WAF 배포" → Firewall Manager + 조직 기능 + Config 매핑: 중앙 관리 = Firewall Manager 필수

해설

【핵심 용어】 ▸ SAML 어설션 — IdP에서 생성한 인증 데이터 ▸ AssumeRoleWithSAML — STS API, 역할 획득 ▸ 신뢰 정책 — IAM 역할이 SAML 공급자 신뢰 【정답 포인트】 ▸ (B) 신뢰 정책: 역할 > SAML 공급자 신뢰 설정 필수 ▸ (B) IdP 그룹: 사용자가 페더레이션 그룹 멤버여야 함 ▸ (C) AssumeRoleWithSAML: 웹 포털이 올바른 API 호출 ▸ (E) SAML 어설션: IdP가 사용자-역할 매핑 올바르게 【오답 체크】 (A) IAM 사용자 권한: 페더레이션 시 IAM 사용자 불필요 (D) DNS 도달: 일방향, IdP → AWS 필수 아님 【시험 포인트】 패턴: "SAML 인증 실패" → 신뢰 정책 + 그룹 멤버십 + 어설션 매핑 매핑: 페더레이션 = 웹 포털 > AssumeRoleWithSAML > 역할 신뢰