✅ 이 문제는 AWS Config의 대표적인 사용 목적(컴플라이언스 및 구성 변경 추적)을 정확히 묻고 있습니다.

📘 Q612

A company has a compliance requirement to record and evaluate configuration changes,
as well as perform remediation actions on AWS resources.
Which AWS service should the company use?

한 회사에서는 구성 변경 사항을 기록하고 평가하며,
AWS 리소스에 대한 수정 조치를 수행해야 하는 규정 준수 요구 사항이 있습니다.
어떤 AWS 서비스를 사용해야 합니까?

✅ 정답: A. AWS Config

🧠 해설:

AWS Config는 AWS 리소스의 구성 변경 사항(Configuration Changes) 을 추적하고
컴플라이언스(규정 준수) 상태를 자동으로 평가하며,
필요 시 자동 복구(Remediation) 도 수행할 수 있는 관리형 서비스입니다.

즉, “누가 어떤 리소스를 만들었는가?”가 아니라
“리소스의 설정이 어떻게 바뀌었는가?”를 추적하는 서비스입니다.

⚙️ 주요 기능 요약

🧩 유사 서비스 비교

🔒 예시 시나리오

✅ 정답 요약

구성 변경 추적, 규정 준수 평가, 자동 수정(remediation)이 필요한 경우
AWS Config를 사용해야 합니다.

✅ 이 문제는 AWS Well-Architected Framework의 5가지 기둥(pillars) 중에서 어떤 항목이 해당되는지를 묻는 전형적인 CLF-C02 / SAA-C03 공통 문제입니다.

📘 Q619

A company is designing workloads in the AWS Cloud.
The company wants the workloads to perform their intended function correctly and consistently throughout their lifecycle.

회사는 AWS 클라우드에서 워크로드를 설계하고 있으며,
워크로드가 수명 주기 내내 의도된 기능을 올바르고 일관되게 수행하기를 원합니다.

➡ Which pillar of the AWS Well-Architected Framework does this goal represent?

✅ 정답: C. Reliability (안정성)

🧠 해설:

**Reliability Pillar (안정성 기둥)**은
워크로드가 의도된 기능을 올바르게 수행하고,
장애가 발생하더라도 복구(resilience)와 일관성(consistency) 을 유지하도록 하는 것을 목표로 합니다.

즉, “시스템이 끊김 없이 신뢰성 있게 작동하도록 설계”하는 것이 핵심입니다.

⚙️ Reliability Pillar 주요 구성 요소

🧩 AWS Well-Architected Framework 5대 기둥 요약

❌ 오답 분석

✅ 정답 요약

워크로드가 의도된 기능을 올바르고 일관되게 수행하도록 설계하려면
Reliability (안정성) 기둥이 핵심입니다.

✅ 이 문제는 AWS 서비스 관리 도구 중 인터페이스 차이를 구분할 수 있는지를 묻는 기본형 문제입니다.
(AWS Certified Cloud Practitioner – CLF-C02 단골문제입니다.)

📘 Q633

Which AWS service or tool provides users with a graphical interface that they can use to manage AWS services?

어떤 AWS 서비스 또는 도구가 사용자가 AWS 서비스를 관리할 수 있는
그래픽 인터페이스(GUI)를 제공합니까?

✅ 정답: C. AWS Management Console

🧠 해설

AWS Management Console은 웹 기반 그래픽 사용자 인터페이스(GUI) 로,
AWS의 모든 주요 서비스(EC2, S3, IAM, RDS 등)를 시각적으로 탐색하고 관리할 수 있는 도구입니다.

즉, AWS 서비스를 명령어 없이 마우스로 클릭해 조작할 수 있는 콘솔 환경입니다.

🖥️ AWS 서비스 관리 방식 비교표

💡 예시

✅ 정답 요약

AWS 서비스를 그래픽(GUI) 으로 관리하고 싶다면
AWS Management Console을 사용해야 합니다.

✅ 이 문제는 AWS 데이터베이스 서비스 유형 구분 — 특히 RDS / Redshift / DynamoDB / Aurora의 차이를 묻는 기본 핵심 문제입니다.
(CL, SAA, DVA 시험에서 모두 자주 출제됩니다.)

📘 Q662

Which AWS service is a fully managed NoSQL database service?

어떤 AWS 서비스가 완전 관리형(NoSQL) 데이터베이스 서비스입니까?

✅ 정답: C. Amazon DynamoDB

🧠 해설

Amazon DynamoDB는 AWS의 대표적인 완전관리형(fully managed)
NoSQL 데이터베이스 서비스로, Key-Value 및 Document 기반 스토리지를 제공합니다.

즉, 서버 관리, 확장, 백업, 장애 복구를 AWS가 모두 관리하므로
사용자는 데이터 모델링과 쿼리 로직에만 집중할 수 있습니다.

⚙️ DynamoDB 주요 특징 요약

🧩 비교: AWS 주요 DB 서비스 간 차이

💡 정답 포인트 암기법

🔸 SQL → RDS, Aurora
🔸 NoSQL → DynamoDB
🔸 분석용(DWH) → Redshift

✅ 정답 요약

완전관리형(fully managed) NoSQL DB 서비스 =
Amazon DynamoDB

✅ 이 문제는 EC2 인스턴스 구매 옵션(Purchasing Options) 의 특징을 이해하는 문제입니다.
AWS Certified Cloud Practitioner (CLF-C02)와 Solutions Architect Associate (SAA-C03) 시험에서 자주 출제되는 핵심 유형이에요.

📘 Q684

A company needs to run an application on Amazon EC2 instances without interruption.
Which EC2 instance purchasing option will meet this requirement MOST cost-effectively?

회사는 중단 없이(Without interruption) Amazon EC2 인스턴스에서
애플리케이션을 실행해야 합니다.
어떤 EC2 구매 옵션이 가장 비용 효율적으로 이 요구사항을 충족할까요?

✅ 정답: A. Standard Reserved Instances

🧠 해설

**Standard Reserved Instances (RI)**는
1년 또는 3년 동안 지속적인 사용(steady-state usage) 을 약정함으로써
On-Demand 대비 최대 72%까지 절감할 수 있는 비용 효율적인 옵션입니다.

이 문제에서 핵심 키워드는 👇

"without interruption" (= 항상 실행되어야 함)
→ 즉, 중단이 없어야 하는 상시 워크로드
→ 따라서 Reserved Instance (RI) 가 정답입니다.

⚙️ EC2 인스턴스 구매 옵션 비교표

💡 정답 포인트 요약

✅ 정답 요약

중단 없이 항상 실행되어야 하고
가장 비용 효율적인 옵션은
Standard Reserved Instance 입니다.

📘 Q403.

Which statements represent the cost-effectiveness of the AWS Cloud? (Choose two)

AWS 클라우드의 비용 효율성을 나타내는 설명은 무엇입니까? (2개 선택)

✅ 정답: A. Users can trade fixed expenses for variable expenses.

✅ 정답: E. Users benefit from economies of scale.

💡 해설

🧮 A. Users can trade fixed expenses for variable expenses

• 온프레미스 환경에서는 서버, 스토리지, 네트워크 장비 등을 미리 구입해야 하는 고정비용(CapEx) 이 필요합니다.
• 반면 AWS는 필요할 때만 리소스를 사용하고 그만큼만 비용을 지불하는 변동비용(OpEx) 구조입니다.

📊 예시:

• 기존: 서버 10대를 선구매(수천만 원의 초기 비용)
• AWS: 실제 사용 시간만큼만 과금 (예: 2시간만 EC2 인스턴스 실행)

