[SAA-C03] 문제 유형 11~20 정리

Q11)

현재는 EC2 로컬 파일에 DB 계정/비번 저장 
→ 변경·회전이 수동이라 운영 부담 큼
자격 증명 관리의 운영 오버헤드 최소화?

오버헤드(Overhead)

-> 일 하기 위해 추가로 드는 귀찮은 작업

변경 -> DB 비번 바꿈, 앱 설정도 같이 수정해야 함.
회전(Rotation) -> 일정 주기로 자동으로 비밀번호 교체 (보안정책)
(수동이면 운영 부담 큼)

Secrets Manager

-> DB 자격증명 저장 + Aurora 연동 자동 회전이 표준 기능

 

애플리케이션은 실행 시 Secrets Manager에서 자격증명 조회 

→ 로컬 파일 관리 제거

// 서버 안에 비밀번호 저장하지 않음, 필요할 때 가져옴

Amazon Aurora
-> AWS가 만든 “빠르고 튼튼한” 관계형 데이터베이스
(MySQL/PostgreSQL 호환)

관계형 DB = “엑셀처럼 생긴 데이터 저장소”
SQL = “그 엑셀한테 질문하는 언어”

(Parameter Store도 설정값 저장 가능 but 회전(Rotation) 직접 구현해야함)

 

#시험 포인트

DB 비밀번호 자동 회전/운영 최소 -> Secrets Manager

---

Q12)

목표: 정적(S3) + 동적(ALB) 모두 성능 개선 + 글로벌 지연 최소화

S3 -> 파일 저장소니까 정적콘텐츠 저장

동적콘텐츠 
-> 요청할 때마다 서버가 계산해서 생성하는 응답

ALB 
-> 사용자 요청을 EC2 / ECS / Lambda 같은 서버로 전달
-> 서버 거쳐서 계산 후 응답 (동적)

Route 53 - >AWS의 DNS 서비스

CloudFront origin으로 S3(정적) + ALB(동적) 둘 다 연결 가능
Route 53 → CloudFront로 라우팅 → 모든 사용자 요청 가속


#시험 포인트
글로벌 성능 개선 + S3 + ALB -> CloudFront (CDN 표준 정답)

---

Q13)

요구사항: 여러 리전의 RDS(MySQL) 자격증명 교체를 운영 최소로

Secrets Manager는 DB 자격증명 저장 + 자동/스케줄 회전(rotate) 지원
Multi-Region secret replication으로 필요한 리전에 동일 시크릿을 복제
-> 스케줄만 걸면 월별 유지보수 때 자동 교체/관리 가능

#시험 포인트

DB 비밀번호 회전 + 운영 최소 + 멀티리전 = Secrets Manager 복제 + 자동 회전

---

Q14)

ALB

-> 들어오는 사용자 요청을 여러 서버로 나눠주는 트래픽 분배기

(서버 앞 교통경찰)

 

ALB는 L7 (HTTP/HTTPS 레벨) 에서 동작

 

메트릭(Metric)

-> 시스템 상태를 숫자로 보여주는 지표

-> Auto Scaling은 메트릭을 보고 판단

 [구조 문제점]

앱 서버는 ALB + Auto Scaling → 잘 확장됨

DB는 EC2 위 MySQL 단일 인스턴스

 

트래픽 증가하면?

앱 서버는 늘어나는데 

DB는 하나라서 병목 발생

(+ 읽기 요청이 쓰기보다 더 많음)

 

[요구사항]

고가용성 유지, 읽기 워크로드 예측 불가, 자동확장 필요

 

Aurora는

1. Multi-AZ 기본 지원(고가용성)

2. Read Replica 확장(최대 15개까지, 읽기 요청 자동분산)

3. Aurora Auto Scaling

 

 

#시험 포인트

읽기 많고 자동 확장 + 고가용성 필요하면
→ Aurora Multi-AZ + Aurora Replica + Auto Scaling

---

Q15)

사내 데이터 센터에 검사 서버를 가지고 있다.

서버는 트래픽 흐름 검사 및 트래픽 필터링과 같은 특정 작업 수행

AWS 클라우드에서 동일한 기능 갖추려면?

 

AWS Network Firewall(네트워크 방화벽)
-> VPC로 들어오고 나가는 모든 트래픽을 
중앙에서 검사·필터링하는 네트워크 보안 구조

(모든 트래픽을 “보안 검색대”를 통과시키는 구조)

 

#시험 포인트
VPC In/Out 트래픽 검사, 중앙 집중식 보안,
온프레미스 방화벽 대체, 트래픽 필터링 + 모니터링
→ AWS Network Firewall

---

Q16)

Amazon QuickSight

-> 여러 데이터 소스를 연결해 시각화 대시보드를
만드는 관리형 BI(비즈니스 인텔리전스) 서비스

 

