Q101 ~ Q150 오답노트 21EA

📘 Q102 문제 정리

🔹 문제 요약

• 회사는 EC2 Auto Scaling 그룹을 사용, 평균 CPU 사용률을 기준으로 확장 중
• 이벤트 로그에서 InsufficientInstanceCapacity 오류 발생
  → 새 인스턴스를 시작하려 했으나 해당 AZ에 여유 용량 없음

👉 SysOps 관리자가 취할 수 있는 조치는 무엇일까? (2개 선택)

---

🔹 선택지 분석

• A. 인스턴스 유형 변경
  → 현재 AZ에서 특정 인스턴스 타입의 가용 용량이 부족한 상황
  → 다른 인스턴스 타입을 사용하면 새 인스턴스를 실행할 수 있음 ✅
• B. 다른 가용 영역(AZ)에 Auto Scaling 그룹 확장
  → 여러 AZ에 인스턴스를 분산하면 특정 AZ 용량 부족 문제를 피할 수 있음 ✅
• C. EBS 볼륨 크기를 키움
  → 디스크 크기와 용량 부족은 무관 ❌
• D. Auto Scaling 그룹 최대 크기 증가
  → 한도 설정 문제가 아니라 물리적 가용 용량 문제이므로 효과 없음 ❌
• E. 서비스 할당량 증가 요청
  → 계정 한도 문제가 아니라 리전/AZ 자원 가용성 문제라서 해당 없음 ❌

✅ 정답: A, B

---

📝 쉬운 해설

• InsufficientInstanceCapacity = 특정 인스턴스 타입을 해당 AZ에서 더 이상 프로비저닝할 수 없는 경우 발생
• 해결책은 인스턴스 타입 변경 또는 다른 AZ에 배포

---

📊 Mermaid 시각화

```mermaid

flowchart TD
    ASG[Auto Scaling 그룹] --> AZ1[가용 영역 1 - 용량 부족]
    ASG --> AZ2[가용 영역 2 - 여유 있음]
    AZ1 -. 시도 실패 .-> Error[InsufficientInstanceCapacity]
    AZ2 --> Success[새 인스턴스 실행 성공]

```

 

---

🎯 암기 팁

👉 “InsufficientInstanceCapacity = 타입 바꾸거나, AZ 분산”

• 타입 변경 ✅
• 다른 AZ 활용 ✅
• EBS 크기/ASG 한도/서비스 할당량 ❌

---

📘 Q103 문제 정리

🔹 문제 요약

• SysOps 관리자가 AWS Systems Manager Session Manager를 사용해 EC2 인스턴스 그룹에 대한 액세스를 제어해야 함
• 특정 태그는 이미 EC2 인스턴스에 추가된 상태
• 추가로 어떤 조치를 해야 액세스를 제어할 수 있을까? (2개 선택)

---

🔹 선택지 분석

• A. IAM 정책을 사용자/그룹에 연결 → EC2 인스턴스 접근 권한 부여
  → Session Manager 접근을 위한 IAM 정책 필요 ✅
• B. IAM 역할을 연결하여 EC2 자체 접근 제어
  → EC2 인스턴스 프로파일과는 다르며, 직접 IAM 역할만으로는 제어 불가 ❌
• C. EC2 배치 그룹 생성 후 태그 추가
  → 배치 그룹은 물리적 배치 관리 목적, 액세스 제어와 무관 ❌
• D. 서비스 계정을 생성해 EC2 연결
  → AWS IAM 역할/정책 기반으로 해야 하므로 오답 ❌
• E. Condition 요소를 활용한 IAM 정책 작성 (태그 기반 접근 제어)
  → 특정 태그가 있는 EC2 인스턴스만 접근 가능하도록 제어 가능 ✅

✅ 정답: A, E

---

📝 쉬운 해설

1. IAM 정책: Session Manager를 통해 접속하려면 IAM 사용자/그룹/역할에 정책을 연결해야 함
2. Condition 요소: IAM 정책 조건으로 "특정 태그가 있는 EC2 인스턴스만 접근 가능"을 설정 가능

즉, IAM 정책 연결 + 태그 기반 조건 설정이 핵심 조치입니다.

---

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    Admin[관리자 IAM 사용자/그룹] --> Policy[IAM 정책 연결]
    Policy --> Cond[Condition 태그 기반 접근 제어]
    Cond --> SSM[AWS Systems Manager Session Manager]
    SSM --> EC2[EC2 인스턴스 (특정 태그 있음)]

```

---

🎯 암기 팁

👉 “SSM 접근 제어 = IAM 정책 + 태그 조건”

• IAM 정책 연결 필수
• 태그 기반 Condition으로 세밀 제어 가능

---

📘 Q105 문제 정리

🔹 문제 요약

• AWS Lambda 함수가 하루에 여러 번 간헐적으로 실패
• SysOps 관리자는 지난 7일 동안 이 오류가 얼마나 자주 발생했는지 확인해야 함
• 가장 운영상 효율적인 방법은?

---

🔹 선택지 분석

• A. Amazon Athena로 CloudWatch 로그 쿼리
  → 가능은 하지만 로그를 S3로 내보낸 뒤 Athena로 쿼리해야 해서 비효율적 ❌
• B. Amazon Athena로 CloudTrail 로그 쿼리
  → CloudTrail은 API 호출 기록, Lambda 실행 실패 세부 로그는 없음 ❌
• C. CloudWatch Logs Insights 사용
  → Lambda 로그가 기본적으로 CloudWatch Logs에 저장됨
  → Logs Insights는 로그를 직접 쿼리하고 기간 지정(예: 최근 7일) 가능 ✅
• D. OpenSearch Service + 로그 스트리밍
  → 구축 가능하지만 별도 스트리밍/인덱싱 필요, 운영 오버헤드 큼 ❌

✅ 정답: C

---

📝 쉬운 해설

• Lambda 로그 = CloudWatch Logs 기본 저장
• Logs Insights: CloudWatch Logs 데이터를 실시간으로 쿼리/분석 가능
• "지난 7일간 오류 패턴" 같은 질문에 즉시 활용 가능

---

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    Lambda[AWS Lambda 함수] --> CWL[CloudWatch Logs]
    CWL --> Insights[CloudWatch Logs Insights]
    Insights --> Report[오류 발생 빈도 분석 (최근 7일)]

```

---

🎯 암기 팁

👉 “Lambda 실행 오류 분석 = CloudWatch Logs Insights”

