[AWS SOA-C02] Q201 ~ Q250 오답노트 5EA

📘 오답노트 - 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를 교체할 필요 없음. 불필요하게 복잡.

---

📊 비교 요약

옵션	설명	적합 여부
A	ALB 유형/도메인만 설정, CloudFront 전용 접근 불가	❌
B	Lambda@Edge 코드 필요, 운영 오버헤드 증가	❌
C	ALB 교체 불필요, 과도한 변경	❌
D	CloudFront에서 헤더 추가 + 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 관리형 환경에서 불필요하고 지원되지 않음.

---

📊 비교 요약

옵션	설명	적합 여부
A	보안 그룹 규칙은 SSL 강제 불가	❌
B	KMS는 저장 시 암호화 (at rest) 전용	❌
C	DB 매개변수 그룹에서 SSL 강제 설정 (rds.force_ssl)	✅ 정답
D	PostgreSQL 확장 필요 없음 (AWS 관리형에서 지원X)	❌

---

🌐 동작 흐름 (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 필요)

---

📊 비교 요약

옵션	설명	적합 여부
A	Route 53 Alias + Failover Routing Policy	✅ 정답
B	단순 CNAME, Failover 불가	❌
C	ELB 상태 확인 (리전 Failover 불가)	❌
D	EC2 상태 확인 (리전 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 주제로 알림 발송
  → 단순 알림으로 오류 발생 사실만 전달. 세부 원인 추적 불가.

---

📊 비교 요약

옵션	설명	적합 여부
A	이벤트 재생 (아카이브)	❌ 오류 분석 불가
B	SQS DLQ로 실패 이벤트 보관 및 분석	✅ 정답
C	Lambda + 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 사용량 문제 해결 불가.

---

📊 비교 요약

옵션	설명	적합 여부
A	CPU 하이퍼스레딩 (Lambda에 불가능)	❌
B	관리 암호화 끄기 (보안 관련, 성능 무관)	❌
C	메모리 증설 → CPU 성능도 자동 증가	✅ 정답
D	코드 레이어 사용 (배포 효율성 관련)	❌

---

🌐 동작 원리 (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 함수의 메모리 양을 늘린다.