정답 · 해설

해설

【핵심 용어】 ▸ AWS Transfer for SFTP — SFTP 프로토콜을 위한 완전 관리형 서비스 ▸ 관리 오버헤드 제로 — 서버 패칭, 확장성 자동 ▸ 높은 가용성 — 다중 AZ 분산, 장애 자동 복구 【정답 포인트】 ▸ 문제: EC2 단일 서버의 SPOF(Single Point of Failure) ▸ Transfer for SFTP = 완전 관리형, 자동 확장, 높은 가용성 ▸ 신뢰할 수 있는 제3자 업로드 → 관리형 서비스 필수 ▸ DNS 엔드포인트 제공으로 Route 53 연동 간단 【오답 체크】 (A) ALB는 SFTP(L4 프로토콜) 미지원, 비효율 (C) Storage Gateway 파일 게이트웨이는 NFS/SMB용, SFTP 아님 (D) NLB는 기술적으로 가능하나 관리 부담 유지, SFTP 특화 아님 【시험 포인트】 SFTP 관리형 서비스 → AWS Transfer for SFTP EC2 기반 프로토콜 서버 → 관리형 서비스로 전환이 최고의 실천

해설

【핵심 용어】 ▸ VM Import/Export — VMware, Hyper-V VM을 EC2 AMI로 변환 ▸ OVF 형식 — 가상머신 표준 형식, 포터빌리티 보장 ▸ 소프트웨어+설정 보존 — 이미지 단위 마이그레이션의 핵심 【정답 포인트】 ▸ 요구사항: '소프트웨어와 구성 설정 보존' → 이미지 방식 필수 ▸ vSphere Client로 OVF 내보내기 → EC2 Import로 AMI 생성 ▸ 완전한 VM 환경을 그대로 이전 가능 ▸ S3 중간 저장 → 보안, 재사용성 강화 【오답 체크】 (A) DataSync + FSx는 스토리지만 이전, 소프트웨어 보존 안 됨 (C) Storage Gateway CIFS는 네트워크 공유, AMI 생성 불가 (D) Systems Manager는 기존 리소스 관리용, VM 이미지 변환 아님 【시험 포인트】 VMware VM 이전 → OVF 내보내기 + EC2 Import/Export 전체 환경 보존 → 이미지 단위 마이그레이션 필수

해설

【핵심 용어】 ▸ Lambda 타임아웃 한계 — 최대 15분, 장시간 작업 부적합 ▸ ECS Fargate — 서버리스 컨테이너, 시간 제한 없음 ▸ 관리 오버헤드 제로 — '기본 인프라 관리 불원' 충족 【정답 포인트】 ▸ (A) Docker 이미지화 → ECR 저장으로 재사용성 확보 ▸ (B) Fargate 기반 ECS 작업 → 긴 처리 시간 가능, 자동 확장 ▸ Lambda에서 S3 이벤트 감지 → ECS 작업 호출 패턴 ▸ 인프라 관리 불필요 (EC2 아님) 【오답 체크】 (C) Step Functions 병렬화는 Lambda 타임아웃 근본 해결 못함 (D) EC2 호환성 = 인프라 관리 필요, 요구사항 위배 (E) EFS/RDS는 스토리지만 해결, 처리 시간 단축 아님 【시험 포인트】 장시간 처리 작업 + 서버리스 → ECS Fargate Docker + ECR + Lambda 조합 = 현대적 마이크로서비스 아키텍처

해설

【핵심 용어】 ▸ AWS Control Tower Guardrails — 거버넌스 규칙 자동화 ▸ 필수(Mandatory) vs 권장(Recommended) — 필수는 항상 적용, 권장은 선택 ▸ Detective Guardrail — 규정 위반 감지 (RDS 암호화 미적용 탐지) 【정답 포인트】 ▸ 프로덕션 OU의 RDS 암호화 미적용 감지 → Detective 유형 필요 ▸ Control Tower 'Strongly Recommended' 가드레일에 RDS 암호화 규칙 포함 ▸ OU 단위 적용으로 세밀한 제어 가능 ▸ AWS Config 규칙의 자동 통합 【오답 체크】 (A) 필수 가드레일 = 정책 적용(Preventive), 감지(Detective) 아님 (C) AWS Config는 Control Tower 아래에서 작동, 직접 생성 비효율 (D) SCP = 접근 제어, RDS 암호화 상태 감지 불가 【시험 포인트】 Control Tower 감지(Detective) → Recommended Guardrails RDS 암호화 정책 → 기본 포함된 가드레일 활용

