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

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에 배포된 애플리케이션에 대한 CI/CD 파이프라인을 구현하려고 합니다. 또한 이 회사는 보안 결함을 확인하는 온프레미스에서 호스팅되는 소스 코드 분석 도구를 보유하고 있습니다. 이 도구는 아직 AWS로 마이그레이션되지 않았으며 온프레미스 서버에서만 액세스할 수 있습니다. 회사는 코드가 컴파일되기 전에 파이프라인의 일부로 소스 코드에 대한 검사를 실행하려고 합니다. 확인을 완료하는 데 몇 분에서 한 시간이 걸립니다.
   
   DevOps 엔지니어는 어떻게 이러한 요구 사항을 충족할 수 있습니까?
   
   • AWS CodePipeline을 사용하여 파이프라인을 생성합니다. 소스 단계 후에 AWS Lambda 함수를 호출하기 위해 파이프라인에 작업을 추가합니다. Lambda 함수가 CodePipeline의 소스 입력에 대해 온프레미스에서 소스 코드 분석 도구를 호출하도록 합니다. 그런 다음 함수는 실행이 완료될 때까지 기다렸다가 지정된 Amazon S3 위치에 출력을 배치합니다.
   • AWS CodePipeline을 사용하여 파이프라인을 만든 다음 사용자 지정 작업 유형을 만듭니다. 작업 요청에 대해 CodePipeline을 폴링하고 테스트를 시작하고 결과를 반환하는 온프레미스 서버용 작업자를 만듭니다. 소스 단계 후에 사용자 지정 작업을 호출하도록 파이프라인을 구성합니다.
   • AWS CodePipeline을 사용하여 파이프라인을 생성합니다. 소스 코드 분석 도구로 테스트를 호출하는 온프레미스 호스팅 웹 서비스에 대한 HTTPS 요청을 만들기 위해 소스 단계 뒤에 단계를 추가합니다. 분석이 완료되면 웹 서비스는 CodePipeline에서 제공하는 Amazon S3 출력 위치에 결과를 넣어 다시 결과를 보냅니다.
   • AWS CodePipeline을 사용하여 파이프라인을 생성합니다. 입력 소스 코드를 온프레미스 위치에 복사하는 셸 스크립트를 만듭니다. 소스 코드 분석 도구를 호출하고 결과를 CodePipeline에 반환합니다. 소스 단계 뒤에 사용자 지정 스크립트 작업을 추가하여 셸 스크립트를 호s출합니다.
     
     설명:  AWS CodePipeline란 무엇인가요?
     AWS CodePipeline은 소프트웨어 릴리스에 필요한 단계를 모델링, 시각화 및 자동화하는 데 사용할 수 있는 지속적 전달 서비스입니다. 소프트웨어 릴리스 프로세스의 다양한 단계를 신속하게 모델링하고 구성할 수 있습니다. CodePipeline 소프트웨어 변경 사항을 지속적으로 릴리스하는 데 필요한 단계를 자동화합니다. 
     파이프라인에 사용자 지정 작업 추가
     파이프라인에 단계의 일부로 사용자 지정 작업이 포함되어 있으면 파이프라인에서 작업 요청이 생성됩니다. 사용자 지정 작업자가 해당 요청을 감지하고 해당 작업을 수행합니다(이 예에서는 타사 빌드 소프트웨어를 사용하는 사용자 지정 프로세스). 작업이 완료되면 작업자가 성공 결과 또는 실패 결과를 반환합니다. 성공 결과가 수신된 경우 파이프라인은 개정 사항 및 아티팩트를 다음 작업에 제공합니다. 
2. 한 회사에서 Apache 웹 서버가 있는 Java-Apache Tomcat 애플리케이션의 애플리케이션 배포를 자동화하기 위해 AWS CodeDeploy를 채택하고 있습니다. 개발 팀은 개념 증명으로 시작하여 개발자 환경을 위한 배포 그룹을 만들고 애플리케이션 내에서 기능 테스트를 수행했습니다. 완료 후 팀은 스테이징 및 프로덕션을 위한 추가 배포 그룹을 생성합니다.
   
   현재 로그 수준은 Apache 설정 내에서 구성되지만 팀은 배포가 발생할 때 이 구성을 동적으로 변경하여 각 그룹에 대해 다른 애플리케이션 개정 없이 배포 그룹에 따라 다른 로그 수준 구성을 설정할 수 있기를 원합니다.
   
   각 배포 그룹에 대해 서로 다른 스크립트 버전을 요구하지 않고 최소한의 관리 오버헤드로 이러한 요구 사항을 어떻게 충족할 수 있습니까?
   • 배포 그룹에 따라 Amazon EC2 인스턴스에 태그를 지정합니다. 그런 다음 인스턴스가 속한 배포 그룹을 식별하기 위해 메타데이터 서비스 및 EC2 API를 호출하는 애플리케이션 개정에 스크립트를 배치합니다. 이 정보를 사용하여 로그 수준 설정을 구성합니다. appspec.yml 파일에서 Afterinstall 라이프사이클 후크의 일부로 스크립트를 참조하십시오.
   • 인스턴스가 속한 배포 그룹을 식별하기 위해 CodeDeploy 환경 변수 DEPLOYMENT_GROUP_NAME을 사용하는 스크립트를 생성합니다. 이 정보를 사용하여 로그 수준 설정을 구성합니다. appspec.yml 파일에서 BeforeInstall 라이프사이클 후크의 일부로 이 스크립트를 참조하십시오.
   • 각 환경에 대한 CodeDeploy 사용자 지정 환경 변수를 생성합니다. 그런 다음 이 환경 변수를 확인하는 스크립트를 애플리케이션 개정에 배치하여 인스턴스가 속한 배포 그룹을 식별합니다. 이 정보를 사용하여 로그 수준 설정을 구성합니다. appspec.yml 파일에서 ValidateService 수명 주기 후크의 일부로 이 스크립트를 참조하십시오.
   • 로그 수준 설정을 구성하기 위해 인스턴스가 속한 배포 그룹을 식별하기 위해 CodeDeploy 환경 변수 DEPLOYMENT_GROUP_ID를 사용하는 스크립트를 생성합니다. appspec.yml 파일에서 설치 수명 주기 후크의 일부로 이 스크립트를 참조하십시오.
     
     설명:  CodeDeploy의 LifeCycle Event Hook
     
     1. Start
        • lifecycle의 첫 번째 이벤트로, CodeDeploy 에이전트를 자동으로 실행하고 인스턴스 배포가 시작된다.
     2. ApplicationStop
        • 이전 프로그램을 중지하는 스크립트를 실행하는 단계이다.
        • 예를 들어 커머스 웹 어플리케이션을 운영하고 있는데 새 버전(v.1)을 배포할 경우 이 이벤트를 통해 구 버전(v.0)을 사용하지 않도록 설정하고 새 버전(v.1)을 수신하도록 인스턴스를 준비할 수 있다.
     3. DownloadBundle
        • 이 이벤트 동안 CodeDeploy에이전트는 새 버전을 인스턴스로 가져온다.(ex CodeBuild에서 패키징된 zip 파일)
     4. BeforeInstall
        • 이 이벤트를 통해 구버전의 설치 구성을 저장하고, 파일을 복호화하고, 현재 버전의 백업을 만들 수 있다.
     5. Install
        • DownloadBundle을 통해 가져온 Bundle의 압축을 해제하고 appspec.yml에 정의된대로 파일을 지정한 경로로 복사한다.
     6. AfterInstall
        • 이 이벤트를 통해 프로그램이 시작되기 전에 프로그램의 구성을 변경할 수 있다.
     7. ApplicationStart
        • 이름에서 알 수 있듯이 어플리케이션을 구 버전(v.0) 대신 새 버전(v.1)로 설정한다.
     8. ValidateService
        
        • 이 이벤트를 통해 배포가 성공했는지 확인할 수 있는 검증 로직을 실행할 수 있다.
     9. End
        • lifecycle의 마지막 이벤트로, 인스턴스의 배포 성공유무를 중앙 서비스에 알린다.
     
     CodeDeploy 후크의 환경 변수 가용성
     후크의 환경 변수 가용성: 각 배포 수명 주기 이벤트 동안 후크 스크립트는 다음 환경 변수에 액세스할 수 있습니다.
     DEPLOYMENT_GROUP_NAME: 현재 배포의 일부인 CodeDeploy의 배포 그룹 이름(예: WordPress_DepGroup)
     
     
