📘 오답노트 - Q201

❓ 문제 요약

• 웹 애플리케이션은 CloudFront 배포와 ALB를 통해 접근 가능해야 함.
• 조건: ALB를 통해서만 접근 가능하도록 해야 함.
• 요구사항: 코드 수정 없이 적용할 수 있는 솔루션.

✅ 정답

D. 배포 원본에 사용자 정의 HTTP 헤더 추가 + ALB 리스너 규칙으로 헤더 검사 후 없는 경우 403 반환.

• CloudFront → ALB로 요청 전달 시, 특정 HTTP 헤더를 자동 추가.
• ALB에서 해당 헤더 값이 없으면 요청을 거부(403 Forbidden).
• 즉, CloudFront를 통해 들어오는 요청만 ALB 접근 허용 가능.
• 코드 변경 필요 없음 → 관리자가 ALB와 CloudFront 설정으로 해결 가능.

❌ 오답 해설

• A. ALB 유형 변경
  → 단순히 ALB 도메인 이름 설정으로는 CloudFront 전용 접근을 강제할 수 없음.
• B. Lambda@Edge 함수 생성
  → 동작은 가능하나 코드 작성 및 배포 필요 → 문제 조건(코드 변경 없이) 위배.
• C. ALB 교체 + 헤더 설정
  → ALB를 교체할 필요 없음. 불필요하게 복잡.

📊 비교 요약

🌐 동작 흐름 (Mermaid)

```mermaid
flowchart TD
    User["🌍 사용자 요청"] --> CF["🌐 CloudFront 배포"]
    CF -->|"📝 HTTP 헤더 추가"| ALB["⚖️ Application Load Balancer"]
    ALB -->|"✅ 헤더 검증 성공"| App["💻 웹 애플리케이션"]
    ALB -->|"❌ 헤더 없음 → 403 Forbidden"| Block["🚫 접근 차단"]
```

📊 결과 설명

• 🌍 사용자 요청 → 🌐 CloudFront 배포
• CloudFront가 📝 HTTP 헤더 추가 후 ALB로 전달
• ALB에서
  • ✅ 헤더 검증 성공 → 💻 웹 애플리케이션 연결
  • ❌ 헤더 없음 → 🚫 접근 차단 (403 Forbidden)

🎯 핵심 정리

• CloudFront 전용 접근 보장 방법 = 사용자 정의 헤더 + ALB 리스너 규칙.
• Lambda@Edge로도 가능하지만, 코드 수정 필요하므로 조건 불일치.

📘 오답노트 - Q204

❓ 문제 요약

• Amazon EC2 애플리케이션이 Amazon RDS for PostgreSQL DB를 사용.
• 회사 요구사항: DB 연결은 모두 암호화(SSL) 해야 함.
• SysOps 관리자가 어떤 조치를 취해야 할까?

✅ 정답

C. 사용자 지정 매개변수 그룹을 사용하여 데이터베이스에 대한 SSL 연결을 적용합니다.

• Amazon RDS에서 SSL/TLS를 강제하려면 DB Parameter Group에서 rds.force_ssl = 1 로 설정해야 함.
• 이렇게 하면 모든 클라이언트 연결이 SSL을 사용하지 않으면 거부됨.
• 따라서 DB 연결 암호화 요구사항 충족.

❌ 오답 해설

• A. 인바운드 보안 그룹 규칙
  → 보안 그룹은 단순히 포트/프로토콜 접근 제어만 가능. SSL 암호화 강제 불가.
• B. AWS KMS 암호화 키 사용
  → KMS는 데이터 저장 시 암호화(at rest) 용도.
  → 여기서는 전송 중 암호화(in transit) 요구사항이므로 적합하지 않음.
• D. PostgreSQL 확장 사용
  → 확장으로 SSL/TLS 강제를 구현하는 방법은 AWS RDS 관리형 환경에서 불필요하고 지원되지 않음.

📊 비교 요약

🌐 동작 흐름 (Mermaid)

```mermaid
flowchart TD
    App["💻 애플리케이션 (EC2)"] -->|"🔐 SSL 요청"| RDS["🗄️ Amazon RDS: PostgreSQL"]
    RDS -->|"✅ SSL 인증 필수"| Accept["🟢 연결 허용"]

    App -.->|"❌ Non-SSL 요청"| RDS
    RDS -.-> Block["🚫 연결 거부"]
```

📊 결과 설명

• 💻 EC2 애플리케이션 → 🔐 SSL 요청 → 🗄️ RDS (PostgreSQL)
  • SSL 인증이 필수이므로 → 🟢 연결 허용
• 만약 ❌ Non-SSL 요청이라면 → 🚫 연결 거부

🎯 핵심 정리

• 요구사항: DB 연결 암호화(in transit).
• 해결 방법: DB Parameter Group에서 SSL 강제 적용.
• 따라서 정답은 C.

👉 Q204는 네트워크 보안과 데이터베이스 보안을 동시에 고려하는 문제

📘 오답노트 - Q210

❓ 문제 요약

• 회사는 Active-Active(활성-수동 구성) 으로 두 개 리전에 애플리케이션 배포.
• 각 리전: ALB + EC2 Auto Scaling 으로 구성.
• DNS는 Amazon Route 53 사용.
• 요구사항: 보조 리전에서 자동 장애 조치(Failover) 수행 가능해야 함.

✅ 정답

A. 각 ALB를 가리키는 Route 53 별칭 레코드를 구성하고, 장애 조치 라우팅 정책을 선택. 대상 상태 평가를 예로 설정.

• Route 53의 Failover Routing Policy 를 사용하면
  • Primary ALB와 Secondary ALB를 등록 가능.
  • Primary 상태가 비정상이면 자동으로 Secondary로 라우팅.
• 상태 체크(Health Check)를 기반으로 장애 조치를 수행함.

❌ 오답 해설

• B. CNAME 레코드 구성
  → 단순 CNAME은 Failover 기능 제공하지 않음. 단순 매핑만 가능.
• C. ELB 상태 확인 추가
  → ELB 상태 확인은 로드밸런서 내부에서만 동작. 리전 간 장애 조치와 직접 관련 없음.
