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

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

Đề hỏi: loại credential nào được dùng để truy cập AWS resources theo kiểu programmatic từ AWS CLI/API.

Cụm từ quyết định đáp án là "programmatic access ... from the AWS CLI/API". Đây chính là ràng buộc tách bạch bốn phương án, vì AWS cố ý dùng các loại credential khác nhau cho các kênh truy cập khác nhau:

• Truy cập bằng con người qua AWS Management Console → user name và password (kèm MFA nếu bật).
• Truy cập bằng chương trình qua CLI, API, SDK → access keys.

Nếu đề chỉ nói "đăng nhập vào AWS" thì phương án D mới có cửa. Nhưng đề đã chốt kênh là CLI/API, nên mọi credential dành cho giao diện web hoặc dành cho giao thức khác đều bị loại. Ba phương án còn lại đều là những loại credential có thật trong hệ sinh thái AWS — cái bẫy nằm ở chỗ chúng phục vụ mục đích khác, không phải ở chỗ chúng vô nghĩa.

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

Đáp án đúng theo tệp là C — Access keys.

Access keys là long-term credentials gắn với một IAM user (hoặc với AWS account root user, dù AWS khuyến nghị không dùng root cho việc này). Chúng chính là thứ dùng để ký (sign) các request theo kiểu programmatic gửi tới AWS CLI hoặc AWS API — trực tiếp, hoặc gián tiếp qua AWS SDK.

Một access key gồm hai phần đi cùng nhau:

• Access key ID — phần định danh, dạng công khai, ví dụ AKIAIOSFODNN7EXAMPLE.
• Secret access key — phần bí mật, ví dụ wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY.

Cả hai phải dùng chung mới xác thực được request, đúng như cặp user name và password: có ID mà không có secret thì không ký được gì. Vì secret access key có sức mạnh tương đương mật khẩu, nó phải được bảo quản nghiêm ngặt như mật khẩu — đây là lý do AWS chỉ cho xem/tải secret một lần duy nhất lúc tạo.

Khi bạn chạy aws configure, thứ CLI hỏi bạn nhập chính là cặp key này. Đó là lời khẳng định trực tiếp nhất cho phương án C.

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

A. SSL/TLS certificate — Chứng chỉ SSL/TLS trong AWS tồn tại thật (ví dụ để bảo vệ kết nối HTTPS tới load balancer hay CloudFront), nhưng vai trò của nó là mã hoá kênh truyền và chứng minh danh tính của máy chủ với client, chứ không phải để một người dùng tự xác thực mình với AWS API. Nói cách khác: request CLI của bạn đi qua TLS, nhưng danh tính người gọi vẫn phải do access key ký mới xác định được. Đây là phương án dễ gạt nhất trong bốn cái.

B. SSH public keys — Cặp khoá SSH cũng rất quen mặt với người dùng AWS, nhưng nó dùng cho giao thức SSH, tức là để đăng nhập vào hệ điều hành bên trong một EC2 instance. Đây là phương án gần đúng theo kiểu dễ nhầm: cả SSH key lẫn access key đều là "credential không phải mật khẩu, dùng cho dòng lệnh". Chỗ hỏng của nó là nhầm tầng — SSH key xác thực bạn với máy chủ Linux, còn access key xác thực bạn với AWS control plane (các API như ec2:DescribeInstances, s3:ListBucket). Bạn có thể có SSH key mà không có quyền gọi bất kỳ API AWS nào, và ngược lại.

D. User name and password — Đây là phương án gần đúng nhất, và là cái thí sinh hay chọn nhầm. Cặp user name/password của một IAM user là credential hợp lệ và rất phổ biến, nhưng nó chỉ dùng được cho AWS Management Console — tức là kênh giao diện web dành cho con người ngồi bấm. AWS CLI và AWS API không chấp nhận cặp này để ký request. Chỗ hỏng: đúng loại credential, sai kênh truy cập — mà "kênh truy cập" lại chính là cụm từ đề bài nhấn mạnh.

📌 Điểm cần nhớ

• Ánh xạ cố định cần thuộc lòng: Console → user name + password; CLI / API / SDK → access keys. Đề nhắc tới từ nào trong hai nhóm này là đã chỉ thẳng đáp án.
• Access key luôn là một cặp: access key ID (định danh) + secret access key (bí mật). Thiếu một nửa thì không ký được request; secret phải giữ như mật khẩu.
• Phân biệt tầng xác thực: SSH key vào hệ điều hành của EC2 instance, access key vào AWS API. Hai thứ độc lập nhau, có cái này không suy ra cái kia.
• SSL/TLS certificate là chuyện của kênh truyền và danh tính máy chủ, không phải cách người dùng chứng minh danh tính với AWS. Thấy nó trong đề về "credential để gọi API" thì gần như luôn là mồi nhử.

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

Đề mô tả một ứng dụng web được triển khai trong đúng một AWS Region, nhưng người dùng thì rải khắp toàn cầu (users globally). Câu hỏi: dịch vụ nào giúp giảm độ trễ và tăng tốc độ truyền tải cho nhóm người dùng phân tán đó? (Chọn HAI.)

Cụm từ quyết định là "a single AWS Region ... users globally" kết hợp với "lowering latency and improving transfer speeds for the global users". Nó khoá lại hai điều kiện:

1. Ứng dụng không được nhân bản sang nhiều Region — nên lời giải phải là thứ đưa điểm tiếp nhận lưu lượng đến gần người dùng, chứ không phải đưa ứng dụng đến gần người dùng.
2. Người dùng là người dùng Internet công cộng, không xác định trước — nên mọi giải pháp cần đường kết nối riêng đã dựng sẵn tới một địa điểm cụ thể đều lệch đề.

Đúng hai tiêu chí này là mạng biên (edge locations) của AWS: dịch vụ dùng edge để phục vụ hoặc để nhận lưu lượng, rồi đi tiếp bằng AWS global network thay vì Internet công cộng.

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

C – Amazon CloudFront là CDN của AWS. Nó cache nội dung tại các edge location trên khắp thế giới, nên người dùng ở xa lấy nội dung từ điểm biên gần mình thay vì phải đi hết quãng đường tới Region gốc. Với nội dung động không cache được, request vẫn được nhận tại edge rồi chuyển về origin qua backbone của AWS — vẫn nhanh hơn đi thẳng qua Internet.