3. 한 회사에 피크 트래픽 시간을 예측할 수 있는 애플리케이션이 있습니다. 회사는 사용량이 많은 시간에만 애플리케이션 인스턴스를 확장하기를 원합니다. 애플리케이션은 Amazon DynamoDB에 상태를 저장합니다. 애플리케이션 환경은 개인 Git 리포지토리에 저장된 표준 Node.js 애플리케이션 스택과 사용자 지정 Chef 레시피를 사용합니다.
   
   애플리케이션 환경의 롤링 업데이트를 수행할 때 가장 비용 효율적이고 최소한의 관리 오버헤드가 필요한 솔루션은 무엇입니까?
   
   • Chef 레시피를 사용하여 Node.js 환경 및 애플리케이션 스택으로 사용자 지정 AMI를 생성합니다. Auto Scaling 그룹에서 AMI를 사용하고 필요한 시간에 대해 예약된 조정을 설정한 다음 DynamoDB 액세스 권한을 제공하는 Amazon EC2 IAM 역할을 설정합니다.
   • 공식 Node.js Docker 이미지를 기반으로 애플리케이션 환경에 대한 Chef 레시피를 사용하는 Docker 파일을 생성합니다. 애플리케이션 환경을 위한 Amazon ECS 클러스터 및 서비스를 생성한 다음 이 Docker 이미지를 기반으로 작업을 생성합니다. 예약된 조정을 사용하여 적절한 시간에 컨테이너를 조정하고 DynamoDB에 액세스할 수 있는 권한을 제공하는 작업 수준 IAM 역할을 연결합니다.
   • AWS OpsWorks 스택을 구성하고 사용자 지정 Chef 쿡북을 사용합니다. 커스텀 레시피가 저장된 Git 리포지토리 정보를 추가하고 Node.js 애플리케이션 서버용 OpsWorks에 레이어를 추가합니다. 그런 다음 배포 단계에서 애플리케이션을 배포하도록 사용자 지정 레시피를 구성합니다. 시간 기반 인스턴스를 구성하고 DynamoDB 액세스 권한을 제공하는 Amazon EC2 IAM 역할을 연결합니다.
   • AWS OpsWorks 스택을 구성하고 사용자 지정 레시피를 Amazon S3 버킷으로 푸시하고 S3 버킷을 가리키도록 사용자 지정 레시피를 구성합니다. 그런 다음 표준 Node.js 애플리케이션 서버에 대한 애플리케이션 계층 유형을 추가하고 S3 버킷의 배포 단계에서 애플리케이션을 배포하도록 사용자 지정 레시피를 구성합니다. 시간 기반 인스턴스를 구성하고 DynamoDB 액세스 권한을 제공하는 Amazon EC2 IAM 역할을 연결합니다.
     
     설명: AWS OpsWorks이란 무엇입니까?
     AWS OpsWorks는 Puppet 또는 Chef를 사용하여 클라우드 엔터프라이즈에서 애플리케이션을 구성하고 운영하도록 지원하는 구성 관리 서비스입니다.
     
     시간 기반 인스턴스와 로드 기반 인스턴스를 사용한 로드 관리
     수신 트래픽이 변동함에 따라 스택의 인스턴스 수가 로드를 무리 없이 처리하기에는 너무 적거나 필요 이상으로 많을 수 있습니다. 시간 기반 또는 로드 기반 인스턴스를 사용하여 계층의 인스턴스 수를 자동으로 늘리거나 줄이면 불필요한 용량에 대한 비용을 지불할 필요 없이 수신 트래픽을 적절히 처리하는 데 충분한 인스턴스를 항상 유지하면서도 시간과 비용을 모두 절감할 수 있습니다.
4. 온라인 소매업체의 개발 팀은 비즈니스 지원으로 이동했으며 AWS Health Dashboard 및 AWS Health API를 활용하여 AWS 리소스 상태 문제에 대한 해결 조치를 자동화하려고 합니다. 첫 번째 사용 사례는 퍼블릭 코드 리포지토리 사이트에 나열된 IAM 액세스 키를 감지하는 AWS에 대응하는 것입니다. 자동 응답은 IAM 액세스 키를 삭제하고 보안 팀에 알림을 보내는 것입니다.
   
   이를 어떻게 달성해야 합니까?
   
   • IAM 액세스 키를 삭제하는 AWS Lambda 함수를 생성합니다. AWS CloudTrail 로그를 AWS CloudWatch 로그로 보냅니다. 두 가지 작업으로 AWS_RISK_CREDENTIALS_EXPOSED 이벤트에 대한 CloudWatch Logs 지표 필터를 생성합니다. 먼저 Lambda 함수를 실행합니다. 둘째, Amazon SNS를 사용하여 보안 팀에 알림을 보냅니다.
   • IAM 액세스 키를 삭제하는 AWS Lambda 함수를 생성합니다. 두 가지 작업으로 aws.health 및 AWS_RISK_CREDENTIALS_EXPOSED 이벤트의 변경 사항에 대한 AWS Config 규칙을 생성합니다. 먼저 Lambda 함수를 실행합니다. 둘째, Amazon SNS를 사용하여 보안 팀에 알림을 보냅니다.
   • AWS Step Functions를 사용하여 IAM 액세스 키를 삭제하는 함수를 만든 다음 Amazon SNS를 사용하여 보안 팀에 알림을 보냅니다. AWS_RISK_CREDENTIALS_EXPOSED 이벤트에 대한 AWS Personal Health Dashboard 규칙을 생성합니다. Personal Health Dashboard 규칙의 대상을 Step Functions로 설정합니다.
   • AWS Step Functions를 사용하여 IAM 액세스 키를 삭제하는 함수를 만든 다음 Amazon SNS를 사용하여 보안 팀에 알림을 보냅니다. aws.health 이벤트 소스 및 AWS_RISK_CREDENTIALS_EXPOSED 이벤트를 사용하여 Amazon CloudWatch Events 규칙을 생성합니다. CloudWatch 이벤트 규칙의 대상을 Step Functions로 설정합니다.
     
     
     설명:  AWS Health란 무엇입니까?
     AWS Health리소스 성능 및 가용성에 대한 지속적인 가시성을 제공합니다. AWS Health 행사서비스 및 리소스 변경이 실행 중인 애플리케이션에 어떤 영향을 미칠 수 있는지 알 수 있습니다. AWS Health 진행 중인 이벤트를 관리하는 데 도움이 되는 관련성 있고 시기적절한 정보를 제공합니다.
     
     AWS Health 대시보드
     AWS Health대시보드를 사용하면 특정 지역의 서비스에 대한 예정된 유지 관리 문제 등 일반적인 상황을 파악할 수 있는 이벤트를 확인할 수 있습니다.
     
     AWS Health API
     AWS 상태 API는 AWS 상태 대시보드 에 표시되는 AWS 상태 정보에 대한 액세스를 제공합니다.  API 작업을 사용하여 AWS 서비스 및 리소스에 영향을 줄 수 있는 이벤트에 대한 정보를 얻을 수 있습니다.
     
     AWS_RISK_CREDENTIALS_EXPOSED
      AWS Step Functions를 사용하여 AWS 상태 에서 생성된 Amazon CloudWatch Event 에 대한 응답으로 서버리스 AWS Lambda 워크플로를 오케스트레이션할 수 있다.
     
     