• D. EC2 상태 확인 추가
  → 개별 EC2 인스턴스 상태 체크는 리전 장애 상황을 커버하지 못함. (ALB 단위 Failover 필요)

📊 비교 요약

🌐 장애 조치 흐름 (Mermaid)

```mermaid
flowchart TD
    User["🌍 사용자 요청"] --> Route53["🌐 Amazon Route 53"]
    Route53 -->|"✅ 헬스 체크 정상"| ALB1["⚖️ Primary ALB: 리전1"]
    Route53 -->|"❌ 헬스 체크 실패"| ALB2["⚖️ Secondary ALB: 리전2"]

    ALB1 --> EC2A["💻 리전1 EC2 Auto Scaling"]
    ALB2 --> EC2B["💻 리전2 EC2 Auto Scaling"]
```

📊 결과 설명

• 🌍 사용자 요청 → 🌐 Route 53
• Route 53 헬스 체크 결과:
  • ✅ 정상 → ⚖️ Primary ALB (리전1) → 💻 리전1 EC2 Auto Scaling
  • ❌ 실패 → ⚖️ Secondary ALB (리전2) → 💻 리전2 EC2 Auto Scaling

🎯 핵심 정리

• Route 53 Failover Routing Policy 사용해야 자동 장애 조치 가능.
• 상태 체크 결과에 따라 Primary → Secondary로 트래픽 자동 전환.

📘 오답노트 - Q211

❓ 문제 요약

• 회사는 머신러닝 기반 모니터링 솔루션 사용 중.
• 솔루션은 Amazon EventBridge(CloudWatch Events) 이벤트를 이용함.
• 문제: 이벤트가 수신되지 않음 → 규칙은 호출되지만 세부 오류 정보 부족.
• 요구사항: 운영 오버헤드를 최소화하면서 클라이언트 오류 세부 정보 검색 가능해야 함.

✅ 정답

B. Amazon Simple Queue Service(Amazon SQS) 표준 대기열을 대상으로 배달 못한 편지(Dead-letter queue, DLQ)를 대기열로 추가. 오류 세부 정보를 검색하려면 배달 못한 편지 대기열의 메시지를 처리

• EventBridge → SQS 대기열로 이벤트 전달.
• 처리 실패 시 Dead-letter Queue(DLQ) 에 메시지가 저장됨.
• DLQ 메시지를 확인하여 오류 원인 세부 정보를 분석 가능.
• 운영 오버헤드 최소화 + 내구성 있는 이벤트 보관 가능.

❌ 오답 해설

• A. EventBridge 아카이브 생성 후 재생
  → 이벤트 재생은 과거 이벤트 재처리에 유용하지만, 세부 오류 원인 파악과는 무관.
• C. Lambda 함수로 CloudWatch Logs 기록
  → 로그는 단순 저장일 뿐, 실패 이벤트를 구조적으로 분석하기 어려움.
• D. SNS 주제로 알림 발송
  → 단순 알림으로 오류 발생 사실만 전달. 세부 원인 추적 불가.

📊 비교 요약

🌐 동작 흐름 (Mermaid)

```mermaid
flowchart TD
    EventBridge["🪢 Amazon EventBridge: 이벤트"] --> SQS["📬 Amazon SQS: 대기열"]

    SQS -->|"✅ 정상 처리"| Monitoring["🤖 머신러닝 모니터링 솔루션"]
    SQS -->|"❌ 처리 실패"| DLQ["📦 Dead-letter Queue: SQS"]

    DLQ --> Admin["👨‍💻 관리자: 오류 메시지 분석"]
```

📊 결과 설명

• 🪢 EventBridge 가 이벤트 발생 → 📬 SQS 대기열에 전달
• SQS 메시지 처리 결과:
  • ✅ 정상 처리 → 🤖 머신러닝 모니터링 솔루션
  • ❌ 실패 → 📦 Dead-letter Queue (DLQ) 로 이동
• 이후 👨‍💻 관리자가 오류 메시지 분석 수행

🎯 핵심 정리

• EventBridge 이벤트 처리 실패 시, DLQ(SQS Dead-letter Queue) 로 보관.
• DLQ 메시지를 통해 세부 오류 원인 파악 가능.
• 운영 오버헤드를 최소화하는 최적의 방식 

📘 오답노트 - Q215

❓ 문제 요약

• 회사의 AWS Lambda 함수에 성능 문제가 발생.
• Lambda 함수는 CPU 집약적 작업을 수행 중.
• 증상: 실행 속도가 충분히 빠르지 않고, 시스템 병목 현상 발생.
• 해결책은?

✅ 정답

C. Lambda 함수의 메모리 양을 늘린다.

• AWS Lambda에서는 메모리 크기를 늘리면 CPU와 네트워크 대역폭도 비례해서 증가.
• CPU 집약적 작업일 경우, 메모리 설정을 높여주면 성능이 개선됨.
• 간단하면서도 즉각적인 성능 최적화 방법.

❌ 오답 해설

• A. CPU 시작 옵션에서 하이퍼스레딩 활성화
  → Lambda에는 하이퍼스레딩 같은 직접 CPU 옵션 제어 불가.
• B. AWS 관리 암호화를 끄기
  → 암호화 여부는 보안 관련 설정이며 성능 병목과 관계 없음.
• D. 코드 레이어에 필요한 코드 로드
  → 레이어는 코드 관리 방식 최적화일 뿐, CPU 사용량 문제 해결 불가.

📊 비교 요약

🌐 동작 원리 (Mermaid)

```mermaid
flowchart TD
    User["🌍 사용자 요청"] --> Lambda["🟦 AWS Lambda 함수"]
    Lambda -->|"⚙️ CPU 집약적 작업"| Execution["🖥️ 실행 환경"]
    Execution -->|"📈 메모리 증가 시"| CPU["🔧 더 많은 vCPU 및 🌐 네트워크 대역폭"]
    CPU --> Faster["⚡ 빠른 실행 속도 + 🚀 성능 개선"]

```

📊 결과 설명

