정답 · 해설

해설

【핵심 용어】 ▸ Gateway VPC Endpoint: S3 및 DynamoDB 전용, 무료, 경로 테이블로 관리 ▸ Interface VPC Endpoint: PrivateLink 기반, 시간당 비용 발생 ▸ VPC Endpoint Policy: 특정 S3 버킷만 접근 가능하도록 제한 【정답 포인트】 ▸ Gateway Endpoint는 모든 S3 버킷에 자동으로 적용 가능 ▸ 추가 비용 없음: AWS 관리형 게이트웨이 엔드포인트는 무료 ▸ 단일 엔드포인트: 50개 버킷 모두 하나의 엔드포인트로 접근 ▸ 구성 간단: 경로 테이블에 경로 추가만으로 사용 가능 ▸ 버킷별 정책으로 세밀한 접근 제어 가능 【오답 체크】 (A) 각 버킷마다 엔드포인트 생성 불필요 (B) Interface Endpoint는 시간당 요금 발생 (D) 하나의 Interface Endpoint로 50개 버킷 모두 접근 가능하지만 비용 발생 【시험 포인트】 ▸ VPC Endpoint 선택: S3/DynamoDB → Gateway(무료), 기타 서비스 → Interface(유료) ▸ 비용 최적화 문제의 답: 항상 Gateway Endpoint 검토 ▸ 보안 + 성능: 엔드포인트 정책으로 특정 버킷만 접근 제한 가능

해설

【핵심 용어】 ▸ SSM Agent: EC2 인스턴스에서 Systems Manager와 통신하는 에이전트 ▸ Instance Profile(IAM Role): EC2가 AWS 서비스와 통신하기 위한 권한 ▸ AmazonSSMManagedInstanceCore: Session Manager 최소 필수 권한 【정답 포인트】 ▸ Session Manager는 SSH(포트 22)를 사용하지 않음 ▸ IAM 정책 부족: 인스턴스 프로필에 SSM 권한이 없으면 에이전트가 Systems Manager와 통신 불가 ▸ AmazonSSMManagedInstanceCore 정책이 필수: ssm:UpdateInstanceInformation, ssmmessages:*, ec2messages:* 권한 포함 ▸ 다른 인스턴스 작동: 그 인스턴스들에는 적절한 IAM 역할이 할당되어 있음 【오답 체크】 (A) Session Manager는 SSH(포트 22) 미사용 (C) SSM Agent 사용자명 설정과 무관 (D) 키 쌍 생성은 Session Manager(비SSH) 운영과 무관 【시험 포인트】 ▸ Session Manager 문제 해결 순서: IAM 권한 → 보안 그룹(HTTPS 아웃바운드) → 네트워크 경로 ▸ EC2 Instance Profile 확인이 가장 일반적인 원인 ▸ Systems Manager 통신은 HTTPS(포트 443)이며 프라이빗 엔드포인트 권장

해설

【핵심 용어】 ▸ CloudWatch Alarm: 메트릭 데이터를 지정된 임계값과 비교하여 상태 결정 ▸ 상태 평가: 알람은 지속적으로 메트릭을 모니터링하며 상태 결정 ▸ 자동 상태 전환: 메트릭 값이 정상 범위로 돌아오면 자동으로 OK 상태로 변경 【정답 포인트】 ▸ CloudWatch는 알람 트리거 후에도 계속 메트릭을 평가 ▸ ALARM 상태 유지: 메트릭 값이 계속 임계값을 초과하고 있기 때문 ▸ 상태 자동 복구: 메트릭이 정상으로 돌아오면 자동으로 OK 상태로 변경 ▸ 수동 개입 불필요: 임계값을 초과한 상태가 지속되면 알람도 지속됨 【오답 체크】 (B) 알람은 자동으로 상태 변경, 수동 비활성화 필요 없음 (C) 애플리케이션이 상태 재설정할 필요 없음 ▸ CloudWatch 자동 관리 (D) 메트릭을 수신하지 않으면 INSUFFICIENT_DATA 상태 표시 【시험 포인트】 ▸ CloudWatch 알람의 세 가지 상태: OK, ALARM, INSUFFICIENT_DATA ▸ 상태 전환은 메트릭과 임계값의 관계에 따라 자동 결정 ▸ 지속적인 문제 메트릭이 진정한 원인 파악 필요

