📘 오답노트 - Q260

❓ 문제 요약

• 회사는 여러 AWS 계정에서 사용할 새 EC2 인스턴스 AMI를 생성.
• AMI는 AWS KMS 키로 암호화된 상태.
• 요구사항: 특정 승인된 AWS 계정만 해당 AMI를 안전하게 사용할 수 있도록 공유해야 함.

✅ 정답

B. AMI가 생성된 계정에서 고객 관리형 KMS 키를 생성하고, 키 정책을 수정해 다른 AWS 계정에 권한을 부여한 뒤, 복사본 AMI를 생성하여 공유 계정 번호를 지정한다.

• KMS 키로 암호화된 AMI를 다른 계정과 공유하려면:
  1. KMS 키 정책 수정 → 대상 계정에 kms:DescribeKey, kms:ReEncrypt*, kms:CreateGrant, kms:Decrypt 권한 부여.
  2. AMI 권한 수정 및 복사본 생성 → 공유하려는 계정 번호 지정.
• 이 방식이 가장 안전하고 AWS 권장 방식.

❌ 오답 해설

• A. 단순히 AMI 권한만 수정
  → KMS 키 권한 부여가 빠져있음. 암호화된 AMI는 키 권한 없이는 공유 계정에서 사용할 수 없음.
• C. 복사본 AMI 생성 후 공개
  → “공개”로 만들면 모든 계정이 접근 가능 → 보안 위협. 승인된 계정만 접근해야 한다는 조건 위배.
• D. AWS 관리형 키 사용
  → 관리형 키는 다른 계정과 직접 공유 불가. 반드시 고객 관리형 KMS 키를 사용해야 함.

📊 비교 요약

🎯 핵심 정리

• 암호화된 AMI 공유 = KMS 키 정책 수정 + AMI 권한 수정 두 단계가 필요.
• AWS 관리형 키(X), 고객 관리형 KMS 키(O).

📘 오답노트 - Q278

❓ 문제 요약

• SysOps 관리자는 Auto Scaling 그룹의 EC2 인스턴스에 애플리케이션을 배포해야 함.
• 애플리케이션 업데이트는 매주 발생.
• AMI 생성 시 취약점 검사도 필요.
• 요구사항: 효율적이고 자동화된 업데이트 및 배포.

✅ 정답

C. 사용자 지정 레시피와 함께 EC2 Image Builder를 사용하여 애플리케이션과 해당 종속성을 설치한다.

• EC2 Image Builder는
  • OS 및 애플리케이션 패치를 자동화,
  • AMI 생성 및 업데이트 자동화,
  • 취약점 검사(Security Scan) 지원.
• 운영 효율성과 보안 요구를 동시에 충족.

❌ 오답 해설

• A. Packer 사용
  → 가능은 하지만 서드파티 도구. AWS 네이티브 서비스보다 관리 오버헤드 큼.
• B. EC2 인스턴스에 직접 설치 후 AMI 생성
  → 수동 작업으로 운영 효율성 낮음. 자동화 및 취약점 검사 부족.
• D. EventBridge + CreateImage API 호출
  → 단순 자동화는 가능하나, 취약점 검사나 종속성 설치 관리 기능 없음.

📊 비교 요약

🌐 동작 원리 (Mermaid)

```mermaid
flowchart TD
    Update["📅 매주 애플리케이션 업데이트"] --> ImageBuilder["🏗️ EC2 Image Builder"]
    ImageBuilder --> Recipe["📜 사용자 지정 레시피 + 🔒 보안 스캔"]
    Recipe --> AMI["📦 최신 보안 적용 AMI 생성"]
    AMI --> AutoScaling["⚖️ Auto Scaling 그룹에 배포"]
    AutoScaling --> UpdatedEC2["💻 최신 애플리케이션 설치된 EC2 인스턴스"]
```

 

📊 결과 설명

• 📅 매주 애플리케이션 업데이트 시작
• → 🏗️ EC2 Image Builder 를 사용
• → 📜 사용자 지정 레시피 + 🔒 보안 스캔 적용
• → 📦 최신 보안 적용 AMI 생성
• → ⚖️ Auto Scaling 그룹에 배포
• → 최종적으로 💻 최신 애플리케이션 설치된 EC2 인스턴스 실행

🎯 핵심 정리

• 문제의 요구사항은 매주 업데이트 + 취약점 검사 + 운영 효율성.
• 이 조건을 모두 만족하는 AWS 네이티브 서비스는 EC2 Image Builder.
• 따라서 정답은 C. EC2 Image Builder 사용.

📘 오답노트 - Q279

❓ 문제 요약

• CloudFormation 템플릿으로 RDS 인스턴스를 생성.
• 스택이 삭제되더라도 RDS의 데이터는 보존해야 함.
• 요구사항: 안정적이고 효율적으로 데이터 보호.

✅ 정답

C. RDS 인스턴스의 CloudFormation 템플릿 정의에서 스냅샷 삭제 정책을 사용한다.

• CloudFormation에서는 리소스 삭제 시 행동을 제어하는 DeletionPolicy 속성이 있음.
• DeletionPolicy: Snapshot을 사용하면 스택 삭제 시 RDS 인스턴스 자체는 삭제되지만 스냅샷이 자동으로 남아 데이터 보존 가능.
• 운영 효율성과 안정성을 동시에 충족.

❌ 오답 해설

• A. 5분마다 스크립트로 백업
  → 불필요하게 비효율적이며, 자동화된 CloudFormation 기능을 활용하지 않음.
• B. Lambda 함수로 스택 삭제 전 스냅샷 생성
  → 가능하지만 불필요하게 복잡하고, CloudFormation 네이티브 방식보다 운영 오버헤드 큼.
• D. 새로운 템플릿 실행 후 수동 백업
  → 중복된 관리 작업, 자동화 부족.

📊 비교 요약

📝 CloudFormation 예시 코드

Resources:
  MyDB:
    Type: AWS::RDS::DBInstance
    Properties:
      DBInstanceClass: db.t3.micro
      Engine: mysql
      MasterUsername: admin
      MasterUserPassword: password123
    DeletionPolicy: Snapshot

• 스택 삭제 시 MyDB는 삭제되지만, 최신 스냅샷이 보존됨.

🎯 핵심 정리

• 문제의 요구사항은 스택 삭제 후에도 RDS 데이터 보존.
• CloudFormation의 DeletionPolicy: Snapshot이 가장 적합.

📘 오답노트 - Q284

❓ 문제 요약

• 금융 데이터를 Amazon S3에 저장해야 함.
• 모든 데이터는 암호화 필수.
• 자체 키 제공은 원치 않음.
• 대신, 언제/누가 키를 사용했는지 감사 추적(Audit) 필요.

✅ 정답

D. AWS KMS 관리형 암호화 키(SSE-KMS)와 함께 서버 측 암호화를 사용하여 Amazon S3에서 사용자 데이터를 암호화한다.

