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

 

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. 회사의 인기 있는 글로벌 웹 애플리케이션이 Auto Scaling 그룹을 사용하여 Application Load Balancer(ALB) 뒤에 있는 Amazon EC2 인스턴스에서 호스팅됩니다. 이 회사는 새로운 기능을 출시하고 웹 트래픽의 예측할 수 없는 급증을 예상합니다. 이 사이트에는 현재 많은 양의 미디어 콘텐츠가 포함되어 있으며 새로운 기능은 새로운 Amazon DynamoDB 테이블에 저장될 평가 및 댓글을 제출하는 기능을 추가합니다. DevOps 엔지니어는 증가된 트래픽 및 워크로드에 따라 웹 애플리케이션이 확장될 수 있도록 하는 임무를 맡고 있습니다.
   
   이 작업을 수행하는 단계 조합은 무엇입니까? (두 가지를 선택하세요.)
   
   • 웹 애플리케이션의 정적 및 동적 콘텐츠를 캐시하도록 Amazon CloudFront 배포를 구성합니다.
   • HTTP 캐시 헤더를 준수하여 Amazon ElastiCache의 콘텐츠를 캐시하도록 웹 애플리케이션의 ALB를 구성합니다.
   • Amazon SQS를 사용하여 새 평가 및 댓글을 비동기식으로 처리합니다.
   • 지연 시간을 줄이기 위해 DynamoDB 테이블을 DynamoDB Accelerator로 교체하여 평점과 설명을 저장합니다.
   • 정적 콘텐츠를 캐시하고 동적 요청을 웹 애플리케이션의 ALB 엔드포인트에 전달하도록 AWS Global Accelerator를 설정합니다.
     
     정리: 비동기 처리 시 부하가 분산됨.   캐시는 단위 처리속도를 높여서 부하를 줄여줌.
2. 애플리케이션은 Auto Scaling 그룹에서 실행되는 Amazon EC2 인스턴스에 배포됩니다. 부트스트래핑 프로세스 중에 인스턴스는 모니터링 시스템에 프라이빗 IP 주소를 등록합니다. 모니터링 시스템은 해당 IP 주소에 ping 요청을 보내고 인스턴스가 응답하지 않으면 경고를 보내 상태 확인을 자주 수행합니다.
   
   기존 배포 전략은 현재 EC2 인스턴스를 새 인스턴스로 대체합니다. DevOps 엔지니어는 배포 중에 모니터링 시스템이 잘못된 경보를 보내는 것을 발견하고 이러한 잘못된 경보를 중지하는 임무를 맡았습니다.
   
   현재 배포 방법에 영향을 주지 않고 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
   • Auto Scaling 그룹에 연결된 Amazon CloudWatch Events 대상, AWS Lambda 함수 및 수명 주기 후크를 정의합니다. Amazon SNS를 호출하여 수정을 위해 시스템 관리자 그룹에 메시지를 보내도록 CloudWatch Events를 구성합니다.
   • Auto Scaling 그룹에 연결된 AWS Lambda 함수 및 수명 주기 후크를 정의합니다. 인스턴스 종료 시 모니터링 시스템에서 프라이빗 IP 항목을 제거하는 Lambda 함수를 호출하도록 수명 주기 후크를 구성합니다.
   • Auto Scaling 그룹에 연결된 Amazon CloudWatch Events 대상, AWS Lambda 함수 및 수명 주기 후크를 정의합니다. 인스턴스 종료 시 모니터링 시스템에서 프라이빗 IP 항목을 제거하는 Lambda 함수를 호출하도록 CloudWatch 이벤트를 구성합니다.
   • Auto Scaling 그룹에서 인스턴스 종료가 발생할 때 스크립트를 실행할 AWS Lambda 함수를 정의합니다. 스크립트는 모니터링 시스템에서 개인 IP 항목을 제거합니다.
     
     정리: ASG는 필요한 작업을 수행하기 위해 Lambda를 트리거하기 위해 CloudWatch 이벤트가 필요합니다.
     
     
3. Application Load Balancer 뒤의 Amazon EC2 인스턴스에서 실행되는 애플리케이션은 AWS Elastic Beanstalk를 사용하여 배포됩니다. 최근 롤링 배포 중에 애플리케이션 상태 검사가 모든 인스턴스에 전달되었음에도 불구하고 사용자에게 애플리케이션 오류가 발생했습니다. 로그 분석은 오류가 동일한 로드 밸런서 뒤에 있는 서로 다른 두 버전의 애플리케이션에서 처리 중인 사용자 요청으로 인해 발생했음을 보여줍니다. 분석은 또한 응답이 이전 버전과 호환되지 않는 최근 변경 사항을 보여줍니다.
   
   이러한 문제를 해결하는 배포 방법은 무엇입니까?
   
   • 한꺼번에 방법을 사용하여 배포하도록 Elastic Beanstalk를 업데이트합니다.
   • 블루/그린 방법을 사용하여 배포하도록 Elastic Beanstalk를 업데이트합니다.
   • 변경할 수 없는 방법을 사용하여 배포하도록 Elastic Beanstalk를 업데이트합니다.
   • 추가 일괄 처리 방식으로 롤링을 사용하여 배포하도록 Elastic Beanstalk를 업데이트합니다.