E – AWS Global Accelerator dùng chính hệ thống edge location đó, nhưng ở tầng khác: nó cấp điểm truy cập toàn cầu và định tuyến kết nối của người dùng vào mạng lưới AWS ngay tại điểm biên gần nhất, rồi đưa lưu lượng về ứng dụng qua AWS global network. Nhờ rút ngắn đoạn đi qua Internet công cộng, độ trễ giảm và thông lượng ổn định hơn — kể cả khi ứng dụng chỉ nằm ở một Region duy nhất.

Cả hai đều thoả đúng yêu cầu của đề: lowering latency và improving transfer speeds cho người dùng phân tán toàn cầu.

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

A – AWS Direct Connect. Đây là kết nối mạng riêng từ data center / văn phòng của bạn tới AWS, phải dựng vật lý tại một địa điểm cụ thể. Nó thật sự cải thiện độ trễ và băng thông — nhưng chỉ cho lưu lượng đi qua đúng đường đó. Người dùng toàn cầu vào ứng dụng qua Internet không hề "dùng ké" được Direct Connect của công ty. Đây là phương án gần đúng nhất về mặt từ khoá ("giảm latency, tăng băng thông"), nhưng hỏng ở chỗ sai đối tượng phục vụ: nó dành cho kết nối hybrid, không dành cho người dùng cuối phân tán.

B – AWS Snowcone. Thiết bị edge vật lý dùng để thu thập và vận chuyển dữ liệu ở nơi mạng kém hoặc không có mạng, mang tính chất truyền dữ liệu theo lô. Nó không nằm trên đường phục vụ request của một web application đang chạy, nên không liên quan tới độ trễ của người dùng truy cập web.

D – AWS Transit Gateway. Dùng để tổ chức topology mạng nội bộ: nối nhiều VPC với nhau và với mạng on-premises qua một trung tâm định tuyến, thay cho mạng lưới peering chằng chịt. Nó tối ưu kết nối bên trong hạ tầng của bạn, hoàn toàn không tác động tới đường đi từ trình duyệt của người dùng Internet tới ứng dụng.

📌 Điểm cần nhớ

• Thấy đề nêu "single Region" + "global users" và hỏi giảm latency → nghĩ ngay tới edge: CloudFront và Global Accelerator. Đây là cặp đáp án kinh điển của dạng câu này.
• Phân biệt hai dịch vụ đúng: CloudFront thiên về cache và phân phối nội dung (HTTP/HTTPS, web/media); Global Accelerator thiên về định tuyến kết nối vào AWS global network, hợp cả với giao thức không phải web. Cả hai cùng dùng chung hạ tầng edge location.
• Direct Connect là câu trả lời cho hybrid (data center ↔ AWS), không bao giờ là câu trả lời cho "người dùng Internet toàn cầu".
• Transit Gateway giải bài toán kết nối VPC / on-premises, còn Snowcone giải bài toán chuyển dữ liệu ở biên. Cả hai đều không nằm trên đường phục vụ request của người dùng cuối — gặp trong câu hỏi về latency cho end user thì loại thẳng.

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

Đề bài rất ngắn: một công ty triển khai ứng dụng trên AWS Cloud và hỏi "How can they secure the application?", chọn TWO.

Cụm từ quyết định nằm ở chính động từ "secure" kết hợp với "(Select TWO)". Đây là câu hỏi về nguyên tắc thực hành bảo mật tốt (security best practices) ở mức khái niệm, chứ không phải câu hỏi cấu hình dịch vụ cụ thể. Vì vậy cách chấm rất máy móc nhưng cũng rất dễ đoán: phương án nào làm tăng mức bảo vệ thì đúng, phương án nào làm giảm mức bảo vệ thì sai — kể cả khi nó được gói trong một lý do nghe có vẻ hợp lý.

Điểm cần để ý thêm: đề không nói ứng dụng có cần phục vụ người dùng Internet hay không, không nói cần giám sát (monitoring) gì. Mọi phương án tự thêm giả định "phải mở public", "phải tắt mã hoá để giám sát" đều là giả định do phương án tự bịa ra, không có trong đề.

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

Theo tệp, đáp án đúng là C và D.

C — Enable encryption for the application data at rest. Mã hoá dữ liệu lúc lưu trữ là lớp phòng thủ chuẩn: nếu ai đó tiếp cận được tầng lưu trữ bên dưới (bản snapshot, ổ đĩa, đối tượng trong bucket) mà không có quyền dùng khoá thì dữ liệu vẫn là chuỗi vô nghĩa. Đây là biện pháp thuần tuý cộng thêm — bật lên không làm mất chức năng nào của ứng dụng, nên trong một câu "chọn cách bảo mật ứng dụng" thì nó luôn là đáp án an toàn.

D — Limit access privileges according to the principle of least privilege. Nguyên tắc đặc quyền tối thiểu: mỗi người dùng, mỗi vai trò, mỗi thành phần chỉ được cấp đúng những quyền cần để làm việc của mình, không hơn. Giá trị của nó là giới hạn bán kính thiệt hại — một tài khoản bị lộ hay một đoạn mã bị lợi dụng cũng chỉ chạm tới được đúng phần tài nguyên nó vốn được phép chạm. Đây là nguyên tắc nền tảng của toàn bộ phần identity trên AWS và là cụm từ xuất hiện dày đặc trong đề thi.

Hai đáp án này còn ghép với nhau rất đẹp: một cái bảo vệ dữ liệu, một cái bảo vệ quyền truy cập — đúng hai trục chính khi nói "secure an application".

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

A — Provide full admin access to developer and operations staff. Đây chính là phản đề trực tiếp của phương án D. Cấp quyền quản trị toàn phần cho toàn bộ nhân sự phát triển và vận hành nghĩa là bất kỳ tài khoản nào trong nhóm đó bị chiếm cũng đồng nghĩa với việc kẻ tấn công nắm trọn môi trường. Lập luận "để anh em làm việc cho nhanh" là lý do tiện lợi, không phải lý do bảo mật. Khi trong cùng một câu hỏi xuất hiện cả "full admin access" lẫn "least privilege", gần như chắc chắn cái sau là đáp án và cái trước là mồi.