해설

【핵심 용어】 ▸ Systems Manager Session Manager — SSH 대체, 모든 활동이 CloudTrail에 기록 ▸ 감시(Auditing) — Session Manager는 세션 기록 및 로깅 자동 지원 ▸ 포트 22 제거 — 네트워크 공격 표면 축소 【정답 포인트】 ▸ 요구사항: '보안 제어 강화' + '명령 감시' → Session Manager 필수 ▸ SSH 포트 22 완전 차단 → SSH 기반 공격 원천 차단 ▸ AmazonSSMManagedInstanceCore 정책 → Systems Manager Agent 통신 권한 ▸ Session Manager는 모든 입출력을 S3/CloudWatch에 기록 【오답 체크】 (A) EC2 Instance Connect는 여전히 포트 기반, 감시 기능 미약 (B) CloudWatch 로그 전송은 선택적, SSH 접근 자체 미해결 (C) Config + Firewall Manager는 정책 보호만, 접근 제어 미흡 【시험 포인트】 SSH 제거 + 감시 → Systems Manager Session Manager 규정 준수 요구사항 → Session Manager의 감사 로그

해설

【핵심 용어】 ▸ AWS Budgets — 비용 모니터링 및 경보 ▸ SCP(Service Control Policy) — 서비스 접근 제어 ▸ Preventive(예방) vs Detective(감지) — SCP는 예방, Budgets은 감지 【정답 포인트】 ▸ (B) Budgets 생성 → 월정액 예산 추적, 비용 가시화 ▸ (C) 비용 서비스 SCP 차단 → EC2, RDS 등 비용 높은 리소스 사전 제어 ▸ (F) Budget 경고 + Lambda → 예산 초과 시 자동 대응 (비용 폭발 방지) ▸ 3단계 조합: 예방 (C) + 모니터링 (B) + 자동화(F) 【오답 체크】 (A) SCP는 사용량 한도 설정 불가, 접근 제어만 가능 (D) IAM 정책은 계정 조직 수준 제어 불가, 개별 사용자 수준 (E) 모든 서비스 종료는 과도함, 선택적 종료 필요 【시험 포인트】 비용 제한 다층 방어 → SCP(접근) + Budgets(모니터) + Lambda(자동화) Organizations 레벨 → SCP, 계정 레벨 → IAM/Budgets 구분

해설

【핵심 용어】 ▸ AWS RAM 공유 — 크로스 계정 리소스 접근 (즉시, 다운타임 최소) ▸ Aurora Clone — 원본 DB 유지하며 복제본 생성, 빠른 RTO ▸ Lambda 배포 패키지 — 수동 다운로드 후 재배포 【정답 포인트】 ▸ 요구사항: '다운타임 최소화' → Clone이 Snapshot보다 빠름 ▸ (B) Lambda 패키지 수동 다운로드 → 확실한 코드 이전 ▸ Aurora Clone via AWS RAM → 스냅샷 복구 없이 즉시 복제 ▸ 다운타임: Clone은 초 단위, Snapshot 복구는 분 단위 【오답 체크】 (A) Snapshot 공유 → 복구 시간 소요, 다운타임 증가 (C) Lambda는 RAM 공유 불가, 코드 재배포 필수 (D) Lambda는 공유만으로 충분하지만, Snapshot은 느림 【시험 포인트】 크로스 계정 DB 마이그레이션 + 최소 다운타임 → Aurora Clone AWS RAM Clone = 거의 즉시 복제, 저사용량 시점 컷오버 가능

해설

