정답 · 해설

해설

【핵심 용어】 ▸ Cross-Account 역할 가정 — STS AssumeRole로 다른 계정의 리소스 접근 ▸ 신뢰 관계 — 역할 신뢰 정책에서 다른 계정 지정 ▸ 운영 오버헤드 최소 — 복제 불필요, 데이터 일관성 유지 【정답 포인트】 ▸ "모든 호출 최종 완료" → 신뢰성 높은 대기열 필요 ▸ 영업 계정(S3 소유) → IAM 역할 생성 + QuickSight 신뢰 설정 ▸ 마케팅 계정(QuickSight) → 역할 가정으로 원본 S3 접근 ▸ KMS 키는 영업 계정이 소유 → 리소스 기반 정책 필요 (선택 D) ▸ 데이터 복제 불필요 → 운영 복잡도 최소 【오답 체크】 (A) S3 복제 — 페타바이트 규모 복제 비용 + 동기화 오버헤드 (B) SCP 권한 부족 — SCP는 정책이지 S3 버킷 정책 아님 (C) 마케팅 계정 버킷 정책 수정 — 영업 계정 버킷 정책을 수정해야 함 (역순) 【시험 포인트】 다중 계정 접근 = 역할 가정 기반 아키텍처 KMS 권한도 함께 고려 필수

해설

【핵심 용어】 ▸ 이기종 마이그레이션 — SQL Server → MySQL 등 다른 데이터베이스 플랫폼 ▸ AWS Schema Conversion Tool(SCT) — 스키마 변환 도구 ▸ AWS DMS — 데이터 마이그레이션 서비스, 일관성 검증 【정답 포인트】 ▸ "SQL Server Always On" → 다른 DBMS (MySQL)로 변환 필요 ▸ SCT로 스키마 변환 → 복잡한 T-SQL을 MySQL 구문으로 번역 ▸ DMS로 데이터 마이그레이션 → 재결합 및 재시도 지원 ▸ 이기종 마이그레이션의 표준 절차 【오답 체크】 (A) 백업/복원 — 스키마 변환 미포함, SQL Server 기능 호환성 문제 (B) Snowball — 데이터 전송만, 스키마 변환 불가능 (D) DataSync — 스토리지 간 동기화, 스키마 변환 불가능 【시험 포인트】 이기종 = SCT(스키마) + DMS(데이터) 조합 필수 AWS 데이터베이스 마이그레이션의 정석

해설

【핵심 용어】 ▸ AssumeRole — 교차 계정 역할 가정 (STS) ▸ 신뢰 관계 — 역할의 Trust Policy에서 다른 계정 지정 ▸ 최소 권한 원칙 — S3만 접근, 웹 애플리케이션 다른 부분은 보호 【정답 포인트】 ▸ (A) 프로덕션 S3 정책 — 버킷 접근 권한 필수 ▸ (C) 프로덕션 역할 + 개발 계정 신뢰 — 교차 계정 역할 가정 설정 ▸ (E) 개발 계정 그룹 → sts:AssumeRole — 디자인 팀 사용자가 역할 가정 가능 ▸ 3단계: 정책 (A) + 역할 (C) + 신뢰 (E) 【오답 체크】 (B) 개발 계정 정책 — S3 권한이 아니므로 불필요 (D) 개발 계정 역할 + 프로덕션 신뢰 — 반대 방향, 동작 불가 (F) 개발 계정 역할 가정 — 프로덕션이 아닌 개발 계정 역할이므로 목적 불일치 【시험 포인트】 교차 계정 아키텍처 3단계: 1. 리소스 계정(프로덕션)에 정책 생성 (A) 2. 리소스 계정에 역할 생성 + 사용자 계정 신뢰 (C) 3. 사용자 계정(개발)에서 AssumeRole 권한 부여 (E)

해설

