Question # 1 ~ # 10

 

// # 1

 

한 회사가 여러 대륙에 걸쳐 있는 도시의 온도, 습도, 기압에 대한 데이터를 수집합니다. 회사가 각 사이트에서 매일 수집하는 평균 데이터 양은 500GB입니다. 각 사이트에는 고속 인터넷 연결이 있습니다.
회사는 이러한 모든 글로벌 사이트의 데이터를 가능한 한 빨리 단일 Amazon S3 버킷에 집계하려고 합니다. 솔루션은 운영 복잡성을 최소화해야 합니다.
어떤 솔루션이 이러한 요구 사항을 충족합니까?

• A. 대상 S3 버킷에서 S3 Transfer Acceleration을 켭니다. 멀티파트 업로드를 사용하여 사이트 데이터를 대상 S3 버킷에 직접 업로드합니다.
• B. 각 사이트의 데이터를 가장 가까운 리전의 S3 버킷으로 업로드합니다. S3 크로스 리전 복제를 사용하여 객체를 대상 S3 버킷으로 복사합니다. 그런 다음 원본 S3 버킷에서 데이터를 제거합니다.
• C. AWS Snowball Edge Storage Optimized 장치 작업을 매일 예약하여 각 사이트에서 가장 가까운 Region으로 데이터를 전송합니다. S3 Cross-Region Replication을 사용하여 객체를 대상 S3 버킷으로 복사합니다.
• D. 각 사이트의 데이터를 가장 가까운 리전의 Amazon EC2 인스턴스로 업로드합니다. Amazon Elastic Block Store(Amazon EBS) 볼륨에 데이터를 저장합니다. 정기적으로 EBS 스냅샷을 찍어 대상 S3 버킷이 있는 리전에 복사합니다. 해당 리전에서 EBS 볼륨을 복원합니다.

S3 Transfer Acceleration : 데이터를 더 빠르게 Amazon S3으로 전송 가능

멀티파트 업로드 : 큰 파일을 여러 개의 작은 조각으로 나누어 도시에 업로드 가능

 

// # 2

 

회사는 자체 애플리케이션의 로그 파일을 분석할 수 있는 기능이 필요합니다. 로그는 Amazon S3 버킷에 JSON 형식으로 저장됩니다. 쿼리는 간단하며 주문형으로 실행됩니다. 솔루션 아키텍트는 기존 아키텍처를 최소한으로 변경하여 분석을 수행해야 합니다. 솔루션 아키텍트는 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하기 위해 무엇을 해야 할까요?

• A. Amazon Redshift를 사용하여 모든 콘텐츠를 한곳에 로드하고 필요에 따라 SQL 쿼리를 실행합니다.
• B. Amazon CloudWatch Logs를 사용하여 로그를 저장합니다. 필요에 따라 Amazon CloudWatch 콘솔에서 SQL 쿼리를 실행합니다.
• C. 필요에 따라 Amazon Athena를 Amazon S3와 직접 함께 사용하여 쿼리를 실행합니다.
• D. AWS Glue를 사용하여 로그를 카탈로그화합니다. Amazon EMR에서 일시적인 Apache Spark 클러스터를 사용하여 필요에 따라 SQL 쿼리를 실행합니다.

Amazon Athena : S3에 저장된 데이터를 직접 쿼리할 수 있는 서버리스 쿼리 서비스, 데이터를 별도로 로드할 필요 없이 SQL 쿼리를 통해 직접 분석 가능

 

// # 3

 

한 회사에서는 AWS Organizations를 사용하여 여러 부서의 여러 AWS 계정을 관리합니다. 관리 계정에는 프로젝트 보고서가 포함된 Amazon S3 버킷이 있습니다. 이 회사는 이 S3 버킷에 대한 액세스를 AWS Organizations의 조직 내 계정 사용자로만 제한하려고 합니다.
어떤 솔루션이 운영 오버헤드를 최소화하면서 이러한 요구 사항을 충족합니까?

