정답 · 해설

해설

【핵심 용어】 ▸ Launch Template: AMI, 인스턴스 타입, 보안 그룹 등 인스턴스 구성 정보 저장 ▸ Launch Configuration: 레거시 방식의 Auto Scaling 인스턴스 설정 (업데이트 불가) ▸ Mixed Instances Policy: 단일 ASG에서 온디맨드와 Spot 인스턴스 혼합 운영 【정답 포인트】 ▸ Launch Template은 버전 관리 및 업데이트 지원으로 더 유연한 관리 가능 ▸ 단일 Auto Scaling 그룹에서 온디맨드 3개 + Spot 3개 구성으로 복잡도 감소 ▸ Mixed Instances Policy 사용으로 비용 최적화와 가용성 동시 달성 【오답 체크】 (A) Launch Configuration은 레거시 방식이며 업데이트 불가능하여 관리성 낮음 - 75자 (C) 2개의 별도 ASG 운영은 관리 복잡도 증가 및 스케일링 정책 이중 설정 필요 - 85자 (D) 2개 ASG 분리 운영은 필요한 복잡도 증가로 "LEAST operational overhead" 불만족 - 90자 【시험 포인트】 ▸ Launch Template vs Launch Configuration 차이점 이해 ▸ Auto Scaling 그룹의 Mixed Instances Policy 기능 ▸ "Least Operational Overhead" 선택 기준

해설

【핵심 용어】 ▸ CloudFormation Template: Infrastructure as Code로 AWS 리소스 정의 ▸ AWS::CloudWatch::Dashboard: CloudWatch 대시보드를 CloudFormation으로 정의하는 리소스 ▸ DashboardBody: JSON 형식의 대시보드 설정 정보 【정답 포인트】 ▸ 기존 대시보드를 JSON으로 내보내 CloudFormation 템플릿에 통합 ▸ DashboardBody 프로퍼티에 JSON을 포함하여 자동 생성 가능 ▸ 각 배포 시 동일한 대시보드 구성이 자동으로 생성됨 【오답 체크】 (A) put-dashboard는 CloudFormation 외부 작업으로 인프라 코드화 미흡; 별도 스크립트 관리 필요 - 95자 (C) Ref 함수는 리소스 ID만 참조하며, 기존 대시보드 정보 복제 불가; 새 생성 불가 - 90자 (D) DashboardName만으로는 기존 대시보드 참조만 가능하며 새로운 대시보드 생성 불가 - 85자 【시험 포인트】 ▸ CloudFormation 리소스 정의 방법 (JSON 포함 방식) ▸ Infrastructure as Code 원칙 이해 ▸ 대시보드 내보내기와 CloudFormation 통합 방법

해설

【핵심 용어】 ▸ Dedicated Hosts: 단일 계정 전용 물리 서버 (고급 격리) ▸ Dedicated Instances: 단일 고객 전용 하드웨어 (다른 고객과 공유 안 함, 같은 계정의 다른 인스턴스는 공유 가능) ▸ Reserved Instances: 할인 모델이며 격리 기능 없음 【정답 포인트】 ▸ Dedicated Hosts는 물리 서버 전체가 단일 계정 전용 ▸ 다른 AWS 계정과 절대 공유되지 않는 완전 격리 보장 ▸ 규제 요구사항의 "다른 계정과 공유 금지" 조건 충족 【오답 체크】 (B) Dedicated Instances는 같은 회사 내 다른 AWS 계정과 물리 서버 공유 가능 - 85자 (C) Reserved Instances는 가격 결정 모델이며 하드웨어 격리 기능 제공 안 함 - 80자 (D) Placement Group은 인스턴스 배치 최적화용이며 다른 고객/계정과의 공유 제어 불가 - 90자 【시험 포인트】 ▸ Dedicated Hosts vs Dedicated Instances 차이점 명확히 ▸ 다른 AWS 계정과의 격리 수준 이해 ▸ 규제 준수 요구사항 분석 능력