👉 즉, “고정비를 변동비로 전환”함으로써 초기 투자 부담 없이 클라우드 도입이 가능합니다.

💡 E. Users benefit from economies of scale

• AWS는 전 세계 수백만 고객의 인프라 사용량을 기반으로 규모의 경제(economies of scale) 를 실현합니다.
• 대규모 인프라 운영으로 인해 AWS는 더 낮은 단가로 컴퓨팅 파워, 스토리지, 네트워크 서비스를 제공할 수 있습니다.

📉 효과:

• AWS의 고객이 많아질수록 단가가 낮아지고,
• 그 혜택이 다시 사용자에게 가격 인하(Price Reduction) 형태로 돌아옵니다.

🏷️ 실제로 AWS는 2006년 이후 100회 이상 공식적으로 가격을 인하했습니다.

❌ 오답 해설

📊 핵심 요약

🧩 시각 요약 (Mermaid)

```mermaid
flowchart LR
    A["🏢 On-Premises"] -->|"💰 CapEx - 서버 구매 및 유지비"| B["💸 높은 고정비"]
    C["☁️ AWS Cloud"] -->|"⚙️ OpEx - 사용한 만큼 지불 (Pay-as-you-go)"| D["💵 변동비 + 효율적 비용"]
    D -->|"📉 규모의 경제로 지속적 가격 인하"| E["🚀 비용 효율 향상"]
```

 

📗 한 줄 요약

☁️ AWS의 비용 효율성 핵심은 “CapEx → OpEx 전환” + “규모의 경제(Economies of Scale)”

📘 Q406.

A company needs to consolidate the billing for multiple AWS accounts.

여러 AWS 계정의 결제를 통합해야 한다면 어떤 서비스를 사용해야 할까요?

✅ 정답: B. AWS Organizations

💡 정답 해설

🔹 AWS Organizations란?

AWS Organizations는 여러 AWS 계정을 중앙에서 관리하고,
청구서 통합(Consolidated Billing) 및 정책 제어(Service Control Policies, SCPs) 를 수행할 수 있는 서비스입니다.

✅ 핵심 기능

🧮 Consolidated Billing 예시

즉, 개별 계정이 아닌 조직 전체 사용량을 기준으로 할인율이 적용되어
비용 효율성이 증가합니다.

❌ 오답 해설

🧩 시각 요약 (Mermaid)

```mermaid
flowchart TD
    A["👩‍💼 Management / Payer Account"] -->|"🧾 Consolidated Billing"| B["👥 Linked Accounts"]
    B -->|"📊 Usage Data + 💸 Discounts"| C["💰 Single Combined Invoice"]
    A -->|"🛡️ Apply SCPs"| D["🔒 Control Policies"]
```

 

📗 한 줄 요약

💼 여러 AWS 계정의 청구를 통합하려면 AWS Organizations의 Consolidated Billing 기능을 사용합니다.

VPC 내에서 EC2 인스턴스 간 트래픽 제어를 위한 AWS 네이티브 보안 리소스를 묻는 문제입니다.

📘 Q413.

Which AWS service or feature will meet this requirement?

특정 EC2 인스턴스 간의 네트워크 트래픽을 제어하기 위한 AWS 기본 보안 기능은 무엇입니까?

✅ 정답: D. Security groups

💡 해설

🔹 Security Group이란?

• AWS의 가상 방화벽(Virtual Firewall) 역할을 하는 인스턴스 수준 보안 제어(Instance-level security control) 기능입니다.
• VPC 내의 개별 EC2 인스턴스 간 트래픽을 허용하거나 차단할 수 있습니다.

✅ 주요 특징

🧱 예시 시나리오

회사가 VPC 안에 EC2 인스턴스 10개를 실행 중이고,
이 중 웹 서버(EC2-1) 와 DB 서버(EC2-2) 사이에만 통신을 허용하고 싶을 때:

• EC2-2(DB) 인스턴스의 Security Group에서
  • Inbound 규칙: EC2-1의 Security Group ID로부터만 3306(MySQL) 포트 허용
  • 다른 트래픽은 모두 차단

✅ 이렇게 하면 DB 인스턴스는 지정된 웹 서버 SG에서 오는 요청만 수락합니다.

❌ 오답 해설

🧩 시각 요약 (Mermaid)

 

```mermaid
flowchart LR
    A["💻 EC2-1 - Web Server"] -->|"✅ Allow Port 3306"| B["🗄️ EC2-2 - DB Server"]
    A -.->|"🚫 Other Ports Denied"| B
    subgraph VPC ["🌐 VPC"]
        A
        B
    end
    Note["🔒 Security Group - Instance-level, Stateful, Allow-based Rules"]
```

 

📗 한 줄 요약

🛡️ EC2 인스턴스 간 트래픽 제어는 보안 그룹(Security Group) 으로 수행하며, 이는 인스턴스 수준의 상태 저장형 방화벽입니다.

📘 Q426.

Which AWS service should the company use to meet these requirements?

전 세계 사용자에게 웹사이트를 빠르고 효율적으로 전달하려면 어떤 서비스를 사용해야 할까요?

✅ 정답: B. Amazon CloudFront

💡 해설

🔹 Amazon CloudFront란?

Amazon CloudFront는 AWS의 글로벌 콘텐츠 전송 네트워크(CDN, Content Delivery Network) 서비스입니다.
전 세계 600개 이상의 Edge Location(엣지 로케이션) 을 통해 콘텐츠를 캐싱하고,
사용자에게 가장 가까운 위치에서 데이터를 전송함으로써 지연시간(Latency) 을 최소화합니다.

✅ CloudFront의 주요 역할

📦 구성 예시

회사는 EC2 인스턴스에서 웹사이트를 호스팅 중
CloudFront를 구성하여 전 세계 엣지 로케이션에 캐싱하면 지연이 크게 감소합니다.

 

 

📍 요약:
사용자는 가까운 Edge Location을 통해 콘텐츠를 받기 때문에
서울, 뉴욕, 런던 어디서 접속하든 빠른 속도로 웹사이트가 표시됩니다.

❌ 오답 해설

🧩 CloudFront의 장점 정리

📗 한 줄 요약

⚡ 전 세계 사용자에게 빠르고 안전하게 웹사이트를 전달하려면 Amazon CloudFront (CDN) 를 사용하세요.

📘 Q435.

Which AWS service should the company use to identify who accessed an AWS service and what action was performed?

✅ 정답: B. AWS CloudTrail

💡 해설

🔹 AWS CloudTrail이란?

AWS CloudTrail은 계정 내에서 발생한 모든 API 호출(Activity Logs) 을 기록하는 감사(Audit) 서비스입니다.

즉,
“누가 (Who)”,
“언제 (When)”,
“어디서 (Where)”,
“무엇을 (What)”
했는지를 모두 추적할 수 있습니다.

✅ 주요 기능 요약

🧠 예시 시나리오

회사가 “어제 누가 S3 버킷을 삭제했는지” 확인해야 한다면?

1. CloudTrail 콘솔 → Event history(이벤트 기록) 로 이동
2. Event Name = DeleteBucket 검색
3. 결과에서 userIdentity 필드를 확인
   → 해당 작업을 수행한 사용자 또는 IAM Role을 확인 가능

📦 로그 저장 구조 (예시)

{
  "eventVersion": "1.05",
  "userIdentity": {
    "type": "IAMUser",
    "userName": "admin-user"
  },
  "eventTime": "2025-10-18T09:33:12Z",
  "eventSource": "s3.amazonaws.com",
  "eventName": "DeleteBucket",
  "sourceIPAddress": "203.0.113.45"
}