해설

【핵심 용어】 ▸ VPN Connection: Site-to-Site VPN으로 온프레미스와 AWS 연결 ▸ Virtual Private Gateway(VGW): VPC의 VPN 종료점 ▸ Route Propagation: VGW가 학습한 경로를 자동으로 경로 테이블에 추가 【정답 포인트】 ▸ 터널이 UP이지만 통신 불가: 경로 테이블에 온프레미스 CIDR 경로가 없음 ▸ Route Propagation 활성화: VGW에서 배운 경로(온프레미스 CIDR)를 경로 테이블에 자동 추가 ▸ 경로 학습: VPN 터널을 통한 트래픽이 올바른 게이트웨이로 라우팅됨 ▸ 수동 경로 추가 대안: 정적 경로 추가도 가능하나 자동화가 더 효율적 【오답 체크】 (A) 보안 그룹은 ICMP 허용하더라도 경로 테이블 부재 시 도달 불가 (B) 피어링은 VPN과 무관한 다른 연결 방식 (D) DHCP 옵션은 DNS 설정 관련이지 경로와 무관 【시험 포인트】 ▸ VPN 문제 해결 체크리스트: VPN 상태 → 경로 테이블 → 보안 그룹 → 네트워크 ACL ▸ Route Propagation은 Site-to-Site VPN 필수 기능 ▸ VGW 생성만으로는 부족, 경로 테이블 연결 및 전파 설정 필요

해설

【핵심 용어】 ▸ Aurora Replica: 동일 클러스터 내 읽기 전용 복제본으로 자동 페일오버 지원 ▸ Read-Only Endpoint: 모든 복제본에 자동으로 분산되는 읽기 연결 ▸ Auto Scaling: 복제본 수를 자동으로 조정하여 비용 최적화 【정답 포인트】 ▸ 문제 진단: 보고 쿼리가 주 인스턴스의 CPU와 연결을 고갈시킴 ▸ Aurora Replica 추가: 읽기 작업 분산으로 주 인스턴스 부하 감소 ▸ CPU 기반 Auto Scaling: 읽기 부하 증가 시 자동으로 복제본 추가 ▸ Read-Only Endpoint 사용: 애플리케이션 수정 최소화, 자동 분산 【오답 체크】 (B) 별도 클러스터는 데이터 동기화 지연 및 비용 증가 (C) Lambda는 처리 지연 가능성이 높음 (D) ElastiCache는 캐시 관리 복잡도 증가, Aurora Replica가 더 효율적 【시험 포인트】 ▸ Aurora의 강점: 완전 관리형 읽기 복제본 Auto Scaling ▸ 보고 부하 분산: Aurora Replica + Read-Only Endpoint 조합이 표준 ▸ 비용 효율성: 필요한 만큼만 복제본 유지

해설