5. 보안 팀은 AWS CloudTrail을 사용하여 회사의 AWS 계정에서 민감한 보안 문제를 감지합니다. DevOps 엔지니어는 AWS 계정에서 꺼지는 CloudTrail을 자동으로 수정하는 솔루션이 필요합니다.
   
   CloudTrail 로그 전달에 대한 최소한의 다운타임을 보장하는 솔루션은 무엇입니까?
   
   • CloudTrail StopLogging 이벤트에 대한 Amazon CloudWatch Events 규칙을 생성합니다. AWS SDK를 사용하여 StopLogging이 호출된 리소스의 ARN에서 StartLogging을 호출하는 AWS Lambda 함수를 생성합니다. CloudWatch 이벤트 규칙에 대상으로 Lambda 함수 ARN을 추가합니다.
   • 1시간의 주기적 간격으로 설정된 AWS 관리형 CloudTrail 지원 AWS Config 규칙을 배포합니다. AWS Config 규칙 준수 변경에 대한 Amazon CloudWatch Events 규칙을 생성합니다. AWS SDK를 사용하여 StopLogging이 호출된 리소스의 ARN에서 StartLogging을 호출하는 AWS Lambda 함수를 생성합니다. CloudWatch 이벤트 규칙에 대상으로 Lambda 함수 ARN을 추가합니다.
   • 5분마다 예약된 이벤트에 대한 Amazon CloudWatch Events 규칙을 생성합니다. AWS SDK를 사용하여 AWS 계정의 CloudTrail 트레일에서 StartLogging을 호출하는 AWS Lambda 함수를 생성합니다. CloudWatch 이벤트 규칙에 대상으로 Lambda 함수 ARN을 추가합니다.
   • AWS SDK를 사용하여 현재 계정에서 CloudTrail을 쿼리하는 5분마다 실행되는 스크립트로 t2.nano 인스턴스를 시작합니다. CloudTrail 추적이 비활성화된 경우 스크립트가 추적을 다시 활성화하도록 합니다.
     
     설명:  Amazon 리소스 이름(ARN)
     Amazon 리소스 이름(ARN)은 AWS 리소스를 고유하게 식별합니다.
     예) arn:partition:service:region:account-id:resource-id
     
     CloudWatch Events로 특정 AWS API 모니터링하기
     AWS CloudTrail는 AWS 계정 내에서 수행된 작업들의 API 로그를 기록하고 저장해서 “누가”, “언제", “어떤" 작업을 했는지 확인하고 수집된 로그들을 토대로 보안 분석, 운영 감사, 규정 위반 감사, 비정상적 활동 탐지등을 손쉽게 할수 있는 서비스입니다.
       뿐만 아니라 CloudWatch Events와의 연동을 통해서 Trail에 저장되는 API 이벤트 로그를 실시간으로 탐지후 특정 API가 호출될 경우에 AWS SNS를 통해서 알람을 보낸다거나 AWS Lambda를 통해서 미리 짜여진 작업을 실행시킬수도 있습니다.
     
     
6. 보안 팀은 DevOps 엔지니어에게 AWS CloudTrail 파일이 생성된 후 변조되지 않도록 확인하라는 요청을 받았습니다. 현재 AWS IAM을 사용하여 특정 추적에 대한 액세스를 제한하는 여러 추적이 있는 프로세스가 있습니다. 보안 팀은 각 파일의 무결성을 추적하고 변조가 없었는지 확인하고자 합니다.
   
   보안 팀이 로그의 신뢰성을 증명할 수 있도록 하면서 파일의 적법성을 구현하고 보장하는 데 최소한의 노력이 필요한 옵션은 무엇입니까?
   
   • 새 파일이 전달될 때 AWS Lambda 함수를 트리거하는 Amazon CloudWatch Events 규칙을 생성합니다. 파일에서 MD5 해시 확인을 수행하고 파일의 이름과 위치를 저장하고 반환된 해시를 Amazon DynamoDB 테이블에 게시하도록 Lambda 함수를 구성합니다. 보안 팀은 DynamoDB에 저장된 값을 사용하여 파일 신뢰성을 확인할 수 있습니다.
   • Amazon S3 버킷에서 CloudTrail 파일 무결성 기능을 활성화합니다. 보안 팀에 S3 버킷에 저장된 파일 무결성 로그에 대한 액세스 권한을 부여하는 IAM 정책을 생성합니다.
   • 추적에서 CloudTrail 파일 무결성 기능을 활성화합니다. CloudTrail에서 생성한 다이제스트 파일을 사용하여 제공된 CloudTrail 파일의 무결성을 확인합니다.
   • 새 파일이 CloudTrail 버킷에 전달될 때마다 트리거되는 AWS Lambda 함수를 생성합니다. 파일에서 MD5 해시 확인을 실행하고 결과를 Amazon S3 객체의 태그에 저장하도록 Lambda 함수를 구성합니다. 보안 팀은 태그에 대한 정보를 사용하여 파일의 무결성을 확인할 수 있습니다.
     
     설명: CloudTrail 콘솔에서 로그 파일 무결성 검증을 활성화하려면 추적을 생성하거나 업데이트할 때 [로그 파일 검증 활성화(Enable log file validation)] 옵션에 대해 [예(Yes)]를 선택합니다. 기본적으로 이 기능은 새 추적에 대해 활성화됩니다. 자세한 내용은 콘솔을 사용하여 추적 생성 및 업데이트 단원을 참조하세요.
     
7. 한 회사에서 AWS Lambda 및 Amazon API Gateway로 구동되는 서버리스 아키텍처를 사용하는 웹 및 모바일 애플리케이션을 구축하고 있습니다. 이 회사는 AWS CodeCommit 리포지토리의 적절한 환경 브랜치로 푸시되는 코드를 기반으로 백엔드 Lambda 배포를 완전히 자동화하려고 합니다.
   
   배포에는 다음이 있어야 합니다.
   – 테스트 및 프로덕션을 위한 별도의 환경 파이프라인.
   – 테스트 환경에서만 발생하는 자동 배포.
   
   이러한 요구 사항을 충족하려면 어떤 조치를 취해야 합니까?
   
   • 새 AWS CodePipeline 서비스를 구성합니다. 각 환경에 대한 CodeCommit 리포지토리를 생성합니다. 적절한 리포지토리에서 소스 코드를 검색하도록 CodePipeline을 설정합니다. AWS CloudFormation을 사용하여 Lambda 함수를 배포하도록 배포 단계를 설정합니다.
   • 테스트 및 프로덕션 환경을 위한 2개의 AWS CodePipeline 구성을 생성합니다. 수동 승인 단계를 갖도록 프로덕션 파이프라인을 구성합니다. 각 환경에 대한 CodeCommit 리포지토리를 생성합니다. 적절한 리포지토리에서 소스 코드를 검색하도록 각 CodePipeline을 설정합니다. AWS CloudFormation을 사용하여 Lambda 함수를 배포하도록 배포 단계를 설정합니다.
   • 테스트 및 프로덕션 환경을 위한 2개의 AWS CodePipeline 구성을 생성합니다. 수동 승인 단계를 갖도록 프로덕션 파이프라인을 구성합니다. 각 환경에 대한 분기가 있는 하나의 CodeCommit 리포지토리를 생성합니다. 리포지토리의 해당 분기에서 소스 코드를 검색하도록 각 CodePipeline을 설정합니다. AWS CloudFormation을 사용하여 Lambda 함수를 배포하도록 배포 단계를 설정합니다.
   • 테스트 및 프로덕션 환경을 위한 AWS CodeBuild 구성을 생성합니다. 수동 승인 단계를 갖도록 프로덕션 파이프라인을 구성합니다. 각 환경에 대한 분기가 있는 하나의 CodeCommit 리포지토리를 생성합니다. Lambda 함수 코드를 Amazon S3 버킷으로 푸시합니다. S3 버킷에서 Lambda 함수를 배포하도록 배포 단계를 설정합니다.
     
     설명: AWS CodeCommit란 무엇입니까?
     AWS CodeCommit는 클라우드에서 자산 (예: 문서, 소스 코드, 바이너리 파일) 을 비공개로 저장하여 관리하는 데 사용할 수 있도록 Amazon Web Services Services에서 호스팅되는 버전 관리 서비스입니다.
     AWS CodeCommit 기능을 사용하는 방법. 먼저 리포지토리를 생성하고 몇 가지 변경 사항을 커밋합니다. 그런 다음 파일을 검색하고 변경 내용을 확인합니다. 다른 사용자에게 코드 변경 내용을 검토하고 의견을 제시할 수 있게 풀 요청을 생성할 수도 있습니다.
     
     DevOps 파이프라인 예시
     
     AWS CodePipeline 설명: 개발자가 소스 리포지토리에 대한 변경 사항을 커밋하면 CodePipeline이 자동으로 변경 사항을 감지합니다. 이러한 변경 사항이 빌드되고 테스트가 구성된 경우 해당 테스트가 실행됩니다. 테스트가 완료되면 빌드된 코드가 테스트를 위해 스테이징 서버에 배포됩니다. 스테이징 서버에서 CodePipeline은 통합 또는 로드 테스트와 같은 더 많은 테스트를 실행합니다. 해당 테스트가 성공적으로 완료되고 파이프라인에 추가된 수동 승인 작업이 승인된 후 CodePipeline은 테스트 및 승인된 코드를 프로덕션 인스턴스에 배포합니다. CodePipeline의 AWS CloudFormation 작업 파라미터에 대한 자세한 내용을 알아보려면 AWS CodePipeline 사용 설명서의 AWS CloudFormation 작업 구성 참조를 참조하세요.
     
     