• SSE-KMS(Server-Side Encryption with KMS-Managed Keys):
  • AWS KMS를 통해 키 관리.
  • CloudTrail 로그로 키 사용 내역 및 사용자 추적 가능 → 감사 요구 충족.
  • 회사가 직접 키를 관리할 필요 없음.

❌ 오답 해설

• A. SSE-C (클라이언트 제공 키 암호화)
  → 키를 직접 관리해야 함. 회사가 키 관리 원하지 않는다는 조건 불일치.
• B. SSE-S3 (S3 관리형 키 암호화)
  → 암호화는 가능하지만 CloudTrail 감사 추적 불가. 키 사용 내역을 추적할 수 없음.
• C. SSE-C (고객 제공 키)
  → 고객이 키 제공 및 관리해야 하므로, 회사 요건과 충돌.

📊 비교 요약

📝 추가 팁

• SSE-S3: 단순 암호화, 추적 불가.
• SSE-KMS: 암호화 + CloudTrail로 누가 언제 키를 사용했는지 로깅 가능.
• SSE-C: 키 관리 복잡, 보안 위험 증가.

🎯 핵심 정리

• 요구사항은 키 직접 관리 X, 감사 추적 필요.

📘 오답노트 - Q291

❓ 문제 요약

• Amazon EC2 인스턴스에서 Amazon SQS 대기열을 사용하는 애플리케이션 실행.
• SysOps 관리자는 EC2가 SQS 대기열에 메시지를 읽고, 쓰고, 삭제할 수 있어야 함.
• 요구사항: 가장 안전한 방식으로 권한 부여.

✅ 정답

D. EC2 인스턴스가 AWS 서비스를 호출할 수 있도록 허용하는 IAM 역할을 생성하고, 해당 역할에 SQS 권한을 연결한다.

• IAM 역할(Role) 사용 → 인스턴스 프로파일에 연결
  • EC2 인스턴스가 자동으로 IAM Role을 통해 자격 증명 획득.
  • SQS에 필요한 최소 권한(sqs:SendMessage, sqs:ReceiveMessage, sqs:DeleteMessage)만 부여.
  • 키 관리 불필요 → 안전하고 모범 사례(Best Practice).

❌ 오답 해설

• A. IAM 사용자 생성 후 Access Key 사용
  → Access Key를 애플리케이션에 하드코딩하거나 환경 변수에 저장해야 하므로 보안 위험.
• B. IAM 사용자 생성 후 키를 EC2 환경 변수에 내보내기
  → 동일하게 Access Key를 노출하게 되며, 키 유출 위험 존재.
• C. EC2에 IAM Role 부여 BUT sqs:* 와일드카드 권한 부여
  → 최소 권한 원칙(Least Privilege)에 어긋남. 불필요한 과도 권한 제공.

📊 비교 요약

🎯 핵심 정리

• Access Key 직접 사용은 위험 (A, B 탈락).
• 와일드카드(*) 권한은 최소 권한 원칙 위배 (C 탈락).
• 따라서 정답은 D (IAM Role + 최소 권한 부여).

📘 오답노트 - Q292

❓ 문제 요약

• SysOps 관리자가 Amazon S3 버킷을 생성하고 정적 웹 애플리케이션 파일을 복사함.
• 회사 정책: S3 버킷은 모두 비공개(공개 금지).
• 요구사항: 정적 웹 애플리케이션을 안전하게 호스팅해야 함.

✅ 정답

A. Amazon CloudFront 배포를 생성하고, S3 버킷을 원본 액세스 ID - OAI(Origin Access Identity)가 있는 원본으로 구성. S3 버킷 버킷 정책에서 OAI에 s3:GetObject 권한을 부여.

• CloudFront를 사용하면 S3 버킷을 직접 공개하지 않고도 웹 사이트 제공 가능.
• OAI를 통해 CloudFront에서만 S3 객체(s3:GetObject) 접근 허용.
• 보안과 성능(캐싱) 모두 충족.

❌ 오답 해설

• B. S3 정적 웹사이트 호스팅
  → 정적 웹사이트 호스팅은 S3 버킷이 공개되어야 동작. 회사 정책(비공개 유지) 위배.
• C. ALB 생성 후 S3 연결
  → ALB는 EC2와 같은 동적 리소스 로드밸런싱용이지 S3 정적 파일 제공 불가.
• D. AWS Global Accelerator 사용
  → 애플리케이션 성능 최적화(글로벌 네트워크 가속화)용.
  → 여전히 S3 버킷을 공개해야 하므로 정책 위배.

📊 비교 요약

🎯 핵심 정리

• S3 정적 웹사이트 + 보안 요구사항이 동시에 주어지면 → CloudFront + OAI 조합.
• 이 방식으로만 S3 버킷 비공개 유지 + 안전한 웹사이트 제공 가능.

📘 오답노트 - 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) 같은 문제랑 묶어서
"최소 노력 & 단순 자동화 방식" 주제로 한 번에 정리해두면 외우기 쉽습니다.

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

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

📘 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 시각화

🎯 암기 팁

👉 “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 시각화

🎯 암기 팁

👉 “암호화된 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 시각화

🎯 암기 팁

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

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

📘 Q120 문제 정리

🔹 문제 요약

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

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

🔹 선택지 분석

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

✅ 정답: C

📝 쉬운 해설

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

📊 Mermaid 시각화

🎯 암기 팁

👉 “프라이빗 서브넷 → 인터넷 = 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 시각화

🎯 암기 팁

👉 “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 시각화

🎯 암기 팁

👉 “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 시각화

🎯 암기 팁

👉 “트래픽 증가 → 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)

📌 핵심 포인트

• 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)

📌 핵심 요약

• 네트워크 모니터링 → 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)

📌 핵심 포인트

• 규정 준수 & 불변성 보장 = 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 → 개별 객체 보호 (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)

📌 핵심 포인트

• 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)

📌 핵심 포인트

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

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

📊 VPC Flow Logs – 필터 옵션 비교

📌 핵심 암기 문구

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

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

📌 핵심 기억 포인트

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

📘 Q4 문제 정리

🔹 문제 요약

SysOps 관리자가 AWS 계정에서 CloudTrail을 활성화했다.
만약 CloudTrail이 꺼지면 즉시 다시 켜져야 한다.
→ 코드를 따로 작성하지 않고 이 요구사항을 만족하려면?

🔹 선택지 분석

• A. AWS Organizations
  → 여러 계정 관리용 서비스. CloudTrail 자동 복구와는 관계 없음 ❌
• B. AWS Config 규칙 (CloudTrail 구성 변경 감지 + 자동 수정)
  → CloudTrail이 꺼지면 AWS Config가 감지 → 자동으로 다시 켜줌 ✅
• C. AWS Config + Lambda
  → 가능은 하지만 Lambda 코드를 직접 작성해야 함. 문제에서 "사용자 정의 코드 없이"라고 했으므로 ❌
• D. EventBridge 스케줄링
  → 단순히 주기적으로 실행할 뿐, 실시간 복구 보장은 안 됨 ❌

✅ 정답: B

