Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- kotlin spring
- 정보처리기사 실기
- Elasticsearch
- 티스토리챌린지
- kotlin querydsl
- 코틀린 코루틴의 정석
- AI
- PETERICA
- kotlin
- 공부
- 정보처리기사 실기 기출문제
- mysql 튜닝
- 정보처리기사실기 기출문제
- CKA
- Spring
- AWS EKS
- IntelliJ
- MySQL
- 오블완
- CloudWatch
- aws
- Java
- Pinpoint
- APM
- Kubernetes
- kotlin coroutine
- CKA 기출문제
- 기록으로 실력을 쌓자
- Linux
- minikube
Archives
- Today
- Total
피터의 개발이야기
[DOP-C01] AWS DevOps Engineer Professional : Part 05 본문
반응형
- DevOps 엔지니어는 확장 가능한 3계층 Node.js 애플리케이션을 AWS에 배포해야 합니다. 애플리케이션은 배포 중에 다운타임이 없어야 하며 이전 버전으로 롤백할 수 있어야 합니다. 다른 애플리케이션도 동일한 MySQL 백엔드 데이터베이스에 연결됩니다.
CIO는 로깅에 대해 다음 지침을 제공했습니다.
– 모든 현재 웹 액세스 서버 로그를 중앙에서 봅니다.
– 거의 실시간으로 웹 및 애플리케이션 로그를 검색하고 필터링합니다.
– 로그 데이터는 3개월간 보관합니다.
이러한 요구 사항을 어떻게 충족해야 합니까?
- AWS Elastic Beanstalk를 사용하여 애플리케이션을 배포합니다. Elastic Load Balancing 및 Auto Scaling에 대한 환경 유형을 구성합니다. Elastic Beanstalk 스택 내에 Amazon RDS MySQL 인스턴스를 생성합니다. 로그를 Amazon CloudWatch Logs로 스트리밍하도록 Elastic Beanstalk 로그 옵션을 구성합니다. 보존 기간을 90일로 설정합니다.
- Amazon EC2에 애플리케이션을 배포합니다. Elastic Load Balancing 및 Auto Scaling을 구성합니다. 데이터베이스 계층에 Amazon RDS MySQL 인스턴스를 사용합니다. Amazon S3에 로그 파일을 저장하도록 애플리케이션을 구성합니다. Amazon EMR을 사용하여 데이터를 검색하고 필터링합니다. 90일 후에 객체가 만료되도록 Amazon S3 수명 주기 규칙을 설정합니다.
- AWS Elastic Beanstalk를 사용하여 애플리케이션을 배포합니다. Elastic Load Balancing 및 Auto Scaling에 대한 환경 유형을 구성합니다. Elastic Beanstalk 스택 외부에서 Amazon RDS MySQL 인스턴스를 생성합니다. 로그를 Amazon CloudWatch Logs로 스트리밍하도록 Elastic Beanstalk 로그 옵션을 구성합니다. 보존 기간을 90일로 설정합니다.
- Amazon EC2에 애플리케이션을 배포합니다. Elastic Load Balancing 및 Auto Scaling을 구성합니다. 데이터베이스 계층에 Amazon RDS MySQL 인스턴스를 사용합니다. Amazon Kinesis Data Firehose를 사용하여 스트리밍 로그 데이터를 Amazon ES로 로드하도록 애플리케이션을 구성합니다. 90일마다 새 Amazon ES 도메인을 삭제하고 생성합니다.
설명:
Elastic Beanstalk 환경의 Amazon EC2 인스턴스는 애플리케이션 또는 구성 파일의 문제를 해결하기 위해 볼 수 있는 로그를 생성합니다. 웹 서버, 애플리케이션 서버, Elastic Beanstalk 플랫폼 스크립트 및 AWS CloudFormation에서 생성된 로그는 개별 인스턴스에 로컬로 저장됩니다. 환경 관리 콘솔 또는 EB CLI를 사용하여 쉽게 검색할 수 있습니다. 실시간으로 Amazon CloudWatch Logs로 로그를 스트리밍하도록 환경을 구성할 수도 있습니다. - IT 팀은 회사의 다른 사람들이 애플리케이션을 빠르고 안정적으로 배포하고 종료할 수 있도록 AWS CloudFormation 템플릿을 구축했습니다. 이 템플릿은 사용자 데이터 스크립트를 사용하여 Amazon EC2 인스턴스를 생성하여 애플리케이션을 설치하고 애플리케이션이 실행 중인 동안 정적 웹 페이지를 제공하는 데 사용하는 Amazon S3 버킷을 생성합니다.
CloudFormation 스택이 삭제되면 모든 리소스를 제거해야 합니다. 그러나 팀은 CloudFormation이 스택 삭제 중에 오류를 보고하고 스택에 의해 생성된 S3 버킷이 삭제되지 않음을 관찰합니다.
모든 리소스가 오류 없이 삭제되도록 팀에서 가장 효율적인 방식으로 오류를 해결하려면 어떻게 해야 합니까?- DeletionPolicy 속성을 S3 버킷 리소스에 추가하고 Delete 값을 사용하면 스택이 삭제될 때 버킷이 강제로 제거됩니다.
- S3 버킷 및 IAM 역할을 지정하는 DependsOn 속성이 있는 AWS Lambda 함수가 있을 때 사용자 지정 리소스를 추가합니다. RequestType이 Delete일 때 버킷에서 모든 객체를 삭제하도록 Lambda 함수를 작성합니다.
- 삭제되지 않은 리소스를 식별합니다. S3 콘솔에서 S3 버킷을 비운 다음 삭제합니다.
- EC2 및 S3 버킷 리소스를 단일 AWS OpsWorks Stacks 리소스로 바꿉니다. 스택에 대한 사용자 지정 레시피를 정의하여 EC2 인스턴스 및 S3 버킷을 생성하고 삭제합니다.
- DevOps 엔지니어가 Amazon EC2 인스턴스에서 이미 워크로드를 실행 중인 새 회사에 막 합류했습니다. AWS는 중앙 거버넌스 없이 점진적으로 채택되었습니다. 엔지니어는 이제 기존 배포가 다음 요구 사항을 얼마나 잘 준수하는지 평가해야 합니다.
– EC2 인스턴스는 승인된 AMI만 실행합니다.
– Amazon EBS 볼륨은 암호화됩니다.
– EC2 인스턴스에는 소유자 태그가 있습니다.
– SSH를 통한 루트 로그인은 EC2 인스턴스에서 비활성화됩니다.
엔지니어는 최소한의 노력으로 이 평가를 수행하기 위해 어떤 서비스를 사용해야 합니까? (두 가지를 선택하세요.)
- AWS Config
- Amazon GuardDuty
- AWS System Manager
- AWS Directory Service
- Amazon Inspector
노트: Amazon Inspector는 소프트웨어 취약성 및 의도하지 않은 네트워크 노출에 대해 AWS 워크로드를 지속적으로 스캔하는 자동화된 취약성 관리 서비스입니다.
- 의료 회사에는 AWS에서 실행되는 중요한 애플리케이션이 있습니다. 최근에 회사는 다운타임을 겪었습니다. 이런 일이 다시 발생하면 회사는 다른 AWS 리전에서 애플리케이션을 복구할 수 있어야 합니다. 애플리케이션은 Elastic Load Balancing 및 Amazon EC2 인스턴스를 사용합니다. 회사는 또한 애플리케이션이 포함된 사용자 지정 AMI를 유지 관리합니다. 이 AMI는 자주 변경됩니다.
트래픽이 새 지역으로 장애 조치되어야 하는 지역 서비스 중단이 없는 한 워크로드는 기본 지역에서 실행해야 합니다. 또한 두 번째 지역의 비용이 낮아야 합니다. RTO는 2시간입니다.
장애 발생 시 회사가 다른 지역으로 장애 조치할 수 있고 위의 요구 사항도 충족하는 솔루션은 무엇입니까?- 백업 지역의 기본 지역에서 AMI 사본을 유지합니다. 복사된 AMI가 포함된 시작 구성을 사용하여 하나의 인스턴스로 Auto Scaling 그룹을 생성합니다. 장애 발생 시 필요에 따라 Amazon Route 53 레코드를 사용하여 백업 리전의 로드 밸런서로 트래픽을 보냅니다. 장애 발생 시 필요에 따라 Auto Scaling 그룹이 확장되도록 허용합니다.
- 기본 지역의 AMI를 백업 지역으로 자동 복사합니다. AMI에서 EC2 인스턴스를 생성하고 로드 밸런서 뒤에 배치하는 AWS Lambda 함수를 생성합니다. 동일한 Lambda 함수를 사용하여 Amazon Route 53 레코드가 백업 리전의 로드 밸런서를 가리키도록 합니다. 실패 시 Lambda 함수를 트리거합니다.
- 복제된 Amazon S3 버킷에 AMI를 배치합니다. 시작 구성을 생성하고 이미 생성된 Auto Scaling 그룹에 할당할 수 있는 AWS Lambda 함수를 생성합니다. 이 Auto Scaling 그룹에 트래픽을 수락할 준비가 된 인스턴스가 하나 있습니다. 실패 시 Lambda 함수를 트리거합니다. Amazon Route 53 레코드를 사용하고 백업 리전의 로드 밸런서를 가리키도록 동일한 Lambda 함수로 수정합니다.
- 백업 지역으로 AMI 복사를 자동화합니다. 시작 구성을 생성하고 이미 생성된 Auto Scaling 그룹에 할당할 수 있는 AWS Lambda 함수를 생성합니다. Auto Scaling 그룹 최대 크기를 0으로 설정하고 장애 발생 시 Lambda 함수로만 크기를 늘립니다. 실패 시 Lambda 함수를 트리거합니다. Amazon Route 53 레코드를 사용하고 백업 리전의 로드 밸런서를 가리키도록 동일한 Lambda 함수로 수정합니다.
- 레거시 웹 애플리케이션은 독점 텍스트 형식으로 액세스 로그를 저장합니다. 보안 요구 사항 중 하나는 애플리케이션 액세스 이벤트를 검색하고 이를 다양한 시스템의 액세스 데이터와 연관시키는 것입니다. 이러한 검색은 거의 실시간이어야 합니다.
애플리케이션 서버의 처리 부하를 줄이고 거의 실시간으로 데이터를 검색하는 메커니즘을 제공하는 솔루션은 무엇입니까?
- 애플리케이션 서버에 Amazon CloudWatch Logs 에이전트를 설치하고 CloudWatch Events 규칙을 사용하여 액세스 이벤트에 대한 로그를 검색합니다. Amazon CloudSearch를 인터페이스로 사용하여 이벤트를 검색합니다.
- 타사 파일 입력 플러그인 Logstash를 사용하여 애플리케이션 로그 파일을 모니터링한 다음 에이전트에서 사용자 지정 분석 필터를 사용하여 로그 항목을 JSON 형식으로 구문 분석합니다. 검색할 이벤트를 Amazon ES로 출력합니다. 데이터 쿼리에 Elasticsearch API를 사용합니다.
- S3 sync 명령을 사용하여 Amazon S3에 로그 파일을 업로드합니다. Amazon Athena를 사용하여 데이터 구조를 테이블로 정의하고 Athena SQL 쿼리를 사용하여 액세스 이벤트를 검색합니다.
- 애플리케이션 서버에 Amazon Kinesis 에이전트를 설치하고 로그 파일을 모니터링하도록 구성한 다음 Kinesis 스트림으로 보냅니다. AWS Lambda 함수를 사용하여 데이터를 변환하고 분석을 위해 이벤트를 Amazon ES로 전달하도록 Kinesis를 구성합니다. 데이터 쿼리에 Elasticsearch API를 사용합니다.
메모: RTO/ RPO 개념 설명
- 회사는 개발 환경의 단일 Amazon EC2 인스턴스에서 데이터베이스를 실행합니다. 데이터는 EC2 인스턴스에 연결된 별도의 Amazon EBS 볼륨에 저장됩니다. EC2 인스턴스를 가리키도록 Amazon Route 53 A 레코드가 생성 및 구성되었습니다. 회사는 인스턴스 또는 가용 영역(AZ)이 실패할 때 데이터베이스 인스턴스 복구를 자동화하려고 합니다. 회사는 또한 비용을 낮게 유지하기를 원합니다. RTO는 4시간이고 RPO는 12시간입니다.
DevOps 엔지니어는 이러한 요구 사항을 충족하기 위해 어떤 솔루션을 구현해야 합니까?
- 여러 AZ에서 최소 및 최대 인스턴스 수가 1인 Auto Scaling 그룹에서 데이터베이스를 실행합니다. Auto Scaling 그룹에 수명 주기 후크를 추가하고 수명 주기 이벤트가 발생할 때 트리거되는 Amazon CloudWatch Events 규칙을 정의합니다. CloudWatch Events 규칙이 AWS Lambda 함수를 호출하여 이벤트를 기반으로 EC2 인스턴스에서 Amazon EBS 데이터 볼륨을 분리하거나 연결하도록 합니다. 데이터 볼륨을 탑재하도록 EC2 인스턴스 UserData를 구성한 다음(실패 시 짧은 지연으로 재시도) 데이터베이스를 시작하고 Route 53 레코드를 업데이트합니다.
- 하나는 활성 상태이고 다른 하나는 대기 상태인 서로 다른 AZ에 있는 두 개의 개별 EC2 인스턴스에서 데이터베이스를 실행합니다. 활성 인스턴스에 데이터 볼륨을 연결합니다. EC2 인스턴스 종료 시 AWS Lambda 함수를 호출하도록 Amazon CloudWatch Events 규칙을 구성합니다. Lambda 함수는 대체 EC2 인스턴스를 시작합니다. 종료된 인스턴스가 활성 노드인 경우 함수는 데이터 볼륨을 대기 노드에 연결합니다. 데이터베이스를 시작하고 Route 53 레코드를 업데이트합니다.
- 여러 AZ에서 최소 및 최대 인스턴스 수가 1인 Auto Scaling 그룹에서 데이터베이스를 실행합니다. 4시간마다 예약된 Amazon CloudWatch Events 규칙에 의해 트리거되는 AWS Lambda 함수를 생성하여 데이터 볼륨의 스냅샷을 만들고 태그를 적용합니다. 인스턴스 UserData가 최신 스냅샷을 가져오고 여기에서 새 볼륨을 만들고 볼륨을 연결 및 마운트하도록 합니다. 그런 다음 데이터베이스를 시작하고 Route 53 레코드를 업데이트합니다.
- 서로 다른 AZ에 있는 두 개의 개별 EC2 인스턴스에서 데이터베이스를 실행합니다. 인스턴스 중 하나를 마스터로 구성하고 다른 하나를 대기로 구성합니다. 마스터와 대기 인스턴스 간의 복제를 설정합니다. Route 53 레코드가 마스터를 가리키도록 합니다. EC2 인스턴스 종료 시 AWS Lambda 함수를 호출하도록 Amazon CloudWatch Events 규칙을 구성합니다. Lambda 함수는 대체 EC2 인스턴스를 시작합니다. 종료된 인스턴스가 활성 노드인 경우 함수는 대기를 마스터로 승격하고 Route 53 레코드를 가리킵니다.
- 클라이언트 회사의 애플리케이션 내의 보안 취약점을 평가하고 식별된 모든 문제를 해결할 계획을 제안하기 위해 컨설팅 회사를 고용했습니다. 아키텍처는 콘텐츠용 Amazon S3 스토리지, Amazon EBS 스토리지가 연결된 Elastic Load Balancer 뒤에 있는 Amazon EC2 인스턴스의 Auto Scaling 그룹, Amazon RDS MySQL 데이터베이스로 식별됩니다. 또한 코드의 연결 문자열 문을 사용하여 RDS 데이터베이스와 직접 통신하는 여러 AWS Lambda 함수가 있습니다.
컨설턴트는 다음과 같이 가장 큰 보안 위협을 식별했습니다. 응용 프로그램이 미사용 암호화 요구 사항을 충족하지 않습니다.
최소한의 운영 오버헤드로 이 문제를 해결하고 잠재적인 향후 위반에 대한 모니터링을 제공하는 솔루션은 무엇입니까?- S3 버킷 및 RDS 데이터베이스에서 SSE 암호화를 활성화합니다. EBS 볼륨에서 데이터의 OS 기반 암호화를 활성화합니다. 안전하지 않은 암호화 암호를 보고하도록 EC2 인스턴스에서 Amazon Inspector 에이전트를 구성합니다. 암호화되지 않은 S3 객체를 주기적으로 확인하도록 AWS Config 규칙을 설정합니다.
- Amazon S3에 저장하기 전에 각 파일을 암호화하도록 애플리케이션을 구성합니다. EBS 볼륨에서 데이터의 OS 기반 암호화를 활성화합니다. RDS에 쓸 때 데이터를 암호화합니다. 각 인스턴스에서 cron 작업을 실행하여 암호화되지 않은 데이터를 확인하고 Amazon SNS를 통해 알립니다. S3 이벤트를 사용하여 AWS Lambda 함수를 호출하고 파일이 암호화되었는지 확인합니다.
- 로드 밸런서에서 SSL(Secure Sockets Layer)을 활성화하고 AWS Lambda가 SSL을 사용하여 RDS 데이터베이스와 통신하는지 확인하고 S3 암호화를 활성화합니다. 들어오는 연결에 SSL을 적용하도록 애플리케이션을 구성하고 세션이 암호화된 경우에만 액세스 권한을 부여하도록 RDS를 구성합니다. 안전하지 않은 암호화 암호를 보고하도록 EC2 인스턴스에서 Amazon Inspector 에이전트를 구성합니다.
- S3 버킷, EBS 볼륨 및 RDS 데이터베이스에서 SSE 암호화를 활성화합니다. EC2 Parameter Store에 RDS 자격 증명을 저장합니다. S3 버킷에서 암호화되지 않은 넣기를 거부하는 정책을 활성화합니다. 암호화되지 않은 S3 객체 및 EBS 볼륨을 주기적으로 확인하고 RDS 스토리지가 암호화되었는지 확인하도록 AWS Config 규칙을 설정합니다.
- OpenSSL에서 Amazon Linux에서 실행되는 프로덕션 웹 플릿의 즉각적인 패치가 필요한 새로운 제로 데이 취약점이 발견되었습니다. 현재 OS 업데이트는 매월 수동으로 수행되며 프로덕션 Auto Scaling Group의 시작 구성에 대한 업데이트를 사용하여 배포됩니다.
다운타임 없이 패키지를 인플레이스에서 업데이트하기 위해 DevOps 엔지니어는 어떤 방법을 사용해야 합니까?
- AWS CodePipline 및 AWS CodeBuild를 사용하여 이러한 패키지의 새 복사본을 생성하고 Auto Scaling 그룹의 시작 구성을 업데이트합니다.
- AWS Inspector를 사용하여 실행 중인 모든 프로덕션 인스턴스에서 "yum 업그레이드"를 실행하고 다음 유지 관리 기간을 위해 AMI를 수동으로 업데이트합니다.
- Amazon EC2 Run Command를 사용하여 실행 중인 모든 프로덕션 인스턴스에 패키지 업데이트 명령을 실행하고 향후 배포를 위해 AMI를 업데이트합니다.
- 실행 중인 프로덕션 인스턴스와 일치하도록 새 AWS OpsWorks 계층을 정의하고 레시피를 사용하여 실행 중인 모든 프로덕션 인스턴스에 패키지 업데이트 명령을 실행합니다.
- 회사는 Amazon Route 53, AWS Elastic Beanstalk 및 Amazon RDS를 사용하는 단일 AWS 계정에서 프로덕션 애플리케이션 워크로드를 실행합니다. 보안 사고 발생 시 보안 팀은 애플리케이션 워크로드가 새 AWS 계정으로 장애 조치되기를 원합니다. 또한 보안 팀은 포렌식 분석 중에 원래 AWS 계정의 AWS 리소스에 대한 액세스 없이 원래 계정에 대한 모든 액세스를 즉시 차단하려고 합니다.
보안 사고가 발생하기 전에 두 번째 계정으로 장애 조치를 준비하는 가장 비용 효율적인 방법은 무엇입니까?
- Amazon Route 53 구성을 전용 AWS 계정으로 마이그레이션합니다. 다른 계정에서 Elastic Beanstalk 구성을 미러링합니다. 다른 계정에서 RDS 데이터베이스 읽기 전용 복제본을 활성화합니다.
- Amazon Route 53 구성을 전용 AWS 계정으로 마이그레이션합니다. 다른 AWS 계정에 Elastic Beanstalk 구성 파일을 저장/복사합니다. RDS 데이터베이스의 스냅샷을 다른 계정에 복사합니다.
- 사고 후 다른 AWS 계정에서 사용할 수 있도록 Amazon Route 53 구성을 저장/복사합니다. Elastic Beanstalk 구성 파일을 다른 계정에 저장/복사합니다. 다른 계정에서 RDS 데이터베이스 읽기 전용 복제본을 활성화합니다.
- 사고 후 다른 AWS 계정에서 사용할 수 있도록 Amazon Route 53 구성을 저장/복사합니다. 다른 계정에서 Elastic Beanstalk의 구성을 미러링합니다. RDS 데이터베이스의 스냅샷을 다른 계정에 복사합니다.
- 두 팀이 아키텍처의 서로 다른 부분에서 함께 작업하고 있으며 AWS CloudFormation을 사용하여 리소스를 관리하고 있습니다. 한 팀은 운영 체제 수준 업데이트 및 패치를 관리하고 다른 팀은 애플리케이션 수준 종속성 및 업데이트를 관리합니다. 애플리케이션 팀은 새 인스턴스를 생성하고 애플리케이션을 배포할 때 최신 AMI를 사용해야 합니다.
이 두 팀과 프로세스를 연결하기 위한 가장 확장 가능한 방법은 무엇입니까?
- 운영 체제 팀은 CloudFormation을 사용하여 AMI의 새 버전을 생성하고 스택 출력 섹션의 일부로 암호화된 Amazon S3 객체에 AMI의 Amazon 리소스 이름(ARN)을 나열합니다. 애플리케이션 팀은 교차 스택 참조를 사용하여 암호화된 S3 객체를 로드하고 가장 최근의 AMI ARN을 얻습니다.
- 운영 체제 팀은 CloudFormation 스택을 사용하여 새 AMI를 구축하는 AWS CodePipeline 파이프라인을 생성한 다음 최신 AMI ARN을 파이프라인 출력의 일부로 암호화된 Amazon S3 객체에 배치합니다. 애플리케이션 팀은 자체 CloudFormation 템플릿 내에서 교차 스택 참조를 사용하여 해당 S3 객체 위치를 가져오고 애플리케이션을 배포할 때 사용할 최신 AMI ARN을 가져옵니다.
- 운영 체제 팀은 CloudFormation 스택을 사용하여 새 AMI를 구축하는 AWS CodePipeline 파이프라인을 생성합니다. 그런 다음 팀은 AMI ARN을 파이프라인 출력의 일부로 AWS Systems Manager Parameter Store의 매개변수로 배치합니다. 애플리케이션 팀은 Parameter Store에서 최신 AMI ARN을 얻기 위해 CloudFormation 스택에서 SSM 유형의 매개변수를 지정합니다.
- 운영 체제 팀은 운영 체제와 애플리케이션 팀 템플릿을 모두 포함하는 중첩 스택을 유지 관리합니다. 운영 체제 팀은 애플리케이션 팀이 애플리케이션 코드를 변경할 때마다 스택 업데이트를 사용하여 애플리케이션 스택에 업데이트를 배포합니다.
- 개발팀은 최근 몇 달 동안 크게 성장했으며 별도의 코드 저장소를 사용하는 프로젝트 수도 늘어났습니다. 현재 프로세스에는 AWS CodePipeline을 수동으로 구성하는 작업이 포함됩니다. 존재하는 Amazon S3 버킷 수에 대한 서비스 제한 알림이 있습니다.
S3 버킷 스프롤 알림을 줄이는 파이프라인 옵션은 무엇입니까?
- 여러 개별 코드 리포지토리를 하나로 결합하고 각 프로젝트에 대한 로직이 있는 AWS CodePipeline을 사용하여 배포합니다.
- AWS API 또는 AWS CLI를 사용하여 새 파이프라인을 만들고 각 프로젝트에 대해 별도의 접두사가 있는 단일 S3 버킷을 사용하도록 구성합니다.
- 단일 지역의 S3 버킷에 대한 서비스 제한을 우회하려면 프로젝트마다 다른 지역에 새 파이프라인을 생성하십시오.
- 단일 계정에서 S3 버킷에 대한 서비스 제한을 우회하기 위해 AWS API 또는 AWS CLI를 사용하여 각 프로젝트에 대한 새 파이프라인 및 S3 버킷을 생성합니다.
- 한 스타트업 회사가 AWS에서 웹 애플리케이션을 개발하고 있습니다. 지속성을 위해 Amazon RDS를 사용하고 Auto Scaling 그룹과 함께 Amazon EC2에 애플리케이션을 배포할 계획입니다. 회사는 또한 개발, 테스트 및 생산을 위한 환경을 분리하려고 합니다.
애플리케이션 구성을 관리하기 위한 가장 안전한 접근 방식은 무엇입니까?
- 구성 및 암호화된 비밀번호를 포함하는 특성 파일을 작성하십시오. 특성 파일을 소스 리포지토리에 체크인하고 애플리케이션과 함께 특성 파일을 패키징하고 애플리케이션을 배포합니다. EC2 인스턴스에 대한 환경 태그를 생성하고 인스턴스에 각각 태그를 지정합니다. 애플리케이션은 환경 태그를 기반으로 필요한 속성 값을 추출합니다.
- 환경별 구성 및 암호화된 암호를 포함하도록 각 환경에 대한 속성 파일을 만듭니다. 특성 파일을 소스 저장소에 체크인하십시오. 배포 중에는 애플리케이션과 함께 환경별 속성 파일만 사용하십시오. 애플리케이션은 배포된 속성 파일에서 필요한 속성 값을 읽습니다.
- 환경별 구성을 포함하도록 각 환경에 대한 속성 파일을 만듭니다. 프라이빗 Amazon S3 버킷을 생성하고 버킷에 속성 파일을 저장합니다. AWS KMS 암호화를 사용하여 버킷에 암호를 저장합니다. 배포 중에 애플리케이션은 S3 버킷의 환경별 속성 파일에서 필요한 속성 값을 읽습니다.
- 환경별 구성을 포함하도록 각 환경에 대한 속성 파일을 만듭니다. 프라이빗 Amazon S3 버킷을 생성하고 버킷에 속성 파일을 저장합니다. AWS Systems Manager Parameter Store에 암호화된 암호를 저장합니다. EC2 인스턴스에 대한 환경 태그를 생성하고 인스턴스에 각각 태그를 지정합니다. 애플리케이션은 S3 버킷 및 파라미터 스토어의 환경별 속성 파일에서 필요한 속성 값을 읽습니다.
- DevOps 엔지니어는 EC2 Auto Scaling 그룹의 Amazon EC2 인스턴스 전체에서 AWS CodeDeploy를 사용하고 있습니다. EC2 Auto Scaling과 통합된 연결된 CodeDeploy 배포 그룹은 CodeDeployDefault.OneAtATime을 사용하여 인플레이스 배포를 수행하도록 구성됩니다. 진행 중인 새 배포 중에 엔지니어는 전체 배포가 성공적으로 완료되었지만 인스턴스 5개 중 2개가 이전 애플리케이션 버전이 배포되었음을 발견했습니다. 다른 세 인스턴스에는 최신 애플리케이션 개정판이 있습니다.
이 문제의 원인은 무엇입니까?
- 영향을 받는 두 인스턴스가 새 배포를 가져오지 못했습니다.
- 실패한 AfterInstall 수명 주기 이벤트 후크로 인해 CodeDeploy 에이전트가 영향을 받는 인스턴스에서 이전 버전으로 롤백되었습니다.
- 영향을 받는 두 인스턴스에 CodeDeploy 에이전트가 설치되지 않았습니다.
- 새 배포가 아직 완료되지 않은 동안 EC2 Auto Scaling에서 두 개의 새 인스턴스를 시작하여 이전 버전이 영향을 받는 인스턴스에 배포되었습니다.
- 회사는 프로덕션 환경에서 ELB Application Load Balancer 뒤의 Amazon EC2 인스턴스로 구성된 단일 AWS CloudFormation 템플릿에 구축된 3계층 웹 애플리케이션을 실행합니다. 인스턴스는 여러 가용 영역에 걸쳐 EC2 Auto Scaling 그룹에서 실행됩니다. 데이터는 읽기 전용 복제본이 있는 Amazon RDS 다중 AZ DB 인스턴스에 저장됩니다. Amazon Route 53은 애플리케이션의 퍼블릭 DNS 레코드를 관리합니다.
DevOps 엔지니어는 새 애플리케이션 소프트웨어에 대한 소프트웨어 컷오버가 발생할 때 프로덕션 환경의 변경 사항을 롤백하여 실패한 소프트웨어 배포를 완화하는 워크플로우를 생성해야 합니다.
가동 중지 시간을 최소화하면서 이러한 요구 사항을 충족하려면 엔지니어가 수행해야 하는 단계는 무엇입니까?- CloudFormation을 사용하여 추가 스테이징 환경을 배포하고 가중치 레코드로 Route 53 DNS를 구성합니다. 컷오버 중에 Route 53 A 레코드 가중치를 변경하여 두 환경 간에 트래픽을 고르게 분배하십시오. 새 환경에서 트래픽을 검증하고 테스트가 성공하면 이전 환경을 즉시 종료합니다.
- 단일 AWS Elastic Beanstalk 환경을 사용하여 스테이징 및 프로덕션 환경을 배포합니다. 새 애플리케이션 코드로 ZIP 파일을 업로드하여 환경을 업데이트합니다. Elastic Beanstalk 환경 CNAME을 교체합니다. 새 환경에서 트래픽을 검증하고 테스트가 성공하면 이전 환경을 즉시 종료합니다.
- 단일 AWS Elastic Beanstalk 환경과 AWS OpsWorks 환경을 사용하여 스테이징 및 프로덕션 환경을 배포합니다. 새 애플리케이션 코드가 포함된 ZIP 파일을 OpsWorks 스택과 함께 배포된 Elastic Beanstalk 환경에 업로드하여 환경을 업데이트합니다. 새 환경에서 트래픽을 검증하고 테스트가 성공하면 이전 환경을 즉시 종료합니다.
- AWS CloudFormation을 사용하여 추가 스테이징 환경을 배포하고 가중치 레코드로 Route 53 DNS를 구성합니다. 컷오버 중에 워크로드가 성공적으로 검증되면 더 많은 트래픽이 새 스테이징 환경으로 전달되도록 가중치 분포를 늘립니다. 새 스테이징 환경이 모든 트래픽을 처리할 때까지 기존 프로덕션 환경을 그대로 유지합니다.
- 회사에서 유출 및 손상된 IAM 액세스 키로 인한 보안 위협을 처리하기 위한 방법론을 채택하려고 합니다. DevOps 엔지니어는 사용자 식별, 권한 취소, 보안 팀에 알림 보내기를 포함하여 손상된 액세스 키에 대한 작업 프로세스를 자동화하라는 요청을 받았습니다.
다음 중 이 목표를 달성하는 것은 무엇입니까?
- 액세스 키에 대해 AWS Trusted Advisor에서 생성한 보안 보고서를 사용하십시오. Amazon EMR을 사용하여 보고서에 대한 분석을 실행합니다. 손상된 IAM 액세스 키를 식별하고 삭제합니다. EMR 클러스터 상태 변경 이벤트와 함께 Amazon CloudWatch를 사용하여 보안 팀에 알립니다.
- AWS Trusted Advisor를 사용하여 손상된 액세스 키를 식별합니다. Trusted Advisor를 이벤트 소스로 사용하고 AWS Lambda 및 Amazon SNS를 대상으로 하는 Amazon CloudWatch Events 규칙을 생성합니다. AWS Lambda를 사용하여 손상된 IAM 액세스 키를 삭제하고 Amazon SNS를 사용하여 보안 팀에 알립니다.
- 액세스 키에 대해 AWS Trusted Advisor에서 생성한 보안 보고서를 사용하십시오. AWS Lambda를 사용하여 보고서를 스캔합니다. AWS Lambda 내부의 스캔 결과를 사용하고 손상된 IAM 액세스 키를 삭제하십시오. Amazon SNS를 사용하여 보안 팀에 알립니다.
- 타사 라이브러리와 함께 AWS Lambda를 사용하여 손상된 액세스 키를 검색합니다. AWS Lambda 내부의 스캔 결과를 사용하고 손상된 IAM 액세스 키를 삭제하십시오. 손상된 키에 대한 Amazon CloudWatch 사용자 지정 지표를 생성합니다. 지표에 대한 CloudWatch 경보를 생성하여 보안 팀에 알립니다.
- 회사에서 Amazon ECS를 사용하여 Docker 컨테이너 런타임 환경을 제공하려고 합니다. 규정 준수를 위해 ECS 클러스터에서 사용되는 모든 Amazon EBS 볼륨은 암호화되어야 합니다. 클러스터 인스턴스에 대한 롤링 업데이트가 이루어지며 회사는 인스턴스가 종료되기 전에 모든 작업에서 배출되기를 원합니다.
이러한 요구 사항을 어떻게 충족할 수 있습니까? (두 가지를 선택하세요.)
- 기본 ECS AMI 사용자 데이터를 수정하여 실행 중인 모든 컨테이너 인스턴스에 대해 docker rm –f {id}를 실행하는 스크립트를 생성합니다. 스크립트를 /etc/init.d/rc.d 디렉토리에 복사하고 chconfig를 실행하여 운영 체제 종료 중에 스크립트를 실행할 수 있도록 합니다.
- AWS CodePipeline을 사용하여 최신 Amazon 제공 ECS AMI를 검색하는 파이프라인을 구축한 다음 암호화된 AMI ID를 출력하는 암호화된 AMI에 이미지를 복사합니다. 클러스터를 배포할 때 암호화된 AMI ID를 사용합니다.
- ECS가 클러스터 인스턴스를 배포하는 데 사용하는 기본 AWS CloudFormation 템플릿을 복사합니다. 템플릿 리소스 EBS 구성 설정을 수정하여 'Encrypted: True'를 설정하고 AWS KMS 별칭: 'aws/ebs'를 포함하여 AMI를 암호화합니다.
- 종료 인스턴스를 DRAINING으로 표시하기 위해 AWS SDK를 사용하는 AWS Lambda 함수가 지원하는 Auto Scaling 수명 주기 후크를 생성합니다. 인스턴스에서 실행 중인 작업이 0이 될 때까지 수명 주기 후크가 완료되지 않도록 합니다.
- ECS::EncryptedImage 작업을 허용하는 IAM 역할을 생성합니다. 이 역할을 사용하도록 AWS CLI 및 프로필을 구성합니다. create-cluster ECS 명령에 –use-encrypted-image 및 –kms-key 인수를 제공하는 AWS CLI를 사용하여 클러스터를 시작합니다.
- 정부 기관에는 여러 AWS 계정이 있으며 그 중 다수는 민감한 시민 정보를 저장합니다. 보안 팀은 모든 계정에서 비정상적인 계정 및 네트워크 활동(예: SSH 무차별 암호 대입 공격)을 감지하고 해당 정보를 전용 보안 계정에 중앙 집중화하려고 합니다. 이벤트 정보는 부서의 보안 정보 및 이벤트 관리(SIEM) 시스템에서 모니터링하는 보안 계정의 Amazon S3 버킷에 저장해야 합니다.
이것이 어떻게 이루어질 수 있습니까?
- 모든 계정에서 Amazon Macie를 활성화합니다. 초대/수락을 사용하여 모든 멤버 계정에 대해 보안 계정을 Macie 관리자로 구성합니다. 보안 계정에서 Amazon CloudWatch Events 규칙을 생성하여 모든 결과를 Amazon Kinesis Data Firehose로 보내면 결과를 S3 버킷으로 푸시해야 합니다.
- 보안 계정에서만 Amazon Macie를 활성화합니다. 초대/수락을 사용하여 모든 멤버 계정에 대해 보안 계정을 Macie 관리자로 구성합니다. 보안 계정에서 Amazon CloudWatch Events 규칙을 생성하여 모든 결과를 Amazon Kinesis Data Streams로 보냅니다. KCL을 사용하여 Kinesis Data Streams에서 데이터를 읽고 S3 버킷에 쓰는 애플리케이션을 작성합니다.
- 모든 계정에서 Amazon GuardDuty를 활성화합니다. 초대/수락을 사용하여 모든 멤버 계정에 대해 보안 계정을 GuardDuty Administrator로 구성합니다. 보안 계정에서 Amazon CloudWatch 규칙을 생성하여 모든 결과를 Amazon Kinesis Data Firehose로 보내면 결과를 S3 버킷으로 푸시합니다.
- 보안 계정에서만 Amazon GuardDuty를 활성화합니다. 초대/수락을 사용하여 모든 멤버 계정에 대해 보안 계정을 GuardDuty Administrator로 구성합니다. 보안 계정에서 Amazon CloudWatch 규칙을 생성하여 모든 결과를 Amazon Kinesis Data Streams로 보냅니다. KCL을 사용하여 Kinesis Data Streams에서 데이터를 읽고 S3 버킷에 쓰는 애플리케이션을 작성합니다.
- AWS CodePipeline 파이프라인은 코드 릴리스 프로세스를 구현했습니다. 파이프라인은 AWS CodeDeploy와 통합되어 각 CodePipeline 단계의 여러 Amazon EC2 인스턴스에 애플리케이션 버전을 배포합니다.
최근 배포 중에 CodeDeploy 문제로 인해 파이프라인이 실패했습니다. DevOps 팀은 해결 시간을 줄이기 위해 배포 중 모니터링 및 알림을 개선하려고 합니다.
DevOps 엔지니어는 문제가 발견되었을 때 알림을 생성하기 위해 무엇을 해야 합니까?- CodePipeline 및 CodeDeploy에 대한 AWS CloudWatch Logs를 구현하고, 코드 배포 문제를 평가하기 위한 AWS Config 규칙을 생성하고, 이해 관계자에게 배포 문제를 알리는 Amazon SNS 주제를 생성합니다.
- CodePipeline 및 CodeDeploy에 대한 AWS CloudWatch 이벤트를 구현하고, 코드 배포 문제를 평가하는 AWS Lambda 함수를 생성하고, 이해 관계자에게 배포 문제를 알리는 Amazon SNS 주제를 생성합니다.
- AWS CloudTrail을 구현하여 CodePipeline 및 CodeDeploy API 호출 정보를 기록하고, AWS Lambda 함수를 생성하여 코드 배포 문제를 평가하고, Amazon SNS 주제를 생성하여 이해 관계자에게 배포 문제를 알립니다.
- CodePipeline 및 CodeDeploy에 대한 AWS CloudWatch Events를 구현하고 Amazon Inspector 평가 대상을 생성하여 코드 배포 문제를 평가하고 Amazon SNS 주제를 생성하여 이해 관계자에게 배포 문제를 알립니다.
- 회사는 Application Load Balancer 뒤의 Amazon EC2 인스턴스에서 애플리케이션을 실행합니다. 인스턴스는 us-east-1의 여러 가용 영역에 걸쳐 Amazon EC2 Auto Scaling 그룹에서 실행됩니다. 애플리케이션은 Amazon RDS MySQL 다중 AZ DB 인스턴스에 데이터를 저장합니다.
DevOps 엔지니어는 us-east-1에서 문제가 발생할 경우 다운타임을 최소화하기 위해 현재 솔루션을 수정하고 다른 지역에서 환경의 상시 대기를 생성하려고 합니다.
DevOps 엔지니어는 이러한 요구 사항을 충족하기 위해 어떤 단계 조합을 수행해야 합니까? (3개를 선택하세요.)- Amazon Route 53 별칭 레코드에 상태 확인을 추가하여 기본 지역의 상태를 평가합니다. Amazon CloudWatch Events 트리거로 구성된 AWS Lambda를 사용하여 재해 복구 리전에서 Amazon RDS 읽기 전용 복제본을 승격합니다.
- 재해 복구 지역에서 새 Application Load Balancer 및 Amazon EC2 Auto Scaling 그룹을 생성합니다.
- 현재 Amazon EC2 Auto Scaling 그룹을 재해 복구 지역의 서브넷으로 확장합니다.
- 데이터베이스 인스턴스의 RDS 구성에 대해 다중 지역 장애 조치를 활성화합니다.
- 재해 복구 지역에 RDS 인스턴스의 읽기 복제본을 배포합니다.
- 기본 지역의 상태를 평가하는 AWS Lambda 함수를 생성합니다. 실패하면 재해 복구 지역을 가리키도록 Amazon Route 53 레코드를 수정하고 RDS 읽기 전용 복제본을 승격하십시오.
- DevOps 엔지니어는 Amazon EFS용 백업 메커니즘을 설계하고 구현해야 합니다.
– 엔지니어에게는 다음과 같은 요구 사항이 주어집니다.
– 백업은 일정대로 실행되어야 합니다.
– 백업 기간이 만료되면 백업을 중지해야 합니다.
– 백업 기간 전에 백업이 완료되면 백업을 중지해야 합니다.
– 추가 분석을 위해 백업 로그를 보관해야 합니다.
– 설계는 고가용성 및 내결함성 패러다임을 지원해야 합니다.
– 관리자에게 백업 메타데이터를 알려야 합니다.
이러한 요구 사항을 충족하는 디자인은 무엇입니까?- Amazon CloudWatch Events 규칙과 함께 AWS Lambda를 사용하여 백업 활동의 시작/중지를 예약하십시오. Auto Scaling 그룹의 Amazon EC2에서 백업 스크립트를 실행합니다. Amazon S3에 백업 로그를 업로드하려면 EC2에서 Auto Scaling 수명 주기 후크 및 SSM Run Command를 사용하십시오. Amazon SNS를 사용하여 백업 활동 메타데이터로 관리자에게 알립니다.
- 백업 활동의 시작/중지를 예약하려면 Amazon CloudWatch Events 규칙과 함께 Amazon SWF를 사용하십시오. Auto Scaling 그룹의 Amazon EC2에서 백업 스크립트를 실행합니다. Amazon Redshift에 백업 로그를 업로드하려면 EC2에서 Auto Scaling 수명 주기 후크 및 SSM Run Command를 사용하십시오. CloudWatch 경보를 사용하여 관리자에게 백업 활동 메타데이터를 알립니다.
- Amazon CloudWatch Events 규칙과 함께 AWS Data Pipeline을 사용하여 백업 활동의 시작/중지를 예약하십시오. 단일 가용 영역의 Amazon EC2에서 백업 스크립트를 실행합니다. 백업 로그를 Amazon RDS에 업로드하려면 EC2에서 Auto Scaling 수명 주기 후크 및 SSM Run Command를 사용하십시오. Amazon SNS를 사용하여 백업 활동 메타데이터로 관리자에게 알립니다.
- Amazon CloudWatch Events 규칙과 함께 AWS CodePipeline을 사용하여 백업 활동의 시작/중지를 예약하십시오. 단일 가용 영역의 Amazon EC2에서 백업 스크립트를 실행합니다. Amazon S3에 백업 로그를 업로드하려면 Amazon EC2에서 Auto Scaling 수명 주기 후크 및 SSM Run Command를 사용하십시오. Amazon SES를 사용하여 백업 활동 메타데이터로 관리자에게 알립니다.
정답 |
|
반응형
'AWS > DOP' 카테고리의 다른 글
[DOP-C01] AWS DevOps Engineer Professional : Part 07 (0) | 2023.02.28 |
---|---|
[DOP-C01] AWS DevOps Engineer Professional : Part 06 (0) | 2023.02.28 |
[DOP-C01] AWS DevOps Engineer Professional : Part 04 (0) | 2023.02.27 |
[DOP-C01] AWS DevOps Engineer Professional : Part 03 (0) | 2023.02.27 |
[DOP-C01] AWS DevOps Engineer Professional : Part 02 (0) | 2023.02.27 |
Comments