• A. 조직 ID에 대한 참조가 있는 aws PrincipalOrgID 글로벌 조건 키를 S3 버킷 정책에 추가합니다.
• B. 각 부서에 대한 조직 단위(OU)를 만듭니다. S3 버킷 정책에 aws:PrincipalOrgPaths 글로벌 조건 키를 추가합니다.
• C. AWS CloudTrail을 사용하여 CreateAccount, InviteAccountToOrganization, LeaveOrganization 및 RemoveAccountFromOrganization 이벤트를 모니터링합니다. 이에 따라 S3 버킷 정책을 업데이트합니다.
• D. S3 버킷에 액세스해야 하는 각 사용자를 태그합니다. aws:PrincipalTag 글로벌 조건 키를 S3 버킷 정책에 추가합니다.

aws PrincipalOrgID : 특정 AWS Organizations의 조직 ID를 참조하는 조건 키

 

// # 4

 

애플리케이션은 VPC의 Amazon EC2 인스턴스에서 실행됩니다. 애플리케이션은 Amazon S3 버킷에 저장된 로그를 처리합니다. EC2 인스턴스는 인터넷에 연결하지 않고도 S3 버킷에 액세스해야 합니다.
어떤 솔루션이 Amazon S3에 프라이빗 네트워크 연결을 제공할까요?

• A. S3 버킷에 대한 게이트웨이 VPC 엔드포인트를 생성합니다.
• B. 로그를 Amazon CloudWatch Logs로 스트리밍합니다. 로그를 S3 버킷으로 내보냅니다.
• C. S3 액세스를 허용하기 위해 Amazon EC2에 인스턴스 프로필을 생성합니다.
• D. S3 엔드포인트에 액세스하기 위한 개인 링크가 있는 Amazon API Gateway API를 생성합니다.

게이트웨이 VPC 엔드포인트 : VPC 내의 Amazon EC2 인스턴스가 인터넷에 연결하지 않고도 Amazon S3에 프라이빗 네트워크로 직접 연결 가능

 

// # 5

 

한 회사가 사용자가 업로드한 문서를 Amazon EBS 볼륨에 저장하는 단일 Amazon EC2 인스턴스를 사용하여 AWS에서 웹 애플리케이션을 호스팅하고 있습니다. 더 나은 확장성과 가용성을 위해 회사는 아키텍처를 복제하고 다른 가용성 영역에 두 번째 EC2 인스턴스와 EBS 볼륨을 만들어 둘 다 애플리케이션 로드 밸런서 뒤에 배치했습니다. 이 변경을 완료한 후, 사용자들은 웹사이트를 새로 고칠 때마다 문서의 하위 집합 중 하나 또는 다른 하나를 볼 수 있지만 모든 문서를 동시에 볼 수는 없다고 보고했습니다.
솔루션 아키텍트는 사용자가 모든 문서를 한 번에 볼 수 있도록 하기 위해 무엇을 제안해야 할까요?

• A. 두 EBS 볼륨 모두에 모든 문서가 포함되도록 데이터를 복사합니다.
• B. 사용자를 문서가 있는 서버로 안내하도록 애플리케이션 로드 밸런서를 구성합니다.
• C. 두 EBS 볼륨의 데이터를 Amazon EFS로 복사합니다. 애플리케이션을 수정하여 새 문서를 Amazon EFS에 저장합니다.
• D. 두 서버 모두에 요청을 보내도록 애플리케이션 로드 밸런서를 구성합니다. 올바른 서버에서 각 문서를 반환합니다.

Amazon EFS : 여러 EC2 인스턴스에서 동시에 접근할 수 있는 파일 스토리지 서비스

 

// # 6

 

한 회사가 NFS를 사용하여 온프레미스 네트워크 연결 스토리지에 대용량 비디오 파일을 저장합니다. 각 비디오 파일의 크기는 1MB에서 500GB까지입니다. 총 스토리지는 70TB이며 더 이상 증가하지 않습니다. 회사는 비디오 파일을 Amazon S3로 마이그레이션하기로 결정했습니다. 회사는 가능한 한 빨리 비디오 파일을 마이그레이션해야 하며 가능한 한 최소한의 네트워크 대역폭을 사용해야 합니다.
어떤 솔루션이 이러한 요구 사항을 충족할까요?

