AWS SAA 합격으로 가는 길 #71

안녕하세요, NxtCloud SA 이수민입니다. AWS SAA 자격증 준비를 위한 실전 문제 풀이를 진행하겠습니다. 문제를 함께 다루며 AWS 서비스에 대한 이해도를 높이는 시간이 되길 바랍니다.

 

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

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

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

3. 선택지 분석하기

 

바로 문제 풀이 해보겠습니다!

---

문제1

회사에는 Amazon EC2 인스턴스에서 실행되는 레거시 데이터 처리 애플리케이션이 있습니다. 데이터는 순차적으로 처리되지만 결과의 순서는 중요하지 않습니다. 응용 프로그램은 모놀리식 아키텍처를 사용합니다. 회사에서 수요 증가에 맞춰 애플리케이션을 확장할 수 있는 유일한 방법은 인스턴스 크기를 늘리는 것입니다.
이 회사의 개발자는 Amazon Elastic Container Service(Amazon ECS)에서 마이크로서비스 아키텍처를 사용하도록 애플리케이션을 다시 작성하기로 결정했습니다.
솔루션 설계자는 마이크로서비스 간의 통신을 위해 무엇을 권장해야 합니까?

 

선택지

A. Amazon Simple Queue Service(Amazon SQS) 대기열을 생성합니다. 데이터 생산자에 코드를 추가하고 데이터를 대기열로 보냅니다. 데이터 소비자에 코드를 추가하여 대기열의 데이터를 처리합니다.

B. Amazon Simple Notification Service(Amazon SNS) 주제를 생성합니다. 데이터 생산자에 코드를 추가하고 주제에 알림을 게시합니다. 데이터 소비자에 코드를 추가하여 주제를 구독합니다.

C. 메시지를 전달할 AWS Lambda 함수를 생성합니다. 데이터 생산자에 코드를 추가하여 데이터 객체로 Lambda 함수를 호출합니다. 데이터 소비자에 코드를 추가하여 Lambda 함수에서 전달되는 데이터 객체를 수신합니다.

D. Amazon DynamoDB 테이블을 생성합니다. DynamoDB 스트림을 활성화합니다. 데이터 생산자에 코드를 추가하여 테이블에 데이터를 삽입합니다. 데이터 소비자에 코드를 추가하여 DynamoDB Streams API를 사용하여 새 테이블 항목을 감지하고 데이터를 검색합니다.

 

풀이

레거시 애플리케이션을 마이크로서비스 아키텍처로 전환하면서 마이크로서비스 간 통신 방식을 결정해야 하는 상황입니다.

 

정답 : A

 

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

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

• 레거시 애플리케이션을 마이크로서비스 아키텍처로 전환하려 함
• 데이터는 순차적으로 처리되지만 결과 순서는 중요하지 않음
• 마이크로서비스 간 통신 방식 결정 필요

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

• Amazon SQS(Simple Queue Service)는 분산 애플리케이션을 위한 메시징 대기열 서비스로, 메시지 전달 및 순서 보장, 중복 제거, 메시지 보존 기능을 제공합니다. 대기열은 생산자와 소비자 간의 결합도를 낮추어 애플리케이션 구성 요소를 독립적으로 배포하고 확장할 수 있게 해줍니다.
• Amazon SNS(Simple Notification Service)는 발행-구독(pub-sub) 메시징 서비스로, 메시지 발행자가 여러 구독자에게 메시지를 동시에 전달할 수 있습니다. 주로 일대다 통신 패턴에 적합합니다.
• AWS Lambda는 서버리스 컴퓨팅 서비스로, 코드를 실행하지만 마이크로서비스 간 통신에 직접 사용하면 결합도가 높아집니다.
• Amazon DynamoDB는 NoSQL 데이터베이스 서비스로, DynamoDB Streams를 통해 데이터 변경 이벤트를 캡처할 수 있지만 주요 목적은 데이터 저장입니다.

3. 선택지 분석하기

A. Amazon SQS 대기열을 생성하고 데이터 생산자와 소비자 간 통신에 활용

→ SQS는 마이크로서비스 간 비동기 통신에 적합하며, 생산자와 소비자 간 결합도를 낮추어 확장성을 제공합니다. 또한 메시지가 대기열에 저장되므로 일시적인 서비스 장애에도 데이터 손실 없이 처리할 수 있습니다.

 

B. Amazon SNS 주제를 생성하고 발행-구독 패턴 활용

