Ngân hàng đề — AWS Certified Cloud Practitioner

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

Đề hỏi: dịch vụ AWS nào giúp điều phối (coordinate) các thành phần của ứng dụng phân tán thành một chuỗi các bước trong một visual workflow.

Có hai cụm từ quyết định, và phải đọc cả hai mới loại được nhiễu:

• "coordinate the components ... as a series of steps" — đây là bài toán orchestration: có trạng thái, có thứ tự bước, bước này xong mới tới bước kia. Cụm này đã loại được nhóm dịch vụ chỉ làm nhiệm vụ gửi tin (messaging) chứ không điều phối luồng.
• "visual workflow" — cụm phân biệt thật sự. Trong danh sách có tới hai dịch vụ đều làm orchestration cho ứng dụng phân tán (Step Functions và SWF), nên nếu chỉ bám vào "coordinate ... steps" thì cả hai đều nghe hợp lý. Chính chữ visual mới tách được chúng: đề đang hỏi dịch vụ mô tả luồng dưới dạng sơ đồ trạng thái nhìn thấy được, không phải dịch vụ mà logic luồng nằm trong code do lập trình viên tự viết.

Đây là câu chọn một đáp án.

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

Đáp án đúng theo tệp là C — AWS Step Functions.

Step Functions cho phép ghép nhiều dịch vụ AWS lại thành các serverless workflow: bạn khai báo luồng dưới dạng một máy trạng thái (state machine) gồm các bước nối tiếp nhau, có nhánh rẽ, có xử lý lỗi và retry. Điểm khớp trực tiếp với đề là Step Functions dựng được visual workflow — luồng hiện ra dưới dạng sơ đồ, nên yêu cầu nghiệp vụ dịch sang yêu cầu kỹ thuật rất nhanh, và khi chạy thì nhìn được bước nào đang chạy, bước nào hỏng.

Ba từ khóa trong đề — coordinate, series of steps, visual workflow — khớp gần như nguyên văn với mô tả chính thức của Step Functions. Ở mức Cloud Practitioner, đây là kiểu câu nhận diện dịch vụ theo mô tả, và cụm "visual workflow" gần như là chữ ký riêng của Step Functions.

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

A — Amazon SNS. Đây là dịch vụ nhắn tin pub/sub được quản lý hoàn toàn: một message được publish vào topic rồi phát tới nhiều subscriber. SNS có mặt trong nhiều kiến trúc phân tán, nhưng nó chỉ chuyển tin, hoàn toàn không giữ trạng thái luồng, không biết bước nào đứng trước bước nào, và không có sơ đồ workflow. Nó là thành phần bên trong một kiến trúc, không phải thứ điều phối kiến trúc đó.

B — Amazon SES. Lệch chủ đề rõ nhất. SES là dịch vụ gửi email trên nền cloud, dùng cho email marketing, email thông báo và email giao dịch. Không liên quan gì tới điều phối các bước xử lý. Nếu bạn phân vân giữa SNS và SES thì hãy nhớ: SES gửi email, SNS gửi message/notification — nhưng cả hai đều không phải orchestration.

D — Amazon SWF. Đây là phương án gần đúng nhất và là bẫy thật sự của câu này. SWF (Simple Workflow Service) đúng là dịch vụ workflow: nó giúp lập trình viên xây dựng, chạy và mở rộng các tác vụ nền có các bước song song hoặc tuần tự. Nghĩa là vế "coordinate ... as a series of steps" thì SWF thỏa. Chỗ nó hỏng là vế còn lại: SWF không phải công cụ workflow dạng trực quan — logic điều phối nằm trong code do bạn viết (decider/worker), không phải sơ đồ khai báo nhìn thấy được. Đề đã cài sẵn chữ visual để loại chính phương án này, nên bỏ qua chữ đó là chọn nhầm D.

📌 Điểm cần nhớ

• "Visual workflow" + "coordinate components as a series of steps" → AWS Step Functions. Đây là cụm nhận diện gần như cố định trong đề thi.
• Step Functions và SWF là cặp bẫy kinh điển. Cả hai đều là workflow orchestration; phân biệt bằng cách trình bày luồng: Step Functions khai báo state machine và có sơ đồ trực quan, SWF thì luồng nằm trong code người dùng viết.
• Đừng nhầm messaging với orchestration. SNS chuyển message theo mô hình pub/sub — nó là thành phần trong luồng, không phải thứ điều khiển luồng.
• Loại nhanh phương án lệch chủ đề trước. SES là dịch vụ gửi email; thấy đề nói về điều phối bước xử lý thì gạch ngay, rồi tập trung sức so sánh hai phương án còn lại thực sự cạnh tranh nhau.

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

Đề hỏi: phát biểu nào về mô hình giá pay-as-you-go của AWS là đúng?

Cụm từ quyết định nằm ngay ở tên mô hình: "pay-as-you-go" — trả tiền theo mức đã dùng thực tế, tính theo tháng. Khi đọc bốn phương án, phải soi chúng qua đúng nghĩa đó cùng với cặp khái niệm tài chính kinh điển của AWS:

• Capital expenditure (CapEx) — chi phí đầu tư tài sản: mua máy chủ, thiết bị mạng, xây data center. Bỏ tiền lớn ngay từ đầu, trước khi biết mình có dùng hết công suất hay không.
• Operational expenditure (OpEx) — chi phí vận hành: hoá đơn định kỳ theo mức tiêu thụ.

Pay-as-you-go chuyển chi phí từ CapEx sang OpEx. Đây chính là cái bẫy của câu hỏi: hai phương án B và C nói gần y hệt nhau, chỉ khác một chữ (operational vs capital), và chỉ một trong hai đúng chiều dịch chuyển.

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

