[SAA-C03] 문제 유형 81-90 정리

Q81)
ELB에서 ACM 인증서 사용
인증서 만료 30일 전 보안팀 알림 필요
자동으로 만료상태 감지 필요
AWS 관리 서비스 기반 모니터링
 
AWS Certificate Manager (ACM)
SSL/TLS 인증서 관리 서비스
인증서 발급, 가져오기, 갱신 관리
(ELB, CloudFront, API Gateway 등에 연결)
 
import한 인증서는 자동 갱신 안 됨
-> 모니터링 필요
 
AWS Config
AWS 리소스 구성 상태 지속적으로 평가
규칙(Config Rule)으로 컴플라이언스 체크
(인증서 만료 확인, 보안 그룹 규칙 검사 등의 기능)
 
AWS Config 관리형 규칙
 
acm-certificate-expiration-check
 
-> ACM 인증서 만료 검사
-> 만료까지 남은 일수(threshold) 지정 가능
-> 지정 일수 이하로 남으면 NON_COMPLIANT 상태로 표시

흐름.
ACM Certificate -> Config rule 평가 ->
Config 비준수 발생(Non-compliant) -> Amazon EventBridge
-> SNS -> 보안팀 알림
 
 
#시험 포인트
ACM 인증서 만료 모니터링 → AWS Config expiration rule + EventBridge + SNS

---

Q82)
웹사이트 현재 위치 : 온프레미스 (미국)
유럽 사용자 증가
유럽 로딩 속도 개선 필요
백엔드는 반드시 미국 유지
며칠 내 출시, 빠른 적용 필요
 
Amazon CloudFront + CDN
// 전 세계 Edge Location 캐싱
// Origin 서버 위치 상관없이 사용 가능
// 기존 인프라 변경 없이 적용 가능
 
Origin 유형
S3, ALB / EC2, On-premise server, Custom HTTP server


#시험 포인트
글로벌 사용자 latency 문제 + origin 유지 → CloudFront CDN 사용

---

Q83)
3계층 웹 아키텍처
EC2 사용
Production / Development / Test (환경)
Production → 24시간 실행
Dev/Test → 하루 최소 8시간
Dev/Test → 사용 안할 때 자동 종료
 
비용절감 솔루션

Amazon EC2 Reserved Instances
장기적으로 계속 사용하는 인스턴스에 적합
1년 / 3년 약정
온디맨드 대비 최대 72% 절감
항상 실행되는 워크로드에 최적

Amazon EC2 On-Demand Instances
사용한 만큼만 비용 지불
약정 없음, 시작/중지 자유
간헐적 사용 워크로드에 적합

Amazon EC2 Spot Instances
남는 AWS 용량을 최저가로 제공
최대 90% 절감
언제든 중단 가능
 
Production → 24시간 실행 → Reserved Instance
Dev/Test → 하루 8시간, 안 쓸 때 종료 → On-Demand



#시험 포인트
항상 실행되는 서버 → Reserved Instance
간헐적 Dev/Test → On-Demand

---

Q84)
사용자가 문서 업로드
업로드 경로 Web / Mobile
저장 후 수정/삭제 불가 (규제 요구사항)

Amazon S3 Object Lock (객체잠금)
-> S3 객체를 지정 기간 동안 수정/삭제 불가능하게 만드는 기능
// WORM (Write Once Read Many) 모델
// 객체 삭제 및 overwrite 방지

Amazon S3 Versioning
-> 객체 변경 시 이전 버전 유지
-> Object Lock 사용 전 반드시 활성화
// Object Lock은 “객체 버전” 단위로 동작
(Version이 없으면 Lock 대상이 존재하지 않음)

흐름.
S3 Bucket -> Versioning 활성화 (필수)
-> Object Lock 활성화 -> 객체 수정/삭제 방지



#시험 포인트
Amazon S3 Versioning + Amazon S3 Object Lock -> 기존 객체 변경 및 삭제 불가

---

정답 바로 찾는 아는 문제들은 패스
DB 자격 증명 저장 + 자동 rotation → AWS Secrets Manager(Q86 패스)
손실될 위험이 있는 처리 대상 데이터를 잠시 보관 -> SQS(Q87 패스)

---

Q85)
설문 데이터 Amazon S3 버킷 저장
데이터 크기 3TB (지속 증가)
미국 → 유럽 회사와 데이터 공유
목표: 데이터 전송 비용 최소화

S3 Requester Pays
-> 데이터 요청자가 비용을 부담하게 만드는 버킷 옵션
// 대용량 데이터셋 공유에 적합
// 버킷 소유자의 데이터 전송 비용을 줄임

데이터는 계속 미국 S3에 있음
유럽 회사가 필요할 때마다 다운로드하는 구조
-> 데이터에 접근하는 요청자가
데이터 전송 비용을 부담하게 하고 싶을 때
Requester Pays(요청자 지불 버킷) 사용
 
 
#시험 포인트
S3 대용량 데이터 공유 + 전송 비용 최소화 
→ S3 Requester Pays