• CloudTrail ❌ (API 호출 기록)
• Athena ❌ (S3 내보내야 함)
• OpenSearch ❌ (추가 구성 필요)

---

📘 Q112 문제 정리

🔹 문제 요약

• 회사 애플리케이션: Elastic Load Balancer (ELB) 뒤의 EC2 Auto Scaling 그룹에서 실행
• 평상시에는 성능 안정적
• 하지만 트래픽이 증가하면 매일 동일한 4시간 동안 성능 저하 발생

👉 이 문제를 해결할 수 있는 가장 효율적인 방법은?

---

🔹 선택지 분석

• A. 가중치 라우팅 정책 사용 + 두 번째 ELB 구성
  → 불필요하게 복잡하며 문제의 원인(트래픽 피크 시간 성능 저하) 해결에 맞지 않음 ❌
• B. 더 큰 인스턴스 유형 사용
  → 성능 개선 가능하지만, 특정 시간대만 부하가 증가하므로 비용 낭비 ❌
• C. EC2 인스턴스 수를 예약 조정 작업(Scheduled Scaling)으로 확장
  → ✅ 정답
  → 트래픽 증가 시간이 예측 가능(매일 동일 4시간)하므로 예약된 스케일링으로 미리 인스턴스 확장 가능
• D. 수동으로 EC2 인스턴스 추가
  → 관리 부담 크고 자동화되지 않음 ❌

✅ 정답: C

---

📝 쉬운 해설

• Auto Scaling은 2가지 방식으로 동작:
  1. 동적 스케일링 → CloudWatch 지표 기반 (예: CPU > 70%)
  2. 예약 스케일링 → 트래픽 피크 시간이 미리 예측 가능할 때 사용
• 이 문제는 “매일 같은 시간에 성능 저하” → 예약 스케일링(Scheduled Scaling)이 정답

---

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    Users[사용자 트래픽] --> ELB[Elastic Load Balancer]
    ELB --> ASG[Auto Scaling 그룹]
    ASG --> EC2[EC2 인스턴스]
    Schedule[예약 스케일링: 매일 동일 시간 인스턴스 확장] --> ASG

```

 

---

🎯 암기 팁

👉 “매일 같은 시간대 트래픽 증가 = Scheduled Scaling”

• 예측 불가 = 동적 스케일링
• 예측 가능 = 예약 스케일링

---

📘 Q113 문제 정리

🔹 문제 요약

• 회사는 단일 리전의 EC2 인스턴스에서 애플리케이션을 호스팅
• 애플리케이션은 HTTP가 아닌 TCP 트래픽 지원 필요
• AWS 네트워크를 활용해 짧은 지연 시간으로 콘텐츠 제공 원함
• Auto Scaling 그룹과 탄력적 로드 밸런싱도 필요

👉 어떤 아키텍처가 요구사항을 충족할까?

---

🔹 선택지 분석

• A. ALB + CloudFront
  → ALB는 HTTP/HTTPS 레벨 7 전용, TCP 지원 불가 ❌
• B. ALB + Global Accelerator
  → Global Accelerator는 ALB를 엔드포인트로 지원하지만, TCP/UDP 지원을 위해서는 NLB 사용이 더 적합 ❌
• C. NLB + CloudFront
  → CloudFront는 HTTP/HTTPS 캐싱 전용 서비스, TCP 트래픽 가속화는 불가 ❌
• D. NLB + Global Accelerator
  → NLB는 TCP/UDP 레벨 4 로드 밸런싱 지원 ✅
  → Global Accelerator는 AWS 글로벌 네트워크를 통해 최적화된 경로와 낮은 지연 시간 제공 ✅
  → Auto Scaling 그룹 뒤에 NLB 연결 가능 ✅

✅ 정답: D

---

📝 쉬운 해설

• ALB (Application Load Balancer) = HTTP/HTTPS (L7) 전용
• NLB (Network Load Balancer) = TCP/UDP (L4) 지원 → 문제 조건 충족
• CloudFront = 콘텐츠 캐싱/CDN, TCP 가속 목적과는 맞지 않음
• Global Accelerator = 전 세계 엣지 로케이션을 활용한 네트워크 최적화 → 짧은 지연 시간 보장

즉, TCP 기반 애플리케이션 + 글로벌 저지연 = NLB + Global Accelerator 조합이 정답입니다.

---

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    Users[사용자 트래픽] --> ELB[Elastic Load Balancer]
    ELB --> ASG[Auto Scaling 그룹]
    ASG --> EC2[EC2 인스턴스]
    Schedule[예약 스케일링: 매일 동일 시간 인스턴스 확장] --> ASG

```

 

---

🎯 암기 팁

👉 “TCP/UDP 필요 = NLB, 글로벌 저지연 = Global Accelerator”

• HTTP/HTTPS = ALB + CloudFront
• TCP/UDP = NLB + Global Accelerator

---

📘 Q114 문제 정리

🔹 문제 요약

• SysOps 관리자에게는 암호화된 AMI를 배포하는 CloudFormation 템플릿이 있음
• 이 템플릿은 두 번째 계정에서도 사용됨
• 그러나 두 번째 계정에서 스택을 실행하면 실패 발생

👉 문제 해결을 위해 SysOps 관리자가 해야 할 조치는?

---

🔹 선택지 분석

• A. AMI 권한을 공개로 변경
  → AMI 자체는 공유 가능하지만, 암호화된 경우 KMS 키 권한도 공유해야 함. 단순 AMI 공개만으로는 실패 해결 불가 ❌
• B. 원본 계정에서 AMI 등록 취소
  → 오히려 더 문제를 악화시키는 잘못된 선택 ❌
• C. 대상 계정의 AWS KMS 키를 사용해 AMI를 다시 암호화
  → ✅ 정답
  → 암호화된 AMI를 다른 계정에서 사용하려면 해당 계정에서 사용할 수 있는 KMS 키로 다시 암호화해야 함
• D. 대상 계정에서 AMI ID를 CloudFormation 템플릿에 업데이트
  → 단순 AMI ID만 업데이트해도, KMS 키 권한이 없으면 여전히 실패 ❌

✅ 정답: C

---

📝 쉬운 해설

• 암호화된 AMI는 단순히 공유만으로는 다른 계정에서 사용할 수 없음
• 해결 방법: 대상 계정의 KMS 키로 재암호화해야 정상적으로 CloudFormation에서 사용 가능