• 🌍 사용자 요청 → 🟦 Lambda 함수 실행
• Lambda에서 ⚙️ CPU 집약적 작업을 실행 환경으로 전달
• 메모리 증가 시 → 🔧 vCPU와 🌐 네트워크 대역폭 자동 확장
• 최종적으로 ⚡ 실행 속도 향상 + 🚀 성능 개선

🎯 핵심 정리

• Lambda는 메모리와 CPU가 비례해서 할당됨.
• CPU 병목 발생 시, 메모리를 늘리면 CPU 성능도 같이 향상.
• 따라서 정답은 C. Lambda 함수의 메모리 양을 늘린다.

📘 오답노트 - Q430

❓ 문제 요약

• 회사는 기존 Amazon Route 53 프라이빗 호스팅 영역을
  새로 생성한 VPC에 적용하려고 함.
• 목표: VPC 내부에서 사용자 정의 리소스 이름을 확인 가능하게 만드는 것.

✅ 정답

A. Route 53 프라이빗 호스팅 영역을 VPC와 연결한다.

• 프라이빗 호스팅 영역은 해당 VPC 내부에서만 DNS 쿼리를 처리 가능.
• 따라서, 단순히 새 VPC를 생성하는 것만으로는 동작하지 않고
  → 반드시 호스팅 영역을 VPC와 연결(Associate) 해야 함.

❌ 오답 해설

• B. Resolver에 대한 보안 그룹 규칙 생성
  → Route 53 Resolver는 프라이빗 호스팅 영역 사용과 직접적 관련 없음.
• C. VPC ACL 확인
  → ACL은 네트워크 트래픽 제어용이며, DNS 이름 확인 기능을 제공하지 않음.
• D. 라우팅 테이블 경로 확인
  → 경로(Route)는 IP 트래픽 전달 제어이지, DNS 이름 확인과 무관.

📊 비교 요약

🌐 동작 흐름 (Mermaid)

```mermaid
flowchart TD
    CreateVPC["🆕 새 VPC 생성"] --> Associate["🔗 Route 53 Private Hosted Zone 연결"]
    Associate --> DNSQuery["🔍 VPC 내부 DNS 쿼리 가능"]
    DNSQuery --> Success["✅ 사용자 정의 리소스 이름 확인 성공 🎉"]

```

📊 결과 설명

• 🆕 새 VPC 생성 → 🔗 Route 53 Private Hosted Zone 연결
• 연결 후 🔍 VPC 내부에서 DNS 쿼리 가능
• 최종적으로 ✅ 사용자 정의 리소스 이름 확인 성공 🎉

🎯 핵심 정리

• Route 53 프라이빗 호스팅 영역은 반드시 VPC와 연결해야 DNS 질의 처리 가능.
• 네트워크 ACL / 라우팅 테이블 / 보안 그룹은 네트워크 계층 트래픽 제어용이지, DNS와 직접적인 관계 없음.

👉 이 문제는 Q200, Q363 같이 VPC + Route 53 DNS Resolver 관련 문제와 묶어두면,
“DNS 이름 확인을 위해서는 → 프라이빗 호스팅 영역 연결 or Resolver 엔드포인트 구성 필요” 라는 패턴으로 정리하기 좋습니다.

📘 오답노트 - Q434

❓ 문제 요약

• 회사는 MariaDB 다중 AZ 배포의 Amazon RDS 사용 중.
• 계획된 유지 관리 이벤트(예: 패치, 장애 조치) 시 몇 분 동안 DB 장애가 발생하여 애플리케이션 사용 불가.
• 목표: 애플리케이션의 자동 중지 시간을 최소화.

✅ 정답

D. 데이터베이스와 연결된 RDS 프록시를 생성한다.

• RDS Proxy는 DB와 애플리케이션 사이에서 연결 풀을 관리.
• 장애 조치(Failover) 발생 시, 애플리케이션 연결을 유지하고 새로운 DB 인스턴스로 빠르게 전환 가능.
• 따라서 자동 중지 시간(다운타임) 단축에 최적.

❌ 오답 해설

• A. 여러 라이터 인스턴스 MariaDB RDS 생성
  → MariaDB는 기본적으로 단일 라이터 구조. Aurora와 달리 Multi-Master를 지원하지 않음.
• B. 유휴 연결 풀링 설정
  → 단순 풀링은 DB 연결 유지에는 도움이 되지만, 장애 조치 시 연결 자동 전환 불가.
• C. ElastiCache 캐시 구성
  → 읽기 성능 개선에는 유효하지만, DB 장애 조치 시 중지 시간을 줄이는 데는 직접적인 도움 없음.

📊 비교 요약

🌐 동작 흐름 (Mermaid)

 

```mermaid
flowchart TD
    App["💻 애플리케이션"] --> Proxy["🔗 RDS Proxy: 연결 풀 관리"]
    Proxy --> DB1["🗄️ DB 인스턴스 A"]
    Proxy --> DB2["🗄️ DB 인스턴스 B: Failover"]
    DB1 -.->|"⚠️ Failover 발생"| DB2
    Proxy --> AppResponse["✅ 연결 유지, 다운타임 최소화 🎉"]
```

📊 결과 설명

• 💻 애플리케이션 → 🔗 RDS Proxy 를 통해 DB 연결 관리
• RDS Proxy는 🗄️ DB 인스턴스 A (기본)와 🗄️ DB 인스턴스 B (Failover용) 을 연결
• ⚠️ Failover 발생 시 A → B 로 전환
• 최종적으로 ✅ 연결 유지, 다운타임 최소화 🎉

🎯 핵심 정리

• RDS Proxy는 장애 조치 시 연결 풀을 관리하여 애플리케이션 다운타임을 최소화한다.
• ElastiCache는 읽기 성능 향상 목적이지, 장애 조치 복구와는 별개.
• MariaDB 다중 AZ 환경에서 자동 중지 시간 최소화 문제 → RDS Proxy가 정답.

📘 오답노트 - Q453

❓ 문제 요약

