본문 바로가기
AWS/SAA 준비

AWS SAA 합격으로 가는 길 #90

by Pacloud 2025. 6. 9.
반응형

안녕하세요! 넥스트클라우드의 SA 손유림입니다. 😊 자격증 학습은 문제 풀이 전략이 필요합니다. 함께 알아보시죠!

 

문제는  가지 단계를 거치며 풀어 나갈 거예요.

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

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

3. 선택지 분석하기

 

바로 문제 풀이 해볼까요?


문제1

회사는 3계층 상태 비저장 웹 애플리케이션을 위한 백업 전략이 필요합니다. 웹 애플리케이션은 조정 이벤트에 응답하도록 구성된 동적 조정 정책이 있는 Auto Scaling 그룹의 Amazon EC2 인스턴스에서 실행됩니다. 데이터베이스 계층은 PostgreSQL용 Amazon RDS에서 실행됩니다. 웹 애플리케이션은 EC2 인스턴스에 임시 로컬 스토리지가 필요하지 않습니다. 회사 의 복구 지점 목표(RPO)는 2시간입니다. 백업 전략은 확장성을 최대화하고 이 환경에 대한 리소스 활용을 최적화해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. RPO를 충족하기 위해 2시간마다 EC2 인스턴스 및 데이터베이스의 Amazon Elastic Block Store(Amazon EBS) 볼륨의 스냅샷을 생성합니다.

B. Amazon Elastic Block Store(Amazon EBS) 스냅샷을 생성하도록 스냅샷 수명 주기 정책을 구성합니다. RPO를 충족하기 위해 Amazon RDS에서 자동 백업을 활성화합니다.

C. 웹 및 애플리케이션 계층의 최신 Amazon 머신 이미지(AMI)를 유지합니다. Amazon RDS에서 자동 백업을 활성화하고 지정 시간 복구를 사용하여 RPO를 충족합니다.

D. 2시간마다 EC2 인스턴스의 Amazon Elastic Block Store(Amazon EBS) 볼륨의 스냅샷을 생성합니다. Amazon RDS에서 자동 백업을 활성화하고 지정 시간 복구를 사용하여 RPO를 충족합니다.


풀이

웹 애플리케이션에 적합한 백업 전략은 Amazon EBS 스냅샷과 Amazon RDS 자동 백업을 결합하는 것입니다. 상태 비저장 웹 애플리케이션의 경우 EC2 인스턴스에는 영구 스토리지가 필요하지 않으므로 EBS 스냅샷만으로 충분합니다. 그리고 RDS 자동 백업을 사용하면 데이터베이스 계층의 백업도 가능하며, 지정 시간 복구 기능을 통해 RPO 2시간 요구사항도 충족할 수 있습니다.

정답 : C

 

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

더보기

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

  • 상태 비저존 웹 애플리케이션을 위한 백업 전략 필요
  • 확장성과 리소스 활용 최적화 필요
  • RPO(복구 지점 목표) 2시간

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

EC2는 가상 컴퓨팅 환경을 제공하는 웹 서비스로, 필요에 따라 쉽게 확장할 수 있습니다. EC2 인스턴스에 연결된 EBS(Elastic Block Store) 볼륨은 스냅샷을 통해 백업이 가능합니다. EBS는 EC2 인스턴스에 영구 스토리지를 제공하는 블록 수준 스토리지 서비스입니다. EBS 스냅샷을 통해 데이터를 백업할 수 있으며, 스냅샷 수명 주기 정책을 구성하여 자동화할 수 있습니다.

 

RDS는 관계형 데이터베이스를 클라우드에서 간편하게 설치, 운영 및 확장할 수 있게 해주는 웹 서비스입니다. 자동 백업 기능을 제공하여 데이터베이스 백업이 가능하며, 지정 시간 복구(Point-in-Time Recovery) 기능을 통해 특정 시점의 데이터로 복구할 수 있습니다.