4. DevOps 엔지니어는 Go에서 실행되는 미션 크리티컬 비즈니스 애플리케이션을 AWS로 옮기는 임무를 맡고 있습니다. 이 애플리케이션을 실행하는 개발 팀은 인력이 부족하여 팀이 애플리케이션 개발에 집중할 수 있는 솔루션이 필요합니다. 그들은 또한 블루/그린 배포를 활성화하고 A/B 테스트를 수행하기를 원합니다.
   
   이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
   
   • Amazon EC2 인스턴스에 애플리케이션을 배포하고 이 인스턴스의 AMI를 생성합니다. 이 AMI를 사용하여 Auto Scaling 그룹에서 사용되는 자동 조정 시작 구성을 생성합니다. Elastic Load Balancer를 사용하여 트래픽을 분산합니다. 애플리케이션이 변경되면 새 AMI가 생성되고 시작 구성을 대체합니다.
   • Amazon Lightsail을 사용하여 애플리케이션을 배포합니다. 애플리케이션을 압축 형식으로 Amazon S3 버킷에 저장합니다. 이 압축 버전을 사용하여 애플리케이션의 새 버전을 Lightsail에 배포합니다. Lightsail 배포 옵션을 사용하여 배포를 관리합니다.
   • AWS CodeDeploy와 함께 AWS CodePipeline을 사용하여 Amazon EC2 인스턴스 플릿에 애플리케이션을 배포합니다. Elastic Load Balancer를 사용하여 EC2 인스턴스에 트래픽을 분산합니다. 애플리케이션을 변경할 때 CodePipeline에 새 버전을 업로드하고 새 버전을 배포하도록 합니다.
   • AWS Elastic Beanstalk를 사용하여 애플리케이션을 호스팅합니다. 압축된 버전의 애플리케이션을 Amazon S3에 저장하고 해당 위치를 사용하여 Elastic Beanstalk를 사용하여 배포 옵션을 관리하는 애플리케이션의 새 버전을 배포합니다.
     
     설명:  Elastic Beanstalk를 사용한 블루/그린 배포
     AWS Elastic Beanstalk는 blue/green 및 a/b 테스트(카나리아)가 있으며 다른 것보다 오버헤드가 적습니다.
     
     Elastic beanstalk에 대한 A/B 테스트 생성
     Elastic Beanstalk를 사용하면 콘솔 또는 명령줄을 통해 Elastic Beanstalk 환경을 복제 환경과 분리하는 두 가지 버전의 애플리케이션을 빠르게 생성할 수 있습니다. 새로 복제된 환경은 Green 환경이 됩니다.
     
     그런 다음 가중 라우팅 라우팅 정책 기능과 함께 Amazons Route 53을 활용합니다. 이를 통해 단일 도메인 이름을 사용하고 정책 내에서 결정한 비율에 따라 Blue 환경과 Green 환경 간에 트래픽을 분할할 수 있습니다. 작게 시작하고 Green이 좋다면 100%로 갑니다.
     
     정리: A/B는 간을 보는 형태이군.
5. 전자상거래 회사는 다음 요구 사항을 충족하는 애플리케이션을 AWS에 배포하는 방법을 찾고 있습니다.
   – 간단하고 자동화된 애플리케이션 배포 프로세스가 있습니다.
   – 인스턴스의 절반 이상이 최종 사용자 요청을 수신하는 데 사용할 수 있도록 보장하면서 최소한의 배포 비용이 있습니다.
   – 애플리케이션이 실패하면 자동 복구 메커니즘이 영향을 받는 인스턴스를 대체합니다.
   
   이러한 요구 사항을 충족하는 배포 전략은 무엇입니까?
   • AWS Elastic Beanstalk 환경을 생성하고 Auto Scaling 및 Elastic Load Balancer를 사용하도록 구성합니다. 일괄 처리 크기가 50%인 롤링 배포를 사용합니다.
   • AWS OpsWorks 스택을 생성합니다. 롤링 배포를 배포 전략으로 사용하도록 애플리케이션 계층을 구성합니다. Elastic Load Balancing 계층을 추가합니다. 애플리케이션 계층에서 자동 복구를 활성화합니다.
   • Auto Scaling 및 Elastic Load Balancer와 함께 AWS CodeDeploy를 사용하십시오. CodeDeployDefault.HalfAtAtime 배포 전략을 사용합니다. Elastic Load Balancing 상태 확인을 활성화하여 애플리케이션의 상태를 보고하고 Auto Scaling 상태 확인을 ELB로 설정합니다.
   • Auto Scaling 및 Elastic Load Balancer와 함께 AWS CodeDeploy를 사용하십시오. 블루/그린 배포 전략을 사용합니다. Elastic Load Balancing 상태 확인을 활성화하여 애플리케이션의 상태를 보고하고 Auto Scaling 상태 확인을 ELB로 설정합니다.
     
     설명: CodeDeploy에서 배포 구성 작업
     배포 구성은 배포 중 CodeDeploy에서 사용하는 규칙과 성공 및 실패 조건 세트입니다. 
     CodeDeployDefault.HalfAtATime
     블루/그린 배포: 한 번에 대체 환경의 인스턴스 중 최대 절반으로 트래픽을 라우팅합니다. 인스턴스 중 절반 이상으로의 다시 라우팅에 성공
     
6. DevOps 엔지니어는 워크로드에 사용되는 Docker 컨테이너를 AWS로 마이그레이션하는 임무를 맡고 있습니다. 솔루션은 각 컨테이너를 업데이트하고 컨테이너 레지스트리에 체크인하여 변경 사항을 개발 및 테스트 환경에 자동으로 배포할 수 있어야 합니다. 컨테이너가 푸시되면 자동으로 배포되어야 합니다.
   
   이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
   
   • 컨테이너 이미지를 Amazon S3에 저장합니다. 멀티컨테이너 Docker 환경을 사용하여 AWS Elastic Beanstalk에서 컨테이너를 실행합니다. Amazon S3에서 새 버전이 감지되면 컨테이너를 재배포하도록 Elastic Beanstalk를 구성합니다.
   • 컨테이너 이미지를 AWS Artifact에 저장합니다. 새 컨테이너 버전이 생성되면 AWS CodePipeline을 사용하여 배포를 트리거합니다. AWS CodeDeploy를 사용하여 Amazon EKS에 새 컨테이너를 배포합니다.
   • 컨테이너 이미지를 Amazon ECR에 저장합니다. 새 컨테이너 버전이 생성되면 AWS CodePipeline을 사용하여 배포를 트리거합니다. AWS CodeDeploy를 사용하여 이미지를 AWS Fargate에 배포합니다.
   • 컨테이너 이미지를 Docker Hub에 저장합니다. Amazon EC2 인스턴스에 Docker를 설치하고 AWS CodePipeline 및 AWS CodeDeploy를 사용하여 새 컨테이너를 배포합니다.
     
     설명:  AWS Fargate
     AWS Fargate는 서버를 관리하지 않고도 애플리케이션 구축에 초점을 맞출 수 있도록 지원하는 종량제 서버리스 컴퓨팅 엔진입니다. Fargate는 가장 중요한 애플리케이션에 초점을 맞출 수 있도록 컴퓨팅 인프라의 수명 주기를 소유, 실행 및 관리할 필요성을 없애줍니다. 
     
     정리: 컨테이너를 푸시할 수 있는 저장소 ECR이 필요.