C — "It results in reduced capital expenditures".

Với pay-as-you-go, bạn chỉ trả cho compute, storage và outbound data transfer mà bạn thực sự tiêu thụ. Không phải mua trước máy chủ, không phải đầu tư vào data center, không phải ước lượng công suất cho ba năm tới rồi bỏ tiền ra mua trọn gói. Toàn bộ khoản đầu tư tài sản ban đầu đó biến mất — nên capital expenditure giảm.

Đổi lại, bạn nhận một hoá đơn hằng tháng theo mức đã dùng. Khoản này thuộc operational expenditure. Vậy nên phát biểu đúng và duy nhất đúng ở đây là: pay-as-you-go làm giảm CapEx, chứ không phải giảm OpEx.

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

A — "It requires payment up front for AWS services"

Sai vì trả tiền trước là điều pay-as-you-go không đòi hỏi — bản chất của nó là trả sau theo mức tiêu thụ. Đây là phương án gần đúng theo kiểu "có phần sự thật": AWS có những lựa chọn trả trước để được giá tốt hơn, ví dụ EC2 Reserved Instances với các mức all upfront / partial upfront. Nhưng đó là tuỳ chọn của một mô hình giá khác dành cho ai cam kết dùng lâu dài, không phải yêu cầu của pay-as-you-go. Chữ hỏng ở đây là "requires" — biến một lựa chọn thành điều kiện bắt buộc.

B — "It reduces operational expenditures"

Đây là phương án nguy hiểm nhất, sai đúng một chữ so với đáp án. Pay-as-you-go không giảm OpEx — nó chính là OpEx. Hoá đơn AWS hằng tháng nằm ở cột chi phí vận hành. Cái được giảm là khoản đầu tư tài sản ở đầu vào. Nói cách khác, mô hình này dịch chuyển chi phí từ CapEx sang OpEx; ai nhớ nhầm chiều dịch chuyển sẽ chọn B.

D — "It is relevant only for Amazon EC2, Amazon S3, and Amazon DynamoDB"

Sai vì chữ "only". Ba dịch vụ được nêu đều thực sự tính tiền theo mức sử dụng, nên phương án đọc lên rất thuận tai — nhưng pay-as-you-go là nguyên tắc định giá áp dụng cho hầu hết các dịch vụ AWS, không phải đặc quyền của một nhóm nhỏ. Một danh sách khép kín kiểu này gần như luôn là bẫy trong đề thi.

📌 Điểm cần nhớ

• Pay-as-you-go = giảm CapEx, chuyển sang OpEx. Nhớ đúng chiều mũi tên này là giải được cả nhóm câu hỏi về AWS Cost Management. Cloud không xoá chi phí, nó đổi loại chi phí.
• CapEx là tiền mua tài sản trước khi dùng (máy chủ, data center); OpEx là hoá đơn định kỳ theo mức tiêu thụ. Hoá đơn AWS hằng tháng luôn thuộc vế thứ hai.
• Khi hai phương án chỉ khác nhau một tính từ (capital vs operational), đề đang kiểm tra định nghĩa chứ không kiểm tra hiểu biết chung — đọc kỹ đúng chữ đó rồi mới chọn.
• Cảnh giác với các chữ tuyệt đối: "requires", "only". Trả trước với Reserved Instances là tuỳ chọn, không bắt buộc; và pay-as-you-go áp dụng rộng rãi chứ không giới hạn ở EC2, S3, DynamoDB.

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

Đề hỏi: mô hình định giá (pricing model) nào của Amazon EC2 sẽ làm gián đoạn một instance đang chạy khi năng lực tính toán (capacity) tạm thời không còn khả dụng.

Cụm từ quyết định nằm ở vế sau: "will interrupt a running instance if capacity becomes temporarily unavailable". Cả bốn phương án đều là những mô hình giá hợp lệ của EC2, đều chạy được cùng một loại instance, cùng một AMI — nên câu hỏi không hỏi về giá rẻ hay đắt, cũng không hỏi về cam kết thời hạn. Nó hỏi đúng một tính chất duy nhất: mô hình nào cho phép AWS lấy lại capacity và tắt máy của bạn giữa chừng.

Chỉ có một mô hình được thiết kế với đúng đặc tính đó, vì bản chất của nó là dùng phần capacity đang dư thừa trong AWS chứ không phải capacity được cấp riêng cho bạn.

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

B — Spot Instances.

Spot Instances cho phép bạn tận dụng phần EC2 capacity chưa dùng đến trong AWS Cloud, đổi lại là mức giá thấp hơn nhiều so với On-Demand (mức chiết khấu có thể rất sâu). Cái giá phải trả cho khoản chiết khấu đó chính là điều đề bài mô tả: khi AWS cần lấy lại phần capacity ấy — vì nhu cầu tăng lên hoặc giá Spot vượt ngưỡng — instance của bạn bị thu hồi. AWS phát tín hiệu cảnh báo trước một khoảng rất ngắn (thường được nhắc tới là hai phút) rồi tắt instance.

Đây là hành vi thiết kế sẵn, không phải sự cố. Vì vậy Spot phù hợp với workload chịu được gián đoạn: xử lý theo lô (batch), CI/CD, render, phân tích dữ liệu có checkpoint — những việc mất một node thì chạy lại được. Với các mô hình còn lại, một khi instance đã chạy thì AWS không chủ động chấm dứt nó vì lý do capacity.

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

A — Convertible Reserved Instances. Đây là cam kết sử dụng dài hạn để đổi lấy chiết khấu, điểm đặc biệt là bạn được đổi sang họ instance / OS / tenancy khác trong thời hạn cam kết. Chữ "Convertible" khiến nhiều người liên tưởng tới "có thể bị thay đổi" — nhưng cái thay đổi được ở đây là cấu hình bạn tự chọn đổi, không phải AWS tự ý dừng máy bạn. Không có cơ chế thu hồi vì thiếu capacity.

