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

 

DOP-C01 : AWS DevOps Engineer Professional : All Parts
DOP-C01 Part 01	DOP-C01 Part 08	DOP-C01 Part 15	DOP-C01 Part 22
DOP-C01 Part 02	DOP-C01 Part 09	DOP-C01 Part 16	DOP-C01 Part 23
DOP-C01 Part 03	DOP-C01 Part 10	DOP-C01 Part 17	DOP-C01 Part 24
DOP-C01 Part 04	DOP-C01 Part 11	DOP-C01 Part 18	DOP-C01 Part 25
DOP-C01 Part 05	DOP-C01 Part 12	DOP-C01 Part 19	DOP-C01 Part 26
DOP-C01 Part 06	DOP-C01 Part 13	DOP-C01 Part 20	DOP-C01 Part 27
DOP-C01 Part 07	DOP-C01 Part 14	DOP-C01 Part 21

 

 

1. 소스 제어를 위해 AWS CodeCommit을 사용하는 회사는 개발 환경의 AWS에서 지속적 통합 및 지속적 전달 파이프라인을 자동화하려고 합니다. 회사에는 세 가지 요구 사항이 있습니다.
   
   1. 코드 변경은 CI/CD 파이프라인을 자동으로 트리거해야 합니다.
   2. 파이프라인의 모든 오류는 devops-admin@xyz.com에 알려야 합니다.
   3. 테스트를 수행한 후 자산을 Amazon S3에 스테이징하려면 승인을 받아야 합니다.
   
   또한 회사는 자동화에 대해 다음과 같은 요구 사항을 가지고 있습니다.
   
   1. 민감한 정보가 소스 코드를 통해 유출되지 않도록 모든 코드 변경에 대한 법적 및 보안 검토가 있어야 합니다.
   2. 모든 변경 사항은 단위 테스트를 거쳐야 합니다.
   3. 모든 변경 사항은 기능을 보장하기 위해 일련의 기능 테스트를 거쳐야 합니다.
   
   DevOps 엔지니어는 CI/CD 모범 사례를 따르는 동시에 이러한 모든 요구 사항을 충족하기 위해 무엇을 해야 합니까?
   • 개발 분기에 커밋하고 개발 분기에서 AWS CodePipeline을 트리거합니다. 보안 검토, 단위 테스트, 기능 테스트 및 수동 승인을 위해 CodePipeline에서 개별 단계를 만듭니다. Amazon CloudWatch 지표를 사용하여 devops-admin@xyz.com에 이메일을 보내기 위해 파이프라인 단계 및 Amazon SES의 변경 사항을 감지합니다.
   • 메인라인에 커밋하고 메인라인에서 AWS CodePipeline을 트리거합니다. 보안 검토, 단위 테스트, 기능 테스트 및 수동 승인을 위해 CodePipeline에서 개별 단계를 만듭니다. AWS CloudTrail 로그를 사용하여 devops-admin@xyz.com으로 이메일을 보내기 위해 파이프라인 단계 및 Amazon SNS의 변경 사항을 감지합니다.
   • 개발 분기에 커밋하고 개발 분기에서 AWS CodePipeline을 트리거합니다. 보안 검토, 단위 테스트, 기능 테스트 및 수동 승인을 위해 CodePipeline에서 개별 단계를 만듭니다. Amazon CloudWatch Events를 사용하여 devops-admin@xyz.com에 이메일을 보내기 위해 파이프라인 단계 및 Amazon SNS의 변경 사항을 감지합니다.
   • 메인라인에 커밋하고 메인라인에서 AWS CodePipeline을 트리거합니다. 보안 검토, 단위 테스트, 기능 테스트 및 수동 승인을 위해 CodePipeline에서 개별 단계를 만듭니다. Amazon CloudWatch Events를 사용하여 파이프라인 단계의 변경 사항을 감지하고 devops-admin@xyz.com에 이메일을 보내기 위해 Amazon SES를 사용합니다.
     
     설명:  CodePipeline 이벤트 모니터링
     CodePipeline AWS계정의 리소스 상태가 변경될 때마다 Amazon Events에 CloudWatch 이벤트를 보고합니다.
     
     
2. DevOps 엔지니어는 Docker 컨테이너 기술을 사용하여 이미지 분석 애플리케이션을 구축합니다. 애플리케이션은 종종 트래픽 급증을 확인합니다. 엔지니어는 비용 효율성을 유지하고 가용성에 미치는 영향을 최소화하면서 고객 요구에 따라 애플리케이션을 자동으로 확장해야 합니다.
   
   다른 요구 사항을 충족하면서 트래픽 급증에 가장 빠르게 대응할 수 있는 것은 무엇입니까?
   
   • Auto Scaling 그룹의 컨테이너 인스턴스로 Amazon ECS 클러스터를 생성합니다. Service Auto Scaling을 사용하도록 ECS 서비스를 구성합니다. Amazon CloudWatch 경보를 설정하여 ECS 서비스 및 클러스터를 확장합니다.
   • AWS Elastic Beanstalk 멀티컨테이너 Docker 환경에 컨테이너를 배포합니다. Amazon CloudWatch 지표를 기반으로 환경을 자동으로 확장하도록 Elastic Beanstalk를 구성합니다.
   • 스팟 인스턴스를 사용하여 Amazon ECS 클러스터를 생성합니다. Service Auto Scaling을 사용하도록 ECS 서비스를 구성합니다. Amazon CloudWatch 경보를 설정하여 ECS 서비스 및 클러스터를 확장합니다.
   • Amazon EC2 인스턴스에 컨테이너를 배포합니다. 컨테이너 스케줄러를 배포하여 컨테이너를 EC2 인스턴스에 예약합니다. 사용 가능한 Amazon CloudWatch 지표를 기반으로 EC2 인스턴스에 대한 EC2 Auto Scaling을 구성합니다.
     
     설명: AWS Elastic Beanstalk > Elastic Beanstalk 콘솔의 ECS 관리형 Docker 환경
     Elastic Beanstalk 콘솔을 사용하는 확장 가능 Elastic Beanstalk 환경 또는 단일 인스턴스에서 멀티컨테이너 인스턴스의 클러스터를 시작할 수 있습니다. 
     
     
