AWS SAA 문제풀이 정리_0904

한 회사에서 Oracle 데이터베이스를 AWS로 마이그레이션하려고 합니다. 이 데이터베이스는 수백만 개의 고해상도 지리 정보 시스템(GIS) 이미지가 포함된 단일 테이블로 구성되어 있으며, 이 이미지는 지리 코드로 식별됩니다.

자연 재해가 발생하면 수만 개의 이미지가 몇 분마다 업데이트됩니다. 각 지리 코드에는 연관된 단일 이미지 또는 행이 있습니다. 이 회사는 이러한 이벤트 중에 가용성이 높고 확장 가능한 솔루션을 원합니다.

어떤 솔루션이 이러한 요구 사항을 가장 비용 효율적으로 충족합니까?

• A. 이미지와 지리적 코드를 데이터베이스 테이블에 저장합니다. Amazon RDS Multi-AZ DB 인스턴스에서 실행되는 Oracle을 사용합니다.
• B. Amazon S3 버킷에 이미지를 저장합니다. 지리적 코드를 키로, 이미지 S3 URL을 값으로 사용하여 Amazon DynamoDB를 사용합니다. 
• C. Amazon DynamoDB 테이블에 이미지와 지리적 코드를 저장합니다. 부하가 높은 시간에 DynamoDB Accelerator(DAX)를 구성합니다.
• D. Amazon S3 버킷에 이미지를 저장합니다. 지리적 코드와 이미지 S3 URL을 데이터베이스 테이블에 저장합니다. Amazon RDS Multi-AZ DB 인스턴스에서 실행되는 Oracle을 사용합니다.

이유: Amazon은 사람들이 Oracle에서 DynamoDB와 S3와 같은 자사 서비스로 전환하는 것을 선호, D는 실행 가능하지만 Oracle 라이선스 및 HA 및 확장성을 위한 다른 설정으로 인해 비용이 더 많이 듭니다.

 

 

한 회사가 다른 팀이 액세스할 수 있도록 하루에 한 번 Amazon S3에 데이터베이스를 내보내야 합니다. 내보내는 객체 크기는 2GB에서 5GB 사이입니다. 데이터에 대한 S3 액세스 패턴은 가변적이며 빠르게 변경됩니다. 데이터는 즉시 사용할 수 있어야 하며 최대 3개월 동안 액세스할 수 있어야 합니다. 이 회사는 검색 시간을 늘리지 않는 가장 비용 효율적인 솔루션이 필요합니다.

이 회사는 이러한 요구 사항을 충족하기 위해 어떤 S3 스토리지 클래스를 사용해야 합니까?

• A. S3 지능형 계층화
• B. S3 Glacier 즉시 검색
• C. S3 표준
• D. S3 표준-빈번하지 않은 액세스(S3 표준-IA)

 

이유: 알 수 없음 / 변경되는 액세스 패턴 = 지능형 계층화, Amazon이 "알 수 없거나 변경되는 액세스" 패턴에 Intelligent Tiering(A)을 사용하라는 명확한 권장 사항이며, 이는 질문의 진술과 일치

 

한 회사가 AWS에서 다중 계층 애플리케이션을 호스팅합니다. 규정 준수, 거버넌스, 감사 및 보안을 위해 회사는 AWS 리소스의 구성 변경 사항을 추적하고 이러한 리소스에 대한 API 호출 내역을 기록해야 합니다.
솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까?

• A. AWS CloudTrail을 사용하여 구성 변경 사항을 추적하고 AWS Config를 사용하여 API 호출을 기록합니다.
• B. AWS Config를 사용하여 구성 변경 사항을 추적하고 AWS CloudTrail을 사용하여 API 호출을 기록합니다.
• C. AWS Config를 사용하여 구성 변경 사항을 추적하고 Amazon CloudWatch를 사용하여 API 호출을 기록합니다.
• D. AWS CloudTrail을 사용하여 구성 변경 사항을 추적하고 Amazon CloudWatch를 사용하여 API 호출을 기록합니다.

이유: Config = AWS 리소스의 거버넌스(시간 경과에 따른 리소스 구성의 변경 사항을 추적하는 서비스), 감사 CloudTrail = API 호출 추적

 