【핵심 용어】 ▸ ALIAS Record: AWS 리소스(CloudFront, ALB, S3 등)를 가리키는 Route 53 고유 레코드 타입, 쿼리 비용 없음 ▸ CNAME Record: 표준 DNS CNAME으로 쿼리마다 추가 DNS 조회 비용 ▸ 비용 최적화: ALIAS 사용 시 Route 53 쿼리 비용 면제 【정답 포인트】 ▸ CloudFront는 AWS 서비스이므로 ALIAS 레코드 가능 ▸ 비용 절감: ALIAS 쿼리는 요금 청구 안 됨 ▸ CNAME보다 효율적: 표준 DNS 오버헤드 제거 ▸ www.example.com 유지: 하위 도메인도 ALIAS 지원 【오답 체크】 (A) CNAME은 가능하지만 쿼리마다 비용 발생, CloudFront 배포에는 ALIAS 권장 (C) CloudFront URL이 아닌 원본 IP 사용은 CloudFront 우회 (D) PTR은 역방향 DNS 조회용이며 부적절 【시험 포인트】 ▸ ALIAS vs CNAME: AWS 리소스 → ALIAS(비용 없음), 외부 → CNAME(비용 있음) ▸ CloudFront 배포와 Route 53의 필수 조합: ALIAS 레코드 필수 ▸ AWS 서비스 호환성: ALB, S3, API Gateway, CloudFront 모두 ALIAS 지원

해설

【핵심 용어】 ▸ Cross-Account Role: 다른 계정의 사용자가 수임(Assume)할 수 있는 IAM 역할 ▸ 최소 권한 원칙: 필요한 최소 권한만 부여(관리자 제외) ▸ Trust Policy: 역할을 수임할 수 있는 주체 지정 【정답 포인트】 ▸ 교차 계정 접근의 안전한 방식: 자격증명 공유 제외 ▸ 읽기 전용 권한: VPC 검토만 필요하므로 쓰기 권한 제거 ▸ 역할 수임: 임시 자격증명으로 최소 권한 제공 ▸ 감사 추적: 역할 사용 기록이 CloudTrail에 남음 【오답 체크】 (A) 자격증명 공유는 보안 위험 ▸ 사용자 개인 정보 노출 (B) 관리자 권한은 과도함 ▸ 읽기 전용으로 충분 (C) 교차 계정 역할은 맞지만 관리자 권한 과도 【시험 포인트】 ▸ 다중 계정 관리: 자격증명 공유 금지 → 교차 계정 역할 필수 ▸ 최소 권한: 읽기 전용이 기본, 필요 시만 쓰기 권한 추가 ▸ Organizations 환경에서의 거버넌스 표준 패턴

해설

【핵심 용어】 ▸ AWS Config: AWS 리소스 변경 감지 및 규칙 기반 자동화 ▸ Systems Manager Automation Runbook: 자동 치료 조치 수행 ▸ CloudWatch: 메트릭 기반 모니터링 (규칙 기반 자동화 없음) ▸ Inspector: 인스턴스 에이전트 기반 취약점 평가 【정답 포인트】 ▸ B(AWS Config): 보안 그룹 규칙 변경을 감지하는 데 최적화되어 있습니다. 규칙 위반 시 자동 치료를 구성할 수 있습니다. ▸ D(Automation Runbook): 보안 그룹에서 SSH 포트(22)를 닫는 자동 치료 조치를 실행합니다. ▸ 이 조합으로 감지와 자동 해결이 동시에 이루어집니다. 【오답 체크】 ▸ A(CloudWatch 알람): 보안 그룹 규칙 변경을 직접 모니터링할 수 없고, 알람만 발생합니다. 자동 치료 기능이 없습니다. ▸ C(Inspector): EC2 인스턴스의 취약점을 평가하지만 보안 그룹 규칙 변경을 감지하지 못합니다. ▸ E(Run Command): 일회용 명령 실행이며 지속적인 모니터링과 자동 응답이 불가능합니다. 【시험 포인트】 ▸ AWS Config는 리소스 구성 변경을 추적하고 규칙 기반 자동 치료를 지원합니다(CloudWatch는 지원 안 함). ▸ 정책 위반 시 자동 응답이 필요한 경우: Config 규칙 + Automation Runbook 조합 사용.

해설

