정답 · 해설

해설

【핵심 용어】 ▸ AWS Organizations — 단일 청구서, 다중 계정 거버넌스 ▸ Service Control Policy(SCP) — 권한 상한선(거버넌스 강제) 【정답 포인트】 ▸ (B) 단일 Organization: 모든 LOB 계정을 부모 조직에 연결 → 통합 청구 + 비용 분류 ▸ (D) SCP: 서비스 제한(거버넌스) 동시에 LOB 계정의 명시적 관리자 권한 유지 가능 【오답 체크】 (A) 각 LOB마다 조직: 단일 청구서 불가능 (C) Service Quotas: 비용 제한 아님, 리소스 사용량만 제한 (E) 통합 청기: Organizations 전제 필요 【시험 포인트】 다중 계정 거버넌스 + 비용 추적에서 Organizations(단일) + SCP(제한)의 조합이 핵심입니다.

해설

【핵심 용어】 ▸ Health Check — Route 53의 자동 페일오버 전제 조건 ▸ Evaluate Target Health — 별칭 레코드가 가중치 상태를 인식 【정답 포인트】 ▸ (D) 대상 상태 평가 미활성: 별칭 레코드가 기본 웹 서버 상태를 무시함 → 페일오버 안 됨 ▸ (E) Health Check 미구성: 서버 중지 감지 불가능 → Route 53이 리디렉션 판단 불가 【오답 체크】 (A) 가중치: 페일오버와 무관, 트래픽 분배에만 영향 (B) 보조 서버 1개 실패: 2개 중 1개 정상이면 충분 (C) 지연시간 + 가중치: 조합 가능 (별칭 레코드 사용) 【시험 포인트】 Route 53 페일오버는 (1) Health Check 구성 + (2) Evaluate Target Health 활성화 둘 다 필요합니다.

해설

【핵심 용어】 ▸ Kinesis Data Firehose — 자동 스케일링 수집(서버리스) ▸ Athena — S3의 대규모 분석 쿼리(유지보수 불필요) ▸ Parquet — 컬럼 저장(쿼리 효율) 【정답 포인트】 ▸ (B) IoT Core → Firehose(자동 확장) → Lambda → S3(Parquet) → Athena ▸ Firehose: 버퍼링 및 자동 배치 → 데이터 손실 없음, 10,000 센서 처리 가능 ▸ Athena: 쿼리 기반 비용, 서버 유지보수 불필요 【오답 체크】 (A) Aurora에 매초 삽입: 과도한 쓰기 부하, 비용 높음 (C) (D) Flink: Lambda보다 복잡, 추가 인프라 관리 【시험 포인트】 "지속적 수집 + 유지보수 최소화 + 비용 최적"에서 Firehose(자동 스케일) + Athena(서버리스)가 최적입니다.

해설

【핵심 용어】 ▸ 상태 검사 분리 — ALB(인스턴스만), Route 53(애플리케이션 전체) ▸ ElastiCache — 데이터베이스 부하 절감 【정답 포인트】 ▸ (B) 상태 검사 분리: ALB는 간단한 HTML(웹 서버만 확인) / Route 53은 제품 페이지(DB 포함 전체 기능) → DB 부하 감지 ▸ (E) ElastiCache: 쿼리 응답 시간 단축 → DB 부하 감소 【오답 체크】 (A) 읽기 복제본: 제품 카탈로그는 읽기 위주지만 Route 53 상태 검사 필요 (C) TCP 검사: DB 상태를 감지하지 않음 (D) CloudWatch 알람: 복구 불가능(RDS Auto Failover 이미 활성) 【시험 포인트】 Auto Scaling이 부하 없는 인스턴스를 교체하는 이유는 상태 검사가 DB 부하를 반영하지 않기 때문입니다.

해설

【핵심 용어】 ▸ EKS on Outposts 로컬 클러스터 — 온프레미스 완전 자체 관리 ▸ EKS Anywhere — AWS 관리 없음, 독립형 【정답 포인트】 ▸ (A) Outposts + 로컬 클러스터: AWS 관리형이면서 온프레미스 제어/데이터 평면 = "AWS 관리 + 자체 호스팅" ▸ Outposts: 하드웨어 구매/설치 필요하지만 AWS에서 관리 【오답 체크】 (B) EKS Anywhere: AWS 관리형이 아님, 완전 독립형 (C) 확장 클러스터: 제어 평면을 EKS(AWS)에서 실행, 요구사항 미충족 (D) Outposts + Anywhere: 중복, Anywhere만으로 충분 【시험 포인트】 "AWS 관리형 + 온프레미스 호스팅"의 키는 Outposts입니다. EKS Anywhere는 순수 자체 관리형입니다.

해설