8. 회사에서 애플리케이션에 AWS를 사용하고 있습니다. 개발 팀은 배포를 자동화해야 합니다. 팀은 AWS CodeBuild 서비스를 사용하여 빌드한 후 AWS CodeDeploy를 사용하여 애플리케이션을 Amazon EC2 인스턴스에 배포하도록 AWS CodePipeline을 설정했습니다.
   
   팀은 동일한 코드를 사용하여 파이프라인의 다음 단계에 애플리케이션을 배포하기 전에 애플리케이션이 정상인지 확인하기 위해 자동화된 테스트를 파이프라인에 추가하려고 합니다. 팀은 테스트가 성공적이더라도 애플리케이션을 배포하기 전에 수동 승인 작업이 필요합니다. 가장 간단한 관리 솔루션을 사용하여 가장 낮은 비용으로 테스트 및 승인을 수행해야 합니다.
   
   이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
   • 파이프라인의 마지막 배포 작업 후에 수동 승인 작업을 추가합니다. Amazon SNS를 사용하여 트리거되는 단계를 팀에 알립니다. 다음으로 필요한 테스트를 수행하기 위해 CodeBuild를 사용하여 테스트 작업을 추가합니다. 파이프라인 끝에 애플리케이션을 다음 단계로 배포하는 배포 작업을 추가합니다.
   • 파이프라인의 마지막 배포 작업 뒤에 테스트 작업을 추가합니다. CodeBuild를 사용하여 필요한 테스트를 수행하도록 작업을 구성합니다. 이러한 테스트가 성공하면 작업을 성공으로 표시합니다. Amazon SNS를 사용하여 팀에 알리는 수동 승인 작업을 추가하고 애플리케이션을 다음 단계로 배포하는 배포 작업을 추가합니다.
   • 첫 번째 파이프라인과 동일한 리포지토리에서 코드를 가져오는 소스 작업을 사용하는 새 파이프라인을 만듭니다. 배포 작업을 추가하여 코드를 테스트 환경에 배포합니다. AWS Lambda를 사용하는 테스트 작업을 사용하여 배포를 테스트합니다. Amazon SNS를 사용하여 팀에 알리는 수동 승인 작업을 추가하고 애플리케이션을 다음 단계로 배포하는 배포 작업을 추가합니다.
   • 마지막 배포 작업 후에 테스트 작업을 추가합니다. Amazon EC2의 Jenkins 서버를 사용하여 필요한 테스트를 수행하고 테스트를 통과하면 작업을 성공으로 표시합니다. Amazon SQS를 사용하여 팀에 알리는 수동 승인 작업을 생성하고 애플리케이션을 다음 단계로 배포하는 배포 작업을 추가합니다.
     
     
     설명:  AWS CodeBuild Report를 통한 UnitTest 및 Code Coverage 시각화
     유닛테스트는 모듈의 기능을 테스트. AWS CodeBuild에서는 유닛테스트와 코드 커버리지의 결과를 시각화하여 리포트로 받아볼 수 있습니다. 
     
     CodePipeline 의 파이프라인에 수동 승인 작업 추가
     파이프라인을 중지하려는 시점에 CodePipeline 파이프라인의 단계에 승인 작업을 추가하면 다른 사람이 해당 작업을 수동으로 승인하거나 거부할 수 있습니다.
     
     
9. 한 회사에서 AWS에 개인 식별 정보(PII)가 포함된 파일을 저장하기 위한 솔루션을 구축하고 있습니다.
   요구 사항 상태:
   – 모든 데이터는 유휴 및 전송 중에 암호화되어야 합니다.
   – 모든 데이터는 최소 500마일 떨어져 있는 두 개 이상의 위치에 복제되어야 합니다.
   
   어떤 솔루션이 이러한 요구 사항을 충족합니까?
   • 최소 500마일 떨어져 있는 두 개의 별도 가용 영역에서 기본 및 보조 Amazon S3 버킷을 생성합니다. 버킷 정책을 사용하여 HTTPS를 통해서만 버킷에 액세스하도록 합니다. 버킷 정책을 사용하여 버킷에 업로드된 모든 객체에 Amazon S3 SSE-C를 적용합니다. 두 버킷 간에 교차 리전 복제를 구성합니다.
   • 최소 500마일 떨어져 있는 두 개의 개별 AWS 리전에서 기본 및 보조 Amazon S3 버킷을 생성합니다. 버킷 정책을 사용하여 HTTPS를 통해서만 버킷에 액세스하도록 합니다. 버킷 정책을 사용하여 버킷에 업로드된 모든 객체에 S3 관리형 키(SSE-S3)를 적용합니다. 두 버킷 간에 교차 리전 복제를 구성합니다.
   • 최소 500마일 떨어져 있는 두 개의 개별 AWS 리전에서 기본 및 보조 Amazon S3 버킷을 생성합니다. HTTPS를 통해서만 버킷에 대한 액세스를 적용하려면 IAM 역할을 사용하십시오. 버킷 정책을 사용하여 버킷에 업로드된 모든 객체에 Amazon S3 관리형 키(SSE-S3)를 적용합니다. 두 버킷 간에 교차 리전 복제를 구성합니다.
   • 최소 500마일 떨어져 있는 두 개의 별도 가용 영역에서 기본 및 보조 Amazon S3 버킷을 생성합니다. 버킷 정책을 사용하여 HTTPS를 통해서만 버킷에 액세스하도록 합니다. 버킷 정책을 사용하여 버킷에 업로드된 모든 객체에 AWS KMS 암호화를 적용합니다. 두 버킷 간에 교차 리전 복제를 구성합니다. 객체 암호화를 위해 기본 리전에서 KMS 고객 마스터 키(CMK)를 생성합니다.
     
     설명: AWS S3 교차 리전 복제활성화
     S3 교차 리전 복제(CRR)는 서로 다른 AWS 리전의 Amazon S3 버킷에서 객체를 복사하는 데 사용됩니다. 
     
     
     