해설

【핵심 용어】 ▸ CloudFront: 글로벌 CDN 서비스로 콘텐츠를 엣지 로케이션에 캐시 ▸ Edge Locations: 전 세계 200+ 위치의 AWS 서버 (사용자 근처) ▸ Content Delivery Network (CDN): 지리적으로 분산된 콘텐츠 전송 【정답 포인트】 ▸ CloudFront는 정적 콘텐츠(이미지, 동영상)에 최적화된 글로벌 배포 서비스 ▸ 미국, 유럽 사용자에게 가까운 엣지 로케이션에서 콘텐츠 제공 ▸ 네트워크 지연 최소화로 로딩 속도 극적 개선 【오답 체크】 (A) PrivateLink는 VPC 간 프라이빗 연결로, 공개 사용자 성능 개선 관계 없음 - 85자 (B) Transfer Acceleration은 S3 업로드 속도 향상용이며, 다운로드/배포 최적화 아님 - 80자 (D) API Gateway는 API 엔드포인트용이며, 정적 콘텐츠 캐싱에 비효율적 - 80자 【시험 포인트】 ▸ CloudFront의 글로벌 배포 메커니즘 이해 ▸ 정적 콘텐츠 최적화 서비스 선택 기준 ▸ 지역별 성능 문제 해결 방법

해설

【핵심 용어】 ▸ CloudWatch Agent: EC2 인스턴스 내부 메트릭 수집 (디스크, 메모리, 프로세스 등) ▸ Composite Alarm: 여러 메트릭 알람을 논리 연산으로 결합 (AND, OR 등) ▸ Disk Space Metric: CloudWatch 에이전트에서만 수집 가능한 커스텀 메트릭 【정답 포인트】 ▸ CloudWatch 에이전트 설치로 EC2 내부의 디스크 사용량 메트릭 수집 ▸ 합성 알람으로 "디스크 사용량 AND DiskReadOps" 조건 설정 ▸ 두 조건 모두 충족할 때만 SNS 알림 발송 【오답 체크】 (B) 각 알람을 독립적으로 SNS 발행하면 OR 조건 발생, AND 조건 불가능 - 90자 (C) EBSByteBalance는 EBS 성능 메트릭이며 디스크 사용량과 무관; Agent 설치 필요 - 95자 (D) Detailed Monitoring은 EC2 CPU 등 기본 메트릭만 개선; 디스크 메트릭은 Agent 필수 - 100자 【시험 포인트】 ▸ CloudWatch Agent의 용도와 커스텀 메트릭 수집 ▸ Composite Alarm과 단일 Alarm의 차이 ▸ 다중 조건 알람 구성 방법 (AND 로직)

해설

【핵심 용어】 ▸ S3 Block Public Access: 계정/버킷 레벨에서 공개 액세스 차단 설정 ▸ Account Level: 계정 내 모든 버킷에 일괄 적용 (중앙 집중식) ▸ Public Access: ACL 또는 버킷 정책으로 인한 공개 접근 【정답 포인트】 ▸ Block Public Access는 설정만으로 즉시 모든 공개 액세스 차단 ▸ 계정 레벨 활성화로 정책 모든 버킷에 중앙 적용 ▸ 예방적(Preventive) 보안 기능으로 가장 효율적 【오답 체크】 (B) EventBridge는 이벤트 라우팅 서비스이며, ACL 강제 변경 기능 없음 - 85자 (C) Inspector는 취약점 스캔 도구이며, ACL 자동 수정 기능 제공 안 함 - 80자 (D) Object Lambda는 객체 반환 데이터 변환용이며, ACL 정책 변경 기능 없음 - 85자 【시험 포인트】 ▸ S3 Block Public Access의 네 가지 옵션 이해 ▸ 계정 레벨 vs 버킷 레벨 적용 범위 차이 ▸ 규제 준수를 위한 중앙 집중식 보안 정책