C — Standard Reserved Instances. Cũng là cam kết dài hạn, chiết khấu sâu hơn Convertible nhưng kém linh hoạt hơn (phạm vi thay đổi hẹp). Reserved Instance thiên về billing discount áp lên instance đang chạy; nó không hề đặt instance của bạn vào diện có thể bị ngắt. Đây là phương án "gần đúng" nhất theo kiểu bẫy từ ngữ vì nó nằm cùng nhóm cam kết với A, nhưng cả hai đều sai vì cùng một lý do: không có khái niệm bị interrupt.

D — On-Demand Instances. Trả tiền theo lượng dùng, không cam kết, bật lúc nào cũng được. Điểm cần phân biệt: On-Demand có thể thất bại lúc khởi chạy nếu vùng đó tạm hết capacity (InsufficientInstanceCapacity) — nhưng đó là chuyện không launch được, hoàn toàn khác với đề bài đang nói: instance đang chạy bị ngắt. Một khi On-Demand đã lên, AWS không thu hồi nó để nhường capacity cho ai khác. Nhầm hai tình huống này là cái bẫy chính của phương án D.

📌 Điểm cần nhớ

• Trong bốn mô hình giá EC2, chỉ Spot Instances mới có thể bị AWS chấm dứt giữa chừng vì lý do capacity — đây là dấu hiệu nhận diện gần như tuyệt đối trong đề thi.
• Từ khoá cần bắt trong đề: interrupt / interruption / reclaim capacity / terminated by AWS → Spot. Từ khoá commitment, 1–3 năm, discount → Reserved. Từ khoá no commitment, pay as you go → On-Demand.
• "Convertible" nói về quyền đổi cấu hình của bạn, không nói về việc AWS đổi ý — đừng để chữ này kéo sang nghĩa "không ổn định".
• Phân biệt rõ "không launch được vì hết capacity" (có thể xảy ra với On-Demand) và "đang chạy thì bị ngắt" (đặc trưng của Spot). Đề nhấn chữ running là để loại On-Demand.

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

Đề hỏi rất ngắn: "What do you need to log into the AWS console?" — cần thứ gì để đăng nhập vào AWS Management Console.

Cụm từ quyết định đáp án là "log into the AWS console". Đây chính là ràng buộc phân biệt bốn phương án, bởi vì cả bốn thứ được liệt kê (certificate, key pair, user name + password, access key + secret) đều là những loại "thông tin xác thực" có thật trong hệ sinh thái AWS — nhưng mỗi loại phục vụ một kênh truy cập khác nhau. Chỉ khi bám vào chữ console (giao diện web mà con người mở bằng trình duyệt) thì mới loại được ba phương án còn lại.

Nói cách khác, câu này kiểm tra xem bạn có phân biệt được hai nhóm credentials hay không:

• Console credentials — dành cho người, đăng nhập bằng trình duyệt.
• Programmatic credentials — dành cho máy/công cụ, dùng cho API, CLI, SDK.

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

Đáp án đúng theo tệp là C — User name and password.

AWS Management Console là một ứng dụng web, và cách đăng nhập vào nó là nhập user name và password: hoặc là tài khoản root (đăng nhập bằng email + password), hoặc là một IAM user (đăng nhập bằng account ID/alias + user name + password). Password dành cho console trong IAM còn được gọi riêng là console password, tách bạch hẳn với các loại credentials khác gắn trên cùng một user.

Đúng như phần giải thích gốc nêu: bạn không thể đăng nhập AWS Console bằng key pair, bằng access key + secret, hay bằng certificate. Chúng thuộc các kênh truy cập khác, sẽ phân tích ngay dưới đây.

(Lưu ý cho kỳ thi: MFA có thể được bật thêm như một lớp xác thực bổ sung, nhưng nó là thứ cộng thêm vào user name + password chứ không thay thế chúng — và MFA cũng không nằm trong danh sách phương án.)

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

A — Certificate. Certificate trong AWS gắn với các tình huống như xác thực bằng chứng chỉ X.509 cho một số giao diện lập trình cũ, hoặc chứng chỉ TLS/SSL để mã hoá lưu lượng cho website và load balancer. Không có luồng nào cho phép người dùng "trình chứng chỉ" ra để mở AWS Management Console trong trình duyệt. Đây là phương án dễ loại nhất vì nó nhầm lẫn giữa bảo mật đường truyền và danh tính người đăng nhập.

B — Key pair. Đây là phương án gây nhầm nhiều nhất vì chữ "đăng nhập" xuất hiện ở cả hai chỗ. Nhưng key pair (public key/private key .pem) là để đăng nhập vào EC2 instance — tức là vào hệ điều hành bên trong máy ảo qua SSH (Linux) hoặc để giải mã password quản trị (Windows). Nó xác thực bạn với instance, không xác thực bạn với AWS. Bạn có thể có key pair mà không hề có tài khoản để mở console, và ngược lại. Hỏng ở chỗ: nhầm lẫn tầng — bên trong máy ảo so với tầng quản lý tài khoản AWS.

D — Access key and secret ID. Đây là phương án "gần đúng" nhất và cũng là bẫy chính của câu hỏi. Access key ID cùng secret access key đúng là credentials của một IAM user thật, đúng là dùng để gọi AWS — nhưng chỉ theo đường programmatic access: AWS CLI, SDK, hoặc gọi trực tiếp API. Chúng được dùng để ký request theo cơ chế chữ ký của AWS, chứ màn hình đăng nhập console không có ô nào để dán chúng vào. Một IAM user hoàn toàn có thể chỉ có access key mà không có console password — khi đó user đó dùng được CLI nhưng không mở được console. Chính khả năng tách rời này chứng minh hai loại credentials là khác nhau.