3. DevOps 엔지니어는 AWS CodePipeline을 사용하여 다단계 파이프라인을 구축하여 애플리케이션을 구축, 확인, 스테이징, 테스트 및 배포합니다. 테스트 단계와 배포 단계 사이에 수동 승인 단계가 필요합니다. 개발팀은 웹후크를 지원하는 팀 채팅 도구를 사용합니다.
   
   엔지니어는 채팅 도구에 게시할 파이프라인 활동 및 승인 요청에 대한 상태 업데이트를 어떻게 구성할 수 있습니까?
   
   • "detail-type": "CodePipeline Pipeline Execution State Change"를 필터링하는 AWS CloudWatch Logs 구독을 생성합니다. 이를 Amazon SNS 주제로 전달합니다. 구독자로 SNS 주제에 채팅 웹훅 URL을 추가하고 구독 유효성 검사를 완료합니다.
   • AWS CloudTrail 이벤트 업데이트로 트리거되는 AWS Lambda 함수를 생성합니다. 업데이트된 이벤트에서 "CodePipeline 파이프라인 실행 상태 변경" 이벤트가 감지되면 이벤트 세부 정보를 채팅 웹훅 URL로 보냅니다.
   • "CodePipeline 파이프라인 실행 상태 변경"을 필터링하는 AWS CloudWatch Events 규칙을 생성합니다. 이를 Amazon SNS 주제로 전달합니다. Amazon SNS 주제에 대한 AWS Lambda 함수를 구독하고 이벤트를 채팅 웹후크 URL로 전달하도록 합니다.
   • 각 단계의 끝에서 채팅 웹후크 URL로 이벤트 세부 정보를 보내도록 파이프라인 코드를 수정합니다. 각 파이프라인이 파이프라인 환경에 따라 다른 URL로 보낼 수 있도록 URL을 매개변수화합니다.
     
     설명: How to Set AWS CodePipeline Notification Rules?
     
     
     
4. 한 회사가 AWS 클라우드로 이전하기 시작했습니다. 내부 고객은 AWS 기술에 따라 초보자와 전문가의 두 그룹으로 분류됩니다.
   
   DevOps 엔지니어는 초보자가 AWS CloudFormation 템플릿으로 표현되는 제한된 AWS 아키텍처 청사진 세트를 배포할 수 있는 솔루션을 구축해야 합니다. 배포는 미리 결정된 Virtual Private Cloud(VPC)에서만 가능해야 합니다. 그러나 전문 사용자는 제약 없이 Blueprint를 배포할 수 있어야 합니다. 전문가는 필요에 따라 다른 AWS 서비스에도 액세스할 수 있어야 합니다.
   
   엔지니어는 최소한의 오버헤드로 이러한 요구 사항을 충족하는 솔루션을 어떻게 구현할 수 있습니까?
   • 템플릿의 매개변수에 제약 조건을 적용하여 배포에 사용할 수 있는 VPC를 제한합니다. 템플릿을 Amazon S3에 저장합니다. 초보자를 위한 IAM 그룹을 생성하고 템플릿 및 CloudFormation에 대한 액세스 권한을 부여합니다. 전문가를 위한 별도의 그룹을 만들어 템플릿, CloudFormation 및 기타 AWS 서비스에 대한 액세스 권한을 부여합니다.
   • 템플릿을 Amazon S3에 저장합니다. AWS Service Catalog를 사용하여 해당 템플릿을 기반으로 제품 포트폴리오를 생성합니다. 배포에 사용할 수 있는 VPC를 제한하는 규칙이 있는 제품에 템플릿 제약 조건을 적용합니다. 포트폴리오에 대한 액세스 권한을 부여하는 초보자용 IAM 그룹을 생성합니다. 템플릿, CloudFormation 및 기타 AWS 서비스에 대한 액세스 권한을 부여하는 전문가를 위한 별도의 그룹을 만듭니다.
   • 템플릿을 Amazon S3에 저장합니다. AWS Service Catalog를 사용하여 해당 템플릿을 기반으로 제품 포트폴리오를 생성합니다. AWS 리소스 생성에 사용할 수 있는 VPC를 제한하는 IAM 역할을 생성합니다. 이 역할을 사용하는 제품에 시작 제약 조건을 적용합니다. 포트폴리오에 대한 액세스 권한을 부여하는 초보자용 IAM 그룹을 생성합니다. 전문가에게 포트폴리오 및 기타 AWS 서비스에 대한 액세스 권한을 부여하는 별도의 그룹을 만듭니다.
   • 각 아키텍처 청사진에 대해 두 개의 템플릿을 생성합니다. 이 템플릿 중 하나만 배포에 사용할 수 있는 VPC를 제한합니다. 템플릿을 Amazon DynamoDB에 저장합니다. 제한된 템플릿과 CloudFormation에 대한 액세스 권한을 부여하는 초보자용 IAM 그룹을 생성합니다. 무제한 템플릿, CloudFormation 및 기타 AWS 서비스에 대한 액세스 권한을 부여하는 전문가를 위한 별도의 그룹을 만듭니다.
     
     설명: AWS Service Catalog
     AWS Service Catalog를 사용하면 조직에서 AWS용으로 승인된 IT 서비스의 카탈로그를 생성하고 관리할 수 있습니다. 이러한 IT 서비스에는 가상 머신 이미지, 서버, 소프트웨어, 데이터베이스 등에서 완전한 다중 계층 애플리케이션 아키텍처에 이르기까지 모든 것이 포함될 수 있습니다.
     
     서비스 카탈로그를 통해 조직은 일반적으로 배포된 IT 서비스를 중앙에서 관리하고 조직이 일관된 거버넌스를 달성하고 규정 준수 요구 사항을 충족하도록 돕습니다. 최종 사용자는 조직에서 설정한 제약 조건에 따라 필요한 승인된 IT 서비스만 신속하게 배포할 수 있습니다.
5. DevOps 엔지니어가 AWS CloudFormation 템플릿을 사용하여 Amazon ECS 클러스터를 생성하려고 할 때 다음 오류가 발생했습니다.
   An error occurred (InsufficientCapabilitiesException) when calling the CreateStack operation.
   
   이 오류의 원인은 무엇이며 엔지니어가 AWS CloudFormation 템플릿을 성공적으로 실행하려면 어떤 조치를 취해야 합니까?
   • CloudFormation 템플릿을 실행하려는 AWS 사용자 또는 역할에 템플릿 내에서 리소스를 생성하는 데 필요한 권한이 없습니다. 엔지니어는 사용자 정책을 검토하고 리소스를 생성하는 데 필요한 권한을 추가한 다음 템플릿 실행을 다시 실행해야 합니다.
   • AWS CloudFormation 서비스에 연결할 수 없으며 클러스터를 생성할 수 없습니다. 엔지니어는 라우팅 및 방화벽 규칙이 AWS CloudFormation 스크립트가 AWS 서비스 엔드포인트와 통신하는 것을 막지 않는지 확인한 다음 템플릿 실행을 다시 실행해야 합니다.
   • CloudFormation 실행에 IAM 리소스를 생성할 수 있는 기능이 부여되지 않았습니다. 엔지니어는 CAPABILITY_IAM 및 CAPABILITY_NAMED_IAM을 CloudFormation 실행 매개변수의 기능으로 제공하거나 AWS Management Console에서 기능을 제공해야 합니다.
   • CloudFormation은 현재 AWS 리전에서 지정된 리소스의 요청을 이행할 수 없습니다. 엔지니어는 새 지역을 지정하고 템플릿을 다시 실행해야 합니다.
     
     설명: AWS CloudFormation > CreateStack
     CAPABILITY_IAM그리고CAPABILITY_NAMED_IAM 일부 스택 템플릿에는 AWS 계정의 권한에 영향을 줄 수 있는 리소스가 포함될 수 있습니다. 예를 들어 새 AWS Identity and Access Management(IAM) 사용자를 생성합니다. 해당 스택의 경우 이러한 기능 중 하나를 지정하여 이를 명시적으로 승인해야 합니다. 이러한 기능 중 하나를 지정하지 않으면 AWS CloudFormation에서 InsufficientCapabilities오류를 반환합니다.
     
     
