무료 온라인 액세스 Amazon.AWS-Solutions-Architect-Professional.v2022-09-23.q164 모의 시험 (Page 4)

AWS-Solutions-Architect-Professional 문제 11

한 회사는 최근 VPC의 Amazon EC2 Linux 인스턴스 그룹에서 실행되는 새 애플리케이션을 배포했습니다. 피어링된 VPC에서 회사는 배스천 호스트 역할을 하는 EC2 Linux 인스턴스를 시작했습니다. 애플리케이션 인스턴스의 보안 그룹은 배스천 호스트의 사설 IP에서 TCP 포트 22로만 액세스를 허용합니다. 배스천 호스트의 보안 그룹은 시스템 관리자가 SSH를 사용하여 여러 지점에서 애플리케이션 인스턴스에 원격으로 로그인할 수 있도록 0.0.0.0/0에서 TCP 포트 22에 대한 액세스를 허용합니다.
배스천 호스트의 운영 체제 로그를 살펴보는 동안 클라우드 엔지니어는 전 세계 여러 위치에서 배스천 호스트에 대한 수천 건의 SSH 로그인 실패를 확인했습니다. 클라우드 엔지니어는 애플리케이션 인스턴스에 대한 원격 액세스 권한 부여 방법을 변경하고 다음 요구 사항을 충족하려고 합니다.
* 무차별 대입 SSH 로그인 시도 제거
* SSH 세션 동안 실행된 명령 로그 유지
* 포트 포워딩 기능 유지
애플리케이션 인스턴스에 대한 원격 액세스에 대한 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

A. 시스템 관리자가 Session Manager를 사용하여 애플리케이션 인스턴스와 세션을 설정하도록 그램 액세스 권한을 AWS 시스템 관리자와 통신하도록 애플리케이션 인스턴스를 구성합니다. 배스천 호스트를 종료합니다.

B. AWS Systems Manager와 통신하도록 애플리케이션 인스턴스를 구성합니다. Systems Manager Run을 사용하여 애플리케이션 인스턴스에 명령을 실행할 수 있는 시스템 관리자에 대한 액세스 권한 부여 AWS Systems Manager Run Command와 통신하도록 애플리케이션 인스턴스를 구성합니다.
배스천 호스트 종료

C. 지점의 공용 IP 주소에서만 트래픽을 허용하도록 배스천 호스트의 보안 그룹을 업데이트합니다.

D. AWS 클라이언트 VPN 엔드포인트를 구성하고 각 시스템 관리자에게 인증서를 프로비저닝하여 애플리케이션 VPC에 대한 VPN 연결을 설정합니다. 클라이언트 VPN IPv4 CIDR의 트래픽만 허용하도록 애플리케이션 인스턴스의 보안 그룹 업데이트 배스천 호스트 종료

AWS-Solutions-Architect-Professional 문제 12

한 회사에서 소프트웨어 테스트에 사용되는 여러 랩 환경의 마이그레이션을 계획하고 있습니다. 다양한 맞춤형 도구를 사용하여 각 랩의 테스트 실행을 관리합니다. 랩은 소프트웨어 테스트 실행을 위해 변경할 수 없는 인프라를 사용하며 결과는 고가용성 SQL 데이터베이스 클러스터에 저장됩니다. 사용자 지정 도구를 완전히 다시 작성하는 것은 마이그레이션 프로젝트의 범위를 벗어났지만 회사는 마이그레이션 중에 워크로드를 최적화하려고 합니다.
이 요구 사항을 충족하는 애플리케이션 마이그레이션 전략은 무엇입니까?

A. 재호스트

B. 재플랫폼

C. 리팩터링/재설계

D. 은퇴

AWS-Solutions-Architect-Professional 문제 13

한 신문사에 Java로 작성된 웹사이트를 통해 일반 대중이 카탈로그를 검색하고 개별 신문 페이지를 검색할 수 있는 사내 애플리케이션이 있습니다. 그들은 오래된 신문을 JPEG(약 17TB)로 스캔하고 광학 문자 인식(OCR)을 사용하여 상업용 검색 제품을 채웠습니다. 이제 호스팅 플랫폼과 소프트웨어의 수명이 종료되었으며 조직은 아카이브를 AWS로 마이그레이션하고 비용 효율적인 아키텍처를 생성하면서도 가용성과 내구성을 위해 설계되기를 원합니다.
가장 적절한 것은?

