Ngân hàng đề — AWS Certified CloudOps Engineer Associate

🧩 Phân tích nội dung câu hỏi

Đề mô tả một ứng dụng internet-facing chạy sau Application Load Balancer (ALB), listener được cấu hình bảo mật (HTTPS), và yêu cầu chứng chỉ SSL/TLS phải tự động gia hạn. Câu hỏi kết lại bằng "MOST efficiently".

Có ba cụm từ trong đề quyết định đáp án, và cả bốn phương án đều xoay quanh AWS Certificate Manager (ACM) nên phải bắt đúng cả ba:

• "internet-facing" → chứng chỉ phải là public certificate. Trình duyệt của người dùng bên ngoài chỉ tin chứng chỉ do một CA công cộng ký; chứng chỉ private do CA nội bộ ký sẽ bị báo lỗi tin cậy.
• "automatically renews" → phương pháp xác thực quyền sở hữu tên miền phải là loại ACM tự làm lại được, tức DNS validation.
• "MOST efficiently" → loại bỏ mọi giải pháp phải tự viết và tự vận hành code.

Ba ràng buộc này cắt đúng ba phương án sai, mỗi phương án hỏng ở một ràng buộc khác nhau — đây là kiểu câu "một biến đổi mỗi lựa chọn", cần đọc kỹ từng chữ chứ không đọc lướt tên dịch vụ.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng: C — Request a public certificate bằng ACM và dùng DNS validation, ACM tự gia hạn.

ACM cung cấp cơ chế managed renewal cho các chứng chỉ do Amazon cấp. Với DNS validation, bạn tạo một bản ghi CNAME trong zone DNS của tên miền và để nguyên bản ghi đó. Khi tới kỳ gia hạn, ACM tự truy vấn lại bản ghi CNAME này để chứng minh bạn vẫn kiểm soát tên miền, rồi cấp chứng chỉ mới — hoàn toàn không cần con người can thiệp. Đó chính là nghĩa của "automatically renews" trong đề.

Chứng chỉ public là loại phù hợp cho ứng dụng internet-facing: nó được ký bởi CA công cộng của Amazon, nằm sẵn trong kho tin cậy của trình duyệt và hệ điều hành, nên khách truy cập từ Internet mở trang là thấy khoá xanh chứ không thấy cảnh báo.

Ngoài ra, chứng chỉ ACM public gắn trực tiếp vào listener của ALB, và khi ACM gia hạn thì ALB tự dùng bản mới — không có thao tác cài lại chứng chỉ nào. Đây là lựa chọn "efficient" nhất theo đúng nghĩa: ít bộ phận chuyển động nhất.

❌ Vì sao các phương án còn lại sai

A — Public certificate + Email validation. Đây là phương án gần đúng nhất, và nó hỏng đúng một chỗ: phương pháp xác thực. Loại chứng chỉ đã đúng (public, hợp cho internet-facing), nhưng với email validation, tới kỳ gia hạn ACM gửi thư tới các địa chỉ liên hệ của tên miền và chờ người bấm xác nhận. Nếu không ai bấm, chứng chỉ không được gia hạn và listener sẽ phục vụ một chứng chỉ hết hạn. Đó là quy trình thủ công có gắn nhãn tự động, không thoả yêu cầu "automatically renews" của đề. Khi câu hỏi nhắc tới gia hạn tự động, DNS validation là câu trả lời.

B — Private certificate + DNS validation. Phương án này bắt đúng vế xác thực nhưng sai loại chứng chỉ. Chứng chỉ private do một CA nội bộ (AWS Private CA) ký, chỉ được tin cậy trong phạm vi mà bạn đã phân phối chứng chỉ gốc — phù hợp cho traffic nội bộ giữa các service, không phù hợp cho ứng dụng mở ra Internet. Người dùng bên ngoài không có CA gốc đó trong kho tin cậy nên sẽ gặp cảnh báo chứng chỉ không hợp lệ. Cụm "internet-facing" trong đề loại thẳng phương án này.

D — Public certificate + Lambda function tự gia hạn. Loại chứng chỉ đúng, nhưng phương án này tự viết lại thứ dịch vụ đã làm sẵn. ACM đã có managed renewal miễn phí và không cần bảo trì; thêm một Lambda function nghĩa là thêm code phải viết, quyền IAM phải cấp, lịch trigger phải đặt, và một điểm hỏng mới phải theo dõi. Với tiêu chí "MOST efficiently", bất kỳ phương án nào yêu cầu viết code cho việc mà dịch vụ quản lý đã đảm nhiệm đều là phương án thua.

📌 Điểm cần nhớ

• Public vs private certificate quyết định bởi ai là người kết nối: internet-facing → public certificate; traffic nội bộ giữa các thành phần → private certificate từ AWS Private CA.
• DNS validation là điều kiện của gia hạn tự động thật sự: bản ghi CNAME nằm nguyên đó cho ACM tự kiểm tra lại. Email validation đòi con người bấm xác nhận mỗi kỳ, nên thấy đề nhấn "automatic renewal" là loại ngay email validation.
• Chứng chỉ ACM gắn vào listener của ALB được thay mới trong suốt với người vận hành — không phải tải lại chứng chỉ bằng tay.
• Đề có chữ "MOST efficiently" hay "least operational overhead" thì phương án chứa Lambda tự viết hầu như luôn sai khi tồn tại một tính năng managed làm đúng việc đó.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một tình huống rất quen: log ứng dụng do phần mềm bên thứ ba thu thập rồi đổ vào một Amazon S3 bucket. Yêu cầu là tìm cách tìm kiếm, phân tích log và trực quan hoá bằng Kibana.

Có hai cụm từ trong đề quyết định đáp án, và cả hai đều phải thoả cùng lúc:

• "fully managed service" — dịch vụ được quản lý hoàn toàn. Cụm này loại thẳng mọi phương án bắt bạn tự dựng và tự vận hành cụm.
• "visualize the data using Kibana" — Kibana là giao diện đi kèm Elasticsearch/Amazon Elasticsearch Service (nay là Amazon OpenSearch Service, với OpenSearch Dashboards). Nhắc tới Kibana gần như là chỉ đích danh Elasticsearch, nên mọi kho dữ liệu không phải Elasticsearch đều bị loại.