6. 소매 회사는 현재 온프레미스 데이터 센터에서 Java 기반 애플리케이션을 호스팅하고 있습니다. 경영진은 DevOps 엔지니어가 이 애플리케이션을 AWS로 옮기기를 원합니다. 요구 사항에 따르면 고가용성을 유지하면서 인프라 관리는 가능한 한 단순해야 합니다. 또한 새 애플리케이션 버전을 배포하는 동안 비용은 중요한 메트릭이지만 엔지니어는 플릿의 절반 이상이 사용자 트래픽을 처리하는 데 사용할 수 있는지 확인해야 합니다.
   
   이러한 요구 사항을 충족하기 위해 최소한의 관리 오버헤드가 필요한 옵션은 무엇입니까?
   
   • AWS CodeDeploy 배포 그룹을 생성하고 서로 다른 가용 영역의 서브넷에서 인스턴스를 시작하도록 구성된 Auto Scaling 그룹과 연결합니다. 애플리케이션 배포를 위한 CodeDeploy.HalfAtAtime 구성으로 인플레이스 배포를 구성합니다.
   • Auto Scaling 및 로드 밸런싱을 사용하여 AWS Elastic Beanstalk Java 기반 환경을 만듭니다. 서로 다른 가용 영역의 서브넷에서 인스턴스를 시작하도록 환경에 대한 네트워크 설정을 구성합니다. 배치 크기가 50%인 배포 전략으로 "추가 배치로 롤링"을 사용합니다.
   • AWS CodeDeploy 배포 그룹을 생성하고 서로 다른 가용 영역의 서브넷에서 인스턴스를 시작하도록 구성된 Auto Scaling 그룹과 연결합니다. FLEET_PERCENT 유형 및 값 50으로 설정된 MinimumHealthyHosts 옵션을 사용하여 사용자 지정 배포 구성으로 인플레이스 배포를 구성합니다.
   • Auto Scaling 및 로드 밸런싱을 사용하여 AWS Elastic Beanstalk Java 기반 환경을 만듭니다. 서로 다른 가용 영역의 서브넷에서 인스턴스를 시작하도록 환경에 대한 네트워크 옵션을 구성합니다. 일괄 처리 크기가 50%인 배포 전략으로 "롤링"을 사용합니다.
7. 분산된 개발 팀이 있는 글로벌 회사는 Amazon ECS에서 실행되는 마이크로서비스 아키텍처를 사용하여 웹 애플리케이션을 구축했습니다. 각 애플리케이션 서비스는 독립적이며 ECS 클러스터에서 서비스로 실행됩니다. 컨테이너 빌드 파일과 소스 코드는 비공개 GitHub 소스 코드 리포지토리에 있습니다. 개발, 테스트 및 프로덕션 환경을 위한 별도의 ECS 클러스터가 있습니다.
   
   개발자는 GitHub 리포지토리의 분기에 기능을 푸시한 다음 변경 사항을 환경별 분기(개발, 테스트 또는 프로덕션)로 병합해야 합니다. 이 병합은 적절한 ECS 클러스터에 대한 빌드 및 배포를 실행하기 위해 자동화된 파이프라인을 트리거해야 합니다.
   
   DevOps 엔지니어는 이러한 요구 사항에 대한 자동화된 솔루션으로 무엇을 권장해야 합니까?
   • ECS 클러스터 및 AWS CodePipeline 서비스에 대한 AWS CloudFormation 스택을 생성합니다. 컨테이너 빌드 파일을 Amazon S3 버킷에 저장합니다. 커밋 후 후크를 사용하여 ECS 클러스터를 배포하는 CloudFormation 스택 업데이트를 트리거합니다. S3의 컨테이너 빌드 파일을 기반으로 이미지를 빌드하고 Amazon ECR에 푸시하는 작업을 ECS 클러스터에 추가합니다.
   • 각 환경에 대해 AWS CodePipeline에서 별도의 파이프라인을 생성합니다. GitHub의 해당 환경 분기에 대한 커밋을 기반으로 각 파이프라인을 트리거합니다. 빌드 단계를 추가하여 AWS CodeBuild를 시작하여 빌드 파일에서 컨테이너 이미지를 생성하고 Amazon ECR로 푸시합니다. 그런 다음 다른 단계를 추가하여 해당 환경에 적합한 클러스터에서 Amazon ECS 작업 및 서비스 정의를 업데이트합니다.
   • AWS CodePipeline에서 파이프라인을 생성합니다. GitHub의 마스터 브랜치에 대한 커밋에 의해 트리거되도록 구성합니다. 커밋을 적용해야 하는 환경을 결정하기 위해 Git 커밋 메시지를 사용하는 단계를 추가한 다음 create-image Amazon ECR 명령을 호출하여 이미지를 빌드하고 컨테이너 빌드 파일에 전달합니다. 그런 다음 해당 환경에 적합한 클러스터에서 ECS 작업 및 서비스 정의를 업데이트하는 단계를 추가합니다.
   • AWS CodeCommit에서 새 리포지토리를 생성합니다. GitHub 리포지토리를 새 CodeCommit 리포지토리와 동기화하도록 AWS CodeBuild에서 예약된 프로젝트를 구성합니다. CodeCommit 리포지토리 변경으로 트리거되는 각 환경에 대해 별도의 파이프라인을 생성합니다. AWS Lambda를 사용하여 컨테이너 이미지를 빌드하고 Amazon ECR에 푸시하는 단계를 추가합니다. 그런 다음 다른 단계를 추가하여 해당 환경에 적합한 클러스터에서 ECS 작업 및 서비스 정의를 업데이트합니다.