B — Configure public access for the AWS services used by the application. Đây là phương án gần đúng nhất trong ba phương án sai, nên cần nói rõ nó hỏng ở đâu. Thực tế có những trường hợp cần public access — ví dụ thành phần front end phải nhận được request từ Internet. Nhưng phương án viết là "the AWS services used by the application", tức là mở công khai cho mọi dịch vụ mà ứng dụng dùng, bao gồm cả những tầng phía sau vốn chỉ nên nói chuyện nội bộ. Mở public diện rộng như vậy là mở rộng bề mặt tấn công, tức là đi ngược lại yêu cầu "secure". Nguyên tắc đúng là chỉ phơi ra bên ngoài đúng thành phần bắt buộc phải phơi ra, phần còn lại giữ ở phạm vi riêng tư.

E — Enable monitoring by turning off encryption for data in transit. Phương án này dùng thủ thuật "gói một hành động xấu trong một mục tiêu tốt". Giám sát (monitoring) tự nó là việc nên làm, nhưng vế sau — tắt mã hoá dữ liệu trên đường truyền — là hành động làm giảm bảo mật, khiến dữ liệu đi qua mạng có thể bị nghe lén hoặc can thiệp. Quan trọng hơn: không hề có sự đánh đổi bắt buộc ở đây. Bật giám sát không đòi hỏi phải tắt mã hoá in transit; đây là một tiền đề giả do phương án dựng lên. Cả hai vế đều hỏng nên phương án này bị loại chắc chắn.

📌 Điểm cần nhớ

• Với câu hỏi khái niệm dạng "làm sao để secure", hãy chấm theo hướng đơn giản: phương án cộng thêm một lớp bảo vệ thì đúng; phương án gỡ bỏ một lớp bảo vệ, dù lý do nghe hợp lý đến đâu, thì sai.
• Least privilege là câu trả lời mặc định cho mọi câu hỏi về cấp quyền. Hễ thấy phương án đối lập kiểu "full admin access cho cả team" xuất hiện cùng, thì đó là cặp mồi–đáp án kinh điển.
• Mã hoá có hai mặt cần phân biệt: at rest (dữ liệu lúc lưu trữ) và in transit (dữ liệu lúc truyền). Đề thi thường bật cái này ở đáp án đúng và tắt cái kia ở đáp án sai — đọc kỹ xem phương án đang bật hay tắt.
• Cảnh giác với phương án ghép "mục tiêu tốt + hành động xấu" trong cùng một câu (bật monitoring bằng cách tắt encryption). Hãy tách đôi và chấm riêng từng vế; nếu vế hành động làm yếu hệ thống thì cả phương án sai.
• Public access không phải luôn xấu, nhưng phải giới hạn ở đúng thành phần cần tiếp xúc Internet. Phương án nói mở công khai cho toàn bộ dịch vụ thì luôn là phương án sai.

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

Đề mô tả một công ty muốn dùng Reserved Instances để được giá ưu đãi cho Amazon EC2, cam kết một năm, và hỏi lựa chọn mua nào là tiết kiệm chi phí nhất (MOST cost-effective) cho tình huống đó.

Cụm từ quyết định nằm ở câu thứ hai: "may need to change the EC2 instance type during the one year period" — trong thời hạn cam kết, công ty có thể phải đổi loại instance. Đây chính là ràng buộc phân biệt bốn phương án, vì cả bốn đều là Reserved Instances và đều rẻ hơn On-Demand; điểm khác nhau duy nhất đáng kể ở đây là có được đổi cấu hình instance giữa chừng hay không.

Cần chú ý rằng bốn phương án thực ra thuộc hai trục khác nhau của Reserved Instances:

• Trục offering class (hạng chào bán): Standard và Convertible — quy định bạn sửa đổi/trao đổi được tới đâu.
• Trục scope (phạm vi áp dụng): Regional và Zonal — quy định chiết khấu áp cho vùng hay cho một Availability Zone cụ thể, kèm việc có đặt chỗ dung lượng hay không.

Nhận ra đề đang hỏi về trục thứ nhất là đã loại được một nửa danh sách.

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

Đáp án đúng theo tệp là C — Convertible Reserved Instances.

Convertible RI cho phép bạn exchange (trao đổi) một hoặc nhiều Convertible RI đang có lấy Convertible RI khác có cấu hình khác: khác instance family, khác operating system, khác tenancy. Đây đúng là thứ đề bài cần — công ty giữ nguyên cam kết một năm để hưởng chiết khấu, nhưng vẫn xoay xở được khi nhu cầu buộc phải đổi sang loại instance khác.

Về mức chiết khấu, Convertible RI thường thấp hơn Standard RI vì bạn trả thêm cho tính linh hoạt. Nhưng "cost-effective" ở đây phải xét trên toàn bộ tình huống: nếu chọn hạng không đổi được cấu hình rồi giữa chừng phải đổi loại instance, phần cam kết cũ trở thành khoản trả cho thứ không dùng nữa, và tải mới lại chạy giá On-Demand. Với ràng buộc "có thể phải đổi instance type", Convertible là phương án tối ưu chi phí.

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

A — Zonal Reserved Instances. Đây là phạm vi chứ không phải hạng chào bán. Zonal RI áp chiết khấu cho instance chạy trong một Availability Zone cụ thể và có đặt chỗ dung lượng trong AZ đó. Nó không trả lời gì cho câu hỏi "đổi được instance type hay không" — một Zonal RI vẫn có thể là Standard hoặc Convertible. Chọn A là trả lời sai trục của câu hỏi.

B — Regional Reserved Instances. Cũng thuộc trục phạm vi: chiết khấu áp cho instance usage trong bất kỳ AZ nào của một Region đã chỉ định, linh hoạt hơn Zonal về vị trí nhưng không đặt chỗ dung lượng. Đây là phương án dễ nhầm nhất, vì chữ "linh hoạt" khiến người học tưởng nó bao luôn cả việc đổi loại instance. Chỗ hỏng: linh hoạt của Regional RI là linh hoạt về AZ, không phải linh hoạt về cấu hình instance. Đề không hề nói tới AZ hay Region.