Còn một chi tiết thứ ba, tinh hơn, dùng để phân biệt hai phương án nhìn rất giống nhau: nguồn dữ liệu là S3. Cách đưa dữ liệu từ S3 sang Elasticsearch domain là chuyện quyết định giữa C và D.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là D — tạo Amazon Elasticsearch cluster và dùng AWS Lambda để xử lý dữ liệu từ S3 bucket rồi stream sang Elasticsearch domain.

• Amazon Elasticsearch Service là dịch vụ được quản lý hoàn toàn: AWS lo việc triển khai, vá lỗi, mở rộng và bảo mật cụm. Điều này khớp đúng chữ "fully managed" trong đề.
• Kibana đi kèm sẵn với domain, nên yêu cầu trực quan hoá được đáp ứng mà không cần dựng thêm gì.
• Về đường nạp dữ liệu: một số nguồn như Kinesis Data Firehose hay CloudWatch Logs có tích hợp sẵn với Amazon ES. Còn những nguồn như S3, Kinesis Data Streams và DynamoDB thì dùng AWS Lambda làm event handler — Lambda được kích hoạt khi có dữ liệu mới, xử lý rồi stream vào domain. Đây chính xác là mô hình mà phương án D mô tả, và cũng là mẫu tích hợp S3 → Lambda → Amazon ES được tài liệu AWS ghi rõ.

❌ Vì sao các phương án còn lại sai

A — DynamoDB + Lambda nạp dữ liệu từ S3. Sai ở cả hai vế của đề. DynamoDB là key-value/document store phục vụ truy vấn theo khoá, không phải công cụ tìm kiếm và phân tích log khối lượng lớn: nó không có full-text search, không có khả năng phân tích kiểu log analytics. Quan trọng hơn, DynamoDB không dùng được Kibana để trực quan hoá — yêu cầu rõ ràng nhất của đề rơi mất hoàn toàn.

B — Elasticsearch tự cài trên EC2 + Lambda. Đây là phương án gần đúng nhất về mặt kỹ thuật: nó vẫn ra Elasticsearch, vẫn có Kibana, đường nạp dữ liệu qua Lambda cũng giống D. Nhưng nó hỏng đúng ở chữ "fully managed": cụm chạy trên EC2 nghĩa là bạn tự dựng, tự vá hệ điều hành, tự cấu hình node, tự lo mở rộng, tự lo sao lưu và tính sẵn sàng. Đó là mô hình self-managed, trái thẳng với ràng buộc đề đưa ra. So D với B, phần Elasticsearch giống nhau, chỉ khác ai vận hành cụm — và đề đã nói ai rồi.

C — Kinesis Data Firehose ingest từ S3 rồi stream sang Elasticsearch domain. Đây là bẫy khó chịu nhất, vì Firehose thật sự là dịch vụ fully managed và thật sự có tích hợp sẵn với Elasticsearch domain — hai nửa của câu đều nghe đúng. Chỗ hỏng nằm ở chiều dữ liệu: S3 không phải là nguồn (source) mà Firehose đọc vào. Trong kiến trúc Firehose, S3 đóng vai trò đích đến, hoặc nơi sao lưu bản ghi lỗi — dữ liệu được đẩy vào Firehose từ producer (SDK, agent, Kinesis Data Streams…), chứ Firehose không tự đi kéo dữ liệu ra khỏi một bucket có sẵn. Ở đây log đã nằm sẵn trong S3 rồi, nên Firehose không có cách nào bắt đầu luồng. Đúng vì lý do này mà S3 phải dùng Lambda làm event handler như phương án D.

📌 Điểm cần nhớ

• Thấy "Kibana" trong đề thì nghĩ ngay tới Elasticsearch/OpenSearch domain — không kho dữ liệu nào khác trong danh sách phương án (DynamoDB, S3 trần…) dùng được Kibana.
• "Fully managed" là từ khoá loại trừ: bất kỳ phương án nào nói "cluster on EC2", "install on EC2", "self-hosted" đều bị loại, dù kiến trúc còn lại đúng y hệt.
• Nhớ chiều dữ liệu của Kinesis Data Firehose: S3 là destination, không phải source. Firehose nhận từ producer/Kinesis Data Streams và ghi ra S3, Elasticsearch, Redshift…
• Mẫu tích hợp cần thuộc: nguồn có tích hợp sẵn với Amazon ES gồm Firehose và CloudWatch Logs; còn S3, Kinesis Data Streams và DynamoDB thì đi qua AWS Lambda làm event handler. Câu hỏi dạng "dữ liệu đang nằm trong S3, làm sao đưa vào Elasticsearch" gần như luôn có đáp án chứa Lambda.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một công ty dùng AWS Organizations với consolidated billing (gộp hoá đơn), và người quản trị muốn được cảnh báo khi tổng chi phí của TẤT CẢ tài khoản trong tổ chức vượt một ngưỡng nhất định.

Có hai cụm từ quyết định đáp án:

• "total billing for all accounts" — cần con số tổng của cả tổ chức, chứ không phải chi phí lẻ của từng member account. Trong mô hình consolidated billing, nơi duy nhất nhìn thấy con số tổng đó là payer account (management account). Suy ra: mọi thao tác cấu hình đều phải làm ở payer account, không phải rải ra từng member account.
• "be alerted if ... exceeds a specific threshold" — đây là mô tả kinh điển của một alarm theo ngưỡng trên một metric. Dịch vụ chịu trách nhiệm về metric và alarm trong AWS là Amazon CloudWatch, cụ thể là metric EstimatedCharges trong namespace AWS/Billing.

Hai ràng buộc này chia bốn phương án thành lưới 2×2: payer account hay member account × CloudWatch hay AWS Config. Chỉ một ô đúng cả hai chiều.

✅ Vì sao đáp án đúng là đúng

Phương án A — bật Receive Billing Alerts ở payer account, tạo billing alarm trong Amazon CloudWatch, dùng SNS để gửi thông báo khi alarm chuyển sang trạng thái ALARM.

Cơ chế hoạt động: khi bạn bật theo dõi estimated charges cho tài khoản, AWS tính chi phí ước tính và đẩy sang CloudWatch dưới dạng dữ liệu metric nhiều lần mỗi ngày. Trong một tổ chức dùng consolidated billing, metric của các member account chỉ được ghi nhận nếu payer account đã bật tuỳ chọn Receive Billing Alerts — đúng một lần, ở đúng một chỗ. Nhờ vậy payer account có được metric phản ánh tổng chi phí toàn tổ chức.

