Ngân hàng đề — AWS Certified DevOps Engineer Professional

Đáp án

C và D.

• C — Cài CloudWatch Agent trên EC2, tạo alarm dựa trên metric bộ nhớ, gửi thông báo qua SNS.
• D — Cấu hình Auto Scaling group thay thế instance khi chúng trượt health check của load balancer.

Vì sao đúng

Hai vế của một giải pháp: nhìn thấy vấn đề và tự phục hồi.

Vế nhìn thấy (C). Đây là điểm kiến thức cốt lõi: EC2 KHÔNG phát metric bộ nhớ. Hypervisor chỉ thấy CPU, mạng và đĩa từ bên ngoài; mức dùng RAM là thứ chỉ hệ điều hành bên trong biết. Muốn có nó thì bắt buộc phải cài CloudWatch Agent:

{"metrics": {"metrics_collected": {
  "mem": {"measurement": ["mem_used_percent"], "metrics_collection_interval": 60}
}}}

Có metric rồi mới đặt alarm được — và đó là cách duy nhất để theo dõi rò rỉ bộ nhớ theo thời gian, thứ mà đề đang nghi ngờ.

Vế tự phục hồi (D). Đặt health check type của ASG thành ELB thay vì EC2. Khi ấy instance trượt health check của target group sẽ bị ASG huỷ và thay bằng máy mới:

aws autoscaling update-auto-scaling-group --auto-scaling-group-name nhom-app \
  --health-check-type ELB --health-check-grace-period 300

Đây là điểm mấu chốt: với health check type mặc định là EC2, ASG chỉ quan tâm instance có chạy hay không — ứng dụng chết mà máy vẫn bật thì ASG coi là hoàn toàn khoẻ mạnh.

Vì sao các phương án khác sai

• B. "Alarm trên memory utilization" mà không cài agent — bẫy chính. Không có agent thì metric đó không tồn tại, nên alarm sẽ ở trạng thái INSUFFICIENT_DATA vĩnh viễn và không bao giờ kêu. Khác biệt duy nhất giữa B và C chính là câu "Configure the CloudWatch agent".
• A. Đổi health check sang TCP — đi ngược mục đích. TCP check chỉ xác nhận cổng có mở không; tiến trình bị rò rỉ bộ nhớ tới mức không xử lý nổi request vẫn giữ cổng mở, nên nó sẽ báo lành trong khi ứng dụng đã hỏng. Đổi từ HTTP sang TCP là làm health check kém nhạy hơn.
• E. Alarm tự recover instance theo EC2 status check — status check phát hiện hỏng ở tầng hạ tầng hoặc hệ điều hành, không phát hiện ứng dụng hết bộ nhớ. Máy vẫn qua status check bình thường trong khi ứng dụng đã chết.

Ghi nhớ

Ba metric không có sẵn trên EC2 và bắt buộc phải cài CloudWatch Agent: bộ nhớ (mem_used_percent), dung lượng đĩa còn trống (disk_used_percent), và swap. Đây là câu hỏi kinh điển, và biến thể phổ biến nhất là đặt alarm cho một metric chưa từng tồn tại.

Đáp án

C — Auto Scaling với ELB, dùng CodeDeploy với cấu hình CodeDeployDefault.HalfAtATime, bật ELB health check và đặt health check của ASG thành ELB.

Vì sao đúng

Ba yêu cầu khớp từng dòng:

Vế chi phí là điểm phân biệt quan trọng nhất. HalfAtATime là in-place deployment — dùng lại chính các instance đang có, không tốn thêm đồng nào cho hạ tầng. Blue/green thì phải chạy gấp đôi số instance trong suốt quá trình deploy.

Vế tự chữa: đặt --health-check-type ELB khiến ASG lắng nghe kết quả health check của load balancer. Ứng dụng chết mà máy vẫn bật thì ASG vẫn thay — điều mà health check mặc định (EC2) không làm được.

Vì sao các phương án khác sai

