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

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

Đề mô tả một hành động rất cụ thể: người dùng triển khai một Amazon Aurora database instance trải trên nhiều Availability Zone, rồi hỏi cách làm đó thuộc pillar nào của AWS Well-Architected Framework.

Cụm từ quyết định là "in multiple Availability Zones". Đây không phải câu hỏi về Aurora, cũng không phải về hiệu năng hay chi phí — Aurora chỉ là cái cớ. Điều duy nhất đề nói tới là việc nhân bản hạ tầng sang nhiều AZ, tức là chuẩn bị sẵn cho tình huống một AZ gặp sự cố. Câu hỏi thực chất là: "đặt bản sao ở nhiều vùng cách ly lỗi thì thuộc trụ cột nào?"

Lưu ý thêm: đề không nhắc gì tới độ trễ, thông lượng, mã hoá, quyền truy cập, hay tiền bạc. Khi đề chỉ nêu đúng một đặc tính, hãy ánh xạ thẳng đặc tính đó sang pillar tương ứng thay vì suy diễn thêm những lợi ích phụ.

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

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

Reliability pillar nói về khả năng hệ thống hoạt động đúng chức năng khi được mong đợi và phục hồi được sau gián đoạn của hạ tầng hoặc dịch vụ, cấp phát tài nguyên linh hoạt theo nhu cầu, và giảm thiểu ảnh hưởng của những sự cố như cấu hình sai hay trục trặc mạng tạm thời.

Năm nguyên tắc thiết kế của Reliability trong cloud:

• Test recovery procedures — diễn tập quy trình phục hồi
• Automatically recover from failure — tự động phục hồi khi có lỗi
• Scale horizontally to increase aggregate system availability — mở rộng theo chiều ngang
• Stop guessing capacity — thôi đoán mò dung lượng
• Manage change in automation — quản lý thay đổi bằng tự động hoá

Triển khai Aurora qua nhiều Availability Zone rơi đúng vào nguyên tắc "Automatically recover from failure": mỗi AZ là một vùng cách ly lỗi riêng, nên khi một AZ mất, database vẫn còn bản sao ở AZ khác để tiếp tục phục vụ mà không cần con người can thiệp. Đó chính là định nghĩa của Reliability.

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

A — Performance efficiency. Đây là phương án gây nhầm nhiều nhất, vì multi-AZ đôi khi cũng giúp phân tải đọc. Nhưng Performance efficiency nói về việc dùng đúng loại và đúng lượng tài nguyên để đạt hiệu năng mong muốn, và duy trì hiệu năng đó khi nhu cầu thay đổi — chọn instance type phù hợp, dùng caching, dùng dịch vụ được tối ưu sẵn. Đề không hề nhắc tới độ trễ, thông lượng hay tối ưu tài nguyên. Mục đích được mô tả là chịu được sự cố, không phải chạy nhanh hơn.

B — Security. Security pillar lo việc bảo vệ dữ liệu, hệ thống và tài sản: quản lý danh tính và quyền truy cập, mã hoá khi lưu trữ và khi truyền, khả năng truy vết, phản ứng khi có sự cố an ninh. Trải instance ra nhiều AZ không thay đổi gì về ai được truy cập database hay dữ liệu có được mã hoá hay không. Nhầm ở đây thường do gộp chung "an toàn" theo nghĩa chống mất mát với "an ninh" theo nghĩa chống truy cập trái phép — hai chuyện khác nhau.

C — Cost optimization. Trụ cột này nói về việc tránh chi phí không cần thiết và đạt được giá trị kinh doanh với mức chi thấp nhất. Multi-AZ đi theo hướng ngược lại: bạn trả thêm tiền cho hạ tầng dự phòng để đổi lấy khả năng chịu lỗi. Đó là một đánh đổi có chủ đích nghiêng về Reliability chứ không phải một biện pháp tiết kiệm.

📌 Điểm cần nhớ

• Thấy multiple Availability Zones, Multi-AZ, replica, failover, backup, recovery trong đề → gần như chắc chắn là Reliability.
• Ánh xạ nhanh các pillar: Reliability = chịu lỗi và phục hồi; Performance efficiency = đúng tài nguyên, đúng hiệu năng; Security = quyền truy cập và bảo vệ dữ liệu; Cost optimization = cắt chi phí thừa; Operational excellence = vận hành, giám sát, tự động hoá quy trình.
• Redundancy luôn tốn thêm tiền — nên nếu đề nhấn mạnh dự phòng thì đáp án không thể là Cost optimization.
• Tên dịch vụ trong đề (ở đây là Aurora) thường chỉ là bối cảnh; hãy bám vào thuộc tính kiến trúc mà đề mô tả để chọn pillar.

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

Đề hỏi: thành phần nào của AWS giúp xây dựng ứng dụng fault-tolerant (chịu lỗi) — chọn HAI.

Cụm từ quyết định là "fault-tolerant", và cụ thể hơn là chữ "aid in the construction of". Fault tolerance nghĩa là khi một thành phần chết, hệ thống vẫn tiếp tục phục vụ — hoặc phục hồi nhanh sang thành phần khác. Vậy tiêu chí sàng lọc rất gọn: thứ đó có giúp thay thế / chuyển hướng khi một EC2 instance hỏng hay không?

Đây là kiểu câu bẫy bằng "toàn tên quen thuộc": AMIs, ARNs, Tags, Elastic IP, block device mappings đều là khái niệm cơ bản mà ai học AWS cũng biết. Nhưng phần lớn trong số đó chỉ là định danh, gán nhãn hoặc cấu hình lúc khởi tạo — chúng không thay đổi được điều gì tại thời điểm sự cố xảy ra. Đọc từng phương án với câu hỏi "khi instance chết, cái này có làm được gì không?" là phân loại xong.

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