【핵심 용어】 ▸ 단일 인스턴스 환경 — 로드 밸런서 없음, 자동 확장 불가 ▸ 로드 균형 환경 — ALB + Auto Scaling 지원 ▸ 용량 구성 수정 — 기존 환경을 최소한의 다운타임으로 변경 【정답 포인트】 ▸ "파일럿 → 프로덕션" 전환 → 기존 구성 활용 ▸ 단일 인스턴스에서 로드 균형으로 변경 → 스케일링 가능 ▸ "운영 오버헤드 최소" → 새 애플리케이션 생성 불필요 ▸ 용량 구성 수정으로 한 번에 처리 가능 【오답 체크】 (A) 새 애플리케이션 생성 — 불필요한 추가 관리, 기존 리소스 폐기 (B) 트래픽 분할 → 두 환경 유지 비용, 복잡성 증가 (D) 환경 재구성 — 합계 CPU는 메트릭 오류, 평균 사용률이 맞음 【시험 포인트】 기존 환경 용량 구성 수정 = 최소 오버헤드 최적화 Elastic Beanstalk 환경 유형 변경의 표준 절차

해설

【핵심 용어】 ▸ 자체 관리 MySQL — On-premise 또는 EC2 자신이 관리 ▸ Amazon RDS — AWS 관리형 데이터베이스 (패치, 백업 자동) ▸ 읽기 복제본 — 읽기 성능 향상을 위한 복제 인스턴스 【정답 포인트】 ▸ "월말 보고" → 읽기 집중적 작업 ▸ "I/O 병목" → EBS 성능 증가로는 한계 있음 ▸ "자체 관리 → RDS" → 관리 부담 감소, 읽기 복제본 지원 ▸ 읽기 복제본으로 읽기 부하 분산 → 쓰기 성능 영향 X 【오답 체크】 (A) EBS 볼륨 GP2 — 읽기 복제 미지원, 자체 관리 성능 한계 (C) CloudWatch + Lambda — 자체 관리 MySQL 동적 변경 불안정 (D) PIOPS 교체 — 루트 볼륨 변경 복잡도 높음, 월말만 필요하므로 비효율 【시험 포인트】 자체 관리 → RDS 마이그레이션 = 관리 간소화 + 읽기 복제본 확장성 월말 부하 대응 = 읽기 복제본 활용

해설

【핵심 용어】 ▸ AWS App2Container — 기존 애플리케이션을 컨테이너로 자동 변환 ▸ ECS Fargate — 관리형 컨테이너, 서버 관리 불필요 ▸ EKS — Kubernetes, 더 복잡한 오케스트레이션 【정답 포인트】 ▸ "복잡한 종속성" + "코드 변경 최소" → App2Container 사용 ▸ "서버 관리 오버헤드 최소" → Fargate 선택 (EC2 관리 불필요) ▸ App2Container → 기존 Java 애플리케이션 자동 컨테이너화 ▸ ECS + Fargate = 서버리스 컨테이너 【오답 체크】 (B) Lambda 마이그레이션 — 복잡한 Java 앱에 부적합, 코드 변경 많음 (C) EKS — Kubernetes 복잡성, 관리 오버헤드 증가 (D) Lambda + ALB — Lambda는 15분 타임아웃, 복잡한 앱 미지원 【시험 포인트】 기존 애플리케이션 컨테이너화: App2Container + ECS Fargate Serverless 컨테이너 = 최소 관리 오버헤드

해설

【핵심 용어】 ▸ 장애 조치(Failover) — 주 region 장애 시 대체 region으로 자동 전환 ▸ Route 53 Failover 라우팅 — 상태 확인 기반 자동 장애 조치 ▸ 비동기 HTTP — 상태 유지 불필요 【정답 포인트】 ▸ "다른 Region으로 장애 조치" → 대체 region에 리소스 배포 필수 ▸ Lambda + API Gateway를 양 region에 배포 필수 ▸ Route 53 Failover 정책 → 자동 상태 확인 + 장애 조치 ▸ 비동기 HTTP → 상태 동기화 불필요 【오답 체크】 (A) us-west-2 엔드포인트만 → us-east-1 Lambda는 공유, 장애 조치 미흡 (B) SQS 도입 — 장애 조치 아키텍처 아님, 구성 복잡화 (C) Global Accelerator — 비용 증가, 과도한 구성 【시험 포인트】 완전한 장애 조치 = 양쪽 region에 Lambda + API Gateway + Route 53 Failover Route 53는 상태 확인으로 자동 전환

