AWS/AWS SAA-C03/ [AWS SOA-C02] Q151 ~ Q200 오답노트 6EA

2025-09-27 22:00:46

📘 오답노트 - Q157

❓ 문제 요약

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

✅ 정답

A, D

A. 정적 콘텐츠에 대해 Amazon CloudFront 캐싱 추가
- 정적 콘텐츠(S3 제공)를 CloudFront 글로벌 캐싱을 통해 사용자 가까운 엣지 로케이션에서 제공.
- 네트워크 지연(latency)을 줄여 로딩 속도 향상.
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 정책 검증 가능하나, 실시간 로그인 감지 불가능.

📊 비교 표

옵션	기능	로그인 모니터링 적합 여부
A. Cognito	앱/사용자 인증 서비스	❌
B. Inspector	취약점/보안 점검	❌
C. Config	리소스 구성 추적, 정책 준수 검사	❌
D. GuardDuty	무단 로그인/위협 탐지	✅

📊 흐름도 (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 퍼블릭 호스팅 영역 구성
→ 퍼블릭 도메인용이라, 온프레미스 내부 도메인 해석 불가.

📊 비교 표

옵션	설명	적합 여부
A	EC2 DNS 전달자 수동 배포	❌ 관리 오버헤드
B	Route 53 Resolver 아웃바운드 → 온프레미스 DNS 전달	✅ 정답
C	Direct Connect 연결	❌ DNS 문제 직접 해결 불가
D	퍼블릭 호스팅 영역	❌ 내부 DNS 불가

📊 흐름도 (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 아웃바운드입니다.

📘 오답노트 - Q157

❓ 문제 요약

✅ 정답

❌ 오답 해설

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

📊 결과 설명

🎯 핵심 개념 정리

📘 오답노트 - Q162

❓ 문제 요약

✅ 정답

❌ 오답 해설

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

📊 결과 설명

🎯 핵심 개념 정리

📘 오답노트 - Q165

❓ 문제 요약

✅ 정답

❌ 오답 해설

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

📊 결과 설명

🎯 핵심 개념 정리

📘 오답노트 - Q170

❓ 문제 요약

✅ 정답

❌ 오답 해설

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

🎯 핵심 개념 정리

📘 오답노트 - Q173

❓ 문제 요약

✅ 정답

❌ 오답 해설

📊 비교 표

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

📊 결과 설명

🎯 핵심 개념 정리

📘 오답노트 - Q200

❓ 문제 요약

✅ 정답

❌ 오답 해설

📊 비교 표

📊 흐름도 (Mermaid)

📊 결과 설명

🎯 핵심 개념 정리

티스토리툴바