[AWS SOA-C02] Q383 ~ Q429 오답노트 7EA

📘 Q384 문제 정리

✅ 문제 요약

• 환경: 퍼블릭/프라이빗 서브넷이 있는 VPC
• 상황: 프라이빗 서브넷의 EC2 인스턴스가 인터넷에 액세스 불가
• 조건:
  • 퍼블릭 서브넷은 인터넷 게이트웨이에 연결됨
  • 프라이빗 서브넷은 퍼블릭 서브넷의 NAT 게이트웨이에 대한 경로 보유
  • EC2 인스턴스는 기본 보안 그룹과 연결됨

👉 그런데도 프라이빗 서브넷 인스턴스가 인터넷에 나가지 못함

---

✅ 정답

A. 프라이빗 서브넷에는 모든 아웃바운드 트래픽을 거부하도록 설정된 네트워크 ACL이 있습니다.

---

❌ 오답 보기 분석

• B. NAT 게이트웨이가 없음 → 문제에서 이미 NAT 게이트웨이가 존재한다고 명시되어 있음.
• C. 기본 보안 그룹이 모든 인바운드 차단 → 인바운드와 무관, 인터넷 아웃바운드 불가 문제와 직접 관련 없음.
• D. 기본 보안 그룹이 모든 아웃바운드 차단 → 기본 보안 그룹은 기본적으로 모든 아웃바운드를 허용.

---

📊 해설

• 네트워크 ACL(NACL) 은 서브넷 단위로 적용되며, 보안 그룹과 달리 상태 비저장(stateless).
• 만약 프라이빗 서브넷의 아웃바운드 규칙이 모두 DENY로 되어 있다면, NAT 게이트웨이를 거치더라도 인터넷 접근이 불가능함.
• 따라서 이 문제의 원인은 프라이빗 서브넷의 NACL 설정이 잘못되었기 때문.

---

📝 정리 포인트

• 보안 그룹(Security Group): 상태 저장, 기본 아웃바운드 허용
• 네트워크 ACL(Network ACL): 상태 비저장, 아웃바운드/인바운드 둘 다 명시 필요
• 인터넷이 안 되는 경우 확인 순서:
  1. 라우팅 테이블 (NAT/IGW 경로 확인)
  2. NACL 아웃바운드 허용 여부
  3. 보안 그룹 아웃바운드 규칙

---

📘 Q385 문제 정리

✅ 문제 요약

• 회사는 내부 데이터를 Amazon S3 버킷에 저장 중.
• 모든 기존 데이터는 **SSE-S3 (Amazon 관리형 암호화 키)**로 암호화됨.
• S3 버전 관리 활성화 상태.
• SysOps 관리자는 재해 복구를 위해 데이터를 다른 AWS 계정의 S3 버킷으로 복제해야 함.
• 모든 기존 데이터는 소스 버킷에서 대상 버킷으로 복제되어야 함.

---

✅ 정답

A. 원본 버킷에 복제 규칙을 추가하고 대상 버킷을 지정한다.

• 원본 버킷 소유자가 객체를 복제할 수 있도록 대상 버킷에 버킷 정책을 설정해야 한다.
• 즉, **Cross-Account S3 Replication (CRR)**을 설정하는 방식이 가장 효율적이다.

---

❌ 오답 보기 분석

• B. EventBridge + AWS Batch
  → 이벤트 기반의 배치 작업은 가능하지만, S3 데이터 전체 복제를 위해 설계된 최적화 방법이 아님.
• C. S3 이벤트 알림 + Lambda
  → 신규 객체 업로드 시에는 유효하지만, 기존 객체 전체 복제를 처리하지 못함.
• D. EC2에서 스크립트 실행
  → 가능은 하지만 비효율적이고 운영 비용이 크며, 관리 복잡성이 증가.

---

📊 해설

• S3 Cross-Region Replication(CRR) / Cross-Account Replication을 사용하면:
  • 다른 AWS 계정 또는 리전에 데이터를 자동 복제 가능
  • 기존 객체와 신규 객체 모두 복제 가능 (옵션 설정)
  • 버전 관리가 활성화되어 있어 데이터 무결성 보장

---

📝 정리 포인트

• S3 복제 최적화 방법: 버킷 복제 규칙(Replication Rule) + 대상 버킷 정책 설정
• Lambda/EC2/Batch 활용 방법: 유연하지만, 대량 데이터 복제에는 비효율적
• 시험 포인트: 운영 효율성과 AWS 관리형 기능 활용 → S3 Replication

---

📘 Q387 문제 정리

✅ 문제 요약

• 현재 Auto Scaling 그룹에는 10개의 온디맨드(OD) EC2 인스턴스가 있음.
• 서비스 요구사항: 최소 6개의 인스턴스가 항상 필요.
• 목표: 가장 비용 효율적으로 애플리케이션 가동 시간을 유지해야 함.

---

✅ 정답

