📘 오답노트 - Q342

❓ 문제 요약

• 회사는 EC2에서 HPC(고성능 컴퓨팅) 애플리케이션을 실행 중.
• 두 개 이상의 EC2 인스턴스를 확장해야 함.
• HPC 특성상 짧은 지연 시간, 빠른 속도로 인스턴스 간 통신 필요.
• SysOps 관리자가 해야 할 일은?

✅ 정답

A. 클러스터 배치 그룹을 생성하고 EC2 인스턴스를 AMI로 복원하여 그룹에서 시작

• 클러스터 배치 그룹(Cluster Placement Group) 은 HPC 워크로드처럼 인스턴스 간의 저지연, 고대역폭 통신을 제공.
• 같은 가용 영역(AZ)에 인스턴스를 밀집 배치하여 네트워크 성능 극대화.
• 따라서 HPC 애플리케이션 요구사항을 충족하는 유일한 해답.

❌ 오답 해설

• B. AMI 생성 후 Auto Scaling
  → Auto Scaling은 가용성/확장성에는 좋지만, 저지연 통신 보장은 불가. HPC 환경 요구사항을 충족하지 못함.
• C. NLB 사용
  → 로드 밸런서는 외부 트래픽 분산용이지, 인스턴스 간 내부 통신 최적화와는 무관.
• D. 동일 AZ 내 복제본 생성
  → 단순히 같은 AZ 내에 있어도 저지연 고속 네트워킹이 보장되지 않음. 반드시 배치 그룹 필요.

📊 비교 표

📊 HPC 인스턴스 배치 구조 (Mermaid)

```mermaid
graph TD
    subgraph AZ1["🏢 가용 영역: AZ1"]
        EC2A["💻 EC2 인스턴스 A"]
        EC2B["💻 EC2 인스턴스 B"]
        EC2C["💻 EC2 인스턴스 C"]
    end

    EC2A <--> EC2B
    EC2B <--> EC2C
    EC2A <--> EC2C

    AZ1 -.-> Note["⚡ 클러스터 배치 그룹: 저지연 + 고대역폭 네트워킹"]

```

📊 결과 설명

• 🏢 AZ1 내부에 💻 EC2 인스턴스 A, B, C 존재
• 모든 인스턴스 간에 양방향 네트워크 연결 (<-->)
• 점선으로 연결된 설명 노드: ⚡ 클러스터 배치 그룹 (저지연 + 고대역폭)

🎯 핵심 개념 정리

• HPC(고성능 컴퓨팅) 워크로드는 인스턴스 간 통신 지연 최소화가 핵심.
• 일반적인 Auto Scaling, NLB, 단순 복제본으로는 해결 불가.
• 해결책 = 클러스터 배치 그룹(Cluster Placement Group).

👉 Q342의 포인트는 HPC = Placement Group (Cluster) 이라는 연관성을 기억하는 것입니다.

📘 오답노트 - Q344

❓ 문제 요약

• 회사는 us-west-2 리전 ALB 뒤 애플리케이션을 운영 중.
• Route 53 레코드는 app.anycompany.com → us-west-2 ALB.
• 최근 ap-southeast-2 리전 사용자 증가 → 지연 시간(latency) 문제 발생.
• 애플리케이션 사본을 ap-southeast-2에도 배포.
• 목표: URL 변경 없이 가장 낮은 대기 시간의 엔드포인트로 라우팅.

✅ 정답

C. 대기 시간 라우팅 정책(Latency Routing Policy)을 사용하도록 기존 별칭 레코드 변경

• Route 53의 Latency-based Routing은 사용자 요청을 지연 시간이 가장 짧은 리전의 리소스로 라우팅.
• 즉, 미국 사용자 → us-west-2, 호주/뉴질랜드 사용자 → ap-southeast-2.
• URL은 그대로 유지되면서 지리적으로 최적화된 접근이 가능.

❌ 오답 해설

• A. ap-southeast-2 ALB DNS 이름을 기존 레코드에 추가
  → 단순히 ALB DNS 이름을 추가하면 라운드 로빈처럼 작동. 지연 시간 기반 분산이 아님.
• B. 지리적 위치 라우팅 정책
  → 특정 국가/지역 기반으로만 라우팅. "지연 시간 최적화" 목적에는 맞지 않음.
• D. 다중값 라우팅 정책(Multi-Value Answer)
  → 여러 ALB DNS를 반환 → 클라이언트 단에서 무작위 선택. 지연 시간 보장은 없음.

📊 비교 표

🌏 Route 53 Latency Routing 동작 구조 (Mermaid)

 

```mermaid
graph TD
    User1["👤 사용자: 미국 서부"] --> Route53["🌐 Amazon Route 53"]
    User2["👤 사용자: 호주"] --> Route53

    Route53 -->|"⚡ 낮은 지연 시간 선택"| ALB_US["⚖️ ALB: us-west-2"]
    Route53 -->|"⚡ 낮은 지연 시간 선택"| ALB_AUS["⚖️ ALB: ap-southeast-2"]
```

📊 결과 설명

• 👤 미국 서부 사용자, 👤 호주 사용자
  → 🌐 Route 53 으로 DNS 요청 전달
• Route 53은 ⚡ 지연 시간이 낮은 리전 선택
  • 미국 서부 → ⚖️ ALB (us-west-2)
  • 호주 → ⚖️ ALB (ap-southeast-2)

🎯 핵심 개념 정리

• Latency Routing Policy = "가장 가까운(지연 낮은) 리전"으로 트래픽 라우팅.
• 지리적 라우팅(Geolocation)과는 구별해야 함.
• 멀티 리전 애플리케이션 배포 시 가장 자주 쓰이는 정책.

👉 Q344 핵심 포인트는 멀티 리전 사용자 지연 시간 문제 = Route 53 Latency-based Routing이라는 점입니다.

📘 오답노트 - Q345

❓ 문제 요약

• 회사는 동일한 리전에 50개의 Amazon S3 버킷을 보유.
• Amazon EC2 인스턴스가 프라이빗 연결을 통해 S3 버킷과 안전하게 통신해야 함.
• 조건: 추가 비용이 없는 솔루션 필요.

✅ 정답

C. 모든 S3 버킷에 대해 하나의 게이트웨이 VPC 엔드포인트 생성 후 라우팅 테이블에 추가

• S3용 VPC Gateway Endpoint는 무료로 제공됨.
• 단일 엔드포인트로 리전 내 모든 S3 버킷에 접근 가능.
• 라우팅 테이블에 엔드포인트를 추가하면 EC2 → S3 트래픽이 프라이빗 네트워크 내부에서 안전하게 이동.

❌ 오답 해설

• A. 각 S3 버킷마다 개별 VPC Gateway Endpoint 생성
  → 엔드포인트는 S3 전체 서비스 단위로 동작. 버킷별 생성 불필요 + 관리 복잡도 증가.
• B. 각 S3 버킷마다 Interface Endpoint 생성
  → S3는 Interface Endpoint 대신 Gateway Endpoint가 권장됨. 또한 Interface Endpoint는 비용 발생.
• D. 모든 버킷에 대해 단일 Interface Endpoint 생성
  → 가능하나 비용 발생. 문제 조건(“추가 비용 없음”) 위배.

📊 비교 표

🌐 VPC Endpoint 구조 (Mermaid)

```mermaid
graph TD
    EC2["💻 Amazon EC2 인스턴스"] --> VPC_GW["🔗 VPC Gateway Endpoint"]
    VPC_GW --> S3["📦 Amazon S3: 리전 내 모든 버킷"]

    VPC_GW -.-> Note["🔒 트래픽은 인터넷을 거치지 않고 VPC 내부에서 안전하게 전송됨"]

```

📊 결과 설명

• 💻 EC2 인스턴스 → 🔗 VPC Gateway Endpoint → 📦 Amazon S3
• 데이터 전송 시 🔒 인터넷을 거치지 않고 VPC 내부에서 안전하게 처리됨
• 점선 화살표로 보안 관련 부가 설명 강조

🎯 핵심 개념 정리

• VPC Endpoint 종류
  • Gateway Endpoint: S3, DynamoDB 전용 / 무료 / 라우팅 테이블 기반.
  • Interface Endpoint: ENI(Elastic Network Interface) 방식 / 대부분의 AWS 서비스 / 비용 발생.
• 문제 조건 "추가 비용 없음" = Gateway Endpoint 선택이 정답.

👉 Q345 핵심 포인트는 S3와 DynamoDB는 Gateway VPC Endpoint라는 점을 기억하는 것입니다.

📘 오답노트 - Q355

❓ 문제 요약

• 회사는 다수의 Amazon EC2 인스턴스에서 애플리케이션 실행 중.
• 요구사항: EC2 인스턴스 상태 변경(Event) 발생 시 운영팀에게 알림 제공.
• 조건: 가장 운영 효율적인 방법 선택.

✅ 정답

B. EC2 인스턴스 상태 변경을 캡처하는 Amazon EventBridge 규칙 생성 후 SNS 주제를 대상으로 설정

• Amazon EventBridge는 AWS 리소스 이벤트(예: EC2 상태 변경)를 자동으로 캡처.
• 이벤트를 Amazon SNS 주제로 전달하면 운영팀에 이메일/메시지 알림 전송 가능.
• 서버리스 + 자동화로 별도의 스크립트나 관리 부담 없음.

❌ 오답 해설

• A. 스크립트 + SNS
  → 수동적인 방식이며 EC2 전체에 스크립트를 설치해야 하므로 운영 오버헤드 증가.
• C. EventBridge + SNS + Lambda
  → 동작은 가능하나, 단순 알림만 필요할 때 Lambda는 불필요한 복잡성.
• D. AWS Config + Lambda + SNS
  → Config는 리소스 규정 준수/구성 변경 감시용. 단순 EC2 상태 변경 알림에는 과도한 솔루션.

📊 비교 표

🌐 이벤트 흐름도 (Mermaid)

 

```mermaid
flowchart TD
    EC2["💻 EC2 인스턴스: 상태 변경"] --> EventBridge["🪢 Amazon EventBridge"]
    EventBridge --> SNS["📨 Amazon SNS: 주제"]
    SNS --> OpsTeam["👨‍💻 운영팀 알림: Email / SMS"]

```

 

📊 결과 설명

• 💻 EC2 인스턴스 상태 변경 이벤트 발생
• → 🪢 EventBridge 가 이벤트를 감지 및 전달
• → 📨 SNS 주제로 게시
• → 👨‍💻 운영팀이 Email / SMS로 알림 수신

🎯 핵심 개념 정리

• Amazon EventBridge = AWS 이벤트 버스, 리소스 상태 변경 자동 캡처.
• Amazon SNS = 메시지 브로커 서비스, 운영팀 알림 발송.
• 조합하면 "상태 변경 → 자동 알림" 시나리오를 가장 단순하고 효율적으로 구현 가능.

👉 Q355의 핵심은 **"EC2 상태 변경 알림은 EventBridge + SNS 조합이 정석"**이라는 점입니다.

📘 오답노트 - Q361

❓ 문제 요약

• 환경: ALB 뒤 Amazon EC2 (Auto Scaling 그룹)에서 웹 애플리케이션 실행 중.
• 상황: 의심스러운 트래픽이 단일 공용 IP에서 발생.
• 요구사항: SysOps 관리자는 해당 공용 IP 주소를 차단해야 함.

✅ 정답

D. AWS WAF에 설정된 IPSet에 악성 IP 주소를 추가하고, Web ACL을 ALB에 연결하여 차단

• AWS WAF는 웹 애플리케이션 방화벽으로, IP 차단 규칙을 Web ACL에 정의 가능.
• IPSet을 만들어 차단할 IP 주소를 등록.
• Web ACL을 ALB에 연결 → 해당 IP에서 오는 요청 자동 BLOCK.
• 가장 효율적이고 운영 표준에 부합하는 방법.

❌ 오답 해설

• A. 보안 그룹 규칙으로 IP 차단
  → 보안 그룹은 L4 수준(인스턴스 레벨) 트래픽 제어 가능.
  하지만 ALB 뒤에 여러 EC2 인스턴스가 Auto Scaling으로 운영되면 개별 인스턴스 제어는 비효율적.
• B. Amazon Detective 사용
  → Detective는 보안 조사 및 포렌식 분석 도구.
  트래픽 차단 기능은 없음.
• C. AWS RAM (Resource Access Manager)
  → 리소스 공유 서비스.
  보안 제어나 IP 차단과는 무관.

📊 비교 표

🌐 동작 흐름 (Mermaid)

 

```mermaid
flowchart TD
    Attacker["🚨 악성 IP 트래픽"] --> ALB["⚖️ Application Load Balancer"]
    ALB --> WAF["🛡️ AWS WAF: Web ACL"]

    WAF -->|"⛔ 차단 규칙 적용"| Blocked["❌ 요청 거부"]
    WAF -->|"✅ 정상 요청"| EC2["💻 Amazon EC2 Auto Scaling 그룹"]
```

 

📊 결과 설명