【핵심 용어】 ▸ Lambda 함수 트리거 — S3 이벤트 감지, 즉시 호출 ▸ 비용 효율성 — Lambda는 실행 시간만 결제, 유휴 시간 없음 ▸ 관리 오버헤드 제로 — 서버리스, 자동 확장 【정답 포인트】 ▸ 문제: EC2 인스턴스 40% 유휴 → Lambda로 교체 시 비용 75% 절감 ▸ S3 이벤트 알림 → 푸시 기반, 폴링 오버헤드 없음 ▸ Lambda 자동 병렬화 → 파일당 별도 함수 호출, 동시 처리 ▸ 관리 오버헤드: 0 (Auto Scaling, 패치 불필요) 【오답 체크】 (B) SQS + Auto Scaling = 1대 인스턴스 운영, 여전히 유휴 시간 존재 (C) 컨테이너 + EC2 폴링 = 여전히 인프라 관리 부담 (D) ECS Fargate = Lambda보다 복잡, 비용 높음 (최소 요금) 【시험 포인트】 파일 처리 + 이벤트 기반 + 비용 효율 → Lambda 폴링 기반 처리 → Queue 고려, 그 외 → 이벤트 알림

해설

【핵심 용어】 ▸ Active-Passive 장애 조치 — 주 리전 정상 시 트래픽 집중, 장애 시 보조 리전으로 전환 ▸ Route 53 Failover Routing — 상태 검사 기반 자동 라우팅 전환 ▸ 다중 AZ 로드 밸런싱 — 각 리전 내 고가용성 【정답 포인트】 ▸ (C) 만이 두 리전 모두에 독립적인 인프라 구성 ▸ Route 53 Failover Policy가 Active-Passive 구현의 핵심 ▸ 상태 검사 → 주 리전 장애 감지, 보조 리전으로 자동 전환 ▸ 각 ALB별 별도 레코드 + Failover = 명확한 재해 복구 【오답 체크】 (A) VPC 피어링 + 단일 ALB = 액티브-패시브 구조 아님, 고가용성만 (B) Weighted Routing = 항상 두 리전에 분산, 액티브-액티브 (재해 복구 아님) (D) VPC 피어링 + 단일 ALB = 영역 간 고가용성 미흡 【시험 포인트】 Active-Passive DR → 각 리전 독립 인프라 + Route 53 Failover 리전 간 중복성 = 다중 AZ(같은 리전) + 다중 리전의 조합

해설

【핵심 용어】 ▸ AD Connector — 온프레미스 Active Directory와의 직접 연결 (네트워크 기반) ▸ AWS Managed Microsoft AD — AWS에서 새로운 AD 디렉터리 생성 (추가 동기화 필요) ▸ 비용 효율성 — Connector < Managed AD (라이선스 불필요) 【정답 포인트】 ▸ 요구사항: '온프레미스 Active Directory 자격증명 사용' → AD Connector 최적 ▸ (D) 만이 'Turn on all features' 명시 → Organizations 전체 기능 활성화 필수 ▸ AD Connector = 기존 AD 직접 사용, 동기화 불필요, 비용 저렴 ▸ IAM Identity Center + AD Connector 조합 = 표준 아키텍처 【오답 체크】 (A) (B) 'Turn on all features' 미명시 → Organizations 기본 기능만 (C) AWS Managed Microsoft AD = 추가 라이선스 비용, 불필요한 중복 (A) (C) 양방향 신뢰 = 복잡도 증가, AD Connector는 더 간단 【시험 포인트】 온프레미스 AD 재사용 + SSO → AD Connector Organizations 모든 기능 활성화 → IAM Identity Center 전제 조건

해설