• 회사는 AWS 계정 지출을 추적해야 함.
• 실제 비용이나 예상 비용이 특정 임계값 초과 시 알림을 받아야 함.
• 조건: 운영 오버헤드가 가장 적은 솔루션 필요.

✅ 정답

D. AWS 예산(Budgets)에서 반복 비용 예산을 작성하고, 실제/예상 비용에 대한 알림을 구성한다.

• AWS Budgets는 비용과 사용량에 대해 임계값 기반 알림을 제공.
• SNS(Amazon Simple Notification Service)와 연계해 이메일/SMS/주제 구독 형태로 알림 발송 가능.
• 운영 오버헤드가 가장 낮고 AWS에서 권장하는 솔루션.

❌ 오답 해설

• A. IAM 역할 + Cost Explorer 모니터링
  → Cost Explorer는 분석/리포트 용도이며 실시간 알림 제공 불가.
• B. Predict + Lambda
  → Amazon Predict는 오래된 서비스이며 비용 추적과는 관련 없음. 과도한 복잡성.
• C. 비용 보고서 + SNS 예약
  → 비용 및 사용 보고서는 CSV 형태 리포트이며 실시간 알림 불가. SNS로 직접 알림 연동도 안 됨.

📊 비교 요약

🌐 동작 흐름 (Mermaid)

```mermaid
flowchart TD
    Cost["💰 AWS 비용 및 예상 비용 추적"] --> Budgets["📊 AWS Budgets: 예산 임계값 설정"]
    Budgets -->|"⚠️ 임계값 초과"| SNS["📨 Amazon SNS: 알림 전송"]
    SNS --> Email["📧 이메일 / SMS 알림 수신"]
```

📊 결과 설명

• 💰 비용 및 예상 비용 추적
• → 📊 AWS Budgets 에서 임계값 설정
• → ⚠️ 임계값 초과 시 📨 SNS 알림 전송
• → 최종적으로 📧 이메일/SMS로 알림 수신

🎯 핵심 정리

• 비용 임계값 초과 시 자동 알림 = AWS Budgets + SNS 연계가 정답.
• Cost Explorer/보고서 기반은 수동 확인 용도.
• 운영 오버헤드 최소화, 실시간 알림 필요 → Budgets 사용이 Best Practice.

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

• 시험 비중은 작지만 🚨
• 실제 회사에서는 돈을 아끼고(비용 최적화),
  빠르게 잘 돌아가게(성능 최적화) 하는 게 아주 중요해요.

👉 비유:

• 비용 최적화 = 용돈 절약 🪙
• 성능 최적화 = 시험 공부할 때 빠르고 효율적인 방법 찾기 ✏️

• AWS Trusted Advisor = 선생님 조언 👩‍🏫 (낭비하는 리소스 알려줌)
• Cost Explorer = 가계부 📒 (돈이 어디에 쓰였는지 확인)
• AWS Budgets = 용돈 한도 설정 💵 (넘으면 알림)
• 태그(Tag) = 이름표 붙이기 🏷️ (부서별, 프로젝트별 비용 추적)
• 스팟 인스턴스 = 땡처리 세일 상품 🛒 (싸지만 언제 사라질 수 있음)
• 예약 인스턴스/저장용량 예약 = 정기권 🎫 (장기 이용 시 할인)
• 관리형 서비스 (RDS, Fargate, EFS) = 학원 버스 🚌 (직접 운전 안 해도 됨 → 시간·돈 절약)

• EC2 인스턴스 종류 = 운동선수 선택 🏃‍♂️ (달리기, 수영, 씨름 선수처럼 필요에 맞게 선택)
• 향상된 네트워킹 / 배치 그룹 = 초고속 도로 🛣️ (빠른 데이터 통신)
• EBS 지표 확인 = 건강검진 결과 📊 (디스크 상태, 속도 확인)
• S3 Transfer Acceleration = 택배 항공편 ✈️ (멀리서도 빠르게 전송)
• S3 멀티파트 업로드 = 레고 블록 조립 🧱 (큰 파일을 조각내서 빨리 업로드)
• RDS 성능 지표 = 성적표 📑 (데이터베이스 상태 확인)
• RDS Proxy / 성능 개선 도우미 = 공부 과외 선생님 👨‍🏫 (효율적으로 연결 관리, 문제 알려줌)

📝 비용 태그(JSON 예시)

{
  "Key": "Project",     // 태그 이름: 어떤 프로젝트인지
  "Value": "ShoppingApp" // 태그 값: 쇼핑 앱 프로젝트
}

👉 설명: EC2나 S3 같은 리소스에 "이건 쇼핑앱 프로젝트용이야" 라고 이름표를 붙이는 것.
이렇게 하면 나중에 비용을 프로젝트별로 확인할 수 있어요.

💼 현업에서 어떻게 쓰일까?

1. 스타트업
   • 스팟 인스턴스 활용 → 개발 서버 비용 절감
2. 금융사
   • RDS Proxy → 동시에 많은 고객이 접속해도 빠르게 처리
3. 게임사
   • CloudFront + S3 Transfer Acceleration → 전 세계 게이머에게 업데이트 빠르게 전달
4. 대기업 IT팀
   • Cost Explorer + Budgets → 부서별 클라우드 비용 관리
   • 태그 붙여서 “마케팅팀” vs “개발팀” 비용 따로 확인
5. e커머스 회사
   • EBS 지표 보고 성능 부족하면 SSD 타입으로 교체 → 결제 지연 방지

🧾 정리

• 비용 최적화 = 돈 아끼기 (가계부, 세일 상품, 이름표 관리)
• 성능 최적화 = 빠르고 효율적으로 (초고속 도로, 택배 항공편, 과외 선생님)
• 시험 팁: 보안과 함께 비용·성능 최적화까지 고려된 답이 정답일 확률 ↑

• "더 빠르게 하려면 돈이 많이 든다" → 보통 이렇게 생각해요.
• 하지만 AWS에서는 비용(돈)과 성능(속도) 을 같이 최적화할 수 있어요!
• 즉, 똑똑하게 선택하면 빠르고 싸게 둘 다 잡을 수 있어요 😎

👉 비유:

• 비용 최적화 = 용돈 아껴 쓰기 🪙
• 성능 최적화 = 시험 문제 빨리 푸는 방법 찾기 ✏️

• AWS는 서버를 사는 게 아니라 빌리는 것 🏠
• 쓰고 싶을 때만 켜고, 다 쓰면 꺼서 요금 STOP! ⏹️

👉 예시:

• 6시간 필요한 작업 → EC2 켜서 딱 6시간만 사용

• 큰 숙제를 혼자 하면 6시간 ⏳
• 6명이 같이 하면 1시간만에 끝! 🙌
• AWS도 이렇게 병렬 처리(Parallel Workload) 를 지원해요.

👉 단점:

• 더 많은 컴퓨터(EC2)를 켜야 해서 순간 비용은 ↑
  👉 장점:
• 전체 시간 단축 → 결과적으로 효율적

• 마트에서 "땡처리 세일" 상품 사는 것과 같아요 🛒
• 싸게 빌릴 수 있지만, 언제 회수될지 몰라요.
• 긴급하지 않은 작업에 사용하면 비용 절약 👍

• EC2 인스턴스는 필요에 맞게 고를 수 있어요 🏋️‍♂️
  • 메모리 많은 서버? 🧠
  • CPU 파워 강한 서버? 💪
• 작업에 맞게 골라 쓰면 성능이 좋아져요.

📝 EC2 스팟 인스턴스 요청 JSON 예시

{
  "InstanceType": "m5.large",     // 인스턴스 종류 (중간 크기 서버)
  "SpotPrice": "0.05",            // 시간당 내가 낼 최대 가격 ($0.05)
  "InstanceCount": 3,             // 실행할 서버 개수 (3대)
  "Action": "request"             // 스팟 인스턴스 요청
}

🔎 한 줄씩 설명

• "InstanceType": "m5.large" → 필요한 서버 크기 선택
• "SpotPrice": "0.05" → "나는 5센트까지만 낼래!"
• "InstanceCount": 3 → 서버 3대 동시에 실행
• "Action": "request" → 스팟 인스턴스 요청 시작

👉 즉, "세일 서버 3대 주세요! 단, 5센트 이상이면 안 사요~" 라는 뜻이에요.

💼 현업에서 어떻게 쓰일까?

1. 연구소
   • 빅데이터 분석 작업을 병렬 처리 → 10시간 걸릴 걸 2시간 만에 끝냄
2. 게임 회사
   • 긴급하지 않은 테스트 서버는 스팟 인스턴스로 실행 → 비용 70% 절약
3. 금융사
   • RDS(데이터베이스) 지표 모니터링 → 성능 부족 시 빠른 업그레이드
4. 스타트업
   • AWS Budgets로 비용 초과 시 알람 → 클라우드 요금 폭탄 방지
5. e커머스
   • 큰 이미지 파일 업로드 시 S3 멀티파트 업로드 사용 → 업로드 실패 줄이고 성능 개선

🧾 정리

• AWS에서는 비용 절약과 성능 향상을 동시에 할 수 있어요.
• 👉 핵심 방법:
  • 필요할 때만 쓰기
  • 병렬 처리로 빨리 끝내기
  • 스팟 인스턴스로 절약
  • 작업에 맞는 인스턴스 선택

시험 문제에서도 항상 **“비용 + 성능 둘 다 고려된 답”**이 정답일 확률이 높습니다 ✅

• 네트워킹과 콘텐츠 전송은 시험 비중이 높고 광범위
• 학습 영역을 3개로 나누면 정리하기 쉬움
  1. 네트워킹 기능 및 연결 구현
  2. DNS 서비스 & 콘텐츠 전송 구성
  3. 네트워크 연결 문제 해결

• VPC (Virtual Private Cloud)
  • 서브넷, 라우팅 테이블, NACL, 보안 그룹
  • NAT 게이트웨이, 인터넷 게이트웨이
• 보안 연결
  • Systems Manager Session Manager (SSH 대체)
  • VPC 엔드포인트 (프라이빗 연결)
  • VPC 피어링, VPN 연결
• 보호 도구
  • AWS WAF (웹 방화벽)
  • AWS Shield (DDoS 방어)

• Amazon Route 53
  • 호스팅 영역, 레코드 관리
  • 라우팅 정책 (단순, 지연시간, 가중치, 장애조치 등)
• Amazon CloudFront + S3
  • 전 세계 CDN(콘텐츠 전송 네트워크) 구축
  • SSL/TLS 인증서(ACM)로 보안 강화
• 일반적인 DNS 구성
  • A 레코드, CNAME, Alias, MX 등

• 구성 확인
  • 서브넷, 라우팅, NACL, 보안 그룹 확인
• 로그 분석
  • VPC Flow Logs
  • ELB 액세스 로그
  • AWS WAF / Web ACL 로그
  • CloudFront 로그
• 문제 해결 예시
  • S3 정적 웹사이트 + CloudFront 캐싱 오류 → 캐시 무효화
  • Route 53 레코드 잘못 설정 → 도메인 불분해 문제 해결

📝 Route 53 레코드 JSON 예시

{
  "Comment": "Route 53 A 레코드 예시",   // 레코드 설명
  "Changes": [
    {
      "Action": "CREATE",               // 레코드 생성 동작
      "ResourceRecordSet": {
        "Name": "example.com",          // 도메인 이름
        "Type": "A",                    // A 레코드 (IPv4 주소 매핑)
        "TTL": 300,                     // TTL (캐싱 시간, 초 단위)
        "ResourceRecords": [
          { "Value": "192.0.2.44" }     // 연결할 IP 주소
        ]
      }
    }
  ]
}

🔎 라인별 설명

• "Comment" → 레코드에 대한 설명 문구
• "Action": "CREATE" → 새로운 레코드 생성
• "Name": "example.com" → 연결할 도메인 이름
• "Type": "A" → A 레코드 (IPv4 매핑)
• "TTL": 300 → DNS 캐싱 유지 시간 5분
• "ResourceRecords" → 연결할 실제 IP 주소 목록

