[AWS SOA-C02] Q251 ~ Q300 오답노트 6EA

📘 오답노트 - Q260

❓ 문제 요약

• 회사는 여러 AWS 계정에서 사용할 새 EC2 인스턴스 AMI를 생성.
• AMI는 AWS KMS 키로 암호화된 상태.
• 요구사항: 특정 승인된 AWS 계정만 해당 AMI를 안전하게 사용할 수 있도록 공유해야 함.

---

✅ 정답

B. AMI가 생성된 계정에서 고객 관리형 KMS 키를 생성하고, 키 정책을 수정해 다른 AWS 계정에 권한을 부여한 뒤, 복사본 AMI를 생성하여 공유 계정 번호를 지정한다.

• KMS 키로 암호화된 AMI를 다른 계정과 공유하려면:
  1. KMS 키 정책 수정 → 대상 계정에 kms:DescribeKey, kms:ReEncrypt*, kms:CreateGrant, kms:Decrypt 권한 부여.
  2. AMI 권한 수정 및 복사본 생성 → 공유하려는 계정 번호 지정.
• 이 방식이 가장 안전하고 AWS 권장 방식.

---

❌ 오답 해설

• A. 단순히 AMI 권한만 수정
  → KMS 키 권한 부여가 빠져있음. 암호화된 AMI는 키 권한 없이는 공유 계정에서 사용할 수 없음.
• C. 복사본 AMI 생성 후 공개
  → “공개”로 만들면 모든 계정이 접근 가능 → 보안 위협. 승인된 계정만 접근해야 한다는 조건 위배.
• D. AWS 관리형 키 사용
  → 관리형 키는 다른 계정과 직접 공유 불가. 반드시 고객 관리형 KMS 키를 사용해야 함.

---

📊 비교 요약

옵션	설명	적합 여부
A	AMI 권한만 수정	❌ 키 권한 누락
B	KMS 키 정책 수정 + 복사본 AMI 공유	✅ 정답
C	AMI 공개	❌ 보안 위협
D	AWS 관리형 키 사용	❌ 공유 불가

---

🎯 핵심 정리

• 암호화된 AMI 공유 = KMS 키 정책 수정 + AMI 권한 수정 두 단계가 필요.
• AWS 관리형 키(X), 고객 관리형 KMS 키(O).

---

📘 오답노트 - Q278

❓ 문제 요약

• SysOps 관리자는 Auto Scaling 그룹의 EC2 인스턴스에 애플리케이션을 배포해야 함.
• 애플리케이션 업데이트는 매주 발생.
• AMI 생성 시 취약점 검사도 필요.
• 요구사항: 효율적이고 자동화된 업데이트 및 배포.

---

✅ 정답

C. 사용자 지정 레시피와 함께 EC2 Image Builder를 사용하여 애플리케이션과 해당 종속성을 설치한다.

• EC2 Image Builder는
  • OS 및 애플리케이션 패치를 자동화,
  • AMI 생성 및 업데이트 자동화,
  • 취약점 검사(Security Scan) 지원.
• 운영 효율성과 보안 요구를 동시에 충족.

---

❌ 오답 해설

• A. Packer 사용
  → 가능은 하지만 서드파티 도구. AWS 네이티브 서비스보다 관리 오버헤드 큼.
• B. EC2 인스턴스에 직접 설치 후 AMI 생성
  → 수동 작업으로 운영 효율성 낮음. 자동화 및 취약점 검사 부족.
• D. EventBridge + CreateImage API 호출
  → 단순 자동화는 가능하나, 취약점 검사나 종속성 설치 관리 기능 없음.

---

📊 비교 요약

옵션	설명	적합 여부
A	Packer 스크립트 기반 이미지 생성	❌ (서드파티, 오버헤드)
B	인스턴스에서 직접 설치 후 AMI 생성	❌ (비효율적, 자동화 부족)
C	EC2 Image Builder → 자동화 + 보안 검사 + 종속성 관리	✅ 정답
D	EventBridge로 CreateImage API 호출	❌ (단순 자동화, 보안 기능 없음)

---

🌐 동작 원리 (Mermaid)

```mermaid
flowchart TD
    Update["📅 매주 애플리케이션 업데이트"] --> ImageBuilder["🏗️ EC2 Image Builder"]
    ImageBuilder --> Recipe["📜 사용자 지정 레시피 + 🔒 보안 스캔"]
    Recipe --> AMI["📦 최신 보안 적용 AMI 생성"]
    AMI --> AutoScaling["⚖️ Auto Scaling 그룹에 배포"]
    AutoScaling --> UpdatedEC2["💻 최신 애플리케이션 설치된 EC2 인스턴스"]
```

 

📊 결과 설명

