AWS/AWS SAA-C03 (1)
AWS/AWS SAA-C03/ [AWS SOA-C02] Q151 ~ Q200 오답노트 6EA
2025-09-27 22:00:46
반응형

📘 오답노트 - 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 정책 검증 가능하나, 실시간 로그인 감지 불가능.

📊 비교 표

옵션 기능 로그인 모니터링 적합 여부
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 아웃바운드입니다.

 

반응형

티스토리툴바