해설

【핵심 용어】 ▸ Reserved Instance(RI) 공유 — Organizations 통합 결제에서 계정 간 RI 할인 공유 ▸ RI 공유 비활성화 — 관리 계정에서 특정 계정 제외 가능 ▸ 통합 결제 — 조직 전체 계정이 RI 혜택 수혜 【정답 포인트】 ▸ "RI 공유 금지" → 개별 계정 설정 필요 ▸ Organizations 통합 결제 활용 중 → 관리 계정에서 제어 ▸ Billing Console에서 계정별 RI 공유 설정 가능 ▸ 개별 계정(HR)이 아닌 관리 계정에서 설정 【오답 체크】 (A) 개별 계정 설정 불가능 — 관리 계정에서만 제어 가능 (B) 조직에서 제거 — 통합 결제 이점 상실 (D) SCP 활용 불가 — SCP는 권한 제어, RI 공유 설정 아님 【시험 포인트】 AWS Organizations RI 공유 관리 = 관리 계정의 Billing Console RI 공유 비활성화는 조직 수준의 중앙 제어

해설

【핵심 용어】 ▸ Auto Scaling 프로세스 — Launch, Terminate, HealthCheck, Rebalance 등 ▸ Terminate 프로세스 일시 중단 — 비정상 인스턴스 종료 방지 ▸ Session Manager — Private 서브넷 인스턴스 접근 【정답 포인트】 ▸ "비정상 → 즉시 종료" → Terminate 프로세스 실행 중 ▸ "조사 중" → 인스턴스 보존 필요 ▸ Terminate 프로세스 일시 중단 → 인스턴스 즉시 종료 방지 ▸ Session Manager → 문제 분석을 위한 접근 【오답 체크】 (A) HealthCheck 일시 중단 — 비정상 판단 자체 중단, 근본 원인 파악 불가 (B) 종료 보호 — 개별 인스턴스 설정, Auto Scaling과 상충 가능성 (C) OldestInstance 정책 — 종료 순서만 변경, 여전히 종료됨 【시험 포인트】 Auto Scaling 긴급 상황 = Terminate 프로세스 일시 중단 (인스턴스 보존) HealthCheck vs. Terminate 프로세스의 구분 중요

해설

【핵심 용어】 ▸ AWS Firewall Manager — Organizations 수준의 WAF 규칙 중앙 관리 ▸ Parameter Store — 설정 저장 및 변경 추적 ▸ EventBridge — 변경 사항 자동 감지 및 Lambda 트리거 【정답 포인트】 ▸ "계정/OU 추가 제거" → 파라미터 기반 동적 관리 필요 ▸ "자동 업데이트" → EventBridge + Lambda 조합 ▸ "운영 오버헤드 최소" → Firewall Manager의 중앙 관리 ▸ Parameter Store 변경 → EventBridge 감지 → Lambda 실행 【오답 체크】 (B) Config + CloudFormation — Config 규칙은 WAF 강제 불가, 복잡도 높음 (C) Lambda 환경 변수 — Parameter Store보다 변경 추적 어려움, 수동 관리 (D) Control Tower + KMS — KMS는 설정 저장소 아님, 보안 키 노출 위험 【시험 포인트】 Firewall Manager = Organizations WAF 중앙 관리 도구 Parameter Store + EventBridge + Lambda = 동적 설정 업데이트 패턴

해설