A. 6개 인스턴스의 온디맨드 용량을 갖춘 스팟 집합을 사용한다.

• 최소 요구 용량(6개)은 온디맨드 인스턴스로 유지 → 안정성 보장.
• 나머지 4개는 스팟 인스턴스로 구성 → 비용 절감 효과.
• AWS Auto Scaling의 **혼합 인스턴스 정책(Mixed Instances Policy)**을 활용.

---

❌ 오답 보기 분석

• B. 최소 6개~최대 10개 온디맨드만 사용
  → 안정적이지만 비용 효율성이 낮음. 비용 최적화 X.
• C. 최소 1개~최대 6개 온디맨드만 사용
  → 최소 요구사항(6개)을 충족하지 못할 가능성이 있음. 가용성 리스크.
• D. 목표 용량 6개를 스팟으로만 운영
  → 스팟은 예측 불가능하게 회수될 수 있음. 안정성 부족.

---

📊 해설

• Auto Scaling 그룹에서 비용 최적화의 핵심:
  • 최소 안정성 → 온디맨드 인스턴스
  • 추가 확장/변동 부분 → 스팟 인스턴스
• 따라서 "6개 온디맨드 + 나머지는 스팟" 구성이 가장 안정적이면서 비용 최적화 가능.

---

📝 정리 포인트

• 시험 포인트:
  • 온디맨드는 안정성
  • 스팟은 비용 절감
  • 혼합해서 쓰는 Mixed Instances Policy가 정답

---

📘 Q400 문제 정리

✅ 문제 요약

• 환경: PostgreSQL Multi-AZ RDS 인스턴스 (CloudFormation으로 배포, 초기 크기 100GB).
• 상황:
  • 매주 월요일 DB 생성 → 금요일 삭제.
  • 시간이 지나면 디스크 공간 부족 → CloudWatch 경보 발생.
• 요구사항:
  • 애플리케이션 변경 최소화.
  • 디스크 공간 부족을 예방할 자동화된 방법 필요.

---

✅ 정답

C. CloudFormation 템플릿을 수정하여 기존 DB 인스턴스에서 스토리지 Auto Scaling을 활성화한다.

• RDS Storage Auto Scaling을 사용하면 스토리지가 부족할 때 자동으로 크기를 확장.
• 기존 인프라/애플리케이션 변경을 최소화하면서 문제 해결 가능.

---

❌ 오답 보기 분석

• A. Aurora PostgreSQL로 전환
  → DB 엔진 변경은 애플리케이션 수정 필요. 요구 조건 불만족.
• B. DynamoDB로 전환
  → 관계형 데이터베이스에서 NoSQL로 바꾸는 것은 아키텍처 자체 변경. 요구 조건 불만족.
• D. CloudWatch 경보 + VACUUM 명령
  → 모니터링은 가능하지만 자동 확장 불가. 여전히 수동 관리 필요.

---

📊 해설

• RDS의 Storage Auto Scaling은 CloudFormation에서 바로 활성화 가능.
• 스토리지 부족 문제를 해결하면서, 기존 워크로드와 코드 변경 최소화.
• 즉, 가장 적은 변경으로 안정적 확장 가능 → C 선택.

---

📝 정리 포인트

• 시험 포인트:
  • Storage Auto Scaling → RDS의 자동 디스크 확장 기능.
  • "최소 변경, 최대 효과" → 엔진 교체/아키텍처 변경은 정답이 아님.

---

📘Q414 문제 정리

✅ 문제 요약

• 회사는 50개의 AWS 계정을 운영 중.
• 각 계정에서 동일한 Amazon VPC를 생성해야 함.
• 향후 변경 사항도 모든 계정의 VPC에 일괄 반영해야 함.
• 요구사항: 운영상 가장 효율적인 방법으로 모든 계정에 VPC 배포 & 업데이트.

---

✅ 정답

D. VPC를 정의하는 AWS CloudFormation 템플릿을 생성하고, 이를 기반으로 AWS CloudFormation StackSet을 사용하여 모든 계정에 배포.

• CloudFormation StackSets는 여러 계정 및 리전에 동시에 인프라 배포 가능.
• 변경 시 템플릿 수정 → 전체 계정에 자동 반영.
• 대규모 멀티계정 환경(50개 계정)에 가장 적합하고 운영 효율성이 높음.

---

❌ 오답 보기 분석

• A. CloudFormation 템플릿 + 수동 로그인 배포
  → 각 계정에 일일이 들어가서 배포해야 하므로 운영상 비효율적.
• B. AWS CLI 스크립트로 계정별 실행
  → 스크립트 관리 & 실행이 복잡하고, 50개 계정에 적용 시 운영상 위험이 큼.
• C. DynamoDB + Lambda 기반 VPStore 구현
  → 복잡하고 불필요한 커스텀 설계. AWS가 제공하는 StackSets 기능이 이미 최적화되어 있음.

---

📊 해설