• 🚨 악성 IP 트래픽 → ⚖️ ALB → 🛡️ WAF
• WAF에서
  • ⛔ 차단 규칙이 적용되면 → ❌ 요청 거부
  • ✅ 정상 요청이면 → 💻 EC2 Auto Scaling 그룹 으로 전달

🎯 핵심 개념 정리

• 보안 그룹: 인스턴스 레벨 제어 (IP 기반 차단은 가능하나 ALB 레벨에서는 비효율).
• NACL: 서브넷 레벨 제어, 범위가 넓음 → 세밀한 ALB 트래픽 제어에는 불리.
• AWS WAF: ALB, API Gateway, CloudFront 앞단에서 애플리케이션 계층 보안 담당.
• 따라서 "공용 IP 차단"은 WAF + Web ACL이 정답.

👉 Q361 핵심은 “IP 기반 차단은 WAF의 Web ACL을 ALB에 연결하는 것이 최적” 이라는 점이에요.

📘 오답노트 - Q363

❓ 문제 요약

• 회사는 두 개의 애플리케이션을 연결해야 함.
  • 온프레미스: host1.onprem.private
  • AWS: host1.awscloud.private (EC2 인스턴스에서 실행)
• 온프레미스 ↔ AWS 연결: Site-to-Site VPN.
• 문제: 온프레미스 앱이 EC2 앱에 연결 시 DNS 확인 실패 발생.
• 요구사항: 온프레미스와 AWS 리소스 간 DNS 확인 가능해야 함.

✅ 정답

B. Amazon Route 53 인바운드 확인자 엔드포인트를 설정하고, 온프레미스 DNS 확인자와 연결

• Route 53 Resolver 인바운드 엔드포인트: 온프레미스에서 들어오는 DNS 쿼리를 VPC로 전달.
• 온프레미스 DNS 서버가 AWS 내 **사설 호스트 존(private hosted zone)**을 조회할 수 있음.
• 이렇게 하면 awscloud.private DNS를 온프레미스 애플리케이션이 정상적으로 확인 가능.

❌ 오답 해설

• A. Route 53 인바운드 확인자 + VPC 연결
  → "onprem.private" 도메인은 온프레미스 DNS에서 관리되므로, 인바운드 엔드포인트만으로는 해결 안 됨.
• C. Route 53 아웃바운드 확인자
  → 아웃바운드 엔드포인트는 AWS → 온프레미스 DNS 쿼리 전달 용도.
  문제는 반대(온프레미스 → AWS)라서 부적절.
• D. Route 53 아웃바운드 확인자 + 온프레미스 DNS 확인자
  → AWS에서 온프레미스 DNS로 쿼리 전달할 때 사용.
  여기서는 온프레미스가 AWS 도메인을 확인해야 하므로 맞지 않음.

📊 비교 표

🌐 동작 흐름 (Mermaid)

 

```mermaid
flowchart TD
    OnPremApp["🏢 온프레미스 앱"] --> OnPremDNS["🖥️ 온프레미스 DNS"]
    OnPremDNS --> Inbound["🔗 Route 53 인바운드 엔드포인트"]
    Inbound --> VPCDNS["📦 VPC DNS: awscloud.private"]
    VPCDNS --> EC2["💻 Amazon EC2 애플리케이션"]
```

 

📊 결과 설명

• 🏢 온프레미스 앱 → 🖥️ 온프레미스 DNS 쿼리 발생
• 🔗 Route 53 인바운드 엔드포인트가 VPC 내부로 전달
• 📦 VPC DNS (awscloud.private) 에서 이름 해석 수행
• 결과적으로 💻 EC2 애플리케이션에 연결됨

🎯 핵심 개념 정리

• Route 53 Resolver 인바운드 엔드포인트: 온프레미스 → AWS DNS 요청 처리.
• Route 53 Resolver 아웃바운드 엔드포인트: AWS → 온프레미스 DNS 요청 처리.
• 문제 상황은 온프레미스 → AWS 방향 DNS 조회 실패 → 따라서 인바운드 엔드포인트 필요.

👉 Q363 핵심은 “온프레미스에서 AWS 사설 도메인을 확인해야 할 때는 Route 53 인바운드 엔드포인트” 라는 점이에요.

📘 오답노트 - Q381

❓ 문제 요약

• 모든 EC2 인스턴스에 사용자 지정 애플리케이션을 설치해야 함.
• 애플리케이션은 크기가 작고, 자주 업데이트, 자동 설치가 필요.
• 질문: 새로운 EC2 인스턴스에 어떻게 애플리케이션을 배포할 수 있는가?

✅ 정답

A. EC2 사용자 데이터(User Data) 스크립트를 사용

• EC2 인스턴스 시작 시 User Data에 스크립트를 지정하면,
  → 인스턴스 부팅 시 자동으로 실행됨.
• 여기서 설치 스크립트를 작성해두면 애플리케이션 자동 다운로드 & 설치 가능.
• 경량 애플리케이션, 자주 업데이트되는 경우 최적.

❌ 오답 해설

• B. API Gateway + CloudFormation
  → API Gateway는 API 호출용 서비스, 앱 배포와 직접적 관계 없음.
• C. AMI에 주입
  → AMI(Custom Image) 방식은 애플리케이션 변경이 적고 업데이트가 드문 경우 적합.
  → 문제에서 요구한 "자주 업데이트"와 맞지 않음.
• D. CodePipeline
  → CI/CD 배포 자동화는 가능하지만, 작고 단순한 앱 배포에 비해 오버엔지니어링.
  → 유지보수 비용이 불필요하게 커짐.

📊 비교 요약

🌐 동작 흐름 (Mermaid)

 

```mermaid
flowchart TD
    Launch["🚀 EC2 인스턴스 시작"] --> UserData["📜 User Data 스크립트 실행"]
    UserData --> Install["⬇️ 애플리케이션 다운로드 및 설치"]
    Install --> Ready["✅ 애플리케이션 준비 완료 🎉"]
```

 

📊 결과 설명

• 🚀 EC2 인스턴스 시작 → 부팅 시
• 📜 User Data 스크립트 실행 → 초기화 과정
• ⬇️ 애플리케이션 다운로드 및 설치 → 자동 설치 수행
• 마지막에 ✅ 애플리케이션 준비 완료 🎉 → 서비스 시작 가능 상태

🎯 핵심 정리

• User Data = EC2 초기 부팅 시 실행되는 스크립트.
• 반복적이고 작은 규모의 애플리케이션 설치/업데이트에 적합.
• 반면, AMI는 업데이트 적고 안정적인 앱에 적합, CodePipeline은 대규모 CI/CD 환경에서 적합.

👉 제가 보기엔 Q381은 Q327 (Lambda + NAT 게이트웨이), Q356 (고정 IP + Route 53) 같은 문제랑 묶어서
"최소 노력 & 단순 자동화 방식" 주제로 한 번에 정리해두면 외우기 쉽습니다.

📘 오답노트 - Q157

❓ 문제 요약

• 회사는 2개의 가용 영역에 걸친 ALB 뒤 EC2 인스턴스에서 웹 애플리케이션 운영.
• 정적 콘텐츠는 Amazon S3 버킷에서 제공.
• 사용자는 페이지 로딩 시간이 길다고 보고.
• 목표: 웹사이트 성능 개선.

✅ 정답

A, D

1. A. 정적 콘텐츠에 대해 Amazon CloudFront 캐싱 추가
   • 정적 콘텐츠(S3 제공)를 CloudFront 글로벌 캐싱을 통해 사용자 가까운 엣지 로케이션에서 제공.
   • 네트워크 지연(latency)을 줄여 로딩 속도 향상.
2. D. 웹 서버용 Amazon EC2 Auto Scaling 구현
   • 동적 콘텐츠는 ALB 뒤 EC2 인스턴스에서 처리.
   • 트래픽 급증 시 Auto Scaling이 서버 인스턴스를 자동으로 확장하여 성능 저하 방지.

❌ 오답 해설

• B. 로드 밸런서 리스너를 HTTPS에서 TCP로 변경
  → HTTPS는 보안 트래픽을 위한 표준 프로토콜이며, TCP로 바꾼다고 성능이 개선되지 않음.
• C. Route 53 지연 시간 기반 라우팅 활성화
  → 이미 ALB + S3 기반 아키텍처에서는 지연 시간 라우팅이 아닌 캐싱 및 Auto Scaling이 더 효과적.
• E. 정적 콘텐츠를 웹 서버로 이동
  → 오히려 성능 저하 유발. 정적 콘텐츠는 S3 + CloudFront로 제공하는 것이 최적.

📊 흐름도 (Mermaid 다이어그램)

```mermaid
flowchart TD
    User["🌍 사용자"] --> CF["🌐 Amazon CloudFront: 캐싱"]
    CF --> S3["📦 Amazon S3: 정적 콘텐츠"]

    User["🌍 사용자"] --> ALB["⚖️ Application Load Balancer"]
    ALB --> EC2["💻 Amazon EC2: 동적 콘텐츠"]
    EC2 --> ASG["📈 Auto Scaling: 트래픽 증가 시 인스턴스 확장"]
```

📊 결과 설명

• 🌍 사용자 요청
  • → 🌐 CloudFront 를 거쳐 📦 S3 정적 콘텐츠 제공
  • → 또는 ⚖️ ALB 로 라우팅되어 💻 EC2 동적 콘텐츠 처리
• 📈 Auto Scaling 이 트래픽 증가 시 EC2 인스턴스를 자동 확장

🎯 핵심 개념 정리

• CloudFront + S3: 전 세계 엣지 로케이션에서 정적 콘텐츠 캐싱 제공 → 로딩 시간 단축.
• Auto Scaling + ALB + EC2: 동적 콘텐츠 트래픽 급증 시 자동 확장으로 안정적 성능 보장.
• 웹 성능 개선 시 정적 콘텐츠는 CDN, 동적 콘텐츠는 Auto Scaling이 핵심.

📘 오답노트 - Q162

❓ 문제 요약

• 회사는 Oracle DB 인스턴스용 Amazon RDS를 사용 중.
• 다른 AWS 리전에 정기적인 백업을 제공하려고 함.
• 목표: 가장 운영상 효율적인 백업 솔루션 찾기.

✅ 정답

A. DB 인스턴스를 수정하고 지역 간 자동 백업 활성화

• Amazon RDS는 자동 백업(Auto Backup) 기능 제공.
• 지역 간 복제를 지원하여 별도의 수동 작업 없이 다른 리전에 정기적 백업 자동 전송 가능.
• 관리 오버헤드 최소화, 운영 효율성 극대화.

❌ 오답 해설

• B. 다른 리전에 RDS 읽기 전용 복제본 생성 후 스냅샷
  → 읽기 전용 복제본은 고가용성과 장애 조치 목적이지, 정기적 백업 솔루션으로는 비효율적.
• C. AWS DMS(AWS Database Migration Service) 사용
  → DMS는 데이터 마이그레이션/변환 목적이지, 단순 주기적 백업에는 불필요하게 복잡하고 비용 비효율적.
• D. 암호화 해제 후 스냅샷 복사
  → 보안 취약점을 초래하며, 암호화를 해제하는 것은 올바른 솔루션이 아님.

📊 흐름도 (Mermaid 다이어그램)

```mermaid
flowchart TD
    RDS["🗄️ Amazon RDS: Oracle DB"] --> AutoB["⚙️ 자동 백업 활성화"]
    AutoB --> Backup["💾 백업 스냅샷 저장"]
    Backup --> CrossRegion["🌍 다른 AWS 리전으로 자동 복제"]
    CrossRegion --> Admin["👨‍💻 관리자: 복구 시 활용"]
```

📊 결과 설명

• 🗄️ Amazon RDS (Oracle DB) 에서
  → ⚙️ 자동 백업 활성화
  → 💾 백업 스냅샷 저장
  → 🌍 다른 리전으로 자동 복제
  → 👨‍💻 관리자가 복구 시 활용
• 한눈에 백업 → 복제 → 복구 흐름을 직관적으로 이해할 수 있음.

🎯 핵심 개념 정리

• RDS의 자동 백업 + 교차 리전 복제(Cross-Region Backup) 기능이 가장 효율적.
• 운영자가 직접 스냅샷 찍고 복사하는 방식(D)은 비효율적이고 보안 문제 유발.
• 읽기 전용 복제본(B)이나 DMS(C)는 백업 목적에는 맞지 않음.

📘 오답노트 - Q165

❓ 문제 요약

• SysOps 관리자가 AWS Lambda 함수 실행을 자동화해야 함.
• 매일 업무 종료 시, Amazon S3 버킷에 저장된 데이터를 기반으로 보고서 생성 필요.
• 요구 사항: 가장 운영 효율적인 방법.

✅ 정답

B. 일정과 Lambda 함수를 대상으로 하는 Amazon EventBridge 규칙 생성

• EventBridge(구 CloudWatch Events)를 사용하면 **일정 기반(cron/매일 특정 시간)**으로 Lambda를 자동 실행 가능.
• 운영자가 직접 개입하지 않아도 매일 업무 종료 시 보고서 생성 가능.
• 서버리스 방식이므로 비용 효율적이며 관리 오버헤드 최소화.