【핵심 용어】 ▸ Warm Pool: 사전에 구성된 준비 상태의 인스턴스 집합 ▸ 부트 지연(Boot Lag): 인스턴스 시작 시간 지연 ▸ 스케일 아웃: 새로운 인스턴스 추가 ▸ 과도한 프로비저닝: 불필요한 리소스 사전 배포 【정답 포인트】 ▸ D(Warm Pool): 사전에 생성되고 구성된 준비 상태의 인스턴스들을 유지합니다. ▸ 스케일 아웃 필요 시 이 인스턴스들을 재개하기만 하면 되어 부트 시간을 대폭 단축합니다(초 단위). ▸ 필요할 때만 재활성화되므로 과도한 프로비저닝을 피합니다. 【오답 체크】 ▸ A(더 큰 인스턴스): 인스턴스 크기는 부트 시간과 무관하며 오히려 부트 프로세스가 더 복잡할 수 있습니다. ▸ B(최소 인스턴스 증가): 항상 대기 중인 추가 인스턴스 비용이 발생하므로 과도한 프로비저닝입니다. ▸ C(예측 스케일링): 미래 수요를 예측하지만 기존 부트 시간 문제는 해결하지 못합니다. 【시험 포인트】 ▸ Warm Pool은 Auto Scaling 성능 최적화 위한 AWS 고급 기능입니다. ▸ 빠른 응답성이 필요한 경우와 과도한 프로비저닝을 피해야 하는 경우의 최적 솔루션입니다.

해설

【핵심 용어】 ▸ Cross-Region AMI Copy: AMI를 다른 리전으로 복사하는 메커니즘 ▸ CloudFormation Mapping: 리전별 리소스 ID 매핑 ▸ Fully Configured AMI: 모든 소프트웨어와 설정을 포함한 AMI ▸ 운영 효율성: 최소한의 수동 작업과 자동화 【정답 포인트】 ▸ A(aws ec2 copy-image): 이미 완전히 구성된 AMI를 각 리전에 복사하는 가장 빠른 방법입니다. ▸ copy-image는 AWS에서 지원하는 표준 도구로, 100개 이상의 인스턴스 구성을 재현할 필요가 없습니다. ▸ CloudFormation 매핑으로 각 리전의 복사된 AMI ID를 참조하면 단일 템플릿으로 배포 가능합니다. 【오답 체크】 ▸ B(스냅샷 방식): 인스턴스 기반 스냅샷은 비효율적이고 AMI 복사보다 느립니다. ▸ C(각 리전마다 실행): 각 리전에서 CloudFormation 템플릿을 별도로 실행하므로 비효율적입니다. ▸ D(Auto Scaling 그룹): 단일 스택에서 여러 리전의 Auto Scaling을 관리할 수 없으며 아키텍처상 부적절합니다. 【시험 포인트】 ▸ 이미 구성된 리소스를 여러 리전에 배포할 때는 copy-image + CloudFormation 매핑 조합이 표준입니다. ▸ 스냅샷 기반 복사는 블록 스토리지 레벨이므로 더 느리고 복잡합니다.

해설

【핵심 용어】 ▸ EventBridge: AWS 이벤트 기반 아키텍처의 핵심 서비스 ▸ SNS 직접 통합: EventBridge에서 SNS 주제로 직접 메시지 전송 ▸ EC2 인스턴스 상태 이벤트: running, stopped, terminated 등 ▸ 운영 효율성: 최소 지연, 간단한 구성, 낮은 비용 【정답 포인트】 ▸ B(EventBridge + SNS): EC2 인스턴스 상태 변경 이벤트가 발생하면 EventBridge가 감지합니다. ▸ EventBridge가 SNS 주제로 직접 메시지를 전송하므로 Lambda 같은 중간 계층 없이 즉시 알림이 전달됩니다. ▸ 가장 간단하고 비용이 적으며 지연이 없는 솔루션입니다. 【오답 체크】 ▸ A(스크립트 + Run Command): 각 인스턴스에서 폴링 방식 모니터링은 비효율적이고 지연이 발생합니다. ▸ C(EventBridge + Lambda + SNS): Lambda를 거치므로 B보다 느리고 복잡하며 비용이 증가합니다. ▸ D(Config 규칙): Config는 리소스 구성 변경을 평가하며, 실시간 상태 변경 이벤트 모니터링에는 적합하지 않습니다. 【시험 포인트】 ▸ 실시간 이벤트 기반 통지 = EventBridge를 직접 SNS와 연동 ▸ Lambda는 이벤트 변환, 필터링, 복잡한 로직이 필요할 때만 사용합니다.

