[DOP-C01] AWS DevOps Engineer Professional : Part 14

 

 

 

 

1. 규정 준수로 인해 경영진은 애플리케이션 로그를 비용 효율적으로 장기간 저장할 수 있고 지원 담당자가 로그를 더 빨리 볼 수 있는 방법을 제공하는 시스템을 제공하도록 요청했습니다. 현재 로그 시스템은 로그를 매시간 Amazon S3에 자동으로 보관하며 지원 직원은 현재 라이브 로그를 볼 수 있는 시스템에 대한 액세스 권한이 없기 때문에 이러한 로그가 Amazon S3에 나타날 때까지 기다려야 합니다.
   
   지원 담당자가 로그에 액세스할 수 있는 더 빠른 방법을 제공하는 동시에 규정을 준수하려면 어떤 방법을 사용해야 합니까?
   
   • Amazon S3 수명 주기 정책을 업데이트하여 이전 로그를 Amazon Glacier에 보관하고 지원 팀이 수집할 수 있도록 모든 로그 항목을 Amazon SQS에 푸시하는 새 정책을 추가합니다.
   • Amazon S3 수명 주기 정책을 업데이트하여 이전 로그를 Amazon Glacier에 보관하고 서비스를 사용하거나 작성하여 애플리케이션 로그를 CloudWatch Logs로 스트리밍하십시오.
   • Amazon Glacier 수명 주기 정책을 업데이트하여 Amazon S3에서 새 로그를 가져오고 Amazon EC2 콘솔에서 모든 애플리케이션 서버에서 CloudWatch Logs 에이전트를 활성화합니다.
   • Amazon Glacier에 오래된 로그를 보관하도록 Amazon S3 수명 주기 정책을 업데이트합니다. 키는 테이블과 다를 수 있습니다. Amazon S3 버킷에서 Amazon S3 부분 업로드를 활성화하고 부분 업로드가 발생할 때 Amazon SNS 알림을 트리거합니다.
   • 서비스를 사용하거나 작성하여 애플리케이션 로그를 CloudWatch Logs로 스트리밍합니다. Amazon Elastic Map Reduce 클러스터를 사용하여 지원 팀이 수집할 수 있도록 CloudWatch Logs에서 로그를 라이브 스트리밍하고 Hadoop 작업을 생성하여 로그를 5분 단위로 S3에 푸시합니다.
2. Amazon RDS 인스턴스에 대한 자격 증명을 웹 서버 인스턴스 플릿에 안전하게 배포하려고 합니다. 자격 증명은 구성 관리 시스템에서 제어하는 ​​파일에 저장됩니다.
   
   필요한 경우 롤백 기능을 유지하면서 수백 개에 달하는 웹 서버 인스턴스 전체에 걸쳐 자동화된 방식으로 자격 증명을 어떻게 안전하게 배포합니까?
   
   • 자격 증명 파일을 Amazon S3 버킷에 저장합니다. 자격 증명 파일에 Amazon S3 서버 측 암호화를 사용합니다. 자격 증명 파일을 10분마다 인스턴스로 가져오는 예약된 작업이 있습니다. 
   • 나머지 코드와 함께 버전 제어 리포지토리에 자격 증명 파일을 저장합니다. 새 자격 증명 파일을 모든 웹 서버 인스턴스에 안전하게 적용하는 지속적인 통합 시스템에서 작업을 시작하는 버전 제어에서 커밋 후 작업을 수행합니다.
   • 자격 증명 파일을 사용자 데이터에 삽입하고 인스턴스 수명 주기 정책을 사용하여 사용자 데이터에서 주기적으로 파일을 새로 고칩니다.
   • 자격 증명 파일을 Amazon RDS MySQL DB 인스턴스에 이진 blob으로 유지하고 각 Amazon EC2 인스턴스에 RDS 인스턴스에서 파일을 가져오는 스크립트가 있습니다.
   • 나머지 코드와 함께 버전 제어 리포지토리에 자격 증명 파일을 저장합니다. 병렬 파일 복사 프로그램을 사용하여 자격 증명 파일을 로컬 시스템에서 Amazon EC2 인스턴스로 보냅니다.