❌ 오답 해설

• A. S3 이벤트 패턴 기반 Lambda 실행
  → 이는 객체 업로드/변경 시 실행되는 트리거로, "매일 업무 종료 시"라는 일정 기반 조건에 맞지 않음.
• C. S3 객체 변경 이벤트 시 Lambda 실행
  → 마찬가지로, "객체 변경" 이벤트 기반이므로 일정 실행 요구 조건과 맞지 않음.
• D. cron 작업을 통한 EC2 기반 Lambda 실행
  → EC2에 cron 스케줄러를 두는 방식은 관리 오버헤드와 비용이 크며, **서버리스 자동화(EventBridge)**보다 비효율적.

📊 흐름도 (Mermaid 다이어그램)

```mermaid
flowchart TD
    Schedule["⏰ EventBridge 스케줄: 매일 18시"] --> Lambda["🟦 AWS Lambda: 함수 실행"]
    Lambda --> S3["📦 Amazon S3: 데이터 처리"]
    S3 --> Report["📊 보고서 생성"]

```

📊 결과 설명

• ⏰ EventBridge 스케줄: 매일 18시에 이벤트 발생
• 🟦 Lambda 함수: 자동 실행되어 데이터 처리 로직 수행
• 📦 S3: 처리된 데이터를 저장 및 관리
• 📊 보고서 생성: 최종 산출물

🎯 핵심 개념 정리

• S3 이벤트 트리거(A, C) = 객체 생성/변경 시 실행 (❌ 일정 기반 아님)
• EC2 cron(D) = 불필요한 리소스 관리 + 비용 증가 (❌ 서버리스 철학 위배)
• EventBridge 일정(B) = Lambda를 매일 정해진 시간에 실행 가능 (✅ 정답)

👉 Q165의 핵심은 스케줄 기반 자동화는 EventBridge라는 점이에요.

📘 오답노트 - Q170

❓ 문제 요약

• 회사는 단일 Amazon EC2 인스턴스에서 MySQL 데이터베이스를 실행 중.
• SysOps 관리자는 다중 테넌트 워크로드를 처리할 수 있는 고가용성 DB 솔루션을 요청받음.
• 요구사항: 확장성 + 고가용성을 제공하는 DB로 이전해야 함.

✅ 정답

C. 데이터베이스를 Amazon Aurora 다중 마스터 DB 클러스터로 마이그레이션

• Amazon Aurora 다중 마스터 클러스터는 쓰기 및 읽기 모두 고가용성을 제공.
• 단일 인스턴스 장애 시에도 다른 마스터 노드가 즉시 처리 가능.
• 다중 테넌트 워크로드 환경에서도 확장성과 가용성을 충족.

❌ 오답 해설

• A. MySQL용 두 번째 EC2 인스턴스 생성
  → EC2에서 직접 MySQL을 운영하는 것은 수동 관리가 필요하고, 내결함성 보장이 부족함.
• B. Aurora DB 클러스터로 마이그레이션 (단일 마스터 + 리더)
  → 고가용성은 제공되지만, 여전히 쓰기 작업은 단일 마스터에 집중됨 → 다중 테넌트 환경에서 성능 한계.
• D. MySQL DB 인스턴스용 Amazon RDS로 마이그레이션
  → 관리형 RDS MySQL은 편리하지만, Aurora 다중 마스터 대비 확장성과 내결함성 부족.

📊 흐름도 (Mermaid 다이어그램)

```mermaid
flowchart TD
    EC2["💻 기존 EC2: MySQL 단일 인스턴스"] -->|"🛠️ 마이그레이션"| Aurora["🌟 Amazon Aurora: 다중 마스터 클러스터"]

    Aurora --> Master1["📝 마스터 노드 1: 쓰기 가능"]
    Aurora --> Master2["📝 마스터 노드 2: 쓰기 가능"]
    Aurora --> Reader1["📖 읽기 전용 노드 1"]
    Aurora --> Reader2["📖 읽기 전용 노드 2"]
```

 

📊 결과 설명

• 💻 기존 EC2 (MySQL 단일 인스턴스)
  → 🛠️ 마이그레이션 → 🌟 Amazon Aurora 다중 마스터 클러스터
• Aurora 클러스터 구성:
  • 📝 마스터 노드 1 & 2 (쓰기 가능)
  • 📖 읽기 전용 노드 1 & 2

🎯 핵심 개념 정리

• EC2 MySQL (A) = 직접 관리 필요 + 고가용성 부족 (❌)
• Aurora 단일 마스터 (B) = 쓰기 단일 지점 → 다중 테넌트 비효율적 (❌)
• RDS MySQL (D) = 관리 편의성은 있지만 Aurora 다중 마스터 대비 한계 (❌)
• Aurora 다중 마스터 (C) = 쓰기/읽기 모두 고가용성 + 자동 장애 조치 (✅ 정답)

👉 Q170의 핵심은 다중 테넌트 + 고가용성 조건 = Aurora 다중 마스터라는 점이에요.

📘 오답노트 - Q173

❓ 문제 요약

• 여러 지역에서 발생할 수 있는 무단 AWS Management Console 로그인을 자동으로 모니터링해야 함.
• 요구사항: AWS 계정 보안 이벤트 감지 및 모니터링 자동화.

✅ 정답

D. Amazon GuardDuty를 구성하여 Unauthorized Access: IAMUser/ConsoleLoginSuccess.B finding을 모니터링

• Amazon GuardDuty는 AWS 계정에 대한 악의적 활동 및 무단 접근을 자동 감지.
• “IAMUser/ConsoleLoginSuccess.B” 같은 이벤트는 무단 콘솔 로그인 성공을 의미.
• 요구사항에 가장 적합.

❌ 오답 해설

• A. Amazon Cognito
  → 애플리케이션 사용자 인증 서비스(소셜 로그인/앱 인증 등). AWS 콘솔 로그인 감지와 무관.
• B. Amazon Inspector
  → EC2 및 컨테이너 워크로드 취약점/보안 검사 서비스. 로그인 이벤트 모니터링 기능 없음.
• C. AWS Config
  → 리소스 구성 변경 추적 서비스. IAM 정책 검증 가능하나, 실시간 로그인 감지 불가능.

📊 비교 표

📊 흐름도 (Mermaid 다이어그램)

 

```mermaid
flowchart TD
    User["👤 사용자: 로그인 시도"] --> CloudTrail["📜 AWS CloudTrail: 로그 기록"]
    CloudTrail --> GuardDuty["🛡️ Amazon GuardDuty: 로그 분석"]
    GuardDuty -->|"🚨 Unauthorized Access 감지"| Alert["📧 보안 알림 전송"]

```

 

📊 결과 설명

• 👤 사용자 로그인 시도 → 📜 CloudTrail 로그 기록
• 🛡️ GuardDuty 분석으로 Unauthorized Access 여부 감지
• 감지 시 📧 보안 알림 전송으로 보안팀 대응 가능

🎯 핵심 개념 정리

• AWS Cognito → 앱 사용자 인증 (❌)
• AWS Inspector → 워크로드 취약점 분석 (❌)
• AWS Config → 리소스 변경 추적 (❌)
• Amazon GuardDuty → AWS 계정의 무단 로그인/보안 위협 탐지 (✅ 정답)

👉 Q173의 핵심은 AWS 계정 로그인 보안 이벤트 자동 감지 = GuardDuty입니다.

📘 오답노트 - Q200

❓ 문제 요약

• 회사는 애플리케이션을 AWS VPC로 마이그레이션.
• 온프레미스 네트워크와는 Site-to-Site VPN으로 연결.
• 애플리케이션은 온프레미스 DNS 서버를 사용해 도메인 이름을 확인해야 함.
• 마이그레이션 후 이름 확인 오류 발생 → 내부 도메인 이름 확인 필요.

✅ 정답

B. Amazon Route 53 Resolver 아웃바운드 엔드포인트를 생성한다.

• Route 53 Resolver 아웃바운드 엔드포인트를 사용하면, VPC 내부에서 발생하는 DNS 쿼리를 온프레미스 DNS 서버로 전달 가능.
• 이렇게 하면 애플리케이션이 여전히 온프레미스 DNS를 사용하여 내부 도메인을 해석할 수 있음.

❌ 오답 해설

• A. EC2 인스턴스에서 사용자 지정 DNS 전달자 배포
  → 불필요하게 관리 오버헤드가 큼. Route 53 Resolver가 더 적절한 관리형 솔루션임.
• C. AWS Direct Connect 연결 구성
  → 네트워크 연결 대역폭 향상은 가능하나, DNS 질의 전달 문제 해결과 직접적 관련 없음.
• D. Amazon Route 53 퍼블릭 호스팅 영역 구성
  → 퍼블릭 도메인용이라, 온프레미스 내부 도메인 해석 불가.

📊 비교 표

📊 흐름도 (Mermaid)

```mermaid
flowchart TD
    App["💻 애플리케이션 (VPC 내부)"] --> Resolver["🌐 Route 53 Resolver: 아웃바운드 엔드포인트"]
    Resolver --> OnPremDNS["🏢 온프레미스 DNS 서버"]
    OnPremDNS --> App

```

 

📊 결과 설명

• 💻 애플리케이션 (VPC 내부) → 🌐 Route 53 Resolver 아웃바운드 엔드포인트
• Resolver가 요청을 🏢 온프레미스 DNS 서버로 전달
• 결과가 다시 💻 애플리케이션으로 돌아옴

🎯 핵심 개념 정리

• 문제 상황: 마이그레이션 후 애플리케이션이 내부 도메인 이름을 못 찾음.
• 핵심 해결책: AWS VPC에서 발생하는 DNS 요청을 온프레미스 DNS로 전달.
• 정답: Route 53 Resolver 아웃바운드 엔드포인트 (B).

👉 Q200의 핵심은 온프레미스 DNS와의 연동 = Route 53 Resolver 아웃바운드입니다.

📘 오답노트 - Q271

✅ 문제 요약

• SysOps 관리자가 재해 복구(DR) 계획 설계
• 앱: ALB 뒤 Amazon EC2 인스턴스에서 실행
• DB: Amazon Aurora PostgreSQL
• RTO ≤ 15분, RPO ≤ 15분 요구

✅ 정답

B, D

• B. Aurora 글로벌 데이터베이스 옵션 사용 → DR 리전 Aurora 클러스터 구성
  → Aurora Global Database는 리전 간 데이터 복제를 지원하며, 짧은 RPO 달성 가능
• D. ALB 및 Auto Scaling 그룹을 사용하여 DR 리전 구성
  → 최소 용량/최대 용량을 1로 설정해 대기 비용을 줄이면서도 빠른 Failover 가능
  → 필요 시 Auto Scaling으로 신속히 확장 → RTO 충족

❌ 오답 해설

• A. DR 리전으로 Aurora 백업 내보내기
  → 백업 기반 복구는 느려서 RTO 15분 요구 충족 불가
• C. ALB 및 Auto Scaling 그룹만 DR 구성
  → DB 복구 방안 없음 → RPO 충족 불가
• E. CloudFormation으로 새 ALB/Auto Scaling 그룹 시작
  → 배포 시간이 오래 걸려 RTO 15분 충족 불가

📊 해설

• RTO (Recovery Time Objective) ≤ 15분
  → 서비스 빠른 전환 필요 → DR 리전 Pre-provisioned 최소 자원
• RPO (Recovery Point Objective) ≤ 15분
  → 데이터 손실 최소화 필요 → Aurora Global Database 복제 활용

📈 다이어그램 (Mermaid)

```mermaid
flowchart TD
    Aurora["Aurora Primary: Region A"] --> GlobalDB["Global Database 복제"]
    GlobalDB --> AuroraDR["Aurora Cluster: Region B"]
    
    ALB1["ALB: Region A"] --> EC2A["EC2 Auto Scaling: Region A"]
    ALB2["ALB: Region B - DR"] --> EC2B["EC2 Auto Scaling: Region B, Min=1"]
    
    AuroraDR --> App["Failover 시 App 연결"]
```

📌 핵심 키워드

• Aurora Global Database → 리전 간 데이터 동기화로 낮은 RPO
• ALB + Auto Scaling 최소 용량 설정(1) → 저비용 대기, 빠른 확장으로 RTO 충족
• 단순 백업/재배포 방식은 시간 초과로 부적절

📘 오답노트 - Q275

✅ 문제 요약

• 회사는 ALB 뒤 Amazon EC2 인스턴스 집합에 웹사이트를 배포.
• 소셜 IdP(예: Google, Facebook 등) 를 통해 사용자 인증 필요.
• 요구사항: AWS 기본 서비스만 사용.

✅ 정답

A, D

• A. 소셜 IdP를 Amazon Cognito 사용자 풀 구성
  → Cognito는 Facebook, Google 같은 소셜 IdP와 연동 가능.
  → 사용자 인증을 쉽게 구현 가능.