3. 선택지 분석하기

A. RPO를 충족하기 위해 2시간마다 EC2 인스턴스 및 데이터베이스의 Amazon Elastic Block Store(Amazon EBS) 볼륨의 스냅샷을 생성합니다.

→ RPO 2시간을 충족하기 위해 2시간마다 EC2 인스턴스 및 데이터베이스의 EBS 볼륨 스냅샷을 생성하는 방식은 RDS 백업이 누락되어 부적절합니다.

 

B. Amazon Elastic Block Store(Amazon EBS) 스냅샷을 생성하도록 스냅샷 수명 주기 정책을 구성합니다. RPO를 충족하기 위해 Amazon RDS에서 자동 백업을 활성화합니다.

→ EBS 스냅샷을 위한 수명 주기 정책과 RDS 자동 백업을 병행하는 방식입니다. 하지만 RDS 자동 백업만으로는 RPO 2시간 요구사항을 만족하지 못합니다.

 

C. 웹 및 애플리케이션 계층의 최신 Amazon 머신 이미지(AMI)를 유지합니다. Amazon RDS에서 자동 백업을 활성화하고 지정 시간 복구를 사용하여 RPO를 충족합니다.

→ 상태 비저장 애플리케이션에 최적화된 AMI 백업과 RDS 자동 백업, 지정 시간 복구를 활용하여 RPO 요구사항과 확장성을 모두 만족하는 방식입니다.

 

D. 2시간마다 EC2 인스턴스의 Amazon Elastic Block Store(Amazon EBS) 볼륨의 스냅샷을 생성합니다. Amazon RDS에서 자동 백업을 활성화하고 지정 시간 복구를 사용하여 RPO를 충족합니다.

→ EC2 EBS 스냅샷과 RDS 자동 백업을 활용하는 방식이지만, 상태 비저장 애플리케이션에서 개별 인스턴스 EBS 스냅샷은 불필요한 오버헤드로 확장성과 리소스 최적화 요구사항을 만족하지 못합니다.

 

이어서 다음 문제입니다.


문제2

회사는 AWS에서 애플리케이션을 호스팅합니다. 이 회사는 Amazon Cognito를 사용하여 사용자를 관리합니다. 사용자가 애플리케이션에 로그인하면 애플리케이션은 Amazon API Gateway에서 호스팅되는 REST API를 사용하여 Amazon DynamoDB에서 필요한 데이터를 가져옵니다. 이 회사는 개발 노력을 줄이기 위해 REST API에 대한 액세스를 제어하는 AWS 관리형 솔루션을 원합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. 어떤 사용자가 요청했는지 확인하기 위해 API Gateway에서 권한 부여자가 되도록 AWS Lambda 함수를 구성합니다.

B. 각 사용자에 대해 각 요청과 함께 전송되어야 하는 API 키를 생성하고 할당합니다. AWS Lambda 함수를 사용하여 키를 검증합니다.

C. 모든 요청과 함께 헤더에 사용자의 이메일 주소를 보냅니다. 해당 이메일 주소를 가진 사용자에게 적절한 액세스 권한이 있는지 확인하려면 AWS Lambda 함수를 호출하십시오.

D. Amazon Cognito가 각 요청을 검증할 수 있도록 API Gateway에서 Amazon Cognito 사용자 풀 권한 부여자를 구성합니다.


풀이

Amazon Cognito 사용자 풀 권한 부여자를 API Gateway에 설정하면, Cognito를 통해 인증된 사용자만 REST API에 액세스할 수 있게 됩니다. 이렇게 하면 API에 대한 액세스 제어를 완전 관리형 서비스로 처리할 수 있어 운영 오버헤드를 최소화할 수 있습니다.

정답 : D

 

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

더보기

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

  • Cognito를 사용하여 사용자 관리
  • API Gateway에서 호스팅되는 REST API를 통해 DynamoDB 데이터 조회

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