Từ metric đó, bạn tạo một CloudWatch alarm với ngưỡng mong muốn, và gắn SNS topic làm hành động khi alarm kích hoạt. SNS lo phần phát thông báo (email, HTTP endpoint, v.v.). Ba mảnh ghép — preference ở payer account, alarm ở CloudWatch, thông báo qua SNS — khớp chính xác yêu cầu của đề.

❌ Vì sao các phương án còn lại sai

B — Receive Billing Alerts ở từng member account + billing alarm trong AWS Config ở payer account. Sai cả hai chiều. Thứ nhất, tuỳ chọn nhận billing alerts phải bật ở payer account; bật lẻ tẻ ở từng member account không làm cho metric chi phí xuất hiện đúng cách theo mô hình consolidated billing. Thứ hai, AWS Config không phải nơi tạo alarm theo ngưỡng metric — nó theo dõi cấu hình tài nguyên và đánh giá tuân thủ (compliance) so với các rule, chứ không đọc metric EstimatedCharges và cũng không có khái niệm alarm ngưỡng như CloudWatch.

C — Receive Billing Alerts ở payer account + billing alarm trong AWS Config. Đây là phương án gần đúng nhất và cũng là bẫy chính: vế đầu hoàn toàn chuẩn, bật preference ở đúng payer account. Nó hỏng ở vế thứ hai — đặt alarm vào AWS Config. Dữ liệu chi phí ước tính chảy vào CloudWatch dưới dạng metric, nên nơi duy nhất đặt được ngưỡng cảnh báo trên dữ liệu đó là CloudWatch alarm. Chọn C nghĩa là bạn nhận diện đúng mô hình billing nhưng nhầm dịch vụ giám sát.

D — Receive Billing Alerts ở từng member account + billing alarm trong Amazon CloudWatch ở payer account. Cũng gần đúng, và là bẫy đối xứng với C: đúng dịch vụ (CloudWatch, SNS), sai chỗ bật preference. Đề bài nói rõ cần con số tổng của cả tổ chức; cả hai thay đổi cấu hình đều phải thực hiện tại payer account. Đi bật preference ở từng member account vừa tốn công vừa không cho ra thứ đề bài cần.

📌 Điểm cần nhớ

• Trong consolidated billing, metric chi phí của member account chỉ được thu thập khi payer account bật Receive Billing Alerts — mọi cấu hình liên quan đến billing alert nằm ở payer account, không rải xuống member account.
• Chi phí ước tính được đưa vào Amazon CloudWatch dưới dạng metric (EstimatedCharges, namespace AWS/Billing), nên cảnh báo theo ngưỡng chi phí = CloudWatch alarm, không phải AWS Config.
• AWS Config dùng để ghi lại và đánh giá cấu hình tài nguyên so với rule tuân thủ — thấy nó xuất hiện trong một câu hỏi về "alarm theo ngưỡng" thì gần như chắc chắn là phương án nhiễu.
• Mẫu chuẩn cho mọi cảnh báo trong AWS: metric → CloudWatch alarm → SNS topic → người nhận. Nhận ra mẫu này giúp loại nhanh các phương án thay CloudWatch bằng dịch vụ khác.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một tình huống rất cụ thể: ban quản lý muốn xem và theo dõi chi phí của từng project riêng biệt nằm trong CÙNG MỘT AWS account, và thông tin đó phải hiển thị được trong AWS Cost Explorer.

Có ba cụm từ quyết định đáp án:

• "separate projects within an AWS account" — ranh giới cần phân tách là project, không phải account. AWS không có khái niệm "project" tự nhiên trong dữ liệu billing; chi phí mặc định chỉ được bóc tách theo service, region, usage type, linked account… Muốn có chiều "project" thì phải tự tạo ra chiều đó, và cách tạo là gắn nhãn lên tài nguyên.
• "within an AWS account" (số ít) — loại thẳng mọi phương án dựa vào ranh giới nhiều account.
• "viewed for each project in AWS Cost Explorer" — kết quả phải là một dimension lọc/nhóm được ngay trong Cost Explorer, chứ không phải một cảnh báo, một ngưỡng ngân sách hay một tệp báo cáo thô.

Ghép lại: cần một cơ chế biến "project" thành một chiều dữ liệu billing hợp lệ bên trong một account duy nhất.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng là A — Activate cost allocation tags, rồi tag tài nguyên theo project mà nó thuộc về.

Tag là nhãn gồm cặp key–value gắn lên tài nguyên AWS; mỗi resource thì mỗi tag key là duy nhất và ứng với đúng một value. Nhưng bản thân việc gắn tag chưa đủ — tag chỉ mang ý nghĩa quản lý thông thường cho tới khi bạn kích hoạt nó thành cost allocation tag trong phần Billing. Sau khi kích hoạt, AWS bắt đầu dùng tag đó để tổ chức chi phí tài nguyên trong cost allocation report, và chiều đó xuất hiện trong Cost Explorer để lọc và group by.

Đúng như đề yêu cầu: gắn tag kiểu Project = <tên project> cho mọi tài nguyên, kích hoạt tag key Project, thế là ban quản lý mở Cost Explorer, group by tag Project và thấy chi phí tách theo từng project — tất cả nằm gọn trong một account. Lưu ý thứ tự trong đáp án cũng chính là điều đề hỏi: activate trước, tag tài nguyên — hai vế đều cần, thiếu vế nào cũng không ra dữ liệu.

❌ Vì sao các phương án còn lại sai

B — Cost categories định nghĩa nhóm tuỳ biến dựa trên cost and usage dimensions. Đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì cost categories thật sự dùng để gom chi phí thành các nhóm do mình đặt tên. Nhưng nó hỏng ở nguyên liệu đầu vào: rule của cost category phải dựa trên các dimension đã tồn tại trong dữ liệu billing. Mà "project" chưa tồn tại như một dimension — phải activate cost allocation tags và tag tài nguyên trước thì tag mới trở thành dimension để cost category viết rule lên đó. Nói cách khác, B là bước sau, không thay thế được A; chọn B mà bỏ A thì không có gì để nhóm.