📝 쉬운 해설

• CloudTrail = 누가, 언제, 어떤 API를 호출했는지 기록
• 문제 요구사항 = CloudTrail이 꺼져도 자동으로 다시 켜져야 함
• 해결 방법 = AWS Config 자동 수정(Auto Remediation)
  • "CloudTrailLoggingEnabled" 규칙 사용
  • **자동 수정(Auto remediation)**으로 AWS-ConfigureCloudTrailLogging 실행

즉, CloudTrail이 꺼지면 AWS Config가 바로 감지하고 자동으로 켜주는 역할을 합니다.

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    A[CloudTrail 비활성화됨] --> B[AWS Config 규칙 감지]
    B --> C[자동 수정 실행: AWS-ConfigureCloudTrailLogging]
    C --> D[CloudTrail 다시 활성화]

```

 

🎯 암기 팁

👉 CloudTrail 유지 = AWS Config + Auto Remediation

• "Config가 감시하고, 자동으로 켜준다" 라고만 기억하면 OK!

Q4.
A SysOps administrator has enabled AWS CloudTrail in an AWS account.
If CloudTrail is disabled, it must be re-enabled immediately.
What should the SysOps administrator do to meet these requirements WITHOUT writing custom code?

A. Add the AWS account to AWS Organizations.
Enable CloudTrail in the management account.

B. Create an AWS Config rule that is invoked when CloudTrail configuration changes.
Apply the AWS-ConfigureCloudTrailLogging automatic remediation action.

C. Create an AWS Config rule that is invoked when CloudTrail configuration changes.
Configure the rule to invoke an AWS Lambda function to enable CloudTrail.

D. Create an Amazon EventBridge (Amazon CloudWatch Event) hourly rule with a schedule pattern to run an AWS Systems Manager Automation document to enable CloudTrail.

Answer: B

📘 Q5 문제 정리

🔹 문제 요약

• 회사는 ALB(Application Load Balancer) 뒤의 EC2 인스턴스에서 웹사이트를 운영 중
• DNS 관리는 Amazon Route 53에서 함
• 도메인의 zone apex (example.com)를 웹사이트와 연결하려고 함

👉 이때 어떤 DNS 레코드 타입을 사용해야 할까?

🔹 선택지 분석

• A. AAAA 레코드 (IPv6 주소 매핑)
  → zone apex 자체를 ALB에 바로 연결 불가 ❌
• B. A 레코드 (IPv4 주소 매핑)
  → ALB는 고정 IP가 없음. 따라서 직접 매핑 불가 ❌
• C. CNAME 레코드
  → zone apex에서는 CNAME 사용이 불가능 ❌ (RFC 표준 제약)
• D. Alias 레코드
  → Route 53이 제공하는 특수 레코드
  → ALB, CloudFront, S3 등 AWS 리소스와 직접 연결 가능 ✅

✅ 정답: D

📝 쉬운 해설

• ALB는 IP 주소가 변할 수 있어서 A/AAAA 레코드에 직접 연결할 수 없음.
• CNAME은 www.example.com 같은 서브도메인에서는 가능하지만, zone apex(example.com)에는 불가.
• AWS Route 53의 Alias 레코드는 이런 문제를 해결하기 위해 제공됨.
  • 마치 CNAME처럼 동작하지만 zone apex에서도 사용 가능
  • 추가 비용 없음

📊 Mermaid 시각화

```mermaid

flowchart TD
    U[사용자 브라우저] --> R53[Route 53]
    R53 --> A[Alias Record]
    A --> ALB[Application Load Balancer]
    ALB --> EC2[웹 서버 EC2 인스턴스]

```

🎯 암기 팁

👉 “zone apex = Alias 레코드”

• ALB, CloudFront, S3 정적 웹사이트를 example.com에 연결할 땐 항상 Alias!

Q5.
A company hosts its website on Amazon EC2 instances behind an Application Load Balancer.
The company manages its DNS with Amazon Route 53, and wants to point its domain's zone apex to the website. Which type of record should be used to meet these requirements?

A. An AAAA record for the domain's zone apex
B. An A record for the domain's zone apex
C. A CNAME record for the domain's zone apex
D. An alias record for the domain's zone apex

Answer: D

📘 Q6 문제 정리

🔹 문제 요약

• 회사는 S3 버킷에 업로드되는 모든 객체가 반드시 암호화되었는지 확인해야 함
• 이 요구사항을 만족하는 방법 2가지 선택

🔹 선택지 분석

• A. AWS Shield 적용
  → DDoS 방어 서비스. 객체 암호화와는 관계 없음 ❌
• B. 객체 ACL로 제어
  → ACL은 접근 권한만 제어. 암호화 강제 불가 ❌
• C. S3 기본 암호화(Default Encryption)
  → 업로드 시 자동으로 암호화 처리 ✅
• D. Amazon Inspector 적용
  → 취약점 분석 툴. S3 암호화 확인 불가 ❌
• E. S3 버킷 정책으로 비암호화 객체 거부
  → "암호화 헤더 없는 업로드는 Deny" 정책 가능 ✅

✅ 정답: C, E

📝 쉬운 해설

1. S3 기본 암호화(Default Encryption)
   • 모든 업로드 객체를 자동으로 암호화
   • 사용자가 별도 지정하지 않아도 안전하게 저장됨
2. S3 버킷 정책(Bucket Policy)
   • 업로드 요청에 x-amz-server-side-encryption 헤더가 없으면 거부(Deny)
   • 암호화 강제 적용 가능

💡 두 방법을 함께 쓰면 자동 암호화 + 정책적 강제성으로 이중 보호!

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    A[사용자 업로드 요청] --> B{암호화 헤더 포함?}
    B -->|Yes| C[저장됨 (Default Encryption 적용)]
    B -->|No| D[Bucket Policy 거부]

```

🎯 암기 팁

👉 "S3 암호화 = Default Encryption + Bucket Policy"

• Default Encryption = 자동 암호화
• Bucket Policy = 암호화 안 된 업로드 차단

Q6.
A company must ensure that any objects uploaded to an S3 bucket are encrypted.
Which of the following actions will meet this requirement? (Choose two)

A. Implement AWS Shield to protect against unencrypted objects stored in S3 buckets.
B. Implement Object access control list (ACL) to deny unencrypted objects from being uploaded to the S3 bucket.
C. Implement Amazon S3 default encryption to make sure that any object being uploaded is encrypted before it is stored.
D. Implement Amazon Inspector to inspect objects uploaded to the S3 bucket to make sure that they are encrypted.
E. Implement S3 bucket policies to deny unencrypted objects from being uploaded to the buckets.

Answer: C, E

📘 Q7 문제 정리

🔹 문제 요약

• 회사는 Auto Scaling 그룹의 EC2 인스턴스에서 웹 애플리케이션을 호스팅 중
• ALB(Application Load Balancer) → CloudFront 오리진으로 구성됨
• 사용자가 웹 애플리케이션에서 무작위 로그아웃되는 문제가 발생

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

