AWS Certified Solutions Architect Associate Practice Test 2

Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

yundream
2022-08-14
2021-04-24
11021

### Question #1

<span style="color: rgb(5, 25, 34); font-family: 'Open Sans', sans-serif; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: 0.1px; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">외환 거래 응용 프로그램을 운영하는 상업은행이 있다. 이들은 은행이 현재 트래픽에 대처하고 비용 효율성을 달성 할 수 있도록 EC2 인스턴스의 Auto Scaling 그룹을 생성했다. 이들은 Auto Scaling 그룹이 EC2 인스턴스 수를 축소하기 전에 의도하지 않은 속도 저하 혹은 사용 불가능으로 부터 시스템을 보호할 수 있기를 원한다.

1. 오토스케일링 그룹이 어떠한 다움타임 없이 EC2 인스턴스를 추가하거나 종료하도록 한다.
2. 기본 휴지 시간은 600 초다.
3. 이전 조정 활동이 종료되기 전에 EC2 인스턴스를 추가하거나 종료하지 않도록 오토 스케일링 그룹을 설정한다.
4. 기본 휴지 시간은 300 초다.

#### 설명

조정 휴지 시간은 (caling cooldown) 오토 스케일링 그룹이 이전 활동의 효과가 나타나기 전에 추가 인스턴스를 시작하거나 종료하지 않도록 하는데 도움이 된다. 인스턴스의 비정상적 상태의 경우 오토 스케일링 그룹은 휴지 기간이 완료ㅗ딜 때까지 대기하지 않고 즉시 비정상 인스턴스를 교체한다.