D — Standard Reserved Instances. Đây mới đúng trục — Standard là hạng đối lập với Convertible — nên nó là phương án gần đúng nhất và cũng là bẫy chính. Hỏng ở chỗ: với Standard RI bạn không đổi được instance type, chỉ modify được trong phạm vi hẹp hơn như đổi size trong cùng instance family (với điều kiện phù hợp). Standard RI cho chiết khấu sâu hơn, nên nếu đề không có câu "may need to change the instance type" thì D sẽ là đáp án. Chính cụm từ đó lật ngược lựa chọn.

📌 Điểm cần nhớ

• Reserved Instances có hai trục độc lập: offering class (Standard ↔ Convertible) và scope (Regional ↔ Zonal). Đọc đề trước để biết nó hỏi trục nào, rồi mới so các phương án — chúng thường trộn lẫn cả hai trục trong cùng danh sách.
• Đổi instance family / OS / tenancy giữa kỳ hạn ⇒ Convertible RI. Standard RI chỉ cho những thay đổi hẹp hơn như đổi size trong cùng family, không đổi được sang loại instance khác.
• Regional vs Zonal là chuyện vị trí, không phải chuyện cấu hình: Regional áp cho mọi AZ trong Region, Zonal gắn với một AZ cụ thể và kèm đặt chỗ dung lượng.
• "MOST cost-effective" không đồng nghĩa với "chiết khấu sâu nhất": khi đề nêu khả năng thay đổi trong tương lai, hãy chọn phương án chịu được thay đổi đó, vì cam kết dùng sai mục đích mới là khoản lãng phí lớn nhất.

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

Đề hỏi: "Which AWS service provides a managed software version control system?" — dịch vụ AWS nào cung cấp hệ thống quản lý phiên bản mã nguồn được quản lý sẵn.

Cụm từ quyết định là "version control system" (hệ thống quản lý phiên bản), tức là nơi lưu trữ mã nguồn và theo dõi lịch sử thay đổi — đúng vai trò của một Git repository. Từ "managed" chỉ bổ sung rằng AWS lo phần hạ tầng, không phải bạn tự dựng máy chủ Git.

Đây là bẫy kinh điển của họ dịch vụ "Code*" trong AWS Developer Tools: bốn cái tên nghe rất giống nhau nhưng mỗi cái đứng ở một khâu khác nhau của vòng đời CI/CD. Chỉ cần bám vào khâu mà đề đang hỏi — lưu trữ mã nguồn, không phải build, không phải triển khai, không phải điều phối — là loại được ba phương án còn lại.

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

D. AWS CodeCommit là dịch vụ source control được quản lý hoàn toàn, host các Git repository bảo mật. Đây chính xác là "version control system" mà đề nhắc tới.

CodeCommit khiến bạn không cần tự vận hành máy chủ quản lý mã nguồn hay lo chuyện mở rộng hạ tầng cho nó. Bạn có thể dùng CodeCommit để lưu trữ an toàn mọi thứ từ mã nguồn tới file nhị phân, và nó hoạt động trơn tru với các công cụ Git sẵn có mà đội của bạn đang dùng — không phải học lệnh mới.

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

B. AWS CodePipeline — đây là phương án gần đúng nhất và dễ nhầm nhất, vì nó cũng thuộc nhóm Developer Tools và cũng "đụng" tới mã nguồn. Nhưng CodePipeline là dịch vụ continuous delivery: nó tự động hoá đường ống phát hành (release pipeline), nối các khâu source → build → deploy lại với nhau. Nó điều phối chứ không lưu trữ mã. Bằng chứng rõ nhất: CodeCommit thường được dùng làm một stage nguồn bên trong một pipeline của CodePipeline — cái chứa cái kia, nên chúng không thể là cùng một thứ.

C. Amazon CodeDeploy — cũng thuộc họ Code* nên rất dễ chọn nhầm. Nhưng CodeDeploy là dịch vụ triển khai: nó đưa ứng dụng của bạn lên hạ tầng đích. Nó đứng ở cuối vòng đời, khi mã đã được lưu và đã được build xong; nó không giữ lịch sử commit, không có khái niệm branch hay merge. (Ghi chú nhỏ: tên chuẩn của dịch vụ là AWS CodeDeploy, phương án ghi "Amazon" — bản thân tiền tố sai này cũng là một tín hiệu nhận dạng phương án nhiễu.)

A. AWS DataSync — lạc hẳn khỏi nhóm Developer Tools. DataSync dùng để sao chép và di chuyển dữ liệu giữa các hệ thống lưu trữ và AWS. Nó chuyển file, không quản lý phiên bản mã nguồn: không commit, không branch, không lịch sử thay đổi. Từ khoá "Sync" dễ gợi cảm giác "đồng bộ mã nguồn" nhưng đó là đồng bộ dữ liệu lưu trữ, hoàn toàn khác.

📌 Điểm cần nhớ

• Ánh xạ họ Code* theo đúng khâu trong vòng đời: CodeCommit = lưu trữ mã (Git repository), CodePipeline = điều phối đường ống phát hành, CodeDeploy = triển khai ứng dụng lên hạ tầng. Nhớ đúng ba vai này là xử lý được phần lớn câu hỏi nhóm Developer Tools.
• Gặp từ khoá "version control" / "source control" / "Git repository" → nghĩ ngay tới CodeCommit. Gặp "automate release pipeline" → CodePipeline. Gặp "deploy to instances" → CodeDeploy.
• Đừng chọn chỉ vì tên dịch vụ có chữ "Code": AWS cố tình đặt tên gần nhau, nên phải đọc động từ trong đề (lưu trữ / build / triển khai / điều phối) rồi mới khớp dịch vụ.
• Tên chứa "Data" (như DataSync) gần như luôn thuộc nhóm di chuyển và xử lý dữ liệu, không liên quan tới quy trình phát triển phần mềm — loại sớm để tiết kiệm thời gian.

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

