📘 Q102 문제 정리

🔹 문제 요약

• 회사는 EC2 Auto Scaling 그룹을 사용, 평균 CPU 사용률을 기준으로 확장 중
• 이벤트 로그에서 InsufficientInstanceCapacity 오류 발생
  → 새 인스턴스를 시작하려 했으나 해당 AZ에 여유 용량 없음

👉 SysOps 관리자가 취할 수 있는 조치는 무엇일까? (2개 선택)

---

🔹 선택지 분석

• A. 인스턴스 유형 변경
  → 현재 AZ에서 특정 인스턴스 타입의 가용 용량이 부족한 상황
  → 다른 인스턴스 타입을 사용하면 새 인스턴스를 실행할 수 있음 ✅
• B. 다른 가용 영역(AZ)에 Auto Scaling 그룹 확장
  → 여러 AZ에 인스턴스를 분산하면 특정 AZ 용량 부족 문제를 피할 수 있음 ✅
• C. EBS 볼륨 크기를 키움
  → 디스크 크기와 용량 부족은 무관 ❌
• D. Auto Scaling 그룹 최대 크기 증가
  → 한도 설정 문제가 아니라 물리적 가용 용량 문제이므로 효과 없음 ❌
• E. 서비스 할당량 증가 요청
  → 계정 한도 문제가 아니라 리전/AZ 자원 가용성 문제라서 해당 없음 ❌

✅ 정답: A, B

---

📝 쉬운 해설

• InsufficientInstanceCapacity = 특정 인스턴스 타입을 해당 AZ에서 더 이상 프로비저닝할 수 없는 경우 발생
• 해결책은 인스턴스 타입 변경 또는 다른 AZ에 배포

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “InsufficientInstanceCapacity = 타입 바꾸거나, AZ 분산”

• 타입 변경 ✅
• 다른 AZ 활용 ✅
• EBS 크기/ASG 한도/서비스 할당량 ❌

---

📘 Q103 문제 정리

🔹 문제 요약

• SysOps 관리자가 AWS Systems Manager Session Manager를 사용해 EC2 인스턴스 그룹에 대한 액세스를 제어해야 함
• 특정 태그는 이미 EC2 인스턴스에 추가된 상태
• 추가로 어떤 조치를 해야 액세스를 제어할 수 있을까? (2개 선택)

---

🔹 선택지 분석

• A. IAM 정책을 사용자/그룹에 연결 → EC2 인스턴스 접근 권한 부여
  → Session Manager 접근을 위한 IAM 정책 필요 ✅
• B. IAM 역할을 연결하여 EC2 자체 접근 제어
  → EC2 인스턴스 프로파일과는 다르며, 직접 IAM 역할만으로는 제어 불가 ❌
• C. EC2 배치 그룹 생성 후 태그 추가
  → 배치 그룹은 물리적 배치 관리 목적, 액세스 제어와 무관 ❌
• D. 서비스 계정을 생성해 EC2 연결
  → AWS IAM 역할/정책 기반으로 해야 하므로 오답 ❌
• E. Condition 요소를 활용한 IAM 정책 작성 (태그 기반 접근 제어)
  → 특정 태그가 있는 EC2 인스턴스만 접근 가능하도록 제어 가능 ✅

✅ 정답: A, E

---

📝 쉬운 해설

1. IAM 정책: Session Manager를 통해 접속하려면 IAM 사용자/그룹/역할에 정책을 연결해야 함
2. Condition 요소: IAM 정책 조건으로 "특정 태그가 있는 EC2 인스턴스만 접근 가능"을 설정 가능

즉, IAM 정책 연결 + 태그 기반 조건 설정이 핵심 조치입니다.

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “SSM 접근 제어 = IAM 정책 + 태그 조건”

• IAM 정책 연결 필수
• 태그 기반 Condition으로 세밀 제어 가능

---

📘 Q105 문제 정리

🔹 문제 요약

• AWS Lambda 함수가 하루에 여러 번 간헐적으로 실패
• SysOps 관리자는 지난 7일 동안 이 오류가 얼마나 자주 발생했는지 확인해야 함
• 가장 운영상 효율적인 방법은?

---

🔹 선택지 분석

• A. Amazon Athena로 CloudWatch 로그 쿼리
  → 가능은 하지만 로그를 S3로 내보낸 뒤 Athena로 쿼리해야 해서 비효율적 ❌
• B. Amazon Athena로 CloudTrail 로그 쿼리
  → CloudTrail은 API 호출 기록, Lambda 실행 실패 세부 로그는 없음 ❌
• C. CloudWatch Logs Insights 사용
  → Lambda 로그가 기본적으로 CloudWatch Logs에 저장됨
  → Logs Insights는 로그를 직접 쿼리하고 기간 지정(예: 최근 7일) 가능 ✅
• D. OpenSearch Service + 로그 스트리밍
  → 구축 가능하지만 별도 스트리밍/인덱싱 필요, 운영 오버헤드 큼 ❌

✅ 정답: C

---

📝 쉬운 해설

• Lambda 로그 = CloudWatch Logs 기본 저장
• Logs Insights: CloudWatch Logs 데이터를 실시간으로 쿼리/분석 가능
• "지난 7일간 오류 패턴" 같은 질문에 즉시 활용 가능

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “Lambda 실행 오류 분석 = CloudWatch Logs Insights”

• CloudTrail ❌ (API 호출 기록)
• Athena ❌ (S3 내보내야 함)
• OpenSearch ❌ (추가 구성 필요)

---

📘 Q112 문제 정리

🔹 문제 요약

• 회사 애플리케이션: Elastic Load Balancer (ELB) 뒤의 EC2 Auto Scaling 그룹에서 실행
• 평상시에는 성능 안정적
• 하지만 트래픽이 증가하면 매일 동일한 4시간 동안 성능 저하 발생

👉 이 문제를 해결할 수 있는 가장 효율적인 방법은?

---

🔹 선택지 분석

• A. 가중치 라우팅 정책 사용 + 두 번째 ELB 구성
  → 불필요하게 복잡하며 문제의 원인(트래픽 피크 시간 성능 저하) 해결에 맞지 않음 ❌
• B. 더 큰 인스턴스 유형 사용
  → 성능 개선 가능하지만, 특정 시간대만 부하가 증가하므로 비용 낭비 ❌
• C. EC2 인스턴스 수를 예약 조정 작업(Scheduled Scaling)으로 확장
  → ✅ 정답
  → 트래픽 증가 시간이 예측 가능(매일 동일 4시간)하므로 예약된 스케일링으로 미리 인스턴스 확장 가능
• D. 수동으로 EC2 인스턴스 추가
  → 관리 부담 크고 자동화되지 않음 ❌

✅ 정답: C

---

📝 쉬운 해설

• Auto Scaling은 2가지 방식으로 동작:
  1. 동적 스케일링 → CloudWatch 지표 기반 (예: CPU > 70%)
  2. 예약 스케일링 → 트래픽 피크 시간이 미리 예측 가능할 때 사용
• 이 문제는 “매일 같은 시간에 성능 저하” → 예약 스케일링(Scheduled Scaling)이 정답

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “매일 같은 시간대 트래픽 증가 = Scheduled Scaling”

• 예측 불가 = 동적 스케일링
• 예측 가능 = 예약 스케일링

---

📘 Q113 문제 정리

🔹 문제 요약

• 회사는 단일 리전의 EC2 인스턴스에서 애플리케이션을 호스팅
• 애플리케이션은 HTTP가 아닌 TCP 트래픽 지원 필요
• AWS 네트워크를 활용해 짧은 지연 시간으로 콘텐츠 제공 원함
• Auto Scaling 그룹과 탄력적 로드 밸런싱도 필요

👉 어떤 아키텍처가 요구사항을 충족할까?

---

🔹 선택지 분석

• A. ALB + CloudFront
  → ALB는 HTTP/HTTPS 레벨 7 전용, TCP 지원 불가 ❌
• B. ALB + Global Accelerator
  → Global Accelerator는 ALB를 엔드포인트로 지원하지만, TCP/UDP 지원을 위해서는 NLB 사용이 더 적합 ❌
• C. NLB + CloudFront
  → CloudFront는 HTTP/HTTPS 캐싱 전용 서비스, TCP 트래픽 가속화는 불가 ❌
• D. NLB + Global Accelerator
  → NLB는 TCP/UDP 레벨 4 로드 밸런싱 지원 ✅
  → Global Accelerator는 AWS 글로벌 네트워크를 통해 최적화된 경로와 낮은 지연 시간 제공 ✅
  → Auto Scaling 그룹 뒤에 NLB 연결 가능 ✅

✅ 정답: D

---

📝 쉬운 해설

• ALB (Application Load Balancer) = HTTP/HTTPS (L7) 전용
• NLB (Network Load Balancer) = TCP/UDP (L4) 지원 → 문제 조건 충족
• CloudFront = 콘텐츠 캐싱/CDN, TCP 가속 목적과는 맞지 않음
• Global Accelerator = 전 세계 엣지 로케이션을 활용한 네트워크 최적화 → 짧은 지연 시간 보장

즉, TCP 기반 애플리케이션 + 글로벌 저지연 = NLB + Global Accelerator 조합이 정답입니다.

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “TCP/UDP 필요 = NLB, 글로벌 저지연 = Global Accelerator”

• HTTP/HTTPS = ALB + CloudFront
• TCP/UDP = NLB + Global Accelerator

---

📘 Q114 문제 정리

🔹 문제 요약

• SysOps 관리자에게는 암호화된 AMI를 배포하는 CloudFormation 템플릿이 있음
• 이 템플릿은 두 번째 계정에서도 사용됨
• 그러나 두 번째 계정에서 스택을 실행하면 실패 발생

👉 문제 해결을 위해 SysOps 관리자가 해야 할 조치는?

---

🔹 선택지 분석

• A. AMI 권한을 공개로 변경
  → AMI 자체는 공유 가능하지만, 암호화된 경우 KMS 키 권한도 공유해야 함. 단순 AMI 공개만으로는 실패 해결 불가 ❌
• B. 원본 계정에서 AMI 등록 취소
  → 오히려 더 문제를 악화시키는 잘못된 선택 ❌
• C. 대상 계정의 AWS KMS 키를 사용해 AMI를 다시 암호화
  → ✅ 정답
  → 암호화된 AMI를 다른 계정에서 사용하려면 해당 계정에서 사용할 수 있는 KMS 키로 다시 암호화해야 함
• D. 대상 계정에서 AMI ID를 CloudFormation 템플릿에 업데이트
  → 단순 AMI ID만 업데이트해도, KMS 키 권한이 없으면 여전히 실패 ❌

✅ 정답: C

---

📝 쉬운 해설

• 암호화된 AMI는 단순히 공유만으로는 다른 계정에서 사용할 수 없음
• 해결 방법: 대상 계정의 KMS 키로 재암호화해야 정상적으로 CloudFormation에서 사용 가능

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “암호화된 AMI 공유 문제 = KMS 키 재암호화 필요”

• 단순 AMI 공유 ❌
• 단순 AMI ID 업데이트 ❌
• KMS 키 재암호화 ✅

---

📘 Q117 문제 정리

🔹 문제 요약

• AWS 계정에서 IAM CreateUser API 호출이 발생할 때
• SysOps 관리자가 이메일 알림을 받고 싶음
• 어떤 작업 조합을 해야 할까? (2개 선택)

---

🔹 선택지 분석

• A. CloudTrail을 이벤트 소스로 사용 + EventBridge 규칙 생성
  → CloudTrail은 API 호출 기록을 이벤트로 전달
  → EventBridge 규칙으로 CreateUser API 패턴 필터링 가능 ✅
• B. Amazon CloudSearch 사용
  → CloudSearch는 검색 서비스, 이벤트 소스로 적합하지 않음 ❌
• C. IAM Access Analyzer 사용
  → 정책 분석 서비스, 이벤트 소스로 적합하지 않음 ❌
• D. Amazon SNS 사용
  → EventBridge 규칙의 대상(Target)으로 SNS 연결 → 이메일 구독 가능 ✅