• D. 인증 규칙을 추가하도록 ALB 리스너 구성
  → ALB는 Cognito와 직접 통합 가능.
  → ALB에서 인증/인가 처리를 수행해 EC2 인스턴스에 전달.

❌ 오답 해설

• B. OIDC 엔드포인트 직접 구성
  → AWS 기본 서비스 요구 조건과 맞지 않음.
  → ALB + Cognito 조합이 기본 서비스 기반 해법.
• C. Lambda 권한 부여자 생성
  → Lambda Authorizer는 API Gateway와 함께 사용.
  → ALB 인증 시 적용되지 않음.
• E. Lambda@Edge로 ALB 인증 구현
  → CloudFront 기반 인증 방식, ALB 환경과 맞지 않음.

📊 해설

• ALB는 Amazon Cognito와 기본 통합 지원.
• 외부 IdP (소셜 로그인)는 Cognito 사용자 풀에 연결 → ALB 리스너 규칙으로 인증 처리.
• 따라서 Cognito + ALB 인증 규칙 조합이 정답.

📈 다이어그램 (Mermaid)

```mermaid
flowchart TD
    User[사용자] --> ALB["Application Load Balancer"]
    ALB -->|"인증 요청"| Cognito["Amazon Cognito: 소셜 IdP 연동"]
    Cognito -->|"토큰 발급"| ALB
    ALB --> EC2["Amazon EC2 인스턴스: 웹사이트"]
```

 

📌 핵심 키워드

• Amazon Cognito + ALB 통합 → 소셜 로그인 구현
• ALB 리스너 인증 규칙 → 인증 처리 자동화
• Lambda Authorizer, Lambda@Edge는 잘못된 선택

📘 오답노트 - Q276

✅ 문제 요약

• 회사 웹사이트 = 웹 계층(EC2 Auto Scaling) + DB 계층(Amazon RDS MySQL 다중 AZ).
• DB 인스턴스에 접근은 네트워크 ACL로 제한.
• Auto Scaling으로 새로운 웹 서버가 추가되었는데 DB 연결 불가 오류 발생.
• 원인: 신규 웹 서버의 트래픽을 허용하는 ACL 규칙 없음.

✅ 정답

C, D

• C. DB 서브넷의 ACL에 MySQL(3306) 인바운드 허용 규칙 추가
  → 신규 웹 서버가 DB에 접속할 수 있도록 인바운드 트래픽 허용 필요.
• D. DB 서브넷의 ACL에 신규 웹 서버 대상으로 TCP 아웃바운드 허용 규칙 추가
  → RDS로부터 응답이 웹 서버에 돌아갈 수 있도록 아웃바운드 규칙도 허용해야 함.

❌ 오답 해설

• A. 임시 포트 범위를 소스로 TCP 인바운드 허용
  → 소스는 웹 서버 서브넷이어야 하며 임시 포트 지정은 잘못됨.
• B. 기본 ACL에 Aurora(3306) 아웃바운드 허용
  → 아웃바운드는 DB 서버가 웹 서버로 나가는 것이므로 불필요.
• E. DB 서브넷 ACL에 Aurora(3306) 아웃바운드 규칙 추가
  → DB에서 웹 서버로 직접 트래픽을 보내는 게 아니라 응답 트래픽이므로 인바운드/아웃바운드 짝 규칙이 필요.

📊 다이어그램 (Mermaid)

 

```mermaid
flowchart TD
    Web1["웹 서버 1"] -->|"포트 3306"| RDS["Amazon RDS MySQL"]
    Web2["웹 서버 2"] -->|"포트 3306"| RDS
    Web3["웹 서버 3: 신규"] -->|"포트 3306"| RDS

    subgraph ACL["네트워크 ACL 규칙"]
        C["인바운드 허용: MySQL 3306 → DB 서브넷"]
        D["아웃바운드 허용: TCP 응답 → 신규 웹 서버"]
    end

    RDS --> ACL

```

 

📌 핵심 키워드

• NACL 규칙은 인바운드와 아웃바운드 모두 필요
• 신규 Auto Scaling EC2가 추가되면 DB 접근을 허용하도록 규칙 갱신 필요
• 정답: C, D

📘 오답노트 - Q286

✅ 문제 요약

• 환경: PostgreSQL Amazon RDS 클러스터, 자동 백업 보존 기간 = 7일.
• 요구사항: 24시간 이내에 생성되지 않은 데이터는 제외하고 새로운 RDS DB 클러스터 생성.
• 최소한의 운영 오버헤드로 복구/생성해야 함.

✅ 정답

A, C

• A. 가장 최근의 자동 스냅샷 실행 → 새 RDS DB 클러스터로 복원
  → 자동 백업 스냅샷을 이용하면 최근 상태(보존 기간 내)로 복구 가능.
• C. 원본 RDS DB 클러스터에서 읽기 전용 복제본 인스턴스를 생성 → 독립형 RDS DB 클러스터로 승격
  → 최소 오버헤드로 빠르게 새로운 클러스터 생성 가능.

❌ 오답 해설

• B. 백업 툴 + S3 백업 후 복원
  → 불필요하게 복잡하며 운영 오버헤드 증가.
• D. AWS DMS로 마이그레이션
  → 데이터 변환이나 마이그레이션 시 사용, 단순 복제 목적에는 과함.
• E. pg_dump/pg_restore 유틸리티
  → 수동 작업이며 운영 오버헤드가 크고, 질문의 "최소한의 운영 오버헤드" 조건과 맞지 않음.

📊 다이어그램 (Mermaid)

 

```mermaid
flowchart TD
    RDS[기존 RDS PostgreSQL 클러스터] --> Snapshot[자동 스냅샷]
    Snapshot --> NewRDS1[새 RDS 클러스터 복원]

    RDS --> Replica[읽기 전용 복제본 생성]
    Replica --> Promote[독립형 클러스터 승격]
    Promote --> NewRDS2[새 RDS 클러스터]

```

📌 핵심 키워드

• RDS 자동 백업 스냅샷: 최근 데이터 기준 복구.
• 읽기 전용 복제본 + 승격: 빠르게 새로운 클러스터 생성.
• 정답: A, C

📘 오답노트 - Q287

✅ 문제 요약

• 환경: ALB(Application Load Balancer) 뒤에서 Amazon EC2 웹 서버 운영.
• 글로벌 사용자 기반으로 로드 분산 최적화를 위해 ALB를 원본으로 하는 Amazon CloudFront 배포 구성.
• 문제: 일주일간 모니터링 후, ALB가 계속 트래픽을 처리 → 웹 서버 로드에 변화 없음.

✅ 정답

B, D

• B. DNS가 여전히 CloudFront 대신 ALB를 가리키고 있음
  → 트래픽이 CloudFront를 경유하지 않고 ALB로 직접 전달되는 원인.
• D. CloudFront 배포 TTL(Time to Live)이 0으로 설정됨
  → 캐싱이 동작하지 않고, 모든 요청이 계속 ALB로 전달되는 문제 발생.

❌ 오답 해설

• A. CloudFront 원본 액세스 ID 없음
  → 이는 S3 오리진 접근 통제와 관련, ALB 기반 시나리오와 무관.
• C. ALB 보안 그룹이 CloudFront 인바운드 트래픽 허용 안 함
  → ALB가 트래픽을 전혀 받지 못하는 상황이어야 하는데, 문제에서는 “ALB가 계속 처리” 중이라 무관.
• E. ALB와 연결된 대상 그룹이 잘못 구성됨
  → ALB가 정상적으로 요청을 처리하고 있으므로 대상 그룹 문제는 아님.

📊 다이어그램 (Mermaid)

```mermaid
flowchart TD
    User[🌍 글로벌 사용자] --> DNS[DNS 레코드]
    DNS -->|잘못된 설정: ALB 가리킴| ALB[ALB 직접 트래픽 처리]
    DNS -->|정상 설정| CF[Amazon CloudFront]

    CF -->|캐싱 TTL=0초 → 캐싱 불가| ALB
    ALB --> EC2[웹 서버]

```

📌 핵심 키워드

• DNS 레코드가 CloudFront를 가리켜야 함.
• TTL 설정을 통해 캐싱 효과를 얻어야 로드 감소.

📘 오답노트 - Q288

✅ 문제 요약

• 환경: ALB(Application Load Balancer) 를 도메인 example.com 및 www.example.com에 연결해야 함.
• Route 53을 사용해 호스팅 영역 구성 필요.
• SysOps 관리자가 선택해야 할 올바른 조합은?

✅ 정답

C, D

• C. ALB의 CNAME을 가리키도록 example.com에 대한 별칭 레코드 생성
  → ALB는 고정 IP가 아닌 DNS 이름(CNAME)을 가지므로 별칭(Alias) 레코드를 사용해야 함.
• D. Route 53에서 example.com 레코드를 ALB로 가리키도록 별칭 레코드 생성
  → 최적의 방식으로 도메인을 ALB와 연결하는 방법.

❌ 오답 해설

• A, B (ALB의 IP 주소를 직접 A 레코드로 등록)
  → ALB는 고정 IP를 제공하지 않으므로 사용할 수 없음.
• E. ALB의 CNAME을 직접 example.com에 매핑
  → Apex 도메인(example.com)은 CNAME을 지원하지 않음 → Route 53 별칭 레코드를 사용해야 함.

📊 다이어그램 (Mermaid)

```mermaid
flowchart TD
    User["🌍 사용자가 example.com 접속"] --> Route53["Amazon Route 53 호스팅 영역"]
    Route53 -->|"별칭 레코드: Alias"| ALB["Application Load Balancer"]
    ALB --> EC2["웹 서버 EC2 인스턴스"]

```

 

📌 핵심 키워드

• ALB는 IP 고정값 제공 X → CNAME 기반
• Apex 도메인(CNAME 불가) → Route 53 별칭(Alias) 레코드 사용 필수
• 정답: C, D

📘 오답노트 - Q293

✅ 문제 요약

• 회사는 www.example.com 도메인으로 Amazon CloudFront 배포 사용.
• ACM에서 www.example.com용 SSL 인증서 이미 발급받음.
• 모든 CloudFront 트래픽은 암호화(HTTPS) 되어야 함.
• 올바른 단계 조합은? (2개 선택)

✅ 정답

A, C

• A. CloudFront 캐시 동작 → HTTP 요청을 HTTPS로 리디렉션 설정
  → 모든 HTTP 요청을 자동으로 HTTPS로 강제.
• C. CloudFront 배포에 사용자 정의 도메인 이름(CNAME) 등록 & ACM SSL 인증서 연결
  → 사용자 맞춤 도메인(www.example.com)을 CloudFront와 연결하고 HTTPS 인증서 적용.

❌ 오답 해설

• B. HTTP 및 HTTPS를 모두 허용
  → HTTP만 허용 시 암호화 보장 불가 → "HTTPS 강제 리디렉션"이 정답.
• D. AWS WAF Web ACL 구성
  → 보안 필터링 용도일 뿐 HTTPS 강제와 직접적 관련 없음.
• E. CloudFront Origin Shield 구성
  → 캐싱 최적화 기능이지 HTTPS 암호화와는 무관.

📊 다이어그램 (Mermaid)

 

```mermaid
flowchart TD
    User[🌍 사용자가 www.example.com 접속] --> CF[CloudFront 배포]
    CF -->|HTTPS 강제 리디렉션| SSL[ACM SSL 인증서 적용]
    SSL --> Origin[S3/EC2 원본 서버]
```

📌 핵심 키워드

• CloudFront에서 HTTP → HTTPS 리디렉션 설정
• 사용자 정의 도메인(CNAME) + ACM SSL 인증서 연결

📘 오답노트 - Q314

✅ 문제 요약

• 회사는 Windows 파일 서버용 Amazon FSx 파일 시스템을 생성.
• 저장 공간이 100GB 미만일 경우, SysOps 관리자가 이메일 알림을 받아야 함.
• 회사는 Amazon SNS 주제를 생성해 관리자 이메일로 알림 수신 설정 완료.
• 어떤 단계 조합이 이 요구사항을 충족할까? (2개 선택)

✅ 정답

B, E

• B. FreeStorageCapacity 지표 < 100GB일 때 CloudWatch 경보 생성
  → CloudWatch 메트릭(FreeStorageCapacity)을 활용하여 임계값 기반 알람 설정.
• E. CloudWatch 경보 상태 → SNS 주제 게시
  → 경보가 발생하면 SNS로 알림을 보내 SysOps 관리자에게 전달.

❌ 오답 해설

• A. EventBridge 규칙
  → FSx의 스토리지 모니터링은 CloudWatch 지표 기반이어야 함. EventBridge는 적절치 않음.
• C. Lambda 함수 실행
  → 단순 이메일 알림이면 Lambda 필요 없음. 불필요한 복잡성.
• D. EventBridge 규칙과 SNS 연결
  → CloudWatch 알람 → SNS 연결이 표준 방식. EventBridge는 맞지 않음.

📊 다이어그램 (Mermaid)