Đề mô tả một công ty đang dựng serverless workflow để điều phối (coordinate) nhiều dịch vụ AWS thành một ứng dụng đáng tin cậy, và hỏi dịch vụ nào giúp tạo ra loại workflow đó.

Cụm từ quyết định nằm ở câu thứ hai: "a visual workflow that can track the status of each step" — một quy trình có hình ảnh trực quan và theo dõi được trạng thái của từng bước. Đây chính là ràng buộc tách bạch bốn phương án, vì cả bốn dịch vụ trong danh sách đều thường xuyên xuất hiện trong kiến trúc serverless và đều "kết nối các dịch vụ AWS lại với nhau" theo nghĩa nào đó. Nhưng chỉ một dịch vụ đóng vai orchestrator — biết toàn bộ quy trình gồm những bước nào, bước nào đang chạy, bước nào lỗi, bước nào cần thử lại. Ba dịch vụ còn lại chỉ nhìn thấy đúng phần việc của mình: chạy một đoạn code, đẩy một thông điệp, hoặc phát một thông báo. Cụm từ thứ hai đáng chú ý là "coordinate multiple AWS services" — điều phối, chứ không phải chỉ truyền tin giữa các thành phần.

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

D — AWS Step Functions. Đây là dịch vụ orchestration của AWS, sinh ra đúng để nối nhiều dịch vụ AWS lại thành một workflow serverless. Workflow được mô tả dưới dạng state machine gồm các state nối tiếp nhau, có nhánh rẽ, có vòng lặp, có xử lý lỗi và cơ chế thử lại (retry) ngay trong định nghĩa của workflow chứ không phải viết tay trong code ứng dụng — đó là phần "reliable application" mà đề nhắc tới.

Quan trọng nhất với câu hỏi này: Step Functions có console đồ hoạ vẽ ra sơ đồ các bước, và với mỗi lần thực thi (execution) bạn xem được từng bước đã chạy tới đâu, bước nào thành công, bước nào thất bại, dữ liệu vào/ra của từng bước. Đúng hai yêu cầu "visual workflow" và "track the status of each step" mà đề đặt ra.

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

A — Amazon SQS. Đây là hàng đợi thông điệp, dùng để decoupling: bên gửi bỏ message vào queue, bên nhận lấy ra xử lý, hai bên không cần biết nhau và không cần chạy cùng lúc. Đây là phương án dễ nhầm nhất vì SQS thật sự có mặt trong rất nhiều kiến trúc serverless nhiều bước. Nhưng SQS không giữ khái niệm "quy trình": nó không biết sau bước này là bước nào, không có sơ đồ trực quan, và không có chỗ nào để nhìn trạng thái tổng thể của một lượt chạy. Bạn chỉ thấy được số message đang chờ trong queue — thông tin đó không trả lời được câu hỏi "đơn hàng này đang ở bước thứ mấy".

B — AWS Lambda. Lambda chạy code theo sự kiện và gần như luôn là thành phần bên trong một workflow serverless — Step Functions thường gọi Lambda ở từng bước. Nhưng bản thân Lambda chỉ là một đơn vị tính toán: nó không cung cấp cách trực quan để dựng và điều phối chuỗi các bước qua nhiều dịch vụ. Muốn có workflow bằng Lambda thuần thì phải tự viết logic "gọi bước kế tiếp", tự lưu trạng thái, tự xử lý retry — đúng phần việc mà Step Functions sinh ra để thay thế. Đề hỏi dịch vụ tạo ra workflow, không hỏi dịch vụ chạy từng bước.

C — Amazon SNS. Dịch vụ pub/sub dùng để gửi thông báo tới nhiều subscriber cùng lúc (Lambda, SQS, email, HTTP endpoint...). Mô hình của SNS là phát tán một chiều, "bắn rồi quên": bên phát không theo dõi việc bên nhận xử lý xong hay chưa, cũng không có khái niệm thứ tự các bước. Nó có thể kích hoạt một phần của quy trình, nhưng không điều phối được toàn bộ quy trình và không có giao diện trực quan theo dõi từng bước.

📌 Điểm cần nhớ

• Thấy từ khoá "orchestrate / coordinate multiple AWS services", "visual workflow", "track the status of each step", "state machine" → nghĩ ngay tới AWS Step Functions.
• Phân biệt hai nhóm khái niệm hay bị trộn trong đề thi: orchestration (một bộ não biết toàn bộ quy trình — Step Functions) và messaging/decoupling (các thành phần trao đổi thông điệp mà không ai nắm bức tranh tổng thể — SQS, SNS).
• Nhớ đúng vai của từng dịch vụ: SQS = hàng đợi, một người nhận, decoupling; SNS = pub/sub, phát tán tới nhiều subscriber; Lambda = đơn vị tính toán chạy theo sự kiện, thường là một bước trong workflow chứ không phải cả workflow.
• Lambda xuất hiện trong hầu hết câu hỏi serverless nên rất dễ chọn theo phản xạ. Hãy đọc kỹ đề hỏi thành phần thực thi hay thứ điều phối các thành phần — chỉ vế sau mới là Step Functions.

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

Đề mô tả một tình huống rất cụ thể: ba EC2 instance nằm sau một Elastic Load Balancer duy nhất ("a single Elastic Load Balancer"), và yêu cầu triển khai phải highly available. Câu hỏi là bố trí ba instance đó ở đâu.

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

• "a single Elastic Load Balancer" — ELB là dịch vụ hoạt động trong phạm vi một Region. Nó chỉ đăng ký và phân phối lưu lượng tới target nằm trong chính Region đó. Cụm này một mình đã loại được mọi phương án đưa instance ra nhiều Region.
• "highly available" — trong AWS, tính sẵn sàng cao ở tầng hạ tầng đạt được bằng cách trải tài nguyên qua nhiều Availability Zone. Mỗi AZ là một hoặc nhiều trung tâm dữ liệu tách biệt về nguồn điện, làm mát và mạng, nên sự cố ở một AZ không kéo theo AZ còn lại.

Ghép hai ràng buộc lại: nhiều AZ, nhưng vẫn trong một Region. Đó chính là hình dạng của đáp án cần tìm.

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

C — Launch the instances across multiple Availability Zones in a single AWS Region.

Phương án này thoả cả hai ràng buộc cùng lúc:

• Ba instance nằm trong cùng một Region nên ELB đăng ký được tất cả làm target và cân bằng tải giữa chúng.
• Chúng nằm ở các AZ khác nhau, nên khi một AZ gặp sự cố, load balancer phát hiện target ở AZ đó không qua được health check và chuyển toàn bộ lưu lượng sang các instance ở AZ còn lại. Ứng dụng vẫn phục vụ được.

Đây là mẫu kiến trúc chuẩn nhất trong AWS: Multi-AZ trong một Region cho tính sẵn sàng cao, và ELB là thành phần đứng trước để che đi việc một AZ đã chết.

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

A — Nhiều AWS Region, dùng Elastic IP address. Sai ở điểm căn bản nhất: một ELB không phục vụ được instance nằm ở Region khác. Đề đã nói rõ chỉ có một load balancer, nên kiến trúc này không dựng nổi. Elastic IP cũng không cứu được gì — EIP chỉ là địa chỉ IPv4 tĩnh gán cho một instance trong một Region, nó không tạo ra cơ chế chuyển hướng lưu lượng khi có sự cố. Trải qua nhiều Region là chuyện có thật trong thiết kế disaster recovery, nhưng nó cần cơ chế điều hướng ở tầng khác chứ không phải một ELB đơn lẻ.

B — EC2 Spot Instance, cùng Region và cùng một AZ. Đây là phương án sai kép. Thứ nhất, "the same Availability Zone" phá thẳng yêu cầu high availability: cả ba instance nằm trong cùng một vùng cách ly, một sự cố AZ là mất sạch. Thứ hai, Spot Instance là mô hình giá — nó đánh đổi giá rẻ lấy khả năng bị thu hồi khi AWS cần lại dung lượng, tức là đi ngược hướng sẵn sàng cao chứ không hỗ trợ. Nói chung, mô hình mua (Spot / On-Demand / Reserved) không phải là công cụ để đạt HA.

D — EC2 Reserved Instance, cùng Region nhưng khác AZ. Đây là phương án gần đúng nhất và đáng dừng lại. Phần bố trí hạ tầng của nó giống hệt đáp án C: cùng Region, khác AZ. Chỗ hỏng nằm ở chi tiết thừa "Reserved Instances". Reserved Instance cũng chỉ là một mô hình thanh toán — cam kết dùng dài hạn để đổi lấy giá thấp hơn — và không đóng góp gì cho tính sẵn sàng. Đề không cho biết workload này chạy lâu dài hay chỉ tạm thời, nên áp một cam kết dài hạn vào là thêm ràng buộc mà đề không hề yêu cầu. Giữa hai phương án cùng mô tả đúng hạ tầng, phương án chỉ nói về thứ đề hỏi (C) luôn thắng phương án gài thêm điều kiện không liên quan (D).

📌 Điểm cần nhớ

• Elastic Load Balancer là dịch vụ trong phạm vi một Region: nó chỉ phân phối tới target trong Region của chính nó. Thấy đề nói "một ELB" mà phương án đề xuất trải instance qua nhiều Region thì loại ngay.
• High availability = nhiều Availability Zone trong một Region. Đây là câu trả lời mặc định cho mọi câu hỏi kiểu "làm sao cho highly available" ở tầng compute trong kỳ thi Cloud Practitioner.
• Mô hình mua (Spot, Reserved, On-Demand) là chuyện chi phí, không phải chuyện sẵn sàng. Khi đề hỏi về HA mà phương án nhấn vào mô hình giá, đó thường là bẫy — riêng Spot còn chủ động làm HA tệ đi vì instance có thể bị thu hồi.
• Khi hai phương án mô tả cùng một kiến trúc, hãy so phần thừa ra: phương án gắn thêm ràng buộc mà đề không nêu (như cam kết dài hạn của Reserved Instance) là phương án bị loại.

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

Đề bài mô tả một công ty triển khai cơ sở dữ liệu MySQL trên AWS, và đặt ra hai yêu cầu kèm theo: database phải dễ mở rộng (easily scale) và có sao lưu tự động (automatic backup enabled).

Cụm từ quyết định đáp án là "a MySQL database". Đây là ràng buộc phân biệt mạnh nhất trong cả câu: MySQL là một relational database (cơ sở dữ liệu quan hệ), dùng SQL với bảng, khoá chính, khoá ngoại và schema cố định. Ngay khi cụm từ này xuất hiện, mọi phương án không phải database quan hệ đều bị loại bỏ, bất kể chúng mạnh tới đâu ở khía cạnh scale hay backup.

Hai yêu cầu còn lại — scale và automatic backup — đóng vai trò xác nhận thêm chứ không phải yếu tố phân loại chính, vì trong danh sách phương án chỉ còn đúng một dịch vụ quan hệ. Đây là kiểu câu rất hay gặp ở AWS Certified Cloud Practitioner: chọn đúng họ database trước, rồi mới xét tới các tính năng vận hành.

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

Đáp án đúng là B — Amazon Aurora.

Aurora là một relational database do AWS xây dựng, tương thích với engine MySQL và PostgreSQL. Chính điểm tương thích này khiến nó khớp trực tiếp với yêu cầu "deploying a MySQL database": ứng dụng đang dùng MySQL có thể trỏ sang Aurora mà gần như không phải viết lại tầng truy cập dữ liệu.

Về hai yêu cầu vận hành trong đề:

• Dễ mở rộng: Aurora tách phần lưu trữ ra khỏi phần tính toán, dung lượng lưu trữ tự lớn dần theo dữ liệu mà không cần người quản trị can thiệp thủ công. Ngoài ra Aurora còn cho phép triển khai read replica để mở rộng khả năng đọc, kể cả trong cùng Region lẫn giữa các Region khác nhau.
• Automatic backup: Aurora cung cấp sao lưu tự động sẵn có, không phải dựng thêm cơ chế backup riêng.

Nói gọn: Aurora là phương án duy nhất trong danh sách vừa nói được tiếng MySQL, vừa đáp ứng cả yêu cầu scale lẫn backup tự động.

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