A. 중복성이 감소된 S3를 사용하여 저장하고 스캔한 파일을 제공하고, EC2 인스턴스에 상용 검색 애플리케이션을 설치하고, Auto-Scaling 및 Elastic Load Balancer로 구성합니다.

B. Apache 웹 서버 및 오픈 소스 검색 애플리케이션을 실행하는 EC2 인스턴스를 사용하는 CloudFormation을 사용하여 환경을 모델링하고 여러 표준 EBS 볼륨을 함께 스트라이프하여 JPEG 및 검색 인덱스를 저장합니다.

C. 표준 중복성이 있는 S3를 사용하여 스캔한 파일을 저장 및 제공하고, CloudSearch를 쿼리 처리에 사용하고, Elastic Beanstalk를 사용하여 여러 가용 영역에 걸쳐 웹사이트를 호스팅합니다.

D. 단일 AZ RDS MySQL 인스턴스를 사용하여 검색 인덱스 33d를 저장하고 JPEG 이미지는 EC2 인스턴스를 사용하여 웹 사이트를 제공하고 사용자 쿼리를 SQL로 변환합니다.

E. CloudFront 다운로드 배포를 사용하여 최종 사용자에게 JPEG를 제공하고 현재 상용 검색 제품을 Java 컨테이너와 함께 설치하고 EC2 인스턴스에서 웹 사이트를 Tor 및 DNS 라운드 로빈과 함께 Route53을 사용합니다.

정답: C