🔹 선택지 분석

• A. ALB 최소 미해결 요청 알골리즘으로 변경
  → 로드밸런싱 알고리즘 문제 아님 ❌
• B. CloudFront 캐시 정책에서 쿠키 전달 구성
  → 세션 정보는 보통 쿠키에 저장. CloudFront가 쿠키를 전달하지 않으면 세션 불일치 발생 ✅
• C. CloudFront에서 헤더 전달 구성
  → 일부 상황에서는 필요하지만, 여기서는 세션 쿠키 문제이므로 정답 아님 ❌
• D. ALB 리스너 규칙에서 그룹 수준 고정성(stickiness) 활성화
  → 리스너 단위 stickiness는 세밀하지 않음 ❌
• E. ALB 대상 그룹(Target Group)에서 고정 세션(sticky session) 활성화
  → 세션을 항상 같은 인스턴스로 라우팅해 로그아웃 문제 방지 ✅

✅ 정답: B, E

📝 쉬운 해설

• 웹 애플리케이션 로그인 세션은 쿠키 기반
• CloudFront가 쿠키를 오리진(ALB)으로 전달하지 않으면, ALB는 새 사용자처럼 취급 → 로그아웃 문제 발생
• ALB Target Group에서 Sticky Session을 켜면, 같은 사용자는 항상 동일 인스턴스로 연결됨 → 세션 유지

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    U[사용자] --> CF[CloudFront]
    CF -->|쿠키 전달| ALB[Application Load Balancer]
    ALB --> TG[Target Group (Sticky Session ON)]
    TG --> EC2A[EC2 인스턴스 A]
    TG --> EC2B[EC2 인스턴스 B]

```

 

🎯 암기 팁

👉 세션 문제 = “쿠키 전달 + Sticky Session”

• CloudFront: 쿠키 전달 설정
• ALB Target Group: Sticky Session 활성화

Q7.
A company has a stateful web application that is hosted on Amazon EC2 instances in an Auto Scaling group.
The instances run behind an Application Load Balancer (ALB) that has a single target group.

The ALB is configured as the origin in an Amazon CloudFront distribution.
Users are reporting random logouts from the web application.
Which combination of actions should a SysOps administrator take to resolve this problem? (Choose two)

A. Change to the least outstanding requests algorithm on the ALB target group.
B. Configure cookie forwarding in the CloudFront distribution cache behavior.
C. Configure header forwarding in the CloudFront distribution cache behavior.
D. Enable group-level stickiness on the ALB listener rule.
E. Enable sticky sessions on the ALB target group.

Answer: B, E

📘 Q12 문제 정리

🔹 문제 요약

• SysOps 관리자가 CloudFormation 템플릿으로 VPC를 배포 완료
• 이제 AWS Organizations 내 여러 계정에 동일한 템플릿을 배포해야 함
• 운영 오버헤드 최소화가 목표

👉 어떤 방법이 가장 적절한가?

🔹 선택지 분석

• A. 마스터 계정에서 OrganizationAccountAccessRole IAM 역할 사용
  → 단일 계정 단위 배포라서 자동화/대규모 배포 불가 ❌
• B. 각 계정에서 Lambda + CreateStack API 호출
  → 코드 작성 필요, 오버헤드 큼 ❌
• C. 계정 목록을 관리하는 Lambda로 CreateStack API 호출
  → 여전히 커스텀 코드 필요 ❌
• D. 마스터 계정에서 CloudFormation StackSets 사용
  → 여러 계정·리전에 동시에 배포 가능 ✅

✅ 정답: D

📝 쉬운 해설

• CloudFormation Stack = 단일 계정, 단일 리전에만 리소스 생성
• StackSets = 여러 계정과 리전에 한 번에 배포 가능
  • Organizations와 통합되어 있어 운영자가 코드 직접 작성할 필요 없음
  • 운영 오버헤드 최소화 조건 충족

즉, 여러 계정에 공통 리소스를 배포해야 할 때는 StackSets가 정답!

📊 Mermaid 시각화

🎯 암기 팁

👉 “여러 계정 + 여러 리전 = StackSets”

• 단일 계정/리전 = Stack
• 멀티 계정/리전 = StackSets

Q12.
A SysOps administrator has successfully deployed a VPC with an AWS CloudFormation template.
The SysOps administrator wants to deploy the same template across multiple accounts that are managed through AWS Organizations. Which solution will meet this requirement with the LEAST operational overhead?

A. Assume the OrganizationAccountAccessRole IAM role from the management account.
Deploy the template in each of the accounts.
B. Create an AWS Lambda function to assume a role in each account.
Deploy the template by using the AWS CloudFormation CreateStack API call.
C. Create an AWS Lambda function to query for a list of accounts.
Deploy the template by using the AWS CloudFormation CreateStack API call.
D. Use AWS CloudFormation StackSets from the management account to deploy the template in each of the accounts.

Answer: D

📘 Q31 문제 정리

🔹 문제 요약

• SysOps 관리자가 EC2 인스턴스에서 애플리케이션을 운영 중
• 애플리케이션이 DynamoDB 테이블에 접근할 수 있는 권한을 줘야 함
• 가장 적절한 방법은?

🔹 선택지 분석

• A. 액세스 키 생성 → EC2에 키 직접 넣기
  → 보안에 매우 취약 (키 유출 위험) ❌
• B. EC2 키 페어 생성 후 애플리케이션에 사용
  → 키 페어는 SSH 로그인용, DynamoDB 접근 권한과 무관 ❌
• C. IAM 사용자 생성 후 액세스 키 발급 → EC2에 할당
  → 가능하긴 하지만, 키 관리 문제와 보안 리스크 존재 ❌
• D. DynamoDB 접근 권한이 있는 IAM 역할(Role) 생성 → EC2 인스턴스 프로파일에 부여
  → 가장 안전하고 권장되는 방법 ✅

✅ 정답: D

📝 쉬운 해설

• IAM Role = 임시 보안 자격 증명을 EC2에 자동으로 부여
• EC2 Instance Profile = 역할을 EC2에 붙이는 매개체
• 애플리케이션은 액세스 키를 직접 관리하지 않고, EC2 메타데이터 서비스(IMDS)로 권한을 얻음

💡 따라서 보안성이 가장 뛰어나고, AWS에서 공식적으로 권장하는 방식은 IAM Role 사용입니다.

📊 Mermaid 시각화

```mermaid

flowchart TD
    A[EC2 인스턴스] --> B[EC2 인스턴스 프로파일]
    B --> C[IAM Role (DynamoDB 접근 권한)]
    C --> D[DynamoDB 테이블 접근]