8. 감사, 분석 및 문제 해결을 위해 데이터 분석 애플리케이션의 DevOps 엔지니어는 종료 전에 Amazon EC2 인스턴스에서 모든 애플리케이션 및 Linux 시스템 로그를 수집해야 합니다. 이 회사는 평균적으로 Auto Scaling 그룹에서 10,000개의 인스턴스를 실행합니다. 회사는 인스턴스 ID 및 날짜 범위를 기반으로 로그를 빠르게 찾을 수 있는 기능이 필요합니다.
   
   가장 비용 효율적인 솔루션은 무엇입니까?
   
   • 그룹에서 EC2 인스턴스 종료 수명 주기 작업을 생성하고 로그를 Amazon S3로 푸시하기 위한 종료 스크립트를 작성하고 S3 PUT을 기반으로 AWS Lambda 함수를 트리거하여 기본 키가 있는 Amazon DynamoDB 테이블에 로그 파일의 카탈로그를 생성합니다. 인스턴스 ID 및 정렬 키는 인스턴스 종료 날짜입니다.
   • 그룹에서 EC2 인스턴스 종료 수명 주기 작업 생성, 로그를 Amazon CloudWatch Logs로 푸시하기 위한 종료 스크립트 작성, CloudWatch Events 규칙을 생성하여 AWS Lambda 함수를 트리거하여 Amazon DynamoDB 테이블에 로그 파일의 카탈로그를 기본 키는 인스턴스 ID이고 정렬 키는 인스턴스 종료 날짜입니다.
   • 그룹에서 EC2 인스턴스 종료 수명 주기 작업을 생성하고 이를 기반으로 Amazon CloudWatch Events 규칙을 생성하여 Amazon S3에 로그를 저장하기 위한 AWS Lambda 함수를 트리거하고 Amazon DynamoDB 테이블에 기본 로그 파일 카탈로그를 생성합니다. 키는 인스턴스 ID이고 정렬 키는 인스턴스 종료 날짜입니다.
   • 그룹에서 EC2 인스턴스 종료 수명 주기 작업을 생성하고 로그를 Amazon Kinesis Data Firehose로 푸시한 다음 스토리지 및 검색 기능을 제공하기 위한 대상으로 Amazon ES를 선택합니다.
9. DevOps 엔지니어는 Amazon EC2에서 실행되는 대규모 상용 웹 사이트를 관리합니다. 웹사이트는 Amazon Kinesis Data Streams를 사용하여 웹 로그를 수집하고 처리합니다. DevOps 엔지니어는 Amazon EC2에서도 실행되는 Kinesis consumer 애플리케이션을 관리합니다.
   
   데이터가 갑자기 증가하면 Kinesis consumer 애플리케이션이 뒤처지고 Kinesis 데이터 스트림은 레코드가 처리되기 전에 레코드를 삭제합니다. DevOps 엔지니어는 스트림 처리를 개선하기 위한 솔루션을 구현해야 합니다.
   
   가장 운영 효율성이 높은 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
   • Amazon S3에 로그를 안정적으로 저장하도록 Kinesis 소비자 애플리케이션을 수정합니다. Amazon EMR을 사용하여 Amazon S3에서 직접 데이터를 처리하여 고객 통찰력을 얻습니다. 결과를 Amazon S3에 저장합니다.
   • Amazon CloudWatch GetRecords.IteratorAgeMilliseconds 지표를 기반으로 더 많은 EC2 인스턴스를 추가하여 Kinesis 소비자 애플리케이션을 수평으로 확장합니다. Kinesis Data Streams의 보존 기간을 늘립니다.
   • AWS Lambda 함수로 실행되도록 Kinesis 소비자 애플리케이션을 변환합니다. 데이터 스트림을 처리할 Lambda 함수의 이벤트 소스로 Kinesis Data Streams를 구성합니다.
   • 소비자 애플리케이션이 데이터를 더 빠르게 처리할 수 있도록 Kinesis Data Streams의 샤드 수를 늘려 전체 처리량을 늘립니다.
10. DevOps 엔지니어는 AWS 계정의 모든 사용자에 대해 사용자별로 불필요한 권한을 식별하는 주간 프로세스를 자동화해야 합니다. 이 프로세스는 사용자가 지난 90일 동안 실제로 사용한 권한과 비교하여 사용자의 연결된 IAM 액세스 정책을 검사하여 각 사용자에게 현재 부여된 권한을 평가해야 합니다. 비교의 차이는 사용자에게 필요한 것보다 더 많은 권한이 있음을 나타냅니다. 필요에 따라 추가 검토 및 IAM 사용자 액세스 정책 개정을 위해 델타 보고서를 정보 보안 팀에 보내야 합니다.
    
    완전히 자동화되어 가장 상세한 델타 보고서를 생성하는 솔루션은 무엇입니까?
    
    • IAM Access Advisor API를 호출하여 AWS 계정의 모든 사용자에게 사용자별로 부여된 서비스 권한을 가져오는 AWS Lambda 함수를 생성합니다. Access Advisor가 90일의 추적 기간으로 구성되었는지 확인합니다. 매주 일정에 따라 Amazon CloudWatch Events 규칙을 사용하여 Lambda 함수를 호출합니다. 각 레코드, 사용자별, 서비스별로 Access Advisor Last Accesses(액세스 관리자 마지막 액세스) 필드가 "추적 기간 동안 액세스하지 않음" 대신 일 수를 나타내는 경우 이는 사용자의 현재 연결된 액세스 정책에 있는 것과 비교한 델타를 나타냅니다. Lambda가 AWS 계정의 모든 사용자를 통해 반복한 후 보고서를 생성하고 Amazon SES를 사용하여 보고서를 보내도록 구성합니다.
    • 모든 AWS 리전과 모든 읽기/쓰기 이벤트에 걸쳐 있는 AWS CloudTrail 추적을 구성하고 이 추적이 Amazon S3 버킷을 가리키도록 합니다. Amazon Athena 테이블을 생성하고 CREATE TABLE 쿼리에서 S3 버킷 ARN을 지정합니다. WHERE 절에 userIdentity, eventName 및 eventTime이 포함되도록 SELECT를 수행하는 SDK를 사용하여 Athena 테이블에 액세스하는 AWS Lambda 함수를 생성합니다. 사용자의 현재 연결된 IAM 액세스 정책과 결과를 비교하여 델타를 결정합니다. 일주일에 한 번 실행되도록 이 프로세스를 자동화하도록 Amazon CloudWatch Events 일정을 구성합니다. 정보 보안 팀에 통합 보고서를 보내도록 Amazon SES를 구성합니다.
    • 전체 계정에서 사용자 트래픽을 캡처하려면 모든 리전의 모든 VPC에 걸쳐 모든 서브넷에서 VPC 흐름 로그를 구성합니다. 모든 흐름 로그를 통합하고 집계할 수 있도록 모든 로그가 중앙 집중식 Amazon S3 버킷으로 전송되는지 확인합니다. Amazon CloudWatch Events 일정에 따라 일주일에 한 번 트리거되는 AWS Lambda 함수를 생성합니다. Lambda 함수가 IAM 사용자 ID, 서브넷 ID, VPC ID, API 호출당 허용/거부 상태 및 서비스 이름 정보에 대한 흐름 로그 파일을 구문 분석하는지 확인합니다. 그런 다음 함수가 사용자별로 델타를 결정하도록 합니다. Amazon SES를 사용하여 통합 보고서를 보내도록 Lambda 함수를 구성합니다.
    • Amazon ES 클러스터를 생성하고 Lambda 함수에 환경 변수로 제공될 엔드포인트 URL을 기록해 둡니다. AWS CloudTrail 추적 대상 S3 버킷에서 Amazon S3 이벤트를 구성하고 이벤트가 Lambda 함수로 전송되도록 구성되었는지 확인합니다. 이벤트를 사용하고 JSON의 입력을 구문 분석하여 Amazon ES 문서 형식으로 변환하는 Lambda 함수를 생성합니다. 전달된 환경 변수를 통해 Amazon ES 클러스터의 엔드포인트에 문서를 POST합니다. Amazon ES에 적절한 인덱싱이 있는지 확인하고 Apache Lucene 쿼리를 사용하여 사용자별로 권한을 구문 분석하십시오. 델타를 보고서로 내보내고 Amazon ES가 매주 Amazon SES를 사용하여 정보 보안 팀에 보고서를 보내도록 합니다.