7. 개발 팀은 AWS CloudFormation 스택을 사용하여 애플리케이션을 배포하려고 하지만 개발자 IAM 역할에는 현재 CloudFormation 템플릿에 지정된 리소스를 프로비저닝하는 데 필요한 권한이 없습니다. DevOps 엔지니어는 개발자가 최소 권한 원칙을 준수하면서 스택을 배포할 수 있도록 하는 임무를 맡고 있습니다.
   
   이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
   
   • 개발자가 필요한 리소스를 프로비저닝할 수 있도록 허용하는 IAM 정책을 만듭니다. 개발자 역할에 정책을 연결합니다.
   • CloudFormation에 대한 전체 액세스를 허용하는 IAM 정책을 생성합니다. 개발자 역할에 정책을 연결합니다.
   • 필요한 권한이 있는 AWS CloudFormation 서비스 역할을 생성합니다. 개발자 IAM 역할에 cloudformation:* 작업을 부여합니다. 스택 배포 중에 새 서비스 역할을 사용합니다.
   • 필요한 권한이 있는 AWS CloudFormation 서비스 역할을 생성합니다. 개발자 IAM 역할에 iam:PassRole 권한을 부여합니다. 스택 배포 중에 새 서비스 역할을 사용합니다.
     
     설명: 사용자에게 AWS 서비스에 역할을 전달할 권한 부여
     다수의 AWS 서비스를 구성하려면 IAM 역할을 서비스에 전달해야 합니다. 그러면 서비스가 나중에 역할을 수임하고 사용자 대신 작업을 수행할 수 있습니다. IAM 정책을 역할에 연결하여 인스턴스에서 실행 중인 애플리케이션에 대한 권한을 정의합니다. 애플리케이션은 역할이 허용하는 작업을 수행해야 할 때마다 역할을 수임합니다. 사용자가 AWS 서비스에 역할을 전달하도록 하려면 해당 사용자의 IAM 사용자, 역할 또는 그룹에 PassRole 권한을 부여해야 합니다.
     
     
8. 회사에서 SSH 액세스에 Amazon EC2 키 페어 사용을 중단하고 대신 AWS Systems Manager Session Manager를 사용할 계획입니다. 보안을 더욱 강화하려면 Session Manager에 대한 액세스는 사설 네트워크를 통해서만 이루어져야 합니다.
   
   어떤 작업 조합이 이를 달성합니까? (두 가지를 선택하세요.)
   
   • VPC CIDR 범위에서 연결된 모든 EC2 보안 그룹의 TCP 포트 22에 대한 인바운드 액세스를 허용합니다.
   • 필요한 시스템 관리자 권한이 있는 IAM 정책을 기존 IAM 인스턴스 프로필에 연결합니다.
   • 원하는 리전에 Systems Manager용 VPC 엔드포인트를 생성합니다.
   • 나머지 EC2 인스턴스 플릿에 배스천 호스트 역할을 할 새 EC2 인스턴스를 배포합니다.
   • 연결된 라우팅 테이블에서 기본 경로를 제거합니다.
     
     설명: Systems Manager를 사용하여 인터넷 액세스 없이 프라이빗 EC2 인스턴스를 관리할 수 있도록 VPC 엔드포인트를 생성하려면 어떻게 해야 합니까? 
     - EC2 인스턴스에 IAM 역할을 연결합니다.
      - Systems Manager를 위한 Virtual Private Cloud(VPC) 엔드포인트를 생성합니다.
9. 한 회사가 최근 예상보다 인기 있는 애플리케이션을 출시했습니다. 회사는 애플리케이션이 증가하는 요구 사항을 충족하고 여러 가용 영역(AZ)을 사용하여 안정성을 제공하도록 확장할 수 있는지 확인하려고 합니다. 애플리케이션은 ALB(Application Load Balancer) 뒤의 Amazon EC2 인스턴스 플릿에서 실행됩니다. DevOps 엔지니어는 애플리케이션의 여러 AZ에 걸쳐 Auto Scaling 그룹을 생성했습니다. 새로 추가된 AZ에서 시작된 인스턴스는 애플리케이션에 대한 트래픽을 수신하지 않습니다.
   
   이 문제의 원인은 무엇입니까?
   
   • Auto Scaling 그룹은 단일 AZ에서만 새 인스턴스를 생성할 수 있습니다.
   • EC2 인스턴스는 ALB에 수동으로 연결되지 않았습니다.
   • ALB는 NLB(Network Load Balancer)로 교체해야 합니다.
   • 새 AZ가 ALB에 추가되지 않았습니다.