• 시험 포인트:
  • "여러 계정에 공통 인프라 배포" = CloudFormation StackSets 정답 패턴.
  • 멀티계정, 멀티리전 관리 → StackSets는 AWS Organizations와 통합되어 중앙 제어 가능.

---

📝 정리 포인트

• CloudFormation 템플릿: 리소스 정의 (VPC, Subnet 등).
• CloudFormation StackSets: 템플릿을 여러 계정/리전에 한 번에 배포.
• 장점: 일관성, 자동화, 변경 시 전체 계정에 쉽게 반영.

 

---

📘 Q427 문제 정리

✅ 문제 요약

• 회사는 프랑스 리전에 전자상거래 애플리케이션을 배포.
• 현재 요구: 프랑스 사용자만 첫 번째 버전에 접근 가능해야 함.
• 향후: 더 많은 국가를 추가할 예정.
• SysOps 관리자가 Amazon Route 53 라우팅 정책을 구성해야 함.

---

✅ 정답

B. 지리적 위치 라우팅 정책(Geolocation Routing Policy)을 사용하고, 기록의 위치로 프랑스를 선택한다.

• Geolocation Routing: 사용자의 국가/지역 기반으로 트래픽을 라우팅.
• "프랑스 사용자만 접속 허용" 조건을 충족.
• 이후 다른 국가 추가 시, 동일 방식으로 손쉽게 확장 가능.

---

❌ 오답 분석

• A. 지리 근접 라우팅 (Geoproximity Routing)
  → 리소스 위치와 사용자 위치의 가까운 정도(근접성) 를 기준으로 라우팅.
  → 특정 국가 사용자만 제한하는 데 적합하지 않음.
• C. IP 기반 라우팅 정책
  → Route 53에서는 기본적으로 IP 기반 직접 매핑 정책이 없음.
  → CloudFront + WAF 같은 서비스에서 IP 기반 차단/허용은 가능하지만, 문제의 답은 아님.
• D. 지리 근접 라우팅 + IP 주소 지정
  → 특정 국가 사용자만 제한하려면 복잡하고 부정확한 방식.
  → 관리 효율성 떨어짐.

---

📊 핵심 포인트

• Geolocation Routing → 국가 단위 사용자 접근 제한.
• Geoproximity Routing → 지리적 거리 기반 분산.
• 시험에서는 “특정 국가만 접근 허용” = Geolocation 정답 패턴.

---

📘 오답노트 - Q429

✅ 문제 요약

• 회사는 AWS Organizations 를 사용해 여러 AWS 계정을 관리.
• 사용자 계정 및 권한을 중앙에서 관리해야 함.
• 기존에는 온프레미스 Active Directory(AD) 를 사용 중.
• 이미 AWS IAM Identity Center(구 SSO) 와 AWS Direct Connect 가 설정된 상태.
• 목표: 온프레미스 AD와 AWS IAM Identity Center 연동 → 계정/권한 통합 관리.

---

✅ 정답

C. 온프레미스 Active Directory 도메인과 연결된 AD 커넥터를 생성하고, 이를 IAM Identity Center의 ID 소스로 설정한다.

• AD Connector = 온프레미스 AD ↔ AWS IAM Identity Center 브리지
• AWS 계정 접근 시 온프레미스 AD 자격 증명 그대로 사용 가능
• 사용자 및 그룹 복제 불필요 → 관리 효율 ↑
• Direct Connect 이미 연결되어 있어 네트워크 레이턴시/보안 문제도 해결됨

---

❌ 오답 분석

• A. Simple AD + Trust 관계
  • Simple AD는 제한적 기능만 제공.
  • 온프레미스 AD와 완전 통합 불가.
• B. EC2 기반 AD 도메인 컨트롤러
  • AWS 내에서 AD 직접 운영해야 하므로 관리 부담 ↑
  • 온프레미스 AD와 이중 관리 문제 발생.
• D. 내장 SSO 디렉터리 사용
  • 온프레미스 AD와 직접 연동 불가.
  • 사용자/그룹을 별도로 복제해야 해서 비효율적.

---

📊 핵심 포인트

• 시험 패턴: “온프레미스 AD를 AWS 인증/권한 관리에 활용” → 정답은 AD Connector
• IAM Identity Center + AD Connector 조합 = 가장 운영 효율적이고 권장되는 방식

---

📌 다이어그램으로 정리하면 이렇게 표현할 수 있습니다:

 

```mermaid
flowchart TD
    AD["온프레미스 Active Directory"]
    Connector["AD Connector (AWS)"]
    IAMC["AWS IAM Identity Center"]
    Orgs["AWS Organizations (계정)"]
    Users["사용자 계정/권한 중앙 관리"]

    AD --> Connector
    Connector --> IAMC
    IAMC --> Orgs
    Orgs --> Users
```

 

 

---

👉 이 문제는 “기존 온프레미스 AD 연동 → AD Connector” 패턴을 반드시 기억하면 풀 수 있습니다.