👉 현업에서는 Alias 레코드를 활용해 CloudFront 배포 또는 S3 버킷과 연결하는 경우가 많습니다.

💼 현업 적용 사례

1. 스타트업: S3 정적 웹사이트 + CloudFront → 전 세계 빠른 콘텐츠 제공
2. 금융사: VPC 엔드포인트를 사용해 S3와 프라이빗 연결 → 인터넷을 거치지 않음
3. 게임사: WAF + Shield Advanced → DDoS 공격 방어
4. e커머스: Route 53 지연시간 기반 라우팅 → 사용자에게 가장 가까운 리전으로 트래픽 분산
5. 엔터프라이즈: VPC Flow Logs + GuardDuty → 네트워크 이상 징후 실시간 탐지

📌 시험 대비 핵심 키워드

• VPC: Subnet, Route Table, NACL, SG, NAT GW, IGW
• 보안 연결: Session Manager, VPC 엔드포인트, VPN, Peering
• 보호 서비스: WAF, Shield
• Route 53: 레코드 타입, 라우팅 정책, DNS 구성
• CloudFront + S3: CDN, HTTPS 전송, 캐싱
• 트러블슈팅: VPC Flow Logs, ELB Logs, WAF/CloudFront Logs

네트워크와 콘텐츠 전송을 잘 알면:

• 시험에 합격할 수 있어요 🎓
• 회사에서 실제로 안전하고 빠른 인터넷 환경을 만들 수 있어요 💻⚡

• VPC = 아파트 단지 🏢 (내가 원하는 대로 나누고 관리하는 네트워크)
• 서브넷 = 아파트 동 (각각 다른 구역)
• 라우팅 테이블 = 네비게이션 지도 🗺️ (길 안내)
• 보안 그룹 = 현관문 비밀번호 🔑 (누가 들어올지 정함)
• NACL = 아파트 단지 정문 🚪 (더 큰 단위 보안)

👉 VPN = 비밀 터널 🛤️
👉 VPC Peering = 옆 단지랑 다리 놓기 🌉
👉 Session Manager = 열쇠 없어도 관리실에서 초대해서 들어가기 🚪

• Route 53 = 인터넷 전화번호부 ☎️
  → 도메인 이름(예: www.example.com)을 진짜 집 주소(IP)랑 연결해 줌
• CloudFront = 택배 물류창고 🚚
  → 가까운 창고에서 물건(콘텐츠)을 빨리 보내줌
• S3 = 택배 물품 창고 📦 (사진, 동영상, 문서 저장)

• AWS WAF = 집 앞 CCTV + 경비 아저씨 👮 (나쁜 봇, 해커 차단)
• AWS Shield = 대규모 경찰 지원 🚔 (큰 공격, DDoS 방어)
• VPC Flow Logs = 블랙박스 🎥 (누가 드나들었는지 기록)
• ELB Logs = 공동 현관 출입 기록 📋
• CloudFront Logs = 택배 배송 기록 📝

📝 Route 53 레코드 예시 (DNS 등록)

{
  "Comment": "Route 53 A 레코드 예시",   // 설명: 도메인 연결 기록
  "Changes": [
    {
      "Action": "CREATE",               // 동작: 새로 만들기
      "ResourceRecordSet": {
        "Name": "example.com",          // 도메인 이름
        "Type": "A",                    // A레코드 (IP와 연결)
        "TTL": 300,                     // 캐싱 시간 (5분)
        "ResourceRecords": [
          { "Value": "192.0.2.44" }     // 진짜 서버 IP 주소
        ]
      }
    }
  ]
}

💼 현업에서 어떻게 쓰일까?

1. 회사 내부 직원만 데이터베이스 접근
   • VPC + VPN 으로만 접속 가능 → 외부 해커 차단
2. 게임 회사
   • CloudFront로 전 세계 게이머에게 빠르게 업데이트 배포
3. 은행
   • Route 53 장애조치 라우팅(Failover) → 서버가 멈추면 자동으로 다른 서버로 연결
4. 온라인 쇼핑몰
   • WAF로 SQL Injection 같은 공격 차단
   • Shield Advanced로 대형 DDoS 공격 방어
5. IT 운영팀
   • VPC Flow Logs와 ELB Logs 확인 → 누가 잘못된 접속을 시도했는지 추적

🧾 정리

• VPC = 네트워크의 기본 집
• Route 53 = 인터넷 전화번호부
• CloudFront = 빠른 택배 배달
• WAF/Shield = 보안 지킴이
• 로그들 = 블랙박스 (문제 생기면 추적 가능)

👉 시험에서도, 실무에서도 항상 “보안과 안정성”이 더 좋은 답을 고르면 정답일 확률이 높습니다 ✅

📘 AWS Certified SysOps Administrator - Associate (SOA-C02)

Domain 4: 보안 및 규정 준수 (Security & Compliance)

> 이 도메인은 시험 점수의 **16%**를 차지하며, AWS 보안과 규정 준수 정책을 이해하고 구현하는 능력을 평가합니다.
> 핵심은 **비밀 유지(Secrets)** 와 **보안 유지(Security)** 입니다.

---

🔑 주요 학습 주제

1. 보안 정책 및 규정 준수 정책 구현

- **IAM 관리**

• 사용자(User), 그룹(Group), 역할(Role)의 차이 이해
• 암호 정책(Password Policy), MFA 적용
• IAM 정책 JSON 해석 능력
• IAM Access Analyzer, Policy Simulator 활용

- **감사 & 모니터링**

• AWS CloudTrail: 모든 API 호출 기록
• AWS Trusted Advisor: 보안 권장 사항 확인
• 다중 계정 전략: AWS Organizations, Control Tower
• 리전 선택 시 규정 준수 고려 (GDPR, PCI DSS 등)

---

2. 데이터 및 인프라 보호 전략

- **데이터 보호 & 분류**

• 민감 데이터 vs 공개 데이터 구분
• 보관 위치 및 암호화 의무화

- **암호화 & 키 관리**

• S3 암호화 옵션 (SSE-S3, SSE-KMS, SSE-C)
• AWS KMS, CloudHSM 키 관리
• 전송 중 데이터 암호화 (VPN, TLS, ACM 인증서)

