[AWS-SAA] Examtopics 141~150
![[AWS-SAA] Examtopics 141~150](/assets/img/study_AWS/saa-co2_logo.png){kind=logo}
SAA Examtopics 141~150번 문제를 풀어보자.
Prob. 141
회사는 월별 전화 기록을 유지합니다. 통계적으로 기록된 데이터는 1년 이내에 무작위로 참조될 수 있지만 해당 기간을 초과하여 검색되는 경우는 거의 없습니다. 1년 미만의 파일은 즉시 쿼리하고 검색해야 합니다. 오래된 파일을 가져오는 데 지연이 있는 것은 괜찮습니다. 솔루션 설계자는 캡처된 데이터가 가능한 가장 낮은 비용으로 저장되도록 해야 합니다.
가장 저렴한 옵션은 무엇입니까?
A. 개별 파일을 Amazon S3 Glacier에 저장하고 검색 메타데이터를 S3 Glacier 쿼리 S3 Glacier 태그에서 만든 개체 태그에 저장하고 S3 Glacier에서 파일을 검색합니다.
B. 개별 파일을 Amazon S3에 저장(store)합니다. 라이프사이클 정책을 사용하여 1년 후 파일을 Amazon S3 Glacier로 이동합니다. Amazon S3 또는 S3 Glacier에서 파일을 쿼리하고 검색합니다.
C. 개별 파일을 보관하고 각 보관에 대한 검색 메타데이터를 Amazon S3에 저장합니다. 라이프사이클 정책을 사용하여 1년 후 파일을 Amazon S3 Glacier로 이동합니다. Amazon S3에서 메타데이터를 검색하여 파일을 쿼리하고 검색합니다.
D. Amazon S3에 개별 파일을 보관(archive)합니다. 라이프사이클 정책을 사용하여 1년 후 파일을 Amazon S3 Glacier로 이동합니다. 검색 메타데이터를 Amazon DynamoDB에 저장합니다. DynamoDB에서 파일을 쿼리하고 Amazon S3 또는 S3 Glacier에서 파일을 검색합니다.
해설 : 가능한 가장 낮은 비용으로 저장 문제 요점. 월별 전화 기록을 유지. Amazon S3 Glacier 리소스에 태그 지정 태그를 사용하여 스토리지 분류 A 탈락 -> S3에만 저장한 데이터를 사용하여 개체 태그로 분류하는 메타데이터로 쿼리를 하는 것으로 1년이나 월별 기준으로 매일 업데이트해줘야하여 부적합. B 정답 -> 1년을 기준으로 쿼리할 대상을 물리적으로 다른 스토리지에 저장하며 라이프사이클로 자동으로 보내여 적합. C 탈락 -> S3에서 메타데이터로 빠르게 검색하기 위해서지만 보관만하면 사용하지 않기 때문에 1년 후 파일만 가능할 때는 메타데이터가 의미없어 부적합. D 탈락 -> 보관이기 때문에 답이 될 수 없으며 DynamoDB에 메타데이터를 저장하려면 Lambda가 필요하여 부적합.
정답 및 해설 보기
Answer : B
1년 이내에 무작위로 참조/즉시 쿼리하고 검색.
오래된 파일을 가져오는 데 지연이 있는 것.
A태그는 AWS리소스에 할당하는 레이블입니다.
사용자 정의 태그를 할당할 수 있습니다. 태그를 사용하면 간단하면서도 효과적으로 AWS 리소스를 관리하고 결제 데이터를 포함하여 데이터를 구성.
객체 태그 지정을 이용하여 스토리지를 분류합니다. 각 태그는 키-값 페어.
새 객체를 업로드할 때 태그를 덧붙이거나 기존 객체에 태그를 덧붙임.
저장한 객체에 대해 선택 쿼리를 실행.
Prob. 142
비즈니스에서 워크로드를 AWS로 이동하려고 합니다. 최고 정보 보안 책임자(CIO)는 클라우드에 저장된 모든 데이터를 미사용 시 암호화할 것을 요구합니다. 조직은 암호화 키 수명 주기 관리 프로세스를 완전히 제어하기를 원합니다. 조직은 AWS CloudTrail과 별도로 키 자료를 즉시 삭제하고 키 사용을 감사할 수 있어야 합니다. 선택한 서비스는 다른 AWS 스토리지 서비스와 인터페이스해야 합니다.
이러한 보안 표준을 준수하는 서비스는 무엇입니까?
A. AWS 클라우드를 사용한 HSM 클라이언트
B. AWS KMS(AWS Key Management Service)와 AWS 클라우드 HSM
C. 외부 키 자료 출처가 있는 AWS KMS(AWS Key Management Service)
D. AWS KMS(AWS Key Management Service) 및 AWS 관리 고객 마스터 키(CMK)
해설 : 암호화 키 수명 주기 관리 프로세스를 완전히 제어 문제 요점. 클라우드에 저장된 모든 데이터를 미사용 시 암호화. “KMS 고객 마스터 키(CMK)를 표준 KMS 키 저장소가 아닌 사용자 지정 키 저장소에 저장할 수 있습니다. AWS Cloud를 사용하여 사용자 지정 키 저장소 생성사용자가 소유하고 관리하는 HSM 클러스터입니다. 이를 통해 CMK의 핵심 자료를 생성하고 이를 통해 암호화 작업을 수행하는 하드웨어 보안 모듈(HSM)을 직접 제어할 수 있습니다. AWS Cloud를 만드는 데 가장 먼저 필요한 사용자 지정 키 저장소를 시작하려면 HSM 클러스터를 자세히 알아보기.” HSM HSM 클라이언트 Linux HSM 클라이언트를 구성하려면 Linux 클라이언트 인스턴스에 AWS CloudHSM 클래식 클라이언트 소프트웨어를 설치해야 합니다. AWS CloudHSM Classic은 HSM 클라이언트 소프트웨어에 사전 구성된 Amazon Elastic Compute Cloud (Amazon EC2) 인스턴스를 시작하는 데 사용할 수 있는 사용자 지정 Amazon Machine Image (AMI) 를 제공합니다. AWS CloudFormation를 사용하여 환경을 자동으로 설정했거나 AWS CloudHSM Classic AMI를 사용하여 클라이언트 인스턴스를 시작한 경우에는 건너뛰어도 Linux 클라이언트와 HSM 어플라이언스 간의 네트워크 트러스트 링크 생성. AWS KMS(AWS Key Management Service) AWS KMS API를 사용하여 KMS 키와 사용자 지정 키 스토어 등의 특수 기능을 생성 및 관리하고, 암호화 작업에서 KMS 키를 사용. AWS managed key - AWS 서비스들이 KMS 를 통해 Key를 서비스 받는 것으로, 내부적으로 자동으로 일어나게 되며 사용자가 직접적으로 제어가 불가능하다. Customer managed key (CMK) - 사용자가 직접 key를 생성하고 관리하는 것으로 CMK 에 대한 제어는 IAM 을 통해 권한을 부여 받아 제어가 가능하다. Custom key stores - AWS 에서 제공하는 또다른 key 관리형 서비스인 CloudHSM 을 활용한 Key 관리 형태를 의미한다. AWS 클라우드HSM A 탈락 -> EC2에 HSM 클라이언트를 설치하여 윈도우 사용자와 간의 네트워크 트러스트 링크 생성까지만하는 장치라서 부적합. B 정답 -> KMS로 AWS CloudTrail를 사용할 수 있는 별도로 키 자료를 즉시 삭제하고 키 사용을 감사하며 클라우드HSM 기술로 데이터 암호화를 설정하여 적합. C 탈락 -> 기존에 사용하던 키들을 KMS와 연결하여 사용하는 것 같은데 데이터에 대한 조건이 없어 부적합. D 탈락 -> KMS의 CMK 기능은 관리를 인증된 사용자가 지정하는 것인데 데이터에 대한 조건이 없어 부적합.
정답 및 해설 보기
Answer : B
AWS CloudTrail(사용자)과 별도로 키 자료를 즉시 삭제하고 키 사용을 감사.
하드웨어 보안 모듈(HSM)은 데이터의 암호화 및 암호 해독에 사용되는 키를 생성, 보호, 관리하고 디지털 서명 및 인증서를 생성하여 암호화 프로세스를 보호하는 강화된 변조 방지 하드웨어 장치. 최고 보안 표준에 따라 테스트, 검증, 인증 가능.
암호화 및 디지털 서명과 같은 암호화 작업은 사용하는 개인 키가 제대로 보호되지 않으면 가치가 없음.
Windows HSM 클라이언트를 구성하려면 Windows 클라이언트 인스턴스에 HSM 클라이언트 소프트웨어를 수동으로 설치.
인스턴스는 HSM과 동일한 VPC에서 실행 중이어야 함.
AWS KMS는 데이터를 보호하는 데 사용하는 암호화 키를 쉽게 생성하고 제어할 수 있게 해주는 멀티 테넌트 관리형 서비스.
하드웨어 보안 모듈(HSM)을 사용하여 AWS KMS keys를 보호하고 검증.
AWS KMS는 데이터를 암호화하는 대부분의 기타 AWS 서비스와 통합.
감사, 규제 및 규정 준수 요구사항에 따라 KMS 키 사용을 기록하기 위해 AWS CloudTrail과 통합.
또한, AWS KMS 외부 키 스토어(XKS) 기능으로
외부 키 스토어는 AWS KMS에 추가 비용 없이 제공됩니다. AWS KMS는 키 구성 요소가 KMS, CloudHSM 또는 자체 온프레미스 HSM에 저장된 위치와 관계없음.
AWS의 단일 테넌트 하드웨어 보안 모듈(HSM) 관리하고 키 스토어 생성.
데이터 보안에 대한 기업, 계약 및 규제 관련 규정 준수 요구 사항을 충족하는 데 도움. (Amazon CloudWatch/CloudTrail 가능)
저장 데이터 암호화/웹 서버용 SSL 처리 오프로드/발행 인증 기관(CA)의 개인 키 보호/Oracle 데이터베이스용 TDE 활성화.
Prob. 143
기업은 Amazon Web Services(AWS)에서 애플리케이션을 호스팅하고 Amazon DynamoDB를 데이터베이스로 활용합니다. 데이터베이스의 데이터를 처리하기 위해 조직은 Amazon EC2 인스턴스를 사설 네트워크에 추가합니다. 조직은 2개의 NAT 인스턴스를 사용하여 DynamoDB에 연결합니다. 회사는 NAT 인스턴스를 폐기하려고 합니다. 솔루션 설계자는 DynamoDB에 연결되고 자체 관리되는 솔루션을 개발해야 합니다.
이러한 요구 사항을 충족하는 측면에서 가장 비용 효율적인 접근 방식은 무엇입니까?
A. DynamoDB에 대한 연결을 제공할 게이트웨이 VPC 엔드포인트을 만듭니다.
B. DynamoDB에 대한 연결을 제공하도록 관리되는 NAT 게이트웨이를 구성합니다.
C. 개인 네트워크와 DynamoDB 간에 AWS Direct Connect 연결을 설정합니다.
D. 개인 네트워크와 DynamoDB 사이에 AWS PrivateLink 엔드포인트 서비스를 배포합니다.
해설 : 가장 비용 효율적인 문제 요점. 현재 2개의 NAT 인스턴스를 사용하여 DynamoDB에 연결. 만약 외부의 리소스까지 AWS 내부에 VPC 엔드포인트을 하나만 추가하는 것만으로 이러한 작업을 수행할 수 없습니다(이렇게 하면 AWS 내부 리소스는 연결할 수 있지만 외부에서는 연결할 수 없습니다). 게이트웨이 엔드포인트은 지원되는 서비스에 연결할 수 있도록 라우팅 테이블 내에서 사용되는 대상이며, 현재 게이트웨이 엔드포인트을 사용하는 지원되는 서비스는 Amazon S3 및 DynamoDB 뿐입니다. AWS PrivateLink 엔드포인트 NAT 게이트웨이 퍼블릭 - 프라이빗 서브넷의 인스턴스는 퍼블릭 NAT 게이트웨이를 통해 인터넷에 연결할 수 있지만 인터넷에서 원치 않는 인바운드 연결을 수신할 수 없음. 프라이빗- 프라이빗 서브넷의 인스턴스는 프라이빗 NAT 게이트웨이를 통해 다른 VPC 또는 온프레미스 네트워크에 연결할 수 있음. NAT 인스턴스 A 정답 -> 프라이빗 서브넷(네트워크)에서 VPC 밖의 리소스에 연결할 때 인터넷이 아닌 게이트웨이 엔드포인트로 전달하여 적합. B 탈락 -> NAT 인스턴스를 폐기하고 다른 서비스를 원하기 때문에 부적합. C 탈락 -> AWS Direct Connect 연결은 온프레미스와 클라우드를 직접 연결할때 사용(인터넷 대신으로 비용도 쌈)하여 부적합. D 탈락 -> 이것은 서로 다른 VPC의 리소스들을 연결하는 VPC피어링 같아서 부적합.
정답 및 해설 보기
Answer : A
새롭게 사설 네트워크와 DynamoDB에 연결되고 자체 관리.
이러한 이유로 NAT 게이트웨이(관리 솔루션)가 대체하기에 적합한 변종입니다.
이 경우 C와 D는 오버헤드일 뿐이고 돈을 낭비합니다.
서로 다른 VPC의 퍼블릭 서브넷 간의 연결을 위해
인터페이스 엔드포인트(VPC 1) -> PrivateLink -> 엔드포인트 서비스(NLB)로 연결 가능(VPC 2)
NAT(네트워크 주소 변환) 서비스입니다. 프라이빗 서브넷의 인스턴스가 VPC 외부의 서비스에 연결할 수 있지만 외부 서비스에서 이러한 인스턴스와의 연결을 시작할 수 없도록 NAT 게이트웨이를 사용.
트래픽을 NAT 게이트웨이에서 VPC용 인터넷 게이트웨이로 라우팅.
다른 VPC 또는 온프레미스 네트워크에 연결할 수 있게 NAT 게이트웨이에서 Transit Gateway 또는 가상 프라이빗 게이트웨이를 통해 트래픽을 라우팅.
트래픽을 NAT 게이트웨이에서 Transit Gateway 또는 가상 프라이빗 게이트웨이를 통해 트래픽을 라우팅.
탄력적 IP 주소를 프라이빗 NAT 게이트웨이에 연결할 수 없음.
프라이빗 NAT 게이트웨이에서 인터넷 게이트웨이로 트래픽을 라우팅하는 경우 인터넷 게이트웨이가 트래픽을 삭제.
네트워크 주소 변환을 제공하는 고유한 AMI를 생성하고 자신의 AMI를 사용하여 EC2 인스턴스를 NAT 인스턴스로 시작.
퍼블릭 서브넷에 있는 NAT 인스턴스를 시작하여 프라이빗 서브넷에 있는 인스턴스가 인터넷 또는 다른 AWS 서비스로의 아웃바운드 IPv4 트래픽을 시작.
인터넷에서 시작된 인바운드 트래픽은 인스턴스가 수신하지 못하게 막음.
Prob. 144
기업은 다양한 가용 영역에 걸쳐 있는 가상 사설 클라우드(VPC)에서 3계층 웹 애플리케이션을 호스팅합니다. 애플리케이션 계층의 경우 Amazon EC2 인스턴스는 Auto Scaling 그룹에 배포됩니다. 조직은 각 리소스에 대한 일일 및 주간 워크로드 패턴을 분석하는 자동화된 확장 전략을 개발해야 합니다. 설정은 소비의 예측 및 실제 변경 모두에 대응하여 리소스를 올바르게 확장해야 합니다.
이러한 요구 사항을 충족하기 위해 솔루션 설계자가 제안해야 하는 확장 접근 방식(있는 경우)은 무엇입니까?
A. EC2 인스턴스의 평균 CPU 활용률을 기반으로 단계적 확장을 통해 동적 확장을 구현합니다.
B. 예측 및 확장에 따른 예측 확장을 지원합니다. 대상 추적 기능을 사용하여 동적 스케일링을 구성합니다.
C. 웹 응용 프로그램의 트래픽 패턴을 기반으로 자동 예약 확장 작업을 만듭니다.
D. 단순 확장 정책을 설정합니다. EC2 인스턴스 시작 시간을 기준으로 냉각 기간을 늘립니다.
해설 : 소비의 예측 및 실제 변경 모두에 대응하여 리소스 확장 문제 요점. Amazon EC2 인스턴스는 Auto Scaling 그룹에 배포. 예측 스케일링을 동적 스케일링과 함께 사용합니다. 동적 확장은 리소스 활용률의 실시간 변화에 따라 용량을 자동으로 확장하는 데 사용됩니다. 예측 스케일링과 함께 사용하면 애플리케이션의 수요 곡선을 면밀히 따를 수 있으며, 트래픽이 적을 때는 스케일아웃하고 트래픽이 예상보다 많을 때는 스케일인할 수 있습니다. 여러 확장 정책이 활성 상태인 경우 각 정책은 원하는 용량을 독립적으로 결정하고 원하는 용량은 이들 중 최대 용량으로 설정됩니다. 예를 들어, 대상 추적 확장 정책에서 10개의 인스턴스가 대상 활용률에 머물러야 하고 예측 확장 정책에서 8개의 인스턴스가 대상 활용률에 머물러야 하는 경우 그룹의 원하는 용량은 10으로 설정됩니다. 동적 스케일링 예측 스케일링 예약된 스케일링 A 탈락 -> CPU라는 대상의 활용률을 추적해서 확장하는 것은 대상 추적 조정이며 예측에 대한 것이 없어 부적합. B 정답 -> 예측 확장으로 일일/주간 워크로드 패턴을 분석하고 대상 추적 기능으로 대상의 변화에 따라 확장하여 적합. C 탈락 -> 트래픽 패턴으로 자동 예약 확장 작업을 생성하면 예측이나 동적 확장에 대해 성능이 떨어져서 부적합. D 탈락 -> 단순 조정으로 설정에 따라 용량을 스케일링하는데 냉각 기간은 아마도 스케일링이 안되는 시간 같아 부적합.
정답 및 해설 보기
Answer : B
일일 및 주간 워크로드 패턴을 분석하는 자동화된 확장.
동적 조정은 트래픽의 변화에 따라 Auto Scaling 그룹의 용량을 조정.
예측 조정을 사용하여 트래픽 흐름의 일일 및 주간 패턴에 앞서 Auto Scaling 그룹의 EC2 인스턴스 수를 늘릴 수 있음.
예약된 조정을 사용하면 예측 가능한 부하 변화에 따라 조정 일정을 설정할 수 있음.
예를 들어, 매주 수요일에 웹 애플리케이션에 대한 트래픽이 증가하고 목요일까지 높은 상태로 유지되다가 금요일에 줄어들기 시작한다고 가정 -> Amazon EC2 Auto Scaling이 수요일에 용량을 늘리고 금요일에 용량을 줄이도록 일정을 구성.
예약된 작업이 시간 및 날짜 함수에 따라 자동으로 수행.
예약된 작업을 생성할 때 크기 조정 활동이 발생할 시간, 조정 작업에 대한 원하는 용량, 최소 및 최대 용량을 새로 지정.
규모를 한 번만 조정하거나 반복되는 일정으로 조정하도록 예약된 작업을 생성할 수 있음.
Prob. 145
기업은 MySQL 데이터베이스를 운영하도록 구성된 자체 Amazon EC2 인스턴스를 관리합니다. 회사는 수요가 증가하거나 감소함에 따라 수동으로 복제 및 확장을 관리합니다. 조직에는 필요에 따라 데이터베이스 계층에서 컴퓨팅 리소스를 더 쉽게 추가하거나 제거할 수 있는 새로운 솔루션이 필요합니다. 또한 솔루션은 운영 부분에서 거의 작업을 수행하지 않고도 속도, 확장성 및 내구성을 높여야 합니다.
어떤 솔루션이 이러한 기준을 충족합니까?
A. Aurora MySQL의 경우 데이터베이스를 Amazon Aurora Serverless로 마이그레이션하십시오.
B. Aurora PostgreSQL의 경우 Amazon Aurora Serverless로 데이터베이스를 마이그레이션합니다.
C. 데이터베이스를 하나의 더 큰 MySQL 데이터베이스로 결합합니다. 대형 EC2 인스턴스에서 대형 데이터베이스를 실행합니다.
D. 데이터베이스 계층에 대한 EC2 자동 스케일링 그룹을 생성합니다. 기존 데이터베이스를 새 환경으로 마이그레이션합니다.
해설 : 거의 작업을 수행하지 않고도 속도, 확장성 및 내구성 문제 요점. MySQL 데이터베이스를 운영하도록 구성된 자체 Amazon EC2 인스턴스 관리. Aurora Serverless = 예측할 수 없는 간헐적 워크로드의 경우, 고객은 최소 Aurora 용량 단위(예: 1 CPU, 2GB RAM, 64 CPU, 122GB RAM)를 지정합니다. 또한 자동 복제, DB 스토리지의 자동 복구, DB 컴퓨팅의 Aurora Replica 자동 확장과 같은 RDS Aurora 서비스의 나머지 유용한 기능도 갖추고 있으며, Single AZ이지만 지역에 걸쳐 최대 15개의 활성 Aurora Replica를 지원하고 기존 보단 느리나 복구를 지원합니다. “새로운 솔루션”, “DB 컴퓨팅 확장 용이”, “DB 속도, 확장성, 내구성(HA) 향상”, “작은 운영 오버헤드”를 묻는 질문입니다. 서버리스 서비스는 소프트웨어 패치 적용이나 업데이트와 같은 EC2 유지보수를 처리하는 것보다 더 완벽합니다. A 정답 -> 서버리스를 사용하면 비용도 싸면서 서버에 대한 유지보수보다 수행하는 작업이 적고 예측할 수 없는 워크로드/자동복제/복구/AZ/Replica 지원 및 자동 확장으로 성능도 좋아서 적합. B 탈락 -> MySQL을 사용한다고 하여 부적합. C 탈락 -> 그냥 크기만 키운 대형 EC2인스턴스에 실행해도 작업량은 같으며 속도는 좋아지나 한계가 있고 다른 성능에도 부적합. D 탈락 -> 이것도 결국 EC2에서 사용하는 것이라 작업량은 같으며 자동 스케일링으로 속도/확장성은 좋으나 내구성이 문제여서 부적합.
정답 및 해설 보기
Answer : A
수동으로 복제 및 확장을 관리.
컴퓨팅 리소스를 더 쉽게 추가하거나 제거할 수 있는 새로운 솔루션 필요.
MySQL 및 PostgreSQL 호환.
Prob. 146
비즈니스에서 두 개의 앱을 AWS로 이전하려고 합니다. 두 앱 모두 동일한 파일에 액세스하여 엄청난 수의 파일을 동시에 처리합니다. 두 프로그램 모두 최소한의 지연으로 파일을 읽어야 합니다.
이 경우 솔루션 아키텍트가 제안하는 아키텍처는 무엇입니까?
A. 애플리케이션을 실행할 두 개의 AWS Lambda 기능을 구성합니다. 데이터를 저장할 인스턴스 저장소 볼륨을 사용하여 Amazon EC2 인스턴스를 생성합니다.
B. 애플리케이션을 실행할 두 AWS Lambda 기능을 구성합니다. 데이터를 저장할 Amazon EBS(Elastic Block Store) 볼륨을 사용하여 Amazon EC2 인스턴스를 생성합니다.
C. 두 애플리케이션을 동시에 실행하도록 최적화된 메모리 Amazon EC2 인스턴스 하나를 구성합니다. 프로비저닝된 IOPS가 있는 Amazon EBS(Amazon Elastic Block Store) 볼륨을 생성하여 데이터를 저장합니다.
D. 두 개의 Amazon EC2 인스턴스를 구성하여 두 응용 프로그램을 모두 실행합니다. 데이터를 저장할 범용 성능 모드와 버스트 처리량 모드를 사용하여 Amazon EFS(Amazon Elastic File System)를 구성합니다.
해설 : 최소한의 지연으로 파일을 읽어야 함 문제 요점. 동일한 파일에 액세스하여 엄청난 수의 파일을 동시에 처리. EFS for concurrent access to files. 스토리지 클래스 — EFS 원 존 또는 EFS 스탠다드 성능 모드 — 범용(최대 35,000 IOPS를 지원하고 작업당 지연 시간이 가장 짧음) 또는 최대 I/O(더 긴 지연 시간을 견딤, 고도로 병렬화된 워크로드) 처리량 모드 — 버스팅(클래스에 저장된 데이터의 양에 따라 결정), 엘라스틱(읽고 쓴 데이터의 양에 따라 결정) 또는 프로비저닝(프로비저닝된 처리량에 따라 결정) A 탈락 -> 람다 함수로는 이벤트처럼 실행시키고 처리된 데이터를 EC2에 저장하지만 동시성이 없어 부적합. B 탈락 -> 람다 함수로는 이벤트처럼 실행시키고 처리된 데이터를 EBS에 저장하지만 Multi-attach가 있지만 제한과 단일 AZ를 대상으로만 지원으로 동시성이 부족하여 부적합. C 탈락 -> 메모리와 프로비저닝된 IOPS는 처리 관련 성능이고 EBS는 동시성이 부족하여 부적합. D 정답 -> EC2에서 실행하며 데이터를 저장할 EFS는 지연 시간이 짧고 저장된 데이터의 양에 따라 구성되며 멀티 AZ 동시성을 제공하여 적합.
정답 및 해설 보기
Answer : D
파일 시스템 성능은 일반적으로 지연 시간, 처리량 및 초당 입출력 작업 수 (IOPS) 의 차원을 사용하여 측정.
Prob. 147
기업은 Kubernetes 클러스터를 사용하여 온프레미스 데이터 센터에서 컨테이너화된 애플리케이션을 운영합니다. 조직은 데이터를 MongoDB 데이터베이스에 저장합니다. 조직은 이러한 환경 중 일부를 AWS로 전환하기를 원하지만 현재 코드 또는 배포 방법을 수정할 수 없습니다. 비즈니스에는 운영 비용을 낮추는 솔루션이 필요합니다.
어떤 솔루션이 이러한 기준을 충족합니까?
A. 컴퓨팅에는 Amazon EC2 작업자 노드와 Amazon ECS(Amazon Elastic Container Service)를 사용하고 데이터 스토리지에는 EC2의 MongoDB를 사용합니다.
B. 컴퓨팅에는 AWS Fargate와 Amazon ECS(Amazon Elastic Container Service)를 사용하고 데이터 스토리지에는 Amazon DynamoDB를 사용합니다.
C. 컴퓨팅에는 Amazon EC2 작업자 노드와 Amazon EKS(Amazon Elastic Kubernetes Service)를 사용하고 데이터 스토리지에는 Amazon DynamoDB를 사용합니다.
D. 컴퓨팅에는 AWS Fargate와 Amazon EKS(Amazon Elastic Kubernetes Service)를 사용하고 데이터 스토리지에는 Amazon DocumentDB(MongoDB 호환)를 사용합니다.
해설 : 운영 비용을 낮추는 솔루션 문제 요점. Kubernetes 클러스터를 사용. “쿠버네티스 클러스터 사용” - ECS(A 및 B)보다 EKS(C 및 D) 선호하고 쿠버네티스 (k8s, Kubernetes, 큐브, kube)는 컨테이너화된 애플리케이션을 배포, 관리, 확장할 때 수반되는 다수의 수동 프로세스를 자동화하는 오픈소스 컨테이너 오케스트레이션 플랫폼입니다 Amazon Elastic Kubernetes Service(EKS) Amazon DocumentDB(MongoDB 호환) A 탈락 -> 온프레미스에서 사용하던 쿠버네티스 환경과 다른 ECS와 EC2로 DB를 사용하여 컴퓨팅하여 부적합. B 탈락 -> Fargate로 서버리스 컴퓨팅 엔진으로 비용 절감은 하지만 쿠버네티스 환경과 다른 ECS와 다른 DynamoDB로 컴퓨팅하여 부적합. C 탈락 -> 쿠버네티스 환경을 사용하지만 다른 DynamoDB로 컴퓨팅하여 부적합. D 정답 -> 서버리스 형태의 쿠버네티스 환경을 EKS로 사용하고 DB도 호환 되는 컴퓨팅을 사용하여 적합.
정답 및 해설 보기
Answer : D
온프레미스 데이터 센터에서 컨테이너화된 앱 운영.
데이터를 MongoDB 데이터베이스에 저장.
환경 중 일부를 AWS로 전환하기를 원함.
현재 코드 또는 배포 방법을 수정할 수 없음.
“운영 비용 절감” - EC2보다 서버리스(Fargate)를 선호합니다.
Kubernetes를 시작, 실행 및 크기 조정하는 가장 신뢰할 수 있는 방법으로 AWS 클라우드와 온프레미스 데이터 센터에서 Kubernetes를 실행하는 데 사용되는 관리형 Kubernetes 서비스.
클라우드에서
하이브리드 환경 전반에 배포/기계 학습(ML) 워크플로 모델링/웹 애플리케이션 구축 및 실행.
완전관리형 기본 JSON 도큐먼트 데이터베이스를 통해 손쉽게 엔터프라이즈 워크로드 크기 조정.
완전관리형 기본 JSON 도큐먼트 데이터베이스로서 인프라를 관리하지 않고도 규모와 관계없이 중요한 문서 워크로드를 쉽고 비용 효율적으로 운영할 수 있게 해 줍니다. Amazon DocumentDB는 내장 보안 모범 사례, 지속적인 백업, 다른 AWS 서비스와의 기본 통합을 제공하여 사용자의 아키텍처를 간소화.
콘텐츠 관리 데이터 저장 및 쿼리/사용자 프로파일, 기본 설정 및 요청 관리/모바일 및 웹 애플리케이션 크기 조정.
Prob. 148
비즈니스에 Amazon DynamoDB 데이터 스토리지를 활용하는 모바일 채팅 애플리케이션이 있습니다. 사용자는 새로운 메시지를 읽는 동안 가능한 한 짧은 지연을 원합니다. 솔루션 설계자의 목표는 가능한 최소한의 애플리케이션 수정으로 최적의 솔루션을 제공하는 것입니다.
솔루션 아키텍트가 선택해야 하는 기술은 무엇입니까?
A. 새 메시지 테이블에 대해 DAX(Amazon DynamoDB Accelerator)를 구성합니다. DAX 엔드포인트을 사용하도록 코드를 업데이트합니다.
B. 늘어난 읽기 로드를 처리하기 위해 DynamoDB 읽기 복제본을 추가합니다. 읽기 복제본의 읽기 엔드포인트을 가리키도록 응용프로그램을 업데이트합니다.
C. DynamoDB의 새 메시지 테이블에 대한 읽기 용량 단위 수를 두 배로 늘립니다. 기존 DynamoDB 엔드포인트을 계속 사용합니다.
D. 애플리케이션 스택에 Amazon ElastiCache for Redis 캐시를 추가합니다. DynamoDB 대신 Redis 캐시 엔드포인트을 가리키도록 애플리케이션을 업데이트합니다.
해설 : 가능한 최소한의 애플리케이션 수정으로 최적의 솔루션 문제 요점. Amazon DynamoDB 데이터 스토리지를 활용. DAX에는 DB에 기록되는 모든 새 데이터가 캐시되는 Write-Through 모드가 있어 쓰기 후 다음 읽기가 캐시에서 읽힙니다. 스토리지 기반 캐싱 개념과 매우 유사합니다. A 정답 -> 읽기의 처리 속도(검색) 성능을 높이며 DAX 엔드포인트만 적용하면 간단하게 사용할 수 있어 적합. B 탈락 -> 읽기 복제본은 장애 극복이나 읽기의 처리량(IOPS, 트래픽)을 높이는 것이기에 부적합. C 탈락 -> 읽기 용량을 두 배로 늘려도 의미 없어 부적합. D 탈락 -> DynamoDB를 활용하지 않아서 부적합.
정답 및 해설 보기
Answer : A
읽는 동안 가능한 한 짧은 지연.
Prob. 149
기업은 Amazon Web Services를 활용하여 3계층 애플리케이션의 모든 구성 요소를 호스팅합니다. 조직은 환경 내부의 가능한 보안 취약성을 자동으로 식별하기를 원합니다. 조직은 발견을 추적하고 위반이 의심되는 경우 관리자에게 경고하기를 원합니다.
어떤 솔루션이 이러한 기준을 충족합니까?
A. 의심스러운 웹 트래픽을 평가하도록 AWS WAF를 설정합니다. AWS Lambda 함수를 생성하여 Amazon CloudWatch에 결과를 기록하고 관리자에게 e-메일 알림을 보냅니다.
B. 의심스러운 웹 트래픽을 평가하도록 AWS Shield를 설정합니다. AWS Lambda 함수를 생성하여 Amazon CloudWatch에 결과를 기록하고 관리자에게 e-메일 알림을 보냅니다.
C. Amazon CloudWatch에서 환경을 모니터링하고 결과를 생성하려면 Amazon Inspector를 배포하십시오. 메시지를 Amazon Simple Notification Service(Amazon SNS) 항목에 게시하여 관리자에게 이메일로 알리도록 Amazon EventBridge(Amazon CloudWatch Events) 규칙을 구성합니다.
D. Amazon CloudWatch에서 환경을 모니터링하고 결과를 생성하려면 Amazon GuardDuty를 배포합니다. 메시지를 Amazon Simple Notification Service(Amazon SNS) 항목에 게시하여 관리자에게 이메일로 알리도록 Amazon EventBridge(Amazon CloudWatch Events) 규칙을 구성합니다.
해설 : 발견을 추적하고 위반이 의심되는 경우 관리자에게 경고 문제 요점. 3계층 애플리케이션의 모든 구성 요소를 호스팅. AWS WAF AWS Shield Amazon Inspector Amazon GuardDuty A 탈락 -> AWS WAF -> Lambda -> Amazon CloudWatch -> 이메일(SES)로 구체적인 대응 방법으로 부적합. B 탈락 -> AWS Shield -> Lambda -> Amazon CloudWatch -> 이메일(SES)로 구체적인 대응 방법으로 부적합. C 탈락 -> Inspector(검사)는 EC2에 대한 전용으로 부적합. D 정답 -> GuardDuty는 지능형 위협 발견을 위한 것이며, 이 사용 사례에서 우리가 찾고 있는 것으로 적합.
정답 및 해설 보기
Answer : D
환경 내부의 가능한 보안 취약성을 자동으로 식별.
가용성에 영향을 미치거나 보안을 훼손하거나 과도한 리소스를 소비할 수 있는 일반적인 웹 익스플로잇 및 봇으로부터 애플리케이션을 보호.
Amazon CF/ALB/API Gateway/AWS AppSync
AWS에서 실행되는 애플리케이션을 보호하는 관리형 DDoS 보호 서비스로 관리형 DDoS 보호 기능을 통해 애플리케이션 가용성과 응답성을 최대화.
AWS WAF/Firewall Manager/Global Accelerator/ELB/CF 분배/탄력 IP/Route 53 hosted zone
소프트웨어 취약성 및 의도하지 않은 네트워크 노출에 대해 AWS 워크로드를 지속적으로 스캔하는 자동화된 취약성 관리 서비스.
규모에 맞는 지속적인 자동 취약성 관리.
AWS 계정 및 워크로드에서 악의적 활동을 모니터링하고 상세한 보안 결과를 제공하여 가시성 및 해결을 촉진하는 위협 탐지 서비스.
지능형 위협 탐지로 AWS 계정을 보호.
Prob. 150
Amazon RDS MySQL DB 인스턴스에서 회사의 프로덕션 애플리케이션은 OLTP(온라인 트랜잭션 처리) 트랜잭션을 처리합니다. 이 회사는 또한 동일한 데이터 액세스 권한을 가진 새로운 보고 도구(reporting tool)를 제공하고 있습니다. 보고 도구는 액세스 가능성이 높아야 하며 프로덕션 응용 프로그램의 성능에 부정적인 영향을 미치지 않아야 합니다.
이것은 어떻게 이루어지나요?
A. 프로덕션 RDS DB 인스턴스의 스냅샷을 매시간 생성합니다.
B. 프로덕션 RDS DB 인스턴스의 Multi-AZ RDS Read Replica를 생성합니다.
C. 프로덕션 RDS DB 인스턴스의 여러 RDS Read Replica를 작성합니다. 읽기 복제본을 자동 스케일링 그룹에 배치합니다.
D. 프로덕션 RDS DB 인스턴스의 Single-AZ RDS Read Replica를 생성합니다. replica에서 두 번째 Single-AZ RDS Read Replica를 만듭니다.
해설 : 액세스 가능성이 높아야 하며 프로덕션 응용 프로그램의 성능에 긍정적인 영향 문제 요점. Amazon RDS MySQL DB 인스턴스. RDS는 관리형 서비스이기 때문에 읽기 복제본을 AWS에서 스케일링을 관리하므로 내가 Auto Scaling Group에 배치할 필요가 없다. A 탈락 -> 스냅샷 생성시 쿼리를 다 처리한 후에 하는데 성능 문제가 발생할 수도 있어 부적합. B 정답 -> Multi-AZ RDS Read Replica를 생성으로 가용성뿐만 아니라 성능도 적합. C 탈락 -> 직접 Read Replica를 작성하고 자동 스케일링 그룹에 배치하는 것이라 부적합. D 탈락 -> 이게 무슨 소리인지 모르겠음 복제본의 또 복제본을 만든다는 것인지 부적합.
정답 및 해설 보기
Answer : B
OLTP(온라인 트랜잭션 처리) 트랜잭션을 처리.
보고 도구(reporting tool)를 제공.
- Ref