```mermaid
flowchart TD
    FSx["📂 Amazon FSx 파일 시스템"] --> CW["📈 CloudWatch FreeStorageCapacity 지표"]
    CW --> Alarm["⚠️ CloudWatch 경보: 임계값 100GB 미만"]
    Alarm --> SNS["📨 SNS 주제"]
    SNS --> Email["📧 SysOps 관리자 이메일 알림"]

```

📌 핵심 키워드

• CloudWatch 지표 (FreeStorageCapacity)
• SNS 알림 연계

📘 오답노트 - Q333

✅ 문제 요약

• 회사는 단일 AWS 계정에 50개 이상의 EC2 인스턴스를 운영.
• 매달 운영 체제 패치에 많은 시간이 소요됨.
• 요구사항: 최소한 한 번에 한 번 패치를 완료해야 함.
• SysOps 관리자는 AWS Systems Manager를 활용해야 함.

✅ 정답

A, C, E

• A. EC2 인스턴스를 리소스 그룹으로 그룹화
  → Systems Manager에서 패치를 적용할 대상을 정의하는 데 필요.
• C. Systems Manager Automation Runbook 지정
  → Runbook은 패치 절차를 자동화하기 위한 표준 문서(Playbook 역할).
• E. Systems Manager Fleet Manager 구성
  → 대규모(50개+) 인스턴스를 한 번에 패치 관리 가능. Runbook을 대상 그룹에 적용 가능.

❌ 오답 해설

• B. 패치 일정 생성
  → 단순히 일정만 생성해서는 자동 패치 실행이 불가. Runbook과 그룹 지정이 필요.
• D. 패치 상태 모니터링 + Runbook 생성
  → 모니터링만으로는 패치 적용 불가. 유지 관리 기간과 그룹 지정이 더 중요.

📊 다이어그램 (Mermaid)

```mermaid
flowchart TD
    EC2["💻 EC2 인스턴스 50+"] --> Group["📦 리소스 그룹"]
    Group --> Runbook["📘 Systems Manager Runbook: 패치 워크플로우"]
    Runbook --> FleetMgr["🛠️ Systems Manager Fleet Manager"]
    FleetMgr --> Patch["✅ 자동 패치 실행 및 완료"]

```

📌 핵심 키워드

• Systems Manager 리소스 그룹
• Automation Runbook
• Fleet Manager

📘 오답노트 - Q352

✅ 문제 요약

• 회사는 Amazon EC2 인스턴스 보안 그룹을 모니터링해야 함.
• 요구사항: SSH 포트(22번)가 대중에게 공개되지 않도록 관리.
• SSH가 개방되면 → 가능한 한 빨리 포트를 자동으로 폐쇄해야 함.

✅ 정답

B, D

• B. AWS Config 규칙 추가
  → SSH(포트 22)가 보안 그룹에서 허용되는지 여부를 지속적으로 평가.
  → 위반 시 자동 알림 및 수정 조치 가능.
• D. AWS Systems Manager Automation Runbook 호출
  → 위반이 감지되면 자동으로 보안 그룹에서 SSH 포트 규칙 삭제 가능.

❌ 오답 해설

• A. CloudWatch 경보 추가
  → CloudWatch는 보안 그룹 규칙 자체를 모니터링하지 못함. (로그 기반 모니터링만 가능)
• C. Amazon Inspector
  → Inspector는 취약점 평가 도구이지, SSH 포트 실시간 제어 불가.
• E. Run Command
  → 명령 실행은 수동 방식. 자동화된 포트 차단 요구사항에는 부적절.

📊 다이어그램 (Mermaid)

 

```mermaid
flowchart TD
    SG["🔐 보안 그룹 규칙 모니터링"] --> Config["AWS Config: SSH 포트 22 규칙 탐지"]
    Config --> Runbook["⚡ Systems Manager Automation Runbook"]
    Runbook --> Action["❌ SSH 포트 규칙 자동 삭제"]

```

📌 핵심 키워드

• AWS Config = 감지
• SSM Runbook = 자동 수정

📘 오답노트 - Q356

❓ 문제 요약

• 회사는 온프레미스 웹 애플리케이션을 Amazon EC2 인스턴스로 마이그레이션.
• 애플리케이션은 단일 고정 공용 IP 주소가 필요.
• 도메인(example.com)을 통해 접근 가능해야 하며, 최소한의 관리 노력으로 유지해야 함.
• 올바른 솔루션 조합은? (2개 선택)

✅ 정답

B, D

• B. 연결된 EC2 IP 주소에 대한 Amazon Route 53 A 레코드를 생성
• D. 탄력적 IP 주소를 생성하고 이를 EC2 인스턴스와 연결

❌ 오답 해설

• A. ALB 생성 → ALB는 고정 IP 제공하지 않음. DNS 기반 라우팅이라 조건에 맞지 않음.
• C. CNAME 레코드 생성 → ALB나 CloudFront와 같이 CNAME이 필요한 경우에 사용. 단일 고정 IP 요구사항과 맞지 않음.
• E. Auto Scaling 그룹 생성 → 관리 자동화에 도움되지만 "단일 고정 IP"라는 요구사항을 충족하지 않음.

📊 흐름도 (Mermaid 다이어그램)

 

```mermaid
flowchart TD
    User["👤 사용자: example.com 접속"] --> Route53["🌐 Amazon Route 53: A 레코드"]
    Route53 --> EIP["🔗 탄력적 IP: Elastic IP"]
    EIP --> EC2["💻 Amazon EC2 인스턴스"]

```

🎯 핵심 개념 정리

• Elastic IP (EIP):
  • 고정된 퍼블릭 IPv4 주소 제공.
  • 인스턴스가 재시작되거나 교체되어도 동일한 IP를 유지 가능.
• Route 53 A 레코드:
  • 도메인(example.com)을 EIP와 연결하여 사용자가 도메인으로 접근할 수 있게 해줌.

👉 따라서 "단일 고정 공용 IP + 최소한의 관리" 요구사항 충족 = EIP + Route 53 A 레코드 조합

📘 오답노트 - Q390

❓ 문제 요약

• Amazon EBS 볼륨의 디스크 사용률을 모니터링해야 함.
• 사용률이 80% 이상이 되면 **Amazon CloudWatch 경보(Alarm)**를 설정하여 알림 제공.
• SysOps 관리자가 수행해야 할 단계는 무엇인가? (3개 선택)

✅ 정답

A, D, E

1. A. IAM 역할 생성 (CloudWatchAgentServerPolicy 포함) → EC2 인스턴스에 연결
   • CloudWatch 에이전트가 메트릭을 수집할 수 있도록 권한 부여.
2. D. EC2 인스턴스에 CloudWatch 에이전트 설치 및 시작
   • 디스크 사용률 같은 OS 수준 메트릭은 기본 CloudWatch 지표에 없음 → 에이전트 필요.
3. E. CloudWatch 지표(disk_used_percent)에 기반한 Alarm 생성
   • 디스크 사용률 80% 이상일 때 알람을 트리거하도록 설정.

❌ 오답 해설

• B. ReadOnlyAccess 정책 IAM 역할 생성 → 읽기 전용 정책이라 CloudWatch Agent가 메트릭을 수집/전송할 수 없음.
• C. AWS CLI/명령줄로 CloudWatch 에이전트 실행 → 잘못된 접근 방식. IAM 역할 기반 권한 부여 및 관리 필요.
• F. disk_free CloudWatch 지표 활용 → disk_free는 기본적으로 제공되지 않으며, 직접 에이전트 수집 설정 필요. 문제에서 요구한 건 disk_used_percent 기반이 맞음.

📊 흐름도 (Mermaid 다이어그램)

```mermaid
flowchart TD
    EBS["💾 EBS 볼륨"] --> EC2["💻 EC2 Linux 인스턴스"]
    EC2 --> Agent["📥 CloudWatch Agent 설치"]
    Agent --> IAM["🔑 IAM Role: CloudWatchAgentServerPolicy"]
    Agent --> Metrics["📊 Disk Usage Metrics: disk_used_percent"]
    Metrics --> CW["📈 Amazon CloudWatch"]
    CW --> Alarm["🚨 CloudWatch Alarm: 사용률 >= 80%"]
    Alarm --> Notify["📧 관리자 알림: SNS / 이메일"]

```

🎯 핵심 개념 정리

• CloudWatch 기본 지표: EC2 수준(CPU, 네트워크, 디스크 I/O)은 제공되지만, **디스크 사용률(%)**은 제공되지 않음.
• CloudWatch Agent: OS 수준 메트릭(디스크, 메모리, 프로세스 등)을 수집하려면 반드시 설치 필요.
• IAM Role 연결: EC2 인스턴스가 CloudWatch로 메트릭을 전송할 수 있도록 권한 제공.
• CloudWatch Alarm: 특정 임계값(예: 80%) 초과 시 알림(SNS 등) 전송.

👉 따라서, IAM Role + CloudWatch Agent 설치 + Alarm 구성이 정답 조합.

📘 오답노트 - Q408

❓ 문제 요약

• 웹 애플리케이션이 Auto Scaling 그룹의 EC2 인스턴스에서 실행 중.
• ALB(Application Load Balancer) → CloudFront 배포를 통해 사용자에게 서비스됨.
• 현재 ALB는 기간 기반 쿠키를 사용하여 세션 스티키(Session Stickiness)를 구현 중.
• 로그아웃은 15분 타임아웃 전에 발생 → 세션 관리에 문제 발생.

✅ 정답

B, E

1. B. CloudFront 배포의 캐시 동작 설정에서 쿠키 전달을 구성
   • CloudFront가 ALB로 전달하는 요청에 세션 쿠키가 포함되도록 설정해야, 세션 지속성이 올바르게 유지됨.
2. E. 애플리케이션 기반 쿠키를 사용하도록 ALB를 변경
   • ALB에서 기간 기반 쿠키 대신 애플리케이션 생성 쿠키를 사용하면 세션 관리가 더 정확해짐.

❌ 오답 해설

• A. ALB 대상 그룹 최소 대기열 요청 알림값 변경 → 로그아웃 문제와 직접적인 관련 없음.
• C. ALB에서 자체 쿠키를 사용하여 세션 관리 → 이미 이 방식(기간 기반 쿠키) 때문에 문제가 발생한 것.
• D. ALB 고정 세션 기간 변경 → 로그아웃 타이밍 문제를 해결하지 못함.

📊 흐름도 (Mermaid 다이어그램)

```mermaid
flowchart TD
    User["🌍 사용자 브라우저"] --> CF["🌐 Amazon CloudFront"]
    CF --> ALB["⚖️ Application Load Balancer"]
    ALB --> EC2["💻 Auto Scaling EC2 인스턴스들"]

    subgraph 세션관리["🔒 세션 관리"]
        ALB -.->|"⏳ 기간 기반 쿠키: 문제 발생"| User
        ALB --> AppCookie["🍪 애플리케이션 쿠키 기반 세션"]
        CF -->|"🍪 쿠키 전달"| ALB
    end

    AppCookie --> Fixed["✅ 세션 타임아웃 및 로그아웃 정상 처리"]

```

🎯 핵심 개념 정리

• 기간 기반 쿠키 (Duration-based stickiness): ALB가 자체 생성한 쿠키를 기반으로 세션을 고정 → 앱에서 로그아웃 타이밍을 제어하지 못하는 문제 발생.
• 애플리케이션 기반 쿠키 (App-generated cookies): 앱에서 직접 쿠키를 발급/관리 → 로그아웃, 세션 만료 등 제어 가능.
• CloudFront와 쿠키 전달 설정: CloudFront가 ALB로 요청을 전달할 때 반드시 세션 쿠키 포함 필요.

👉 따라서, CloudFront 쿠키 전달 구성 + ALB를 애플리케이션 쿠키 기반으로 변경 조합이 문제 해결의 핵심.

📘 오답노트 - Q465

❓ 문제 요약

• 애플리케이션이 Amazon DynamoDB 테이블을 사용 중.
• AWS Lambda 함수에서 DeleteTable API가 호출되어 프로덕션 테이블이 실수로 삭제되는 문제 발생.
• 요구사항:
  1. 실수로 테이블이 삭제되는 가능성을 최소화해야 함.
  2. 만약 삭제되더라도 데이터 손실을 최소화해야 함.

✅ 정답

B, C

1. B. DynamoDB 테이블에 대한 삭제 보호(Deletion Protection) 활성화
   • 테이블을 삭제하려 할 때 보호 기능이 동작 → 실수로 삭제되는 가능성을 크게 줄임.
2. C. DynamoDB 테이블에 대한 시점 복구(Point-in-Time Recovery, PITR) 활성화
   • 최대 35일 동안의 데이터를 초 단위 단위로 복구 가능 → 실수로 삭제되더라도 데이터 손실 최소화.

❌ 오답 해설

• A. CloudFormation 종료 보호 활성화
  → CloudFormation 스택 단위 보호이므로, DynamoDB 개별 테이블 삭제 방지와는 무관.
• D. 테이블 백업 예약
  → 정기 백업은 가능하나, 실수 삭제 직후 즉시 복구하기에는 한계가 있음. (PITR이 더 적합)