【핵심 용어】 ▸ S3 Transfer Acceleration — CloudFront 엣지 네트워크 활용, 전역 업로드 최적화 ▸ Multipart Upload — 대용량 파일을 청크로 분할, 병렬 전송, 일부 실패 재시도 가능 ▸ 지연 시간 기반 라우팅 — Route 53 L7 기능, S3는 L4 프로토콜만 지원하므로 미작동 【정답 포인트】 ▸ (A) Transfer Acceleration = 호주에서 us-east-1으로의 네트워크 지연 감소 ▸ (D) Multipart Upload = 청크 단위 병렬 전송, 네트워크 불안정성 극복 ▸ 호주 → 미국: 지연 20ms 이상, TLS 오버헤드 큼 → 두 기술 모두 필수 ▸ 조합 효과: Transfer Acceleration(경로 최적화) + Multipart(병렬화) 【오답 체크】 (B) 각 리전 S3 = 복제 시간 소요, 업로드 자체 개선 아님 (C) Route 53 지연 시간 라우팅은 DNS 레벨, S3 HTTP 요청 지원 안 함 (E) 무작위 접두사 = S3 파티션 성능, 클라이언트 업로드 지연과 무관 【시험 포인트】 장거리 대용량 파일 업로드 → Transfer Acceleration + Multipart Upload 호주 사용자 문제 = 네트워크 지연 + 안정성 → 두 기술 모두 필요

해설

【핵심 용어】 ▸ RDS Proxy — 데이터베이스 연결 풀링, 장애 조치 시 연결 자동 재설정 ▸ Connection Pooling — 기존 연결 재사용, 애플리케이션 로직 변경 최소 ▸ Failover 투명성 — 애플리케이션은 프록시 엔드포인트만 바라봄 【정답 포인트】 ▸ 문제: RDS Multi-AZ 장애 조치 후 애플리케이션 연결 정상화 안 됨 ▸ RDS Proxy = 프록시가 새 DB 엔드포인트 감지, 연결 자동 재설정 ▸ 애플리케이션은 프록시 엔드포인트 가리킴 → 투명한 장애 조치 ▸ 재시작 불필요, 즉시 재연결 가능 【오답 체크】 (A) Aurora Serverless = 서버리스 특성, RDS와 다른 아키텍처, 마이그레이션 복잡 (C) Aurora 마이그레이션 + RDS Proxy = 과도한 복잡성 (D) Athena = OLAP 분석용, OLTP 트랜잭션 부적합 【시험 포인트】 RDS 장애 조치 후 자동 재연결 → RDS Proxy 프록시는 연결 풀 관리 및 자동 복구의 핵심

해설

【핵심 용어】 ▸ AWS IoT Core — MQTT 프로토콜 전용 관리형 서비스 ▸ X.509 인증서 기반 인증 — IoT Core 표준 보안 메커니즘 ▸ 운영 오버헤드 제로 — 관리형 서비스 【정답 포인트】 ▸ 요구사항: MQTT + X.509 인증 + 최소 운영 오버헤드 ▸ (C) 만이 AWS IoT Core 사용 → MQTT 프로토콜 네이티브 지원 ▸ AWS IoT Thing = 장치 대표, 인증서 프로비저닝 자동화 ▸ 확장성 무제한, 관리 오버헤드 0 【오답 체크】 (A) Amazon MQ = JMS/AMQP/MQTT 지원하나, EC2 기반 관리 부담 큼 (B) NLB + EC2 MQTT 브로커 = 인프라 관리 필수, 복잡성 높음 (D) API Gateway + NLB = 과도한 복잡성, MQTT 전용 아님 【시험 포인트】 MQTT + IoT 디바이스 → AWS IoT Core X.509 인증 = IoT Core의 기본 보안 모델 운영 오버헤드 최소 → 완전 관리형 서비스 선택

해설

【핵심 용어】 ▸ IAM Service Role — CloudFormation이 리소스 생성 시 사용, 역할 분리 ▸ CloudFormation 액세스 분리 — 사용자(엔지니어)는 최소 권한만 ▸ 승인 리소스 제어 — 서비스 역할에서만 명시된 리소스 생성 권한 【정답 포인트】 ▸ 요구사항: '승인된 리소스만' + 'CloudFormation 강제' ▸ (C) 의 3단계 설계: - 엔지니어 IAM = CloudFormation 작업만 (iam:CreateStack 등) - 서비스 역할 = 리소스 생성 권한만 (EC2, RDS 등 특정 리소스) - CloudFormation은 서비스 역할 권한 내에서만 생성 ▸ 승인되지 않은 리소스 접근 원천 차단 【오답 체크】 (A) S3 접근 = 엔지니어에게 과도한 권한 (B) 엔지니어에게 직접 리소스 생성 권한 → 정책 우회 가능 (D) 각자 스택만 접근 → 중앙화된 거버넌스 미흡 【시험 포인트】 CloudFormation 강제화 → 사용자와 서비스 역할의 권한 분리 승인 리소스 제한 → 서비스 역할의 정책으로 통제

