📘 Q105.

Which tasks are the customer’s responsibility, according to the AWS shared responsibility model? (Choose two)

AWS 공유 책임 모델에 따르면 고객의 책임은 무엇입니까? (2개 선택)

✅ 정답

B. Perform client-side data encryption
C. Configure IAM credentials

💡 정답 해설

❌ 오답 해설

🧩 시각화 요약 (Mermaid)

```mermaid
flowchart TD
    A["☁️ AWS Responsibility<br>(Security of the Cloud)"] -->|🏗️ 데이터센터, 네트워크, 하드웨어| B["🏢 물리적 보안 & 글로벌 인프라"]
    A --> C["🌎 리전, AZ, 엣지 로케이션 관리"]
    D["👤 Customer Responsibility<br>(Security in the Cloud)"] -->|🔒 리소스 보안| E["🔑 IAM 설정, 접근 제어, 암호화"]
    D -->|💾 데이터 관리| F["🗄️ 클라이언트 측 암호화, 백업, 보안 그룹 구성"]
```

 

💬 구성 설명

☁️ AWS Responsibility (Security of the Cloud)

• 🏗️ 데이터센터, 네트워크, 하드웨어 → 물리적 보안 및 글로벌 인프라 관리
• 🌎 리전, AZ, 엣지 로케이션 관리 → 안정적 서비스 제공을 위한 인프라 계층 운영

👤 Customer Responsibility (Security in the Cloud)

• 🔒 리소스 보안 → IAM, 접근 제어, 암호화 설정 관리
• 💾 데이터 관리 → 백업, 클라이언트 암호화, 보안 그룹 구성

✅ 핵심 정리

📗 한 줄 요약

AWS는 “클라우드의 보안”을,
고객은 “클라우드 안의 보안”을 책임진다.
즉, IAM과 데이터 암호화는 고객의 몫입니다. 🔒

📘 Q106.

A developer has been hired by a large company and needs AWS credentials.
Which are security best practices that should be followed? (Choose two)

개발자가 대기업에 새로 입사했으며 AWS 자격 증명이 필요합니다.
어떤 보안 모범 사례를 따라야 합니까? (2개 선택)

✅ 정답

A. Grant the developer access to only the AWS resources needed to perform the job.
E. Ensure the account password policy requires a minimum length.

💡 정답 해설

❌ 오답 해설

🧩 개념 정리: IAM 보안 모범 사례 (Best Practices)

🧠 시각 요약 (Mermaid)

```mermaid
flowchart TD
    A[🔐 IAM Best Practices] --> B[🧱 Root 계정 제한 사용]
    A --> C[⚙️ 최소 권한 원칙 적용]
    A --> D[🔑 MFA 설정]
    A --> E[📏 비밀번호 정책 설정]
    A --> F[🧩 IAM Role 및 개별 사용자 생성]
```

📗 한 줄 요약

IAM 보안의 기본 원칙:
“최소 권한(Least Privilege)” + “강력한 암호 정책(Strong Password Policy)” = 안전한 AWS 계정 🔒

📘 Q128.

A company has a compute workload that is steady, predictable, and uninterruptible.
Which Amazon EC2 instance purchasing options meet these requirements MOST cost-effectively? (Choose two)

한 회사는 안정적이고 예측 가능하며 중단될 수 없는 컴퓨팅 워크로드를 가지고 있습니다.
이러한 요구사항을 가장 비용 효율적으로 충족하는 EC2 구매 옵션은 무엇입니까? (2개 선택)

✅ 정답

B. Reserved Instances
D. Savings Plans

💡 정답 해설

❌ 오답 해설

🧩 비교 표 정리

📈 시각 요약 (Mermaid)

```mermaid
graph TD
    A[💻 워크로드 특성<br>Steady, Predictable, Uninterruptible] --> B[🏷️ Reserved Instances<br>1~3년 약정, 고정 워크로드에 적합]
    A --> C[💡 Savings Plans<br>유연한 약정 기반 할인, 서비스 간 자동 적용]
    B -.->|최대 72% 절감| D[💰 Cost Efficient]
    C -.->|Flexible + Predictable| D
```