3. 구성 관리 시스템을 사용하여 Amazon EC2 인스턴스를 관리하고 있습니다. Amazon EC2 인스턴스에서 Amazon RDS DB 인스턴스에 연결하기 위한 자격 증명을 저장하려고 합니다.
   
   이러한 자격 증명을 어떻게 안전하게 저장해야 합니까?
   
   • 프라이빗 Amazon S3 버킷에 대한 읽기 액세스를 허용하는 IAM 역할을 Amazon EC2 인스턴스에 부여합니다. Amazon S3 버킷에 데이터베이스 자격 증명이 있는 파일을 저장합니다. 필요할 때 구성 관리 시스템이 버킷에서 파일을 가져오도록 합니다.
   • Amazon EC2 인스턴스를 시작하고 구성 관리 시스템을 사용하여 Amazon RDS DB 자격 증명으로 인스턴스를 부트스트랩합니다. 이 인스턴스에서 AMI를 생성합니다.
   • Amazon RDS DB 자격 증명을 Amazon EC2 사용자 데이터에 저장합니다. 부팅 시 자격 증명을 인스턴스로 가져옵니다.
   • Amazon RDS 인스턴스에 IAM 역할을 할당하고 이 IAM 역할을 사용하여 Amazon EC2 인스턴스에서 Amazon RDS DB에 액세스합니다.
   • 자격 증명을 버전 제어 시스템에 일반 텍스트로 저장합니다. 부팅 시 버전 제어 시스템에서 자격 증명 사본을 확인하십시오. Amazon RDS DB 자격 증명을 저장하는 볼륨에서 Amazon EBS 암호화를 사용합니다.
4. 회사에서 웹 애플리케이션을 개발했으며 정적 웹 사이트 호스팅용으로 구성된 Amazon S3 버킷에서 호스팅하고 있습니다. 애플리케이션은 브라우저에서 JavaScript용 AWS SDK를 사용하여 Amazon DynamoDB 테이블에 저장된 데이터에 액세스합니다.
   
   DynamoDB의 데이터에 액세스하기 위한 API 키를 안전하게 유지하려면 어떻게 해야 합니까?
   
   • 특정 DynamoDB 테이블에 대한 액세스 권한이 있는 IAM에서 Amazon S3 역할을 생성하고 웹사이트를 호스팅하는 버킷에 할당합니다.
   • 애플리케이션이 액세스를 위해 쿼리할 수 있도록 웹 사이트를 호스팅하는 버킷에 대한 AWS 액세스 키로 S3 버킷 태그를 구성합니다.
   • 올바른 DynamoDB 리소스에 대한 액세스를 활성화하고 임시 자격 증명을 검색하도록 IAM 내에서 웹 자격 증명 연동 역할을 구성합니다.
   • 애플리케이션 내의 전역 변수에 AWS 키를 저장하고 요청할 때 이러한 자격 증명을 사용하도록 애플리케이션을 구성합니다.
5. 여러 다중 계층 웹 애플리케이션에 대한 A/B 배포를 구현해야 합니다. 각각에는 Amazon Elastic Compute Cloud(EC2) 프런트 엔드 서버, Amazon ElastiCache 클러스터, Amazon Simple Queue Service(SQS) 대기열 및 Amazon Relational Database(RDS) 인스턴스와 같은 개별 인프라가 있습니다. 애플리케이션의 서로 다른 배포 버전 간에 트래픽을 제어할 수 있는 기능을 제공하는 서비스 조합은 무엇입니까?
   • 각 웹 애플리케이션에 대해 하나의 AWS Elastic Beanstalk 애플리케이션과 모든 AWS 리소스(애플리케이션 소스 번들 내의 구성 파일 사용)를 생성합니다. 새 버전은 Elastic Beanstalk 환경을 먹고 URL 스왑 기능을 사용하여 배포됩니다.
   • AWS CloudFormation 템플릿을 사용하여 각 웹 애플리케이션에 대해 하나의 Elastic Beanstalk 애플리케이션과 모든 AWS 리소스(동일한 템플릿 내)를 생성합니다. 새 버전은 AWS CloudFormation 템플릿을 사용하여 배포되어 새 Elastic Beanstalk 환경을 생성하고 Amazon Route53의 WRR(가중 라운드 로빈) 레코드를 사용하여 두 버전 사이에서 트래픽의 균형을 맞춥니다.
   • AWS CloudFormation 템플릿을 사용하여 각 웹 애플리케이션에 대해 하나의 Elastic Beanstalk 애플리케이션과 모든 AWS 리소스(동일한 템플릿 내)를 생성합니다. CloudFormation 템플릿의 매개변수를 업데이트하고 cfn-hup 헬퍼 데몬에 전달하는 새 버전이 배포되고 Amazon Route 53의 WRR(Weighted Round Robin) 레코드를 사용하여 이들 간에 트래픽이 균형을 이룹니다.
   • 각 웹 애플리케이션에 대해 하나의 Elastic Beanstalk 애플리케이션과 모든 AWS 리소스(애플리케이션 소스 번들 내의 구성 파일 사용)를 생성합니다. 현재 Elastic Beanstalk 환경에 대한 Elastic Beanstalk 애플리케이션 버전을 업데이트하는 새 버전이 배포됩니다.