C — Tạo billing alert trong AWS Budgets theo dõi tài nguyên của từng project. Sai ở mục đích công cụ lẫn thứ tự phụ thuộc. Budgets là công cụ đặt ngưỡng và báo động khi chi phí vượt ngưỡng, không phải công cụ để xem và phân tích chi phí — mà đề yêu cầu rõ là view/track trong Cost Explorer. Ngoài ra, muốn budget lọc được "tài nguyên của project X" thì cũng phải có cost allocation tag trước, nên C vấp đúng vấn đề của B: không thể theo dõi tài nguyên theo project khi chưa bật tag.

D — Dùng AWS Organizations, bật consolidated billing, tạo Cost and Usage Reports. Sai ở ranh giới phân tách. Organizations + consolidated billing bóc tách chi phí theo account, phù hợp khi mỗi project nằm ở một account riêng — nhưng đề nói rõ các project nằm trong cùng một account, nên cơ chế này không tách được gì. Phần CUR cũng lệch yêu cầu: đó là báo cáo chi tiết dạng tệp đổ ra S3 để phân tích sâu, không phải cách "xem trong Cost Explorer". Và ngay cả khi dùng CUR, muốn cột "project" xuất hiện trong đó thì vẫn phải quay lại bật cost allocation tags.

📌 Điểm cần nhớ

• Đề hỏi tách chi phí theo một chiều do mình tự định nghĩa (project, team, môi trường, cost center) trong một account → gần như luôn là cost allocation tags.
• Tag phải được activate trong Billing thì mới thành cost allocation tag; chỉ gắn tag lên resource là chưa đủ để chi phí hiện ra theo chiều đó.
• Phân biệt vai trò công cụ: Cost Explorer để xem/phân tích, Budgets để cảnh báo theo ngưỡng, CUR để xuất dữ liệu thô chi tiết, Cost categories để gom nhóm — và cost categories lẫn Budgets đều đứng sau tag chứ không thay thế tag.
• Tách theo account thì dùng Organizations + consolidated billing; tách trong một account thì dùng tag. Đọc kỹ đề xem ranh giới là account hay project.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một kiến trúc quen thuộc: người dùng → CloudFront → ALB → EC2 trong VPC, backend là DynamoDB. Nhưng kiến trúc chỉ là bối cảnh; câu hỏi thật nằm ở một dòng duy nhất:

"investigate HTTP Layer 7 status codes from the web application"

Cụm quyết định là "Layer 7 status codes" — tức mã trạng thái HTTP (200, 404, 502, 503…) ở tầng ứng dụng của mô hình OSI. Kèm theo đó là yêu cầu (Select TWO), nên phải tìm đúng hai nguồn log thực sự ghi lại nội dung HTTP của từng request.

Đây là kiểu câu phân loại nguồn log theo tầng mà nó quan sát được. Năm phương án đại diện cho bốn loại log rất khác nhau:

• log truy cập HTTP (CloudFront, ALB) — tầng 7
• log luồng mạng (VPC Flow Logs) — tầng 3/4
• log gọi API quản trị (CloudTrail) — mặt phẳng điều khiển
• "log của DynamoDB" — một thứ không tồn tại theo nghĩa đề đang hỏi

Chỉ cần đặt đúng từng nguồn vào tầng của nó là câu tự trả lời.

✅ Vì sao đáp án đúng là đúng

Đáp án theo tệp là C và E.

E — ALB access logs. Application Load Balancer hoạt động ở tầng 7: nó phân tích chính giao thức HTTP để định tuyến. Access log của ALB ghi lại chi tiết từng request, trong đó có mã trạng thái mà ALB trả về cho client và mã trạng thái mà target (EC2) trả về cho ALB — hai trường tách biệt nhau, rất đắt giá khi cần phân biệt lỗi do backend hay do chính load balancer. Ngoài ra log còn có thời điểm nhận request, IP client, đường dẫn request và các mốc độ trễ, đúng như tài liệu AWS mô tả.

C — CloudFront access logs. CloudFront có thể ghi log truy cập (standard logs / access logs) chứa thông tin chi tiết về mọi request người dùng gửi tới CloudFront, và lưu vào bucket Amazon S3 do bạn chỉ định. Vì CloudFront cũng là một dịch vụ HTTP, log này chứa mã trạng thái trả về cho người dùng cuối. Đây là điểm quan sát xa nhất về phía người dùng: có những request CloudFront phục vụ từ cache và không bao giờ chạm tới ALB, nên nếu chỉ xem log ALB thì bức tranh sẽ khuyết đúng phần đó.

Hai nguồn này bổ sung cho nhau: CloudFront cho biết người dùng thực sự nhận được mã gì, ALB cho biết tầng phía sau trả lời ra sao.

❌ Vì sao các phương án còn lại sai

A — Amazon DynamoDB logs. DynamoDB không sinh ra loại log truy cập tầng ứng dụng HTTP như đề đang cần. Hoạt động của DynamoDB được ghi qua CloudTrail dưới dạng lời gọi API, nhưng đó là các thao tác lên bảng dữ liệu, không phải mã trạng thái HTTP của web application. Đây cũng là bẫy "dịch vụ có xuất hiện trong đề nên chắc có liên quan" — DynamoDB nằm ở backend, cách xa điểm mà mã trạng thái HTTP được sinh ra cho người dùng.

B — Amazon CloudTrail logs. CloudTrail ghi hoạt động API của mặt phẳng điều khiển: ai gọi lệnh gì lên dịch vụ AWS, lúc nào, từ đâu. Nó trả lời câu hỏi "ai đã sửa cấu hình ALB", chứ không trả lời "request nào bị 502". Đây là phương án dễ chọn nhầm nhất vì CloudTrail cũng có khái niệm mã lỗi — nhưng đó là mã lỗi của lời gọi API AWS, không phải mã trạng thái HTTP của ứng dụng web đang phục vụ khách.

D — VPC Flow Logs. Đây là phương án gần đúng nhất và cũng nguy hiểm nhất, vì đề có nhắc tới VPC nên nó trông rất "thuộc về" kiến trúc này. Flow Logs ghi metadata của luồng traffic IP: IP nguồn/đích, cổng, giao thức, số gói, số byte, và kết quả ACCEPT hay REJECT. Toàn bộ là dữ liệu tầng 3/4, không mở gói tin để đọc nội dung HTTP. Nó cho biết có kết nối tới cổng 443 hay không, nhưng tuyệt đối không cho biết kết nối đó trả về 200 hay 503. Đúng ràng buộc "Layer 7" trong đề loại nó ra.