게임 회사가 데이터 센터에서 AWS 클라우드로 공개 스코어보드를 옮기고 있습니다. 이 회사는 동적 애플리케이션을 호스팅하기 위해 애플리케이션 로드 밸런서 뒤에 있는 Amazon EC2 Windows Server 인스턴스를 사용합니다. 이 회사는 애플리케이션을 위한 고가용성 스토리지 솔루션이 필요합니다. 이 애플리케이션은 정적 파일과 동적 서버 측 코드로 구성되어 있습니다.

솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 어떤 단계 조합을 취해야 합니까? (두 가지를 선택하세요.)

• A. 정적 파일을 Amazon S3에 저장합니다. Amazon CloudFront를 사용하여 에지에서 객체를 캐시합니다.
• B. 정적 파일을 Amazon S3에 저장합니다. Amazon ElastiCache를 사용하여 에지에서 객체를 캐시합니다.
• C. Amazon Elastic File System(Amazon EFS)에 서버 측 코드를 저장합니다. 각 EC2 인스턴스에 EFS 볼륨을 마운트하여 파일을 공유합니다.
• D. Amazon FSx for Windows File Server에 서버 측 코드를 저장합니다. 각 EC2 인스턴스에 FSx for Windows File Server 볼륨을 마운트하여 파일을 공유합니다.
• E. 서버 측 코드를 General Purpose SSD(gp2) Amazon Elastic Block Store(Amazon EBS) 볼륨에 저장합니다. 각 EC2 인스턴스에 EBS 볼륨을 마운트하여 파일을 공유합니다.

이유: CloudFront를 사용하여 S3에 정적 파일을 저장하면 에지 위치에서 캐싱하여 내구성, 고가용성 및 낮은 지연 시간을 제공합니다. FSx for Windows File Server는 Windows EC2 인스턴스에서 액세스하여 서버 측 코드를 공유할 수 있는 완전히 관리되는 Windows 기본 파일 시스템을 제공합니다. 고가용성을 위해 설계되었으며 최대 10초의 GBPS 처리량까지 확장됩니다. EFS 및 EBS 볼륨은 단일 AZ에 연결할 수 있습니다. FSx 및 S3는 고가용성을 위해 AZ 전체에 복제됩니다.

 

한 회사에 여러 Amazon EC2 인스턴스에서 실행되는 애플리케이션이 있습니다. 각 EC2 인스턴스에는 여러 Amazon Elastic Block Store(Amazon EBS) 데이터 볼륨이 연결되어 있습니다. 애플리케이션의 EC2 인스턴스 구성과 데이터는 매일 밤 백업해야 합니다. 또한 애플리케이션은 다른 AWS 지역에서 복구 가능해야 합니다.

어떤 솔루션이 이러한 요구 사항을 가장 운영 효율적인 방식으로 충족할까요?

• A. 애플리케이션의 EBS 볼륨에 대한 매일 밤 스냅샷을 예약하고 다른 지역에 스냅샷을 복사하는 AWS Lambda 함수를 작성합니다.
• B. AWS Backup을 사용하여 야간 백업을 수행하여 백업 계획을 만듭니다. 백업을 다른 Region에 복사합니다. 애플리케이션의 EC2 인스턴스를 리소스로 추가합니다.
• C. AWS Backup을 사용하여 야간 백업을 수행하여 백업 계획을 만듭니다. 백업을 다른 Region에 복사합니다. 애플리케이션의 EBS 볼륨을 리소스로 추가합니다.
• D. 애플리케이션의 EBS 볼륨에 대한 야간 스냅샷을 예약하고 다른 가용성 영역에 스냅샷을 복사하는 AWS Lambda 함수를 작성합니다.

이유: AWS KB에 따르면 EC2 인스턴스를 선택하면 연관된 EBS가 자동으로 적용됩니다.

 

한 회사가 AWS에서 사용자 기기의 센서 데이터를 수집하는 3계층 환경을 보유하고 있습니다. 트래픽은 네트워크 로드 밸런서(NLB)를 거쳐 웹 계층의 Amazon EC2 인스턴스로 이동한 다음, 마지막으로 데이터베이스 호출을 하는 애플리케이션 계층의 EC2 인스턴스로 이동합니다.
솔루션 아키텍트는 웹 계층으로 전송되는 데이터의 보안을 개선하기 위해 무엇을 해야 할까요?

