본문 바로가기
AWS/SAA 준비

AWS SAA 합격으로 가는 길 #142

by Pacloud 2025. 12. 19.
반응형

안녕하세요! 넥스트클라우드의 테크니컬 트레이너 김유림입니다. 😊

오늘 함께 풀어볼 문제는 알고 있으면 정말 유익하지만, 잘 모를 수 있는 내용으로 구성해봤습니다.

 

문제는 세 가지 단계를 거치며 풀어가겠습니다.

1. 문제의 요구사항 분석하기

2. 관련 AWS 서비스 생각하기

3. 선택지 분석하기

 

바로 문제 풀이 시작합니다.

문제1

소매 회사는 퍼블릭 REST API에 지역 Amazon API Gateway API를 사용합니다. API Gateway 엔드포인트는 Amazon Route 53 별칭 레코드를 가리키는 사용자 지정 도메인 이름입니다. 솔루션 아키텍트는 고객에게 최소한의 영향을 미치고 데이터 손실을 최소화하는 솔루션을 생성하여 새 버전의 API를 릴리스해야 합니다.

이러한 요구 사항을 충족하는 솔루션은 무엇입니까? 

 

선택지

A. API 게이트웨이에 대한 카나리아 릴리스 배포 단계를 생성합니다. 최신 API 버전을 배포합니다. 트래픽의 적절한 비율을 카나리아 단계로 지정합니다. API 검증 후 카나리아 단계를 프로덕션 단계로 승격합니다.

B. OpenAPI YAML 파일 형식의 새 API 버전으로 새 API 게이트웨이 엔드포인트를 생성합니다. API Gateway의 API에 병합 모드에서 가져오기-업데이트 작업을 사용합니다. API의 새 버전을 프로덕션 단계에 배포합니다.

C. OpenAPI JSON 파일 형식의 새 API 버전으로 새 API 게이트웨이 엔드포인트를 생성합니다. 덮어쓰기 모드에서 업데이트로 가져오기 작업을 API Gateway의 API에 사용합니다. API의 새 버전을 프로덕션 단계에 배포합니다.

D. API 정의의 새 버전으로 새 API 게이트웨이 엔드포인트를 생성합니다. 새 API Gateway API에 대한 사용자 지정 도메인 이름을 생성합니다. Route 53 별칭 레코드가 새 API Gateway API 사용자 지정 도메인 이름을 가리키도록 합니다.

풀이

문제는 고객 영향을 최소화하고 데이터 손실 없이 새 API 버전을 점진적으로 배포하는 방법을 요구합니다. API Gateway의 카나리아 릴리스 배포는 트래픽의 일부만 새 버전으로 라우팅하여 안전하게 검증한 후 전체 배포를 진행하기 때문에 배포 위험을 최소화할 수 있습니다.

 

정답 : A

 

▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

더보기

1.  문제의 요구사항 분석하기

  • 새 버전의 REST API를 안전하게 릴리스해야 함
  • 고객에게 최소한의 영향을 주어야 함
  • 데이터 손실을 최소화해야 함
  • 기존 사용자 지정 도메인 이름과 Route 53 구성을 유지해야 함

2. 관련 AWS 서비스 생각하기

  • Amazon API Gateway : API를 빌드, 배포, 실행 및 모니터링할 수 있는 완전관리형 서비스입니다.
    • API Gateway 카나리아 배포 : 새로운 API 버전을 프로덕션 환경에 점진적으로 배포하는 방법입니다. 카나리아 배포 단계를 생성하면 전체 트래픽 중 일부(예: 10%)만 새 버전으로 라우팅하고 나머지는 기존 버전으로 유지됩니다. 이를 통해 새 버전의 안정성을 실제 프로덕션 트래픽으로 검증할 수 있으며, 문제 발생 시 즉시 카나리아 단계를 제거하여 롤백할 수 있습니다. 검증이 완료되면 카나리아 단계를 프로덕션 단계로 승격시켜 모든 트래픽이 새 버전을 사용하도록 전환합니다.
    • API Gateway의 가져오기 작업은 OpenAPI 정의 파일을 사용하여 API를 생성하거나 업데이트하는 기능입니다. 병합 모드는 기존 API 정의에 새로운 요소를 추가하면서 기존 설정을 유지하지만, 덮어쓰기 모드는 기존 API 정의를 완전히 교체합니다. 그러나 이 방법들은 즉시 전체 트래픽에 변경사항을 적용하므로 점진적 배포나 롤백이 어렵습니다.
  • Route 53 별칭 레코드 : AWS 리소스를 가리키는 DNS 레코드로, API Gateway 사용자 지정 도메인 이름과 연결됩니다. 별칭 레코드를 변경하면 DNS 전파 시간이 필요하고, 문제 발생 시 롤백에도 시간이 소요되어 고객 영향이 클 수 있습니다.

