Ngân hàng đề — AWS Certified DevOps Engineer Professional
Tìm thấy 681 câu.
A dedicated group has been created for each team. The DevOps team's group has been assigned a permission set named DevOps. The permission set has the AdministratorAccess managed IAM policy attached. The permission set has been applied to all accounts in the organization.
The security team wants to ensure that the DevOps team does not have access to IAM Identity Center in the organization's management account. The security team has attached the following SCP to the organization root:
After implementing the policy, the security team discovers that the DevOps team can still access IAM Identity Center.
Which solution will fix the problem?
- A In the organization's management account, create a new OU. Move the organization's management account to the new OU. Detach the SCP from the organization root. Attach the SCP to the new OU.
- B In the organization's management account, update the SCP condition reference to the ARN of the DevOps team's group role to include the AWS account ID of the organization's management account.
- C In IAM Identity Center, create a new permission set. Ensure that the assigned policy has full access but explicitly denies permission for the sso:* action and the sso-directory:* action. Update the assigned permission set for the DevOps team's group role in the organization's management account. Delete the SCP.
- D In IAM Identity Center, update the DevOps permission set. Ensure that the assigned policy has full access but explicitly denies permission for the sso:* action and the sso-directory:* action. In the Deny statement, add a StringEquals condition that compares the aws:SourceAccount global condition context key with the organization's management account IDelete the SCP.
Xem giải thích
Đáp án
D — Cập nhật permission set của nhóm DevOps trong IAM Identity Center
Vì sao đúng
Trong IAM Identity Center, permission set chính là thứ quyết định một nhóm được làm gì khi họ đăng nhập vào một tài khoản. Khi nhóm DevOps thiếu quyền, chỗ phải sửa là permission set đang gán cho họ — sửa xong thì Identity Center tự đẩy thay đổi xuống mọi tài khoản mà nhóm đó có quyền vào, không phải làm lại từng tài khoản.
Vì sao các phương án khác sai
- A. Tạo OU mới rồi chuyển tài khoản quản lý vào — tài khoản quản lý của tổ chức không chuyển vào OU được, và cấu trúc lại OU là việc quá lớn cho một vấn đề phân quyền.
- B. Sửa điều kiện của SCP — SCP đặt trần quyền; nới trần ra để chữa việc thiếu quyền là đi sai hướng và làm yếu hàng rào chung.
- C. Tạo permission set mới — chạy được nhưng để lại hai bộ quyền song song cho cùng một nhóm, càng lúc càng khó lần; sửa cái đang dùng gọn hơn.
A global financial services company manages over 100 accounts using AWS Organizations and it has recently come to light that several accounts and regions did not have AWS CloudTrail enabled. It also wants to be able to track the compliance of the CloudTrail enablement as a dashboard, and automatically be alerted in case of issues. The company has hired you as an AWS Certified DevOps Engineer Professional to build a solution for this requirement.
How would you go about implementing a solution for this use-case?
-
A
Create a CloudFormation template to enable CloudTrail. Create a StackSet and deploy that StackSet in all your accounts and regions under the AWS organization. Create one CloudFormation template in a centralized account to enable AWS Config, and create a Config rule to track if CloudTrail is enabled. Create an AWS Config aggregator for a centralized account to track compliance across all the other accounts. Create an SNS topic to get notifications when compliance is breached, and subscribe a Lambda function to it, that will send out these notifications
-
B
Create a CloudFormation template to enable CloudTrail. Create a StackSet and deploy that StackSet in all your accounts and regions under the AWS organization. Create another CloudFormation StackSet to enable AWS Config, and create a Config rule to track if CloudTrail is enabled. Create an AWS Config aggregator for a centralized account to track compliance. Create a CloudWatch Event to generate events when compliance is breached, and subscribe a Lambda function to it, that will send out notifications
-
C
Create a CloudFormation template to enable CloudTrail. Create a StackSet and deploy that StackSet in all your accounts and regions under the AWS organization. Create one CloudFormation template in a centralized account to enable AWS Config, and create a Config rule to track if CloudTrail is enabled. Create an AWS Config aggregator for a centralized account to track compliance across all the other accounts. Create a CloudWatch Event to generate events when compliance is breached, and subscribe a Lambda function to it, that will send out notifications
-
D
Create a CloudFormation template to enable CloudTrail. Create a StackSet and deploy it in all your accounts and regions under the AWS organization. Create another StackSet to enable AWS Config, and create a Config rule to track if CloudTrail is enabled. Create an AWS Config aggregator for a centralized account to track compliance across all the other accounts. Create an SQS topic to get notifications when compliance is breached, and subscribe a Lambda function to it, that will send out these notifications
Xem giải thích
Đáp án
B — Dùng CloudFormation StackSet để bật CloudTrail trên mọi tài khoản và Region, rồi dùng một StackSet nữa để bật AWS Config và tạo Config Rule kiểm tra CloudTrail
Vì sao đúng
Đề nêu ba yêu cầu, và giải pháp cần ba mảnh ghép:
| Yêu cầu | Mảnh ghép |
|---|---|
| Bật CloudTrail ở mọi tài khoản và Region | StackSet thứ nhất — triển khai một mẫu ra toàn tổ chức bằng một thao tác |
| Bảng theo dõi mức tuân thủ | AWS Config — có sẵn bảng tổng hợp tuân thủ, và tổng hợp được đa tài khoản qua aggregator |
| Tự động cảnh báo khi có vấn đề | Config Rule (cloudtrail-enabled) phát sự kiện khi tài nguyên rơi vào trạng thái không tuân thủ |
Điểm quan trọng: AWS Config cũng phải được bật ở mọi tài khoản và Region, nên nó cũng cần một StackSet riêng. Đó chính là chỗ phương án B khác các phương án còn lại.
Vì sao các phương án khác sai
- A và C. Dùng StackSet cho CloudTrail nhưng chỉ tạo một CloudFormation template ở tài khoản trung tâm cho phần theo dõi — Config là dịch vụ theo Region và theo tài khoản; một stack ở một chỗ không thấy được tài nguyên ở tài khoản và Region khác. Đây là hai phương án nhiễu chính.
- D. Dùng StackSet cho cả CloudTrail lẫn Config nhưng phần cảnh báo bị mô tả sai — thiếu mắt xích Config Rule đánh giá đúng điều kiện "CloudTrail có được bật không".
The DevOps team at an auditing firm has deployed its flagship application on Elastic Beanstalk that processes invoices uploaded by customers in CSV form. The invoices can be quite big, with up to 10MB and 1,000,000 records total. Processing is CPU intensive which results in slowing down the application. Customers are sent an email when the processing is done, through the use of a cron job. The auditing firm has hired you as an AWS Certified DevOps Engineer Professional to build a solution for this requirement.
What do you recommend for the application to ensure a good performance and address scalability requirements?
-
A
Create a separate Beanstalk tier within the same environment that's a worker configuration and processes invoices through an SQS queue. The invoices are directly sent into SQS after being gzipped by the web tier. The workers process these files. A cron job defined using the
cron.ymlfile on the web tier will send out the emails -
B
Create a separate Beanstalk environment that's a worker environment and processes invoices through an SQS queue. The invoices are uploaded into S3 and a reference to it is sent to the SQS by the web tier. The worker tier processes these files. A cron job defined using the
cron.ymlfile will send out the emails -
C
Create a separate Beanstalk tier within the same environment that's a worker configuration and processes invoices through an SQS queue. The invoices are directly sent into SQS after being gzipped by the web tier. The workers process these files. A cron job defined using the
cron.ymlfile will send out the emails -
D
Create a separate Beanstalk environment that's a worker environment and processes invoices through an SQS queue. The invoices are uploaded into S3 and a reference to it is sent to the SQS by the web tier. The worker tier processes these files. A cron job defined using the
cron.ymlfile on the web tier will send out the emails
Xem giải thích
Đáp án
B — Tạo một environment riêng kiểu worker, xử lý hoá đơn qua hàng đợi SQS; hoá đơn được tải lên S3 và chỉ tham chiếu tới nó được gửi vào SQS
Vì sao đúng
Có hai quyết định trong phương án này, và cả hai đều cần thiết.
Thứ nhất — phải là environment riêng, không phải "tier trong cùng environment". Elastic Beanstalk không có khái niệm nhiều tier trong một environment: mỗi environment hoặc là web tier, hoặc là worker tier. Muốn có cả hai thì phải tạo hai environment, và chúng co giãn độc lập — đúng điều cần, vì việc xử lý hoá đơn ngốn CPU không nên ảnh hưởng tới khả năng phục vụ web.
Thứ hai — gửi tham chiếu, không gửi tệp. SQS giới hạn 256 KB mỗi thông điệp, còn hoá đơn tới 10 MB. Nén gzip cũng không cứu được, vì tỷ lệ nén của CSV không bảo đảm xuống dưới ngưỡng đó, và nếu có thì cũng là thiết kế mong manh. Mẫu chuẩn là:
Web tier → tải tệp lên S3 → gửi khoá S3 vào SQS → Worker tier đọc khoá rồi lấy tệp từ S3
Vì sao các phương án khác sai
- A và C. Tạo "worker tier trong cùng environment" — không tồn tại khái niệm này trong Elastic Beanstalk. Cả hai còn gửi tệp gzip thẳng vào SQS, vướng giới hạn 256 KB.
- D. Environment worker riêng, tải lên S3 và gửi tham chiếu — mô tả gần giống B; khác biệt nằm ở phần chi tiết còn lại của phương án, và B là bản mô tả đúng đầy đủ.
An Internet-of-Things (IoT) solutions company has decided to release every single application as a Docker container and to use ECS classic (on EC2) as the container orchestration system and ECR as the Docker registry. Part of implementing a monitoring pipeline is to ensure all application logs can be stored in CloudWatch logs.
The company has hired you as an AWS Certified DevOps Engineer Professional to provide the simplest possible instructions to accomplish this objective. What are these instructions?
-
A
Create ECS task definitions that include the
awslogsdriver. Set an IAM instance role on the EC2 instance with the necessary permissions to write to CloudWatch logs -
B
Create ECS task definitions that include the
awslogsdriver. Set an IAM task role in the task definition with the necessary permissions to write to CloudWatch logs -
C
Create ECS task definitions for your applications, with a sidecar container which contains the CloudWatch Agent tracking the
/var/log/containersdirectory. Map the application's/var/logdirectory onto the sidecar filesystem. Set an IAM task role in the task definition with the necessary permissions to write to CloudWatch logs -
D
Create ECS task definitions for your applications, with a mapping of the
/var/logdirectory onto the local filesystem of the EC2 instance. Install the CloudWatch Agent on the EC2 instance using user-data and track the/var/log/containersdirectory. Create an EC2 instance role with the necessary permissions to write to CloudWatch logs
Xem giải thích
Đáp án
A — Định nghĩa ECS task definition có dùng awslogs driver, và gán IAM instance role cho EC2 với quyền ghi vào CloudWatch Logs
Vì sao đúng
Chữ khoá của đề là "chỉ dẫn đơn giản nhất có thể", và awslogs là log driver dựng sẵn của Docker — chỉ cần khai trong task definition:
"logConfiguration": {
"logDriver": "awslogs",
"options": { "awslogs-group": "/ecs/ung-dung", "awslogs-region": "ap-southeast-1" }
}
Không cần cài agent, không cần container phụ, không cần ánh xạ thư mục.
Chi tiết quyết định nằm ở gán role cho ai. Với ECS trên EC2, log driver chạy ở tầng Docker daemon trên chính EC2 instance, chứ không chạy bên trong container. Vì vậy quyền phải nằm ở IAM instance role của EC2, không phải ở task role.
Vì sao các phương án khác sai
- B. Gán IAM task role trong task definition — task role cấp quyền cho mã chạy bên trong container; nó không áp cho Docker daemon. Đây là phương án nhiễu tinh vi nhất, và nó chỉ khác đáp án đúng ở một từ. (Với Fargate thì ngược lại — ở đó dùng task execution role.)
- C. Dùng container phụ (sidecar) chạy CloudWatch Agent — hoạt động được nhưng phức tạp hơn nhiều: thêm một container cho mỗi task, thêm cấu hình ánh xạ thư mục.
- D. Cài CloudWatch Agent trên EC2 qua user-data và ánh xạ
/var/log— cũng làm được nhưng thủ công hơn hẳn, và bạn phải tự quản lý agent.
The DevOps team at a geological hazard monitoring agency maintains an application that provides near real-time notifications to Android and iOS devices during tremors, volcanic eruptions and tsunamis. The team has created a CodePipeline pipeline, which consists of CodeCommit and CodeBuild, and the application is deployed on Elastic Beanstalk. The team would like to enable Blue/Green deployments for Beanstalk through CodePipeline.
As a DevOps Engineer, how would you implement a solution for this requirement?
-
A
Make CodePipeline deploy to the current Beanstalk environment using an immutable strategy. Add a CodeStar stage action afterward to enable Blue / Green configured through the
template.ymlfile -
B
Make CodePipeline deploy to a new Beanstalk environment. After that stage action, create another stage action to invoke a Custom Job using AWS Lambda, which will perform the API call to swap the CNAME of the environments
-
C
Make CodePipeline deploy to the current Beanstalk environment using a rolling with additional batch strategy. Add a CodeDeploy stage action afterward to enable Blue / Green
-
D
Make CodePipeline deploy to a new Beanstalk environment. After that stage action, create another stage action to invoke a CloudFormation template that will perform a CNAME swap
Xem giải thích
Đáp án
*B — Cho CodePipeline triển khai sang một environment Beanstalk mới, rồi thêm một stage action gọi Custom Job qua AWS Lambda để thực hiện lời gọi API hoán đổi CNAME
Vì sao đúng
Blue/Green trên Elastic Beanstalk hoạt động bằng cách hoán đổi CNAME giữa hai environment:
Trước: app.example.com → environment BLUE (bản cũ)
environment GREEN (bản mới, đã kiểm thử)
Sau: app.example.com → environment GREEN
Vấn đề là CodePipeline không có sẵn action nào thực hiện việc hoán đổi này. Deploy action của nó chỉ triển khai mã vào một environment.
Vì vậy phải tự thêm bước: một custom action gọi Lambda, và Lambda gọi API SwapEnvironmentCNAMEs. Đây là cách chuẩn được AWS ghi trong tài liệu.
Ưu điểm của Blue/Green kiểu này: quay lui gần như tức thì — chỉ cần hoán đổi CNAME lần nữa, vì environment cũ vẫn còn nguyên.
Vì sao các phương án khác sai
- D. Gọi một CloudFormation template để hoán đổi CNAME — CloudFormation không có tài nguyên nào thực hiện thao tác hoán đổi này; nó quản lý tài nguyên chứ không gọi API tuỳ ý. (Về lý thuyết có thể làm qua custom resource, nhưng khi đó bên dưới vẫn là Lambda.) Đây là phương án nhiễu chính.
- A. Dùng chiến lược immutable rồi thêm CodeStar action — immutable là chiến lược triển khai trong một environment, không phải Blue/Green; và CodeStar không có action như vậy.
- C. Dùng rolling with additional batch rồi thêm CodeDeploy action — rolling cập nhật tại chỗ, không tạo environment thứ hai nên không phải Blue/Green.
A retail company is finishing its migration to AWS and realizes that while some employees have passed the AWS Certified DevOps Engineer Professional certification and know AWS very well, other ones are still beginning and haven't passed their Associate-level certifications yet. The company has established architectural and tagging specific internal rules and would like to minimize the risk of the AWS-beginner employees launching uncompliant resources.
As a DevOps Engineer, how should you implement this requirement while allowing the employees to create the resources they need?
-
A
Create AWS Config custom rules that will check for the compliance of your company's resources thanks to a Lambda Function. Update the Lambda Function over time while your company improves its architectural and tagging rules. Provide IAM users full access to AWS
-
B
Define commonly used architectures as CloudFormation templates. Place the IAM users into a beginner group and allow the users to only launch stacks from these CloudFormation stacks, while restricting any write access to other services
-
C
Define commonly used architectures as CloudFormation templates. Create Service Catalog stacks from these templates, and ensure the tagging is done properly. Place the IAM users into a beginner group and allow the users to only launch stacks from Service Catalog, while restricting any write access to other services
-
D
Place the beginner IAM users into a group and create an IAM policy that requires conditional approvals from senior DevOps engineers upon resource creation. Hook an SNS topic into the IAM approval channel
Xem giải thích
Đáp án
*C — Định nghĩa các kiến trúc thường dùng thành CloudFormation template, tạo Service Catalog product từ chúng với thẻ được gắn sẵn, rồi cho nhóm người mới chỉ được khởi chạy từ Service Catalog
Vì sao đúng
Đề đòi hai thứ trái chiều nhau: nhân viên mới vẫn tạo được tài nguyên họ cần, nhưng không tạo được thứ vi phạm chuẩn. Service Catalog dựng chính xác cho tình huống đó.
Cách hoạt động:
- Đội có kinh nghiệm định nghĩa product từ CloudFormation template đã kiểm chứng.
- TagOptions bảo đảm mọi tài nguyên sinh ra đều mang đủ thẻ theo chuẩn — người dùng không quên được vì không có chỗ để quên.
- Launch constraint cho phép người dùng khởi chạy product bằng một IAM role có quyền cao, dù bản thân họ không có quyền tạo tài nguyên trực tiếp. Đây là điểm mấu chốt: quyền nằm ở product, không nằm ở người.
Kết quả: nhân viên mới tự phục vụ được, nhưng chỉ trong khuôn khổ đã duyệt.
Vì sao các phương án khác sai
- B. Cho phép người dùng chỉ được khởi chạy stack từ các CloudFormation template có sẵn — thiếu một mảnh quan trọng: để chạy stack, người dùng vẫn cần quyền tạo từng tài nguyên bên trong. Nghĩa là họ vẫn có thể tạo trực tiếp ngoài stack. Service Catalog giải đúng chỗ này bằng launch constraint. Đây là phương án nhiễu chính.
- A. Dùng AWS Config custom rule — chỉ phát hiện sau khi tài nguyên đã được tạo; đề muốn giảm rủi ro tạo ra chứ không phải dọn dẹp sau.
- D. IAM policy đòi phê duyệt có điều kiện từ kỹ sư cấp cao — IAM không có cơ chế phê duyệt; chính sách chỉ cho phép hoặc từ chối, không có trạng thái chờ.
The DevOps team at a presentation software company is deploying their flagship application using Elastic Beanstalk. The application is deployed using a Deploy stage in a CodePipeline pipeline. The technical requirements mandate changing the configuration of the Application Load Balancer tied to Elastic Beanstalk by adding an HTTP to HTTPS redirection rule.
As a DevOps Engineer, you don't have the permissions to directly edit the Elastic Beanstalk environment, how can you proceed?
-
A
Using the EB CLI, create a
.elasticbeanstalk/saved_configs/config.yml, and specify the rules for the keyaws:elbv2:listener:default. Run a deploy using the EB CLI from your computer onto the Elastic Beanstalk Environment -
B
Using the EB CLI, create a
.elasticbeanstalk/saved_configs/config.yml, and specify the rules for the keyaws:elbv2:listener:default. Configure CodePipeline to deploy to Elastic Beanstalk using the EB CLI and push the code -
C
Create a file named
.ebextensions/alb.configin your code repository and add acontainer_commandsblock for which you will specify a container command that will run inleader_onlymode. The EC2 instance will issue an API call to the Load Balancer to add the redirection rule -
D
Create a file named
.ebextensions/alb.configin your code repository and add anoption_settingsblock for which you will specify the Rules for the keyaws:elbv2:listener:default. Push your code and let the CodePipeline run
Xem giải thích
Đáp án
D — Tạo tệp .ebextensions/alb.config trong kho mã, khai khối option_settings với các Rules cho namespace aws:elbv2:listener:default
Vì sao đúng
Ràng buộc quyết định trong đề: bạn không có quyền sửa trực tiếp environment Elastic Beanstalk.
.ebextensions giải đúng chỗ đó — đây là cơ chế cấu hình environment bằng chính mã nguồn: bạn đặt tệp cấu hình vào kho mã, và khi CodePipeline triển khai, Beanstalk đọc và áp dụng chúng.
Nhờ vậy cấu hình đi qua quy trình review và deploy bình thường, không cần quyền sửa environment.
Về khối cần dùng: option_settings là nơi khai thiết lập cấu hình của environment — đúng loại thay đổi mà đề cần (thêm luật chuyển hướng HTTP sang HTTPS trên listener của ALB).
Vì sao các phương án khác sai
-
C. Dùng khối
container_commandsvớileader_only—container_commandschạy lệnh shell trên EC2 instance trước khi ứng dụng khởi động; nó không cấu hình được ALB, vì ALB là tài nguyên do Beanstalk quản lý ở tầng environment. Đây là phương án nhiễu chính, và cặp này đáng nhớ:option_settingscontainer_commandsCấu hình Environment (ALB, ASG, biến môi trường) Bên trong instance (chạy lệnh) -
A và B. Dùng
.elasticbeanstalk/saved_configs/config.ymlqua EB CLI — saved configuration áp trực tiếp lên environment, tức là cần quyền sửa environment — đúng thứ bạn không có.
A global health-care company has an EFS filesystem being used in eu-west-1. The company would like to plan for a disaster recovery strategy and backup that EFS file system in ap-southeast-2. It needs to have a hot copy of the data so that the applications can be re-deployed in ap-southeast-2 with a minimum RPO and RTO. The VPCs in each region are not peered with each other.
How should a DevOps engineer implement a solution for this use-case?
-
A
Create a replication cluster managed by EC2 with Auto Scaling in eu-west-1. Scale according to a Custom Metric you would publish with the application representing the lag in file reads. Replicate the data into Amazon S3 in ap-southeast-2. Create another replication cluster in ap-southeast-2 that reads from Amazon S3 and copies the files into a standby EFS cluster
-
B
Create a CloudWatch Event hourly rule that triggers an AWS Batch cluster in eu-west-1 to perform an incremental replication. Replicate the data into Amazon S3 in another region. Create an EC2 replication cluster in ap-southeast-2 that reads from Amazon S3 and copies the files into a standby EFS cluster
-
C
Create a replication cluster managed by EC2 with Auto Scaling in eu-west-1. Scale according to a Custom Metric you would publish with the application representing the lag in file reads. Create a standby EFS cluster in ap-southeast-2 and mount it on the same EC2 cluster. Let the replication software perform EFS to EFS replication
-
D
Create a CloudWatch Event hourly rule that triggers an AWS Batch cluster in eu-west-1 to perform an incremental replication. Replicate the data into Amazon S3 in another region. Create a Lambda Function in ap-southeast-2 for PUT on Amazon S3 and triggers an SSM Run Command to copy the files from S3 into EFS
Xem giải thích
Đáp án
A — Dựng cụm nhân bản trên EC2 có Auto Scaling ở eu-west-1, co giãn theo custom metric đo độ trễ đọc tệp, và nhân bản dữ liệu sang Region kia
Vì sao đúng
Ba ràng buộc trong đề cùng nhau loại bỏ mọi giải pháp đơn giản:
- Cần bản sao "nóng" (hot copy) — dữ liệu phải sẵn sàng dùng ngay, không phải khôi phục từ sao lưu.
- RPO và RTO tối thiểu — nhân bản phải liên tục, không theo chu kỳ.
- Hai VPC không peering với nhau — nên việc nhân bản phải đi qua một đường khác.
Vì vậy giải pháp phải là một tiến trình nhân bản chạy liên tục, và cụm EC2 có Auto Scaling đáp ứng: nó đọc từ EFS nguồn và ghi sang đích không ngừng.
Chi tiết co giãn theo custom metric đo độ trễ đọc tệp là phần tinh tế: nó cho biết cụm nhân bản có theo kịp tốc độ ghi hay không — chỉ số đúng để quyết định thêm hay bớt node, thay vì dùng CPU vốn không phản ánh được độ trễ nhân bản.
Vì sao các phương án khác sai
- B và D. Dùng CloudWatch Event chạy mỗi giờ để nhân bản tăng dần — chu kỳ một giờ nghĩa là RPO tối đa một giờ; vi phạm yêu cầu "RPO tối thiểu". Đây là hai phương án nhiễu chính, và chữ "hourly" là chỗ loại chúng.
- C. Cụm nhân bản kèm phần mô tả đích không tạo ra bản sao nóng — thiếu chính vế "hot copy" mà đề đòi.
Ghi chú
AWS hiện có EFS Replication — tính năng nhân bản EFS liên tục sang Region khác, được quản lý hoàn toàn. Nó ra đời sau bộ đề này; khi làm việc thật thì đó mới là lựa chọn đúng, đơn giản hơn hẳn việc tự dựng cụm.
The DevOps team at a business travel solutions company wants to use CodeDeploy to ensure zero downtime during deployments through rolling updates. The team wants to deploy the company's flagship web application on a set of 5 EC2 instances running behind an Application Load Balancer. The team would like the deployment to be gradual and to automatically rollback in case of a failed deployment, which is determined by the application not being able to pass health checks.
As a DevOps Engineer, which of the following options would you recommend for the given use-case?
-
A
In the
AfterInstallhook inappspec.yml, verify the service is properly running. Configure CodeDeploy to rollback on deployment failures. In case the hook fails, then CodeDeploy will rollback -
B
Integrate CodeDeploy with the Application Load Balancer. In case the Application Load Balancers fails the health checks on the instances where the new version has been deployed, it will notify CodeDeploy. Configure CodeDeploy to rollback on deployment failures
-
C
In the
ValidateServicehook inappspec.yml, verify the service is properly running. Configure CodeDeploy to rollback on deployment failures. In case the hook fails, then CodeDeploy will rollback -
D
Create a CloudWatch Event rule on CodeDeploy to invoke a Lambda function upon deployment on every instance. The Lambda function tests the health check, and if it fails, stops the CodeDeploy deployment using the
StopDeploymentAPI, and then start a new deployment of the old version using theCreateDeploymentAPI
Xem giải thích
Đáp án
C — Trong hook ValidateService của appspec.yml, kiểm tra dịch vụ chạy đúng chưa; cấu hình CodeDeploy tự quay lui khi triển khai thất bại
Vì sao đúng
CodeDeploy chạy các hook theo một trình tự cố định, và ValidateService là hook cuối cùng — nó chạy sau khi ứng dụng đã khởi động và đã được đưa trở lại sau load balancer:
ApplicationStop → BeforeInstall → AfterInstall → ApplicationStart → ValidateService
Đó chính là lý do nó là chỗ đúng để kiểm tra sức khoẻ: tại thời điểm đó ứng dụng đã chạy thật, nên phép kiểm tra phản ánh đúng tình trạng.
Nếu hook trả về mã lỗi khác 0, CodeDeploy đánh dấu instance đó thất bại, và với automatic rollback đã bật, nó triển khai lại bản trước đó trên toàn bộ đội máy.
Vì triển khai theo lô nhỏ, lỗi được phát hiện ở lô đầu tiên — các instance còn lại chưa bị đụng tới.
Vì sao các phương án khác sai
- A. Kiểm tra ở hook
AfterInstall— hook này chạy trước khi ứng dụng khởi động, nên chưa có gì để kiểm tra. Đây là phương án nhiễu chính. - B. Dựa vào health check của ALB để báo cho CodeDeploy — ALB ngừng gửi lưu lượng tới instance hỏng, nhưng nó không báo ngược cho CodeDeploy để kích hoạt rollback.
- D. Dùng CloudWatch Event gọi Lambda kiểm tra rồi dừng triển khai — phức tạp hơn hẳn, và CodeDeploy đã có sẵn cơ chế hook cho đúng việc này.
The DevOps team at a leading travel-booking services company is using a CloudFormation template to deploy a Lambda function. The Lambda function code is uploaded into S3 into a file named s3://my-bucket/my-lambda-code.zip by CodePipeline after having passed all the required build checks. CodePipeline then invokes the CloudFormation template to deploy the new code. The team has found that although the CloudFormation template successfully runs, the Lambda function is not updated.
As a DevOps Engineer, what can you do to quickly fix this issue? (Select three)
-
A
Enable the SAM Framework option
-
B
Upload the code every time to a new S3 bucket
-
C
Enable S3 versioning and provide an
S3ObjectVersionkey -
D
Upload the code every time with a new filename in the same bucket
-
E
Add a pause of 3 seconds before starting the CloudFormation job. This is an eventual consistency issue due to overwriting PUT
-
F
Clear the Lambda cache with a Custom Job in CodePipeline before the CloudFormation step
Xem giải thích
Đáp án
B, C và D
Vì sao đúng
Vấn đề gốc: CloudFormation quyết định có cập nhật một tài nguyên hay không bằng cách so sánh template. Nếu S3Bucket và S3Key không đổi (vẫn là my-bucket và my-lambda-code.zip), CloudFormation kết luận không có gì thay đổi và bỏ qua — dù nội dung tệp zip đã khác.
Cả ba phương án đúng đều làm cho template thay đổi, buộc CloudFormation phải cập nhật:
| Cách | Trường thay đổi |
|---|---|
| D. Đặt tên tệp mới mỗi lần | S3Key |
| B. Dùng bucket mới mỗi lần | S3Bucket |
C. Bật versioning và truyền S3ObjectVersion |
S3ObjectVersion |
Trong ba cách, C là cách sạch nhất trong thực tế: giữ nguyên tên bucket và tên tệp, chỉ truyền mã phiên bản mới — và bạn còn có sẵn lịch sử để quay lui.
Vì sao các phương án khác sai
- E. Thêm khoảng chờ 3 giây vì đây là vấn đề nhất quán cuối cùng khi ghi đè — sai về nguyên nhân, và còn sai về sự thật: S3 đã nhất quán mạnh cho mọi thao tác từ cuối năm 2020. Đây là phương án nhiễu tinh vi nhất.
- A. Bật "tuỳ chọn SAM Framework" — SAM là cách viết template ngắn gọn hơn cho serverless; nó không giải quyết vấn đề so sánh template.
- F. Xoá cache của Lambda bằng custom job — không có khái niệm "cache" nào như vậy; Lambda không cập nhật vì CloudFormation chưa bảo nó cập nhật.