• A. TLS 리스너를 구성하고 NLB에 서버 인증서를 추가합니다.
• B. AWS Shield Advanced를 구성하고 NLB에서 AWS WAF를 활성화합니다.
• C. 로드 밸런서를 애플리케이션 로드 밸런서로 변경하고 여기에 AWS WAF를 연결합니다.
• D. AWS Key Management Service(AWS KMS)를 사용하여 EC2 인스턴스의 Amazon Elastic Block Store(Amazon EBS) 볼륨을 암호화합니다.

이유: 데이터 변조 및 도청을 방지할 수 있는 TLS가 적합

 

한 회사가 오래된 애플리케이션을 AWS로 마이그레이션하고 있습니다. 이 애플리케이션은 매 시간 배치 작업을 실행하며 CPU를 많이 사용합니다. 배치 작업은 온프레미스 서버에서 평균 15분이 걸립니다. 이 서버에는 64개의 가상 CPU(vCPU)와 512GiB의 메모리가 있습니다.

어떤 솔루션이 가장 적은 운영 오버헤드로 15분 이내에 배치 작업을 실행할 수 있을까요?

• A. AWS Lambda를 함수형 확장에 사용합니다.
• B. AWS Fargate와 함께 Amazon Elastic Container Service(Amazon ECS)를 사용합니다.
• C. AWS Auto Scaling과 함께 Amazon Lightsail을 사용합니다.
• D. Amazon EC2에서 AWS Batch를 사용합니다.

이유: Lambda가 아닙니다. "평균 15분"은 15분 이상 또는 15분 미만으로 실행되는 작업이 있다는 것을 의미합니다. Lambda 최대값은 15분입니다. AWS Batch는 다양한 인스턴스 유형과 시작 모드를 사용할 수 있는 옵션과 함께 배치 작업에 필요한 인프라를 자동으로 프로비저닝하는 완전 관리형 서비스

 

한 회사가 AWS Lambda와 통합된 Amazon API Gateway API 백엔드를 사용하는 프런트엔드 애플리케이션을 호스팅합니다. API가 요청을 받으면 Lambda 함수는 많은 라이브러리를 로드합니다. 그런 다음 Lambda 함수는 Amazon RDS 데이터베이스에 연결하여 데이터를 처리하고 프런트엔드 애플리케이션에 데이터를 반환합니다. 이 회사는 회사 운영에 대한 변경 횟수를 최소화하여 모든 사용자에게 응답 지연 시간을 최대한 낮추고자 합니다.

어떤 솔루션이 이러한 요구 사항을 충족할까요?

• A. API를 우회하여 프런트엔드 애플리케이션과 데이터베이스 간에 연결을 설정하여 쿼리를 더 빠르게 실행합니다.
• B. 요청을 처리하는 Lambda 함수에 대해 프로비저닝된 동시성을 구성합니다.
• C. 유사한 데이터 세트를 더 빠르게 검색하기 위해 Amazon S3에 쿼리 결과를 캐시합니다.
• D. 데이터베이스 크기를 늘려 Lambda가 한 번에 설정할 수 있는 연결 수를 늘립니다.

이유: Lambda 함수는 많은 라이브러리를 로드합니다. 프로비저닝된 동시성을 구성하면 함수의 "콜드 스타트"가 없어져 프로세스 속도가 빨라집니다.

 

한 회사가 다중 계층 웹 애플리케이션에 Amazon ElastiCache를 사용할 계획입니다. 솔루션 아키텍트가 ElastiCache 클러스터에 대한 Cache VPC와 애플리케이션의 Amazon EC2 인스턴스에 대한 App VPC를 만듭니다. 두 VPC 모두 us-east-1 지역에 있습니다. 솔루션 아키텍트는 애플리케이션의 EC2 인스턴스에 ElastiCache 클러스터에 대한 액세스를 제공하는 솔루션을 구현해야 합니다.

이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

