🎯 SAA-C03 오답 분석 (2026-03-23)
오늘 결과
점수 50%대 — 30문제 오답. 패턴별로 묶어서 정리.
📑 목차
- S3 스토리지 클래스
- RDS 관련
- Capacity Reservation
- CloudWatch
- KMS
- 네트워킹
- 도구 선택
- Lambda
- 멀티 계정
- [[#11. Q28 (#640) — Lambda + KMS 복호화 권한|Q28: Lambda KMS 권한]]
- 오답 목록
1. S3 스토리지 클래스 혼동
자주 틀리는 구간
| 클래스 | 검색 시간 | 비용 | 쓰는 경우 |
|---|---|---|---|
| Standard | 즉시 | 높음 | 자주 접근 |
| Standard-IA | 즉시 | 중간 | 가끔 접근 |
| Glacier Instant | 즉시 | 낮음 | 거의 안씀, 즉시 필요 |
| Glacier Flexible | 1 | 더 낮음 | 몇 시간 기다려도 됨 |
| Glacier Deep Archive | 12시간+ | 최저 | 거의 안씀 |
💡 문제별 적용
- Q32 (#485) — 비디오 아카이브, 5분 내 복원 필요 → Glacier Instant Retrieval
- 내 답(C): 오답 / 정답(A)
- Q34 (#551) — 첫 주 자주 접근, 이후 6시간 내 복원 → S3 Standard → Lifecycle → Glacier Flexible
- 내 답(C): 오답 / 정답(A)
- Q7 (#446) — 7년 법적 보관 의무 → S3 Object Lock (Compliance Mode)
- 내 답(A): 오답 / 정답(D)
- 핵심: 법적 요구 = Object Lock compliance, 삭제 불가 보장
2. RDS 관련
RDS 문제 결정 로직
Q1 (#365) — 5분 전 상태로 복원 (30일 이내)
- 정답: PITR (Point-in-Time Recovery)
- 조건: 자동 백업 활성화 + retention 30일 설정
- 주의: 스냅샷은 특정 시점 복원 불가, PITR만 가능
Q6 (#90) — 스크립트 쿼리가 DB 성능 저하
- 정답: Read Replica 생성 후 읽기 쿼리 분리
- 최소 운영 오버헤드 조건 충족
Q17 (#300) — 24/7, 스토리지 계속 증가
- 정답: Amazon Aurora
- Aurora = 스토리지 자동 확장 + 관리 최소화
Q27 (#440) — mysqldump + RDS 스냅샷 → Aurora 복원 (2개 선택)
- 정답: A, C
- RDS 스냅샷 → Aurora 직접 복원 가능 ✅
- mysqldump → S3 업로드 → Aurora import 가능 ✅
Q63 (#449) — Oracle, 서드파티 특권(privileged) 기능 필요
- 정답: RDS Custom for Oracle
- 일반 RDS = OS 레벨 접근 불가
- RDS Custom = OS/DB 레벨 접근 허용
3. 용량 예약 vs 예약 인스턴스
헷갈리는 핵심 포인트
Q5 (#47) — 특정 3개 AZ에서 1주일 용량 보장
| 옵션 | 목적 | 용량 보장 |
|---|---|---|
| Reserved Instances | 비용 절감 | ❌ |
| On-Demand Capacity Reservations | 물리 용량 확보 | ✅ |
→ 정답: On-Demand Capacity Reservations (기간/AZ 지정 가능)
4. CloudWatch Composite Alarm
Q13 (#150) — CPU 높음 AND 디스크 IOPS 높음 동시에 → Composite Alarm
Composite Alarm = 여러 알람을 AND/OR 조합
→ 오경보 감소 + 복합 조건 감지
단순 알람 2개 따로 = 오경보 증가 (각자 단독으로 트리거)
5. KMS 키 자동 순환
Q9 (#202) — 연간 자동 순환, 최소 오버헤드
- 정답: SSE-KMS + 자동 키 순환(Automatic Key Rotation) 활성화
- SSE-C (고객 직접 관리) = 직접 순환해야 해서 오버헤드 높음
6. 네트워킹
Q55 (#296) — VPC 피어링 CIDR 설계
- Dev VPC: 192.168.0.0/24
- 겹치지 않는 가장 작은 블록 = /28 (16개 IP)
- 정답: D
Q65 (#237) — 다른 계정 VPC 간 연결, 단일 장애점 없음
- 정답: VPC Peering
- VPC Peering = 단순, 안정, 대역폭 제한 없음
- Transit Gateway = 오버스펙 (여러 VPC 허브 구성 시 사용)
7. 도구 선택 혼동
공식처럼 외우기
| 상황 | 정답 서비스 | 내가 고른 오답 |
|---|---|---|
| NFS → S3 정기 백업 (Q35) | DataSync | Storage Gateway |
| SMB 프로토콜 공유 스토리지 (Q38) | FSx for Windows | EFS (NFS 전용) |
| EC2 비용 그래프 + 심층 분석 (Q31) | Cost Explorer | - |
| EC2 보안 스캔 + 패치 + 리포트 (Q45) | Systems Manager Patch Manager + Inspector | - |
| Kinesis 격일 소비 중 데이터 유실 (Q59) | 보존 기간 연장 (기본 24h) | - |
| DDoS 방어 + 감사 추적 (Q29) | AWS Shield + WAF | Network ACL |
8. Lambda CPU 최적화
Q24 (#672) — CPU 집약적 Lambda, 비용 절감 + 지연 유지
→ arm64 (Graviton2) 아키텍처 선택
- 동일 작업 약 20% 저렴
- 성능 동등하거나 향상
9. 멀티 계정 Organizations
Q37 (#543) — Savings Plan 다른 계정에서 사용
- 정답: A, E
- Organizations 통합 결제 + discount sharing 활성화
Q50 (#484) — 회사 디렉터리로 여러 계정 인증
- 정답: A, E
- AWS Organizations + IAM Identity Center(SSO) + AD Connector
10. Q27 (#440) — RDS MySQL 백업 → Aurora MySQL 복원
백업 2개 생성 순서가 핵심
백업 생성 순서:
테스트 종료 시점
1. mysqldump 실행 → 덤프 파일 생성
2. RDS 종료 시 "최종 스냅샷" 옵션 활성화 → RDS 스냅샷 생성
──────────────────────────────────────
DB 인스턴스 종료 (삭제됨)
지문 함정 1 — "가장 최근 백업"
스냅샷이 mysqldump보다 나중에 생성됨. 하지만 문제가 진짜 묻는 건 “어떤 방법으로 Aurora MySQL을 생성하는가” 이지, 어느 백업이 더 최신인지가 아님.
지문 함정 2 — 목적지가 Aurora MySQL
일반 RDS MySQL → Aurora MySQL은 엔진이 다름. Aurora 전용 복원 방법이 필요.
A — RDS 스냅샷 → Aurora MySQL 직접 복원 ✅
- AWS는 RDS MySQL 스냅샷을 Aurora MySQL 클러스터로 직접 복원 지원
- Console: 스냅샷 선택 → “Aurora로 복원” 옵션 선택
- 중간 단계 불필요
C — mysqldump → S3 업로드 → Aurora MySQL import ✅
- Aurora MySQL은 S3에 올린 mysqldump 파일을 직접 import 지원
LOAD DATA FROM S3또는 Aurora 콘솔 S3 import 기능 사용
D, B가 틀린 이유
- B: 스냅샷 → RDS MySQL 복원 → Aurora 마이그레이션 (2단계, 불필요한 중간 단계)
- D: AWS DMS 사용 → DMS는 live DB 간 마이그레이션 도구, 종료된 DB의 덤프/스냅샷에 부적합
공식:
RDS MySQL 스냅샷 → Aurora MySQL ✅ 직접 복원 가능
mysqldump 파일 → S3 → Aurora ✅ S3 import 지원
RDS 복원 후 → Aurora 마이그레이션 ❌ 불필요한 중간 단계
DMS로 스냅샷/덤프 처리 ❌ DMS는 live DB 전용
11. Q26 (#308) — Trusted Advisor + RDS RI 최적화
통합 결제 환경 + Trusted Advisor 조합
상황: RDS for Oracle 온디맨드를 90일간 실행 중, 통합 결제(Organizations) 환경, Trusted Advisor로 비용 절감
B — payer(관리) 계정의 Trusted Advisor 에서 확인
- 개별 멤버 계정 Trusted Advisor = 해당 계정 리소스만 조회
- payer 계정 Trusted Advisor = 연결된 모든 계정 통합 확인 가능
- 단, Business/Enterprise Support 플랜 필요
D — Trusted Advisor “RDS RI 최적화” 체크 확인 후 Reserved Instance 구매
- 90일 이상 온디맨드 실행 → RI 구매 권장 자동 표시
- 온디맨드 대비 최대 69% 절감
C, A가 틀린 이유
- A: 개별 멤버 계정 Trusted Advisor → 다른 계정 리소스 안 보임
- C: Trusted Advisor는 수동 활성화 개념 없음 (Support 플랜에 따라 자동 제공)
공식: 멀티 계정 Trusted Advisor = 반드시 payer 계정에서 확인
온디맨드 장기 실행 → RI 구매 (Trusted Advisor "RI 최적화" 체크)
11. Q28 (#640) — Lambda + KMS 복호화 권한
핵심 포인트: 실행 역할 vs 리소스 기반 정책
상황: Lambda 함수가 KMS로 암호화된 데이터를 복호화해야 함. 권한이 없어 실패 중.
정답: C, E
| 선택지 | 내용 | 정오 |
|---|---|---|
| B (내 답) | KMS 키 리소스 정책에 Lambda 함수 ARN 추가 | ❌ |
| C (정답) | Lambda **실행 역할(Execution Role)**에 kms:Decrypt 권한 추가 | ✅ |
| E (공통 정답) | KMS 키 리소스 정책에 Lambda 실행 역할 추가 | ✅ |
왜 B가 틀렸나?
Lambda 함수 ARN ≠ Lambda 실행 역할 ARN
함수 ARN: arn:aws:lambda:ap-northeast-2:123456789:function:my-func
실행 역할: arn:aws:iam::123456789:role/lambda-execution-role
- KMS는 **IAM Identity(역할/사용자)**를 Principal로 인식
- Lambda 함수 자체는 IAM Identity가 아님
- KMS API를 실제로 호출하는 주체는 실행 역할
두 가지가 모두 필요한 이유
KMS 키 접근 = IAM 정책 (실행 역할에 부여) AND KMS 키 정책 (키에서 허용)
둘 중 하나만 있어도 접근 불가:
- IAM만 있고 KMS 키 정책에 없으면 → 거부
- KMS 키 정책에만 있고 IAM 없으면 → 거부
공식 암기법
KMS 접근 = 실행 역할에 kms:Decrypt (IAM 정책) + KMS 키 정책에 실행 역할 ARN 추가 (키 정책) Lambda 함수 ARN으로 키 정책 설정 → 절대 작동 안 함
확장: Lambda가 VPC 안에 있을 때
Lambda in VPC → KMS 접근은 VPC Endpoint(interface) 또는 NAT Gateway 필요
권한은 동일하게 실행 역할 기준
12. 오늘 틀린 문제 목록
| 번호 | 문제 ID | 정답 | 내 답 | 핵심 키워드 |
|---|---|---|---|---|
| Q1 | #365 | C | A | RDS PITR |
| Q5 | #47 | D | C | Capacity Reservation |
| Q6 | #90 | B | A | Read Replica |
| Q7 | #446 | D | A | S3 Object Lock |
| Q9 | #202 | B | D | KMS 자동 순환 |
| Q13 | #150 | A | C | Composite Alarm |
| Q17 | #300 | C | A | Aurora 스토리지 자동확장 |
| Q20 | #183 | A | B | DynamoDB 즉시 확장 |
| Q24 | #672 | D | C | Lambda Graviton2 |
| Q25 | #278 | B, E | D, E | Neptune 계층구조 |
| Q26 | #308 | B, D | C, A | Trusted Advisor + RI |
| Q27 | #440 | A, C | D, B | Aurora 복원 방법 |
| Q28 | #640 | C, E | B, E | Lambda KMS 권한 |
| Q29 | #690 | C | B | Shield + WAF |
| Q31 | #24 | B | C | Cost Explorer |
| Q32 | #485 | A | C | Glacier Instant |
| Q34 | #551 | A | C | Glacier Flexible |
| Q35 | #694 | B | C | DataSync |
| Q37 | #543 | A, E | E, C | Savings Plan 공유 |
| Q38 | #305 | C | B | FSx for Windows (SMB) |
| Q40 | #240 | D | C | Direct Connect 송신비용 |
| Q45 | #329 | D | B | Patch Manager |
| Q50 | #484 | A, E | B, D | Organizations + SSO |
| Q53 | #310 | B | C | CloudFront + S3 |
| Q55 | #296 | D | C | VPC CIDR /28 |
| Q57 | #670 | C | D | Step Functions 마이크로서비스 |
| Q59 | #402 | A | C | Kinesis 보존 기간 |
| Q62 | #502 | C, E | A, E | ASG + S3 이미지 이전 |
| Q63 | #449 | B | A | RDS Custom |
| Q65 | #237 | A | D | VPC Peering |
🎯 우선 암기 Top 5
- S3 Glacier 클래스 — Instant(즉시) / Flexible(수분~시간) / Deep Archive(12h+)
- RDS Custom — 특권 접근, OS 레벨 필요할 때
- Capacity Reservation — 용량 보장은 Reserved Instance 아님
- DataSync vs Storage Gateway — 단순 이관/백업은 DataSync
- SMB = FSx for Windows (EFS는 NFS 전용)