D. Elastic IP addresses — Elastic IP là địa chỉ IP public tĩnh gắn với tài khoản chứ không gắn chết vào một instance. Khi instance đang giữ nó bị hỏng, ta remap Elastic IP đó sang instance khỏe mạnh khác. Người dùng bên ngoài vẫn gọi đúng địa chỉ IP cũ và dịch vụ hồi phục mà không cần chờ DNS lan truyền. Đây chính là cơ chế "che giấu lỗi" — đúng tinh thần fault tolerance.

A. AMIs — Amazon Machine Image là bản chụp đầy đủ của một máy: hệ điều hành, phần mềm đã cài, cấu hình. Khi một instance chết, có sẵn AMI nghĩa là khởi chạy instance thay thế gần như ngay lập tức, giống hệt bản đã hỏng, không phải cài đặt lại từ đầu. Chính khả năng thay thế nhanh này là nền tảng để tự phục hồi.

Hai phương án này bổ trợ nhau rất tự nhiên: AMI dựng lại năng lực xử lý, Elastic IP chuyển lưu lượng sang năng lực mới đó.

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

B. ARNs — Amazon Resource Name chỉ là chuỗi định danh duy nhất cho một tài nguyên AWS, dùng để trỏ tới tài nguyên trong IAM policy, trong lời gọi API, trong cấu hình dịch vụ. Nó mô tả "tài nguyên nào", chứ không tạo ra bản dự phòng nào và cũng không chuyển hướng được thứ gì khi tài nguyên đó chết. Có ARN hay không, instance hỏng vẫn cứ hỏng.

C. Tags — Tag là cặp key/value gắn thêm để phân loại, tìm kiếm, phân bổ chi phí và viết điều kiện phân quyền. Đây là phương án dễ gây phân vân nhất, vì trong thực tế tag đúng là hữu ích khi vận hành: nhờ tag mà biết instance nào thuộc hệ thống nào lúc xử lý sự cố. Nhưng đó là giá trị về quản trị và khả năng quan sát, không phải cơ chế chịu lỗi — tag không tự khởi chạy instance mới và không chuyển lưu lượng đi đâu cả. Đề hỏi cái giúp xây dựng ứng dụng fault-tolerant, không hỏi cái giúp quản lý cho gọn.

E. Block device mappings — Đây là phần cấu hình khai báo instance sẽ có những volume nào và gắn ở đâu khi khởi chạy. Nó cũng là phương án gần đúng, vì có liên quan tới lưu trữ, mà lưu trữ thì nghe như liên quan tới độ bền dữ liệu. Chỗ hỏng: block device mapping chỉ mô tả cách gắn ổ đĩa lúc khởi tạo, tự nó không tạo bản sao, không sao lưu, không failover. Một instance có block device mapping hoàn hảo vẫn ngừng phục vụ ngay khi nó chết.

📌 Điểm cần nhớ

• Chia phương án theo câu hỏi "khi sự cố xảy ra, thứ này có hành động được không?": thứ hành động được (AMI để dựng lại, Elastic IP để remap) mới là fault tolerance; thứ chỉ mô tả (ARN, tag, block device mapping) thì không.
• Định danh và siêu dữ liệu không bao giờ là câu trả lời cho fault tolerance. ARN và tag rất hay xuất hiện làm mồi nhử trong nhóm câu hỏi kiểu này.
• Elastic IP = địa chỉ tĩnh có thể di chuyển giữa các instance — nhớ đúng đặc tính "di chuyển được" này thì nhận ra nó ngay trong mọi câu về failover.
• AMI = khuôn để nhân bản nhanh, nên nó gắn với cả fault tolerance lẫn khả năng mở rộng. Câu hỏi nào nhắc tới "thay thế instance hỏng thật nhanh" thì AMI thường có mặt trong đáp án.
• Phân biệt hữu ích khi vận hành (tag giúp tìm ra tài nguyên lúc điều tra sự cố) với cơ chế chịu lỗi thật sự. Đề thi rất hay khai thác đúng ranh giới này.

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

Đề hỏi: đâu là lợi thế của điện toán đám mây AWS so với hạ tầng IT truyền thống (legacy IT) — chọn HAI phương án.

Cụm từ quyết định là "advantages … over legacy IT" và "(Select TWO)". Chữ legacy IT buộc ta so sánh với mô hình tự mua máy chủ đặt trong trung tâm dữ liệu riêng: phải dự báo công suất trước nhiều tháng, phải mua dư để phòng đỉnh tải, và mỗi lần thử ý tưởng mới đều chờ phần cứng về. Vậy phương án đúng phải là thứ mà mô hình trả tiền theo mức dùng và cấp phát trong vài phút giải quyết được.

Cái bẫy nằm ở chỗ có ba phương án nghe rất "cloud" — nhưng chúng hoặc mô tả sai mô hình shared responsibility, hoặc mô tả một lợi ích có điều kiện chứ không phải lợi ích mặc định. Đọc kỹ từng chữ mới tách được.

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

B — "You don't need to worry about over provisioning as you can elastically scale": đây chính là lợi ích được nêu trong tài liệu Six Advantages of Cloud Computing của AWS — "stop guessing capacity". Với legacy IT bạn phải đoán nhu cầu trước khi mua máy, đoán thiếu thì hệ thống nghẽn, đoán thừa thì tiền nằm chết trong đống máy chạy không hết công suất. Trên AWS bạn phản ứng theo tải thực tế: scale ra khi đông, thu về khi vắng, và chỉ trả tiền cho phần đang dùng.

E — "You can bring new applications to market faster": đây là lợi ích agility (tăng tốc độ và sự nhanh nhẹn). Không còn chu kỳ mua sắm — đặt hàng, chờ giao, lắp đặt, cấu hình — nên vòng lặp phát triển và phát hành ngắn lại. Thử một ý tưởng, hỏng thì bỏ, chi phí thử nghiệm thấp hẳn so với việc phải sắm phần cứng trước.

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