위 로그에서 누가(userName), 언제(eventTime), 어떤 서비스(eventSource) 에서
어떤 행동(eventName) 을 수행했는지를 알 수 있습니다.

❌ 오답 해설

🧩 시각 요약 (Mermaid)

 

```mermaid
flowchart TD
    A["👤 IAM User / Role"] -->|API Call| B["🧠 AWS CloudTrail"]
    B --> C["📦 S3 Log Storage"]
    B --> D["🔍 Event History Console"]
    D --> E["👁️ Identify who, when, and what action was taken"]
```

 

📗 한 줄 요약

🕵️‍♂️ AWS CloudTrail은 “누가 언제 무엇을 했는지”를 기록하는 감사 및 보안 추적 서비스입니다.

여러 VPC 및 온프레미스 네트워크를 효율적으로 연결하고, 피어링 관계를 단순화하기 위한 AWS 네트워크 서비스를 묻고 있습니다.

📘 Q445.

Which AWS service can the company use as a cloud router to simplify peering relationships?

여러 VPC와 온프레미스 네트워크를 연결하고 라우팅을 단순화하기 위해 사용할 수 있는 AWS 서비스는 무엇입니까?

✅ 정답: B. AWS Transit Gateway

💡 해설

🔹 AWS Transit Gateway란?

AWS Transit Gateway는 여러 VPC, 온프레미스 네트워크, VPN 연결을
하나의 중앙 허브(Cloud Router) 를 통해 연결하는 서비스입니다.

기존의 VPC Peering(1:1 연결) 은 복잡한 Full Mesh 구조를 만들어 관리가 어려웠지만,
Transit Gateway를 사용하면 모든 네트워크가 하나의 허브를 통해 간단히 통신할 수 있습니다.

✅ 주요 특징

🧩 구조 예시

기존의 VPC Peering 방식은 복잡한 N² 구조를 가지지만,
Transit Gateway를 사용하면 중앙 허브 형태로 간결하게 연결됩니다.

 

📦 시나리오 예시

회사가 여러 부서(VPC)를 운영하며 온프레미스 데이터센터와 연결할 때,

• Before (VPC Peering)
  • VPC 간 개별 Peering (A↔B, B↔C, A↔C...)
  • 관리 복잡도 ↑
• After (Transit Gateway)
  • 모든 VPC가 Transit Gateway에 연결
  • 라우팅 중앙 관리, 트래픽 제어 단순화 ✅

❌ 오답 해설 

📗 한 줄 요약

🔄 여러 VPC와 온프레미스 네트워크를 하나의 중앙 허브로 연결하려면 AWS Transit Gateway를 사용합니다 — “Cloud Router” 역할을 수행합니다.

온프레미스 시스템에 대한 저지연(로우 레이턴시) 접근과 데이터 상주(Data Residency) 요구사항을 동시에 충족해야 하는 상황을 묻고 있습니다.

📘 Q459.

Which AWS service should the company use to design a solution that meets these requirements?

“로우 레이턴시(저지연) + 데이터 상주(데이터가 회사 내에 머무를 것)”
👉 어떤 AWS 서비스를 사용해야 할까요?

✅ 정답: D. AWS Outposts

💡 해설

🔹 AWS Outposts란?

AWS Outposts는 AWS 인프라, 서비스, API, 툴을
고객의 온프레미스 데이터센터 또는 로컬 환경에 물리적으로 설치하여
AWS 클라우드와 동일한 경험을 제공하는 하이브리드 클라우드 솔루션입니다.

즉,

“온프레미스에서 AWS를 그대로 사용하는 서비스” 입니다.

✅ Outposts의 주요 특징

📦 아키텍처 예시

 

📍 결과:

• 데이터는 회사 내(On-prem)에 상주
• AWS API, 관리 콘솔, 서비스는 그대로 사용 가능
• 로컬 처리로 짧은 지연시간 보장

🧠 사용 사례

❌ 오답 해설

📗 한 줄 요약

🧩 AWS Outposts = AWS 인프라를 온프레미스에 직접 설치하여
저지연 처리와 데이터 상주 규제 준수를 동시에 만족시키는 하이브리드 클라우드 솔루션.

Amazon CloudFront에 유입되는 악성 HTTP/HTTPS 요청을 감시하고 차단하는 서비스를 묻는 문제입니다.

📘 Q468.

Which AWS service should the company use to monitor and block malicious HTTP and HTTPS requests that its Amazon CloudFront distributions receive?

CloudFront로 들어오는 악성 요청(HTTP/HTTPS)을 탐지하고 차단하기 위해 어떤 서비스를 사용해야 할까요?

✅ 정답: C. AWS WAF (Web Application Firewall)

💡 해설

🔹 AWS WAF란?

AWS WAF(Web Application Firewall) 는
웹 애플리케이션 계층(Layer 7) 의 공격으로부터
HTTP 및 HTTPS 트래픽을 필터링, 모니터링, 차단하는 보안 서비스입니다.

✅ 주요 기능 요약

⚙️ 구성 예시

🧠 시나리오 예시

한 회사의 웹사이트가 DDoS나 SQL Injection 공격을 받는다면?

• CloudFront에 AWS WAF를 연결하면,
  공격 트래픽은 엣지 로케이션(Edge Location) 단계에서 즉시 차단됨.
• AWS Shield와 함께 사용하면 DDoS 방어도 강화 가능.

❌ 오답 해설

📗 한 줄 요약

🧩 AWS WAF는 CloudFront, ALB, API Gateway에 연결되어
악성 HTTP/HTTPS 요청을 탐지·차단하는 웹 방화벽(Web Application Firewall) 서비스입니다.

“외부 ID 공급자(IdP)를 사용하는 회사가, 별도의 자격 증명 없이 AWS에 접근할 수 있도록 하는 서비스”를 묻고 있습니다.

📘 Q477.

A company uses a third-party identity provider (IdP).
Which AWS service will meet this requirement?

회사에서 외부 IdP(예: Azure AD, Okta, Google Workspace 등)를 사용 중이며,
직원들이 별도의 로그인 자격 증명 없이 AWS 리소스에 접근할 수 있도록 해야 합니다.

✅ 정답: B. Amazon Cognito

💡 해설

🔹 Amazon Cognito란?

Amazon Cognito는 사용자 인증(Authentication), 권한 부여(Authorization),
그리고 사용자 관리(User Management)를 제공하는 ID 관리 서비스입니다.

특히,

• 외부 IdP(Identity Provider) 와의 통합 인증 (Federation) 기능을 제공하므로,
• 사용자는 기존 회사 계정 (예: Google, SAML, Azure AD) 으로 로그인할 수 있습니다.

즉,

“AWS 리소스 접근 시 새로운 로그인 정보 없이 기존 계정으로 인증할 수 있다”
👉 바로 Cognito Federated Identity 기능입니다.

✅ Cognito의 두 가지 주요 구성요소

⚙️ 인증 흐름 예시

요약:
외부 IdP → Cognito → AWS STS → AWS 리소스 접근

🧠 시나리오 예시

회사가 Google Workspace 를 사용 중이라면,
Cognito를 통해 Google 계정으로 AWS 서비스 로그인 가능.
→ 별도의 IAM 유저 생성 불필요
→ 기존 ID 관리 체계를 그대로 유지

❌ 오답 해설

📗 한 줄 요약

🔐 Amazon Cognito는 외부 IdP(Azure AD, Google, Okta 등)와 연동하여
별도의 AWS 자격 증명 없이 기존 계정으로 로그인 가능하게 해주는 서비스입니다.