A — Amazon DocumentDB. Đây là một NoSQL database làm việc với cấu trúc dữ liệu dạng document (tài liệu kiểu JSON), được thiết kế cho khối lượng công việc kiểu MongoDB. Phương án này dễ gây nhầm vì nó vẫn là "database được AWS quản lý", cũng có backup, cũng mở rộng được — nhưng nó hỏng ở đúng chỗ ràng buộc chính: mô hình dữ liệu document không phải mô hình quan hệ, nên không thể dùng để chạy một MySQL database.

C — Amazon DynamoDB. Cũng là một NoSQL database, thuộc dạng key-value. DynamoDB nổi tiếng về khả năng scale và là câu trả lời rất hay gặp cho những câu hỏi thiên về mở rộng quy mô — chính vì thế nó là bẫy mạnh nhất ở đây. Nhưng một lần nữa, DynamoDB không phải relational database, nên không triển khai MySQL trên đó được. Ai chỉ đọc lướt hai chữ "easily scale" mà bỏ qua chữ "MySQL" sẽ rơi vào đúng phương án này.

D — Amazon Athena. Đây thậm chí không phải một database để lưu trữ và vận hành ứng dụng, mà là dịch vụ truy vấn dữ liệu nằm trong Amazon S3 bằng SQL. Việc Athena dùng cú pháp SQL khiến nó trông có vẻ liên quan tới MySQL, nhưng đó chỉ là sự trùng nhau ở ngôn ngữ truy vấn. Athena phục vụ phân tích dữ liệu đã có sẵn trong S3, không phải nơi để một ứng dụng ghi và đọc dữ liệu giao dịch như một MySQL database.

📌 Điểm cần nhớ

• Khi đề nêu đích danh MySQL, PostgreSQL, MariaDB, Oracle hay SQL Server, hãy chuyển ngay sang nhóm relational database và loại toàn bộ phương án NoSQL — đây là bước lọc rẻ nhất và đúng nhất.
• Phân nhóm nhanh các dịch vụ hay xuất hiện: Amazon Aurora là relational, tương thích MySQL và PostgreSQL; DynamoDB là NoSQL key-value; DocumentDB là NoSQL dạng document.
• Athena không phải database mà là công cụ truy vấn dữ liệu trong S3 bằng SQL. Đừng để chữ "SQL" đánh lừa thành "cơ sở dữ liệu quan hệ".
• Trong một câu có nhiều yêu cầu, hãy xác định ràng buộc loại bỏ được nhiều phương án nhất trước (ở đây là loại database), rồi mới dùng các yêu cầu còn lại (scale, automatic backup) để xác nhận lựa chọn.

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

Đề hỏi: "For what purpose would a Cloud Practitioner access AWS Artifact?" — tức là một người dùng vào AWS Artifact để làm gì.

Cụm từ quyết định ở đây chính là tên dịch vụ AWS Artifact. Đây là dạng câu hỏi "một dịch vụ — một chức năng", không có ràng buộc phụ nào về kiến trúc hay chi phí, nên toàn bộ việc chọn đáp án nằm ở chỗ bạn có nhớ đúng vai trò của AWS Artifact hay không. Bốn phương án đều là những việc có thật trong hệ sinh thái AWS, nhưng chỉ một việc thuộc về Artifact.

Cách phân biệt: Artifact là cổng tải tài liệu, không phải công cụ quét, không phải công cụ kiểm kê, không phải nơi học. Nó phục vụ cho tình huống bộ phận kiểm toán hoặc khách hàng doanh nghiệp yêu cầu bạn chứng minh AWS tuân thủ một chuẩn nào đó — bạn vào Artifact tải bản báo cáo do bên thứ ba kiểm định về, đưa cho họ.

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

D — Gain access to AWS security and compliance documents.

AWS Artifact là nơi truy cập theo yêu cầu (on-demand) các báo cáo bảo mật và tuân thủ của AWS, cùng một số thoả thuận trực tuyến mà khách hàng có thể xem và chấp nhận.

Các tài liệu tiêu biểu có trong Artifact:

• Báo cáo SOC (Service Organization Control)
• Báo cáo PCI (Payment Card Industry)
• Các chứng nhận từ những tổ chức kiểm định ở nhiều khu vực địa lý và nhiều mảng tuân thủ khác nhau, xác nhận rằng các biện pháp kiểm soát bảo mật (security controls) của AWS đã được triển khai và vận hành hiệu quả

Điểm mấu chốt: các tài liệu này nói về AWS, tức là về phần hạ tầng mà AWS chịu trách nhiệm trong mô hình shared responsibility. Artifact cung cấp tài liệu có sẵn — bạn tải xuống, chứ không tạo ra tài liệu mới.

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

A — Access training materials for AWS services. Artifact không chứa tài liệu đào tạo. Nội dung trong Artifact là báo cáo kiểm định và thoả thuận pháp lý — thứ dành cho bộ phận tuân thủ, kiểm toán, pháp chế, chứ không phải cho người muốn học cách dùng dịch vụ. Phương án này lợi dụng chỗ cả hai đều là "tài liệu bạn tải về", nhưng loại tài liệu hoàn toàn khác nhau.

B — Create a security assessment report for AWS services. Đây là phương án gần đúng nhất và cũng là bẫy nặng nhất, vì nó cũng nói tới "security report". Hỏng ở động từ Create. Artifact chỉ cho phép truy cập những báo cáo đã có sẵn, do các đơn vị kiểm định độc lập lập ra về hạ tầng AWS. Nó không chạy đánh giá, không quét, không sinh ra báo cáo mới dựa trên môi trường của bạn. Phân biệt "download tài liệu có sẵn" với "tạo ra kết quả đánh giá mới" là đúng ranh giới mà câu hỏi này muốn kiểm tra.

C — Download configuration details for all AWS resources. Artifact không có khả năng này. Đây là mô tả việc kiểm kê và theo dõi cấu hình tài nguyên trong tài khoản của bạn — một loại dữ liệu hoàn toàn khác với tài liệu tuân thủ về hạ tầng AWS. Chỗ nhầm ở đây là hướng của dữ liệu: Artifact nói về phía AWS, còn phương án này nói về phía tài nguyên do khách hàng tạo ra.

📌 Điểm cần nhớ