→ SNS는 일대다 통신에 적합하지만, 메시지가 지속적으로 저장되지 않고 구독자가 오프라인 상태인 경우 메시지가 손실될 수 있습니다.

 

C. AWS Lambda 함수를 직접 호출하여 데이터 전달

→ Lambda 함수를 직접 호출하는 방식은 마이크로서비스 간 결합도가 높아져 확장성과 유연성이 제한됩니다.

 

D. DynamoDB 테이블과 스트림을 활용한 데이터 전달

→ DynamoDB와 스트림을 사용하면 통신 지연이 발생할 수 있으며, 주요 목적이 데이터 저장인 서비스를 통신에 활용하는 것은 오버헤드가 큽니다.

 

이어서 다음 문제입니다.

---

문제2

회사는 사용자 요청을 수집하고 요청 유형에 따라 처리를 위해 적절한 마이크로 서비스에 요청을 발송하는 데 사용되는 비동기 API를 소유하고 있습니다. 이 회사는 Amazon API Gateway를 사용하여 API 프런트 엔드를 배포하고 Amazon DynamoDB를 호출하여 사용자 요청을 처리 마이크로서비스로 보내기 전에 저장하는 AWS Lambda 함수를 사용하고 있습니다.
회사는 예산이 허용하는 한 많은 DynamoDB 처리량을 프로비저닝했지만 회사는 여전히 가용성 문제를 겪고 있으며 사용자 요청이 손실되고 있습니다.
솔루션 설계자는 기존 사용자에게 영향을 주지 않고 이 문제를 해결하기 위해 무엇을 해야 합니까?

 

선택지

A. API 게이트웨이에서 서버 측 조절 제한을 사용하여 조절을 추가합니다.

B. DynamoDB Accelerator(DAX) 및 Lambda를 사용하여 DynamoDB에 대한 쓰기를 버퍼링합니다.

C. 사용자 요청이 있는 테이블에 대해 DynamoDB에서 보조 인덱스를 생성합니다.

D. Amazon Simple Queue Service(Amazon SQS) 대기열과 Lambda를 사용하여 DynamoDB에 대한 쓰기를 버퍼링합니다.

 

풀이

API Gateway와 Lambda를 통해 DynamoDB에 사용자 요청을 저장하는 과정에서 처리량 제한으로 인해 요청이 손실되는 문제가 발생하고 있습니다.

 

정답 : D

 

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

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

• 비동기 API가 사용자 요청을 수집하고 처리 마이크로서비스로 전달함
• API Gateway, Lambda, DynamoDB를 사용하는 아키텍처
• DynamoDB 처리량을 최대로 프로비저닝했지만 여전히 가용성 문제 발생
• 사용자 요청이 손실되는 문제 해결 필요
• 기존 사용자에게 영향을 주지 않는 솔루션 필요

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

• Amazon API Gateway는 REST API를 생성, 게시, 유지관리, 모니터링할 수 있는 서비스로, 요청 조절(throttling) 기능을 제공합니다.
• Amazon DynamoDB는 완전관리형 NoSQL 데이터베이스 서비스로, 프로비저닝된 처리량 모드에서는 읽기 및 쓰기 용량을 미리 설정해야 합니다.
• DynamoDB Accelerator(DAX)는 DynamoDB를 위한 완전관리형 인메모리 캐시로, 주로 읽기 성능 향상에 사용됩니다.
• Amazon SQS(Simple Queue Service)는 완전관리형 메시지 대기열 서비스로, 비동기 처리와 부하 분산에 적합합니다.

3. 선택지 분석하기

A. API Gateway에서 서버 측 조절 제한을 사용하여 조절 추가

→ 조절을 추가하면 요청 수를 제한하여 DynamoDB 부하를 줄일 수 있지만, 사용자 요청이 거부되어 손실될 수 있습니다.

 

B. DynamoDB Accelerator(DAX) 및 Lambda를 사용하여 DynamoDB 쓰기 버퍼링

→ DAX는 주로 읽기 캐싱에 효과적이며, 쓰기 작업에 대한 버퍼링 기능은 제한적입니다.

 

C. DynamoDB에서 사용자 요청 테이블에 대한 보조 인덱스 생성

→ 보조 인덱스는 쿼리 효율성을 높이지만 쓰기 처리량 문제는 해결하지 못합니다.

 

D. Amazon SQS 대기열과 Lambda를 사용하여 DynamoDB 쓰기 버퍼링