“반복 가능하고 일관된 인프라 구성(Highly Repeatable Infrastructure Configurations)”을 가능하게 하는 AWS 서비스를 묻고 있습니다.

📘 Q487.

Which AWS service gives users the ability to deploy highly repeatable infrastructure configurations?

반복적이고 예측 가능한 방식으로 인프라를 배포하려면 어떤 AWS 서비스를 사용해야 할까요?

✅ 정답: A. AWS CloudFormation

💡 해설

🔹 AWS CloudFormation이란?

AWS CloudFormation은 인프라를 코드로 관리 (IaC, Infrastructure as Code) 할 수 있는 서비스입니다.
즉, YAML 또는 JSON 템플릿을 통해 AWS 리소스를 반복적이고 일관되게 배포할 수 있습니다.

✅ 핵심 개념

⚙️ 예시 (CloudFormation 템플릿 - YAML)

AWSTemplateFormatVersion: '2010-09-09'
Description: Simple EC2 instance template

Resources:
  MyEC2Instance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t3.micro
      ImageId: ami-0abcdef1234567890
      Tags:
        - Key: Name
          Value: MyCFNInstance

➡️ 위 템플릿을 실행하면 동일한 EC2 인스턴스를 여러 번 반복적으로 배포 가능합니다.

🧠 예시 시나리오

개발팀, 테스트팀, 운영팀이 동일한 아키텍처를 각각의 환경에 구축해야 할 때
CloudFormation 템플릿 하나로 Dev/Test/Prod 환경을 쉽게 복제 가능

❌ 오답 해설

📗 한 줄 요약

🧩 AWS CloudFormation은 인프라를 코드(YAML/JSON)로 정의하여
반복적이고 자동화된 방식으로 AWS 리소스를 일관되게 배포할 수 있게 해주는 서비스입니다.

음성 통화(Voice Calls) 및 웹 채팅(Web Chat) 기능을 활용한 고객 서비스 제공에 적합한 AWS 서비스를 묻고 있습니다.

📘 Q488.

A company needs to provide customer service by using voice calls and web chat features.
Which AWS service should the company use to meet these requirements?

음성 통화 및 웹 채팅 기능으로 고객 상담 서비스를 제공해야 합니다.
어떤 AWS 서비스를 사용해야 할까요?

✅ 정답: B. Amazon Connect

💡 해설

🔹 Amazon Connect란?

Amazon Connect는 클라우드 기반 컨택 센터(Contact Center) 서비스로,
음성 통화, 채팅, 상담 워크플로우를 손쉽게 구성할 수 있는 AWS 서비스입니다.

즉, 고객이 전화나 채팅으로 문의할 때 상담원과 연결해주는
콜센터 솔루션을 AWS에서 완전관리형(fully managed) 형태로 제공합니다.

✅ Amazon Connect의 주요 특징

⚙️ 예시 아키텍처

 

🧠 예시 시나리오

예를 들어, 온라인 쇼핑몰에서 고객이
“배송이 지연되었어요” 라고 채팅하거나 전화를 걸면,
Amazon Connect가 Amazon Lex를 통해 자동 응답 후,
필요 시 상담원에게 연결합니다.

❌ 오답 해설

📗 한 줄 요약

🎧 Amazon Connect는 AWS의 클라우드 기반 컨택 센터(Contact Center) 서비스로,
음성 통화·웹 채팅·AI 챗봇 통합 기능을 통해
고객 지원(Customer Service) 을 쉽고 빠르게 구축할 수 있습니다.

VPC 내에서 서브넷(subnet) 수준의 방화벽 역할을 하는 기능을 묻고 있습니다.

📘 Q493.

Which AWS tool or feature acts as a VPC firewall at the subnet level?
서브넷 수준에서 VPC 방화벽 역할을 하는 AWS 도구 또는 기능은 무엇입니까?

✅ 정답: B. Network ACL

💡 해설

🔹 Network ACL (NACL, Network Access Control List)

Network ACL은 서브넷(Subnet) 수준에서 트래픽을 제어하는 방화벽 역할을 합니다.

• VPC의 각 서브넷(Subnet) 에 적용되며,
• 들어오는(Inbound) 및 나가는(Outbound) 트래픽을
  허용(Allow) 또는 거부(Deny) 규칙으로 제어합니다.

✅ 주요 특징 비교

⚙️ 동작 흐름 예시

• 트래픽이 서브넷에 들어오거나 나갈 때 Network ACL이 검사합니다.
• 따라서, 보안 그룹보다 먼저 트래픽을 필터링할 수 있습니다.

🧠 예시 시나리오

회사가 VPC 내 Public Subnet과 Private Subnet 간 통신을 제한하려고 할 때
Network ACL을 설정하여 특정 포트(예: 22, 80) 만 허용하고 나머지는 차단할 수 있습니다.

❌ 오답 해설

📗 한 줄 요약

🧱 Network ACL은 서브넷 단위의 방화벽으로,
인바운드/아웃바운드 트래픽을 허용 또는 거부 규칙으로 제어하는
비상태(stateless) 보안 레이어입니다.

모놀리식(monolithic) 애플리케이션을 마이크로서비스(MSA) 로 분리해 AWS로 이전하는 전략을 묻고 있습니다.

📘 Q500.

A company is planning to migrate a monolithic application to AWS.
The company wants to modernize the application by splitting it into microservices.
Which migration strategy should the company use?

회사는 모놀리식 애플리케이션을 AWS로 마이그레이션할 계획이며,
이를 마이크로서비스 아키텍처로 현대화(modernize) 하려고 합니다.
어떤 마이그레이션 전략을 사용해야 할까요?

✅ 정답: D. Refactor (리팩터링)

💡 해설

🔹 Refactor란?

Refactor (또는 Re-architect) 는 애플리케이션 아키텍처를 근본적으로 재설계하여
클라우드 네이티브 기능과 확장성을 극대화하는 가장 현대적인 마이그레이션 전략입니다.

✅ Refactor의 핵심 개념

⚙️ 예시 시나리오

 

• 기존의 한 덩어리 애플리케이션(모놀리식)을
  여러 개의 독립적인 서비스(마이크로서비스) 로 나누고
  AWS의 컨테이너(ECS, EKS) 나 서버리스(Lambda) 기반으로 재구성합니다.

❌ 오답 해설

🧠 7R Migration Strategies 요약표

📗 한 줄 요약

🧠 Refactor는 모놀리식 애플리케이션을 마이크로서비스 아키텍처(MSA) 로 재설계하여
AWS의 클라우드 네이티브 기능을 최대한 활용하는 현대화 전략입니다.

📘 Q335.

Which options are AWS Cloud Adoption Framework (AWS CAF) cloud transformation journey recommendations? (Choose two)

AWS CAF(Cloud Adoption Framework) 클라우드 전환 여정 권장 사항은 어떤 단계입니까? (2개 선택)

✅ 정답: A. Envision phase, B. Align phase

💡 정답 해설

AWS CAF는 조직이 클라우드로 성공적으로 전환(Cloud Transformation) 하도록 돕기 위한 전략적 프레임워크입니다.
즉, 단순히 기술 이전(migration)만이 아니라 조직, 인력, 거버넌스, 비즈니스 프로세스 전반을 고려합니다.

🔹 AWS Cloud Transformation Journey (CAF 3-Phase Model)

❌ 오답 해설

🧠 핵심 개념 요약

📊 시각 요약 (Mermaid 다이어그램)

```mermaid
flowchart LR
    A[🏁 Envision Phase<br>비전 수립 및 목표 정의] --> B[⚙️ Align Phase<br>조직·운영 모델 정렬]
    B --> C[🚀 Launch/Mobilize Phase<br>실행 기반 및 초기 마이그레이션]
```