```

 

🎯 암기 팁

👉 "EC2 → DynamoDB = IAM Role + Instance Profile"

• 액세스 키 = ❌ 위험
• 키 페어 = ❌ SSH 전용
• IAM Role = ✅ 보안 + 자동 인증

Q31.
A SysOps administrator is using Amazon EC2 instances to host an application.
The SysOps administrator needs to grant permissions for the application to access an Amazon DynamoDB table. Which solution will meet this requirement?

A. Create access keys to access the DynamoDB table. Assign the access keys to the EC2 instance profile.
B. Create an EC2 key pair to access the DynamoDB table. Assign the key pair to the EC2 instance profile.
C. Create an IAM user to access the DynamoDB table. Assign the IAM user to the EC2 instance profile.
D. Create an IAM role to access the DynamoDB table. Assign the IAM role to the EC2 instance profile.

Answer: D

📘 Q34 문제 정리

🔹 문제 요약

• 회사는 AWS Organizations를 사용해 여러 AWS 계정을 관리 중
• 기업 정책상 특정 리전만 사용 가능, 다른 리전에서는 EC2 인스턴스를 생성하면 안 됨
• 승인되지 않은 리전에서 EC2가 생성되지 않도록 운영 오버헤드가 최소인 방법을 찾아야 함

🔹 선택지 분석

• A. CloudTrail + EventBridge + Lambda로 차단
  → 가능은 하지만, 실행 후 탐지/종료 방식이라 완벽 차단 불가 ❌
• B. 각 계정별 IAM 정책으로 ec2:RunInstances 제한
  → 모든 계정마다 정책을 일일이 붙여야 해서 운영 오버헤드 큼 ❌
• C. 각 계정별 IAM 사용자/그룹에 경계 정책 연결
  → 여전히 계정별 관리 필요. 효율적이지 않음 ❌
• D. AWS Organizations의 서비스 제어 정책(SCP) 사용
  → 조직 전체(OU/루트)에 정책을 한 번만 적용하면 됨
  → “승인되지 않은 리전에서 ec2:RunInstances 거부” 가능 ✅

✅ 정답: D

📝 쉬운 해설

• SCP(Service Control Policy) = AWS Organizations에서 제공하는 정책
• 모든 하위 계정에 공통 적용 가능
• 예: "Deny ec2:RunInstances if region != ap-northeast-2"
• 즉, 회사 정책을 중앙에서 통제하고, 계정별 세부 설정 불필요

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    A[Master Account - Organizations] --> B[Service Control Policy (SCP)]
    B --> C[OU / 계정 전체 적용]
    C --> D{리전 승인 여부}
    D -->|승인됨| E[EC2 생성 허용]
    D -->|승인 안됨| F[EC2 생성 거부]

```

 

🎯 암기 팁

👉 “계정 여러 개 + 중앙 통제 = SCP”

• IAM 정책 = 계정 단위
• SCP = 조직 전체 단위 (운영 효율 최고)

Q34.
A company uses AWS Organizations to manage multiple AWS accounts.
Corporate policy mandates that only specific AWS Regions can be used to store and process customer data.
A SysOps administrator must prevent the provisioning of Amazon EC2 instances in unauthorized Regions by anyone in the company.

What is the MOST operationally efficient solution that meets these requirements?

A. Configure AWS CloudTrail in all Regions to record all API activity.
Create an Amazon EventBridge (Amazon CloudWatch Events) rule in all unauthorized Regions for ec2:RunInstances events.
Use AWS Lambda to terminate the launched EC2 instances.
B. In each AWS account, create a managed IAM policy that uses a Region condition to deny the ec2:RunInstances action in all unauthorized Regions. Attach this policy to all IAM groups in each AWS account. C. In each AWS account, create an IAM permissions boundary policy that uses a Region condition to deny the ec2:RunInstances action in all unauthorized Regions. Attach the permissions boundary policy to all IAM users in each AWS account.
D. Create a service control policy (SCP) in AWS Organizations to deny the ec2:RunInstances action in all unauthorized Regions. Attach this policy to the root level of the organization.

Answer: D

📘 Q35 문제 정리

🔹 문제 요약

• 회사 웹사이트 = CloudFront 배포 + us-east-1 S3 버킷에서 호스팅
• 요구사항 = DDoS 공격 방어 + 비율 제한(rate limiting) 기능 필요

👉 어떤 솔루션이 적합할까?

🔹 선택지 분석

• A. AWS WAF 웹 ACL을 CloudFront 배포에 연결 + 속도 기반(rate-based) 규칙 적용
  → CloudFront는 글로벌 서비스, DDoS 방어는 WAF + Shield Standard로 가능 ✅
• B. AWS WAF를 S3 버킷에 직접 연결
  → WAF는 S3에 직접 연결 불가, 오직 CloudFront, ALB, API Gateway 등에만 붙일 수 있음 ❌
• C. 차단 규칙만 사용해 WAF 적용
  → DDoS는 단순 차단 규칙보다 **비율 제한 규칙(rate limiting)**이 핵심. 요구사항 불충족 ❌
• D. S3 버킷에 연결된 WAF 적용
  → 다시 말하지만, S3에는 WAF 직접 연결 불가 ❌

✅ 정답: A

📝 쉬운 해설

• WAF(Web Application Firewall): CloudFront에 붙여서 특정 패턴/속도 기반 공격 차단 가능
• Shield Standard: CloudFront에 기본 포함되어 있어 DDoS 방어 지원
• 따라서 S3에 직접 보안 걸 수 없고, CloudFront + WAF 조합이 정답

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    A[사용자 요청] --> CF[CloudFront 배포]
    CF --> WAF[AWS WAF 웹 ACL]
    WAF -->|속도 기반 규칙 적용| CF
    CF --> S3[S3 버킷 - 웹사이트 콘텐츠]

