[AWS SOA-C02] Multiple Choice-1 오답노트 15EA

📘 오답노트 - 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 → 고가용성, 성능 개선과 직접적 관련 없음

---