🧭 핵심 요약

AWS CAF의 3단계는 다음과 같습니다:
Envision → Align → Launch (또는 Mobilize)
즉, **“비전을 정립하고 → 조직을 정렬하고 → 실행 준비를 하는 과정”**입니다.

📗 한 줄 요약

☁️ AWS CAF의 핵심 전환 단계는 Envision → Align → Launch
즉, “비전 정립 → 정렬 → 실행” 의 순서로 클라우드 전환이 이루어집니다.

Amazon EC2 인스턴스 접속 방식을 묻는 대표적인 기초 실무형 문제

📘 Q346.

A company launched an Amazon EC2 instance with the latest Amazon Linux 2 AMI.
Which actions can a system administrator take to connect to the EC2 instance? (Choose two)

Amazon Linux 2 AMI로 생성된 EC2 인스턴스에 접속하기 위한 방법은 무엇입니까? (2개 선택)

✅ 정답: A. Use Amazon EC2 Instance Connect

✅ 정답: D. Use AWS Systems Manager Session Manager

💡 정답 해설

1️⃣ Amazon EC2 Instance Connect

• Amazon Linux 2 또는 Ubuntu 등 지원되는 AMI에서 SSH 접속을 대신해주는 AWS 기능.
• 브라우저 기반 SSH 접속 기능으로, AWS 콘솔에서 바로 접속 가능.
• 키 페어 없이도 일시적(temporary) 공개키를 전송해 연결 가능.
• 전제 조건:
  • EC2 인스턴스에 EC2 Instance Connect 패키지 설치
  • 인바운드 22번 포트(SSH) 열려 있어야 함
  • IAM 권한: ec2-instance-connect:SendSSHPublicKey

2️⃣ AWS Systems Manager Session Manager

• EC2 인스턴스에 Session Manager 에이전트(SSM Agent) 가 설치되어 있으면
  브라우저 기반 터미널 접속 가능.
• SSH 포트(22) 가 열려 있지 않아도 안전하게 접속 가능.
• VPC 내 비공개 인스턴스(Private Subnet) 도 연결 가능.
• 필요 조건:
  • EC2에 SSM Agent 설치
  • IAM 역할에 SSM 관련 권한 부여 (AmazonSSMManagedInstanceCore)
  • AWS Systems Manager 서비스 활성화

❌ 오답 해설

🧠 핵심 요약

📊 시각 요약 (Mermaid)

 

```mermaid
flowchart TD
    A["👩‍💻 Admin"] -->|🔐 EC2 Instance Connect| B["🐧 Amazon Linux 2 EC2"]
    A -->|🧩 SSM Session Manager| B
    B -.-> C["🪟 RDP - Windows Only ❌"]
```

📗 한 줄 요약

☁️ Amazon Linux 2 EC2 인스턴스는
EC2 Instance Connect 또는 SSM Session Manager로 접속할 수 있습니다 —
SSH 포트 유무에 따라 적절히 선택!

AWS Well-Architected Framework 중 Sustainability Pillar (지속 가능성 기둥) 의 핵심 원칙을 묻는 문제입니다.

최근 시험에서 자주 등장하는 유형

📘 Q358.

Which design principles should a company apply to AWS Cloud workloads to maximize sustainability and minimize environmental impact? (Choose two)

AWS 클라우드 워크로드의 지속 가능성을 극대화하고 환경적 영향을 최소화하기 위한 설계 원칙은 무엇입니까? (2개 선택)

✅ 정답: A. Maximize utilization of Amazon EC2 instances

✅ 정답: E. Reduce the need for users to reinstall applications

💡 정답 해설

AWS Sustainability Pillar 의 목표는

“최소한의 리소스로 최대의 성능을 달성하여 탄소 배출량과 낭비를 줄이는 것”
입니다 🌱

즉, 효율을 극대화하고, 중복 리소스 및 불필요한 작업을 줄이는 것이 핵심이에요.

✅ A. Maximize utilization of Amazon EC2 instances

• 사용 중인 인스턴스의 활용도를 극대화하여 낭비되는 컴퓨팅 자원을 줄임
• 예:
  • 워크로드에 맞는 적절한 인스턴스 크기 선택
  • Auto Scaling 사용
  • Serverless나 container 기반 아키텍처 활용

📈 → 더 높은 리소스 효율성과 낮은 전력 소비로 지속 가능성 향상

✅ E. Reduce the need for users to reinstall applications

• 사용자가 애플리케이션을 자주 재설치하거나 중복 실행하지 않도록 설계
• 예:
  • 중앙 집중 배포(Auto-deploy pipelines)
  • 캐싱 및 자동 복원 기능 적용
  • 지속 가능한 유지보수 설계

♻️ → 재작업을 줄여 불필요한 컴퓨팅, 스토리지 사용, 네트워크 부하 감소

❌ 오답 해설

🌍 AWS Sustainability 설계 원칙 요약

📊 시각 요약 (Mermaid)

 

```mermaid
flowchart LR
    A[🌱 Sustainable Design] --> B[📈 Maximize Resource Utilization]
    A --> C[🔁 Reduce Rework & Redundant Tasks]
    B --> D[⚙️ Auto Scaling, Right-Sizing]
    C --> E[🧩 Automation, Caching]
```

 

📗 한 줄 요약

♻️ AWS 지속 가능성의 핵심은
**“적게 쓰는 것”이 아니라, “효율적으로 쓰는 것”**입니다.

📘 Q359.

In which ways does the AWS Cloud offer lower total cost of ownership (TCO) of computing resources than on-premises data centers? (Choose two)

AWS 클라우드는 어떤 방식으로 온프레미스 데이터 센터보다 컴퓨팅 리소스의 총 소유 비용(TCO)을 낮추나요? (2개 선택)

✅ 정답: A. AWS replaces upfront capital expenditures with pay-as-you-go costs.

✅ 정답: D. AWS uses economies of scale to continually reduce prices.

💡 정답 해설

AWS는 비용 구조 혁신(Cost Model Innovation) 을 통해
온프레미스 대비 TCO(총소유비용, Total Cost of Ownership) 를 획기적으로 낮출 수 있습니다.
그 핵심은 다음 두 가지입니다 👇

✅ A. AWS replaces upfront capital expenditures with pay-as-you-go costs

• 온프레미스 환경에서는 서버, 네트워크, 스토리지 등의 초기 자본 지출(CapEx) 이 필요합니다.
• 반면 AWS는 운영비용(OpEx) 모델, 즉 사용한 만큼 지불(Pay-as-you-go) 방식을 제공합니다.
• 즉, 초기 투자 없이도 즉시 인프라 사용 가능 → 비용 효율성과 확장성 향상

📈 효과:

• 초기 하드웨어 구매, 설치, 유지보수 비용 제거
• 불필요한 용량 계획(capacity planning) 불필요
• 사용량에 따른 유연한 지출 구조

✅ D. AWS uses economies of scale to continually reduce prices

• AWS는 전 세계 수백만 고객의 수요를 기반으로 규모의 경제(Economies of Scale) 를 실현합니다.
• 대규모 인프라 운영을 통해 단가를 낮출 수 있고,
  그 절감된 비용을 고객에게 지속적인 가격 인하 형태로 환원합니다.

📊 예시:

• AWS는 지난 10년간 100회 이상 공식 가격 인하(Price Reduction) 발표
• 클라우드 전체 인프라 효율이 향상될수록 고객의 단위당 비용도 절감

❌ 오답 해설

🧠 핵심 요약