A — "You are able to pass responsibility for the availability of your application to AWS": sai vì hiểu nhầm shared responsibility model. AWS chịu trách nhiệm cho hạ tầng — phần cứng, mạng, cơ sở vật chất, và tính sẵn sàng của bản thân dịch vụ. Nhưng tính sẵn sàng của ứng dụng bạn viết vẫn là việc của bạn: kiến trúc chạy trên nhiều Availability Zone, xử lý lỗi, sao lưu, kiểm thử phục hồi. AWS cho bạn công cụ để đạt độ sẵn sàng cao, chứ không nhận thay trách nhiệm đó. Đây là phương án gần đúng nhất và cũng nguy hiểm nhất — cloud làm việc này dễ hơn, nhưng "dễ hơn" khác "không còn là việc của bạn".

C — "You don't need to patch your operating systems": sai theo cách rất giống A. Khi chạy máy ảo (mô hình IaaS), hệ điều hành khách nằm trong phần trách nhiệm của khách hàng — bạn vẫn phải vá nó. Điều gây nhầm là có những dịch vụ managed mà AWS lo phần OS giúp, nhưng đề nói chung về "sử dụng AWS cloud", không giới hạn ở nhóm dịch vụ đó, nên phát biểu tuyệt đối "không cần vá OS" là sai.

D — "You can bring services closer to your end users": đây là phương án dễ chọn nhầm nhất vì nghe hoàn toàn hợp lý — AWS có nhiều Region trên khắp thế giới. Nhưng bản thân mô hình cloud là tập trung hoá: bạn triển khai vào một số Region nhất định, và nếu người dùng của bạn ở xa Region đó thì dịch vụ không tự nhiên gần họ hơn. Đưa nội dung tới gần người dùng là kết quả của một lựa chọn kiến trúc có chủ đích (chọn Region phù hợp, triển khai nhiều Region), chứ không phải lợi ích mặc định đi kèm việc dùng cloud. So với B và E — hai thứ đúng ngay từ khoảnh khắc bạn chuyển lên cloud — thì D yếu hơn hẳn.

📌 Điểm cần nhớ

• Sáu lợi thế kinh điển của cloud theo AWS: đổi chi phí đầu tư ban đầu thành chi phí biến đổi, hưởng lợi thế quy mô, thôi phải đoán công suất, tăng tốc độ và sự nhanh nhẹn, thôi tốn tiền vận hành trung tâm dữ liệu, và vươn ra toàn cầu trong vài phút. Câu hỏi lợi ích thường hỏi thẳng vào danh sách này.
• Hễ phương án nào nói "bạn không cần làm X nữa" — vá OS, lo tính sẵn sàng của ứng dụng, quản lý dữ liệu — hãy đối chiếu ngay với shared responsibility model. Với IaaS, phần từ hệ điều hành trở lên thuộc về khách hàng.
• Phân biệt lợi ích mặc định (có ngay khi dùng cloud) với lợi ích có điều kiện (chỉ có nếu bạn thiết kế đúng). Phương án mô tả loại thứ hai thường là mồi nhử trong câu "advantages of cloud".
• Với câu "(Select TWO)", đọc trọn cả năm phương án rồi mới chọn: những phương án sai thường sai vì một chữ tuyệt đối ("pass responsibility", "don't need to"), chứ không phải vì nội dung hoàn toàn xa lạ.

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

Đề hỏi: "what are two ways AWS reduce prices" — hai cách AWS giảm giá để thưởng cho khách hàng dùng dịch vụ của họ. Đây là câu về mô hình định giá (pricing model) của AWS, thuộc mảng Cost Management.

Cụm từ quyết định nằm ở chỗ "reward customers for using their services" — tức là phần thưởng phải gắn với mức độ sử dụng hoặc mức cam kết, chứ không phải với việc "dùng nhiều loại dịch vụ khác nhau" hay với việc miễn một khoản phí nào đó. Đọc kỹ, ba phương án sai đều hỏng ở đúng điểm này: hoặc chúng đo sai thứ (đa dạng dịch vụ thay vì khối lượng dùng), hoặc chúng mô tả thứ vốn đã miễn phí sẵn nên không phải là "giảm giá thưởng thêm".

Đề cũng ghi rõ (Select TWO) — phải chọn đúng hai, chọn ba là sai cả câu.

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

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

A — Reduced cost for reserved capacity. AWS cho phép bạn cam kết dùng một mức tài nguyên trong một kỳ hạn cố định (thường là 1 năm hoặc 3 năm) để đổi lấy đơn giá thấp hơn đáng kể so với on-demand. Đây chính là mô hình đứng sau các hình thức như Reserved Instances hay các gói cam kết dung lượng. Logic đánh đổi rất rõ: bạn cho AWS sự chắc chắn về nhu cầu, AWS trả lại bạn giá rẻ hơn.

D — Volume based discounts when you use more services. AWS áp dụng giảm giá theo bậc khối lượng: càng dùng nhiều thì đơn giá trên mỗi đơn vị càng giảm. Đây đúng nghĩa "thưởng cho khách hàng vì đã dùng dịch vụ" — không cần ký cam kết gì, chỉ cần khối lượng sử dụng tăng lên là bậc giá tự động rẻ đi.

Hai phương án này bao trọn hai cơ chế giảm giá kinh điển của AWS: giảm theo cam kết (A) và giảm theo khối lượng (D).

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

B — Discounts for using a wider variety of services. Đây là phương án gài bẫy gần đúng nhất, vì nó chỉ khác D đúng một chữ: variety (đa dạng) thay vì volume (khối lượng). AWS không giảm giá vì bạn dùng nhiều loại dịch vụ khác nhau. Giá của mỗi dịch vụ được tính độc lập theo mức tiêu thụ của chính dịch vụ đó; bật thêm một dịch vụ mới không làm rẻ đi các dịch vụ bạn đang dùng. Cái được thưởng là dùng nhiều hơn, không phải dùng đa dạng hơn.

C — Removal of termination fees for customers who spend more. Sai ở tiền đề: AWS vốn không có phí chấm dứt hợp đồng (termination fee) để mà "gỡ bỏ". Mô hình là pay-as-you-go — ngừng dùng thì ngừng trả tiền. Không thể coi việc miễn một khoản phí chưa từng tồn tại là hình thức giảm giá. Vế "cho khách hàng chi tiêu nhiều hơn" chỉ làm phương án nghe có vẻ hợp lý chứ không cứu được tiền đề sai.