해설

【핵심 용어】 ▸ Elastic IP: 고정된 공용 IP 주소 (EC2와 1:1 연결) ▸ Route 53 A 레코드: 도메인을 IPv4 주소로 매핑 ▸ CNAME: 도메인을 다른 도메인으로 매핑 (IP 주소 직접 매핑 불가) ▸ 최소 노력: 자동 스케일링 대신 고정 구성 【정답 포인트】 ▸ D(Elastic IP): 단일 정적 IP 주소가 필요하므로 Elastic IP를 생성하여 EC2와 연결합니다. ▸ B(Route 53 A 레코드): example.com을 Elastic IP 주소로 매핑하여 사용자가 도메인으로 접속할 수 있습니다. ▸ 이 조합으로 단순하고 관리 오버헤드가 최소화됩니다. 【오답 체크】 ▸ A(ALB): ALB는 여러 인스턴스 로드 밸런싱을 위한 것이며, 단일 EC2에는 추가 복잡도입니다. ▸ C(CNAME): CNAME은 도메인을 다른 도메인으로만 매핑 가능하며, IP 주소 직접 매핑은 불가능합니다. ▸ E(Auto Scaling): 단일 정적 IP를 필요로 하는데 Auto Scaling은 다중 인스턴스를 생성하므로 불필요합니다. 【시험 포인트】 ▸ 단일 고정 IP 필요 = Elastic IP (공용 IP는 인스턴스 재시작 시 변경) ▸ Route 53 A 레코드: 도메인 → IPv4 주소 매핑 (표준 구성) ▸ CNAME은 도메인 간 별칭만 가능하므로 IP 주소와 사용할 수 없습니다.

해설

【핵심 용어】 ▸ DynamoDB Global Table: 여러 리전의 테이블을 자동으로 동기화 ▸ DynamoDB Streams: 데이터 변경 이벤트를 캡처하는 메커니즘 ▸ Point-in-Time Recovery: 특정 시점으로의 복구 (단일 리전) ▸ DAX: 캐싱 계층 (성능 향상, 복제 아님) 【정답 포인트】 ▸ C(Streams + Global Table): DynamoDB Streams를 활성화하면 테이블 변경이 감지됩니다. ▸ Global Table 리전을 추가하면 AWS가 자동으로 다른 리전에서 테이블을 생성하고 변경사항을 동기화합니다. ▸ 다중 리전 재해 복구에 최적의 솔루션입니다. 【오답 체크】 ▸ A(DAX): 인 메모리 캐시로 성능을 향상시키지만 복제 기능은 없습니다. ▸ B(Streams + GSI): GSI는 보조 인덱스이며 리전 간 복제와는 무관합니다. ▸ D(Point-in-Time Recovery): 같은 리전 내에서만 시점 복구가 가능하며 다른 리전으로의 복제는 아닙니다. 【시험 포인트】 ▸ 다중 리전 활성-활성 복제 = DynamoDB Global Table ▸ Global Table은 Streams를 자동으로 활성화하므로 Streams를 명시적으로 활성화해야 합니다. ▸ PITR과 Global Table은 다른 목적: PITR은 시간 범위 내 단일 리전 복구, Global Table은 다중 리전 실시간 동기화.

해설