📗 한 줄 요약

예측 가능한 장기 워크로드에는
💡 “Reserved Instances + Savings Plans” 조합이 가장 경제적이다.

📘 Q131.

A company wants to migrate its on-premises workloads to the AWS Cloud.
The company wants to separate workloads for chargeback to different departments.

Which AWS services or features will meet these requirements? (Choose two)

회사는 온프레미스 워크로드를 AWS 클라우드로 마이그레이션하려고 합니다.
각 부서별로 워크로드를 분리하고 비용을 부서별로 배분(Chargeback)하려고 합니다.
어떤 AWS 서비스/기능을 사용해야 할까요? (2개 선택)

✅ 정답

B. Consolidated Billing
E. Multiple AWS Accounts

💡 정답 해설

❌ 오답 해설

🧭 개념 요약

📊 시각 요약 (Mermaid)

 

```mermaid
flowchart TD
    A["🏢 회사 계정 구조"] --> B["🧾 Payer Account<br>Consolidated Billing"]
    B --> C["📂 Dept A Account<br>R&D"]
    B --> D["📂 Dept B Account<br>Marketing"]
    B --> E["📂 Dept C Account<br>Finance"]
    B -.-> F["💰 비용 통합 관리 및 청구 보고"]
```

 

💬 구성 설명

• 🏢 회사 계정 구조 (Organization)
  AWS Organizations 기반으로 전체 계정 구조 관리
• 🧾 Payer Account (Consolidated Billing)
  모든 부서 계정의 비용을 통합 청구 및 관리
• 📂 Dept A / B / C Accounts
  각 부서별로 독립적인 AWS 리소스 운영 (R&D, Marketing, Finance 등)
• 💰 비용 통합 관리 및 청구 보고
  비용 절감, 리소스 가시성, 예산 추적 가능

📗 한 줄 요약

부서별로 비용을 분리하려면
Multiple AWS Accounts + Consolidated Billing (AWS Organizations) 조합이 정답입니다. 🧾

📘 Q137.

Which options are AWS Cloud Adoption Framework (AWS CAF) security perspective capabilities? (Choose two)

AWS Cloud Adoption Framework(AWS CAF) 보안 관점(Security Perspective)에서 제공하는 기능은 무엇입니까?
(2개 선택)

✅ 정답

C. Incident Response
D. Infrastructure Protection

💡 정답 해설

❌ 오답 해설

🧭 AWS Cloud Adoption Framework (CAF) 6 Perspectives

🧩 시각 요약 (Mermaid)

```mermaid
flowchart TD
    A[🔒 AWS CAF Security Perspective] --> B[🛡️ Infrastructure Protection]
    A --> C[🚨 Incident Response]
    A --> D[👤 Identity & Access Management]
    A --> E[🧠 Detection]
```

📗 한 줄 요약

AWS CAF의 보안(Security) 관점은 인프라 보호 + 사고 대응 중심이다.
즉, “예방(Protect) + 대응(Respond)” 이 핵심 키워드 🔐

📘 Q140.

Which AWS services can a company use to achieve a loosely coupled architecture? (Choose two)

느슨하게 결합된 아키텍처를 달성하기 위해 사용할 수 있는 AWS 서비스는 무엇입니까? (2개 선택)

✅ 정답: B. Amazon Simple Queue Service (Amazon SQS)

E. AWS Step Functions

💡 정답 해설

❌ 오답 해설

🧠 핵심 개념: Loosely Coupled Architecture

📊 시각 요약 (Mermaid)

 

```mermaid
flowchart LR
    A["🟢 Producer Service"] -->|📤 메시지 전송| B["📦 Amazon SQS Queue"]
    B -->|📥 메시지 수신| C["🔵 Consumer Service"]
    C -->|🎯 오케스트레이션| D["🧩 AWS Step Functions"]
    D --> E["⚙️ Lambda / ECS 등 워크로드"]
```

 

✅ 정답

B. Amazon Simple Queue Service (Amazon SQS)
E. AWS Step Functions

📗 한 줄 요약