```

 

🎯 암기 팁

👉 “S3 보안은 직접 불가 → CloudFront + WAF”

• DDoS 방어 = 기본 Shield + WAF
• Rate limiting = WAF 규칙

Q35.
A company's public website is hosted in an Amazon S3 bucket in the us-east-1 Region behind an Amazon CloudFront distribution. The company wants to ensure that the website is protected from DDoS attacks.
A SysOps administrator needs to deploy a solution that gives the company the ability to maintain control over the rate limit at which DDoS protections are applied. Which solution will meet these requirements?

A. Deploy a global-scoped AWS WAF web ACL with an allow default action.
Configure an AWS WAF rate-based rule to block matching traffic.
Associate the web ACL with the CloudFront distribution.
B. Deploy an AWS WAF web ACL with an allow default action in us-east-1.
Configure an AWS WAF rate-based rule to block matching traffic.
Associate the web ACL with the S3 bucket.
C. Deploy a global-scoped AWS WAF web ACL with a block default action.
Configure an AWS WAF rate-based rule to allow matching traffic.
Associate the web ACL with the CloudFront distribution.
D. Deploy an AWS WAF web ACL with a block default action in us-east-1.
Configure an AWS WAF rate-based rule to allow matching traffic.
Associate the web ACL with the S3 bucket.

Answer: A

📘 Q39 문제 정리

🔹 문제 요약

• SysOps 관리자가 NAT 인스턴스를 NAT 게이트웨이로 마이그레이션
• 이후, 프라이빗 서브넷 EC2 애플리케이션이 인터넷에 접근 불가

👉 가능한 원인 2가지 선택

🔹 선택지 분석

• A. 애플리케이션이 NAT 게이트웨이가 지원하지 않는 프로토콜을 사용
  → NAT 게이트웨이는 TCP/UDP만 지원, ICMP 같은 다른 프로토콜은 안 됨 ✅
• B. NAT 게이트웨이가 보안 그룹에 속하지 않음
  → NAT 게이트웨이는 ENI 기반이지만 보안 그룹을 사용하지 않음. 대신 NACL과 라우팅으로 제어됨 ❌
• C. NAT 게이트웨이가 지원되지 않는 가용 영역(AZ)에 존재
  → NAT 게이트웨이는 특정 AZ에서 생성해야 하고, 다른 AZ 리소스가 접근 가능함. 하지만 이 보기는 문제와 무관 ❌
• D. NAT 게이트웨이가 사용 불가능 상태
  → NAT 게이트웨이가 실패 상태거나 Elastic IP 미연결 시 인터넷 접근 불가 ✅
• E. 포트 포워딩 설정 문제
  → NAT 게이트웨이는 포트 포워딩 개념이 아님. ❌

✅ 정답: A, D

📝 쉬운 해설

1. NAT Gateway 제한사항
   • TCP/UDP 지원
   • ICMP (ping) 같은 다른 프로토콜은 지원하지 않음
2. 상태 확인
   • NAT GW가 “사용 불가 상태”라면 트래픽 전달 불가
   • 보통 Elastic IP 미연결, 라우팅 테이블 오류, 서브넷 문제가 원인

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    EC2[Private EC2] --> RT[Route Table: 0.0.0.0/0]
    RT --> NATGW[NAT Gateway]
    NATGW --> IGW[Internet Gateway]
    NATGW -->|비정상 상태 or 지원 안되는 프로토콜| ERR[인터넷 접근 불가]

```

🎯 암기 팁

👉 “NAT GW 장애 원인 = 프로토콜 제한 + 상태 확인”

• TCP/UDP만 지원
• NAT 게이트웨이가 “사용 불가” 상태면 인터넷 연결 안 됨

Q39.
A SysOps administrator migrates NAT instances to NAT gateways. After the migration,
an application that is hosted on Amazon EC2 instances in a private subnet cannot access the internet.
Which of the following are possible reasons for this problem? (Choose two)

A. The application is using a protocol that the NAT gateway does not support.
B. The NAT gateway is not in a security group.
C. The NAT gateway is in an unsupported Availability Zone.
D. The NAT gateway is not in the Available state.
E. The port forwarding settings do not allow access to internal services from the internet.

Answer: A, D

📘 Q46 문제 정리

🔹 문제 요약

• 회사 웹 애플리케이션: ALB 뒤의 EC2에서 동작
• 백업 사이트: S3에 정적 웹사이트로 구성
• DNS: Route 53 사용
• 요구사항:
  • ALB 기반 웹 애플리케이션이 장애나면 → 자동으로 S3 정적 웹사이트로 트래픽 전환

👉 어떤 작업 조합을 해야 할까? (2개 선택)

🔹 선택지 분석

• A. 기본 장애 조치 라우팅 정책을 ALB로 설정
  → 백업 사이트 연결 고려 없음 ❌
• B. Lambda를 이용한 수동 장애 전환
  → 자동화 요구사항 충족 못 함 ❌
• C. 기본 장애 조치 라우팅 정책 레코드를 ALB로 설정, 상태 확인과 연결
  → 정상일 때는 ALB로 트래픽 전달 ✅
• D. 보조 장애 조치 라우팅 정책 레코드를 ALB로 설정
  → 백업은 ALB가 아니라 S3여야 함 ❌
• E. 보조 장애 조치 라우팅 정책 레코드를 S3 정적 웹사이트로 설정
  → ALB 장애 시 자동으로 S3로 트래픽 전환 ✅

✅ 정답: C, E

📝 쉬운 해설

• Route 53 Failover Routing을 사용
• Primary = ALB
• Secondary = S3 정적 웹사이트
• Route 53이 Health Check로 ALB 상태를 감시
• 장애 발생 시 자동으로 S3 백업 사이트로 전환

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    U[사용자] --> R53[Route 53 - Failover Routing]
    R53 -->|ALB 정상| ALB[Application Load Balancer → EC2]
    R53 -->|ALB 장애| S3[S3 정적 웹사이트 (백업)]

```

 

🎯 암기 팁

👉 “ALB Primary + S3 Secondary = Route 53 Failover”

• ALB = 메인 서비스
• S3 = 백업 사이트
• Route 53 Health Check로 자동 전환

Q46.
A company hosts a web application on Amazon EC2 instances behind an Application Load Balancer (ALB).
The company uses Amazon Route 53 to route traffic.
The company also has a static website that is configured in an Amazon S3 bucket.

A SysOps administrator must use the static website as a backup to the web application.
The failover to the static website must be fully automated.
Which combination of actions will meet these requirements? (Choose two)

A. Create a primary failover routing policy record.
Configure the value to be the ALB.
B. Create an AWS Lambda function to switch from the primary website
to the secondary website when the health check fails.
C. Create a primary failover routing policy record.
Configure the value to be the ALB.
Associate the record with a Route 53 health check.
D. Create a secondary failover routing policy record.
Configure the value to be the static website.
Associate the record with a Route 53 health check.
E. Create a secondary failover routing policy record.
Configure the value to be the static website.

Answer: C, E

📘 Q47 문제 정리

🔹 문제 요약

• Amazon EC2 인스턴스에서 데이터 분석 애플리케이션 실행 중
• SysOps 관리자가 CloudWatch Agent에서 수집하는 메트릭에 **사용자 지정 차원(Custom Dimension)**을 추가해야 함

👉 어떤 방법이 올바른가?

🔹 선택지 분석

• A. CloudWatch Agent + 사용자 지정 스크립트
  → 가능은 하지만 번거롭고 관리 부담 큼 ❌
• B. EventBridge 규칙 + SNS 전송
  → 알림/이벤트 처리용. 메트릭에 차원 추가와는 무관 ❌
• C. CloudTrail + CloudWatch Logs + Lambda
  → CloudTrail은 API 호출 기록용. 메트릭 차원 추가와는 관계 없음 ❌
• D. CloudWatch Agent 설정 파일에 append_dimensions 필드 추가
  → 가장 올바른 방법 ✅
  → 예: {"append_dimensions": {"InstanceId": "${aws:InstanceId}"}}

✅ 정답: D

📝 쉬운 해설

• CloudWatch Agent 설정 파일(amazon-cloudwatch-agent.json)에는
  → metrics_collected (수집할 메트릭)
  → append_dimensions (추가할 사용자 지정 차원)
• 예를 들어, 각 인스턴스의 InstanceId, AutoScalingGroupName 등을 차원으로 붙일 수 있음
• 이렇게 하면 메트릭 분석/필터링이 훨씬 쉬워짐

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    EC2[EC2 인스턴스] --> CWA[CloudWatch Agent]
    CWA -->|메트릭 수집 + append_dimensions| CW[CloudWatch Metrics]
    CW --> D[사용자 지정 차원 추가된 메트릭 저장]

```

 