6. 귀하는 보험 회사에서 근무하며 일반 대중에게 보험 견적을 제공하는 데 사용되는 회사 온라인 견적 시스템의 일상적인 운영을 담당하고 있습니다. 귀사는 고객 행동을 더 잘 이해하기 위해 시스템에서 생성된 애플리케이션 로그를 사용하려고 합니다. 업계 규정에 따르면 향후 사기 주장을 조사하기 위해 시스템에 대한 모든 애플리케이션 로그를 무기한으로 보관해야 합니다. 귀하는 다음 요구 사항을 충족하는 로그 관리 시스템을 설계하는 임무를 맡았습니다.
   
   – 모든 로그 항목은 계획되지 않은 인스턴스 장애 중에도 시스템에서 유지되어야 합니다.
   – 고객 통찰력 팀은 지난 7일 동안의 로그에 즉시 액세스해야 합니다.
   – 사기 조사 팀은 모든 과거 로그에 액세스해야 하지만 이러한 로그를 사용할 수 있으려면 최대 24시간을 기다려야 합니다.
   
   비용 효율적인 방식으로 이러한 요구 사항을 충족하려면 어떻게 해야 합니까? (3개를 선택하세요.)
   • 이 저장소는 무료이고 쓰기 성능이 좋기 때문에 인스턴스의 임시 디스크에 로그를 쓰도록 애플리케이션을 구성합니다. 한 시간에 한 번씩 인스턴스에서 Amazon 53으로 로그를 이동하는 스크립트를 생성합니다.
   • 인스턴스가 중지되거나 종료될 때 실행되도록 구성되고 인스턴스에 남아 있는 모든 로그를 Amazon S3에 업로드하도록 구성된 스크립트를 작성합니다.
   • 7일 후에 Amazon S3에서 Amazon Glacier로 로그 파일을 이동하도록 Amazon S3 수명 주기 구성을 생성합니다.
   • 이 스토리지가 이미 있으므로 인스턴스의 기본 Amazon EBS 부팅 볼륨에 로그를 쓰도록 애플리케이션을 구성합니다. 한 시간에 한 번씩 인스턴스에서 Amazon 53으로 로그를 이동하는 스크립트를 생성합니다.
   • "종료 시 삭제" 필드를 false로 설정하여 별도의 Amazon EBS 볼륨에 로그를 쓰도록 애플리케이션을 구성합니다. 한 시간에 한 번씩 인스턴스에서 Amazon S3로 로그를 이동하는 스크립트를 생성합니다.
   • 고가용성을 위해 Auto Scaling 그룹에서 관리하는 T2 마이크로 인스턴스에서 실행되는 하우스키핑 스크립트를 생성합니다. 이 스크립트는 AWS API를 사용하여 로그 파일이 포함된 연결되지 않은 Amazon EBS 볼륨을 식별합니다. 관리 스크립트는 Amazon EBS 볼륨을 탑재하고 모든 로그를 Amazon S3에 업로드한 다음 볼륨을 삭제합니다.
7. Auto Scaling 그룹의 Amazon EC2에서 실행 중인 애플리케이션이 있습니다. 인스턴스가 동적으로 부트스트랩되고 있으며 부트스트랩을 완료하는 데 15분 이상 걸립니다. 부트스트래핑이 완료되기 전에 인스턴스가 Auto Scaling에서 서비스 중인 것으로 보고됩니다. 부트스트래핑이 완료되기 전에 새 인스턴스와 관련된 애플리케이션 경보를 수신하여 혼란을 야기하고 있습니다. 원인을 찾았습니다. 애플리케이션 모니터링 도구가 서비스 중인 인스턴스에 대해 Auto Scaling 서비스 API를 폴링하고 이전에 알려지지 않은 새 인스턴스에 대한 경보를 생성합니다.
   
   다음 중 부트스트래핑이 완료되기 전에 애플리케이션 모니터링 도구에 새 인스턴스가 추가되지 않도록 하는 것은 무엇입니까?
   
   • Auto Scaling 그룹 수명 주기 후크를 생성하여 부트스트래핑이 완료될 때까지 인스턴스를 보류: 대기 상태로 유지합니다. 부트스트래핑이 완료되면 수명 주기 후크를 완료하고 인스턴스를 보류: 완료 상태로 이동하도록 Auto Scaling에 알립니다.
   • 기본 Amazon CloudWatch 애플리케이션 지표를 사용하여 애플리케이션의 상태를 모니터링합니다. 이러한 CloudWatch 경보를 올바른 수신자에게 보내도록 Amazon SNS 주제를 구성합니다.
   • 시작 시 모든 인스턴스에 태그를 지정하여 보류 상태인지 식별합니다. 새 인스턴스를 추가하기 전에 이 태그를 찾도록 애플리케이션 모니터링 도구를 변경하고 Amazon API를 사용하여 부트스트래핑이 완료될 때까지 인스턴스 상태를 '대기 중'으로 설정합니다.
   • 향후 인스턴스를 부트스트랩하는 데 걸리는 시간을 줄이려면 Auto Scaling 그룹 구성에서 원하는 인스턴스 수를 늘리십시오.