E — Reduction in inbound data transfer charges. Cũng sai ở tiền đề, giống C. Dữ liệu đi vào (inbound / data transfer in) AWS vốn không tính phí — chiều bị tính tiền là dữ liệu đi ra (outbound). Không có khoản phí nào để giảm ở chiều inbound, nên đây không phải một cách giảm giá. Đây là bẫy rất hay gặp: nhiều người nhớ nhầm cả hai chiều đều mất tiền.

📌 Điểm cần nhớ

• AWS thưởng khách hàng theo hai trục: cam kết kỳ hạn (reserved capacity, đổi cam kết 1–3 năm lấy đơn giá thấp) và khối lượng sử dụng (volume-based discount, dùng càng nhiều đơn giá càng giảm).
• Phân biệt volume với variety: giảm giá bám vào lượng dùng của từng dịch vụ, không bám vào số lượng loại dịch vụ bạn bật lên.
• Chiều dữ liệu: inbound không tính phí, chiều tính tiền là outbound. Bất kỳ phương án nào nói "giảm phí inbound" đều là bẫy dựa trên tiền đề không tồn tại.
• Mô hình AWS là pay-as-you-go, không có termination fee. Gặp phương án hứa "miễn/bỏ phí huỷ", hãy nghi ngay: không thể bỏ thứ chưa từng có.
• Mẹo chung khi làm dạng câu này: loại trước các phương án dựa trên tiền đề sai (C, E), rồi mới cân nhắc giữa các phương án gần giống nhau về câu chữ (B vs D).

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

Đề hỏi: dịch vụ nào báo động (alerts) và hướng dẫn khắc phục (remediation guidance) khi chính AWS đang gặp sự cố có thể ảnh hưởng tới bạn.

Cụm từ quyết định là "when AWS is experiencing events" — chủ thể gặp sự cố ở đây là phía AWS, không phải hạ tầng hay ứng dụng của bạn. Đây chính là ranh giới tách bốn phương án: ba phương án còn lại đều nhìn vào tài nguyên và ứng dụng do bạn vận hành (cấu hình, lỗ hổng, tấn công nhắm vào bạn), chỉ một dịch vụ có nhiệm vụ nói cho bạn biết tình trạng của bản thân AWS và những sự kiện vận hành phía AWS chạm tới tài khoản của bạn.

Cụm phụ thứ hai đáng chú ý là "that may impact you" — tức là không chỉ một trang trạng thái chung chung cho toàn thế giới, mà là thông tin được lọc theo đúng tài nguyên và tài khoản của bạn, kèm việc bạn cần làm để xử lý.

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

B — AWS Health Dashboard.

Đây là dịch vụ chuyên trách việc thông báo về tình trạng vận hành của AWS và các sự kiện phía AWS ảnh hưởng đến bạn. Nó khớp cả ba thành phần của đề:

• Alerts: phát cảnh báo khi có sự cố dịch vụ, sự kiện bảo trì theo lịch, hoặc thay đổi ảnh hưởng tới tài nguyên bạn đang chạy.
• Remediation guidance: mỗi sự kiện đi kèm mô tả và hướng dẫn hành động — ví dụ cần thay thế hay khởi động lại tài nguyên nào, cần chuẩn bị gì trước mốc bảo trì.
• "May impact you": dashboard hiển thị theo góc nhìn tài khoản của bạn, gắn sự kiện với đúng những tài nguyên bị ảnh hưởng, chứ không dừng ở bức tranh trạng thái chung của tất cả các dịch vụ và Region.

Nói gọn: khi vấn đề nằm ở phía AWS, AWS Health Dashboard là nơi bạn nhìn vào đầu tiên.

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

A — AWS Inspector. Đây là dịch vụ đánh giá bảo mật tự động cho các workload bạn triển khai trên AWS: quét lỗ hổng đã biết trong phần mềm, các vấn đề về cấu hình và tuân thủ, rồi xếp hạng mức độ nghiêm trọng. Nó có "phát hiện" và có "khuyến nghị xử lý", nên nghe qua khá giống vế "alerts and remediation guidance" — nhưng đối tượng nó soi là ứng dụng và tài nguyên của bạn, hoàn toàn không nói gì về việc bản thân AWS đang gặp sự cố. Sai ở chủ thể gặp vấn đề.

C — AWS Shield. Dịch vụ bảo vệ khỏi tấn công DDoS dạng managed. Nó liên quan tới "sự kiện" thật, nhưng là sự kiện tấn công từ bên ngoài nhắm vào ứng dụng của bạn, không phải sự cố vận hành nội tại của AWS. Đây là phương án dễ loại nhất trong bốn phương án vì phạm vi của nó rất hẹp và rất riêng biệt.

D — AWS Trusted Advisor. Đây là phương án gần đúng nhất và cũng là bẫy chính. Trusted Advisor thực sự đưa ra khuyến nghị kèm hướng dẫn khắc phục, chia theo các trục như tối ưu chi phí, hiệu năng, bảo mật, khả năng chịu lỗi và hạn mức dịch vụ. Nhưng nó là công cụ rà soát và tối ưu môi trường AWS của chính bạn — nó chỉ ra rằng bạn đang cấu hình chưa tốt, đang lãng phí, đang sắp chạm hạn mức. Nó không phải kênh thông báo khi AWS gặp sự cố. Đề nhấn "when AWS is experiencing events" chính là để tách Trusted Advisor ra khỏi Health Dashboard.

📌 Điểm cần nhớ