11. 한 회사가 AWS 리전에서 웹 애플리케이션을 호스팅하고 있습니다. 재해 복구를 위해 두 번째 지역이 대기 지역으로 사용되고 있습니다. 재해 복구 요구 사항에 따르면 거의 실시간으로 지역 간에 세션 데이터를 복제해야 하며 시스템 기능을 지속적으로 확인하기 위해 요청의 1%를 보조 지역으로 라우팅해야 합니다. 또한 메인 리전에서 서비스 중단이 발생하면 트래픽이 자동으로 보조 리전으로 라우팅되어야 하며 보조 리전은 모든 트래픽을 처리할 수 있도록 확장할 수 있어야 합니다.
    
    DevOps 엔지니어는 이러한 요구 사항을 어떻게 충족해야 합니까?
    
    • 두 리전에서 AWS Elastic Beanstalk에 애플리케이션을 배포하고 세션 데이터에 Amazon DynamoDB 전역 테이블을 사용합니다. 상태 확인과 함께 Amazon Route 53 가중 라우팅 정책을 사용하여 리전 전체에 트래픽을 분산합니다.
    • 두 리전에서 Auto Scaling 그룹의 애플리케이션을 시작하고 세션 데이터에 DynamoDB를 사용합니다. 상태 확인과 함께 Route 53 장애 조치 라우팅 정책을 사용하여 리전 전체에 트래픽을 분산합니다.
    • 두 리전에서 Amazon API Gateway에 의해 노출되는 AWS Lambda에 애플리케이션을 배포하고 세션 데이터에 대한 교차 리전 복제와 함께 Amazon RDS PostgreSQL을 사용합니다. API 게이트웨이를 직접 호출하기 위해 클라이언트측 로직과 함께 웹 애플리케이션을 배포합니다.
    • 두 리전에서 Auto Scaling 그룹의 애플리케이션을 시작하고 세션 데이터에 DynamoDB 전역 테이블을 사용합니다. 여러 지역에서 Amazon CloudFront 가중 분포를 활성화합니다. CloudFront 배포에서 Amazon Route 53 DNS 레코드를 가리킵니다.
      
      설명: Amazon DynamoDB > 전역 테이블 개념
      전역 테이블이란 하나의 AWS 계정에서 소유한 한 개 이상의 복제 테이블 모음입니다.
      
      복제 테이블(줄여서 복제본이라고도 함)은 전역 테이블의 일부로 기능하는 단일 DynamoDB 테이블입니다. 각 복제본에는 동일한 데이터 항목 집합이 저장됩니다. 전역 테이블은 AWS 리전당 한 개의 복제 테이블을 가질 수 있습니다. 전역 테이블을 시작하는 방법에 대한 자세한 내용은 자습서: 전역 테이블 생성를 참조하십시오.
12. DevOps 엔지니어는 지역 간 장애 조치 요구 사항이 있는 애플리케이션을 관리합니다. 애플리케이션은 보조 지역에 읽기 전용 복제본이 있는 기본 지역의 Amazon RDS 데이터베이스의 Amazon Aurora에 데이터를 저장합니다. 이 애플리케이션은 Amazon Route 53을 사용하여 고객 트래픽을 활성 지역으로 보냅니다.
    
    기본 데이터베이스에 장애가 발생할 경우 가동 중지 시간을 최소화하려면 어떤 조치를 취해야 합니까?
    
    • Amazon CloudWatch를 사용하여 RDS 인스턴스의 상태를 모니터링합니다. 장애가 발생한 경우 CloudWatch Events 규칙을 사용하여 Amazon SNS를 통해 시스템 운영자에게 단문 메시지 서비스(SMS)를 보냅니다. 시스템 운영자가 다운타임 메시지를 표시하는 Amazon S3 정적 웹 사이트로 트래픽을 리디렉션하도록 합니다. RDS 읽기 전용 복제본을 마스터로 승격합니다. 애플리케이션이 정상적으로 작동하는지 확인한 다음 Amazon S3 웹 사이트에서 보조 리전으로 트래픽을 리디렉션합니다.
    • RDS 이벤트 알림을 사용하여 Amazon SNS 주제에 대한 상태 업데이트를 게시합니다. 주제를 구독하는 AWS Lambda 함수를 사용하여 데이터베이스 상태를 모니터링합니다. 장애가 발생하면 Lambda 함수는 읽기 전용 복제본을 승격한 다음 Route 53을 업데이트하여 기본 지역에서 보조 지역으로 트래픽을 리디렉션합니다.
    • 기본 데이터베이스의 상태를 확인하는 AWS Lambda 함수를 주기적으로 호출하도록 Amazon CloudWatch Events 규칙을 설정합니다. 실패가 감지되면 Lambda 함수는 읽기 전용 복제본을 승격합니다. 그런 다음 Route 53을 업데이트하여 기본 리전에서 보조 리전으로 트래픽을 리디렉션합니다.
    • Route 53을 설정하여 두 지역 간의 트래픽 균형을 동일하게 유지하십시오. Aurora 다중 마스터 옵션을 활성화한 다음 Route 53 상태 확인을 설정하여 데이터베이스 상태를 분석하십시오. 기본 데이터베이스에 장애가 발생할 경우 자동으로 모든 트래픽을 보조 리전으로 보내도록 Route 53을 구성합니다.
      
      설명: Amazon RDS > Amazon RDS 이벤트 알림 작업
      Amazon Relational Database Service(Amazon RDS)는 AWS 클라우드에서 관계형 데이터베이스를 더 쉽게 설치, 운영 및 확장할 수 있는 웹 서비스입니다. 이 서비스는 산업 표준 관계형 데이터베이스를 위한 경제적이고 크기 조절이 가능한 용량을 제공하고 공통 데이터베이스 관리 작업을 관리합니다.
      Amazon RDS는 Amazon RDS 이벤트 발생 시 Amazon Simple Notification Service(Amazon SNS)를 사용하여 알림 서비스를 제공합니다. 이 서비스는 AWS 리전에 따라 Amazon SNS가 지원하는 알림 메시지 형식에 따라 이메일, 문자 또는 HTTP 엔드포인트 호출 등이 될 수 있습니다.
      
      