10. 회사에서 AWS CodeDeploy를 사용하여 소프트웨어 배포를 자동화하고 있습니다. 배포는 다음 요구 사항을 충족해야 합니다.
    – 배포 중에 트래픽을 처리하려면 여러 인스턴스를 사용할 수 있어야 합니다. 트래픽은 이러한 인스턴스 간에 균형을 이루어야 하며 장애 발생 시 인스턴스가 자동으로 복구되어야 합니다.
    – 수동 프로비저닝 없이 새 개정을 자동으로 배포하려면 새 인스턴스 플릿을 시작해야 합니다.
    트래픽은 한 번에 새 인스턴스의 절반으로 새 환경으로 다시 라우팅되어야 합니다. 트래픽이 인스턴스의 절반 이상으로 다시 라우팅되면 배포가 성공해야 합니다. 그렇지 않으면 실패합니다.
    – 새로운 인스턴스 플릿으로 트래픽을 라우팅하기 전에 배포 프로세스 중에 생성된 임시 파일을 삭제해야 합니다.
    – 성공적인 배포가 끝나면 비용을 줄이기 위해 배포 그룹의 원래 인스턴스를 즉시 삭제해야 합니다.
    
    DevOps 엔지니어는 어떻게 이러한 요구 사항을 충족할 수 있습니까?
    • Application Load Balancer 및 인플레이스 배포를 사용합니다. Auto Scaling 그룹을 배포 그룹과 연결합니다. Auto Scaling 그룹 자동 복사 옵션을 사용하고 CodeDeployDefault.OneAtAtime을 배포 구성으로 사용합니다. 배포 그룹의 원래 인스턴스를 종료하도록 AWS CodeDeploy에 지시하고 appspec.yml 내의 AllowTraffic 후크를 사용하여 임시 파일을 삭제합니다.
    • Application Load Balancer 및 블루/그린 배포를 사용합니다. Auto Scaling 그룹 및 Application Load Balancer 대상 그룹을 배포 그룹과 연결합니다. Auto Scaling 그룹 자동 복사 옵션을 사용하고 최소 정상 호스트가 50%로 정의된 사용자 지정 배포 구성을 생성하고 구성을 배포 그룹에 할당합니다. 배포 그룹에서 원래 인스턴스를 종료하도록 AWS CodeDeploy에 지시하고 appspec.yml 내에서 BeforeBlockTraffic 후크를 사용하여 임시 파일을 삭제합니다.
    • Application Load Balancer 및 블루/그린 배포를 사용합니다. Auto Scaling 그룹 및 Application Load Balancer 대상 그룹을 배포 그룹과 연결합니다. Auto Scaling 그룹 자동 복사 옵션을 사용하고 CodeDeployDefault.HalfAtAtime을 배포 구성으로 사용합니다. 배포 그룹의 원래 인스턴스를 종료하도록 AWS CodeDeploy에 지시하고 appspec.yml 내의 BeforeAllowTraffic 후크를 사용하여 임시 파일을 삭제합니다.
    • Application Load Balancer 및 인플레이스 배포를 사용합니다. Auto Scaling 그룹 및 Application Load Balancer 대상 그룹을 배포 그룹과 연결합니다. Auto Scaling 그룹 자동 복사 옵션을 사용하고 CodeDeployDefault.AllatOnce를 배포 구성으로 사용합니다. 배포 그룹의 원래 인스턴스를 종료하도록 AWS CodeDeploy에 지시하고 appspec.yml 내의 BlockTraffic 후크를 사용하여 임시 파일을 삭제합니다.
      
      설명: CodeDeploy에서 배포 구성 작업
      배포 구성은 배포 중 CodeDeploy에서 사용하는 규칙과 성공 및 실패 조건 세트입니다. 
      CodeDeployDefault.HalfAtATime
      블루/그린 배포: 한 번에 대체 환경의 인스턴스 중 최대 절반으로 트래픽을 라우팅합니다. 인스턴스 중 절반 이상으로의 다시 라우팅에 성공
11. DevOps 엔지니어는 3개의 가용 영역에서 12개의 Amazon EC2 인스턴스에 배포된 애플리케이션으로 작업하고 있습니다. 새 인스턴스는 AMI 이미지에서 시작할 수 있습니다. 일반적으로 각 EC2 인스턴스의 업무 시간에는 30%, 업무 시간 이후에는 10%의 활용률이 있습니다. CPU 사용률은 업무 시간의 처음 몇 분 동안 즉시 급증합니다. CPU 사용률의 다른 증가는 점진적으로 증가합니다.
    
    엔지니어는 동일하거나 더 높은 안정성을 유지하면서 비용을 절감하라는 요청을 받았습니다.
    어떤 솔루션이 이러한 요구 사항을 충족합니까?
    • 업무 시간 시작 및 종료 전후 일정으로 두 개의 Amazon CloudWatch Events 규칙을 생성합니다. 각 규칙에 의해 호출되는 두 개의 AWS Lambda 함수를 생성합니다. 첫 번째 기능은 업무 시간 종료 후 9개의 인스턴스를 중지해야 하고, 두 번째 기능은 영업일이 시작되기 전에 9개의 인스턴스를 다시 시작해야 합니다.
    • 목표가 75%인 Auto Scaling 그룹의 CPU 사용률 평균을 기반으로 하는 조정 작업과 함께 AMI 이미지를 사용하여 Amazon EC2 Auto Scaling 그룹을 생성합니다. 업무 시간 종료 후 최소 인스턴스 수를 3개로 조정하고 업무 시간 시작 전에 6개로 재설정하도록 그룹에 예약된 작업을 생성합니다.
    • 업무 시간 시작 및 종료 전후 일정으로 두 개의 Amazon CloudWatch Events 규칙을 생성합니다. 인스턴스 수에 대한 파라미터를 사용하여 EC2 Auto Scaling 그룹을 생성하는 AWS CloudFormation 스택을 생성합니다. 아침에 세 번, 저녁에 여섯 번 매개 변수 값을 전달하여 각 규칙에서 스택을 호출합니다.
    • 목표가 75%인 Auto Scaling 그룹의 CPU 사용률 평균을 기반으로 하는 조정 작업과 함께 AMI 이미지를 사용하여 EC2 Auto Scaling 그룹을 생성합니다. 업무 종료 후 매일 저녁 9개의 인스턴스를 종료하도록 예약된 작업을 만듭니다.
      
      설명:  Amazon EC2 Auto Scaling > 예약된 작업을 사용하여 예측 값 재정의
      예약된 작업을 사용하여 미래 기간에 대한 예상을 임시로 재정의할 수 있습니다. 예약된 작업은 반복적으로 실행되거나 일회성 수요 변동이 있는 특정 날짜 및 시간에 실행될 수 있습니다.
        예를 들어 예상한 것보다 높은 최소 용량으로 예약된 작업을 생성할 수 있습니다. 런타임 시 Amazon EC2 Auto Scaling은 Auto Scaling 그룹의 최소 용량을 업데이트합니다. 예측 조정은 용량에 맞게 최적화하므로 최소 용량이 예상 값보다 높은 예약된 작업이 적용됩니다. 이렇게 하면 용량이 예상보다 작아지는 것을 방지할 수 있습니다. 예상 재정의를 중지하려면 두 번째 예약된 작업을 사용하여 최소 용량을 원래 설정으로 되돌립니다.
      
      