10. DevOps 엔지니어는 다음 단계에 따라 AWS CodePipeline을 사용하여 웹 서비스 배포를 자동화했습니다.
    1. AWS CodeBuild 프로젝트는 배포 아티팩트를 컴파일하고 단위 테스트를 실행합니다.
    2. AWS CodeDeploy 배포 그룹은 스테이징 환경의 Amazon EC2 인스턴스에 웹 서비스를 배포합니다.
    3. CodeDeploy 배포 그룹은 프로덕션 환경의 EC2 인스턴스에 웹 서비스를 배포합니다.
    
    품질 보증(QA) 팀은 프로덕션 환경에 배포하기 전에 빌드 아티팩트를 검사할 수 있는 권한을 요청합니다. QA 팀은 내부 침투 테스트 도구를 실행하여 수동 테스트를 수행하려고 합니다. 이 도구는 REST API 호출에 의해 호출됩니다.
    
    이 요청을 이행하기 위해 DevOps 엔지니어가 취해야 하는 조치 조합은 무엇입니까? (두 가지를 선택하세요.)
    
    • 파이프라인의 테스트 작업과 배포 작업 사이에 수동 승인 작업을 삽입합니다.
    • 완료 전에 수동 승인이 필요하도록 컴파일 단계에 대한 buildspec.yml 파일을 수정합니다.
    • 진행하려면 수동 승인이 필요하도록 CodeDeploy 배포 그룹을 업데이트합니다.
    • 침투 테스트 도구에 대해 REST API를 직접 호출하도록 파이프라인을 업데이트합니다.
    • 침투 테스트 도구에 대해 REST API를 호출하는 Lambda 함수를 호출하도록 파이프라인을 업데이트합니다.
      
      설명: CodeDeploy sample for CodeBuild
      수동 승인에 대한 codebuild 또는 codedeploy 수정에 대한 내용을 찾지 못하므로 codepipeline입니다.
      
      
11. 개발 팀은 로컬에서 수동으로 아티팩트를 빌드한 다음 Amazon S3 버킷에 배치합니다. 애플리케이션에는 배포가 발생할 때 지워야 하는 로컬 캐시가 있습니다. 팀은 이를 수행하기 위한 명령을 실행하고 Amazon S3에서 아티팩트를 다운로드하고 아티팩트의 압축을 풀어 배포를 완료합니다.
    
    DevOps 팀은 CI/CD 프로세스로 마이그레이션하고 장애 발생 시 배포를 중지하고 롤백하기 위한 검사를 구축하려고 합니다. 이를 위해서는 팀이 배포 진행 상황을 추적해야 합니다.
    
    어떤 작업 조합이 이를 달성합니까? (3개를 선택하세요.)
    • 개발자가 코드를 코드 리포지토리에 체크인할 수 있습니다. Amazon CloudWatch Events를 사용하여 마스터로 가져올 때마다 AWS Lambda 함수를 트리거하여 아티팩트를 빌드하고 Amazon S3에 저장합니다.
    • 캐시를 지우는 사용자 지정 스크립트를 만듭니다. AppSpec file의 BeforeInstall 수명 주기 후크에서 스크립트를 지정합니다.
    • 캐시 지우기 스크립트가 포함된 각 Amazon EC2 인스턴스에 대한 사용자 데이터를 생성합니다. 배포되면 애플리케이션을 테스트합니다. 성공하지 못한 경우 다시 배포하십시오.
    • 애플리케이션을 배포하도록 AWS CodePipeline을 설정합니다. 개발자가 코드를 파이프라인의 소스로 코드 리포지토리에 체크인할 수 있습니다.
    • AWS CodeBuild를 사용하여 아티팩트를 빌드하고 Amazon S3에 배치합니다. AWS CodeDeploy를 사용하여 아티팩트를 Amazon EC2 인스턴스에 배포합니다.
    • AWS Systems Manager를 사용하여 Amazon S3에서 아티팩트를 가져와 모든 인스턴스에 배포합니다.
      
      설명: AWS CodeDeploy > AppSpec 'hooks' 섹션 > Amazon ECS 배포를 위한 수명 주기 이벤트 후크 목록
      BeforeInstall – 대체 작업 세트가 생성되기 전에 작업을 실행하려면 이 항목을 사용합니다. 대상 그룹 하나가 원래 작업 세트와 연결됩니다. 테스트 리스너(선택 사항)가 지정된 경우 원래 작업 세트와 연결됩니다. 이 시점에서는 롤백이 불가능합니다.
      
      
12. 한 법률 회사가 AWS에서 웹 애플리케이션을 실행하고 있습니다. 시스템은 사용자가 업로드한 법률 문서를 관리하고 Amazon S3에 문서를 저장합니다. 사용자는 파일 업로드가 너무 오래 걸리고 최대 사용량 동안 시간 초과가 발생한다고 불평했습니다. DevOps 엔지니어는 웹 서버가 동시 업로드를 관리하고 과부하 상태임을 발견했습니다.
    
    가장 비용 효율적인 방식으로 문제를 해결하려면 어떤 조치를 취해야 합니까?
    
    • 웹 서버 앞에 AWS CloudFront 배포를 만들고 S3 Transfer Acceleration을 사용하여 Amazon S3에 업로드하도록 애플리케이션을 수정합니다.
    • 브라우저가 서명된 URL을 사용하여 멀티파트 업로드를 통해 Amazon S3에 직접 업로드하도록 애플리케이션을 수정합니다.
    • 웹 서버 앞에 AWS CloudFront 배포를 생성하고 최대 I/O 성능 모드에서 Amazon EFS에 파일을 저장하도록 애플리케이션을 수정합니다.
    • 웹 서버를 Amazon EC2 Auto Scaling 그룹에 배치하여 스팟 인스턴스를 포함하고 멀티파트 업로드를 사용하여 Amazon S3에 업로드하도록 애플리케이션을 수정합니다.
      
      설명:  AWS S3 > S3 Transfer Acceleration이란 무엇인가요?
      Amazon S3 Transfer Acceleration은 거리가 먼 클라이언트와 Amazon S3 버킷 간에 파일을 빠르고, 쉽고, 안전하게 전송할 수 있게 합니다. S3 Transfer Acceleration은 전 세계적으로 분산된 Amazon CloudFront의 AWS 엣지 로케이션을 활용합니다. 데이터가 AWS 엣지 로케이션에 도착하면, 이 데이터는 최적화된 네트워크 경로를 통해 Amazon S3 버킷으로 라우팅됩니다.
      
      버킷에서 Transfer Acceleration을 사용하는 이유는 다음과 같이 다양합니다.
       - 전 세계 각지에서 중앙의 버킷으로 업로드하는 고객이 있는 경우
       - 전 세계에 정기적으로 수 기가바이트에서 수 테라바이트의 데이터를 전송할 경우
       - Amazon S3에 업로드할 때 인터넷을 통해 사용 가능한 대역폭을 충분히 활용할 수 없는 경우
