Ngân hàng đề — AWS Certified DevOps Engineer Professional
Tìm thấy 681 câu.
The technology team at a health-care solutions company has developed a REST API which is deployed in an Auto Scaling Group behind an Application Load Balancer. The API stores the data payload in DynamoDB and the static content is served through S3. Upon doing some analytics, it's found that 85% of the read requests are shared across all users.
As a DevOps Engineer, how can you improve the application performance while decreasing the cost?
-
A
Enable ElastiCache Redis for DynamoDB and ElastiCache Memcached for S3
-
B
Enable ElastiCache Redis for DynamoDB and CloudFront for S3
-
C
Enable DynamoDB Accelerator (DAX) for DynamoDB and CloudFront for S3
-
D
Enable DAX for DynamoDB and ElastiCache Memcached for S3
Xem giải thích
Đáp án
C — Bật DynamoDB Accelerator (DAX) cho DynamoDB và CloudFront cho S3
Vì sao đúng
Đề có hai tầng dữ liệu khác nhau, và mỗi tầng có công cụ cache riêng phù hợp:
| Tầng | Vấn đề | Giải pháp | Vì sao |
|---|---|---|---|
| DynamoDB | 85% lượt đọc trùng nhau | DAX | Cache trong bộ nhớ tương thích API với DynamoDB — chỉ đổi endpoint, không viết lại logic cache |
| S3 (nội dung tĩnh) | Phục vụ lặp lại cùng tệp | CloudFront | Cache tại edge gần người dùng, và giá truyền dữ liệu rẻ hơn S3 |
Cả hai đều đáp ứng cùng lúc hai mục tiêu của đề: nhanh hơn (độ trễ giảm) và rẻ hơn (ít lượt đọc DynamoDB tính tiền, ít lưu lượng ra từ S3).
Con số 85% lượt đọc dùng chung chính là dấu hiệu cho biết cache sẽ rất hiệu quả — tỷ lệ trúng cache cao.
Vì sao các phương án khác sai
- B. ElastiCache Redis cho DynamoDB và CloudFront cho S3 — đúng vế S3, nhưng ElastiCache đòi bạn tự viết toàn bộ logic cache (kiểm tra trước, ghi sau, xử lý làm mới). DAX làm sẵn. Đây là phương án nhiễu chính.
- A và D. Dùng ElastiCache Memcached cho S3 — Memcached là cache trong bộ nhớ đặt trong VPC; nó không phục vụ nội dung tĩnh cho người dùng cuối và không nằm ở edge, nên vô ích cho bài toán này.
As the Lead DevOps Engineer at an analytics company, you are deploying a global application using a CICD pipeline comprising of AWS CodeCommit, CodeBuild, CodeDeploy and orchestrated by AWS CodePipeline. Your pipeline is currently setup in eu-west-1 and you would like to extend the pipeline to deploy your application in us-east-2. This will require a multi-step CodePipeline to be created there and invoked.
How would you implement a solution to address this use-case?
-
A
At the end of the pipeline in eu-west-1, include an S3 step to copy the artifacts being used by CodeDeploy to an S3 bucket in us-east-2. Make the CodePipeline in us-east-2 source files from S3
-
B
At the end of the pipeline in eu-west-1, include a CodeDeploy step to deploy the application to the CodePipeline in us-east-2
-
C
At the end of the pipeline in eu-west-1, include a CodePipeline step to invoke the CodePipeline in us-east-2. Ensure the CodePipeline in us-east-2 has the necessary IAM permission to read the artifacts in S3 in eu-west-1
-
D
At the end of the pipeline in eu-west-1, include a CodeCommit step to push the changes to the code into the master branch of another CodeCommit repository in us-east-2. Make the CodePipeline in us-east-2 source files from CodeCommit
Xem giải thích
Đáp án
A — Ở cuối pipeline eu-west-1, thêm một bước sao chép artefact sang bucket S3 ở us-east-2, và cho pipeline ở us-east-2 lấy nguồn từ bucket đó
Vì sao đúng
Ràng buộc kỹ thuật quyết định: CodePipeline chỉ đọc được artefact từ bucket S3 nằm trong chính Region của nó.
Vì vậy để pipeline ở us-east-2 chạy được, artefact phải có mặt vật lý ở Region đó — không có cách nào để nó "với sang" bucket ở eu-west-1.
Kiến trúc:
Pipeline eu-west-1
▼ bước cuối: sao chép artefact
Bucket S3 ở us-east-2
▼ sự kiện thay đổi đối tượng kích hoạt
Pipeline us-east-2
Bucket S3 làm nguồn cũng chính là cơ chế kích hoạt: pipeline theo dõi đối tượng và tự chạy khi có bản mới.
Vì sao các phương án khác sai
- C. Gọi pipeline ở
us-east-2và cấp cho nó quyền đọc bucket ởeu-west-1— quyền không phải vấn đề; đây là ràng buộc kiến trúc của CodePipeline về vị trí artefact bucket. Đây là phương án nhiễu chính. - D. Đẩy mã sang một kho CodeCommit thứ hai ở
us-east-2— làm được nhưng đi lùi trong quy trình: bạn đưa mã nguồn sang thay vì artefact đã dựng và đã kiểm thử, nên phải dựng lại từ đầu và không bảo đảm hai Region chạy đúng cùng một bản. - B. Dùng CodeDeploy để "triển khai tới CodePipeline" — không có khái niệm này; CodeDeploy triển khai lên hạ tầng, không triển khai lên một pipeline.
A multi-national retail company is in the process of capturing all of its infrastructure as code using CloudFormation. The infrastructure inventory is huge and will contain a networking stack, an application stack, a data stack, and so on. Some teams are ready to move ahead with the process while others are lagging, and there is a desire to keep all the infrastructure version controlled.
The company has hired you as an AWS Certified DevOps Engineer Professional to build a solution to address this use-case. How would you implement this?
-
A
Create one template per logical element of your infrastructure. Create a master stack that contains all the other stacks as a nested template. Deploy the master template once using CloudFormation and then update the nested stacks individually as new CloudFormation code is created
-
B
Create one template per logical element of your infrastructure. Deploy them using CloudFormation as they are ready. Use outputs and exports to reference values in the stacks. Keep each file separately in a version-controlled repository
-
C
Create one template per logical element of your infrastructure. Create a master stack that contains all the other stacks as a nested template. Deploy the master template using CloudFormation every-time a nested stack template is updated in version control
-
D
Create one master template that contains all the stacks in your infrastructure. Collaborate on that template using pull requests and merges to the master branch in your code repository. Deploy the master template every-time it is updated
Xem giải thích
Đáp án
B — Mỗi thành phần logic một template riêng, triển khai từng cái khi sẵn sàng, dùng Outputs và Exports để tham chiếu giá trị giữa các stack, và giữ mỗi tệp trong hệ thống quản lý phiên bản
Vì sao đúng
Chi tiết quyết định trong đề: một số đội đã sẵn sàng, số khác thì chưa. Nghĩa là các phần hạ tầng phải triển khai độc lập theo tiến độ riêng.
Mô hình cross-stack reference cho đúng điều đó:
Stack mạng → Export: VpcId, SubnetIds
Stack dữ liệu → ImportValue: SubnetIds → Export: DatabaseEndpoint
Stack ứng dụng → ImportValue: VpcId, DatabaseEndpoint
Mỗi stack có vòng đời riêng: đội mạng cập nhật stack của mình mà không đụng tới stack ứng dụng, và ngược lại.
So với nested stack, khác biệt về mặt vận hành rất lớn: nested stack là một đơn vị triển khai duy nhất — muốn đổi một phần nhỏ cũng phải cập nhật cả stack mẹ, và mọi đội bị khoá vào cùng một nhịp.
Vì sao các phương án khác sai
- A và C. Dùng nested stack với một master stack chứa tất cả — buộc mọi thay đổi phải đi qua stack mẹ, nên đội đi nhanh bị đội đi chậm giữ lại. A là phương án nhiễu chính vì nested stack đúng là một mô hình hợp lệ — chỉ là không hợp với ràng buộc "các đội tiến độ khác nhau".
- D. Một template duy nhất chứa toàn bộ hạ tầng — tệ nhất: mọi thay đổi đụng vào cùng một tệp, xung đột merge liên tục, và một lỗi làm hỏng cả stack.
Lưu ý về ràng buộc của Export
Giá trị đã được Import thì stack xuất không xoá hay sửa được cho tới khi bên nhập ngừng dùng. Đây là đánh đổi cần biết khi thiết kế.
An IT company is deploying a Python Flask based application and would like to ensure that it has a base AMI that contains the necessary Python runtime, as well as OS patches. That AMI must be used able to be referenced programmatically from across all regions in your account in a scalable way. The company has hired you as an AWS Certified DevOps Engineer Professional to build a solution to address this requirement.
Which of the following options would you recommend for this use-case? (Select two)
-
A
Use AWS Lambda to create a patched AMI using the latest working AMI
-
B
Use AWS Inspector to create a patched AMI using the latest working AMI
-
C
Create an SSM Automation document to create the AMI in a repeatable manner
-
D
Store the AMI ID in the SSM parameter store in one region, and have a Lambda function that copies the AMI across all the other regions, and stores the corresponding AMI ID in SSM. Use the same parameter store name so it can be re-used across regions
-
E
Store the AMI ID in the SSM parameter store in one region, and create a Step Function that copies the value of that AMI ID across all the other regions. Use the same parameter store name so it can be re-used across regions
Xem giải thích
Đáp án
C và D — tạo SSM Automation document để dựng AMI một cách lặp lại được, và lưu AMI ID trong SSM Parameter Store ở một Region rồi dùng Lambda sao chép AMI sang các Region khác và ghi ID tương ứng vào Parameter Store cùng tên
Vì sao đúng
Đề có hai yêu cầu, và mỗi phương án đúng lo một cái:
-
C. SSM Automation document dựng AMI — Automation có sẵn các bước cho đúng quy trình này: khởi chạy instance từ AMI gốc, cài Python runtime, áp bản vá, tạo AMI, huỷ instance tạm. Nó lặp lại được và chạy theo lịch được.
-
D. Parameter Store cùng tên ở mọi Region — đây là phần khiến AMI tham chiếu được theo cách mở rộng. Chìa khoá nằm ở chữ cùng tên:
eu-west-1: /golden-ami/python-flask → ami-aaaa us-east-1: /golden-ami/python-flask → ami-bbbb ap-southeast-1: /golden-ami/python-flask → ami-ccccNhờ vậy cùng một template CloudFormation chạy được ở mọi Region mà không sửa gì — nó chỉ tham chiếu tên tham số, và mỗi Region tự phân giải ra AMI ID của mình.
Vì sao các phương án khác sai
- E. Dùng Step Functions sao chép giá trị của AMI ID sang các Region khác — sai về bản chất: AMI ID không dùng chung được giữa các Region; phải sao chép chính AMI (thao tác
CopyImage) rồi mới có ID mới. Đây là phương án nhiễu chính. - A và B. Dùng Lambda hoặc Inspector để tạo AMI đã vá — Lambda vướng giới hạn 15 phút cho quy trình dựng AMI, còn Inspector quét lỗ hổng chứ không tạo AMI.
A health-care services company has strong regulatory requirements and it has come to light recently that some of the EBS volumes have not been encrypted. It is necessary for the company to monitor and audit compliance over time and alert the corresponding teams if unencrypted EBS volumes are detected.
How should a DevOps Engineer implement an alert for the unencrypted EBS volumes with the least administrative overhead?
-
A
Create an AWS Config managed rule checking for EBS volume encryption. Use a CloudWatch Event rule to provide alerting
-
B
Create an AWS Lambda Function that is triggered by a CloudWatch Event rule. The rule is monitoring for new EBS volumes being created. The Lambda function should send a notification to SNS in case of a compliance check
-
C
Create an AWS Config managed rule checking for EBS volume encryption. Connect the rule to an SNS topic to provide alerting
-
D
Create an AWS Config custom rule checking for the EC2 instances, and their EBS attachments. Connect the rule to an SNS topic to provide alerting
Xem giải thích
Đáp án
A — Tạo một AWS Config managed rule kiểm tra mã hoá EBS volume, và dùng CloudWatch Event rule để cảnh báo
Vì sao đúng
Chữ khoá của đề là "ít công quản trị nhất", và AWS Config có sẵn managed rule cho đúng việc này: encrypted-volumes. Bạn không phải viết dòng mã nào — chỉ bật rule lên.
Config cũng phủ luôn yêu cầu "theo dõi và kiểm toán tuân thủ theo thời gian": nó lưu lịch sử tuân thủ của từng volume, nên bạn trả lời được câu hỏi kiểm toán viên hay hỏi — "volume này từ khi nào thì không tuân thủ?"
Về phần cảnh báo, CloudWatch Events là kênh đúng: Config phát sự kiện thay đổi tuân thủ qua EventBridge, và từ đó bạn nối sang SNS, Lambda, hay hệ thống quản lý sự cố.
Vì sao các phương án khác sai
- *C. Cùng managed rule nhưng nối rule trực tiếp với một SNS topic — Config rule không nối thẳng vào SNS; nó phát sự kiện qua EventBridge, và từ đó mới đi tiếp. Đây là phương án nhiễu chính, và nó chỉ khác đáp án đúng ở một mắt xích.
- D. Viết custom rule kiểm tra EC2 instance và các EBS attachment — tự viết Lambda cho việc mà managed rule đã làm sẵn, và cách tiếp cận qua instance còn bỏ sót volume không gắn vào máy nào.
- B. Lambda kích hoạt bởi CloudWatch Event khi có volume mới được tạo — chỉ bắt được volume tạo mới; nó không phát hiện những volume chưa mã hoá đã tồn tại từ trước — đúng thứ đề đang muốn tìm.
As a DevOps Engineer at a data analytics company, you're deploying a web application on EC2 using an Auto Scaling group. The data is stored in RDS MySQL Multi-AZ, and a caching layer using ElastiCache. The application configuration takes time and currently needs over 20 minutes to warm up. 10 of those minutes are spent installing and configuring the web application, and another 10 minutes are spent warming up the local instance data cache.
What can be done to improve the performance of the setup?
-
A
Create an AMI that contains the web application and a copy of the local data cache. Configure the dynamic part at runtime an EC2 User Data script
-
B
Create an AMI that contains the web application. Configure the dynamic part at runtime using an EC2 User Data script
-
C
Create an AMI that contains the web application. Configure the dynamic part at runtime using an EC2 User Data script. Use AWS Lambda to configure the instance local cache at boot time
-
D
Migrate from ElastiCache to DynamoDB. Create an AMI that contains the web application. Configure the dynamic part at runtime using an EC2 User Data script
Xem giải thích
Đáp án
B — Tạo AMI chứa sẵn ứng dụng web, phần cấu hình động xử lý lúc chạy bằng EC2 User Data.
Vì sao đúng
Bài toán là 20 phút khởi động, chia làm hai nửa rất khác nhau:
| Việc | Thời gian | Bản chất |
|---|---|---|
| Cài và cấu hình ứng dụng web | 10 phút | tĩnh — lần nào cũng ra kết quả giống nhau |
| Làm nóng cache dữ liệu cục bộ | 10 phút | động — phụ thuộc dữ liệu tại thời điểm đó |
Phần tĩnh là thứ duy nhất "nướng" (bake) vào AMI được, và đó chính là ý nghĩa của golden AMI: trả 10 phút đó một lần lúc build image, để mỗi instance mới bung ra đã có sẵn ứng dụng. Phần cấu hình khác nhau giữa các instance (endpoint của RDS, endpoint ElastiCache, tên môi trường) đặt vào User Data — script này chạy đúng một lần lúc boot đầu tiên.
Đây là mô hình lai baked + booted mà AWS khuyến nghị cho Auto Scaling: bake thứ không đổi, boot thứ có đổi.
Vì sao các phương án khác sai
- A. Chép luôn cache cục bộ vào AMI — cache là ảnh chụp dữ liệu tại thời điểm build AMI. Instance bung ra tuần sau sẽ khởi động nhanh nhưng phục vụ dữ liệu cũ, và không có cơ chế nào biết nó cũ. Đổi một vấn đề hiệu năng lấy một vấn đề đúng-sai dữ liệu là nước lùi. Muốn cache nóng sẵn thì dùng ElastiCache (đã có) chứ không nhân bản cache vào image.
- C. Dùng Lambda nạp cache cục bộ lúc boot — Lambda không có đường ghi vào ổ đĩa cục bộ của một EC2 instance. Muốn làm vậy phải qua SSM Run Command, và khi ấy vẫn mất đúng 10 phút nạp cache, chỉ thêm một dịch vụ vào đường đi.
- D. Chuyển ElastiCache sang DynamoDB — thay tầng cache không rút ngắn được thời gian làm nóng cache cục bộ trên instance, mà lại là một cuộc di trú lớn không liên quan gì tới yêu cầu.
Ghi nhớ
Cái gì giống nhau ở mọi instance thì nướng vào AMI; cái gì khác nhau giữa các instance hoặc thay đổi theo thời gian thì để User Data. Đừng bao giờ nướng dữ liệu vào image — chỉ nướng phần mềm.
An Aurora cluster is configured with a single DB instance for a web application. The application uses the instance endpoint to read/write data to the database. The operations team has scheduled an update on the cluster during the upcoming maintenance window. The application support team has requested help to ensure uninterrupted access to the application during the maintenance window.
Which step should a DevOps Engineer take so that the users experience the least possible interruption during the maintenance window?
-
A
Add a reader instance to the Aurora cluster. Update the application configuration to use the Aurora cluster custom endpoints by creating two groups of DB instances, one for read and the other for write requests. Update the Aurora cluster's reader endpoint to point to the read DB group of instances
-
B
Add a reader instance to the Aurora cluster. Update the application configuration to use the Aurora cluster endpoint for write operations. Update the Aurora cluster reader endpoint for read operations
-
C
Turn on the Multi-AZ option on the Aurora cluster. Update the application configuration to use the Aurora cluster Multi-AZ instance endpoint for read/write operations
-
D
Turn on the Multi-AZ option on the Aurora cluster write operations. Update the application configuration to use the Aurora cluster endpoint for write operations. Read operations will automatically be served since its a Multi-AZ cluster configuration
Xem giải thích
Đáp án
B — Thêm một reader instance; ứng dụng ghi qua cluster endpoint, đọc qua reader endpoint.
Vì sao đúng
Vấn đề nằm ở chỗ ứng dụng đang dùng instance endpoint — địa chỉ trỏ thẳng vào đúng một DB instance. Bảo trì instance đó là mất kết nối, không có gì đỡ.
Aurora cho ba loại endpoint:
| Endpoint | Trỏ vào đâu | Tự chuyển khi failover? |
|---|---|---|
| Cluster (writer) | instance đang giữ vai writer | ✅ có |
| Reader | cân tải vòng qua các replica | ✅ có |
| Instance | đúng một instance cụ thể | ❌ không |
| Custom | nhóm instance do bạn định nghĩa | ✅ trong nhóm |
Một cluster chỉ có một instance thì cũng không có gì để failover sang. Thêm reader instance đạt hai việc cùng lúc: có chỗ để Aurora đưa vai writer sang khi instance kia được bảo trì (thường trong khoảng 30 giây), và có chỗ nhận tải đọc.
Vì sao các phương án khác sai
- A. Custom endpoint — làm được về mặt kỹ thuật nhưng custom endpoint sinh ra để phân nhóm theo cấu hình (ví dụ nhóm instance mạnh dành cho báo cáo). Dùng nó thay cho reader endpoint có sẵn là tự thêm việc quản lý thành viên nhóm mà chẳng được gì thêm.
- C và D. "Bật Multi-AZ trên cluster Aurora" — Aurora không có nút Multi-AZ như RDS truyền thống. Lớp lưu trữ của Aurora vốn đã trải sáu bản sao trên ba AZ ngay từ khi tạo cluster. Cái gọi là "Multi-AZ" ở Aurora chính là việc có replica ở AZ khác — tức là đúng việc mà phương án B mô tả bằng đúng tên gọi.
Ghi nhớ
Không bao giờ để ứng dụng production trỏ vào instance endpoint của Aurora. Ghi → cluster endpoint, đọc → reader endpoint.
A company uses an AWS CodePipeline pipeline to deploy updates to the API several times a month. As part of this process, the DevOps team exports the JavaScript SDK for the API from the API Gateway console and uploads it to an Amazon S3 bucket, which is being used as an origin for an Amazon CloudFront distribution. Web clients access the SDK through the CloudFront distribution's endpoint. The goal is to have an automated solution that ensures the latest SDK is always available to clients whenever there's a new API deployment.
As an AWS Certified DevOps Engineer - Professional, what solution will you suggest?
-
A
Set up a CodePipeline action that runs immediately after the API deployment stage. Configure this action to invoke an AWS Lambda function. The Lambda function will then download the SDK from API Gateway, upload it to the S3 bucket, and create a CloudFront invalidation for the SDK path
-
B
Set up an Amazon EventBridge rule that reacts to CreateDeployment events from aws.apigateway. Configure this rule to leverage the CodePipeline integration with API Gateway to export the SDK to Amazon S3. Trigger another action that calls the S3 API to invalidate the cache for the SDK path
-
C
Set up a CodePipeline action that runs immediately after the API deployment stage. Configure this action to leverage the CodePipeline integration with API Gateway to export the SDK to Amazon S3. Trigger another action that calls the S3 API to invalidate the cache for the SDK path
-
D
Set up an Amazon EventBridge rule on a schedule that is invoked every 5 minutes. Configure this rule to invoke an AWS Lambda function. The Lambda function will then download the SDK from API Gateway, upload it to the S3 bucket, and create a CloudFront invalidation for the SDK path
Xem giải thích
Đáp án
A — Thêm một action trong CodePipeline ngay sau stage deploy API, gọi Lambda để export SDK, đẩy lên S3 và invalidate CloudFront.
Vì sao đúng
Yêu cầu là "SDK mới nhất luôn sẵn sàng mỗi khi API được deploy". Từ khoá là mỗi khi — nghĩa là phải mắc vào chính sự kiện deploy, và pipeline đã có sẵn chỗ để mắc.
Lambda làm ba việc theo đúng thứ tự:
# 1. Xuất SDK JavaScript của stage vừa deploy
aws apigateway get-sdk --rest-api-id abc123 --stage-name prod \
--sdk-type javascript sdk.zip
# 2. Đẩy lên bucket origin
aws s3 cp sdk.zip s3://my-sdk-bucket/sdk.zip
# 3. Xoá bản cũ trong cache CloudFront
aws cloudfront create-invalidation --distribution-id E123 --paths "/sdk.zip"
Bước 3 là bước hay bị quên nhất: đẩy file mới lên S3 mà không invalidate thì CloudFront vẫn phục vụ bản cũ cho tới khi hết TTL — client tải về SDK không khớp API vừa đổi.
Vì sao các phương án khác sai
- B và C. "CodePipeline integration với API Gateway để export SDK" — thứ tích hợp này không tồn tại. CodePipeline có action deploy CloudFormation, ECS, S3, Lambda… nhưng không có action "export API Gateway SDK". Muốn có thì phải tự viết, tức là quay về phương án A.
- D. EventBridge chạy theo lịch 5 phút — vừa lãng phí (deploy vài lần mỗi tháng, nhưng chạy ~8.640 lần mỗi tháng) vừa để lại cửa sổ tới 5 phút trong đó SDK không khớp API. Lịch định kỳ là câu trả lời sai cho một câu hỏi có sự kiện rõ ràng.
Ghi nhớ
Có sự kiện thì bám vào sự kiện, đừng polling. Và mỗi lần thay nội dung sau CloudFront, nhớ invalidate — nếu không thì phần việc còn lại coi như không có tác dụng.
A company having hundreds of AWS accounts manages its operations and security through a single organization created in AWS Organizations. As per the company's policy, AWS Config and AWS CloudTrail are enabled for all accounts. The security policy mandates configuring AWS Web Application Firewall (AWS WAF) web ACLs for all internet-facing Application Load Balancers (ALBs) and Amazon API Gateway APIs. However, monthly audit reports consistently report unsecured ALBs and API Gateway APIs.
As a DevOps engineer, the security team has requested you to automate these configurations for all accounts to avoid oversight. What steps will you recommend?
-
A
Designate one of the AWS accounts in your organization as the administrator for Firewall Manager in AWS Organizations. Create an AWS Firewall Manager policy to attach AWS WAF web ACLs to any newly created ALBs and API Gateway APIs
-
B
Configure a managed rule in AWS Config to attach AWS WAF web ACLs to any newly created ALBs and API Gateway APIs
-
C
Create an Amazon GuardDuty policy to attach AWS WAF web ACLs to any newly created ALBs and API Gateway APIs
-
D
Create an Amazon Systems Manager policy to attach AWS WAF web ACLs to any newly created ALBs and API Gateway APIs
Xem giải thích
Đáp án
A — Chỉ định một tài khoản làm Firewall Manager administrator, rồi tạo policy của Firewall Manager để tự gắn WAF web ACL.
Vì sao đúng
Sai lầm ở đây là kiểm tra thủ công: báo cáo tháng phát hiện ALB không có WAF, nhưng phát hiện sau khi nó đã hở cả tháng. Cần thứ tự gắn, không phải thứ tự báo.
AWS Firewall Manager sinh ra đúng cho việc này. Nó nằm trên AWS Organizations và:
- Tự áp policy lên tài khoản/OU đã chọn, kể cả tài khoản mới tạo sau này
- Tự gắn web ACL vào tài nguyên mới khớp phạm vi (lọc theo loại tài nguyên và theo tag)
- Tự khắc phục tài nguyên đang lệch chuẩn (remediation)
Điều kiện tiên quyết đã có đủ trong đề: Organizations bật hết tính năng, và AWS Config bật ở mọi tài khoản — Firewall Manager dựa vào Config để biết tài nguyên nào đang tồn tại.
Vì sao các phương án khác sai
- B. AWS Config managed rule — Config đánh giá và có thể gọi remediation qua SSM, nhưng không có managed rule nào gắn WAF web ACL. Managed rule chỉ nói COMPLIANT / NON_COMPLIANT. Tự viết remediation thì đúng là làm lại Firewall Manager bằng tay, cho hàng trăm tài khoản.
- C. GuardDuty — là dịch vụ phát hiện mối đe doạ (đọc VPC Flow Logs, DNS logs, CloudTrail). Nó không cấu hình tài nguyên và không có khái niệm "policy gắn web ACL".
- D. "Systems Manager policy" — không có thứ này. SSM có document, association, patch baseline; không có policy gắn WAF cho cả tổ chức.
Ghi nhớ
Ba dịch vụ hay lẫn ở tầng tổ chức: SCP chặn quyền gọi API, AWS Config phát hiện lệch chuẩn, Firewall Manager tự áp và tự sửa cấu hình bảo vệ biên (WAF, Shield, security group, Network Firewall, Route 53 Resolver DNS Firewall).
An AWS managed cloudformation-stack-drift-detection-check rule is defined in AWS Config for drift detection in AWS CloudFormation resources. The DevOps team is facing two issues:
a) How to detect drifts of Cloudformation custom resources b) Drift status of the stack shows as IN_SYNC in the CloudFormation console, the following is the drift detection error - 'While AWS CloudFormation failed to detect drift, defaulting to NON_COMPLIANT. Re-evaluate the rule and try again. If the problem persists contact AWS CloudFormation support'
As a DevOps Engineer, which steps will you combine to fix the aforementioned issues? (Select two)
-
A
AWS CloudFormation only determines drift for property values that are explicitly set. Explicitly set the property values for your custom resource to be included in drift
-
B
This error is a false positive and can be ignored for this scenario
-
C
AWS Config rule depends on the availability of
DetectStackDriftaction of CloudFormation API. AWS Config defaults the rule to NON_COMPLIANT when throttling occurs -
D
You receive the error when the AWS Identity and Access Management (IAM) role for the required
cloudformationRoleArnparameter doesn't have sufficient service permissions -
E
AWS CloudFormation does not support drift detection of custom resources
Xem giải thích
Đáp án
C và E.
- C — Config rule phụ thuộc vào
DetectStackDriftcủa CloudFormation API; bị throttle thì Config mặc định trả NON_COMPLIANT. - E — CloudFormation không hỗ trợ drift detection cho custom resource.
Vì sao đúng
Đề nêu hai hiện tượng, và chúng có hai nguyên nhân độc lập.
Vấn đề (b) — console báo IN_SYNC nhưng Config báo NON_COMPLIANT. Hai bên nhìn hai thứ khác nhau: console hiển thị kết quả lần detect gần nhất đã chạy xong, còn rule cloudformation-stack-drift-detection-check tự gọi DetectStackDrift ở mỗi lần đánh giá. Gọi API đó có giới hạn tần suất, mà rule chạy trên nhiều stack cùng lúc thì rất dễ bị throttle. Khi Config không lấy được kết quả, nó không trả "không xác định" — nó mặc định NON_COMPLIANT, kèm đúng thông báo trong đề. Đó là lý do trạng thái hai nơi mâu thuẫn nhau.
Vấn đề (a) — drift của custom resource. Đơn giản là không làm được. Drift detection so thuộc tính thực tế của tài nguyên với template, mà custom resource được hiện thực bằng Lambda hoặc SNS do bạn viết — CloudFormation không biết "trạng thái thực tế" của nó là gì để mà so. Cùng nhóm không hỗ trợ còn có nested stack và một số loại tài nguyên khác.
Vì sao các phương án khác sai
- A. "Chỉ set tường minh property là detect được custom resource" — câu đầu đúng (drift chỉ xét property được set tường minh) nhưng kết luận sai: có set gì thì custom resource vẫn nằm ngoài phạm vi hỗ trợ.
- B. "False positive, bỏ qua được" — nguy hiểm nhất trong bốn phương án. Rule đang không đánh giá được chứ không phải đang báo nhầm; dạy đội vận hành bỏ qua NON_COMPLIANT là vô hiệu hoá luôn kiểm soát tuân thủ.
- D. Thiếu quyền cho
cloudformationRoleArn— thiếu quyền thì thông báo lỗi sẽ nói vềAccessDenied, không phải "failed to detect drift, defaulting to NON_COMPLIANT… Re-evaluate the rule and try again". Cụm "thử lại đi" chính là dấu hiệu của lỗi tạm thời do throttling.
Ghi nhớ
Khi một Config rule gọi API của dịch vụ khác, throttling biểu hiện thành NON_COMPLIANT, không thành lỗi. Thấy compliance nhảy loạn trên số lượng lớn tài nguyên thì nghĩ tới giới hạn tần suất trước khi nghĩ tới cấu hình sai.