8. 애플리케이션에 대한 로그 파일을 10년 동안 유지해야 한다는 비즈니스 요구 사항이 주어졌습니다. 문제 해결을 위해 최신 로그를 정기적으로 검색해야 합니다. 로깅 시스템은 대량의 로그를 고려할 때 비용 효율적이어야 합니다.
   
   이러한 요구 사항을 충족하려면 어떤 기술을 사용해야 합니까?
   
   • Amazon CloudWatch Logs에 로그를 저장합니다.
   • Amazon Glacier에 로그를 저장합니다.
   • Amazon S3에 로그를 저장하고 수명 주기 정책을 사용하여 Amazon Glacier에 보관합니다.
   • Amazon EMR 클러스터의 HDFS에 로그를 저장합니다.
   • Amazon EBS에 로그를 저장하고 Amazon EBS 스냅샷을 사용하여 보관하십시오.
9. 당신은 새로운 모바일 장치용 사진 공유 응용 프로그램을 개발한 신생 기업에서 일합니다. 최근 몇 달 동안 애플리케이션의 인기가 높아졌습니다. 이로 인해 증가된 부하에 대한 애플리케이션 단서의 성능 저하가 발생했습니다. 애플리케이션에는 처음에 AWS CloudFormation과 함께 배포된 MySQL RDS 인스턴스와 Auto Scaling PHP 애플리케이션 계층으로 구성된 2계층 아키텍처가 있습니다. Auto Scaling 그룹의 최소값은 4이고 최대값은 8입니다. 인스턴스의 CPU 사용률이 높기 때문에 이제 원하는 용량은 8입니다. 약간의 분석 후 메모리 사용률은 여전히 ​​낮지만 CPU 용량의 제약으로 인해 성능 문제가 발생한다고 확신합니다. 따라서 범용 M3 인스턴스에서 컴퓨팅 최적화 C3 인스턴스로 이동하기로 결정합니다.
   
   최종 사용자에 대한 중단을 최소화하면서 이 변경 사항을 어떻게 배포하시겠습니까?
   
   • AWS Management Console에 로그인하고 이전 시작 구성을 복사한 다음 C3 인스턴스를 지정하는 새 시작 구성을 생성합니다. 새로운 시작 구성으로 Auto Scaling 그룹을 업데이트합니다. Auto Scaling은 실행 중인 모든 인스턴스의 인스턴스 유형을 업데이트합니다.
   • AWS Management Console에 로그인하고 기존 시작 구성을 새 C3 인스턴스 유형으로 업데이트합니다. AutoScalingRollingUpdate를 지정하는 Auto Scaling 그룹에 UpdatePolicy 속성을 추가합니다.
   • 새 C3 인스턴스 유형으로 AWS CloudFormation 템플릿에 지정된 시작 구성을 업데이트합니다. 새 템플릿으로 스택 업데이트를 실행합니다. 그러면 Auto Scaling이 새 인스턴스 유형으로 인스턴스를 업데이트합니다.
   • 새 C3 인스턴스 유형으로 AWS CloudFormation 템플릿에 지정된 시작 구성을 업데이트합니다. 또한 AutoScalingRollingUpdate를 지정하는 Auto Scaling 그룹에 UpdatePolicy 속성을 추가합니다. 새 템플릿으로 스택 업데이트를 실행합니다.