---

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    AMI[암호화된 AMI (계정 A)] --> KMSA[KMS 키 - 계정 A]
    KMSA -.공유 불가.-> AccountB[계정 B]
    AMI --> ReEncrypt[계정 B의 KMS 키로 재암호화]
    ReEncrypt --> Success[계정 B에서 CloudFormation 스택 실행 성공]

```

---

🎯 암기 팁

👉 “암호화된 AMI 공유 문제 = KMS 키 재암호화 필요”

• 단순 AMI 공유 ❌
• 단순 AMI ID 업데이트 ❌
• KMS 키 재암호화 ✅

---

📘 Q117 문제 정리

🔹 문제 요약

• AWS 계정에서 IAM CreateUser API 호출이 발생할 때
• SysOps 관리자가 이메일 알림을 받고 싶음
• 어떤 작업 조합을 해야 할까? (2개 선택)

---

🔹 선택지 분석

• A. CloudTrail을 이벤트 소스로 사용 + EventBridge 규칙 생성
  → CloudTrail은 API 호출 기록을 이벤트로 전달
  → EventBridge 규칙으로 CreateUser API 패턴 필터링 가능 ✅
• B. Amazon CloudSearch 사용
  → CloudSearch는 검색 서비스, 이벤트 소스로 적합하지 않음 ❌
• C. IAM Access Analyzer 사용
  → 정책 분석 서비스, 이벤트 소스로 적합하지 않음 ❌
• D. Amazon SNS 사용
  → EventBridge 규칙의 대상(Target)으로 SNS 연결 → 이메일 구독 가능 ✅
• E. Amazon SES 사용
  → SES는 메일 전송 서비스이지만, EventBridge와 직접 연결하는 기본적인 패턴 아님 ❌

✅ 정답: A, D

---

📝 쉬운 해설

1. CloudTrail + EventBridge
   • CloudTrail: IAM API 호출 이벤트 기록
   • EventBridge: CreateUser API 패턴 감지 시 이벤트 발생
2. SNS + 이메일 구독
   • EventBridge 이벤트 → SNS Topic
   • SNS Topic 구독 → 이메일 알림 수신

---

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    UserAction[IAM CreateUser API 호출] --> CT[AWS CloudTrail]
    CT --> EB[Amazon EventBridge 규칙 (CreateUser 필터)]
    EB --> SNS[Amazon SNS 주제]
    SNS --> Email[관리자 이메일 알림]

```

 

---

🎯 암기 팁

👉 “API 이벤트 알림 = CloudTrail + EventBridge + SNS”

• CloudTrail = API 이벤트 감지
• EventBridge = 이벤트 필터링
• SNS = 이메일/SMS 알림

---

📘 Q118 문제 정리

🔹 문제 요약

• 현재 Amazon RDS 다중 AZ DB 인스턴스가 실행 중
• 최근 보안 감사에서 DB 인스턴스가 암호화되지 않음 → 규정 위반
• 이제 DB를 암호화해야 함

👉 어떤 접근 방식이 필요할까?

---

🔹 선택지 분석

• A. RDS 콘솔에서 암호화 옵션 선택
  → RDS는 생성 시 암호화 여부를 지정해야 하며, 실행 중인 인스턴스에 암호화를 직접 적용할 수 없음 ❌
• B. 새 EBS 볼륨을 생성 후 인스턴스에 연결
  → EBS 암호화는 RDS 인스턴스 DB 암호화와 직접적 연관 없음 ❌
• C. 보조 가용 영역 복제본 암호화 후 승격
  → 암호화되지 않은 기본 인스턴스로부터 생성된 복제본도 암호화되지 않음 ❌
• D. RDS 스냅샷을 생성 → 스냅샷 복사 시 암호화 적용 → 암호화된 스냅샷으로 새 인스턴스 생성
  → ✅ 정답
  → 유일하게 암호화되지 않은 DB를 암호화된 상태로 변환할 수 있는 절차

✅ 정답: D

---

📝 쉬운 해설

• RDS 암호화는 인스턴스 생성 시에만 가능
• 이미 실행 중인 비암호화 DB 인스턴스 → 암호화 불가
• 해결책:
  1. 기존 RDS 스냅샷 생성
  2. 스냅샷 복사 시 "암호화" 옵션 활성화
  3. 암호화된 스냅샷으로 새 RDS 인스턴스 생성

---

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    A[기존 RDS 인스턴스 - 암호화 안 됨] --> B[스냅샷 생성]
    B --> C[스냅샷 복사 - 암호화 적용]
    C --> D[암호화된 새 RDS 인스턴스 생성]

```

---

🎯 암기 팁

👉 “RDS 실행 중 암호화 불가 → 스냅샷 복사 후 암호화”

• 실행 중 직접 암호화 ❌
• 새 스냅샷 암호화 ✅

---

📘 Q120 문제 정리

🔹 문제 요약

• 회사는 VPC 내 EC2 인스턴스에서 애플리케이션 실행 중
• 이 애플리케이션은 인터넷에서 소프트웨어 업데이트를 다운로드해야 함
• 보안 정책상 모든 EC2 인스턴스는 프라이빗 서브넷에만 배포해야 함
• VPC에는 퍼블릭 서브넷과 프라이빗 서브넷이 존재

👉 이 상황에서 인터넷 접근을 가능하게 하려면?

---

🔹 선택지 분석

• A. VPC에 인터넷 게이트웨이 추가 후, 프라이빗 서브넷 라우팅에 경로 추가
  → 인터넷 게이트웨이는 퍼블릭 서브넷 전용. 프라이빗 서브넷에서는 직접 사용 불가 ❌
• B. 프라이빗 서브넷에 NAT 게이트웨이 추가
  → NAT 게이트웨이는 반드시 퍼블릭 서브넷에 위치해야 하므로 잘못됨 ❌
• C. 퍼블릭 서브넷에 NAT 게이트웨이 추가 후, 프라이빗 서브넷 라우팅에서 NAT 게이트웨이로 경로 지정
  → ✅ 정답
  → 프라이빗 서브넷 인스턴스들이 NAT 게이트웨이를 통해 인터넷에 아웃바운드 트래픽 전송 가능
• D. VPC에 인터넷 게이트웨이 2개 추가
  → 인터넷 게이트웨이는 하나만 가능. 그리고 프라이빗 서브넷에는 직접 적용 불가 ❌

✅ 정답: C

---

📝 쉬운 해설

• 프라이빗 서브넷 인스턴스는 보안상 직접 인터넷 게이트웨이 사용 불가
• 대신, 퍼블릭 서브넷에 NAT 게이트웨이 생성 → 라우팅을 NAT GW로 설정
• 이렇게 하면 인스턴스는 아웃바운드 인터넷 접근 가능, 외부에서 직접 접근 불가

---

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    PrivateEC2[EC2 인스턴스 - 프라이빗 서브넷] --> Route[라우팅 테이블 - NAT 게이트웨이로 경로]
    Route --> NATGW[NAT 게이트웨이 - 퍼블릭 서브넷]
    NATGW --> IGW[인터넷 게이트웨이]
    IGW --> Internet[인터넷]

```