13. 한 전자상거래 회사가 AWS에서 애플리케이션을 실행하고 있습니다. 회사는 현재 애플리케이션 코드를 유지하는 추가 지역에 대기 재해 복구 솔루션을 생성하려고 합니다. 애플리케이션은 ALB(Application Load Balancer) 뒤의 Amazon EC2 인스턴스에서 실행됩니다. 인스턴스는 여러 가용 영역에 걸쳐 EC2 Auto Scaling 그룹에서 실행됩니다. 데이터베이스 계층은 Amazon RDS MySQL 다중 AZ DB 인스턴스에서 호스팅됩니다. Amazon Route 53 DNS 레코드는 ALB를 가리킵니다.
    
    최저 비용으로 이러한 요구 사항을 충족하는 작업 조합은 무엇입니까? (3개를 선택하세요.)
    
    • 애플리케이션 DNS 항목에 대한 장애 조치 라우팅 정책을 구성합니다.
    • 애플리케이션 DNS 항목에 대한 지리적 위치 라우팅 정책을 구성합니다.
    • 새 대기 리전에서 리전 간 RDS 읽기 전용 복제본을 생성합니다.
    • 데이터베이스 계층을 Amazon DynamoDB로 마이그레이션하고 새로운 대기 리전으로 전역 복제를 활성화합니다.
    • 새 대기 리전에서 ALB 및 Auto Scaling 그룹을 프로비저닝하고 활성 리전과 일치하도록 원하는 용량을 설정합니다.
    • 새 대기 리전에서 ALB 및 Auto Scaling 그룹을 프로비저닝하고 원하는 용량을 1로 설정합니다.
      
      설명: Amazon Route 53 > 장애 조치 라우팅
      장애 조치 라우팅은 특정 리소스가 정상일 경우 해당 리소스로 트래픽을 라우팅하고 첫 번째 리소스가 비정상일 경우 다른 리소스로 트래픽을 라우팅합니다. 기본 및 보조 레코드는 웹 사이트로 구성되는 Amazon S3 버킷에서 복잡한 레코드 트리에 이르기까지 그 어느 것에도 트래픽을 라우팅할 수 있습니다. 
      
      액티브-패시브 장애 조치 
      기본 리소스가 사용 불가능할 경우를 대비해 대기 중인 보조 리소스에  장애 조치 구성한다. 쿼리에 응답할 때 Route 53는 정상적인 기본 리소스만을 포함합니다. 모든 기본 리소스가 비정상인 경우 Route 53는 DNS 쿼리에 응답할 때 정상적인 보조 리소스만을 포함시키기 시작합니다.
      
      AWS RDS > 다른 AWS 리전에서 읽기 전용 복제본 생성
      Amazon RDS를 사용하면 소스 DB 인스턴스와 다른 AWS 리전에서 읽기 전용 복제본을 생성할 수 있습니다.
      
      
14. DevOps 엔지니어가 Amazon ECS 서비스용 CI/CD 파이프라인을 생성하고 있습니다. ECS 컨테이너 인스턴스는 Application Load Balancer 뒤에서 3계층 애플리케이션의 웹 계층으로 실행됩니다. 성공적인 배포를 위한 승인 기준은 웹 계층이 배포 시 응용 프로그램의 데이터베이스 및 미들웨어 계층과 통신할 수 있는지 확인하는 것입니다.
    
    이것이 자동화된 방식으로 어떻게 달성될 수 있습니까?
    
    • 데이터 및 미들웨어 계층에 대한 연결을 테스트하는 웹 애플리케이션에서 상태 검사 엔드포인트를 생성합니다. 이 엔드포인트를 로드 밸런서의 상태 확인 URL로 사용하십시오.
    • 품질 보증 팀이 연결을 검증할 수 있도록 승인 단계를 만듭니다. 종속 계층에 연결하는 데 문제가 있는 경우 파이프라인의 변경 사항을 거부합니다.
    • Amazon RDS 활성 연결 수와 Amazon CloudWatch ELB 지표를 사용하여 열려 있는 연결 수의 중요한 변화에 대한 경보를 울립니다.
    • Amazon Route 53 상태 확인을 사용하여 웹 서비스의 문제를 감지하고 오류가 있는 경우 CI/CD 파이프라인을 롤백하십시오.
      
      설명: Elastic Load Balancing >대상 그룹에 대한 상태 확인 >  대상의 상태 확인
      대상 그룹에 등록된 대상의 상태를 확인할 수 있습니다. 상태 확인이 UnhealthyThresholdCount 연속 실패를 초과하면 로드 밸런서는 대상을 서비스에서 제외합니다. 상태 확인이 HealthyThresholdCount 연속 성공을 초과하면 로드 밸런서는 대상을 다시 서비스합니다.
      
      