• E. Amazon SES 사용
  → SES는 메일 전송 서비스이지만, EventBridge와 직접 연결하는 기본적인 패턴 아님 ❌

✅ 정답: A, D

---

📝 쉬운 해설

1. CloudTrail + EventBridge
   • CloudTrail: IAM API 호출 이벤트 기록
   • EventBridge: CreateUser API 패턴 감지 시 이벤트 발생
2. SNS + 이메일 구독
   • EventBridge 이벤트 → SNS Topic
   • SNS Topic 구독 → 이메일 알림 수신

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “API 이벤트 알림 = CloudTrail + EventBridge + SNS”

• CloudTrail = API 이벤트 감지
• EventBridge = 이벤트 필터링
• SNS = 이메일/SMS 알림

---

📘 Q118 문제 정리

🔹 문제 요약

• 현재 Amazon RDS 다중 AZ DB 인스턴스가 실행 중
• 최근 보안 감사에서 DB 인스턴스가 암호화되지 않음 → 규정 위반
• 이제 DB를 암호화해야 함

👉 어떤 접근 방식이 필요할까?

---

🔹 선택지 분석

• A. RDS 콘솔에서 암호화 옵션 선택
  → RDS는 생성 시 암호화 여부를 지정해야 하며, 실행 중인 인스턴스에 암호화를 직접 적용할 수 없음 ❌
• B. 새 EBS 볼륨을 생성 후 인스턴스에 연결
  → EBS 암호화는 RDS 인스턴스 DB 암호화와 직접적 연관 없음 ❌
• C. 보조 가용 영역 복제본 암호화 후 승격
  → 암호화되지 않은 기본 인스턴스로부터 생성된 복제본도 암호화되지 않음 ❌
• D. RDS 스냅샷을 생성 → 스냅샷 복사 시 암호화 적용 → 암호화된 스냅샷으로 새 인스턴스 생성
  → ✅ 정답
  → 유일하게 암호화되지 않은 DB를 암호화된 상태로 변환할 수 있는 절차

✅ 정답: D

---

📝 쉬운 해설

• RDS 암호화는 인스턴스 생성 시에만 가능
• 이미 실행 중인 비암호화 DB 인스턴스 → 암호화 불가
• 해결책:
  1. 기존 RDS 스냅샷 생성
  2. 스냅샷 복사 시 "암호화" 옵션 활성화
  3. 암호화된 스냅샷으로 새 RDS 인스턴스 생성

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “RDS 실행 중 암호화 불가 → 스냅샷 복사 후 암호화”

• 실행 중 직접 암호화 ❌
• 새 스냅샷 암호화 ✅

---

📘 Q120 문제 정리

🔹 문제 요약

• 회사는 VPC 내 EC2 인스턴스에서 애플리케이션 실행 중
• 이 애플리케이션은 인터넷에서 소프트웨어 업데이트를 다운로드해야 함
• 보안 정책상 모든 EC2 인스턴스는 프라이빗 서브넷에만 배포해야 함
• VPC에는 퍼블릭 서브넷과 프라이빗 서브넷이 존재

👉 이 상황에서 인터넷 접근을 가능하게 하려면?

---

🔹 선택지 분석

• A. VPC에 인터넷 게이트웨이 추가 후, 프라이빗 서브넷 라우팅에 경로 추가
  → 인터넷 게이트웨이는 퍼블릭 서브넷 전용. 프라이빗 서브넷에서는 직접 사용 불가 ❌
• B. 프라이빗 서브넷에 NAT 게이트웨이 추가
  → NAT 게이트웨이는 반드시 퍼블릭 서브넷에 위치해야 하므로 잘못됨 ❌
• C. 퍼블릭 서브넷에 NAT 게이트웨이 추가 후, 프라이빗 서브넷 라우팅에서 NAT 게이트웨이로 경로 지정
  → ✅ 정답
  → 프라이빗 서브넷 인스턴스들이 NAT 게이트웨이를 통해 인터넷에 아웃바운드 트래픽 전송 가능
• D. VPC에 인터넷 게이트웨이 2개 추가
  → 인터넷 게이트웨이는 하나만 가능. 그리고 프라이빗 서브넷에는 직접 적용 불가 ❌

✅ 정답: C

---

📝 쉬운 해설

• 프라이빗 서브넷 인스턴스는 보안상 직접 인터넷 게이트웨이 사용 불가
• 대신, 퍼블릭 서브넷에 NAT 게이트웨이 생성 → 라우팅을 NAT GW로 설정
• 이렇게 하면 인스턴스는 아웃바운드 인터넷 접근 가능, 외부에서 직접 접근 불가

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “프라이빗 서브넷 → 인터넷 = NAT 게이트웨이 필요”

• 퍼블릭 서브넷: IGW 직접 연결
• 프라이빗 서브넷: NAT GW 통해 간접 연결

---

📘 Q122 문제 정리

🔹 문제 요약

• SysOps 관리자가 고성능 컴퓨팅(HPC) 애플리케이션 실행을 위해 EC2 인스턴스 클러스터를 구성해야 함
• HPC 특성상 노드 간 최소 대기 시간(Low Latency) 필요

👉 어떤 조치를 취해야 할까? (2개 선택)

---

🔹 선택지 분석

• A. Amazon EFS 파일 시스템 생성
  → 파일 공유는 가능하지만, HPC의 핵심 요건인 노드 간 저지연 통신과 무관 ❌
• B. 다중 AZ 로드 밸런서 사용
  → HPC는 단일 AZ 내 저지연 클러스터가 핵심. 다중 AZ 사용 시 지연 시간 증가 ❌
• C. 단일 서브넷 내 Auto Scaling 그룹에서 EC2 시작
  → 같은 서브넷/같은 AZ에 인스턴스를 모아 저지연 네트워킹 가능 ✅
• D. EC2 인스턴스를 클러스터 배치 그룹(Cluster Placement Group)에서 시작
  → HPC 워크로드를 위해 인스턴스를 물리적으로 근접 배치해 네트워크 지연 최소화 ✅
• E. EC2 인스턴스를 파티션 배치 그룹에서 시작
  → 파티션은 대규모 분산 워크로드에 적합 (예: Hadoop), 저지연 HPC 목적과는 맞지 않음 ❌

✅ 정답: C, D

---

📝 쉬운 해설

• HPC 애플리케이션 → 인스턴스 간 저지연 네트워크 필수
• 이를 위해:
  1. 단일 서브넷/단일 AZ에 배치 (네트워크 경로 짧게)
  2. Cluster Placement Group 사용 (인스턴스를 물리적으로 가까운 하드웨어에 배치)

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “HPC = 단일 AZ + Cluster Placement Group”

• EFS ❌
• Multi-AZ ❌
• Partition ❌

---

📘 Q123 문제 정리

🔹 문제 요약

• 고객이 Amazon S3 정적 웹 콘텐츠에 액세스하는 동안 지연 시간 증가 발생
• SysOps 관리자는 특정 S3 버킷에서 매우 높은 읽기 트래픽을 관찰
• 목표: S3 버킷 로드 줄이고 지연 시간 최소화

👉 어떤 접근 방식이 가장 적절할까?

---

🔹 선택지 분석

• A. S3 버킷을 더 가까운 리전으로 마이그레이션
  → 리전 변경만으로는 전 세계 사용자 지연 시간 해결 불가 ❌
• B. 교차 리전 복제를 사용해 다른 리전으로 복제
  → 데이터 복제는 가능하지만, 전 세계 캐싱/지연 시간 최소화에는 적절치 않음 ❌
• C. CloudFront 배포 생성, S3를 오리진으로 사용
  → ✅ 정답
  → CloudFront는 전 세계 엣지 로케이션에서 콘텐츠 캐싱 → S3 부하 감소 + 지연 시간 단축
• D. Amazon ElastiCache로 캐싱
  → ElastiCache는 데이터베이스 캐싱 용도로 주로 사용, S3 정적 웹 콘텐츠 캐싱에는 부적합 ❌

✅ 정답: C

---

📝 쉬운 해설

• 문제 핵심: S3에 직접 트래픽 집중 → 지연 시간 증가
• CloudFront 사용:
  1. 전 세계 엣지 로케이션에서 캐시 제공
  2. 사용자는 가까운 엣지 서버에서 콘텐츠 제공받아 지연 시간 단축
  3. 원본 S3에 도달하는 요청 횟수도 줄어듦 → 부하 분산 효과

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “S3 읽기 트래픽 + 지연 시간 문제 = CloudFront 캐싱”

• 데이터베이스 캐싱 = ElastiCache
• 웹 콘텐츠 캐싱 = CloudFront

---

📘 Q127 문제 정리

🔹 문제 요약

• 상황: VPC에서 사용할 프라이빗 IPv4 주소가 고갈되어 EC2 인스턴스를 시작할 수 없음.
• 질문: SysOps 관리자가 취할 수 있는 올바른 조치는? (2개 선택)

---

🔹 선택지 분석

• A. 보조 IPv4 CIDR 블록을 VPC에 연결한다.
  → ✅ 정답
  → 기존 VPC에 Secondary IPv4 CIDR을 추가해서 IP 풀을 확장할 수 있음.
• B. 기본 IPv6 CIDR 블록을 VPC에 연결한다.
  → ❌ IPv6은 IPv4 고갈 문제를 직접 해결하지 못함. (IPv6 전환과는 별개 문제)
• C. VPC에 대한 새 서브넷을 생성한다.
  → ✅ 정답
  → 새로 추가한 CIDR 블록을 기반으로 새 서브넷을 만들어야 인스턴스 배포 가능.
• D. VPC의 CIDR 블록을 수정한다.
  → ❌ 기존 CIDR은 수정 불가. 오직 추가만 가능.
• E. 인스턴스와 연결된 서브넷의 CIDR 블록을 수정한다.
  → ❌ 서브넷 CIDR도 생성 후 변경 불가. 새로운 서브넷을 생성해야 함.

---

✅ 정답: A, C

---

📝 쉬운 해설

1. VPC CIDR 수정 불가 → Secondary IPv4 CIDR 추가
2. 서브넷 CIDR 수정 불가 → 새 서브넷 생성 필요

즉, IPv4 부족 = VPC에 보조 CIDR 추가 + 새 서브넷 생성

---

📊 흐름도 (Mermaid)

---

🎯 암기 팁

👉 “CIDR 고갈 = VPC에 CIDR 추가 + 새 서브넷 생성”

• CIDR 수정 불가 ❌
• 서브넷 CIDR 수정 불가 ❌

---

📘 Q128 문제 정리

🔹 문제 요약

• SysOps 관리자가 새 AWS 계정에서 EC2 Auto Scaling 그룹 생성
• 일부 인스턴스 추가 후, 최소 인스턴스 수에 도달하지 못함 → 오류 발생
• 오류 메시지:
•  
  새 EC2 인스턴스를 시작하지 못했습니다. 상태 이유: 귀하의 할당량은 0개의 추가 인스턴스 실행만 허용합니다. 최소 1개가 필요합니다.
• 즉, 계정의 EC2 인스턴스 서비스 할당량 부족(=Limit) 문제

👉 어떻게 해결할까?

---

🔹 선택지 분석

• A. Billing & Cost Management 콘솔에서 EC2 지출 한도 조정
  → ❌ 지출 한도는 관련 없음. 문제는 서비스 할당량
• B. EC2 콘솔의 설정 섹션에서 특정 리전의 EC2 할당량 수정
  → ❌ 콘솔에서 직접 수정 불가. AWS Support를 통한 요청 필요
• C. AWS Management Console → 서비스 할당량 (Service Quotas)에서 인스턴스 유형 패밀리별 할당량 증가 요청
  → ✅ 정답
  → EC2는 인스턴스 패밀리별(vCPU 기반) 할당량 제한이 있으며, Service Quotas에서 증가 요청 가능
• D. Auto Scaling 그룹 재조정 작업
  → ❌ 근본적 해결 불가 (여전히 할당량 제한 때문에 실패)

✅ 정답: C