해설

【핵심 용어】 ▸ Root Account: AWS 계정 소유자 (모든 권한 보유) ▸ Root User MFA Loss Recovery: 이메일/전화 확인을 통한 계정 복구 ▸ Account Recovery Process: AWS 자격증명 복구 절차 【정답 포인트】 ▸ MFA 디바이스 손실 시 루트 사용자도 로그인 불가 ▸ AWS는 이메일 및 전화 확인으로 루트 신원 증명 요구 ▸ 신원 확인 후 새 MFA 디바이스 설정 가능 【오답 체크】 (B) IAM 사용자는 루트 계정의 MFA 재설정 권한 없음; 지원 플랜 변경도 루트 필요 - 95자 (C) IAM 사용자는 루트 사용자의 MFA 기기 재설정 권한 부족 - 70자 (D) 암호 재설정만으로는 MFA 디바이스 손실 복구 불가; 추가 신원 확인 필수 - 85자 【시험 포인트】 ▸ 루트 계정 MFA 손실 복구 절차 이해 ▸ 루트 계정 vs IAM 사용자의 권한 차이 ▸ AWS Support 플랜 변경 시 루트 계정 필요성

해설

【핵심 용어】 ▸ AWS SSO: AWS Organizations과 통합된 중앙 SSO 서비스 ▸ SAML 2.0 IdP: 타사 ID 공급자 (Okta, Azure AD 등) ▸ Multi-Account Access: 조직의 모든 계정에 대한 중앙 인증 【정답 포인트】 ▸ AWS SSO는 Organizations과 직접 통합되어 모든 계정 관리 ▸ SAML 2.0 IdP 연결로 기존 사용자 디렉토리 활용 ▸ 단일 관리 지점에서 모든 계정의 권한 관리 가능 【오답 체크】 (A) Cognito는 외부 애플리케이션용이며, Organizations 통합 미흡 - 80자 (C) 각 계정마다 페더레이션 설정은 중앙 관리 불가능하며 복잡도 증가 - 85자 (D) IdP를 Organizations과 직접 통합 불가능; SSO 같은 중간 계층 필요 - 85자 【시험 포인트】 ▸ AWS SSO의 Organizations 통합 기능 이해 ▸ SAML 2.0 기반 페더레이션 방식 ▸ 중앙 집중식 계정 관리 아키텍처

해설

【핵심 용어】 ▸ CloudFormation Stack Sets: 다중 계정/리전에 스택 배포 ▸ Stack Instances: 각 계정/리전별 스택 인스턴스 ▸ Organizational Units (OUs): Organizations의 계정 그룹화 【정답 포인트】 ▸ Stack Sets는 Organizations 계정 세트에 자동 배포 가능 ▸ 모든 리전에 동시 배포로 운영 효율성 극대화 ▸ 중앙 관리 포인트에서 일괄 관리 및 업데이트 가능 【오답 체크】 (B) Stack Policy는 리소스 보호 정책이며, Config 활성화 불가능 - 85자 (C) SCP는 권한 제어이지 리소스 프로비저닝 불가; Config 활성화 기능 없음 - 90자 (D) 수동 스크립트 관리는 리전별 반복 실행 필요, 운영 오버헤드 높음 - 85자 【시험 포인트】 ▸ CloudFormation Stack Sets의 다중 계정/리전 배포 기능 ▸ Organizations과의 통합 방식 ▸ 중앙 집중식 관리의 운영 효율성

해설