15. DevOps 팀은 AWS를 사용하여 컨테이너화된 애플리케이션을 구현하려고 합니다. 배포는 다음 요구 사항을 충족해야 합니다.
    – 배포하는 동안 다운타임이 최소화되어야 합니다.
    – 성공으로 간주되려면 애플리케이션이 기능적으로 테스트되어야 합니다.
    
    DevOps 팀은 이 배포를 어떻게 자동화할 수 있습니까?
    • 다중 Docker 컨테이너 솔루션 스택과 함께 AWS Elastic Beanstalk를 사용합니다. 배포 전략으로 변경할 수 없는 업데이트를 선택합니다. Elastic Beanstalk 환경에서 모니터링 유형으로 향상된 상태를 선택하여 배포 시 상태 확인이 전송되도록 합니다.
    • Application Load Balancer 및 AWS CodeDeploy 블루/그린 배포 유형과 함께 Amazon ECS 클러스터 및 서비스를 사용합니다. Amazon ECS에서 프로덕션 포트와 테스트 포트를 정의합니다. 애플리케이션을 테스트하는 AWS Lambda 함수를 작성하고 appspec.yml의 AfterAllowTestTraffic 후크 내에서 이를 참조합니다.
    • AWS CloudFormation을 사용하여 Application Load Balancer 뒤에 Amazon EC2 인스턴스를 프로비저닝합니다. Amazon ECS를 사용하여 컨테이너를 배포합니다. 배포 시 새 EC2 인스턴스에 구성을 복제하고, 테스트를 수행하고, Amazon Route 53을 사용하여 이전 Application Load Balancer에서 새 애플리케이션 로드 밸런서로 트래픽을 전환합니다.
    • Amazon EC2 인스턴스 및 Application Load Balancer와 함께 Amazon ECS 클러스터 및 서비스를 사용합니다. 롤링 업데이트를 배포 전략으로 선택합니다. 상태 확인이 실패할 경우 롤백을 보장하기 위해 작업 정의 내에 Docker 상태 확인을 추가합니다.
      
      설명: AWS CodeDeploy > AppSpec 'hooks' 섹션 > Amazon ECS 배포를 위한 수명 주기 이벤트 후크 목록
      AfterAllowTestTraffic – 테스트 리스너가 대체 작업 세트에 트래픽을 제공한 후 작업을 실행하려면 이 항목을 사용합니다. 이 시점에서 후크 함수의 결과는 롤백을 트리거할 수 있습니다.
      
      CodeDeploy를 사용한 블루/그린 배포
      블루/그린 배포 유형은 CodeDeploy로 제어되는 블루/그린 배포 모델을 사용합니다. 이 배포 유형을 사용하면 프로덕션 트래픽을 전송하기 전에 서비스의 새로운 배포를 확인할 수 있습니다. 자세한 정보는 AWS CodeDeploy 사용 설명서의 CodeDeploy란 무엇인가요?를 참조하세요.
      
      블루/그린 배포 중 트래픽을 이동할 수 있는 방법은 3가지가 있습니다.
       - Canary — 트래픽이 2증분씩 이동합니다. 나머지 트래픽이 두 번째 증분으로 이동하기 전에 첫 번째 증분에서 업데이트된 작업 세트로 이동할 트래픽 비율(%)과 간격(분)을 지정하는 사전 정의된 Canary 옵션 중에서 선택할 수 있습니다.
       - Linear — 트래픽이 동일한 증분으로 이동하며 각 증분 간에 시간(분)이 동일합니다. 각 증분에서 이동되는 트래픽 비율(%)과 각 증분 간의 시간(분)을 지정하는 사전 정의된 Linear 옵션에서 선택할 수 있습니다.
       - All-at-once — 모든 트래픽이 원래 작업 세트에서 업데이트된 작업 세트로 한 번에 이동합니다.
      
      
16. 한 회사에서 다양한 워크로드에 Amazon EC2를 사용하고 있습니다. 회사 정책에 따라 구성을 표준화하기 위해 인스턴스를 중앙에서 관리해야 합니다. 이러한 구성에는 표준 로깅, 메트릭, 보안 평가 및 주간 패치가 포함됩니다.
    
    회사는 이러한 요구 사항을 어떻게 충족할 수 있습니까? (3개를 선택하세요.)
    
    • AWS Config를 사용하여 모든 EC2 인스턴스가 Amazon Inspector에서 관리되도록 합니다.
    • AWS Config를 사용하여 모든 EC2 인스턴스가 AWS Systems Manager에서 관리되도록 합니다.
    • AWS Systems Manager를 사용하여 모든 인스턴스에서 Amazon Inspector, Systems Manager Patch Manager 및 Amazon CloudWatch 에이전트를 설치하고 관리하십시오.
    • Amazon Inspector를 사용하여 모든 인스턴스에서 AWS Systems Manager, Systems Manager Patch Manager 및 Amazon CloudWatch 에이전트를 설치하고 관리하십시오.
    • Systems Manager Run Command와 함께 AWS Systems Manager 유지 관리 기간을 사용하여 Systems Manager Patch Manager 작업을 예약합니다. Amazon CloudWatch 에이전트를 사용하여 Amazon Inspector 평가 실행을 예약합니다.
    • Systems Manager Run Command와 함께 AWS Systems Manager 유지 관리 기간을 사용하여 Systems Manager Patch Manager 작업을 예약합니다. Amazon CloudWatch Events를 사용하여 Amazon Inspector 평가 실행을 예약합니다.
      
      정리: AWS Config ->
                  ->AWS Systems Manager
                       -> Amazon Inspector, Systems Manager Patch Manager,Amazon CloudWatch 에이전트
      실행은 Amazon CloudWatch Events ->  Amazon Inspector 