• AWS Artifact = cổng tải báo cáo tuân thủ (SOC, PCI, các chứng nhận) và thoả thuận trực tuyến. Thấy đề nhắc tới auditor, compliance report, chứng nhận của bên thứ ba thì nghĩ ngay tới Artifact.
• Chú ý động từ trong phương án: Artifact đi với access / download / obtain, không bao giờ đi với create / generate / assess / scan. Một phương án đúng danh từ nhưng sai động từ vẫn là phương án sai.
• Phân biệt theo hướng của dữ liệu: tài liệu trong Artifact nói về phần hạ tầng thuộc trách nhiệm của AWS; còn cấu hình tài nguyên trong tài khoản là phần thuộc trách nhiệm của khách hàng, không nằm ở Artifact.
• Trong đề Cloud Practitioner, các phương án sai thường là chức năng có thật của một dịch vụ AWS khác được gán nhầm tên. Đọc kỹ từng phương án và tự hỏi "việc này thực ra thuộc về đâu" sẽ loại được nhanh hơn là cố chứng minh phương án đúng.

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

Đề mô tả một công ty dịch vụ tài chính muốn dựng nền tảng phân tích real-time, dữ liệu được stream và xử lý ngay khi chảy qua. Nghe tới đây thì có vài dịch vụ AWS cùng họ streaming đều có vẻ hợp.

Nhưng ràng buộc quyết định nằm ở hai vế nối liền nhau trong đề:

"They are looking to use Apache Kafka for this, but they want to avoid the overhead of managing the Kafka infrastructure."

Hai cụm này phải đọc cùng nhau mới ra đáp án:

• "use Apache Kafka" — khách hàng đã chốt công nghệ. Đề không hỏi "cách nào để làm real-time analytics", mà hỏi "chạy Kafka bằng gì". Điều đó loại mọi dịch vụ streaming không phải Kafka, dù chúng làm được việc tương đương.
• "avoid the overhead of managing... infrastructure" — khách hàng muốn bản managed, không tự dựng cụm Kafka trên EC2, không tự lo broker, ZooKeeper/KRaft, vá lỗi hay mở rộng cụm.

Ghép lại: cần một dịch vụ AWS quản lý hộ chính Apache Kafka, chứ không phải một dịch vụ streaming khác cũng làm được chuyện tương tự.

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

Đáp án đúng là D — Amazon MSK (Amazon Managed Streaming for Apache Kafka).

MSK là dịch vụ fully managed để chạy chính Apache Kafka trên AWS. AWS lo phần hạ tầng bên dưới — provisioning broker, vá lỗi, thay node hỏng, mở rộng cụm — còn khách hàng vẫn làm việc với Kafka đúng như Kafka: cùng API, cùng khái niệm topic/partition/consumer group, ứng dụng và công cụ Kafka sẵn có kết nối vào mà không phải viết lại.

Đó là điểm khớp chính xác với cả hai vế của đề: giữ được Apache Kafka theo yêu cầu, đồng thời bỏ được gánh nặng vận hành hạ tầng. Công ty tập trung xây phần phân tích của mình thay vì làm quản trị viên cụm Kafka.

Một lưu ý dạng đề: bài thi hay viết tắt tên dịch vụ. "Amazon MSK" xuất hiện trần trụi như vậy, không kèm chú giải, nên bạn phải tự nhận ra M-S-K = Managed Streaming for Kafka. Nhớ mặt chữ viết tắt cũng là một phần của việc ôn.

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

A — Amazon Kinesis: đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Kinesis đúng là dịch vụ streaming dữ liệu real-time, cũng managed, cũng dựng được nền tảng phân tích tức thời — nếu đề chỉ nói "real-time analytics" thì Kinesis hoàn toàn có thể là đáp án. Chỗ nó hỏng là: Kinesis có giải pháp streaming riêng của AWS, tách biệt hẳn với Kafka. Nó không phải Apache Kafka, không dùng API của Kafka. Đề đã nêu đích danh yêu cầu Kafka, nên chọn Kinesis là phớt lờ đúng cái ràng buộc phân biệt các phương án. Đây là kiểu bẫy rất hay gặp: một dịch vụ làm được việc nhưng không đáp ứng công nghệ đã chỉ định.

B — Amazon SQS: là dịch vụ message queue, sinh ra để tách rời (decouple) các thành phần của ứng dụng — một component đẩy message vào queue, component khác lấy ra xử lý. Nó không phải nền tảng streaming để phân tích dữ liệu on the fly, và tất nhiên không phải Apache Kafka. Hỏng cả hai vế của đề.

C — Amazon Redshift: là data warehouse, phục vụ phân tích và báo cáo bằng các công cụ business intelligence trên dữ liệu đã được nạp vào kho. Nó thuộc khâu phân tích chứ không phải khâu vận chuyển luồng dữ liệu, và hoàn toàn không cung cấp Apache Kafka dưới dạng dịch vụ. Có chữ "analytics" trong đề nên trông liên quan, nhưng đề hỏi hạ tầng để stream dữ liệu, không hỏi nơi lưu trữ để truy vấn về sau.

📌 Điểm cần nhớ

• Khi đề gọi tên đích danh một công nghệ mã nguồn mở (Apache Kafka, Redis, Elasticsearch...), hãy tìm dịch vụ AWS managed cho chính công nghệ đó — ở đây là Amazon MSK. Một dịch vụ AWS "tương đương về chức năng" như Kinesis không thoả yêu cầu.
• Phân biệt ba nhóm dễ lẫn: SQS là hàng đợi để decouple ứng dụng, Kinesis/MSK là streaming dữ liệu real-time, Redshift là data warehouse để phân tích dữ liệu đã lưu. Đọc kỹ đề đang hỏi khâu nào.
• Cụm "avoid the overhead of managing infrastructure" / "reduce operational overhead" luôn đẩy đáp án về phía dịch vụ managed, tránh xa phương án tự dựng và tự vận hành.
• Học thuộc tên viết tắt của dịch vụ. Đề thi thật thường (nhưng không phải luôn luôn) viết đầy đủ; gặp lúc nó chỉ ghi MSK mà không nhận ra thì mất câu dù hiểu bản chất.