• Hỏi về tình trạng của chính AWS (sự cố dịch vụ, bảo trì theo lịch, sự kiện vận hành ảnh hưởng tài khoản bạn) → AWS Health Dashboard.
• Hỏi về tối ưu môi trường của bạn (chi phí, hiệu năng, bảo mật, fault tolerance, hạn mức) → AWS Trusted Advisor. Cả hai đều "đưa khuyến nghị", nên phải đọc kỹ xem ai là bên đang có vấn đề.
• AWS Inspector = quét lỗ hổng và đánh giá bảo mật tự động cho workload của bạn. AWS Shield = chống DDoS. Cả hai đều là dịch vụ bảo mật, không phải kênh thông báo tình trạng dịch vụ.
• Mẹo chung cho dạng câu này: xác định chủ ngữ của sự cố trong đề. "AWS is experiencing…" ≠ "your resources are misconfigured…" ≠ "your application is under attack…" — mỗi vế trỏ tới một dịch vụ khác nhau.

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

Đề hỏi: tính năng nào của DynamoDB cung cấp khả năng tăng tốc bằng bộ nhớ (in-memory acceleration) cho các bảng, đem lại cải thiện hiệu năng đáng kể.

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

• "DynamoDB feature" — đề không hỏi "dịch vụ cache nào của AWS", mà hỏi tính năng thuộc về chính DynamoDB. Cụm này một mình đã loại được mọi phương án là dịch vụ độc lập, dù dịch vụ đó cũng làm cache.
• "in-memory acceleration to tables" — đối tượng được tăng tốc là bảng DynamoDB, tức dữ liệu có cấu trúc key-value/document đọc qua API của DynamoDB, chứ không phải file hay nội dung web tĩnh.

Ghép hai ràng buộc lại: phải là thứ vừa nằm trong DynamoDB, vừa là cache bộ nhớ đặt trước các bảng.

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

D — Amazon DynamoDB Accelerator (DAX).

DAX là bộ nhớ đệm in-memory được quản lý hoàn toàn, thiết kế riêng cho DynamoDB. Nó nhận yêu cầu đọc thay cho bảng và trả kết quả từ bộ nhớ, đưa độ trễ đọc từ mức mili giây xuống mức micro giây, và vẫn giữ được thông lượng rất cao.

Điểm khiến DAX là feature chứ không phải một dịch vụ rời: nó tương thích API với DynamoDB, nên ứng dụng chỉ cần đổi client trỏ vào DAX cluster mà gần như không phải viết lại logic truy cập dữ liệu. Quan trọng hơn, DAX tự lo phần nặng nhọc của việc cache: populate dữ liệu, vô hiệu hoá cache (cache invalidation) và quản lý cluster đều do dịch vụ đảm nhiệm. Lập trình viên không phải tự viết đoạn "đọc cache, miss thì đọc DB rồi ghi ngược lại cache", cũng không phải tự xử lý chuyện cache cũ sau khi ghi.

Đúng cả hai ràng buộc trong đề: là tính năng của DynamoDB, và là in-memory cache đặt trước bảng.

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

A — Amazon EFS: đây là hệ thống file đàn hồi dựa trên giao thức NFS, dùng để nhiều EC2 instance cùng mount một thư mục chia sẻ. Nó là storage file, không phải cache bộ nhớ, và không liên quan gì tới bảng DynamoDB. Đây là phương án xa đề nhất — chọn nó thường là do nhầm chữ "elastic" hoặc chỉ nhớ mang máng "EFS là thứ gì đó nhanh".

B — Amazon ElastiCache: phương án gần đúng nhất và là bẫy chính của câu này. ElastiCache đúng là in-memory cache được quản lý (Redis/Memcached), và người ta hoàn toàn có thể đặt nó trước một database để giảm độ trễ. Nó hỏng ở đúng chữ "feature" trong đề: ElastiCache là một dịch vụ AWS độc lập, không phải tính năng của DynamoDB. Hệ quả thực tế cũng khác: dùng ElastiCache thì ứng dụng phải nói hai thứ tiếng — API của Redis/Memcached và API của DynamoDB — đồng thời tự viết logic cache-aside và tự lo invalidation khi dữ liệu trong bảng thay đổi. Đó chính là phần việc mà DAX làm sẵn.

C — Amazon CloudFront: là CDN, cache nội dung ở các edge location gần người dùng cuối để giảm độ trễ mạng khi phân phối web content. Cache của nó nằm ở tầng phân phối HTTP và tính theo đối tượng/URL, không phải bộ nhớ đệm cho các thao tác đọc item trong một bảng DynamoDB. Cũng là dịch vụ riêng, không phải tính năng của DynamoDB.

📌 Điểm cần nhớ

• Đề hỏi "feature of X" thì đáp án phải là thành phần thuộc về X, không phải một dịch vụ khác ghép vào — dù dịch vụ đó giải quyết được cùng vấn đề.
• Cặp DAX ↔ ElastiCache là bẫy kinh điển: cả hai đều là in-memory cache. Phân biệt bằng chỗ gắn — DAX gắn liền với DynamoDB và tương thích API của nó; ElastiCache là cache dùng chung, ứng dụng phải tự quản lý cache-aside và invalidation.
• Nhận diện nhanh theo loại dịch vụ: EFS = file storage (NFS), CloudFront = CDN cho nội dung web, ElastiCache = in-memory cache dùng chung, DAX = in-memory cache riêng cho DynamoDB.
• Giá trị bán hàng của DAX không chỉ là "nhanh hơn" mà còn là không phải tự quản lý cache invalidation, populate dữ liệu và cluster — cụm này hay xuất hiện trong đề để ám chỉ DAX.

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

Đề hỏi: trong các IAM best practice của AWS, thực hành nào khuyến nghị cấp quyền tối thiểu cần thiết để hoàn thành một tác vụ khi soạn IAM policy.

Cụm từ quyết định đáp án nằm gọn trong vế: "applying the minimum permissions necessary to perform a task" — cấp đúng phần quyền cần cho công việc, không hơn. Đây là cách diễn đạt lại nguyên văn định nghĩa của một best practice có tên riêng, nên câu này thực chất là bài kiểm tra khớp định nghĩa với tên gọi, không phải bài chọn giải pháp kiến trúc.