12. DevOps 엔지니어는 전자 상거래 플랫폼의 거래를 처리하는 재무 팀 결제 마이크로 서비스의 모니터링을 개선해야 합니다. 마이크로서비스는 여러 Amazon EC2 인스턴스에서 실행됩니다. 재무 팀은 분당 결제 횟수를 알고 싶어 하며 이 지표가 지정된 임계값 아래로 떨어지면 팀에 알림을 받고자 합니다.
    
    이를 비용 효율적으로 자동화하는 방법은 무엇입니까?
    
    • 개발 팀이 성공적인 트랜잭션을 애플리케이션 로그에 기록하도록 합니다. 로그를 Amazon ES 클러스터로 전송하는 각 인스턴스에 Logstash를 설정합니다. 메트릭을 그래프로 표시하는 재무 팀을 위한 Kibana 대시보드를 생성합니다.
    • 개발 팀이 성공적인 트랜잭션 수를 Amazon CloudWatch에 사용자 지정 메트릭으로 게시하도록 합니다. 임계값을 위반하면 CloudWatch 경보를 생성하고 Amazon SNS를 사용하여 재무 팀에 알립니다.
    • 개발 팀이 성공적인 트랜잭션을 애플리케이션 로그에 기록하도록 합니다. 각 인스턴스에서 애플리케이션 로그를 CloudWatch Logs로 보내도록 Amazon CloudWatch Logs 에이전트를 설정합니다. EC2 인스턴스를 사용하여 지표 필터를 모니터링하고 재무 팀에 알림을 보냅니다.
    • 개발 팀이 성공적인 트랜잭션을 애플리케이션 로그에 기록하도록 합니다. 각 인스턴스에서 Amazon CloudWatch 에이전트를 설정합니다. 임계값을 위반하면 CloudWatch 경보를 생성하고 Amazon SNS를 사용하여 재무 팀에 알립니다.
      
      설명:  Amazon CloudWatch > 사용 가능한 지표 보기
      지표는 먼저 네임스페이스별로 그룹화된 다음, 각 네임스페이스 내에서 다양한 측정기준 조합별로 그룹화됩니다. 예를 들어 모든 EC2 지표, 인스턴스별로 그룹화된 EC2 지표 또는 오토 스케일링 그룹별로 그룹화된 EC2 지표를 볼 수 있습니다.
      
      CloudWatch 경보 생성
      과거 지표 데이터를 분석하고 예상 값의 모델을 생성하는 CloudWatch 이상 탐지를 기반으로 경보를 생성할 수 있습니다. 
      
      CloudWatch를 사용하여 Amazon SNS 주제 모니터링
      Amazon SNS와 Amazon CloudWatch가 통합되어 모든 활성 Amazon SNS 알림에 대한 지표를 수집, 확인 및 분석할 수 있습니다. Amazon SNS용 CloudWatch를 구성하고 나면 Amazon SNS 주제, 푸시 알림 및 SMS 전송의 성능에 대한 더 나은 인사이트를 얻을 수 있습니다.
      
      
13. 회사에서 단일 Amazon EC2 인스턴스에서 실행되는 AWS로 애플리케이션을 마이그레이션하고 있습니다. 라이센스 제한으로 인해 애플리케이션은 수평 확장을 지원하지 않습니다. 애플리케이션은 데이터베이스로 Amazon Aurora를 사용합니다.
    
    DevOps 엔지니어 설계자는 가용 영역(AZ) 전체에서 복구하는 것 외에도 EC2 및 Aurora 장애로부터 자동으로 복구하기 위해 자동 복구를 가장 비용 효율적인 방식으로 어떻게 수행할 수 있습니까?
    
    • 최소 및 최대 인스턴스 수가 1인 EC2 Auto Scaling 그룹을 생성하고 여러 AZ에 걸쳐 있도록 합니다. 단일 노드 Aurora 인스턴스를 사용합니다.
    • EC2 인스턴스를 생성하고 인스턴스 복구를 활성화합니다. 두 번째 AZ에 읽기 전용 복제본이 있는 Aurora 데이터베이스를 생성하고 기본 데이터베이스 인스턴스가 실패하면 기본 데이터베이스 인스턴스로 승격합니다.
    • 인스턴스 상태가 실패 상태에 도달하면 사용 가능한 AZ에서 새 EC2 인스턴스를 시작하도록 AWS Lambda 함수를 트리거하는 Amazon CloudWatch Events 규칙을 생성합니다. 두 번째 AZ에 읽기 전용 복제본이 있는 Aurora 데이터베이스를 생성하고 기본 데이터베이스 인스턴스가 실패하면 기본 데이터베이스 인스턴스로 승격합니다.
    • 인스턴스에 탄력적 IP 주소를 할당합니다. 두 번째 AZ에서 두 번째 EC2 인스턴스를 생성합니다. 첫 번째 인스턴스가 실패할 때 탄력적 IP 주소를 두 번째 인스턴스로 이동하도록 AWS Lambda 함수를 트리거하는 Amazon CloudWatch Events 규칙을 생성합니다. 단일 노드 Aurora 인스턴스를 사용합니다.
      
      설명: Amazon CloudWatch Events > CloudWatch Events를 사용하여 Amazon EC2 인스턴스의 상태 로그
      Amazon EC2 인스턴스의 상태 변경을 로그하는 AWS Lambda 함수를 생성할 수 있습니다. 상태 전환이 있거나 관심이 있는 하나 이상의 상태로 전환될 때마다 함수를 실행하도록 규칙을 생성할 수 있습니다. 
      
      
14. 애플리케이션 팀에는 개발, 사전 프로덕션 및 프로덕션의 세 가지 애플리케이션 환경이 있습니다. 이 팀은 최근에 AWS CodePipeline을 채택했습니다. 그러나 팀은 잘못 구성되었거나 작동하지 않는 개발 코드를 프로덕션 환경에 여러 번 배포하여 사용자 중단 및 다운타임을 초래했습니다. DevOps 엔지니어는 파이프라인을 검토하고 응용 프로그램을 배포하기 전에 문제를 식별하는 단계를 추가해야 합니다.
    
    엔지니어는 배포 프로세스 중에 기능 문제를 식별하기 위해 무엇을 해야 합니까? (두 가지를 선택하세요.)
    
    • Amazon Inspector를 사용하여 파이프라인에 테스트 작업을 추가합니다. Amazon Inspector Runtime Behavior Analysis Inspector 규칙 패키지를 사용하여 배포된 코드가 프로덕션에 배포하기 전에 회사 보안 표준을 준수하는지 확인하십시오.
    • AWS CodeBuild를 사용하여 테스트 작업을 파이프라인에 추가하여 일반 사용자 활동을 복제하고 프로덕션 배포로 진행하기 전에 결과가 예상대로인지 확인합니다.
    • 제한된 수의 인스턴스에 애플리케이션 코드를 자동으로 배포하는 배포 구성을 사용하여 파이프라인에서 AWS CodeDeploy 작업을 생성합니다. 그런 다음 작업은 QA 팀이 애플리케이션 기능을 검토할 수 있도록 배포를 일시 중지합니다. 검토가 완료되면 CodeDeploy는 애플리케이션을 재개하고 나머지 프로덕션 Amazon EC2 인스턴스에 배포합니다.
    • 배포 프로세스가 완료되면 사용자 동작을 시뮬레이션하기 위해 애플리케이션에 액세스하는 다른 지역의 Amazon EC2 인스턴스에서 테스트 활동을 실행합니다. 예기치 않은 결과가 발생하면 테스트 활동이 Amazon SNS 주제에 경고를 보냅니다. 업데이트를 받으려면 주제를 구독하십시오.
    • 파이프라인에 AWS CodeDeploy 작업을 추가하여 개발 코드의 최신 버전을 사전 프로덕션에 배포합니다. QA 팀이 예상 기능을 테스트하고 확인할 수 있도록 파이프라인에 수동 승인 작업을 추가합니다. 수동 승인 작업 후에 승인된 코드를 프로덕션 환경에 배포하는 두 번째 CodeDeploy 작업을 추가합니다.
      
      설명:  AWS CodeDeploy >  Amazon ECS 서비스 배포 및 확인 테스트
      CodeDeploy는 Amazon EC2 인스턴스, 온프레미스 인스턴스, 서버리스 Lambda 함수 또는 Amazon ECS 서비스로 애플리케이션 배포를 자동화하는 배포 서비스입니다.
       확인 테스트를 포함한 Amazon ECS 배포 중에 CodeDeploy는 프로덕션 트래픽 리스너 하나와 테스트 트래픽 리스너 하나라는 두 개의 대상 그룹으로 구성된 로드 밸런서를 사용합니다. 
      
      