---

🎯 암기 팁

👉 “프라이빗 서브넷 → 인터넷 = NAT 게이트웨이 필요”

• 퍼블릭 서브넷: IGW 직접 연결
• 프라이빗 서브넷: NAT GW 통해 간접 연결

---

📘 Q122 문제 정리

🔹 문제 요약

• SysOps 관리자가 고성능 컴퓨팅(HPC) 애플리케이션 실행을 위해 EC2 인스턴스 클러스터를 구성해야 함
• HPC 특성상 노드 간 최소 대기 시간(Low Latency) 필요

👉 어떤 조치를 취해야 할까? (2개 선택)

---

🔹 선택지 분석

• A. Amazon EFS 파일 시스템 생성
  → 파일 공유는 가능하지만, HPC의 핵심 요건인 노드 간 저지연 통신과 무관 ❌
• B. 다중 AZ 로드 밸런서 사용
  → HPC는 단일 AZ 내 저지연 클러스터가 핵심. 다중 AZ 사용 시 지연 시간 증가 ❌
• C. 단일 서브넷 내 Auto Scaling 그룹에서 EC2 시작
  → 같은 서브넷/같은 AZ에 인스턴스를 모아 저지연 네트워킹 가능 ✅
• D. EC2 인스턴스를 클러스터 배치 그룹(Cluster Placement Group)에서 시작
  → HPC 워크로드를 위해 인스턴스를 물리적으로 근접 배치해 네트워크 지연 최소화 ✅
• E. EC2 인스턴스를 파티션 배치 그룹에서 시작
  → 파티션은 대규모 분산 워크로드에 적합 (예: Hadoop), 저지연 HPC 목적과는 맞지 않음 ❌

✅ 정답: C, D

---

📝 쉬운 해설

• HPC 애플리케이션 → 인스턴스 간 저지연 네트워크 필수
• 이를 위해:
  1. 단일 서브넷/단일 AZ에 배치 (네트워크 경로 짧게)
  2. Cluster Placement Group 사용 (인스턴스를 물리적으로 가까운 하드웨어에 배치)

---

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    ASG[Auto Scaling 그룹 - 단일 서브넷] --> EC1[EC2 인스턴스 1]
    ASG --> EC2[EC2 인스턴스 2]
    ASG --> EC3[EC2 인스턴스 3]
    subgraph CPG[Cluster Placement Group - 저지연]
        EC1
        EC2
        EC3
    end

```

---

🎯 암기 팁

👉 “HPC = 단일 AZ + Cluster Placement Group”

• EFS ❌
• Multi-AZ ❌
• Partition ❌

---

📘 Q123 문제 정리

🔹 문제 요약

• 고객이 Amazon S3 정적 웹 콘텐츠에 액세스하는 동안 지연 시간 증가 발생
• SysOps 관리자는 특정 S3 버킷에서 매우 높은 읽기 트래픽을 관찰
• 목표: S3 버킷 로드 줄이고 지연 시간 최소화

👉 어떤 접근 방식이 가장 적절할까?

---

🔹 선택지 분석

• A. S3 버킷을 더 가까운 리전으로 마이그레이션
  → 리전 변경만으로는 전 세계 사용자 지연 시간 해결 불가 ❌
• B. 교차 리전 복제를 사용해 다른 리전으로 복제
  → 데이터 복제는 가능하지만, 전 세계 캐싱/지연 시간 최소화에는 적절치 않음 ❌
• C. CloudFront 배포 생성, S3를 오리진으로 사용
  → ✅ 정답
  → CloudFront는 전 세계 엣지 로케이션에서 콘텐츠 캐싱 → S3 부하 감소 + 지연 시간 단축
• D. Amazon ElastiCache로 캐싱
  → ElastiCache는 데이터베이스 캐싱 용도로 주로 사용, S3 정적 웹 콘텐츠 캐싱에는 부적합 ❌

✅ 정답: C

---

📝 쉬운 해설

• 문제 핵심: S3에 직접 트래픽 집중 → 지연 시간 증가
• CloudFront 사용:
  1. 전 세계 엣지 로케이션에서 캐시 제공
  2. 사용자는 가까운 엣지 서버에서 콘텐츠 제공받아 지연 시간 단축
  3. 원본 S3에 도달하는 요청 횟수도 줄어듦 → 부하 분산 효과

---

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    user[전 세계 사용자]
    cloudfront[Amazon CloudFront 엣지 로케이션]
    s3[S3 버킷 - 오리진]
    cache[캐싱된 콘텐츠 제공]

    user --> cloudfront
    cloudfront --> s3
    cloudfront --> cache

```

 

---

🎯 암기 팁

👉 “S3 읽기 트래픽 + 지연 시간 문제 = CloudFront 캐싱”

• 데이터베이스 캐싱 = ElastiCache
• 웹 콘텐츠 캐싱 = CloudFront

---

📘 Q127 문제 정리

🔹 문제 요약

• 상황: VPC에서 사용할 프라이빗 IPv4 주소가 고갈되어 EC2 인스턴스를 시작할 수 없음.
• 질문: SysOps 관리자가 취할 수 있는 올바른 조치는? (2개 선택)

---

🔹 선택지 분석

• A. 보조 IPv4 CIDR 블록을 VPC에 연결한다.
  → ✅ 정답
  → 기존 VPC에 Secondary IPv4 CIDR을 추가해서 IP 풀을 확장할 수 있음.
• B. 기본 IPv6 CIDR 블록을 VPC에 연결한다.
  → ❌ IPv6은 IPv4 고갈 문제를 직접 해결하지 못함. (IPv6 전환과는 별개 문제)
• C. VPC에 대한 새 서브넷을 생성한다.
  → ✅ 정답
  → 새로 추가한 CIDR 블록을 기반으로 새 서브넷을 만들어야 인스턴스 배포 가능.
• D. VPC의 CIDR 블록을 수정한다.
  → ❌ 기존 CIDR은 수정 불가. 오직 추가만 가능.
