[AWS SOA-C02] Multiple Choice-2 오답노트 14EA

📘 오답노트 - 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일 동안 모든 시점으로 데이터 복구 가능.
• 두 기능을 함께 사용해야 실수 삭제 방지 + 데이터 손실 최소화라는 두 가지 목표를 달성할 수 있음.