15. DevOps 엔지니어는 PHP 애플리케이션 배포를 담당합니다. 엔지니어는 온프레미스 서버와 Amazon EC2 인스턴스 모두에서 애플리케이션이 실행되는 하이브리드 배포에서 작업하고 있습니다. 응용 프로그램은 극비 정보가 포함된 데이터베이스에 액세스해야 합니다. 애플리케이션 인스턴스는 데이터베이스 자격 증명에 액세스해야 하며 인스턴스에 도달하기 전에 미사용 및 전송 중에 암호화되어야 합니다.
    
    엔지니어는 보안 요구 사항을 충족하면서 배포 프로세스를 어떻게 자동화해야 합니까?
    
    • PHP 플랫폼 구성과 함께 AWS Elastic Beanstalk를 사용하여 애플리케이션 패키지를 인스턴스에 배포합니다. Secure String 데이터 유형을 사용하여 AWS Systems Manager Parameter Store에 데이터베이스 자격 증명을 저장합니다. 액세스를 허용하는 Amazon EC2에 대한 IAM 역할을 정의하고 데이터베이스 자격 증명만 해독합니다. 이 역할을 모든 인스턴스에 연결합니다.
    • AWS CodeDeploy를 사용하여 애플리케이션 패키지를 인스턴스에 배포합니다. Secure String 데이터 유형을 사용하여 AWS Systems Manager Parameter Store에 데이터베이스 자격 증명을 저장합니다. 액세스를 허용하기 위한 IAM 정책을 정의하고 데이터베이스 자격 증명만 해독합니다. IAM 정책을 CodeDeploy 관리형 인스턴스의 인스턴스 프로필에 연결된 역할과 CodeDeploy의 온프레미스 인스턴스 등록에 사용되는 역할에 연결합니다.
    • AWS CodeDeploy를 사용하여 애플리케이션 패키지를 인스턴스에 배포합니다. Secure String 데이터 유형을 사용하여 AWS Systems Manager Parameter Store에 데이터베이스 자격 증명을 저장합니다. 데이터베이스 자격 증명의 암호 해독을 허용하는 연결된 정책으로 IAM 역할을 정의합니다. 이 역할을 모든 인스턴스 및 온프레미스 서버에 연결합니다.
    • AWS CodeDeploy를 사용하여 애플리케이션 패키지를 인스턴스에 배포합니다. AppSpec file에 데이터베이스 자격 증명을 저장합니다. 데이터베이스 자격 증명에만 액세스할 수 있도록 IAM 정책을 정의합니다. IAM 정책을 CodeDeploy 관리형 인스턴스의 인스턴스 프로필과 연결된 역할과 CodeDeploy에서 온프레미스 인스턴스 등록에 사용되는 역할에 연결합니다.
      
      설명: AWS Systems Manager Parameter Store
      AWS Systems Manager의 기능인 Parameter Store는 구성 데이터 관리 및 비밀 관리를 위한 안전한 계층적 스토리지를 제공합니다. 
      
      • 관리할 서버가 없는 안전하고 확장 가능한 호스팅 비밀 관리 서비스를 사용하세요.
      • 코드에서 데이터를 분리하여 보안 태세를 개선하십시오.
      • 구성 데이터와 암호화된 문자열을 계층에 저장하고 버전을 추적합니다.
      • 세분화된 수준에서 액세스를 제어하고 감사합니다.
      • Parameter Store는 AWS 리전의 여러 가용 영역에서 호스팅되므로 파라미터를 안정적으로 저장합니다.
        
        
16. 회사에는 자동화된 배포 파이프라인을 위한 코드를 작성하는 단일 개발자가 있습니다. 개발자는 각 프로젝트의 Amazon S3 버킷에 소스 코드를 저장하고 있습니다. 회사는 팀에 더 많은 개발자를 추가하기를 원하지만 코드 충돌 및 작업 손실이 우려됩니다. 회사는 또한 테스트를 위해 최신 버전의 코드를 배포하고 저장소에서 코드가 변경될 때 개발자가 두 환경에 자동으로 배포할 수 있도록 테스트 환경을 구축하고자 합니다.
    
    이러한 요구 사항을 충족하는 가장 효율적인 방법은 무엇입니까?
    
    • 각 프로젝트에 대한 AWS CodeCommit 리포지토리를 생성하고, 프로덕션 코드에 마스터 브랜치를 사용하고, 테스트에 배포된 코드에 대한 테스트 브랜치를 생성합니다. 기능 분기를 사용하여 새로운 기능을 개발하고 코드를 테스트 및 마스터 분기에 병합하기 위한 풀 리퀘스트를 사용하십시오.
    • 코드 테스트를 위해 각 프로젝트에 대해 다른 S3 버킷을 생성하고 AWS Lambda 함수를 사용하여 테스트 버킷과 프로덕션 버킷 간에 코드 변경을 촉진합니다. 코드 충돌을 방지하기 위해 모든 버킷에서 버전 관리를 활성화합니다.
    • 각 프로젝트에 대한 AWS CodeCommit 리포지토리를 생성하고 각 환경에 대해 서로 다른 배포 파이프라인이 있는 프로덕션 및 테스트 코드에 대한 마스터 브랜치를 사용합니다. 새 기능을 개발하려면 기능 분기를 사용하세요.
    • 각 S3 버킷에서 버전 관리 및 분기를 활성화하고, 프로덕션 코드에 마스터 분기를 사용하고, 테스트에 배포된 코드에 대한 테스트 분기를 생성합니다. 개발자가 각 환경에서 개발을 위해 각 분기를 사용하도록 합니다.
      
      설명: AWS CodeCommit란 무엇입니까?
      AWS CodeCommit는 클라우드에서 자산 (예: 문서, 소스 코드, 바이너리 파일) 을 비공개로 저장하여 관리하는 데 사용할 수 있도록 Amazon Web Services Services에서 호스팅되는 버전 관리 서비스입니다.
      
      풀 요청 작업
      pull 요청은 나와 리포지토리의 다른 사용자가 검토하고, 주석을 추가하며, 한 브랜치에서 다른 브랜치로 코드를 변경하기 위한 기본적인 방법입니다. pull 요청은 소스 브랜치의 말단과 pull 요청이 생성될 당시의 대상 브랜치의 마지막 커밋 간의 차이를 표시하므로, 사용자는 변경 내용을 보고 그에 대한 설명을 추가할 수 있습니다. 주석에 따라 변경 내용을 소스 브랜치로 커밋하고 푸시함으로써 pull 요청을 업데이트할 수 있습니다.
      
      
17. AWS API Gateway를 사용하는 새로운 애플리케이션에 대한 개념 증명을 제시한 후 개발자는 프로젝트를 위한 팀 개발 환경을 설정해야 합니다. 촉박한 일정으로 인해 개발자는 인프라 설정에 소요되는 시간을 최소화하고 개념 증명을 위해 생성된 코드 리포지토리를 재사용하고자 합니다. 현재 모든 소스 코드는 AWS CodeCommit에 저장되어 있습니다.
    
    회사 정책에 따라 별도의 Jenkins 서버를 사용하여 알파, 베타 및 생산 단계를 갖추어 모든 단계에서 코드를 빌드하고 테스트를 실행해야 합니다. 개발 관리자는 언제든지 관리자 간의 코드 전파를 차단할 수 있어야 합니다. 보안 팀은 사용자가 허가 없이 환경을 수정할 수 없도록 하고자 합니다.
    
    이것이 어떻게 이루어질 수 있습니까?
    • API Gateway 알파, 베타 및 프로덕션 단계를 생성합니다. AWS Lambda 함수를 사용하여 다른 단계에 코드를 배포하는 CodeCommit 트리거를 생성합니다.
    • API Gateway 알파, 베타 및 프로덕션 단계를 생성합니다. CodeCommit 리포지토리에서 코드를 가져오는 AWS CodePipeline을 생성합니다. CodePipeline 작업을 생성하여 API Gateway 단계에 코드를 배포합니다.
    • Amazon EC2 인스턴스에서 알파, 베타 및 프로덕션 단계를 위한 Jenkins 서버를 생성합니다. AWS Lambda 함수를 사용하여 여러 단계에 코드를 배포하는 여러 CodeCommit 트리거를 생성합니다.
    • CodeCommit 리포지토리에서 코드를 가져오는 AWS CodePipeline 파이프라인을 생성합니다. CodePipeline에서 Jenkins 서버로 알파, 베타 및 프로덕션 단계를 생성합니다.
      
      설명:
      CodeCommit에서 파이프라인 생성
      CodePipeline Jenkins 작업> 젠킨스와 젠킨스용 CodePipeline 플러그인 설치 및 구성
      
      