📊 시각 요약 (Mermaid)

 

```mermaid
flowchart LR
    A["💰 On-Premises"] -->|"💵 CapEx - 서버 구매 및 유지비"| C["💸 높은 TCO"]
    B["☁️ AWS Cloud"] -->|"⚙️ Pay-as-you-go + 규모의 경제"| D["📉 낮은 TCO"]
```

📗 한 줄 요약

☁️ AWS의 낮은 TCO 비결 = 초기투자 제거 + 규모의 경제 기반 지속적 가격 인하

Amazon CloudFront의 핵심 기능을 묻는 대표적인 AWS 서비스 구분 문제입니다.
CloudFront, Route 53, ALB(로드 밸런서) 등의 기능을 혼동하지 않도록 정확히 구분해야 합니다.

📘 Q365.

What does Amazon CloudFront provide?

Amazon CloudFront는 무엇을 제공합니까?

✅ 정답: B. Secure delivery of data, videos, applications, and APIs to users globally with low latency

전 세계 사용자에게 짧은 지연시간(low latency) 과 보안성 높은 콘텐츠 전송을 제공합니다.

💡 정답 해설

🧭 Amazon CloudFront란?

• AWS의 글로벌 콘텐츠 전송 네트워크(CDN, Content Delivery Network) 서비스입니다.
• 데이터를 가까운 엣지 로케이션(Edge Location) 에 캐싱하여
  전 세계 사용자에게 더 빠르고 안전하게 콘텐츠를 전달합니다.

✅ 주요 기능

📦 대표적인 CloudFront 사용 예시

❌ 오답 해설

🧠 핵심 비교 정리

📊 시각 요약 (Mermaid)

```mermaid
flowchart LR
    A["🌐 Origin - S3 / EC2 / ALB"] -->|"🧠 Cached Copy"| B["🌎 CloudFront Edge Location"]
    B -->|"🌍 Content Delivery"| C["👤 Global Users"]
    B -.->|"⚡ Low Latency + 🔒 SSL Security"| C
```

 

📗 한 줄 요약

🚀 Amazon CloudFront = 빠르고 안전한 글로벌 콘텐츠 전송 네트워크 (CDN)

AWS Cloud Adoption Framework (AWS CAF) 의 6가지 관점(perspectives) 중
Governance 관점에 해당하는 기능(capabilities)을 묻는 문제입니다.

📘 Q387.

Which AWS Cloud Adoption Framework (AWS CAF) capabilities belong to the governance perspective? (Choose two)

거버넌스 관점에 속하는 AWS Cloud Adoption Framework(AWS CAF) 기능은 무엇입니까? (2개 선택)

✅ 정답: A. Program and project management

✅ 정답: D. Risk management

💡 해설

🔹 AWS CAF (Cloud Adoption Framework)란?

AWS CAF는 조직이 클라우드 도입(Cloud Adoption)을 체계적으로 계획하고 실행할 수 있도록
6가지 관점(perspective)으로 나누어 제시하는 프레임워크입니다.

🧭 AWS CAF 6가지 관점 요약

🟩 Governance Perspective 상세 설명

Governance 관점은 조직이 클라우드 환경에서
책임, 위험, 의사결정, 프로젝트 수행을 체계적으로 관리하도록 돕는 역할을 합니다.

✅ 주요 포함 항목:

❌ 오답 해설

🧩 시각 요약 (Mermaid)

```mermaid
flowchart LR
    A["🏛️ Governance Perspective"] --> B["📋 Program & Project Management"]
    A --> C["⚖️ Risk Management"]
    A --> D["💼 Portfolio Management"]
```

 

💡 설명

• 🏛️ → Governance(통제 및 정책적 관점)
• 📋 → 프로젝트/프로그램 관리
• ⚖️ → 위험 관리
• 💼 → 포트폴리오 관리

📗 한 줄 요약

🧭 AWS CAF의 Governance 관점 = 프로젝트 관리와 위험 관리로 클라우드 도입의 방향과 통제를 확립하는 단계

📘 Q278.

What is a benefit of using AWS serverless computing?

AWS 서버리스 컴퓨팅을 사용하면 어떤 이점이 있습니까?

✅ 정답: D. Management of infrastructure is offloaded to AWS.

인프라 관리가 AWS로 오프로드됩니다.

💡 정답 해설

❌ 오답 해설

🧠 핵심 개념 요약

📊 시각 요약 (Mermaid)

 

```mermaid
flowchart LR
    A[👨‍💻 Developer] -->|Writes code only| B[⚙️ AWS Lambda]
    B -->|Executes automatically| C[☁️ AWS Infrastructure]
    C --> D[📈 Auto Scaling, Monitoring, Maintenance]
    D --> E[✅ No Server Management Required]
```

📗 한 줄 요약

☁️ 서버리스의 가장 큰 장점은 인프라 관리가 필요 없다는 것!
개발자는 코드 실행과 비즈니스 로직에만 집중하면 됩니다.

📘 Q282.

Which of the following is the customer’s responsibility under the AWS shared responsibility model? (Choose two)

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

✅ 정답: C, D

• C. Maintain the configuration of guest operating systems and applications
• D. Manage decisions involving encryption options

💡 정답 해설

AWS 공유 책임 모델에서는
보안(Security) 과 컴플라이언스(Compliance) 에 대해
AWS와 고객이 각각 나누어 책임을 집니다.

🔸 AWS의 책임 (Security of the Cloud)

“클라우드 자체의 보안”

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

“클라우드 내부의 보안”

🧠 각 보기 해석 및 평가

🧩 핵심 개념 정리표

📊 시각 요약 (Mermaid)

 

```mermaid
flowchart TD
    A[☁️ AWS Responsibility] --> B[🔒 Data Center Security]
    A --> C[🧱 Network Infrastructure Protection]
    A --> D[🧰 Hardware Maintenance]

    E[👩‍💻 Customer Responsibility] --> F[💾 OS & App Configuration]
    E --> G[🔐 Encryption Management]
    E --> H[🧑‍💼 Access Control & IAM Policies]
```

 

📗 한 줄 요약

☁️ AWS는 클라우드 인프라를 보호하고,
👩‍💻 고객은 클라우드 내부의 설정·데이터·암호화를 관리합니다.

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

📘 오답노트 - Q157

❓ 문제 요약

• 회사는 2개의 가용 영역에 걸친 ALB 뒤 EC2 인스턴스에서 웹 애플리케이션 운영.
• 정적 콘텐츠는 Amazon S3 버킷에서 제공.
• 사용자는 페이지 로딩 시간이 길다고 보고.
• 목표: 웹사이트 성능 개선.

✅ 정답

A, D

1. A. 정적 콘텐츠에 대해 Amazon CloudFront 캐싱 추가
   • 정적 콘텐츠(S3 제공)를 CloudFront 글로벌 캐싱을 통해 사용자 가까운 엣지 로케이션에서 제공.
   • 네트워크 지연(latency)을 줄여 로딩 속도 향상.
2. D. 웹 서버용 Amazon EC2 Auto Scaling 구현
   • 동적 콘텐츠는 ALB 뒤 EC2 인스턴스에서 처리.
   • 트래픽 급증 시 Auto Scaling이 서버 인스턴스를 자동으로 확장하여 성능 저하 방지.

❌ 오답 해설

• B. 로드 밸런서 리스너를 HTTPS에서 TCP로 변경
  → HTTPS는 보안 트래픽을 위한 표준 프로토콜이며, TCP로 바꾼다고 성능이 개선되지 않음.