해설

【핵심 용어】 ▸ DynamoDB TTL — 자동으로 만료된 항목 삭제, 스토리지 비용 절감 ▸ On-Demand Billing — 초당 백만 개 항목도 자동 확장 ▸ 저지연 검색 — DynamoDB의 장점 (밀리초 응답) 【정답 포인트】 ▸ 요구사항: '분당 백만 개' + '낮은 지연' + '120일 자동 삭제' + '비용 효율' ▸ (B) 만이 모든 요구사항 충족: - DynamoDB = 초당 수백만 처리량 - TTL = 자동 삭제, 관리 오버헤드 0 - 낮은 지연 = 밀리초 응답 - 비용 = 스토리지 + 처리량만 (매월 청정) 【오답 체크】 (A) 파일당 1개 객체 = 수백만 개 파일, S3 API 호출 폭증, 비용 최악 (C) RDS MySQL + 크론 작업 = 관리 오버헤드 높음, 기계 용량 예측 필요 (D) S3 메타데이터 검색 = S3는 메타데이터 검색 기능 없음 (Athena 필요) 【시험 포인트】 분당 백만 개 초고속 데이터 수집 → DynamoDB On-Demand 임시 데이터 + 자동 삭제 → TTL 기능

해설

【핵심 용어】 】 ▸ 크로스 리전 읽기 복제본 — 다중 리전 고가용성의 표준 ▸ 승격(Promotion) — 읽기 복제본을 독립 DB로 전환, RTO 짧음 ▸ Failover Automation — Route 53 + 헬스 체크로 자동 전환 【정답 포인트】 트】 ▸ 요구사항: '다중 리전' + '최고 가용성' (Highest) ▸ (D) 의 아키텍처: - 읽기 복제본(크로스 리전) 항상 최신 상태 유지 - 장애 감지 시 즉시 승격, 수초 내 완료 - 승격 후 새 읽기 복제본 재생성 - RTO: 분 단위, RPO: 초 단위 【오답 체크】 】 (A) 자동 백업만 → 복구 시간 길고(분~시간), 최고 가용성 아님 (B) 'Global Tables' = RDS 미지원 (Aurora만 지원) (C) Global Tables 오류 + Lambda 수동 개입 = 자동화 미흡 【시험 포인트】 트】 RDS 다중 리전 HA → 크로스 리전 읽기 복제본 + 승격 Aurora Global Database 아님 → RDS는 수동 또는 Application Logic

해설

【핵심 용어】 】 ▸ Transit Gateway — 여러 VPC, 온프레미스 네트워크, VPN을 중앙에서 연결하는 서비스 ▸ VPC Peering — 두 VPC 간의 직접 연결 (이미 구성됨) ▸ Site-to-Site VPN — 온프레미스와 AWS의 보안 연결 【정답 포인트】 트】 ▸ "최소 운영 오버헤드" → Transit Gateway 선택 ▸ Transit Gateway는 VPC, VPN, 온프레미스를 단일 허브에서 관리 ▸ 라우팅 테이블만 업데이트하면 모든 네트워크 간 통신 가능 ▸ Peering보다 확장 가능하고 관리 효율적 【오답 체크】 】 (B) BGP 인증 규칙은 Transit Gateway 기능 아님 — VPN만으로 부족 (C) BGP 전파는 좋지만 VPC Peering 때문에 복잡하고 시간 소요 (D) 가상 프라이빗 게이트웨이 분할은 불가능한 방식 【시험 포인트】 트】 다중 네트워크 연결 → Transit Gateway 운영 간소화 → 중앙 라우팅 관리 VPN + 여러 VPC → Transit Gateway 이용