10. 귀하는 Amazon EBS 볼륨이 있는 Amazon EC2에서 실행되는 애플리케이션 서버용 자동 데이터 백업 솔루션을 구현하는 임무를 맡았습니다. 단일 실패 지점을 방지하고 데이터의 내구성을 높이기 위해 백업에 분산 데이터 저장소를 사용하려고 합니다. 1시간 이내에 데이터를 복원할 수 있도록 매일 백업을 30일 동안 유지해야 합니다.
    
    애플리케이션 서버에서 스케줄링 데몬이 매일 실행하는 스크립트를 통해 이를 어떻게 구현할 수 있습니까?
    
    • ec2-create-volume API를 호출하는 스크립트를 작성하고 현재 날짜 시간 그룹으로 Amazon EBS 볼륨에 태그를 지정하고 백업 데이터를 두 번째 Amazon EBS 볼륨에 복사합니다. ec2-describe-volumes API를 사용하여 기존 백업 볼륨을 열거합니다. ec2-delete-volume API를 호출하여 30일보다 오래된 date-tine 그룹으로 태그가 지정된 백업 볼륨을 정리합니다.
    • Amazon Glacier 업로드 아카이브 API를 호출하는 스크립트를 작성하고 현재 날짜-시간 그룹으로 백업 아카이브에 태그를 지정합니다. 볼트 목록 API를 사용하여 기존 백업 아카이브를 열거합니다. 볼트 삭제 API를 호출하여 30일보다 오래된 날짜-시간 그룹으로 태그가 지정된 백업 아카이브를 정리합니다.
    • ec2-create-snapshot API를 호출하는 스크립트를 작성하고 현재 날짜-시간 그룹으로 Amazon EBS 스냅샷에 태그를 지정합니다. ec2-describe-snapshot API를 사용하여 기존 Amazon EBS 스냅샷을 열거합니다. ec2-delete-snapShot API를 호출하여 30일보다 오래된 datetime 그룹으로 태그가 지정된 Amazon EBS 스냅샷을 정리합니다.
    • ec2-create-volume API를 호출하는 스크립트를 작성하고 현재 날짜-시간 그룹으로 Amazon EBS 볼륨에 태그를 지정하고 ec2-copy-snapshot API를 사용하여 데이터를 새 Amazon EBS 볼륨에 백업합니다. ec2-describe-snapshot API를 사용하여 기존 백업 볼륨을 열거합니다. ec2-delete-snaphot API를 호출하여 30일보다 오래된 날짜-시간 그룹으로 태그가 지정된 백업 Amazon EBS 볼륨을 정리합니다.
11. 애플리케이션은 CloudFormation을 사용하여 애플리케이션의 리소스를 오케스트레이션합니다. 애플리케이션이 실행되기 전 테스트 단계에서 Amazon RDS 인스턴스 유형이 변경되어 인스턴스가 다시 생성되어 테스트 데이터가 손실되었습니다.
    
    앞으로 이런 일이 발생하지 않도록 하려면 어떻게 해야 합니까?
    
    • 사용자가 Amazon RDS 인스턴스 유형을 선택할 수 있는 AWS CloudFormation 파라미터 내에서 현재 인스턴스 유형만 포함하도록 AllowedValues를 설정합니다.
    • AWS CloudFormation 스택 정책을 사용하여 인스턴스에 대한 업데이트를 거부하십시오. SetStackPolicy가 거부된 IAM 주체에 대한 UpdateStack 권한만 허용합니다.
    • AWS CloudFormation 템플릿에서 AWS::RDS::DBInstance의 DBlnstanceClass 속성을 읽기 전용으로 설정합니다.
    • AWS CloudFormation 알림 "BeforeResourceUpdate"를 구독하고 식별된 리소스가 Amazon RDS 인스턴스인 경우 CancelStackUpdate를 호출합니다.
    • AWS CloudFormation 템플릿에서 AWS::RDS::DBInstance의 DeletionPolicy 속성의 DeletionPolicy를 "Retain"으로 설정합니다.
12. 귀하의 회사는 서로 다른 응용 프로그램 종속성을 가진 많은 플랫폼과 프로그래밍 언어를 사용하여 다양한 웹 응용 프로그램을 개발합니다. 비즈니스 요구 사항을 충족하려면 각 애플리케이션을 신속하게 개발하고 배포해야 하며 회피 가능성이 높아야 합니다.
    
    이러한 애플리케이션을 빠르게 배포하려면 다음 중 어떤 방법을 사용해야 합니까?
    
    • Docker 컨테이너에서 애플리케이션을 개발한 다음 Auto Scaling 및 Elastic Load Balancing을 사용하여 Elastic Beanstalk 환경에 배포합니다.
    • AWS CloudFormation Docker 가져오기 서비스를 사용하여 여러 가용 영역에서 고가용성으로 애플리케이션을 구축하고 배포하십시오.
    • DynamoDB에서 각 애플리케이션의 코드를 개발한 다음 후크를 사용하여 Auto Scaling 및 Elastic Load Balancing을 통해 Elastic Beanstalk 환경에 배포합니다.
    • 각 애플리케이션의 코드를 Git 리포지토리에 저장하고, 각 애플리케이션의 종속성에 대한 사용자 지정 패키지 리포지토리 관리자를 개발하고, 여러 가용 영역의 AWS OpsWorks에 배포합니다.
