안녕하세요! 오늘도 AWS 솔루션 아키텍트 자격증 준비를 위한 시간입니다.
AWS SAA(Solutions Architect Associate) 자격증 준비에 도움이 될 핵심 문제들을 준비했습니다. 이론만으로는 부족할 수 있는 실전 감각을 키우고, 출제 경향을 파악할 수 있는 좋은 기회가 될 것입니다. 지금부터 시작하겠습니다. 준비되셨나요?
문제는 세 가지 단계를 거치며 풀어 나갈 거예요.
1. 문제의 요구사항 분석하기
2. 관련 AWS 서비스 생각하기
3. 선택지 분석하기
바로 문제 풀이 해보겠습니다!
문제1
회사는 온프레미스에서 다중 계층 웹 애플리케이션을 실행하고 있습니다. 웹 애플리케이션은 컨테이너화되어 있으며 사용자 레코드가 포함된 PostgreSQL 데이터베이스에 연결된 여러 Linux 호스트에서 실행됩니다. 인프라 및 용량 계획을 유지 관리하는 운영 오버헤드는 회사의 성장을 제한하고 있습니다. 솔루션 설계자는 애플리케이션의 인프라를 개선해야 합니다. 이를 달성하기 위해 솔루션 설계자는 어떤 작업 조합을 수행해야 합니까? (두 가지를 선택하세요.)
선택지
A. PostgreSQL 데이터베이스를 Amazon Aurora로 마이그레이션합니다.
B. Amazon EC2 인스턴스에서 호스팅할 웹 애플리케이션을 마이그레이션합니다.
C. 웹 애플리케이션 콘텐츠에 대한 Amazon CloudFront 배포를 설정합니다.
D. 웹 애플리케이션과 PostgreSQL 데이터베이스 간에 Amazon ElastiCache를 설정합니다.
E. Amazon Elastic Container Service(Amazon ECS)를 사용하여 AWS Fargate에서 호스팅할 웹 애플리케이션을 마이그레이션합니다.
풀이
Amazon ECS를 사용하여 웹 애플리케이션을 AWS Fargate로 마이그레이션하면 컨테이너 관리를 자동화하여 인프라 및 용량 계획 관리의 운영 오버헤드가 감소합니다. Fargate는 서버리스 컴퓨팅 엔진으로, 컨테이너 실행을 위한 컴퓨팅 리소스 프로비저닝 및 관리가 불필요하므로 운영 부담을 최소화할 수 있습니다.
정답 : A,E
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 컨테이너화된 다중 계층 웹 애플리케이션을 온프레미스에서 실행 중
- PostgreSQL 데이터베이스에 사용자 레코드 저장
- 인프라 및 용량 계획 유지 관리로 인한 운영 오버헤드가 성장 제한 요소임
- 운영 오버헤드를 줄이는 인프라 개선 방안 필요
2. 관련 AWS 서비스 생각하기
- Amazon ECS(Elastic Container Service)는 완전관리형 컨테이너 오케스트레이션 서비스로, Docker 컨테이너를 클러스터에서 실행, 중지, 관리할 수 있습니다. EC2 인스턴스 또는 AWS Fargate와 함께 사용할 수 있습니다. Fargate는 서버리스 컴퓨팅 엔진으로, 컨테이너 실행을 위한 컴퓨팅 리소스를 자동으로 프로비저닝하고 관리합니다. 필요한 리소스만 사용하므로 비용 효율적이며 확장성이 뛰어납니다.
- Amazon Aurora는 MySQL 및 PostgreSQL 호환 관계형 데이터베이스 서비스로, 고가용성과 높은 성능을 제공합니다. 데이터베이스 마이그레이션을 지원하며, 기존 PostgreSQL 데이터베이스를 Amazon Aurora로 마이그레이션할 수 있습니다.
- Amazon CloudFront는 콘텐츠를 전 세계 엣지 로케이션에 캐싱하여 낮은 지연시간과 높은 전송 속도로 사용자에게 콘텐츠를 전달하는 웹 서비스입니다.
- Amazon ElastiCache는 인 메모리 데이터 스토어로, 웹 애플리케이션의 성능을 높이기 위해 데이터를 캐싱하는 데 사용됩니다.
3. 선택지 분석하기
A. PostgreSQL 데이터베이스를 Amazon Aurora로 마이그레이션합니다.
→ 적절한 선택입니다. Amazon Aurora는 완전관리형 데이터베이스 서비스로, 자동화된 백업, 패치 적용, 고가용성 설정 등을 AWS가 관리하여 운영 오버헤드를 크게 줄일 수 있습니다. Aurora PostgreSQL은 기존 PostgreSQL 데이터베이스와 호환되므로 마이그레이션이 상대적으로 용이하며, 자동 확장 기능으로 용량 계획 걱정을 줄일 수 있습니다.
B. Amazon EC2 인스턴스에서 호스팅할 웹 애플리케이션을 마이그레이션합니다.
→ 부적절한 선택입니다. EC2 인스턴스로 마이그레이션하면 온프레미스에서 클라우드로 이동하는 이점이 있지만, 여전히 인스턴스 관리, 확장, 패치 적용 등의 운영 오버헤드가 발생합니다. 문제에서 언급한 인프라 및 용량 계획 관련 운영 오버헤드를 효과적으로 줄이지 못합니다.
C. 웹 애플리케이션 콘텐츠에 대한 Amazon CloudFront 배포를 설정합니다.
→ 부적절한 선택입니다. CloudFront는 정적 콘텐츠 전송 속도 향상과 글로벌 사용자 경험 개선에 도움이 되지만, 인프라 관리 및 용량 계획의 운영 오버헤드를 직접적으로 줄이지는 않습니다.
D. 웹 애플리케이션과 PostgreSQL 데이터베이스 간에 Amazon ElastiCache를 설정합니다.
→ 부적절한 선택입니다. ElastiCache는 데이터베이스 부하를 줄이고 성능을 향상시킬 수 있지만, 인프라 관리와 용량 계획의 근본적인 운영 오버헤드 문제를 해결하지는 않습니다.
E. Amazon Elastic Container Service(Amazon ECS)를 사용하여 AWS Fargate에서 호스팅할 웹 애플리케이션을 마이그레이션합니다.
→ 적절한 선택입니다. AWS Fargate를 사용하면 컨테이너를 실행하기 위한 서버 관리가 필요 없는 서버리스 컴퓨팅 환경을 제공합니다. 기존 컨테이너화된 애플리케이션을 Fargate로 이동함으로써 용량 계획, 인스턴스 관리, 확장성 관리와 같은 인프라 관련 운영 오버헤드를 크게 줄일 수 있습니다. 애플리케이션 요구에 따라 자동으로 확장되므로 회사 성장에 따른 인프라 제약을 해소할 수 있습니다.
이어서 다음 문제입니다.
문제2
신입 사원이 배포 엔지니어로 회사에 합류했습니다. 배포 엔지니어는 AWS CloudFormation 템플릿을 사용하여 여러 AWS 리소스를 생성합니다. 솔루션 설계자는 배포 엔지니어가 최소 권한 원칙에 따라 작업 활동을 수행하기를 원합니다. 이 목표를 달성하기 위해 솔루션 설계자가 취해야 하는 작업 조합은 무엇입니까? (두 가지를 선택하세요.)
선택지
A. 배포 엔지니어가 AWS CloudFormation 스택 작업을 수행하기 위해 AWS 계정 루트 사용자 자격 증명을 사용하도록 합니다.
B. 배포 엔지니어를 위한 새 IAM 사용자를 생성하고 PowerUsers IAM 정책이 연결된 그룹에 IAM 사용자를 추가합니다.
C. 배포 엔지니어를 위한 새 IAM 사용자를 생성하고 AdministratorAccess IAM 정책이 연결된 그룹에 IAM 사용자를 추가합니다.
D. 배포 엔지니어를 위한 새 IAM 사용자를 생성하고 AWS CloudFormation 작업만 허용하는 IAM 정책이 있는 그룹에 IAM 사용자를 추가합니다.
E. 배포 엔지니어를 위한 IAM 역할을 생성하여 해당 IAM 역할을 사용하여 AWS CloudFormation 스택 및 시작 스택에 특정한 권한을 명시적으로 정의합니다.
풀이
최소 권한 원칙을 준수하기 위해 배포 엔지니어를 위한 새로운 IAM 사용자를 생성하고, AWS CloudFormation 작업만 허용하는 IAM 정책이 있는 그룹에 해당 사용자를 추가해야 합니다. 이렇게 하면 필요한 최소한의 권한만 부여되어 보안 위험을 줄일 수 있습니다.
정답 : D,E
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 배포 엔지니어가 AWS CloudFormation을 사용하여 작업 수행
- 최소 권한 원칙에 따라 권한 부여
2. 관련 AWS 서비스 생각하기
- AWS IAM(Identity and Access Management): 사용자 및 역할 관리, 권한 부여 서비스
- AWS CloudFormation: 인프라를 코드로 관리하는 서비스
3. 선택지 분석하기
A. 배포 엔지니어가 AWS CloudFormation 스택 작업을 수행하기 위해 AWS 계정 루트 사용자 자격 증명을 사용하도록 합니다. → 부적절한 선택입니다. 루트 사용자는 AWS 계정의 모든 권한을 가진 사용자로, 일상적인 작업에 사용해서는 안 됩니다. 루트 사용자 자격 증명을 공유하는 것은 심각한 보안 위험을 초래하며 최소 권한 원칙에 명백히 위배됩니다.
B. 배포 엔지니어를 위한 새 IAM 사용자를 생성하고 PowerUsers IAM 정책이 연결된 그룹에 IAM 사용자를 추가합니다.
→ 부적절한 선택입니다. PowerUsers 정책은 광범위한 권한을 제공하며 CloudFormation 작업 외에도 많은 리소스에 대한 접근 권한을 부여합니다. 최소 권한 원칙에 부합하지 않습니다.
C. 배포 엔지니어를 위한 새 IAM 사용자를 생성하고 AdministratorAccess IAM 정책이 연결된 그룹에 IAM 사용자를 추가합니다.
→ 부적절한 선택입니다. AdministratorAccess 정책은 AWS 계정의 모든 리소스에 대한 전체 관리 권한을 제공하므로, 최소 권한 원칙에 명백히 위배됩니다.
D. 배포 엔지니어를 위한 새 IAM 사용자를 생성하고 AWS CloudFormation 작업만 허용하는 IAM 정책이 있는 그룹에 IAM 사용자를 추가합니다.
→ 적절한 선택입니다. 새 IAM 사용자를 생성하고 CloudFormation 작업만 허용하는 제한된 IAM 정책을 적용함으로써, 배포 엔지니어는 필요한 CloudFormation 작업을 수행할 수 있지만 다른 AWS 서비스나 리소스에 대한 불필요한 접근은 제한됩니다. 이는 최소 권한 원칙에 부합합니다.
E. 배포 엔지니어를 위한 IAM 역할을 생성하여 해당 IAM 역할을 사용하여 AWS CloudFormation 스택 및 시작 스택에 특정한 권한을 명시적으로 정의합니다.
→ 적절한 선택입니다. IAM 역할을 생성하고 CloudFormation 스택 및 관련 리소스에 대한 특정 권한을 명시적으로 정의함으로써, 필요한 리소스에만 접근할 수 있도록 세밀하게 제어할 수 있습니다. IAM 역할은 또한 임시 자격 증명을 제공하여 보안을 강화하고, CloudFormation이 리소스를 생성하는 데 필요한 권한을 명확하게 정의할 수 있습니다.
마지막 문제 살펴볼게요.
문제3
회사에서 애플리케이션을 서버리스 솔루션으로 이동하려고 합니다. 서버리스 솔루션은 SL을 사용하여 기존 및 신규 데이터를 분석해야 합니다. 회사는 데이터를 Amazon S3 버킷에 저장합 니다. 데이터는 암호화가 필요하며 다른 AWS 리전에 복제되어야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
선택지
A. 새 S3 버킷을 생성합니다. 새 S3 버킷에 데이터를 로드합니다. S3 교차 리전 복제(CRR)를 사용하여 암호화된 객체를 다른 리전의 S3 버킷에 복제합니다. AWS KMS 다중 리전 키 (SSE-KMS)로 서버 측 암호화를 사용합니다. Amazon Athena를 사용하여 데이터를 쿼리합니다.
B. 새 S3 버킷을 생성합니다. 새 S3 버킷에 데이터를 로드합니다. S3 CRR(Cross-Region Replication)을 사용하여 암호화된 객체를 다른 리전의 S3 버킷에 복제합니다. AWS KMS 다중 리전 키(SSE-KMS)로 서버 측 암호화를 사용합니다. Amazon RDS를 사용하여 데이터를 쿼리합니다.
C. 기존 S3 버킷에 데이터를 로드합니다. S3 CRR(Cross-Region Replication)을 사용하여 암호화된 객체를 다른 리전의 S3 버킷에 복제합니다. Amazon S3 관리형 암호화 키 (SSE-S3)로 서버 측 암호화를 사용합니다. Amazon Athena를 사용하여 데이터를 쿼리합니다.
D. 기존 S3 버킷에 데이터를 로드합니다. S3 CRR(Cross-Region Replication)을 사용하여 암호화된 객체를 다른 리전의 S3 버킷에 복제합니다. Amazon S3 관리형 암호화 키 (SSE-S3)로 서버 측 암호화를 사용합니다. Amazon RDS를 사용하여 데이터를 쿼리합니다.
풀이
데이터를 새로운 Amazon S3 버킷에 저장하고, 서버 측 암호화(SSE-KMS)를 사용하여 AWS KMS 다중 리전 키로 암호화합니다. S3 교차 리전 복제(CRR)를 사용하여 데이터를 다른 AWS 리전에 복제합니다. Amazon Athena를 사용하여 S3의 데이터를 쿼리할 수 있습니다. 이 솔루션을 통해 운영 오버헤드를 최소화하면서 데이터 암호화, 복제, 분석 요구사항을 충족할 수 있습니다.
정답 : A
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 서버리스 솔루션으로 애플리케이션 이전
- SQL을 사용한 데이터 분석 필요
- 데이터는 S3 버킷에 저장
- 데이터 암호화 필요
- 다른 AWS 리전으로 데이터 복제 필요
- 운영 오버헤드 최소화 필요
2. 관련 AWS 서비스 생각하기
-
- Amazon S3: 확장성 있는 객체 스토리지 서비스
- S3 교차 리전 복제(CRR): 다른 리전으로 데이터 복제
- AWS KMS(Key Management Service): 암호화 키 관리 서비스
- Amazon Athena: 서버리스 SQL 쿼리 서비스(S3 데이터 직접 쿼리)
- Amazon RDS: 관계형 데이터베이스 서비스
3. 선택지 분석하기
A. 새 S3 버킷을 생성합니다. 새 S3 버킷에 데이터를 로드합니다. S3 교차 리전 복제(CRR)를 사용하여 암호화된 객체를 다른 리전의 S3 버킷에 복제합니다. AWS KMS 다중 리전 키(SSE-KMS)로 서버 측 암호화를 사용합니다. Amazon Athena를 사용하여 데이터를 쿼리합니다.
→ 적절한 선택입니다. 이 방법은:
- 새 S3 버킷으로 서버리스 데이터 저장소 생성
- AWS KMS 다중 리전 키를 사용한 강력한 서버 측 암호화 구현
- S3 CRR을 통한 리전 간 데이터 복제
- 서버리스 SQL 쿼리 서비스인 Athena를 사용하여 데이터 분석
- 인프라 관리 없이 서버리스 아키텍처로 운영 오버헤드 최소화
B. 새 S3 버킷을 생성합니다. 새 S3 버킷에 데이터를 로드합니다. S3 CRR(Cross-Region Replication)을 사용하여 암호화된 객체를 다른 리전의 S3 버킷에 복제합니다. AWS KMS 다중 리전 키(SSE-KMS)로 서버 측 암호화를 사용합니다. Amazon RDS를 사용하여 데이터를 쿼리합니다.
→ 부적절한 선택입니다. S3에 저장된 데이터를 직접 RDS로 쿼리하는 것은 일반적인 아키텍처가 아닙니다. RDS는 서버리스 서비스가 아니며, 데이터베이스 서버를 프로비저닝하고 관리해야 하므로 운영 오버헤드가 증가합니다. 서버리스 요구사항에 부합하지 않습니다.
C. 기존 S3 버킷에 데이터를 로드합니다. S3 CRR(Cross-Region Replication)을 사용하여 암호화된 객체를 다른 리전의 S3 버킷에 복제합니다. Amazon S3 관리형 암호화 키(SSE-S3)로 서버 측 암호화를 사용합니다. Amazon Athena를 사용하여 데이터를 쿼리합니다.
→ 부분적으로 적절하지만 최적의 선택은 아닙니다. SSE-S3는 S3가 암호화 키를 관리하는 방식으로, 다중 리전 키 관리 기능이 제한적입니다. 교차 리전 복제 시나리오에서는 다중 리전 키를 지원하는 SSE-KMS가 더 적합합니다. 또한 기존 S3 버킷 사용은 새로운 서버리스 아키텍처에 맞게 최적화되지 않을 수 있습니다.
D. 기존 S3 버킷에 데이터를 로드합니다. S3 CRR(Cross-Region Replication)을 사용하여 암호화된 객체를 다른 리전의 S3 버킷에 복제합니다. Amazon S3 관리형 암호화 키(SSE-S3)로 서버 측 암호화를 사용합니다. Amazon RDS를 사용하여 데이터를 쿼리합니다.
→ 부적절한 선택입니다. 이 옵션은 서버리스 요구사항을 충족하지 않으며, RDS를 사용한 S3 데이터 직접 쿼리는 일반적인 아키텍처가 아닙니다. SSE-S3도 다중 리전 시나리오에 최적화되어 있지 않습니다.
오늘 준비한 AWS SAA 핵심 문제들은 여기까지입니다. 여러분이 풀어보신 문제들을 통해 AWS 서비스의 특성과 아키텍처 설계 원칙에 대한 이해가 더욱 깊어졌기를 바랍니다.
지금까지 학습한 내용을 꾸준히 복습하시고, 실제 시험에서도 침착하게 접근하신다면 반드시 좋은 결과를 얻으실 수 있을 것입니다.
'AWS > SAA 준비' 카테고리의 다른 글
| AWS SAA 합격으로 가는 길 #70 (0) | 2025.03.31 |
|---|---|
| AWS SAA 합격으로 가는 길 #69 (0) | 2025.03.28 |
| AWS SAA 합격으로 가는 길 #67 (0) | 2025.03.21 |
| AWS SAA 합격으로 가는 길 #66 (0) | 2025.03.17 |
| AWS SAA 합격으로 가는 길 #65 (0) | 2025.03.14 |