SQS는 서비스 간 비동기 통신으로 결합도를 낮추고,
Step Functions는 여러 워크플로를 느슨하게 연결하여 안정적 오케스트레이션을 제공합니다. 🚀

📘 Q146.

Which option is a customer responsibility under the AWS shared responsibility model?

AWS 공동 책임 모델에서 고객의 책임에 해당하는 것은 무엇입니까?

✅ 정답: B. Application data security

💡 정답 해설

AWS와 고객은 각각 클라우드 보안의 다른 측면을 책임집니다.
이를 “Security of the Cloud” (AWS의 책임) vs “Security in the Cloud” (고객의 책임) 으로 구분합니다.

🔍 고객 책임 예시 (Security in the Cloud)

• 애플리케이션 및 데이터 암호화
• 사용자 접근 제어 (IAM)
• OS 보안 패치
• 네트워크 ACL / 보안 그룹 설정
• 로깅 및 모니터링 구성 (CloudTrail, Config 등)

🔒 AWS 책임 예시 (Security of the Cloud)

• 물리적 데이터센터 보안 (CCTV, 출입통제 등)
• 하이퍼바이저, 호스트 서버, 네트워크 인프라
• 하드웨어 유지보수 및 패치
• 글로벌 인프라 가용성 및 탄력성 확보

❌ 오답 해설

📊 시각 요약 (Mermaid)

 

```mermaid
flowchart LR
    A[AWS 책임] --> B[🔒 Security of the Cloud<br>물리적 인프라, 네트워크, 하드웨어]
    A2[고객 책임] --> C[🧩 Security in the Cloud<br>데이터, 애플리케이션, IAM, 암호화]
```

📗 한 줄 요약

AWS는 클라우드 자체를 보호(Security of the Cloud),
고객은 클라우드 내 자산을 보호(Security in the Cloud) 한다. 💡

📘 Q68. EC2 재해 복구 솔루션 (Disaster Recovery for EC2)

❓ 문제 요약

Amazon EC2 인스턴스에 대해 재해 복구(Disaster Recovery) 기능을 제공하는 AWS 서비스 또는 기능은 무엇입니까?
(2개 선택)

✅ 정답

B. EC2 Amazon Machine Images (AMIs)
C. Amazon Elastic Block Store (EBS) snapshots

💡 정답 해설

🧠 즉, AMI는 인스턴스 자체를 복제해 복구하고,
EBS Snapshot은 데이터 디스크를 백업해 복구합니다.

❌ 오답 해설

🧩 구조 시각화 (Mermaid)

```mermaid
flowchart TD
    A[💻 EC2 Instance] --> B[🖼️ Create AMI Image]
    A --> C[📦 EBS Volume]
    C --> D[📸 Take EBS Snapshot]
    B --> E[☁️ Backup stored in S3]
    D --> E
    E --> F[🔄 Restore to new EC2 instance when needed]
```

🧠 핵심 요약

📗 한 줄 정리

EC2 재해 복구의 기본은 AMI + EBS Snapshot
→ 시스템 이미지 복원 + 데이터 복원 조합이 완벽한 DR 전략! 💪

📘 Q82. Consolidated Billing — 통합 결제의 이점

❓ 문제 요약

AWS 클라우드 서비스에 대한 통합 결제(Consolidated Billing) 의 장점은 무엇입니까?
(2개 선택)

✅ 정답

A. Volume discounts
C. One bill for multiple accounts

💡 정답 해설

❌ 오답 해설

🧩 구조 시각화 (Mermaid)

```mermaid
flowchart TD
    A1[👥 여러 AWS 계정] --> B1[🏢 AWS Organizations]
    B1 --> C1[💳 Consolidated Billing]
    C1 --> D1[🧾 하나의 청구서로 통합 관리]
    C1 --> E1[💰 합산 사용량 기준으로 Volume Discount 적용]
```

🧠 핵심 요약

📗 한 줄 정리

“통합 결제(Consolidated Billing)”은
여러 계정을 묶어 한 번에 결제하고,
전체 사용량 기준으로 볼륨 할인 혜택을 받는 무료 기능입니다. 💳💰

📘 Q89. Advantages of Moving to AWS Cloud