【핵심 용어】 ▸ Transit Gateway + RAM — 중앙 허브 기반 다중 VPC 네트워킹 ▸ RAM 리소스 공유 — Organizations 계정 간 리소스 공유 【정답 포인트】 ▸ (B) Transit Gateway: 모든 개발 계정의 VPC를 중앙 허브로 연결 ▸ RAM: 공유 서비스 계정의 TGW를 개발 계정과 공유 → 오버헤드 최소 ▸ 네트워킹: 라우팅 테이블 설정(간단함) 【오답 체크】 (A) RAM으로 DB 직접 공유: DB 엔드포인트 공유 불가능 (C) PrivateLink + ALB: DB 접속이 아닌 서비스 노출용 (D) VPN: 복잡도 높음, 각 계정마다 VPN 설정 【시험 포인트】 다중 계정 환경에서 "리소스 공유 + 네트워킹"은 Transit Gateway(중앙 허브)가 최적입니다.

해설

【핵심 용어】 ▸ Cost Anomaly Detection — ML 기반 비용 이상 탐지 ▸ AWS services 모니터 — 서비스별 비용 변화 추적 【정답 포인트】 ▸ (D) AWS services 타입: 사용하지 않는 개별 리소스(예: EC2)의 비용 증가 감지 ▸ Anomaly Detection: "정상 패턴 대비 이상"을 ML로 자동 감지 → 구체적 알림 ▸ 구독: 일일 요약 + 임계값 기반 자동 알림 【오답 체크】 (A) (B) CloudWatch 정적 임계값: 테스트 증감 패턴 감지 불가 (C) Linked account 타입: 계정별 전체 비용 추적(서비스별 아님) 【시험 포인트】 "비용 증가 + 원인 식별"은 정적 임계값이 아닌 ML 기반 Anomaly Detection이 필수입니다.

해설

【핵심 용어】 ▸ EFS Multi-AZ — 고가용성 공유 스토리지 ▸ Provisioned Throughput — 처리량 보장 ▸ Cross-Region 복제 — RPO < 1시간 【정답 포인트】 ▸ (A) EFS: "모든 인스턴스 공유" + "100GB(EFS 범위)" 요구 충족 ▸ 75 MiBps: 피크 시 225 MiBps 필요 → 버스트 가능(최대 500 MiBps) ▸ 리전 간 복제: AWS Backup으로 자동 가능, RPO < 1시간 달성 【오답 체크】 (B) Lustre: HPC/배치 분석용, "모든 인스턴스 공유"에 최적화 아님 (C) gp3 EBS: Multi-Attach는 2개만 가능, 다중 인스턴스 공유 불가 (D) OpenZFS: DataSync 10분 RPO 가능하지만 FSx for Lustre보다 복잡 【시험 포인트】 "다중 인스턴스 공유 + 피크 처리량 + 리전 간 복제"는 EFS가 최적입니다.

해설

【핵심 용어】 ▸ Snowcone — 소형 엣지 디바이스, EC2 지원 ▸ FTP 서버 — 센서의 기본 프로토콜 지원 【정답 포인트】 ▸ (C) Snowcone EC2: Snowcone에서 EC2 실행 → FTP 서버 설치 ▸ 센서 FTP 업로드: EC2 FTP 서버로 직접 업로드 → 로컬 네트워크 수집 ▸ S3 최종 저장: Snowcone이 AWS에 도착하면 S3로 로드 【오답 체크】 (A) DataSync: NFS 언로드(센서 FTP 미지원) → 추가 변환 필요 (B) 쉘 스크립트: 센서의 주기적 다운로드 필요하지만 FTP 서버 없음 (D) FSx: Snowcone에서 지원하지 않음, EBS 최종 로드도 S3 아님 【시험 포인트】 "센서 FTP만 지원"이라는 제약에서 FTP 서버(EC2 on Snowcone)를 직접 구축하는 것이 가장 간단합니다.

해설

【핵심 용어】 ▸ S3 Event + Lambda — 자동 데이터 분류 ▸ S3 버킷 정책 — 계정별 액세스 제어 【정답 포인트】 ▸ (B) Lambda: 중앙 CUR를 자동으로 파싱 → 멤버별 접두사로 분류 ▸ S3 정책: 각 계정이 자신 접두사만 읽기 가능 → Athena로 쿼리 ▸ 자동화: 신규 데이터 도착 시 자동 처리 【오답 체크】 (A) RAM: CUR 데이터(S3 객체) 공유 불가능 (C) Cost Explorer: Athena 쿼리 기능 없음, 생성된 보고서는 정적 (D) 각 계정마다 CUR: Organizations 통합 CUR의 이점 상실 【시험 포인트】 "중앙 CUR + 계정별 분류 + Athena 쿼리"는 S3 Event/Lambda + 버킷 정책이 최적입니다.

해설