3. 선택지 분석하기

A. API 게이트웨이에 대한 카나리아 릴리스 배포 단계를 생성합니다. 최신 API 버전을 배포합니다. 트래픽의 적절한 비율을 카나리아 단계로 지정합니다. API 검증 후 카나리아 단계를 프로덕션 단계로 승격합니다.

→ 점진적 배포로 위험 최소화하고 즉시 롤백 가능하여 고객 영향과 데이터 손실을 최소화할 수 있습니다.

 

B. OpenAPI YAML 파일 형식의 새 API 버전으로 새 API 게이트웨이 엔드포인트를 생성합니다. API Gateway의 API에 병합 모드에서 가져오기-업데이트 작업을 사용합니다. API의 새 버전을 프로덕션 단계에 배포합니다.

→ 즉시 전체 배포되어 점진적 검증 불가능하고, 문제 발생 시 빠른 롤백이 어렵습니다.

 

C. OpenAPI JSON 파일 형식의 새 API 버전으로 새 API 게이트웨이 엔드포인트를 생성합니다. 덮어쓰기 모드에서 업데이트로 가져오기 작업을 API Gateway의 API에 사용합니다. API의 새 버전을 프로덕션 단계에 배포합니다.

→ 덮어쓰기 모드로 기존 설정 손실 위험이 있고, 전체 즉시 배포로 고객에게 큰 영향을 줄 수 있습니다.

 

D. API 정의의 새 버전으로 새 API 게이트웨이 엔드포인트를 생성합니다. 새 API Gateway API에 대한 사용자 지정 도메인 이름을 생성합니다. Route 53 별칭 레코드가 새 API Gateway API 사용자 지정 도메인 이름을 가리키도록 합니다.

→ DNS 전파 시간 필요하고 즉시 전체 전환되어 점진적 검증 불가능합니다.

 

이어서 다음 문제입니다.

문제2

회사에서 AWS에 새로운 퍼블릭 웹 애플리케이션을 배포하고 있습니다. 애플리케이션은 ALB(Application Load Balancer) 뒤에서 실행됩니다. 외부 인증 기관(CA)에서 발급한 SSL/TLS 인증서를 사용하여 엣지에서 애플리케이션을 암호화해야 합니다. 인증서는 만료되기 전에 매년 교체해야 합니다.

솔루션 설계자는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까? 

 

선택지

A. AWS Certificate Manager(ACM)를 사용하여 SSL/TLS 인증서를 발급합니다. ALB에 인증서를 적용합니다. 관리형 갱신 기능을 사용하여 인증서를 자동으로 교체하십시오.

B. AWS Certificate Manager(ACM)를 사용하여 SSL/TLS 인증서를 발급합니다. 인증서에서 키 자료를 가져옵니다. 인증서를 AL에 적용관리형 갱신 기능을 사용하여 인증서를 자동으로 교체하십시오.

C. AWS Certificate Manager(ACM) 사설 인증 기관을 사용하여 루트 CA에서 SSL/TLS 인증서를 발급합니다. ALB에 인증서를 적용합니다. 관리형 갱신 기능을 사용하여 인증서를 자동으로 교체하십시오.

D. AWS Certificate Manager(ACM)를 사용하여 SSL/TLS 인증서를 가져옵니다. ALB에 인증서를 적용합니다. 인증서 만료가 가까워지면 Amazon EventBridge(Amazon CloudWatch Events)를 사용하여 알림을 보냅니다. 인증서를 수동으로 교체하십시오.

풀이

문제는 외부 CA에서 발급한 인증서를 사용해야 하므로 ACM에서 직접 발급할 수 없고, 외부 인증서를 ACM으로 가져와야 합니다. ACM으로 가져온 인증서는 자동 갱신이 지원되지 않으므로, EventBridge를 통해 만료 알림을 받아 수동으로 교체하는 방법만 가능합니다.

 

정답 : D

 

▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

더보기

1.  문제의 요구사항 분석하기

  • 퍼블릭 웹 애플리케이션을 ALB 뒤에서 실행
  • 외부 인증 기관에서 발급한 SSL/TLS 인증서를 사용해야 함
  • 엣지에서 암호화 적용 필요
  • 인증서는 만료 전 매년 교체해야 함