Cognito는 웹 및 모바일 앱에 간편한 사용자 가입, 로그인 및 액세스 제어를 제공하는 인증 서비스입니다. 사용자 풀(User Pool)을 통해 사용자 디렉터리를 관리할 수 있으며, 자격 증명 풀(Identity Pool)을 통해 AWS 리소스에 대한 액세스 권한을 관리할 수 있습니다.

 

API Gateway는 백엔드 서비스의 안전하고 효율적인 제어를 지원하는 완전관리형 서비스입니다. API 요청을 받아 백엔드 리소스로 라우팅하고, 다양한 유형의 권한 부여자를 지원합니다. Amazon Cognito 사용자 풀 권한 부여자를 설정하면 Cognito를 통해 인증된 사용자만 API에 액세스할 수 있습니다.

3. 선택지 분석하기

A. 어떤 사용자가 요청했는지 확인하기 위해 API Gateway에서 권한 부여자가 되도록 AWS Lambda 함수를 구성합니다.

→ API Gateway에서 Lambda 함수 권한 부여자를 구성하는 방식은 직접 Lambda 함수를 개발해야 하므로 오버헤드가 큽니다.

 

B. 각 사용자에 대해 각 요청과 함께 전송되어야 하는 API 키를 생성하고 할당합니다. AWS Lambda 함수를 사용하여 키를 검증합니다.

→ API 키는 기본적으로 리소스 권한이 아닌 호출 레이트 제한 용도이므로 부적절합니다. 키 검증을 위한 Lambda 함수도 필요해 오버헤드가 발생합니다.

 

C. 모든 요청과 함께 헤더에 사용자의 이메일 주소를 보냅니다. 해당 이메일 주소를 가진 사용자에게 적절한 액세스 권한이 있는지 확인하려면 AWS Lambda 함수를 호출하십시오.

→ 사용자 이메일 헤더를 전송해서 Lambda 함수로 검증하는 방식은 커스텀 개발이 필요하므로 오버헤드가 큽니다.

 

D. Amazon Cognito가 각 요청을 검증할 수 있도록 API Gateway에서 Amazon Cognito 사용자 풀 권한 부여자를 구성합니다.

→ Cognito를 API Gateway의 권한 부여자로 설정하면 사용자 인증을 완전관리형으로 처리할 수 있어 운영 오버헤드가 최소화됩니다.

 

마지막 문제 살펴볼게요.


문제3

회사는 온프레미스 데이터 센터의 Kubernetes 클러스터에서 컨테이너화된 애플리케이션을 실행합니다. 회사는 데이터 저장을 위해 MongoDB 데이터베이스를 사용하고 있습니다. 회사는 이러한 환경 중 일부를 AWS로 마이그레이션하려고 하지만 현재로서는 코드 변경이나 배포 방법 변경이 불가능합니다. 회사는 운영 오버헤드를 최소화하는 솔루션이 필요합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

선택지

A. 컴퓨팅을 위해 Amazon EC2 작업자 노드와 함께 Amazon Elastic Container Service(Amazon ECS)를 사용하고 데이터 저장을 위해 EC2의 MongoDB를 사용합니다.

B. 컴퓨팅용 AWS Fargate 및 데이터 스토리지용 Amazon DynamoDB와 함께 Amazon Elastic Container Service(Amazon ECS) 사용

C. Amazon Elastic Kubernetes Service(Amazon EKS)를 Amazon EC2 작업자 노드와 함께 컴퓨팅용으로 사용하고 Amazon DynamoDB를 데이터 저장용으로 사용합니다.

D. 컴퓨팅용 AWS Fargate 및 데이터 스토리지용 Amazon DocumentDB(MongoDB 호환)와 함께 Amazon Elastic Kubernetes Service(Amazon EKS)를 사용합니다.


풀이