• A. Blue/green — thoả yêu cầu "ít nhất một nửa" quá dư (100% bản cũ vẫn chạy), nhưng tốn gấp đôi hạ tầng trong lúc deploy. Đề nói rõ "minimize deployment costs", nên đây là lựa chọn đắt hơn cần thiết.
• B. AWS OpsWorks với rolling deployment — OpsWorks là dịch vụ quản lý cấu hình bằng Chef/Puppet, đã ngừng phát triển, đòi viết và bảo trì recipe. Auto healing của nó cũng dựa trên agent của OpsWorks chứ không dựa trên ELB health check. Phức tạp hơn hẳn mà không được gì thêm.
• D. Elastic Beanstalk rolling với batch 50% — về hành vi thì gần giống C, nhưng nó đòi di trú toàn bộ ứng dụng sang Elastic Beanstalk. Đề mô tả hạ tầng EC2 + ELB tự quản; đổi nền tảng chỉ để đạt một chiến lược deploy là thay đổi quá lớn.

Ghi nhớ

Ba deployment configuration dựng sẵn của CodeDeploy trên EC2: | Cấu hình | Giữ lại bao nhiêu | |---|---| | OneAtATime | n−1 instance — an toàn nhất, chậm nhất | | HalfAtATime | 50% | | AllAtOnce | 0 — nhanh nhất, rủi ro nhất |

Và nhớ: health check type của ASG mặc định là EC2, chỉ kiểm tra máy có chạy không. Muốn ASG biết ứng dụng hỏng thì phải đổi sang ELB — đây là một dòng cấu hình bị bỏ quên rất thường xuyên.

Đáp án

A — Hai môi trường Elastic Beanstalk có auto scaling (test và production), build bằng CodeBuild, dữ liệu ở Amazon RDS, và dùng swap CNAME để đưa bản test lên production.

Vì sao đúng

Bốn yêu cầu, và Beanstalk đáp ứng cả bốn với công sức ít nhất:

Swap CNAME là điểm mạnh nhất: bản mới được kiểm thử trên một môi trường production đầy đủ, chỉ khác URL. Kiểm thử xong thì hai môi trường đổi CNAME cho nhau — tức thì, và rollback là swap ngược lại, cũng tức thì.

RDS đặt riêng (không nằm trong môi trường Beanstalk) là chi tiết đúng và quan trọng: nhờ vậy cả hai môi trường dùng chung một CSDL và swap không làm mất dữ liệu.

Beanstalk cũng có nền tảng PHP dựng sẵn, nên đội chỉ cần đẩy mã lên.

Vì sao các phương án khác sai

• B. OpsWorks với tầng DynamoDB — sai hai chỗ. Ứng dụng được thiết kế cho MySQL; chuyển sang DynamoDB nghĩa là viết lại toàn bộ tầng dữ liệu. Và OpsWorks là dịch vụ đã ngừng phát triển, đòi viết Chef recipe.
• C. CloudFormation + cài MySQL trên từng EC2 instance — lỗi nghiêm trọng: mỗi instance có một CSDL riêng, nên dữ liệu phân mảnh và không nhất quán. Thêm nữa, auto scaling tạo máy mới là tạo thêm một CSDL rỗng. Cập nhật stack cũng không cho deploy không gián đoạn.
• D. Hai ECS service, "upload mã bằng AWS CLI vào task" — mô tả sai cách ECS hoạt động: bạn không upload mã vào task đang chạy; bạn build image, đẩy lên registry, rồi tạo task definition mới. Ngoài ra ECS đòi container hoá ứng dụng PHP — thêm một bước lớn.

Ghi nhớ

Quy tắc vàng của Elastic Beanstalk: CSDL production luôn nằm NGOÀI môi trường. Trong môi trường thì nó bị xoá cùng môi trường, và blue/green sẽ tạo ra hai CSDL riêng biệt — swap CNAME xong người dùng rơi vào một CSDL trống.

Đáp án

D — Cấu hình redrive policy để chuyển message hỏng sang dead-letter queue (DLQ).

Vì sao đúng

Vấn đề: Lambda thỉnh thoảng không xử lý được một số message, và kỹ sư cần phân tích chúng để tìm nguyên nhân.

Nếu không có DLQ thì với SQS standard queue, message xử lý hỏng sẽ quay lại hàng đợi và được thử lại — lặp đi lặp lại cho tới khi hết MessageRetentionPeriod (tối đa 14 ngày) rồi biến mất không dấu vết. Không có gì để đọc, không có gì để phân tích.

Redrive policy đặt một ngưỡng: sau maxReceiveCount lần nhận không thành công, SQS chuyển message sang DLQ:

{
  "RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:...:hang-doi-loi\",
                    \"maxReceiveCount\":\"3\"}"
}

Hai cái lợi cùng lúc:

• Message hỏng được giữ lại nguyên vẹn để đọc và tái hiện lỗi
• Message hỏng không còn chặn hàng đợi, các message khác được xử lý bình thường

Sửa mã xong thì dùng redrive to source để đẩy chúng ngược về hàng đợi chính xử lý lại.

Vì sao các phương án khác sai

• A. Bật long polling (WaitTimeSeconds) — long polling giảm số lời gọi rỗng và giảm chi phí; nó không liên quan gì tới việc message xử lý hỏng.
• B. Chuyển sang FIFO queue — FIFO đảm bảo thứ tự và xử lý đúng một lần. Message vẫn hỏng y như cũ, chỉ là hỏng theo đúng thứ tự — và tệ hơn: trong FIFO, một message hỏng ở đầu chặn cả message group phía sau nó.
• C. Delay queue (DelaySeconds) — chỉ hoãn thời điểm message hiển thị cho consumer. Hoãn xong thì message vẫn hỏng đúng như vậy.

Ghi nhớ

Lỗi hay gặp nhất trong cặp SQS + Lambda: VisibilityTimeout nhỏ hơn timeout của hàm — message được phát lại trong khi hàm vẫn đang chạy, gây xử lý trùng.

Đáp án theo nguồn

C — Dùng AWS OpsWorks để tạo ALB, Auto Scaling group, tài nguyên ứng dụng và CSDL; triển khai cập nhật bằng OpsWorks lifecycle event.

Vì sao nguồn chọn phương án này

Tiêu chí của đề là giảm gánh nặng vận hành nhiều nhất có thể, và logic của khoá đáp án là: dùng một dịch vụ duy nhất cho toàn bộ ngăn xếp thay vì chia đôi giữa hai công cụ.

OpsWorks có mô hình stack → layer → instance, trong đó mỗi layer (ALB, ứng dụng, CSDL) được cấu hình và quản lý trong cùng một nơi. Lifecycle event (setup, configure, deploy, undeploy, shutdown) tự chạy khi có thay đổi — ví dụ thêm một instance ứng dụng thì layer load balancer tự nhận biết và đăng ký nó.

So với các phương án lai (A và D), lập luận là: chia hạ tầng giữa CloudFormation và OpsWorks tạo ra hai nguồn sự thật, hai quy trình cập nhật, và ranh giới không rõ ai sở hữu cái gì.

Vì sao các phương án khác sai theo logic của đề

• A. CloudFormation cho ALB/ASG + OpsWorks cho ứng dụng và CSDL — chia đôi trách nhiệm ở đúng chỗ dễ lệch nhau nhất.
• D. OpsWorks cho ALB/ASG/ứng dụng + CloudFormation cho CSDL — cùng vấn đề, đảo chiều.
• B. Toàn bộ bằng CloudFormation + rolling update — nhất quán về công cụ, nhưng CloudFormation không quản lý việc triển khai mã ứng dụng; bạn vẫn phải tự dựng cơ chế deploy, và AutoScalingRollingUpdate là để thay instance, không phải để phát hành phiên bản ứng dụng mới.

Ghi nhớ về chất lượng câu hỏi

Câu này đã lỗi thời. AWS đã thông báo ngừng dịch vụ AWS OpsWorks — cả OpsWorks Stacks lẫn OpsWorks for Chef/Puppet. Nó không còn là câu trả lời đúng cho bất kỳ thiết kế mới nào, và cũng không còn xuất hiện như đáp án đúng trong các đề thi AWS hiện hành.

Câu trả lời đúng ngày nay cho cùng yêu cầu — ba tầng trên EC2 + RDS, ít gánh nặng vận hành nhất — là AWS Elastic Beanstalk (nền tảng được quản lý, tự lo ALB, Auto Scaling, deploy và rollback), với RDS tạo riêng bên ngoài môi trường. Nếu cần kiểm soát chi tiết hơn thì là CloudFormation cho hạ tầng + CodeDeploy cho triển khai mã.

Hãy nhớ lập luận của câu hỏi (một công cụ tốt hơn hai công cụ chia đôi), đừng nhớ dịch vụ trong đáp án.

Đáp án theo nguồn

B và C — trong đó chỉ C thực sự khớp với thông báo lỗi, xem phần ghi chú cuối bài.

• C — Đảm bảo ECS task trong cụm Fargate có ENI cấu hình đúng và có endpoint api.ecr.

Vì sao C đúng