【핵심 용어】 ▸ HTTP Redirect: HTTP → HTTPS로의 자동 리다이렉트 ▸ HTTPS Listener: 암호화된 통신을 위한 포트 443 리스너 ▸ SSL/TLS 인증서: ACM에서 관리되는 디지털 인증서 ▸ 사용자 경험: 기존 HTTP 링크로 접속해도 자동으로 HTTPS로 전환 【정답 포인트】 ▸ D(HTTP Redirect + HTTPS Listener): 기존 사용자는 HTTP(80)로 접속하지만 ALB가 자동으로 HTTPS(443)로 리다이렉트합니다. ▸ 별도의 HTTPS 리스너를 생성하여 암호화된 통신을 처리합니다. ▸ 사용자는 엔드포인트 변경 없이 자동으로 보안 연결로 전환됩니다. 【오답 체크】 ▸ A(HTTPS 리스너만): HTTPS 리스너를 추가하지만 HTTP 요청을 리다이렉트하지 않으면 사용자가 수동으로 HTTPS로 변경해야 합니다. ▸ B(HTTP 리스너 삭제): 기존 HTTP 사용자가 연결할 수 없게 되므로 "기존 사용자 변경 불필요" 요구사항 위반입니다. ▸ C(HTTP 규칙 수정): HTTPS 암호화를 위한 리스너를 생성하지 않으므로 암호화 요구사항을 충족하지 못합니다. 【시험 포인트】 ▸ "기존 사용자 변경 불필요" = HTTP → HTTPS 리다이렉트 필수 ▸ ALB HTTP 리스너의 기본 규칙을 리다이렉트 작업으로 설정 ▸ 별도의 HTTPS(443) 리스너와 인증서로 암호화된 통신 처리.

해설

【핵심 용어】 ▸ Compute Savings Plans: EC2 및 Fargate를 포함한 컴퓨팅 비용 절감 ▸ EC2 Instance Savings Plans: EC2 인스턴스 전용 (Fargate 미포함) ▸ Reserved Instances: EC2 인스턴스 전용 (컨테이너/Fargate 미포함) ▸ 6개월 전환: EC2에서 Fargate로의 마이그레이션 기간 【정답 포인트】 ▸ B(Compute Savings Plans + 부분 선불): Compute Savings Plans은 EC2와 Fargate 모두를 지원합니다. ▸ 6개월 후 EC2를 완전히 폐기하고 Fargate만 사용하므로, Compute Savings Plans으로 두 서비스의 비용을 절감할 수 있습니다. ▸ 부분 선불은 선불 비용을 최소화하면서도 할인을 받을 수 있습니다. 【오답 체크】 ▸ A(Compute Savings Plans No Upfront): 할인율이 부분 선불보다 낮으므로 최적이 아닙니다. ▸ C(EC2 Instance Savings Plans): EC2 인스턴스만 지원하며 Fargate는 지원하지 않습니다. ▸ D(EC2 Reserved Instances): EC2 인스턴스만 지원하며 Fargate는 지원하지 않습니다. 【시험 포인트】 ▸ Compute Savings Plans: EC2, Fargate, Lambda 등 다양한 컴퓨팅 서비스 지원 ▸ EC2 Savings Plans / RI: EC2 전용 (Fargate 지원 안 함) ▸ 여러 서비스 전환 시 Compute Savings Plans의 유연성이 중요합니다.

해설

