반응형
📘 Q102 문제 정리
🔹 문제 요약
- 회사는 EC2 Auto Scaling 그룹을 사용, 평균 CPU 사용률을 기준으로 확장 중
- 이벤트 로그에서 InsufficientInstanceCapacity 오류 발생
→ 새 인스턴스를 시작하려 했으나 해당 AZ에 여유 용량 없음
👉 SysOps 관리자가 취할 수 있는 조치는 무엇일까? (2개 선택)
🔹 선택지 분석
- A. 인스턴스 유형 변경
→ 현재 AZ에서 특정 인스턴스 타입의 가용 용량이 부족한 상황
→ 다른 인스턴스 타입을 사용하면 새 인스턴스를 실행할 수 있음 ✅ - B. 다른 가용 영역(AZ)에 Auto Scaling 그룹 확장
→ 여러 AZ에 인스턴스를 분산하면 특정 AZ 용량 부족 문제를 피할 수 있음 ✅ - C. EBS 볼륨 크기를 키움
→ 디스크 크기와 용량 부족은 무관 ❌ - D. Auto Scaling 그룹 최대 크기 증가
→ 한도 설정 문제가 아니라 물리적 가용 용량 문제이므로 효과 없음 ❌ - E. 서비스 할당량 증가 요청
→ 계정 한도 문제가 아니라 리전/AZ 자원 가용성 문제라서 해당 없음 ❌
✅ 정답: A, B
📝 쉬운 해설
- InsufficientInstanceCapacity = 특정 인스턴스 타입을 해당 AZ에서 더 이상 프로비저닝할 수 없는 경우 발생
- 해결책은 인스턴스 타입 변경 또는 다른 AZ에 배포
📊 Mermaid 시각화
```mermaid
flowchart TD
ASG[Auto Scaling 그룹] --> AZ1[가용 영역 1 - 용량 부족]
ASG --> AZ2[가용 영역 2 - 여유 있음]
AZ1 -. 시도 실패 .-> Error[InsufficientInstanceCapacity]
AZ2 --> Success[새 인스턴스 실행 성공]
ASG[Auto Scaling 그룹] --> AZ1[가용 영역 1 - 용량 부족]
ASG --> AZ2[가용 영역 2 - 여유 있음]
AZ1 -. 시도 실패 .-> Error[InsufficientInstanceCapacity]
AZ2 --> Success[새 인스턴스 실행 성공]
```
🎯 암기 팁
👉 “InsufficientInstanceCapacity = 타입 바꾸거나, AZ 분산”
- 타입 변경 ✅
- 다른 AZ 활용 ✅
- EBS 크기/ASG 한도/서비스 할당량 ❌
📘 Q103 문제 정리
🔹 문제 요약
- SysOps 관리자가 AWS Systems Manager Session Manager를 사용해 EC2 인스턴스 그룹에 대한 액세스를 제어해야 함
- 특정 태그는 이미 EC2 인스턴스에 추가된 상태
- 추가로 어떤 조치를 해야 액세스를 제어할 수 있을까? (2개 선택)
🔹 선택지 분석
- A. IAM 정책을 사용자/그룹에 연결 → EC2 인스턴스 접근 권한 부여
→ Session Manager 접근을 위한 IAM 정책 필요 ✅ - B. IAM 역할을 연결하여 EC2 자체 접근 제어
→ EC2 인스턴스 프로파일과는 다르며, 직접 IAM 역할만으로는 제어 불가 ❌ - C. EC2 배치 그룹 생성 후 태그 추가
→ 배치 그룹은 물리적 배치 관리 목적, 액세스 제어와 무관 ❌ - D. 서비스 계정을 생성해 EC2 연결
→ AWS IAM 역할/정책 기반으로 해야 하므로 오답 ❌ - E. Condition 요소를 활용한 IAM 정책 작성 (태그 기반 접근 제어)
→ 특정 태그가 있는 EC2 인스턴스만 접근 가능하도록 제어 가능 ✅
✅ 정답: A, E
📝 쉬운 해설
- IAM 정책: Session Manager를 통해 접속하려면 IAM 사용자/그룹/역할에 정책을 연결해야 함
- Condition 요소: IAM 정책 조건으로 "특정 태그가 있는 EC2 인스턴스만 접근 가능"을 설정 가능
즉, IAM 정책 연결 + 태그 기반 조건 설정이 핵심 조치입니다.
📊 Mermaid 시각화
```mermaid
flowchart TD
Admin[관리자 IAM 사용자/그룹] --> Policy[IAM 정책 연결]
Policy --> Cond[Condition 태그 기반 접근 제어]
Cond --> SSM[AWS Systems Manager Session Manager]
SSM --> EC2[EC2 인스턴스 (특정 태그 있음)]
Admin[관리자 IAM 사용자/그룹] --> Policy[IAM 정책 연결]
Policy --> Cond[Condition 태그 기반 접근 제어]
Cond --> SSM[AWS Systems Manager Session Manager]
SSM --> EC2[EC2 인스턴스 (특정 태그 있음)]
```
🎯 암기 팁
👉 “SSM 접근 제어 = IAM 정책 + 태그 조건”
- IAM 정책 연결 필수
- 태그 기반 Condition으로 세밀 제어 가능
📘 Q105 문제 정리
🔹 문제 요약
- AWS Lambda 함수가 하루에 여러 번 간헐적으로 실패
- SysOps 관리자는 지난 7일 동안 이 오류가 얼마나 자주 발생했는지 확인해야 함
- 가장 운영상 효율적인 방법은?
🔹 선택지 분석
- A. Amazon Athena로 CloudWatch 로그 쿼리
→ 가능은 하지만 로그를 S3로 내보낸 뒤 Athena로 쿼리해야 해서 비효율적 ❌ - B. Amazon Athena로 CloudTrail 로그 쿼리
→ CloudTrail은 API 호출 기록, Lambda 실행 실패 세부 로그는 없음 ❌ - C. CloudWatch Logs Insights 사용
→ Lambda 로그가 기본적으로 CloudWatch Logs에 저장됨
→ Logs Insights는 로그를 직접 쿼리하고 기간 지정(예: 최근 7일) 가능 ✅ - D. OpenSearch Service + 로그 스트리밍
→ 구축 가능하지만 별도 스트리밍/인덱싱 필요, 운영 오버헤드 큼 ❌
✅ 정답: C
📝 쉬운 해설
- Lambda 로그 = CloudWatch Logs 기본 저장
- Logs Insights: CloudWatch Logs 데이터를 실시간으로 쿼리/분석 가능
- "지난 7일간 오류 패턴" 같은 질문에 즉시 활용 가능
📊 Mermaid 시각화
```mermaid
flowchart TD
Lambda[AWS Lambda 함수] --> CWL[CloudWatch Logs]
CWL --> Insights[CloudWatch Logs Insights]
Insights --> Report[오류 발생 빈도 분석 (최근 7일)]
Lambda[AWS Lambda 함수] --> CWL[CloudWatch Logs]
CWL --> Insights[CloudWatch Logs Insights]
Insights --> Report[오류 발생 빈도 분석 (최근 7일)]
```
🎯 암기 팁
👉 “Lambda 실행 오류 분석 = CloudWatch Logs Insights”
- CloudTrail ❌ (API 호출 기록)
- Athena ❌ (S3 내보내야 함)
- OpenSearch ❌ (추가 구성 필요)
📘 Q112 문제 정리
🔹 문제 요약
- 회사 애플리케이션: Elastic Load Balancer (ELB) 뒤의 EC2 Auto Scaling 그룹에서 실행
- 평상시에는 성능 안정적
- 하지만 트래픽이 증가하면 매일 동일한 4시간 동안 성능 저하 발생
👉 이 문제를 해결할 수 있는 가장 효율적인 방법은?
🔹 선택지 분석
- A. 가중치 라우팅 정책 사용 + 두 번째 ELB 구성
→ 불필요하게 복잡하며 문제의 원인(트래픽 피크 시간 성능 저하) 해결에 맞지 않음 ❌ - B. 더 큰 인스턴스 유형 사용
→ 성능 개선 가능하지만, 특정 시간대만 부하가 증가하므로 비용 낭비 ❌ - C. EC2 인스턴스 수를 예약 조정 작업(Scheduled Scaling)으로 확장
→ ✅ 정답
→ 트래픽 증가 시간이 예측 가능(매일 동일 4시간)하므로 예약된 스케일링으로 미리 인스턴스 확장 가능 - D. 수동으로 EC2 인스턴스 추가
→ 관리 부담 크고 자동화되지 않음 ❌
✅ 정답: C
📝 쉬운 해설
- Auto Scaling은 2가지 방식으로 동작:
- 동적 스케일링 → CloudWatch 지표 기반 (예: CPU > 70%)
- 예약 스케일링 → 트래픽 피크 시간이 미리 예측 가능할 때 사용
- 이 문제는 “매일 같은 시간에 성능 저하” → 예약 스케일링(Scheduled Scaling)이 정답
📊 Mermaid 시각화
```mermaid
flowchart TD
Users[사용자 트래픽] --> ELB[Elastic Load Balancer]
ELB --> ASG[Auto Scaling 그룹]
ASG --> EC2[EC2 인스턴스]
Schedule[예약 스케일링: 매일 동일 시간 인스턴스 확장] --> ASG
Users[사용자 트래픽] --> ELB[Elastic Load Balancer]
ELB --> ASG[Auto Scaling 그룹]
ASG --> EC2[EC2 인스턴스]
Schedule[예약 스케일링: 매일 동일 시간 인스턴스 확장] --> ASG
```
🎯 암기 팁
👉 “매일 같은 시간대 트래픽 증가 = Scheduled Scaling”
- 예측 불가 = 동적 스케일링
- 예측 가능 = 예약 스케일링
📘 Q113 문제 정리
🔹 문제 요약
- 회사는 단일 리전의 EC2 인스턴스에서 애플리케이션을 호스팅
- 애플리케이션은 HTTP가 아닌 TCP 트래픽 지원 필요
- AWS 네트워크를 활용해 짧은 지연 시간으로 콘텐츠 제공 원함
- Auto Scaling 그룹과 탄력적 로드 밸런싱도 필요
👉 어떤 아키텍처가 요구사항을 충족할까?
🔹 선택지 분석
- A. ALB + CloudFront
→ ALB는 HTTP/HTTPS 레벨 7 전용, TCP 지원 불가 ❌ - B. ALB + Global Accelerator
→ Global Accelerator는 ALB를 엔드포인트로 지원하지만, TCP/UDP 지원을 위해서는 NLB 사용이 더 적합 ❌ - C. NLB + CloudFront
→ CloudFront는 HTTP/HTTPS 캐싱 전용 서비스, TCP 트래픽 가속화는 불가 ❌ - D. NLB + Global Accelerator
→ NLB는 TCP/UDP 레벨 4 로드 밸런싱 지원 ✅
→ Global Accelerator는 AWS 글로벌 네트워크를 통해 최적화된 경로와 낮은 지연 시간 제공 ✅
→ Auto Scaling 그룹 뒤에 NLB 연결 가능 ✅
✅ 정답: D
📝 쉬운 해설
- ALB (Application Load Balancer) = HTTP/HTTPS (L7) 전용
- NLB (Network Load Balancer) = TCP/UDP (L4) 지원 → 문제 조건 충족
- CloudFront = 콘텐츠 캐싱/CDN, TCP 가속 목적과는 맞지 않음
- Global Accelerator = 전 세계 엣지 로케이션을 활용한 네트워크 최적화 → 짧은 지연 시간 보장
즉, TCP 기반 애플리케이션 + 글로벌 저지연 = NLB + Global Accelerator 조합이 정답입니다.
📊 Mermaid 시각화
```mermaid
flowchart TD
Users[사용자 트래픽] --> ELB[Elastic Load Balancer]
ELB --> ASG[Auto Scaling 그룹]
ASG --> EC2[EC2 인스턴스]
Schedule[예약 스케일링: 매일 동일 시간 인스턴스 확장] --> ASG
Users[사용자 트래픽] --> ELB[Elastic Load Balancer]
ELB --> ASG[Auto Scaling 그룹]
ASG --> EC2[EC2 인스턴스]
Schedule[예약 스케일링: 매일 동일 시간 인스턴스 확장] --> ASG
```
🎯 암기 팁
👉 “TCP/UDP 필요 = NLB, 글로벌 저지연 = Global Accelerator”
- HTTP/HTTPS = ALB + CloudFront
- TCP/UDP = NLB + Global Accelerator
📘 Q114 문제 정리
🔹 문제 요약
- SysOps 관리자에게는 암호화된 AMI를 배포하는 CloudFormation 템플릿이 있음
- 이 템플릿은 두 번째 계정에서도 사용됨
- 그러나 두 번째 계정에서 스택을 실행하면 실패 발생
👉 문제 해결을 위해 SysOps 관리자가 해야 할 조치는?
🔹 선택지 분석
- A. AMI 권한을 공개로 변경
→ AMI 자체는 공유 가능하지만, 암호화된 경우 KMS 키 권한도 공유해야 함. 단순 AMI 공개만으로는 실패 해결 불가 ❌ - B. 원본 계정에서 AMI 등록 취소
→ 오히려 더 문제를 악화시키는 잘못된 선택 ❌ - C. 대상 계정의 AWS KMS 키를 사용해 AMI를 다시 암호화
→ ✅ 정답
→ 암호화된 AMI를 다른 계정에서 사용하려면 해당 계정에서 사용할 수 있는 KMS 키로 다시 암호화해야 함 - D. 대상 계정에서 AMI ID를 CloudFormation 템플릿에 업데이트
→ 단순 AMI ID만 업데이트해도, KMS 키 권한이 없으면 여전히 실패 ❌
✅ 정답: C
📝 쉬운 해설
- 암호화된 AMI는 단순히 공유만으로는 다른 계정에서 사용할 수 없음
- 해결 방법: 대상 계정의 KMS 키로 재암호화해야 정상적으로 CloudFormation에서 사용 가능
📊 Mermaid 시각화
```mermaid
flowchart TD
AMI[암호화된 AMI (계정 A)] --> KMSA[KMS 키 - 계정 A]
KMSA -.공유 불가.-> AccountB[계정 B]
AMI --> ReEncrypt[계정 B의 KMS 키로 재암호화]
ReEncrypt --> Success[계정 B에서 CloudFormation 스택 실행 성공]
AMI[암호화된 AMI (계정 A)] --> KMSA[KMS 키 - 계정 A]
KMSA -.공유 불가.-> AccountB[계정 B]
AMI --> ReEncrypt[계정 B의 KMS 키로 재암호화]
ReEncrypt --> Success[계정 B에서 CloudFormation 스택 실행 성공]
```
🎯 암기 팁
👉 “암호화된 AMI 공유 문제 = KMS 키 재암호화 필요”
- 단순 AMI 공유 ❌
- 단순 AMI ID 업데이트 ❌
- KMS 키 재암호화 ✅
📘 Q117 문제 정리
🔹 문제 요약
- AWS 계정에서 IAM CreateUser API 호출이 발생할 때
- SysOps 관리자가 이메일 알림을 받고 싶음
- 어떤 작업 조합을 해야 할까? (2개 선택)
🔹 선택지 분석
- A. CloudTrail을 이벤트 소스로 사용 + EventBridge 규칙 생성
→ CloudTrail은 API 호출 기록을 이벤트로 전달
→ EventBridge 규칙으로 CreateUser API 패턴 필터링 가능 ✅ - B. Amazon CloudSearch 사용
→ CloudSearch는 검색 서비스, 이벤트 소스로 적합하지 않음 ❌ - C. IAM Access Analyzer 사용
→ 정책 분석 서비스, 이벤트 소스로 적합하지 않음 ❌ - D. Amazon SNS 사용
→ EventBridge 규칙의 대상(Target)으로 SNS 연결 → 이메일 구독 가능 ✅ - E. Amazon SES 사용
→ SES는 메일 전송 서비스이지만, EventBridge와 직접 연결하는 기본적인 패턴 아님 ❌
✅ 정답: A, D
📝 쉬운 해설
- CloudTrail + EventBridge
- CloudTrail: IAM API 호출 이벤트 기록
- EventBridge: CreateUser API 패턴 감지 시 이벤트 발생
- SNS + 이메일 구독
- EventBridge 이벤트 → SNS Topic
- SNS Topic 구독 → 이메일 알림 수신
📊 Mermaid 시각화
```mermaid
flowchart TD
UserAction[IAM CreateUser API 호출] --> CT[AWS CloudTrail]
CT --> EB[Amazon EventBridge 규칙 (CreateUser 필터)]
EB --> SNS[Amazon SNS 주제]
SNS --> Email[관리자 이메일 알림]
UserAction[IAM CreateUser API 호출] --> CT[AWS CloudTrail]
CT --> EB[Amazon EventBridge 규칙 (CreateUser 필터)]
EB --> SNS[Amazon SNS 주제]
SNS --> Email[관리자 이메일 알림]
```
🎯 암기 팁
👉 “API 이벤트 알림 = CloudTrail + EventBridge + SNS”
- CloudTrail = API 이벤트 감지
- EventBridge = 이벤트 필터링
- SNS = 이메일/SMS 알림
📘 Q118 문제 정리
🔹 문제 요약
- 현재 Amazon RDS 다중 AZ DB 인스턴스가 실행 중
- 최근 보안 감사에서 DB 인스턴스가 암호화되지 않음 → 규정 위반
- 이제 DB를 암호화해야 함
👉 어떤 접근 방식이 필요할까?
🔹 선택지 분석
- A. RDS 콘솔에서 암호화 옵션 선택
→ RDS는 생성 시 암호화 여부를 지정해야 하며, 실행 중인 인스턴스에 암호화를 직접 적용할 수 없음 ❌ - B. 새 EBS 볼륨을 생성 후 인스턴스에 연결
→ EBS 암호화는 RDS 인스턴스 DB 암호화와 직접적 연관 없음 ❌ - C. 보조 가용 영역 복제본 암호화 후 승격
→ 암호화되지 않은 기본 인스턴스로부터 생성된 복제본도 암호화되지 않음 ❌ - D. RDS 스냅샷을 생성 → 스냅샷 복사 시 암호화 적용 → 암호화된 스냅샷으로 새 인스턴스 생성
→ ✅ 정답
→ 유일하게 암호화되지 않은 DB를 암호화된 상태로 변환할 수 있는 절차
✅ 정답: D
📝 쉬운 해설
- RDS 암호화는 인스턴스 생성 시에만 가능
- 이미 실행 중인 비암호화 DB 인스턴스 → 암호화 불가
- 해결책:
- 기존 RDS 스냅샷 생성
- 스냅샷 복사 시 "암호화" 옵션 활성화
- 암호화된 스냅샷으로 새 RDS 인스턴스 생성
📊 Mermaid 시각화
```mermaid
flowchart TD
A[기존 RDS 인스턴스 - 암호화 안 됨] --> B[스냅샷 생성]
B --> C[스냅샷 복사 - 암호화 적용]
C --> D[암호화된 새 RDS 인스턴스 생성]
A[기존 RDS 인스턴스 - 암호화 안 됨] --> B[스냅샷 생성]
B --> C[스냅샷 복사 - 암호화 적용]
C --> D[암호화된 새 RDS 인스턴스 생성]
```
🎯 암기 팁
👉 “RDS 실행 중 암호화 불가 → 스냅샷 복사 후 암호화”
- 실행 중 직접 암호화 ❌
- 새 스냅샷 암호화 ✅
📘 Q120 문제 정리
🔹 문제 요약
- 회사는 VPC 내 EC2 인스턴스에서 애플리케이션 실행 중
- 이 애플리케이션은 인터넷에서 소프트웨어 업데이트를 다운로드해야 함
- 보안 정책상 모든 EC2 인스턴스는 프라이빗 서브넷에만 배포해야 함
- VPC에는 퍼블릭 서브넷과 프라이빗 서브넷이 존재
👉 이 상황에서 인터넷 접근을 가능하게 하려면?
🔹 선택지 분석
- A. VPC에 인터넷 게이트웨이 추가 후, 프라이빗 서브넷 라우팅에 경로 추가
→ 인터넷 게이트웨이는 퍼블릭 서브넷 전용. 프라이빗 서브넷에서는 직접 사용 불가 ❌ - B. 프라이빗 서브넷에 NAT 게이트웨이 추가
→ NAT 게이트웨이는 반드시 퍼블릭 서브넷에 위치해야 하므로 잘못됨 ❌ - C. 퍼블릭 서브넷에 NAT 게이트웨이 추가 후, 프라이빗 서브넷 라우팅에서 NAT 게이트웨이로 경로 지정
→ ✅ 정답
→ 프라이빗 서브넷 인스턴스들이 NAT 게이트웨이를 통해 인터넷에 아웃바운드 트래픽 전송 가능 - D. VPC에 인터넷 게이트웨이 2개 추가
→ 인터넷 게이트웨이는 하나만 가능. 그리고 프라이빗 서브넷에는 직접 적용 불가 ❌
✅ 정답: C
📝 쉬운 해설
- 프라이빗 서브넷 인스턴스는 보안상 직접 인터넷 게이트웨이 사용 불가
- 대신, 퍼블릭 서브넷에 NAT 게이트웨이 생성 → 라우팅을 NAT GW로 설정
- 이렇게 하면 인스턴스는 아웃바운드 인터넷 접근 가능, 외부에서 직접 접근 불가
📊 Mermaid 시각화
```mermaid
flowchart TD
PrivateEC2[EC2 인스턴스 - 프라이빗 서브넷] --> Route[라우팅 테이블 - NAT 게이트웨이로 경로]
Route --> NATGW[NAT 게이트웨이 - 퍼블릭 서브넷]
NATGW --> IGW[인터넷 게이트웨이]
IGW --> Internet[인터넷]
PrivateEC2[EC2 인스턴스 - 프라이빗 서브넷] --> Route[라우팅 테이블 - NAT 게이트웨이로 경로]
Route --> NATGW[NAT 게이트웨이 - 퍼블릭 서브넷]
NATGW --> IGW[인터넷 게이트웨이]
IGW --> Internet[인터넷]
```
🎯 암기 팁
👉 “프라이빗 서브넷 → 인터넷 = NAT 게이트웨이 필요”
- 퍼블릭 서브넷: IGW 직접 연결
- 프라이빗 서브넷: NAT GW 통해 간접 연결
📘 Q122 문제 정리
🔹 문제 요약
- SysOps 관리자가 고성능 컴퓨팅(HPC) 애플리케이션 실행을 위해 EC2 인스턴스 클러스터를 구성해야 함
- HPC 특성상 노드 간 최소 대기 시간(Low Latency) 필요
👉 어떤 조치를 취해야 할까? (2개 선택)
🔹 선택지 분석
- A. Amazon EFS 파일 시스템 생성
→ 파일 공유는 가능하지만, HPC의 핵심 요건인 노드 간 저지연 통신과 무관 ❌ - B. 다중 AZ 로드 밸런서 사용
→ HPC는 단일 AZ 내 저지연 클러스터가 핵심. 다중 AZ 사용 시 지연 시간 증가 ❌ - C. 단일 서브넷 내 Auto Scaling 그룹에서 EC2 시작
→ 같은 서브넷/같은 AZ에 인스턴스를 모아 저지연 네트워킹 가능 ✅ - D. EC2 인스턴스를 클러스터 배치 그룹(Cluster Placement Group)에서 시작
→ HPC 워크로드를 위해 인스턴스를 물리적으로 근접 배치해 네트워크 지연 최소화 ✅ - E. EC2 인스턴스를 파티션 배치 그룹에서 시작
→ 파티션은 대규모 분산 워크로드에 적합 (예: Hadoop), 저지연 HPC 목적과는 맞지 않음 ❌
✅ 정답: C, D
📝 쉬운 해설
- HPC 애플리케이션 → 인스턴스 간 저지연 네트워크 필수
- 이를 위해:
- 단일 서브넷/단일 AZ에 배치 (네트워크 경로 짧게)
- Cluster Placement Group 사용 (인스턴스를 물리적으로 가까운 하드웨어에 배치)
📊 Mermaid 시각화
```mermaid
flowchart TD
ASG[Auto Scaling 그룹 - 단일 서브넷] --> EC1[EC2 인스턴스 1]
ASG --> EC2[EC2 인스턴스 2]
ASG --> EC3[EC2 인스턴스 3]
subgraph CPG[Cluster Placement Group - 저지연]
EC1
EC2
EC3
end
ASG[Auto Scaling 그룹 - 단일 서브넷] --> EC1[EC2 인스턴스 1]
ASG --> EC2[EC2 인스턴스 2]
ASG --> EC3[EC2 인스턴스 3]
subgraph CPG[Cluster Placement Group - 저지연]
EC1
EC2
EC3
end
```
🎯 암기 팁
👉 “HPC = 단일 AZ + Cluster Placement Group”
- EFS ❌
- Multi-AZ ❌
- Partition ❌
📘 Q123 문제 정리
🔹 문제 요약
- 고객이 Amazon S3 정적 웹 콘텐츠에 액세스하는 동안 지연 시간 증가 발생
- SysOps 관리자는 특정 S3 버킷에서 매우 높은 읽기 트래픽을 관찰
- 목표: S3 버킷 로드 줄이고 지연 시간 최소화
👉 어떤 접근 방식이 가장 적절할까?
🔹 선택지 분석
- A. S3 버킷을 더 가까운 리전으로 마이그레이션
→ 리전 변경만으로는 전 세계 사용자 지연 시간 해결 불가 ❌ - B. 교차 리전 복제를 사용해 다른 리전으로 복제
→ 데이터 복제는 가능하지만, 전 세계 캐싱/지연 시간 최소화에는 적절치 않음 ❌ - C. CloudFront 배포 생성, S3를 오리진으로 사용
→ ✅ 정답
→ CloudFront는 전 세계 엣지 로케이션에서 콘텐츠 캐싱 → S3 부하 감소 + 지연 시간 단축 - D. Amazon ElastiCache로 캐싱
→ ElastiCache는 데이터베이스 캐싱 용도로 주로 사용, S3 정적 웹 콘텐츠 캐싱에는 부적합 ❌
✅ 정답: C
📝 쉬운 해설
- 문제 핵심: S3에 직접 트래픽 집중 → 지연 시간 증가
- CloudFront 사용:
- 전 세계 엣지 로케이션에서 캐시 제공
- 사용자는 가까운 엣지 서버에서 콘텐츠 제공받아 지연 시간 단축
- 원본 S3에 도달하는 요청 횟수도 줄어듦 → 부하 분산 효과
📊 Mermaid 시각화
```mermaid
flowchart TD
user[전 세계 사용자]
cloudfront[Amazon CloudFront 엣지 로케이션]
s3[S3 버킷 - 오리진]
cache[캐싱된 콘텐츠 제공]
user --> cloudfront
cloudfront --> s3
cloudfront --> cache
user[전 세계 사용자]
cloudfront[Amazon CloudFront 엣지 로케이션]
s3[S3 버킷 - 오리진]
cache[캐싱된 콘텐츠 제공]
user --> cloudfront
cloudfront --> s3
cloudfront --> cache
```
🎯 암기 팁
👉 “S3 읽기 트래픽 + 지연 시간 문제 = CloudFront 캐싱”
- 데이터베이스 캐싱 = ElastiCache
- 웹 콘텐츠 캐싱 = CloudFront
📘 Q127 문제 정리
🔹 문제 요약
- 상황: VPC에서 사용할 프라이빗 IPv4 주소가 고갈되어 EC2 인스턴스를 시작할 수 없음.
- 질문: SysOps 관리자가 취할 수 있는 올바른 조치는? (2개 선택)
🔹 선택지 분석
- A. 보조 IPv4 CIDR 블록을 VPC에 연결한다.
→ ✅ 정답
→ 기존 VPC에 Secondary IPv4 CIDR을 추가해서 IP 풀을 확장할 수 있음. - B. 기본 IPv6 CIDR 블록을 VPC에 연결한다.
→ ❌ IPv6은 IPv4 고갈 문제를 직접 해결하지 못함. (IPv6 전환과는 별개 문제) - C. VPC에 대한 새 서브넷을 생성한다.
→ ✅ 정답
→ 새로 추가한 CIDR 블록을 기반으로 새 서브넷을 만들어야 인스턴스 배포 가능. - D. VPC의 CIDR 블록을 수정한다.
→ ❌ 기존 CIDR은 수정 불가. 오직 추가만 가능. - E. 인스턴스와 연결된 서브넷의 CIDR 블록을 수정한다.
→ ❌ 서브넷 CIDR도 생성 후 변경 불가. 새로운 서브넷을 생성해야 함.
✅ 정답: A, C
📝 쉬운 해설
- VPC CIDR 수정 불가 → Secondary IPv4 CIDR 추가
- 서브넷 CIDR 수정 불가 → 새 서브넷 생성 필요
즉, IPv4 부족 = VPC에 보조 CIDR 추가 + 새 서브넷 생성
📊 흐름도 (Mermaid)
```mermaid
flowchart TD
VPC[VPC - 기존 CIDR 고갈] --> AddCIDR[보조 IPv4 CIDR 추가]
AddCIDR --> NewSubnet[새 서브넷 생성]
NewSubnet --> EC2[새로운 EC2 인스턴스 시작 가능]
VPC[VPC - 기존 CIDR 고갈] --> AddCIDR[보조 IPv4 CIDR 추가]
AddCIDR --> NewSubnet[새 서브넷 생성]
NewSubnet --> EC2[새로운 EC2 인스턴스 시작 가능]
```
🎯 암기 팁
👉 “CIDR 고갈 = VPC에 CIDR 추가 + 새 서브넷 생성”
- CIDR 수정 불가 ❌
- 서브넷 CIDR 수정 불가 ❌
📘 Q128 문제 정리
🔹 문제 요약
- SysOps 관리자가 새 AWS 계정에서 EC2 Auto Scaling 그룹 생성
- 일부 인스턴스 추가 후, 최소 인스턴스 수에 도달하지 못함 → 오류 발생
- 오류 메시지:
-
새 EC2 인스턴스를 시작하지 못했습니다. 상태 이유: 귀하의 할당량은 0개의 추가 인스턴스 실행만 허용합니다. 최소 1개가 필요합니다.
- 즉, 계정의 EC2 인스턴스 서비스 할당량 부족(=Limit) 문제
👉 어떻게 해결할까?
🔹 선택지 분석
- A. Billing & Cost Management 콘솔에서 EC2 지출 한도 조정
→ ❌ 지출 한도는 관련 없음. 문제는 서비스 할당량 - B. EC2 콘솔의 설정 섹션에서 특정 리전의 EC2 할당량 수정
→ ❌ 콘솔에서 직접 수정 불가. AWS Support를 통한 요청 필요 - C. AWS Management Console → 서비스 할당량 (Service Quotas)에서 인스턴스 유형 패밀리별 할당량 증가 요청
→ ✅ 정답
→ EC2는 인스턴스 패밀리별(vCPU 기반) 할당량 제한이 있으며, Service Quotas에서 증가 요청 가능 - D. Auto Scaling 그룹 재조정 작업
→ ❌ 근본적 해결 불가 (여전히 할당량 제한 때문에 실패)
✅ 정답: C
📝 쉬운 해설
- AWS 새 계정은 기본적으로 리소스 할당량이 낮음 (예: t2.micro 몇 개만 가능)
- Auto Scaling에서 인스턴스 추가 시 한도 초과 → 인스턴스 시작 불가
- 해결책: Service Quotas(AWS 콘솔)에서 할당량 증가 요청
📊 Mermaid 시각화
```mermaid
flowchart TD
AutoScaling[EC2 Auto Scaling 그룹] --> EC2[새 EC2 인스턴스 요청]
EC2 --> LimitCheck[계정 EC2 할당량 확인]
LimitCheck -. 초과 .-> Error[인스턴스 시작 실패]
LimitCheck --> Request[Service Quotas에서 할당량 증가 요청]
Request --> Success[정상적으로 인스턴스 시작 가능]
AutoScaling[EC2 Auto Scaling 그룹] --> EC2[새 EC2 인스턴스 요청]
EC2 --> LimitCheck[계정 EC2 할당량 확인]
LimitCheck -. 초과 .-> Error[인스턴스 시작 실패]
LimitCheck --> Request[Service Quotas에서 할당량 증가 요청]
Request --> Success[정상적으로 인스턴스 시작 가능]
```
🎯 암기 팁
👉 “EC2 인스턴스 시작 불가 + ‘할당량 부족’ 오류 = Service Quotas 증가 요청”
📘 Q130 문제 정리
🔹 문제 요약
- 회사는 ALB (Application Load Balancer) 뒤에 3개의 EC2 인스턴스로 웹 애플리케이션 운영 중
- 특정 기간 동안 트래픽이 증가하면 성능 저하 발생
- SysOps 관리자는 애플리케이션이 증가된 트래픽을 감당할 수 있도록 확장해야 함
👉 어떤 솔루션이 가장 적절할까?
🔹 선택지 분석
- A. CloudWatch 경보로 인스턴스 크기를 늘린다.
→ ❌ Auto Scaling 없이 단일 인스턴스 크기를 키우는 방식 → 수평 확장이 아님 - B. EventBridge 규칙으로 ALB에 EC2 인스턴스 추가
→ ❌ ALB는 직접 EC2 인스턴스를 추가/제거하지 않음 → Auto Scaling 그룹이 필요 - C. 대상 추적 조정(Target Tracking Scaling Policy)을 사용, Auto Scaling 그룹에 EC2 인스턴스 포함 후 ALB에 연결
→ ✅ 정답
→ 트래픽 증가 시 Auto Scaling이 자동으로 인스턴스를 늘리고, ALB가 로드 분산 처리 - D. 예약된 조정 정책(Scheduled Scaling)을 사용해 EC2 인스턴스를 Auto Scaling 그룹에 추가
→ ❌ 예약된 스케일링은 특정 시간대 트래픽 증가 시 적합, 본 시나리오(임의의 트래픽 증가)에는 부적절
✅ 정답: C
📝 쉬운 해설
- 문제 핵심: 트래픽 증가 → 성능 저하 → 자동 확장 필요
- 가장 적절한 방법은:
- Auto Scaling 그룹에 EC2 인스턴스를 포함
- Target Tracking Policy (예: CPU 사용률 70% 유지)로 자동 스케일링
- ALB와 Auto Scaling 그룹을 연결 → 새 인스턴스도 자동으로 트래픽 분산
📊 Mermaid 시각화
```mermaid
flowchart TD
Users[사용자 트래픽] --> ALB[Application Load Balancer]
ALB --> ASG[Auto Scaling 그룹]
ASG --> EC1[EC2 인스턴스 1]
ASG --> EC2[EC2 인스턴스 2]
ASG --> EC3[EC2 인스턴스 3]
Policy[Target Tracking Policy - CPU/Request 기반] --> ASG
Users[사용자 트래픽] --> ALB[Application Load Balancer]
ALB --> ASG[Auto Scaling 그룹]
ASG --> EC1[EC2 인스턴스 1]
ASG --> EC2[EC2 인스턴스 2]
ASG --> EC3[EC2 인스턴스 3]
Policy[Target Tracking Policy - CPU/Request 기반] --> ASG
```
🎯 암기 팁
👉 “트래픽 증가 → ALB + Auto Scaling + Target Tracking”
- 일정 시간대 예측 가능 = Scheduled Scaling
- 예측 불가/실시간 대응 = Target Tracking Scaling Policy
📘 Q132 문제 정리
문제 요약
- 조건: 60분 이상 평균 CPU 사용률이 10% 미만이면 EC2 인스턴스를 자동 종료해야 함.
- 목표: 운영상 가장 효율적인 방법 선택.
선택지 분석
- A. cron으로 60분마다 스크립트 실행
→ 에이전트/스크립트 관리 필요, 신뢰성·확장성 떨어짐. ❌ - B. CloudWatch 경보로 평균 CPU 모니터링(평균 기간 1시간, 임계치 10%) + 경보 연계 EC2 작업(Stop/Terminate)
→ AWS 네이티브, 관리형, 신뢰성 높음. ✅ - C. CloudWatch 에이전트 + 커스텀 지표 세트
→ 기본 지표(CPUUtilization)로 충분, 에이전트 불필요. 과도한 구성. ❌ - D. Systems Manager Run Command로 60분마다 CPU 확인
→ 주기 호출·권한·오케스트레이션 관리 부담 큼. 이벤트 기반이 아님. ❌
정답: B
구현 핵심(짧게)
- CloudWatch Alarm 생성
- Metric: CPUUtilization (Average)
- Period: 60 minutes
- Threshold: < 10
- Evaluation: 1 (또는 운영 기준에 맞게 2~3)
- Alarm 상태(Alarm) 시 EC2 인스턴스 작업 연결
- 작업 유형: Stop this instance(중지) 또는 Terminate this instance(종료)
- 필요 권한: EC2ActionsAccess가 포함된 CloudWatch 알람 서비스 연결 역할(콘솔이 자동 생성/선택 가능)
흐름도
```mermaid
flowchart TD
Metric[CloudWatch Metric: CPUUtilization avg 60m] --> Alarm[CloudWatch Alarm < 10%]
Alarm --> Action[EC2 Action: Stop/Terminate Instance]
Metric[CloudWatch Metric: CPUUtilization avg 60m] --> Alarm[CloudWatch Alarm < 10%]
Alarm --> Action[EC2 Action: Stop/Terminate Instance]
```
한줄 암기
👉 “지표 기반 자동조치 = CloudWatch Alarm + EC2 Action”
스크립트/Run Command ❌, 에이전트 ❌. 기본 CPU 지표로 충분 ✅
“지표 기반 자동 조치 = CloudWatch Alarm + EC2 Action(Stop/Terminate)”
운영 시 주의사항
- Auto Scaling 그룹인지 여부 확인
- 개별 인스턴스에 “Terminate”를 걸면 ASG가 다시 인스턴스를 띄울 수 있음.
- ASG 환경이라면: Target Tracking/Step Scaling(예: 평균 CPU 10% 유지)으로 스케일-인이 더 자연스러움.
- Stop vs Terminate
- Stop: 재시작 가능(요금: EBS 스토리지만).
- Terminate: 완전 삭제(스냅샷/백업 전략 사전 점검 필수).
- 지표 지연: CloudWatch 표준 지표는 수 분 지연될 수 있음 → 서비스 특성에 맞게 Period/Evaluation 조정.
한 줄 정리
“지표 기반 자동종료 = CloudWatch Alarm(평균 CPU 60분 <10%) + EC2 Action(Stop/Terminate)”
📘 Q138 문제 정리
📝 문제
- 회사는 ALB(Elastic Load Balancer) 뒤의 EC2 웹 애플리케이션을 운영 중
- 보안팀은 AWS Certificate Manager(ACM) SSL 인증서를 사용하여 웹 사이트를 보호하려고 함
- 요구사항: 모든 HTTP 요청을 HTTPS로 자동 리디렉션해야 한다
✅ 보기
A. ALB에 HTTPS 리스너(포트 80)만 두고 SSL 인증서를 연결 → ❌ (포트 80은 HTTP 전용, HTTPS 리스너는 443 필요)
B. ALB에 포트 80 HTTP 리스너와 포트 443 HTTPS 리스너를 두고, SSL 인증서를 포트 443에 연결 + 포트 80 요청은 443으로 리디렉션 규칙 설정 → ✅
C. ALB에 두 개의 **TCP 리스너(80, 443)**를 두고 SSL 인증서를 443에 연결 → ❌ (TCP는 SSL/TLS 오프로딩 지원 불가)
D. NLB에 두 개의 TCP 리스너를 두고 SSL 인증서를 443에 연결 → ❌ (NLB는 HTTP → HTTPS 리디렉션 기능 없음)
🎯 정답
B. 포트 80 HTTP 리스너 + 포트 443 HTTPS 리스너 구성, 80 → 443 리디렉션 규칙 적용
💡 해설
- HTTP → HTTPS 강제 리디렉션은 Application Load Balancer에서 가능
- ALB 리스너 규칙에서 리디렉션(redirect action) 기능 제공
- **NLB(Network Load Balancer)**는 단순 TCP 수준 로드밸런싱이라 이런 기능 없음
📊 시각화 (Mermaid)
```mermaid
flowchart TD
Metric[CloudWatch Metric: CPUUtilization avg 60m] --> Alarm[CloudWatch Alarm < 10%]
Alarm --> Action[EC2 Action: Stop/Terminate Instance]
Metric[CloudWatch Metric: CPUUtilization avg 60m] --> Alarm[CloudWatch Alarm < 10%]
Alarm --> Action[EC2 Action: Stop/Terminate Instance]
```
📌 핵심 포인트
- SSL 인증서는 반드시 443 포트 리스너에 연결해야 함
- 리디렉션 규칙은 ALB HTTP 리스너에서 설정
- NLB는 Layer 4, ALB는 Layer 7 → 리디렉션 같은 고급 기능은 ALB에서만 가능
📘 Q140 문제 정리 (Amazon ECS 네트워크 트래픽 모니터링)
❓ 문제
회사는 Amazon ECS (Elastic Container Service) 를 사용해 Amazon EC2 인스턴스에서 컨테이너화된 애플리케이션을 실행 중입니다.
SysOps 관리자는 ECS 작업 간 트래픽 흐름만 모니터링해야 합니다.
👉 어떤 단계 조합을 수행해야 할까요? (2개 선택)
✅ 정답: B, C
- B. 각 작업의 탄력적 네트워크 인터페이스에서 VPC 흐름 로그를 구성한다.
→ VPC Flow Logs는 네트워크 트래픽을 캡처해 CloudWatch Logs나 S3에 저장할 수 있음.
→ ECS 작업 간의 트래픽을 확인하려면 ENI(Elastic Network Interface) 레벨에서 Flow Logs를 활성화해야 함. - C. 작업 정의에서 awsvpc 네트워크 모드를 지정한다.
→ awsvpc 모드는 각 ECS Task에 자체 ENI를 부여하여 VPC 네트워크와 직접 통신할 수 있게 함.
→ 따라서 작업(Task) 단위로 네트워크 트래픽 모니터링이 가능해짐.
❌ 오답 해설
- A. CloudWatch Logs 구성
→ 애플리케이션 로그 수집 용도이지, 네트워크 트래픽 흐름 모니터링은 불가능. - D. 브리지(bridge) 네트워크 모드
→ 컨테이너 인스턴스 내에서 Docker 가상 네트워크를 사용, ENI 단위 추적 불가. - E. 호스트(host) 네트워크 모드
→ 컨테이너가 EC2 인스턴스의 네트워크 스택을 공유, 개별 Task 네트워크 추적 불가.
📊 시각화 (Mermaid)
```mermaid
flowchart TD
subgraph ECS["Amazon ECS Cluster"]
Task1["Task 1 (awsvpc, ENI-1)"]
Task2["Task 2 (awsvpc, ENI-2)"]
end
Task1 <---> Task2
Task1 --> ENI1["Elastic Network Interface (ENI-1)"]
Task2 --> ENI2["Elastic Network Interface (ENI-2)"]
ENI1 --> VPC["VPC Flow Logs"]
ENI2 --> VPC
VPC --> CloudWatch["Amazon CloudWatch Logs / S3"]
subgraph ECS["Amazon ECS Cluster"]
Task1["Task 1 (awsvpc, ENI-1)"]
Task2["Task 2 (awsvpc, ENI-2)"]
end
Task1 <---> Task2
Task1 --> ENI1["Elastic Network Interface (ENI-1)"]
Task2 --> ENI2["Elastic Network Interface (ENI-2)"]
ENI1 --> VPC["VPC Flow Logs"]
ENI2 --> VPC
VPC --> CloudWatch["Amazon CloudWatch Logs / S3"]
```
📌 핵심 요약
- 네트워크 모니터링 → VPC Flow Logs
- Task 단위 네트워크 추적 → awsvpc 모드
- ECS에서 Task 간 트래픽 흐름 모니터링은 B + C 조합으로만 가능
📘 Q143 문제 정리 (Amazon EBS 스냅샷 복구)
❓ 문제
SysOps 관리자가 Amazon EBS 스냅샷을 복원하려고 하는데, 다른 관리자가 실수로 스냅샷을 삭제했습니다.
→ 회사는 스냅샷이 삭제되더라도 일정 기간 동안 복구할 수 있는 기능을 원합니다.
👉 어떤 솔루션이 이 기능을 제공할까요?
✅ 정답: C. 원하는 보관 기간 동안 EBS 스냅샷에 대한 휴지통 보관 규칙 생성
💡 해설
- AWS에서는 Amazon Data Lifecycle Manager(DLM) + EBS Snapshots Archive/Recycle Bin 기능을 통해 삭제된 스냅샷을 일정 기간 동안 복구 가능하도록 설정할 수 있습니다.
- 이 기능은 Recycle Bin for EBS Snapshots이라고 하며, 보존 규칙(retention rules)을 만들면, 삭제된 스냅샷이 즉시 완전히 사라지지 않고 지정된 기간 동안 복구 가능합니다.
❌ 오답 해설
- A. 개별 스냅샷에 삭제 방지 기능: 스냅샷에는 S3처럼 버전 관리/삭제 방지 기능 없음.
- B. IAM 정책으로 삭제 거부: 삭제를 막을 순 있지만, 실수로 삭제된 경우 복구 불가능.
- D. EventBridge + Lambda → Glacier 백업: 가능은 하지만 스냅샷 복구 기능과는 무관, 아카이빙일 뿐.
📊 시각화 (Mermaid)
```mermaid
flowchart TD
Admin[관리자] --> Delete[스냅샷 삭제]
Delete --> RecycleBin["EBS Snapshot Recycle Bin (보존 규칙 적용)"]
RecycleBin -->|보존 기간 내 복구| Snapshot[스냅샷 복원]
RecycleBin -->|보존 기간 종료| PermanentDelete[영구 삭제]
Admin[관리자] --> Delete[스냅샷 삭제]
Delete --> RecycleBin["EBS Snapshot Recycle Bin (보존 규칙 적용)"]
RecycleBin -->|보존 기간 내 복구| Snapshot[스냅샷 복원]
RecycleBin -->|보존 기간 종료| PermanentDelete[영구 삭제]
```
📌 핵심 포인트
- EBS 스냅샷 Recycle Bin → 삭제 후에도 지정된 보존 기간 동안 복구 가능
- DR(재해 복구) 및 실수 방지 목적에 유용
- IAM 정책은 예방책, Recycle Bin은 복구책
👉 이 문제는 시험에서 자주 나오는 EBS Snapshot Recycle Bin 관련 문제입니다.
📘 Q146 문제 정리 (Amazon S3 Glacier – Vault Lock)
❓ 문제
회사는 Amazon S3 Glacier에 민감한 데이터를 보관하려 합니다.
규제 및 규정 준수 요구 때문에, **모든 계정의 데이터 수정 금지(불변성 보장)**가 필요합니다.
👉 어떤 솔루션이 이 요구사항을 충족할까요?
✅ 정답: B. S3 Glacier 볼트(Vault)에 볼트 잠금 정책(Vault Lock Policy)을 연결하고, 잠금 ID를 사용하여 24시간 이내에 정책을 검증
💡 해설
- S3 Glacier Vault Lock
- 규정 준수 및 보안 요건을 충족하기 위해 제공되는 기능
- Vault에 **잠금 정책(Lock Policy)**를 설정하면, 일단 잠금이 커밋(commit)되면 변경 불가
- WORM (Write Once, Read Many) 스토리지를 구현 → 데이터 삭제·수정 방지
- 정책은 24시간 내 검증해야 하고, 그 이후에는 영구적으로 고정됨
❌ 오답 해설
- A. 24시간 후에 검증 → 잘못됨, 반드시 24시간 내 검증 필요
- C/D. 거버넌스 모드 S3 객체 잠금 → 이는 S3 Object Lock 기능, S3 Glacier Vault Lock과는 다른 서비스
📊 시각화 (Mermaid)
```mermaid
flowchart TD
Data[민감 데이터] --> Vault[S3 Glacier Vault]
Vault -->|Vault Lock Policy 설정| Lock[WORM 적용 (Write Once Read Many)]
Lock --> Compliance[규제 준수: 수정/삭제 불가]
Data[민감 데이터] --> Vault[S3 Glacier Vault]
Vault -->|Vault Lock Policy 설정| Lock[WORM 적용 (Write Once Read Many)]
Lock --> Compliance[규제 준수: 수정/삭제 불가]
```
📌 핵심 포인트
- 규정 준수 & 불변성 보장 = S3 Glacier Vault Lock
- 정책 설정 후 24시간 내 검증 필수
- 커밋 이후 정책은 변경 불가
- Object Lock과 혼동 주의 (Object Lock = S3 버킷, Vault Lock = Glacier 볼트)
👉 이 문제는 시험에서 자주 묻는 Vault Lock vs S3 Object Lock 비교 문제입니다.
📊 Object Lock vs Vault Lock 비교
| 구분 | S3 Object Lock | S3 Glacier Vault Lock |
| 적용 대상 | S3 버킷 내 개별 객체 | S3 Glacier의 Vault 전체 |
| 주요 목적 | 개별 객체 수준에서 WORM(Write Once, Read Many) 보장 | Vault 단위로 데이터 수정/삭제 방지 |
| 사용 사례 | 규정 준수 보관(예: 금융 데이터, 로그 파일) | 규제 데이터 아카이빙(예: 의료 기록, 법적 증거) |
| 정책 유형 | - Governance Mode (관리자 권한으로 삭제 가능) - Compliance Mode (완전 불변, 관리자도 수정 불가) |
Vault Lock Policy (커밋 후 변경 불가) |
| 적용 단위 | 객체 단위 (파일 단위) | 볼트 단위 (컨테이너 단위) |
| 잠금 적용 방식 | 객체 업로드 시 Object Lock 적용 | Vault에 Policy를 걸고, 잠금 ID로 24시간 내 검증 → 커밋 |
| 변경 가능 여부 | Governance Mode에서는 관리자 해제 가능 Compliance Mode는 불가능 |
한 번 커밋하면 영구 불변 (변경 불가) |
| 통합 서비스 | S3 버킷, S3 API | S3 Glacier (아카이빙) |
📌 한 줄 요약
- S3 Object Lock → 개별 객체 보호 (Governance/Compliance Mode 선택 가능)
- Glacier Vault Lock → Vault 단위 보호, 24시간 내 검증 후 영구 불변
👉 이렇게 보면 시험에서 "객체 단위 불변성" vs "아카이브 전체 불변성" 구분이 핵심 포인트입니다.
📘 Q149 문제 정리 (AWS Organizations + EC2 백업 전략)
❓ 문제
회사는 AWS Organizations를 사용해 여러 AWS 계정을 관리합니다.
SysOps 관리자는 회사의 모든 계정에 걸쳐 EC2 인스턴스 백업 전략을 수립해야 합니다.
👉 어떤 솔루션이 가장 효율적일까요?
✅ 정답: C. 마스터 계정에서 AWS Backup을 사용하여 모든 계정 및 리소스에 대한 정책을 배포한다.
💡 해설
- AWS Backup은 중앙에서 백업 정책을 정의하고,
AWS Organizations를 통해 여러 계정과 리소스에 적용할 수 있습니다. - Backup Policy를 생성 후 OU(조직 단위)에 연결하면 모든 계정에 일괄 적용됩니다.
- 따라서 운영 효율성 + 규정 준수 모두 만족.
❌ 오답 해설
- A. Lambda 배포 후 스냅샷 실행
→ 계정마다 함수 배포 필요, 관리 복잡성 ↑ → 비효율적. - B. CloudFormation으로 태그 추가
→ 태그만으로 백업 자동화 불가, 실제 스냅샷 수행 X. - D. SCP(Service Control Policy) 사용
→ SCP는 권한 제어 정책이지, 스냅샷 실행 기능이 아님.
📊 시각화 (Mermaid)
```mermaid
flowchart TD
Master[Master Account] --> Backup[AWS Backup Policy]
Backup --> OU1[Org Unit 1 - EC2 Instances]
Backup --> OU2[Org Unit 2 - EC2 Instances]
OU1 --> Snap1[자동 백업 실행]
OU2 --> Snap2[자동 백업 실행]
Master[Master Account] --> Backup[AWS Backup Policy]
Backup --> OU1[Org Unit 1 - EC2 Instances]
Backup --> OU2[Org Unit 2 - EC2 Instances]
OU1 --> Snap1[자동 백업 실행]
OU2 --> Snap2[자동 백업 실행]
```
📌 핵심 포인트
- AWS Backup + AWS Organizations = 다계정 환경 백업 전략 표준
- 중앙 관리, 자동 정책 배포, 규정 준수 강화
- Lambda/CloudFormation/SCP는 보조적이지만 중앙 집중 백업 전략에 부적합
👉 이 문제는 시험에서 자주 나오는 AWS Backup과 Organizations 통합 관련 문제예요.
📘 Q150 문제 정리 (VPC Flow Logs – 모든 트래픽 기록)
❓ 문제
SysOps 관리자가 **VPC 흐름 로그(Flow Logs)**를 검토하여 연결 문제를 해결 중입니다.
로그를 확인하는 동안 거부된 트래픽이 기록되지 않음을 발견했습니다.
👉 모든 트래픽(허용 + 거부)이 기록되도록 하려면 무엇을 해야 할까요?
✅ 정답: A. 모든 트래픽을 캡처하는 필터 설정이 있는 새 흐름 로그를 생성한다.
💡 해설
- VPC Flow Logs는 3가지 필터 옵션이 있음:
- ACCEPT → 허용된 트래픽만 기록
- REJECT → 거부된 트래픽만 기록
- ALL → 허용 + 거부 모든 트래픽 기록
- 기존 Flow Logs는 필터를 수정할 수 없음 → 반드시 새로운 Flow Log를 생성해야 함.
- 따라서 "거부된 트래픽도 기록되게 하려면 → 필터를 ALL로 설정한 새 Flow Log 생성"이 정답.
❌ 오답 해설
- B/D. 로그 형식 편집
→ 로그 출력 포맷만 바뀌지, 허용/거부 캡처 범위는 변하지 않음. - C. 기존 Flow Log 필터 수정
→ Flow Logs는 한 번 생성되면 편집 불가, 삭제 후 재생성이 필요.
📊 시각화 (Mermaid)
```mermaid
flowchart TD
Subnet["VPC Subnet"] --> FlowLog1["Flow Log: Filter=ACCEPT"]
FlowLog1 --> Logs1["CloudWatch Logs: 허용만 기록"]
Subnet --> FlowLog2["Flow Log: Filter=ALL (새로 생성)"]
FlowLog2 --> Logs2["CloudWatch Logs: 허용+거부 기록"]
Subnet["VPC Subnet"] --> FlowLog1["Flow Log: Filter=ACCEPT"]
FlowLog1 --> Logs1["CloudWatch Logs: 허용만 기록"]
Subnet --> FlowLog2["Flow Log: Filter=ALL (새로 생성)"]
FlowLog2 --> Logs2["CloudWatch Logs: 허용+거부 기록"]
```
📌 핵심 포인트
- VPC Flow Logs → 필터: ACCEPT / REJECT / ALL
- 기존 로그는 편집 불가 → 새로 생성 필요
- 거부 트래픽까지 확인하려면 필터=ALL 설정
👉 이 문제는 시험에서 자주 나오는 VPC Flow Logs 필터와 편집 불가 특성 관련 포인트입니다.
📊 VPC Flow Logs – 필터 옵션 비교
| 필터 옵션 | 기록되는 내용 | 사용 예시 |
| ACCEPT | 허용된 트래픽만 기록 | 정상적인 연결 상태 분석 (ex. EC2 ↔ RDS 연결 성공 로그 확인) |
| REJECT | 거부된 트래픽만 기록 | 보안 그룹/네트워크 ACL 문제 진단 (ex. 인바운드 차단 원인 확인) |
| ALL | 허용 + 거부 모든 트래픽 기록 | 가장 완전한 모니터링 (네트워크 전체 감사, 보안 사고 분석) |
📌 핵심 암기 문구
- ACCEPT = 정상 확인
- REJECT = 차단 확인
- ALL = 둘 다 확인 → 시험 정답
📊 VPC Flow Logs – 필터 옵션 시각화
📌 핵심 기억 포인트
- ACCEPT → 허용만
- REJECT → 거부만
- ALL → 둘 다 (시험 정답 포인트)
반응형
'AWS > AWS SOA-C02' 카테고리의 다른 글
| Q001 ~ Q100 오답노트 22EA (0) | 2025.09.07 |
|---|