설명
모든 목표를 알지 못하면 "가장 적절한" 것과 같은 것은 없습니다. 나는 당신의 시나리오가 매우 모호하다는 것을 알았습니다. 왜냐하면 당신은 분명히 그들 사이를 혼합하고 일치시킬 수 있기 때문입니다. 대신 레이어별로 결정해야 한다고 생각합니다.
로드 밸런서 계층: ELB 또는 DNS만, 또는 자체 제작. (DNS+EIP를 사용하는 것은 ELB보다 약간 저렴하지만 덜 안정적입니다.) 17TB의 이미지를 위한 스토리지 계층: 이것은 S3의 완벽한 사용 사례입니다. 모든 웹 요청을 S3의 관련 JPEG로 직접 오프로드합니다. EC2 상자는 해당 상자에 대한 링크를 생성합니다.
앱이 이미 자체 이미지(이미지에 대한 링크가 아님)를 제공하는 경우 EFS로 시작할 수 있습니다. 그러나 모든 JPEG 링크를 S3로 매우 쉽게 다시 쓰거나 리디렉션하도록 웹 서버를 설정할 수 있습니다.
S3를 사용하는 경우 버킷에서 직접 제공하지 마십시오. 제어하는 도메인의 CNAME을 통해 제공하십시오. 그렇게 하면 CloudFront에서 쉽게 전환할 수 있습니다.
EBS는 훨씬 더 비싸고 2개의 상자가 필요한 경우 2개의 드라이브가 필요합니다. 왝.
더 작은 저장 형식을 고려하십시오. 예를 들어 JPEG200, WebP 또는 기타 도구는 더 작은 이미지를 만들 수 있습니다. 얼마 전 DejaVu 형식도 있습니다.
캐시 계층: S3 앞에 CloudFront를 추가하면 지구 반대편에 있는 사람들에게 도움이 될 것입니다. 일반적인 아카이브는 거듭제곱 법칙을 따릅니다. 긴 꼬리 요청은 대부분의 JPEG가 캐시에 있을 만큼 충분히 요청되지 않는다는 것을 의미합니다. 따라서 가장 인기 있는 개체만 속도를 높이고 있습니다. 언제든지 기다릴 수 있으며 비용을 더 잘 알게 된 후 나중에 CF로 전환할 수 있습니다. (경우에 따라 실제로 비용을 절감할 수 있습니다.) 아카이브 검색 결과가 상당히 정적이어야 하므로 CloudFront를 앱 앞에 배치할 수도 있습니다. 또한 올바르게 수행하면 CF가 많은 부하를 처리하므로 더 작은 인스턴스 유형으로 실행할 수도 있습니다.
데이터베이스 계층: 몇 가지 옵션:
현재 서버가 현재 수행하는 모든 것을 사용하고 나중에 다른 것으로 교체하십시오. 이 접근 방식을 과소 평가하지 마십시오. 때로는 지금 시작하고 나중에 최적화하는 것이 좋습니다.
RDS를 사용하여 MySQL/Postgres 실행
저는 ElasticSearch/Cloudsearch에 익숙하지 않지만 분명히 Cloudsearch는 유지 관리+설정이 덜할 것입니다.
앱 레이어:
앱 계층을 처음부터 생성할 때 CloudFormation 및/또는 OpsWorks를 고려하십시오. 배워야 할 추가 항목이지만 향후에 도움이 됩니다.
Java+Tomcat은 ElasticBeanstalk의 골목 바로 위에 있습니다. (기본적으로 EC2 + Autoscale + ELB).
남용 방지: 공개 S3 버킷에 무언가를 넣으면 사람들이 웹 페이지에서 핫링크합니다. 이를 방지하려면 EC2 상자의 앱에서 몇 시간 후에 만료되는 서명된 S3 링크를 생성할 수 있습니다. 이제 모든 사람이 앱을 통과해야 하며 앱에서 속도 제한 등을 적용할 수 있습니다.
비용 절감: 다운타임이 괜찮다면:
하나의 AZ(DB와 EC2 모두)에서 모든 것을 실행합니다. 상태 비저장 방식으로 설계된 한 언제든지 서버와 AZ를 추가할 수 있습니다. 실제로 강력한 기능을 원한다면 여러 영역을 사용해야 합니다.
S3에서 Reduced Redundancy를 사용하여 한 달에 수백 달러 절약(S3을 복구하기 위한 오프라인 사본을 포함하여 고장날 때마다 누군가 "고침"해야 합니다.) EC2 상자에서 예약 인스턴스를 구입하여 이를 만들 수 있습니다. 더 싸다. (RI 마켓부터 시작해서 부분적으로 사용한 것을 사서 시작하세요.) "이 AZ에서 이런 종류의 박스를 운영하면 시간당 비용을 절약할 수 있다"라는 쿠폰일 뿐입니다. 1/2에서 1/3까지 쉽게 할인받을 수 있습니다.
더 적은 메모리와 CPU를 사용하도록 애플리케이션을 다시 작성하십시오. 그렇게 하면 더 적은/작은 상자에서 실행할 수 있습니다. (투자할 가치가 있을 수도 있고 없을 수도 있습니다.) 앱을 매우 드물게 사용하는 경우 Lambda를 사용하여 많은 비용을 절약할 수 있습니다. 하지만 Java 응용 프로그램을 실행하려고 하면 속도가 상당히 느려질까 걱정됩니다.
로드, 검색 대기 시간 예상, 인덱싱 속도, 검색 인덱스 크기 등과 같은 일부 정보가 누락되었습니다. 그러나 귀하가 제공한 정보를 바탕으로 S3를 파일용 스토리지로 사용하겠습니다(S3 락. It 정말, 정말 대단해). 상업용 검색 애플리케이션이 계속 고민이라면 Autoscaling 및 ELB가 있는 EC2 인스턴스를 사용하세요. 대체 검색 엔진이 허용된다면 Elasticsearch가 최선의 선택일 것입니다. IMHO가 아직 준비되지 않았기 때문에 AWS Elasticsearch 서비스 대신 EC2에서 실행하겠습니다. 그러나 Elasticsearch를 자동으로 확장하지 마십시오. 모든 종류의 문제가 발생할 수 있습니다. 저는 CloudSearch에 대한 경험이 전혀 없으므로 이에 대해 언급하지 않습니다. 어떤 옵션을 선택하든 CloudFormation을 사용합니다.

AWS-Solutions-Architect-Professional 문제 14