❓ 문제 요약

AWS 클라우드로 이전했을 때 얻을 수 있는 이점(advantages) 은 무엇입니까?
(2개 선택)

✅ 정답

B. The ability to use the pay-as-you-go model.
D. No longer having to guess what capacity will be required.

💡 정답 해설

❌ 오답 해설

🧩 개념 시각화 (Mermaid)

 

```mermaid
flowchart TD
    A["🏢 On-Premise 환경"] -->|🚚 Migration| B["☁️ AWS Cloud"]
    B --> C1["💳 Pay-as-you-go<br>요금제 모델"]
    B --> C2["⚙️ Elastic Capacity<br>탄력적 용량"]
    C1 --> D1["💰 비용 효율성<br>(Cost Optimization)"]
    C2 --> D2["📈 탄력적 확장<br>(Scalability)"]
```

🧠 핵심 요약

📗 한 줄 정리

AWS 클라우드의 가장 큰 장점은
“비용 효율성(Pay-as-you-go)” + “유연한 확장성(Elastic Capacity)” 입니다. 🌩️

📘 Q97. How does AWS Cloud computing help businesses reduce costs?

❓ 문제 요약

AWS 클라우드 컴퓨팅은 기업이 비용을 절감하는 데 어떻게 도움을 주나요?
(2개 선택)

✅ 정답

B. AWS enables capacity to be adjusted on demand
E. AWS eliminates many of the costs of building and maintaining on-premises data centers

💡 정답 해설

❌ 오답 해설

🧩 개념 시각화 (Mermaid)

```mermaid
flowchart TD
    A[🏢 On-Premises Data Center] -->|🚚 Migration| B[☁️ AWS Cloud]
    B --> C1[⚙️ On-Demand Capacity Scaling]
    B --> C2[💰 No Upfront Hardware Costs]
    C1 --> D1[📉 Pay only for what you use]
    C2 --> D2[🏗️ Remove CapEx, use OpEx]
```

🧠 핵심 요약

📗 한 줄 정리

AWS는 탄력적 확장(On-Demand Capacity) 과
온프레미스 제거(CapEx 절감) 를 통해
기업의 비용 효율성(Cost Efficiency) 을 극대화합니다. 🚀

📘 Q99. Responsibility of AWS when using AWS services

❓ 문제 요약

AWS 서비스를 사용할 때, AWS가 책임지는 영역은 무엇입니까?

✅ 정답: C. Maintenance of physical and environmental controls

💡 정답 해설

AWS와 고객은 보안 책임을 공유(Shared Responsibility) 합니다.
AWS는 클라우드 “안의” 보안(Security of the Cloud) 을,
고객은 클라우드 “내의” 보안(Security in the Cloud) 을 담당합니다.

✅ AWS의 책임 (Security of the Cloud)

✅ 고객의 책임 (Security in the Cloud)

❌ 오답 해설

🧩 시각화 요약 (Mermaid)

 

```mermaid
flowchart TD
    A["☁️ AWS Responsibility<br>(Security of the Cloud)"] -->|🏗️ 데이터센터, 하드웨어, 네트워크| B["🏢 물리적 & 환경적 제어"]
    A -->|🧱 인프라 계층| C["⚙️ 하이퍼바이저 및 인프라 유지"]

    D["👤 Customer Responsibility<br>(Security in the Cloud)"] -->|🔒 리소스 보안| E["🧰 IAM, 보안 그룹, 패치 관리"]
    D -->|💾 데이터 관리| F["🗄️ 암호화 및 백업"]
```

📗 한 줄 정리

AWS는 “클라우드 자체의 보안(Security of the Cloud)” 을 담당하고,
사용자는 “클라우드 내부의 보안(Security in the Cloud)” 을 관리해야 합니다. 🔒

📘 Q3. AWS Storage Gateway 문제 정리

❓ 문제 요약

• 한 회사에는 대용량 파일 저장이 필요한 사용자 그룹이 있음.
• 현재 온프레미스(로컬) 스토리지는 용량이 부족함.
• 클라우드로 파일 저장 공간을 확장하려고 함.
• 단, 로컬 파일 공유 성능(빠른 접근성) 은 유지해야 함.