13. 회사는 ELB Application Load Balancer 뒤의 Amazon EC2 인스턴스에서 애플리케이션을 실행하고 있습니다. 인스턴스는 여러 가용 영역에 걸쳐 EC2 Auto Scaling 그룹에서 실행됩니다.
    
    최근 애플리케이션 업데이트 후 애플리케이션 URL에서 HTTP 502 잘못된 게이트웨이 오류가 발생합니다. DevOps 엔지니어는 시작 직후 Auto Scaling이 비정상으로 모든 EC2 인스턴스를 종료하기 때문에 문제를 분석할 수 없습니다.
    
    배포된 애플리케이션의 문제를 해결하기 위해 DevOps 엔지니어가 비정상 인스턴스 중 하나에 액세스할 수 있는 단계는 무엇입니까?
    • 종료된 인스턴스에서 이미지를 만들고 해당 이미지에서 새 인스턴스를 만듭니다. 그러면 애플리케이션 팀이 새 인스턴스에 로그인할 수 있습니다.
    • AutoScaling에 의해 새 인스턴스가 생성되는 즉시 인스턴스를 대기 상태로 전환해야 인스턴스가 종료되지 않습니다.
    • Auto Scaling 그룹에 수명 주기 후크를 추가하여 Terminating 상태의 인스턴스를 Terminating:Wait 상태로 이동합니다.
    • 비정상 인스턴스가 종료되지 않도록 보호하는 종료 방지 기능을 활성화하도록 Auto Scaling 그룹을 편집합니다.
14. 애플리케이션이 Amazon EC2에서 실행 중입니다. AWS Systems Manager Parameter Store에서 SecureString 파라미터 리소스에 액세스하려고 시도하는 동안 AccessDenied 오류를 수신하는 연결된 IAM 역할이 있습니다. SecureString 파라미터는 고객 관리형 고객 마스터 키(CMK)로 암호화됩니다.
    
    DevOps 엔지니어는 최소 권한을 부여하면서 역할에 대한 액세스 권한을 부여하기 위해 어떤 단계를 수행해야 합니까? (3개를 선택하세요.)
    
    • 인스턴스 역할의 IAM 정책에서 파라미터 리소스에 대해 ssm:GetParamter를 설정합니다.
    • 고객 관리형 CMK 정책에서 인스턴스 역할에 대해 kms:Decrypt를 설정합니다.
    • 역할의 IAM 정책에서 고객 관리형 CMK 리소스에 대해 kms:Decrypt를 설정합니다.
    • 인스턴스 역할 IAM 정책에서 파라미터 리소스에 대해 ssm:DecryptParameter를 설정합니다.
    • AWS 관리형 SSM KMS 키에서 사용자에 대해 kms:GenerateDataKey를 설정합니다.
    • 고객 관리형 CMK 정책에서 파라미터 리소스에 대해 kms:Decrypt를 설정합니다.
15. 애플리케이션 팀은 온프레미스 하드웨어 대신 AWS에서 실행되도록 내부 도구 중 하나를 리팩토링하고 있습니다. 모든 코드는 현재 Python으로 작성되었으며 독립 실행형입니다. 쿼리할 외부 상태 저장소나 관계형 데이터베이스도 없습니다.
    
    어떤 배포 파이프라인이 개발과 생산 사이에 가장 적은 양의 변경을 초래합니까?
    
    • 개발자는 로컬 개발에 Docker를 사용해야 합니다. 종속성이 변경되고 새 컨테이너가 준비되면 AWS CodePipeline 및 AWS CodeBuild를 사용하여 기능 테스트를 수행한 다음 새 컨테이너를 Amazon ECR에 업로드합니다. 사용자 지정 컨테이너와 함께 AWS CloudFormation을 사용하여 새 Amazon ECS를 배포합니다.
    • 개발자는 로컬 개발에 Docker를 사용해야 합니다. 종속성이 업데이트될 때마다 AWS SMS를 사용하여 이러한 컨테이너를 Amazon EC2용 AMI로 가져옵니다. AWS CodePipeline을 사용하여 Auto Scaling 그룹에 대한 새로운 코드 변경 사항을 테스트합니다.
    • 개발자는 기본 Python 환경을 사용해야 합니다. 종속성이 변경되고 새 컨테이너가 준비되면 AWS CodePipeline 및 AWS CodeBuild를 사용하여 기능 테스트를 수행한 다음 새 컨테이너를 Amazon ECR에 업로드합니다. 사용자 지정 컨테이너와 함께 AWS CloudFormation을 사용하여 새 Amazon ECS를 배포합니다.
    • 개발자는 기본 Python 환경을 사용해야 합니다. 종속성이 변경되고 새 코드가 준비되면 AWS CodePipeline 및 AWS CodeBuild를 사용하여 기능 테스트를 수행한 다음 새 컨테이너를 Amazon ECR에 업로드합니다. 사용자 지정 컨테이너와 함께 CodePipeline 및 CodeBuild를 사용하여 AWS Elastic Beanstalk 내에서 새로운 코드 변경 사항을 테스트하십시오.
      
      설명: AWS CodeDeploy > AWS CloudFormation을(를) 통해 Amazon ECS 블루/그린 배포 생성
      
      
      