• 📅 매주 애플리케이션 업데이트 시작
• → 🏗️ EC2 Image Builder 를 사용
• → 📜 사용자 지정 레시피 + 🔒 보안 스캔 적용
• → 📦 최신 보안 적용 AMI 생성
• → ⚖️ Auto Scaling 그룹에 배포
• → 최종적으로 💻 최신 애플리케이션 설치된 EC2 인스턴스 실행

---

🎯 핵심 정리

• 문제의 요구사항은 매주 업데이트 + 취약점 검사 + 운영 효율성.
• 이 조건을 모두 만족하는 AWS 네이티브 서비스는 EC2 Image Builder.
• 따라서 정답은 C. EC2 Image Builder 사용.

---

📘 오답노트 - Q279

❓ 문제 요약

• CloudFormation 템플릿으로 RDS 인스턴스를 생성.
• 스택이 삭제되더라도 RDS의 데이터는 보존해야 함.
• 요구사항: 안정적이고 효율적으로 데이터 보호.

---

✅ 정답

C. RDS 인스턴스의 CloudFormation 템플릿 정의에서 스냅샷 삭제 정책을 사용한다.

• CloudFormation에서는 리소스 삭제 시 행동을 제어하는 DeletionPolicy 속성이 있음.
• DeletionPolicy: Snapshot을 사용하면 스택 삭제 시 RDS 인스턴스 자체는 삭제되지만 스냅샷이 자동으로 남아 데이터 보존 가능.
• 운영 효율성과 안정성을 동시에 충족.

---

❌ 오답 해설

• A. 5분마다 스크립트로 백업
  → 불필요하게 비효율적이며, 자동화된 CloudFormation 기능을 활용하지 않음.
• B. Lambda 함수로 스택 삭제 전 스냅샷 생성
  → 가능하지만 불필요하게 복잡하고, CloudFormation 네이티브 방식보다 운영 오버헤드 큼.
• D. 새로운 템플릿 실행 후 수동 백업
  → 중복된 관리 작업, 자동화 부족.

---

📊 비교 요약

옵션	설명	적합 여부
A	스크립트로 주기적 백업	❌ (비효율적, 관리 부담)
B	Lambda로 스냅샷 후 스택 삭제	❌ (복잡, 비효율적)
C	CloudFormation DeletionPolicy: Snapshot	✅ 정답
D	별도 템플릿으로 수동 백업	❌ (자동화 부족, 중복 작업)

---

📝 CloudFormation 예시 코드

Resources:
  MyDB:
    Type: AWS::RDS::DBInstance
    Properties:
      DBInstanceClass: db.t3.micro
      Engine: mysql
      MasterUsername: admin
      MasterUserPassword: password123
    DeletionPolicy: Snapshot

• 스택 삭제 시 MyDB는 삭제되지만, 최신 스냅샷이 보존됨.

---

🎯 핵심 정리

• 문제의 요구사항은 스택 삭제 후에도 RDS 데이터 보존.
• CloudFormation의 DeletionPolicy: Snapshot이 가장 적합.

---

📘 오답노트 - Q284

❓ 문제 요약

• 금융 데이터를 Amazon S3에 저장해야 함.
• 모든 데이터는 암호화 필수.
• 자체 키 제공은 원치 않음.
• 대신, 언제/누가 키를 사용했는지 감사 추적(Audit) 필요.

---

✅ 정답

D. AWS KMS 관리형 암호화 키(SSE-KMS)와 함께 서버 측 암호화를 사용하여 Amazon S3에서 사용자 데이터를 암호화한다.

• SSE-KMS(Server-Side Encryption with KMS-Managed Keys):
  • AWS KMS를 통해 키 관리.
  • CloudTrail 로그로 키 사용 내역 및 사용자 추적 가능 → 감사 요구 충족.
  • 회사가 직접 키를 관리할 필요 없음.

---

❌ 오답 해설

• A. SSE-C (클라이언트 제공 키 암호화)
  → 키를 직접 관리해야 함. 회사가 키 관리 원하지 않는다는 조건 불일치.
• B. SSE-S3 (S3 관리형 키 암호화)
  → 암호화는 가능하지만 CloudTrail 감사 추적 불가. 키 사용 내역을 추적할 수 없음.
• C. SSE-C (고객 제공 키)
  → 고객이 키 제공 및 관리해야 하므로, 회사 요건과 충돌.

---

📊 비교 요약

옵션	설명	적합 여부
A	클라이언트 제공 키 (SSE-C), 직접 키 관리 필요	❌
B	S3 관리형 키 (SSE-S3), 감사 추적 불가	❌
C	고객 제공 키 (SSE-C), 직접 키 관리 필요	❌
D	AWS KMS 관리형 키 (SSE-KMS), 감사 추적 가능	✅ 정답

---

📝 추가 팁

