Ngân hàng đề — AWS Certified DevOps Engineer Professional
Tìm thấy 681 câu.
A company has hired you as an AWS Certified DevOps Engineer - Professional to provide recommendations for a failed security audit of its flagship project. You have been tasked to review the company's buildspec.yaml file for its AWS CodeBuild project. Upon investigation, you have noticed that the file has hard-coded values for the environment variables that reference the AWS Access Key ID, Secret Access Key, and the database password. In addition, to perform one-time configuration changes during the build phase, the file has commands to ssh and scp into an EC2 instance using an SSH private key stored on Amazon S3.
What changes would you recommend to comply with AWS security best practices? (Select three)
-
A
Leverage the AWS Systems Manager automation document to manage the EC2 instance, rather than using commands to
sshandscpinto the EC2 instance via the SSH private key stored on Amazon S3 -
B
Configure the CodeBuild project role with the necessary permissions policy and then delete the environment variables referencing the AWS credentials from the buildspec.yaml file
-
C
Store the database password as a SecureString value in AWS Systems Manager Parameter Store which is then referenced in the buildspec environment. Also, delete the environment variable referencing the hard-coded value of the database password from the buildspec.yaml file
-
D
Leverage the AWS Systems Manager
runcommand to manage the EC2 instance, rather than using commands tosshandscpinto the EC2 instance via the SSH private key stored on Amazon S3 -
E
Store the database password as a SecureString value in AWS Secrets Manager which is then referenced in the buildspec environment. Also, delete the environment variable referencing the hard-coded value of the database password from the buildspec.yaml file
-
F
Store the environment variables that reference the AWS
Access Key ID,Secret Access Key, and the database password in an encrypted format on Amazon S3. Leverage a Python script to dynamically import the values from S3 during the pre-build phase
Xem giải thích
Đáp án
B, C và D.
- B — Cấp quyền qua IAM role của CodeBuild project, xoá biến môi trường chứa AWS credentials.
- C — Đưa mật khẩu CSDL vào SSM Parameter Store kiểu SecureString, tham chiếu từ buildspec.
- D — Dùng SSM Run Command thay cho
ssh/scpbằng khoá riêng để trên S3.
Vì sao đúng
Ba lỗi bảo mật, ba cách chữa:
1. Access key ghi cứng trong buildspec (B). CodeBuild chạy dưới một service role; mọi quyền gọi AWS lấy từ đó qua thông tin xác thực tạm thời, tự xoay vòng. Access key tĩnh trong file nằm trong Git, ai clone repo cũng có — và nó không bao giờ tự hết hạn.
2. Mật khẩu CSDL ghi cứng (C). SecureString trong Parameter Store được mã hoá bằng KMS và tham chiếu trực tiếp trong buildspec:
env:
parameter-store:
DB_PASSWORD: /prod/db/password
Giá trị không bao giờ xuất hiện trong mã nguồn.
3. ssh/scp bằng khoá riêng lấy từ S3 (D). Đây mới là lỗ hổng nặng nhất: một khoá SSH nằm trên S3 mà build nào cũng tải về được. SSM Run Command bỏ hoàn toàn khoá SSH — chạy lệnh trên instance qua SSM Agent, quyền kiểm soát bằng IAM, mỗi lần chạy đều có vết trong CloudTrail.
Vì sao các phương án khác sai
- A. SSM Automation document — cùng hướng đúng với D, nhưng Automation dùng cho quy trình nhiều bước có điều kiện (kiểu dựng AMI, vá hàng loạt). Chạy vài lệnh cấu hình một lần thì Run Command là công cụ tương xứng. Nếu đề chỉ chọn ba thì D sát hơn.
- E. Secrets Manager — về bảo mật thì tốt ngang hoặc hơn (có xoay vòng tự động), nhưng CodeBuild
envchỉ hỗ trợ tham chiếuparameter-storevàsecrets-managervới cú pháp khác nhau, và với một mật khẩu tĩnh không cần xoay vòng thì Parameter Store SecureString là lựa chọn miễn phí. Đây là lý do nguồn chọn C thay vì E. - F. Mã hoá biến rồi để trên S3, script Python tự nạp — tự chế lại cả một dịch vụ quản lý bí mật, thêm mã phải bảo trì và thêm chỗ để sai. Vẫn phải giải bài toán "ai giữ khoá giải mã".
Ghi nhớ về chất lượng câu hỏi
C và E gần như tương đương về mặt bảo mật. Cả hai đều bỏ được mật khẩu ghi cứng. Nguồn chọn C, và lý do hợp lý nhất là chi phí (Parameter Store standard miễn phí, Secrets Manager tính tiền mỗi bí mật mỗi tháng) — nhưng đề không nêu chi phí làm tiêu chí. Trong thực tế, nếu mật khẩu CSDL cần xoay vòng định kỳ thì Secrets Manager là lựa chọn đúng hơn.
A CloudFormation stack consists of the following AWS resources - Amazon Simple Storage Service (Amazon S3) bucket, Amazon Amazon Elastic Compute Cloud (Amazon EC2) instance, and an Amazon EBS Volume. Due to a high-impact security issue, the DevOps team has been asked to rename the AWS CloudFormation stack. However, the resources created by the stack cannot be deleted for business purposes.
What steps will you take to rename the CloudFormation stack without deleting the resources created?
-
A
Launch a CloudFormation stack that deploys all the resources of the stack. Add a
Retainattribute to the deletion policy of each of these resources. Delete the original stack. Create a new stack with a different name and import the resources that were retained from the original stack. Remove theRetainattribute from the stack to revert to the original template -
B
Launch a new CloudFormation stack that deploys all the resources of the stack. Launch another CloudFormation stack that deploys all the resources of the stack with a new name. In the second CloudFormation stack use, the
DependsOnattribute to create the resource dependency on the first stack. Delete both the stacks while retaining the resources -
C
Launch a CloudFormation stack that deploys all the resources of the stack. Add a
Retainattribute to the deletion policy of the S3 bucket and EC2 instance. Add a 'Snapshot' attribute to the deletion policy of Amazon EBS Volume. Delete the original stack. Create a new stack with a different name and import the resources that were retained from the original stack. Remove theRetainand 'Snapshot' attribute from the stack to revert to the original template -
D
Use CloudFormation registry to create custom hooks for all the resources of the CloudFormation stack. Then, delete the original CloudFormation stack and recreate a new one with the updated name. Using the hooks created earlier, import the resources back into the newly created stack
Xem giải thích
Đáp án
A — Thêm DeletionPolicy: Retain cho từng tài nguyên, xoá stack cũ, tạo stack mới với tên khác rồi import lại tài nguyên.
Vì sao đúng
Sự thật nền tảng: tên stack CloudFormation không đổi được. Không có rename-stack trong API, và tên nằm trong ARN của stack.
Nên cách duy nhất là đi vòng, và DeletionPolicy: Retain chính là chìa khoá:
Resources:
KhoDuLieu:
Type: AWS::S3::Bucket
DeletionPolicy: Retain # xoá stack thì bucket vẫn còn
MayChu:
Type: AWS::EC2::Instance
DeletionPolicy: Retain
OD:
Type: AWS::EBS::Volume
DeletionPolicy: Retain
Quy trình đủ:
- Cập nhật stack hiện tại để mọi tài nguyên có
DeletionPolicy: Retain. - Xoá stack — CloudFormation bỏ quản lý nhưng không xoá tài nguyên nào.
- Tạo stack mới với tên mong muốn, dùng resource import để nhận lại đúng những tài nguyên đó.
Vì sao các phương án khác sai
- B. Dựng hai stack song song rồi làm gì đó ở stack thứ hai — tạo thêm stack nghĩa là tạo thêm tài nguyên mới, không phải đổi tên tài nguyên đang có. Bucket không trùng tên được, và bạn kết thúc với hạ tầng nhân đôi.
- C.
Retaincho S3 và EC2,Snapshotcho EBS — bẫy tinh vi.DeletionPolicy: Snapshotchụp ảnh rồi XOÁ volume gốc. Đề nói rõ tài nguyên không được xoá. Khôi phục từ snapshot cho ra volume mới với ID khác, tức là mất chính thứ cần giữ. - D. CloudFormation Hooks — hook là cơ chế kiểm tra trước khi tạo/sửa tài nguyên (chặn cấu hình vi phạm chính sách). Nó không giữ lại tài nguyên khi xoá stack.
Ghi nhớ
Ba giá trị của DeletionPolicy: | Giá trị | Hậu quả | |---|---| | Delete (mặc định) | Xoá tài nguyên | | Retain | Giữ nguyên, chỉ bỏ quản lý | | Snapshot | Chụp ảnh rồi xoá — chỉ áp dụng cho EBS, RDS, ElastiCache, Redshift… |
Snapshot nghe an toàn nhưng vẫn là xoá. Cần giữ nguyên vật thì luôn dùng Retain.
A company implements access control by creating different policies for different job functions. These policies are attached to IAM roles/groups with minimum permissions necessary for the job function. Up until this point, the solution has been functioning effectively. However, with business expansion, the administrator has to frequently update the existing policies to allow access to new resources.
Which of the following solutions can make the access control applicable to all new resources without the need to update the policies?
-
A
Create a Resource-based policy on the newly created resources to add to the existing permissions of the IAM roles accessing the created resources
-
B
Configure Attribute-based access control by use of tags. Create tags for IAM roles based on their function. Whenever a new resource is created, add these tag(s) to the resource for immediate access to the resource created
-
C
Configure Access control lists (ACLs) to allow access to certain principals in the account. Add the ACLs to a session policy to dynamically add permissions to the IAM role that the user already has
-
D
Create an AWS Organization and enable all the features. Attach identity-based IAM roles for newly created resources and share them using Service control policies (SCPs) with all member accounts of the organization
Xem giải thích
Đáp án
B — Dùng ABAC (Attribute-Based Access Control) bằng tag: gắn tag cho IAM role theo chức năng, và gắn cùng tag đó cho tài nguyên mới.
Vì sao đúng
Vấn đề trong đề là vấn đề quy mô của mô hình RBAC: mỗi lần thêm tài nguyên là phải sửa policy. Số policy phải bảo trì tăng theo số tài nguyên.
ABAC đảo ngược chuyện đó. Policy viết một lần, so tag của người gọi với tag của tài nguyên:
{
"Effect": "Allow",
"Action": ["ec2:StartInstances", "ec2:StopInstances"],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"
}
}
}
Từ đó, tài nguyên mới gắn đúng tag là có quyền ngay, không ai phải sửa policy. Đây chính xác là điều đề yêu cầu: "áp dụng được cho mọi tài nguyên mới mà không cần cập nhật policy".
Đổi lại, ABAC dời trách nhiệm sang kỷ luật gắn tag — nên trong thực tế thường đi kèm SCP hoặc Config rule bắt buộc phải có tag.
Vì sao các phương án khác sai
- A. Resource-based policy trên từng tài nguyên mới — vẫn là viết policy cho từng tài nguyên, chỉ chuyển chỗ phải sửa từ IAM sang tài nguyên. Không giải quyết gì. Ngoài ra phần lớn dịch vụ AWS không hỗ trợ resource-based policy (chỉ có S3, SQS, SNS, KMS, Lambda, Secrets Manager…).
- C. ACL + session policy — ACL là cơ chế cũ, gần như chỉ còn ở S3, và AWS khuyến nghị không dùng. Session policy thì chỉ thu hẹp quyền của phiên, không bao giờ mở rộng — nên câu "dynamically add permissions" là sai về nguyên lý.
- D. SCP chia sẻ IAM role — sai hai chỗ: SCP giới hạn quyền tối đa, không cấp quyền; và SCP không phải cơ chế chia sẻ role. Chia sẻ tài nguyên giữa các tài khoản là việc của AWS RAM.
Ghi nhớ
| RBAC | ABAC | |
|---|---|---|
| Số policy | tăng theo số vai + tài nguyên | gần như cố định |
| Tài nguyên mới | phải sửa policy | chỉ gắn tag |
| Rủi ro chính | policy phình to, khó rà | tag sai = quyền sai |
A support team wants to be notified via an Amazon Simple Notification Service (Amazon SNS) notification when an AWS Glue job fails a retry.
As a DevOps Engineer, how will you implement this requirement?
-
A
Configure Amazon EventBridge events for AWS Glue. Configure an Amazon Simple Notification Service (Amazon SNS) notification when the Glue job fails a retry
-
B
Check the AWS Personal Health Dashboard for failed AWS Glue jobs. Schedule an AWS Lambda function to pick the failed event from the service health dashboard and trigger an Amazon Simple Notification Service (Amazon SNS) notification when a retry fails
-
C
Amazon Simple Notification Service (Amazon SNS) cannot retry failures, leverage Amazon Simple Queue Service (Amazon SQS) dead-letter queues to retry the failed Glue jobs
-
D
Configure Amazon EventBridge events for AWS Glue. Define the AWS Lambda function as a target to the EventBridge. The Lambda function will have the logic to process the events and filter the AWS Glue job retry failure event. Publish a message to Amazon Simple Notification Service (Amazon SNS) notification if such an event is found
Xem giải thích
Đáp án
D — EventBridge bắt sự kiện của AWS Glue, đưa vào Lambda để lọc riêng trường hợp retry thất bại, rồi Lambda gọi SNS.
Vì sao đúng
Điểm mấu chốt nằm ở chữ "fails a retry" — không phải "job thất bại", mà là lần chạy lại cũng thất bại.
Glue phát sự kiện Glue Job State Change với state = FAILED cho mọi lần thất bại, kể cả lần đầu. Bản thân event pattern của EventBridge không phân biệt được đó là lần chạy đầu hay lần retry — thông tin đó nằm ở các trường như jobRunId, attemptId/previousRunId trong detail, và EventBridge chỉ so khớp giá trị chứ không suy luận được quan hệ giữa các lần chạy.
Vậy phải có một bước có logic: Lambda nhận mọi sự kiện FAILED, tự xác định đây có phải retry hay không (đọc attemptId, hoặc gọi GetJobRun để tra), rồi mới quyết định có gửi SNS không.
def handler(event, context):
d = event['detail']
if d.get('state') == 'FAILED' and d.get('attemptId', 0) > 0:
sns.publish(TopicArn=TOPIC, Subject='Glue job retry thất bại',
Message=f"Job {d['jobName']} run {d['jobRunId']} lỗi: {d.get('message')}")
Vì sao các phương án khác sai
- A. EventBridge gửi thẳng SNS — rất gần đúng và là bẫy chính. Nó báo mọi lần job hỏng, kể cả lần đầu mà sau đó retry thành công — tức là báo động giả cho tình huống hệ thống đã tự chữa xong. Thiếu đúng bước lọc mà đề đòi.
- B. Personal Health Dashboard — PHD báo sự cố của chính AWS ảnh hưởng tới tài khoản bạn, không báo job của bạn viết sai SQL. Sai nguồn dữ liệu.
- C. SQS dead-letter queue để retry job Glue — lẫn lộn khái niệm. DLQ chứa message không xử lý được; nó không chạy lại Glue job, và đề cũng không hỏi về việc chạy lại.
Ghi nhớ
EventBridge lọc tĩnh theo cấu trúc JSON của một sự kiện. Cần lọc theo trạng thái tích luỹ ("lần thứ mấy", "đã hỏng N lần liên tiếp") thì bắt buộc phải chèn một bước có logic — Lambda hoặc Step Functions.
A web application is hosted on Amazon EC2 instances behind an Application Load Balancer (ALB). While using CodeDeploy Blue/Green deployment to deploy a new version, the deployment failed during the AllowTraffic lifecycle event. The DevOps team has found no errors in the deployment logs.
Which of the following would you identify as the root cause behind the failure of the deployment?
-
A
The cause of the failure could be a script from the last successful deployment that never runs successfully. Create a new deployment and specify that the ApplicationStop, BeforeBlockTraffic, and AfterBlockTraffic failures should be ignored
-
B
Incorrectly configured health checks on Application Load Balancer (ALB) are responsible for this issue
-
C
If an instance is terminated between lifecycle events or before the first lifecycle event step starts, then
AllowTrafficlifecycle event fails without generating logs -
D
A scale-in event or any other termination event, during an in-progress deployment, causes the instance to detach from the Amazon EC2 Auto Scaling group and the instance fails the
AllowTrafficlifecycle event
Xem giải thích
Đáp án
B — Health check trên ALB cấu hình sai.
Vì sao đúng
Manh mối trong đề đã khoanh vùng rất hẹp: hỏng ở AllowTraffic và không có lỗi nào trong log deployment.
AllowTraffic là bước CodeDeploy đăng ký instance mới vào target group rồi chờ chúng chuyển sang healthy. Bước này không chạy script nào của bạn — nên đương nhiên không có log lỗi ứng dụng để đọc. Nó chỉ thất bại khi hết thời gian chờ mà target vẫn không lành.
Health check sai kiểu nào cũng ra đúng triệu chứng đó:
| Cấu hình | Hậu quả |
|---|---|
Sai đường dẫn (/health mà app không có) |
trả 404, mãi không healthy |
| Sai cổng (80 mà app nghe 8080) | không kết nối được |
HealthyThresholdCount × Interval > thời gian app khởi động |
timeout trước khi app kịp sẵn sàng |
| Mã kỳ vọng sai (chờ 200 mà app trả 302) | không bao giờ đạt |
| Security group không cho ALB vào cổng health check | mọi lần kiểm tra đều rớt |
Cách kiểm chứng: xem Target group → Targets trong console; cột Health status details nói thẳng lý do (Health checks failed with these codes: [404]).
Vì sao các phương án khác sai
- A. Script từ lần deploy trước không chạy được — vấn đề này có thật, nhưng nó xảy ra ở
ApplicationStop/BeforeBlockTraffic, tức là đầu vòng đời, không phảiAllowTraffic. Ngoài ra trong Blue/Green, instance xanh là instance mới hoàn toàn, không có bản revision cũ nào để chạy script cũ. - C và D. Instance bị huỷ giữa chừng do scale-in — có thể làm deploy hỏng, nhưng khi ấy sẽ có sự kiện và log ghi lại việc instance bị gỡ. Đề nói rõ log sạch. Hơn nữa trong Blue/Green, fleet xanh vừa được tạo cho lần deploy này nên khả năng bị scale-in ngay là rất thấp.
Ghi nhớ
Bản đồ chẩn đoán theo lifecycle event: | Hỏng ở | Nghi ngờ đầu tiên | |---|---| | ApplicationStop | script của revision cũ hỏng | | DownloadBundle | quyền S3 / IAM role | | BeforeInstall, AfterInstall | script của bạn | | AllowTraffic | health check của ELB | | ValidateService | script kiểm thử của bạn |
A data analytics company wants to move all its clients belonging to the regulated and security-sensitive industries such as financial services and healthcare to the AWS Cloud as it wants to leverage the out-of-box security-specific capabilities offered by AWS. The DevOps team at the company is developing a framework to validate the adoption of AWS best practices and industry-recognized compliance standards. The AWS Management Console is the preferred method for the in-house teams wanting to provision resources.
Which of the following strategies would you adopt to address these business requirements for continuously assessing, auditing and monitoring the configurations of AWS resources? (Select two)
-
A
Leverage AWS Config rules to audit changes to AWS resources and monitor the compliance of the configuration by running the evaluations for the rule at a frequency that you choose. Develop AWS Config custom rules to establish a test-driven development approach by triggering the evaluation when any resource that matches the rule's scope changes in configuration
-
B
Leverage CloudTrail integration with SNS to automatically notify unauthorized API activities. Ensure that CloudTrail is enabled for all accounts as well as all available AWS services. Use Lambda functions to automatically revert non-authorized changes in AWS resources
-
C
Enable trails and set up CloudTrail events to review and monitor management activities of all AWS accounts by logging these activities into CloudWatch Logs using a KMS key. Ensure that CloudTrail is enabled for all accounts as well as all available AWS services
-
D
Leverage EventBridge events near-real-time capabilities to monitor system events patterns to trigger Lambda functions to automatically revert non-authorized changes in AWS resources. Send notifications via SNS topics to improve the incidence response time
-
E
Leverage CloudWatch Logs agent to collect all the AWS SDK logs. Search the log data using a pre-defined set of filter patterns that match mutating API calls. Use CloudWatch alarms to send notifications via SNS when unintended changes are performed. Archive log data by using a batch export to Amazon S3 and analyze via Athena
Xem giải thích
Đáp án
A và C.
- A — AWS Config rule kiểm toán thay đổi tài nguyên và đánh giá tuân thủ theo tần suất bạn chọn, kèm custom rule cho chuẩn riêng.
- C — Bật CloudTrail cho mọi tài khoản và mọi Region, đưa log vào CloudWatch Logs, mã hoá bằng KMS.
Vì sao đúng
Đề nêu hai nhu cầu khác nhau về bản chất, và đây là cặp bổ sung kinh điển:
| AWS Config | CloudTrail | |
|---|---|---|
| Trả lời câu hỏi | Tài nguyên đang ở trạng thái nào? Có đúng chuẩn không? | Ai đã làm gì, lúc nào, từ đâu? |
| Dữ liệu | ảnh chụp cấu hình theo thời gian | nhật ký lời gọi API |
| Dùng cho | tuân thủ, phát hiện lệch chuẩn | điều tra, truy vết |
Chi tiết đáng chú ý trong đề: "AWS Management Console là cách các đội thích dùng để tạo tài nguyên". Nghĩa là tài nguyên được tạo bằng tay, ngoài mọi pipeline — nên không thể kiểm soát trước lúc tạo, chỉ còn cách phát hiện sau khi tạo. Đó chính là mô hình detective control mà Config sinh ra để làm.
Vế mã hoá log bằng KMS ở C không phải chi tiết trang trí: với ngành tài chính và y tế, log kiểm toán là dữ liệu nhạy cảm và thường bị quy định bắt buộc mã hoá.
Vì sao các phương án khác sai
- B. CloudTrail tích hợp SNS để báo API "trái phép" — CloudTrail không phân loại được cái gì là trái phép; nó ghi tất cả như nhau. Muốn có phán xét thì phải có metric filter hoặc Config rule. Ngoài ra "tự động khắc phục bằng Lambda" là sửa chữa, còn đề hỏi khung xác thực việc tuân thủ.
- D. EventBridge tự động hoàn tác thay đổi trái phép — đây là remediation, không phải validation. Còn nguy hiểm nữa: tự động đảo ngược thay đổi mà không có ngữ cảnh dễ phá hỏng công việc hợp lệ.
- E. CloudWatch Logs agent thu "AWS SDK logs" — không có thứ gọi là "log của AWS SDK" tập trung được như vậy. Muốn ghi lời gọi API thì đã có CloudTrail; dựng lại nó bằng agent là vừa thiếu vừa không đáng tin.
Ghi nhớ
Câu hỏi về tuân thủ và chuẩn ngành trên AWS gần như luôn ra bộ ba: CloudTrail (ai làm gì) + Config (trạng thái có đúng chuẩn không) + Security Hub (gom kết quả theo khung chuẩn như CIS, PCI DSS).
An application runs on a fleet of Amazon EC2 instances that are configured with an Auto Scaling group (ASG). Both Spot and On-Demand instances are utilized as per the ASG configuration. For the most part, the ASG seems to be working fine as expected. There are a few issues that the DevOps team has flagged:
a) During a scale-in activity, ASG has terminated instance in the Availability Zone (AZ) that already had fewer instances than the other b) For some duration, ASG exceeded the specified maximum capacity of the group
What reasons can you identify for this behavior? (Select two)
-
A
The instance that was launched from the oldest launch template or launch configuration is terminated first. This can temporarily lead to an unbalanced group
-
B
When an Auto Scaling group with a mixed instances policy scales in, Amazon EC2 Auto Scaling will first identify which of the two types (Spot or On-Demand) should be terminated. This can temporarily cause a misbalance between the AZs
-
C
With Default termination policy, instances that are closest to the next billing hour are terminated first. This can temporarily cause instance distribution imbalance among the AZs
-
D
Amazon EC2 Auto Scaling can temporarily exceed the specified maximum capacity of a group by a 10 percent margin (or by a margin of one instance, whichever is greater) during a rebalancing activity
-
E
You can only specify one Lambda function in the termination policies for an Auto Scaling group. If more than one Lambda functions are configured, the ASG behavior is ambiguous
Xem giải thích
Đáp án
B và D.
- B — Với mixed instances policy, khi scale-in ASG xác định huỷ loại nào (Spot hay On-Demand) trước, việc này có thể tạm làm lệch phân bố giữa các AZ.
- D — ASG được phép tạm vượt maximum capacity thêm 10% (hoặc 1 instance, lấy giá trị lớn hơn) trong lúc rebalancing.
Vì sao đúng
Đề nêu hai hiện tượng nhìn như lỗi, nhưng cả hai đều là hành vi có tài liệu.
(a) Huỷ instance ở AZ đang ít instance hơn. Bình thường ASG ưu tiên cân bằng AZ khi scale-in. Nhưng với mixed instances policy, thứ tự ưu tiên đổi: ASG quyết định loại mua trước (giữ đúng tỷ lệ Spot/On-Demand đã khai), rồi mới chọn instance trong loại đó. Nếu instance Spot cần huỷ tình cờ nằm ở AZ đang mỏng, nó vẫn bị huỷ. Tỷ lệ Spot/On-Demand thắng cân bằng AZ.
(b) Vượt maximum capacity. Khi ASG tự rebalance (ví dụ một AZ phục hồi sau sự cố), nó launch trước, terminate sau để không bao giờ tụt năng lực. Trong khoảnh khắc chồng lấn đó, số instance có thể vượt max tối đa 10% hoặc 1 instance — tuỳ giá trị nào lớn hơn. Rất ngắn, và có ghi rõ trong tài liệu.
Vì sao các phương án khác sai
- A. "Huỷ instance từ launch template cũ nhất trước" — mô tả này đúng với default termination policy, nhưng chỉ được xét sau khi đã chọn AZ, nên nó không giải thích được việc AZ mỏng bị đụng vào. Nó cũng chẳng liên quan gì tới hiện tượng (b).
- C. "Huỷ instance gần giờ tính tiền tiếp theo nhất" — tiêu chí này thuộc default termination policy và đã lỗi thời từ khi EC2 chuyển sang tính tiền theo giây (2017). Nay tiêu chí cuối là instance gần mốc giờ kế tiếp nhất chỉ còn ý nghĩa lịch sử.
- E. "Chỉ khai được một Lambda trong termination policy" — bịa hoàn toàn. Termination policy nhận danh sách các tiêu chí dựng sẵn (
OldestInstance,NewestInstance,OldestLaunchTemplate,ClosestToNextInstanceHour,AllocationStrategy,Default) và có thể trỏ tới custom termination policy bằng Lambda — vẫn là một hàm, nhưng không có "hành vi mơ hồ" nào như phương án mô tả.
Ghi nhớ
Hai hành vi "trông như bug" của ASG cần thuộc: tạm vượt max 10% khi rebalancing, và mixed instances policy ưu tiên tỷ lệ mua hơn cân bằng AZ. Cả hai đều là thiết kế, không phải sự cố.
A company has configured AWS Organizations to manage its multiple AWS accounts. The company uses Amazon Elastic File System (Amazon EFS) as a shared storage service, configured in AWS Account A of the company. To implement a serverless architecture, the company has decided to move its applications to AWS Lambda. The Lambda functions will be managed through another AWS account (Account B). All the Lambda functions will be deployed in a VPC. A DevOps team needs help to continue using Amazon EFS in Account A with the Lambda function in Account B.
How will you reconfigure the existing EFS file system for use with AWS Lambda function? (Select two)
-
A
Create a VPC peering connection to connect Account A to Account B. Create Service control policies (SCPs) to set permission guardrails for access to Amazon EFS from AWS Lambda function execution role
-
B
Create a VPC peering connection to connect Account A to Account B. Update the EFS file system policy to provide Account B with access to mount and write to the EFS file system in Account A
-
C
Update the Lambda execution roles with permission to access the VPC and the EFS file system
-
D
Configure the Lambda functions in Account B to assume an existing IAM role in Account A for the cross-region, or cross-AZ connectivity between EFS and Lambda
-
E
Lambda charges for data transfer between VPCs. To manage costs, create a new EFS file system in Account B. Configure AWS DataSync to transfer data from EFS in Account B to EFS in Account B
Xem giải thích
Đáp án
B và C.
- B — VPC peering giữa Account A và Account B, đồng thời sửa file system policy của EFS để cho Account B mount và ghi.
- C — Cập nhật execution role của Lambda để có quyền truy cập VPC và EFS.
Vì sao đúng
Lambda dùng EFS chéo tài khoản cần đủ ba lớp, và thiếu bất kỳ lớp nào cũng hỏng:
| Lớp | Cần gì |
|---|---|
| Mạng | Lambda nằm trong VPC của B, EFS nằm trong VPC của A ⇒ phải có VPC peering (hoặc Transit Gateway) và security group của mount target cho phép NFS cổng 2049 |
| Quyền phía tài nguyên | EFS file system policy cho phép principal ở Account B thực hiện elasticfilesystem:ClientMount và ClientWrite |
| Quyền phía danh tính | Execution role của Lambda có elasticfilesystem:ClientMount, ClientWrite, cộng với ec2:CreateNetworkInterface, DescribeNetworkInterfaces, DeleteNetworkInterface để cắm ENI vào VPC |
Đây lại là mẫu quen thuộc: truy cập chéo tài khoản luôn cần cả policy phía tài nguyên lẫn policy phía danh tính.
// File system policy trên EFS ở Account A
{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::<AccountB>:role/lambda-exec"},
"Action": ["elasticfilesystem:ClientMount", "elasticfilesystem:ClientWrite"],
"Resource": "arn:aws:elasticfilesystem:ap-southeast-1:<AccountA>:file-system/fs-xxxx"
}
Vì sao các phương án khác sai
- A. SCP đặt guardrail cho việc truy cập EFS — SCP không cấp quyền, chỉ giới hạn quyền tối đa của tài khoản trong Organizations. Dùng SCP để "mở đường" là hiểu ngược cơ chế.
- D. Lambda ở B assume role ở A — nghe hợp lý nhưng không dùng được: Lambda mount EFS bằng giao thức NFS ở tầng mạng, quyền được kiểm bằng file system policy chứ không bằng một phiên STS mà code tự lấy. Câu này còn nói "cross-region, or cross-AZ connectivity", vốn không phải vấn đề đang bàn.
- E. "Lambda tính phí truyền dữ liệu giữa các VPC" nên nhân bản EFS bằng DataSync — vế sau còn viết sai chính nó ("từ EFS ở Account B sang EFS ở Account B"). Về ý tưởng, nhân đôi dữ liệu tạo ra bài toán đồng bộ mới, trái hẳn mục đích dùng shared storage.
Ghi nhớ
Lambda gắn EFS cần: cùng VPC (hoặc có peering) + security group mở cổng 2049 + access point + quyền ở cả hai phía. Lỗi hay gặp nhất là quên security group — triệu chứng là hàm timeout khi mount, không có thông báo quyền nào.
A media application runs on a host of Amazon EC2 instances fronted with an Application Load Balancer (ALB) and Amazon S3 buckets as storage service. For enhanced security, an AWS Web Application Firewall (AWS WAF) has been set up to monitor the requests coming to the ALB. The DevOps team needs to submit a quarterly report on the web requests received by AWS WAF, having detailed information about each web request as well as the details about rules that the request matched. The team has reached out to you for implementing the changes needed for collecting the security data for the coming months.
As DevOps Engineer, how will you implement this requirement?
-
A
Create an Amazon S3 bucket. Enable logging and provide an Amazon S3 bucket ARN as a WAF logging destination. Bucket names for AWS WAF logging must start with
aws-waf-logs-and can end with any suffix you want -
B
Create an Amazon S3 bucket. Enable logging and provide an Amazon S3 bucket ARN as a WAF logging destination. Bucket names for AWS WAF logging must start with
aws-waf-logs-and can end with any suffix you want. For added security, you can add log encryption configuration by providing AWS Key Management Service keys that are managed by AWS -
C
To send logs to Amazon CloudWatch Logs, create a CloudWatch Logs log group. When you enable logging in AWS WAF, provide the log group ARN as the WAF logging destination. Log group names must start with
aws-waf-logs-and end with any suffix. Define CloudWatch Metrics for the logs collected and trigger CloudWatch alarm(s) based on the logs generated -
D
Enable logging on AWS WAF and configure Amazon Kinesis Data Firehose with a configured storage destination as WAF logging destination. Configure Firehose to use a Kinesis stream as its source. Data firehose name should start with the prefix
aws-waf-logs-
Xem giải thích
Đáp án
A — Tạo bucket S3, bật logging và khai ARN bucket làm đích ghi log của WAF; tên bucket bắt buộc bắt đầu bằng aws-waf-logs-.
Vì sao đúng
AWS WAF ghi được full log của từng web request: header, thời điểm, IP nguồn, và quan trọng nhất là rule nào đã khớp (terminatingRuleId, ruleGroupList, nonTerminatingMatchingRules). Đó đúng là thứ báo cáo quý cần.
WAF hỗ trợ ba đích ghi log, và cả ba đều chịu chung một quy tắc đặt tên:
| Đích | Ràng buộc tên |
|---|---|
| S3 bucket | phải bắt đầu bằng aws-waf-logs- |
| CloudWatch Logs log group | phải bắt đầu bằng aws-waf-logs- |
| Kinesis Data Firehose | phải bắt đầu bằng aws-waf-logs- |
Với báo cáo hàng quý — dữ liệu lớn, truy vấn thưa — thì S3 là lựa chọn rẻ nhất, và có thể truy vấn thẳng bằng Athena.
Tiền tố aws-waf-logs- không phải quy ước cho đẹp: đó là ràng buộc bắt buộc, WAF từ chối cấu hình nếu tên không khớp.
Vì sao các phương án khác sai
- B. Nửa đầu giống hệt A và cũng đúng, nhưng phần bổ sung phía sau làm câu trả lời sai lệch. Đây là kiểu bẫy "hai phương án na ná, khác nhau ở vế cuối" — phải đọc hết câu.
- C. CloudWatch Logs — về kỹ thuật hợp lệ, nhưng cho báo cáo quý thì CloudWatch Logs đắt hơn hẳn S3 ở cả khâu nạp lẫn khâu lưu. CloudWatch Logs hợp với cảnh báo gần thời gian thực, không hợp với kho dữ liệu để tổng hợp định kỳ.
- D. "Firehose lấy nguồn từ một Kinesis stream" — sai chiều. Khi ghi log WAF qua Firehose, chính WAF là nguồn đẩy vào delivery stream; Firehose không đi lấy từ một Kinesis Data Stream nào cả. Ngoài ra câu này đặt ràng buộc tên vào sai chỗ.
Ghi nhớ
Cụm aws-waf-logs- là chi tiết hay được hỏi thẳng trong đề. Và nhớ thêm: WAF logging có redaction — che được các trường nhạy cảm (authorization, cookie) trước khi ghi ra log.
An e-commerce company is deploying its flagship application on Amazon EC2 instances. The DevOps team at the company needs a solution to query both the application logs as well as the AWS account API activity.
As an AWS Certified DevOps Engineer - Professional, what solution will you recommend to meet these requirements?
-
A
Set up AWS CloudTrail to deliver the API logs to Amazon S3. Leverage the Amazon CloudWatch Agent to deliver logs from the EC2 instances to Amazon CloudWatch Logs. Utilize Amazon Athena to query both sets of logs
-
B
Set up AWS CloudTrail to deliver the API logs to CloudWatch Logs. Leverage the Amazon CloudWatch Agent to deliver logs from the EC2 instances to Amazon CloudWatch Logs. Utilize the CloudWatch Logs Insights to query both sets of logs
-
C
Set up AWS CloudTrail to deliver the API logs to Amazon S3. Leverage the Amazon CloudWatch Agent to deliver logs from the EC2 instances to Amazon S3. Utilize Amazon Athena to query both sets of logs
-
D
Set up AWS CloudTrail to deliver the API logs to Kinesis Data Streams. Leverage the Amazon CloudWatch Agent to deliver logs from the EC2 instances to Kinesis Data Streams. Direct both the Kinesis Data Streams to direct the stream output to Kinesis Data Analytics for running near-real-time queries on both sets of logs
Xem giải thích
Đáp án
B — CloudTrail đẩy log API vào CloudWatch Logs, CloudWatch Agent đẩy log ứng dụng vào CloudWatch Logs, rồi truy vấn cả hai bằng CloudWatch Logs Insights.
Vì sao đúng
Yêu cầu là truy vấn cả hai loại log. Nguyên tắc: muốn truy vấn chung thì đưa về cùng một nơi.
CloudTrail có hai đích: S3 (mặc định) và CloudWatch Logs (bật thêm được). CloudWatch Agent thì đẩy thẳng vào CloudWatch Logs. Cho cả hai vào CloudWatch Logs thì Logs Insights truy vấn được cả hai bằng cùng một ngôn ngữ, và truy vấn nhiều log group cùng lúc:
fields @timestamp, @message
| filter @message like /ConsoleLogin/ or @message like /ERROR/
| sort @timestamp desc
| limit 50
Ưu điểm thực tế: kết quả có gần như tức thì (log tới nơi là truy vấn được), không cần định nghĩa schema, không cần crawler.
Vì sao các phương án khác sai
- A. CloudTrail → S3, app log → CloudWatch Logs, rồi Athena truy vấn cả hai — Athena không đọc được CloudWatch Logs. Muốn dùng Athena thì phải export log ra S3 trước, mà export là thao tác thủ công hoặc phải tự dựng đường ống. Phương án này không chạy được như mô tả.
- C. Cả hai vào S3, dùng Athena — cái này chạy được và là lựa chọn tốt cho phân tích lịch sử dài hạn. Nhưng CloudWatch Agent không ghi thẳng vào S3; phải qua Firehose hoặc script tự viết, tức là mô tả trong phương án đã đơn giản hoá quá mức. Với nhu cầu "truy vấn log vận hành", Logs Insights cũng cho kết quả tức thì hơn.
- D. Cả hai vào Kinesis Data Streams — Kinesis là đường vận chuyển, không phải nơi truy vấn. Vẫn phải đổ vào một đích rồi mới truy vấn được; thêm một tầng mà không giải quyết gì.
Ghi nhớ về chất lượng câu hỏi
A và C đều đề xuất Athena, nhưng chỉ C là khả thi — điểm phân biệt thật nằm ở việc Athena không đọc trực tiếp CloudWatch Logs. Nếu đề hỏi "phân tích lịch sử nhiều năm, rẻ nhất" thì C mới là đáp án; ở đây đề hỏi giải pháp truy vấn vận hành nên B đúng. Đọc kỹ tiêu chí ngầm định là điều quyết định.