2. 관련 AWS 서비스 생각하기

  • AWS Certificate Manager(ACM) : SSL/TLS 인증서를 관리하는 서비스로 두 가지 방식을 제공합니다.
    • 첫째, ACM에서 직접 퍼블릭 인증서를 발급하는 방식은 Amazon의 신뢰 체인을 사용하며 자동 갱신을 지원합니다. 이 경우 도메인 소유권 검증(DNS 또는 이메일)만 완료하면 무료로 인증서를 사용할 수 있고, 만료 60일 전부터 자동으로 갱신을 시도합니다.
    • 둘째, 외부 CA에서 발급받은 인증서를 ACM으로 가져오는 방식입니다. 이 경우 인증서 파일, 프라이빗 키, 인증서 체인을 함께 업로드해야 하며, ACM이 인증서를 안전하게 저장하고 ALB 등의 AWS 서비스에 배포할 수 있습니다. 그러나 가져온 인증서는 자동 갱신이 지원되지 않습니다.
  • ACM Private CA : 조직 내부에서 사용하는 프라이빗 인증서를 발급하기 위한 관리형 프라이빗 CA 서비스입니다. 자체 루트 CA를 생성하고 내부 애플리케이션용 인증서를 발급할 수 있지만, 퍼블릭 웹 애플리케이션에는 적합하지 않습니다. 외부 사용자의 브라우저가 이 프라이빗 CA를 신뢰하지 않기 때문에 인증서 경고가 발생합니다.
  • Amazon EventBridge(구 CloudWatch Events) : AWS 리소스의 상태 변화를 감지하고 이벤트 기반 작업을 수행하는 서비스입니다. ACM은 인증서 만료 45일, 30일, 15일, 7일, 3일, 1일 전에 자동으로 EventBridge 이벤트를 발생시킵니다. 이 이벤트를 SNS, Lambda 등과 연결하여 알림을 받거나 자동화된 작업을 수행할 수 있습니다.

3. 선택지 분석하기

A. AWS Certificate Manager(ACM)를 사용하여 SSL/TLS 인증서를 발급합니다. ALB에 인증서를 적용합니다. 관리형 갱신 기능을 사용하여 인증서를 자동으로 교체하십시오.

→ ACM 발급 인증서는 Amazon CA를 사용하므로 외부 CA 요구사항을 충족하지 못합니다.

 

B. AWS Certificate Manager(ACM)를 사용하여 SSL/TLS 인증서를 발급합니다. 인증서에서 키 자료를 가져옵니다. 인증서를 AL에 적용관리형 갱신 기능을 사용하여 인증서를 자동으로 교체하십시오.

→ ACM 발급 인증서는 외부 CA가 아니며, 설명이 논리적으로 모순됩니다.

 

C. AWS Certificate Manager(ACM) 사설 인증 기관을 사용하여 루트 CA에서 SSL/TLS 인증서를 발급합니다. ALB에 인증서를 적용합니다. 관리형 갱신 기능을 사용하여 인증서를 자동으로 교체하십시오.

→ 프라이빗 CA는 퍼블릭 웹 애플리케이션에 부적합하고 외부 사용자가 신뢰하지 않습니다.

 

D. AWS Certificate Manager(ACM)를 사용하여 SSL/TLS 인증서를 가져옵니다. ALB에 인증서를 적용합니다. 인증서 만료가 가까워지면 Amazon EventBridge(Amazon CloudWatch Events)를 사용하여 알림을 보냅니다. 인증서를 수동으로 교체하십시오.

→ 외부 CA 인증서를 가져오고 EventBridge로 만료 알림을 받아 수동 교체 가능합니다.

 

마지막 문제 살펴보겠습니다.

문제3

회사는 Amazon Elastic Kubernetes Service(Amazon EKS)를 사용하여 컨테이너 애플리케이션을 실행합니다. EKS 클러스터는 Kubernetes 비밀 객체에 민감한 정보를 저장합니다. 회사는 정보가 암호화되었는지 확인하려고 합니다.

최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까? 

 

선택지

A. 컨테이너 애플리케이션을 사용하여 AWS Key Management Service(AWS KMS)를 사용하여 정보를 암호화합니다.

B. AWS Key Management Service(AWS KMS)를 사용하여 EKS 클러스터에서 비밀 암호화를 활성화합니다.

C. AWS KMS(AWS Key Management Service)를 사용하여 정보를 암호화하는 AWS Lambda 함수를 구현합니다.

D. AWS Systems Manager Parameter Store를 사용하여 AWS Key Management Service(AWS KMS)를 사용하여 정보를 암호화합니다.

풀이

EKS 클러스터의 Kubernetes 비밀 객체를 암호화하려면 EKS의 내장 기능인 비밀 암호화 기능을 활성화하는 것이 가장 간단합니다. EKS는 AWS KMS와 통합되어 etcd에 저장되는 Kubernetes Secret을 자동으로 암호화할 수 있으며, 별도의 애플리케이션 코드 변경이나 추가 인프라 구성 없이 클러스터 레벨에서 설정만으로 해결됩니다.

 

정답 : B

 

▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

더보기