📌 Điểm cần nhớ

• Phân đôi credentials của AWS: user name + password → console (dành cho người); access key ID + secret access key → CLI/SDK/API (dành cho chương trình). Gặp câu hỏi về credentials, việc đầu tiên là xác định đề đang nói tới kênh truy cập nào.
• Key pair thuộc về EC2, không thuộc về IAM. Nó mở cửa vào hệ điều hành bên trong instance (SSH / lấy password Windows), không mở cửa vào tài khoản AWS.
• Certificate là chuyện mã hoá đường truyền và xác thực dịch vụ, không phải cách con người đăng nhập giao diện quản trị.
• Một IAM user có thể được cấp chỉ console password, chỉ access key, hoặc cả hai — hai loại này bật/tắt độc lập nhau, nên đừng suy ra cái này từ cái kia. MFA nếu có thì là lớp bổ sung phía trên password, không thay thế password.

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

Đề mô tả một Cloud Practitioner đang xây dựng business process workflows cho hệ thống xử lý đơn hàng (order fulfilment), và hỏi dịch vụ AWS nào giúp "coordinating tasks across distributed application components".

Cụm từ quyết định là "coordinating tasks" — điều phối các tác vụ theo một quy trình có nhiều bước, có thứ tự, có trạng thái. Đây chính là ngôn ngữ AWS dùng để mô tả Amazon SWF. Cụm thứ hai củng cố thêm là "business process workflows": bài toán không phải gửi một thông điệp rồi thôi, mà là chạy hết một quy trình nghiệp vụ nhiều công đoạn (nhận đơn → thanh toán → soạn hàng → giao hàng), trong đó mỗi công đoạn phải biết công đoạn trước đã xong hay chưa.

Nếu đề chỉ nói "decouple hai thành phần" hoặc "gửi thông báo cho nhiều bên nhận" thì đáp án đã khác. Chính chữ coordinate/workflow loại bỏ các dịch vụ messaging thuần tuý.

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

C — Amazon SWF (Amazon Simple Workflow Service) là dịch vụ được AWS mô tả đúng bằng câu chữ trong đề: nó giúp coordinate work across distributed application components. SWF cho phép mô hình hoá một quy trình thành tập hợp các task, theo dõi trạng thái từng task, đảm bảo task được giao đúng nơi và không bị thực hiện trùng, đồng thời giữ lịch sử thực thi của cả workflow.

Các nhóm bài toán mà AWS nêu cho SWF gồm media processing, web application back-end, business process workflow và analytics pipeline — order fulfilment rơi đúng vào nhóm business process workflow. Với SWF, logic điều phối (thứ tự bước, xử lý bước lỗi, chờ bước thủ công do con người làm) nằm ở tầng dịch vụ, thay vì phải tự viết bằng tay trong ứng dụng.

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

A — Amazon SQS: đây là phương án gần đúng nhất và dễ nhầm nhất. SQS là message queue, dùng để decouple các thành phần ứng dụng: bên gửi bỏ message vào hàng đợi, bên nhận lấy ra xử lý. Nó giải quyết chuyện truyền việc, nhưng bản thân hàng đợi không biết quy trình có bao nhiêu bước, bước nào chạy trước bước nào, bước nào đã hoàn tất. Muốn có workflow từ SQS thì bạn phải tự viết toàn bộ phần điều phối và theo dõi trạng thái. Đề hỏi dịch vụ assist with coordinating tasks, chứ không hỏi dịch vụ truyền message — nên SQS hỏng ở chỗ thiếu hẳn tầng điều phối.

B — AWS STS: AWS Security Token Service thuộc mảng bảo mật/danh tính, dùng để cấp temporary credentials (thông tin đăng nhập tạm thời) cho người dùng hoặc dịch vụ. Nó không liên quan gì tới workflow hay xử lý đơn hàng. Đây là phương án gây nhiễu dễ loại nhất — nhận ra nó nằm ở nhóm security là loại được ngay.

D — Amazon SNS: Simple Notification Service là dịch vụ notification/pub-sub: một message được đẩy ra topic rồi phát tới nhiều subscriber qua HTTP/HTTPS, Email, SQS, SMS… SNS mạnh ở chỗ phát tán thông tin cho nhiều bên cùng lúc, nhưng cũng như SQS, nó là dịch vụ messaging chứ không phải dịch vụ điều phối: SNS không giữ trạng thái quy trình, không đảm bảo thứ tự các bước nghiệp vụ, không biết task nào còn dở. Nó có thể nằm trong một hệ thống order fulfilment (ví dụ báo cho khách rằng đơn đã giao), nhưng không phải thứ đứng ra coordinate cả workflow.

📌 Điểm cần nhớ

• Nhìn động từ trong đề để chọn nhóm dịch vụ: coordinate / orchestrate / workflow / multi-step business process → SWF; decouple / buffer / queue → SQS; notify / publish / fan-out tới nhiều subscriber → SNS.
• SQS và SNS là messaging, chúng chuyển thông điệp nhưng không giữ trạng thái của cả quy trình. Workflow cần một dịch vụ biết "đang ở bước mấy" — đó là điểm khác biệt cốt lõi so với SWF.
• Tên viết tắt gần giống nhau (SQS, SNS, SWF, STS) là chiêu gây nhiễu quen thuộc ở đề Cloud Practitioner. Hãy bung đủ tên: Simple Queue, Simple Notification, Simple Workflow, Security Token — bung ra là gần như tự lộ đáp án.
• STS luôn thuộc mảng security/identity (temporary credentials). Thấy nó trong đề về xử lý dữ liệu hay quy trình nghiệp vụ thì gần như chắc chắn là phương án nhiễu.

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