16. 회사에서 AWS CodeBuild 프로젝트를 사용하여 애플리케이션을 빌드하고 패키징합니다. 패키지는 여러 AWS 계정에 배포되기 전에 공유 Amazon S3 버킷에 복사됩니다.
    
    buildspec.yml 파일에는 다음이 포함되어 있습니다.
    

    

    DOP-C01 AWS DevOps 엔지니어 전문가 파트 07 Q16 011

    
    DevOps 엔지니어는 AWS 계정이 있는 사람은 누구나 아티팩트를 다운로드할 수 있음을 확인했습니다.
    
    
    •  --acl public-read를 사용하도록 post_build를 명령으로 수정하고 관련 AWS 계정에만 읽기 액세스 권한을 부여하는 버킷 정책을 구성합니다.
    • 인증된 사용자 집합을 관련 AWS 계정으로만 정의하고 읽기 전용 액세스 권한을 부여하는 S3 버킷에 대한 기본 ACL을 구성합니다.
    • 관련 AWS 계정에 대한 읽기 액세스 권한을 부여하고 보안 주체 "*"에 대한 읽기 액세스를 거부하는 S3 버킷 정책 생성
    • post_build 명령을 수정하여 –-acl authenticated-read를 제거하고 관련 AWS 계정에 대한 읽기 액세스만 허용하는 버킷 정책을 구성합니다.
17. AWS Elastic Beanstalk 애플리케이션을 사용하여 웹 애플리케이션이 배포되었습니다. 애플리케이션 개발자는 애플리케이션의 서로 다른 두 영역에서 대기 시간이 길어지는 것을 우려하고 있습니다.
    
    – 타사 API에 대한 HTTP 클라이언트 요청
    – Amazon RDS 데이터베이스에 대한 MySQL 클라이언트 라이브러리 쿼리
    
    DevOps 엔지니어는 문제를 진단하기 위해 추적 데이터를 수집해야 합니다.
    
    응용 프로그램에 대한 변경 및 성능 영향이 가장 적은 추적 정보를 수집하는 단계는 무엇입니까?
    
    • 애플리케이션 코드에 추가 로깅을 추가합니다. Amazon CloudWatch 에이전트를 사용하여 애플리케이션 로그를 Amazon Elasticsearch Service로 스트리밍합니다. Amazon ES에서 로그 데이터를 쿼리합니다.
    • AWS X-Ray SDK를 사용하도록 애플리케이션을 계측합니다. 추적 데이터를 Amazon Elasticsearch Service 클러스터에 게시합니다. HTTP 클라이언트 및 MySQL 클라이언트 호출에 대한 추적 데이터를 쿼리합니다.
    • 애플리케이션의 AWS Elastic Beanstalk 관리 페이지에서 AWS X-Ray 데몬을 활성화합니다. X-Ray 콘솔에서 트레이스 데이터를 봅니다.
    • AWS X-Ray SDK를 사용하여 애플리케이션을 계측합니다. 애플리케이션의 AWS Elastic Beanstalk 관리 페이지에서 X-Ray 데몬을 활성화합니다. X-Ray 콘솔에서 트레이스 데이터를 봅니다.
      
      설명: AWS X-Ray란 무엇인가요?
      AWS X-Ray는 애플리케이션이 처리하는 요청에 대한 데이터를 수집하는 서비스이며, 해당 데이터를 보고, 필터링하고, 통찰을 얻어 문제와 최적화 기회를 식별할 수 있는 도구를 제공합니다. 애플리케이션에 대한 모든 트레이스된 요청에서, 요청 및 응답뿐 아니라 애플리케이션이 다운스트림AWS 리소스, 마이크로서비스, 데이터베이스 및 웹 API에 대해 하는 호출에 대해서도 상세한 정보를 확인할 수 있습니다.
      
18. 정보 보안 정책에 따라 공개적으로 액세스할 수 있는 모든 시스템은 패치 릴리스 후 24시간 이내에 중요한 OS 보안 패치로 패치되어야 합니다. 모든 인스턴스에는 패치 그룹 키가 0으로 설정된 태그가 지정됩니다. 중요 심각도의 보안 패치에 대한 제로데이 지연이 포함된 Windows 및 RHEL(Red Hat Enterprise Linux)용 2개의 새로운 AWS Systems Manager 패치 기준이 자동 승인 규칙으로 생성되었습니다. 패치 그룹 0이 새 패치 기준선과 연결되었습니다.
    
    패치 규정 준수 및 보고를 자동화하는 두 단계는 무엇입니까? (두 가지를 선택하세요.)
    
    • AWS Systems Manager 유지 관리 기간을 생성하고 패치 그룹 0으로 대상을 추가합니다. 일일 일정으로 AWS-InstallWindowsUpdates 문서를 실행하는 작업을 추가합니다.
    • 일일 일정으로 AWS Systems Manager 유지 관리 기간을 생성하고 패치 그룹 0으로 대상을 추가합니다. 설치 작업으로 AWS-RunPatchBaseline 문서를 실행하는 작업을 추가합니다.
    • AWS Systems Manager State Manager 구성을 생성합니다. AWS-RunPatchBaseline 작업을 구성과 연결하고 패치 그룹 0에 대상을 추가합니다.
    • AWS Systems Manager 유지 관리 기간을 생성하고 패치 그룹 0으로 대상을 추가합니다. 일일 일정으로 AWS-ApplyPatchBaseline 문서를 실행하는 작업을 추가합니다.
    • AWS Systems Manager Run Command를 사용하여 AWS-ApplyPatchBaseline 문서를 패치 그룹 0으로 태그가 지정된 인스턴스와 연결합니다.