🎯 암기 팁

👉 CloudWatch 메트릭에 사용자 정의 차원 추가 = append_dimensions

• Agent 설정 파일에서 지정
• InstanceId, ASG 이름 같은 정보 자동 추가 가능

Q47.
A data analytics application is running on an Amazon EC2 instance.
A SysOps administrator must add custom dimensions to the metrics collected by the Amazon CloudWatch agent. How can the SysOps administrator meet this requirement?

A. Create a custom shell script to extract the dimensions and collect the metrics using the Amazon CloudWatch agent.
B. Create an Amazon EventBridge (Amazon CloudWatch Events) rule to evaluate the required custom dimensions and send the metrics to Amazon Simple Notification Service (Amazon SNS).
C. Create an AWS Lambda function to collect the metrics from AWS CloudTrail and send the metrics to an Amazon CloudWatch Logs group.
D. Create an append_dimensions field in the Amazon CloudWatch agent configuration file to collect the metrics.

Answer: D

📘 Q51 문제 정리

🔹 문제 요약

• SysOps 관리자가 아래와 같은 CloudFormation 템플릿을 사용하여 EC2 인스턴스를 생성하려고 함

👉 스택 생성이 실패하는 이유는 무엇일까?

🔹 선택지 분석

• A. 출력(Outputs) 섹션 없음
  → Outputs는 선택 사항. 없어도 스택 생성 가능 ❌
• B. 매개변수(Parameters) 섹션 없음
  → Parameters도 선택 사항. 없어도 문제 없음 ❌
• C. PrivateDnsName 속성은 CloudFormation에서 설정할 수 없음
  → ✅ 올바른 답변. PrivateDnsName은 EC2 생성 시 AWS에서 자동으로 할당하는 값이지, 사용자가 템플릿에 직접 지정 불가 ✅
• D. VPC 지정 없음
  → SubnetId를 지정했기 때문에 VPC도 자동으로 연계됨. 문제 아님 ❌

✅ 정답: C

📝 쉬운 해설

• CloudFormation에서 허용되지 않는 속성을 사용했기 때문
• EC2의 PrivateDnsName은 AWS가 인스턴스 시작 시 자동 생성하는 값
• 따라서 CloudFormation 템플릿에서 해당 속성을 수동으로 지정하면 스택 생성 실패 발생

📊 Mermaid 시각화

🎯 암기 팁

👉 “CloudFormation에서 EC2 PrivateDnsName은 자동 설정”

• 수동 지정 ❌ → 오류 발생
• AWS가 자동 할당 ✅

Q51.
A SysOps administrator is examining the following AWS CloudFormation template:

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Creates an EC2 Instance'
Resources:
  EC2Instance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: ami-79fd7eee
      InstanceType: m5n.large
      SubnetId: subnet-1abc3d3fg
      PrivateDnsName: ip-10-24-34-0.ec2.internal
      Tags:
        - Key: Name
          Value: !Sub "${AWS::StackName} Instance"

Why will the stack creation fail?

A. The Outputs section of the CloudFormation template was omitted.
B. The Parameters section of the CloudFormation template was omitted.
C. The PrivateDnsName cannot be set from a CloudFormation template.
D. The VPC was not specified in the CloudFormation template.

Answer: C

📘 Q52 문제 정리

🔹 문제 요약

• 새 애플리케이션: EC2 인스턴스에서 실행
• 데이터베이스: Amazon RDS 인스턴스
• 배포 후 애플리케이션이 실패하고,
  에러 로그: Error Establishing a Database Connection

👉 가능한 원인은? (2개 선택)

🔹 선택지 분석

• A. DB 보안 그룹에 송신 규칙 없음
  → 송신 규칙은 기본적으로 모든 아웃바운드 허용. 일반적으로 문제 원인 아님 ❌
• B. 인증서 문제
  → TLS 인증서 신뢰 관련. 여기서는 연결 자체가 안 되므로 무관 ❌
• C. DB 보안 그룹에 EC2 → DB로의 수신 규칙 없음
  → ✅ 올바른 원인. DB 보안 그룹에서 EC2 보안 그룹/서브넷을 허용해야 연결 가능
• D. EC2 애플리케이션의 포트가 DB 포트와 불일치
  → ✅ 올바른 원인. 예: DB는 3306인데 애플리케이션 설정이 3307이면 연결 불가
• E. RDS가 아직 생성 중
  → 문제에서 이미 "쿼리할 수 있다"고 했으므로 무관 ❌

✅ 정답: C, D

📝 쉬운 해설

1. DB 연결 실패 주요 원인
   • DB 보안 그룹(Security Group)에서 EC2 인스턴스 접근을 허용하지 않음
   • 앱에서 사용하는 DB 포트 설정이 잘못됨
2. EC2 → RDS 연결 성공 조건
   • 올바른 포트 (MySQL=3306, PostgreSQL=5432 등)
   • DB SG에서 EC2 SG 또는 CIDR 허용

📊 Mermaid 시각화

🎯 암기 팁

👉 “DB 연결 안 될 때는? SG 규칙 + 포트 확인”

• SG 인바운드 확인
• 앱 DB 포트 확인

Q52.
A new application runs on Amazon EC2 instances and accesses data in an Amazon RDS database instance. When fully deployed in production, the application fails.
The database can be queried from a console on a bastion host.
When looking at the web server logs, the following error is repeated multiple times:

*** Error Establishing a Database Connection Which of the following may be causes of the connectivity problems? (Choose two)

A. The security group for the database does not have the appropriate egress rule from the database to the web server.
B. The certificate used by the web server is not trusted by the RDS instance.
C. The security group for the database does not have the appropriate ingress rule from the web server to the database.
D. The port used by the application developer does not match the port specified in the RDS configuration.
E. The database is still being created and is not available for connectivity.

Answer: C, D

📘 Q55 문제 정리

🔹 문제 요약

• 회사는 CloudFront 배포를 통해 웹사이트를 제공
• 모든 트래픽 로그는 중앙에서 저장되어야 함
• 저장 시 모든 데이터는 반드시 암호화되어야 함

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

🔹 선택지 분석

• A. KMS CMK + OpenSearch
  → OpenSearch는 검색/로그 분석 서비스, CloudFront 로그 저장소로 적합하지 않음 ❌
• B. AES-256 + OpenSearch
  → 역시 저장은 가능하지만 중앙 저장/암호화 로그 저장소로는 비효율적 ❌
• C. AES-256 서버 측 암호화(SSE-S3) 적용된 S3 버킷에 CloudFront 로그 저장
  → CloudFront 액세스 로그를 S3로 저장 가능
  → S3에서 AES-256 기본 암호화 적용하면 저장 시 자동 암호화 ✅