• E. 테이블을 S3로 내보내기
  → 분석이나 장기 보관에는 유용하지만, 삭제된 DynamoDB 테이블을 직접적으로 빠르게 복원할 수 없음.

📊 흐름도 (Mermaid 다이어그램)

```mermaid
flowchart TD
    Lambda["🟦 AWS Lambda 함수"] -->|"⚠️ 실수로 DeleteTable API 호출"| DynamoDB["🗄️ DynamoDB 테이블"]

    DynamoDB --> Protect["🛡️ 삭제 보호: Deletion Protection - 삭제 방지"]
    DynamoDB --> PITR["⏳ 시점 복구: PITR - 최대 35일 내 복원"]

    Protect -.-> Admin["👨‍💻 SysOps 관리자: 실수 삭제 예방"]
    PITR -.-> Recovery["🔄 데이터 손실 최소화 및 복구"]

```

🎯 핵심 개념 정리

• Deletion Protection: DynamoDB 테이블 삭제 방지 기능.
• PITR (Point-in-Time Recovery): 최대 35일 동안 모든 시점으로 데이터 복구 가능.
• 두 기능을 함께 사용해야 실수 삭제 방지 + 데이터 손실 최소화라는 두 가지 목표를 달성할 수 있음.

📘 오답노트 - Q6

✅ 문제 요약

• 회사는 S3 버킷에 업로드된 모든 객체가 암호화되었는지 확인해야 함.
• 요구사항: 암호화 강제 + 암호화되지 않은 업로드 거부.
• 정답: C, E

✅ 정답 해설

• C. 업로드되는 모든 객체가 저장되기 전에 암호화되도록 Amazon S3 기본 암호화를 구현한다.
  • 기본 암호화(Default Encryption) 설정 시, 모든 객체는 자동으로 서버 측 암호화(SSE-S3, SSE-KMS 등) 적용됨.
  • 사용자가 암호화를 명시하지 않아도 항상 암호화된 상태로 저장됨.
• E. 암호화되지 않은 객체가 버킷에 업로드되는 것을 거부하는 S3 버킷 정책을 구현한다.
  • S3 버킷 정책에서 "s3:x-amz-server-side-encryption" 조건을 강제하면, 암호화되지 않은 객체는 업로드 거부됨.
  • 즉, 보안 정책 준수 보장 가능.

❌ 오답 해설

• A. AWS Shield 구현
  • AWS Shield는 DDoS 방어 서비스이지, 객체 암호화 확인과는 무관함.
• B. 객체 ACL 사용
  • ACL은 액세스 권한 관리 용도로, 암호화 강제 기능 없음.
• D. Amazon Inspector 구현
  • Amazon Inspector는 EC2, ECR 보안 취약점 스캐닝 서비스로, S3 객체 암호화 검증 기능 제공하지 않음.

📊 핵심 포인트

• S3 객체 암호화 보장 방법
  1. S3 Default Encryption → 항상 암호화된 상태로 저장.
  2. Bucket Policy with Deny → 암호화 옵션 없는 업로드 거부.
• 시험에서 자주 나오는 패턴:
  👉 “S3 객체 암호화를 보장해야 한다” = 기본 암호화 + 버킷 정책 조합.

📈 다이어그램 (Mermaid)

 

```mermaid
flowchart TD
    U[사용자] --> S3[Amazon S3 버킷]
    S3 -->|Default Encryption| ENC[자동 암호화 적용]
    S3 -.->|Bucket Policy| DENY[암호화 미적용 객체 거부]
```

 

👉 이 문제는 S3 보안 Best Practice 그대로 물어보는 유형입니다.
즉, "Default Encryption + Bucket Policy" 조합을 무조건 기억해두시면 됩니다.

📘 오답노트 - Q46

✅ 문제 요약

• 회사는 ALB 뒤의 EC2 웹 애플리케이션을 운영 중.
• Amazon Route 53을 사용하여 트래픽 라우팅.
• Amazon S3에 정적 웹 사이트를 구성해두었음 (백업/보조 사이트).
• 요구사항:
  • 장애 발생 시 자동으로 정적 웹 사이트로 장애 조치(failover) 라우팅.
• 정답: C, E

✅ 정답 해설

• C. 기본 장애 조치 라우팅 정책 레코드를 생성한다.
  • Route 53에서 기본(primary) 레코드는 정상일 때 사용됨.
  • ALB와 연결되어 정상 서비스로 트래픽 전달.
• E. 보조 장애 조치 라우팅 정책 레코드를 생성한다.
  • 보조(secondary) 레코드는 헬스 체크 실패 시 활성화됨.
  • 장애 시 Route 53이 S3 정적 웹 사이트 엔드포인트로 트래픽을 라우팅.

➡️ 즉, Route 53 장애 조치 라우팅 정책 (Failover Routing Policy) 를 활용하는 것이 정답.

❌ 오답 해설

• A. ALB와 연결된 기본 장애 조치 레코드만 생성
  • 보조 레코드가 없으므로 장애 발생 시 S3로 자동 전환 불가.
• B. Lambda 함수로 장애 시 S3로 수동 전환
  • Route 53의 failover 정책만으로 자동화 가능하므로 Lambda는 불필요.
• D. 보조 레코드를 Route 53 상태 확인 없이 구성
  • 헬스 체크 없이 보조 레코드를 지정하면 자동 장애 조치 불가능.

📊 핵심 포인트

• Route 53 장애 조치 라우팅 정책 (Failover Routing Policy)
  • 기본(primary) 레코드: 정상 서비스 (예: ALB).
  • 보조(secondary) 레코드: 장애 시 활성화 (예: S3 정적 웹 사이트).
  • 헬스 체크 기반으로 자동 전환.

📈 다이어그램 (Mermaid)

```mermaid
flowchart TD
    U[사용자 요청] --> Route53[Amazon Route 53]

    Route53 -->|헬스체크 정상| ALB[ALB + EC2 웹 애플리케이션]
    Route53 -->|헬스체크 실패| S3[Amazon S3 정적 웹 사이트]
```

👉 이 문제의 핵심은 **Route 53의 장애 조치 라우팅 정책 (Failover Routing)**을 정확히 아는 것!
즉, Primary = ALB, Secondary = S3 구조를 그려두면 바로 맞출 수 있습니다 ✅

📘 오답노트 - Q52

✅ 문제 요약

• 애플리케이션: EC2 인스턴스에서 실행
• 데이터베이스: Amazon RDS 인스턴스
• 증상: 배포 후 애플리케이션이 RDS DB에 연결 실패
• 에러 메시지: Error Establishing a Database Connection
• 정답: C, D

✅ 정답 해설

• C. DB 보안 그룹에 웹 서버로부터의 적절한 수신 규칙 없음
  • RDS 보안 그룹에서 EC2 인스턴스의 IP 또는 보안 그룹을 허용하지 않으면 연결 불가.
  • 가장 흔한 원인 중 하나.
• D. 애플리케이션에서 지정한 포트와 RDS 구성 포트 불일치
  • MySQL은 기본 3306, PostgreSQL은 5432 포트.
  • 애플리케이션 연결 문자열에서 포트를 잘못 설정하면 연결 오류 발생.

❌ 오답 해설

• A. 보안 그룹 송신 규칙 없음
  • 기본적으로 보안 그룹의 Outbound(송신) 은 모두 허용됨.
  • 따라서 원인이 될 가능성 낮음.
• B. 인증서 문제
  • SSL 인증서 문제라면 인증 실패 오류가 발생하지, 단순 "DB 연결 오류"로 나타나진 않음.
• E. DB가 아직 생성 중
  • 문제에서는 "프로덕션에 배포 완료"라고 했으므로 이미 DB는 생성 완료된 상태.

📊 핵심 포인트

• RDS 연결 오류 점검 순서:
  1. 보안 그룹 (Inbound Rule): EC2 → RDS 포트 열려 있는지 확인.
  2. 네트워크 (VPC/Subnet): 같은 VPC/Subnet/라우팅 테이블 연결 확인.
  3. 포트 일치 여부: RDS 포트와 애플리케이션 설정 확인.
  4. 엔드포인트: 올바른 RDS 엔드포인트를 사용했는지 확인.

📈 다이어그램 (Mermaid)

```mermaid
flowchart TD
    EC2[EC2 웹 애플리케이션]
    EC2 -->|DB 연결 시도| SG["보안 그룹 (Inbound Rule)"]
    SG -->|허용된 포트만 통과| RDS[(Amazon RDS 인스턴스)]

    RDS --> Fail["연결 실패 원인 ▼"]

    subgraph 연결 실패 원인
        C1["보안 그룹 Inbound 규칙 없음"]
        C2["포트 불일치 (예: 3306 vs 5432)"]
    end

    Fail --> C1
    Fail --> C2


```

👉 이 문제의 포인트는 보안 그룹(Inbound Rule) 과 포트 불일치가 가장 흔한 RDS 연결 장애 원인이라는 점이에요.

📘 오답노트 - Q102

✅ 문제 요약

• 환경: Amazon EC2 Auto Scaling 그룹 (CPU 사용률 기반 확장)
• 문제 상황: Auto Scaling 이벤트 로그에서
  → InsufficientInstanceCapacity 오류 발생
• 정답: A, B

✅ 정답 해설

• A. 인스턴스 유형 변경
  • 특정 AZ 또는 리전에 요청된 인스턴스 유형 용량이 부족하면 새 인스턴스를 시작할 수 없음.
  • 다른 인스턴스 패밀리/유형(예: t3 → t3a, m5 → m5a 등)으로 변경 시 문제 해결 가능.
• B. 다양한 가용 영역(AZ)에 Auto Scaling 그룹 구성
  • 특정 AZ에서만 용량이 부족할 수 있으므로, 여러 AZ에 분산 배치하면 문제를 회피 가능.
  • 고가용성(HA)도 함께 확보할 수 있음.

❌ 오답 해설

• C. EBS 볼륨 크기 확장
  • 문제는 인스턴스 용량 부족이지, 스토리지 문제가 아님.
• D. Auto Scaling 최대 크기 증가
  • 그룹 크기를 늘려도, 애초에 용량 부족(Insufficient Capacity) 상태라면 해결되지 않음.
• E. 서비스 할당량 증가 요청
  • 이 경우는 Service Quota 문제일 때 필요. 하지만 여기선 "InsufficientInstanceCapacity" → AWS 내부 리소스 부족 문제라서 적절하지 않음.

📊 핵심 포인트

• InsufficientInstanceCapacity 에러 의미:
  → 요청한 인스턴스 유형/크기에 대해 특정 AZ나 리전에 AWS가 충분한 물리적 리소스를 제공할 수 없음.
• 해결 방법:
  1. 인스턴스 유형 변경 (유연성 확보)
  2. 여러 가용 영역에 배포 (분산 배치)

📈 다이어그램 (Mermaid)

 

```mermaid
flowchart TD
    ASG[Auto Scaling 그룹] --> AZ1[가용 영역 A]
    ASG --> AZ2[가용 영역 B]
    
    AZ1 -.->|"용량 부족: InsufficientInstanceCapacity"| Fail[인스턴스 생성 실패]
    AZ2 -->|"정상 인스턴스 시작"| Success[애플리케이션 확장 성공]

    Fail --> NoteA[해결책 1: 인스턴스 유형 변경]:::solution
    Fail --> NoteB[해결책 2: 다중 AZ 배포]:::solution

    classDef solution fill:#d1ffd6,stroke:#2c7,stroke-width:2px;

```

👉 이 문제의 키워드는 "InsufficientInstanceCapacity = AWS 인프라 부족" 입니다.
즉, 유형 변경 + 다중 AZ 활용이 가장 효율적인 해결책이에요.

📘 오답노트 - Q116

✅ 문제 요약

• 환경:
  • Amazon CloudFront (웹 배포)
  • Application Load Balancer (ALB)
  • Amazon RDS
  • VPC의 EC2 인스턴스
• 상황:
  • 모든 서비스에 로깅이 활성화됨
  • 관리자는 웹 애플리케이션의 HTTP 계층 (Layer 7) 상태 코드를 조사해야 함
• 정답: C, D (ALB 액세스 로그 + CloudFront 액세스 로그)

✅ 정답 해설

• C. ALB 액세스 로그
  • ALB는 L7 (HTTP/HTTPS) 트래픽을 처리하고, 액세스 로그에 HTTP 상태 코드가 기록됨.
  • 예: 200 (OK), 404 (Not Found), 500 (Internal Server Error)
• D. CloudFront 액세스 로그
  • CloudFront는 CDN으로서 엣지에서 요청을 처리하며, 응답 상태 코드(HTTP 2xx, 4xx, 5xx 등)를 로그에 남김.
  • 전 세계 사용자 요청을 추적할 때 유용.

❌ 오답 해설

• A. VPC 흐름 로그
  • 네트워크 레벨 (Layer 3/4)만 기록 (IP, 포트, ALLOW/DENY).
  • HTTP 상태 코드는 기록하지 않음.