S3(데이터 레이크 파일) + RDS (운영 데이터)
-> QuickSight가 데이터 소스 연결
-> 대시보드 생성
-> 사용자/그룹별 접근 권한 설정(대시보드별 접근제어 가능)

 

데이터 레이크(Data Lake)

-> 모든 데이터를 일단 다 모아두는 큰 창고

 

RDS ->
AWS가 대신 관리해주는 관계형 데이터베이스

 

즉, S3에 있는 파일 데이터랑 RDS에 있는 DB 데이터까지
전부 모아서 시각화해주는 게 QuickSight

 

 

#시험포인트

데이터 시각화, 여러 데이터 소스 연결 (S3 + RDS), 

대시보드 공유, 사용자/그룹별 접근 제어

->  Amazon QuickSight

---

Q17)

IAM 정책(Policy)
AWS에서 “무엇을 할 수 있는지”를 정의한 권한 문서 (허가증)

정책은 단독으로 못 씀.
반드시 붙여야 함:

IAM 사용자(User)
IAM 역할(Role)
IAM 그룹(Group)

Role은 
-> AWS 서비스에 붙이는 권한 단위
EC2 전용으로 설계됨
임시 자격 증명 자동 제공

(User는 사람, Group은 사람 묶음)

 

#시험 포인트
EC2 → S3 접근, 서비스 간 권한 부여, Access Key 저장 없이 접근
→ IAM Role

---

Q18)

1. 사용자가 이미지 업로드
→ S3 원본 버킷 저장

2. S3가 이벤트 발생
→ SQS에 메시지 전달

3. Lambda가 SQS를 Polling
→ 이미지 압축 처리

4. 압축된 이미지
→ 다른 S3 버킷 저장

왜 SQS를 쓰냐?
“내구성 있는 상태 비저장 구성 요소”

SQS = 메시지 내구성 보장
Lambda 실패해도 메시지 안 사라짐
재시도 가능
(직접 S3 → Lambda 연결보다 안정적)

비동기 
-> 결과 기다리지 않고 다음 단계로 넘어가는 구조

AWS Lambda 
-> 서버 없이 코드만 올리면, AWS가 대신 실행해주는 서비스

 

#시험 포인트
비동기 처리 / 내구성 필요 / 상태 비저장 / 이벤트 기반 처리
→ S3 + SQS + Lambda 패턴

---

Q19)

Gateway Load Balancer (GWLB)
-> 네트워크 트래픽을 타사 보안 어플라이언스로 
투명하게 전달하고 분산시키는 로드 밸런서

문제 키워드:

1. AWS Marketplace의 타사 가상 방화벽 
-> AWS가 만든 방화벽이 아니라, 다른 보안 회사 제품
// 타회사의 방화벽 소프트웨어를 AWS에서 VM 형태로 실행
// VM(Virtual Machine -> 실제 물리 서버 안 가짜 컴퓨터)

2. IP 패킷 수락 가능한 IP 인터페이스
//인터넷에서 오가는 데이터는
IP 패킷이라는 작은 데이터 묶음 단위로 이동

패킷 수락 =
“네트워크 단계에서 직접 트래픽을 받는다”
그래서 웹 서버 전에 검사 가능

3. 모든 트래픽 검사
4. 최소 운영 오버헤드

Gateway Load Balancer (GWLB)

자동 확장
고가용성
어플라이언스 그룹 관리
라우팅 자동화
(수동 라우팅/복잡한 NAT 구성 불필요)


#시험 포인트
보안 장비를 트래픽 경로 한가운데에 넣고
모든 요청이 반드시 거치게 만드는 구조
-> Gateway Load Balancer (GWLB)

---

Q20)

조건

EBS 복제 + 빠른 복사 + 높은 I/O(입출력) + 프로덕션 환경에 영향 없음

Snapshot
->디스크를 특정 시점에 통째로 복사해두는 것
(게임 세이브 포인트처럼)

일반 EBS Snapshot은
S3에 저장됨 // 새 볼륨 생성 시 “Lazy Loading” 방식
// 처음 접근하는 블록은 S3에서 읽어옴
// 초기 I/O 성능 저하 발생

Fast Snapshot Restore(FSR)
-> Snapshot에서 생성된 볼륨이 즉시 전체 성능 제공
(초기지연 없음. 고성능 즉시 보장)

[흐름]
1. 프로덕션 EBS → Snapshot 생성
2. Snapshot에 FSR 활성화
3. Snapshot에서 새 EBS 생성
4. 테스트 EC2에 연결

(Snapshot은 “저장 파일”, EBS는 “실제로 연결해서 쓰는 디스크”
그래서 Snapshot 만든 다음 Snapshot으로 새 EBS를 또 만드는 것)


#시험 포인트
EBS 복제 + 고성능 즉시 필요
→ Snapshot + FSR