---

📝 쉬운 해설

• AWS 새 계정은 기본적으로 리소스 할당량이 낮음 (예: t2.micro 몇 개만 가능)
• Auto Scaling에서 인스턴스 추가 시 한도 초과 → 인스턴스 시작 불가
• 해결책: Service Quotas(AWS 콘솔)에서 할당량 증가 요청

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “EC2 인스턴스 시작 불가 + ‘할당량 부족’ 오류 = Service Quotas 증가 요청”

---

📘 Q130 문제 정리

🔹 문제 요약

• 회사는 ALB (Application Load Balancer) 뒤에 3개의 EC2 인스턴스로 웹 애플리케이션 운영 중
• 특정 기간 동안 트래픽이 증가하면 성능 저하 발생
• SysOps 관리자는 애플리케이션이 증가된 트래픽을 감당할 수 있도록 확장해야 함

👉 어떤 솔루션이 가장 적절할까?

---

🔹 선택지 분석

• A. CloudWatch 경보로 인스턴스 크기를 늘린다.
  → ❌ Auto Scaling 없이 단일 인스턴스 크기를 키우는 방식 → 수평 확장이 아님
• B. EventBridge 규칙으로 ALB에 EC2 인스턴스 추가
  → ❌ ALB는 직접 EC2 인스턴스를 추가/제거하지 않음 → Auto Scaling 그룹이 필요
• C. 대상 추적 조정(Target Tracking Scaling Policy)을 사용, Auto Scaling 그룹에 EC2 인스턴스 포함 후 ALB에 연결
  → ✅ 정답
  → 트래픽 증가 시 Auto Scaling이 자동으로 인스턴스를 늘리고, ALB가 로드 분산 처리
• D. 예약된 조정 정책(Scheduled Scaling)을 사용해 EC2 인스턴스를 Auto Scaling 그룹에 추가
  → ❌ 예약된 스케일링은 특정 시간대 트래픽 증가 시 적합, 본 시나리오(임의의 트래픽 증가)에는 부적절

✅ 정답: C

---

📝 쉬운 해설

• 문제 핵심: 트래픽 증가 → 성능 저하 → 자동 확장 필요
• 가장 적절한 방법은:
  1. Auto Scaling 그룹에 EC2 인스턴스를 포함
  2. Target Tracking Policy (예: CPU 사용률 70% 유지)로 자동 스케일링
  3. ALB와 Auto Scaling 그룹을 연결 → 새 인스턴스도 자동으로 트래픽 분산

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “트래픽 증가 → ALB + Auto Scaling + Target Tracking”

• 일정 시간대 예측 가능 = Scheduled Scaling
• 예측 불가/실시간 대응 = Target Tracking Scaling Policy

---

📘 Q132 문제 정리

문제 요약

• 조건: 60분 이상 평균 CPU 사용률이 10% 미만이면 EC2 인스턴스를 자동 종료해야 함.
• 목표: 운영상 가장 효율적인 방법 선택.

---

선택지 분석

• A. cron으로 60분마다 스크립트 실행
  → 에이전트/스크립트 관리 필요, 신뢰성·확장성 떨어짐. ❌
• B. CloudWatch 경보로 평균 CPU 모니터링(평균 기간 1시간, 임계치 10%) + 경보 연계 EC2 작업(Stop/Terminate)
  → AWS 네이티브, 관리형, 신뢰성 높음. ✅
• C. CloudWatch 에이전트 + 커스텀 지표 세트
  → 기본 지표(CPUUtilization)로 충분, 에이전트 불필요. 과도한 구성. ❌
• D. Systems Manager Run Command로 60분마다 CPU 확인
  → 주기 호출·권한·오케스트레이션 관리 부담 큼. 이벤트 기반이 아님. ❌

정답: B

---

구현 핵심(짧게)

1. CloudWatch Alarm 생성
   • Metric: CPUUtilization (Average)
   • Period: 60 minutes
   • Threshold: < 10
   • Evaluation: 1 (또는 운영 기준에 맞게 2~3)
2. Alarm 상태(Alarm) 시 EC2 인스턴스 작업 연결
   • 작업 유형: Stop this instance(중지) 또는 Terminate this instance(종료)
   • 필요 권한: EC2ActionsAccess가 포함된 CloudWatch 알람 서비스 연결 역할(콘솔이 자동 생성/선택 가능)

---

흐름도

---

한줄 암기

👉 “지표 기반 자동조치 = CloudWatch Alarm + EC2 Action”
스크립트/Run Command ❌, 에이전트 ❌. 기본 CPU 지표로 충분 ✅

“지표 기반 자동 조치 = CloudWatch Alarm + EC2 Action(Stop/Terminate)”

운영 시 주의사항

• Auto Scaling 그룹인지 여부 확인
  • 개별 인스턴스에 “Terminate”를 걸면 ASG가 다시 인스턴스를 띄울 수 있음.
  • ASG 환경이라면: Target Tracking/Step Scaling(예: 평균 CPU 10% 유지)으로 스케일-인이 더 자연스러움.
• Stop vs Terminate
  • Stop: 재시작 가능(요금: EBS 스토리지만).
  • Terminate: 완전 삭제(스냅샷/백업 전략 사전 점검 필수).
• 지표 지연: CloudWatch 표준 지표는 수 분 지연될 수 있음 → 서비스 특성에 맞게 Period/Evaluation 조정.

한 줄 정리

“지표 기반 자동종료 = CloudWatch Alarm(평균 CPU 60분 <10%) + EC2 Action(Stop/Terminate)”

 

---

 

📘 Q138 문제 정리

📝 문제

• 회사는 ALB(Elastic Load Balancer) 뒤의 EC2 웹 애플리케이션을 운영 중
• 보안팀은 AWS Certificate Manager(ACM) SSL 인증서를 사용하여 웹 사이트를 보호하려고 함
• 요구사항: 모든 HTTP 요청을 HTTPS로 자동 리디렉션해야 한다

---

✅ 보기

A. ALB에 HTTPS 리스너(포트 80)만 두고 SSL 인증서를 연결 → ❌ (포트 80은 HTTP 전용, HTTPS 리스너는 443 필요)
B. ALB에 포트 80 HTTP 리스너와 포트 443 HTTPS 리스너를 두고, SSL 인증서를 포트 443에 연결 + 포트 80 요청은 443으로 리디렉션 규칙 설정 → ✅
C. ALB에 두 개의 **TCP 리스너(80, 443)**를 두고 SSL 인증서를 443에 연결 → ❌ (TCP는 SSL/TLS 오프로딩 지원 불가)
D. NLB에 두 개의 TCP 리스너를 두고 SSL 인증서를 443에 연결 → ❌ (NLB는 HTTP → HTTPS 리디렉션 기능 없음)

---

🎯 정답

B. 포트 80 HTTP 리스너 + 포트 443 HTTPS 리스너 구성, 80 → 443 리디렉션 규칙 적용

---

💡 해설

• HTTP → HTTPS 강제 리디렉션은 Application Load Balancer에서 가능
• ALB 리스너 규칙에서 리디렉션(redirect action) 기능 제공
• **NLB(Network Load Balancer)**는 단순 TCP 수준 로드밸런싱이라 이런 기능 없음

---

📊 시각화 (Mermaid)

---

📌 핵심 포인트

• SSL 인증서는 반드시 443 포트 리스너에 연결해야 함
• 리디렉션 규칙은 ALB HTTP 리스너에서 설정
• NLB는 Layer 4, ALB는 Layer 7 → 리디렉션 같은 고급 기능은 ALB에서만 가능

---

📘 Q140 문제 정리 (Amazon ECS 네트워크 트래픽 모니터링)

❓ 문제

회사는 Amazon ECS (Elastic Container Service) 를 사용해 Amazon EC2 인스턴스에서 컨테이너화된 애플리케이션을 실행 중입니다.
SysOps 관리자는 ECS 작업 간 트래픽 흐름만 모니터링해야 합니다.

👉 어떤 단계 조합을 수행해야 할까요? (2개 선택)

---

✅ 정답: B, C

• B. 각 작업의 탄력적 네트워크 인터페이스에서 VPC 흐름 로그를 구성한다.
  → VPC Flow Logs는 네트워크 트래픽을 캡처해 CloudWatch Logs나 S3에 저장할 수 있음.
  → ECS 작업 간의 트래픽을 확인하려면 ENI(Elastic Network Interface) 레벨에서 Flow Logs를 활성화해야 함.
• C. 작업 정의에서 awsvpc 네트워크 모드를 지정한다.
  → awsvpc 모드는 각 ECS Task에 자체 ENI를 부여하여 VPC 네트워크와 직접 통신할 수 있게 함.
  → 따라서 작업(Task) 단위로 네트워크 트래픽 모니터링이 가능해짐.

---

❌ 오답 해설

• A. CloudWatch Logs 구성
  → 애플리케이션 로그 수집 용도이지, 네트워크 트래픽 흐름 모니터링은 불가능.
• D. 브리지(bridge) 네트워크 모드
  → 컨테이너 인스턴스 내에서 Docker 가상 네트워크를 사용, ENI 단위 추적 불가.
• E. 호스트(host) 네트워크 모드
  → 컨테이너가 EC2 인스턴스의 네트워크 스택을 공유, 개별 Task 네트워크 추적 불가.

---

📊 시각화 (Mermaid)

---

📌 핵심 요약

• 네트워크 모니터링 → VPC Flow Logs
• Task 단위 네트워크 추적 → awsvpc 모드
• ECS에서 Task 간 트래픽 흐름 모니터링은 B + C 조합으로만 가능

---

📘 Q143 문제 정리 (Amazon EBS 스냅샷 복구)

❓ 문제

SysOps 관리자가 Amazon EBS 스냅샷을 복원하려고 하는데, 다른 관리자가 실수로 스냅샷을 삭제했습니다.
→ 회사는 스냅샷이 삭제되더라도 일정 기간 동안 복구할 수 있는 기능을 원합니다.

👉 어떤 솔루션이 이 기능을 제공할까요?

---

✅ 정답: C. 원하는 보관 기간 동안 EBS 스냅샷에 대한 휴지통 보관 규칙 생성

---

💡 해설

• AWS에서는 Amazon Data Lifecycle Manager(DLM) + EBS Snapshots Archive/Recycle Bin 기능을 통해 삭제된 스냅샷을 일정 기간 동안 복구 가능하도록 설정할 수 있습니다.
• 이 기능은 Recycle Bin for EBS Snapshots이라고 하며, 보존 규칙(retention rules)을 만들면, 삭제된 스냅샷이 즉시 완전히 사라지지 않고 지정된 기간 동안 복구 가능합니다.

---

❌ 오답 해설

• A. 개별 스냅샷에 삭제 방지 기능: 스냅샷에는 S3처럼 버전 관리/삭제 방지 기능 없음.
• B. IAM 정책으로 삭제 거부: 삭제를 막을 순 있지만, 실수로 삭제된 경우 복구 불가능.
• D. EventBridge + Lambda → Glacier 백업: 가능은 하지만 스냅샷 복구 기능과는 무관, 아카이빙일 뿐.

---

📊 시각화 (Mermaid)

---

📌 핵심 포인트

• EBS 스냅샷 Recycle Bin → 삭제 후에도 지정된 보존 기간 동안 복구 가능
• DR(재해 복구) 및 실수 방지 목적에 유용
• IAM 정책은 예방책, Recycle Bin은 복구책

---

👉 이 문제는 시험에서 자주 나오는 EBS Snapshot Recycle Bin 관련 문제입니다.

---

📘 Q146 문제 정리 (Amazon S3 Glacier – Vault Lock)

❓ 문제

회사는 Amazon S3 Glacier에 민감한 데이터를 보관하려 합니다.
규제 및 규정 준수 요구 때문에, **모든 계정의 데이터 수정 금지(불변성 보장)**가 필요합니다.

👉 어떤 솔루션이 이 요구사항을 충족할까요?

---

✅ 정답: B. S3 Glacier 볼트(Vault)에 볼트 잠금 정책(Vault Lock Policy)을 연결하고, 잠금 ID를 사용하여 24시간 이내에 정책을 검증