Đề hỏi: tính năng nào của Amazon S3 cho phép tạo rules để điều khiển việc chuyển objects giữa các storage class khác nhau.

Cụm từ quyết định đáp án nằm gọn trong hai mảnh:

• "create rules" — đây phải là một tính năng cấu hình được bằng tập luật, chạy tự động theo điều kiện, chứ không phải một thao tác thủ công hay một cơ chế bảo vệ dữ liệu.
• "transfer of objects between different storage classes" — việc cần làm là di chuyển object sang storage class khác (ví dụ từ S3 Standard sang S3 Standard-IA, hoặc archive sang S3 Glacier), chứ không phải kiểm soát ai được truy cập object, cũng không phải giữ nhiều bản của object.

Ghép hai mảnh lại: cần một tính năng vừa mang hình thức "tập luật khai báo", vừa có hành động là "đổi storage class". Trong bốn phương án, chỉ có một cái thoả cả hai.

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

Đáp án đúng theo tệp là D — Lifecycle management.

S3 Lifecycle configuration đúng nghĩa là một tập rules định nghĩa các hành động mà Amazon S3 tự áp lên một nhóm object. Có hai loại hành động:

• Transition actions — quy định khi nào object chuyển sang storage class khác. Ví dụ: chuyển object sang S3 Standard-IA sau một khoảng thời gian kể từ lúc tạo, hoặc archive sang S3 Glacier sau một khoảng dài hơn.
• Expiration actions — quy định khi nào object hết hạn; S3 sẽ tự xoá object hết hạn thay cho bạn.

Vế transition actions chính là thứ đề bài mô tả nguyên văn: "rules to control the transfer of objects between different storage classes". Mục đích của cả tính năng là để dữ liệu được lưu tiết kiệm chi phí xuyên suốt vòng đời của nó — dữ liệu mới truy cập nhiều thì để ở class đắt-nhanh, dữ liệu nguội dần thì tự động rơi xuống class rẻ hơn, mà không cần ai đụng tay.

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

A — Bucket policies. Đây là resource-based policy viết bằng JSON gắn vào bucket, dùng để kiểm soát quyền truy cập vào bucket và object bên trong: ai được GetObject, PutObject, từ IP nào, có bắt buộc HTTPS không… Phương án này nghe gần đúng vì nó cũng là "rules" viết ra rồi gắn vào bucket, đúng một nửa yêu cầu của đề. Nhưng nó hỏng ở nửa còn lại: bucket policy chỉ trả lời câu hỏi "cho phép hay từ chối hành động này", không có khả năng ra lệnh cho S3 di chuyển dữ liệu sang storage class khác. Đây là kiểm soát access, không phải kiểm soát vị trí lưu trữ.

B — Versioning. Bật versioning thì S3 tự giữ nhiều phiên bản của cùng một object, nên khi ghi đè hay xoá nhầm vẫn khôi phục lại được. Đây cũng là một cấu hình bật ở cấp bucket, nhưng nó thuộc nhóm bảo vệ dữ liệu, giải quyết vấn đề "mất/hỏng dữ liệu do thao tác nhầm", chứ không sinh ra bất kỳ luật chuyển storage class nào. Lưu ý dễ nhầm: versioning và lifecycle phối hợp được với nhau (lifecycle rule có thể áp riêng cho các phiên bản cũ), nhưng phần tạo luật và chuyển class vẫn là việc của lifecycle — versioning chỉ tạo ra các phiên bản để lifecycle làm việc lên đó.

C — Object sharing. Chỉ nói tới khả năng làm cho một object truy cập được công khai qua URL, tức là chuyện chia sẻ và phân phối nội dung ra ngoài. Nó không phải một tập rules, không có yếu tố thời gian, và tuyệt đối không liên quan tới storage class. Đây là phương án xa đề nhất trong bốn cái.

📌 Điểm cần nhớ

• Thấy đề S3 có các chữ "rules", "automatically", "transition", "archive", "expire/delete after N days", "cost effectively over time" → gần như chắc chắn đáp án là S3 Lifecycle.
• Lifecycle có hai loại action: transition (đổi storage class) và expiration (xoá object). Đề hỏi cái nào trong hai cái đó thì vẫn cùng một tính năng.
• Phân biệt bằng mục đích, không phải bằng hình thức: Bucket policies = kiểm soát truy cập; Versioning = giữ nhiều phiên bản để chống mất dữ liệu; Object sharing = cho truy cập qua URL công khai; Lifecycle = quản lý vòng đời và chi phí lưu trữ.
• Cạm bẫy hay gặp: bucket policy cũng là "rules", nhưng rules ở đó phán quyết allow/deny một hành động, còn rules của lifecycle ra lệnh cho S3 tự làm một việc với dữ liệu theo thời gian.

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

Đề hỏi: "Which of the following are examples of horizontal scaling? (Select TWO.)" — đâu là ví dụ của horizontal scaling.

Cụm từ quyết định là "horizontal scaling", và điều làm câu này khó là năm phương án được cố tình trộn hai nhóm: hai phương án mô tả horizontal scaling, ba phương án còn lại đều là đặc điểm của vertical scaling. Nếu chỉ đọc lướt, ba phương án kia nghe vẫn rất "scaling" — vẫn là mở rộng năng lực xử lý — nên chúng không sai vì vô lý, chúng sai vì sai chiều.

Ranh giới cần nắm rất gọn:

• Horizontal scaling (scale out/in): thêm hoặc bớt số lượng instance trong một fleet.
• Vertical scaling (scale up/down): thêm CPU/RAM/storage cho chính một instance đang có, thường phải đổi instance type.

Cụm (Select TWO) cũng là một tín hiệu: đề đã nói trước rằng chỉ có đúng hai phương án thuộc nhóm horizontal.

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

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

B — "Add more instances as demand increases": đây chính là định nghĩa nguyên bản của horizontal scaling. Khi tải tăng, ta không đụng gì tới instance đang chạy mà đưa thêm instance vào fleet để chia việc; tải giảm thì rút bớt. Đây là mô tả trực tiếp nhất của khái niệm mà đề hỏi.

D — "Automatic scaling using services such as AWS Auto Scaling": AWS Auto Scaling thực hiện đúng hành vi ở B, chỉ khác là tự động. Nó theo dõi các metric hiệu năng từ CloudWatch rồi tự thêm/bớt instance theo nhu cầu thực tế. Nói cách khác, D là cách hiện thực hoá B trên AWS — cùng một chiều mở rộng, chỉ là do dịch vụ điều khiển thay vì con người bấm tay.

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

A — "Requires a restart to scale up or down": đây là đặc điểm của vertical scaling. Muốn thêm CPU/RAM cho một instance thì thường phải đổi instance type, và thao tác đó đòi khởi động lại instance. Horizontal scaling thì ngược lại: instance đang chạy không bị đụng tới, instance mới chỉ đơn giản được thêm vào, nên không có gián đoạn kiểu này. Chi tiết "restart" chính là dấu hiệu nhận diện vertical.

C — "Add more CPU/RAM to existing instances as demand increases": phương án gần đúng nhất và cũng là bẫy chính. Nó đúng ở chỗ đây thật sự là một cách mở rộng khi tải tăng, và nửa sau câu ("as demand increases") giống hệt phương án B. Chỗ hỏng nằm ở cụm "to existing instances" — làm to hơn cái đang có là vertical scaling, không phải horizontal. Chỉ cần đọc đúng danh từ đứng sau "add" là phân biệt được: add instances → horizontal; add CPU/RAM → vertical.

E — "Scalability is limited by maximum instance size": đây là hệ quả của vertical scaling chứ không phải một ví dụ về horizontal scaling. Khi mở rộng bằng cách phóng to một instance, sớm muộn cũng chạm trần vì instance type lớn nhất là hữu hạn. Horizontal scaling không gặp trần theo kiểu này vì cách mở rộng là thêm instance mới. Ngoài ra để ý về mặt hình thức: E mô tả một giới hạn, trong khi đề hỏi ví dụ — bản thân cách diễn đạt đã lệch với câu hỏi.

📌 Điểm cần nhớ

• Đọc danh từ đứng sau "add": thêm instances là horizontal scaling; thêm CPU/RAM/storage cho instance đang có là vertical scaling. Đây là dấu hiệu nhanh nhất tách hai nhóm.
• AWS Auto Scaling là công cụ của horizontal scaling: nó thêm/bớt instance dựa trên metric CloudWatch, chứ không phóng to instance sẵn có.
• Hai đặc điểm luôn đi kèm vertical scaling: cần restart khi đổi instance type, và bị chặn bởi kích thước instance lớn nhất. Thấy hai ý này trong phương án thì gần như chắc chắn đó là vertical.
• Phân biệt "ví dụ" với "hệ quả/hạn chế": đề hỏi ví dụ về một khái niệm thì phương án mô tả giới hạn hay ràng buộc thường là mồi nhử, kể cả khi nội dung của nó về mặt kỹ thuật không sai.

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

Đề hỏi: dịch vụ nào cho phép monitor và troubleshoot hệ thống bằng chính các file log do hệ thống và ứng dụng sinh ra.

Cụm từ quyết định là "system and application log files generated by those systems" — tức là log do chính máy chủ và ứng dụng của bạn ghi ra (log của hệ điều hành, log của web server, log ứng dụng), chứ không phải bản ghi hoạt động của tài khoản AWS. Cụm thứ hai là "log files" chứ không phải số liệu đo — nó loại ngay mọi phương án có chữ Metrics.

Bốn phương án là tích của hai trục: CloudWatch vs CloudTrail và Logs vs Metrics. Muốn chọn đúng phải trả lời hai câu hỏi tách bạch: log này của ai (ứng dụng của bạn → CloudWatch; hành động gọi API trong tài khoản AWS → CloudTrail), và dữ liệu ở dạng gì (dòng văn bản → Logs; con số theo thời gian → Metrics).

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

Đáp án đúng theo tệp là D — CloudWatch Logs.

Amazon CloudWatch Logs được thiết kế đúng cho việc mà đề mô tả: thu thập, lưu trữ và theo dõi log file có sẵn của hệ thống, của ứng dụng và log tuỳ chỉnh. Nó khớp cả hai vế của đề bài:

• Đúng nguồn dữ liệu: log do hệ thống và ứng dụng của bạn sinh ra được đẩy vào CloudWatch Logs, thay vì nằm rải rác trên từng instance.
• Đúng mục đích: dùng để giám sát ứng dụng và hệ thống gần thời gian thực, đồng thời giữ log lâu dài phục vụ tra cứu — tức là vừa monitor vừa troubleshoot như đề nêu.

Đây là điểm mấu chốt: khi câu hỏi nhắc tới "log file của hệ thống/ứng dụng", CloudWatch Logs là địa chỉ mặc định trong hệ sinh thái AWS.

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

