[AWS SOA-C02] Q301 ~ Q341 오답노트 5EA

📘 Q311 문제 정리

📝 문제 요약

• 회사는 여러 사업부에서 Amazon EC2를 사용.
• 단, 승인된 EC2 인스턴스 구성만 사용해야 함.
• 사업부는 직접 인스턴스를 시작(provisioning) 가능해야 함.

---

✅ 정답: C. AWS Service Catalog

AWS Service Catalog를 사용하면 관리자가 승인된 EC2 인스턴스 템플릿을 미리 정의할 수 있음.
각 사업부는 Service Catalog 안에서만 인스턴스를 실행할 수 있으므로, 표준화된 구성만 사용 가능.

---

❌ 오답 포인트

1. A. Management Console에서 인스턴스 시작 구성 허용
   • 단순히 시작 구성을 지정하는 방법.
   • 승인된 인스턴스만 보장 ❌ (사업부가 다른 구성도 시작할 수 있음).
2. B. IAM 정책 + CloudFormation 템플릿 제공
   • IAM 정책만으로는 승인된 인스턴스 구성 강제 ❌.
   • CloudFormation 템플릿도 사업부가 임의로 수정 가능 → 보안 리스크.
3. D. CloudFormation 템플릿 공유
   • 템플릿을 직접 공유하는 방식도 마찬가지로 표준 강제가 어려움.
   • 관리자가 승인된 구성을 보장하기에는 불완전.

---

🔎 해설

• AWS Service Catalog는 기업 IT에서 표준화된 리소스 템플릿을 제공할 때 사용.
• EC2, RDS, VPC 등 미리 승인된 구성을 카탈로그로 묶어 제공 →
  사업부는 해당 카탈로그 내에서만 리소스를 시작 가능.
• 따라서 정책 준수와 운영 효율성을 동시에 만족시킴.

---

📊 흐름 (Mermaid 다이어그램)

 

---

📌 핵심 키워드

• Service Catalog → 표준화 + 승인된 구성만 제공
• IAM → 권한 제어 보완용
• CloudFormation → 리소스 자동화 (하지만 표준 강제 기능은 부족)

---

👉 정리: "여러 부서에서 EC2를 써야 하지만 반드시 표준화된 구성만 쓰게 하고 싶다" → 정답은 무조건 Service Catalog.

 

---

📝 Q314 분석 정리

📌 문제 요약

• 환경: Windows 파일 서버 + Amazon FSx 파일 시스템
• 조건: 사용 가능한 공간이 100GB 미만일 때 관리자에게 이메일 알림
• 요구 사항: SysOps 관리자가 SNS를 통해 이메일을 받아야 함

---

✅ 정답: B, E

---

🔎 선택지별 해설

1. A. FreeStorageCapacity 지표 + EventBridge 규칙 ❌
   • EventBridge는 주로 이벤트 기반 서비스 연동에 사용됨.
   • 스토리지 임계치 모니터링은 CloudWatch 지표와 알람이 적합.
2. B. FreeStorageCapacity 지표 + CloudWatch 경보 ✅
   • Amazon FSx는 CloudWatch 지표(FreeStorageCapacity) 제공.
   • 조건(100GB 미만)일 때 CloudWatch Alarm을 트리거하여 모니터링 가능.
3. C. CloudWatch 경보 → Lambda → SNS 게시 ❌
   • 가능은 하지만 불필요하게 Lambda를 거칠 필요 없음.
   • 문제 요구는 단순히 이메일 알림 → SNS 직접 연결이 가장 효율적.
4. D. Alarm 진입 시 EventBridge 규칙 실행 ❌
   • EventBridge로 우회할 필요 없음.
   • CloudWatch Alarm → SNS 연결로 충분.
5. E. CloudWatch Alarm → SNS 주제 알림 구성 ✅
   • CloudWatch Alarm 상태 전환 시 SNS에 게시 → 이메일 알림 발송
   • 문제에서 요구하는 알림 방식을 충족.

 

---

📊 아키텍처 흐름 (Mermaid)

 

 

---

🎯 정리

• B: FreeStorageCapacity 지표를 기반으로 CloudWatch Alarm 생성
• E: Alarm 상태 전환 시 SNS로 알림 → 이메일 발송

---

👉 즉, CloudWatch + SNS 조합이 정답!

 

---

📘 Q326 문제 정리

📝 문제 상황

• 환경: AWS Organizations → 여러 계정 관리
• 요구사항:
  • 각 계정 리소스의 메트릭 임계값 초과 시 경고 발생
  • 이를 중앙 집중식으로 알림 받을 수 있어야 함

---

✅ 정답: A

👉 조직의 계정에 CloudFormation StackSets을 배포하고,
👉 각 계정에서 CloudWatch Alarm을 생성하며,
👉 로그/보안 계정에 있는 SNS 주제로 알림을 전달한다.

---

📊 아키텍처 흐름 (Mermaid)

 

---

🔑 핵심 개념 정리

• CloudFormation StackSets
  • 멀티 계정/리전에 CloudFormation 리소스를 일괄 배포 가능