• E. 인스턴스와 연결된 서브넷의 CIDR 블록을 수정한다.
  → ❌ 서브넷 CIDR도 생성 후 변경 불가. 새로운 서브넷을 생성해야 함.

---

✅ 정답: A, C

---

📝 쉬운 해설

1. VPC CIDR 수정 불가 → Secondary IPv4 CIDR 추가
2. 서브넷 CIDR 수정 불가 → 새 서브넷 생성 필요

즉, IPv4 부족 = VPC에 보조 CIDR 추가 + 새 서브넷 생성

---

📊 흐름도 (Mermaid)

 

```mermaid

flowchart TD
    VPC[VPC - 기존 CIDR 고갈] --> AddCIDR[보조 IPv4 CIDR 추가]
    AddCIDR --> NewSubnet[새 서브넷 생성]
    NewSubnet --> EC2[새로운 EC2 인스턴스 시작 가능]

```

 

---

🎯 암기 팁

👉 “CIDR 고갈 = VPC에 CIDR 추가 + 새 서브넷 생성”

• CIDR 수정 불가 ❌
• 서브넷 CIDR 수정 불가 ❌

---

📘 Q128 문제 정리

🔹 문제 요약

• SysOps 관리자가 새 AWS 계정에서 EC2 Auto Scaling 그룹 생성
• 일부 인스턴스 추가 후, 최소 인스턴스 수에 도달하지 못함 → 오류 발생
• 오류 메시지:
•  
  새 EC2 인스턴스를 시작하지 못했습니다. 상태 이유: 귀하의 할당량은 0개의 추가 인스턴스 실행만 허용합니다. 최소 1개가 필요합니다.
• 즉, 계정의 EC2 인스턴스 서비스 할당량 부족(=Limit) 문제

👉 어떻게 해결할까?

---

🔹 선택지 분석

• A. Billing & Cost Management 콘솔에서 EC2 지출 한도 조정
  → ❌ 지출 한도는 관련 없음. 문제는 서비스 할당량
• B. EC2 콘솔의 설정 섹션에서 특정 리전의 EC2 할당량 수정
  → ❌ 콘솔에서 직접 수정 불가. AWS Support를 통한 요청 필요
• C. AWS Management Console → 서비스 할당량 (Service Quotas)에서 인스턴스 유형 패밀리별 할당량 증가 요청
  → ✅ 정답
  → EC2는 인스턴스 패밀리별(vCPU 기반) 할당량 제한이 있으며, Service Quotas에서 증가 요청 가능
• D. Auto Scaling 그룹 재조정 작업
  → ❌ 근본적 해결 불가 (여전히 할당량 제한 때문에 실패)

✅ 정답: C

---

📝 쉬운 해설

• AWS 새 계정은 기본적으로 리소스 할당량이 낮음 (예: t2.micro 몇 개만 가능)
• Auto Scaling에서 인스턴스 추가 시 한도 초과 → 인스턴스 시작 불가
• 해결책: Service Quotas(AWS 콘솔)에서 할당량 증가 요청

---

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    AutoScaling[EC2 Auto Scaling 그룹] --> EC2[새 EC2 인스턴스 요청]
    EC2 --> LimitCheck[계정 EC2 할당량 확인]
    LimitCheck -. 초과 .-> Error[인스턴스 시작 실패]
    LimitCheck --> Request[Service Quotas에서 할당량 증가 요청]
    Request --> Success[정상적으로 인스턴스 시작 가능]

```

---

🎯 암기 팁

👉 “EC2 인스턴스 시작 불가 + ‘할당량 부족’ 오류 = Service Quotas 증가 요청”

---

📘 Q130 문제 정리

🔹 문제 요약

• 회사는 ALB (Application Load Balancer) 뒤에 3개의 EC2 인스턴스로 웹 애플리케이션 운영 중
• 특정 기간 동안 트래픽이 증가하면 성능 저하 발생
• SysOps 관리자는 애플리케이션이 증가된 트래픽을 감당할 수 있도록 확장해야 함

👉 어떤 솔루션이 가장 적절할까?

---

🔹 선택지 분석

• A. CloudWatch 경보로 인스턴스 크기를 늘린다.
  → ❌ Auto Scaling 없이 단일 인스턴스 크기를 키우는 방식 → 수평 확장이 아님
• B. EventBridge 규칙으로 ALB에 EC2 인스턴스 추가
  → ❌ ALB는 직접 EC2 인스턴스를 추가/제거하지 않음 → Auto Scaling 그룹이 필요
• C. 대상 추적 조정(Target Tracking Scaling Policy)을 사용, Auto Scaling 그룹에 EC2 인스턴스 포함 후 ALB에 연결
  → ✅ 정답
  → 트래픽 증가 시 Auto Scaling이 자동으로 인스턴스를 늘리고, ALB가 로드 분산 처리
• D. 예약된 조정 정책(Scheduled Scaling)을 사용해 EC2 인스턴스를 Auto Scaling 그룹에 추가
  → ❌ 예약된 스케일링은 특정 시간대 트래픽 증가 시 적합, 본 시나리오(임의의 트래픽 증가)에는 부적절

✅ 정답: C

---

📝 쉬운 해설

• 문제 핵심: 트래픽 증가 → 성능 저하 → 자동 확장 필요
• 가장 적절한 방법은:
  1. Auto Scaling 그룹에 EC2 인스턴스를 포함
  2. Target Tracking Policy (예: CPU 사용률 70% 유지)로 자동 스케일링
  3. ALB와 Auto Scaling 그룹을 연결 → 새 인스턴스도 자동으로 트래픽 분산

---

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    Users[사용자 트래픽] --> ALB[Application Load Balancer]
    ALB --> ASG[Auto Scaling 그룹]
    ASG --> EC1[EC2 인스턴스 1]
    ASG --> EC2[EC2 인스턴스 2]
    ASG --> EC3[EC2 인스턴스 3]
    Policy[Target Tracking Policy - CPU/Request 기반] --> ASG

```

---

🎯 암기 팁

👉 “트래픽 증가 → ALB + Auto Scaling + Target Tracking”

• 일정 시간대 예측 가능 = Scheduled Scaling
• 예측 불가/실시간 대응 = Target Tracking Scaling Policy

---

📘 Q132 문제 정리

문제 요약

• 조건: 60분 이상 평균 CPU 사용률이 10% 미만이면 EC2 인스턴스를 자동 종료해야 함.
• 목표: 운영상 가장 효율적인 방법 선택.