• B. CloudTrail 로그
  • API 호출 기록용(AWS API Call).
  • HTTP 상태 코드는 사용자 애플리케이션 요청에 대한 것이므로 CloudTrail과 무관.
• E. RDS 로그
  • DB 쿼리나 성능에 관련된 로그이지, 웹 애플리케이션 HTTP 상태 코드와 관련 없음.

📊 핵심 포인트

• HTTP 상태 코드 (Layer 7) 를 확인하려면 반드시 Application Layer 로그를 확인해야 함.
• 따라서 정답은 ALB + CloudFront 액세스 로그 조합.

📈 다이어그램 (Mermaid)

```mermaid
flowchart TD
    User[사용자 요청 🌍] --> CF["CloudFront 액세스 로그: HTTP 상태 기록"]
    CF --> ALB["ALB 액세스 로그: HTTP 상태 기록"]
    ALB --> EC2[EC2 웹 애플리케이션 서버]
    EC2 --> RDS[(Amazon RDS 데이터베이스)]

    style CF fill:#d1f0ff,stroke:#2980b9,stroke-width:2px
    style ALB fill:#d1ffd6,stroke:#27ae60,stroke-width:2px


```

 

👉 이 문제의 핵심 키워드는 “HTTP 상태 코드 = L7 로그 → ALB + CloudFront 액세스 로그” 입니다.

📘 오답노트 - Q117

✅ 문제 요약

• 상황:
  • 회사는 AWS 계정 내에서 IAM CreateUser API 호출이 발생할 때
    이메일로 알림을 받고 싶음.
• 요구사항:
  • SysOps 관리자가 이메일 알림을 받을 수 있는 구성.
• 정답: A, D

✅ 정답 해설

• A. CloudTrail + EventBridge 규칙 생성
  • CloudTrail은 IAM API 호출(예: CreateUser) 을 기록함.
  • EventBridge 규칙을 설정하여 특정 API 호출 이벤트를 필터링하고
    알림 워크플로우(SNS 등)로 연결 가능.
• D. Amazon SNS 주제를 이메일 구독자로 사용
  • EventBridge 규칙의 타겟으로 SNS 주제를 연결.
  • SysOps 관리자는 이메일을 구독하여 알림을 받을 수 있음.

❌ 오답 해설

• B. CloudSearch 사용
  • CloudSearch는 텍스트 검색 엔진 서비스.
  • API 호출 이벤트와는 무관.
• C. IAM Access Analyzer 사용
  • Access Analyzer는 IAM 정책의 과도한 권한을 분석하는 서비스.
  • API 호출 이벤트 탐지에는 적합하지 않음.
• E. SES 사용
  • SES는 이메일 전송 서비스이지만,
    EventBridge → SNS → 이메일 구독 방식이 AWS 권장 아키텍처.
  • SES는 이 문제에 직접적으로 적합하지 않음.

📊 핵심 포인트

• API 이벤트 감지 → CloudTrail + EventBridge
• 이벤트 알림 → SNS (이메일 구독자)
• 따라서 정답은 A + D 조합.

📈 다이어그램 (Mermaid)

 

```mermaid
flowchart TD
    CT[CloudTrail - IAM CreateUser API 기록] --> EB["EventBridge 규칙: CreateUser 필터"]
    EB --> SNS[SNS 주제 - 이메일 구독자]
    SNS --> Admin[📧 SysOps 관리자 이메일]

    style CT fill:#d1f0ff,stroke:#2980b9,stroke-width:2px
    style EB fill:#fff2cc,stroke:#e67e22,stroke-width:2px
    style SNS fill:#d1ffd6,stroke:#27ae60,stroke-width:2px


```

 

👉 이 문제의 핵심 키워드는 CloudTrail로 이벤트 기록 → EventBridge로 필터링 → SNS로 이메일 알림 입니다.

📘 오답노트 - Q122

✅ 문제 요약

• 상황:
  • 회사는 HPC(고성능 컴퓨팅) 애플리케이션을 위해 Amazon EC2 인스턴스를 사용.
  • HPC 환경에서는 노드 간 최소 대기 시간(저지연) 이 중요.
• 요구사항:
  • HPC 워크로드를 만족하도록 인스턴스를 적절히 배치해야 함.
• 정답: C, D

✅ 정답 해설

• C. 단일 서버 내 Auto Scaling 그룹에 EC2 인스턴스를 배치
  • HPC에서는 동일 영역(가용영역, AZ) 내에 인스턴스를 모아야 네트워크 지연을 최소화할 수 있음.
  • Auto Scaling을 통해 동일 서버 랙 기반 배치 가능.
• D. EC2 인스턴스를 클러스터 배치 그룹으로 시작
  • 클러스터 배치 그룹(Cluster Placement Group) 은 HPC 워크로드에서 자주 사용됨.
  • 인스턴스를 물리적으로 가까운 호스트에 배치하여 저지연, 고대역폭 네트워크 성능을 제공.

❌ 오답 해설

• A. Amazon EFS 생성
  • 파일 시스템 공유는 가능하지만, HPC의 핵심 요구인 저지연 통신과 직접적 관련 없음.
• B. EC2 인스턴스 앞에 다중 AZ 로드 밸런서 배치
  • HPC는 부하분산보다는 노드 간 빠른 통신이 핵심이므로 로드 밸런서는 적절하지 않음.
• E. 파티션 배치 그룹 사용
  • 파티션 배치 그룹은 대규모 분산 데이터 처리 (예: Hadoop, HBase) 에 적합.
  • 저지연 네트워크 성능이 필요한 HPC에는 적절하지 않음.

📊 핵심 포인트

• HPC(고성능 컴퓨팅) = 저지연(ultra-low latency) + 고대역폭(high throughput)
• 따라서 Cluster Placement Group + Auto Scaling 조합이 최적.

📈 다이어그램 (Mermaid)

```mermaid
flowchart TD
    Admin[SysOps 관리자] --> ASG["Auto Scaling 그룹: 단일 서버 내"]
    ASG --> EC1[EC2 인스턴스 1]
    ASG --> EC2[EC2 인스턴스 2]
    ASG --> EC3[EC2 인스턴스 3]

    subgraph Cluster["Cluster Placement Group"]
        EC1
        EC2
        EC3
    end

    Cluster -.-> Note[저지연 + 고대역폭 네트워크 제공]

```

 

👉 이 문제 핵심은 HPC = Cluster Placement Group 이라는 점이에요.

📘 오답노트 - Q127

✅ 문제 요약

• 상황: SysOps 관리자가 VPC에 사용할 수 있는 IPv4 주소가 부족해서 EC2 인스턴스를 시작할 수 없음.
• 요구사항: 새로운 EC2 인스턴스를 시작할 수 있도록 적절한 작업 조합 선택 (2개).

✅ 정답

A, C

• A. 보조 IPv4 CIDR 블록을 VPC와 연결
  → VPC에 새로운 IP 주소 대역을 추가하여 EC2 인스턴스를 배치할 수 있음.
• C. VPC에 대한 새 서브넷 생성
  → 새로 추가한 IPv4 CIDR 블록 기반으로 서브넷을 만들어야 인스턴스를 실제로 배치 가능.

❌ 오답 해설

• B. 기본 IPv6 CIDR 블록 연결
  → 문제는 IPv4 주소 부족이며, IPv6 추가는 해결책이 아님.
• D. VPC의 CIDR 블록 수정
  → 기본 CIDR 블록은 수정 불가. 오직 새로운 CIDR 블록 추가만 가능.
• E. 서브넷의 CIDR 블록 수정
  → 기존 서브넷 CIDR은 수정 불가. 새 서브넷을 생성해야 함.

📊 해설

• AWS VPC는 한 번 생성된 기본 CIDR 블록은 수정할 수 없음.
• IP 주소 부족 문제 해결 방법:
  1. 보조 IPv4 CIDR 블록 추가 (A)
  2. 해당 CIDR을 기반으로 새 서브넷 생성 (C)

📈 다이어그램 (Mermaid)

```mermaid
flowchart TD
    VPC["VPC: 기존 CIDR 고갈"] --> AddCIDR[보조 IPv4 CIDR 블록 추가]
    AddCIDR --> Subnet[새 서브넷 생성]
    Subnet --> EC2[EC2 인스턴스 배치 가능]

```

 

📌 핵심 키워드

• VPC CIDR 블록: 기존 CIDR 수정 불가 → 보조 CIDR만 추가 가능
• 서브넷: 추가된 CIDR을 기반으로 새로 생성해야 리소스 배치 가능
• 정답 패턴: IP 부족 문제 = 보조 CIDR + 새 서브넷

👉 이 문제는 "VPC CIDR 관리" 관련해서 자주 출제되는 유형이에요.

📘 오답노트 - Q140

✅ 문제 요약

• 회사는 Amazon ECS (EC2 런치 타입) 사용
• SysOps 관리자는 ECS 작업 간 트래픽 흐름 모니터링 필요
• 어떤 단계 조합이 필요한가? (2개 선택)

✅ 정답

B, C

• B. 각 작업의 탄력적 네트워크 인터페이스에서 VPC 흐름 로그를 구성
  → VPC Flow Logs를 통해 ENI(Elastic Network Interface) 단위 트래픽 모니터링 가능
• C. 작업 정의에서 awsvpc 네트워크 모드를 지정
  → awsvpc 모드를 사용해야 ECS 작업(Task)별로 ENI가 생성되고 VPC Flow Logs로 추적 가능

❌ 오답 해설

• A. CloudWatch Logs 구성
  → 애플리케이션 로그 모니터링은 가능하지만, 네트워크 트래픽 모니터링 불가
• D. 브리지 네트워크 모드
  → 컨테이너 단위 네트워크 분리만 제공, ENI 단위 모니터링 불가
• E. 호스트 네트워크 모드
  → EC2 인스턴스 네트워크 공유, 개별 Task 추적 불가

📊 해설

• ECS 작업 간 트래픽을 네트워크 인터페이스 단위로 모니터링하려면:
  1. awsvpc 네트워크 모드 → ECS Task마다 고유 ENI 부여
  2. VPC Flow Logs 활성화 → ENI의 트래픽 흐름 기록

📈 다이어그램 (Mermaid)

```mermaid
flowchart TD
    ECS["ECS 작업: Task"] --> ENI["탄력적 네트워크 인터페이스: ENI"]
    ENI --> VPCFlow["VPC Flow Logs: 트래픽 기록"]
    VPCFlow --> CloudWatch["CloudWatch Logs 및 Insights 분석"]

```

 

📌 핵심 키워드

• awsvpc 모드 → Task별 ENI 할당
• VPC Flow Logs → 네트워크 트래픽 기록
• CloudWatch Logs는 애플리케이션 로그용, 네트워크 모니터링과는 다름

📘 오답노트 - Q152

✅ 문제 요약

• 상황: SysOps 관리자가 Amazon CloudFront 배포의 캐시 적중률(Cache Hit Ratio)이 10% 미만임을 확인.
• 목표: 캐시 적중률을 높이기 위한 구성 변경 (2개 선택).

✅ 정답

A, E

• A. 캐시 동작 설정에서 필요한 쿠키, 쿼리 문자열 및 헤더만 전달되도록 확인
  → 불필요한 요청 변수를 캐시에 포함시키면 캐시 분산이 일어나 캐시 효율이 떨어짐. 필요한 항목만 전달하면 캐시 적중률이 상승.
• E. 캐시 동작 설정에서 CloudFront TTL(Time to Live) 설정을 늘림
  → TTL을 늘리면 캐싱된 객체가 더 오래 유지되어 원본 요청 횟수를 줄이고 캐시 적중률을 높일 수 있음.

❌ 오답 해설

• B. HTTPS만 사용하도록 뷰어 프로토콜 정책 변경
  → HTTPS는 보안 관련 설정이지 캐시 적중률과 직접적 관련 없음.
• C. 서명된 쿠키와 URL 사용
  → 액세스 제어(보안) 관련 기능으로 캐시 성능에는 영향을 주지 않음.
• D. 객체 자동 압축 활성화
  → 네트워크 전송 효율성을 개선할 뿐 캐시 적중률 자체는 높이지 않음.

📊 해설

CloudFront 캐시 적중률 향상 핵심 전략:

1. 쿼리 문자열, 헤더, 쿠키 관리 → 캐시 분산을 최소화.
2. TTL 조정 → 캐시 유지 시간을 늘려 원본 요청 감소.

📈 다이어그램 (Mermaid)

```mermaid
flowchart TD
    User[사용자 요청] --> CF[CloudFront 배포]
    CF -->|쿠키/쿼리/헤더 최소화| Cache[캐시 히트 ↑]
    CF -->|TTL 증가| Cache
    Cache --> Origin[원본 요청 감소]
```

📌 핵심 키워드

• 캐시 적중률(Cache Hit Ratio) = (캐시 히트 수 / 전체 요청 수) × 100
• 캐시 적중률 저하 원인: 불필요한 변수 포함, TTL 짧음
• 해결책: 필요한 변수만 캐시에 전달 + TTL 연장