---

💡 해설

• S3 Glacier Vault Lock
  • 규정 준수 및 보안 요건을 충족하기 위해 제공되는 기능
  • Vault에 **잠금 정책(Lock Policy)**를 설정하면, 일단 잠금이 커밋(commit)되면 변경 불가
  • WORM (Write Once, Read Many) 스토리지를 구현 → 데이터 삭제·수정 방지
  • 정책은 24시간 내 검증해야 하고, 그 이후에는 영구적으로 고정됨

---

❌ 오답 해설

• A. 24시간 후에 검증 → 잘못됨, 반드시 24시간 내 검증 필요
• C/D. 거버넌스 모드 S3 객체 잠금 → 이는 S3 Object Lock 기능, S3 Glacier Vault Lock과는 다른 서비스

---

📊 시각화 (Mermaid)

---

📌 핵심 포인트

• 규정 준수 & 불변성 보장 = S3 Glacier Vault Lock
• 정책 설정 후 24시간 내 검증 필수
• 커밋 이후 정책은 변경 불가
• Object Lock과 혼동 주의 (Object Lock = S3 버킷, Vault Lock = Glacier 볼트)

---

👉 이 문제는 시험에서 자주 묻는 Vault Lock vs S3 Object Lock 비교 문제입니다.

📊 Object Lock vs Vault Lock 비교

📌 한 줄 요약

• S3 Object Lock → 개별 객체 보호 (Governance/Compliance Mode 선택 가능)
• Glacier Vault Lock → Vault 단위 보호, 24시간 내 검증 후 영구 불변

---

👉 이렇게 보면 시험에서 "객체 단위 불변성" vs "아카이브 전체 불변성" 구분이 핵심 포인트입니다.

---

📘 Q149 문제 정리 (AWS Organizations + EC2 백업 전략)

❓ 문제

회사는 AWS Organizations를 사용해 여러 AWS 계정을 관리합니다.
SysOps 관리자는 회사의 모든 계정에 걸쳐 EC2 인스턴스 백업 전략을 수립해야 합니다.

👉 어떤 솔루션이 가장 효율적일까요?

---

✅ 정답: C. 마스터 계정에서 AWS Backup을 사용하여 모든 계정 및 리소스에 대한 정책을 배포한다.

---

💡 해설

• AWS Backup은 중앙에서 백업 정책을 정의하고,
  AWS Organizations를 통해 여러 계정과 리소스에 적용할 수 있습니다.
• Backup Policy를 생성 후 OU(조직 단위)에 연결하면 모든 계정에 일괄 적용됩니다.
• 따라서 운영 효율성 + 규정 준수 모두 만족.

---

❌ 오답 해설

• A. Lambda 배포 후 스냅샷 실행
  → 계정마다 함수 배포 필요, 관리 복잡성 ↑ → 비효율적.
• B. CloudFormation으로 태그 추가
  → 태그만으로 백업 자동화 불가, 실제 스냅샷 수행 X.
• D. SCP(Service Control Policy) 사용
  → SCP는 권한 제어 정책이지, 스냅샷 실행 기능이 아님.

---

📊 시각화 (Mermaid)

---

📌 핵심 포인트

• AWS Backup + AWS Organizations = 다계정 환경 백업 전략 표준
• 중앙 관리, 자동 정책 배포, 규정 준수 강화
• Lambda/CloudFormation/SCP는 보조적이지만 중앙 집중 백업 전략에 부적합

---

👉 이 문제는 시험에서 자주 나오는 AWS Backup과 Organizations 통합 관련 문제예요.

---

📘 Q150 문제 정리 (VPC Flow Logs – 모든 트래픽 기록)

❓ 문제

SysOps 관리자가 **VPC 흐름 로그(Flow Logs)**를 검토하여 연결 문제를 해결 중입니다.
로그를 확인하는 동안 거부된 트래픽이 기록되지 않음을 발견했습니다.

👉 모든 트래픽(허용 + 거부)이 기록되도록 하려면 무엇을 해야 할까요?

---

✅ 정답: A. 모든 트래픽을 캡처하는 필터 설정이 있는 새 흐름 로그를 생성한다.

---

💡 해설

• VPC Flow Logs는 3가지 필터 옵션이 있음:
  1. ACCEPT → 허용된 트래픽만 기록
  2. REJECT → 거부된 트래픽만 기록
  3. ALL → 허용 + 거부 모든 트래픽 기록
• 기존 Flow Logs는 필터를 수정할 수 없음 → 반드시 새로운 Flow Log를 생성해야 함.
• 따라서 "거부된 트래픽도 기록되게 하려면 → 필터를 ALL로 설정한 새 Flow Log 생성"이 정답.

---

❌ 오답 해설

• B/D. 로그 형식 편집
  → 로그 출력 포맷만 바뀌지, 허용/거부 캡처 범위는 변하지 않음.
• C. 기존 Flow Log 필터 수정
  → Flow Logs는 한 번 생성되면 편집 불가, 삭제 후 재생성이 필요.

---

📊 시각화 (Mermaid)

---

📌 핵심 포인트

• VPC Flow Logs → 필터: ACCEPT / REJECT / ALL
• 기존 로그는 편집 불가 → 새로 생성 필요
• 거부 트래픽까지 확인하려면 필터=ALL 설정

---

👉 이 문제는 시험에서 자주 나오는 VPC Flow Logs 필터와 편집 불가 특성 관련 포인트입니다.

📊 VPC Flow Logs – 필터 옵션 비교

---

📌 핵심 암기 문구

• ACCEPT = 정상 확인
• REJECT = 차단 확인
• ALL = 둘 다 확인 → 시험 정답

 

📊 VPC Flow Logs – 필터 옵션 시각화

📌 핵심 기억 포인트

• ACCEPT → 허용만
• REJECT → 거부만
• ALL → 둘 다 (시험 정답 포인트)

📘 Q4 문제 정리

🔹 문제 요약

SysOps 관리자가 AWS 계정에서 CloudTrail을 활성화했다.
만약 CloudTrail이 꺼지면 즉시 다시 켜져야 한다.
→ 코드를 따로 작성하지 않고 이 요구사항을 만족하려면?

---

🔹 선택지 분석

• A. AWS Organizations
  → 여러 계정 관리용 서비스. CloudTrail 자동 복구와는 관계 없음 ❌
• B. AWS Config 규칙 (CloudTrail 구성 변경 감지 + 자동 수정)
  → CloudTrail이 꺼지면 AWS Config가 감지 → 자동으로 다시 켜줌 ✅
• C. AWS Config + Lambda
  → 가능은 하지만 Lambda 코드를 직접 작성해야 함. 문제에서 "사용자 정의 코드 없이"라고 했으므로 ❌
• D. EventBridge 스케줄링
  → 단순히 주기적으로 실행할 뿐, 실시간 복구 보장은 안 됨 ❌

✅ 정답: B

---

📝 쉬운 해설

• CloudTrail = 누가, 언제, 어떤 API를 호출했는지 기록
• 문제 요구사항 = CloudTrail이 꺼져도 자동으로 다시 켜져야 함
• 해결 방법 = AWS Config 자동 수정(Auto Remediation)
  • "CloudTrailLoggingEnabled" 규칙 사용
  • **자동 수정(Auto remediation)**으로 AWS-ConfigureCloudTrailLogging 실행

즉, CloudTrail이 꺼지면 AWS Config가 바로 감지하고 자동으로 켜주는 역할을 합니다.

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 CloudTrail 유지 = AWS Config + Auto Remediation

• "Config가 감시하고, 자동으로 켜준다" 라고만 기억하면 OK!

---

Q4.
A SysOps administrator has enabled AWS CloudTrail in an AWS account.
If CloudTrail is disabled, it must be re-enabled immediately.
What should the SysOps administrator do to meet these requirements WITHOUT writing custom code?

A. Add the AWS account to AWS Organizations.
Enable CloudTrail in the management account.

B. Create an AWS Config rule that is invoked when CloudTrail configuration changes.
Apply the AWS-ConfigureCloudTrailLogging automatic remediation action.

C. Create an AWS Config rule that is invoked when CloudTrail configuration changes.
Configure the rule to invoke an AWS Lambda function to enable CloudTrail.

D. Create an Amazon EventBridge (Amazon CloudWatch Event) hourly rule with a schedule pattern to run an AWS Systems Manager Automation document to enable CloudTrail.

Answer: B

---

📘 Q5 문제 정리

🔹 문제 요약

• 회사는 ALB(Application Load Balancer) 뒤의 EC2 인스턴스에서 웹사이트를 운영 중
• DNS 관리는 Amazon Route 53에서 함
• 도메인의 zone apex (example.com)를 웹사이트와 연결하려고 함

👉 이때 어떤 DNS 레코드 타입을 사용해야 할까?

---

🔹 선택지 분석

• A. AAAA 레코드 (IPv6 주소 매핑)
  → zone apex 자체를 ALB에 바로 연결 불가 ❌
• B. A 레코드 (IPv4 주소 매핑)
  → ALB는 고정 IP가 없음. 따라서 직접 매핑 불가 ❌
• C. CNAME 레코드
  → zone apex에서는 CNAME 사용이 불가능 ❌ (RFC 표준 제약)
• D. Alias 레코드
  → Route 53이 제공하는 특수 레코드
  → ALB, CloudFront, S3 등 AWS 리소스와 직접 연결 가능 ✅

✅ 정답: D

---

📝 쉬운 해설

• ALB는 IP 주소가 변할 수 있어서 A/AAAA 레코드에 직접 연결할 수 없음.
• CNAME은 www.example.com 같은 서브도메인에서는 가능하지만, zone apex(example.com)에는 불가.
• AWS Route 53의 Alias 레코드는 이런 문제를 해결하기 위해 제공됨.
  • 마치 CNAME처럼 동작하지만 zone apex에서도 사용 가능
  • 추가 비용 없음

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “zone apex = Alias 레코드”

• ALB, CloudFront, S3 정적 웹사이트를 example.com에 연결할 땐 항상 Alias!

Q5.
A company hosts its website on Amazon EC2 instances behind an Application Load Balancer.
The company manages its DNS with Amazon Route 53, and wants to point its domain's zone apex to the website. Which type of record should be used to meet these requirements?

A. An AAAA record for the domain's zone apex
B. An A record for the domain's zone apex
C. A CNAME record for the domain's zone apex
D. An alias record for the domain's zone apex

Answer: D

 

---

📘 Q6 문제 정리

🔹 문제 요약

• 회사는 S3 버킷에 업로드되는 모든 객체가 반드시 암호화되었는지 확인해야 함
• 이 요구사항을 만족하는 방법 2가지 선택

---

🔹 선택지 분석

• A. AWS Shield 적용
  → DDoS 방어 서비스. 객체 암호화와는 관계 없음 ❌
• B. 객체 ACL로 제어
  → ACL은 접근 권한만 제어. 암호화 강제 불가 ❌
• C. S3 기본 암호화(Default Encryption)
  → 업로드 시 자동으로 암호화 처리 ✅
• D. Amazon Inspector 적용
  → 취약점 분석 툴. S3 암호화 확인 불가 ❌
• E. S3 버킷 정책으로 비암호화 객체 거부
  → "암호화 헤더 없는 업로드는 Deny" 정책 가능 ✅

✅ 정답: C, E

---

📝 쉬운 해설

1. S3 기본 암호화(Default Encryption)
   • 모든 업로드 객체를 자동으로 암호화
   • 사용자가 별도 지정하지 않아도 안전하게 저장됨
2. S3 버킷 정책(Bucket Policy)
   • 업로드 요청에 x-amz-server-side-encryption 헤더가 없으면 거부(Deny)
   • 암호화 강제 적용 가능

💡 두 방법을 함께 쓰면 자동 암호화 + 정책적 강제성으로 이중 보호!

---

📊 Mermaid 시각화

 

---

🎯 암기 팁

👉 "S3 암호화 = Default Encryption + Bucket Policy"