• C. Route 53 지연 시간 기반 라우팅 활성화
  → 이미 ALB + S3 기반 아키텍처에서는 지연 시간 라우팅이 아닌 캐싱 및 Auto Scaling이 더 효과적.
• E. 정적 콘텐츠를 웹 서버로 이동
  → 오히려 성능 저하 유발. 정적 콘텐츠는 S3 + CloudFront로 제공하는 것이 최적.

📊 흐름도 (Mermaid 다이어그램)

```mermaid
flowchart TD
    User["🌍 사용자"] --> CF["🌐 Amazon CloudFront: 캐싱"]
    CF --> S3["📦 Amazon S3: 정적 콘텐츠"]

    User["🌍 사용자"] --> ALB["⚖️ Application Load Balancer"]
    ALB --> EC2["💻 Amazon EC2: 동적 콘텐츠"]
    EC2 --> ASG["📈 Auto Scaling: 트래픽 증가 시 인스턴스 확장"]
```

📊 결과 설명

• 🌍 사용자 요청
  • → 🌐 CloudFront 를 거쳐 📦 S3 정적 콘텐츠 제공
  • → 또는 ⚖️ ALB 로 라우팅되어 💻 EC2 동적 콘텐츠 처리
• 📈 Auto Scaling 이 트래픽 증가 시 EC2 인스턴스를 자동 확장

🎯 핵심 개념 정리

• CloudFront + S3: 전 세계 엣지 로케이션에서 정적 콘텐츠 캐싱 제공 → 로딩 시간 단축.
• Auto Scaling + ALB + EC2: 동적 콘텐츠 트래픽 급증 시 자동 확장으로 안정적 성능 보장.
• 웹 성능 개선 시 정적 콘텐츠는 CDN, 동적 콘텐츠는 Auto Scaling이 핵심.

📘 오답노트 - Q162

❓ 문제 요약

• 회사는 Oracle DB 인스턴스용 Amazon RDS를 사용 중.
• 다른 AWS 리전에 정기적인 백업을 제공하려고 함.
• 목표: 가장 운영상 효율적인 백업 솔루션 찾기.

✅ 정답

A. DB 인스턴스를 수정하고 지역 간 자동 백업 활성화

• Amazon RDS는 자동 백업(Auto Backup) 기능 제공.
• 지역 간 복제를 지원하여 별도의 수동 작업 없이 다른 리전에 정기적 백업 자동 전송 가능.
• 관리 오버헤드 최소화, 운영 효율성 극대화.

❌ 오답 해설

• B. 다른 리전에 RDS 읽기 전용 복제본 생성 후 스냅샷
  → 읽기 전용 복제본은 고가용성과 장애 조치 목적이지, 정기적 백업 솔루션으로는 비효율적.
• C. AWS DMS(AWS Database Migration Service) 사용
  → DMS는 데이터 마이그레이션/변환 목적이지, 단순 주기적 백업에는 불필요하게 복잡하고 비용 비효율적.
• D. 암호화 해제 후 스냅샷 복사
  → 보안 취약점을 초래하며, 암호화를 해제하는 것은 올바른 솔루션이 아님.

📊 흐름도 (Mermaid 다이어그램)

```mermaid
flowchart TD
    RDS["🗄️ Amazon RDS: Oracle DB"] --> AutoB["⚙️ 자동 백업 활성화"]
    AutoB --> Backup["💾 백업 스냅샷 저장"]
    Backup --> CrossRegion["🌍 다른 AWS 리전으로 자동 복제"]
    CrossRegion --> Admin["👨‍💻 관리자: 복구 시 활용"]
```

📊 결과 설명

• 🗄️ Amazon RDS (Oracle DB) 에서
  → ⚙️ 자동 백업 활성화
  → 💾 백업 스냅샷 저장
  → 🌍 다른 리전으로 자동 복제
  → 👨‍💻 관리자가 복구 시 활용
• 한눈에 백업 → 복제 → 복구 흐름을 직관적으로 이해할 수 있음.

🎯 핵심 개념 정리

• RDS의 자동 백업 + 교차 리전 복제(Cross-Region Backup) 기능이 가장 효율적.
• 운영자가 직접 스냅샷 찍고 복사하는 방식(D)은 비효율적이고 보안 문제 유발.
• 읽기 전용 복제본(B)이나 DMS(C)는 백업 목적에는 맞지 않음.

📘 오답노트 - Q165

❓ 문제 요약

• SysOps 관리자가 AWS Lambda 함수 실행을 자동화해야 함.
• 매일 업무 종료 시, Amazon S3 버킷에 저장된 데이터를 기반으로 보고서 생성 필요.
• 요구 사항: 가장 운영 효율적인 방법.

✅ 정답

B. 일정과 Lambda 함수를 대상으로 하는 Amazon EventBridge 규칙 생성

• EventBridge(구 CloudWatch Events)를 사용하면 **일정 기반(cron/매일 특정 시간)**으로 Lambda를 자동 실행 가능.
• 운영자가 직접 개입하지 않아도 매일 업무 종료 시 보고서 생성 가능.
• 서버리스 방식이므로 비용 효율적이며 관리 오버헤드 최소화.

❌ 오답 해설

• A. S3 이벤트 패턴 기반 Lambda 실행
  → 이는 객체 업로드/변경 시 실행되는 트리거로, "매일 업무 종료 시"라는 일정 기반 조건에 맞지 않음.
• C. S3 객체 변경 이벤트 시 Lambda 실행
  → 마찬가지로, "객체 변경" 이벤트 기반이므로 일정 실행 요구 조건과 맞지 않음.
• D. cron 작업을 통한 EC2 기반 Lambda 실행
  → EC2에 cron 스케줄러를 두는 방식은 관리 오버헤드와 비용이 크며, **서버리스 자동화(EventBridge)**보다 비효율적.

📊 흐름도 (Mermaid 다이어그램)

```mermaid
flowchart TD
    Schedule["⏰ EventBridge 스케줄: 매일 18시"] --> Lambda["🟦 AWS Lambda: 함수 실행"]
    Lambda --> S3["📦 Amazon S3: 데이터 처리"]
    S3 --> Report["📊 보고서 생성"]

```

📊 결과 설명

• ⏰ EventBridge 스케줄: 매일 18시에 이벤트 발생
• 🟦 Lambda 함수: 자동 실행되어 데이터 처리 로직 수행
• 📦 S3: 처리된 데이터를 저장 및 관리
• 📊 보고서 생성: 최종 산출물

🎯 핵심 개념 정리

• S3 이벤트 트리거(A, C) = 객체 생성/변경 시 실행 (❌ 일정 기반 아님)
• EC2 cron(D) = 불필요한 리소스 관리 + 비용 증가 (❌ 서버리스 철학 위배)
• EventBridge 일정(B) = Lambda를 매일 정해진 시간에 실행 가능 (✅ 정답)

👉 Q165의 핵심은 스케줄 기반 자동화는 EventBridge라는 점이에요.

📘 오답노트 - Q170

❓ 문제 요약

• 회사는 단일 Amazon EC2 인스턴스에서 MySQL 데이터베이스를 실행 중.
• SysOps 관리자는 다중 테넌트 워크로드를 처리할 수 있는 고가용성 DB 솔루션을 요청받음.
• 요구사항: 확장성 + 고가용성을 제공하는 DB로 이전해야 함.

✅ 정답

C. 데이터베이스를 Amazon Aurora 다중 마스터 DB 클러스터로 마이그레이션

• Amazon Aurora 다중 마스터 클러스터는 쓰기 및 읽기 모두 고가용성을 제공.
• 단일 인스턴스 장애 시에도 다른 마스터 노드가 즉시 처리 가능.
• 다중 테넌트 워크로드 환경에서도 확장성과 가용성을 충족.