📌 Điểm cần nhớ

• Đề nêu tầng OSI thì đó chính là bộ lọc phương án: tầng 7 → access log của dịch vụ HTTP (ALB, CloudFront); tầng 3/4 → VPC Flow Logs. Ghép sai tầng là sai ngay, bất kể dịch vụ đó có trong kiến trúc hay không.
• Phân biệt ba họ log AWS: access log (nội dung request của người dùng), flow log (metadata kết nối mạng), CloudTrail (lời gọi API quản trị). Ba loại trả lời ba câu hỏi khác nhau và gần như không thay thế được cho nhau.
• ALB là load balancer tầng 7 nên access log của nó có mã trạng thái; đặc biệt nó tách riêng mã do ALB trả về và mã do target trả về — dùng để khoanh vùng lỗi nằm ở backend hay ở load balancer.
• Khi có CDN đứng trước, log ở CDN và log ở origin không trùng nhau: request được phục vụ từ cache chỉ hiện trong CloudFront access logs. Điều tra đầy đủ cần cả hai điểm quan sát.
• Cẩn thận với các dịch vụ được nhắc trong đề chỉ để làm nhiễu (ở đây là DynamoDB và VPC) — xuất hiện trong kiến trúc không có nghĩa là nó sinh ra loại dữ liệu đang cần.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một công ty đang lưu dữ liệu trong một bảng Amazon DynamoDB, và SysOps administrator phải cấu hình sao cho bảng đó được nhân bản sang một AWS Region khác nhằm đáp ứng yêu cầu disaster recovery.

Cụm từ quyết định đáp án là "replication of the table in an alternate AWS Region" — tức là dữ liệu phải tồn tại ở một Region thứ hai, cập nhật theo bảng gốc. Đây là ràng buộc liên Region (cross-Region), không phải "khôi phục dữ liệu bị xoá nhầm", không phải "đọc nhanh hơn", cũng không phải "truy vấn theo thuộc tính khác". Ba phương án sai đều là tính năng thật của DynamoDB, nhưng cả ba đều nằm gọn trong một Region duy nhất. Chỉ cần bám vào chữ alternate Region là loại được ngay ba lựa chọn kia.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng là B — Implement DynamoDB Streams and establish a global table in another Region.

DynamoDB global tables là giải pháp được quản lý hoàn toàn để triển khai một cơ sở dữ liệu multi-Region, multi-master. Đây chính là tính năng của DynamoDB dùng để nhân bản dữ liệu sang nhiều AWS Region khác nhau — đúng thứ mà yêu cầu disaster recovery trong đề đòi hỏi.

Điểm mấu chốt của phương án này là mối liên hệ giữa hai thành phần: global tables dùng DynamoDB Streams làm cơ chế lan truyền thay đổi. Mọi thao tác ghi trên Region gốc được ghi vào stream, và stream đó là kênh để DynamoDB tự động đẩy thay đổi sang các bản replica ở Region khác. Vì vậy câu trả lời gộp cả hai vế "Streams + global table" là mô tả đúng cách tính năng này hoạt động, chứ không phải hai việc rời rạc ghép lại cho có.

❌ Vì sao các phương án còn lại sai

A — Activate point-in-time recovery (PITR). Đây là phương án dễ nhầm nhất vì nó cũng thuộc nhóm bảo vệ dữ liệu. PITR cung cấp backup liên tục, giúp bảo vệ bảng khỏi các thao tác ghi hoặc xoá nhầm bằng cách cho phép khôi phục về một thời điểm trong quá khứ. Nhưng nó giải quyết trục thời gian, không giải quyết trục địa lý: bản thân việc bật PITR không tạo ra bản sao dữ liệu đang được cập nhật liên tục ở một Region khác. Đề hỏi replication sang Region khác, PITR không đáp ứng.

C — Activate DynamoDB Accelerator (DAX). DAX là in-memory cache được quản lý, tính sẵn sàng cao, đặt trước DynamoDB để tăng tốc độ đọc. Nó là lớp cache hiệu năng, hoàn toàn không liên quan tới disaster recovery và không cung cấp regional replication. Dữ liệu trong DAX là bản tạm để phục vụ đọc nhanh, không phải bản sao bền vững ở Region khác.

D — Enable DynamoDB Streams and create a global secondary index (GSI). Đây là bẫy tinh vi nhất: vế đầu ("DynamoDB Streams") giống hệt đáp án đúng, nên nếu chỉ đọc lướt rất dễ chọn nhầm. Chỗ hỏng nằm ở vế sau. GSI phục vụ thêm access pattern — cho phép truy vấn dữ liệu theo partition key / sort key khác với bảng gốc — chứ không phải để nhân bản dữ liệu sang Region khác. GSI sống cùng bảng, trong cùng Region với bảng. Bật Streams mà không tạo global table thì bạn chỉ có một luồng sự kiện thay đổi, còn việc mang dữ liệu sang Region khác vẫn chưa ai làm.

📌 Điểm cần nhớ

• Trong đề DynamoDB, cứ thấy yêu cầu "another/alternate Region", multi-Region, hay disaster recovery cấp Region thì đích đến gần như luôn là global tables.
• Phân biệt rõ bốn tính năng theo vấn đề chúng giải quyết: global tables → nhân bản liên Region; point-in-time recovery → khôi phục theo thời điểm, chống xoá/ghi nhầm; DAX → cache in-memory, tăng tốc đọc; GSI → thêm cách truy vấn dữ liệu.
• DynamoDB Streams là cơ chế nền của global tables, không phải một giải pháp replication đứng một mình. Thấy "Streams" trong một phương án chưa đủ để kết luận phương án đó đúng — phải đọc tiếp vế sau xem Streams được dùng để làm gì.
• Khi hai phương án chia sẻ chung một nửa nội dung (ở đây là "Enable DynamoDB Streams"), nửa giống nhau đó là nhiễu; điểm phân biệt luôn nằm ở nửa còn lại.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một EC2 Linux instance nằm trong public subnet, đã có public IP, nhưng SSH từ máy quản trị viên thất bại với lỗi timeout.

Cụm từ quyết định đáp án là "fails repeatedly with a timeout error" — kiểu lỗi, chứ không phải bản thân việc kết nối hỏng. Trong AWS, cách hỏng của kết nối là manh mối chẩn đoán:

• Timeout (gói tin đi vào rồi biến mất, không có phản hồi nào) là dấu hiệu điển hình của việc traffic bị chặn im lặng — security group hoặc network ACL không cho port 22 đi vào.
• Nếu đường đi (routing) sai hoặc không có đường về, kết nối thường hỏng nhanh kiểu "network unreachable" chứ không treo tới lúc hết giờ.

Đề cũng đã chủ động loại bỏ hai nghi phạm khác: instance ở public subnet và đã có public IP, nên không phải chuyện thiếu Internet Gateway hay thiếu địa chỉ công khai. Còn lại đúng một chỗ để sửa: rule cho phép SSH đi vào (inbound) trên security group của instance.

✅ Vì sao đáp án đúng là đúng

D — Update the instance security group with a rule allowing SSH inbound from the SysOps administrator's IP address.

Security group là firewall gắn ở tầng instance (ENI). Mặc định, một security group mới không có inbound rule nào, tức là mọi kết nối từ bên ngoài đi vào đều bị bỏ im lặng — đúng triệu chứng timeout mà đề mô tả.

Chiều của rule cũng khớp với chiều của kết nối: người quản trị khởi tạo phiên SSH từ máy của họ vào instance, nên đây là traffic inbound trên port 22. Thêm inbound rule cho protocol SSH với source là IP của quản trị viên vừa mở đúng thứ cần mở, vừa là cấu hình an toàn nhất: chỉ đúng một địa chỉ đó SSH được, thay vì mở cho toàn Internet.

Không cần thêm outbound rule cho gói tin phản hồi, vì security group là stateful — traffic đi vào đã được cho phép thì phản hồi tương ứng tự động được ra, bất kể outbound rule.

❌ Vì sao các phương án còn lại sai

A — Network ACL cho phép port 22 outbound tới IP của quản trị viên. Đây là phương án gần đúng nhất và cũng dễ bẫy nhất, vì network ACL là stateless nên người ta hay nghĩ "phải mở cả hai chiều". Nhưng nó hỏng ở chiều được mở: chiều cần thiết cho việc thiết lập phiên SSH là inbound port 22, còn phương án chỉ đụng tới outbound. Ngoài ra network ACL mặc định vốn cho phép toàn bộ traffic hai chiều, nên nó thường không phải thủ phạm; sửa outbound ở đây không giúp gì cho kết nối đi vào.

B — Security group cho phép SSH outbound tới IP của quản trị viên. Đúng đối tượng (security group của instance) nhưng sai chiều. Kết nối do quản trị viên khởi tạo, nên instance là bên nhận, cần inbound rule. Outbound rule chỉ có tác dụng khi chính instance chủ động mở kết nối SSH ra ngoài. Hơn nữa security group mặc định đã cho phép toàn bộ outbound, nên rule này gần như không đổi gì.

C — Thêm entry cho IP của quản trị viên vào route table của subnet. Route table quyết định gói tin đi theo hướng nào (ví dụ 0.0.0.0/0 trỏ về Internet Gateway), không phải nơi liệt kê từng IP client được phép truy cập — đó là nhầm lẫn giữa routing và filtering. Thêm nữa, subnet đã là public nên đường ra Internet đã có sẵn; và nếu routing thật sự sai thì kết nối thường hỏng nhanh chứ không timeout như đề mô tả.

📌 Điểm cần nhớ

• Đọc kiểu lỗi để đoán tầng hỏng: timeout → traffic bị chặn im lặng (security group / network ACL); connection refused → tới được instance nhưng không có dịch vụ nghe ở port đó; hỏng nhanh kiểu unreachable → nghi routing.
• Xác định chiều theo bên khởi tạo kết nối: ai gọi trước thì bên kia cần inbound. Client SSH vào server ⇒ inbound port 22 trên security group của server.
• Security group là stateful, network ACL là stateless: với security group chỉ cần mở đúng một chiều, phản hồi tự động được phép; với network ACL mới phải nghĩ tới cả hai chiều (kể cả dải ephemeral port cho traffic trả về).
• Route table định tuyến, security group/NACL mới lọc. Không bao giờ đặt IP của một người dùng cụ thể vào route table để "cấp quyền" truy cập.
• Mặc định: security group chặn hết inbound, mở hết outbound; network ACL mặc định cho phép cả hai chiều — nên nghi can số một khi không SSH được thường là inbound rule của security group.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một nền tảng e-commerce chạy trên nhiều EC2 instance nằm sau một Application Load Balancer (ALB), và yêu cầu SysOps administrator bảo đảm toàn bộ traffic của website đi qua HTTPS. Câu hỏi chọn hai bước.

Hai cụm từ trong đề quyết định đáp án:

• "e-commerce platform" — đây là website phục vụ người dùng trên Internet công cộng. Trình duyệt của khách chỉ tin certificate do một public CA ký; certificate loại "private" chỉ được tin trong nội bộ tổ chức. Cụm này một mình đã loại phương án A.
• "behind an Application Load Balancer" — điểm tiếp nhận kết nối từ Internet là ALB, không phải từng EC2 instance. Nơi cần trình bày certificate cho client vì thế là listener HTTPS của ALB. Cụm này quyết định giữa "gắn lên ALB" và "cài lên từng instance".

Ghép lại: cần một certificate public và cần gắn nó vào ALB — đúng hai bước, đúng số lượng đề yêu cầu.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là C và D.

D — Provision a public SSL certificate through AWS Certificate Manager (ACM). ACM cấp phát, quản lý và triển khai certificate SSL/TLS cho các dịch vụ AWS. Với website hướng ra Internet thì phải là public certificate, vì chuỗi tin cậy của nó neo vào một public CA mà mọi trình duyệt đều đã tin sẵn. Certificate public của ACM còn được ACM tự lo việc gia hạn, nên không có chuyện website chết vì certificate hết hạn giữa đêm.

C — Associate the SSL certificate with the ALB. ALB là điểm chấm dứt kết nối từ client, nên certificate phải nằm ở listener HTTPS của ALB. Gắn một lần là mọi instance phía sau đều được phủ, không cần đụng vào từng máy, và số lượng instance có thay đổi (auto scaling) cũng không ảnh hưởng gì. Traffic được giải mã tại ALB, kiểm tra nếu cần, rồi có thể mã hoá lại khi chuyển tiếp về backend.