---

선택지 분석

• A. cron으로 60분마다 스크립트 실행
  → 에이전트/스크립트 관리 필요, 신뢰성·확장성 떨어짐. ❌
• B. CloudWatch 경보로 평균 CPU 모니터링(평균 기간 1시간, 임계치 10%) + 경보 연계 EC2 작업(Stop/Terminate)
  → AWS 네이티브, 관리형, 신뢰성 높음. ✅
• C. CloudWatch 에이전트 + 커스텀 지표 세트
  → 기본 지표(CPUUtilization)로 충분, 에이전트 불필요. 과도한 구성. ❌
• D. Systems Manager Run Command로 60분마다 CPU 확인
  → 주기 호출·권한·오케스트레이션 관리 부담 큼. 이벤트 기반이 아님. ❌

정답: B

---

구현 핵심(짧게)

1. CloudWatch Alarm 생성
   • Metric: CPUUtilization (Average)
   • Period: 60 minutes
   • Threshold: < 10
   • Evaluation: 1 (또는 운영 기준에 맞게 2~3)
2. Alarm 상태(Alarm) 시 EC2 인스턴스 작업 연결
   • 작업 유형: Stop this instance(중지) 또는 Terminate this instance(종료)
   • 필요 권한: EC2ActionsAccess가 포함된 CloudWatch 알람 서비스 연결 역할(콘솔이 자동 생성/선택 가능)

---

흐름도

 

```mermaid

flowchart TD
  Metric[CloudWatch Metric: CPUUtilization avg 60m] --> Alarm[CloudWatch Alarm < 10%]
  Alarm --> Action[EC2 Action: Stop/Terminate Instance]

```

 

---

한줄 암기

👉 “지표 기반 자동조치 = CloudWatch Alarm + EC2 Action”
스크립트/Run Command ❌, 에이전트 ❌. 기본 CPU 지표로 충분 ✅

“지표 기반 자동 조치 = CloudWatch Alarm + EC2 Action(Stop/Terminate)”

운영 시 주의사항

• Auto Scaling 그룹인지 여부 확인
  • 개별 인스턴스에 “Terminate”를 걸면 ASG가 다시 인스턴스를 띄울 수 있음.
  • ASG 환경이라면: Target Tracking/Step Scaling(예: 평균 CPU 10% 유지)으로 스케일-인이 더 자연스러움.
• Stop vs Terminate
  • Stop: 재시작 가능(요금: EBS 스토리지만).
  • Terminate: 완전 삭제(스냅샷/백업 전략 사전 점검 필수).
• 지표 지연: CloudWatch 표준 지표는 수 분 지연될 수 있음 → 서비스 특성에 맞게 Period/Evaluation 조정.

한 줄 정리

“지표 기반 자동종료 = CloudWatch Alarm(평균 CPU 60분 <10%) + EC2 Action(Stop/Terminate)”

 

---

 

📘 Q138 문제 정리

📝 문제

• 회사는 ALB(Elastic Load Balancer) 뒤의 EC2 웹 애플리케이션을 운영 중
• 보안팀은 AWS Certificate Manager(ACM) SSL 인증서를 사용하여 웹 사이트를 보호하려고 함
• 요구사항: 모든 HTTP 요청을 HTTPS로 자동 리디렉션해야 한다

---

✅ 보기

A. ALB에 HTTPS 리스너(포트 80)만 두고 SSL 인증서를 연결 → ❌ (포트 80은 HTTP 전용, HTTPS 리스너는 443 필요)
B. ALB에 포트 80 HTTP 리스너와 포트 443 HTTPS 리스너를 두고, SSL 인증서를 포트 443에 연결 + 포트 80 요청은 443으로 리디렉션 규칙 설정 → ✅
C. ALB에 두 개의 **TCP 리스너(80, 443)**를 두고 SSL 인증서를 443에 연결 → ❌ (TCP는 SSL/TLS 오프로딩 지원 불가)
D. NLB에 두 개의 TCP 리스너를 두고 SSL 인증서를 443에 연결 → ❌ (NLB는 HTTP → HTTPS 리디렉션 기능 없음)

---

🎯 정답

B. 포트 80 HTTP 리스너 + 포트 443 HTTPS 리스너 구성, 80 → 443 리디렉션 규칙 적용

---

💡 해설

• HTTP → HTTPS 강제 리디렉션은 Application Load Balancer에서 가능
• ALB 리스너 규칙에서 리디렉션(redirect action) 기능 제공
• **NLB(Network Load Balancer)**는 단순 TCP 수준 로드밸런싱이라 이런 기능 없음

---

📊 시각화 (Mermaid)

 

```mermaid

flowchart TD
  Metric[CloudWatch Metric: CPUUtilization avg 60m] --> Alarm[CloudWatch Alarm < 10%]
  Alarm --> Action[EC2 Action: Stop/Terminate Instance]

```

---

📌 핵심 포인트

• SSL 인증서는 반드시 443 포트 리스너에 연결해야 함
• 리디렉션 규칙은 ALB HTTP 리스너에서 설정
• NLB는 Layer 4, ALB는 Layer 7 → 리디렉션 같은 고급 기능은 ALB에서만 가능

---

📘 Q140 문제 정리 (Amazon ECS 네트워크 트래픽 모니터링)

❓ 문제

회사는 Amazon ECS (Elastic Container Service) 를 사용해 Amazon EC2 인스턴스에서 컨테이너화된 애플리케이션을 실행 중입니다.
SysOps 관리자는 ECS 작업 간 트래픽 흐름만 모니터링해야 합니다.

👉 어떤 단계 조합을 수행해야 할까요? (2개 선택)

---

✅ 정답: B, C

• B. 각 작업의 탄력적 네트워크 인터페이스에서 VPC 흐름 로그를 구성한다.
  → VPC Flow Logs는 네트워크 트래픽을 캡처해 CloudWatch Logs나 S3에 저장할 수 있음.
  → ECS 작업 간의 트래픽을 확인하려면 ENI(Elastic Network Interface) 레벨에서 Flow Logs를 활성화해야 함.
• C. 작업 정의에서 awsvpc 네트워크 모드를 지정한다.
  → awsvpc 모드는 각 ECS Task에 자체 ENI를 부여하여 VPC 네트워크와 직접 통신할 수 있게 함.
  → 따라서 작업(Task) 단위로 네트워크 트래픽 모니터링이 가능해짐.

---

❌ 오답 해설