• Default Encryption = 자동 암호화
• Bucket Policy = 암호화 안 된 업로드 차단

 

Q6.
A company must ensure that any objects uploaded to an S3 bucket are encrypted.
Which of the following actions will meet this requirement? (Choose two)

A. Implement AWS Shield to protect against unencrypted objects stored in S3 buckets.
B. Implement Object access control list (ACL) to deny unencrypted objects from being uploaded to the S3 bucket.
C. Implement Amazon S3 default encryption to make sure that any object being uploaded is encrypted before it is stored.
D. Implement Amazon Inspector to inspect objects uploaded to the S3 bucket to make sure that they are encrypted.
E. Implement S3 bucket policies to deny unencrypted objects from being uploaded to the buckets.

Answer: C, E

---

📘 Q7 문제 정리

🔹 문제 요약

• 회사는 Auto Scaling 그룹의 EC2 인스턴스에서 웹 애플리케이션을 호스팅 중
• ALB(Application Load Balancer) → CloudFront 오리진으로 구성됨
• 사용자가 웹 애플리케이션에서 무작위 로그아웃되는 문제가 발생

👉 SysOps 관리자가 해야 할 조치는 무엇일까? (2개 선택)

---

🔹 선택지 분석

• A. ALB 최소 미해결 요청 알골리즘으로 변경
  → 로드밸런싱 알고리즘 문제 아님 ❌
• B. CloudFront 캐시 정책에서 쿠키 전달 구성
  → 세션 정보는 보통 쿠키에 저장. CloudFront가 쿠키를 전달하지 않으면 세션 불일치 발생 ✅
• C. CloudFront에서 헤더 전달 구성
  → 일부 상황에서는 필요하지만, 여기서는 세션 쿠키 문제이므로 정답 아님 ❌
• D. ALB 리스너 규칙에서 그룹 수준 고정성(stickiness) 활성화
  → 리스너 단위 stickiness는 세밀하지 않음 ❌
• E. ALB 대상 그룹(Target Group)에서 고정 세션(sticky session) 활성화
  → 세션을 항상 같은 인스턴스로 라우팅해 로그아웃 문제 방지 ✅

✅ 정답: B, E

---

📝 쉬운 해설

• 웹 애플리케이션 로그인 세션은 쿠키 기반
• CloudFront가 쿠키를 오리진(ALB)으로 전달하지 않으면, ALB는 새 사용자처럼 취급 → 로그아웃 문제 발생
• ALB Target Group에서 Sticky Session을 켜면, 같은 사용자는 항상 동일 인스턴스로 연결됨 → 세션 유지

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 세션 문제 = “쿠키 전달 + Sticky Session”

• CloudFront: 쿠키 전달 설정
• ALB Target Group: Sticky Session 활성화

 

Q7.
A company has a stateful web application that is hosted on Amazon EC2 instances in an Auto Scaling group.
The instances run behind an Application Load Balancer (ALB) that has a single target group.

The ALB is configured as the origin in an Amazon CloudFront distribution.
Users are reporting random logouts from the web application.
Which combination of actions should a SysOps administrator take to resolve this problem? (Choose two)

A. Change to the least outstanding requests algorithm on the ALB target group.
B. Configure cookie forwarding in the CloudFront distribution cache behavior.
C. Configure header forwarding in the CloudFront distribution cache behavior.
D. Enable group-level stickiness on the ALB listener rule.
E. Enable sticky sessions on the ALB target group.

Answer: B, E

---

📘 Q12 문제 정리

🔹 문제 요약

• SysOps 관리자가 CloudFormation 템플릿으로 VPC를 배포 완료
• 이제 AWS Organizations 내 여러 계정에 동일한 템플릿을 배포해야 함
• 운영 오버헤드 최소화가 목표

👉 어떤 방법이 가장 적절한가?

---

🔹 선택지 분석

• A. 마스터 계정에서 OrganizationAccountAccessRole IAM 역할 사용
  → 단일 계정 단위 배포라서 자동화/대규모 배포 불가 ❌
• B. 각 계정에서 Lambda + CreateStack API 호출
  → 코드 작성 필요, 오버헤드 큼 ❌
• C. 계정 목록을 관리하는 Lambda로 CreateStack API 호출
  → 여전히 커스텀 코드 필요 ❌
• D. 마스터 계정에서 CloudFormation StackSets 사용
  → 여러 계정·리전에 동시에 배포 가능 ✅

✅ 정답: D

---

📝 쉬운 해설

• CloudFormation Stack = 단일 계정, 단일 리전에만 리소스 생성
• StackSets = 여러 계정과 리전에 한 번에 배포 가능
  • Organizations와 통합되어 있어 운영자가 코드 직접 작성할 필요 없음
  • 운영 오버헤드 최소화 조건 충족

즉, 여러 계정에 공통 리소스를 배포해야 할 때는 StackSets가 정답!

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “여러 계정 + 여러 리전 = StackSets”

• 단일 계정/리전 = Stack
• 멀티 계정/리전 = StackSets

 

Q12.
A SysOps administrator has successfully deployed a VPC with an AWS CloudFormation template.
The SysOps administrator wants to deploy the same template across multiple accounts that are managed through AWS Organizations. Which solution will meet this requirement with the LEAST operational overhead?

A. Assume the OrganizationAccountAccessRole IAM role from the management account.
Deploy the template in each of the accounts.
B. Create an AWS Lambda function to assume a role in each account.
Deploy the template by using the AWS CloudFormation CreateStack API call.
C. Create an AWS Lambda function to query for a list of accounts.
Deploy the template by using the AWS CloudFormation CreateStack API call.
D. Use AWS CloudFormation StackSets from the management account to deploy the template in each of the accounts.

Answer: D

 

---

📘 Q31 문제 정리

🔹 문제 요약

• SysOps 관리자가 EC2 인스턴스에서 애플리케이션을 운영 중
• 애플리케이션이 DynamoDB 테이블에 접근할 수 있는 권한을 줘야 함
• 가장 적절한 방법은?

---

🔹 선택지 분석

• A. 액세스 키 생성 → EC2에 키 직접 넣기
  → 보안에 매우 취약 (키 유출 위험) ❌
• B. EC2 키 페어 생성 후 애플리케이션에 사용
  → 키 페어는 SSH 로그인용, DynamoDB 접근 권한과 무관 ❌
• C. IAM 사용자 생성 후 액세스 키 발급 → EC2에 할당
  → 가능하긴 하지만, 키 관리 문제와 보안 리스크 존재 ❌
• D. DynamoDB 접근 권한이 있는 IAM 역할(Role) 생성 → EC2 인스턴스 프로파일에 부여
  → 가장 안전하고 권장되는 방법 ✅

✅ 정답: D

---

📝 쉬운 해설

• IAM Role = 임시 보안 자격 증명을 EC2에 자동으로 부여
• EC2 Instance Profile = 역할을 EC2에 붙이는 매개체
• 애플리케이션은 액세스 키를 직접 관리하지 않고, EC2 메타데이터 서비스(IMDS)로 권한을 얻음

💡 따라서 보안성이 가장 뛰어나고, AWS에서 공식적으로 권장하는 방식은 IAM Role 사용입니다.

---

📊 Mermaid 시각화

 

---

🎯 암기 팁

👉 "EC2 → DynamoDB = IAM Role + Instance Profile"

• 액세스 키 = ❌ 위험
• 키 페어 = ❌ SSH 전용
• IAM Role = ✅ 보안 + 자동 인증

 

Q31.
A SysOps administrator is using Amazon EC2 instances to host an application.
The SysOps administrator needs to grant permissions for the application to access an Amazon DynamoDB table. Which solution will meet this requirement?

A. Create access keys to access the DynamoDB table. Assign the access keys to the EC2 instance profile.
B. Create an EC2 key pair to access the DynamoDB table. Assign the key pair to the EC2 instance profile.
C. Create an IAM user to access the DynamoDB table. Assign the IAM user to the EC2 instance profile.
D. Create an IAM role to access the DynamoDB table. Assign the IAM role to the EC2 instance profile.

Answer: D

---

📘 Q34 문제 정리

🔹 문제 요약

• 회사는 AWS Organizations를 사용해 여러 AWS 계정을 관리 중
• 기업 정책상 특정 리전만 사용 가능, 다른 리전에서는 EC2 인스턴스를 생성하면 안 됨
• 승인되지 않은 리전에서 EC2가 생성되지 않도록 운영 오버헤드가 최소인 방법을 찾아야 함

---

🔹 선택지 분석

• A. CloudTrail + EventBridge + Lambda로 차단
  → 가능은 하지만, 실행 후 탐지/종료 방식이라 완벽 차단 불가 ❌
• B. 각 계정별 IAM 정책으로 ec2:RunInstances 제한
  → 모든 계정마다 정책을 일일이 붙여야 해서 운영 오버헤드 큼 ❌
• C. 각 계정별 IAM 사용자/그룹에 경계 정책 연결
  → 여전히 계정별 관리 필요. 효율적이지 않음 ❌
• D. AWS Organizations의 서비스 제어 정책(SCP) 사용
  → 조직 전체(OU/루트)에 정책을 한 번만 적용하면 됨
  → “승인되지 않은 리전에서 ec2:RunInstances 거부” 가능 ✅

✅ 정답: D

---

📝 쉬운 해설

• SCP(Service Control Policy) = AWS Organizations에서 제공하는 정책
• 모든 하위 계정에 공통 적용 가능
• 예: "Deny ec2:RunInstances if region != ap-northeast-2"
• 즉, 회사 정책을 중앙에서 통제하고, 계정별 세부 설정 불필요

---

📊 Mermaid 시각화

 

---

🎯 암기 팁

👉 “계정 여러 개 + 중앙 통제 = SCP”

• IAM 정책 = 계정 단위
• SCP = 조직 전체 단위 (운영 효율 최고)

---

Q34.
A company uses AWS Organizations to manage multiple AWS accounts.
Corporate policy mandates that only specific AWS Regions can be used to store and process customer data.
A SysOps administrator must prevent the provisioning of Amazon EC2 instances in unauthorized Regions by anyone in the company.

What is the MOST operationally efficient solution that meets these requirements?

A. Configure AWS CloudTrail in all Regions to record all API activity.
Create an Amazon EventBridge (Amazon CloudWatch Events) rule in all unauthorized Regions for ec2:RunInstances events.
Use AWS Lambda to terminate the launched EC2 instances.
B. In each AWS account, create a managed IAM policy that uses a Region condition to deny the ec2:RunInstances action in all unauthorized Regions. Attach this policy to all IAM groups in each AWS account. C. In each AWS account, create an IAM permissions boundary policy that uses a Region condition to deny the ec2:RunInstances action in all unauthorized Regions. Attach the permissions boundary policy to all IAM users in each AWS account.
D. Create a service control policy (SCP) in AWS Organizations to deny the ec2:RunInstances action in all unauthorized Regions. Attach this policy to the root level of the organization.

Answer: D

 

---

📘 Q35 문제 정리

🔹 문제 요약

• 회사 웹사이트 = CloudFront 배포 + us-east-1 S3 버킷에서 호스팅
• 요구사항 = DDoS 공격 방어 + 비율 제한(rate limiting) 기능 필요

👉 어떤 솔루션이 적합할까?

---

🔹 선택지 분석

• A. AWS WAF 웹 ACL을 CloudFront 배포에 연결 + 속도 기반(rate-based) 규칙 적용
  → CloudFront는 글로벌 서비스, DDoS 방어는 WAF + Shield Standard로 가능 ✅
• B. AWS WAF를 S3 버킷에 직접 연결
  → WAF는 S3에 직접 연결 불가, 오직 CloudFront, ALB, API Gateway 등에만 붙일 수 있음 ❌
• C. 차단 규칙만 사용해 WAF 적용
  → DDoS는 단순 차단 규칙보다 **비율 제한 규칙(rate limiting)**이 핵심. 요구사항 불충족 ❌
• D. S3 버킷에 연결된 WAF 적용
  → 다시 말하지만, S3에는 WAF 직접 연결 불가 ❌