✅ 정답: B. Configure and deploy an AWS Storage Gateway file gateway.

💡 정답 해설

🔹 선택지 B: AWS Storage Gateway – File Gateway

• 온프레미스 환경에서 사용하는 파일 서버와 AWS S3를 연결하는 서비스.
• 사용자는 로컬 네트워크의 SMB/NFS 공유 방식으로 파일에 접근.
• 백엔드에서는 자동으로 S3에 업로드/저장,
  자주 쓰는 파일은 로컬 캐시에 남겨 빠른 액세스 가능.
• 결과적으로 온프레미스의 성능 + 클라우드의 확장성을 모두 얻을 수 있음.
• 운영 효율성(Operation Efficiency)이 가장 높음 ✅

❌ 오답 해설

📊 비교 요약

🔍 핵심 요약

“온프레미스에서 사용 중인 파일 서버를 클라우드로 확장하려면
AWS Storage Gateway File Gateway를 사용하여
로컬 캐시 성능을 유지하면서 S3에 확장 저장소를 구축하라.”

🧩 구조 시각화

✅ 정답: B. AWS Storage Gateway File Gateway
☁️ 핵심 개념: 하이브리드 파일 스토리지 확장 + 로컬 캐싱 + S3 연동

📘 Q24. Internet Gateway의 역할

❓ 문제 요약

VPC(가상 사설 클라우드) 내에 Internet Gateway(IGW)를 추가하는 이유는?

✅ 정답: B. To allow communication between the VPC and the Internet

VPC와 인터넷 간의 양방향 통신을 가능하게 하기 위함이다.

💡 정답 해설

🔹 Internet Gateway란?

• AWS VPC 내부 리소스(예: EC2 인스턴스)가 인터넷과 통신할 수 있도록 연결해주는 출입문 역할
• 양방향 트래픽 허용:
  • Outbound: EC2 → 인터넷
  • Inbound: 인터넷 → EC2 (보안 그룹에서 허용 시)
• IGW를 연결하고, Route Table에 0.0.0.0/0 → IGW 경로를 추가해야 외부 통신 가능

❌ 오답 해설

🌐 구조 시각화

 

```mermaid
flowchart TD
    %% 🌐 인터넷 영역
    subgraph Internet
        I["🌍 Internet User"]
    end

    %% ☁️ VPC 내부 구성
    subgraph VPC
        IGW["🔗 Internet Gateway"]
        E["💻 EC2 Instance<br>Public Subnet"]
    end

    %% 🔁 연결 관계
    I <--> IGW <--> E

    %% 💡 설명 노드
    N["💡 IGW allows internet access<br>only for resources with Public IPs"]
    IGW --- N
```

 

🧩 핵심 요약

✅ 한 줄 요약

“Internet Gateway는 VPC와 인터넷 간 통신을 가능하게 하는 관문 역할을 한다.”

📘 Q34. AWS Cloud에서의 민첩성(Agility) 개념

❓ 문제 요약

AWS 클라우드 컴퓨팅에서 “민첩성(Agility)”의 개념은 무엇을 의미하는가?
(정답 2개 선택)

✅ 정답: A, C

💡 정답 해설

❌ 오답 해설

📊 개념 정리 비교

⚙️ 시각화 (Mermaid)

 

```mermaid
flowchart TD
    A["💡 아이디어 또는<br>요구사항 발생"] --> B["🚀 빠르게 리소스 생성<br>Agility"]
    B --> C["🧪 실험 및 테스트"]
    C --> D{"❌ 실패?"}
    D -->|Yes| E["🛑 즉시 종료하여<br>비용 절감"]
    D -->|No| F["✅ 서비스 확장 및 배포"]
```

 

🧩 핵심 요약

민첩성(Agility) = “리소스를 빠르게 배포하고, 아이디어를 신속하게 실험할 수 있는 능력”
→ 클라우드가 제공하는 가장 큰 비즈니스 혁신의 기반

✅ 정답

A. The speed at which AWS resources are implemented
C. The ability to experiment quickly

📘 Q39. IAM 보안 모범 사례 (IAM Security Best Practice)