【핵심 용어】 ▸ Static Site-to-Site VPN — 간단한 페일오버 ▸ BGP 자동 페일오버 — 경로 자동 전환 【정답 포인트】 ▸ (D) VPN: Direct Connect 외 보조 경로 제공 → 고가용성 ▸ 정적 VPN: 낮은 복잡도, 비용 최소(동적 VPN 불필요) ▸ BGP: 자동 페일오버, MACsec 없이도 보안 (VPN 암호화) 【오답 체크】 (A) 동적 VPN: 정적으로 충분, 비용 증가 (B) 두 번째 DX: 1→2 Gbps이지만 매우 비싸고 필수 아님 (C) 다중 VIF: DX 내 로드밸런싱이지 보조 경로 아님 【시험 포인트】 "고가용성 + 비용 최적"은 Direct Connect(주) + VPN(백업) 조합입니다.

해설

【핵심 용어】 ▸ S3 — 대규모 바이너리 파일 저장소(확장성) ▸ DynamoDB — 메타데이터(프로필 + S3 참조) 【정답 포인트】 ▸ (B) DynamoDB: 사용자 프로필(구조화됨) 저장 ▸ S3: 4GB 비디오(바이너리) 저장 → 확장 가능, 애플리케이션 성능 영향 없음 ▸ S3 키 참조: DynamoDB에 저장하여 연결 【오답 체크】 (A) base64 DB: 4GB를 base64하면 5GB+ → DB 과부하, 성능 저하 (C) Keyspaces: DynamoDB보다 복잡, 비용 높음 (D) DynamoDB base64: (A) 와 동일한 성능 문제 【시험 포인트】 "대용량 파일 + 신속 확장 + 성능 보호"는 S3(파일) + DynamoDB(메타데이터) 분리입니다.

해설

【핵심 용어】 ▸ 시간당 백업 — RPO < 100분 달성 ▸ KMS 정책 — 백업 역할 권한 필수 【정답 포인트】 ▸ (A) 새 IAM 역할: 백업용 권한 분리 ▸ 시간당 일정: 1시간 < 100분 RPO → 요구사항 충족 ▸ KMS 정책: 역할이 암호화 키 사용 가능 【오답 체크】 (B) 30분: 가능하지만 복잡(cron), 기존 계획 무시 (C) 지속적 백업: RPO 분 단위이지만 EFS 미지원 (D) 교차 리전: RPO 아님, 재해 복구용 【시험 포인트】 "100분 RPO + KMS 암호화"에서 시간당 백업(60분 < 100분)이 최소 요구사항입니다.

해설

【핵심 용어】 ▸ MFA 기반 권한 거부 — IAM 정책으로 MFA 강제 ▸ STS 임시 자격증명 — MFA 검증 후 발급 【정답 포인트】 ▸ (D) 정책: MFA 없으면 모든 S3 작업 거부 ▸ STS: `aws sts get-session-token --serial-number ... --token-code ...` ▸ 프로필: 임시 토큰으로 S3 CLI 실행 【오답 체크】 (A) 버킷 정책: MFA 프롬프트만 → 접근 차단 아님 (B) 신뢰 정책: 그룹에 신뢰 정책 없음 (C) 액세스 키만: STS 없이 액세스 키로 작업 가능 → MFA 우회 【시험 포인트】 "MFA 강제 + CLI 사용"은 (1) 정책으로 거부 + (2) STS로 임시 토큰 발급 조합입니다.

해설

【핵심 용어】 ▸ Windows Web Application Migration Assistant — .NET 마이그레이션 자동화 ▸ Elastic Beanstalk — 관리형(코드 변경 불필요) 【정답 포인트】 ▸ (B) Migration Assistant: Windows IIS 앱 자동 마이그레이션(코드 변경 없음) ▸ Elastic Beanstalk: 배포/스케일링 자동, 인프라 관리 불필요 ▸ 60개 앱: 빠른 처리 가능 【오답 체크】 (A) (D) Refactoring: 리팩터링 필요 → 코드 변경, 시간 증가 (C) EC2: 인프라 관리 필요 → 요구사항 불충족 【시험 포인트】 ".NET 레거시 + 코드 변경 없음 + 빠른 마이그레이션"은 Windows Migration Assistant + Elastic Beanstalk입니다.

해설

【핵심 용어】 ▸ AWS Batch — 배치 작업용 서비스 ▸ Spot Instances — 비용 최소화 【정답 포인트】 ▸ (B) Batch: 배치 작업(15-20GB) 최적화 ▸ Spot 전용: "중단 견딜 수 있음" → 가장 저렴 ▸ SPOT_CAPACITY_OPTIMIZED: 중단 최소화 【오답 체크】 (A) Lambda: 15GB 처리 시 Lambda 한계(메모리 10GB), 비용 높음 (C) On-Demand + Spot: Spot만으로 충분, On-Demand 비용 낭비 (D) EKS: Batch보다 복잡, 오버헤드 높음 【시험 포인트】 "배치 + 중단 허용 + 비용 최소"는 AWS Batch + Spot Instance의 필수 조합입니다.