18. 온라인 회사는 Amazon EC2 Auto Scaling을 광범위하게 사용하여 실행 중인 EC2 인스턴스 수를 최소화하면서 뛰어난 고객 경험을 제공합니다. 애플리케이션 계층에 있는 회사의 자체 호스팅 Puppet 환경은 인스턴스의 구성을 관리합니다. IT 관리자는 최저 라이선스 비용을 원하고 EC2 Auto Scaling 그룹이 축소될 때마다 제거된 EC2 인스턴스가 Puppet 마스터에서 가능한 한 빨리 등록 취소되기를 원합니다.
    
    요구 사항을 어떻게 충족할 수 있습니까?
    
    • 인스턴스 시작 시 EC2 사용자 데이터를 사용하여 AWS CodeDeploy 에이전트를 배포합니다. CodeDeploy를 사용하여 Puppet 에이전트를 설치합니다. Auto Scaling 그룹이 확장되면 스크립트를 실행하여 새로 배포된 인스턴스를 Puppet 마스터에 등록합니다. Auto Scaling 그룹이 축소되면 EC2 Auto Scaling EC2_INSTANCE_TERMINATING 수명 주기 후크를 사용하여 Puppet 마스터에서 등록 취소를 트리거합니다.
    • AWS CodeDeploy 에이전트를 기본 AMI로 굽습니다. Auto Scaling 그룹이 확장되면 CodeDeploy를 사용하여 Puppet 에이전트를 설치하고 스크립트를 실행하여 새로 배포된 인스턴스를 Puppet 마스터에 등록합니다. Auto Scaling 그룹이 축소되면 CodeDeploy ApplicationStop 수명 주기 후크를 사용하여 Puppet 마스터에서 인스턴스 등록을 취소하는 스크립트를 실행합니다.
    • 인스턴스 시작 시 EC2 사용자 데이터를 사용하여 AWS CodeDeploy 에이전트를 배포합니다. Auto Scaling 그룹이 확장되면 CodeDeploy를 사용하여 Puppet 에이전트를 설치하고 스크립트를 실행하여 새로 배포된 인스턴스를 Puppet 마스터에 등록합니다. Auto Scaling 그룹이 축소되면 EC2 사용자 데이터 인스턴스 중지 스크립트를 사용하여 Puppet 마스터에서 인스턴스 등록을 취소하는 스크립트를 실행합니다.
    • AWS Systems Manager 에이전트를 기본 AMI에 굽습니다. Auto Scaling 그룹이 확장되면 AWS Systems Manager를 사용하여 Puppet 에이전트를 설치하고 스크립트를 실행하여 새로 배포된 인스턴스를 Puppet 마스터에 등록합니다. Auto Scaling 그룹이 축소되면 Systems Manager 인스턴스 수명 주기 중지 후크를 사용하여 Puppet 마스터에서 인스턴스 등록을 취소하는 스크립트를 실행합니다.
19. 한 회사에서 일부 IAM 사용자가 Git 리포지토리 호스팅 서비스로 푸시된 구성 파일에 AWS 액세스 키를 저장하고 있음을 발견했습니다.
    
    노출된 AWS 액세스 키가 사용되지 않도록 방지하면서 최소한의 관리 오버헤드가 필요한 솔루션은 무엇입니까?
    
    • 계정의 모든 AWS 액세스 키 목록을 생성하고 Git 리포지토리 호스팅 서비스에서 각 키를 검색하는 애플리케이션을 빌드합니다. 일치 항목이 발견되면 연결된 액세스 키를 비활성화하도록 애플리케이션을 구성합니다. 그런 다음 애플리케이션을 AWS Elastic Beanstalk 작업자 환경에 배포하고 매시간 애플리케이션을 호출하는 주기적 작업을 정의합니다.
    • Amazon Inspector를 사용하여 키가 온라인에 노출된 시점을 감지합니다. 키가 노출되면 Amazon Inspector가 Amazon SNS 주제에 알림을 보내도록 합니다. SNS 주제를 구독하는 AWS Lambda 함수를 생성하여 키가 속한 IAM 사용자를 비활성화한 후 키를 사용할 수 없도록 삭제합니다.
    • AWS Trusted Advisor를 구성하고 Trusted Advisor를 이벤트 소스로 사용하는 Amazon CloudWatch Events 규칙을 생성합니다. AWS Lambda 함수를 대상으로 호출하도록 CloudWatch 이벤트 규칙을 구성합니다. Lambda 함수가 노출된 액세스 키를 찾으면 액세스 키를 사용할 수 없도록 비활성화합니다.
    • 키가 온라인에 노출되는 시기를 감지하는 AWS Config 규칙을 생성합니다. Haw AWS Config는 변경 알림을 SNS 주제로 보냅니다. SNS 주제를 구독하는 AWS Lambda 함수를 구성하여 AWS Config에서 보낸 알림을 확인한 다음 사용할 수 없도록 액세스 키를 비활성화합니다.
      
      설명: AWS Trusted Advisor는 AWS 인프라를 최적화하고 보안 및 성능을 개선하며 비용을 절감하고 서비스 할당량을 모니터링할 방법을 식별합니다. 사용자는 권장 사항에 따라 서비스 및 리소스를 최적화할 수 있습니다.
      
      
20. 회사 정책에 따라 프로덕션 Amazon VPC의 인스턴스 간에 이동하는 IP 트래픽에 대한 정보를 캡처해야 합니다. 캡처 메커니즘은 항상 활성화되어야 하며 구성이 변경되면 보안 팀에 알려야 합니다.
    
    이러한 요구 사항을 충족하려면 어떻게 해야 합니까?
    
    • AWS CloudFormation 템플릿의 UserData 섹션을 사용하여 프로비저닝된 모든 Amazon EC2 인스턴스에 tcpdump를 설치합니다. 도구의 출력은 집계 및 쿼리를 위해 Amazon EFS로 전송됩니다. 또한 Amazon CloudWatch Events 규칙을 예약하면 AWS Lambda 함수를 호출하여 tcpdump가 실행 중인지 확인하고 예외가 있을 때 보안 조직에 이메일을 보냅니다.
    • 프로덕션 VPC에 대한 흐름 로그를 생성하고 Amazon S3 버킷을 배달 대상으로 할당합니다. Amazon S3 이벤트 알림을 사용하여 새 로그 파일이 전달될 때 트리거되는 AWS Lambda 함수를 설정합니다. 이 Lambda 함수는 로그가 도착하지 않았을 때 보안에 알리도록 Amazon CloudWatch Events 규칙을 예약하여 주기적으로 확인하는 Amazon DynamoDB의 항목을 업데이트합니다.
    • 프로덕션 VPC에 대한 흐름 로그를 생성합니다. 'EC2:VPC' 유형 리소스의 구성 변경에 의해 트리거되는 AWS Config를 사용하여 새 규칙을 생성합니다. 규칙 구성의 일부로 지정된 VPC에 대한 흐름 로그를 조회하는 AWS Lambda 함수를 생성합니다. VPC 흐름 로그가 구성되지 않은 경우 'NON_COMPLIANT' 상태를 반환하고 보안 조직에 알립니다.
    • AWS CloudTrail 서비스를 사용하여 새 추적을 구성합니다. AWS CloudFormation 템플릿의 UserData 섹션을 사용하여 프로비저닝된 모든 Amazon EC2 인스턴스에 tcpdump를 설치합니다. Amazon Athena를 CloudTrail에 연결하고 흐름 로그 비활성화 이벤트를 모니터링하는 AWS Lambda 함수를 작성합니다. CloudTrail 항목이 발견되면 보안 조직에 알립니다.

설명: AWS Config이란 무엇입니까?
AWS Config를 사용하여 각 리소스에 대한 호출을 폴링함으로써 리소스가 생성, 수정 또는 삭제될 때마다 모니터링할 필요 없이 이러한 변경 사항에 대한 알림을 받을 수 있습니다.

 

정답

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