No46.
솔루션 아키텍트는 AWS에서 호스팅될 새 애플리케이션을 위한 클라우드 아키텍처를 생성하는 책임이 있습니다. 처리할 작업의 수가 추가 및 제거된 응용 프로그램 노드의 수를 지시하여 프로세스를 병렬화해야 합니다. 상태는 프로세서 프로그램에 의해 유지되지 않습니다. 솔루션 설계자는 응용 프로그램이 느슨하게 연결되어 있고 작업 항목이 지속적으로 유지되도록 보장해야 합니다.
솔루션 설계자는 어떤 디자인을 사용해야 합니까?
A. 처리해야 하는 작업을 보낼 Amazon SNS 주제를 생성합니다. 프로세서 애플리케이션으로 구성된 Amazon 머신 이미지(AMI)를 생성합니다. AMI를 사용하는 시작 구성을 생성합니다. 시작 구성을 사용하여 Auto Scaling 그룹을 생성합니다. CPU 사용량에 따라 노드를 추가 및 제거하도록 Auto Scaling 그룹에 대한 조정 정책을 설정합니다.
B. 처리해야 하는 작업을 보관할 Amazon SQS 대기열을 생성합니다. 프로세서 애플리케이션으로 구성된 Amazon 머신 이미지(AMI)를 생성합니다. AMI를 사용하는 시작 구성을 생성합니다. 시작 구성을 사용하여 Auto Scaling 그룹을 생성합니다. Auto Scaling 그룹의 scaling 정책을 설정하여 네트워크 사용량에 따라 노드를 추가 및 제거합니다.
C. 처리해야 하는 작업을 보관할 Amazon SQS 대기열을 생성합니다. 프로세서 애플리케이션으로 구성된 Amazon 머신 이미지(AMI)를 생성합니다. AMI를 사용하는 시작 템플릿을 생성합니다. 시작 템플릿을 사용하여 Auto Scaling 그룹을 생성합니다. SQS 대기열의 항목 수에 따라 노드를 추가 및 제거하도록 Auto Scaling 그룹에 대한 조정 정책을 설정합니다.
D. 처리해야 하는 작업을 보낼 Amazon SNS 주제를 생성합니다. 프로세서 애플리케이션으로 구성된 Amazon 머신 이미지(AMI)를 생성합니다. AMI를 사용하는 시작 템플릿을 생성합니다. 시작 템플릿을 사용하여 Auto Scaling 그룹을 생성합니다. SNS 주제에 게시된 메시지 수에 따라 노드를 추가 및 제거하도록 Auto Scaling 그룹에 대한 조정 정책을 설정합니다.
C
문제에서 '처리할 작업의 수가 추가 및 제거된 응용 프로그램 노드의 수' 및 '느슨하게 연결'을 주목해야 합니다. 먼저 '느슨하게'를 의미하는 것은 SQS 서비스입니다. 또한 '처리할 작업의 수가 추가 및 제거된 응용 프로그램 노드의 수'는 SQS 대기열의 항목 수에 따라 노드를 조정하는 것이 적절합니다.
A, D - SNS는 하나의 요청을 여러 곳으로 보내는 서비스이므로 적절하지 않습니다.
No47.
한 기업이 Amazon S3 버킷에 저장될 파일 공유 애플리케이션을 구축하고 있습니다. 회사는 Amazon CloudFront를 사용하여 모든 파일을 배포하려고 합니다. 회사는 파일이 S3 URL을 통해 직접 사용 가능한 것을 원하지 않습니다.
이러한 기준이 충족되도록 솔루션 설계자는 어떤 조치를 취해야 합니까?
A. 각 S3 버킷에 대한 개별 정책을 작성하여 CloudFront 액세스에 대해서만 읽기 권한을 부여하십시오.
B. IAM 사용자를 생성합니다. 사용자에게 S3 버킷의 객체에 대한 읽기 권한을 부여합니다. CloudFront에 사용자를 할당합니다.
C. CloudFront 배포 ID를 보안 주체로 할당하고 대상 S3 버킷을 Amazon 리소스 이름(ARN)으로 할당하는 S3 버킷 정책을 작성합니다.
D. 원본 액세스 ID(OAI)를 생성합니다. CloudFront 배포에 OAI를 할당합니다. OAI만 읽기 권한을 갖도록 S3 버킷 권한을 구성합니다.
D
문제의 핵심은 'S3의 파일을 URL 통해 사용자가 직접 사용하지 않도록 하는 것'입니다. 이를 방지하기 위해서는 Origin Access ID(OAI)를 사용하면 간단하게 해결됩니다. 이를 통하면 사용자는 URL을 통해 S3 버킷에 직접 액세스하는 것이 아닌, CloudFront를 통해서만 파일에 액세스가 가능합니다.
참고 : https://aws.amazon.com/ko/premiumsupport/knowledge-center/cloudfront-access-to-amazon-s3/
No48.
기업 내부의 수많은 비즈니스 프로세스는 파일 공유에 보관된 데이터에 액세스해야 합니다. 파일 공유는 SMB(서버 메시지 블록) 프로토콜을 사용하여 비즈니스 시스템에서 액세스합니다. 파일 공유 솔루션은 기업의 온프레미스 및 클라우드 환경 모두에서 사용할 수 있어야 합니다.
비즈니스에 필요한 서비스는 무엇입니까? (2개를 선택하세요.)
A. Amazon Elastic Block Store (Amazon EBS)
B. Amazon Elastic File System (Amazon EFS)
C. Amazon FSx for Windows
D. Amazon S3
E. AWS Storage Gateway file gateway
C,E
문제의 핵심은 'SMB 프로토콜을 사용해 회사 시스템에서 액세스'입니다. Windows 용 AWS FSx는 SMB/NTFS 프로토콜을 기반으로 하기에 적절합니다. 또한 비교적 최신 서비스인 AWS Storage GW File GW는 사용자가 온프레미스에서 Windows 용 AWS FSx에 액세스할 수 있도록 합니다.
A - 온프레미스에 액세스 불가합니다.
B - EFS는 NFS 프로토콜에 사용됩니다. 또한 EFS는 온프레미스에 액세스 시 Direct Connect(DX) 혹은 Site to Site VPN을 통해 가능합니다.
No49.
기업은 Amazon EC2 인스턴스 집합을 활용하여 온프레미스 데이터 원본에서 데이터를 수집하고 있습니다. 데이터는 JSON 형식이며 최대 1MB/s의 속도로 수집될 수 있습니다. EC2 인스턴스가 다시 시작되면 전송 중이던 모든 데이터가 손실됩니다. 조직의 데이터 과학 팀은 가져온 데이터를 거의 실시간으로 쿼리 하려고 합니다.
확장 가능하고 데이터 손실을 최소화하면서 실시간에 가까운 데이터 쿼리를 가능하게 하는 방법은 무엇입니까?
A. Amazon Kinesis Data Streams에 데이터를 게시합니다. Kinesis Data Analytics를 사용하여 데이터를 쿼리 합니다.
B. Amazon Redshift를 대상으로 하여 Amazon Kinesis Data Firehose에 데이터를 게시합니다. Amazon Redshift를 사용하여 데이터를 쿼리 합니다.
C. 수집된 데이터를 EC2 인스턴스 스토어에 저장합니다. Amazon S3를 대상으로 하여 Amazon Kinesis Data Firehose에 데이터를 게시합니다. Amazon Athena를 사용하여 데이터를 쿼리 합니다.
D. 수집된 데이터를 Amazon Elastic Block Store(Amazon EBS) 볼륨에 저장합니다. Redis 용 Amazon ElastiCache에 데이터를 게시합니다. Redis 채널을 구독하여 데이터를 쿼리 하세요.
B
보기 A와 B가 굉장히 혼동되는 문제입니다. 문제를 잘 읽어보시면 기업은 데이터를 '거의 실시간'으로 쿼리 하며, 데이터 손실을 최소화하기를 원하고 있습니다. 이때 보기 A가 애매한 이유는 '데이터 손실' 부분입니다. 보기 A의 Kinesis Data Streams는 데이터를 실시간으로 수집하는 서비스로, 수집된 데이터를 1~7일(최대 365일) 동안만 저장됩니다. 때문에 EC2 중단 시 수집된 데이터가 손실될 수 있으므로 틀렸습니다. 보기 B는 요구를 모두 충족합니다. Firehose는 확장 가능하며, 요구에 따라 '거의 실시간'으로 데이터를 처리합니다. 또한 데이터가 손실되지 않도록 Redshift에 데이터를 전송하며, Redshift에는 데이터 분석을 위한 쿼리를 수행하기 위해 SQL 인터페이스도 존재합니다.
문제에 명시된 '거의 실시간'은 '실시간'과 다른 의미입니다. Kinesis Data Streams 및 Kinesis Data Analytics는 '실시간' 수집 및 분석을 수행합니다.
참고 : https://aws.amazon.com/ko/redshift/features/ - (Amazon Kinesis Data Firehose는 거의 실시간에 가까운 분석을 위해 스트리밍 데이터를 캡처하고 변환하여 Amazon Redshift에 로드할 수 있는 가장 쉬운 방법입니다.)
No50.
비즈니스는 테라바이트 규모의. csv 파일에서 실행되고 몇 개월 분량의 데이터를 포함하는 기존의 온프레미스 분석 솔루션에 의존합니다. 이전 프로그램은 증가하는. csv 파일 크기에 대처할 수 없습니다. 매일 new.csv 파일이 수많은 데이터 소스에서 공통 온프레미스 스토리지 사이트에 업로드됩니다. 조직은 고객이 AWS 분석 기능에 익숙해지는 동안 기존 애플리케이션에 대한 지원을 유지하기를 원합니다. 이를 위해 솔루션 설계자는 all.csv 파일의 동기화된 사본 두 개를 온프레미스와 Amazon S3에 보관하려고 합니다.
솔루션 설계자는 어떤 솔루션을 권장해야 합니까?
A. AWS DataSync를 온프레미스에 배포합니다. 회사의 온프레미스 스토리지와 회사의 S3 버킷 간에. csv 파일을 지속적으로 복제하도록 DataSync를 구성합니다.
B. 온프레미스 파일 게이트웨이를 배포합니다. .csv 파일을 파일 게이트웨이에 쓰도록 데이터 원본을 구성합니다. 레거시 분석 애플리케이션이 파일 게이트웨이를 가리키도록 합니다. 파일 게이트웨이는. csv 파일을 Amazon S3에 복제해야 합니다.
C. 온프레미스 볼륨 게이트웨이를 배포합니다. .csv 파일을 볼륨 게이트웨이에 쓰도록 데이터 소스를 구성합니다. 레거시 분석 애플리케이션이 볼륨 게이트웨이를 가리키도록 합니다. 볼륨 게이트웨이는 데이터를 Amazon S3에 복제해야 합니다.
D. AWS DataSync를 온프레미스에 배포합니다. 온프레미스와 Amazon Elastic File System(Amazon EFS) 간에. csv 파일을 지속적으로 복제하도록 DataSync를 구성합니다. Amazon Elastic File System(Amazon EFS)에서 회사의 S3 버킷으로 복제를 활성화합니다.
A
Examtopic 사이트에서도 A와 B가 많이 혼동되고 있습니다. 하지만 문제를 명확하게 파악하면 해결할 수 있습니다. 문제의 핵심은 '사본 2개'를 온프레미스와 AWS S3에 각각 하나씩 보관하는 것입니다. 이때 이미 온프레미스에는 1개의 사본이 존재하며, 나머지 1개의 사본을 S3에 저장함으로 완성할 수 있는 것입니다. 온프레미스에서 AWS 스토리지로 데이터를 마이그레이션할 때 DataSync는 훌륭한 선택입니다. 또한 보기 A의 마지막에 있는 'S3 버킷 간에 csv 파일을 지속적으로 복제하도록 DataSync를 구성' 이 말 때문에 Examtopic 사이트에서도 B의 File GW를 선택하여 온프레미스와 AWS 스토리지의 액세스를 한다는 선택을 하곤 합니다. 하지만, 이는 잘못된 지식이며,DataSync는 데이터 덩어리를 한번 마이그레이션 하는 것뿐만 아니라 이후의 증분 되는 데이터 처리를 위해서 '동기화'를 할 수 있습니다.
마지막으로, 문제에서 요구하는 것은 '동기화'가 아닌 '데이터 사본을 S3에 저장한다'이므로, 문제의 핵심을 파악하는 것이 정답의 지름길입니다.
참고 : https://aws.amazon.com/ko/blogs/storage/synchronizing-your-data-to-amazon-s3-using-aws-datasync/
No51.
한 기업이 3계층 애플리케이션을 Amazon Web Services로 이전하고 있습니다. 프로그램에는 MySQL 데이터베이스가 필요합니다. 이전에는 응용 프로그램 사용자가 새 항목을 추가하는 동안 프로그램의 느린 성능에 대해 불평했습니다. 이러한 성능 문제는 사용자가 업무 시간 동안 프로그램에서 다양한 실시간 보고서를 생성한 결과 발생했습니다.
AWS로 마이그레이션할 때 애플리케이션의 성능을 최적화하는 솔루션은 무엇입니까?
A. 프로비저닝된 용량이 있는 Amazon DynamoDB 테이블로 데이터를 가져옵니다. 보고서에 DynamoDB를 사용하도록 애플리케이션을 리팩터링합니다.
B. 컴퓨팅 최적화 Amazon EC2 인스턴스에 데이터베이스를 생성합니다. 컴퓨팅 리소스가 온프레미스 데이터베이스를 초과하는지 확인합니다.
C. 여러 읽기 전용 복제본이 있는 Amazon Aurora MySQL 다중 AZ DB 클러스터를 생성합니다. 보고서에 리더 엔드포인트를 사용하도록 애플리케이션을 구성합니다.
D. Amazon Aurora MySQL 다중 AZ DB 클러스터를 생성합니다. 클러스터의 백업 인스턴스를 보고서의 끝점으로 사용하도록 애플리케이션을 구성합니다.
C
문제에서 애플리케이션을 AWS로 이전하는데, 이때 데이터베이스를 MySQL로 사용하기를 원합니다. Aurora는 MySQL 및 PostgreSQL과 호환이 가능합니다. Aurora의 엔드포인트에는 Cluster와 Reader 및 Instance가 있습니다. 그중 Reader 엔드포인트는 사용 가능한 읽기 전용 복제본 풀 전체에 걸쳐 연결 부하를 분산합니다. 여기에서 읽기 쿼리를 오프로드하여 기본 DB 인스턴스의 로드를 줄여 성능을 향상시킵니다.
D - 클러스터의 '백업' 인스턴스는 엔드포인트에 존재하지 않습니다.
Cluster Endpoint - 클러스터 엔드포인트는 애플리케이션을 해당 DB 클러스터의 현재 기본 DB 인스턴스에 연결합니다. 애플리케이션은 이 인스턴스를 읽고 쓸 수 있습니다. Instance Endpoint - 인스턴스 엔드포인트는 클러스터의 특정 인스턴스에 연결합니다. 클라이언트는 Amazon Aurora가 연결 배포를 처리하도록 하는 대신 쿼리 할당을 세부적으로 제어할 수 있습니다.
No52.
한 기업에 전 세계 영업 직원이 자주 사용하지 않는 사내 MySQL 데이터베이스가 있습니다. 영업 팀은 데이터베이스 다운타임이 거의 필요하지 않습니다. 데이터베이스 관리자는 앞으로 증가하는 사용자 트래픽 앞에서 인스턴스 유형을 지정하지 않고 이 데이터베이스를 AWS로 이동하려고 합니다.
어떤 솔루션 아키텍트 서비스를 권장해야 합니까?
A. Amazon Aurora MySQL
B. Amazon Aurora Serverless for MySQL
C. Amazon Redshift Spectrum
D. Amazon RDS for MySQL
B
문제의 핵심은 '인스턴스 유형을 지정하지 않고'입니다. Aurora Serverless를 사용하면 데이터베이스 인스턴스 유형을 지정하지 않고 시작이 가능합니다. 또한 문제에 명시된 '간헐적 액세스'에도 적합한 서비스로 사용량이 없을 땐 값을 지불하지 않습니다. Aurora Serverless의 Auto Scaling은 일반적으로 30초 이내의 다운 타임이 걸려 배포되지만, 문제에선 다운타임을 신경 쓰지 않으니 이를 고려하지 않아도 됩니다.
A - Aurora는 인스턴스 유형을 지정해야 합니다. 참고로 Aurora Auto Scaling에는 가동 중지 시간이 없습니다.
참고 : https://www.techtarget.com/searchcloudcomputing/answer/When-should-I-use-Amazon-RDS-vs-Aurora-Serverless
No53.
A사는 소비자에게 최소한의 지연이 필요한 모바일 애플리케이션용 아키텍처를 개발하고 있다. 이 회사의 아키텍처는 자동 확장 그룹에서 작동하도록 구성된 애플리케이션 로드 밸런서를 통해 라우팅 되는 Amazon EC2 인스턴스로 구성되어 있습니다. Amazon EC2 인스턴스는 Amazon RDS와 통신합니다. 응용 프로그램의 베타 테스트 결과 데이터를 읽는 동안 속도가 느립니다. 그러나 데이터는 EC2 인스턴스가 CPU 사용량 기준을 초과하지 않음을 시사합니다.
어떻게 이 문제를 해결할 수 있나요?
A. 자동 확장 그룹에서 CPU 활용률 임계값을 줄입니다.
B. 애플리케이션 로드 밸런서를 네트워크 로드 밸런서로 교체합니다.
C. RDS 인스턴스에 대한 읽기 복제본을 추가하고 읽기 트래픽을 복제본으로 보냅니다.
D. RDS 인스턴스에 Multi-AZ 지원을 추가하고 읽기 트래픽을 새 EC2 인스턴스로 보냅니다.
C
문제의 마지막에 EC2의 CPU는 사용량을 초과하지 않았다고 하므로, CPU에는 문제가 없습니다. 단지 RDS DB의 읽는 속도가 느린 문제입니다. 이는 읽기 복제본을 사용하여 DB의 읽기 작업을 분산하면 적절합니다.
No54.
비즈니스의 애플리케이션 아키텍처는 2계층으로 되어 있으며 공용 서브넷과 사설 서브넷에 분산되어 있습니다. 퍼블릭 서브넷에는 웹 애플리케이션을 실행하는 Amazon EC2 인스턴스가 포함되어 있는 반면 프라이빗 서브넷에는 데이터베이스가 있습니다. 웹 애플리케이션 인스턴스와 데이터베이스는 모두 단일 가용 영역(AZ)에 포함됩니다.
솔루션 설계자는 이 아키텍처의 고가용성을 보장하기 위해 어떤 조치를 취해야 합니까? (2개를 선택하세요.)
A. 고가용성을 위해 동일한 AZ에 새 퍼블릭 및 프라이빗 서브넷을 생성합니다.
B. 여러 AZ에 걸쳐 Amazon EC2 Auto Scaling 그룹 및 Application Load Balancer를 생성합니다.
C. Application Load Balancer 뒤의 Auto Scaling 그룹에 기존 웹 애플리케이션 인스턴스를 추가합니다.
D. 새 AZ에 새 퍼블릭 및 프라이빗 서브넷을 생성합니다. 하나의 AZ에서 Amazon EC2를 사용하여 데이터베이스를 생성합니다.
E. 동일한 VPC에서 각각 새 AZ에 새 퍼블릭 및 프라이빗 서브넷을 생성합니다. 데이터베이스를 Amazon RDS 다중 AZ 배포로 마이그레이션합니다.
B,E
기업의 아키텍처는 2계층으로 각각 웹 애플리케이션을 구동 중인 EC2와, 이를 저장하는 데이터베이스로 구성되어 있습니다. 이때 두 서비스는 각각 퍼블릭, 프라이빗에 위치하여 있으며, 둘 다 '단일 AZ'로 구성되어 있습니다. 이를 고가용성을 보장하기 위해선 '단일 AZ'인 두 서비스 모두에게 '다중 AZ'를 구성해 줘야 합니다. 그렇기에 보기 B의 다중 AZ에 ALB를 통해 웹 애플리케이션을 로드밸런싱 하면 되며, 보기 E 또한 RDS DB를 다중 AZ를 통해 배포하면 적절합니다.
No55.
기업은 Amazon S3를 온프레미스 데이터 세트의 보조 스토리지 위치로 활용하려고 합니다. 회사에서 이 사본에 액세스할 필요가 거의 없습니다. 스토리지 솔루션의 비용은 최소로 유지되어야 합니다.
이 기준을 충족하는 스토리지 옵션은 무엇입니까?
A. S3 표준
B. S3 지능형 계층화
C. S3 Standard-Infrequent Access(S3 Standard-IA)
D. S3 One Zone-Infrequent Access(S3 One Zone-IA)
D
스토리지 옵션에 대한 문제 유형입니다. 기업엔 이미 온프레미스에 데이터 세트가 있으며, S3에 보조로 사본을 하나 더 만들어 보관하려 합니다. 이때 '자주 액세스하지 않음' 및 '비용을 최소'라는 조건이 있으며, '복원력'에 대한 언급이 없기에 S3 One Zone-IA를 사용하면 적절합니다.
C - '가용성'과 '복원력'이 필요할 때 적절합니다.
No56.
팀의 모든 AWS 계정에서 특정 서비스 또는 활동에 대한 액세스를 제한하는 책임이 있는 보안 팀. AWS Organizations의 모든 계정은 거대한 조직의 일부입니다.
솔루션은 확장 가능해야 하며 권한은 중앙에서 관리되어야 합니다.
솔루션 설계자는 이를 달성하기 위해 어떤 조치를 취해야 합니까?
A. 서비스 또는 작업에 대한 액세스를 제공하기 위해 ACL을 생성합니다.
B. 계정을 허용하는 보안 그룹을 생성하고 이를 사용자 그룹에 연결합니다.
C. 각 계정에 교차 계정 역할을 만들어 서비스 또는 작업에 대한 액세스를 거부합니다.
D. 루트 조직 단위에서 서비스 제어 정책(SCP)을 만들어 서비스 또는 작업에 대한 액세스를 거부합니다.
D
서비스 제어 정책(SCP)는 조직을 관리하는 데 사용할 수 있는 정책 유형입니다. SCP는 조직의 모든 계정에 대해 사용 가능한 최대 권한에 대해 중앙 제어를 제공하므로 계정이 조직의 액세스 제어 정책(SCP)를 준수하도록 할 수 있습니다. 이때 SCP 단독으로 권한을 부여하는 것은 아니며, IAM 및 리소스 기반 정책이 허용하는 권한과의 논리적 교집합으로 권한 범위가 설정됩니다.
참고 : https://docs.aws.amazon.com/ko_kr/organizations/latest/userguide/orgs_manage_policies_scps.html
No57.
비즈니스에는 타사 공급업체로부터 거의 실시간으로 데이터를 검색할 수 있는 REST 기반 인터페이스가 있는 응용 프로그램이 있습니다. 데이터를 수신한 후 프로그램은 추가 분석을 위해 분석하고 저장합니다. Amazon EC2 인스턴스는 애플리케이션을 호스팅 하는 데 사용됩니다.
프로그램에 데이터를 전달할 때 타사 공급업체는 많은 503 서비스를 사용할 수 없음 오류를 확인했습니다. 데이터 볼륨이 증가하면 컴퓨팅 용량이 한계에 도달하고 애플리케이션이 모든 요청을 처리할 수 없게 됩니다.
확장성을 높이기 위해 솔루션 설계자는 어떤 설계를 옹호해야 합니까?
A. Amazon Kinesis Data Streams를 사용하여 데이터를 수집합니다. AWS Lambda 함수를 사용하여 데이터를 처리합니다.
B. 기존 애플리케이션 위에 Amazon API Gateway를 사용합니다. 타사 공급업체에 대한 할당량 제한이 있는 사용 계획을 만듭니다.
C. Amazon Simple Notification Service(Amazon SNS)를 사용하여 데이터를 수집합니다. EC2 인스턴스를 Application Load Balancer 뒤에 있는 Auto Scaling 그룹에 넣습니다.
D. 애플리케이션을 컨테이너로 다시 패키징 합니다. Auto Scaling 그룹과 함께 EC2 시작 유형을 사용하여 Amazon Elastic Container Service(Amazon ECS)를 사용하여 애플리케이션을 배포합니다.
A
Kinesis Data Streams(KDS)은 Lambda와 함께 연결되어 처리 작업을 수행 가능합니다. KDS는 데이터 수집을 위해 1-7일(최대 365일) 동안 저장이 가능하여 공급업체가 수신하는 503 오류를 줄임으로 Lambda가 처리할 수 있는 충분한 시간을 제공합니다. 또한 Lambda는 확장이 가능합니다.
No58.
한 비즈니스에서 상점 선반에 있는 품목의 야간 디지털 사진을 사용하여 재고 데이터를 분석하는 애플리케이션을 개발했습니다. 애플리케이션은 ALB(Application Load Balancer) 뒤의 Amazon EC2 인스턴스에 배포되고 작업자 노드의 메타데이터 처리를 위해 Amazon S3 버킷에서 사진을 검색합니다. 솔루션 설계자는 작업자 노드가 각 그림을 처리하도록 보장해야 합니다.
솔루션 설계자는 가능한 가장 비용 효율적인 방식으로 이러한 요구 사항을 충족하기 위해 어떤 조치를 취해야 합니까?
A. 애플리케이션의 이미지 메타데이터를 EC2 스팟 인스턴스의 Auto Scaling 그룹을 대상 그룹으로 사용하는 작업자 노드의 두 번째 ALB로 직접 보냅니다.
B. Auto Scaling 그룹의 EC2 예약 인스턴스로 직접 전송하여 이미지 메타데이터를 처리합니다. 동적 조정 정책에서는 프런트 엔드 애플리케이션이 이미지를 가져오는 즉시 Auto Scaling 그룹의 평균 CPU 사용률에 대해 Amazon CloudWatch 지표를 사용합니다.
C. 프런트 엔드 애플리케이션이 이미지를 얻을 때 Amazon Simple Queue Service(Amazon SQS)에 메시지를 씁니다. 인스턴스 축소 보호 기능이 있는 Auto Scaling 그룹의 EC2 온디맨드 인스턴스와 정기적인 상태 확인을 통해 고정된 수의 인스턴스로 이미지를 처리합니다.
D. 애플리케이션이 이미지를 얻을 때 Amazon Simple Queue Service(Amazon SQS)에 메시지를 씁니다. 대기열의 현재 메시지 수에 대한 사용자 지정 Amazon CloudWatch 지표를 사용하여 인스턴스 축소 보호 및 동적 조정 정책이 있는 Auto Scaling 그룹의 EC2 스팟 인스턴스로 이미지를 처리합니다.
D
문제의 핵심은 '작업 노드가 모든 이미지를 처리하도록 보장'입니다. SQS는 메시지가 손실되지 않았는지 확인합니다(14일까지). 따라서 보기 C와 D 중에 답이 있습니다. 이는 온디맨드 혹은 스팟 인스턴스 중에 선택해야 합니다. 문제의 '야간작업'은 중요하지 않음을 의미하는 것이 절대 아닙니다. 때문에 중단의 위험이 있는 '스팟 인스턴스'는 원래 옳지 않지만, SQS와 함께라면 이를 최대의 비용 효율을 내며 정상 워크 로드 작업을 수행할 수 있습니다. 만약 스팟 인스턴스가 중단된다 하더라도 SQS의 대기열에서 메시지를 가지고 있기 때문입니다.
참고 : https://aws.amazon.com/vi/blogs/compute/running-cost-effective-queue-workers-with-amazon-sqs-and-amazon-ec2-spot-instances/ - Amazon SQS 및 Amazon EC2 스팟 인스턴스로 비용 효율적인 대기열 작업자 실행
No59.
us-east-1 리전에서 회사에는 Development, Testing 및 Production으로 지정된 3개의 VPC가 있습니다. 3개의 가상 사설 클라우드는 온프레미스 데이터 센터에 연결되어야 하며 보안을 보장하고 리소스 공유를 피하기 위해 독립적이어야 합니다. 솔루션 설계자는 확장 가능하고 안전한 솔루션을 식별해야 합니다.
솔루션 설계자는 어떤 권장 사항을 제시해야 합니까?
A. 데이터 센터에 다시 연결할 각 VPC에 대해 AWS Direct Connect 연결 및 VPN 연결을 생성합니다.
B. 모든 VPC에서 프로덕션 VPC로 VPC 피어를 생성합니다. 프로덕션 VPC에서 데이터 센터로 다시 AWS Direct Connect 연결을 사용합니다.
C. 모든 VPC의 VPN 연결을 프로덕션 VPC의 VPN으로 연결합니다. 프로덕션 VPC에서 데이터 센터로 다시 VPN 연결을 사용합니다.
D. 네트워크라는 새 VPC를 생성합니다. 네트워크 VPC 내에서 데이터 센터에 대한 AWS Direct Connect 연결을 사용하여 AWS Transit Gateway를 생성합니다. 다른 모든 VPC를 네트워크 VPC에 연결합니다.
A
문제의 핵심은 '겹치지 않는 리소스'입니다. 이는 각각의 VPC는 독립적일 것을 요구합니다. 세 개의 VPC에 대해서 Direct Connect(DX)를 연결하면 처음 구성 시 세 개 모두 DX에 중복됩니다. 하지만 후 작업을 통해 VPN을 연결하면 각 VPC는 보안을 충족하게 됩니다.
D - '새 네트워크 VPC 생성'이 틀렸습니다. Transit Gateway를 사용하려면 3개의 VPC를 모두 Transit GW의 라우팅 테이블에 연결해야 합니다. 참고로 Transit GW는 DX에 연결하여 VPC 전체에서 리소스를 격리하는 데 사용할 수 있으며, 확장 가능한 방법입니다.
참고 : https://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-vpc-connectivity-options/aws-direct-connect-vpn.html - AWS Direct Connect + VPN
No60.
기업은 애플리케이션을 위한 신뢰할 수 있는 아키텍처를 개발하기 위해 솔루션 설계자의 서비스를 유지했습니다. 애플리케이션은 단일 Amazon RDS 데이터베이스 인스턴스와 웹 서버를 실행하는 수동 배포 Amazon EC2 인스턴스 2개로 구성됩니다. 단일 가용 영역에는 모든 EC2 인스턴스가 포함됩니다.
직원이 최근에 데이터베이스 인스턴스를 제거하여 애플리케이션이 24시간 동안 오프라인 상태가 되었습니다. 회사는 환경의 일반적인 신뢰성에 관심이 있습니다.
솔루션 설계자는 애플리케이션의 인프라를 가능한 한 안정적으로 유지하기 위해 무엇을 해야 합니까?
A. 하나의 EC2 인스턴스를 삭제하고 다른 EC2 인스턴스에서 종료 방지를 활성화합니다. DB 인스턴스를 다중 AZ로 업데이트하고 삭제 방지를 활성화합니다.
B. DB 인스턴스를 다중 AZ로 업데이트하고 삭제 방지를 활성화합니다. EC2 인스턴스를 Application Load Balancer 뒤에 배치하고 여러 가용 영역에 걸쳐 EC2 Auto Scaling 그룹에서 실행합니다.
C. Amazon API Gateway 및 AWS Lambda 함수와 함께 추가 DB 인스턴스를 생성합니다. API Gateway를 통해 Lambda 함수를 호출하도록 애플리케이션을 구성합니다. Lambda 함수가 두 DB 인스턴스에 데이터를 쓰도록 합니다.
D. 여러 가용 영역에 여러 서브넷이 있는 EC2 Auto Scaling 그룹에 EC2 인스턴스를 배치합니다. 온디맨드 인스턴스 대신 스팟 인스턴스를 사용합니다. 인스턴스의 상태를 모니터링하도록 Amazon CloudWatch 경보를 설정합니다. DB 인스턴스를 다중 AZ로 업데이트하고 삭제 방지를 활성화합니다.
B
문제의 요지는 '고가용성'입니다. 이는 두 인스턴스가 중단되지 않기를 원하는 말입니다. 각각의 EC2 인스턴스와 DB 인스턴스에 대해서 '다중 AZ'를 구성하면 됩니다.
D - 스팟 인스턴스는 언제든지 종료될 위험이 있으므로 이는 안정적인 유지에 적합하지 않습니다.
No61.
AWS에서 비즈니스는 전자 상거래 웹 사이트의 프로토타입을 개발 중입니다. 이 웹 사이트는 Amazon Auto Scaling 사업부의 Application Load Balancer로 구동됩니다.
단일 AZ 모드로 구성된 웹 서버용 EC2 인스턴스 및 MySQL 용 Amazon RDS 데이터베이스 인스턴스.
웹 사이트는 제품 카탈로그 검색을 수행하는 동안 반응이 느립니다. 제품 카탈로그는 회사가 제품을 저장하는 데 사용하는 MySQL 데이터베이스의 테이블 모음입니다.
정기적으로 업데이트되지 않습니다. 솔루션 설계자는 제품 카탈로그 검색이 발생할 때 데이터베이스 인스턴스의 CPU 사용량이 상당하다는 것을 확인했습니다.
솔루션 설계자는 제품 카탈로그 검색 중 웹사이트 성능을 최적화하기 위해 무엇을 제안해야 합니까?
A. 제품 카탈로그를 Amazon Redshift 데이터베이스로 마이그레이션합니다. COPY 명령을 사용하여 제품 카탈로그 테이블을 로드하십시오.
B. Redis 용 Amazon ElastiCache 클러스터를 구현하여 제품 카탈로그를 캐시 합니다. 캐시를 채우려면 지연 로딩을 사용하십시오.
C. Auto Scaling 그룹에 추가 조정 정책을 추가하여 데이터베이스 응답이 느릴 때 추가 EC2 인스턴스를 시작합니다.
D. DB 인스턴스에 대한 다중 AZ 구성을 켭니다. 데이터베이스로 전송되는 제품 카탈로그 쿼리를 조절하도록 EC2 인스턴스를 구성합니다.
B
현재 발생되는 문제점은 애플리케이션의 카탈로그 검색 시, 데이터베이스에 저장된 카탈로그 목록을 찾는 중 발생되는 CPU 사용량이 많다는 점입니다. 이를 해결하기 위해서는 ElastiCache를 사용하면 됩니다. ElastiCache는 액세스하는 애플리케이션과 데이터 스토어(데이터베이스) 사이에 위치하는 인 메모리 키/값 저장소입니다. ElastiCache를 사용하면 애플리케이션에서 데이터를 요청할 때마다 데이터베이스에 요청을 하는 것이 아닌 ElastiCache의 캐시에 먼저 요청합니다. 요청된 데이터가 캐시에 있는 경우 바로 데이터를 반환하며, 만약 캐시에 요청된 데이터가 없는 경우 데이터베이스로 넘어가 데이터를 찾아 반환합니다. 이때, 한번 데이터베이스에서 반환된 데이터는 캐시에 남기 때문에 다음 요청 시 더 빠른 속도로 데이터 검색이 가능합니다.
No62.
한 기업이 내장된 자격 증명을 활용하여 Amazon RDS MySQL DB 인스턴스에서 데이터를 가져오는 맞춤형 애플리케이션을 개발했습니다. 경영진에 따르면 최소한의 개발 작업으로 애플리케이션의 보안을 강화해야 합니다.
이러한 기준이 충족되도록 솔루션 설계자는 어떤 조치를 취해야 합니까?
A. AWS Key Management Service(AWS KMS) 고객 마스터키(CMK)를 사용하여 키를 생성합니다. AWS KMS에서 데이터베이스 자격 증명을 로드하도록 애플리케이션을 구성합니다. 자동 키 회전을 활성화합니다.
B. RDS for MySQL 데이터베이스에서 애플리케이션 사용자에 대한 자격 증명을 생성하고 AWS Secrets Manager에 자격 증명을 저장합니다. Secrets Manager에서 데이터베이스 자격 증명을 로드하도록 애플리케이션을 구성합니다. Secret Manager에서 자격 증명을 교체하는 AWS Lambda 함수를 생성합니다.
C. RDS for MySQL 데이터베이스에서 애플리케이션 사용자에 대한 자격 증명을 생성하고 AWS Secrets Manager에 자격 증명을 저장합니다. Secrets Manager에서 데이터베이스 자격 증명을 로드하도록 애플리케이션을 구성합니다. Secrets Manager를 사용하여 MySQL 용 RDS 데이터베이스에서 애플리케이션 사용자에 대한 자격 증명 교체 일정을 설정합니다.
D. RDS for MySQL 데이터베이스에서 애플리케이션 사용자에 대한 자격 증명을 생성하고 AWS Systems Manager Parameter Store에 해당 자격 증명을 저장합니다. Parameter Store에서 데이터베이스 자격 증명을 로드하도록 애플리케이션을 구성합니다. Parameter Store를 사용하여 MySQL 용 RDS 데이터베이스에서 애플리케이션 사용자에 대한 자격 증명 교체 일정을 설정합니다.
C
기업은 데이터베이스의 보안을 강화하기를 원하고 있습니다. Secrets Manager는 암호화해야 하는 기밀 정보(데이터베이스, 자격 증명, API 키)를 위한 서비스이며, 비밀 항목 생성 시 기본적으로 암호화가 활성화됩니다. 또한 키 회전과 같은 추가 기능을 제공합니다.
B - RDS 이외의 서비스의 경우 Lambda 함수를 사용해 사용자 지정 키 교체 로직을 작성할 수 있지만, 문제에서 RDS라고 명시되어 있기에 정답이 아닙니다.
D - Parameter Store와 Secrets Manager는 둘 다 자격 증명을 저장하는 데 사용할 수 있지만, Parameter Store는 키 회전 기능이 없습니다.
No63.
솔루션 설계자는 시장이 닫혀 있는 동안 금융 시장 성과를 분석하기 위한 시스템을 개발하고 있습니다. 매일 밤 시스템은 4시간 동안 연산 집약적인 작업을 연속적으로 수행합니다. 컴퓨팅 작업을 완료하는 데 필요한 시간은 일정해야 하며 한 번 시작되면 작업을 중지할 수 없습니다. 완공 후 시스템은 최소 1년 동안 운영될 예정이다.
시스템 비용을 낮추려면 어떤 Amazon EC2 인스턴스 유형을 사용해야 합니까?
A. 스팟 인스턴스
B. 온디맨드 인스턴스
C. 표준 예약 인스턴스
D. 정기 예약 인스턴스
D
문제의 핵심은 '매일 4시간' 및 '일정한 작업 완료 시간'입니다. 덧붙여 최소 1년을 운영할 거라고 명시되어 있습니다. 이는 정기 예약 인스턴스를 사용하면 가장 비용 효율적입니다. (참고로, 현재 AWS에서는 정기 예약 인스턴스를 지원하지 않습니다.)
C - 하루에 4시간만 사용할 것이기 때문에 적절하지 않습니다.
No64.
기업의 온프레미스 데이터 센터는 디렉터리 서비스 및 DNS와 같은 중요한 네트워크 서비스를 호스팅 합니다. AWS Direct Connect는 데이터 센터를 AWS 클라우드(DX)에 연결합니다. 이러한 네트워크 서비스에 대한 지속적이고 신속하며 비용 효율적인 액세스가 필요한 추가 AWS 계정이 예상됩니다.
이러한 기준이 가능한 최소한의 운영 오버헤드를 충족하도록 하기 위해 솔루션 설계자는 어떤 조치를 취해야 합니까?
A. 각각의 새 계정에서 DX 연결을 만드십시오. 네트워크 트래픽을 온프레미스 서버로 라우팅합니다.
B. 모든 필수 서비스에 대해 DX VPC에서 VPC 엔드포인트를 구성합니다. 네트워크 트래픽을 온프레미스 서버로 라우팅합니다.
C. 각각의 새 계정과 DX VPC 간에 VPN 연결을 생성합니다. 네트워크 트래픽을 온프레미스 서버로 라우팅합니다.
D. 계정 간에 AWS Transit Gateway를 구성합니다. DX를 전송 게이트웨이에 할당하고 네트워크 트래픽을 온프레미스 서버로 라우팅합니다.
D
AWS Transit GW는 중앙 허브를 통해 VPC와 온프레미스 네트워크를 연결합니다. Transit GW와 Direct Connect(DX)의 통합 솔루션은 프라이빗 연결을 통해 VPC와 네트워크 간의 연결 관리를 간소화합니다. 또한 네트워크 비용을 최소화하고 대역폭 처리량을 개선하여 인터넷 기반 연결보다 더 안정적인 네트워크 환경을 제공할 수 있습니다.
A, C - 새 계정을 통해 새 연결을 설정하면, 문제의 '최소한의 운영 오버헤드'를 충족하지 못합니다.
No65.
기업에서 대용량 데이터를 저장하기 위한 새로운 애플리케이션을 개발 중입니다. 시간별 데이터 분석 및 수정은 여러 가용 영역에 분산된 많은 Amazon EC2 Linux 인스턴스에서 수행됩니다. 애플리케이션 팀은 필요한 공간이 다음 6개월 동안 계속 확장될 것으로 예상합니다.
이러한 요구 사항을 충족하기 위해 솔루션 설계자는 어떤 조치를 취해야 합니까?
A. Amazon Elastic Block Store(Amazon EBS) 볼륨에 데이터를 저장합니다. 애플리케이션 인스턴스에 EBS 볼륨을 탑재합니다.
B. Amazon Elastic File System(Amazon EFS) 파일 시스템에 데이터를 저장합니다. 애플리케이션 인스턴스에 파일 시스템을 마운트 합니다.
C. Amazon S3 Glacier에 데이터를 저장합니다. 애플리케이션 인스턴스에 대한 액세스를 허용하도록 S3 Glacier 볼트 정책을 업데이트합니다.
D. 애플리케이션 인스턴스 간에 공유되는 Amazon Elastic Block Store(Amazon EBS) 프로비저닝된 IOPS 볼륨에 데이터를 저장합니다.
정답 : B
이유 : 문제의 키포인트는 '여러 AZ에 분산된 많은 인스턴스'입니다. 때문에 스토리지 솔루션은 여러 AZ에는 사용이 가능해야 합니다. AWS EFS는 온프레미스 및 클라우드에는 사용이 가능하며, 고가용성과 내구성을 위해 여러 AZ에 데이터를 저장하는 리전 서비스입니다. 또한 애플리케이션 중단 없이 페타바이트까지 온디맨드로 확장이 가능하며, 파일 추가 및 제거 시 자동으로 용량이 관리됩니다.
B
문제의 키포인트는 '여러 AZ에 분산된 많은 인스턴스'입니다. 때문에 스토리지 솔루션은 여러 AZ에는 사용이 가능해야 합니다. AWS EFS는 온프레미스 및 클라우드에는 사용이 가능하며, 고가용성과 내구성을 위해 여러 AZ에 데이터를 저장하는 리전 서비스입니다. 또한 애플리케이션 중단 없이 페타바이트까지 온디맨드로 확장이 가능하며, 파일 추가 및 제거 시 자동으로 용량이 관리됩니다.
A - EBS는 EC2 인스턴스들이 동일한 AZ 내에 있어야 사용이 가능합니다
우리 모두 문제 중간 중간 배너는 한번씩 누르면서 문제 풀어요.
관련글
'Cloud > AWS SAA 모의시험' 카테고리의 다른 글
AWS SAA 모의 시험 5th #2 (6) | 2022.08.05 |
---|---|
AWS SAA 모의 시험 5th #1 (3) | 2022.08.05 |
AWS SAA 모의 시험 4th #3 문제풀이 (1) | 2022.08.05 |
AWS SAA 모의 시험 4th #2 문제풀이 (3) | 2022.08.05 |
AWS SAA 모의 시험 4th #1 문제풀이 (0) | 2022.08.05 |