Hai bước này bổ trợ nhau: D tạo ra thứ cần gắn, C là hành động gắn. Thiếu một trong hai thì HTTPS không hoạt động.

❌ Vì sao các phương án còn lại sai

A — Generate a private SSL certificate using AWS Certificate Manager (ACM). Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi: nó vẫn dùng ACM, vẫn là bước "tạo certificate", chỉ sai đúng một chữ private. Private certificate của ACM chỉ được tin cậy trong nội bộ tổ chức (các máy đã được cài root CA của bạn), không được trình duyệt của khách hàng ngoài Internet tin. Gắn nó lên ALB thì mọi khách vào trang e-commerce đều thấy cảnh báo certificate không tin cậy — về mặt kỹ thuật là HTTPS, nhưng về mặt sử dụng là website hỏng. Private certificate hợp cho traffic nội bộ giữa các thành phần, không hợp cho mặt tiền công khai.

B — Install the SSL certificate directly on each EC2 instance. Về nguyên tắc thì cài certificate lên từng instance là làm được, nhưng đây không phải cách nên làm trong kiến trúc có ALB: mỗi instance thêm vào là thêm một chỗ phải cài và phải gia hạn, việc quản lý phình ra theo số lượng máy. Quan trọng hơn, nó không kết hợp được với ACM: ACM không cho export private key của public certificate, nên certificate ACM không thể mang xuống cài trên EC2. Chọn B là tự đẩy mình sang hướng phải mua và quản lý certificate thủ công.

E — Secure the website by attaching an externally obtained certificate. Cùng vướng đúng rào cản trên nhưng theo chiều ngược lại: certificate do ACM quản lý không lấy được phần private key ra để mang sang dùng ở nơi khác. Ngoài ra phương án này bỏ qua hạ tầng sẵn có — đề đã có ALB và ACM tích hợp trực tiếp với ALB, đi vòng qua certificate bên ngoài chỉ thêm việc mà không giải quyết gì thêm.

📌 Điểm cần nhớ

• Public-facing thì dùng public certificate; private certificate của ACM chỉ được tin trong nội bộ. Thấy chữ "e-commerce", "public website", "customers" trong đề là loại ngay các phương án "private certificate".
• Certificate gắn ở điểm chấm dứt kết nối TLS, tức là ALB / CloudFront / API Gateway, không phải ở từng EC2 instance phía sau. Gắn một chỗ, phủ toàn bộ backend.
• ACM không cho export private key của public certificate. Bất cứ phương án nào đòi mang certificate ACM đi cài lên EC2 hay lên máy chủ ngoài AWS đều bất khả thi — đây là mẹo loại đáp án rất hay dùng lại.
• Câu "chọn TWO" thường ghép cặp tạo tài nguyên + gắn tài nguyên. Khi thấy một phương án là "provision/create X" và một phương án là "associate X with Y", nhiều khả năng đó chính là cặp đáp án.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một ứng dụng đã được triển khai bằng CloudFormation stack set trải trên nhiều AWS account và nhiều Region. Quản trị viên có một template mới và muốn thử nghiệm bản cập nhật trên một tập con (subset) các account và Region trước khi tung ra toàn bộ stack set.

Cụm từ quyết định đáp án là "test the update in a subset of the accounts and Regions before rolling it out to the entire stack set". Từ khoá ở đây không phải là "cập nhật" mà là phạm vi cập nhật: chỉ một phần, chứ không phải tất cả stack instance.

Điều này va thẳng vào bản chất của stack set: một stack set là một đơn vị quản lý duy nhất, và thao tác cập nhật stack set tác động lên toàn bộ stack instance thuộc về nó. Nếu có 20 account × 2 Region thì có 40 stack instance, và cập nhật stack set nghĩa là cả 40 đều đổi theo. Vì vậy, muốn có nhóm "thử nghiệm" riêng biệt thì phải tách nó ra thành một đơn vị quản lý khác — tức là một stack set khác.

✅ Vì sao đáp án đúng là đúng

A. Create a separate stack set to test the update.

Vì ranh giới cập nhật của CloudFormation là chính stack set, cách duy nhất trong danh sách để có được quyền kiểm soát ở mức nhỏ hơn là tạo thêm stack set. Quản trị viên dựng một stack set riêng chứa các account/Region dùng làm môi trường thử, triển khai template mới lên đó, quan sát kết quả; nếu ổn thì mới cập nhật stack set chính đang phục vụ toàn bộ hệ thống.

Đây cũng chính là khuyến nghị của AWS trong tài liệu best practices cho stack set: với stack set có nhiều stack instance, hãy thử template mới trên một vài account thử nghiệm trước; và để có kiểm soát chi tiết hơn đối với từng stack bên trong stack set, hãy lên kế hoạch tạo nhiều stack set ngay từ đầu. Nói cách khác, "phân nhóm để triển khai theo từng đợt" là một quyết định thiết kế cấu trúc stack set, không phải một tuỳ chọn bật lên lúc chạy lệnh update.

❌ Vì sao các phương án còn lại sai

B. Use a change set for the stack set to test the update. — Đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì change set đúng là công cụ "xem trước thay đổi" của CloudFormation. Nhưng change set chỉ cho biết những tài nguyên nào sẽ bị tạo/sửa/xoá nếu áp template mới; nó là bản xem trước, không phải một lần triển khai thật để quan sát ứng dụng chạy đúng hay sai. Quan trọng hơn với câu này: change set không cho chọn riêng từng account và Region bên trong stack set. Nó hỏng đúng ở yêu cầu cốt lõi của đề — phạm vi.

C. Update the stack set and select a single account and Region. — Phương án này mô tả đúng điều quản trị viên mong muốn, nhưng lại không đúng với cách stack set hoạt động theo lập luận ở trên: cập nhật stack set là cập nhật toàn bộ stack instance của nó, chứ không phải chỉ một account/Region được chọn ra. Chọn phương án này là biến thao tác "thử nghiệm" thành thao tác "tung ra toàn hệ thống" — đúng cái rủi ro mà đề đang muốn tránh.