17. 한 회사에서 ALB(Application Load Balancer) 뒤의 Amazon EC2 인스턴스에서 실행되는 웹 서비스를 구축했습니다. 회사는 us-east-1에 애플리케이션을 배포했습니다. Amazon Route 53은 example.com에서 적절한 상태 확인으로 생성된 애플리케이션으로 트래픽을 라우팅하는 외부 DNS를 제공합니다.
    
    회사는 애플리케이션을 위한 두 번째 환경을 eu-west-1에 배포했습니다. 회사는 트래픽이 각 사용자에게 최상의 응답 시간을 제공하는 환경으로 라우팅되기를 원합니다. 한 리전에서 중단이 발생하면 트래픽이 다른 환경으로 전달되어야 합니다.
    
    이러한 요구 사항을 충족하는 구성은 무엇입니까?
    • – 가중치 라우팅이 있는 하위 도메인 us.example.com: 가중치가 2인 US ALB 및 가중치가 1인 EU ALB.
      – 가중치가 적용된 라우팅이 있는 또 다른 하위 도메인 eu.example.com: 가중치가 2인 EU ALB 및 가중치가 있는 US ALB 1.
      – example.com에 대한 지리적 위치 라우팅 레코드: us.example.com으로 별칭이 지정된 북미 및 eu.example.com으로 별칭이 지정된 유럽.
    • – 대기 시간 기반 라우팅이 있는 하위 도메인 us.example.com: US ALB를 첫 번째 대상으로, EU ALB를 두 번째 대상으로 합니다.
      – 대기 시간 기반 라우팅을 사용하는 또 다른 하위 도메인 eu.example.com: EU ALB를 첫 번째 대상으로, US ALB를 두 번째 대상으로 합니다.
      – 첫 번째 대상으로 us.example.com으로, 두 번째 대상으로 eu.example.com으로 별칭이 지정된 example.com의 장애 조치 라우팅 레코드.
    • – 장애 조치 라우팅이 있는 하위 도메인 us.example.com: US ALB가 기본이고 EU ALB가 보조입니다.
      – 장애 조치 라우팅이 있는 또 다른 하위 도메인 eu.example.com: EU ALB를 기본으로, US ALB를 보조로 사용합니다.
      – us.example.com 및 eu.example.com으로 별칭이 지정된 example.com의 지연 시간 기반 라우팅 레코드.
    • – 다중값 응답 라우팅이 있는 하위 도메인 us.example.com: US ALB가 먼저이고 EU ALB가 두 번째입니다.
      – 다중값 응답 라우팅이 있는 또 다른 하위 도메인 eu.example.com: EU ALB가 먼저이고 US ALB가 두 번째입니다.
      – us.example.com 및 eu.example.com으로 별칭이 지정된 example.com의 장애 조치 라우팅 레코드.
      
      설명: Amazon Route 53 > Amazon Route 53에서 지연 시간 기반 라우팅으로 전환
      Amazon Route 53은 지연 시간 기반 라우팅을 통해 사용자를 지연 시간이 가장 짧은 AWS 엔드포인트로 보냅니다. 
      
18. 회사는 Amazon EBS 스토리지로 지원되는 Amazon EC2 인스턴스를 사용하여 스테이징 웹 사이트를 호스팅합니다. 이 회사는 EC2 인스턴스에서 네트워크 연결 문제 또는 정전이 발생할 경우 최소한의 데이터 손실로 신속하게 복구하기를 원합니다.
    
    이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
    
    • 최소, 최대 및 원하는 용량이 1로 설정된 EC2 Auto Scaling 그룹에 인스턴스를 추가합니다.
    • 수명 주기 후크가 있는 EC2 Auto Scaling 그룹에 인스턴스를 추가하여 EC2 인스턴스가 종료되거나 종료될 때 EBS 볼륨을 분리합니다.
    • StatusCheckFailed_System 지표에 대한 Amazon CloudWatch 경보를 생성하고 EC2 작업을 선택하여 인스턴스를 복구합니다.
    • StatusCheckFailed_Instance 지표에 대한 Amazon CloudWatch 경보를 생성하고 EC2 작업을 선택하여 인스턴스를 재부팅합니다.
      
      설명: Amazon CloudWatch > Amazon CloudWatch 경보에 복구 작업 추가하기
      Amazon EC2 인스턴스를 모니터링하고 기본 하드웨어 장애나 복구에 AWS 개입이 필요한 문제로 인해 인스턴스가 손상된 경우 인스턴스를 자동으로 복구하는 Amazon CloudWatch 경보를 생성할 수 있습니다. 
        StatusCheckFailed_System 경보가 트리거되고 복구 작업이 시작되면 경보를 생성하고 복구 작업을 연결했을 때 선택한 Amazon SNS 주제로 알림을 받게 됩니다. 인스턴스 복구 중에 인스턴스를 재부팅할 때 인스턴스가 마이그레이션되고 모든 인 메모리 데이터가 손실됩니다. 프로세스가 완료되면 해당 경보를 위해 구성해 둔 SNS 주제로 정보가 게시됩니다. 이 SNS 주제에 가입되어 있는 사람은 누구나 복구 시도 상태와 세부 지침이 포함된 이메일 알림을 받게 됩니다. 복구된 인스턴스에서 인스턴스를 재부팅하라는 메시지가 나타납니다.
      
        복구 작업은 StatusCheckFailed_Instance가 아닌 StatusCheckFailed_System을 통해서만 사용할 수 있습니다.
      
      시스템 상태 확인이 실패하게 되는 문제의 예를 들면 다음과 같습니다.
       - 네트워크 연결 끊김
       - 시스템 전원 중단
       - 물리적 호스트의 소프트웨어 문제 
       - 네트워크 연결성에 영향을 주는 물리적 호스트의 하드웨어 문제