👉 이 문제는 CloudFront 최적화에서 캐시 적중률 관리를 묻는 대표적인 유형이에요.

📘 오답노트 - Q157

✅ 문제 요약

• 환경:
  • ALB 뒤에 2개의 EC2 인스턴스에서 웹 애플리케이션 실행
  • Amazon RDS 다중 AZ DB 사용
  • Amazon Route 53 → 동적 콘텐츠는 로드 밸런서로, 정적 콘텐츠는 S3 버킷으로 라우팅
• 문제:
  • 웹사이트 로딩 시간이 길어져 성능 개선 필요

✅ 정답

A, D

• A. 정적 콘텐츠에 대해 Amazon CloudFront 캐싱 추가
  → 정적 콘텐츠(S3 버킷에 저장된 파일 등)를 전 세계 엣지 로케이션에 캐싱하면 지연 시간이 줄고 성능이 크게 향상됨.
• D. 웹 서버용 Amazon EC2 Auto Scaling 구현
  → 동적 콘텐츠는 ALB 뒤 EC2 인스턴스에서 처리되므로 트래픽 증가 시 Auto Scaling을 적용해야 안정적 성능을 유지 가능.

❌ 오답 해설

• B. 로드 밸런서 리스너를 HTTPS에서 TCP로 변경
  → HTTPS는 애플리케이션 계층 보안, TCP는 전송 계층. 보안 및 성능 개선과 무관.
• C. Amazon Route 53 지연 시간 기반 라우팅 활성화
  → 이미 동적은 ALB, 정적은 S3로 라우팅되고 있음. 캐싱/스케일링 문제 해결과는 직접적 관련 없음.
• E. Amazon S3의 정적 콘텐츠를 웹 서버로 이동
  → 오히려 EC2에 부담 증가, 성능 저하로 이어짐. 정적 콘텐츠는 S3 + CloudFront가 가장 효율적.

📊 해설

성능 문제를 해결하려면:

1. 정적 콘텐츠 → CloudFront 캐싱 (엣지 로케이션에서 제공 → 빠른 응답)
2. 동적 콘텐츠 → Auto Scaling (트래픽 급증 시 서버 확장)

📈 다이어그램 (Mermaid)

 

```mermaid
flowchart TD
    User[사용자 요청] --> Route53[Amazon Route 53]
    Route53 -->|정적 콘텐츠| CF[CloudFront 캐싱] --> S3[Amazon S3 버킷]
    Route53 -->|동적 콘텐츠| ALB[Application Load Balancer]
    ALB --> EC2[Auto Scaling된 EC2 인스턴스 그룹]
    EC2 --> RDS[(Amazon RDS 다중 AZ DB)]

```

 

📌 핵심 키워드

• CloudFront 캐싱: 정적 콘텐츠 성능 최적화
• Auto Scaling: 동적 콘텐츠 트래픽 대응
• ALB + RDS 멀티 AZ: 가용성과 안정성 확보

👉 이 문제는 실무에서도 자주 나오는 정적/동적 콘텐츠 성능 최적화 패턴이에요.

📘 오답노트 - Q181

✅ 문제 요약

• 글로벌 게임 회사가 AWS에서 새로운 게임 출시 준비 중
• 게임은 여러 AWS 리전에 배포된 EC2 인스턴스 집합에서 실행
• 인스턴스는 ALB + Auto Scaling 그룹 뒤에 위치
• Amazon Route 53을 DNS 서비스로 사용 계획
• 요구사항:
  1. 가장 가까운 리전으로 사용자 라우팅
  2. 리전 장애 시 자동으로 다른 리전으로 트래픽 전환

✅ 정답

A, D

• A. 각 지역의 ALB 상태를 모니터링하는 CloudWatch 경보 → Route 53 DNS 장애 조치 연결
  → 특정 리전의 ALB가 비정상일 경우 Route 53이 자동으로 다른 리전으로 트래픽을 전환
• D. Route 53 지리 근접 라우팅 구성
  → 사용자를 가장 가까운 리전으로 안내하여 성능(지연 시간 최소화) 보장

❌ 오답 해설

• B. EC2 인스턴스 상태 기반 CloudWatch 경보 + Route 53 장애 조치
  → EC2 개별 인스턴스가 아니라 ALB 단위로 상태 확인을 해야 전체 서비스의 정상 여부를 판단 가능
• C. 리전별 EC2 프라이빗 IP 모니터링 + Route 53 장애 조치
  → 프라이빗 IP는 외부 DNS 트래픽 라우팅과 직접적인 연관이 없음
• E. Route 53 단순 라우팅
  → 단순 라우팅은 장애 조치 불가능, 리전 장애 시 트래픽 우회 기능이 없음

📊 해설

성능 + 가용성을 동시에 충족시키려면:

1. 지리 근접 라우팅(Geolocation / Geoproximity) → 사용자를 가장 가까운 리전으로 연결
2. ALB 상태 모니터링 기반 장애 조치 → 리전 단위 서비스 장애 발생 시 다른 리전으로 트래픽 전환

📈 다이어그램 (Mermaid)

 

```mermaid
flowchart TD
    User[글로벌 사용자] --> Route53[Amazon Route 53 DNS]

    Route53 -->|"지리 근접 라우팅"| ALB1[리전 A - ALB + Auto Scaling]
    ALB1 --> AppA[애플리케이션 서비스 A]

    Route53 -->|"지리 근접 라우팅"| ALB2[리전 B - ALB + Auto Scaling]
    ALB2 --> AppB[애플리케이션 서비스 B]

    %% 장애 조치 서브그래프 (세로 정렬)
    subgraph FailoverFlow["장애 조치"]
        CW[CloudWatch - ALB 상태 확인]
        CW --> Route53
        Route53 -->|"ALB 장애 발생 시"| Failover[다른 리전으로 트래픽 전환]
    end
```

 

📌 핵심 키워드

• Route 53 지리 근접 라우팅 → 성능 최적화 (사용자 → 가까운 리전)
• Route 53 장애 조치 + ALB 상태 확인 → 고가용성 확보

👉 이 문제는 글로벌 애플리케이션 배포 전략의 전형적인 사례예요.

📘 오답노트 - Q231

✅ 문제 요약

• SysOps 관리자가 더 이상 사용하지 않는 AWS CloudFormation 스택을 삭제해야 함
• 현재 스택 상태: DELETE_FAILED
• 원인 파악이 필요

✅ 정답

D, E

• D. 스택에는 보안 그룹과 연결된 추가 리소스가 있다
  → 보안 그룹은 다른 리소스에서 참조 중일 경우 삭제할 수 없음
• E. 스택에 여전히 객체를 포함하는 Amazon S3 버킷이 있다
  → S3 버킷이 비워지지 않으면 CloudFormation이 자동 삭제 불가

❌ 오답 해설

• A. 삭제 시간이 너무 길어 완료 불가
  → 시간 문제로 인해 DELETE_FAILED 상태가 발생하지 않음. (재시도 시 보통 정상 진행됨)
• B. 중첩 스택이 포함됨
  → 중첩 스택은 상위 스택 삭제 시 함께 삭제 가능, DELETE_FAILED의 일반적인 원인 아님
• C. --disable-rollback 옵션 사용
  → 이는 스택 생성 실패 시 롤백하지 않는 옵션으로, 삭제 실패와 직접적인 관련 없음

📊 해설

CloudFormation에서 DELETE_FAILED 상태의 대표적인 원인은:

1. 종속성 문제 (Dependency): 다른 리소스가 참조 중인 경우 (예: 보안 그룹, VPC, ENI 등)
2. 수동 정리 필요 리소스: CloudFormation이 자동 삭제 못 하는 리소스 (예: 객체가 남아 있는 S3 버킷, 수동 종료가 필요한 Lambda 연결, EC2 EBS 볼륨 등)

즉, 관리자가 직접 리소스를 정리한 후 스택 삭제 재시도해야 함.

📈 다이어그램 (Mermaid)

```mermaid
flowchart TD
    CF[CloudFormation 스택 삭제 시도] --> Check[리소스 상태 확인]
    Check --> SG[보안 그룹 참조 중] --> Fail[DELETE_FAILED 발생]
    Check --> S3[S3 버킷 안에 객체 존재] --> Fail
    Fail --> Action[수동 정리 필요 → 다시 스택 삭제 시도]

```

📌 핵심 키워드

• DELETE_FAILED 원인:
  • 보안 그룹 참조 중 → 삭제 불가
  • 비워지지 않은 S3 버킷 존재 → 삭제 불가
• 해결: 문제 리소스 수동 삭제 or 해제 후 스택 재삭제

📘 오답노트 - Q254

✅ 문제 요약

• 미국 리전에 있는 S3 버킷에 유럽과 호주 지사에서 대용량 비디오 파일 업로드
• 업로드 시 지연(latency) 발생
• 목표: 비용 효율적이고 빠른 업로드 방법

✅ 정답

C, E

• C. Amazon S3 Transfer Acceleration 사용
  → S3 Transfer Acceleration은 글로벌 엣지 로케이션을 활용하여 지리적으로 멀리 있는 클라이언트도 S3 버킷에 빠르게 업로드 가능
• E. 멀티파트 업로드 사용
  → 대용량 파일을 여러 파트로 분할하여 병렬 업로드 → 전송 속도 향상 및 네트워크 오류 시 재전송 효율적

❌ 오답 해설

• A. Direct Connect
  → 전용선 구축은 비용이 매우 높고 지사별 구축은 비효율적
• B. Site-to-Site VPN
  → VPN은 보안 통신을 제공할 뿐, 업로드 속도를 획기적으로 개선하지 않음
• D. Global Accelerator
  → TCP/UDP 트래픽 최적화 서비스이지만 S3 전용 업로드 가속에는 사용하지 않음 (S3 Transfer Acceleration이 맞는 서비스)

📊 해설

S3에 원거리에서 빠른 업로드를 원할 때 가장 효율적인 방법은:

1. Amazon S3 Transfer Acceleration
   • CloudFront 엣지 로케이션을 통해 글로벌 최적 경로로 전송
   • 별도 전용선 불필요, 비용 효율적
2. 멀티파트 업로드
   • 병렬 전송으로 대용량 파일 업로드 속도 및 안정성 향상

📈 다이어그램 (Mermaid)

```mermaid
flowchart TD
    User[유럽/호주 사용자] --> Edge[CloudFront 엣지 로케이션]
    Edge --> S3[S3 버킷: 미국 리전]
    
    %% Transfer Acceleration 설명 노드
    Edge -.-> NoteTA[Transfer Acceleration 적용]

    User -->|"멀티파트 업로드"| Parallel[병렬 전송]
    Parallel --> S3
```

📌 핵심 키워드

• Transfer Acceleration → 지리적으로 멀리 있는 클라이언트의 업로드 가속화
• 멀티파트 업로드 → 대용량 파일을 빠르고 안정적으로 업로드

📘 오답노트 - Q259

✅ 문제 요약

• 단일 Amazon RDS DB 인스턴스 사용
• 읽기 트래픽 과다로 DB 리소스가 과도하게 사용됨
• 목표: RDS 성능 향상

✅ 정답

A, B

• A. 읽기 전용 복제본 추가
  → RDS Read Replica를 통해 읽기 트래픽을 분산하여 성능 개선
• B. Amazon ElastiCache (Memcached/Redis) 사용
  → 자주 조회되는 데이터를 캐시하여 DB 부하를 줄임

❌ 오답 해설

• C. RDS → DynamoDB 마이그레이션
  → 구조적인 변경 필요, 운영 중 서비스에는 부적합
• D. RDS → EC2로 마이그레이션
  → 관리 부담 증가, 확장성과 성능 최적화 측면에서 적절하지 않음
• E. 다중 AZ 배포
  → 가용성(HA) 향상 목적이지 성능 최적화 목적 아님

📊 해설

읽기 트래픽으로 인한 성능 저하 해결 방안은:

1. 읽기 전용 복제본(Read Replica)
   • 읽기 요청을 분산하여 성능 최적화
2. 캐싱(ElastiCache)
   • 빈번한 읽기 요청을 DB 대신 캐시에서 처리

📈 다이어그램 (Mermaid)

```mermaid
flowchart TD
    Client[클라이언트] --> App[애플리케이션]
    App --> Cache["ElastiCache: Redis 또는 Memcached"]
    App --> RDS[RDS DB 인스턴스]
    RDS --> Replica1[읽기 전용 복제본 1]
    RDS --> Replica2[읽기 전용 복제본 2]

    %% Note를 별도 노드로 추가
    Cache -.-> NoteCache[자주 조회되는 데이터<br/>DB 부하 감소]
```​

📌 핵심 키워드

• RDS Read Replica → 읽기 트래픽 분산
• Amazon ElastiCache → 캐시 활용으로 성능 최적화
• Multi-AZ → 고가용성, 성능 개선과 직접적 관련 없음

📘 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” 패턴을 반드시 기억하면 풀 수 있습니다.

ㅇ