AWS Fargate와 Amazon EKS(Elastic Kubernetes Service), Amazon DocumentDB(MongoDB 호환 가능)를 결합하면 문제의 요구사항을 충족할 수 있습니다. EKS를 통해 온프레미스 Kubernetes 환경과 동일한 방식으로 컨테이너화된 애플리케이션을 실행할 수 있고, Fargate를 사용하면 별도의 서버 프로비저닝 없이 컨테이너를 실행할 수 있어 운영 오버헤드가 최소화됩니다. 또한 DocumentDB를 사용하면 기존 MongoDB 데이터베이스를 모든 코드 변경 없이 그대로 사용할 수 있습니다.

정답 : D

 

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

더보기

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

  • 온프레미스 Kubernetes 환경의 일부를 AWS로 마이그레이션
  • MongoDB 데이터베이스 그대로 활용
  • 코드 변경이나 배포 방식 변경 없이 마이그레이션

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

EKS는 관리형 Kubernetes 서비스로, 기존 Kubernetes 환경과 동일한 방식으로 컨테이너화된 애플리케이션을 배포하고 관리할 수 있습니다. 마스터 노드는 AWS에서 완전 관리하며, 사용자는 작업자 노드만 관리하면 됩니다.

 

Fargate는 서버 프로비저닝 없이 컨테이너를 실행할 수 있는 서버리스 컴퓨팅 엔진으로, ECS나 EKS와 결합하여 사용할 수 있습니다. 별도의 서버 관리가 필요 없어 운영 오버헤드를 최소화할 수 있습니다.

 

DocumentDB는 MongoDB와 호환되는 AWS 고유의 클라우드 네이티브 문서 데이터베이스 서비스입니다. MongoDB와 동일한 API를 사용하므로 코드 변경 없이 기존 애플리케이션을 마이그레이션할 수 있습니다.

3. 선택지 분석하기

A. 컴퓨팅을 위해 Amazon EC2 작업자 노드와 함께 Amazon Elastic Container Service(Amazon ECS)를 사용하고 데이터 저장을 위해 EC2의 MongoDB를 사용합니다.

→ ECS와 EC2 작업자 노드, EC2의 MongoDB를 사용하는 방식은 서버 관리 오버헤드가 있어 요구사항을 충족하지 못합니다.

 

B. 컴퓨팅용 AWS Fargate 및 데이터 스토리지용 Amazon DynamoDB와 함께 Amazon Elastic Container Service(Amazon ECS) 사용

→ ECS와 Fargate를 사용하지만, MongoDB 대신 DynamoDB를 사용해야 하므로 기존 코드 변경이 필요해 부적절합니다.

 

C. Amazon Elastic Kubernetes Service(Amazon EKS)를 Amazon EC2 작업자 노드와 함께 컴퓨팅용으로 사용하고 Amazon DynamoDB를 데이터 저장용으로 사용합니다.

→ EKS와 EC2 작업자 노드를 사용하지만 DynamoDB를 사용해야 하므로 기존 코드 변경이 필요해 부적절합니다.

 

D. 컴퓨팅용 AWS Fargate 및 데이터 스토리지용 Amazon DocumentDB(MongoDB 호환)와 함께 Amazon Elastic Kubernetes Service(Amazon EKS)를 사용합니다.

→ EKS와 Fargate를 사용하고, DocumentDB를 통해 코드 변경없이 MongoDB를 그대로 활용할 수 있어 모든 요구사항을 만족합니다.

 

 

끝까지 읽어주셔서 감사합니다. 꾸준한 학습이 합격을 만듭니다.

 

감사합니다. 다음 글에서 만나요! 😊

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

AWS SAA 합격으로 가는 길 #92  (0) 2025.06.16
AWS SAA 합격으로 가는 길 #91  (0) 2025.06.13
AWS SAA 합격으로 가는 길 #89  (0) 2025.06.06
AWS SAA 합격으로 가는 길 #88  (0) 2025.06.02
AWS SAA 합격으로 가는 길 #87  (1) 2025.05.30