【핵심 용어】 ▸ AWS Secrets Manager: 자동 비밀번호 로테이션 기능이 있는 전용 서비스 ▸ 자동 로테이션: Secrets Manager가 Lambda를 통해 자동으로 비밀번호 변경 ▸ 암호화 저장: 모든 자격증명이 암호화되어 저장됨 ▸ 운영 효율성: 최소한의 수동 구성과 자동 관리 【정답 포인트】 ▸ C(AWS Secrets Manager): 데이터베이스 자격증명 저장 및 자동 로테이션 전용 서비스입니다. ▸ Secrets Manager는 자동으로 Lambda 함수를 호출하여 데이터베이스 비밀번호를 변경하고 저장된 자격증명을 업데이트합니다. ▸ 30일 자동 회전 일정 설정만으로 이후 모든 과정이 자동화됩니다. ▸ 평문 저장 없이 암호화된 상태로 관리됩니다. 【오답 체크】 ▸ A(환경 변수): 평문 환경 변수는 보안 위험이 있으며 수동 로테이션이 필요합니다. ▸ B(KMS 암호화): 비밀번호는 암호화되지만 로테이션을 수동으로 구현해야 하며 비효율적입니다. ▸ D(Parameter Store): Parameter Store는 기본 KMS 암호화를 지원하지만 자동 로테이션 기능이 없습니다. 【시험 포인트】 ▸ 자동 비밀번호 로테이션 필요 = AWS Secrets Manager 필수 ▸ Secrets Manager는 RDS, DynamoDB 등 AWS 서비스와 기본 통합 ▸ Parameter Store는 일반 구성 저장용; Secrets Manager는 자격증명 로테이션용.

해설

【핵심 용어】 ▸ AWS WAF: 웹 애플리케이션 방화벽 (ALB에서 계층 7 필터링) ▸ IP Set: 특정 IP 주소들의 목록 ▸ Web ACL: 웹 요청에 대한 규칙 모음 ▸ Security Group: 인스턴스 레벨 (계층 4) 방화벽 【정답 포인트】 ▸ D(AWS WAF): 특정 IP 주소를 기반으로 HTTP/HTTPS 요청을 차단하는 가장 효과적인 솔루션입니다. ▸ IP 세트를 생성하여 악의적인 IP를 추가하고, BLOCK 작업으로 설정하여 ALB 수준에서 차단합니다. ▸ 웹 ACL을 ALB에 연결하면 악의적인 트래픽이 인스턴스에 도달하기 전에 차단됩니다. 【오답 체크】 ▸ A(Security Group): 보안 그룹은 인스턴스 레벨에서만 작동하므로 ALB에 연결할 수 없습니다. ▸ B(Amazon Detective): 위협 감지 및 분석 서비스이며 실시간 트래픽 차단 기능이 없습니다. ▸ C(AWS RAM): 리소스 공유 서비스이며 트래픽 필터링과 무관합니다. 【시험 포인트】 ▸ ALB 수준에서 특정 IP 차단 = AWS WAF + IP 세트 ▸ Security Group은 ALB에 연결할 수 없으므로 애플리케이션 레이어 필터링은 WAF 사용 ▸ WAF는 계층 7(Application) 필터링으로 HTTP/HTTPS 요청 세부 분석 가능.

해설

【핵심 용어】 ▸ cfn-signal: CloudFormation Wait 조건에 신호를 보내는 도구 ▸ Wait Condition: 스택이 계속되기 전에 특정 신호를 기다리는 리소스 ▸ 사용자 데이터: EC2 인스턴스 시작 시 실행되는 스크립트 ▸ 신호 부족: Wait 조건이 필요한 신호를 받지 못함 【정답 포인트】 ▸ A(cfn-signal): 사용자 데이터 스크립트의 끝에 cfn-signal 명령을 추가하면 인스턴스가 정상적으로 초기화되었음을 CloudFormation에 알립니다. ▸ CloudFormation은 이 신호를 받고 Wait 조건을 완료하며 스택 생성을 계속합니다. ▸ 이것은 Wait 조건 신호 부족 문제의 표준 해결책입니다. 【오답 체크】 ▸ B(포트 443): EC2 인스턴스가 CloudFormation 메타데이터 서버와 통신하기 위해서는 포트 443이 열려있어야 하지만, 이것은 별도의 문제이며 cfn-signal이 주요 해결책입니다. ▸ C(DesiredCapacity 감소): 신호 부족 문제를 해결하지 못합니다. ▸ D(AssociatePublicIpAddress): 공용 IP 할당과는 무관한 신호 메커니즘입니다. 【시험 포인트】 ▸ CloudFormation Wait Condition 신호 실패 = cfn-signal 실행 확인 ▸ cfn-signal은 사용자 데이터 스크립트 완료 후에 호출되어야 합니다. ▸ 포트 443 아웃바운드도 중요하지만 일차적 원인은 cfn-signal 누락입니다.