【핵심 용어】 ▸ IAM 데이터베이스 인증 — 암호 대신 임시 IAM 자격 증명 사용 ▸ 자격 증명 손상 최소화 — 암호 제거 → 노출 위험 제거 ▸ Gateway VPC Endpoint — 데이터가 인터넷을 거치지 않도록 【정답 포인트】 ▸ "자격 증명 손상" → 환경 변수 암호 제거 필수 ▸ IAM 데이터베이스 인증 → 암호 불필요, 임시 토큰 사용 ▸ "데이터는 인터넷을 통해 이동하면 안 됨" → Gateway VPC Endpoint ▸ 가장 강력한 보안 + 최소 영향 솔루션 【오답 체크】 (B) HTTPS 적용 — Gateway VPC Endpoint보다 약함, 인터넷 통과 가능 (C) Parameter Store — Secrets Manager보다 기능 부족, 회전 관리 복잡 (D) Secrets Manager + HTTPS — Parameter Store보다 좋지만, Gateway Endpoint가 더 안전 【시험 포인트】 IAM DB 인증 = 자격 증명 손상 최소화의 핵심 Gateway VPC Endpoint = 데이터 유출 방지

해설

【핵심 용어】 ▸ IAM 정책 — ec2:RunInstances 조건으로 인스턴스 유형 제한 ▸ 예방 제어 — 규정 위반 인스턴스 생성 방지 ▸ IAM 그룹 — 개발자 집단 권한 관리 【정답 포인트】 ▸ "인스턴스 유형 제한" → IAM 정책의 조건 기반 통제 ▸ "개발자만" → 특정 IAM 그룹 대상 ▸ "시작 방지" → Config가 아닌 IAM으로 사전 방지 ▸ ec2:RunInstances 액션 + instanceType 조건 【오답 체크】 (A) AWS Config — 사후 컴플라이언스 확인, 사전 방지 불가 (B) 시작 템플릿 — 강제 아님, 개발자가 무시 가능 (D) EC2 Image Builder — 이미지 생성, 인스턴스 유형 제한과 무관 【시험 포인트】 IAM 정책 조건 = 인스턴스 유형 제한의 표준 방식 ec2:RunInstances 액션에서 instanceType 조건 적용

해설

【핵심 용어】 ▸ SCP(Service Control Policy) — 조직 수준의 권한 제어 ▸ AWS Config — 규정 준수 모니터링 ▸ Config Aggregator — 다중 계정 규정 준수 중앙 집계 【정답 포인트】 ▸ (A) 각 계정 Config 규칙 — 누락된 태그 감지 ▸ (B) SCP로 강제 — 미래 생성 시 Project 태그 필수 ▸ (E) Config Aggregator — 조직 전체 미규정 리소스 시각화 ▸ 세 가지 조합: 감지 (A) + 예방 (B) + 집계 (E) 【오답 체크】 (C) Inspector — 보안 취약점 스캔, 태그 확인 아님 (D) IAM 정책 — 계정별 관리 필요, 조직 수준 SCP가 효율적 (F) Security Hub — 보안 결과 집계, 태그 검증 아님 【시험 포인트】 다중 계정 태그 관리 = Config(감지) + SCP(강제) + Aggregator(중앙 집계) SCP가 IAM 정책보다 조직 수준에서 효율적

해설

【핵심 용어】 ▸ Kinesis Data Firehose — 자동 확장 버퍼, 배치 처리 ▸ Amazon ES — 비정형 JSON 데이터, Kibana 시각화 ▸ 자동 확장 — 관리 불필요 【정답 포인트】 ▸ (A) Firehose — 자동 확장 버퍼 + Lambda 변환 ▸ (D) Elasticsearch + Kibana — 반구조화 JSON + 실시간 대시보드 ▸ ES의 Kibana가 QuickSight보다 JSON 시각화에 최적 ▸ Firehose는 관리 불필요, Kinesis Stream은 관리 필요 【오답 체크】 (B) Kinesis 스트림 — 관리 필요 (shard 관리), 자동 확장 아님 (C) Aurora PostgreSQL — 동적 스키마 미지원, 기존 문제와 동일 (E) Neptune — 그래프 데이터베이스, 모니터링 로그용 부적합 【시험 포인트】 반구조화 JSON + 실시간 = Elasticsearch + Kibana 자동 확장 버퍼 = Kinesis Firehose QuickSight는 구조화된 데이터용