Đọc kỹ thông báo lỗi:

ResourceInitializationError: unable to pull secrets or registry auth: pull command failed :: signal: killed

Cụm "unable to pull secrets or registry auth" nói rất rõ: task thất bại ngay ở giai đoạn khởi tạo, khi Fargate cố kéo image từ ECR và/hoặc lấy bí mật. Nó chưa từng chạy tới đoạn mã kết nối Redis.

Nguyên nhân gần như luôn là task nằm trong subnet riêng, không có đường ra tới các endpoint cần thiết. Fargate cần bốn VPC endpoint:

Endpoint s3 là thứ bị quên nhiều nhất — thiếu nó thì ECR API trả lời được nhưng tải lớp image thì treo rồi bị kill, đúng chữ signal: killed trong lỗi.

Vì sao các phương án khác sai

• A. Đưa task ra public subnet với IP công khai — có thể làm lỗi biến mất (task đi ra Internet để tới ECR), nhưng đó là hạ thấp bảo mật để vá một vấn đề mạng, và đề không hề nói kiến trúc cho phép điều đó.
• D. Quyền của IAM role — thiếu quyền ECR sẽ cho lỗi AccessDenied rõ ràng, không phải signal: killed. Sai loại lỗi.
• E. Mở security group cho 0.0.0.0/0 — mở toàn bộ Internet vào ứng dụng là lỗ hổng nghiêm trọng, và vẫn không sửa được đường đi ra tới ECR.

Ghi nhớ về chất lượng câu hỏi

Phương án B — mở cổng 6379 cho Redis — bị nguồn đánh dấu là đúng, nhưng nó không giải thích được thông báo lỗi trong đề. ResourceInitializationError xảy ra trước khi container khởi động, nên không có kết nối Redis nào được thử. Nếu vấn đề thật là security group của Redis, lỗi sẽ là timeout kết nối từ trong mã ứng dụng, ghi ở log ứng dụng chứ không phải ở stoppedReason của task.

Nhiều khả năng đề gốc trộn hai tình huống: phần mô tả nói "không kết nối được Redis" (khớp B) còn thông báo lỗi dán vào lại là lỗi kéo image (khớp C). Hãy nhớ C — đó là kiến thức thật và bị hỏi rất nhiều; B chỉ đúng nếu bỏ qua chính thông báo lỗi mà đề đưa ra.

Đáp án

A và C.

• A — Chuyển tầng web sang cụm AWS Fargate, tạo service và gắn Application Load Balancer.
• C — Chuyển MySQL sang Amazon RDS Multi-AZ.

Vì sao đúng

Ba yêu cầu: sẵn sàng cao, chịu lỗi, chi phí thấp nhất.

Vế web (A). Ứng dụng đã được container hoá, nên Fargate là bước đi tự nhiên nhất:

• Không quản máy chủ nào — không vá, không scale cluster, không lo instance hỏng
• Trả tiền theo vCPU và bộ nhớ mà task thực sự dùng, tính theo giây
• ECS service tự trải task trên nhiều AZ và tự thay task chết
• ALB phân phối và loại task không lành

Vế CSDL (C). Multi-AZ là cơ chế sẵn sàng cao chuẩn của RDS: một standby đồng bộ ở AZ khác, failover tự động trong 1–2 phút, hoàn toàn trong suốt với ứng dụng vì endpoint không đổi.

Vì sao các phương án khác sai

• B. RDS với read replica ở AZ khác — đây là bẫy chính, và khác biệt rất quan trọng:

  	Multi-AZ standby	Read replica
  Sao chép	đồng bộ	bất đồng bộ
  Failover	tự động	thủ công (promote)
  Phục vụ đọc	không	có
  Mục đích	sẵn sàng cao	mở rộng đọc

  Read replica là công cụ hiệu năng, không phải công cụ sẵn sàng cao. Promote thủ công còn có thể mất dữ liệu vì sao chép bất đồng bộ.

• D. DynamoDB Global Tables — đòi viết lại toàn bộ tầng dữ liệu từ MySQL quan hệ sang NoSQL. Global Tables cũng là công cụ đa Region, dư thừa hoàn toàn cho yêu cầu chỉ cần đa AZ, và đắt hơn.

• E. ASG của EC2 + ALB cho tầng web — làm được, nhưng ứng dụng đã container hoá rồi mà lại quay về tự quản EC2: phải vá hệ điều hành, phải quản dung lượng cluster, và trả tiền cho instance kể cả lúc rảnh. Trượt tiêu chí "minimize cost" so với Fargate.