→ SQS 대기열을 사용하면 요청을 일시적으로 저장하고 Lambda가 DynamoDB의 가용 처리량에 맞춰 점진적으로 처리할 수 있습니다. 이는 요청 손실을 방지하고 시스템 복원력을 높이는 효과적인 솔루션입니다.

 

마지막 문제 살펴볼게요.

---

문제3

회사에서 CompanyConfidential Amazon S3 버킷에 대한 액세스 권한이 없어야 하는 새로운 클라우드 엔지니어를 채용했습니다. 클라우드 엔지니어는 AdminTools라는 S3 버킷에 대한 읽기 및 쓰기 권한이 있어야 합니다. 이러한 기준을 충족하는 IAM 정책은 무엇입니까?

 

선택지

A.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3::AdminTools*"
},
{
"Effect": "Allow",
"Action": [ "s3:GetObject", "s3:PutObject" ],
"Resource": "arn:aws:s3::AdminTools/*"
},
{
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"arn:aws:s3::CompanyConfidential/*",
"arn:aws:s3::CompanyConfidential"
]
}
]
}

B.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": [
"arn:aws:s3::AdminTools*",
"arn:aws:s3::CompanyConfidential/*"
]
},
{
"Effect": "Allow",
"Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ],
"Resource": "arn:aws:s3::AdminTools/*"
},
{
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3::CompanyConfidential"
}
]
}

C.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [ "s3:GetObject", "s3:PutObject" ],
"Resource": "arn:aws:s3::AdminTools/*"
},
{
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"arn:aws:s3::CompanyConfidential/*",
"arn:aws:s3::CompanyConfidential"
]
}
]
}

D.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3::AdminTools/*"
},
{
"Effect": "Allow",
"Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ],
"Resource": "arn:aws:s3::AdminTools/"
},
{
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"arn:aws:s3::CompanyConfidential",
"arn:aws:s3::CompanyConfidential/*",
"arn:aws:s3::AdminTools/*"
]
}
]
}

 

 

풀이

IAM 정책을 통해 새로운 클라우드 엔지니어에게 적절한 S3 버킷 접근 권한을 부여해야 합니다.

 

정답 : A

 

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

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

• 새로운 클라우드 엔지니어는 CompanyConfidential S3 버킷에 액세스할 수 없어야 함
• AdminTools S3 버킷에 대한 읽기 및 쓰기 권한 필요
• 이를 충족하는 IAM 정책 선택

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

• AWS Identity and Access Management(IAM)는 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 서비스입니다.
• IAM 정책은 JSON 형식으로 작성되며 Allow(허용) 또는 Deny(거부) 효과를 갖는 명시적 권한을 설정할 수 있습니다.
• S3 권한은 버킷 수준과 객체 수준으로 나누어 관리할 수 있으며, ListBucket은 버킷 목록 조회, GetObject는 객체 읽기, PutObject는 객체 쓰기 권한을 제공합니다.
• IAM 정책 평가에서 Deny는 Allow보다 우선 적용됩니다.

3. 선택지 분석하기

A. AdminTools 버킷에 대한 ListBucket, GetObject, PutObject 권한을 허용하고 CompanyConfidential 버킷에 대한 모든 권한을 거부

→ 이 정책은 AdminTools 버킷에 대한 목록 조회, 읽기, 쓰기 권한을 부여하면서 CompanyConfidential 버킷과 객체에 대한 모든 액세스를 명시적으로 거부합니다. 요구사항을 정확히 충족합니다.

 

B. CompanyConfidential 버킷 내 객체에 대한 ListBucket 권한을 허용하며 버킷 자체에만 Deny 설정

→ 이 정책은 CompanyConfidential/* 리소스에 대한 ListBucket 권한을 허용하고 있어 일부 액세스가 가능합니다. 또한 CompanyConfidential 버킷 내 객체에 대한 액세스를 거부하지 않습니다.

 

C. AdminTools 버킷에 객체 권한만 부여하고 ListBucket 권한 누락

→ 이 정책은 AdminTools 버킷의 객체에 대한 읽기 및 쓰기 권한만 부여하고 버킷 목록 조회(ListBucket) 권한이 누락되어 있습니다.

 

D. AdminTools 버킷과 객체 모두에 Deny 설정

→ 이 정책은 마지막 문장에서 AdminTools/* 리소스에 대한 모든 액세스를 거부하고 있어 AdminTools 버킷에 대한 권한을 부여하지 않습니다.

 

감사합니다!