D. Create a nested stack to deploy the update. — Nested stack là cơ chế tổ chức template: tách một template lớn thành các template con để tái sử dụng và giảm độ phức tạp. Nó giải quyết bài toán cấu trúc bên trong một stack, hoàn toàn không liên quan tới việc chọn account/Region nào được nhận bản cập nhật. Tạo nested stack không giúp giới hạn phạm vi triển khai của stack set chút nào.

📌 Điểm cần nhớ

• Stack set là ranh giới cập nhật. Update một stack set thì mọi stack instance (mọi account × mọi Region) đều bị tác động; không có nút "chỉ áp cho account này".
• Muốn triển khai theo đợt thì phải chia thành nhiều stack set — đây là quyết định thiết kế lúc lập kế hoạch, và là khuyến nghị best practice của AWS cho stack set có nhiều instance.
• Change set = xem trước, không phải thử nghiệm thật, và không chọn được phạm vi. Gặp từ khoá "preview what will change" thì nghĩ tới change set; gặp "test on a subset of accounts/Regions" thì nghĩ tới stack set riêng.
• Nested stack là chuyện cấu trúc template, không phải chuyện phạm vi triển khai — đừng để nó lẫn vào các câu hỏi về stack set.

🧩 Phân tích nội dung câu hỏi

Một tài khoản AWS dùng chung cho hơn 60 developer, chi phí hằng tháng tăng lên và người quản lý muốn biết chi phí phát sinh theo từng developer. Câu hỏi yêu cầu chọn HAI việc mà SysOps administrator phải làm để thu thập thông tin đó.

Cụm từ quyết định nằm ở hai chỗ:

• "costs incurred per developer" — không phải tổng chi phí của tài khoản, mà là chi phí bóc tách theo từng người. Trong một tài khoản AWS duy nhất, cách duy nhất để tách chi phí theo chiều nào đó là cost allocation tag: phải có một tag gắn được lên resource và nói được ai tạo ra nó.
• "collect this information" — đề hỏi cách thu thập và xem số liệu chi phí, tức là báo cáo, chứ không phải cảnh báo, không phải kiểm tra tuân thủ cấu hình, cũng không phải audit lời gọi API.

Ghép hai ràng buộc này lại: cần một thứ gán nhãn chi phí theo người tạo, cộng với một thứ đọc và phân tích chi phí theo nhãn đó. Đúng hai mảnh — khớp với yêu cầu "Select TWO".

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là A và B.

B — Activate the createdBy tag in the account. createdBy là một AWS generated tag: AWS tự định nghĩa và tự gắn lên các resource được hỗ trợ, phục vụ mục đích phân bổ chi phí (cost allocation). Điểm mấu chốt là nó không tự bật — chủ tài khoản quản lý phải vào Billing and Cost Management console kích hoạt tag này thì dữ liệu mới bắt đầu được ghi nhận cho việc phân bổ chi phí. Vì tag này ghi lại ai là người tạo ra resource, nó chính là chiều dữ liệu cho phép quy chi phí về từng developer trong cùng một tài khoản.

A — Analyze the usage with AWS Cost Explorer. Bật tag mới chỉ tạo ra nhãn; phải có công cụ đọc nhãn đó ra thành báo cáo. AWS Cost Explorer cho phép lọc và nhóm chi phí theo cost allocation tag, nên sau khi createdBy được kích hoạt, người quản lý dùng Cost Explorer nhóm theo tag này để thấy tổng chi phí của từng developer.

Hai phương án bổ trợ nhau chứ không trùng lặp: B tạo dữ liệu phân bổ, A trình bày dữ liệu đó. Thiếu B thì Cost Explorer chỉ thấy chi phí gộp cả tài khoản; thiếu A thì tag có mà không ai đọc.

❌ Vì sao các phương án còn lại sai

C — Configure AWS Config to track resource usage. AWS Config theo dõi cấu hình của resource và lịch sử thay đổi cấu hình, phục vụ compliance và audit. Nó cho biết resource tồn tại, được cấu hình ra sao, đổi lúc nào — nhưng hoàn toàn không phải công cụ quản lý chi phí và không tạo ra số tiền cho từng developer. Đây là phương án nghe hợp lý vì có chữ "track resource usage", nhưng "usage" ở đây là trạng thái cấu hình, không phải chi phí.

D — Create a billing alarm in AWS Budgets. Đây là phương án gần đúng nhất và cần chỉ rõ nó hỏng ở đâu. AWS Budgets đúng là thuộc mảng cost management, nhưng bản chất nó là cơ chế đặt ngưỡng và cảnh báo khi chi phí vượt mức — nó trả lời câu "đã vượt hạn mức chưa", chứ không phải câu "mỗi developer tiêu bao nhiêu". Đề bài hỏi cách thu thập thông tin phân bổ chi phí, không hỏi cách được báo động. Không thể dựng một billing alarm kích hoạt theo chi phí của từng developer để giải bài toán bóc tách này.

E — Analyze the API usage with AWS CloudTrail. CloudTrail ghi lại lời gọi API: ai gọi, gọi gì, lúc nào. Nghe rất gần với "ai tạo ra resource", nên dễ bị chọn nhầm. Nhưng CloudTrail chỉ có dữ liệu hoạt động, không có dữ liệu tiền: nó không biết một EC2 instance chạy bao lâu tốn bao nhiêu, không cộng dồn được thành hoá đơn theo người. Dữ liệu API usage không dùng để báo cáo chi phí phát sinh theo từng developer.

📌 Điểm cần nhớ

• Muốn bóc tách chi phí bên trong một tài khoản AWS duy nhất thì con đường là cost allocation tag; tag createdBy do AWS tự sinh chính là nhãn theo người tạo resource.
• Cost allocation tag (kể cả AWS generated tag) phải được kích hoạt trong Billing and Cost Management console mới có tác dụng phân bổ chi phí — không bật thì không có dữ liệu để lọc.
• Phân biệt vai trò rõ ràng: Cost Explorer = phân tích và báo cáo chi phí; AWS Budgets = đặt ngưỡng và cảnh báo; AWS Config = tuân thủ cấu hình; CloudTrail = audit lời gọi API. Chỉ có nhóm đầu trả lời được câu hỏi "tốn bao nhiêu, cho ai".
• Với dạng câu "Select TWO" về chi phí, mẫu hay gặp là một phương án gắn nhãn dữ liệu cộng một phương án đọc dữ liệu — thấy hai mảnh bổ trợ nhau như vậy thì thường là cặp đáp án.