• A. S3 버킷을 만듭니다. S3 버킷에 쓸 수 있는 권한이 있는 IAM 역할을 만듭니다. AWS CLI를 사용하여 모든 파일을 로컬로 S3 버킷에 복사합니다.
• B. AWS Snowball Edge 작업을 만듭니다. 온프레미스에서 Snowball Edge 장치를 받습니다. Snowball Edge 클라이언트를 사용하여 데이터를 장치로 전송합니다. AWS가 Amazon S3로 데이터를 가져올 수 있도록 장치를 반환합니다.
• C. 온프레미스에 S3 파일 게이트웨이를 배포합니다. S3 파일 게이트웨이에 연결할 퍼블릭 서비스 엔드포인트를 만듭니다. S3 버킷을 만듭니다. S3 파일 게이트웨이에 새 NFS 파일 공유를 만듭니다. 새 파일 공유를 S3 버킷으로 지정합니다. 기존 NFS 파일 공유에서 S3 파일 게이트웨이로 데이터를 전송합니다.
• D. 온프레미스 네트워크와 AWS 간에 AWS Direct Connect 연결을 설정합니다. 온프레미스에 S3 파일 게이트웨이를 배포합니다. S3 파일 게이트웨이에 연결할 퍼블릭 가상 인터페이스(VIF)를 만듭니다. S3 버킷을 만듭니다. S3 파일 게이트웨이에 새 NFS 파일 공유를 만듭니다. 새 파일 공유를 S3 버킷으로 지정합니다. 기존 NFS 파일 공유에서 S3 파일 게이트웨이로 데이터를 전송합니다.

 AWS Snowball Edge : 대량의 데이터를 빠르게 전송하기 위한 물리적 장치

 

// # 7

 

어떤 회사에 수신 메시지를 수집하는 애플리케이션이 있습니다. 수십 개의 다른 애플리케이션과 마이크로서비스가 이러한 메시지를 빠르게 소비합니다. 메시지 수는 크게 달라지며 때로는 초당 100,000개로 갑자기 증가합니다. 이 회사는 솔루션을 분리하고 확장성을 높이고자 합니다.
어떤 솔루션이 이러한 요구 사항을 충족합니까?

• A. Amazon Kinesis Data Analytics에 메시지를 유지합니다. 소비자 애플리케이션을 구성하여 메시지를 읽고 처리합니다.
• B. CPU 메트릭에 따라 EC2 인스턴스 수를 확장하기 위해 Auto Scaling 그룹의 Amazon EC2 인스턴스에 수집 애플리케이션을 배포합니다.
• C. 단일 샤드로 Amazon Kinesis Data Streams에 메시지를 씁니다. AWS Lambda 함수를 사용하여 메시지를 사전 처리하고 Amazon DynamoDB에 저장합니다. 소비자 애플리케이션을 구성하여 DynamoDB에서 읽어 메시지를 처리합니다.
• D. 여러 Amazon Simple Queue Service(Amazon SQS) 구독이 있는 Amazon Simple Notification Service(Amazon SNS) 주제에 메시지를 게시합니다. 소비자 애플리케이션을 구성하여 대기열에서 메시지를 처리합니다.

Amazon SNS : 메시지 게시

Amazon SQS : 메시지 대기열에 저장 

 

// # 8

 

한 회사가 분산 애플리케이션을 AWS로 마이그레이션하고 있습니다. 이 애플리케이션은 가변적인 워크로드를 처리합니다. 레거시 플랫폼은 여러 컴퓨팅 노드에서 작업을 조정하는 기본 서버로 구성됩니다. 이 회사는 복원성과 확장성을 극대화하는 솔루션으로 애플리케이션을 현대화하려고 합니다.
솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 어떻게 아키텍처를 설계해야 할까요?

• A. Amazon Simple Queue Service(Amazon SQS) 대기열을 작업의 대상으로 구성합니다. Auto Scaling 그룹에서 관리되는 Amazon EC2 인스턴스로 컴퓨팅 노드를 구현합니다. 예약된 스케일링을 사용하도록 EC2 Auto Scaling을 구성합니다.
• B. Amazon Simple Queue Service(Amazon SQS) 대기열을 작업의 대상으로 구성합니다. Auto Scaling 그룹에서 관리되는 Amazon EC2 인스턴스로 컴퓨팅 노드를 구현합니다. 대기열의 크기에 따라 EC2 Auto Scaling을 구성합니다. 
• C. Auto Scaling 그룹에서 관리되는 Amazon EC2 인스턴스로 기본 서버와 컴퓨팅 노드를 구현합니다. 작업의 대상으로 AWS CloudTrail을 구성합니다. 기본 서버의 부하에 따라 EC2 Auto Scaling을 구성합니다.
• D. Auto Scaling 그룹에서 관리되는 Amazon EC2 인스턴스로 기본 서버와 컴퓨트 노드를 구현합니다. 작업의 대상으로 Amazon EventBridge(Amazon CloudWatch Events)를 구성합니다. 컴퓨트 노드의 부하에 따라 EC2 Auto Scaling을 구성합니다.

 Amazon SQS : 메시지 대기열 서비스, 가변적인 워크로드 처리하는 데에 적합