• CloudWatch Alarms
  • 각 계정에서 리소스 상태 모니터링 및 임계값 초과 감지
• SNS (중앙 계정)
  • 모든 계정에서 발생한 경보를 한 곳에 모아 중앙 관리자에게 전달

---

🚀 운영 효율 포인트

• 계정이 많아도 일관된 모니터링/알림 구조 유지 가능
• 관리 계정 하나에서만 집중 관리 → 운영 부담 최소화
• 확장성 좋고, 보안적으로도 안전한 구조

---

👉 이렇게 하면 Q326은 “멀티 계정 환경에서 중앙 집중식 CloudWatch 알림 체계 구축” 문제라는 게 명확해집니다 ✅

---

📘 Q327 문제 정리

📌 문제 요약

• 회사는 AWS Lambda 함수를 사용해 외부 소스에서 데이터를 검색.
• Lambda 함수는 VPC와 연결되지 않은 상태.
• 수정된 애플리케이션은 프라이빗 서브넷의 Amazon RDS DB 인스턴스에 접근해야 함.
• VPC는 퍼블릭 서브넷 2개, 프라이빗 서브넷 2개 존재.
• 목표: Lambda 함수가 프라이빗 DB에 액세스 가능하면서도 인터넷 접근이 가능해야 함.

---

✅ 정답: C

VPC 액세스를 위해 Lambda 함수를 재구성하고, NAT 게이트웨이를 통해 인터넷으로 라우팅하도록 설정

• Lambda 함수를 VPC에 연결해야 프라이빗 RDS 접근 가능
• 하지만 Lambda는 인터넷이 필요하므로, 퍼블릭 서브넷에 NAT 게이트웨이 배치 → 프라이빗 서브넷에서 인터넷으로 나가는 경로 제공
• 보안 그룹과 라우팅 테이블 규칙도 함께 설정 필요

---

❌ 오답 해설

• A. VPC 액세스 및 탄력적 IP 주소 → 오답
  • Lambda는 탄력적 IP로 직접 인터넷에 접근 불가
  • NAT 게이트웨이/NAT 인스턴스를 사용해야 함
• B. VPC 액세스 + 탄력적 IP 주소 + 새로운 Lambda → 오답
  • Lambda 함수 생성 방식이 잘못됨 (탄력적 IP 불필요)
  • 핵심은 NAT 게이트웨이 필요성
• D. VPC 액세스 + 인터넷 게이트웨이 → 오답
  • 프라이빗 서브넷에 배치된 Lambda는 인터넷 게이트웨이만으로 외부 접근 불가
  • 반드시 NAT 게이트웨이를 거쳐야 함

---

📊 정리 포인트

• Lambda가 프라이빗 서브넷 리소스(RDS) 접근 필요 → VPC 연결 필수
• Lambda가 외부 API 호출(인터넷 접근) 필요 → NAT 게이트웨이 필수
• 인터넷 게이트웨이만으로는 부족, Lambda는 퍼블릭 IP를 직접 사용하지 않음

---

📈 다이어그램 (Mermaid)

👉 핵심 기억: Lambda + VPC 연결 시 인터넷 접근하려면 NAT 게이트웨이 필요! 🚀

---

📘 Q332 문제 정리

📝 문제 요약

• 회사는 실행 중인 Amazon EC2 인스턴스 수를 모니터링하고 싶음.
• 인스턴스 수가 특정 임계값에 도달하면 서비스 할당량 증가를 자동화해야 함.

---

✅ 정답: A. CloudWatch 경보 + Lambda

Amazon CloudWatch 경보로 임계값을 모니터링하고,
해당 경보가 발생하면 AWS Lambda를 호출하여 할당량 증가 요청을 자동화.

---

❌ 오답 포인트

1. B. AWS Config
   • AWS Config는 리소스 설정 변경 추적 용도.
   • 실시간 서비스 할당량 모니터링/증가 자동화 ❌.
2. C. CloudWatch 대시보드
   • 대시보드는 시각화 도구일 뿐, 자동으로 액션 수행 ❌.
3. D. Trusted Advisor + SNS
   • Trusted Advisor는 리소스 최적화, 비용, 보안 권장사항 제공 용도.
   • 임계값에 따른 자동 증가 처리와는 무관 ❌.

---

🔎 해설

• CloudWatch는 메트릭 기반 경보 생성 가능 (ex: EC2 인스턴스 수 ≥ 특정 값).
• 경보가 발생하면 Lambda 함수를 트리거 →
  서비스 할당량 증가 API 호출 자동화.
• 따라서 운영 효율성과 자동화를 모두 충족.

---

📊 흐름 (Mermaid 다이어그램)

 

---

📌 핵심 키워드

• CloudWatch Alarm → 상태 감지
• Lambda Function → 자동화 액션 실행
• Service Quotas → 할당량 증가

---

👉 이렇게 정리해두면, 비슷한 문제에서 "모니터링 + 자동 액션" 키워드를 보면 바로 CloudWatch + Lambda 조합을 떠올리면 됩니다.