한 회사는 시장 분석을 실행할 그리드 환경을 만들기 위해 일부 워크로드를 AWS로 이동하기로 결정했습니다. 그리드는 작업 예약 기능에 의해 스핀업된 많은 유사한 인스턴스로 구성됩니다. 대규모 분석 워크로드가 완료될 때마다 작업 스케줄러 및 그리드 노드와 함께 새 VPC가 배포됩니다.
여러 그리드가 병렬로 실행될 수 있습니다.
주요 요구 사항은 다음과 같습니다.

그리드 인스턴스는 처리할 데이터를 검색하는 Amazon S3와 통신해야 합니다.

그리드 인스턴스는 중간 데이터를 추적하기 위해 Amazon DynamoDB와 통신해야 합니다.

작업 스케줄러는 새 그리드 노드를 시작하기 위해 Amazon EC2 API와 통신하기만 하면 됩니다.
핵심 요구 사항은 환경이 직접 또는 온프레미스 프록시를 통해 인터넷에 액세스할 수 없다는 것입니다. 그러나 애플리케이션은 각각의 새로운 배포에 대해 재구성할 필요 없이 Amazon S3, Amazon DynamoDB 및 Amazon EC2 API와 원활하게 통신할 수 있어야 합니다.
솔루션 아키텍트는 다음 중 이 타겟 아키텍처를 달성하기 위해 무엇을 해야 합니까? (3개를 선택하세요.)

A. Amazon S3 및 DynamoDB에 대한 VPC 엔드포인트를 활성화합니다.

B. 사설 DNS 이름 지원을 비활성화합니다.

C. Amazon S3 엔드포인트의 프라이빗 DNS 이름을 사용하도록 그리드 인스턴스의 애플리케이션을 구성합니다.

D. 온프레미스 DNS 서버를 EC2 엔드포인트의 프라이빗 IP 주소로 채웁니다.

E. EC2용 인터페이스 VPC 엔드포인트를 활성화합니다.

F. 그리드 노드에서만 액세스를 허용하도록 Amazon S3 엔드포인트 정책을 구성합니다.

AWS-Solutions-Architect-Professional 문제 15

회사에 AWS로 마이그레이션해야 하는 Microsoft Windows 기반 애플리케이션이 있습니다. 이 애플리케이션을 사용하려면 여러 Amazon EC2 Windows 인스턴스에 연결된 공유 Windows 파일 시스템을 사용해야 합니다.
솔루션 설계자는 이를 달성하기 위해 무엇을 해야 합니까?

A. 볼륨 게이트웨이 모드에서 AWS Storage Gateway를 구성합니다. 각 Windows 인스턴스에 볼륨을 탑재합니다.

B. Amazon EFS를 사용하여 볼륨을 구성합니다. 각 Windows 인스턴스에 EFS 볼륨을 탑재합니다.

C. 필요한 크기로 Amazon EBS 볼륨을 구성합니다. 각 EC2 인스턴스를 볼륨에 연결합니다.
볼륨 내의 파일 시스템을 각 Windows 인스턴스에 마운트합니다.

D. Windows 파일 서버용 Amazon FSx를 구성합니다. Amazon FSx 볼륨을 각 Windows 인스턴스에 탑재합니다.

다른 버전: 1497Amazon.AWS-Solutions-Architect-Professional.v2024-06-22.q126; 4382Amazon.AWS-Solutions-Architect-Professional.v2024-04-01.q368; 3750Amazon.AWS-Solutions-Architect-Professional.v2023-10-04.q257; 2809Amazon.AWS-Solutions-Architect-Professional.v2023-02-18.q309; 3353Amazon.AWS-Solutions-Architect-Professional.v2022-05-27.q219

최근 업로드: 108Microsoft.AZ-500-KR.v2026-06-04.q213; 111Microsoft.DP-600-KR.v2026-06-04.q98; 105Microsoft.AZ-204-KR.v2026-06-04.q237; 136Microsoft.PL-600-KR.v2026-06-04.q112; 193Microsoft.SC-300-KR.v2026-06-03.q151; 154Microsoft.DP-600-KR.v2026-06-03.q70; 870PMI.PMP-KR.v2026-06-01.q1069; 231Microsoft.MS-102-KR.v2026-06-01.q252; 212Amazon.DOP-C02-KR.v2026-06-01.q207; 159Microsoft.AZ-104-KR.v2026-06-01.q197