13. 로드 밸런서 뒤에 있는 Auto Scaling 그룹에 많은 수의 웹 서버가 있습니다. 매시간 로그를 필터링 및 처리하여 고유한 방문자에 대한 데이터를 수집한 다음 해당 데이터를 내구성 있는 데이터 저장소에 저장하여 보고서를 실행하려고 합니다. Auto Scaling 그룹의 웹 서버는 조정 정책에 따라 지속적으로 시작 및 종료되지만 사용자 또는 Auto Scaling에 의해 시작된 중지/종료 중에 이러한 서버의 로그 데이터가 손실되는 것을 원하지 않습니다.
    
    이러한 요구 사항을 충족하는 두 가지 접근 방식은 무엇입니까? (두 가지를 선택하세요.)
    
    • 부트스트랩 프로세스 중에 모든 웹 서버에 Amazon Cloudwatch Logs 에이전트를 설치합니다. CloudWatch 로그 그룹을 생성하고 지표 필터를 정의하여 스트리밍 웹 서버 로그에서 고유한 방문자를 추적하는 사용자 지정 지표를 생성합니다. Cloudwatch 사용자 지정 지표를 기반으로 새 보고서를 생성하기 위해 매시간 실행되는 Amazon EC2 인스턴스에서 예약된 작업을 생성합니다.
    • 웹 서버에서 로그를 교체하고 Amazon Glacier로 전송하는 스크립트를 실행하는 예약 작업을 생성합니다. Amazon EC2 인스턴스가 중지/종료될 때 운영 체제 종료 절차가 로그 전송을 트리거하는지 확인하십시오. Amazon Data Pipeline을 사용하여 Amazon Glacier에서 데이터를 처리하고 매시간 보고서를 실행합니다.
    • 웹 서버에서 로그를 교체하고 Amazon S3 버킷으로 전송하는 스크립트를 실행하는 예약 작업을 생성합니다. Amazon EC2 인스턴스가 중지/종료될 때 운영 체제 종료 절차가 로그 전송을 트리거하는지 확인하십시오. 매시간 보고서를 처리하고 실행하기 위해 AWS Data Pipeline을 사용하여 Amazon S3 버킷에서 Amazon Redshift로 로그 데이터를 이동합니다.
    • 부트스트랩 프로세스 중에 모든 웹 서버에 AWS Data Pipeline 로그 에이전트를 설치합니다. AWS Data Pipeline에서 로그 그룹 객체를 생성하고 지표 필터를 정의하여 처리된 로그 데이터를 웹 서버에서 Amazon Redshift로 직접 이동하고 매시간 보고서를 실행합니다.
14. 귀하는 AWS OpsWorks를 사용하여 확장 가능한 분산 시스템을 배포하는 임무를 받았습니다. 분산 시스템은 필요에 따라 확장해야 합니다. 분산되어 있으므로 각 노드는 계층 내 다른 인스턴스의 호스트 이름을 포함하는 구성 파일을 보유해야 합니다.
    
    이 애플리케이션을 동적으로 조정하려면 AWS OpsWorks를 어떻게 구성해야 합니까?
    
    • Chef 레시피를 생성하여 이 구성 파일을 업데이트하고, 사용자 지정 쿡북을 사용하도록 AWS OpsWorks 스택을 구성하고, 이 레시피를 특정 계층의 Configure LifeCycle Event에 할당합니다.
    • 새 인스턴스에 대한 AWS OpsWorks 서비스 API를 폴링하는 스크립트를 작성하여 이 구성 파일을 업데이트합니다. 운영 체제 시작 시 이 스크립트를 실행하도록 기본 AMI를 구성합니다.
    • Chef 레시피를 생성하여 이 구성 파일을 업데이트하고, 사용자 지정 쿡북을 사용하도록 AWS OpsWorks 스택을 구성하고, 인스턴스가 시작될 때 실행할 이 레시피를 할당합니다.
    • 분산 호스트 구성에 AWS 제공 레시피를 사용하도록 AWS OpsWorks 계층을 구성하고 레시피 설정에서 인스턴스 호스트 이름 및 파일 경로 파라미터를 구성합니다.