• D. KMS 암호화된 S3 버킷 + CloudFront 로그 저장
  → 가능은 하지만 요구사항은 단순히 “모든 데이터가 암호화”
  → 기본 AES-256로 충분, KMS는 과도한 옵션 ❌

✅ 정답: C

📝 쉬운 해설

• CloudFront는 액세스 로그를 S3 버킷에 저장 가능
• S3는 저장 시 자동 암호화 기능 제공
  • SSE-S3 (AES-256): 간단하고 관리 부담 적음
  • SSE-KMS: 더 세밀한 키 관리 필요할 때 사용
• 문제 요구사항 = 저장 시 반드시 암호화 → AES-256 기본 암호화로 충족

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    U[사용자 요청] --> CF[CloudFront]
    CF --> Logs[Access Logs]
    Logs --> S3[S3 버킷 (SSE-S3, AES-256 암호화)]

```

 

🎯 암기 팁

👉 “CloudFront 로그 중앙 저장 = S3 + AES-256”

• CloudFront 로그 저장 = 항상 S3
• 데이터 암호화 = 기본 AES-256로 충분

Q55.
A company uses an Amazon CloudFront distribution to deliver its website.
Traffic logs for the website must be centrally stored, and all data must be encrypted at rest.
Which solution will meet these requirements?

A. Create an Amazon OpenSearch Service (Amazon Elasticsearch Service) domain with internet access and server-side encryption that uses the default AWS managed customer master key (CMK).
Configure CloudFront to use the Amazon OpenSearch Service (Amazon Elasticsearch Service) domain as a log destination.
B. Create an Amazon OpenSearch Service (Amazon Elasticsearch Service) domain with VPC access and server-side encryption that uses AES-256. Configure CloudFront to use the Amazon OpenSearch Service (Amazon Elasticsearch Service) domain as a log destination.
C. Create an Amazon S3 bucket that is configured with default server-side encryption that uses AES-256. Configure CloudFront to use the S3 bucket as a log destination.
D. Create an Amazon S3 bucket that is configured with no default encryption.
Enable encryption in the CloudFront distribution, and use the S3 bucket as a log destination.

Answer: C

📘 Q62 문제 정리

🔹 문제 요약

• 회사는 SysOps 관리자에게 CloudTrail 로그 파일이 생성된 후 변조되지 않았는지 확인하도록 요청
• IAM을 사용해 특정 트레일에 대한 액세스를 제한해야 함
• 요구사항: 로그 파일의 무결성 검증 기능 필요

👉 어떤 방법이 가장 효율적인가?

🔹 선택지 분석

• A. Lambda + EventBridge + DynamoDB로 MD5 해시 검증
  → 가능은 하지만 너무 복잡하고 운영 오버헤드 큼 ❌
• B. Lambda로 CloudTrail 전달 이벤트마다 해시 계산 후 S3에 저장
  → 역시 사용자 정의 코드 필요, 비효율적 ❌
• C. S3 버킷 정책으로 IAM 권한 제어
  → 권한 제어는 되지만, 파일 무결성(변조 여부) 검증은 불가 ❌
• D. CloudTrail 로그 파일 무결성 검증 기능 활성화
  → AWS에서 제공하는 기본 기능 ✅
  → CloudTrail은 각 로그 파일에 서명(Signature)과 다이제스트(Digest) 파일을 제공
  → 보안 팀이 이를 통해 로그 파일이 변조되지 않았는지 확인 가능

✅ 정답: D

📝 쉬운 해설

• CloudTrail은 옵션으로 **로그 파일 무결성 검증(File Integrity Validation)**을 지원
• 활성화 시 각 로그 파일에 대해 SHA-256 해시 + 디지털 서명을 함께 제공
• 보안팀은 이를 사용해 로그가 중간에 변조되었는지 확인 가능

📊 Mermaid 시각화

 

```mermaid

flowchart TD
    A[CloudTrail 로그 파일] --> B[SHA-256 해시 생성]
    B --> C[디지털 서명 + Digest 파일 생성]
    C --> S3[S3에 저장]
    S3 --> Sec[보안팀 검증: 변조 여부 확인]

```

 

🎯 암기 팁

👉 “CloudTrail 로그 변조 방지 = 무결성 검증 기능 ON”

• Digest 파일 + 서명 → 변조 여부 추적 가능
• Lambda 같은 커스텀 검증 불필요

Q62.
A company asks a SysOps administrator to ensure that AWS CloudTrail files are not tampered with after they are created. Currently, the company uses AWS Identity and Access Management (IAM) to restrict access to specific trails. The company's security team needs the ability to trace the integrity of each file.
What is the MOST operationally efficient solution that meets these requirements?

A. Create an Amazon EventBridge (Amazon CloudWatch Events) rule that invokes an AWS Lambda function when a new file is delivered. Configure the Lambda function to compute an MD5 hash check on the file and store the result in an Amazon DynamoDB table. The security team can use the values that are stored in DynamoDB to verify the integrity of the delivered files.
B. Create an AWS Lambda function that is invoked each time a new file is delivered to the CloudTrail bucket. Configure the Lambda function to compute an MD5 hash check on the file and store the result as a tag in an Amazon 53 object. The security team can use the information in the tag to verify the integrity of the delivered files. C. Enable the CloudTrail file integrity feature on an Amazon S3 bucket. Create an IAM policy that grants the security team access to the file integrity logs that are stored in the S3 bucket.
D. Enable the CloudTrail file integrity feature on the trail. The security team can use the digest file that is created by CloudTrail to verify the integrity of the delivered files.

Answer: D

📘 Q63 문제 정리

🔹 문제 요약

• AWS 클라우드 인프라에서 조직에 영향을 미칠 수 있는 이벤트가 발생했을 때,
• 어떤 AWS 서비스를 통해 내 리소스에 직접적인 영향 여부를 확인할 수 있을까?

🔹 선택지 분석

• A. AWS Service Health Dashboard
  → AWS 전체 리전/서비스 상태를 보여줌 (공용 대시보드)
  → 내 계정 리소스에 영향이 있는지는 알려주지 않음 ❌
• B. AWS Trusted Advisor
  → 비용 최적화, 보안, 성능, 제한(Quota) 점검 도구
  → 이벤트 영향과는 무관 ❌
• C. AWS Personal Health Dashboard
  → 내 계정과 리소스에 직접 영향이 있는 이벤트를 보여줌 ✅
  → 예: 특정 리전 EC2 장애가 내 인스턴스에 영향을 주는지 확인 가능
• D. AWS Systems Manager
  → 인스턴스/리소스 운영 관리 도구
  → 이벤트 모니터링 서비스 아님 ❌

✅ 정답: C

📝 쉬운 해설

• Service Health Dashboard = 전 세계 AWS 서비스 상태 (공통, 누구나 확인 가능)
• Personal Health Dashboard = 내 계정 리소스에 실제 영향이 있는 이벤트만 표시 (맞춤형)

즉, "조직에 영향을 주는 이벤트 확인" 문제에서는 항상 Personal Health Dashboard가 정답!

📊 Mermaid 시각화