✅ 정답: A

---

📝 쉬운 해설

• WAF(Web Application Firewall): CloudFront에 붙여서 특정 패턴/속도 기반 공격 차단 가능
• Shield Standard: CloudFront에 기본 포함되어 있어 DDoS 방어 지원
• 따라서 S3에 직접 보안 걸 수 없고, CloudFront + WAF 조합이 정답

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “S3 보안은 직접 불가 → CloudFront + WAF”

• DDoS 방어 = 기본 Shield + WAF
• Rate limiting = WAF 규칙

---

 

Q35.
A company's public website is hosted in an Amazon S3 bucket in the us-east-1 Region behind an Amazon CloudFront distribution. The company wants to ensure that the website is protected from DDoS attacks.
A SysOps administrator needs to deploy a solution that gives the company the ability to maintain control over the rate limit at which DDoS protections are applied. Which solution will meet these requirements?

A. Deploy a global-scoped AWS WAF web ACL with an allow default action.
Configure an AWS WAF rate-based rule to block matching traffic.
Associate the web ACL with the CloudFront distribution.
B. Deploy an AWS WAF web ACL with an allow default action in us-east-1.
Configure an AWS WAF rate-based rule to block matching traffic.
Associate the web ACL with the S3 bucket.
C. Deploy a global-scoped AWS WAF web ACL with a block default action.
Configure an AWS WAF rate-based rule to allow matching traffic.
Associate the web ACL with the CloudFront distribution.
D. Deploy an AWS WAF web ACL with a block default action in us-east-1.
Configure an AWS WAF rate-based rule to allow matching traffic.
Associate the web ACL with the S3 bucket.

Answer: A

---

📘 Q39 문제 정리

🔹 문제 요약

• SysOps 관리자가 NAT 인스턴스를 NAT 게이트웨이로 마이그레이션
• 이후, 프라이빗 서브넷 EC2 애플리케이션이 인터넷에 접근 불가

👉 가능한 원인 2가지 선택

---

🔹 선택지 분석

• A. 애플리케이션이 NAT 게이트웨이가 지원하지 않는 프로토콜을 사용
  → NAT 게이트웨이는 TCP/UDP만 지원, ICMP 같은 다른 프로토콜은 안 됨 ✅
• B. NAT 게이트웨이가 보안 그룹에 속하지 않음
  → NAT 게이트웨이는 ENI 기반이지만 보안 그룹을 사용하지 않음. 대신 NACL과 라우팅으로 제어됨 ❌
• C. NAT 게이트웨이가 지원되지 않는 가용 영역(AZ)에 존재
  → NAT 게이트웨이는 특정 AZ에서 생성해야 하고, 다른 AZ 리소스가 접근 가능함. 하지만 이 보기는 문제와 무관 ❌
• D. NAT 게이트웨이가 사용 불가능 상태
  → NAT 게이트웨이가 실패 상태거나 Elastic IP 미연결 시 인터넷 접근 불가 ✅
• E. 포트 포워딩 설정 문제
  → NAT 게이트웨이는 포트 포워딩 개념이 아님. ❌

✅ 정답: A, D

---

📝 쉬운 해설

1. NAT Gateway 제한사항
   • TCP/UDP 지원
   • ICMP (ping) 같은 다른 프로토콜은 지원하지 않음
2. 상태 확인
   • NAT GW가 “사용 불가 상태”라면 트래픽 전달 불가
   • 보통 Elastic IP 미연결, 라우팅 테이블 오류, 서브넷 문제가 원인

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “NAT GW 장애 원인 = 프로토콜 제한 + 상태 확인”

• TCP/UDP만 지원
• NAT 게이트웨이가 “사용 불가” 상태면 인터넷 연결 안 됨

---

Q39.
A SysOps administrator migrates NAT instances to NAT gateways. After the migration,
an application that is hosted on Amazon EC2 instances in a private subnet cannot access the internet.
Which of the following are possible reasons for this problem? (Choose two)

A. The application is using a protocol that the NAT gateway does not support.
B. The NAT gateway is not in a security group.
C. The NAT gateway is in an unsupported Availability Zone.
D. The NAT gateway is not in the Available state.
E. The port forwarding settings do not allow access to internal services from the internet.

Answer: A, D

 

 

---

📘 Q46 문제 정리

🔹 문제 요약

• 회사 웹 애플리케이션: ALB 뒤의 EC2에서 동작
• 백업 사이트: S3에 정적 웹사이트로 구성
• DNS: Route 53 사용
• 요구사항:
  • ALB 기반 웹 애플리케이션이 장애나면 → 자동으로 S3 정적 웹사이트로 트래픽 전환

👉 어떤 작업 조합을 해야 할까? (2개 선택)

---

🔹 선택지 분석

• A. 기본 장애 조치 라우팅 정책을 ALB로 설정
  → 백업 사이트 연결 고려 없음 ❌
• B. Lambda를 이용한 수동 장애 전환
  → 자동화 요구사항 충족 못 함 ❌
• C. 기본 장애 조치 라우팅 정책 레코드를 ALB로 설정, 상태 확인과 연결
  → 정상일 때는 ALB로 트래픽 전달 ✅
• D. 보조 장애 조치 라우팅 정책 레코드를 ALB로 설정
  → 백업은 ALB가 아니라 S3여야 함 ❌
• E. 보조 장애 조치 라우팅 정책 레코드를 S3 정적 웹사이트로 설정
  → ALB 장애 시 자동으로 S3로 트래픽 전환 ✅

✅ 정답: C, E

---

📝 쉬운 해설

• Route 53 Failover Routing을 사용
• Primary = ALB
• Secondary = S3 정적 웹사이트
• Route 53이 Health Check로 ALB 상태를 감시
• 장애 발생 시 자동으로 S3 백업 사이트로 전환

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “ALB Primary + S3 Secondary = Route 53 Failover”

• ALB = 메인 서비스
• S3 = 백업 사이트
• Route 53 Health Check로 자동 전환

---

 

 

Q46.
A company hosts a web application on Amazon EC2 instances behind an Application Load Balancer (ALB).
The company uses Amazon Route 53 to route traffic.
The company also has a static website that is configured in an Amazon S3 bucket.

A SysOps administrator must use the static website as a backup to the web application.
The failover to the static website must be fully automated.
Which combination of actions will meet these requirements? (Choose two)

A. Create a primary failover routing policy record.
Configure the value to be the ALB.
B. Create an AWS Lambda function to switch from the primary website
to the secondary website when the health check fails.
C. Create a primary failover routing policy record.
Configure the value to be the ALB.
Associate the record with a Route 53 health check.
D. Create a secondary failover routing policy record.
Configure the value to be the static website.
Associate the record with a Route 53 health check.
E. Create a secondary failover routing policy record.
Configure the value to be the static website.

Answer: C, E

 

---

📘 Q47 문제 정리

🔹 문제 요약

• Amazon EC2 인스턴스에서 데이터 분석 애플리케이션 실행 중
• SysOps 관리자가 CloudWatch Agent에서 수집하는 메트릭에 **사용자 지정 차원(Custom Dimension)**을 추가해야 함

👉 어떤 방법이 올바른가?

---

🔹 선택지 분석

• A. CloudWatch Agent + 사용자 지정 스크립트
  → 가능은 하지만 번거롭고 관리 부담 큼 ❌
• B. EventBridge 규칙 + SNS 전송
  → 알림/이벤트 처리용. 메트릭에 차원 추가와는 무관 ❌
• C. CloudTrail + CloudWatch Logs + Lambda
  → CloudTrail은 API 호출 기록용. 메트릭 차원 추가와는 관계 없음 ❌
• D. CloudWatch Agent 설정 파일에 append_dimensions 필드 추가
  → 가장 올바른 방법 ✅
  → 예: {"append_dimensions": {"InstanceId": "${aws:InstanceId}"}}

✅ 정답: D

---

📝 쉬운 해설

• CloudWatch Agent 설정 파일(amazon-cloudwatch-agent.json)에는
  → metrics_collected (수집할 메트릭)
  → append_dimensions (추가할 사용자 지정 차원)
• 예를 들어, 각 인스턴스의 InstanceId, AutoScalingGroupName 등을 차원으로 붙일 수 있음
• 이렇게 하면 메트릭 분석/필터링이 훨씬 쉬워짐

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 CloudWatch 메트릭에 사용자 정의 차원 추가 = append_dimensions

• Agent 설정 파일에서 지정
• InstanceId, ASG 이름 같은 정보 자동 추가 가능

 

---

 

Q47.
A data analytics application is running on an Amazon EC2 instance.
A SysOps administrator must add custom dimensions to the metrics collected by the Amazon CloudWatch agent. How can the SysOps administrator meet this requirement?

A. Create a custom shell script to extract the dimensions and collect the metrics using the Amazon CloudWatch agent.
B. Create an Amazon EventBridge (Amazon CloudWatch Events) rule to evaluate the required custom dimensions and send the metrics to Amazon Simple Notification Service (Amazon SNS).
C. Create an AWS Lambda function to collect the metrics from AWS CloudTrail and send the metrics to an Amazon CloudWatch Logs group.
D. Create an append_dimensions field in the Amazon CloudWatch agent configuration file to collect the metrics.

Answer: D

 

---

📘 Q51 문제 정리

🔹 문제 요약

• SysOps 관리자가 아래와 같은 CloudFormation 템플릿을 사용하여 EC2 인스턴스를 생성하려고 함

👉 스택 생성이 실패하는 이유는 무엇일까?

---

🔹 선택지 분석

• A. 출력(Outputs) 섹션 없음
  → Outputs는 선택 사항. 없어도 스택 생성 가능 ❌
• B. 매개변수(Parameters) 섹션 없음
  → Parameters도 선택 사항. 없어도 문제 없음 ❌
• C. PrivateDnsName 속성은 CloudFormation에서 설정할 수 없음
  → ✅ 올바른 답변. PrivateDnsName은 EC2 생성 시 AWS에서 자동으로 할당하는 값이지, 사용자가 템플릿에 직접 지정 불가 ✅
• D. VPC 지정 없음
  → SubnetId를 지정했기 때문에 VPC도 자동으로 연계됨. 문제 아님 ❌

✅ 정답: C

---

📝 쉬운 해설

• CloudFormation에서 허용되지 않는 속성을 사용했기 때문
• EC2의 PrivateDnsName은 AWS가 인스턴스 시작 시 자동 생성하는 값
• 따라서 CloudFormation 템플릿에서 해당 속성을 수동으로 지정하면 스택 생성 실패 발생

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “CloudFormation에서 EC2 PrivateDnsName은 자동 설정”

• 수동 지정 ❌ → 오류 발생
• AWS가 자동 할당 ✅

---

 

Q51.
A SysOps administrator is examining the following AWS CloudFormation template:

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Creates an EC2 Instance'
Resources:
  EC2Instance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: ami-79fd7eee
      InstanceType: m5n.large
      SubnetId: subnet-1abc3d3fg
      PrivateDnsName: ip-10-24-34-0.ec2.internal
      Tags:
        - Key: Name
          Value: !Sub "${AWS::StackName} Instance"

Why will the stack creation fail?

A. The Outputs section of the CloudFormation template was omitted.
B. The Parameters section of the CloudFormation template was omitted.
C. The PrivateDnsName cannot be set from a CloudFormation template.
D. The VPC was not specified in the CloudFormation template.

Answer: C

---

📘 Q52 문제 정리

🔹 문제 요약

• 새 애플리케이션: EC2 인스턴스에서 실행
• 데이터베이스: Amazon RDS 인스턴스
• 배포 후 애플리케이션이 실패하고,
  에러 로그: Error Establishing a Database Connection

👉 가능한 원인은? (2개 선택)

---

🔹 선택지 분석

• A. DB 보안 그룹에 송신 규칙 없음
  → 송신 규칙은 기본적으로 모든 아웃바운드 허용. 일반적으로 문제 원인 아님 ❌
• B. 인증서 문제
  → TLS 인증서 신뢰 관련. 여기서는 연결 자체가 안 되므로 무관 ❌
