Ngân hàng đề — AWS Certified DevOps Engineer Professional
Tìm thấy 681 câu.
An ed-tech company has created a paid-per-use API using API Gateway. This API is available at http://edtech.com/api/v1. The website's static files have been uploaded in S3 and now support a new API route http://edtech.com/api/v1/new-feature if available. Your team has decided it is safer to send a small amount of traffic to that route first and test if the metrics look okay. Your API gateway routes are backed by AWS Lambda.
As a DevOps Engineer, what steps should you take to enable this testing?
-
A
Create a new Lambda function alias. Enable Canary deployments on the Lambda alias. Deploy the new API to the Lambda alias and assign a small amount of traffic to the canary Lambda version. Enable new route redirection for AWS Lambda and track metrics data using Amazon ES
-
B
Create a new Lambda function alias. Enable Canary deployments on the Lambda alias. Deploy the new API to the Lambda alias and assign a small amount of traffic to the canary Lambda version. Enable new route redirection for AWS Lambda and track metrics data using CloudWatch
-
C
Create a new API Gateway Stage. Enable Canary deployments on the v1 stage. Deploy the new stage to the v1 stage and assign a small amount of traffic to the canary stage. Track metrics data using Amazon ES
-
D
Create a new API Gateway Stage. Enable Canary deployments on the v1 stage. Deploy the new stage to the v1 stage and assign a small amount of traffic to the canary stage. Track metrics data using CloudWatch
Xem giải thích
Đáp án
*D — Tạo stage mới trong API Gateway, bật canary deployment trên stage v1, chuyển một lượng nhỏ lưu lượng sang canary, và theo dõi chỉ số bằng CloudWatch
Vì sao đúng
Canary deployment là tính năng có sẵn của API Gateway ở mức stage, và nó làm đúng điều đề mô tả:
Stage v1
├── 95% lưu lượng → bản triển khai hiện tại
└── 5% lưu lượng → bản canary (có route /new-feature)
Bạn khai tỷ lệ phần trăm, và API Gateway tự chia lưu lượng. Khi thấy chỉ số ổn, promote canary thành bản chính; thấy vấn đề thì xoá canary — quay lui tức thì.
Điểm quan trọng về theo dõi: API Gateway phát chỉ số CloudWatch riêng cho canary (số lượt gọi, độ trễ, lỗi 4XX và 5XX), nên bạn so sánh trực tiếp hai bên trên cùng một bảng.
Vì sao các phương án khác sai
- *C. Cùng kiến trúc nhưng theo dõi bằng Amazon ES — API Gateway phát chỉ số canary vào CloudWatch, không vào OpenSearch; muốn dùng OpenSearch thì phải tự dựng đường ống. Đây là phương án nhiễu chính, và nó chỉ khác đáp án đúng ở công cụ giám sát.
- A và *B. Bật canary trên Lambda alias — weighted alias của Lambda cũng chia lưu lượng được, nhưng nó chia ở tầng hàm, không chia được theo route của API. Đề nói rõ chỉ muốn thử nghiệm một route mới, nên canary phải ở tầng API Gateway.
An analytics company is capturing metrics for its AWS services and applications using CloudWatch metrics. It needs to be able to go back up to 7 years in time for visualizing these metrics due to regulatory requirements. As a DevOps Engineer at the company, you have been tasked with designing a solution that will help the company comply with the regulations.
Which of the following options requires the minimum development effort to address the given requirements?
-
A
Create a CloudWatch dashboard on top of CloudWatch metrics. Enable 'Extended Retention' on CloudWatch metrics, and implement an AWS Config rule that checks for this setting. If the AWS Config rule is non-compliant, use an Auto Remediation to turn it back on
-
B
Create a CloudWatch event rule to trigger every 15 minutes. The target of the rule should be a Lambda Function that will run an API call to export the metrics and put them in Amazon ES. Create a Kibana dashboard on top to visualize the metrics
-
C
Create a CloudWatch event rule to trigger every 15 minutes. The target of the rule should be a Lambda Function that will run an API call to export the metrics and put them in S3. Create a CloudWatch dashboard on top of the metrics in S3
-
D
Create a CloudWatch metrics stream and direct it to Kinesis Firehose Firehose delivery stream. Send all the metrics data into S3 using Firehose, and create a QuickSight dashboard to visualize the metrics. Use Athena to query for specific time ranges
Xem giải thích
Đáp án
D — Tạo CloudWatch metric stream đẩy sang Kinesis Data Firehose, ghi vào S3, rồi dựng bảng điều khiển QuickSight và dùng Athena để truy vấn
Vì sao đúng
Ràng buộc quyết định: giữ chỉ số 7 năm, trong khi CloudWatch chỉ lưu tối đa 15 tháng.
Nghĩa là dữ liệu bắt buộc phải chuyển ra ngoài CloudWatch, và S3 là nơi đúng: rẻ, dung lượng vô hạn, và giữ được bao lâu tuỳ ý.
CloudWatch metric stream là mắt xích khiến phương án này thắng về công sức: nó đẩy chỉ số liên tục và gần thời gian thực ra Firehose, không phải viết mã nào. Đây là tính năng dựng riêng cho việc xuất chỉ số ra hệ thống bên ngoài.
Phần còn lại đều là dịch vụ được quản lý: Firehose tự gom lô và nén, Athena truy vấn trực tiếp trên S3, QuickSight vẽ bảng điều khiển.
Vì sao các phương án khác sai
- C và B. Dùng CloudWatch Event chạy mỗi 15 phút gọi Lambda để xuất chỉ số — hoạt động được nhưng bạn phải viết và bảo trì hàm Lambda, tự xử lý phân trang, lỗi và trùng lặp. Nhiều công hơn hẳn metric stream. C là phương án nhiễu chính.
- A. Bật "Extended Retention" trên CloudWatch metrics — không tồn tại tính năng này; thời gian lưu chỉ số của CloudWatch là cố định.
The DevOps team at a yoga-inspired apparel company wants to stand up development environments for testing new features. The team would like to receive all CodePipeline pipeline failures to be sent to the company's #devops Slack channel. The company has hired you as an AWS Certified DevOps Engineer Professional to build a solution to address this use-case.
Which of the following options would you suggest? (Select two)
-
A
The target of the rule should be a Lambda function that will invoke a 3rd party Slack webhook
-
B
Create a CloudWatch Event Rule with the source corresponding to
{ "source": [ "aws.codepipeline" ], "detail-type": [ "CodePipeline Action Execution State Change" ], "detail": { "state": [ "FAILED" ] } } -
C
The target of the rule should be a 'Slack send'. Provide the channel name and webhook URL
-
D
Create a CloudWatch Event Rule with the source corresponding to
{ "source": [ "aws.codepipeline" ], "detail-type": [ "CodePipeline Pipeline Execution State Change" ], "detail": { "state": [ "FAILED" ] } } -
E
Create a CloudWatch Event rule with the source corresponding to
{ "source": [ "aws.codepipeline" ], "detail-type": [ "CodePipeline Stage Execution State Change" ], "detail": { "state": [ "FAILED" ] } }
Xem giải thích
Đáp án
A và D — target của rule là một Lambda function gọi webhook của Slack, và event pattern dùng CodePipeline Pipeline Execution State Change với state: FAILED
Vì sao đúng
-
D. Đúng mức sự kiện. Đề nói muốn nhận "mọi pipeline failure" — tức là thất bại ở mức toàn pipeline. CodePipeline phát sự kiện ở ba mức, và chọn đúng mức là chỗ phân biệt:
Mức Khi nào phát Pipeline Execution State Change Toàn bộ pipeline chuyển trạng thái Stage Execution State Change Một stage chuyển trạng thái Action Execution State Change Một action chuyển trạng thái Chọn mức action hay stage sẽ gửi nhiều thông báo cho cùng một lần hỏng — mỗi action hỏng một cái, rồi stage hỏng thêm một cái nữa.
-
A. Target là Lambda. EventBridge không có target Slack sẵn; phải qua Lambda gọi incoming webhook của Slack.
Vì sao các phương án khác sai
- C. Target là "Slack send", chỉ cần khai tên kênh và webhook URL — không tồn tại loại target này. Đây là phương án nhiễu chính.
- B và *E. Dùng mức Action hoặc Stage — bắt được sự kiện nhưng gây nhiễu thông báo như vừa nêu, và không khớp với yêu cầu "pipeline failures".
Your application is deployed on Elastic Beanstalk and you manage the configuration of the stack using a CloudFormation template. A new golden AMI is created every week and contains a hardened AMI that has all the necessary recent security patches. You have deployed over 100 applications using CloudFormation & Beanstalk this way and you would like to ensure the newer AMI used for EC2 instances is updated every week. There are no standardization or naming conventions made across all the CloudFormation templates.
As a DevOps Engineer, how would you implement a solution for this requirement?
-
A
Store the Golden AMI id in an S3 object. Create a CloudFormation parameter that points to the S3 object, and is passed on to the configuration of the Elastic Beanstalk environment. Create a CloudWatch Event rule that is triggered every week that will launch a Lambda function. That Lambda function should trigger a refresh of all the CloudFormation templates using the
UpdateStackAPI -
B
Store the Golden AMI id in an S3 object. Create a CloudFormation mapping to contain the last value of the Golden AMI id. That mapping is passed on to the configuration of the Elastic Beanstalk environment. Create a CloudWatch Event rule that is triggered every week that will launch a Lambda function. That Lambda function should update the mapping section of every CloudFormation template using a YAML parser, upload the new templates to S3 and trigger a refresh of all the CloudFormation templates using the
UpdateStackAPI while passing the new parameter -
C
Store the Golden AMI id in an SSM Parameter Store parameter. Create a CloudFormation parameter that points to the SSM Parameter Store, and is passed on to the configuration of the Elastic Beanstalk environment. Create a CloudWatch Event rule that is triggered every week that will launch a Lambda function. That Lambda function should trigger a refresh of all the CloudFormation templates using the
UpdateStackAPI -
D
Store the Golden AMI id in an SSM Parameter Store parameter. Create a CloudFormation parameter of type String, and is passed on to the configuration of the Elastic Beanstalk environment. Create a CloudWatch Event rule that is triggered every week that will launch a Lambda function. That Lambda function should fetch the parameter from the SSM Parameter Store and trigger a refresh of all the CloudFormation templates using the
UpdateStackAPI while passing the new parameter
Xem giải thích
Đáp án
C — Lưu ID của Golden AMI trong SSM Parameter Store, và tạo CloudFormation parameter kiểu SSM trỏ tới tham số đó
Vì sao đúng
Chi tiết quyết định trong đề: có hơn 100 template và không có quy ước đặt tên chuẩn nào. Nghĩa là giải pháp không được đòi hỏi việc sửa từng template.
CloudFormation có kiểu parameter đặc biệt cho đúng việc này:
Parameters:
GoldenAmi:
Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
Default: /golden-ami/latest
Điểm mấu chốt: CloudFormation đọc giá trị từ Parameter Store tại thời điểm tạo hoặc cập nhật stack. Nên khi AMI mới được tạo hằng tuần, bạn chỉ cần cập nhật một tham số duy nhất — mọi stack sau đó tự lấy giá trị mới, không phải sửa template nào.
Vì sao các phương án khác sai
- *D. Lưu trong Parameter Store nhưng khai CloudFormation parameter kiểu String — khi đó CloudFormation coi nó là một chuỗi bình thường và bạn phải tự truyền giá trị vào mỗi lần; mất hết tính tự động. Đây là phương án nhiễu chính, và nó chỉ khác đáp án đúng ở kiểu tham số.
- A. Lưu AMI ID trong một đối tượng S3 và trỏ parameter tới đó — CloudFormation không đọc được giá trị từ S3 theo cách này; không có kiểu parameter tương ứng.
- B. Dùng CloudFormation Mapping để chứa giá trị — mapping là hằng số viết cứng trong template; muốn đổi thì phải sửa và triển khai lại cả 100 template.
A Silicon Valley based startup runs a news discovery web application and it uses CodeDeploy to deploy the web application on a set of 20 EC2 instances behind an Application Load Balancer. The ALB is integrated with CodeDeploy. The DevOps teams at the startup would like the deployment to be gradual and to automatically rollback in case of unusually high maximum CPU utilization for the EC2 instances while traffic is being served.
How can you implement this?
-
A
Create a CloudWatch metric for the maximum CPU utilization of your Application Load Balancer. Create a deployment in CodeDeploy that has rollback enabled, integrated with the CloudWatch metric
-
B
Create a CloudWatch metric for the maximum CPU utilization of your EC2 instances. Create a deployment in CodeDeploy that has rollback enabled, integrated with the CloudWatch metric
-
C
Create a CloudWatch metric for the maximum CPU utilization of your EC2 instances. Create a CloudWatch Alarm on top of that metric. Create a deployment in CodeDeploy that has rollback enabled, integrated with the CloudWatch alarm
-
D
In the
ValidateServicehook inappspec.yml, measure the CPU utilization for 5 minutes. Configure CodeDeploy to rollback on deployment failures. In case the hook fails, then CodeDeploy will rollback
Xem giải thích
Đáp án
*C — Tạo CloudWatch metric cho mức sử dụng CPU tối đa của EC2 instance, tạo CloudWatch Alarm trên chỉ số đó, rồi cấu hình CodeDeploy quay lui và tích hợp với alarm
Vì sao đúng
Điểm mấu chốt của câu này rất gọn: CodeDeploy tích hợp với CloudWatch Alarm, không tích hợp với CloudWatch Metric.
Lý do có tính logic: metric chỉ là một chuỗi số, nó không có khái niệm "bình thường" hay "bất thường". Phải có alarm — tức là metric cộng với ngưỡng và khoảng thời gian đánh giá — thì mới sinh ra trạng thái để CodeDeploy phản ứng.
Cấu hình đầy đủ:
1. Metric: CPUUtilization (Maximum) của các instance trong deployment group
2. Alarm: vượt ngưỡng X% trong Y phút liên tiếp
3. Deployment group: bật "Rollback when alarm thresholds are met" và chọn alarm đó
Khi alarm chuyển sang trạng thái ALARM trong lúc triển khai, CodeDeploy dừng và tự quay lui.
Vì sao các phương án khác sai
- *B. Tích hợp thẳng với CloudWatch metric — không làm được, vì lý do vừa nêu. Đây là phương án nhiễu chính, và nó chỉ khác đáp án đúng ở một mắt xích.
- *A. Đo CPU của Application Load Balancer — ALB là dịch vụ được quản lý, không có chỉ số CPU; đề cũng nói rõ là CPU của EC2 instance.
- D. Đo CPU trong hook
ValidateServicesuốt 5 phút — hook chạy trong lúc triển khai lô đó, nhưng đề muốn phát hiện CPU cao trong khi đang phục vụ lưu lượng thật; và giữ hook chạy 5 phút làm chậm cả quá trình.
As the Lead DevOps Engineer at a retail company, you have a Spring boot web application running in an Auto Scaling group and behind an Application Load Balancer. You must collect the logs before an instance is terminated to perform log analytics later on. It's also necessary to collect all the access logs. The analysis of these logs should be performed at a minimal cost, and only need to be run from time to time.
Which of the following options would you suggest to implement the MOST cost-optimal solution for this requirement? (Select three)
-
A
Enable Access Logs at the Application Load Balancer level
-
B
Analyze the logs using an EMR cluster
-
C
Enable Access Logs at the Target Group level
-
D
Analyze the logs using AWS Athena
-
E
Create an Auto Scaling Group Lifecycle Hook for the terminate action. Create a CloudWatch Event rule for that lifecycle hook and invoke a Lambda function. The Lambda function should use an SSM Run Command to extract the application logs and store them in S3
-
F
Create an Auto Scaling Group Lifecycle Hook for the terminate action. Create a CloudWatch Event rule for that lifecycle hook and invoke a Lambda function. The Lambda function should use an SSM Run Command to install the CloudWatch Logs Agent and push the applications logs in S3
Xem giải thích
Đáp án
A, D và E — bật Access Logs ở mức Application Load Balancer, phân tích bằng Athena, và dùng lifecycle hook khi kết thúc gọi Lambda chạy SSM Run Command để đẩy log ứng dụng lên S3
Vì sao đúng
Đề có ba yêu cầu, và ba phương án đúng ghép thành một giải pháp trọn vẹn:
| Yêu cầu | Phương án |
|---|---|
| Thu access log | A — ALB có tính năng Access Logs sẵn, ghi thẳng vào S3, miễn phí (chỉ trả phí lưu trữ) |
| Thu log ứng dụng trước khi instance bị huỷ | E — lifecycle hook giữ instance ở trạng thái Terminating:Wait, đủ thời gian đẩy log lên S3 |
| Phân tích với chi phí tối thiểu, chỉ chạy thỉnh thoảng | D — Athena không có hạ tầng thường trực, chỉ trả tiền theo lượng dữ liệu quét |
Vế cuối là chỗ quyết định: đề nói rõ việc phân tích chỉ chạy thỉnh thoảng, nên mọi giải pháp có cụm chạy liên tục đều thua.
Vì sao các phương án khác sai
- B. Phân tích bằng cụm EMR — mạnh hơn nhưng bạn trả tiền cho cụm; với việc chạy thỉnh thoảng thì đắt hơn Athena rất nhiều. Đây là phương án nhiễu chính.
- *C. Bật Access Logs ở mức Target Group — không tồn tại; access log là tính năng của load balancer, không phải của target group.
- F. Dùng SSM Run Command để cài CloudWatch Agent lúc instance sắp bị huỷ — quá muộn: cài agent vào lúc đó thì log cũ đã không được thu thập, và việc phân tích trên CloudWatch Logs cũng đắt hơn Athena.
The compliance department at a Wall Street trading firm has hired you as an AWS Certified DevOps Engineer Professional to help with several strategic DevOps initiatives. The department has asked you to regularly generate the list of all the software packages installed on the EC2 instances. The solution needs to be able to extend to future instances in the AWS account and send notifications if the instances are not set up correctly to track their software.
Which of the following options are the best-fit solutions that require the least effort to meet the given requirements? (Select two)
-
A
Use AWS Inspector to track the installed package list on your EC2 instances. Visualize the metadata directly in the AWS Inspector Insights console
-
B
Create a CloudWatch Event rule to trigger a Lambda function on an hourly basis. Do a comparison of the instances that are running in EC2 and those tracked by SSM
-
C
Use an SSM Run Command to have the SSM service find which instances are not currently tracked by SSM
-
D
Install the SSM agent on the instances. Run an SSM Automation during maintenance windows to get the list of all the packages using
yum list installed. Write the output to Amazon S3 -
E
Install the SSM agent on the instances. Run an SSM Inventory to collect the metadata and send them to Amazon S3
Xem giải thích
Đáp án
B và E — cài SSM Agent rồi chạy SSM Inventory để thu thập siêu dữ liệu và gửi sang S3, và tạo CloudWatch Event rule gọi Lambda mỗi giờ để đối chiếu instance đang chạy với instance được SSM theo dõi
Vì sao đúng
Đề có hai yêu cầu, và mỗi phương án đúng lo một cái:
-
E. SSM Inventory — đây là tính năng dựng riêng cho việc thu thập danh sách phần mềm đã cài, bản vá, cấu hình mạng, dịch vụ đang chạy. Nó chạy theo lịch tự động, tổng hợp được đa tài khoản và đa Region qua resource data sync, và ghi thẳng vào S3.
-
B. Lambda đối chiếu mỗi giờ — đây là phần "gửi thông báo nếu instance chưa được thiết lập đúng". Cách làm: gọi
ec2:DescribeInstancesđể lấy danh sách máy đang chạy, gọissm:DescribeInstanceInformationđể lấy danh sách máy SSM biết, rồi lấy phần chênh lệch. Máy nằm trong danh sách đầu mà không có trong danh sách sau là máy thiếu agent hoặc thiếu IAM role.
Vì sao các phương án khác sai
- C. Dùng SSM Run Command để SSM tự tìm instance chưa được nó theo dõi — mâu thuẫn nội tại: Run Command chỉ chạy được trên máy đã đăng ký với SSM, nên nó không bao giờ chạm tới máy chưa đăng ký. Đây là phương án nhiễu chính.
- D. Chạy SSM Automation gọi
yum list installedrồi ghi ra S3 — làm được nhưng tự dựng lại thứ Inventory đã có, và chỉ chạy được với hệ điều hành dùngyum. - A. Dùng AWS Inspector để theo dõi danh sách gói — Inspector quét lỗ hổng bảo mật; nó không phải công cụ kiểm kê phần mềm, và không có "Inspector Insights console" như phương án mô tả.
As a DevOps Engineer at a social media company, you have implemented a CICD pipeline that takes code from a CodeCommit repository, builds it using CodeBuild thanks to the instructions in the local Dockerfile, and then pushes to ECR at 123456789.dkr.ecr.region.amazonaws.com/my-web-app. The last step of your CICD pipeline is to deploy to the application to your ECS cluster. It seems that while you do so, the application is only partly updated on some ECS instances which are running an older version of your image. You have found that terminating the instance or clearing the local Docker cache fixes the issue, but would like to implement something more robust that provides visibility and identification to track where container images are deployed.
How should you implement a solution to address this issue?
-
A
After the deploy step in CodePipeline is done, include a Custom Step using a Lambda function that triggers an SSM Run Command. That command will clear the local Docker cache and stop the task
-
B
When creating a new task definition for your ECS service, ensure to add the
latesttag in the full image name so that ECS pulls the correct image every time -
C
After the deploy step in CodePipeline is done, include a Custom Step using a Lambda function that triggers an AWS Lambda function. That function will SSH onto your ECS instances and clear the local Docker cache and stop the task
-
D
When creating a new task definition for your ECS service, ensure to add the sha256 hash in the full image name so that ECS pulls the correct image every time
Xem giải thích
Đáp án
D — Khi tạo task definition mới, dùng mã băm sha256 trong tên image đầy đủ để ECS luôn kéo đúng image
Vì sao đúng
Vấn đề gốc: task definition tham chiếu image bằng tag (thường là :latest), mà tag trong Docker là con trỏ có thể di chuyển. Khi bạn đẩy image mới với cùng tag, ECS instance đã có image cũ trong cache sẽ không kéo lại — vì với nó, tên image không đổi.
Mã băm sha256 giải triệt để vì nó định danh bất biến của nội dung image:
123456789.dkr.ecr.region.amazonaws.com/my-web-app:latest ← con trỏ, có thể đổi
123456789.dkr.ecr.region.amazonaws.com/my-web-app@sha256:a1b2c3d4... ← BẤT BIẾN
Khi task definition tham chiếu bằng digest, tên image thật sự thay đổi ở mỗi bản dựng, nên ECS buộc phải kéo image mới. Không còn chỗ cho cache cũ.
Đây cũng là cách bảo đảm mọi instance chạy đúng cùng một image — điều mà tag không bảo đảm được.
Vì sao các phương án khác sai
- B. Thêm tag
latestvào tên image đầy đủ — chính là nguyên nhân gây ra vấn đề, không phải cách chữa. Đây là phương án nhiễu chính. - A. Dùng Lambda gọi SSM Run Command để xoá cache Docker rồi dừng task — chữa triệu chứng bằng cách can thiệp thô sau mỗi lần triển khai; mong manh và phải bảo trì.
- C. Dùng Lambda SSH vào ECS instance để xoá cache — Lambda không SSH vào máy được theo cách này, và dựng đường mạng cho việc đó là phản kiến trúc.
A mobility company connects people with taxi drivers and the DevOps team at the company uses CodeCommit as a backup and disaster recovery service for several of its DevOps processes. The team is creating a CICD pipeline so that your code in the CodeCommit master branch automatically gets packaged as a Docker container and published to ECR. The team would then like that image to be automatically deployed to an ECS cluster using a Blue/Green strategy.
As an AWS Certified DevOps Engineer, which of the following options would you recommend as the most efficient solution to meet the given requirements?
-
A
Create a CodePipeline that will invoke a CodeBuild stage. The CodeBuild stage should acquire ECR credentials using the CLI helpers, build the image, and then push it to ECR. Upon the success of that CodeBuild stage, start a CodeDeploy stage with a target being your ECS service
-
B
Create a CodePipeline that will invoke a CodeBuild stage. The CodeBuild stage should acquire ECR credentials using the CLI helpers, build the image, and then push it to ECR. Create a CloudWatch Event Rule that will react to pushes to ECR and invoke CodeDeploy, the target of which should be the ECS cluster
-
C
Create a CodePipeline that will invoke a CodeBuild stage. The CodeBuild stage should acquire ECR credentials using the
AWS_ACCESS_KEY_IDandAWS_SECRET_ACCESS_KEYenvironment variables passed in through CodeBuild configuration, the values being those from your user. Upon the success of that CodeBuild stage, create a new task definition automatically using CodePipeline and apply that task definition to the ECS service using a CloudFormation action -
D
Create a CodePipeline that will invoke a CodeBuild stage. The CodeBuild stage should acquire ECR credentials using the CLI helpers, build the image, and then push it to ECR. Upon the success of that CodeBuild stage, create a new task definition automatically using CodeCommit and apply that task definition to the ECS service using a CloudFormation action
Xem giải thích
Đáp án
A — CodePipeline gọi một stage CodeBuild lấy thông tin đăng nhập ECR bằng CLI helper, dựng image và đẩy lên ECR; khi stage đó thành công thì khởi động một deployment CodeDeploy kiểu Blue/Green
Vì sao đúng
Có hai quyết định trong phương án này, và cả hai đều đúng.
Thứ nhất — dùng CLI helper để lấy thông tin đăng nhập ECR. Lệnh aws ecr get-login-password | docker login ... lấy token tạm thời từ IAM role của CodeBuild. Đây là cách đúng: không có khoá cố định nào nằm trong cấu hình.
Thứ hai — dùng CodeDeploy cho Blue/Green trên ECS. CodeDeploy là dịch vụ có sẵn cơ chế Blue/Green cho ECS: nó tạo task set mới, chuyển lưu lượng qua listener của ALB, và quay lui tức thì nếu có vấn đề — vì task set cũ vẫn còn nguyên.
Chuỗi kết nối bằng CodePipeline giữ mọi thứ trong một quy trình duy nhất với lịch sử đầy đủ.
Vì sao các phương án khác sai
- C. Lấy thông tin đăng nhập ECR bằng biến
AWS_ACCESS_KEY_IDvàAWS_SECRET_ACCESS_KEY— dùng khoá cố định trong khi CodeBuild đã có sẵn IAM role; đây là bước lùi về bảo mật. - B. Dùng CloudWatch Event phản ứng với việc push lên ECR để kích hoạt triển khai — tách quy trình thành hai mảnh rời, mất tính liên tục và khó truy vết khi hỏng.
- D. Tạo task definition mới thay vì dùng CodeDeploy — tạo task definition không phải là triển khai Blue/Green; thiếu hẳn cơ chế chuyển lưu lượng và quay lui.
Your company has adopted a git repository technology to store and have version control on the application code. Your company would like to make sure the production branch of the code is deployed to the production environment, but also would like to enable other versions of the code to be deployed to the development and staging environments for performing various kinds of user acceptance testing.
As a DevOps Engineer, which solution would you implement for the given requirement?
-
A
Create a CodeCommit repository and create a CodePipeline pipeline that will deploy any changes to the master branch to the development and staging environment. Create a manual approval step after the deployment to staging to ensure the application is reviewed before being deployed to production in the last pipeline stage
-
B
Create a CodeCommit repository for the development code and create a CodePipeline pipeline that will deploy any changes to the master branch to the development and staging environment. Create a second CodeCommit repository and CodePipeline pipeline that will deploy changes from the production branch to the production environment after a manual approval step has happened in the first CodePipeline
-
C
Create a CodeCommit repository and create a CodePipeline pipeline that will deploy any changes to the master branch to the development and staging environment. Create a second CodePipeline pipeline that will deploy changes to the production branch to the production environment after the code is merged through a pull request
-
D
Create a CodeCommit repository for the development code and create a CodePipeline pipeline that will deploy any changes to the master branch to the development and staging environment. Create a second CodeCommit repository and CodePipeline pipeline that will deploy changes from the production branch to the production environment after the code is merged through a pull request
Xem giải thích
Đáp án
C — Một kho CodeCommit duy nhất, hai pipeline: một triển khai thay đổi từ master sang development và staging, một triển khai từ nhánh production sang môi trường production
Vì sao đúng
Đề đòi hai luồng triển khai độc lập từ hai nhánh khác nhau, và mấu chốt nằm ở chỗ: mỗi CodePipeline chỉ theo dõi được một nhánh nguồn.
Nên muốn master đi một đường và nhánh production đi đường khác, bắt buộc phải có hai pipeline:
Kho CodeCommit (một kho duy nhất)
├── nhánh master → Pipeline 1 → development → staging
└── nhánh production → Pipeline 2 → production
Điểm quan trọng là một kho, nhiều nhánh — chứ không phải nhiều kho. Nhờ vậy lịch sử mã liền mạch, và việc đưa mã từ master sang nhánh production chỉ là một lần merge có rà soát.
Vì sao các phương án khác sai
- A. Một pipeline duy nhất kèm bước phê duyệt thủ công trước khi lên production — hoạt động được và là mô hình phổ biến, nhưng nó không đáp ứng yêu cầu triển khai từ nhánh production riêng; mọi thứ vẫn đi ra từ
master. Đây là phương án nhiễu chính. - B và *D. Dùng hai kho CodeCommit riêng — đồng bộ mã giữa hai kho là việc thủ công và dễ sai; bạn cũng mất lịch sử chung, nên không truy được một thay đổi đã lên production hay chưa.