![Auto scaling cooldown](https://docs.google.com/drawings/d/e/2PACX-1vQ7BB6SSc6EwfmGiB8LuawTzeevRfsleYQeX-tTqp-Z3FPaoedreLQb9V_1tbG9RyFDCwxDFvP7pc8q/pub?w=579&h=521)

기본 휴지 기간은 단순 조정 정책을 위한 모든 조정 활동에 적용된다. 기존 휴지 시간은 300초다.

1. 애플리케이션 티어에 오토 스케일링 그룹을 적용했다.
2. 트래픽이 급증하면 CloudWatch 경보가 울린다.
3. 오토 스케일링 그룹은 인스턴스를 시작한다.
4. 인스턴스가 시작되는데에는 3-5 분 정도가 소요 된다.
5. 휴지 기간이 없을 경우 CloudWatch 경보가 1분마다 울릴 수 있으며, 그 때마다 오토 스케일링 정책이 작동 할 것이다.
6. 휴지 기간을 설정하면 300초를 기다리게 되므로 안정적으로 스케일링 할 수 있다.

답 : 3,4

### Question #2

한 회사가 정부 기관과 협력하여 교통 계획 및 도류 유지 관리를 개선하여 사고를 예방하는 시스템을 만들고 있다. 제안된 솔류션은 교통 인프라를 실시간으로 관리하고, 문제가 감지되면 교통 엔지니어 및 비상 대응팀에 경고하고, 센서와 스마트 장치를 사용하여 긴급 요원이 사고 현장에 더 빨리 도달 할 수 있도록 교통 신호를 자동으로 변경하는 것이다.

스마트 디바이스를 클라우드 기반 애플리케이션에 연결 할 수 있도록 허용하는 AWS 서비스는 무엇인가 ?

1. Amazon Elastic Container Service
2. AWS CloudFormation
3. AWS IoT Core
4. AWS Elastic Beanstalk

#### 설명

AWS IoT Core는 서버를 프로비저닝 하거나 관리 할 필요 없이 IoT 디바이스를 AWS에 연결 할 수 있게 한다. AWS IoT Core는 수십억 개의 디바이스와 수조 건의 메시지를 지원하며, 안전하고 안정적으로 이러한 메시지를 처리하여 AWS 엔드포인트 및 다른 디바이스로 라우팅 할 수 있다.

AWS IoT Core는 AWS Lambda, Amazon Kinesis, Amazon S3, Amazon SageMaker, Amazon DynamoDB, Amazon CloudWatch, AWS CloudTrail, Amazon QuickSight 및 Alexa Voice Serv ice와 같은 AWS, Amaon 서비스를 사용하여, 컨넥티드 디바이스에서 생성한 데이터를 수집, 처리 분석하여 이를 기반으로 운영하는 IoT 애플리케이션을 쉽게 구축 할 수 있다.

AWS IoT Core는 MQTT, HTTPS, MQTT over WSS, LoRaWAN을 지원한다.

![AWS IoT Core](https://docs.google.com/drawings/d/e/2PACX-1vR5Fin1UX_dMdV0tHSH4F54so8cqICvVYKxnljXTKTL7_KdN2QkV_Ycs9W0qIcImc0sEb8KyAT4wEhE/pub?w=1290&h=732)

* AWS CloudFormation : 데이터 처리가 아닌 아키텍처의 생성과 관리를 위한 서비스다.
* AWS Elastic Beanstalk : Java, NET, PHP, Node.js, Python 등의 언어로 개발된 웹 애플리케이션의 개발 및 배포, 확장에 사용하는 서비스다.
* Amazon Elastic Container Service : 도커 인스턴스 생성과 관리 서비스다.

### Question #3

조직은 프레미스 데이터 센터에 다양한 회사의 재무 기록을 저장하고 있다. 데이터 센터의 용량이 부족해지면서, 경영진은 기존 기록을 클라우드 스토리지로 이동하기로 결정했다. 여기에는 미래의 모든 기록들도 저장 할 것이다. 저장 된 데이터는 삭제나 덮어쓰지 않도록 추가적인 보안 장치가 마련되어야 한다.

위의 요구 사항을 충족하려면 다음 중 무엇을 해야 하는가 ?

1. AWS Storage Gateway를 사용해서 하이브리드 클라우드 스토리지를 설정하고 모든 데이터를 Amazon EBS에 저장하고 객체 잠금을 실행한다.
2. AWS DataSync로 데이터를 옮긴다. 모든 데이터는 Amazon EFS에 저장하고 객체 잠금을 실행한다.
3. AWS Storage Gateway로 하이브리드 클라우드 스토리지를 설정한다. 모든 데이터를 Amazon S3에 저장하고 객체 잠금을 실행한다.
4. AWS DataSync로 데이터를 옮긴다. 모든 데이터는 Amazon S3에 저장하고 객체 잠금을 실행한다.

#### 설명

AWS DataSync는 온프레미스 스토리지 시스템과 AWS 스토리지 서비스간, 여러 AWS 스토리지간의 데이터 이동을 간소화, 자동화 및 가속화하는 온라인 데이터 전송 서비스다. DataSync를 사용하여 활성 데이터를 AWS로 마이그레이션하거나, 데이터를 아카이브하여 온프레미스 스토리지 용량을 확보하거나, 비즈니스 연속성을 위해서 데이터를 AWS에 복제, 분석 및 처리를 위해서 데이터를 클라우드로 전송 할 수 있다.

![DataSync](https://d1.awsstatic.com/aws-datasync-how-it-works-diagram-transfer-data-from-on-premises-to-AWS.348efd1b0f93399ea4edc7b6fd02a86d115b70e4.png)

AWS DataSync를 사용하며면 온프레미스 데이터를 Amazon S3, Amazon EFS, Amazon FSx로 마이그레이션 할 수 있다. DataSync로 전체 데이터의 복사본을 만들고 Amazon S3의 객체 잠금을 활성화하여 레코드의 삭제나 덮어쓰기를 방지 할 수 있다.

AWS DataSync는 주로 데이터를 마이그레이션하기 위해서 사용하며, AWS Storage Gateway는 마이그레이션 된 데이터의 지속적인 액세스를 유지하여 파일 기반 애플리케이션의 지속적인 업데이트를 원하는 경우에 더 적합하다.

* Amazon EFS는 파일 잠금을 지원한다. 객체 잠근은 S3의 기능이다.
* AWS Storage Gateway는 하이브리드 클라우드 스토리지를 설정하기 위해서 사용한다. 시나리오는 모든 데이터를 AWS로 마이그레이션 한다. 하이브리드 클라우드 스토리지 구축은 요구사항이 아니다.

답 : 4

### [4.](https://www.joinc.co.kr/w/man/12/awsCertification/SolutionArchitect/exam02#toc) Question #4

한 회사가 두명의 사용자가 업로드 한 이미지의 저장소 역할을하는 내부 애플리케이션을 구축하고 있다. 사용자가 이미지를 업로드 할 때마다 S3에 저장하기전에 Kiness Data Streams로 전송을 한다. 응용 프로그램은 사용자에게 작업이 성공했음을 알린다. 일반적으로 전체 처리에 걸리는 시간은 5분이다.

다음 옵션 중 Kinesis, S3에 업로드 할때 애플리케이션에 대한 요청을 비동기적으로 처리하고 응답하기 위한 비용 효율적인 방법은 무엇인가 ?

1. SNS를 이용하여 요청을 버퍼링 한다음 EC2 인스턴스를 이용해서 비동기적으로 처리한다.
2. SQS를 이용하여 요청을 큐에 저장하고 EC2 인스턴스를 이용해서 비동기적으로 처리한다.
3. Lambda와 Step function을 이용해서 요청을 비동기적으로 처리할 수 있도록 서비스들을 조율한다.
4. Kinesis 데이터 스트림을 SQS 큐로 대체하고, Lambda를 이용해서 비동기적으로 처리한다.

#### 설명

Lambda 콘솔, Lambda API, AWS SDK, AWS CLI 및 AWS SDK로 Lambda 함수를 직접 호출 할 수 있다. 또한 다른 AWS 서비스가 함수를 호출하도록 구성하거나 스트림 또는 대기열에서 읽기를 수행하고 함수를 호출하도록 구성 할 수 있다. 또한 함수를 호출 할 때 동기식으로 호출 할 것인지 비동기식으로 호출 할 것인지도 결정 할 수 있다.

스트림 또는 대기열에서 항목을 처리하려면 "이벤트 소스 매핑"을 생성하면 된다. 이벤트 소스 매핑은 Amazon SQS 대기열, Amazon Kinesis 스트림 또는 Amazon DynamoDB 스트림에서 항목을 읽어서 처리하는 Lambda 리소스다.

비동기적인 워크플로우에는 Kinesis 과 Amazon SQS를 사용 할 수 있을 것이다. SQS는 Kinesis 보다 더 저렴하기 때문에, 이 경우 Kinesis Data Streams를 Amazon SQS로 교체하면 더 많은 비용을 절약 할 수 있다.

따라서 정답은 kinesis 스트림을 Amazon SQS 대기열로 교체하고 요청을 비동기적으로 처리할 Lambda 함수를 생성하는 것이다.

### Question #5

재무 데이터 분석 서비스를 제공하는 기업이 AWS 아키텍처에 대한 컨설팅을 요청했다. 이 회사는 금융 데이터를 처리 한 다음 클라이언트가 사용하는 보고서를 출력하는 Amazon EC2 인스턴스 집합을 가지고 있다. 생성된 보고서 파일은 내구성 있는 저장소에 저장해야 한다. 서비스가 해외로 빠르게 확장됨에 따라 저장할 파일의 수는 시간이 지나면서 크게 증가 할 수 있다. 회사는 보고서를 전 세계에 있는 고객에게 더 빠르게 배포할 방법을 찾고 있다.

다음 중 이 시나리오 사용해야 하는 비용 효율적이고 확장가능한 스토리지 옵션은 무엇인가 ?

1. Amaon Redshift에 데이터를 저장하고 CloudFront CDN으로 배포한다.
2. 다수의 EC2 인스턴스 스토어에 데이터를 저장하고 ElastiCache로 배포한다.
3. S3에 데이터를 저장하고 CloudFront로 배포한다.
4. Amazon Glacier에 데이터를 저장하고 ElastiCache로 배포한다.

#### 설명

CDN(Content Delivery Network)는 거의 모든 최신 웹 애플리케이션의 핵심 구성요소다. 예전에 CDN은 정적 컨텐츠만 캐시하기 위해서 사용했으나 지금은 훨씬 다양한 기능을 제공한다.

CDN은 캐시의 역할을 하기 때문에 오리진의 부하를 줄이고, 요청자와 가까운 위치에 컨텐츠를 배치함으로 요청자의 경험을 향상시킨다. 결과적으로 CDN을 이용하면 애플리케이션을 확장 할 필요없이 요구사항을 충족할 수 있다.

![CloudFront](https://docs.google.com/drawings/d/e/2PACX-1vRIggI_whlCKYYayKNoSPUQOiRIN3ToUECDbWR1ChRLB3b-hkM2PtnK94t6ZWNhdDqJO1hM6VMNKsv9/pub?w=746&h=561)

Amazon S3는 중요 데이터를 저장하고 보관할 수 있는 뛰어난 확장성과 내구성을 제공하는 스토리지 서비스다. 신생회사는 오디오와 텍스트 데이터를 저장할 내구성 있는 저장소를 찾고 있으므로 올바른 옵션이다. ElastiCache는 캐싱에 사용되며 CDN 목적으로는 사용하지 않는다.

* Amazon Redshift는 데이터웨어하우스로 사용한다.
* Amazon S3 Glacier는 데이터 아카이브용으로 사용한다.
* 인스턴스 스토어는 내굿성을 제공하지 못한다.

### Question #6

네트워크 설계자는 음식 주문 애플리케이션을 개발하고 있다. 설계자는 EC2 서버의 인스턴스 ID, 퍼블릭 키 및 퍼블릭 IP 주소를 검색하는 애플리케이션을 개발해야 한다.

다음 중 이 요구사항을 충족하는 옵션은 무엇인가 ?

1. 인스턴스 메타데이터
2. 리소스 태그
3. 인스턴스 유저 데이터
4. AMI(Amazon Machine Image)

#### 설명

인스턴스 메타데이터는 실행 중인 인스턴스를 구성 또는 관리하는데 사용 할 수 있는 인스턴스 관련 데이터들이다. 인스턴스 메타데이터에는 호스트이름, 이벤트 및 보안 그룹과 같은 정보들을 포함한다.

인스턴스 메타데이터에는 인스턴스를 시작할 때 지정한 사용자 메타데이터에도 액세스 할 수 있다. 따라서 답은 1번이다.

인스턴스 메타데이터는 IMDSv1 과 IMDSV2 두 개의 버전이 있다.

* IMDSv1 : 요청/응답 방식
* IMDSv2 : 세션 지향 방식

인스턴스 메타데이터에 접근 할 수 있는 URL은 http://169.254.169.254/latest/meta-data/ 이다. 169.254.0.0/16 사이더는 Zeroconf를 위해서 사용하는 주소 영역이다.

![EC2 meta-data](https://docs.google.com/drawings/d/e/2PACX-1vRveImd_LJclpN8UkiUQ0zAwTNEgthcHCaNypgT6kabnrF9olJcqs3gWQZDl7crOapqsiheYtoZZd03/pub?w=667&h=392)

* **Instance user data**는 EC2 인스턴스가 실행돼었을 때, 자동으로 실행할 스크립트를 설정하기 위해서 주로 사용한다.
* **리소스 태그**는 AWS 리소스에 레이블을 할당하기 위해서 사용한다.
* **Amazon Machine Image**는 인스턴스를 실행하는데 필요한 이미지 정보를 제공한다.

답 : 1.

### Question #7

솔류션 아키텍트는 자주 액세스하지 않지만 감사자가 요청할 때 즉시 사용 할 수 있는 재무 보고서 시스템을 구성하기 위해서 새로운 S3 표준 클래스 버킷을 생성했다. 비용을 절감하기 위해서 아키텍트는 S3 버킷의 스토리지 클래스를 Standard에서 S3-IA(infrequent Access) 스토리지 클래스로 변경했다.

Amazon S3 Standard IA 클래스에 대한 올바른 설명은 무엇인가. (2개)

1. S3 IA는 필요할 때, 빠르게 데이터를 꺼낼 수 있도록 디자인됐다.
2. 높은 지연, 낮은 throughput을 제공한다.
3. 빈번하지 않은 요청에 최적화 됐다.
4. 데이터 보관을 목적으로 한다.
5. 운영 중에 데이터 접근 패턴에 따라서 가장 비용 효율적인 액세스 계층으로 자동으로 이동한다.

#### 설명

Amazon S3 Standard-Infrequent Access(Standard-IA)는 자주 접근하지 않지만 필요할 때 빠른 액세스가 필요한 데이터를 위한 S3 스토리지 클래스다. Standard-IA는 낮은 GB 스토리지 가격, 검색요금을 제공한다.

![Storage Class](https://k2y3h8q6.stackpathcdn.com/wp-content/uploads/2019/01/S3-1024x585.jpg)

Standard-IA는 장기 저장, 백업, 재해 복구를 위한 데이터 저장소로 이상적이다. Standard-IA 스토리지 클래스는 Standard와 동일한 버킷에 존재할 수 있으므로 수명주기 정책을 사용하여 애플리케이션 변경없이 스토리지 클래스 객체를 자동으로 전환 할 수 있다.

주요 기능은 아래와 같다.

* S3 Standard와 동일한 짧은지연 높은 처리량
* 99.99999999999%의 객체 내구성을 제공
* 전체 가용 영역에 영향을 미치는 이벤트에 대한 복원력
* 하나의 가용 영역 전체가 파괴되더라도 데이터를 복원
* 연간 99.9%의 가용성 제공
* 전송 데이터를 위한 SSL 및 저장 데이터의 암호화
* 자동화된 S3 수명 관리 정책

운영 중에 비용 효율적인 액세스 계층으로 자동으로 이동하는 것은 S3 Intelligent Tiering 의 기능이다.

데이터 보관을 목적으로 하는 것은 S3 Glacier 이다.

답 : 1, 3

### Question #8

솔류션 아키텍트는 PS4, Xbox One, Nintendo Switch 용 콘솔게임과 Android, iOS용 모바일 게임을 개발한다. 다양한 제품과 서비스를 위해서 아키텍트는 API Gateway를 사용 할 것을 제안했다.

아키텍트가 클라이언트에게 말 할 수 있는 API Gateway의 주요 기능은 무엇인가.(2개)

1. API 콜에 대해서만 비용을 지불하면 된다.
2. 서버리스 워크로드를 위한 RESTful API와 WebSocket API를 빌드 할 수 있다.
3. 애플리케이션은 운영체제 바이패스 인터페이스를 이용해서 애플리케이션 대규모 통신을 원할히 할 수 있다.
4. GraphQL과 비슷한 쿼리를 자동으로 지원한다.
5. 고정된 Anycast IP를 제공하며, 하나 이상의 AWS Region에 접근 하게 할 수 있다.

#### 설명

Amazon API Gateway는 규모와 관계 없이 REST 및 WebSocket API를 생성, 게시, 유지, 모니터링 및 보호하기 위한 AWS 서비스다. API 개발자는 AWS나 다른 웹 서비스는 물론 AWS 클라우드에 저장된 데이터에 접근하는 API를 생성 할 수 있다. AWS Management Console에서 몇 번의 클릭만으로 애플리케이션이 데이터, 비즈니스 로직 또는 Amazon Elastic Compute Cloud에서 실행되는 워크로드와 백앤드 서비스 기능에 액세스 할 수 있는 프런트 도어 역할을 하는 API를 생성 할 수 있다. 또한 Lambda를 사용 할 수 있으므로 서버리스 API를 실행 할 수 있다.

![Amazon API Gateway](https://docs.google.com/drawings/d/e/2PACX-1vRjz8yi2dOAIUKw0p51cXPHRAkRVHN-MW0GXrTL4FwfNotoIpvgcO1i2E5cYT5T_oGQ-eezeb7k1yXI/pub?w=599&h=419)

Amazon API Gateway는 트래픽 관리, 권한 부여 및 액세스 제어, 모니터링, API 버전 관리를 포함하여 최대 수십만개의 API 요청을 동시에 처리 할 수 있다. Amazon API Gateway는 최소 요금이나 시작 요금이 없다. 수신한 API 호출 갯수와 전송된 데이터 양에 대해서만 비용을 지불한다.

그러므로 답은

* 서버리스 워크로드를 최적화 할 수 있는 RESTful API, WebSocket API를 빌드 할 수 있다.
* 호출한 API 건수와 전송한 데이터의 크기에 따라서 비용을 지불한다.

하나 이상의 AWS 리전에서 호스팅되는 애플리케이션에 대한 고정 진입 역할을 하는 애니캐스트 IP 주소의 제공은 API Gateway가 아닌 AWS Global Accelerator의 기능이기 때문에 올바르지 않다.

운영체제에서 하드웨어 인터페이스에 직접 접근하여 통신 능력을 향상시키는 것은 API Gateway가 아닌 Elastic Fabric Adapter의 기능이다.

답 : 1, 2

### Question #9

보험 회사는 웹 애플리케이션에 메시지 필터링 기능을 구현할 계획이다. 이 솔류션을 구현하려면 각 견적 요청 유형에 대해 별도의 Amazon SQS 대기열을 생성해야 한다. 전체 메시지 처리는 24시간을 초과하지 않아야 한다.

회사의 솔류션 아키텍트는 위의 요구사항을 충족하기 위한 작업을 수행해야 한다.

1. 하나의 SNS 주제를 생성하고 SNS 주제를 구독하도록 SQS 대기열을 구성한다. SQS 큐에 동일한 메시지를 게시한다. 견적 요청 유형에 따라 각 대기열의 메시지를 필터링 한다.
2. 여러개의 SNS 주제를 생성하고 SNS 주제를 구독하도록 SQS 대기열을 구성한다. 견적 요청 유형에 따라 지정된 SQS 큐에 메시지를 게시한다.
3. Amazon Kinesis Data Streams에서 데이터 스트림을 생성하다. Amazon Kinesis Client Library를 사용하여 견적 요청 유형에 따라 지정된 SQS 대기열에 모든 레코드를 전달한다.
4. 하나의 Amazon SNS 주제를 생성하고 SNS 주제를 구독하도록 Amazon SQS 대기열을 구성한다. SNS 구독에서 필터 정책을 설정하여 견적 요청 유형에 따라 지정된 SQS 대기열에 메시지를 게시한다.

#### 설명

Amazon Simple Notification Service (Amazon SNS)는 완전 관리형 게시/구독형 메시징 서비스다. 게시자는 논리적 액세스 포인트 및 통신 채널인 토픽에 메시지를 전송하여 구독자와 비동기적으로 통신한다. 클라이언트는 Amazon Kinesis Data Firehose, Amazon SQS, AQS Lambda, HTTP, 이메일, 모바일 푸시, 모바일 문자메시지와 같은 앤드포인트 요형을 사용하여 SNS 주제를 구독하고 게시된 메시지를 수신 할 수 있다.

![Amazon SNS](https://docs.aws.amazon.com/ko_kr/sns/latest/dg/images/sns-delivery-protocols.png)

Amazon SQS는 분산 애플리케이션에서 폴링 모델을 통해 메시지를 교환하는데 사용하는 메시지 대기열 서비스다.

팬아웃(fanout)시나리오에서 SNS 주제에 메시지가 게시되면, 이 메시지는 복제되어서 Amazon SQS 대기열, HTTP(S) 엔드 포인트 및 Lambda 함수와 같은 여러 엔드 포인트로 푸시된다. 이러한 구성은 병렬 비동기 처리를 허용한다.

![SNS Fanout 시나리오](https://docs.google.com/drawings/d/e/2PACX-1vQOAfcOvV4CB0s8X4VcF1atpPaztURduYNHK9Ec3upriDnY5aKvTomRtqgVG9lhNqvn6fkaL3N7WohL/pub?w=612&h=252)

예를 들어 제품을 주문할 때마다 SNS 주제에 메시지를 게시하는 애플리케이션을 개발 할 수 있다. 그 다음 SNS 주제를 구독하는 두 개 이상의 SQS 대기열이 새 주문에 대한 동일한 알림을 받는다. 어떤 EC2 인스턴스는 주문을 처리 할 수 있고, 다른 EC2 인스턴스는 데이터 처리를 위해서 데이터 웨어하우스에 전송 할 수 있다.

기본적으로 Amazon SNS 구독자는 주제에 게시된 모든 메시지를 수신한다. SNS 필터링을 사용하면 필더 정책을 할당하여 관심있는 메시지만 읽을 수 있다.

따라서 장답은 하나의 SNS 주제를 생성하고, 이 주제를 구독하는 Amazon SQS 대기열을 구성하는 것이다. SNS 구독에서 필터 정책을 설정하여 견적 요청 유형에 따라 지정된 SQS 대기열에 메시지를 게시한다.

#### 참고

필터 정책은 구독자가 어떤 메시지를 수신할지 정의하는 속성을 포함하는 단순한 JSON 객체다. 메시지를 주제에 게시하면 Amazon SNS는 메시지 속성을 각 주제의 고독에 대한 필터 정책을 비교하여서 일치하는 속성이 있을 경우 메시지를 전송한다.

### Question #10

암호 화폐 교환 포털 서비스를 운영하고 있는 회사가 있다. 이 서비스는 Application Load Balancer과 Auto Scaling 그룹으로 묶인 EC2 인스턴스로 호스팅되고 있다. 전 세계 사용자가 사용하지만 대부분 일본과 스웨덴에서 사용한다. 이 두 위치의 규정 요구사항으로 인해 일본 사용자는 ap-northeast-1(도쿄) 리전의 서비스에 연결하고 스웨덴 사용자는 eu-west-1(아일랜드)리전의 서버에 연결해야 한다.

이 요구 사항을 충족하는 서비스는 무엇인가. ?

1. 지역제한 기능이 활성화된 CloudFront 웹 배포를 설정한다.
2. 트래픽을 적절한 AWS Region으로 라우팅되도록 Application Load Balancer를 설정한다.
3. 가중치 기반 Route 53 라우팅 설정을 한다.
4. 위치기반 라우팅 정책으로 Route 53을 설정한다.

#### 설명

지리적 라우팅을 사용하면 사용자의 지리 위치, 즉 DNS 쿼리가 발생하는 위치를 기반으로 트래픽을 제공하는 리소스를 선택 할 수 있다. 예를 들어 유럽에서 발생하는 모든 쿼리를 프랑크푸르트 리전에 위치한 ELB 로드 밸런서로 라우팅 할 수 있다.

지리 위치는 IP 주소를 위치에 매칭하는 방식으로 작동한다. 그러나 일부 IP 주소들은 지리 위치에 매핑되지 않으므로, 식별할 수 없는 위치에서 온 일부 DNS 쿼리를 수신 할 수 있다.

Elastic Load Balancer는 AWS 리전이 아닌, 가용 영역 단위에서 트래픽을 분산하기 때문에 Application Load Balancer를 설정하는 것은 올바르지 않다.

CloudFront의 지리적 제한 기능 설정은 주로 특정 지리적위치의 사용자가 CloudFront를 통해 컨텐츠에 액세스하지 못하도록 사용한다.

답 : 4

### Question #11

이 회사는 S3 버킷의 정적 웹 호스팅 기능을 이용해서 서비스를 하고 있다. 이 회사는 Route 53을 사용하여 등록된 새로운 도메인이 가지고 있다. 회사는 새 도메인으로 정적 웹 호스팅을 서비스하도록 지시했다.

Amazon Route 53을 이용해서 Amazon S3 버킷을 서비스하기 위해서 필요한 조건은 무엇인가 ? (2개 선택)

1. S3 버킷이름은 반드시 도메인 이름과 일치해야 한다.
2. S3 버킷에 CORS(Cross-Origin Resource Sharing) 옵션을 활성화 한다.
3. 도메인 이름을 등록한다.
4. 반드스 MX 레코드를 설정해야 한다.
5. S3 버킷은 호스트 존과 같은 리전에 있어야 한다.

#### 설명

Amazon S3 버킷에서 정적 호스팅되는 사이트로 트래픽을 라우팅하기 위해서는 아래의 사전 조건이 필요하다.

* S3 버킷이름과 도메인 이름이 반드시 일치해야 한다. 예를 들어 도메인 이름이 www.joinc.co.kr 이라면, S3 버킷이름도 www.joinc.co.kr 이어야 한다. joinc.co.kr 도메인이름도 사용하고 싶다면, joinc.co.kr 버킷을 만들고 www.joinc.co.kr 로 리다이렉트 되도록 구성해야 한다.
* 도메인이름을 Rou53 53에 등록해야 한다.

MX 레코드는 이메일을 수락하기 위한 메일 서버를 지정하는 옵션이므로 올바른 답이 아니다.

[CORS](https://www.joinc.co.kr/w/man/12/CORS)는 한 도메인의 클라이언트가 다른 도메인의 리소스를 요청 할 때 활성화 한다. 따라서 S3 버킷의 리소스에 접근하하기 위해서는 CORS 옵션을 설정 할 필요가 없다.

답 : 1, 3

### Question #12

이 회사는 전 세계인이 사용하는 웹 애플리케이션을 서비스 하고 있다. 이 웹 애플리케이션은 Classic Load Balancer 뒤의 EC2 인스턴스의 Auto Scaling 그룹에서 호스팅 된다. 여러 도메인이 동일한 IP 주소를 통해 SSL 트래픽을 제공하도록 허용하여 애플리케이션을 보호해야 한다.

위의 요구 사항을 충족하려면 무엇을 해야 하는가 ?

1. Elastic IP를 사용하고 ACM(AWS Certificate Manager)를 이용해서 Classic Load Balancer에 여러 개의 타사 인증서를 업로드 한다.
2. SNI(Server Name Indication) 을 이용해서 Classic Load Balancer에 각 도메인별로 여러 개의 SSL 인증서를 업로드 한다.
3. ACM을 이용해서 SSL 인증서를 선택하고 CloudFront 배포를 생성한다. 인증서를 웹 배포와 연결하고 SNI 지원을 활성화 한다.
4. 동일한 IP로 부터 여러 개의 도메인을 허용하는 SSL 설정은 불가능 하다.

#### 설명

SNI란 TLS 서버 이름 표시의 작동방식이다. 서버 이름 표시라고도 부르는 SNI는 클라이언트가 TLS 핸드 셰이크의 첫 번째 단계에서 도달하려는 도메인 이름을 지정할 수 있도록하는 기능을 포함하여 일반적인 도메인 이름 불일치 오류를 방지한다.

SNI는 집(단독주택) 대신 아파트 건물에 우편을 보내는 것과 다소 비슷하다. 집으로 우편을 보내는 거라면 집의 주소만 알고 있으면 된다. 하지만 아파트로 우편을 보내는 거라면, 아파트의 동 주소와 호도 알고 있어야 한다. 만약 그렇지 않으면 올바른 사람에게 전달될 수 없을 것이다.

웹 서비스도 마찬가지다. 때때로 웹 서비스는 여러 개의 도메인으로 서비스 해야 할 때가 있다. 이 경우 클라이언트가 웹 사이트 중 하나에 접근 하려고 할 때, 어떤 인증서를 사용해야 할지 모를 수 있다. 이는 클라이언트가 웹 사이트를 표시하기 전에 SSL/TLS 핸드 셰이크가 발생하기 때문이다.

![SNI](https://imgnew.megazone.com/wp-content/uploads/2018/10/31095253/image12_new_a.png)

SNI는 TLS 프로토콜의 확장으로 이 확장을 사용하면 호스트의 올바른 이림을 지정 할 수 있다. SNI Custom SSL은 Chrome 버전 6 이상, 윈도우즈 XP이상, OS X 10.5.7 이상, Safari 버전 3 이상 등 대부분의 브라우저에서 작동한다.

일부 이전 브라우저는 SNI를 지원하지 않고 CloudFront 에 연결할 수 없을 수 있다. 이러한 경우 CloudFront용 사용자 지정 SSL 옵션을 사용해야 한다.

Classic Load Balancer는 SNI를 지원하지 않기 때문에 여러 도메인에 대한 SSL 트래픽을 처리 할 수 있도록 추가하는 것은 올바르지 않다. 대신 Application Load Balancer를 사용하거나 CloudFront의 SNI를 사용해야 한다.

답 : 3

### Question #13

250TB의 대용량 데이터 아카이브를 호스팅해야 하는 미디어 회사가 있다. 이들은 내구성과 중복성 문제를 해결하기 위해서 S3로 이동하기로 결정했다. 이 회사는 현재 본사를 인터넷에 연결하는 100Mbps 전용선을 가지고 있다.

다음 중 모든 데이터를 Amazon S3로 옮기는 가장 빠르고 비용 효율적인 방법은 무엇 인가 ?

* AWS Direct Connect 연결을 활성화하고 S3에 데이터를 전송한다.
* AWS Snowball 디바이스를 주문하여서 S3에 파일을 업로드 한다.
* AWS Snowmobile를 이용해서 S3에 데이터를 전송한다.
* S3에 직접 파일을 업로드 한다.

#### 설명

AWS Snowball은 페타바이트 규모의 대량 데이터를 AWS 클라우드 안밖으로 전송하는 어플라이언스 솔류션이다. Snowball을 사용하면 높은 네트워크 비용, 긴 전송 시간, 보안 문제 등 대규모 데이터 전송과 관련된 일반적인 문제를 해결 할 수 있다. Snowball을 사용한 데이터 전송은 간단하고 빠르고 안전하며, 고속 인터넷 비용의 1/5의 비용으로 묵적을 달성 할 수 있다.

![Snowball](https://docs.google.com/drawings/d/e/2PACX-1vRWjwPH-NtJIHiQC2YeEIr8bopCsSGzjtk_qaE6vTDz2yiWyqmkhSkJ0IwH929Lj7qu8UJtENCT3MbM/pub?w=517&h=328)

Snowball과 고속 인터넷의 선택의 기준은 아래와 같다.

* 인터넷을 통해 데이터를 로드하는데 1주일 이상이 소요될 것으로 예상되는 경우 Snoball 사용을 고려한다. 일반적인 사용 사례는 클라우드 마이그레이션, 재해복구, 데이터 센터 폐기 및, 컨텐츠 배포다.
* 1주일 이내에 인터넷을 통해 데이터를 전송할 수 있다면 Snowball이 이상적인 솔류션이 아닐 수 있다.

예를 들어 100MB 연결을 사용 할 수 있는 환경에서 100TB의 데이터를 전송해야 하는 경우, 데이터 전송을 완료하는데 100일 이상이 걸린다. Snowball을 사용하면 1주일내에 완료 할 수 있다. 아래에 각 인터넷 연결 옵션별로 80%의 대역폭을 사용 했을 때, 100TB를 옮기는데 이론적으로 걸리는 시간을 정리했다.

| 인터넷 연결 회선 | 걸리는 시간 |
| --------- | ------ |
| T3(44.736Mbps) | 269일 |
| 100Mbps | 120일 |
| 1000Mbps | 12일 |

AWS Snowball은 50TB, 80TB 모델이 있으며, RJ45 1 GigE 1개와 두면에 두 개의 SFP+ 10GigE 네트워크 인터페이스를 가지고 있다. 250TB의 데이터라면 50TB Snowball 5개 (혹은 80TB Snowball 4개)를 이용해서 (분산 작업 할 수 있으므로)1주일 이내에 작업을 끝낼 수 있을 것이다.

답 : 2

### Question #14

한 회사는 웹 애플리케이션 제품군에 대해 IPv6가 활성화된 여러 VPC를 운영하고 있다. 솔류션 아키텍트는 새 Amazon EC2 인스턴스를 배포하려고 했지만 서브넷에 사용가능한 IP 주소가 없다는 오류가 표시되었다. 솔류션 아키텍트는 이 문제를 어떻게 해결해야 하는가 ?

1. VPC에 IPv4 CIDR만 있는지 확인한다. 모든 IPv4 CIDR을 삭제한다.
2. 커다란 CIDR 범위를 가지는 새로운 IPv4 서브넷을 설정한다. 새로운 IPv4 서브넷에 인스턴스가 실행되게 한다.
3. VPC의 IPv4 지원을 비활성화 하고 사용 가능한 IPv6 주소를 활용한다.
4. 커다란 CIDR 범위를 가지는 새로운 IPv6 서브넷을 설정한다. 새로운 IPv6 서브넷에 인스턴스가 실행되게 한다.

#### 설명

Amazon Virtual Private Cloud(VPC)는 사용자가 정의한 논리적으로 격리된 가상 네트워크다. VPC는 IP 주서 범위, 라우터, 라우팅 테이블, 네트워크 게이트웨이 구성 등을 제공하며, 이를 이용해서 완전한 가상 네트워킹 환경을 구성 할 수 있다. VPC는 IPv4와 IPv6를 모두 사용 할 수 있으므로 리소스 및 애플리케이션에 안전하고 쉽게 접근 할 수 있다.

VPC는 커다란 CIDR을 가지며, 하나 이상의 서브넷으로 구성된다. 각 서브넷은 VPC CIDRs를 나눠서 사용하게 된다. 서브넷은 독자적인 IP 주소 범위를 가지며, 애플리케이션들은 이 서브넷에서 IP를 할당 받아서 실행된다. 각 서브넷은 가용 영역당 구성되며, 여러 가용 영역으로 구성 할 수 없다.

* IPv4 CIDRs 는 필수로 구성된다.
* IPv6 CIDRs 는 옵션이다.

VPC는 IPv4와 IPv6의 이중 스택 모드에서 작동 할 수 있다. 리소스는 IPv4와 IPv6 모두에서 통신 할 수 있다.

기본적으로 새 EC2 인스턴스는 IPv4를 사용한다. 이 시나리오에서 발생한 문제를 해결 하려면 IPv4 서브넷을 생성하고 새 서브넷에 EC2 인스턴스를 배포해야 한다. 따라서 정답은 더 큰 CIDR 범위를 가지는 새로운 IPv4 서브넷을 설정하는 것이다.

새로운 IPv6 서브넷을 설정하기 위해서는 먼저 IPv4 CIDR을 추가해야 하므로, 커다란 CIDR 범위를 가지는 새 IPv6 전용 서브넷 설정은 올바르지 않다.

![IPv6, IPv4 subnet](https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/images/subnets-diagram.png)

답 : 2

### Question #15

회사는 AWS 계정의 모든 구성을 평가하고 감사해야 한다. Amazon S3 버킷에 대한 모든 구성 변경 사항을 추적하여 엄격한 규정 준수를 시행해야 한다. 공개적으로 액세스 할 수 있는 S3 버킷은 데이터 침해를 방지하기 위해서 자동으로 식별되어야 한다.

다음 중 이 요구 사항을 충족하는 옵션은 무엇인가 ?

1. AWS IAM을 사용하여 자격 증명 보고서를 생성한다.
2. AWS Trusted Advisor를 이용해서 AWS 환경을 분석한다.
3. AWS CloudTrail을 이용해서 AWS 어카운트에서 발생한 이벤트들을 리뷰한다.
4. AWS Config를 이용해서 AWS 어카운트를 설정한다.

#### 설명

AWS Config는 AWS 리소스 구성을 측정, 감사 및 평가할 수 있는 서비스다. Config는 AWS 리소스 구성을 지속적으로 모니터링 및 기록하고 원하는 구성을 기준으로 기록된 구성을 자동으로 평가해 준다. 이에 따라 규정 준수 감사, 보안 분석, 변경 관리 및 운영 문제 해결 작업을 간소화 할 수 있다.

AWS Config를 사용하여 AWS 리소스의 구성 설정을 평가할 수 있다. AWS Config 규칙을 생성하면 AWS 계정에서 이상적인 구성을 적용 할 수 있다. 또한 리소스에 적용된 구성이 규칙의 조건을 위반하는지 확인한다.

따라서 정답은 AWS Config를 이용하여 AWS 어카운트에 규칙을 설정하는 것이다.

AWS Trusted Advisor는 AWS 모범 사례에 따라서 리소스를 프로비저닝하는데 도움이 되도록 실시간 지침을 제공하는 서비스로 리소스에 대한 규칙을 정의하는 서비스는 아니다.

AWS CloudTrail은 리소스에서 발생한 내용을 추적 할 수는 있지만 규정준수 규칙을 설정 할 수는 없다.

답 : 4

### Question #16

한 광고 회사는 현재 고객에게 SEO 분석을 자동으로 제공하는 POC(개념 증명) 프로젝트를 진행하고 있다. 회사에는 IPv4, IPv6 통신이 허용되는 이중 스택 모드에서 작동하는 VPC를 가지고 있다. 이 VPC에 Auto Scaling EC2 인스턴스 그룹이 있으며, 앞단에 Application Load Balancer가 배치되어 있다. 이제 활성화된 도메인 이름이 Application Load Balancer를 가리키도록 해야 한다.

Route 53에서 Application Load Balancer의 DNS이름을 가리키는데 사용 할 수 있는 레코드 유형은 무엇인가 ? (2개 선택)

1. A 레코드와 Non-Alias
2. MX 레코드와 Alias
3. A 레코드와 Alias
4. CNAME과 Alias
5. AAAA 레코드와 Alias

#### 설명

도메인 트래픽을 ELB로 라우팅하려면 Amazon Route 53을 사용해서 로드밸런서를 가리키는 별칭 레코드를 생성한다. 별칭 레코드는 Route 53 도메인 확장이다. IPv6 를 활성화하기 위해서는 AAAA 레코드를 생성해야 한다. Elastic Load Balancer는 IPv6를 지원한다.

Route 53의 지원 레코드는 아래와 같다.

* A 레코드 : IPv4 주소를 사용한다. (예, 192.0.2.1)
* AAAA 레코드 : IPv6 주소를 사용한다.
* Alias 레코드 : Route 53의 고유 확장이다. CloudFront, Amazon S3 등 선택한 AWS 리소스로 트래픽을 라우팅 할 수 있다. CNAME 레코드와 달리 zone apex라고도 하는 DNS 네임스페이스의 최상위 노드에 레코드를 만들 수 있다. 예를 들어 example.com을 등록했다면 zone apex는 example.com이다. example.com에 대한 CNAME은 만들 수 없지만, www.example.com으로 트래픽을 라우팅하는 example.com의 별칭을 만들 수 있다.

Route 53의 Alias는 아래의 해당 되는 값으로 응답 할 수 있다.

* Amazon API Gateway
* Amazon VPC 인터페이스 엔드포인트
* CloudFront 배포
* Elastic Beanstalk 환경
* ELB 로드 밸런서
* AWS Global Accelerator 액셀러레이터
* 정적 웹사이트로 구성된 Amazon S3 버킷
* 동일한 호스팅 영역의 다른 Route 53 레코드

따라서 답은 1, 5 이다.

답 : 1, 5

### Question #17

HTML, CSS 및 기타 클라이언트 측 Javascript로 구성된 웹 사이트를 AWS 환경에서 호스팅 하고 있다. 이 사이트는 여러 고해상도 이미지를 웹 페이지에 표시해야 한다. 웹 사이트와 사진은 가능한 최적의 응답 시간을 가지며 높은 요청 속도로 확장 할 수 있어야 한다.

다음 중 가장 비용 효율적이고 빠른 경험을 제공하는 아키텍처는 무엇인가. ?

1. EC23 인스턴스에 NginX 웹 서버를 설치하고 HTML, CSS, Javascript 파일을 캐시해서 호스팅한다. 이미지는 S3 버킷에 올린다. CloudFront를 이용해서 사용자에게 이미지를 제공한다.
2. Amazon LightSail Nginx 인스턴스에 HTML, CSS, Javascript 파일을 캐시해서 호스팅한다. 이미지는 S3 버킷에 올리고 CloudFront를 이용해서 사용자에게 이미지를 제공한다.
3. Apache 웹 서버를 미리 설정한 AMI를 이용해서 Auto Scaling 그룹을 실행한다. 이미지는 Elastic Block Store에 저장하고 EC@ 인스턴스를 AWS Global Accelerator 엔드포인트로 설정한다.
4. HTML, CSS, Javascript, 이미지를 단일 S3 버킷에 올리고 웹 사이트 호스팅을 활성화한다. CloudFront 배포를 생성하고 S3 웹 사이트 엔드포인트를 도메인으로 묶어서 서비스한다.

#### 설명

Amazon S3는 업계 최고의 확장성, 가용성, 보안 및 성능을 제공하는 객체 스토리지 서비스다. 또한 Amazon S3를 사용하여 정적 웹 사이트를 호스팅 할 수 있다. 정적 웹 사이트를 사용하여 HTML, CSS, Javascript, 이미지등의 컨텐츠를 서비스 할 수 있다. Amazon S3는 확장성이 뛰어나며 사용한만큼만 지불하면 된다.

Amazon CloudFront는 짧은 지연시간과 빠른 전송 속도로 전 세계 고객에게 데이터, 비디오, 애플리케이션 및 API를 안전하게 제공하기 위해서 사용하는 CDN 서비스다. CloudFront는 S3와 통합되어서 S3의 버킷을 최종 사용자에게 빠르게 전달 할 수 있다. 설계상 CloudFront에서 데이터를 제공하는 것은 S3에서 사용자에게 직접 제공하는 것 보다 비용 효율적일 수 있다.

![s3와 cloudfront](https://docs.google.com/drawings/d/e/2PACX-1vRcFb2PZifbzLjEqNHj-wwMdhdNRTTiKp-eg1FBQIKX9Qq5KoxVP6VJKKMrqGkNuAIR5wuaWvkjdaLg/pub?w=624&h=646)

주어진 시나리오는 정적 웹 사이트를 호스팅하는 것이다. 정적 콘텐츠만 다루기 때문에 S3의 웹 호스팅 기능을 활용 할 수 있다. 그런 다음 CloudFront와 통합하여 아키텍처를 개선 할 수 있다. 이렇게 사용하면 표준 웹 서버에서 서비스를 제공ㅎ가는 것보다 웹 페이지와 이미지를 더 빠르게 제공 할 수 있다.

EC2 인스턴스를 이용해서 정적 웹 사이트를 호스팅ㅎ가는 것은 비용이 많이 드는 솔류션이다. EC2 인스턴스는 일반적으로 동적 웹 애플리케이션을 호스팅 하는데 사용한다.

AWS Global Accelerator는 Amazon Web Service의 글로벌 네트워크 인프라를 통해 사용자에게 트래픽을 전송하여 인터넷 사용자의 성능을 최대 60% 개선하는 네트워킹 서비스다. Global Accelerator의 자동 라우팅 최적화 기능은 인터넷이 혼잡할 때, 패킷 손실, 지연 시간을 일관적으로 낮게 유지한다. EC2 인스턴스에 웹 서버를 설치하고 Global Accelerator로 가리키도록 하는 것은, 예전에 사용하던 정적 웹 사이트 제공 방식이다. 지금은 S3와 CloudFront로 훨씬 더 쉽고, 비용 효율적으로 구성 할 수 있다.

답 : 4

### [18.](https://www.joinc.co.kr/w/man/12/awsCertification/SolutionArchitect/exam02#toc) Question #18

온라인 이벤트 등록 시스템은 AWS에서 호스팅되며 ECS를 사용하여 프론트앤드 계층과 데이터베이스 계층을 분리해서 운영하고 있다. 데이터베이스 계층은 다중 AZ로 구성된 RDS를 사용하고 있다. Amazon RDS가 대기(standby) 복재본에 대한 자동 장애 조치를 수행하게 만드는 이벤트는 무엇인가 ? (2개 선택)

1. Primary 스토리지의 실패
2. Secondary DB 인스턴스의 컴퓨팅 유닛 실패
3. Secondary DB 인스턴스의 스토리지 실패
4. 읽기 전용 복제본의 실패 이벤트
5. Primary 가용영역의 실패

#### 설명

Amazon RDS는 다중 AZ 배포를 사용하여 DB 인스턴스에 대한 고 가용성 및 장애조치를 제공한다. Oracle, PostgreSQL, MySQL, MariaDB DB 인스턴스들이 다중 AZ 배포를 이용한 장애조치 기술을 사용한다. SQL Server DB 인스턴스는 SQL Server 데이터베이스 미러링(DBM)을 사용한다.

다중 AZ 배포에서 Amazon RDS는 다른 가용 영역에 동기식으로 작동하는 대기 복제본을 프로비저닝한다. 기본 DB 인스턴스는 가용영역에서 대기 복제본으로 동기식으로 복제되어 데이터 중복성을 제공하고, 시스템 백업 및 지연 시간 급증을 ㅜ치소화 한다.

Amazon RDS는 다중 AZ 배포에 대한 일반적인 실패 시나리오들을 감지하고 자동으로 복구하므로 관리자의 개입 없이 안전한 데이터베이스 작업을 수행 할 수 있다. 다중 AZ 배포는 읽기 성능을 향상하기 위한 확장 솔류션이 아니다. 읽기 성능 향상은 **읽기 전용 복제본** 기능이 담당하고 있다. 다중 AZ에서 대기 복제본은 읽기 트래픽에 사용 할 수 없다.

Amazon RDS는 아래와 같은 경우 자동으로 장애 조치를 수행한다.

* RDS 데이터베이스 인스턴스의 보안 업데이트 등으로 유지 관리 기간 동안 장애조치가 트리거 된다.
* Primary 가용 영역의 가용성 손실
* Primary 데이터베이스와의 네트워크 연결 실패
* Primary의 컴퓨팅 유닛의 실패
* Primary 스토리지의 실패
* 사용자 DB 인스턴스에 장애 조치를 요청한다.

![다중 AZ](https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/con-multi-AZ.png)

장애 조치가 발생하면 DB 인스턴스의 DNS 레코드가 예비 인스턴스를 가리키도록 자동으로 변경한다. 그 결과 DB 인스턴스의 기존 연결을 모두 재설정해야 한다. Java 애플리케이션의 경우 JVM 환경에서 Java DNS 캐싱 매커니즘이 작동하는 방식 때문에 JVM 설정을 다시 구성해야 할 수 있다. 이 경우 캐시된 IP 정보를 정기적으로 새로 고치도록 JVM의 TTL을 설정하는 것이 중요하다.

답 : 1, 5

### Question #19

한 회사가 고성능 컴퓨팅 워크로드를 위해 Lustre 파일 시스템용 Amazon FSx를 사용하는 Amazon ECS Docker 컨테이너에서 호스팅 되는 엔터프라이즈 웹 애플리케이션을 보유하고 있다. 재해 복구를 위해 웜 대기 환경이 다른 AWS 리전에서 실행되고 있다. 솔류션 아키텍트는 기본 애플리케이션 스택이 중단되는 경우에만 라이브 트래픽을 재해 복구(DR) 환경으로 자동 라우팅하는 시스템을 설계하도록 지시 받았다.

위 요구 사항을 충족하기 위해서 아키텍트가 해야 할 일을 선택하라.

1. Primary 서비스 엔드포인트에 상태 확인을 하도록 Route 53 장애 조치 라우팅 정책을 설정한다. Primay 리소스가 비정상일 때 보조 레코드로 트래픽을 전달하도록 Route 53을 구성한다. Evaluate Target Health 옵션을 활성화 한다.
2. Primary 스택과 DR 환경 모두에 상태 확인을 추가하고 Route 53에 가중치 기반 라우팅 정책을 설정한다. Route 53이 상태 확인에 지정된 엔드 포인트로 요청을 보낼 수 있도록 라우팅 테이블을 구성한다. Evaluate Target Health 옵션을 활성화 한다.
3. CloudWatch 알림을 설정하여 Route 53 DNS 엔드 포인트를 모니터링하고 Lambda 함수를 생성한다. 보조 DNS 레코드에 대한 장애조치를 시작하는 함수를 사용하여 ChangeResourceRecordSets API 호출을 실행한다.
4. CloudWatch 알림을 설정하여 기본 Route 53 DNS 엔드포인트를 모니터링하고 사용자 지정 Lambda 함수를 생성한다. 보조 DNS 레코드에 대한 장애조치를 시작하는 함수를 사용하여 ChangeResourceRecordSets API 호출을 실행한다.

#### 설명

Active-Passive 장애조치는 보조 리소스를 준비하고 있다가 기본 리소스에 문제가 생기면, 보조 리소스가 서비스를 대신하여 계속 서비스를 제공 할 수 있도록 하는 방법이다. Route 53에 질의를 하면 정상적인 기본 리소스만 응답한다. 모든 기본 리소스가 비정상이 될 경우 Route 53은 보조 리소스를 리턴하기 시작한다.

하나의 기본 레코드와 하나의 보조 레코드로 액티브-패시브 장애 조치 구성은 단지 레코드를 만들고 라우팅 정책에 장애조치를 지정하기만 하면 된다. 기본 리소스가 정상이면 Route 53은 기본레코드를 사용하여 DNS 쿼리에 응답한다. 기본 리소스가 비정상이면 Route 53은 보조 레코드를 사용하여 DNS 쿼리에 응답한다.

모니터링은 IP 주소 또는 도메인이름으로 지정할 수 있다. 사용자가 지정하는 간격으로 Route 53은 인터넷을 통해 애플리케이션, 서버 또는 기타 리소스에 자동으로 요청을 제출하여 사용가능한 상태인지 확인한다.

![Route 53 Health Check](https://docs.google.com/drawings/d/e/2PACX-1vR152kqn30k3g5l-JmrNqPO2mbL8DeqlK64sF0udFDi9jV8IkzyrrxKq3dSnNPaQHb6d9J93aMDI2hd/pub?w=458&h=482)

Route 53은 엔드 포인트의 상태를 확인할 때 지정한 IP 주소와 포트로 HTTP, HTTPS 또는 TCP 요청을 보낸다. 상태 확인이 성공하려면 라우터 및 방화벽 규칙이 Route 53이 사용하는 IP 주소의 인바인트 트래픽을 허용해야 한다.

따라서 정답은 기본 서비스 엔드포인트에 대한 상태확인을 추가하여 Route 53을 이용 장애 조치 라우팅을 설정하는 것이다. 기본 리소스가 비정상일 때 보조 레코드로 라우팅 하도록 Route 53을 구성한다.

답 : 1

### Question #20

<span style="color: rgb(5, 25, 34); font-family: 'Open Sans', sans-serif; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: 0.1px; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">DevOps 팀의 한 구성원이 Amazon EC2 인스턴스 중 하나에 연결이 안된다고 문의했다. 애플리케이션 아키텍처는 처음에 4개의 EC2 인스턴스로 설정되며, 각 인스턴스는 모두 퍼블릭 서브넷에 속하는 EIP 주소를 가지고 있다. 애플리케이션의 요청이 증가하면 이를 처리하기 위해 새로운 인스턴스를 시작한다. EC2 인스턴스들은 동일한 보안 그룹에 속한다. 인터넷을 통해 트래픽을 보내거나 받을 수 없는 EC2 인스턴스 하나를 제외하고는 다른 모든 것이 예상대로 잘 작동한다.

1. EC2 인스턴스가 퍼블릭 IP 주소와 연결되지 않았다.
2. EC2 인스턴스가 인터넷 게이트웨이에 연결되지 않은 가용 영역에 배치됐다.
3. EC2 인스턴스가 프라이빗 IP 주소와 연결되지 않았다.
4. 라우트 테이블의 트래픽이 인터넷 게이트웨이로 향하도록 설정되지 않았다.

#### 설명

IP 주소를 사용하면 VPC의 리소스가 서로 통신하고 인터넷으로도 통신 할 수 있다. Amazon EC2와 Amazon VPC는 IPv4 및 IPv6 프로토콜을 사용 할 수 있다. 기본적으로 Amazon EC2 및 Amazon VPC는 IPv4 프로토콜을 사용한다. VPC를 생성 할 때는 IPv4 CIDR 블록을 할당해야 한다.

선택적으로 IPv6 CIDR 블록을 VPC 및 서브넷과 연결하고 해당 블록의 IPv5주소를 VPC 리소스에 할당 할 수 있다. IPv6를 통해서 인터넷에 연결할 수 있다.

![VPC](https://docs.google.com/drawings/d/e/2PACX-1vShrU06nFCi4-eTWaDMdcEAgSBCa4SW_WUh5glrv5BjKigxsjzdPn_xNs4x-NPQlkJ15xqabPko8tv0/pub?w=700&h=607)

모든 서브넷에는 해당 서브넷에서 생성된 네트워크 인터페이스에 대해서 IPv4주소 그리고 필요할 경우 IPv6 주소의 할당을 설정할 수 있다. 여기에는 해당 서브넷에서 인스턴스를 시작할 때 인스턴스에 기본 생성되는 네트워크 인터페이스가 포함된다.

기본적으로 기본이 아닌 서브넷에는 IPv4 퍼블릭 주소 설정이 **false**이다. 다만 웹 콘솔에서 생성 할 경우 웹 콘솔이 속성을 true로 설정한다.

이 시나리오에서는 모든 인스턴스가 동일한 보안 그룹에 속해 있다. 하나를 제외한 모든 인스턴스의 연결에는 문제가 없으므로 라우팅테이블 문제도 아닐 것이다. 또한 인스턴스들이 퍼블릭 서브넷에 속해 있고, 연결이 안되는 인스턴스도 같은 퍼블릭 서브넷에 있으므로 인터넷 게이트웨이 설정 문제도 아닐 것이다. 결국 퍼블릭 IP 혹은 EIP 주소가 없어서 연결을 할 수 없을 가능성이 제일 높다.

답 : 1

### Question #21

<span style="color: rgb(5, 25, 34); font-family: 'Open Sans', sans-serif; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: 0.1px; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">한 정보기관은 개발 및 프로덕션 AWS 계정 모두에서 호스팅되는 미사일 추적 애플리케이션을 개발했다. 정보 기관의 주니어 개발자는 개발 계정에서만 접근 할 수 있다. 이 개발자는 에이전시의 프로덕션 계정에 엑세스 할 수 있는 보안 허가를 받았지만 액세스는 일시적이며 EC2및 S3에 대한 쓰기 엑세스만 허용된다.

1. Use AWS SSO
2. Use AWS STS
3. AWS Cognito를 이용해서 JWT를 발행한다.
4. 위에 있는 모든 서비스 이용

#### 설명

AWS Security Token Service (AWS)는 신뢰 할 수 있는 사용자를 생성하고 AWS 리소스에 대한 액세스를 제어 할 수 있는 임시 보안 자격 증명을 제공하는데 사용 할 수 있는 서비스다. 임시 보안 자격증명은 IAM 사용자가 사용 할 수 있는 장기 액세스키 자격 증명과 거의 동일하게 작동한다.

아래 다이어그램에서 Dev 계정의 IAM 사용자 Alice는 Prod계정에 액세스해야 한다. 작동방식은 아래와 같다.

1. Dev 계정의 Alice는 AssumeRole를 호출하여 Prod 계정의 IAM 역할(WriteAccess)를 할당받는다.
2. STS는 임시 보안 자격 증명 집합을 반환한다.
3. Alice는 임시 보안 자격 증명을 사용하여 Prod 계정의 서비스 및 리소스에 액세스합니다. 예를 들어 Alice는 WriteAccess 역할에 의해 부여된 Amazon S3 및 Amazon EC2를 호출할 수 있다.

![STS](https://docs.google.com/drawings/d/e/2PACX-1vRRf03iCJ4q6HT2vDaW17c4823g0kgs8674FMWXeDtKTaL7CRsLvAD6it1hZTyOYyylk_7uLgcvYEyP/pub?w=684&h=376)

Amazon Cognito 서비스는 AWS 리소스에 대한 액세스가 아닌 사용자 인증에 사용되기 때문에 AWS Cognito를 사용하여 JWT를 발급하는 것은 올바르지 않다. JWT는 사용자 인증 및 세션관리에 사용된다.

AWS SSO 서비스는 STS를 사용하지만 자체적으로 단기 자격증명을 발행하지 않는다. AWS Single Sign-On은 여러 AWS 계정 및 비즈니스 애플리케이션에 대한 SSO 액세스를 중앙에서 쉽게 관리 할 수 있는 클라우드 SSO 서비스다.

STS만이 임시 보안자격증명을 제공 할 수 있다.

답 : 2

### Question #22

1. 애플리케이션 실패에 대비해서 더 많은 서버를 배치한다.
2. S3 웹 사이트 버캣 혹은 CloudFront 배포에 대해서 Route 53 장애조치 옵션을 사용한다.
3. 온-프레미스 데이터센터에 호스팅된 애플리케이션에 대한 장애조치를 설정한다.
4. 다른 리전에 동일한 애플리케이션 아키텍처를 복제해서 배치하고 DNS 가중치 기반 라우팅을 설정한다.

#### 설명

이 시나리오의 경우 정적 S3 웹 사이트 또는 CloudFront 배포에 대한 장애조치 옵션을 설정한 Route 53을 사용하는 것이 올바르다.

중복 시스템을 실행하는 것은 작동은 하지만 비용 효율적인 솔류션이 아니기 때문에 올바르지 않다. 분산 설정이 아닌 웹 앱에 대한 장애 조치 매커니즘을 구축하려 한다는 점을 기억하라.

온-프레미스 데이터 센터에서 호스팅되는 애플리케이션에 대한 장애조치 활성화는 올바르지 않다. 온-프레미스 데이터센터에 대한 장애조치를 설정 할 수 있지만 Route 53 장애조치를 이용하는 것이 AWS 환경관리에 더 적합하다.

### Question #23

1. Amazon SQS
2. Amazon CloudWatch
3. BIND 서버와 함께 실행된 Amazon EC2 인스턴스
4. Amazon Simple Email Service
5. Amazon Simple Notication Service(SNS)

#### 설명

Amazon CloudWEatch와 Amazon Simple Notification Service를 이용하여 구축할 수 있다. 이 요구 사항에서는 Amazon CloudWatch를 사용하여 데이터베이스를 모니터링 하고 Amazon SNS를 사용하여 운영팀에 이메일을 보낼 수 있다. EC2 인스턴스를 모니터링 하려는 경우 SES 대신 SNS를 사용해야 한다.

![SNS](https://docs.google.com/drawings/d/e/2PACX-1vRxl18jDeia5nIjbdcUhZw04PnvQiSA5slPiRWsyoTByXggXPCAgVfPGNLFwANRdY0OpG7fLsc2VtaI/pub?w=650&h=332)

SNS는 마이크로 서비스, 분산 시스템 및 서버리스 애플리케이션을 분리 할 수 있는 고 가용성, 내구성을 지신 완전 관리형 게시/구독 메시징 서비스다.

Amazon Simple Email Service는 알림 및 트랜잭션 이메일을 애플리케이션 안에서 전송하도록 설계된 클라우드 기반 이메일 전송 서비스다.

### Question #24

1. 신뢰할 수 있는 VPC를 위한 endpoint 정책을 생성한다.
2. 신뢰할 수 있는 VPC를 위한 버킷 정책을 생성한다.
3. 신뢰할 수 있는 S3 버킷에 대한 endpoint 정책을 생성한다.
4. 신뢰할 수 있는 S3 버킷에 대한 버킷 정책을 생성한다.

#### 설명

VPC 엔드 포인트를 사용하면 인터넷 게이트웨이, NAT 게이트웨이, VPN 연결 또는 AWS Direct Connect 연결 없이도 VPC를 AWS PrivateLink에서 제공하는 AWS 서비스 및 VPC 엔드포인트 서비스에 프라이빗하게 연결할 수 있다. VPC의 인스턴스는 서비스의 리소스와 통신하는데 퍼블릭 IP 주소가 필요하지 않다. VPC와 다른 서비스 간의 트래픽은 Amazon 네트워크를 벗어나지 않는다.

VPC 엔드포인트를 생성할 때 연결중인 서비스에 대한 액세스를 제어하는 엔드포인트 정책을 연결 할 수 있다. 엔드포인트에 연결된 엔드 포인트 정책을 수정하고 엔드 포인트에서 사용하는 라우팅 테이블을 추가하거나 제거 할 수 있다. 엔드포인트 정책은 IAM 사용자 정책 또는 서비스별 정책을 재 정의하거나 대체하지 않는다. 엔드포인트에서 지정된 서비스로의 액세스를 제어하기 위한 별도의 정책이다.

![VPC Endpoint](https://docs.google.com/drawings/d/e/2PACX-1vSK_Z_-7WWm6oLLoWUbwbORH31NOrHwPdSckqh-7hwrL5OBqow-CmqzhimmOsMXK_4CAx4ZM0Gp5Nru/pub?w=627&h=368)

버킷 정책 또는 엔드포인트 정책을 사용하여 신뢰할 수 있는 트래픽만 S3에 흐르도록 할 수 있다. 신뢰할 수 있는 S3 버킷 설정은 이 시나리오에서 가능한 답이 될 것이다. 하지만 단일 엔드포인트 정책을 사용하는게 훨씬 쉽기 때문에, 엔드 포인트 정책을 사용하여 신뢰 할 수 있는 Amazon S3 버킷에 대한 트래픽을 제어해야 한다.

신뢰할 수 있는 S3 버킷에 대한 버킷 정책 생성 옵션은 사용 할 수 있는 솔류션이지만 모든 S3 버킷에 대해 버킷 정책을 설정하는 데 많은 시간이 걸린다. 여기에서는 하나의 답을 요구하고 있기 때문에, 옳은 방법이 아니다.

### Question #25

<span style="color: rgb(5, 25, 34); font-family: 'Open Sans', sans-serif; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: 0.1px; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">AWS 클라우드 아키텍처를 설계하기 위해서 DevOps 엔지니어가 필요하다. 엔지니어는 Elastic Load Balancer와 여러 가용 영역에 배포된 EC2 인스턴스의 Auto Scaling 그룹으로 구성된 고 가용성 및 내결함성 아키텍처를 개발할 계획이다. 이것은 경로기반 라우팅, 호스트 기반 라우팅 및 웹소켓을 사용하는 양방향 통신 채널이 필요한 온라인 회계 응용 프로그램에서 사용된다.

1. 네트워크 로드밸런서
2. 애플리케이션 로드밸런서
3. 클래식 로드밸런서 혹은 네트워크 로드밸런서
4. 클래식 로드밸런서

#### 설명

Elstic Load Balancing은 세 가지 유형의 로드밸런서를 지원한다. 애플리케이션 요구사항에 따라 적절한 로드 밸런서를 선택할 수 있다.

유연한 애플리케이션 관리 및 TLS 지원이 필요한 경우 애플리케이션 로드 밸런서를 사용하는 것이 좋다. 애플리케이션에 최고의 성능과 고정 IP가 필요한 경우 네트워크 로드 밸런서를 사용하는 것이 좋다. 애플리케이션이 EC2 클래식 네트워크에 구축된 경우 클래식 로드 밸런스를 사용해야 한다.

애플리케이션 로드 밸런서는 OSI 7번째 계층인 애플리케이션 계층에서 작동한다. 로드 밸런서는 요청을 수신한 후 우선 순위에 따라서 리스너 규칙을 평가하여 적용할 규칙을 결정한 다음 정책에 따라서 대상 그룹에서 대상을 선택한다. 애플리케이션 트래픽의 콘텐츠를 기반으로 요청을 다른 대상그룹으로 라우팅하도록 리스너 규칙을 설정 할 수 있다. 대상이 여러 대상 그룹에 등록된 경우에도 각 대상 그룹에 대해 독립적으로 라우팅을 수행 할 수 있다.

애플리케이션 로드 밸런서는 경로 기반 라우팅, 호스트 기반 라우팅 및 컨테이너화된 애플리케이션을 지원하므로 애플리케이션 로드 밸런서가 정답이다.

나머지 타입의 로드밸런서는 경로 기반 라우팅 및 호스트 기반 라우팅을 지원하지 않으므로 모두 올바르지 않다.

답 : 2

### Question #26

<span style="color: rgb(5, 25, 34); font-family: 'Open Sans', sans-serif; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: 0.1px; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">솔류션 아키텍트는 웹 사이트 및 애플리케이션에서 제공되는 수 테라 바이트의 고객 데이터를 보유한 온라인 호텔 예약 회사에서 일하고 있다. 설계자는 연례 기업 회의에 새로운 통찰력을 제시하기 위한 고객 데이터 분석작업을 수행해야 한다.

1. Amazon RDS
2. Amazon ElastiCache
3. Amazon Redshift
4. Amazon DynamoDB

#### 설명

Amazon Redshift는 클라우드에서 완벽하게 관리되는 페타바이트급 데이터웨어 하우스 서비스다. 적게는 수백 기가바이트부터 시작하여 페타바이트 이상까지 데이터를 확장 할 수 있다. 이를 통해 데이터를 사용하여 비즈니스 및 고객에 대한 새로운 인사이트를 발굴 할 수 있다.

![AWS Architecture](https://d2908q01vomqb2.cloudfront.net/887309d048beef83ad3eabf2a79a64a389ab1c9f/2017/09/15/AWSArchitecture.jpg)

Wipro는 CDRS(Cloud Data Warehouse Readiness Solution)전략을 사용하여 데이터를 Amazon Redshift로 마이그레이션 했다. CDRS를 사용하여 40억개의 레코드를 Amazon Redshift로 마이그레이션 한다.

Redshift를 사용하면 표준 SQL 및 기존의 비즈니스 인텔리전스(BI) 도구를 사용하여 모든 데이터를 분석 할 수 있다. 또한 정교한 쿼리 최적화, 대규모 병렬 쿼리 실행을 사하여 테라바이트에서 페타바이트의 정형, 반정형 데이터에 대한 복잡한 분석쿼리를 실행 할 수 있다.

DynamoDB는 동적으로 증가하고 변경되는 작은 데이터러를 빠르게 처리하기 위해 사용하는 Key-Value 기반의 NoSQL 데이터베이스다. DynamoDB는 대량의 데이터를 스캔해야 하는 작업에는 최적의 솔류션이 아니다.

Amazon RDS는 OLTP(온라인 트랜젹선 처리)에 주로 사용하는 데이터베이스다.

답 : 3

### Question #27

1. VPC의 트래픽이 NAT 인스턴스로 향하도록 라우팅 테이블을 수정한다.
2. 온-프레미스 네트워크의 고객 게이트웨이의 외부 인터페이스로 private IP가 라우팅 할 수 있도록 라우팅 테이블을 구성.
3. Virtual Private Gateway에 EIP를 설정한다.
4. Public 서브넷에 dedicated NAT 인스턴스를 구성한다.

#### 설명

기본적으로 VPC에서 시작하는 인스턴스는 자체 네트워크와 통신할 수 없다. 가상 프라이빗 게이트웨이를 VPC에 연결하고, 사용자 지정 라우팅 테이블을 생성, 보안 그룹 규칙을 업데이트하고 AWS 관리형 VPN 연결을 생성하여 VPC에서 네트워크에 대한 액세스를 활성화 할 수 있다.

VPN 연결은 일반적인 용어이지만 Amazon VPC에서 VPN 연결은 VPC와 자체 네트워크 간의 연결을 의미한다.

고객 게이트웨이(Custom Gateway)는 고객측에 있는 VPN의 물리적 장치 또는 소프트웨어이다.

VPN에 연결을 생성하려면 AWS에서 고객 게이트웨이 디바이스에 대한 정보를 AWS에 생성해야 한다. 다음으로 고객 게이트웨이 인터페이스에 대해서 인터넷에서 라우팅 가능한 IP 주소(정적)을 설정해야 한다.

아래 다이어그램은 단일 VPN 연결을 보여준다.

![VPN Connection](https://docs.google.com/drawings/d/e/2PACX-1vQZ8XHQJvqv9qHjmQzIweSPhJ6-fekRTndpXlfd984JL8trxTkTU7OY2GE-XwoOREPWUrwHxBdAlHNs/pub?w=884&h=454)

VPC와 연결된 가상 프라이빗 게이트웨어가 있고 원격 네트워크에는 VPN 연결을 위한 고객 게이트웨이거 포함된다. 네트워크에 바인딩된 모든 VPC 트래픽이 가상 프라이빗 게이트웨이로 라우팅되도록 라우팅 테이블을 설정한다.

답 : 2

### [28.](https://www.joinc.co.kr/w/man/12/awsCertification/SolutionArchitect/exam02#toc) Question #28

<span style="color: rgb(5, 25, 34); font-family: 'Open Sans', sans-serif; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: 0.1px; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">한 회사는 사용자의 음식 소비량과 일주일 동안의 식사 추천을 제공하는 식사 계획 애플리케이션을 개발했다. 애플리케이션은 일상적인 작업을 수행하기 위해서 다양한 AWS 서비스에 액세스해야 하는 EC2로 전개했다.

1. 베스천 호스트에 API Credentials를 저장한다.
2. EC2 인스턴스에 API Credentials를 저장한다.
3. 보안 그룹에 API Credentials를 추가하고 EC2 인스턴스에 할당한다.
4. IAM 롤을 생성하고 EC2 인스턴스에 할당한다.

#### 설명

API Credentials를 핸들링 하는 가장 좋은 방법은 IAM(Identity Access Management)에 새로운 룰을 생성하고 EC2 인스턴스에 할당하는 것이다. 이 방법으로 credentials관리를 중앙에서 안전하게 관리 할 수 있다.

![IAM Role](https://docs.google.com/drawings/d/e/2PACX-1vRw9NKdLsHjREaRoUl5OO0aQMH8GUtwVSbQ_ppCvBg26U2_ozpmLb9Ngq_HdQMVyk19fxfN0kcB-q1_/pub?w=599&h=186)

API Credentiasl를 EC2 인스턴스에 저장하거나 API 자격증명을 보안 그룹에 추가, 배스천 호스트에 저장하는 것은 잘못된 것이다. API Credentials를 안전하게 관리 할 수 없기 때문이다.

### Question #29

1. EBS 주기 정책을 사용하여 EBS 볼륨을 S3로 자동 백업한다.
2. AWS CLI의 Create-snapshot 명령을 예약작업으로 호출해서 주기적으로 EBS 볼륨 스냅샷을 생성한다.
3. EBS 볼륨이 있는 Amazon Storage Gateway를 데이터 원본으로 설정하고 스토리지 게이트웨이를 통해 온 프레미스 서버에 백업을 저장한다.
4. Amazon Data Lifecyle Manager(Amazon DLM)을 이용해서 자동으로 EBS 스냅샷을 생성한다.

#### 설명

Amazon DLM(Amazon Data Lifecyle Manager)는 Amazon EBS 볼륨에 저장된 데이터를 백업하는 자동화된 절차를 관리한다. DLM을 이용해서 스냅샷 관리를 자동화하는 수명 주기 정책을 생성할 수 있다. Amazon DLM을 이용해서 아래와 같은 일을 할 수 있다.

* 장기적인 백업 스케쥴을 시행하여 소중한 데이터를 보호한다.
* 감사 또는 내부 규정준수에서 요구하는대로 백업을 보관할 수 있다.
* 오래된 백업을 삭제하여 저장 비용을 줄일 수 있다.

DLM은 Amazon CloudWatch Events 및 AWS CloudTrail의 모니터링 기능과 결합되며 추가적인 비용없이 EBS 볼륨에 대한 완전한 백업솔류션을 제공한다. 따라서 Amazon DLM을 사용하여 EBS 스냅샷 생성을 자동화하는 것이 정답이다.

AWS CLI를 이용하여 create-snapshot 명령을 호출하여 EBS 볼륨의 스냅샷을 생성하는 것도 유효한 솔류션이기는 하지만 create-snapshot 명령을 주기적으로 호출하기 위한 추가적인 작업이 필요하다. Amazon DLM을 사용하는 것이 더 좋다. Amazon DLM을 사용하면 추가적인 쉘 스크립트를 작성하거나 예약 스크립트를 생성하지 않고도 EBS 스냅샷의 생성, 보존, 삭제를 자동화 할 수 있다.

답 : 4

### [30.](https://www.joinc.co.kr/w/man/12/awsCertification/SolutionArchitect/exam02#toc) Question #30

<span style="color: rgb(5, 25, 34); font-family: 'Open Sans', sans-serif; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: 0.1px; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">한 회사가 Elastic Load Balancer 뒤의 Amazon EC2 인스턴스에서 호스팅되는 퍼블릭 API 서비스를 개발했다. API는 온프레미스 데이터 센터의 다양한 클라이언트에서 사용된다. 솔류션 아키텍트는 웹 서비스 클라이언트가 방화벽에서 허용된 신뢰 할 수 있는 IP 주소에서만 액세스하도록 해야 한다는 지시를 받았다.

1. 로드밸런서의 DNS 이름에 맵핑되는 Route 53 Alias 레코드를 생성한다.
2. 오리진이 웹 서버의 프라이빗 IP 주소를 가리키는 CloudFront 배포를 생성한다.
3. 네트워크 로드 밸런서에 Elastic IP 주소를 할당한다.
4. 애플리케이션 로드 밸런서에 Elastic IP 주소를 할당한다.

#### 설명

네트워크 로드밸런서는 OSI(Open Systems Interconnection) 모델의 네번째 계층에서 작동한다. 초당 수백만 개의 요청을 처리 할 수 있다. 로드 밸런서가 연결 요청을 받으면 대상 그룹에서 대상을 선택한다. 리스너 구성에 지정된 포트에서 선택한 대상에 대한 TCP 연결을 시도한다.

로드밸런서의 가용 용역을 활성화 하면, 각 가용 영역에 로드밸런서를 생성한다. 가용 영역에 배치된 로드밸런서는 기본적으로 해당 가용영역에 등록된 대상으로만 트래픽을 분산한다. 교챠 영역 로드 밸런싱을 활성화 할 경우 로드밸런서는 모든 가용영역에 비치된 대상으로 트래픽을 라우팅한다.

![Network Loadbalancer](https://docs.google.com/drawings/d/e/2PACX-1vSQ-phX9jI1mge-JYEys-5walBjdgF4hc_jWxicHWblWnEt4LwEGKT_V8NIpoS0qXuU-JhaOMqSq2s6/pub?w=971&h=384)

주어진 시나리오에 따르면 웹 서비스 클라이언트는 신뢰할 수 있는 IP 주소에만 액세스 할 수 있다. 이 요구 사항을 해결하려면 BYOIP(Bring Your Own IP)기능을 사용하여 신뢰할 수 있는 IP를 NLB에 EIP로 할당할 수 있다. IP가 고정되기 때문에 클라이언트는 방화벽 정책을 수립할 수 있다.

따라서 정답은 탄력적 IP 주소를 NLB에 연결하는 것이다.

Application Load Balancer에는 EIP를 할당할 수 없기 때문에 올바른 답이 아니다.

답 : 3

Search For:

BY TAGS

Recent Posts

Archive Posts

Tags

About

Get in Touch

Categories

Search For:

BY TAGS

AWS Certified Solutions Architect Associate Practice Test 2

Recent Posts

Archive Posts

Tags

About

Get in Touch

Categories

Subscribe