A — CloudTrail Logs. Đây là phương án gây nhiễu mạnh nhất vì cũng có chữ "Logs". Nhưng CloudTrail ghi lại ai làm gì trong tài khoản AWS, bằng cách lưu các lời gọi API. Nó trả lời câu hỏi kiểu "user nào đã xoá bucket này lúc mấy giờ" — tức là phục vụ auditing, chứ không phải theo dõi vận hành hay hiệu năng của hệ thống. Log của CloudTrail không phải là log file do hệ điều hành hay ứng dụng của bạn sinh ra, nên trượt đúng ở cụm từ khoá trong đề.

B — CloudTrail Metrics. Sai kép. Thứ nhất, sai dịch vụ như phân tích ở phương án A. Thứ hai, CloudTrail không ghi metrics — nó ghi log các lời gọi API. "CloudTrail Metrics" không phải là thành phần có thật theo cách đề bài ngụ ý, đây là phương án bịa ra để làm đầy ma trận hai trục.

C — CloudWatch Metrics. Đúng dịch vụ nhưng sai dạng dữ liệu. Metrics là cách chuẩn để CloudWatch thu thập số liệu đo — các điểm dữ liệu dạng số theo thời gian như mức sử dụng CPU, số request. Chúng cho biết có gì đó bất thường, nhưng không chứa nội dung văn bản của log file. Đề hỏi rõ "log files", nên dù CloudWatch là họ dịch vụ đúng, thành phần này vẫn không phải câu trả lời.

📌 Điểm cần nhớ

• CloudWatch = giám sát vận hành, CloudTrail = kiểm toán hành động. Câu hỏi nói về hiệu năng, sức khoẻ hệ thống, log ứng dụng → CloudWatch. Câu hỏi nói về "ai đã làm gì", API call, tuân thủ → CloudTrail.
• Trong CloudWatch, phân biệt Logs và Metrics: Logs là nội dung văn bản do hệ thống/ứng dụng ghi ra; Metrics là điểm dữ liệu dạng số theo thời gian. Đề nhắc "log file" thì chọn Logs, nhắc "CPU utilization", "số liệu", "ngưỡng cảnh báo dạng số" thì nghiêng về Metrics.
• CloudTrail không sinh ra metrics — nếu một phương án ghép "CloudTrail" với "Metrics", gần như chắc chắn đó là phương án nhiễu.
• Với ma trận phương án kiểu {dịch vụ A, dịch vụ B} × {Logs, Metrics}, hãy tách thành hai quyết định độc lập rồi loại dần, thay vì so sánh bốn phương án cùng lúc.

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

Đề nêu một công ty muốn xây conversational chatbot có thể trao đổi qua lại với khách hàng thông qua natural language interface, và hỏi dịch vụ AWS nào phục vụ việc đó.

Cụm từ quyết định là "conversational chatbot ... interact dynamically ... natural language interface". Ba từ khoá này gộp lại mô tả một thứ rất cụ thể: một hệ thống nhận lượt nói/gõ của người dùng, hiểu ý định, giữ mạch hội thoại và trả lời lại. Đây không phải yêu cầu phân tích văn bản, không phải yêu cầu chuyển âm thanh thành chữ, cũng không phải yêu cầu bóc chữ từ tài liệu. Cả bốn phương án đều là dịch vụ AI/ML của AWS làm việc với ngôn ngữ hoặc văn bản, nên phải bám vào chỗ khác biệt: chỉ một dịch vụ trong danh sách tự nó dựng nên giao diện hội thoại, ba dịch vụ còn lại chỉ xử lý dữ liệu ngôn ngữ rồi trả kết quả về, không có khái niệm lượt hội thoại.

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

B — Amazon Lex là dịch vụ của AWS được thiết kế đúng cho việc xây conversational interface bằng cả giọng nói và văn bản. Đây chính là công nghệ nền tảng phía sau trợ lý ảo kiểu hội thoại của AWS: nó nhận đầu vào ngôn ngữ tự nhiên, xác định người dùng đang muốn gì, thu thập các thông tin còn thiếu qua các lượt hỏi lại, rồi kích hoạt logic xử lý phía sau và trả lời.

Đúng như phần giải thích gốc nêu: Lex dựa trên các khả năng deep learning để tạo ra chatbot giao tiếp với người dùng một cách tự nhiên. Nó là dịch vụ duy nhất trong bốn phương án đóng vai trò "bộ máy hội thoại" — phần còn thiếu mà đề bài đang cần. Ba phương án kia có thể xuất hiện quanh một chatbot nhưng không phải là chatbot.

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

• A — Amazon Comprehend: đây là dịch vụ NLP dùng để hiểu nội dung có sẵn trong văn bản — sentiment (tích cực/tiêu cực), ngôn ngữ, thực thể (entities), chủ đề. Đây là phương án dễ nhầm nhất, vì "hiểu ngôn ngữ tự nhiên" nghe rất giống yêu cầu của đề. Chỗ nó hỏng: Comprehend chỉ phân tích rồi trả kết quả về một đoạn văn bản, nó không quản lý lượt hội thoại, không hỏi lại người dùng, không sinh câu trả lời. Bạn có thể dùng nó để đo cảm xúc trong lời khách hàng, nhưng bản thân nó không tạo ra được cuộc trò chuyện.

• C — Amazon Transcribe: chuyển speech thành text. Nó gần đúng ở khía cạnh "voice", nên nếu chỉ đọc lướt thấy chữ "natural language" thì dễ chọn nhầm. Nhưng chức năng chính của nó là transcribe file/luồng âm thanh — kết quả nhận được là một đoạn chữ, đến đó là hết. Nó không hiểu ý định, không phản hồi lại. Trong một hệ thống thoại nó có thể đứng ở khâu đầu vào, nhưng dựng chatbot thì không phải việc của nó.