- **비밀 관리 & 보안 서비스**

• AWS Secrets Manager → DB 비밀번호, API 키 저장
• SSM Parameter Store → 설정값 안전 관리
• AWS Config, GuardDuty, Security Hub, Inspector, Macie → 보안 상태 점검

---

{
  "Version": "2012-10-17", // 정책 버전 (항상 이 날짜 형식 고정)
  "Statement": [           // 권한을 정의하는 블록
    {
      "Effect": "Allow",   // 허용(Allow) 또는 거부(Deny)
      "Action": "s3:*",    // S3 서비스에서 모든 동작 허용
      "Resource": "*"      // 모든 S3 리소스에 적용
    }
  ]
}

🔎 라인별 설명

• "Version": "2012-10-17" → AWS 정책 문서 표준 버전
• "Statement" → 실제 권한 정의하는 배열
• "Effect": "Allow" → 동작을 허용한다는 의미
• "Action": "s3:*" → S3에서 가능한 모든 API 호출 허용 (GetObject, PutObject 등)
• "Resource": "*" → 모든 S3 버킷 및 객체에 적용

👉 실제 현업에서는 Resource 를 "arn:aws:s3:::my-bucket/*" 같이 특정 리소스로 제한하는 것이 보안 모범 사례입니다.

💼 현업 적용 사례

1. IAM & MFA
   • 사내 직원 계정에 MFA를 필수 적용하여 계정 탈취 위험 방지
2. CloudTrail & GuardDuty
   • 모든 API 호출을 기록 → 비정상 로그인 시도 탐지 가능
3. 데이터 암호화
   • 고객의 금융/의료 데이터는 반드시 KMS를 사용하여 암호화
   • GDPR 등 규정에 따라 특정 리전(EU) 내 데이터 저장
4. Secrets Manager
   • RDS 데이터베이스 비밀번호를 직접 코드에 넣지 않고 Secrets Manager에 저장 → 앱이 동적으로 불러와 사용
5. Security Hub & Inspector
   • 보안 취약점 자동 탐지 → 패치 미적용 서버를 알림으로 확인 가능

📌 핵심 키워드 요약

• IAM, MFA, JSON 정책, Access Analyzer
• CloudTrail, Trusted Advisor, AWS Organizations
• 데이터 분류, 암호화 (KMS, CloudHSM, ACM, VPN)
• Secrets Manager, Parameter Store
• Config, GuardDuty, Security Hub, Inspector, Macie

🔐 AWS Certified SysOps Administrator - Associate (SOA-C02)

Domain 4: 보안 및 규정 준수에 대한 이해

📌 핵심 요약

• 보안은 AWS 인프라의 모든 단계(계획 → 구축 → 운영) 에 걸쳐 반드시 고려해야 함
• IAM 은 AWS 액세스 관리의 중심 → 최소 권한 원칙 적용 필수
• CloudTrail, CloudWatch 를 통한 감사 및 모니터링으로 규정 준수 유지
• 시험에서는 “보안성이 더 높은 선택지가 있으면 그것이 정답”인 경우가 많음

🛡️ 주요 학습 포인트

1. IAM (Identity & Access Management)

• 최소 권한 원칙 (Least Privilege)
  • 사용자에게 꼭 필요한 권한만 부여
  • Production 계정 직접 액세스는 극히 제한
• MFA(멀티 팩터 인증)
  • 콘솔 로그인 시 추가 인증 단계 요구
• 역할(Role)과 페더레이션(Federation)
  • 임시 권한 부여 / 외부 IdP 연동

2. 변경 관리 & 자동화

• 리소스 시작·종료 권한은 개인이 아닌 자동화 도구를 통해 수행
• 변경 관리 프로세스를 통해 실수·오류를 최소화

3. 감사 & 추적

• AWS CloudTrail
  • 모든 API 호출 및 이벤트 로깅
  • “누가, 언제, 무엇을” 했는지 추적 가능
• Amazon CloudWatch
  • CloudTrail 이벤트와 연동 → 알람·경보 생성
• 규정 준수 미준수 활동 탐지 및 알림 자동화 가능

📊 보안 & 규정 준수 흐름 (Mermaid)

flowchart TD
    A["보안 & 규정 준수 고려"] --> B["IAM 관리"]
    A --> C["변경 관리 & 자동화"]
    A --> D["감사 & 추적"]

    B --> B1["최소 권한 원칙"]
    B --> B2["MFA 적용"]
    B --> B3["Role / Federation 활용"]

    C --> C1["자동화 도구를 통한 리소스 제어"]
    C --> C2["프로덕션 계정 직접 액세스 최소화"]

    D --> D1["CloudTrail 로그"]
    D --> D2["CloudWatch 알람"]
    D --> D3["규정 준수 상태 점검"]


📝 예시 IAM 정책 JSON