Ghi nhớ

Phân biệt dứt khoát: Multi-AZ = sẵn sàng cao (standby đồng bộ, failover tự động, không phục vụ đọc); read replica = mở rộng đọc (bất đồng bộ, promote thủ công). Đây là cặp bị hỏi nhiều nhất trong toàn bộ chủ đề RDS, và câu hỏi luôn xoay quanh việc bạn có phân biệt được hai mục đích hay không.

Đáp án

B — Dùng hook BeforeAllowTraffic trong AppSpec để gọi một hàm kiểm tra xem API đã sẵn sàng nhận request chưa.

Vì sao đúng

CodeDeploy khi triển khai Lambda chỉ có bốn lifecycle event, và chỉ hai trong số đó viết hook được:

Start → BeforeAllowTraffic → AllowTraffic → AfterAllowTraffic → End
         ↑ hook viết được                    ↑ hook viết được

Yêu cầu là API phải sẵn sàng TRƯỚC KHI traffic chuyển sang phiên bản Lambda mới. Vậy chỉ có một chỗ đặt được: BeforeAllowTraffic.

Hàm hook kiểm tra endpoint của API Gateway rồi báo kết quả về CodeDeploy:

def handler(event, context):
    san_sang = kiem_tra_api_gateway()   # gọi thử endpoint, chờ tới khi 200
    codedeploy.put_lifecycle_event_hook_execution_status(
        deploymentId=event['DeploymentId'],
        lifecycleEventHookExecutionId=event['LifecycleEventHookExecutionId'],
        status='Succeeded' if san_sang else 'Failed')

Trả Failed thì CodeDeploy tự dừng và rollback — không client nào chạm vào phiên bản mới.

Vì sao các phương án khác sai

• C. AfterAllowTraffic — quá muộn. Hook này chạy sau khi traffic đã chuyển, nghĩa là request thật đã đi vào bản mới trong lúc API chưa sẵn sàng. Đúng vấn đề cần tránh.
• A. ValidateService — không tồn tại trong deploy Lambda; nó thuộc bộ hook của EC2/On-Premises. Khai vào AppSpec của Lambda thì bị bỏ qua, và bạn có một biện pháp bảo vệ chỉ tồn tại trên giấy.
• D. AfterInstall trong buildspec — hai lỗi trong một câu. AfterInstall cũng là hook của EC2/ECS, không phải của Lambda. Và hook được khai trong AppSpec, không phải trong buildspec — buildspec là tệp cấu hình của CodeBuild, hoàn toàn khác vai trò.

Ghi nhớ

Quy tắc nhớ nhanh: cần chặn traffic vì một phụ thuộc chưa sẵn sàng ⇒ luôn là hook có chữ Before. Và AppSpec ≠ buildspec.

Đáp án

A và E.

• A — EC2 đích không có instance profile cấp quyền cần thiết.
• E — EC2 không tới được Internet hoặc endpoint công khai của CodeDeploy (thiếu NAT gateway hoặc internet gateway).

Vì sao đúng

Trạng thái Skipped cho tất cả sự kiện là dấu hiệu rất đặc trưng: CodeDeploy agent chưa từng nhận được lệnh triển khai. Nếu agent nhận được rồi mới hỏng thì sẽ có sự kiện Failed ở một lifecycle event cụ thể, kèm log.

Nghĩa là vấn đề nằm ở đường liên lạc giữa instance và dịch vụ CodeDeploy, và có đúng hai chỗ hỏng phổ biến:

A — thiếu quyền. CodeDeploy agent dùng instance profile để đăng ký, nhận lệnh và tải bundle từ S3. Không có instance profile (hoặc thiếu quyền S3/CodeDeploy) thì agent không đăng ký được:

{"Effect": "Allow",
 "Action": ["s3:GetObject", "s3:GetObjectVersion", "s3:ListBucket"],
 "Resource": "arn:aws:s3:::kho-artifact/*"}

E — thiếu đường mạng. Agent chủ động gọi ra endpoint công khai của CodeDeploy để hỏi có việc gì không. Instance trong subnet riêng mà không có NAT gateway và không có VPC endpoint cho codedeploy và codedeploy-commands-secure thì nó nằm im mãi.

Vì sao các phương án khác sai