• A. CloudWatch Logs 구성
  → 애플리케이션 로그 수집 용도이지, 네트워크 트래픽 흐름 모니터링은 불가능.
• D. 브리지(bridge) 네트워크 모드
  → 컨테이너 인스턴스 내에서 Docker 가상 네트워크를 사용, ENI 단위 추적 불가.
• E. 호스트(host) 네트워크 모드
  → 컨테이너가 EC2 인스턴스의 네트워크 스택을 공유, 개별 Task 네트워크 추적 불가.

---

📊 시각화 (Mermaid)

 

```mermaid

flowchart TD
    subgraph ECS["Amazon ECS Cluster"]
        Task1["Task 1 (awsvpc, ENI-1)"]
        Task2["Task 2 (awsvpc, ENI-2)"]
    end

    Task1 <---> Task2
    Task1 --> ENI1["Elastic Network Interface (ENI-1)"]
    Task2 --> ENI2["Elastic Network Interface (ENI-2)"]

    ENI1 --> VPC["VPC Flow Logs"]
    ENI2 --> VPC
    VPC --> CloudWatch["Amazon CloudWatch Logs / S3"]

```

---

📌 핵심 요약

• 네트워크 모니터링 → VPC Flow Logs
• Task 단위 네트워크 추적 → awsvpc 모드
• ECS에서 Task 간 트래픽 흐름 모니터링은 B + C 조합으로만 가능

---

📘 Q143 문제 정리 (Amazon EBS 스냅샷 복구)

❓ 문제

SysOps 관리자가 Amazon EBS 스냅샷을 복원하려고 하는데, 다른 관리자가 실수로 스냅샷을 삭제했습니다.
→ 회사는 스냅샷이 삭제되더라도 일정 기간 동안 복구할 수 있는 기능을 원합니다.

👉 어떤 솔루션이 이 기능을 제공할까요?

---

✅ 정답: C. 원하는 보관 기간 동안 EBS 스냅샷에 대한 휴지통 보관 규칙 생성

---

💡 해설

• AWS에서는 Amazon Data Lifecycle Manager(DLM) + EBS Snapshots Archive/Recycle Bin 기능을 통해 삭제된 스냅샷을 일정 기간 동안 복구 가능하도록 설정할 수 있습니다.
• 이 기능은 Recycle Bin for EBS Snapshots이라고 하며, 보존 규칙(retention rules)을 만들면, 삭제된 스냅샷이 즉시 완전히 사라지지 않고 지정된 기간 동안 복구 가능합니다.

---

❌ 오답 해설

• A. 개별 스냅샷에 삭제 방지 기능: 스냅샷에는 S3처럼 버전 관리/삭제 방지 기능 없음.
• B. IAM 정책으로 삭제 거부: 삭제를 막을 순 있지만, 실수로 삭제된 경우 복구 불가능.
• D. EventBridge + Lambda → Glacier 백업: 가능은 하지만 스냅샷 복구 기능과는 무관, 아카이빙일 뿐.

---

📊 시각화 (Mermaid)

 

 

```mermaid

flowchart TD
    Admin[관리자] --> Delete[스냅샷 삭제]
    Delete --> RecycleBin["EBS Snapshot Recycle Bin (보존 규칙 적용)"]
    RecycleBin -->|보존 기간 내 복구| Snapshot[스냅샷 복원]
    RecycleBin -->|보존 기간 종료| PermanentDelete[영구 삭제]

```

 

---

📌 핵심 포인트

• EBS 스냅샷 Recycle Bin → 삭제 후에도 지정된 보존 기간 동안 복구 가능
• DR(재해 복구) 및 실수 방지 목적에 유용
• IAM 정책은 예방책, Recycle Bin은 복구책

---

👉 이 문제는 시험에서 자주 나오는 EBS Snapshot Recycle Bin 관련 문제입니다.

---

📘 Q146 문제 정리 (Amazon S3 Glacier – Vault Lock)

❓ 문제

회사는 Amazon S3 Glacier에 민감한 데이터를 보관하려 합니다.
규제 및 규정 준수 요구 때문에, **모든 계정의 데이터 수정 금지(불변성 보장)**가 필요합니다.

👉 어떤 솔루션이 이 요구사항을 충족할까요?

---

✅ 정답: B. S3 Glacier 볼트(Vault)에 볼트 잠금 정책(Vault Lock Policy)을 연결하고, 잠금 ID를 사용하여 24시간 이내에 정책을 검증

---

💡 해설

• S3 Glacier Vault Lock
  • 규정 준수 및 보안 요건을 충족하기 위해 제공되는 기능
  • Vault에 **잠금 정책(Lock Policy)**를 설정하면, 일단 잠금이 커밋(commit)되면 변경 불가
  • WORM (Write Once, Read Many) 스토리지를 구현 → 데이터 삭제·수정 방지
  • 정책은 24시간 내 검증해야 하고, 그 이후에는 영구적으로 고정됨

---

❌ 오답 해설

• A. 24시간 후에 검증 → 잘못됨, 반드시 24시간 내 검증 필요
• C/D. 거버넌스 모드 S3 객체 잠금 → 이는 S3 Object Lock 기능, S3 Glacier Vault Lock과는 다른 서비스

---

📊 시각화 (Mermaid)

 

```mermaid

flowchart TD
    Data[민감 데이터] --> Vault[S3 Glacier Vault]
    Vault -->|Vault Lock Policy 설정| Lock[WORM 적용 (Write Once Read Many)]
    Lock --> Compliance[규제 준수: 수정/삭제 불가]

```

---

📌 핵심 포인트

• 규정 준수 & 불변성 보장 = S3 Glacier Vault Lock
• 정책 설정 후 24시간 내 검증 필수
• 커밋 이후 정책은 변경 불가
• Object Lock과 혼동 주의 (Object Lock = S3 버킷, Vault Lock = Glacier 볼트)

---

👉 이 문제는 시험에서 자주 묻는 Vault Lock vs S3 Object Lock 비교 문제입니다.

📊 Object Lock vs Vault Lock 비교