• D — Amazon Textract: trích xuất chữ và dữ liệu từ tài liệu quét (scanned documents), gồm cả bảng và các trường trong biểu mẫu. Phương án này lệch xa nhất so với đề: đầu vào của nó là hình ảnh tài liệu chứ không phải lời của người dùng, và mục tiêu là số hoá giấy tờ chứ không phải trò chuyện. Không liên quan tới việc dựng conversational interface.

📌 Điểm cần nhớ

• Thấy từ khoá chatbot / conversational interface / voice và text hội thoại trong đề AWS → nghĩ ngay tới Amazon Lex.
• Phân biệt theo đầu vào và đầu ra của từng dịch vụ AI ngôn ngữ: Comprehend = văn bản vào → thông tin phân tích ra; Transcribe = âm thanh vào → văn bản ra; Textract = ảnh tài liệu vào → chữ và dữ liệu có cấu trúc ra; Lex = lượt nói/gõ vào → phản hồi hội thoại ra.
• "Hiểu ngôn ngữ tự nhiên" không đồng nghĩa với "hội thoại". Comprehend hiểu văn bản nhưng không giữ được mạch trò chuyện — đây là cái bẫy quen thuộc của dạng câu này.
• Các dịch vụ này bổ trợ chứ không thay thế nhau: một chatbot thoại có thể có Transcribe ở khâu nghe, nhưng phần là chatbot vẫn thuộc về Lex.

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

Đề hỏi: mô hình định giá (pricing model) của AWS mang lại lợi ích gì cho tổ chức?

Cụm từ quyết định nằm ngay ở chỗ dễ bị đọc lướt: "AWS' pricing model" — tức là lợi ích phải đến từ cách AWS tính tiền, chứ không phải lợi ích chung chung của việc dùng cloud. Đây là ràng buộc phân biệt bốn phương án: cả bốn đều nghe như "điều tốt đẹp khi lên cloud", nhưng chỉ một cái là hệ quả trực tiếp của cách tính tiền.

Mô hình tính tiền của AWS là pay-as-you-go — trả theo lượng tài nguyên thực sự tiêu thụ, không trả trước cho công suất chưa dùng. Ghép nó với khả năng elastic (cấp phát và thu hồi tài nguyên theo nhu cầu), câu trả lời phải là phương án nói về tài nguyên nằm không (idle).

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

A — Reduce the cost of maintaining idle resources.

Trong mô hình on-premises, tổ chức phải mua phần cứng đủ cho đỉnh tải dự kiến, rồi trả tiền cho nó 24/7 kể cả những giờ hệ thống gần như không có ai dùng. Phần công suất thừa đó là idle resource — đã mua rồi thì tiền vẫn mất, dùng hay không dùng cũng vậy.

Với AWS, tổ chức chỉ provision đúng cái mình cần và điều chỉnh tài nguyên một cách tự động, co giãn theo tải. Vì tính tiền theo mức tiêu thụ thực tế, tắt hoặc thu nhỏ tài nguyên khi tải xuống thì hoá đơn giảm theo. Kết quả: lượng tài nguyên ngồi không giảm đi, và chi phí duy trì chúng cũng giảm theo. Đây đúng là lợi ích sinh ra từ chính mô hình định giá.

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

B — Reduces the people cost of application development. Nghe hợp lý, nhưng lẫn hai chuyện khác nhau. AWS lo phần hạ tầng bên dưới; ứng dụng vẫn phải do người của bạn viết ra. Số lập trình viên cần để xây dựng và bảo trì ứng dụng không phải là thứ mô hình định giá của AWS chạm tới. Chi phí nhân sự phát triển vẫn còn nguyên.

C — Eliminates licensing costs. Đây là phương án gần đúng nhất và cũng là bẫy nặng nhất — sai ở chữ "eliminates" (loại bỏ hoàn toàn). Bạn vẫn phải có license cho phần mềm mình chạy: hệ điều hành thương mại, cơ sở dữ liệu thương mại, phần mềm của hãng thứ ba. AWS chỉ đổi cách trả — có lựa chọn gộp license vào giá theo giờ thay vì mua đứt — chứ không làm chi phí license biến mất. Một phương án dùng từ tuyệt đối như "eliminates" mà thực tế chỉ là "có thể giảm hoặc trả theo cách khác" thì là sai.

D — Focus spend on capital expenditure, rather than operational expenditure. Phương án này đảo ngược đúng chiều dịch chuyển. Cloud đưa chi tiêu đi theo hướng ngược lại: bỏ bớt capital expenditure (mua sẵn máy chủ, thiết bị, đầu tư trả trước một cục) để chuyển sang operational expenditure (trả đều theo mức sử dụng). Nếu viết ngược lại — "focus on operational rather than capital" — thì đã là một đáp án đúng. Giữ nguyên như trong đề thì nó mô tả đúng mô hình on-premises chứ không phải AWS.

📌 Điểm cần nhớ

• Pay-as-you-go là hạt nhân của mô hình định giá AWS: chỉ trả cho cái thực sự dùng, nên tài nguyên idle không còn là khoản chi cố định — đây là câu trả lời mặc định cho dạng câu "pricing model benefit".
• Nhớ chắc chiều dịch chuyển: CapEx → OpEx. Đề rất hay đảo ngược cặp này để tạo bẫy; đọc kỹ từ "rather than" đứng ở đâu.
• Cảnh giác với các từ tuyệt đối như "eliminates", "removes all", "no longer need". AWS thường giảm hoặc đổi cách trả, hiếm khi loại bỏ hoàn toàn — đặc biệt là chi phí license.
• Phân biệt "lợi ích của mô hình định giá" với "lợi ích của cloud nói chung". Những thứ như nhân sự phát triển ứng dụng nằm ngoài phạm vi mà cách tính tiền của AWS ảnh hưởng tới.