해설

【핵심 용어】 ▸ NAT Gateway Charges — 프라이빗 서브넷의 인스턴스가 퍼블릭 인터넷 또는 AWS 서비스로 나가는 트래픽에 대한 요금 (시간당 + 처리된 GB당) ▸ VPC Endpoint — AWS 서비스에 인터넷 게이트웨이나 NAT 게이트웨이를 거치지 않고 비공개로 접근하는 수단 【정답 포인트】 ▸ 프라이빗 서브넷 → Kinesis 데이터 → NAT 게이트웨이를 통과 → 비용 증가 ▸ 인터페이스 엔드포인트 추가 → 트래픽이 VPC 내부에서 처리 → NAT 게이트웨이 우회 → 비용 절감 ▸ 정책 확인 → 애플리케이션이 실제로 엔드포인트를 사용할 수 있도록 권한 설정 【오답 체크】 (A) VPC Flow Logs 분석은 비용 원인을 파악하지만, 근본 해결책이 아님 - 어떤 트래픽을 제거할지 불명확 (B) IAM 권한만으로는 부족함 - 정책(policy)이 없으면 엔드포인트 사용이 제한됨 (C) Detective 사용은 과도한 복잡도 - 이미 Kinesis 사용 패턴이 명확함 【시험 포인트】 NAT Gateway 비용 최적화 → Interface VPC Endpoint 패턴은 SAP-C02의 고전 문제. 프라이빗 서브넷에서 AWS 관리 서비스(Kinesis, S3, DynamoDB 등)로의 트래픽은 반드시 엔드포인트로 우회시킬 것.

해설

【핵심 용어】 ▸ Transit VIF — Direct Connect 게이트웨이에서 Transit Gateway 또는 Virtual Private Gateway로 연결되는 가상 인터페이스 ▸ Direct Connect Gateway — 여러 Transit Gateway 및 VGW를 단일 DX 연결에 연결하는 중앙 허브 ▸ Transit Gateway Peering — 리전 간 TGW 간 통신 활성화 【정답 포인트】 ▸ 고가용성 → DX-A, DX-B 두 연결 필요 → 동일한 DXG 내에서 트랜짓 VIF 2개 ▸ 리전 간 통신 → Transit Gateway Peering (DXG는 리전 간 TGW 라우팅 지원 안함) ▸ VIF 유형 → 트랜짓 VIF 필수 (프라이빗 VIF는 VGW만 지원) 【오답 체크】 (A) 프라이빗 VIF 사용 - Transit Gateway 지원 안함, VGW 전용 (B) DXG를 2개로 분리 - 복잡도 증가, 단일 허브 구조 상실 (C) DXG가 TGW 간 트래픽 라우팅 불가 - 반드시 TGW 피어링 필요 【시험 포인트】 DX Gateway + Transit Gateway + Multi-Region 조합은 SAP-C02의 핵심 네트워킹 주제. Transit VIF 사용, 하나의 DXG로 통합, TGW Peering으로 리전 간 연결하는 패턴을 명확히 구분할 것.

해설

【핵심 용어】 ▸ EventBridge — CloudTrail 이벤트를 감지하고 자동 워크플로우 트리거 ▸ Step Functions — 복잡한 자동화 워크플로우 조율 (ECS보다 간단) ▸ SNS — 사람 알림 채널 【정답 포인트】 ▸ CloudTrail CreateUser 이벤트 감지 → EventBridge 규칙 (A) ▸ 액세스 제거 자동화 → Step Functions (D) - 더 간단하고 관리 용이 ▸ 보안 팀 알림 → SNS (E) - 이메일/SMS 지원, Pinpoint는 대량 메시지용 【오답 체크】 (B) CloudTrail은 S3에 직접 알림 전송 불가 - EventBridge 통합 필수 (C) ECS는 과도한 오버헤드 - Step Functions가 더 간단하고 비용 효율적 (F) Pinpoint는 마케팅/대량 메시지용 - 보안 팀 간단 알림에 부적합 【시험 포인트】 CloudTrail + EventBridge + 자동화 조율 패턴은 SAP-C02의 이벤트 기반 아키텍처 핵심. Step Functions vs ECS 선택에서 '최소 복잡도'를 기준으로 할 것.