해설

【핵심 용어】 ▸ AWS DataSync 에이전트(온프레미스) — 대역폭 제어, 예약 가능 ▸ S3 Glacier Deep Archive — 저렴, 1주일 검색 가능 【정답 포인트】 ▸ (B) DataSync Hyper-V: 온프레미스에서 직접 → 네트워크 효율 ▸ Deep Archive: "1주일 검색" 요구 → Instant Retrieval 불필요 ▸ 대역폭 제어 + 예약: DataSync 내장 기능 【오답 체크】 (A) EC2 인스턴스: GPU 불필요, EC2 비용 추가 (C) S3 Standard → Deep Archive: 라이프사이클 지연(1일), 추가 비용 (D) Tape Gateway: Deep Archive 풀 자동화되지만 복잡 【시험 포인트】 "온프레미스 Hyper-V + 대역폭 제어 + 저비용 보관 + 1주일 검색"은 DataSync(온프레미스) + Deep Archive의 조합입니다.

해설

【핵심 용어】 ▸ CloudWatch Logs Metric Filter — 로그 이벤트에서 메트릭 데이터를 추출하는 기능 ▸ Metric Dimension — 메트릭을 분류/집계하는 속성(사용자 이름, 클라이언트 이름) 【정답 포인트】 ▸ 애플리케이션 변경 최소화 → 로그 기반 처리 필요 ▸ 이미 CloudWatch에 로그가 저장되고 있음 → 메트릭 필터 활용 ▸ 메트릭 필터로 로그에서 직접 성공적인 로그인 패턴 추출 가능 ▸ 사용자/클라이언트 정보는 로그에 포함되어 있으므로 차원으로 설정 가능 ▸ 로그 파싱 후 일별/주간/월간 고유 사용자 수를 CloudWatch 쿼리로 집계 【오답 체크】 (B) 애플리케이션 코드 수정 필요 → "최소한의 변경" 요구사항 위배 (C) CloudWatch 에이전트는 메트릭 추출 기능이 없음 → 로그 저장만 담당 (D) Lambda 추가 구성 필요 → 복잡성 증가, (A) 보다 오버엔지니어링 【시험 포인트】 CloudWatch Logs → Metric Filter 패턴: 애플리케이션 수정 없이 기존 로그 활용

해설

【핵심 용어】 ▸ OpenID Connect(OIDC) — 서드파티 신원 공급자로부터 단기 인증 토큰 획득 ▸ sts:AssumeRoleWithWebIdentity — OIDC 토큰으로 IAM 역할 가정 ▸ GitHub OIDC — GitHub Actions에서 자동으로 제공되는 토큰 【정답 포인트】 ▸ GitHub는 기본적으로 OIDC 토큰을 발급함 → 추가 설정 불필요 ▸ IAM OIDC IdP + 신뢰 정책으로 짧은 수명의 임시 자격증명 획득 ▸ 애플리케이션 코드나 GitHub 설정 변경 최소화 ▸ 비용 효율적: 추가 자격증명 관리 불필요 ▸ 운영 오버헤드 가장 적음: 자동 토큰 갱신, 비밀 키 관리 제거 【오답 체크】 (A) SAML은 엔터프라이즈 SSO용 → GitHub OIDC와 호환성 낮음 (C) Cognito는 추가 계층 → 불필요한 복잡성 (D) Private CA + 인증서 관리 → 운영 오버헤드 높음 【시험 포인트】 GitHub Actions + 단기 인증 → OIDC IdP + AssumeRoleWithWebIdentity 패턴

해설

【핵심 용어】 ▸ Lambda Function — 이벤트 기반 서버리스 컴퓨팅, 사용 시간만 비용 ▸ S3 — 비용 효율적인 객체 스토리지 ▸ SQS Integration — Lambda가 SQS 메시지로 자동 트리거 【정답 포인트】 ▸ 불규칙한 트래픽 + 자주 유휴 상태 → 서버리스가 최적 ▸ Lambda: 호출 당 요금, 유휴 시간 비용 없음 ▸ S3: EFS보다 저렴한 스토리지 비용 ▸ 10초 크롤링 작업 = Lambda 적합한 실행 시간 ▸ Lambda + SQS 통합으로 자동 확장 + 최소 운영 오버헤드 【오답 체크】 (A) 큰 인스턴스로 변경 → 유휴 비용 증가, 문제 미해결 (C) Neptune: 그래프 DB, 크롤링 결과 저장에 불필요, 비용 높음 (D) Aurora Serverless: EFS보다 비싸고 복잡함 【시험 포인트】 불규칙 트래픽 + 짧은 작업 → Lambda + S3 조합으로 비용 최소화