Auto Scaling : 대기열의 크기에 따라 자동으로 인스턴스 확장 or 축소

 

// # 9

 

한 회사가 데이터 센터에서 SMB 파일 서버를 운영하고 있습니다. 파일 서버는 파일이 생성된 후 처음 며칠 동안 자주 액세스되는 대용량 파일을 저장합니다. 7일 후에는 파일에 거의 액세스하지 않습니다.
총 데이터 크기가 증가하고 있으며 회사의 총 스토리지 용량에 가깝습니다. 솔루션 아키텍트는 가장 최근에 액세스한 파일에 대한 저지연 액세스를 잃지 않으면서 회사의 사용 가능한 스토리지 공간을 늘려야 합니다. 솔루션 아키텍트는 또한 향후 스토리지 문제를 방지하기 위해 파일 수명 주기 관리를 제공해야 합니다.
어떤 솔루션이 이러한 요구 사항을 충족할까요?

• A. AWS DataSync를 사용하여 7일이 지난 데이터를 SMB 파일 서버에서 AWS로 복사합니다.
• B. 회사의 스토리지 공간을 확장하기 위해 Amazon S3 파일 게이트웨이를 만듭니다. 7일 후 S3 Glacier Deep Archive로 데이터를 전환하기 위한 S3 라이프사이클 정책을 만듭니다.
• C. 회사의 저장 공간을 확장하기 위해 Amazon FSx for Windows File Server 파일 시스템을 만듭니다.
• D. 각 사용자의 컴퓨터에 Amazon S3에 액세스하기 위한 유틸리티를 설치합니다. 7일 후 S3 Glacier Flexible Retrieval로 데이터를 전환하기 위한 S3 Lifecycle 정책을 만듭니다.

Amazon S3 파일 게이트웨이 : 기존 파일 서버와 Amazon S3 간에 파일 쉽게 이동 가능하게 해줌

S3 Glacier Deep Archive : 장기 보관을 위한 비용 효율적인 스토리지 옵션

 

// # 10

 

한 회사가 AWS에서 전자상거래 웹 애플리케이션을 구축하고 있습니다. 이 애플리케이션은 새로운 주문에 대한 정보를 Amazon API Gateway REST API로 보내 처리합니다. 이 회사는 주문이 수신된 순서대로 처리되도록 하려고 합니다.
어떤 솔루션이 이러한 요구 사항을 충족할까요?

• A. API Gateway 통합을 사용하여 애플리케이션이 주문을 받으면 Amazon Simple Notification Service(Amazon SNS) 토픽에 메시지를 게시합니다. 처리를 수행하기 위해 AWS Lambda 함수를 토픽에 구독합니다.
• B. API Gateway 통합을 사용하여 애플리케이션이 주문을 받으면 Amazon Simple Queue Service(Amazon SQS) FIFO 대기열에 메시지를 보냅니다. 처리를 위해 AWS Lambda 함수를 호출하도록 SQS FIFO 대기열을 구성합니다.
• C. API Gateway 권한 부여자를 사용하여 애플리케이션이 주문을 처리하는 동안 모든 요청을 차단합니다.
• D. API Gateway 통합을 사용하여 애플리케이션이 주문을 받을 때 Amazon Simple Queue Service(Amazon SQS) 표준 대기열에 메시지를 보냅니다. 처리를 위해 AWS Lambda 함수를 호출하도록 SQS 표준 대기열을 구성합니다.

Amazon SQS FIFO 대기열 : 메시지를 수신한 순서대로 처리할 수 있도록 보장