해설

【핵심 용어】 ▸ AWS Control Tower — 랜딩 존 및 다중 계정 거버넌스 자동화 ▸ Transit Gateway — 모든 VPC 간 라우팅 중앙화 ▸ IAM Identity Center — 중앙 집중식 SSO + MFA + 권한 집합 관리 【정답 포인트】 ▸ 다중 계정 구조 & 중앙 관리 → Control Tower (A) + Identity Center (D) ▸ MFA 강제 → Identity Center 권한 집합 (Security Hub 아님) ▸ 프라이빗 네트워크 & 선택적 연결 → Transit Gateway (C) + 경로 테이블 설정 ▸ Prod ↔ All, Dev ↔ Staging만 → TGW 경로 테이블로 제어 가능 【오답 체크】 (B) Security Hub는 MFA 강제 불가 - 로그 수집만 함 (E) Control Tower는 라우팅 관리 미지원 - Transit Gateway가 필요 (F) Cognito는 다중 계정 액세스 관리 아님 - 단일 앱 인증용 【시험 포인트】 Control Tower + Transit Gateway + Identity Center는 SAP-C02 다중 계정 아키텍처 표준 스택. 각 서비스의 역할 구분: 거버넌스(CT), 네트워킹(TGW), 액세스(IDC)를 명확히 할 것.

해설

【핵심 용어】 ▸ Stateful EC2 — 상태 저장 인스턴스 (중지 후 시작 가능, 종료/복원은 복잡) ▸ 비용 최적화 — 비운영 시간 중지, 프로덕션은 24h 운영 ▸ 운영상 노력 최소화 — 자동화된 스케줄링 우선 【정답 포인트】 ▸ 개발/테스트 → 저녁 중지, 아침 시작 (스케줄 기반) ▸ 프로덕션 → 항상 실행 (스케줄 무시) ▸ 상태 저장 인스턴스 → stop/start 사용 (RDS도 동일) ▸ 2개 규칙 → 명확한 시간 정의, 복잡한 로직 불필요 【오답 체크】 (A) 매일 1회 규칙은 너무 단순 - 저녁/아침 구분 불가 (C) 종료/복원 방식은 상태 저장 DB에 부적합 - 복잡한 백업/복원 프로세스 (D) 매시간 규칙은 과도한 호출 - 스케줄 관리 복잡도 증가 【시험 포인트】 EventBridge 스케줄링 패턴: 상태 저장 리소스는 stop/start 사용, 종료/복원은 데이터 손실 리스크. 운영상 노력 최소화는 '명확한 시간 + 2개 규칙' 구조 선호.

해설

【핵심 용어】 ▸ API Gateway Account Limit — 계정 전체의 총 RPS 제한 (기본 10,000 RPS) ▸ Per-Method Limit — 각 API 메서드별 RPS 제한 (기본 2,000 RPS) ▸ Lambda Not Invoked — API Gateway 레벨에서 이미 429 반환 【정답 포인트】 ▸ Lambda 미호출 → API Gateway 자체에서 throttling 발생 ▸ 다중 리전 + 프리미엄 고객 3,000 RPS → 계정 전체 한계 초과 가능 ▸ 리전 간 독립 제한 아님 → 계정 제한이 모든 리전의 합산 【오답 체크】 (A) (B) Lambda 미호출이므로 Lambda 제한이 아님 (D) 기본 메서드 제한(2,000)이 아님 - 단일 고객 3,000은 계정 한계 문제 표시 【시험 포인트】 API Gateway 제한 구조: 계정 레벨 제한이 최상위 bottleneck. Lambda는 호출도 안되므로 Lambda 관련 답은 배제. 다중 리전 구조에서 각 리전의 트래픽이 계정 제한에 합산되는 점을 명확히.