❓ 문제 요약

한 회사가 AWS 계정에 IAM을 설정하고 있습니다.
다음 중 보안 모범 사례에 해당하는 것은 무엇입니까?

✅ 정답: C. Turn on multi-factor authentication (MFA) for added security during the login process

💡 정답 해설

🔹 MFA(Multi-Factor Authentication)

• IAM 보안의 기본이자 핵심 모범 사례 ✅
• 비밀번호 외에도 추가 인증 요소(예: OTP, 하드웨어 토큰, 앱 인증) 를 요구하여 보안을 강화
• 루트 계정 및 관리자 계정은 반드시 MFA 활성화 권장

💬 즉, MFA는 “비밀번호 유출 시에도 계정 탈취를 막는 추가 방어선” 역할을 합니다.

❌ 오답 해설

📊 IAM 보안 모범 사례 요약

🧩 구조 시각화 (Mermaid)

 

```mermaid
flowchart TD
  A[🔑 IAM User Login] --> B[🔐 MFA 인증 단계 추가]
  B --> C[✅ 로그인 성공]
  A -. 비밀번호 유출시 .-> X[❌ 로그인 실패 (MFA 차단)]
```

🧠 핵심 요약

AWS IAM 보안의 첫 단계는 MFA 활성화,
그 다음은 루트 계정 최소 사용과 최소 권한 원칙 적용입니다.

📘 Q40. Elasticity in AWS Cloud

❓ 문제 요약

AWS 클라우드에서 탄력성(Elasticity) 이란 무엇을 의미합니까?
(2개 선택)

✅ 정답

B. The ability to rightsize resources as demand shifts
E. How easily resources can be procured when they are needed

💡 정답 해설

❌ 오답 해설

📊 개념 비교

⚙️ 시각화 (Mermaid)

```mermaid
flowchart LR
    A[📈 수요 증가] --> B[⚙️ Auto Scaling: EC2 인스턴스 추가]
    B --> C[💡 성능 유지]
    C --> D[📉 수요 감소]
    D --> E[⚙️ Auto Scaling: 인스턴스 종료]
    E --> F[💰 비용 절감]
```

 

 

🧠 핵심 요약

탄력성(Elasticity) =
“시시각각 변하는 수요에 따라 IT 리소스를 자동으로 확장하거나 축소할 수 있는 능력.”

→ 즉, 필요한 만큼만 사용하고, 필요 없으면 자동으로 줄이는 것!

📘 Q49. Global Content Delivery — CloudFront

❓ 문제 요약

한 회사가 이미지와 비디오를 전 세계 사용자에게 최소한의 지연(latency) 으로 전달해야 합니다.
비용 효율적인 방법으로 이를 달성하기 위해 어떤 접근 방식을 사용해야 할까요?

✅ 정답: A. Deliver the content through Amazon CloudFront

💡 정답 해설

🔹 Amazon CloudFront

AWS의 콘텐츠 전송 네트워크(CDN) 서비스입니다.
정적(이미지, 동영상, HTML 등)과 동적 콘텐츠를 전 세계 엣지 로케이션(Edge Location) 에 캐싱하여,
사용자에게 가장 가까운 위치에서 빠르게 제공합니다.

👉 핵심 효과:

• 🌎 글로벌 전송 속도 향상 (지연 최소화)
• 💰 S3나 EC2와 연동 시 비용 절감
• 🔒 SSL/TLS, WAF 등 보안 기능 통합 가능

❌ 오답 해설

🧩 구조 시각화 (Mermaid)

 

```mermaid
flowchart LR
    A[📦 S3 Origin or EC2 Server] --> B[🌍 Amazon CloudFront Edge Locations]
    B --> C[👩‍💻 Global Users]
    C -->|요청 시 가장 가까운 Edge에서 제공| B
    B -->|Cache 미존재 시 Origin으로 요청| A
```

🧠 핵심 요약

CloudFront = 전 세계 엣지 로케이션을 활용한 저지연 콘텐츠 전송 서비스

✅ 정답

A. Deliver the content through Amazon CloudFront

📘 오답노트 - 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.