{
"Version": "2012-10-17", // 정책 버전 (고정된 표준)
"Statement": [
{
"Effect": "Allow", // 허용 규칙
"Action": [ // 허용할 액션 목록
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": "arn:aws:ec2:ap-northeast-2:123456789012:instance/*"
// 특정 계정의 모든 EC2 인스턴스
}
]
}

```

👉 실무 포인트

• Production 환경에서는 ec2:TerminateInstances 권한은 절대 직접 부여 금지
• Terraform, CloudFormation 같은 IaC 도구를 통해 관리하는 것이 안전

💼 현업 적용 사례

1. 금융회사: 고객 데이터 저장 시 반드시 KMS 키로 암호화
2. 게임사: 운영자가 실수로 서버를 종료하지 않도록 EC2 종료 권한은 자동화 도구에만 부여
3. 의료기관: CloudTrail + GuardDuty로 의심스러운 API 호출 탐지
4. 스타트업: Secrets Manager로 DB 비밀번호 관리 → 코드에 하드코딩 금지

📌 시험 대비 팁

• “두 옵션 중 하나가 보안성이 더 높다” → 보안 강화된 옵션 선택
• IAM, CloudTrail, CloudWatch, Config, GuardDuty, Security Hub 등 보안 서비스의 목적과 차이점 숙지
• Least Privilege 는 항상 답안에서 핵심 키워드

✅ 결론: 보안 및 규정 준수는 AWS 인프라의 기초 체력
시험뿐 아니라 실무에서도 IAM, 감사, 암호화는 반드시 숙지해야 하는 핵심입니다.

📘 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 조합을 떠올리면 됩니다.

🚀 배포, 프로비저닝 및 자동화 (Deployment, Provisioning & Automation)

1. 도메인 개요

• 비중: 시험 점수의 약 18%
• 핵심 테마
  1. 클라우드 리소스의 프로비저닝 및 유지 관리
  2. 반복 가능한 프로세스 자동화

2. 주요 학습 주제

(1) 리소스 프로비저닝 및 유지 관리

• EC2 AMI: AMI 생성·관리 (Image Builder 활용 포함)
• CloudFormation: IaC(Infrastructure as Code)로 스택 생성·관리, 문제 해결
• 리전·계정 간 리소스 관리
  • Resource Access Manager (RAM)
  • CloudFormation StackSets
  • IAM Cross-Account Role
• 배포 전략
  • Blue-Green
  • Rolling Update
  • Canary Deployment
• 서비스 할당량(Service Quotas)
  • 자원 제한 이유 (안정성·보안)
  • 제한 상향 요청 방법
• 오류 대응
  • VPC/서브넷 크기 설정
  • CloudFormation 템플릿 오류
  • OpsWorks 에러 처리

(2) 수동 또는 반복 가능한 프로세스 자동화

• 자동화 도구
  • CloudFormation (IaC)
  • AWS OpsWorks (Chef, Puppet)
  • Elastic Beanstalk (애플리케이션 배포 자동화)
  • AWS Systems Manager (패치 관리, Run Command, Automation Runbooks)
• 이벤트 기반 자동화
  • Amazon EventBridge → 일정·이벤트 기반 작업 트리거
  • AWS Config → 규정 위반 시 자동 조치
• 자동화 시나리오
  • 정기 패치 관리
  • 인스턴스 자동 시작·중지
  • 리소스 정책 자동 수정

3. 시험에서 나올 수 있는 예시 포인트

• AMI 생성·배포 프로세스에 대한 질문
• CloudFormation 스택 오류 원인 분석
• 서비스 할당량 초과 → 해결 방법? (Quotas 변경 요청)
• Blue-Green/Canary 배포 전략 비교
• Systems Manager Automation으로 패치 관리 자동화
• EventBridge 규칙으로 특정 이벤트 발생 시 Lambda 실행

4. 실무 적용 인사이트

• 운영자가 직접 리소스를 생성·변경하는 대신 IaC 및 자동화로 표준화된 환경 제공
• 반복 작업 최소화 → 인적 오류 감소
• 배포 전략(Blue-Green 등)을 통해 무중단 배포 가능
• 서비스 할당량 관리로 장애 예방
• 자동화 도구 조합 (CloudFormation + Systems Manager + EventBridge)으로 운영 효율성 극대화

✅ 핵심 요약
배포, 프로비저닝 및 자동화는 AWS 인프라를 표준화·자동화하여 운영 효율성을 극대화하는 영역입니다.
시험에서는 AMI, CloudFormation, 배포 전략, 자동화 서비스(EventBridge, Systems Manager, Config) 관련 문제가 자주 출제되며,
실무에서는 반복 작업 자동화 + 무중단 배포 전략이 가장 중요한 포인트입니다.

🚀 배포, 프로비저닝 및 자동화에 대한 이해

1. 개념 정리

• 배포(Deployment)
  애플리케이션과 인프라를 특정 환경(개발, 테스트, 운영)에 올려 실행하는 과정
  → 예: Blue-Green, Rolling, Canary 배포 전략
• 프로비저닝(Provisioning)
  클라우드 자원(EC2, VPC, DB 등)을 생성·구성하여 애플리케이션이 실행될 기반을 마련하는 것
  → 예: EC2 인스턴스 생성, VPC 서브넷 설정
• 자동화(Automation)
  반복되는 작업(패치, 업데이트, 백업 등)을 스크립트·도구로 자동 실행하는 것
  → 예: Systems Manager Run Command, EventBridge 스케줄링

2. CloudFormation의 핵심 이점

• 인프라를 코드(IaC) 로 관리
  • JSON/YAML 템플릿으로 전체 아키텍처 정의
  • 버전 관리 및 검토 가능 → GitOps 적용
• 표준화와 재사용성
  • 동일한 아키텍처를 여러 리전·계정에 손쉽게 배포
• 업데이트 및 복구 용이
  • 스택 업데이트, 롤백 기능 → 장애 시 빠른 복원
• 자동화된 배포 파이프라인과 연계
  • CodePipeline + CloudFormation → CI/CD 자동화

3. Systems Manager와 운영 자동화

• Run Command: 여러 EC2 인스턴스에 동시에 명령 실행
• Patch Manager: 자동 패치 적용 및 관리
• Automation Runbook: 미리 정의된 운영 절차 자동 실행
• State Manager: 서버 설정 자동 유지

👉 장점: 수십·수백 대 서버 운영 시 인적 오류 최소화, 반복 작업 자동화

4. 자동화 사례

• 자동 패치 관리: 새벽 시간대에 OS 업데이트 예약
• 트래픽 비활성 시간 업데이트: 피크 시간대 피해서 배포
• 로그 집계 및 보관: 월 1회 자동 실행
• 자동 시작·중지: 비용 최적화를 위해 업무 시간 외 인스턴스 종료

5. 정리

• CloudFormation → 인프라 표준화 & 코드 기반 관리
• Systems Manager → 대규모 서버 운영 효율화
• 자동화 → 인적 오류 줄이고, 비용·운영 효율성 향상

💡 핵심 요약
배포·프로비저닝·자동화를 이해하면 AWS를 더 쉽고 안전하게 운영할 수 있고,
시험에서도 CloudFormation, Systems Manager, 배포 전략, 자동화 도구(EventBridge, Config)가 자주 출제됩니다.