【핵심 용어】 ▸ DELETE_FAILED: CloudFormation이 스택 삭제 중 일부 리소스 삭제 실패 ▸ Retained Resources: 삭제되지 않은 채로 남은 AWS 리소스 ▸ Dependency Issue: 다른 리소스가 의존하는 리소스 삭제 시도 【정답 포인트】 ▸ (D) 보안 그룹의 추가 리소스: ENI 같은 리소스가 SG에 연결되어 있으면 삭제 불가 ▸ (E) S3 버킷 객체: 버킷이 비어 있어야만 CloudFormation이 삭제 가능 【오답 체크】 (A) 타임아웃은 DELETE_IN_PROGRESS 상태만 유발; 실패 원인 아님 - 80자 (B) 중첩 스택은 자동 삭제 대상이며, 수동 삭제 필요 없음 - 75자 (C) --disable-rollback은 실패 시 롤백 비활성화이며, 삭제 실패 원인 아님 - 85자 【시험 포인트】 ▸ CloudFormation 삭제 실패의 일반적 원인 ▸ 의존성 관계로 인한 삭제 차단 ▸ 리소스 정리(Cleanup) 필요성 이해

해설

【핵심 용어】 ▸ Origin Access Identity (OAI): CloudFront만 S3 액세스 권한 가짐 ▸ Signed URLs: 시간 제한이 있는 임시 액세스 권한 토큰 ▸ Public Access Block: S3 버킷의 모든 공개 액세스 차단 【정답 포인트】 ▸ Block Public Access 활성화로 직접 S3 액세스 차단 ▸ OAI 사용으로 CloudFront만 버킷 액세스 가능 ▸ Signed URL로 CloudFront 사용자 인증 및 권한 제어 【오답 체크】 (A) 공개 액세스가 차단되지 않으면 서명된 URL 우회 가능; 보안 취약 - 90자 (C) Field-level Encryption은 암호화 기능이며, 액세스 제어와 무관 - 80자 (D) 공개 액세스 차단 없이 서명된 쿠키 사용만으로는 직접 접근 가능 - 85자 【시험 포인트】 ▸ OAI 기반 CloudFront 보안 아키텍처 ▸ Signed URLs와 Signed Cookies의 사용 시점 ▸ 계층화된 보안 방어(Defense in Depth)

해설

【핵심 용어】 ▸ EventBridge Rule: 이벤트 원본과 대상을 매핑하는 규칙 ▸ Resource-based Policy: Lambda 함수가 특정 서비스의 호출 허용 ▸ Trust Relationship: 서비스가 역할을 수임할 권한 【정답 포인트】 ▸ EventBridge가 Lambda를 호출하려면 Lambda 함수 정책에 권한 추가 필요 ▸ Resource-based policy에 "events.amazonaws.com" 서비스 허용 필수 ▸ 이벤트 발행과 함수 호출 간 권한 연결 필요 【오답 체크】 (B) CONTINUE 동작은 훅 실패 시 진행 설정이며, 호출 미작동 원인 아님 - 85자 (C) 재시도 정책은 호출 실패 후 재시도용이며, 초기 호출 권한 부족 미해결 - 90자 (D) 실행 역할은 Lambda가 다른 서비스 호출 시 필요; EventBridge 호출 미해결 - 95자 【시험 포인트】 ▸ Lambda 함수의 Resource-based Policy 구성 ▸ EventBridge 트리거의 권한 설정 ▸ 이벤트 기반 아키텍처의 권한 모델

해설

【핵심 용어】 ▸ Temporary Credentials: STS(Security Token Service)에서 발급한 임시 자격증명 ▸ get-session-token: MFA 검증 후 임시 토큰 발급 API ▸ MFA-enforced Policy: MFA 토큰 없이 API 호출 차단하는 정책 【정답 포인트】 ▸ MFA 기반 정책은 MFA 컨텍스트 정보(aws:MultiFactorAuthPresent) 체크 ▸ get-session-token은 MFA 토큰과 함께 임시 자격증명 발급 ▸ 임시 자격증명에는 MFA 검증 정보 포함되어 정책 조건 충족 【오답 체크】 (A) IAM 역할의 MFA 활성화는 관리자 용도이며, 사용자 CLI 사용과 무관 - 90자 (B) 콘솔 로그인은 MFA 토큰 획득이지만, CLI 자격증명에 MFA 정보 미포함 - 95자 (C) CLI는 MFA 지원하며 제한 불필요; get-session-token으로 MFA 적용 가능 - 85자 【시험 포인트】 ▸ AWS STS와 임시 자격증명의 역할 ▸ MFA 기반 정책과 임시 자격증명의 통합 ▸ CLI 환경에서의 MFA 적용 방법