구분	S3 Object Lock	S3 Glacier Vault Lock
적용 대상	S3 버킷 내 개별 객체	S3 Glacier의 Vault 전체
주요 목적	개별 객체 수준에서 WORM(Write Once, Read Many) 보장	Vault 단위로 데이터 수정/삭제 방지
사용 사례	규정 준수 보관(예: 금융 데이터, 로그 파일)	규제 데이터 아카이빙(예: 의료 기록, 법적 증거)
정책 유형	- Governance Mode (관리자 권한으로 삭제 가능) - Compliance Mode (완전 불변, 관리자도 수정 불가)	Vault Lock Policy (커밋 후 변경 불가)
적용 단위	객체 단위 (파일 단위)	볼트 단위 (컨테이너 단위)
잠금 적용 방식	객체 업로드 시 Object Lock 적용	Vault에 Policy를 걸고, 잠금 ID로 24시간 내 검증 → 커밋
변경 가능 여부	Governance Mode에서는 관리자 해제 가능 Compliance Mode는 불가능	한 번 커밋하면 영구 불변 (변경 불가)
통합 서비스	S3 버킷, S3 API	S3 Glacier (아카이빙)

📌 한 줄 요약

• S3 Object Lock → 개별 객체 보호 (Governance/Compliance Mode 선택 가능)
• Glacier Vault Lock → Vault 단위 보호, 24시간 내 검증 후 영구 불변

---

👉 이렇게 보면 시험에서 "객체 단위 불변성" vs "아카이브 전체 불변성" 구분이 핵심 포인트입니다.

---

📘 Q149 문제 정리 (AWS Organizations + EC2 백업 전략)

❓ 문제

회사는 AWS Organizations를 사용해 여러 AWS 계정을 관리합니다.
SysOps 관리자는 회사의 모든 계정에 걸쳐 EC2 인스턴스 백업 전략을 수립해야 합니다.

👉 어떤 솔루션이 가장 효율적일까요?

---

✅ 정답: C. 마스터 계정에서 AWS Backup을 사용하여 모든 계정 및 리소스에 대한 정책을 배포한다.

---

💡 해설

• AWS Backup은 중앙에서 백업 정책을 정의하고,
  AWS Organizations를 통해 여러 계정과 리소스에 적용할 수 있습니다.
• Backup Policy를 생성 후 OU(조직 단위)에 연결하면 모든 계정에 일괄 적용됩니다.
• 따라서 운영 효율성 + 규정 준수 모두 만족.

---

❌ 오답 해설

• A. Lambda 배포 후 스냅샷 실행
  → 계정마다 함수 배포 필요, 관리 복잡성 ↑ → 비효율적.
• B. CloudFormation으로 태그 추가
  → 태그만으로 백업 자동화 불가, 실제 스냅샷 수행 X.
• D. SCP(Service Control Policy) 사용
  → SCP는 권한 제어 정책이지, 스냅샷 실행 기능이 아님.

---

📊 시각화 (Mermaid)

 

```mermaid

flowchart TD
    Master[Master Account] --> Backup[AWS Backup Policy]
    Backup --> OU1[Org Unit 1 - EC2 Instances]
    Backup --> OU2[Org Unit 2 - EC2 Instances]
    OU1 --> Snap1[자동 백업 실행]
    OU2 --> Snap2[자동 백업 실행]

```

---

📌 핵심 포인트

• AWS Backup + AWS Organizations = 다계정 환경 백업 전략 표준
• 중앙 관리, 자동 정책 배포, 규정 준수 강화
• Lambda/CloudFormation/SCP는 보조적이지만 중앙 집중 백업 전략에 부적합

---

👉 이 문제는 시험에서 자주 나오는 AWS Backup과 Organizations 통합 관련 문제예요.

---

📘 Q150 문제 정리 (VPC Flow Logs – 모든 트래픽 기록)

❓ 문제

SysOps 관리자가 **VPC 흐름 로그(Flow Logs)**를 검토하여 연결 문제를 해결 중입니다.
로그를 확인하는 동안 거부된 트래픽이 기록되지 않음을 발견했습니다.

👉 모든 트래픽(허용 + 거부)이 기록되도록 하려면 무엇을 해야 할까요?

---

✅ 정답: A. 모든 트래픽을 캡처하는 필터 설정이 있는 새 흐름 로그를 생성한다.

---

💡 해설

• VPC Flow Logs는 3가지 필터 옵션이 있음:
  1. ACCEPT → 허용된 트래픽만 기록
  2. REJECT → 거부된 트래픽만 기록
  3. ALL → 허용 + 거부 모든 트래픽 기록
• 기존 Flow Logs는 필터를 수정할 수 없음 → 반드시 새로운 Flow Log를 생성해야 함.
• 따라서 "거부된 트래픽도 기록되게 하려면 → 필터를 ALL로 설정한 새 Flow Log 생성"이 정답.

---

❌ 오답 해설

• B/D. 로그 형식 편집
  → 로그 출력 포맷만 바뀌지, 허용/거부 캡처 범위는 변하지 않음.
• C. 기존 Flow Log 필터 수정
  → Flow Logs는 한 번 생성되면 편집 불가, 삭제 후 재생성이 필요.

---

📊 시각화 (Mermaid)

 

```mermaid

flowchart TD
    Subnet["VPC Subnet"] --> FlowLog1["Flow Log: Filter=ACCEPT"]
    FlowLog1 --> Logs1["CloudWatch Logs: 허용만 기록"]

    Subnet --> FlowLog2["Flow Log: Filter=ALL (새로 생성)"]
    FlowLog2 --> Logs2["CloudWatch Logs: 허용+거부 기록"]

```

---

📌 핵심 포인트

• VPC Flow Logs → 필터: ACCEPT / REJECT / ALL
• 기존 로그는 편집 불가 → 새로 생성 필요
• 거부 트래픽까지 확인하려면 필터=ALL 설정

---

👉 이 문제는 시험에서 자주 나오는 VPC Flow Logs 필터와 편집 불가 특성 관련 포인트입니다.

📊 VPC Flow Logs – 필터 옵션 비교

필터 옵션	기록되는 내용	사용 예시
ACCEPT	허용된 트래픽만 기록	정상적인 연결 상태 분석 (ex. EC2 ↔ RDS 연결 성공 로그 확인)
REJECT	거부된 트래픽만 기록	보안 그룹/네트워크 ACL 문제 진단 (ex. 인바운드 차단 원인 확인)
ALL	허용 + 거부 모든 트래픽 기록	가장 완전한 모니터링 (네트워크 전체 감사, 보안 사고 분석)

---

📌 핵심 암기 문구

• ACCEPT = 정상 확인
• REJECT = 차단 확인
• ALL = 둘 다 확인 → 시험 정답

 

📊 VPC Flow Logs – 필터 옵션 시각화

📌 핵심 기억 포인트

• ACCEPT → 허용만
• REJECT → 거부만
• ALL → 둘 다 (시험 정답 포인트)