Ngân hàng đề — AWS Certified DevOps Engineer Professional
Tìm thấy 681 câu.
The development team at a social media company is using AWS CodeCommit to store code. As a Lead DevOps Engineer at the company, you have defined a company-wide rule so that the team should not be able to push to the master branch. You have added all the developers in an IAM group developers and attached the AWS managed IAM policy arn:aws:iam::aws:policy/AWSCodeCommitPowerUser to the group. This policy provides full access to AWS CodeCommit repositories but does not allow repository deletion, however, your developers can still push to the master branch.
How should you prevent the developers from pushing to the master branch?
-
A
Include a CodeCommit repository policy on each repository with an explicit Deny for
codecommit:GitPush -
B
Include a git commit pre-hook that invokes a Lambda function and checks if the push is done to master
-
C
Add a new IAM policy attached to the group to Deny
codecommit:GitPushwith a condition on the master branch -
D
Modify the AWS managed IAM policy attached to the group to Deny
codecommit:GitPushwith a condition on the master branch
Xem giải thích
Đáp án
C — Thêm một IAM policy mới gắn vào nhóm, với Deny cho codecommit:GitPush kèm điều kiện trên nhánh master
Vì sao đúng
Câu này kiểm tra hai điều, và cả hai đều quan trọng.
Thứ nhất — vì sao cần policy mới. Chính sách AWSCodeCommitPowerUser cho phép GitPush trên mọi nhánh. Trong IAM, Deny tường minh luôn thắng mọi Allow, nên chỉ cần thêm một chính sách từ chối là đủ — không cần đụng tới chính sách gốc.
Điều kiện dùng khoá codecommit:References:
{
"Effect": "Deny",
"Action": ["codecommit:GitPush"],
"Resource": "*",
"Condition": {
"StringEqualsIfExists": { "codecommit:References": ["refs/heads/master"] },
"Null": { "codecommit:References": "false" }
}
}
Thứ hai — vì sao không sửa chính sách quản lý. Đó là nội dung của phương án D, và nó dẫn tới lỗi tiếp theo.
Vì sao các phương án khác sai
- D. Sửa chính sách AWS managed đang gắn vào nhóm — không làm được: chính sách do AWS quản lý (
arn:aws:iam::aws:policy/...) là chỉ đọc. Muốn tuỳ chỉnh thì phải sao chép thành customer managed policy. Đây là phương án nhiễu chính. - A. Dùng "CodeCommit repository policy" — CodeCommit không có repository policy; kiểm soát truy cập làm hoàn toàn qua IAM.
- B. Dùng git pre-hook gọi Lambda — pre-hook chạy trên máy của lập trình viên, nên ai cũng gỡ được. Đó là biện pháp nhắc nhở, không phải biện pháp thực thi.
As a DevOps Engineer at an IT company, you have deployed a web application with a health check that currently checks if the application is running actively. The application is running in an ASG and the ALB health check integration is turned on. Recently your application has had issues with connecting to a backend database and as such the users of your website were experiencing issues accessing your website through the faulty instances.
How can you improve the user experience with the least effort?
-
A
Migrate the application to Elastic Beanstalk and enable advanced health monitoring
-
B
Enhance the Health Check to report a JSON document that contains the health status of the connectivity to the database. Tune the ALB health check to look for a specific string in the health check result using a RegEx
-
C
Include the health check in a Route 53 record so that users going through the ALB are not routed to the unhealthy instances
-
D
Enhance the health check so that the return status code corresponds to the connectivity to the database
Xem giải thích
Đáp án
*D — Sửa health check để mã trạng thái HTTP phản ánh khả năng kết nối tới cơ sở dữ liệu
Vì sao đúng
Vấn đề gốc rất rõ: health check hiện chỉ kiểm tra ứng dụng có chạy không, nên instance mất kết nối cơ sở dữ liệu vẫn báo khoẻ — và ALB vẫn gửi người dùng vào đó.
Cách sửa đúng là làm cho health check phản ánh khả năng phục vụ thật:
Kết nối được cơ sở dữ liệu → trả HTTP 200
Không kết nối được → trả HTTP 503
Khi đó ALB tự đánh dấu instance là unhealthy và ngừng gửi lưu lượng vào nó. Vì tích hợp ALB health check với ASG đã bật, Auto Scaling cũng thay thế instance đó.
Đây cũng là cách ít công nhất: sửa một endpoint trong mã ứng dụng.
Vì sao các phương án khác sai
- B. Trả về tài liệu JSON chứa trạng thái kết nối, rồi cấu hình ALB dùng RegEx tìm chuỗi trong kết quả — ALB không hỗ trợ khớp nội dung theo biểu thức chính quy; nó chỉ so mã trạng thái HTTP với dải bạn khai (
Matcher). Đây là phương án nhiễu chính vì nghe rất tinh vi. - C. Đưa health check vào bản ghi Route 53 — Route 53 health check hoạt động ở tầng DNS; người dùng đã kết nối qua ALB thì Route 53 không can thiệp được nữa.
- A. Chuyển sang Elastic Beanstalk với enhanced health monitoring — di trú cả nền tảng cho một vấn đề sửa được bằng vài dòng mã.
As part of the CICD pipeline, a DevOps Engineer is performing a functional test using a CloudFormation template that will later get deployed to production. That CloudFormation template creates an S3 bucket and a Lambda function which transforms images uploaded into S3 into thumbnails. To test the Lambda function, a few images are automatically uploaded and the thumbnail output is expected from the Lambda function on the S3 bucket. As part of the clean-up of these functional tests, the CloudFormation stack is deleted, but right now the delete fails.
What's the reason and how could this issue be fixed?
-
A
The Lambda function is still using the S3 bucket and CloudFormation cannot, therefore, delete the S3 bucket. Place a
WaitConditionon the Lambda function to fix the issue -
B
The S3 bucket contains files and therefore cannot be deleted by CloudFormation. Add the property
Delete: Forceto your CloudFormation template so that the S3 bucket is emptied before being deleted -
C
A StackPolicy prevents the CloudFormation template to be deleted. Clear the Stack Policy and try again
-
D
The S3 bucket contains files and therefore cannot be deleted by CloudFormation. Create an additional Custom Resource backed by a Lambda function that performs a clean-up of the bucket
Xem giải thích
Đáp án
D — Bucket S3 còn tệp bên trong nên CloudFormation không xoá được; tạo thêm một Custom Resource dùng Lambda để dọn sạch bucket trước
Vì sao đúng
Đây là hành vi cố định của CloudFormation: nó chỉ xoá được bucket S3 rỗng. Bucket còn đối tượng thì thao tác DeleteBucket thất bại và cả stack kẹt ở DELETE_FAILED.
Trong tình huống của đề, chính bài kiểm thử đã sinh ra tệp: ảnh được tải lên, rồi hàm Lambda ghi thumbnail vào bucket. Nên lúc xoá stack, bucket chắc chắn không rỗng.
Giải pháp chuẩn là Custom Resource — một tài nguyên do bạn định nghĩa, gắn với hàm Lambda:
Xoá stack
▼
CloudFormation gọi Custom Resource với RequestType = "Delete"
▼
Lambda liệt kê và xoá mọi đối tượng trong bucket (kể cả các phiên bản nếu bật versioning)
▼
CloudFormation xoá bucket rỗng thành công
Vì sao các phương án khác sai
- B. Thêm thuộc tính
Delete: Forcevào template — không tồn tại thuộc tính này. Đây là phương án nhiễu chính vì nó nghe rất hợp lý — nhưng CloudFormation không có cơ chế xoá cưỡng bức cho S3. - A. Đặt
WaitConditionlên hàm Lambda —WaitConditiondùng để chờ tín hiệu trong lúc tạo stack; nó không giải quyết việc bucket không rỗng. - C. Stack Policy đang chặn việc xoá — Stack Policy bảo vệ tài nguyên khỏi bị cập nhật, không chặn việc xoá stack.
A cyber-security company has had a dubious distinction of their own AWS account credentials being put in public GitHub repositories. The company wants to implement a workflow to be alerted in case credentials are leaked, generate a report of API calls made recently using the credentials, and de-activate the credentials. All executions of the workflow must be auditable.
The company has hired you as an AWS Certified DevOps Engineer Professional to build a robust solution for this requirement. Which of the following solutions would you implement?
-
A
Create a CloudWatch Event checking for AWS_RISK_CREDENTIALS_EXPOSED in the Health Service. Trigger a Lambda Function that will issue API calls to IAM, CloudTrail, and SNS to achieve the desired requirements
-
B
Create a CloudWatch Event checking for AWS_RISK_CREDENTIALS_EXPOSED in the CloudTrail Service. Trigger a Lambda Function workflow that will issue API calls to IAM, CloudTrail, and SNS to achieve the desired requirements
-
C
Create a CloudWatch Event checking for AWS_RISK_CREDENTIALS_EXPOSED in the Health Service. Trigger a Step Function workflow that will issue API calls to IAM, CloudTrail, and SNS to achieve the desired requirements
-
D
Create a CloudWatch Event checking for AWS_RISK_CREDENTIALS_EXPOSED in the CloudTrail Service. Trigger a Step Function workflow that will issue API calls to IAM, CloudTrail, and SNS to achieve the desired requirements
Xem giải thích
Đáp án
C — CloudWatch Event bắt sự kiện AWS_RISK_CREDENTIALS_EXPOSED từ AWS Health, kích hoạt một Step Functions workflow gọi API tới IAM, CloudTrail và SNS
Vì sao đúng
Câu này có hai quyết định, và cả hai đều phải đúng.
Thứ nhất — nguồn sự kiện là AWS Health, không phải CloudTrail. AWS quét các kho công khai như GitHub để tìm khoá truy cập bị lộ, và khi phát hiện, nó phát sự kiện AWS_RISK_CREDENTIALS_EXPOSED qua AWS Health. CloudTrail chỉ ghi lời gọi API trong tài khoản bạn — nó không biết gì về GitHub.
Thứ hai — dùng Step Functions, không dùng một Lambda. Đề đòi "mọi lần thực thi phải kiểm toán được", và Step Functions lưu lịch sử từng bước của mỗi lần chạy, kèm đầu vào và đầu ra. Với một hàm Lambda đơn lẻ, bạn chỉ có log — phải tự xây phần truy vết.
Step Functions cũng lo sẵn phần thử lại và rẽ nhánh cho quy trình ba bước: vô hiệu khoá, xuất báo cáo lời gọi API gần đây, gửi cảnh báo.
Vì sao các phương án khác sai
- A. Đúng nguồn AWS Health nhưng dùng một Lambda — thiếu phần kiểm toán từng bước. Đây là phương án nhiễu chính.
- B và *D. Bắt sự kiện từ CloudTrail Service — sai nguồn; sự kiện này không đến từ CloudTrail.
A financial planning company runs a tax optimization application that allows people to enter their personal financial information and get recommendations. The company is committed to the maximum security for the Personally identifiable information (PII) data in S3 buckets, and as part of compliance requirements, it needs to implement a solution to be alerted in case of new PII and its access in S3.
As an AWS Certified DevOps Engineer, which solution would you recommend such that it needs MINIMUM development effort?
-
A
Enable Amazon Macie on the selected S3 buckets. Setup alerting using CloudWatch Events
-
B
Set up an S3 bucket policy that filters requests containing PII data using a conditional statement
-
C
Enable Amazon GuardDuty on the select S3 buckets. Setup alerting using CloudWatch Alarms
-
D
Create an Amazon Lambda function that is integrated with Amazon Sagemaker to detect PII data. Integrate the Lambda function with S3 events for PUT requests
Xem giải thích
Đáp án
*A — Bật Amazon Macie trên các bucket S3 đã chọn, và đặt cảnh báo qua CloudWatch Events
Vì sao đúng
Chữ khoá của đề là "ít công phát triển nhất", và Macie là dịch vụ được quản lý hoàn toàn cho đúng việc này.
Macie dùng học máy và so khớp mẫu để tự nhận ra dữ liệu nhạy cảm trong S3 — số bảo hiểm xã hội, số thẻ tín dụng, tên, địa chỉ, thông tin tài chính. Bạn không phải viết luật nhận dạng nào.
Nó cũng phủ cả hai yêu cầu của đề:
- Phát hiện PII mới — quét theo lịch, tự đưa đối tượng mới vào diện quét.
- Theo dõi việc truy cập PII — Macie đánh giá liên tục tư thế bảo mật của bucket: cái nào đang công khai, chưa mã hoá, hay chia sẻ ra ngoài tổ chức.
Phát hiện được đẩy qua EventBridge, nên nối với SNS là có cảnh báo tức thì.
Vì sao các phương án khác sai
- D. Viết Lambda tích hợp SageMaker để phát hiện PII — tự xây lại thứ Macie đã làm sẵn: phải huấn luyện mô hình, bảo trì, và tự đánh giá độ chính xác. Ngược hẳn tiêu chí "ít công nhất". Đây là phương án nhiễu chính.
- C. Bật GuardDuty trên bucket S3 — GuardDuty phát hiện hành vi đe doạ (truy cập bất thường, từ IP đáng ngờ); nó không phân loại nội dung dữ liệu.
- B. Dùng bucket policy lọc yêu cầu chứa PII bằng câu điều kiện — bucket policy đánh giá thuộc tính của yêu cầu (ai gửi, từ đâu), nó không đọc nội dung đối tượng.
An e-commerce company has deployed a Spring application on Elastic Beanstalk running the Java platform. As a DevOps Engineer at the company, you are referencing an RDS PostgreSQL database through an environment variable so that your application can use it for storing its data. You are using a library to perform a database migration in case the schema changes. Upon deploying updates to Beanstalk, you have seen the migration fail because all the EC2 instances running the new version try to run the migration on the RDS database.
How can you fix this issue?
-
A
Create an
.ebextensions/db-migration.configfile in your code repository and set acommandsblock. Set your migration command there and use thelock_mode: trueattribute -
B
Create an
.ebextensions/db-migration.configfile in your code repository and set acontainer_commandsblock. Set your migration command there and use thelock_mode: trueattribute -
C
Create an
.ebextensions/db-migration.configfile in your code repository and set acommandsblock. Set your migration command there and use theleader_only: trueattribute -
D
Create an
.ebextensions/db-migration.configfile in your code repository and set acontainer_commandsblock. Set your migration command there and use theleader_only: trueattribute
Xem giải thích
Đáp án
*D — Tạo tệp .ebextensions/db-migration.config, khai khối container_commands và đặt thuộc tính leader_only: true
Vì sao đúng
Vấn đề trong đề rất cụ thể: mọi instance đều chạy migration cùng lúc, và chúng giẫm chân nhau trên cùng một cơ sở dữ liệu.
Hai lựa chọn trong phương án này giải đúng hai mặt:
leader_only: true — Elastic Beanstalk chọn một instance duy nhất làm "leader" và chỉ chạy lệnh đó ở đấy. Đây là thuộc tính dựng riêng cho những việc chỉ được làm một lần: migration cơ sở dữ liệu, khởi tạo dữ liệu mẫu, đăng ký webhook.
container_commands thay vì commands — khác biệt nằm ở thời điểm:
commands |
container_commands |
|
|---|---|---|
| Chạy khi | Trước khi ứng dụng và web server được cài đặt | Sau khi đã cài, trước khi triển khai |
Có leader_only |
Không hỗ trợ | Có |
| Hợp với | Cài gói hệ thống | Migration cơ sở dữ liệu, biên dịch tài nguyên |
Dòng cuối là chỗ quyết định: leader_only chỉ dùng được trong container_commands.
Vì sao các phương án khác sai
- C. Dùng
commandskèmleader_only—commandskhông hỗ trợleader_only, nên mọi instance vẫn chạy migration. Đây là phương án nhiễu chính. - A và *B. Dùng thuộc tính
lock_mode: true— không tồn tại thuộc tính này trong.ebextensions.
A multi-national retail company is operating a multi-account strategy using AWS Organizations. Each account produces logs to CloudWatch Logs and the company would like to aggregate these logs under a single centralized account for archiving purposes. It needs the solution to be secure and centralized. The target destination for the logs should have little to no provisioning on the storage side.
As a DevOps Engineer, how would you implement a solution to meet these requirements?
-
A
Create a log destination in the centralized account, and create a log subscription on that destination. Create a Kinesis Streams and subscribe it to the destination. Create a Kinesis Firehose delivery stream and subscribe it to the Kinesis Stream. The target of the Kinesis Firehose should be Amazon Redshift
-
B
Create a log destination in the centralized account, and create a log subscription on that destination. Create a Lambda function on that log subscription, and implement a script to send the data to Amazon ES
-
C
Create a log destination in the centralized account, and create a log subscription on that destination. Create a Kinesis Firehose delivery stream and subscribe it to the log destination. The target of Kinesis Firehose should be Amazon S3
-
D
Create a log destination in the centralized account, and create a log subscription on that destination. Create a Kinesis Streams and subscribe it to the destination. Create a Kinesis Firehose delivery stream and subscribe it to the Kinesis Stream. The target of the Kinesis Firehose should be Amazon ES
Xem giải thích
Đáp án
*C — Tạo log destination ở tài khoản trung tâm kèm log subscription, tạo Kinesis Data Firehose đăng ký vào destination đó, và đặt đích của Firehose là Amazon S3
Vì sao đúng
Đề nêu ba yêu cầu, và kiến trúc này thoả cả ba:
Tài khoản 1..N (CloudWatch Logs)
▼ subscription filter
Log destination (tài khoản trung tâm)
▼
Kinesis Data Firehose
▼
Amazon S3 ← lưu trữ, "gần như không phải cấp phát gì"
| Yêu cầu | Cách đáp ứng |
|---|---|
| Tập trung | Log destination ở tài khoản trung tâm nhận log từ mọi tài khoản |
| An toàn | Destination policy kiểm soát tài khoản nào được gửi vào |
| Đích lưu trữ gần như không phải cấp phát | S3 — dung lượng vô hạn, không có gì để khai |
Điểm mấu chốt: Firehose đăng ký trực tiếp vào log destination được — không cần Kinesis Data Streams ở giữa. Đây là chỗ phân biệt với hai phương án nhiễu.
Vì sao các phương án khác sai
- A và D. Chèn thêm Kinesis Data Streams giữa destination và Firehose — thừa một mắt xích, và Data Streams đòi khai số shard — vi phạm yêu cầu "gần như không phải cấp phát gì ở phía lưu trữ". Đây là hai phương án nhiễu chính.
- B. Dùng Lambda gửi dữ liệu sang Amazon ES — OpenSearch đòi cấp phát cụm (số node, loại node, dung lượng), và mục đích ở đây là lưu trữ lâu dài, không phải tìm kiếm.
A Big Data analytics company has deployed a stream processing application using KCL to read records from Kinesis Data Streams configured with multiple shards. The application is running on one EC2 instance. It seems that the consuming application is lagging under a large load and therefore records are not processed in time and eventually dropped from the stream.
As a DevOps Engineer, you have been tasked with improving the reliability of this application with minimal changes, what should you do? (Select two)
-
A
Decrease the numbers of shards in Kinesis to decrease the load
-
B
Migrate the application to AWS Lambda
-
C
Increase the stream data retention period
-
D
Run the application in an Auto Scaling Group and scale based on the CloudWatch Metric
MillisBehindLatest -
E
Increase the number of shards in Kinesis to increase throughput
Xem giải thích
Đáp án
C và D — tăng thời gian lưu giữ dữ liệu của luồng, và chạy ứng dụng trong Auto Scaling group co giãn theo chỉ số MillisBehindLatest
Vì sao đúng
Vấn đề trong đề gồm hai phần, và mỗi phương án đúng chữa một phần:
-
D. Chạy trong ASG co giãn theo
MillisBehindLatest— đây là nguyên nhân gốc: ứng dụng chỉ chạy trên một instance trong khi luồng có nhiều shard, nên nó không theo kịp.MillisBehindLatestđo độ trễ của consumer so với đầu luồng — chính là chỉ số đúng để quyết định thêm hay bớt worker. KCL tự cân bằng lease khi có worker mới tham gia. -
C. Tăng thời gian lưu giữ — đây là biện pháp cầm máu: mặc định Kinesis giữ dữ liệu 24 giờ, và bản ghi bị rơi khỏi luồng khi hết hạn — đúng triệu chứng đề mô tả. Tăng lên tới 365 ngày cho consumer thêm thời gian bắt kịp mà không mất dữ liệu.
Vì sao các phương án khác sai
- E. Tăng số shard để tăng thông lượng — thông lượng đầu vào không phải nút thắt; nút thắt là phía tiêu thụ. Thêm shard mà vẫn chỉ một worker thì worker đó còn phải xử lý nhiều shard hơn — tệ hơn. Đây là phương án nhiễu chính.
- A. Giảm số shard — càng làm giảm thông lượng, không giải quyết gì.
- B. Chuyển ứng dụng sang Lambda — giải được bài toán co giãn (Lambda tự chạy song song theo số shard), nhưng đó là viết lại ứng dụng; đề yêu cầu thay đổi tối thiểu.
A retail company is storing the users' information along with their purchase history in a DynamoDB table and it has also enabled the DynamoDB Streams. Three use cases are implemented for this table: a Lambda function reads the stream to send emails for new users subscriptions, another Lambda function which sends an email after a user has done their first purchase and finally the last Lambda function which awards discounts to users every 10 purchase. When there is a high volume of data on your DynamoDB table, the Lambda functions are experiencing a throttling issue. As you plan on adding future Lambda functions to read from that stream, you need to update the existing solution.
As a DevOps Engineer, which of the following options would you recommend?
-
A
Create a DynamoDB DAX cluster to cache the reads
-
B
Create a new Lambda function that will read from the stream and pass on the payload to SNS. Have the other three and upcoming Lambda functions directly read from the SNS topic
-
C
Increase the memory on the Lambda function so that they have an increased vCPU allocation and process the data faster while making fewer requests to DynamoDB
-
D
Increase the RCUs on your DynamoDB table to avoid throttling issues
Xem giải thích
Đáp án
*B — Tạo một Lambda function đọc stream rồi đẩy dữ liệu sang SNS; ba hàm hiện có và các hàm sau này đăng ký trực tiếp vào SNS topic
Vì sao đúng
Vấn đề gốc là giới hạn số consumer của DynamoDB Streams: mỗi shard chỉ nên có tối đa hai bên đọc đồng thời. Ba hàm Lambda cùng đọc một stream đã vượt ngưỡng đó, nên chúng bị throttle — và đề còn nói sẽ thêm hàm nữa trong tương lai.
Mô hình fan-out qua SNS giải đúng chỗ đó:
DynamoDB Stream → MỘT Lambda (consumer duy nhất) → SNS topic
├→ Lambda: email đăng ký mới
├→ Lambda: email mua hàng đầu tiên
├→ Lambda: ưu đãi mỗi 10 lần mua
└→ ... thêm bao nhiêu cũng được
Chỉ còn một bên đọc stream, nên hết throttle. Và SNS hỗ trợ hàng nghìn subscriber, nên việc mở rộng về sau không đụng lại giới hạn nào.
Vì sao các phương án khác sai
- D. Tăng RCU của bảng DynamoDB — throttle ở đây xảy ra ở stream, không phải ở bảng; RCU không áp cho việc đọc stream. Đây là phương án nhiễu chính.
- C. Tăng bộ nhớ cho Lambda để xử lý nhanh hơn — làm mỗi hàm nhanh hơn một chút, nhưng vẫn có ba bên đọc cùng một stream; giới hạn không đổi.
- A. Tạo cụm DAX để cache đọc — DAX cache việc đọc bảng, hoàn toàn không liên quan tới stream.
An industrial appliances company would like to take advantage of AWS Systems Manager to manage their on-premise instances and their EC2 instances. This will allow them to run some SSM RunCommand across their hybrid fleet. The company would also like to effectively manage the size of the fleet. The company has hired you as an AWS Certified DevOps Engineer Professional to build a solution to address this requirement.
How would you set up the on-premise server to achieve this objective?
-
A
Create an IAM User for each on-premise server to be able to call the
AssumeRoleoperation on the SSM service. Using the Access Key ID and the Secret Access Key ID, use the AWS CLI to register your on-premise servers. They will appear with the prefix 'mi-' in your SSM console -
B
Create an IAM Service Role for instances to be able to call the
AssumeRoleoperation on the SSM service. Generate an activation code and activation ID for your on-premise servers. Use these credentials to register your on-premise servers. They will appear with the prefix 'mi-' in your SSM console -
C
Create an IAM User for all on-premise servers to be able to call the
AssumeRoleoperation on the SSM service. Using the Access Key ID and the Secret Access Key ID, use the AWS CLI to register your on-premise servers. They will appear with the prefix 'i-' in your SSM console -
D
Create an IAM Service Role for each instance to be able to call the
AssumeRoleoperation on the SSM service. Generate a unique activation code and activation ID for each on-premise servers. Use these credentials to register your on-premise servers. They will appear with the prefix 'i-' in your SSM console
Xem giải thích
Đáp án
B — Tạo một IAM Service Role cho instance để gọi AssumeRole tới SSM, sinh activation code và activation ID, rồi dùng chúng để đăng ký các máy chủ tại chỗ
Vì sao đúng
Đây là quy trình hybrid activation của Systems Manager, và nó tránh được vấn đề lớn nhất của việc quản lý máy ngoài AWS: không phải rải khoá truy cập cố định lên từng máy.
Quy trình:
1. Tạo MỘT service role cho SSM (dùng chung cho cả đội máy)
2. Sinh một activation: nhận về activation code + activation ID
3. Chạy lệnh cài agent kèm hai giá trị đó trên từng máy chủ tại chỗ
4. Máy xuất hiện trong SSM với ID dạng mi-xxxxxxxx
Hai chi tiết đáng chú ý:
- Một role dùng chung — không cần role riêng cho từng máy; role chỉ mô tả quyền mà agent được dùng.
- Activation có hạn mức và hạn dùng — bạn khai trước bao nhiêu máy được đăng ký bằng activation đó, và ngày hết hạn. Đó chính là phần "quản lý quy mô đội máy" mà đề nhắc tới.
Vì sao các phương án khác sai
- *D. Tạo service role cho từng instance và activation riêng cho từng máy — làm được nhưng tốn công vô ích: role và activation vốn dùng chung được. Đây là phương án nhiễu chính.
- A và C. Tạo IAM user và dùng Access Key để đăng ký — đây là cách làm cũ và kém an toàn: khoá cố định nằm trên máy chủ tại chỗ, lộ ra là dùng được lâu dài. Hybrid activation sinh ra để thay thế đúng cách này.