19. 한 회사에 AWS에서 실행되는 레거시 애플리케이션이 있습니다. 애플리케이션은 한 번에 하나의 Amazon EC2 인스턴스에서만 실행할 수 있습니다. 애플리케이션 메타데이터는 Amazon S3에 저장되며 인스턴스를 다시 시작할 때 검색해야 합니다. 성능이 저하되면 인스턴스를 자동으로 다시 시작하거나 다시 시작해야 합니다.
    
    이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
    
    • Amazon CloudWatch 경보를 생성하여 EC2 인스턴스를 모니터링합니다. StatusCheckFailed 시스템 경보가 트리거되면 복구 작업을 사용하여 인스턴스를 중지하고 시작합니다. 백업 및 실행 중일 때 Amazon S3의 트리거를 사용하여 인스턴스에 메타데이터를 푸시합니다.
    • AWS OpsWorks의 자동 복구 기능을 사용하여 EC2 인스턴스를 중지하고 시작합니다. OpsWorks에서 수명 주기 이벤트를 사용하여 Amazon S3에서 데이터를 가져와 인스턴스에서 업데이트합니다.
    • 장애 발생 시 Amazon EC2의 자동 복구 기능을 사용하여 EC2 인스턴스를 자동으로 중지하고 시작합니다. 백업 및 실행 중일 때 Amazon S3의 트리거를 사용하여 인스턴스에 메타데이터를 푸시합니다.
    • AWS CloudFormation을 사용하여 EC2 리소스에 대한 사용자 데이터 속성을 포함하는 EC2 인스턴스를 생성합니다. 사용자 데이터에 명령을 추가하여 Amazon S3에서 애플리케이션 메타데이터를 검색합니다.
      
      설명: OpsWork > 자동 복구를 사용하여 실패한 인스턴스 대체
      
      모든 인스턴스에는 서비스와 정기적으로 통신하는AWS OpsWorks Stacks 에이전트가 있습니다. AWS OpsWorks Stacks는 해당 통신을 사용하여 인스턴스 상태를 모니터링합니다. 에이전트가 약 5분 이상 서비스와 통신하지 않는 경우, AWS OpsWorks Stacks는 인스턴스가 실패했다고 간주합니다. 자동 복구는 계층 수준에서 설정을 편집하여 자동 복구 설정을 변경할 수 있습니다.
      
      OpsWork > AWS OpsWorks Stacks 수명 주기 이벤트
      각 계층마다 5개 수명 주기 이벤트(Setup, Configure, Deploy, Undeploy, Shutdown)가 있으며, 각 이벤트에는 레시피 세트가 연결됩니다. 연결되는 레시피는 계층마다 다릅니다. 계층의 인스턴스에서 이벤트가 발생하면 AWS OpsWorks Stacks는 적절한 레시피 세트를 자동으로 실행합니다. 
      
      
20. 회사에서 레거시 애플리케이션을 AWS로 마이그레이션하고 AWS 서비스만 사용하는 배포 파이프라인을 개발하려고 합니다. DevOps 엔지니어는 리포지토리의 기록을 보존하면서 Git 리포지토리의 모든 애플리케이션 코드를 AWS CodeCommit으로 마이그레이션하고 있습니다. DevOps 엔지니어는 CodeCommit 내에서 모든 권한을 설정하고 로컬 컴퓨터에 Git 클라이언트 및 AWS CLI를 설치했으며 리포지토리를 마이그레이션할 준비가 되었습니다.
    
    어떤 조치가 뒤따를까요?
    
    • AWS CLI를 사용하여 CodeCommit 리포지토리를 생성합니다. AWS CLI를 사용하여 Git 리포지토리를 CodeCommit에 직접 복제합니다. 파일이 마이그레이션되었는지 확인하고 CodeCommit 리포지토리를 게시합니다.
    • AWS Management 콘솔을 사용하여 CodeCommit 리포지토리를 생성합니다. Git 및 CodeCommit 리포지토리를 모두 로컬 컴퓨터에 복제합니다. Git 리포지토리에서 로컬 컴퓨터의 CodeCommit 리포지토리로 파일을 복사합니다. CodeCommit 리포지토리를 커밋합니다. 파일이 마이그레이션되었는지 확인하고 CodeCommit 리포지토리를 공유합니다.
    • AWS Management 콘솔을 사용하여 CodeCommit 리포지토리를 생성합니다. 콘솔을 사용하여 Git 리포지토리를 CodeCommit 리포지토리로 복제합니다. 파일이 마이그레이션되었는지 확인하고 CodeCommit 리포지토리를 게시합니다.
    • AWS Management 콘솔 또는 AWS CLI를 사용하여 CodeCommit 리포지토리를 생성합니다. 미러 인수가 있는 Git 리포지토리를 로컬 컴퓨터에 복제하고 리포지토리를 CodeCommit에 푸시합니다. 파일이 마이그레이션되었는지 확인하고 CodeCommit 리포지토리를 공유합니다.

설명: CodeCommit > Git 리포지토리를 AWS CodeCommit으로 마이그레이션
기존 Git 리포지토리를 CodeCommit 리포지토리로 마이그레이션할 수 있습니다. 이 주제의 절차는 다른 Git 리포지토리에서 호스팅되는 프로젝트를 CodeCommit으로 마이그레이션하는 방법을 보여줍니다. 이 프로세스의 일부로 다음을 수행합니다.

 - CodeCommit에 필요한 초기 설정을 완료합니다.
- CodeCommit 리포지토리를 생성합니다.
- 리포지토리를 복제하고 CodeCommit에 푸시합니다.
- CodeCommit 리포지토리에서 파일을 봅니다.
- 팀과 CodeCommit 리포지토리를 공유합니다.

 

정답

1. A,C 2. C 3. A 4. D 5. C 6. C 7. D 8. B,C 9. D 10. A,E 11. B,D,E 12. A 13. A,C,F 14. A 15. B 16. B,C,F 17. C 18. C 19. B 20. D