• A. VPC 간에 피어링 연결을 만듭니다. 두 VPC 모두에서 피어링 연결에 대한 경로 테이블 항목을 추가합니다. ElastiCache 클러스터의 보안 그룹에 대한 인바운드 규칙을 구성하여 애플리케이션의 보안 그룹에서 인바운드 연결을 허용합니다.
• B. Transit VPC를 만듭니다. Cache VPC와 App VPC의 VPC 경로 테이블을 업데이트하여 Transit VPC를 통해 트래픽을 라우팅합니다. ElastiCache 클러스터의 보안 그룹에 대한 인바운드 규칙을 구성하여 애플리케이션의 보안 그룹에서 인바운드 연결을 허용합니다.
• C. VPC 간에 피어링 연결을 만듭니다. 두 VPC 모두에서 피어링 연결에 대한 경로 테이블 항목을 추가합니다. 피어링 연결의 보안 그룹에 대한 인바운드 규칙을 구성하여 애플리케이션의 보안 그룹에서 인바운드 연결을 허용합니다.
• D. Transit VPC를 만듭니다. Cache VPC와 App VPC의 VPC 경로 테이블을 업데이트하여 Transit VPC를 통해 트래픽을 라우팅합니다. Transit VPC의 보안 그룹에 대한 인바운드 규칙을 구성하여 애플리케이션의 보안 그룹에서 인바운드 연결을 허용합니다.

이유: VPC 간에 피어링 연결을 만듭니다. 두 VPC 모두에서 피어링 연결에 대한 경로 테이블 항목을 추가합니다. ElastiCache 클러스터의 보안 그룹에 대한 인바운드 규칙을 구성하여 애플리케이션의 보안 그룹에서 인바운드 연결을 허용합니다. VPC 간에 피어링 연결을 만들면 애플리케이션의 EC2 인스턴스가 ElastiCache 클러스터와 직접 효율적으로 통신할 수 있습니다.

 

한 회사에는 매시간 수백 개의 .csv 파일을 Amazon S3 버킷에 넣는 애플리케이션이 있습니다. 파일 크기는 1GB입니다. 파일을 업로드할 때마다 회사는 파일을 Apache Parquet 형식으로 변환하고 출력 파일을 S3 버킷에 넣어야 합니다.

어떤 솔루션이 이러한 요구 사항을 가장 적은 운영 오버헤드로 충족할까요?

• A. .csv 파일을 다운로드하고, 파일을 Parquet 형식으로 변환하고, 출력 파일을 S3 버킷에 넣는 AWS Lambda 함수를 만듭니다. 각 S3 PUT 이벤트에 대해 Lambda 함수를 호출합니다.
• B. .csv 파일을 읽고, 파일을 Parquet 형식으로 변환하고, 출력 파일을 S3 버킷에 넣는 Apache Spark 작업을 만듭니다. 각 S3 PUT 이벤트에 대해 Spark 작업을 호출하는 AWS Lambda 함수를 만듭니다.
• C. 애플리케이션이 .csv 파일을 저장하는 S3 버킷에 대한 AWS Glue 테이블과 AWS Glue 크롤러를 만듭니다. AWS Lambda 함수를 예약하여 Amazon Athena를 주기적으로 사용하여 AWS Glue 테이블을 쿼리하고, 쿼리 결과를 Parquet 형식으로 변환하고, 출력 파일을 S3 버킷에 저장합니다.
• D. AWS Glue 추출, 변환 및 로드(ETL) 작업을 생성하여 .csv 파일을 Parquet 형식으로 변환하고 출력 파일을 S3 버킷에 넣습니다. 각 S3 PUT 이벤트에 대해 ETL 작업을 호출하기 위한 AWS Lambda 함수를 생성합니다.

이유: 이 솔루션은 AWS Glue가 데이터 저장소 간에 데이터를 쉽게 이동할 수 있는 완전 관리형 ETL 서비스이기 때문에 운영 오버헤드가 가장 적은 요구 사항을 충족합니다. AWS Glue는 S3 버킷에서 .csv 파일을 읽고 다른 S3 버킷에 Parquet 형식으로 데이터를 쓸 수 있습니다. AWS Lambda 함수는 새 .csv 파일이 업로드될 때 S3 PUT 이벤트에 의해 트리거될 수 있으며, AWS Glue ETL 작업을 시작하여 파일을 Parquet 형식으로 변환할 수 있습니다. 이 솔루션은 서버나 클러스터를 관리할 필요가 없으므로 운영 오버헤드가 줄어듭니다.