19. 보안 팀은 AWS Key Management Service(AWS KMS) 암호화를 활성화하기 위해 Amazon EC2 인스턴스에 연결된 모든 Amazon EBS 볼륨이 필요합니다. 암호화가 활성화되지 않은 경우 회사 정책에 따라 EBS 볼륨을 분리하고 삭제해야 합니다. DevOps 엔지니어는 암호화되지 않은 EBS 볼륨의 감지 및 삭제를 자동화해야 합니다.
    
    엔지니어는 최소한의 운영 노력으로 이를 달성하기 위해 어떤 방법을 사용해야 합니까?
    
    • EBS 볼륨이 생성될 때 AWS Lambda 함수를 호출하는 Amazon CloudWatch Events 규칙을 생성합니다. Lambda 함수는 암호화를 위해 EBS 볼륨을 확인합니다. 암호화가 활성화되지 않고 볼륨이 인스턴스에 연결된 경우 함수는 볼륨을 삭제합니다.
    • 리전의 모든 EBS 볼륨을 설명하고 암호화가 활성화되지 않은 EC2 인스턴스에 연결된 볼륨을 식별하는 AWS Lambda 함수를 생성합니다. 그런 다음 함수는 모든 비호환 볼륨을 삭제합니다. AWS Lambda 함수는 Amazon CloudWatch Events 예약 규칙에 의해 5분마다 호출됩니다.
    • 암호화되지 않고 연결된 EBS 볼륨을 확인하는 규칙을 AWS Config에서 생성합니다. AWS Config가 변경 알림을 보내는 Amazon SNS 주제에 대해 AWS Lambda 함수를 구독합니다. Lambda 함수는 변경 알림을 확인하고 규정을 준수하지 않는 모든 EBS 볼륨을 삭제합니다.
    • 볼륨을 설명하고 삭제할 수 있는 권한이 있는 IAM 역할로 EC2 인스턴스를 시작합니다. 5분마다 EC2 인스턴스에서 스크립트를 실행하여 모든 지역의 모든 EBS 볼륨을 설명하고 암호화를 활성화하지 않고 연결된 볼륨을 식별합니다. 그런 다음 스크립트는 해당 볼륨을 삭제합니다.
      
      설명: AWS Config >  AWS Config 규칙으로 리소스 평가
      AWS Config는 AWS 계정의 AWS 리소스 구성에 대한 자세한 보기를 제공합니다. 여기에는 리소스가 서로 관련되어 있는 방식과 과거에 리소스가 구성되었던 방식이 포함되므로 구성 및 관계가 시간 경과에 따라 어떻게 변경되는지 확인할 수 있습니다.
      
      AWS Config를 사용하여 AWS 리소스의 구성 설정을 평가합니다. 이상적인 구성 설정을 나타내는 AWS Config 규칙을 생성하여 이를 수행합니다. EC2 볼륨이 생성되면 AWS Config는 볼륨 암호화를 요구하는 규칙에 따라 볼륨을 평가할 수 있습니다. 볼륨이 암호화되지 않은 경우 AWS Config는 볼륨과 규칙을 비준수로 표시합니다. AWS Config는 계정 전체 요구 사항에 대한 모든 리소스를 확인할 수도 있습니다. 예를 들어 AWS Config는 계정의 EC2 볼륨 수가 원하는 총계 내에서 유지되는지 또는 계정이 로깅을 위해 AWS CloudTrail을 사용하는지 여부를 확인할 수 있습니다.
      
      서비스 연결 규칙은 계정에서 AWS Config 규칙을 생성하기 위해 다른 AWS 서비스를 지원하는 고유한 유형의 관리형 규칙입니다. 이러한 규칙은 사용자를 대신하여 다른 AWS 서비스를 호출하는 데 필요한 모든 권한을 포함하도록 사전 정의됩니다. 이러한 규칙은 AWS 서비스가 규정 준수 확인을 위해 AWS 계정에서 권장하는 표준과 유사합니다. 자세한 내용은 서비스 연결 AWS Config 규칙 단원을 참조하십시오 .
20. 회사에서 모바일 앱을 빌드하고 테스트하기 위한 CI/CD 파이프라인을 구현하려고 합니다. DevOps 엔지니어는 다음 요구 사항을 충족해야 합니다.
    
    – AWS CodePipeline을 사용하여 워크플로를 오케스트레이션합니다.
    – 실제 기기에서 애플리케이션을 테스트합니다.
    – 알림을 트리거합니다.
    – 다른 계정의 프로덕션 버킷에서 애플리케이션 바이너리를 준비합니다.
    – 응용 프로그램 바이너리를 공개적으로 액세스할 수 있도록 합니다.
    
    엔지니어가 요구 사항을 충족하기 위해 파이프라인에서 수행해야 하는 일련의 작업은 무엇입니까?
    • AWS CodeCommit을 코드 소스로 사용하고 AWS CodeDeploy를 사용하여 애플리케이션을 컴파일 및 패키징합니다. CodeDeploy를 사용하여 테스트를 위해 애플리케이션 바이너리를 AWS Lambda 함수에 배포합니다. AWS Lambda에서 타사 라이브러리를 사용하여 디바이스 플랫폼을 시뮬레이션합니다. Lambda 역할이 프로덕션 Amazon S3 버킷에 업로드하도록 허용합니다. 바이너리를 공개적으로 액세스할 수 있도록 합니다. Amazon SNS를 사용하여 알림을 트리거합니다.
    • GitHub를 코드 소스로 사용하고 AWS Lambda를 사용하여 애플리케이션을 컴파일하고 패키징합니다. 다른 Lambda 함수를 사용하여 단위 테스트를 실행하고 애플리케이션 바이너리를 개발 버킷에 전달합니다. 개발 버킷의 바이너리를 사용하고 테스트를 위해 개인 기기에 애플리케이션을 설치합니다. 승인 후 프로덕션 버킷에 바이너리를 전달합니다. Amazon SNS를 사용하여 알림을 트리거합니다.
    • Amazon S3 버킷을 코드 소스로 사용하고 AWS CodeBuild를 사용하여 애플리케이션을 컴파일하고 패키징합니다. 테스트를 위해 AWS CodeDeploy를 사용하여 애플리케이션 바이너리를 디바이스 팜에 배포합니다. 프로덕션 S3 버킷에 바이너리를 전달합니다. 프로덕션 S3 버킷에서 퍼블릭 읽기를 허용하려면 S3 버킷 정책을 사용하십시오. Amazon SNS와 함께 Amazon CloudWatch Events 규칙을 사용하여 알림을 트리거합니다.
    • AWS CodeCommit을 코드 소스로 사용하고 AWS CodeBuild를 사용하여 애플리케이션을 컴파일 및 패키징합니다. 테스트를 위해 애플리케이션 바이너리를 디바이스 팜에 업로드하는 AWS Lambda 함수를 호출합니다. 프로덕션 Amazon S3 버킷에 바이너리를 전달합니다. 프로덕션 S3 버킷에서 퍼블릭 읽기를 허용하려면 S3 버킷 정책을 사용하십시오. Amazon CloudWatch Events 규칙을 사용하여 알림을 트리거합니다.

설명: AWS Device Farm 란 무엇입니까?
AWS Device Farm은 사용자가 Amazon Web Services 에서 호스팅하는 실제 휴대폰 및 태블릿에서 Android, iOS 및 웹 앱을 테스트하고 상호 작용할 수 있는 앱 테스트 서비스입니다.
Device Farm을 사용하는 두 가지 주요 방법이 있습니다.

CodePipeline 테스트 단계에서 AWS Device Farm 사용
AWS CodePipeline을 사용하여 Device Farm에서 구성된 모바일 앱 테스트를 AWS 관리형 자동 릴리스 파이프라인에 통합할 수 있습니다. 요청 시, 일정에 따라 또는 지속적 통합 흐름의 일부로 테스트를 실행하도록 파이프라인을 구성할 수 있습니다.

• 다양한 테스트 프레임워크를 사용하여 앱을 자동으로 테스트합니다.
• 실시간으로 앱을 로드, 실행 및 상호 작용할 수 있는 장치에 대한 원격 액세스

정답

C B C B C D B C B B A B B A,B,C A D D B,C C D