---

Q86)
기밀 감사 문서 저장(S3)
IAM + Bucket Policy 최소 권한 적용
문서가 실수로 삭제되는 것 방지
안전한 솔루션
 
Amazon S3 Versioning
객체 삭제/수정 시 이전 버전 유지
-> 실수로 삭제 시 복구 가능
MFA Delete
-> 버전 삭제 또는 변경 시 MFA 필요(추가인증 요구)
 

#시험 포인트
S3 실수 삭제 방지 → Versioning + MFA Delete

---

Q87)
영화 데이터 SQL DB 저장
DB: Amazon RDS Single-AZ
스크립트가 랜덤 시간에 쿼리 실행
목적: 새 영화 수 집계
문제: 스크립트 실행 시 DB 성능 저하
최소 운영 오버헤드
 
쿼리가 너무 많이 수행되어서 데이터베이스 성능에 영향가는 상황
-> Read Replica를 통해 쿼리 부하를 분산할 수 있음
 
Amazon RDS Read Replica
-> 읽기 트래픽을 분산하기 위한 읽기 전용 복제 DB
// Read query offloading
// Primary DB 부하 감소
// 읽기 전용 복제본만 쿼리 실행
 
Offloading(오프로딩)
-> 부하가 걸리는 작업이나 데이터를 다른 곳으로 떠넘겨서 처리하는 기술
 
 
#시험 포인트
RDS 읽기 쿼리로 DB 부하 발생 → Read Replica

---

Q88) 인터넷 없이 VPC-S3 안전한 비공개 연결 -> S3 gateway endpoint (Q91 패스)
민감한 사용자 정보 저장(S3)
접근 주체: VPC 내부 EC2 애플리케이션 계층
요구사항: 보안 접근 (secure access) 제공
 
S3 VPC Gateway Endpoint
-> VPC에서 인터넷을 거치지 않고 S3 접근
// 인터넷 경유 없음, 보안강화
 
S3 Bucket Policy
// 특정 접근만 허용
-> VPC 내부 애플리케이션만 접근 허용
 
 
#시험 포인트
VPC → S3 private access
→ VPC Gateway Endpoint + Bucket Policy 제한

---

Q89)
기존 온프레미스 MySQL로 구동
AWS로 마이그레이션 진행
읽기 트래픽 많음
4시간마다 전체 DB export
→ staging DB 생성
→ 이 과정 동안 latency 발생
→ staging 환경 사용 불가
 
지연 없이 staging 환경 계속 사용하려면?
 
Staging DB
→ 프로덕션 환경과 거의 동일한 데이터를 사용하는"테스트용 데이터베이스"
 
Aurora Database Cloning
(Aurora의 핵심 기능)
-> 전체 DB 복사 필요 없음
-> 몇 분 내 clone 생성
-> Production 영향 거의 없음
 
DB가 export 작업 때문에 바빠짐
(DB 전체 복사는 엄청 무거운 작업)
→ 애플리케이션 latency 발생
Staging DB // 실제 데이터를 복사해서 테스트
 
해결 : Aurora Cloning(데이터복제) 방식
Aurora는 실제 데이터를 복사하지 않음(같은 데이터 참조)
Production DB->같은 스토리지 공유->Staging DB 생성
 

시험 포인트
Production DB 기반 빠른 staging 생성
→ Aurora Database Cloning

---

Q90)
사용자가 작은 파일 업로드(S3)
업로드 후 즉시 처리 필요
단순 변환 (→ JSON)
트래픽// 어떤 날 많고, 어떤 날 거의 없음
최소 운영 오버헤드
 
흐름.
S3 파일 업로드 -> S3 Event Notification -> SQS Queue
-> Lambda -> 데이터 변환 -> DynamoDB 저장(JSON 지원)
 
Lambda 내부 동작 프로세스
1. 이벤트 수신 (SQS Polling)
-> Lambda가 SQS에서 "S3에 새 파일(A)이 왔다"는 메시지를 캐치함.
2. 파일 읽기 (S3 GetObject)
-> Lambda가 S3 버킷으로 찾아가 파일(A)의 실제 데이터를 메모리로 읽어옴.
3. 데이터 변환 (Transform)
-> 읽어온 데이터(CSV/XML 등)를 한 줄씩 분석.
// DynamoDB가 수용할 수 있는 JSON 형식으로 구조 변경.
4. 데이터 저장 (DynamoDB PutItem)
-> 변환된 JSON 데이터를 PutItem API를 통해
DynamoDB 테이블의 개별 항목(Item)으로 최종 기록

 
#시험 포인트
S3 업로드 후 즉시 처리 + 서버리스 요구
→ S3 Event + SQS + Lambda