• SSE-S3: 단순 암호화, 추적 불가.
• SSE-KMS: 암호화 + CloudTrail로 누가 언제 키를 사용했는지 로깅 가능.
• SSE-C: 키 관리 복잡, 보안 위험 증가.

---

🎯 핵심 정리

• 요구사항은 키 직접 관리 X, 감사 추적 필요.

---

📘 오답노트 - Q291

❓ 문제 요약

• Amazon EC2 인스턴스에서 Amazon SQS 대기열을 사용하는 애플리케이션 실행.
• SysOps 관리자는 EC2가 SQS 대기열에 메시지를 읽고, 쓰고, 삭제할 수 있어야 함.
• 요구사항: 가장 안전한 방식으로 권한 부여.

---

✅ 정답

D. EC2 인스턴스가 AWS 서비스를 호출할 수 있도록 허용하는 IAM 역할을 생성하고, 해당 역할에 SQS 권한을 연결한다.

• IAM 역할(Role) 사용 → 인스턴스 프로파일에 연결
  • EC2 인스턴스가 자동으로 IAM Role을 통해 자격 증명 획득.
  • SQS에 필요한 최소 권한(sqs:SendMessage, sqs:ReceiveMessage, sqs:DeleteMessage)만 부여.
  • 키 관리 불필요 → 안전하고 모범 사례(Best Practice).

---

❌ 오답 해설

• A. IAM 사용자 생성 후 Access Key 사용
  → Access Key를 애플리케이션에 하드코딩하거나 환경 변수에 저장해야 하므로 보안 위험.
• B. IAM 사용자 생성 후 키를 EC2 환경 변수에 내보내기
  → 동일하게 Access Key를 노출하게 되며, 키 유출 위험 존재.
• C. EC2에 IAM Role 부여 BUT sqs:* 와일드카드 권한 부여
  → 최소 권한 원칙(Least Privilege)에 어긋남. 불필요한 과도 권한 제공.

---

📊 비교 요약

옵션	설명	적합 여부
A	IAM 사용자 + Access Key 사용	❌ 보안 취약
B	IAM 사용자 + 키 환경 변수 전달	❌ 보안 취약
C	EC2에 IAM Role 연결, BUT sqs:* 와일드카드 권한	❌ 과도 권한
D	EC2에 IAM Role 연결 + 최소 권한(Send/Receive/Delete)	✅ 정답

---

🎯 핵심 정리

• Access Key 직접 사용은 위험 (A, B 탈락).
• 와일드카드(*) 권한은 최소 권한 원칙 위배 (C 탈락).
• 따라서 정답은 D (IAM Role + 최소 권한 부여).

---

📘 오답노트 - Q292

❓ 문제 요약

• SysOps 관리자가 Amazon S3 버킷을 생성하고 정적 웹 애플리케이션 파일을 복사함.
• 회사 정책: S3 버킷은 모두 비공개(공개 금지).
• 요구사항: 정적 웹 애플리케이션을 안전하게 호스팅해야 함.

---

✅ 정답

A. Amazon CloudFront 배포를 생성하고, S3 버킷을 원본 액세스 ID - OAI(Origin Access Identity)가 있는 원본으로 구성. S3 버킷 버킷 정책에서 OAI에 s3:GetObject 권한을 부여.

• CloudFront를 사용하면 S3 버킷을 직접 공개하지 않고도 웹 사이트 제공 가능.
• OAI를 통해 CloudFront에서만 S3 객체(s3:GetObject) 접근 허용.
• 보안과 성능(캐싱) 모두 충족.

---

❌ 오답 해설

• B. S3 정적 웹사이트 호스팅
  → 정적 웹사이트 호스팅은 S3 버킷이 공개되어야 동작. 회사 정책(비공개 유지) 위배.
• C. ALB 생성 후 S3 연결
  → ALB는 EC2와 같은 동적 리소스 로드밸런싱용이지 S3 정적 파일 제공 불가.
• D. AWS Global Accelerator 사용
  → 애플리케이션 성능 최적화(글로벌 네트워크 가속화)용.
  → 여전히 S3 버킷을 공개해야 하므로 정책 위배.

---

📊 비교 요약

옵션	설명	적합 여부
A	CloudFront + OAI로 S3 비공개 유지 & 안전한 배포	✅ 정답
B	S3 정적 웹 호스팅 (버킷 공개 필요)	❌ 정책 위배
C	ALB → S3 연결 불가	❌
D	Global Accelerator (네트워크 최적화)	❌ 정책 위배

---

🎯 핵심 정리

• S3 정적 웹사이트 + 보안 요구사항이 동시에 주어지면 → CloudFront + OAI 조합.
• 이 방식으로만 S3 버킷 비공개 유지 + 안전한 웹사이트 제공 가능.

---