해설

【핵심 용어】 ▸ Inbound Resolver Endpoint: 온프레미스에서 AWS로 들어오는 DNS 요청을 처리 ▸ Outbound Resolver Endpoint: AWS에서 온프레미스로 나가는 DNS 요청을 처리 ▸ DNS 해석: host1.awscloud private (AWS) ← host1.onprem private (온프레미스) ▸ Site-to-Site VPN: 온프레미스와 AWS 간 연결 【정답 포인트】 ▸ B(인바운드 리졸버 + awscloud.private): 온프레미스에서 AWS의 awscloud.private 호스트명을 해석해야 합니다. ▸ 인바운드 리졸버 엔드포인트는 AWS VPC 측에 생성되어 온프레미스의 DNS 쿼리를 받습니다. ▸ 온프레미스 DNS 리졸버가 awscloud.private 쿼리를 인바운드 엔드포인트로 전달하면, Route 53이 이를 AWS 호스트명으로 해석합니다. 【오답 체크】 ▸ A(인바운드 + onprem.private): onprem.private는 온프레미스 호스트명이므로 온프레미스 DNS가 이미 해석할 수 있습니다. ▸ C(아웃바운드 + onprem.private): 아웃바운드는 AWS에서 온프레미스로 쿼리할 때 사용하므로 요구사항과 맞지 않습니다. ▸ D(아웃바운드 + awscloud.private): 아웃바운드는 온프레미스 호스트명 해석용이므로 awscloud.private 해석에 부적합합니다. 【시험 포인트】 ▸ 온프레미스 → AWS 호스트명 해석 = 인바운드 리졸버 (AWS VPC 측에 생성) ▸ AWS → 온프레미스 호스트명 해석 = 아웃바운드 리졸버 (AWS VPC 측에 생성) ▸ DNS 방향을 명확히 파악하는 것이 중요합니다.

해설

【핵심 용어】 ▸ CloudFormation StackSet: 여러 AWS 계정과 리전에 리소스를 배포하는 도구 ▸ Service-Managed Permissions: AWS Organizations를 통한 자동 권한 관리 ▸ 단일 템플릿: 여러 계정/리전에서 재사용 ▸ 중앙 관리 계정: Organizations 마스터 계정 【정답 포인트】 ▸ D(StackSet + Service-Managed): CloudFormation StackSet은 단일 템플릿을 여러 계정과 리전에 배포하도록 설계되었습니다. ▸ Service-Managed 권한은 AWS Organizations를 활용하여 자동으로 권한을 관리하므로 각 계정에 수동 권한 설정이 불필요합니다. ▸ 중앙 관리 계정에서 한 번에 모든 계정과 리전으로 배포 가능합니다. 【오답 체크】 ▸ A(CRR): S3 Cross-Region Replication은 버킷 간 복제이며 다중 계정 배포를 지원하지 않습니다. ▸ B(중첩 스택): 중첩 스택은 단일 계정 내에서만 작동하며 다른 계정으로 배포 불가능합니다. ▸ C(중첩 스택 + 계정/리전): 중첩 스택은 구조상 다중 계정 배포를 지원하지 않습니다. 【시험 포인트】 ▸ 다중 AWS 계정 + 다중 리전 배포 = CloudFormation StackSet 필수 ▸ Service-Managed Permissions: Organizations와 통합으로 권한 자동 관리 ▸ StackSet은 Organizations 환경에서 운영 효율성을 극대화하는 표준 패턴입니다.