• B. IAM user khởi tạo deployment thiếu quyền — nếu vậy thì lời gọi CreateDeployment bị từ chối ngay, không có deployment ID nào được tạo. Đề nói rõ đã có deployment ID với các sự kiện ở trạng thái Skipped.
• C. "Instance chưa được đăng ký với CodeDeploy endpoint" — nghe hợp lý nhưng không phải bước cấu hình riêng. Với deployment group nhắm vào EC2, instance được chọn theo tag hoặc theo Auto Scaling group; không có thao tác "đăng ký" nào cả. (Việc đăng ký thủ công chỉ áp dụng cho on-premises instance.) Và nếu không instance nào khớp tag thì deployment sẽ thành công với 0 instance, không phải Skipped.
• D. Dùng instance store thay vì EBS — loại lưu trữ hoàn toàn không ảnh hưởng tới CodeDeploy. Agent chạy được trên cả hai như nhau.

Ghi nhớ

Danh sách kiểm khi CodeDeploy không chạm được tới instance:

1. CodeDeploy agent đã cài và đang chạy chưa? (sudo service codedeploy-agent status)
2. Instance profile có đủ quyền CodeDeploy + S3 chưa?
3. Instance ra được mạng chưa? (NAT gateway, IGW, hoặc VPC endpoint codedeploy + codedeploy-commands-secure)
4. Tag có khớp deployment group không?
5. Đồng hồ hệ thống có đúng không? (lệch giờ làm hỏng chữ ký SigV4)

Đáp án

D và E.

• D — Quét toàn bộ tài khoản bằng Tag Editor và gắn tag cho các tài nguyên đang thiếu.
• E — Tạo và gắn SCP bắt buộc phải khai tag khi tạo tài nguyên.

Vì sao đúng

Đề yêu cầu hai việc: khắc phục tình trạng hiện tại và đảm bảo nó không tái diễn. Đó chính là cặp dọn nợ cũ + chặn nợ mới.

D — dọn nợ cũ. Tag Editor (thuộc Resource Groups) tìm được tài nguyên trên nhiều Region và nhiều loại dịch vụ, lọc theo "thiếu tag X", và gắn tag hàng loạt ngay trên giao diện. Đây là công cụ duy nhất trong bốn phương án thực sự sửa được dữ liệu đang có.

E — chặn nợ mới. SCP là kiểm soát ngăn chặn ở tầng tổ chức:

{
  "Effect": "Deny",
  "Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
  "Resource": "*",
  "Condition": {"Null": {"aws:RequestTag/CostCenter": "true"}}
}

Đọc là: từ chối tạo tài nguyên nếu request không kèm tag CostCenter. Áp ở cấp OU thì không tài khoản thành viên nào lách được, kể cả root của tài khoản đó.

Vì sao các phương án khác sai

• A. Kích hoạt cost allocation tag — đây là bước bắt buộc phải làm để tag xuất hiện trong báo cáo chi phí, nhưng nó không gắn tag cho tài nguyên nào. Kích hoạt một tag chưa tồn tại trên tài nguyên thì báo cáo vẫn trống. (Thực tế nên làm cả A — nhưng nó không phải một trong hai hành động giải quyết vấn đề đề nêu.)
• B. Định nghĩa từng ứng dụng trong AWS Budgets — Budgets là công cụ cảnh báo khi vượt ngưỡng chi tiêu, không phải công cụ gắn tag hay phân bổ chi phí. Và nó dựa vào tag đã có, tức là cùng vấn đề con gà–quả trứng.
• C. Dùng báo cáo budget để tìm tài nguyên chưa gắn tag — Budgets không liệt kê tài nguyên chưa gắn tag; nó chỉ tổng hợp chi phí. Công cụ để tìm là Tag Editor hoặc AWS Config với rule required-tags.

Ghi nhớ

Bộ công cụ quản lý tag, mỗi cái một vai: | Công cụ | Vai trò | |---|---| | Tag Editor | tìm và gắn tag hàng loạt cho tài nguyên đang có | | SCP / IAM aws:RequestTag | chặn tạo tài nguyên thiếu tag | | AWS Config required-tags | phát hiện tài nguyên lệch chuẩn, có auto remediation | | Tag Policy (Organizations) | chuẩn hoá cách viết tag (chữ hoa/thường, giá trị hợp lệ) | | Cost allocation tags | làm tag hiện ra trong báo cáo chi phí |