• C. DB 보안 그룹에 EC2 → DB로의 수신 규칙 없음
  → ✅ 올바른 원인. DB 보안 그룹에서 EC2 보안 그룹/서브넷을 허용해야 연결 가능
• D. EC2 애플리케이션의 포트가 DB 포트와 불일치
  → ✅ 올바른 원인. 예: DB는 3306인데 애플리케이션 설정이 3307이면 연결 불가
• E. RDS가 아직 생성 중
  → 문제에서 이미 "쿼리할 수 있다"고 했으므로 무관 ❌

✅ 정답: C, D

---

📝 쉬운 해설

1. DB 연결 실패 주요 원인
   • DB 보안 그룹(Security Group)에서 EC2 인스턴스 접근을 허용하지 않음
   • 앱에서 사용하는 DB 포트 설정이 잘못됨
2. EC2 → RDS 연결 성공 조건
   • 올바른 포트 (MySQL=3306, PostgreSQL=5432 등)
   • DB SG에서 EC2 SG 또는 CIDR 허용

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “DB 연결 안 될 때는? SG 규칙 + 포트 확인”

• SG 인바운드 확인
• 앱 DB 포트 확인

---

 

 

Q52.
A new application runs on Amazon EC2 instances and accesses data in an Amazon RDS database instance. When fully deployed in production, the application fails.
The database can be queried from a console on a bastion host.
When looking at the web server logs, the following error is repeated multiple times:

*** Error Establishing a Database Connection Which of the following may be causes of the connectivity problems? (Choose two)

A. The security group for the database does not have the appropriate egress rule from the database to the web server.
B. The certificate used by the web server is not trusted by the RDS instance.
C. The security group for the database does not have the appropriate ingress rule from the web server to the database.
D. The port used by the application developer does not match the port specified in the RDS configuration.
E. The database is still being created and is not available for connectivity.

Answer: C, D

---

📘 Q55 문제 정리

🔹 문제 요약

• 회사는 CloudFront 배포를 통해 웹사이트를 제공
• 모든 트래픽 로그는 중앙에서 저장되어야 함
• 저장 시 모든 데이터는 반드시 암호화되어야 함

👉 어떤 솔루션이 이 요구사항을 충족할까?

---

🔹 선택지 분석

• A. KMS CMK + OpenSearch
  → OpenSearch는 검색/로그 분석 서비스, CloudFront 로그 저장소로 적합하지 않음 ❌
• B. AES-256 + OpenSearch
  → 역시 저장은 가능하지만 중앙 저장/암호화 로그 저장소로는 비효율적 ❌
• C. AES-256 서버 측 암호화(SSE-S3) 적용된 S3 버킷에 CloudFront 로그 저장
  → CloudFront 액세스 로그를 S3로 저장 가능
  → S3에서 AES-256 기본 암호화 적용하면 저장 시 자동 암호화 ✅
• D. KMS 암호화된 S3 버킷 + CloudFront 로그 저장
  → 가능은 하지만 요구사항은 단순히 “모든 데이터가 암호화”
  → 기본 AES-256로 충분, KMS는 과도한 옵션 ❌

✅ 정답: C

---

📝 쉬운 해설

• CloudFront는 액세스 로그를 S3 버킷에 저장 가능
• S3는 저장 시 자동 암호화 기능 제공
  • SSE-S3 (AES-256): 간단하고 관리 부담 적음
  • SSE-KMS: 더 세밀한 키 관리 필요할 때 사용
• 문제 요구사항 = 저장 시 반드시 암호화 → AES-256 기본 암호화로 충족

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “CloudFront 로그 중앙 저장 = S3 + AES-256”

• CloudFront 로그 저장 = 항상 S3
• 데이터 암호화 = 기본 AES-256로 충분

 

---

Q55.
A company uses an Amazon CloudFront distribution to deliver its website.
Traffic logs for the website must be centrally stored, and all data must be encrypted at rest.
Which solution will meet these requirements?

A. Create an Amazon OpenSearch Service (Amazon Elasticsearch Service) domain with internet access and server-side encryption that uses the default AWS managed customer master key (CMK).
Configure CloudFront to use the Amazon OpenSearch Service (Amazon Elasticsearch Service) domain as a log destination.
B. Create an Amazon OpenSearch Service (Amazon Elasticsearch Service) domain with VPC access and server-side encryption that uses AES-256. Configure CloudFront to use the Amazon OpenSearch Service (Amazon Elasticsearch Service) domain as a log destination.
C. Create an Amazon S3 bucket that is configured with default server-side encryption that uses AES-256. Configure CloudFront to use the S3 bucket as a log destination.
D. Create an Amazon S3 bucket that is configured with no default encryption.
Enable encryption in the CloudFront distribution, and use the S3 bucket as a log destination.

Answer: C

---

📘 Q62 문제 정리

🔹 문제 요약

• 회사는 SysOps 관리자에게 CloudTrail 로그 파일이 생성된 후 변조되지 않았는지 확인하도록 요청
• IAM을 사용해 특정 트레일에 대한 액세스를 제한해야 함
• 요구사항: 로그 파일의 무결성 검증 기능 필요

👉 어떤 방법이 가장 효율적인가?

---

🔹 선택지 분석

• A. Lambda + EventBridge + DynamoDB로 MD5 해시 검증
  → 가능은 하지만 너무 복잡하고 운영 오버헤드 큼 ❌
• B. Lambda로 CloudTrail 전달 이벤트마다 해시 계산 후 S3에 저장
  → 역시 사용자 정의 코드 필요, 비효율적 ❌
• C. S3 버킷 정책으로 IAM 권한 제어
  → 권한 제어는 되지만, 파일 무결성(변조 여부) 검증은 불가 ❌
• D. CloudTrail 로그 파일 무결성 검증 기능 활성화
  → AWS에서 제공하는 기본 기능 ✅
  → CloudTrail은 각 로그 파일에 서명(Signature)과 다이제스트(Digest) 파일을 제공
  → 보안 팀이 이를 통해 로그 파일이 변조되지 않았는지 확인 가능

✅ 정답: D

---

📝 쉬운 해설

• CloudTrail은 옵션으로 **로그 파일 무결성 검증(File Integrity Validation)**을 지원
• 활성화 시 각 로그 파일에 대해 SHA-256 해시 + 디지털 서명을 함께 제공
• 보안팀은 이를 사용해 로그가 중간에 변조되었는지 확인 가능

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “CloudTrail 로그 변조 방지 = 무결성 검증 기능 ON”

• Digest 파일 + 서명 → 변조 여부 추적 가능
• Lambda 같은 커스텀 검증 불필요

 

---

Q62.
A company asks a SysOps administrator to ensure that AWS CloudTrail files are not tampered with after they are created. Currently, the company uses AWS Identity and Access Management (IAM) to restrict access to specific trails. The company's security team needs the ability to trace the integrity of each file.
What is the MOST operationally efficient solution that meets these requirements?

A. Create an Amazon EventBridge (Amazon CloudWatch Events) rule that invokes an AWS Lambda function when a new file is delivered. Configure the Lambda function to compute an MD5 hash check on the file and store the result in an Amazon DynamoDB table. The security team can use the values that are stored in DynamoDB to verify the integrity of the delivered files.
B. Create an AWS Lambda function that is invoked each time a new file is delivered to the CloudTrail bucket. Configure the Lambda function to compute an MD5 hash check on the file and store the result as a tag in an Amazon 53 object. The security team can use the information in the tag to verify the integrity of the delivered files. C. Enable the CloudTrail file integrity feature on an Amazon S3 bucket. Create an IAM policy that grants the security team access to the file integrity logs that are stored in the S3 bucket.
D. Enable the CloudTrail file integrity feature on the trail. The security team can use the digest file that is created by CloudTrail to verify the integrity of the delivered files.

Answer: D

---

📘 Q63 문제 정리

🔹 문제 요약

• AWS 클라우드 인프라에서 조직에 영향을 미칠 수 있는 이벤트가 발생했을 때,
• 어떤 AWS 서비스를 통해 내 리소스에 직접적인 영향 여부를 확인할 수 있을까?

---

🔹 선택지 분석

• A. AWS Service Health Dashboard
  → AWS 전체 리전/서비스 상태를 보여줌 (공용 대시보드)
  → 내 계정 리소스에 영향이 있는지는 알려주지 않음 ❌
• B. AWS Trusted Advisor
  → 비용 최적화, 보안, 성능, 제한(Quota) 점검 도구
  → 이벤트 영향과는 무관 ❌
• C. AWS Personal Health Dashboard
  → 내 계정과 리소스에 직접 영향이 있는 이벤트를 보여줌 ✅
  → 예: 특정 리전 EC2 장애가 내 인스턴스에 영향을 주는지 확인 가능
• D. AWS Systems Manager
  → 인스턴스/리소스 운영 관리 도구
  → 이벤트 모니터링 서비스 아님 ❌

✅ 정답: C

---

📝 쉬운 해설

• Service Health Dashboard = 전 세계 AWS 서비스 상태 (공통, 누구나 확인 가능)
• Personal Health Dashboard = 내 계정 리소스에 실제 영향이 있는 이벤트만 표시 (맞춤형)

즉, "조직에 영향을 주는 이벤트 확인" 문제에서는 항상 Personal Health Dashboard가 정답!

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “전체 상태 = Service, 내 리소스 영향 = Personal”

• Service Health Dashboard = 전 세계 상황
• Personal Health Dashboard = 내 계정 영향

 

---

Q63.
When the AWS Cloud infrastructure experiences an event that may impact an organization,
which AWS service can be used to see which of the organization's resources are affected?

A. AWS Service Health Dashboard
B. AWS Trusted Advisor
C. AWS Personal Health Dashboard
D. AWS Systems Manager

Answer: C

---

📘 Q66 문제 정리

🔹 문제 요약

• 웹사이트: Amazon S3 정적 웹사이트 호스팅
• DNS: Route 53에서 도메인 이름(www.example.com)을 설정해 S3 버킷에 매핑
• 그런데 설정 후 도메인 접속이 안 되고, S3 정적 웹사이트 기본 도메인(예: s3-website-...amazonaws.com)만 표시됨

👉 원인은 무엇일까?

---

🔹 선택지 분석

• A. 먼저 CloudFront를 구성해야 한다
  → S3 정적 웹사이트는 CloudFront 없어도 동작 가능. 필수 조건 아님 ❌
• B. Route 53 레코드에 IAM 권한 필요
  → Route 53 레코드는 DNS 리졸빙만 담당, IAM 권한과 무관 ❌
• C. Route 53 레코드는 동일 리전에 있어야 한다
  → Route 53은 글로벌 서비스, 리전 무관 ❌
• D. S3 버킷 이름이 Route 53 도메인 이름과 반드시 일치해야 한다
  → 정답 ✅
  → 예: 도메인 이름이 www.example.com이면, S3 버킷 이름도 **www.example.com**이어야 함

✅ 정답: D

---

📝 쉬운 해설

• S3 정적 웹사이트 호스팅 시 버킷 이름 = 도메인 이름이어야 함
• 예시:
  • 도메인: www.example.com
  • S3 버킷 이름: www.example.com
• 그렇지 않으면 Route 53에서 Alias 레코드 연결 시 인식되지 않아 접속 불가

---

📊 Mermaid 시각화

 

---

🎯 암기 팁

👉 “S3 정적 웹 호스팅 = 버킷 이름 = 도메인 이름”

• example.com → 버킷 이름도 example.com
• www.example.com → 버킷 이름도 www.example.com

 

---

Q66.
A SysOps administrator is trying to set up an Amazon Route 53 domain name to route traffic to a website hosted on Amazon S3.
The domain name of the website is www.example.com and the S3 bucket name DOC-EXAMPLE-BUCKET.
After the record set is set up in Route 53, the domain name www.anycompany.com does not seem to work,
and the static website is not displayed in the browser. Which of the following is a cause of this?