15. Amazon EC2 인스턴스에서 실행 중인 애플리케이션이 있고 IAM 역할을 사용하여 AWS 서비스 API에 안전하게 액세스하고 있습니다. AWS SDK와 함께 사용할 API 키를 검색하도록 해당 인스턴스에서 실행 중인 애플리케이션을 구성하려면 어떻게 해야 합니까?
    • 콘솔에서 EC2 IAM 역할을 인스턴스에 할당할 때 "Chosen SDK" 드롭다운 목록에서 사용 중인 SDK를 선택하면 인스턴스가 시작할 때 API 키로 올바른 SDK를 구성합니다.
    • 애플리케이션 코드 내에서 IAM 서비스 API에 대한 GET 요청을 만들어 사용자의 자격 증명을 검색합니다.
    • AWS SDK 및 Amazon EC2 역할을 사용하는 경우 SDK가 Amazon EC2 메타데이터 서비스에서 검색을 처리하기 때문에 명시적으로 API 키를 검색할 필요가 없습니다.
    • 애플리케이션 코드 내에서 환경 변수에서 API 키를 가져오도록 AWS SDK를 구성합니다. Amazon EC2 역할을 할당하면 시작 시 환경 변수에 키가 저장되기 때문입니다.
16. Auto Scaling 그룹이 Amazon Elastic Compute Cloud(EC2)에서 실행 중인 경우 애플리케이션은 10분 내에 로드에 대한 응답으로 빠르게 확장 및 축소됩니다. 그러나 부하가 최고조에 달한 후에는 이전에 종료된 Amazon EC2 리소스가 여전히 활성 상태로 표시되는 구성 관리 시스템의 문제를 보기 시작합니다. 구성 관리 시스템 내에서 Amazon EC2 리소스 정리를 처리하는 안정적이고 효율적인 방법은 무엇입니까? (두 가지를 선택하세요.)
    • Amazon EC2 인스턴스에서 일일 크론 작업으로 실행되고 EC2 Auto Scaling 그룹의 API 설명 호출을 실행하고 구성 관리 시스템에서 종료된 인스턴스를 제거하는 스크립트를 작성합니다.
    • 새 메시지를 수신하고 구성 관리 시스템에서 종료된 인스턴스를 제거하는 스크립트가 있는 Auto Scaling 작업을 위해 Amazon Simple Queue Service(SQS) 대기열을 구성합니다.
    • 기존 구성 관리 시스템을 사용하여 인스턴스 시작 및 부트스트래핑을 제어하여 자동화에서 움직이는 부분의 수를 줄이십시오.
    • 구성 관리 시스템에서 리소스 등록을 취소하기 위해 Amazon EC2 인스턴스 종료 중에 실행되는 작은 스크립트를 작성합니다.
    • Amazon Simple Workflow Service(SWF)를 사용하여 이전에 시작된 인스턴스의 화이트리스트가 포함된 Amazon DynamoDB 데이터베이스를 유지하고 Amazon SWF 작업자가 구성 관리 시스템에서 정보를 제거할 수 있도록 합니다.
17. Elastic Load Balancing HTTP 상태 확인을 활성화했습니다. AWS Management Console을 살펴본 후 모든 인스턴스가 상태 확인을 통과하고 있음을 알 수 있지만 고객은 사이트가 응답하지 않는다고 보고합니다. 원인이 무엇입니까?
    • 인스턴스 간 메타데이터 동기화의 대기 시간으로 인해 HTTP 상태 확인 시스템이 잘못 보고하고 있습니다.
    • 상태 확인이 애플리케이션 기능을 충분히 평가하지 않습니다. 
    • 애플리케이션이 AWS Management 콘솔이 응답하기에 너무 빨리 긍정적인 상태 확인을 반환합니다.
    • DNS 확인의 지연 시간이 Amazon EC2 메타데이터 검색을 방해합니다.