Chi tiết thứ hai cũng quan trọng: đề nói "when creating IAM policies" — phạm vi là nội dung của policy, tức là những action/resource nào được cho phép. Cả bốn phương án đều là best practice thật của IAM, nhưng chỉ một phương án nói về phạm vi quyền bên trong policy; ba phương án còn lại nói về cách tổ chức danh tính hoặc cách xác thực. Đọc kỹ ràng buộc này là loại được ngay ba lựa chọn.

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

C — Grant least privilege là đáp án đúng.

Least privilege chính là nguyên tắc bảo mật tiêu chuẩn mà AWS khuyến nghị khi tạo IAM policy: chỉ cấp những permission bắt buộc phải có để thực hiện tác vụ, không cấp dư. Quy trình đúng là xác định người dùng thực sự cần làm gì, rồi mới soạn policy cho phép đúng những việc đó — thay vì cấp quyền rộng rồi thu hẹp dần về sau.

Đây là định nghĩa trùng khớp từng chữ với vế "minimum permissions necessary to perform a task" trong đề. Không cần suy luận thêm: đề đang mô tả least privilege và hỏi tên của nó.

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

A — Create individual IAM users. Đúng là best practice: mỗi người một danh tính riêng thay vì dùng chung một bộ credential, nhờ đó CloudTrail truy vết được ai làm gì và thu hồi quyền từng người được. Nhưng nó trả lời câu hỏi "ai là chủ thể", không nói gì về mức quyền mà policy cấp. Một IAM user riêng biệt vẫn hoàn toàn có thể bị gắn policy cho quyền quản trị toàn tài khoản — tạo user riêng không tự động làm quyền nhỏ lại.

B — Use roles to delegate permissions. Cũng là best practice thật, và là phương án gần đúng nhất về mặt cảm giác vì role có gắn policy, lại thường được nhắc kèm least privilege. Chỗ nó hỏng: role là cơ chế trao quyền tạm thời cho một EC2 instance, một service, hay một user từ tài khoản khác — nó giải quyết bài toán phân phối credential (dùng thông tin xác thực tạm thay vì access key dài hạn), chứ không quy định policy gắn vào role đó rộng hay hẹp. Một role vẫn có thể mang policy cực rộng. Đề hỏi về độ lớn của tập quyền, không hỏi về hình thức trao quyền.

D — Enable MFA for privileged users. Best practice hợp lệ và rất được khuyến nghị, nhưng thuộc tầng xác thực (authentication): bắt buộc thêm một yếu tố thứ hai để chứng minh đúng người đang đăng nhập. Least privilege thuộc tầng ủy quyền (authorization): người đó sau khi vào được thì làm được những gì. MFA không cắt bớt một action nào trong policy — user bật MFA vẫn giữ nguyên toàn bộ quyền đã được cấp.

📌 Điểm cần nhớ

• Khi cả bốn phương án đều là best practice hợp lệ, đề đang hỏi phương án nào khớp định nghĩa được mô tả, không hỏi phương án nào tốt. Hãy bắt lấy cụm từ định nghĩa trong đề và dịch nó sang tên gọi chính thức.
• "Minimum permissions necessary" ⇔ least privilege. Cặp từ khóa này gần như luôn đi với nhau trong đề thi AWS.
• Phân biệt hai tầng: authentication (MFA, IAM user riêng — bạn là ai) và authorization (least privilege, nội dung policy — bạn được làm gì). Câu hỏi nào nhắc tới "permissions", "policy", "actions" thì thuộc tầng authorization.
• Role trả lời câu hỏi credential được cấp thế nào (tạm thời, không cần lưu access key), không trả lời câu hỏi quyền rộng tới đâu. Hai chuyện độc lập nhau: role có thể quá rộng, IAM user cũng có thể rất hẹp.

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

Đề hỏi: AWS support plan nào chỉ hỗ trợ qua email và do đội Cloud Support Associates phụ trách?

Cụm từ quyết định nằm ở hai chỗ, và phải đọc cả hai mới loại được hết phương án:

• "email only support" — nghĩa là kênh liên hệ duy nhất là email. Không có phone, không có chat. Đây là ràng buộc loại bỏ những plan cao cấp hơn (chúng có email và nhiều hơn thế).
• "by Cloud Support Associates" — AWS phân biệt rõ hai cấp đội ngũ: Cloud Support Associates và Cloud Support Engineers. Ai trả lời ticket của bạn là một đặc điểm nằm ngay trong bảng so sánh support plan, không phải chi tiết phụ.

Nhiều người chỉ đọc vế "email only" rồi lưỡng lự giữa Basic và Developer. Vế thứ hai chính là thứ chốt lại: Basic không có kênh technical support qua email nào cả, nên không thể là plan "do Cloud Support Associates hỗ trợ qua email".

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

B — Developer.

Developer là plan trả phí thấp nhất trong nhóm có technical support. Đặc điểm của nó khớp chính xác cả hai ràng buộc trong đề:

• Kênh liên hệ là email (mở ticket qua Support Center), không kèm phone hay chat.
• Người trả lời là Cloud Support Associates — chứ không phải Cloud Support Engineers như ở các plan cao hơn.

Đúng như phần giải thích gốc nêu: Developer cung cấp email support bởi đội Cloud Support Associates. Đây là plan dành cho môi trường thử nghiệm/phát triển, nơi người dùng chấp nhận kênh hẹp hơn và không cần hỗ trợ ngoài giờ.

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

A — Business. Đây là phương án gần đúng nhất theo kiểu "có email thật", nên dễ mắc bẫy. Nhưng nó hỏng ở cả hai ràng buộc: Business không phải "email only" — nó có thêm phone và chat, và hỗ trợ 24×7; đồng thời người trả lời là Cloud Support Engineers, không phải Associates. Nói cách khác, Business là một superset của Developer về kênh liên hệ, nên chữ "only" trong đề tự động loại nó.