해설

【핵심 용어】 ▸ AWS Config: 리소스 구성 변경 추적 및 규정 준수 모니터링 ▸ Managed Rules: AWS 사전 정의 Config 규칙 (s3-bucket-public-read-prohibited 등) ▸ Compliance Monitoring: 지속적 규정 준수 검사 【정답 포인트】 ▸ AWS Config 규칙은 설정만으로 지속 모니터링 제공 ▸ s3-bucket-public-read-prohibited 규칙이 정확한 요구사항 충족 ▸ SNS 통합으로 자동 알림 발송 【오답 체크】 (A) Lambda + cron 조합은 수동 유지보수 필요하고 운영 오버헤드 높음 - 85자 (B) cron 스크립트는 서버 관리 필요하며, Config 자동 모니터링 대비 비효율적 - 90자 (C) S3 Event Notifications는 객체 레벨 이벤트용이며, 버킷 설정 변경 감지 불가 - 95자 【시험 포인트】 ▸ AWS Config의 Managed Rules 활용 ▸ 규제 준수 모니터링 자동화 ▸ 최소 운영 오버헤드(Least Operational Overhead) 원칙

해설

【핵심 용어】 ▸ S3 정적 웹사이트 호스팅: 도메인 이름과 일치해야 하는 버킷명 규칙 필수. ▸ 리디렉션 설정: 서브도메인 요청을 루트 도메인으로 자동 전달. ▸ S3 버킷 명명 규칙: 정확한 도메인명과 일치해야만 호스팅 가능. 【정답 포인트】 ▸ 정답: C - 두 버킷 생성(example.com + www.example.com) 후 www 버킷에서 리디렉션 설정. ▸ S3 정적 웹사이트는 정확한 도메인명 기반 버킷 필수. ▸ www 버킷이 CNAME 역할을 수행하며 루트 버킷으로 모든 요청 리디렉션. ▸ 이는 S3의 표준 호스팅 패턴 중 가장 일반적이고 검증된 방식. 【오답 체크】 (A) 60~80자: 와일드카드 버킷명이 아니므로 www.example.com 요청을 처리할 수 없음. 단일 버킷으로는 두 도메인을 모두 호스팅할 수 없음. (B) 60~80자: AWS S3에서 와일드카드를 버킷명에 직접 포함할 수 없음. S3 버킷 명명 규칙 위반. (D) 75~90자: 버킷명에 프로토콜(http://) 포함 불가능. S3 버킷 명명 규칙에서 영문자, 숫자, 하이픈만 허용. 【시험 포인트】 ▸ S3 정적 웹사이트 호스팅의 도메인 구조 이해 필수. ▸ 버킷명 = 도메인명의 정확한 일치 원칙. ▸ 서브도메인 처리는 리디렉션을 통한 우회 기법. ▸ Route 53과의 연동 시 A 레코드 별칭 설정도 함께 이해해야 함.

해설

【핵심 용어】 ▸ 분할 터널(Split Tunnel): VPN을 통하지 않고 로컬 인터넷 트래픽을 직접 전송하는 기능. ▸ 전체 터널(Full Tunnel): 모든 트래픽이 VPN을 통해 라우팅됨. ▸ 규정 준수: VPC 트래픽만 VPN 통과 요구사항. 【정답 포인트】 ▸ 정답: B - 분할 터널 옵션 활성화. ▸ 분할 터널을 OFF하면 모든 트래픽이 VPN 통과(전체 터널). ▸ 분할 터널을 ON하면 VPC 대상 트래픽만 VPN으로 라우팅. ▸ 규정 준수 요구사항: "VPC로만 트래픽" = VPC 이외 트래픽은 로컬 인터넷 사용. ▸ 이것이 분할 터널의 정의 자체. 【오답 체크】 (A) 70~90자: NAT 게이트웨이는 아웃바운드 인터넷 경로 제공만 할 뿐, 트래픽 분류 기능 없음. VPN 터널 통제 불가능. (C) 75~85자: DNS 설정은 이름 해석 문제만 해결하며, 트래픽 경로 결정과 무관. 규정 준수 요구사항과 직접 연결 안 됨. (D) 60~75자: ID 인증서는 VPN 인증 메커니즘일 뿐, 트래픽 라우팅 제어 불가. 【시험 포인트】 ▸ Client VPN의 분할 터널 개념 필수 암기. ▸ 규정 준수 = 트래픽 경로 제어 문제로 접근. ▸ 전체 터널 vs 분할 터널의 차이점 명확히 구분. ▸ AWS 보안 설계의 최소 권한 원칙과 연결.

해설

【핵심 용어】 ▸ Auto Scaling 프로세스 일시 중단: Launch(시작), Terminate(종료), Health Check(상태 확인) 등 제어 가능. ▸ 스케일 아웃 억제: Launch 프로세스 중단으로 신규 인스턴스 시작 차단. ▸ 근본 원인 분석: 스케일 아웃 없이 기존 인스턴스 진단. 【정답 포인트】 ▸ 정답: D - Launch 및 Terminate 프로세스 일시 중단. ▸ 목표: "스케일 아웃되기 전에 근본 원인 찾기". ▸ Launch 프로세스 중단 = 신규 인스턴스 시작 방지. ▸ Terminate 프로세스 중단 = 기존 인스턴스 보호. ▸ 이 상태에서 CPU 사용률 원인 분석 가능. ▸ CloudWatch, logs, 애플리케이션 프로파일링 등으로 진단. 【오답 체크】 (A) 65~80자: 스케일인 보호는 축소만 방지하고 확대는 막을 수 없음. 새로운 인스턴스 시작은 여전히 발생. (B) 70~85자: Standby 상태는 기존 인스턴스 1개만 격리. 5개 인스턴스 모두가 계속 유입 받음. (C) 60~75자: ALB 리스너 제거는 트래픽 차단하지만, 원인 분석과 무관. 임시방편 수단. 【시험 포인트】 ▸ Auto Scaling 프로세스 제어 메커니즘 숙지 필수. ▸ "Launch 및 Terminate" 프로세스 일시 중단의 정확한 효과 이해. ▸ 트러블슈팅 시나리오에서 프로세스 중단이 표준 진단 기법. ▸ AWS 운영 철학: 문제 격리 후 원인 분석.

해설

【핵심 용어】 ▸ EC2 상태 확인: 인스턴스 자체의 하드웨어/네트워크 상태(AutoScaling 기준). ▸ ALB 상태 확인: 애플리케이션 응답성(대상 그룹 기준, 포트/경로 기반). ▸ 상태 불일치: 두 상태 확인 기준의 차이로 발생. 【정답 포인트】 ▸ 정답: D - 대상 그룹 상태 확인 포트/경로 오설정. ▸ EC2 인스턴스는 실행 중(Auto Scaling 정상). ▸ ALB는 잘못된 포트/경로로 헬스 체크 시도 실패. ▸ 예: 애플리케이션이 8080 포트이나 ALB는 80으로 확인. ▸ 경로도 마찬가지: /health 엔드포인트 없을 때 404 발생. ▸ 이것이 가장 일반적인 원인. 【오답 체크】 (A) 70~85자: 보안 그룹 차단이면 EC2도 Auto Scaling에서 unhealthy 판정. 현 시나리오는 EC2는 정상, ALB만 비정상. (B) 75~90자: EC2 상태 확인 사용은 ALB 비정상 원인이 될 수 없음. Auto Scaling만 영향. (C) 80~95자: 시작 실패하면 인스턴스가 조차 작동 안 함. Auto Scaling도 unhealthy 표시. 【시험 포인트】 ▸ ALB와 Auto Scaling의 상태 확인 차이 명확히 이해. ▸ 헬스 체크 포트/경로 설정 오류가 실전 가장 흔한 문제. ▸ ALB 대상 그룹 설정에서 리스너 포트 vs 헬스 체크 포트 구분. ▸ 애플리케이션의 실제 수신 포트와 ALB 설정 일치 확인.

해설

【핵심 용어】 ▸ ELB 액세스 로그: 로드 밸런서를 통과한 모든 요청의 상세 기록(출처 IP, 타겟, 포트, 시간 등). ▸ CloudTrail: API 호출 기록(관리 이벤트). ▸ Auto Scaling 로그: 스케일링 이벤트 기록. 【정답 포인트】 ▸ 정답: D - Elastic Load Balancer 액세스 로그. ▸ ELB 액세스 로그 형식: 클라이언트 IP, 요청 경로, 응답 코드, 바이트 수 등 포함. ▸ RequestCount 메트릭만으로는 출처 IP 파악 불가능. ▸ ALB 액세스 로그를 S3에 저장 후 조회 가능. ▸ 로그에 "client:port"로 정확한 출처 정보 기록됨. ▸ 요청 분석의 표준 방법. 【오답 체크】 (A) 70~85자: Auto Scaling 로그는 인스턴스 시작/종료 이벤트만 기록. 요청 출처 IP 정보 없음. (B) 75~90자: CloudTrail은 AWS API 호출만 추적. 사용자의 애플리케이션 트래픽 정보 없음. (C) 70~80자: EC2 인스턴스 로그는 각 인스턴스 내부 로그만 포함. 로드 밸런서 수준의 전체 요청 출처 파악 불가. 【시험 포인트】 ▸ ELB 액세스 로그 활성화 및 S3 저장 메커니즘 숙지. ▸ CloudWatch 메트릭 vs 상세 로그의 차이 구분. ▸ 네트워크 트래픽 분석 시 액세스 로그의 중요성. ▸ 로드 밸런서 모니터링의 표준 구성 방식.

해설

【핵심 용어】 ▸ 클러스터 배치(Cluster): 단일 AZ, 저지연 고처리량. ▸ 파티션 배치(Partition): 여러 AZ, 대규모 분산 시스템. ▸ 스프레드 배치(Spread): 여러 AZ, 고가용성(인스턴스 간 격리). 【정답 포인트】 ▸ 정답: A - 클러스터 배치 그룹, 단일 AZ. ▸ HPC 특성: 매우 낮은 지연시간, 높은 대역폭 필수. ▸ 클러스터 배치: 10Gbps 네트워크 대역폭, 단일 자리 마이크로초 지연. ▸ AZ 내 물리적 근접도 극대화 = 최고 성능. ▸ HPC, 금융 시뮬레이션, 기계학습 클러스터 등 표준 배치. ▸ 단일 AZ 위험은 HPC 성능 요구가 더 중요. 【오답 체크】 (B) 65~80자: 파티션 배치는 여러 AZ 지원하지만 인스턴스 간 지연 증가. HPC 요구사항 미충족. (C) 75~85자: 파티션 배치는 Hadoop, Kafka 등 분산 시스템용. HPC의 극저지연 요구사항 맞지 않음. (D) 70~85자: 스프레드 배치는 고가용성 목표, 인스턴스 격리 우선. 네트워크 성능 최적화 반대. 【시험 포인트】 ▸ 세 가지 배치 그룹 유형의 명확한 구분과 용도 숙지. ▸ HPC = 클러스터 배치 연결 고정. ▸ AZ 선택이 성능에 미치는 영향 이해. ▸ 클러스터 배치의 저지연/고처리량 특성과 가용성 트레이드오프.