1.  문제의 요구사항 분석하기

  • EKS 클러스터에서 실행 중인 컨테이너 애플리케이션 환경
  • Kubernetes Secret 객체에 저장된 민감한 정보의 암호화 필요
  • 최소한의 운영 오버헤드로 구현해야 함
  • AWS KMS를 활용한 암호화 솔루션 구성

2. 관련 AWS 서비스 생각하기

  • Amazon EKS(Elastic Kubernetes Service) : AWS에서 제공하는 관리형 Kubernetes 서비스입니다. EKS는 Kubernetes 비밀 암호화를 지원하여 시크릿에 저장된 민감한 데이터를 보호할 수 있습니다. AWS KMS(Key Management Service)와 통합되어 있어 AWS 관리형 키 또는 고객 관리형 키로 암호화가 가능합니다.
    • Amazon EKS Secret 암호화 : EKS 클러스터 생성 시 또는 기존 클러스터에서 KMS 키를 지정하여 etcd에 저장되는 Kubernetes Secret을 자동으로 암호화하는 기능입니다. 클러스터의 암호화 구성에서 KMS 키 ARN을 지정하면 모든 Secret 객체가 저장 시 자동으로 암호화되며, 애플리케이션 코드 변경 없이 투명하게 작동합니다.
    • AWS KMS : 암호화 키를 생성하고 관리하는 관리형 서비스로, EKS와 통합되어 Secret 암호화에 사용되는 고객 관리형 키를 제공합니다. 키 회전, 액세스 제어, 감사 로깅 기능을 제공하며, EKS가 자동으로 KMS API를 호출하여 암호화 및 복호화를 수행합니다.
    • Kubernetes Secret : 컨테이너에서 사용하는 비밀번호, 토큰, 키 등의 민감한 정보를 저장하는 Kubernetes 네이티브 객체입니다. 기본적으로 etcd에 base64 인코딩되어 저장되지만 암호화되지 않으며, EKS의 Secret 암호화 기능을 활성화하면 etcd 레벨에서 암호화됩니다.
    • etcd : Kubernetes 클러스터의 모든 상태 정보를 저장하는 분산 키-값 저장소로, Secret을 포함한 모든 클러스터 데이터가 저장됩니다. EKS Secret 암호화는 이 etcd 저장 계층에서 데이터를 암호화하여 저장 시 암호화를 구현합니다.
  • AWS Lambda : 서버리스 컴퓨팅 서비스로, 이벤트 기반으로 코드를 실행할 수 있습니다. 민감한 데이터를 암호화하기 위해 Lambda 함수를 직접 구현할 수 있지만, 이는 운영 오버헤드가 증가하므로 바람직하지 않습니다.
  • AWS Systems Manager Parameter Store : 구성 데이터 관리 서비스로, 중요한 데이터를 안전하게 저장하고 검색할 수 있습니다. 데이터를 KMS 키로 암호화할 수 있지만, EKS 시크릿 암호화를 위한 서비스는 아닙니다.

3. 선택지 분석하기

A. 컨테이너 애플리케이션을 사용하여 AWS Key Management Service(AWS KMS)를 사용하여 정보를 암호화합니다.

→ 애플리케이션 레벨에서 직접 암호화 구현이 필요한 과정이므로, 코드 변경 필요하여 운영 오버헤드가 큽니다.

 

B. AWS Key Management Service(AWS KMS)를 사용하여 EKS 클러스터에서 비밀 암호화를 활성화합니다.

→ EKS 내장 기능으로 클러스터 설정만으로 자동 암호화합니다. 최소 운영 오버헤드로 요구사항 충족합니다.

 

C. AWS KMS(AWS Key Management Service)를 사용하여 정보를 암호화하는 AWS Lambda 함수를 구현합니다.

→ Lambda 함수 개발 및 관리가 필요하고, Secret 관리 워크플로우 변경 필요하여 오버헤드 큽니다.

 

D. AWS Systems Manager Parameter Store를 사용하여 AWS Key Management Service(AWS KMS)를 사용하여 정보를 암호화합니다.

→ Kubernetes Secret 대신 Parameter Store 를 사용하기 때문에 애플리케이션 코드 변경 필요하여 오버헤드가 방법입니다.

 

그럼 저희는 다음 주에 뵙겠습니다.

힘내서 마지막 스퍼트, 함께해요! 🚀

저작자표시 (새창열림)

'AWS > SAA 준비' 카테고리의 다른 글

AWS SAA 합격으로 가는 길 #144  (1) 2025.12.26
AWS SAA 합격으로 가는 길 #143  (0) 2025.12.22
AWS SAA 합격으로 가는 길 #141  (0) 2025.12.15
AWS SAA 합격으로 가는 길 #140  (0) 2025.12.12
AWS SAA 합격으로 가는 길 #139  (1) 2025.12.08

관련글

티스토리툴바