C — Enterprise. Sai theo đúng cùng một logic với Business, thậm chí còn xa hơn: đây là plan cao cấp nhất, có email + phone + chat 24×7 với Cloud Support Engineers, cộng thêm các đặc quyền dành cho khách hàng lớn. Không có cách đọc nào biến nó thành "email only". Nếu bạn chọn Enterprise vì nghĩ "plan cao nhất thì hỗ trợ tốt nhất", bạn đã trả lời câu hỏi khác với câu được hỏi — đề không hỏi plan nào mạnh nhất, mà hỏi plan nào giới hạn ở đúng email và đúng đội Associates.

D — Basic. Đây là phương án gây nhầm mạnh nhất với ai chỉ nhớ mỗi cụm "email only". Basic là mức miễn phí mặc định của mọi tài khoản AWS, và nó không cung cấp technical support qua email. Người dùng Basic chỉ tiếp cận được tài liệu, whitepaper, diễn đàn cộng đồng, và một số kiểm tra tự động cơ bản; các vấn đề về billing/account thì xử lý qua kênh riêng chứ không phải hỗ trợ kỹ thuật. Không có technical support thì cũng không có đội Cloud Support Associates nào đứng sau — vế thứ hai của đề loại thẳng phương án này.

📌 Điểm cần nhớ

• "Only" trong đề là từ khoá loại trừ. Với câu hỏi so sánh support plan, plan cao hơn luôn bao gồm kênh của plan thấp hơn, nên chỉ có plan thấp nhất còn thoả điều kiện mới là đáp án khi đề ghi "email only".
• Nhớ ai trả lời ticket, không chỉ nhớ kênh nào. Developer → Cloud Support Associates; Business và Enterprise → Cloud Support Engineers. AWS cố tình đưa chi tiết này vào bảng so sánh và đề thi hay dùng nó làm điểm phân biệt.
• Basic không có technical support. Đừng mặc định "miễn phí thì vẫn được hỏi qua email" — Basic chỉ có tài liệu, diễn đàn và các kiểm tra tự động cơ bản.
• Thứ tự tăng dần cần thuộc: Basic (không technical support) → Developer (email, Associates, giờ hành chính) → Business (email + phone + chat, 24×7, Engineers) → Enterprise (như Business, cộng thêm đặc quyền cho khách hàng lớn). Nắm đúng trục này là giải được phần lớn câu hỏi về AWS Support.

🧩 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 bạn đặt ra các quy tắc để tự động chuyển object giữa các storage class khác nhau theo những mốc thời gian định sẵn?

Ba cụm từ trong đề quyết định đáp án, và cần đọc cả ba cùng lúc:

• "set rules" — đây là thứ bạn khai báo trước dưới dạng luật, không phải thao tác chạy tay từng lần.
• "automatically transfer objects between different storage classes" — việc cần làm là chuyển đổi storage class của object (transition), chứ không phải sao chép, nhân bản hay xoá.
• "at defined time intervals" — luật được kích hoạt theo tuổi của object (bao nhiêu ngày kể từ khi tạo), tức là có yếu tố thời gian trong luật.

Gộp lại, đề đang mô tả chính xác khái niệm vòng đời (lifecycle) của object trong S3: object sinh ra, "già" đi, rồi được đẩy sang lớp lưu trữ rẻ hơn khi không còn được truy cập thường xuyên. Đây là câu kiểm tra bạn có nhớ đúng tên gọi chính thức của tính năng hay không — kiểu câu rất hay gặp ở cấp Cloud Practitioner, nơi ba phương án sai đều là tên nghe rất "AWS" nhưng không tồn tại.

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

Đáp án đúng theo tệp là A — Object Lifecycle Management.

Object Lifecycle Management là tính năng cho phép gắn vào bucket một tập luật vòng đời, và mỗi luật làm được hai nhóm hành động:

• Transition — chuyển object sang một storage class khác sau một khoảng thời gian nhất định. Đây chính là phần khớp với "transfer objects between different storage classes at defined time intervals" trong đề.
• Expiration — xoá hẳn object khi nó đạt tới một độ tuổi nhất định.

Mục đích của tính năng là để dữ liệu được lưu tiết kiệm chi phí trong suốt vòng đời của nó: dữ liệu mới thì nằm ở lớp truy cập nhanh và đắt hơn, dữ liệu cũ ít đụng tới thì tự động trôi xuống các lớp rẻ hơn mà không cần ai can thiệp. Luật khai báo một lần, S3 tự thi hành từ đó về sau — đúng với chữ "automatically" trong đề.

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

B. Elastic Data Management — Không tồn tại tính năng nào của S3 mang tên này. Chữ "Elastic" là tiền tố quen thuộc trong hệ sinh thái AWS (EC2, EBS, ELB, EFS), nên tên này nghe rất hợp lý và dễ bị chọn theo cảm giác. Nhưng nó không phải tên của bất kỳ cơ chế nào chuyển object giữa các storage class của S3.

C. Auto Lifecycle Scaling — Đây là phương án gần đúng nhất và cũng là cái bẫy chính, vì nó có chữ "Lifecycle" — đúng khái niệm mà đề đang mô tả. Chỗ hỏng nằm ở phần còn lại của tên: "Auto ... Scaling" thuộc về thế giới co giãn năng lực tính toán (thêm/bớt instance theo tải), hoàn toàn khác với việc đổi lớp lưu trữ của một object đã nằm sẵn trong bucket. Tên ghép này không phải tên thật của tính năng nào; nó chỉ là hai thuật ngữ AWS quen tai dán vào nhau. Nhớ rằng tên đúng là Object Lifecycle Management, không có chữ "Scaling".

D. S3 Archiving — Cũng gần đúng về ý niệm, vì một trong những đích đến phổ biến nhất của luật vòng đời đúng là các lớp lưu trữ dạng archive. Nhưng "S3 Archiving" không phải là tên một tính năng — nó chỉ mô tả kết quả, không mô tả cơ chế. Quan trọng hơn: đề hỏi cái đặt ra luật để tự động chuyển, mà bản thân việc lưu trữ dạng archive không tự sinh ra luật nào cả. Chọn D là nhầm giữa đích đến và công cụ điều khiển việc di chuyển tới đích đó.