18. Amazon CloudWatch를 웹 애플리케이션의 기본 모니터링 시스템으로 사용합니다. 최근 소프트웨어 배포 후 사용자가 웹 응용 프로그램을 사용할 때 간헐적인 500 내부 서버 오류가 발생합니다. CloudWatch 경보를 생성하고 이러한 경보가 발생하면 대기 중인 엔지니어에게 알리려고 합니다. AWS 서비스를 사용하여 어떻게 이를 달성할 수 있습니까? (3개를 선택하세요.)
    • 웹 애플리케이션을 AWS Elastic Beanstalk 애플리케이션으로 배포합니다. 기본 Elastic Beanstalk Cloudwatch 지표를 사용하여 500개의 내부 서버 오류를 캡처합니다. 해당 지표에 CloudWatch 경보를 설정합니다.
    • 웹 애플리케이션 로그를 CloudWatch로 스트리밍하려면 서버에 CloudWatch Logs 에이전트를 설치하십시오.
    • Amazon Simple Email Service를 사용하여 CloudWatch 경보가 트리거될 때 대기 중인 엔지니어에게 알립니다.
    • CloudWatch Logs 그룹을 생성하고 500개의 내부 서버 오류를 캡처하는 지표 필터를 정의합니다. 해당 지표에 CloudWatch 경보를 설정합니다.
    • Amazon Simple Notification Service를 사용하여 CloudWatch 경보가 트리거될 때 대기 중인 엔지니어에게 알립니다.
    • AWS Data Pipeline을 사용하여 서버에서 CloudWatch로 웹 애플리케이션 로그를 스트리밍합니다.
19. 개발 팀과 매일 스크럼을 나눈 후 Blue/Green 스타일 배포를 사용하는 것이 팀에 도움이 된다는 데 동의했습니다.
    
    이 새로운 요구 사항을 전달하기 위해 어떤 기술을 사용해야 합니까?
    
    • AWS Elastic Beanstalk에 애플리케이션을 재배포하고 Elastic Beanstalk 배포 유형을 활용하십시오.
    • AWS CloudFormation 템플릿을 사용하여 로드 밸런서 뒤에 애플리케이션을 재배포하고, 배포할 때마다 새 AWS CloudFormation 스택을 시작하고, 테스트하는 동안 트래픽의 절반을 새 스택으로 보내도록 로드 밸런서를 업데이트하고, 확인 후 로드 밸런서를 다음으로 업데이트합니다. 트래픽의 100%를 새 스택으로 보낸 다음 이전 스택을 종료합니다.
    • Auto Scaling 그룹을 사용하는 로드 밸런서 뒤에 애플리케이션을 재배포하고 동일한 Auto Scaling 그룹을 새로 생성한 다음 로드 밸런서에 연결합니다. 배포 시 기존 Auto Scaling 그룹에 원하는 인스턴스 수를 0으로 설정하고 모든 인스턴스가 종료되면 기존 Auto Scaling 그룹을 삭제합니다.
    • AWS OpsWorks 스택을 사용하여 Elastic Load Balancing 로드 밸런서 뒤에서 애플리케이션을 재배포하고 OpsWorks 스택 버전 관리를 활용하고, 배포 중에 애플리케이션의 새 버전을 생성하고, 로드 밸런서 뒤에서 새 버전을 시작하도록 OpsWorks에 알리고, 언제 새 버전이 실행되면 이전 OpsWorks 스택을 종료합니다.
20. 개발 팀은 매우 안전한 환경의 라이브 디버깅을 수행하기 위해 프로덕션 인스턴스에 대한 계정 수준 액세스를 원합니다. 다음 중 무엇을 해야 합니까?
    • Amazon Elastic Compute Cloud(EC2)에서 제공한 자격 증명을 암호화가 활성화된 보안 Amazon Sample Storage Service(S3) 버킷에 넣습니다. 자격 증명 파일을 다운로드할 수 있도록 AWS Identity and Access Management(IAM) 사용자를 각 개발자에게 할당합니다.
    • 고객 키 및 구성 관리를 사용하여 서버 측 암호화를 사용하여 내부에서 생성된 개인 키를 보안 S3 버킷에 배치하고, 이 개인 키를 사용하여 모든 인스턴스에서 서비스 계정을 만들고, 파일을 다운로드할 수 있도록 각 개발자에게 IAM 사용자를 할당합니다.
    • 각 개발자의 공개 키를 프라이빗 S3 버킷에 배치하고, 인스턴스 프로파일 및 구성 관리를 사용하여 모든 인스턴스에서 각 개발자의 사용자 계정을 생성하고, 사용자의 공개 키를 적절한 계정에 배치합니다.
    • Amazon EC2에서 제공한 자격 증명을 MFA 암호화 USB 드라이브에 저장하고 개인 키가 사무실을 떠나지 않도록 각 개발자와 물리적으로 공유합니다.