❌ 오답 해설

• A. MySQL용 두 번째 EC2 인스턴스 생성
  → EC2에서 직접 MySQL을 운영하는 것은 수동 관리가 필요하고, 내결함성 보장이 부족함.
• B. Aurora DB 클러스터로 마이그레이션 (단일 마스터 + 리더)
  → 고가용성은 제공되지만, 여전히 쓰기 작업은 단일 마스터에 집중됨 → 다중 테넌트 환경에서 성능 한계.
• D. MySQL DB 인스턴스용 Amazon RDS로 마이그레이션
  → 관리형 RDS MySQL은 편리하지만, Aurora 다중 마스터 대비 확장성과 내결함성 부족.

📊 흐름도 (Mermaid 다이어그램)

```mermaid
flowchart TD
    EC2["💻 기존 EC2: MySQL 단일 인스턴스"] -->|"🛠️ 마이그레이션"| Aurora["🌟 Amazon Aurora: 다중 마스터 클러스터"]

    Aurora --> Master1["📝 마스터 노드 1: 쓰기 가능"]
    Aurora --> Master2["📝 마스터 노드 2: 쓰기 가능"]
    Aurora --> Reader1["📖 읽기 전용 노드 1"]
    Aurora --> Reader2["📖 읽기 전용 노드 2"]
```

 

📊 결과 설명

• 💻 기존 EC2 (MySQL 단일 인스턴스)
  → 🛠️ 마이그레이션 → 🌟 Amazon Aurora 다중 마스터 클러스터
• Aurora 클러스터 구성:
  • 📝 마스터 노드 1 & 2 (쓰기 가능)
  • 📖 읽기 전용 노드 1 & 2

🎯 핵심 개념 정리

• EC2 MySQL (A) = 직접 관리 필요 + 고가용성 부족 (❌)
• Aurora 단일 마스터 (B) = 쓰기 단일 지점 → 다중 테넌트 비효율적 (❌)
• RDS MySQL (D) = 관리 편의성은 있지만 Aurora 다중 마스터 대비 한계 (❌)
• Aurora 다중 마스터 (C) = 쓰기/읽기 모두 고가용성 + 자동 장애 조치 (✅ 정답)

👉 Q170의 핵심은 다중 테넌트 + 고가용성 조건 = Aurora 다중 마스터라는 점이에요.

📘 오답노트 - Q173

❓ 문제 요약

• 여러 지역에서 발생할 수 있는 무단 AWS Management Console 로그인을 자동으로 모니터링해야 함.
• 요구사항: AWS 계정 보안 이벤트 감지 및 모니터링 자동화.

✅ 정답

D. Amazon GuardDuty를 구성하여 Unauthorized Access: IAMUser/ConsoleLoginSuccess.B finding을 모니터링

• Amazon GuardDuty는 AWS 계정에 대한 악의적 활동 및 무단 접근을 자동 감지.
• “IAMUser/ConsoleLoginSuccess.B” 같은 이벤트는 무단 콘솔 로그인 성공을 의미.
• 요구사항에 가장 적합.

❌ 오답 해설

• A. Amazon Cognito
  → 애플리케이션 사용자 인증 서비스(소셜 로그인/앱 인증 등). AWS 콘솔 로그인 감지와 무관.
• B. Amazon Inspector
  → EC2 및 컨테이너 워크로드 취약점/보안 검사 서비스. 로그인 이벤트 모니터링 기능 없음.
• C. AWS Config
  → 리소스 구성 변경 추적 서비스. IAM 정책 검증 가능하나, 실시간 로그인 감지 불가능.

📊 비교 표

📊 흐름도 (Mermaid 다이어그램)

 

```mermaid
flowchart TD
    User["👤 사용자: 로그인 시도"] --> CloudTrail["📜 AWS CloudTrail: 로그 기록"]
    CloudTrail --> GuardDuty["🛡️ Amazon GuardDuty: 로그 분석"]
    GuardDuty -->|"🚨 Unauthorized Access 감지"| Alert["📧 보안 알림 전송"]

```

 

📊 결과 설명

• 👤 사용자 로그인 시도 → 📜 CloudTrail 로그 기록
• 🛡️ GuardDuty 분석으로 Unauthorized Access 여부 감지
• 감지 시 📧 보안 알림 전송으로 보안팀 대응 가능

🎯 핵심 개념 정리

• AWS Cognito → 앱 사용자 인증 (❌)
• AWS Inspector → 워크로드 취약점 분석 (❌)
• AWS Config → 리소스 변경 추적 (❌)
• Amazon GuardDuty → AWS 계정의 무단 로그인/보안 위협 탐지 (✅ 정답)

👉 Q173의 핵심은 AWS 계정 로그인 보안 이벤트 자동 감지 = GuardDuty입니다.

📘 오답노트 - Q200

❓ 문제 요약

• 회사는 애플리케이션을 AWS VPC로 마이그레이션.
• 온프레미스 네트워크와는 Site-to-Site VPN으로 연결.
• 애플리케이션은 온프레미스 DNS 서버를 사용해 도메인 이름을 확인해야 함.
• 마이그레이션 후 이름 확인 오류 발생 → 내부 도메인 이름 확인 필요.

✅ 정답

B. Amazon Route 53 Resolver 아웃바운드 엔드포인트를 생성한다.

• Route 53 Resolver 아웃바운드 엔드포인트를 사용하면, VPC 내부에서 발생하는 DNS 쿼리를 온프레미스 DNS 서버로 전달 가능.
• 이렇게 하면 애플리케이션이 여전히 온프레미스 DNS를 사용하여 내부 도메인을 해석할 수 있음.

❌ 오답 해설

• A. EC2 인스턴스에서 사용자 지정 DNS 전달자 배포
  → 불필요하게 관리 오버헤드가 큼. Route 53 Resolver가 더 적절한 관리형 솔루션임.
• C. AWS Direct Connect 연결 구성
  → 네트워크 연결 대역폭 향상은 가능하나, DNS 질의 전달 문제 해결과 직접적 관련 없음.
• D. Amazon Route 53 퍼블릭 호스팅 영역 구성
  → 퍼블릭 도메인용이라, 온프레미스 내부 도메인 해석 불가.

📊 비교 표

📊 흐름도 (Mermaid)

```mermaid
flowchart TD
    App["💻 애플리케이션 (VPC 내부)"] --> Resolver["🌐 Route 53 Resolver: 아웃바운드 엔드포인트"]
    Resolver --> OnPremDNS["🏢 온프레미스 DNS 서버"]
    OnPremDNS --> App

```

 

📊 결과 설명

• 💻 애플리케이션 (VPC 내부) → 🌐 Route 53 Resolver 아웃바운드 엔드포인트
• Resolver가 요청을 🏢 온프레미스 DNS 서버로 전달
• 결과가 다시 💻 애플리케이션으로 돌아옴

🎯 핵심 개념 정리

• 문제 상황: 마이그레이션 후 애플리케이션이 내부 도메인 이름을 못 찾음.
• 핵심 해결책: AWS VPC에서 발생하는 DNS 요청을 온프레미스 DNS로 전달.
• 정답: Route 53 Resolver 아웃바운드 엔드포인트 (B).

👉 Q200의 핵심은 온프레미스 DNS와의 연동 = Route 53 Resolver 아웃바운드입니다.

📘 오답노트 - 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 단순 라우팅
  → 단순 라우팅은 장애 조치 불가능, 리전 장애 시 트래픽 우회 기능이 없음