📌 Điểm cần nhớ

• Hễ đề nhắc tới "rules" + "automatically" + "move between storage classes" + yếu tố thời gian/tuổi object trong S3, câu trả lời gần như luôn là Object Lifecycle Management.
• Luật vòng đời có hai loại hành động cần phân biệt: transition (đổi storage class) và expiration (xoá object). Đề hỏi cái nào thì bám đúng cái đó.
• Ở cấp Cloud Practitioner, nhiều phương án sai được dựng bằng cách ghép các từ khoá AWS quen tai thành một cái tên không có thật ("Auto Lifecycle Scaling", "Elastic Data Management"). Cách chống lại là nhớ tên gọi chính thức, chứ không chọn theo phương án nào "nghe giống AWS nhất".
• Phân biệt tên tính năng với kết quả mà tính năng tạo ra: "archiving" là điều xảy ra, còn lifecycle rule mới là thứ bạn cấu hình để nó xảy ra.

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

Đề hỏi: dịch vụ AWS nào giúp đưa ra các hành động được khuyến nghị (recommended actions) về tối ưu chi phí?

Cụm từ quyết định nằm ở hai chỗ ghép lại:

• "recommended actions" — đề không hỏi dịch vụ nào hiển thị hay báo cáo chi phí, mà hỏi dịch vụ nào tự đưa ra lời khuyên, tức là quét môi trường rồi nói cho bạn biết nên sửa cái gì.
• "cost optimization" — chủ đề của lời khuyên phải là chi phí, không phải bảo mật, không phải tuân thủ, không phải sự kiện hệ thống.

Chỉ cần một phương án đáp ứng đồng thời "đưa ra khuyến nghị" và "về chi phí" là ra đáp án. Ba phương án còn lại đều rơi vào một trong hai kiểu hỏng: hoặc không phải công cụ khuyến nghị, hoặc có khuyến nghị nhưng về lĩnh vực khác.

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

B — AWS Trusted Advisor.

Trusted Advisor là công cụ trực tuyến quét môi trường AWS của bạn rồi đưa ra các khuyến nghị cụ thể dựa trên các thực hành tốt nhất. Nó không dừng ở việc trình bày số liệu — nó chỉ đích danh những chỗ đang lãng phí và gợi ý việc cần làm, ví dụ tài nguyên đang chạy mà gần như không được dùng tới.

Điểm khớp trực tiếp với đề: Trusted Advisor tổ chức các kiểm tra thành nhiều nhóm hạng mục, và cost optimization là một trong những hạng mục đó — bên cạnh performance, security, fault tolerance và service limits. Đề hỏi "recommended actions on cost optimization" thì đây đúng là dịch vụ được thiết kế cho việc đó.

Nói gọn: các dịch vụ khác trong danh sách cho bạn dữ liệu hoặc tài liệu; Trusted Advisor cho bạn việc cần làm.

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

A — Amazon CloudWatch Events. CloudWatch Events cung cấp một luồng sự kiện gần thời gian thực mô tả các thay đổi trong tài nguyên AWS, dùng để kích hoạt hành động tự động khi có sự kiện xảy ra (ví dụ trạng thái một tài nguyên thay đổi). Đây là cơ chế phản ứng theo sự kiện, không phải công cụ phân tích và khuyến nghị. Nó không biết gì về việc bạn đang tiêu tiền hợp lý hay không, và không bao giờ nói với bạn "nên tắt cái này đi". Đây là phương án dễ loại nhất nếu bám vào cụm "recommended actions".

C — AWS Inspector. Đây là phương án gần đúng nhất và cũng là cái bẫy chính, vì Inspector thật sự có đưa ra khuyến nghị: nó là dịch vụ đánh giá bảo mật tự động, quét ứng dụng triển khai trên AWS rồi báo cáo các vấn đề tìm được. Cấu trúc hoạt động rất giống Trusted Advisor — quét, chấm điểm, gợi ý sửa. Chỗ nó hỏng là lĩnh vực: Inspector nói về security và compliance của ứng dụng, hoàn toàn không đụng tới chi phí. Đề đã khoá chủ đề bằng cụm "cost optimization", nên đúng cơ chế mà sai lĩnh vực thì vẫn sai.

D — AWS Artifact. Artifact là nơi lấy các tài liệu liên quan tới tuân thủ (compliance) — báo cáo kiểm toán, chứng nhận của AWS để bạn tải về phục vụ nhu cầu audit của tổ chức mình. Nó là một kho tài liệu, không phân tích môi trường của bạn và không sinh ra khuyến nghị nào cả. Ngoài việc sai lĩnh vực (compliance chứ không phải cost), nó còn sai cả về bản chất: không có "recommended actions" nào ở đây.

📌 Điểm cần nhớ

• Khi đề dùng cụm "recommended actions" / "best practice checks" kèm chủ đề bất kỳ, nghĩ ngay tới Trusted Advisor — nó là dịch vụ duy nhất trong nhóm này quét môi trường rồi trả về việc cần làm.
• Trusted Advisor bao phủ nhiều hạng mục chứ không chỉ chi phí (cost optimization, performance, security, fault tolerance, service limits). Vì vậy nó có thể là đáp án đúng cho cả câu hỏi về bảo mật lẫn câu hỏi về hiệu năng — đừng gắn cứng nó với riêng chi phí.
• Phân biệt ba kiểu dịch vụ hay bị trộn lẫn trong cùng một câu: Inspector = khuyến nghị về bảo mật ứng dụng, Artifact = tải tài liệu compliance, CloudWatch Events = luồng sự kiện để kích hoạt tự động hoá. Cả ba đều không nói gì về tiền.
• Chiến thuật làm bài: tách đề thành hai ràng buộc — loại hành vi (báo cáo? khuyến nghị? tự động hoá? tải tài liệu?) và lĩnh vực (cost? security? compliance?). Phương án nào chỉ khớp một trong hai thì loại, dù nghe rất hợp lý.