A. The S3 bucket must be configured with Amazon CloudFront first.
B. The Route 53 record set must have an IAM role that allows access to the S3 bucket.
C. The Route 53 record set must be in the same region as the S3 bucket.
D. The S3 bucket name must match the record set name in Route 53.

Answer: D

---

📘 Q78 문제 정리

🔹 문제 요약

• 글로벌 기업, 5개 리전에서 EC2 인스턴스 운영 중
• SysOps 관리자는 특정 태그가 없는 EC2 인스턴스를 찾아내야 함
• 회사는 인스턴스 ID와 태그를 보여주는 출력물이 필요

👉 가장 운영상 효율적인 방법은?

---

🔹 선택지 분석

• A. 태그 기반 리소스 그룹 생성
  → 태그가 없는 리소스는 그룹화할 수 없음 ❌
• B. Trusted Advisor 사용
  → Trusted Advisor는 비용/보안/제한 권고 제공, 태그 기반 인스턴스 리포트는 제공하지 않음 ❌
• C. 비용 탐색기(Cost Explorer)
  → 비용/사용량 기반 분석 도구, 태그 없는 인스턴스 구분 용도 아님 ❌
• D. AWS 리소스 그룹(Tag Editor) 사용
  → 여러 리전에 걸쳐 모든 EC2 인스턴스와 태그를 조회 가능 ✅
  → 태그가 없는 리소스도 쉽게 식별 가능

✅ 정답: D

---

📝 쉬운 해설

• Tag Editor (리소스 그룹) = 여러 리전에 걸쳐 리소스의 태그 현황을 검색/관리할 수 있는 도구
• 필터로 EC2 인스턴스 리소스를 선택 → 태그 여부 확인 가능
• 태그가 없는 인스턴스도 결과에서 보여주기 때문에 요구사항 충족

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “여러 리전 태그 관리 = Tag Editor”

• Trusted Advisor ❌ (권장사항)
• Cost Explorer ❌ (비용 분석)
• Tag Editor ✅ (태그 현황 관리/조회)

 

---

Q78.
A global company operates out of five AWS Regions.
A SysOps administrator wants to identify all the company's tagged and untagged Amazon EC2 instances.
The company requires the output to display the instance ID and tags.
What is the MOST operationally efficient way for the SysOps administrator to meet these requirements?

A. Create a tag-based resource group in AWS Resource Groups.
B. Use AWS Trusted Advisor. Export the EC2 On-Demand Instances check results from Trusted Advisor.
C. Use Cost Explorer. Choose a service type of EC2-Instances, and group by Resource.
D. Use Tag Editor in AWS Resource Groups. Select all Regions, and choose a resource type of AWS::EC2::Instance.

Answer: D

---

📘 Q84 문제 정리

🔹 문제 요약

• 회사는 us-east-1 리전의 한 가용 영역(AZ)에 두 개의 EC2 인스턴스를 실행 중
• SysOps 관리자는 이 중 하나를 다른 가용 영역(AZ) 으로 마이그레이션해야 함

👉 어떤 방법이 적절할까?

---

🔹 선택지 분석

• A. 인스턴스를 다른 가용 영역으로 복사 후 원본 종료
  → EC2는 단순히 “복사”로 다른 AZ로 옮길 수 없음 ❌
• B. EC2 인스턴스에서 AMI(Amazon Machine Image) 생성 후, 이를 다른 AZ에서 시작
  → 올바른 절차 ✅
  → AMI로 동일한 설정의 새 인스턴스를 다른 AZ에 배포 가능
• C. AWS CLI로 인스턴스를 직접 다른 AZ로 이동
  → EC2 인스턴스는 “이동” 개념이 없음. 새로 시작해야 함 ❌
• D. 인스턴스 중지 후 AZ 수정
  → AZ는 변경 불가능. 중지 후 재시작해도 같은 AZ에 생성됨 ❌

✅ 정답: B

---

📝 쉬운 해설

• EC2 인스턴스는 생성된 가용 영역을 바꿀 수 없음
• 따라서 AMI를 생성 → 원하는 AZ에서 새로운 인스턴스를 시작해야 함
• 원본 인스턴스는 종료할 수 있음 (옵션)

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “AZ 변경 = AMI 만들어 새로 시작”

• 이동 ❌
• 중지 후 재시작 ❌
• AMI 생성 → 새 인스턴스 시작 ✅

 

---

Q84.
A company runs a multi-tier web application with two Amazon EC2 instances in one Availability Zone in the us-east-1 Region. A SysOps administrator must migrate one of the EC2 instances to a new Availability Zone.
Which solution will accomplish this?

A. Copy the EC2 instance to a different Availability Zone. Terminate the original instance.
B. Create an Amazon Machine Image (AMI) from the EC2 instance and launch it in a different Availability Zone. Terminate the original instance.
C. Move the EC2 instance to a different Availability Zone using the AWS CLI.
D. Stop the EC2 instance, modify the Availability Zone, and start the instance.

Answer: B

---

📘 Q85 문제 정리

🔹 문제 요약

• 회사는 트래픽 증가 대비 → EC2 인스턴스 집합 확장 계획
• SysOps 관리자가 인스턴스 추가 시도 → InstanceLimitExceeded 오류 발생

👉 이 오류를 해결하려면 어떻게 해야 할까?

---

🔹 선택지 분석

• A. VPC에 추가 CIDR 블록 할당
  → 네트워크 IP 공간 부족 문제 해결 방법, 이번 문제와 무관 ❌
• B. 다른 가용 영역(AZ)에서 EC2 시작
  → AZ를 바꿔도 계정의 인스턴스 한도는 동일. 오류 해결 불가 ❌
• C. 다른 VPC에서 새 인스턴스 시작
  → VPC를 바꿔도 계정 한도는 동일. 해결책 아님 ❌
• D. 서비스 할당량(Service Quotas)에서 EC2 인스턴스 한도 증가 요청
  → 정답 ✅
  → InstanceLimitExceeded 오류는 계정의 **EC2 서비스 할당량(Soft Limit)**을 초과했을 때 발생
  → 콘솔(Service Quotas)이나 AWS Support로 증가 요청 가능

✅ 정답: D

---

📝 쉬운 해설

• AWS 계정에는 리소스별 기본 서비스 한도가 있음
  • 예: 리전별 EC2 인스턴스 수 제한
• InstanceLimitExceeded는 바로 이 한도를 초과했을 때 발생하는 오류
• 해결책 = 할당량 증가 요청(Quota Increase)

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “InstanceLimitExceeded = Service Quotas 요청”

• 네트워크 문제 아님 ❌
• AZ/VPC 바꿔도 동일 ❌
• Service Quotas에서 증가 요청 ✅

 

---

 

Q85.
A company is expanding its fleet of Amazon EC2 instances before an expected increase of traffic.
When a SysOps administrator attempts to add more instances, an InstanceLimitExceeded error is returned.
What should the SysOps administrator do to resolve this error?

A. Add an additional CIDR block to the VPC.
B. Launch the EC2 instances in a different Availability Zone.
C. Launch new EC2 instances in another VPC.
D. Use Service Quotas to request an EC2 quota increase.

Answer: D

 

---

📘 Q87 문제 정리

🔹 문제 요약

• EC2 인스턴스가 VPC 안에서 실행 중
• 애플리케이션은 mssql.example.com (온프레미스 SQL Server) DB에 연결해야 함
• 그런데 VPC 내부 EC2 인스턴스는 해당 DNS 이름을 확인하지 못함

👉 이 문제를 해결하는 방법은?

---

🔹 선택지 분석

• A. Route 53 Resolver 인바운드 엔드포인트 + 전달 규칙
  → 인바운드는 온프레미스에서 AWS로 오는 DNS 쿼리 처리용 ❌
• B. Route 53 Resolver 인바운드 엔드포인트 + 시스템 규칙
  → 인바운드는 여전히 방향이 반대. 이번 문제와 무관 ❌
• C. Route 53 Resolver 아웃바운드 엔드포인트 + 전달 규칙
  → EC2 → 온프레미스 DNS로 쿼리 전송 가능 ✅
  → VPC와 연결 후 example.com 도메인에 대한 전달 규칙 작성
• D. Route 53 Resolver 아웃바운드 엔드포인트 + 시스템 규칙
  → 시스템 규칙이 아니라 전달 규칙을 사용해야 함 ❌

✅ 정답: C

---

📝 쉬운 해설

• 인바운드 엔드포인트: 온프레미스 → AWS VPC로 DNS 요청 보낼 때 필요
• 아웃바운드 엔드포인트: AWS VPC → 온프레미스 DNS 서버로 요청 보낼 때 필요
• 이번 문제는 EC2(VPC) → 온프레미스 DNS 쿼리라서 아웃바운드 엔드포인트가 정답

---

📊 Mermaid 시각화

 

---

🎯 암기 팁

👉 DNS 쿼리 방향 기억하기

• 온프레미스 → AWS = 인바운드
• AWS VPC → 온프레미스 = 아웃바운드

 

---

Q87.
An application is running on an Amazon EC2 instance in a VPC with the default DHCP option set. The application connects to an on-premises Microsoft SQL Server database with the DNS name mssql.example.com.
The application is unable to resolve the database DNS name.
Which solution will fix this problem?

A. Create an Amazon Route 53 Resolver inbound endpoint. Add a forwarding rule for the domain example.com. Associate the forwarding rule with the VPC.
B. Create an Amazon Route 53 Resolver inbound endpoint. Add a system rule for the domain example.com. Associate the system rule with the VPC.
C. Create an Amazon Route 53 Resolver outbound endpoint. Add a forwarding rule for the domain example.com. Associate the forwarding rule with the VPC.
D. Create an Amazon Route 53 Resolver outbound endpoint. Add a system rule for the domain example.com. Associate the system rule with the VPC.

Answer: C

 

---

📘 Q94 문제 정리

🔹 문제 요약

• SysOps 관리자는 여러 IAM 정책을 IAM 사용자에게 연결해 AWS 서비스 접근을 제공하려 함
• 또한 정책을 변경하고 새 버전을 생성할 수 있기를 원함

👉 이 요구사항을 충족하는 작업 조합은? (2개 선택)

---

🔹 선택지 분석

• A. IAM 서비스 연결 역할(Service-linked role) 사용
  → 특정 AWS 서비스가 자동 생성하는 역할. 사용자 접근 제어와는 무관 ❌
• B. IAM 사용자 그룹에 사용자를 추가하고, 정책을 그룹에 연결
  → 효율적인 관리 방법. 그룹 단위로 정책 부여 가능 ✅
• C. AWS 관리형 정책 사용
  → 관리형 정책은 AWS가 제공, 버전 관리 불가 ❌
• D. 고객 관리형 정책(Customer managed policy) 사용
  → 직접 작성 및 관리 가능. 정책 버전 관리 가능 ✅
• E. 인라인 정책 사용
  → 사용자/그룹/역할에 직접 붙는 정책. 버전 관리 불가 ❌

✅ 정답: B, D

---

📝 쉬운 해설

1. IAM 그룹 + 정책 연결
   • 많은 사용자에게 정책을 쉽게 적용 가능
   • 그룹 단위로 관리 → 운영 효율 ↑
2. 고객 관리형 정책
   • 직접 만든 정책 → 수정/새 버전 관리 가능
   • AWS 관리형 정책/인라인 정책에는 없는 장점

---

📊 Mermaid 시각화

---

🎯 암기 팁

👉 “IAM 다수 사용자 관리 = 그룹 + 고객 관리형 정책”

• 그룹: 사용자 묶어서 정책 적용
• 고객 관리형: 정책 버전 관리 가능

 

---

Q94.
A SysOps administrator wants to provide access to AWS services by attaching an IAM policy to multiple IAM users. The SysOps administrator also wants to be able to change the policy and create new versions.
Which combination of actions will meet these requirements? (Choose two)

A. Add the users to an IAM service-linked role. Attach the policy to the role.
B. Add the users to an IAM user group. Attach the policy to the group.
C. Create an AWS managed policy.
D. Create a customer managed policy.
E. Create an inline policy.

Answer: B, D

---