해설

【핵심 용어】 】 ▸ STARTTLS — SMTP 연결을 암호화로 업그레이드하는 프로토콜 ▸ SMTP 자격증명 — Amazon SES가 제공하는 SMTP 인증 방식 ▸ TLS Wrapper — 포트 465로 암호화된 연결 (SES는 포트 587 STARTTLS 권장) 【정답 포인트】 트】 ▸ "SMTP만 사용 가능" → SMTP 인터페이스 필요 ▸ "TLS 암호화 없음" → STARTTLS로 보안 추가 ▸ Amazon SES SMTP 엔드포인트는 포트 587에서 STARTTLS 지원 ▸ SMTP 자격증명으로 기존 SMTP 애플리케이션 호환 유지 【오답 체크】 】 (A) TLS Wrapper는 포트 465이고 SES가 권장하는 방식이 아님 (C) SES API는 애플리케이션이 SMTP만 지원하므로 불가능 (D) SDK 사용은 애플리케이션 코드 대대적 수정 필요 【시험 포인트】 트】 SMTP 서비스 → Amazon SES SMTP 엔드포인트 레거시 애플리케이션 호환성 → STARTTLS + SMTP 자격증명 암호화 + 프로토콜 호환 → 최소 변경

해설

【핵심 용어】 】 ▸ AWS Cost and Usage Report — 상세한 청구 데이터를 CSV로 제공하는 서비스 ▸ Cost Categories — 커스텀 청구 그룹 정의 ▸ Amazon Athena — S3 데이터에 SQL 쿼리 ▸ Amazon QuickSight — BI 대시보드 및 분석 【정답 포인트】 트】 ▸ "자체 관리 애플리케이션" → 데이터 수집 및 처리 필요 ▸ "의미 있는 그룹" → 태그 및 비용 카테고리 활용 ▸ Cost and Usage Report + Athena + QuickSight = 완전한 데이터 파이프라인 ▸ Organizations 레벨에서 전체 비용 데이터 통합 【오답 체크】 】 (B) Cost Explorer는 AWS 관리 UI용, 자체 애플리케이션 미지원 (C) Price List API는 정가만 제공, 실제 청구 데이터 아님 (D) Price List API로는 실제 지출 추적 불가능 【시험 포인트】 트】 조직 규모 청구 데이터 → Cost and Usage Report 커스텀 분석 파이프라인 → Athena + QuickSight 자체 애플리케이션 연계 → CUR를 분석 도구와 연결

해설

【핵심 용어】 】 ▸ Kinesis Data Streams — 대규모 스트리밍 데이터 수집 ▸ AWS Lambda — 이벤트 기반 데이터 처리 ▸ DynamoDB — NoSQL, 무제한 확장성, 높은 쓰기 처리량 ▸ API 서버 과부하 + 데이터베이스 쓰기 지연 → 아키텍처 변경 필요 【정답 포인트】 트】 ▸ (C) Kinesis + Lambda = 센서 데이터 버퍼링 및 비동기 처리 ▸ API 서버의 직접 쓰기 부하 제거 ▸ (E) DynamoDB = 무제한 확장 가능한 NoSQL ▸ RDS의 동기식 쓰기 지연 해결 ▸ 함께 작동: Kinesis → Lambda → DynamoDB 【오답 체크】 】 (A) 저장소 확대만으로는 IOPS 및 쓰기 지연 해결 불가 (B) Aurora는 수평 확장이 아니라 수직 확장, 근본 아키텍처 변경 미흡 (D) X-Ray는 분석만 가능하고 더 많은 API 서버도 데이터베이스 병목 변하지 않음 【시험 포인트】 트】 센서 → API 과부하 → 비동기 처리 (Kinesis + Lambda) 데이터베이스 쓰기 병목 → DynamoDB 확장성 IoT 플랫폼 성장 → 메시지 큐 + NoSQL 조합