안녕하세요! 넥스트클라우드의 테크니컬 트레이너 김서윤입니다. 🌸
벌써 4월이에요! 봄바람과 함께 오늘도 가볍게 문제 풀어봅시다.
문제는 세 가지 단계를 거치며 풀어가겠습니다.
1. 문제의 요구사항 분석하기
2. 관련 AWS 서비스 생각하기
3. 선택지 분석하기
바로 문제 풀이 시작합니다.
문제1
한 회사가 AWS에서 결제 애플리케이션을 실행하려고 합니다. 애플리케이션은 모바일 장치로부터 결제 알림을 받습니다. 결제 알림은 추가 처리를 위해 전송되기 전에 기본적인 확인이 필요합니다. 백엔드 처리 애플리케이션은 장기간 실행되며 컴퓨팅 및 메모리를 조정해야 합니다. 회사는 인프라 관리를 원하지 않습니다.
최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
선택지
A. Amazon Simple Queue Service(Amazon SQS) 대기열을 생성합니다. 대기열을 Amazon EventBridge 규칙과 통합하여 모바일 장치에서 결제 알림을 받습니다. 결제 알림을 검증하고 백엔드 애플리케이션에 알림을 보내도록 규칙을 구성합니다. Amazon Elastic Kubernetes Service(Amazon EKS)에 백엔드 애플리케이션을 어디서나 배포합니다. 독립형 클러스터를 만듭니다.
B. Amazon API Gateway API를 생성합니다. API를 AWS Step Functions 상태 머신과 통합하여 모바일 장치로부터 결제 알림을 수신하세요. 상태 시스템을 호출하여 결제 알림을 검증하고 백엔드 애플리케이션에 알림을 보냅니다. Amazon Elastic Kubernetes Service(Amazon EKS)에 백엔드 애플리케이션을 배포합니다. 자체 관리형 노드로 EKS 클러스터를 구성합니다.
C. Amazon Simple Queue Service(Amazon SQS) 대기열을 생성합니다. 대기열을 Amazon EventBridge 규칙과 통합하여 모바일 장치에서 결제 알림을 받습니다. 결제 알림을 검증하고 백엔드 애플리케이션에 알림을 보내도록 규칙을 구성합니다. Amazon EC2 스팟 인스턴스에 백엔드 애플리케이션을 배포합니다. 기본 할당 전략으로 스팟 집합을 구성합니다.
D. Amazon API Gateway API를 생성합니다. API를 AWS Lambda와 통합하여 모바일 장치로부터 결제 알림을 받으세요. Lambda 함수를 호출하여 결제 알림을 검증하고 백엔드 애플리케이션에 알림을 보냅니다. Amazon Elastic Container Service(Amazon ECS)에 백엔드 애플리케이션을 배포합니다. AWS Fargate 시작 유형으로 Amazon ECS를 구성합니다.
풀이
모바일 장치와 같은 외부 클라이언트로부터 데이터를 수신할 때는 Amazon API Gateway가 가장 표준적인 진입점입니다. 들어온 데이터의 간단한 유효성 검사는 서버리스 컴퓨팅인 AWS Lambda로 처리하는 것이 비용과 관리 측면에서 효율적입니다. 마지막으로, 인프라 관리를 원하지 않으면서 장시간 실행되는 컨테이너 애플리케이션을 돌리려면 서버 관리 부담이 없는 AWS Fargate(Amazon ECS)를 사용하는 것이 정답입니다.
정답 : D
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 모바일 장치로부터 결제 알림 수신 필요.
- 수신된 데이터에 대한 기본적인 유효성 검사 수행.
- 백엔드 애플리케이션은 장기간 실행되는 프로세스임.
- 회사는 인프라 관리를 원하지 않음(Serverless 지향).
2. 관련 AWS 서비스 생각하기
- Amazon API Gateway : 어떤 규모에서든 개발자가 API를 손쉽게 생성, 게시, 유지 관리, 모니터링 및 보안 유지할 수 있게 해주는 완전 관리형 서비스입니다. 모바일 앱의 백엔드 진입점으로 사용됩니다.
- AWS Lambda : 서버를 프로비저닝하거나 관리하지 않고 코드를 실행할 수 있는 이벤트 중심의 서버리스 컴퓨팅 서비스입니다. 짧은 실행 시간과 검증 로직에 적합합니다.
- AWS Fargate : 컨테이너에 적합한 서버리스 컴퓨팅 엔진입니다. Amazon ECS 및 EKS와 함께 작동하며, 서버나 클러스터를 관리할 필요 없이 컨테이너를 실행할 수 있습니다.
- Amazon ECS (Elastic Container Service) : 컨테이너화된 애플리케이션의 배포, 관리 및 확장을 돕는 완전 관리형 컨테이너 오케스트레이션 서비스입니다.
3. 선택지 분석하기
A. Amazon Simple Queue Service(Amazon SQS) 대기열을 생성합니다. 대기열을 Amazon EventBridge 규칙과 통합하여 모바일 장치에서 결제 알림을 받습니다. 결제 알림을 검증하고 백엔드 애플리케이션에 알림을 보내도록 규칙을 구성합니다. Amazon Elastic Kubernetes Service(Amazon EKS)에 백엔드 애플리케이션을 어디서나 배포합니다. 독립형 클러스터를 만듭니다.
→ EKS Anywhere나 독립형 클러스터는 고객이 직접 인프라를 관리해야 하는 부담이 매우 큽니다. 인프라 관리를 원하지 않는다는 요구사항에 위배됩니다.
B. Amazon API Gateway API를 생성합니다. API를 AWS Step Functions 상태 머신과 통합하여 모바일 장치로부터 결제 알림을 수신하세요. 상태 시스템을 호출하여 결제 알림을 검증하고 백엔드 애플리케이션에 알림을 보냅니다. Amazon Elastic Kubernetes Service(Amazon EKS)에 백엔드 애플리케이션을 배포합니다. 자체 관리형 노드로 EKS 클러스터를 구성합니다.
→ EKS의 자체 관리형 노드(Self-managed nodes)는 사용자가 직접 EC2 인스턴스를 관리하고 패치해야 함을 의미합니다. 이는 관리 오버헤드가 발생하므로 정답이 아닙니다.
C. Amazon Simple Queue Service(Amazon SQS) 대기열을 생성합니다. 대기열을 Amazon EventBridge 규칙과 통합하여 모바일 장치에서 결제 알림을 받습니다. 결제 알림을 검증하고 백엔드 애플리케이션에 알림을 보내도록 규칙을 구성합니다. Amazon EC2 스팟 인스턴스에 백엔드 애플리케이션을 배포합니다. 기본 할당 전략으로 스팟 집합을 구성합니다.
→ EC2 인스턴스를 직접 관리해야 하며, 스팟 인스턴스는 언제든 중단될 수 있어 장기 실행 프로세스에 대한 추가적인 관리 전략이 필요합니다. 관리 오버헤드가 높습니다.
D. Amazon API Gateway API를 생성합니다. API를 AWS Lambda와 통합하여 모바일 장치로부터 결제 알림을 받으세요. Lambda 함수를 호출하여 결제 알림을 검증하고 백엔드 애플리케이션에 알림을 보냅니다. Amazon Elastic Container Service(Amazon ECS)에 백엔드 애플리케이션을 배포합니다. AWS Fargate 시작 유형으로 Amazon ECS를 구성합니다.
→ API Gateway로 받고, Lambda로 검증하며, Fargate로 서버 관리 없이 백엔드를 실행하는 완벽한 서버리스 아키텍처입니다. 인프라 관리 노력이 제로에 가깝습니다.
이어서 다음 문제입니다.
문제2
솔루션 설계자는 회사를 위한 사용자 인증 솔루션을 설계하고 있습니다. 솔루션은 일관되지 않은 지리적 위치, IP 주소 또는 장치에서 로그인하는 사용자에 대해 2단계 인증을 호출해야 합니다. 또한 솔루션은 수백만 명의 사용자를 수용할 수 있도록 확장할 수 있어야 합니다.
어떤 솔루션이 이러한 요구 사항을 충족합니까?
선택지
A. 사용자 인증을 위해 Amazon Cognito 사용자 풀을 구성합니다. MFA(다단계 인증)를 통해 위험 기반 적응형 인증 기능을 활성화합니다.
B. 사용자 인증을 위해 Amazon Cognito 자격 증명 풀을 구성합니다. 다단계 인증(MFA)을 활성화합니다.
C. 사용자 인증을 위해 AWS Identity and Access Management(IAM) 사용자를 구성합니다. AllowManageOwnUserMFA 작업을 허용하는 IAM 정책을 연결합니다.
D. 사용자 인증을 위해 AWS IAM Identity Center(AWS Single Sign-On) 인증을 구성합니다. MFA(다단계 인증)를 요구하도록 권한 집합을 구성합니다.
풀이
수백만 명의 사용자를 관리하면서 로그인 패턴(위치, IP, 장치 등)을 분석하여 위험할 때만 MFA를 요구하는 기능은 Amazon Cognito 사용자 풀의 고급 보안 기능인 위험 기반 적응형 인증(Adaptive Authentication)입니다. 이 기능을 사용하면 정상적인 사용자는 편하게 로그인하고, 의심스러운 접속 시도에만 추가 인증을 요구하여 보안과 편의성을 모두 잡을 수 있습니다.
정답 : A
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 수백만 명의 사용자를 수용할 수 있는 확장성 있는 인증 서비스 필요.
- 평소와 다른 지리적 위치, IP, 장치에서 접속할 때만 조건부 MFA 호출.
- 사용자 로그인 패턴을 기반으로 위험도를 평가해야 함.
2. 관련 AWS 서비스 생각하기
- Amazon Cognito User Pools (사용자 풀) : 웹 및 모바일 앱을 위한 사용자 디렉터리입니다. 수억 명의 사용자로 확장 가능하며, 회원 가입 및 로그인을 처리합니다. 고급 보안 기능으로 위험 기반 적응형 인증(Adaptive Authentication)을 제공하여, 로그인 위험도가 높을 때만 MFA를 요구하거나 로그인을 차단할 수 있습니다.
- Amazon Cognito Identity Pools (자격 증명 풀) : 사용자가 AWS 서비스(S3, DynamoDB 등)에 직접 접근할 수 있도록 임시 AWS 자격 증명을 부여하는 서비스입니다. 인증 자체보다는 권한 부여(Authorization)에 초점이 맞춰져 있습니다.
3. 선택지 분석하기
A. 사용자 인증을 위해 Amazon Cognito 사용자 풀을 구성합니다. MFA(다단계 인증)를 통해 위험 기반 적응형 인증 기능을 활성화합니다.
→ 수백만 명의 사용자 관리가 가능하며, 문제에서 요구하는 조건부 MFA(위험 기반) 기능을 정확히 제공하는 서비스입니다.
B. 사용자 인증을 위해 Amazon Cognito 자격 증명 풀을 구성합니다. 다단계 인증(MFA)을 활성화합니다.
→ 자격 증명 풀은 AWS 리소스 접근 권한을 관리하는 곳이지, 사용자 프로필과 로그인 정책(MFA 조건 등)을 관리하는 곳이 아닙니다.
C. 사용자 인증을 위해 AWS Identity and Access Management(IAM) 사용자를 구성합니다. AllowManageOwnUserMFA 작업을 허용하는 IAM 정책을 연결합니다.
→ IAM 사용자는 AWS 계정 관리용이며 계정당 최대 5,000명으로 제한됩니다. 수백만 명의 앱 사용자를 수용할 수 없습니다.
D. 사용자 인증을 위해 AWS IAM Identity Center(AWS Single Sign-On) 인증을 구성합니다. MFA(다단계 인증)를 요구하도록 권한 집합을 구성합니다.
→ IAM Identity Center는 주로 직원들이 여러 AWS 계정이나 비즈니스 애플리케이션에 접근할 때 사용하는 인력용 서비스입니다. 일반 대중(B2C)을 위한 대규모 인증 솔루션이 아닙니다.
마지막 문제 살펴보겠습니다.
문제3
회사의 마케팅 데이터는 여러 소스에서 Amazon S3 버킷으로 업로드됩니다. 일련의 데이터 준비 작업은 보고를 위해 데이터를 집계합니다. 데이터 준비 작업은 정기적인 간격으로 병렬로 실행되어야 합니다. 나중에 특정 순서로 몇 가지 작업을 실행해야 합니다. 회사는 작업 오류 처리, 재시도 논리 및 상태 관리의 운영 오버헤드를 제거하려고 합니다.
어떤 솔루션이 이러한 요구 사항을 충족합니까?
선택지
A. 데이터가 S3 버킷에 업로드되는 즉시 AWS Lambda 함수를 사용하여 데이터를 처리합니다. 정기적으로 예약된 간격으로 다른 Lambda 함수를 호출합니다.
B. Amazon Athena를 사용하여 데이터를 처리합니다. Amazon EventBridge Scheduler를 사용하여 정기적인 간격으로 Athena를 호출합니다.
C. AWS Glue DataBrew를 사용하여 데이터를 처리합니다. AWS Step Functions 상태 시스템을 사용하여 DataBrew 데이터 준비 작업을 실행합니다.
D. AWS Data Pipeline을 사용하여 데이터를 처리합니다. 자정에 한 번 데이터를 처리하도록 데이터 파이프라인을 예약합니다.
풀이
이 문제는 여러 단계로 구성된 데이터 처리 작업을 정해진 순서에 따라 실행하면서도 오류 처리와 재시도 같은 복잡한 관리 업무를 자동화하는 최적의 도구를 찾는 것입니다. AWS Glue DataBrew는 코딩 없이도 데이터를 시각적으로 정제하고 집계할 수 있는 도구이며, AWS Step Functions은 이러한 여러 작업을 병렬 또는 순차적으로 연결하여 하나의 거대한 흐름으로 관리해 줍니다. AWS Step Functions이 작업의 상태를 기억하고 실패 시 자동으로 다시 시도하는 기능을 갖추고 있으므로 운영자가 일일이 개입하지 않아도 복잡한 데이터 파이프라인을 안정적으로 운영할 수 있어 문제의 요구 사항을 가장 완벽하게 해결합니다.
정답 : C
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 여러 소스에서 S3로 업로드되는 마케팅 데이터를 집계해야 함.
- 데이터 준비 작업은 정기적인 간격으로 병렬 실행 가능해야 함.
- 일부 작업은 특정 순서로 순차 실행되어야 함.
- 작업 오류 처리, 재시도 로직, 상태 관리 등의 운영 오버헤드 제거 필요.
2. 관련 AWS 서비스 생각하기
- Amazon S3 : 데이터를 버킷이라는 바구니에 객체 단위로 담아 보관하는 저장소로, 저장 용량에 한계가 없으며 한 번 저장된 데이터가 손실되지 않도록 여러 장소에 자동으로 복제되어 관리됩니다.
- AWS Glue DataBrew : 복잡한 코드를 직접 작성하지 않고도 시각적인 인터페이스를 통해 데이터를 탐색하고 정제할 수 있게 돕는 시각적 데이터 준비 도구입니다. 데이터의 결측치를 채우거나 형식을 변환하고 민감한 정보를 마스킹하는 등 250개 이상의 사전 정의된 변환 기능을 제공합니다.
- AWS Step Functions : 여러 AWS 서비스를 시각적 워크플로로 연결하여 애플리케이션을 구성할 수 있는 서버리스 오케스트레이션 서비스입니다. 병렬 실행, 순차 실행, 오류 처리, 자동 재시도, 상태 관리 기능을 기본으로 제공합니다.
3. 선택지 분석하기
A. 데이터가 S3 버킷에 업로드되는 즉시 AWS Lambda 함수를 사용하여 데이터를 처리합니다. 정기적으로 예약된 간격으로 다른 Lambda 함수를 호출합니다.
→ Lambda 자체에는 워크플로를 시각화하거나 복잡한 분기 처리를 내장하는 기능이 부족하여 대규모 데이터 파이프라인 관리용으로는 적절하지 않습니다.
B. Amazon Athena를 사용하여 데이터를 처리합니다. Amazon EventBridge Scheduler를 사용하여 정기적인 간격으로 Athena를 호출합니다.
→ Amazon Athena는 데이터를 조회하고 분석하는 용도로는 훌륭하지만, 데이터의 정제와 집계라는 준비 과정 자체를 전문적으로 처리하기에는 기능적 제약이 있습니다.
C. AWS Glue DataBrew를 사용하여 데이터를 처리합니다. AWS Step Functions 상태 시스템을 사용하여 DataBrew 데이터 준비 작업을 실행합니다.
→ AWS Glue DataBrew를 통해 시각적으로 데이터를 준비하고, AWS Step Functions을 통해 전체 실행 순서와 상태를 제어하는 방식은 요구 사항을 모두 만족합니다.
D. AWS Data Pipeline을 사용하여 데이터를 처리합니다. 자정에 한 번 데이터를 처리하도록 데이터 파이프라인을 예약합니다.
→ AWS Data Pipeline은 과거의 워크플로 도구로, 최신 서비스인 AWS Step Functions이나 AWS Glue DataBrew에 비해 유연성과 시각적 관리 기능이 부족합니다.
오늘도 끝까지 함께해 주셔서 감사합니다. 꽃구경도 좋지만 합격의 기쁨이 더 달콤하니, 조금만 더 힘내봐요!
'AWS > SAA 준비' 카테고리의 다른 글
| AWS SAA 합격으로 가는 길 #171 (0) | 2026.04.20 |
|---|---|
| AWS SAA 합격으로 가는 길 #170 (0) | 2026.04.13 |
| AWS SAA 합격으로 가는 길 #168 (0) | 2026.03.30 |
| AWS SAA 합격으로 가는 길 #167 (0) | 2026.03.23 |
| AWS SAA 합격으로 가는 길 #166 (0) | 2026.03.20 |
