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

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

Đề hỏi: những nguyên tắc thiết kế (design principles) nào của AWS Cloud giúp tăng độ tin cậy — reliability? và yêu cầu chọn HAI.

Cụm từ quyết định đáp án là "increase reliability". Đây là câu kiểm tra xem người học có phân biệt được các nguyên tắc thuộc trụ cột Reliability của AWS Well-Architected Framework với những nguyên tắc nghe cũng "hay ho" nhưng thực chất thuộc trụ cột khác — chủ yếu là Cost Optimization. Bốn trong năm phương án đều là những cụm từ quen thuộc lấy từ tài liệu AWS, nên nếu chỉ đọc lướt thấy "cái nào cũng đúng về mặt best practice" thì sẽ chọn nhầm. Ràng buộc ở đây không phải "cái nào tốt", mà là "cái nào tốt cho reliability".

Reliability nói về khả năng hệ thống hoàn thành đúng chức năng khi được yêu cầu, và tự phục hồi khi có sự cố. Vậy phương án đúng phải nói tới failure và recovery, chứ không nói tới tiền bạc hay hiệu suất sử dụng tài nguyên.

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

C. Automatically recovering from failure — thay vì chờ người trực phát hiện rồi vào xử lý tay, hệ thống tự theo dõi các chỉ số nghiệp vụ quan trọng và tự kích hoạt hành động khắc phục khi vượt ngưỡng. Điều này giảm — hoặc loại bỏ hẳn — gánh nặng vận hành và khoảng thời gian chết đi kèm với một sự cố ở một thành phần nào đó. Tự động hóa cũng loại được độ trễ và sai sót của con người, hai thứ luôn xuất hiện đúng lúc tệ nhất.

D. Testing recovery procedures — quy trình phục hồi phải được diễn tập trước khi sự cố thật xảy ra. Đây là cách duy nhất để chắc chắn nó thực sự hoạt động. Một runbook khôi phục chưa bao giờ chạy thử chỉ là một giả định, không phải một năng lực; trên cloud ta có thể dựng môi trường thử và chủ động gây lỗi để kiểm chứng, việc mà hạ tầng vật lý truyền thống rất khó làm.

Hai nguyên tắc này bổ trợ nhau: C lo phần tự động phản ứng, D lo phần chứng minh rằng phản ứng đó đúng.

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

A. Adopting a consumption model — chỉ trả tiền cho đúng phần tài nguyên đã dùng, dùng bao nhiêu trả bấy nhiêu, không phải đầu tư trước rồi để không. Đây là một nguyên tắc thật của AWS, nhưng lợi ích của nó nghiêng về chi phí và tính linh hoạt (agility), không phải reliability. Một hệ thống trả tiền theo mức dùng vẫn có thể sập y như một hệ thống trả tiền trọn gói nếu không có cơ chế phục hồi.

B. Measuring overall efficiency — đo hiệu quả tổng thể: sản lượng nghiệp vụ thu được so với chi phí bỏ ra. Cũng là nguyên tắc thật, nhưng nó phục vụ quản lý chi phí: biết được tiền đang đi đâu để cắt phần lãng phí. Đây là phương án dễ nhầm nhất vì "đo lường" nghe rất giống monitoring, mà monitoring thì liên quan tới reliability. Khác biệt nằm ở cái được đo: đo efficiency là đo chi phí trên đơn vị công việc, không phải đo sức khỏe hệ thống hay tỉ lệ lỗi.

E. Using monolithic architecture — sai theo hướng ngược lại hẳn: kiến trúc monolithic đặt nhiều thành phần của ứng dụng trên cùng một hệ thống, nên khi hệ thống đó hỏng thì toàn bộ ứng dụng hỏng theo. Bán kính ảnh hưởng lớn nhất có thể. Nguyên tắc được khuyến nghị là kiến trúc phân tán, tách thành các thành phần nhỏ độc lập để một phần hỏng không kéo sập phần còn lại. Đây là phương án nên loại đầu tiên.

📌 Điểm cần nhớ

• Với câu hỏi dạng "nguyên tắc nào giúp X", việc đầu tiên là gán mỗi phương án về đúng trụ cột của Well-Architected Framework, rồi giữ lại những cái thuộc trụ cột đề hỏi. Phương án sai thường không sai về mặt best practice — chúng chỉ thuộc trụ cột khác.
• Từ khóa của Reliability: automatically recover from failure, test recovery procedures, scale horizontally, stop guessing capacity, manage change through automation.
• Từ khóa của Cost Optimization: consumption model, measure overall efficiency, stop spending money on undifferentiated heavy lifting, analyze and attribute expenditure.
• Monolithic gần như luôn là đáp án sai trong các câu về reliability, availability hay khả năng mở rộng — kiến trúc phân tán, tách rời (decoupled) mới là thứ AWS khuyến nghị.
• Một quy trình khôi phục chưa từng được diễn tập thì không tính là có khả năng khôi phục; đó là lý do "testing recovery procedures" đứng riêng thành một nguyên tắc chứ không gộp vào việc lập kế hoạch DR.

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

Đề hỏi: dịch vụ cơ sở dữ liệu nào của AWS vừa schema-less vừa scale động được mà không phát sinh downtime.

Cụm từ quyết định nằm ngay ở hai ràng buộc ghép lại: "schema-less" và "scaled dynamically without incurring downtime". Chỉ cần ràng buộc thứ nhất là đã đủ tách bạch bốn phương án — vì trong danh sách có đúng một dịch vụ NoSQL, còn ba dịch vụ kia đều là cơ sở dữ liệu kiểu SQL, tức là dữ liệu phải nằm trong bảng có schema định nghĩa trước (cột, kiểu dữ liệu, ràng buộc).

Ràng buộc thứ hai là phần củng cố: nhóm SQL trong danh sách này gắn với instance — muốn tăng năng lực xử lý thì phải đổi loại instance, và thao tác đó kéo theo gián đoạn. Còn dịch vụ đúng thì thay đổi năng lực bằng thao tác cấu hình ("push button scaling"), không phải bằng việc dựng lại máy chủ.

Nói cách khác, đề đang kiểm tra một điều rất cơ bản: bạn có phân biệt được NoSQL với relational trong bộ dịch vụ database của AWS không.

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

B. Amazon DynamoDB.

DynamoDB là dịch vụ NoSQL được quản lý hoàn toàn (fully managed), cho hiệu năng nhanh và ổn định kèm khả năng mở rộng liền mạch.

• Schema-less: DynamoDB chỉ bắt buộc khai primary key (partition key, tuỳ chọn thêm sort key). Ngoài khoá đó ra, mỗi item trong cùng một table có thể mang tập thuộc tính khác nhau — thêm một trường mới không cần chạy lệnh đổi cấu trúc bảng. Đây đúng nghĩa "không có schema cố định".
• Scale động không downtime: đây là dịch vụ serverless theo nghĩa người dùng không nhìn thấy và không quản lý instance nào cả. Điều chỉnh năng lực đọc/ghi là một thao tác cấu hình, DynamoDB tự thay đổi ở phía dưới; bảng vẫn phục vụ request trong suốt quá trình. Không có bước "đổi instance type" nào để mà gây gián đoạn.

Hai đặc điểm này khớp chính xác với cả hai ràng buộc trong đề, nên B là đáp án duy nhất thoả mãn.

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

A. Amazon RDS — Đây là dịch vụ relational database được quản lý, chạy các engine SQL. Hỏng ở cả hai vế: dữ liệu bắt buộc nằm trong bảng có schema định nghĩa trước, và RDS chạy trên DB instance mà bạn tự chọn loại. Muốn tăng năng lực thì phải đổi instance class, thao tác đó gây gián đoạn dịch vụ. Không thoả "schema-less", cũng không thoả "no downtime".

C. Amazon Aurora — Đây là phương án gần đúng nhất và cũng là cái bẫy chính. Aurora nghe có vẻ hợp vì nó là engine tương thích MySQL/PostgreSQL do AWS thiết kế lại, với tầng lưu trữ tự lớn dần và khả năng mở rộng đọc rất tốt. Nhưng nó hỏng dứt khoát ở vế "schema-less": Aurora là relational database, bảng vẫn phải có schema, vẫn viết CREATE TABLE với cột và kiểu dữ liệu. Đề hỏi hai ràng buộc chứ không phải một; đọc lướt chỉ thấy chữ "scale" rồi chọn Aurora là mất điểm. Ngoài ra Aurora ở dạng provisioned cũng gắn với instance như RDS.

D. Amazon RedShift — Cũng là kho dữ liệu quan hệ, có schema, dùng SQL để truy vấn; hơn nữa mục đích của nó là data warehouse / phân tích (OLAP) trên khối dữ liệu lớn, không phải cơ sở dữ liệu giao dịch linh hoạt về cấu trúc. Redshift chạy trên cluster gồm các node, thay đổi quy mô là thao tác resize cluster — cũng thuộc nhóm "phải đụng tới hạ tầng". Sai cả về schema lẫn về cách scale, và còn lệch cả về mục đích sử dụng.

📌 Điểm cần nhớ

• Trong bộ database services của AWS, DynamoDB là lựa chọn NoSQL / schema-less; RDS, Aurora và Redshift đều là relational, có schema. Chỉ cần nhìn thấy từ khoá schema-less, NoSQL, key-value, document, flexible schema là hướng thẳng về DynamoDB.
• Phân biệt "managed" và "serverless": RDS/Aurora/Redshift được AWS quản lý hộ nhưng bạn vẫn chọn instance hoặc node — thay đổi quy mô nghĩa là đụng vào hạ tầng và thường kèm gián đoạn. DynamoDB không phơi ra instance nào, nên scale là thao tác cấu hình chứ không phải thao tác hạ tầng.
• Aurora là cái bẫy quen mặt cho câu hỏi có chữ "scale". Nó scale tốt trong thế giới relational, nhưng vẫn là relational — không bao giờ trả lời được câu hỏi có chữ schema-less.
• Khi đề nêu hai ràng buộc, hãy kiểm tra phương án theo cả hai. Một phương án thoả một nửa vẫn là sai, và thường nó chính là mồi nhử được đặt vào đề.
• Redshift đi với data warehouse, analytics, OLAP, báo cáo trên khối dữ liệu lớn — thấy đề nói về database linh hoạt cho ứng dụng thì nó đã lệch mục đích ngay từ đầu.

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

Đề bài hỏi rất gọn: "Which AWS service can be used to run Docker containers?" — dịch vụ AWS nào dùng để chạy container Docker.

Cụm từ quyết định đáp án là động từ "run". Đây chính là chỗ phân biệt bốn phương án, vì trong danh sách có tới hai cái tên nghe đều rất "container": Amazon ECR và AWS Fargate. Container trong AWS đi qua hai giai đoạn tách bạch:

• Lưu trữ image — nơi cất và phân phối image Docker đã build.
• Chạy container — nơi cấp CPU/RAM và thực sự khởi chạy image đó thành tiến trình đang sống.

Đề hỏi vế thứ hai. Ai đọc lướt thấy chữ "Container" trong tên dịch vụ là chọn ngay sẽ sập bẫy ở phương án B.

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

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

Fargate là serverless compute engine dành cho container, hoạt động cùng cả Amazon ECS lẫn Amazon EKS. Nó đúng nghĩa là nơi container chạy: bạn khai báo image, CPU và bộ nhớ cần cho task, Fargate lo phần hạ tầng bên dưới.

Điểm mấu chốt của Fargate, đúng như phần giải thích nguồn nêu:

• Không phải provision và quản lý server — không cần tự dựng, vá, hay scale cụm EC2 làm worker node.
• Khai báo và trả tiền theo tài nguyên của từng ứng dụng, thay vì theo cả một cụm máy chủ.
• Tăng tính bảo mật nhờ cô lập ở mức ứng dụng theo thiết kế — mỗi task chạy trong môi trường tách biệt.

Vậy nên với câu hỏi "chạy Docker container", Fargate là phương án duy nhất trong danh sách đảm nhận vai trò compute.

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

A — Amazon RedShift. Đây là giải pháp data warehouse, dùng cho truy vấn phân tích trên khối dữ liệu lớn. Nó không liên quan gì tới container và không chạy được container. Đây là phương án gây nhiễu rõ ràng nhất, chỉ để lấp chỗ.

B — Amazon ECR. Phương án gần đúng nhất và là bẫy chính của câu này. Elastic Container Registry là registry Docker được quản lý hoàn toàn, giúp lập trình viên lưu trữ, quản lý và phân phối image Docker. Chỗ nó hỏng: ECR chỉ giữ image, nó không cấp compute, không khởi chạy tiến trình. Quan hệ đúng là ECR cung cấp image cho ECS/EKS trên Fargate chạy — hai vai trò bổ sung nhau chứ không thay thế nhau. Từ khoá phân biệt nằm ngay trong tên: Registry ≠ Service/Compute.

D — Amazon AMI. Amazon Machine Image lưu thông tin cấu hình để khởi tạo EC2 instance — hệ điều hành, phần mềm cài sẵn, cấu hình ổ đĩa. Nó là khuôn mẫu cho máy ảo, không phải cho container, và bản thân AMI cũng không phải là một dịch vụ chạy workload: nó là một artifact, giống ECR ở chỗ chỉ là thứ được lưu lại. Ngoài ra AMI cũng không được gọi đúng là "dịch vụ" như cách đề đặt câu hỏi.

📌 Điểm cần nhớ

• Tách bạch hai vai trò khi gặp câu hỏi về container trên AWS: ECR = nơi lưu image, ECS/EKS + Fargate = nơi chạy container. Chỉ cần nhìn động từ trong đề (store hay run) là chọn được.
• AWS Fargate là lựa chọn serverless cho container: không quản lý server, trả tiền theo tài nguyên khai báo cho ứng dụng, và dùng được với cả ECS lẫn EKS.
• Tên dịch vụ có chữ "Container" chưa chắc là dịch vụ chạy container — Registry trong "Elastic Container Registry" là từ quyết định nghĩa.
• AMI thuộc thế giới EC2/máy ảo, không thuộc thế giới container; còn RedShift là data warehouse, xuất hiện ở đây thuần tuý làm nhiễu.

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

Đề hỏi: bộ công cụ AWS Cost Management cho phép người dùng làm những việc nào — chọn HAI.

Cụm từ quyết định nằm ngay ở chủ ngữ: "The AWS Cost Management tools give users the ability to…". Đây là nhóm công cụ về quan sát, phân tích, lập kế hoạch và cảnh báo chi phí (AWS Cost Explorer, AWS Budgets, Cost and Usage Report, Billing Console…). Chúng đọc dữ liệu chi phí và sử dụng, rồi trình bày hoặc cảnh báo — chứ không phải nhóm công cụ vận hành tài nguyên hay thay đổi mô hình mua.

Ràng buộc thứ hai, tinh vi hơn, nằm ở các từ "automatically" trong hai phương án D và E. Bài thi Cloud Practitioner rất hay dựng bẫy kiểu này: lấy một việc tối ưu chi phí có thật, gắn thêm chữ "tự động" và gán cho công cụ báo cáo. Cứ thấy công cụ phân tích chi phí được mô tả như đang tự thay đổi hạ tầng, hãy nghi ngờ ngay.

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

A — Break down AWS costs by day, service, and linked AWS account. Đây đúng là công việc trung tâm của AWS Cost Explorer và Cost and Usage Report: tổ chức và theo dõi dữ liệu chi phí, bóc tách theo nhiều chiều — theo thời gian, theo dịch vụ, theo tài khoản thành viên trong tổ chức (nhờ consolidated billing gom hoá đơn của nhiều tài khoản về một chỗ). Cụm "linked AWS account" chính là dấu hiệu của consolidated billing, một phần của nhóm Cost Management.

C — Create budgets and receive notifications if current or forecasted usage exceeds the budgets. Đây là mô tả gần như nguyên văn của AWS Budgets: đặt ngưỡng ngân sách, và nhận thông báo khi chi phí/mức sử dụng hiện tại hoặc dự báo vượt ngưỡng. Chữ "forecasted" đáng chú ý — Budgets không chỉ báo khi đã vượt mà còn cảnh báo dựa trên xu hướng dự đoán, giúp "lập kế hoạch tốt hơn nhờ ngân sách và dự báo" đúng như phần giải thích gốc nêu.

Hai phương án này đều thuộc đúng nhóm việc mà Cost Management làm: tổ chức – theo dõi – kiểm soát – dự báo chi phí.

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

B — Move data stored in Amazon S3 to a more cost-effective storage class. Đây là việc tối ưu chi phí có thật, nhưng nó thuộc về Amazon S3 (S3 Lifecycle rules, S3 Intelligent-Tiering), không phải bộ công cụ Cost Management. Cost Management có thể chỉ ra rằng bạn đang tiêu nhiều tiền cho S3, nhưng bản thân nó không di chuyển dữ liệu giữa các storage class. Ranh giới cần nhớ: công cụ chi phí báo cáo và khuyến nghị, dịch vụ lưu trữ mới thực thi.

D — Terminate any AWS resource automatically if budget thresholds are exceeded. Đây là phương án gần đúng nhất và cũng nguy hiểm nhất. AWS Budgets Actions có khả năng phản ứng khi vượt ngưỡng — ví dụ áp policy hạn chế hoặc dừng một số loại tài nguyên nhất định. Nhưng phương án hỏng ở chữ "any AWS resource": nó khẳng định phạm vi phổ quát, tự động tắt bất kỳ tài nguyên nào. Điều đó không đúng — phần giải thích gốc nói rõ các công cụ này "không terminate tất cả tài nguyên", chỉ một số tài nguyên mới xử lý được qua Budgets Actions. Một phương án đúng-một-phần nhưng phóng đại phạm vi thì vẫn là phương án sai.

E — Switch automatically to Reserved Instances or Spot Instances, whichever is most cost-effective. Sai ở hai tầng. Thứ nhất, Cost Management không tự thay đổi mô hình mua của bạn. Thứ hai, cách diễn đạt tự nó đã lẫn lộn khái niệm: Reserved Instances là một cam kết mua (mô hình thanh toán/giảm giá), còn Spot Instances là một kiểu chạy instance với vòng đời khác hẳn — có thể bị thu hồi. Không có công tắc nào "chuyển qua chuyển lại" giữa hai thứ đó. Công cụ chi phí có thể khuyến nghị mua Reserved Instances dựa trên lịch sử sử dụng, nhưng quyết định mua vẫn là của người dùng.

📌 Điểm cần nhớ

• AWS Cost Management là nhóm công cụ để nhìn và kiểm soát tiền, không phải để vận hành hạ tầng. Bốn việc chính: tổ chức và theo dõi chi phí, kiểm soát qua consolidated billing và phân quyền, lập kế hoạch bằng ngân sách và dự báo, gợi ý tối ưu giá.
• Cost Explorer = phân tích và bóc tách; AWS Budgets = đặt ngưỡng và cảnh báo. Thấy đề nhắc "by service / by account / theo thời gian" thì nghĩ tới Cost Explorer; thấy "threshold", "notification", "forecasted" thì nghĩ tới Budgets.
• Cảnh giác với chữ "automatically" và các từ tuyệt đối như "any" / "all". Đề thi hay lấy một việc có thật rồi phóng đại phạm vi hoặc gán cho sai dịch vụ. Budgets Actions phản ứng được với một số tài nguyên, nhưng không phải mọi tài nguyên.
• Hành động tối ưu chi phí thuộc về chính dịch vụ đó, không thuộc công cụ báo cáo. Đổi storage class là việc của S3 Lifecycle / Intelligent-Tiering; mua Reserved Instances là quyết định của người dùng. Công cụ chi phí chỉ ra vấn đề, còn dịch vụ tương ứng mới sửa.

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

Đề mô tả một web application chạy trên AWS đang nhận các request độc hại đến từ cùng một nhóm địa chỉ IP, và hỏi dịch vụ AWS nào giúp bảo vệ ứng dụng và chặn (block) lưu lượng độc hại đó.

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

• "web application" — vấn đề nằm ở tầng ứng dụng web (HTTP/HTTPS), không phải tầng tài khoản hay tầng hạ tầng chung.
• "block the malicious traffic" — yêu cầu là chặn thật sự, chứ không phải phát hiện, cảnh báo hay thông báo. Đây là ràng buộc phân biệt các phương án gần giống nhau: có phương án làm rất tốt việc nhìn thấy lưu lượng bất thường, nhưng bản thân nó không đứng chắn giữa đường và từ chối request.

Cộng thêm chi tiết "the same set of IP addresses" — nguồn tấn công đã được xác định rõ, nên cái cần là một cơ chế cho phép viết luật chặn theo source IP cho traffic vào ứng dụng web.

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

Đáp án đúng theo tệp là B — AWS WAF.

AWS WAF là web application firewall: nó nằm trước ứng dụng web hoặc API và kiểm tra từng request HTTP/HTTPS trước khi request đó tới ứng dụng. WAF được thiết kế để bảo vệ khỏi các web exploit phổ biến, và quan trọng với câu này: bạn tạo rule để chặn traffic dựa trên địa chỉ IP nguồn. Với tình huống đề nêu — biết rõ tập IP đang gửi request độc hại — chỉ cần đưa tập IP đó vào rule chặn của WAF là traffic bị từ chối ngay tại biên, không chạm tới ứng dụng.

Đây là dịch vụ duy nhất trong bốn phương án vừa nằm trên đường đi của request web, vừa có hành động block chứ không chỉ quan sát.

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

A. Amazon GuardDuty — đây là phương án gần đúng nhất và cũng là bẫy chính. GuardDuty đúng là một dịch vụ bảo mật, nó phân tích tài nguyên của bạn bằng phát hiện bất thường (anomaly detection) và machine learning, và hoàn toàn có thể phát hiện ra hoạt động độc hại từ một nhóm IP. Nhưng nó hỏng ở đúng chỗ đề yêu cầu: GuardDuty là dịch vụ phát hiện mối đe doạ, nó sinh ra finding và cảnh báo, có thể kích hoạt công cụ khác hành động — chứ bản thân nó không phải network firewall và không chặn được traffic. Đề hỏi dịch vụ nào block traffic, nên GuardDuty dừng lại ở nửa đầu của yêu cầu.

C. Amazon SNS — SNS là dịch vụ gửi thông báo theo mô hình publisher/subscriber (đẩy tin nhắn tới email, SMS, hàng đợi, hàm xử lý…). Nó không liên quan gì tới bảo mật tầng mạng hay tầng ứng dụng, không đứng trước web application và không có khái niệm rule chặn request. Đây là phương án sai rõ ràng nhất.

D. AWS IAM — IAM cũng thuộc nhóm Security, Identity & Compliance nên trông có vẻ hợp bối cảnh, nhưng nó giải quyết bài toán khác hẳn: tạo và quản lý user, group, role và policy để kiểm soát ai được gọi API AWS nào và làm gì với tài nguyên AWS. Nó không dùng để kiểm soát truy cập ở tầng mạng. Người dùng ẩn danh trên Internet gửi request vào web application không hề có danh tính IAM, nên IAM không có chỗ đứng để chặn họ.

📌 Điểm cần nhớ

• Đọc kỹ động từ trong đề: detect / alert / monitor dẫn tới GuardDuty, còn block / filter / protect web application dẫn tới AWS WAF. Cùng một tình huống tấn công, đổi động từ là đổi đáp án.
• AWS WAF = firewall cho tầng ứng dụng web, lọc request HTTP/HTTPS theo rule, trong đó có rule theo source IP; đặt trước ứng dụng nên chặn được trước khi request tới nơi.
• GuardDuty là dịch vụ phát hiện mối đe doạ dựa trên phân tích bất thường — nó báo, không chặn; muốn chặn thì phải để nó kích hoạt một công cụ khác.
• IAM kiểm soát danh tính, không kiểm soát mạng. Nếu kẻ tấn công là khách ẩn danh trên Internet thì IAM không phải công cụ đúng, dù đề nghe rất "security".
• SNS chỉ là kênh thông báo pub/sub. Thấy SNS trong một câu hỏi về chặn tấn công thì gần như chắc chắn nó là phương án gây nhiễu.

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

Đề hỏi: "Which of the following are pillars from the six pillars of the AWS Well-Architected Framework? (Select TWO.)" — trong danh sách phương án, đâu là trụ cột (pillar) của AWS Well-Architected Framework.

Cụm từ quyết định đáp án là "six pillars of the AWS Well-Architected Framework". Đây không phải câu hỏi suy luận kiến trúc mà là câu kiểm tra thuộc lòng danh sách tên gọi chính thức. Điều làm câu này bẫy người học là các phương án sai đều là những từ nghe rất giống ngôn ngữ của Well-Architected: "Resilience", "Confidentiality", "Economics" — cả ba đều là khái niệm hoàn toàn có thật và hoàn toàn đúng đắn trong thiết kế cloud, chỉ có điều chúng không phải tên của một pillar. Ràng buộc ở đây là tên gọi chính xác, không phải ý tưởng gần đúng.

Sáu pillar theo Well-Architected Framework là: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability. Chỉ cần đối chiếu danh sách này với năm phương án là ra kết quả, không cần lập luận gì thêm.

Chú ý thêm: đề ghi rõ "six". Bản đầu tiên của framework chỉ có năm pillar, Sustainability được bổ sung sau thành pillar thứ sáu. Người ôn theo tài liệu cũ rất dễ loại Sustainability vì tưởng nó là chủ đề marketing về môi trường chứ không phải một trụ cột thật.

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

Đáp án đúng theo tệp là B (Sustainability) và E (Operational excellence).

• E — Operational excellence: là pillar kinh điển, có mặt từ phiên bản đầu tiên của framework. Nó nói về việc vận hành và giám sát hệ thống để mang lại giá trị nghiệp vụ, cùng với việc liên tục cải tiến quy trình và thủ tục vận hành. Tên gọi khớp chính xác với danh sách chính thức.
• B — Sustainability: là pillar được thêm vào sau, nâng con số từ năm lên sáu — đúng như đề bài nêu. Nó bàn về việc giảm tác động môi trường của khối lượng công việc chạy trên cloud, chẳng hạn tối ưu mức sử dụng tài nguyên và chọn cách triển khai hiệu quả hơn về năng lượng.

Chính vì đề viết "six pillars" chứ không phải "five pillars" mà Sustainability trở thành đáp án hợp lệ — con số trong đề là gợi ý cố tình.

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

• A — Economics: sai vì đây không phải tên pillar. Pillar liên quan tới chi phí có tên chính thức là Cost Optimization, không phải "Economics". Đây là kiểu bẫy "đúng ý, sai tên": ai hiểu framework theo tinh thần chứ không nhớ chữ sẽ chọn nhầm vì thấy "kinh tế" thì cũng là chuyện tiền bạc.
• C — Resilience: đây là phương án gần đúng nhất và nguy hiểm nhất. Khả năng chịu lỗi và phục hồi đúng là nội dung cốt lõi của một pillar, nhưng pillar đó mang tên Reliability. "Resilience" là một thuộc tính được bàn bên trong Reliability, không phải nhãn của trụ cột. Câu hỏi chấm theo tên gọi, nên gần đúng ở đây vẫn là sai.
• D — Confidentiality: cũng gần đúng theo cùng một kiểu. Tính bảo mật thông tin nằm trong phạm vi của pillar Security, nhưng bản thân "Confidentiality" là một thuộc tính bảo mật (quen thuộc từ bộ ba confidentiality – integrity – availability), không phải tên pillar.

Điểm chung của cả ba phương án sai: chúng đều là một phần nội dung của một pillar có thật, được đổi sang một cái tên khác. Không phương án nào sai vì "vô nghĩa" — chúng sai vì không trùng khớp với danh sách tên gọi chính thức.

📌 Điểm cần nhớ

• Thuộc lòng đúng sáu tên gọi: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability. Câu hỏi dạng này chấm theo tên, không chấm theo ý.
• Ba cặp bẫy hay lặp lại: Resilience ≠ Reliability, Confidentiality ≠ Security, Economics ≠ Cost Optimization. Thấy phương án mô tả đúng tinh thần nhưng lệch chữ thì loại.
• Sustainability là pillar được bổ sung sau, nâng framework từ năm lên sáu. Đề ghi "six" hay "five" là tín hiệu cho biết Sustainability có được tính hay không — đọc kỹ con số trong đề.
• Với câu "(Select TWO)", chọn đủ đúng hai phương án; chọn thiếu hoặc thừa đều bị tính sai toàn bộ câu.

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

Đề hỏi về AWS Cloud Adoption Framework (AWS CAF) — cụ thể là giai đoạn (phase) nào lo việc identifying capability gaps và aligning readiness cho việc chuyển lên cloud.

Cụm từ quyết định nằm gọn trong hai chữ: "capability gaps" và "readiness". Bốn phương án đều là tên các giai đoạn hợp lệ trong lộ trình chuyển đổi của AWS CAF, nên không thể loại bằng cách "cái này không có thật". Phải phân biệt bằng mục đích của từng giai đoạn:

• Nói về tầm nhìn, mục tiêu kinh doanh → một giai đoạn khác.
• Nói về khoảng cách năng lực hiện tại so với năng lực cần có, và mức sẵn sàng → đây chính là dấu hiệu của Align.
• Nói về triển khai, đưa vào chạy thật hay mở rộng, tối ưu → hai giai đoạn phía sau.

Chữ "gap" (khoảng cách) là mấu chốt: muốn nói tới khoảng cách thì phải có hai đầu để so — năng lực đang có và năng lực cần có — và việc so sánh, làm cho hai đầu khớp nhau chính là nghĩa đen của từ align.

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

Đáp án đúng theo tệp là B — Align.

Trong AWS CAF, Align là giai đoạn tổ chức rà soát năng lực hiện tại của mình, chỉ ra các capability gap, và đảm bảo mức độ sẵn sàng (readiness) cho việc áp dụng cloud. Nó là bước kéo quy trình, con người và hệ thống đang có về khớp với yêu cầu cùng đặc điểm của các dịch vụ AWS.

Nói cách khác, Align là bước chẩn đoán và chuẩn bị: chưa xây gì cả, mà đang xác định "chúng ta còn thiếu gì" và "làm sao bịt chỗ thiếu đó" trước khi bắt tay vào triển khai. Đề bài mô tả đúng hai việc này nên Align là lựa chọn khớp trực tiếp.

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

A — Launch — Sai vì đây là giai đoạn bắt đầu đưa vào chạy: khởi động và triển khai các dịch vụ, quy trình mới dựa trên chiến lược và kế hoạch đã dựng ở những giai đoạn trước đó. Launch thừa hưởng kết quả của việc phân tích gap chứ bản thân nó không phải nơi làm việc phân tích ấy. Nếu chọn Launch, tức là giả định gap đã được xác định từ trước — và câu hỏi lại đang hỏi chính bước xác định đó.

C — Scale — Sai vì Scale là giai đoạn mở rộng và tối ưu: nhân rộng các giải pháp đã triển khai để khai thác tối đa lợi ích của cloud. Trọng tâm ở đây là hiệu quả và quy mô, không phải phát hiện năng lực còn thiếu. Đây là giai đoạn nằm xa nhất về phía sau trong lộ trình so với nội dung đề hỏi.

D — Envision — Đây là phương án gần đúng nhất và dễ nhầm nhất, vì Envision cũng là một giai đoạn "chuẩn bị", cũng diễn ra sớm, cũng chưa xây gì. Nhưng Envision tập trung vào việc xác định tầm nhìn và mục tiêu cho việc chuyển đổi lên cloud — trả lời câu hỏi "chúng ta muốn đạt được điều gì, gắn với kết quả kinh doanh nào". Nó không đi vào việc soi năng lực hiện tại để tìm chỗ thiếu. Envision là "đích đến", Align mới là "chúng ta đang đứng cách đích bao xa và thiếu gì để đi tới đó". Đề bài dùng chữ capability gaps, tức là đang nói về khoảng cách chứ không phải về đích — nên chọn Envision là đọc trượt mất từ khoá.

📌 Điểm cần nhớ

• Bắt từ khoá theo động từ chính của giai đoạn: Envision = định tầm nhìn/mục tiêu; Align = tìm capability gap, đánh giá readiness, làm khớp quy trình hiện có; Launch = triển khai chạy thật; Scale = mở rộng và tối ưu.
• Hễ đề nhắc "capability gap", "readiness" hay "change management / stakeholder alignment" trong ngữ cảnh AWS CAF, phản xạ đầu tiên nên là Align.
• Envision và Align đều là giai đoạn chuẩn bị nên rất dễ lẫn: phân biệt bằng đích đến (Envision) so với khoảng cách tới đích (Align).
• Với dạng câu "phase nào của AWS CAF làm việc X", cả bốn phương án thường đều là tên giai đoạn có thật — đừng tìm cách loại bằng "tên này không tồn tại", hãy so ý nghĩa từng giai đoạn với động từ trong đề.

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

Đề bài yêu cầu chọn phát biểu mô tả đúng nhất dịch vụ Elastic Load Balancer (ELB) trong bối cảnh "các dịch vụ AWS giúp tạo môi trường ứng dụng có khả năng mở rộng".

Cụm từ quyết định là "best describes the Elastic Load Balancer service". Đây là dạng câu hỏi định nghĩa: mỗi phương án là mô tả chính thức của một dịch vụ AWS khác nhau, và việc duy nhất phải làm là ghép đúng mô tả với đúng cái tên. Bẫy nằm ở chỗ cả bốn phương án đều là mô tả chính xác — chỉ khác là ba trong số đó mô tả dịch vụ khác chứ không phải ELB.

Cụm phụ đáng chú ý nữa là "scalable application environments". Nó khiến người học liên tưởng ngay tới việc thêm/bớt EC2 instance, và đó chính là lý do phương án D trở nên hấp dẫn. Nhưng bối cảnh này chỉ là khung dẫn dắt, không phải ràng buộc — câu hỏi vẫn hỏi về ELB chứ không hỏi "dịch vụ nào giúp mở rộng".

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

Đáp án đúng theo tệp là B — "Automatically distributes incoming application traffic across multiple targets, such as Amazon EC2 instances, containers, and IP addresses".

Đây đúng là định nghĩa của Elastic Load Balancing. Nhiệm vụ cốt lõi của ELB là nhận lưu lượng đến rồi phân phối sang nhiều target phía sau. Ba loại target được nêu trong phương án — EC2 instances, containers, IP addresses — cũng chính là các target type mà ELB hỗ trợ, phản ánh đúng mô hình target group của dịch vụ.

Ngoài việc chia tải, ELB còn mang lại fault tolerance: nó cân bằng lưu lượng qua nhiều Availability Zone và chỉ gửi request tới những target đang healthy (nhờ health check). Target nào hỏng thì bị loại khỏi vòng quay cho tới khi khoẻ trở lại. Đó là lý do ELB được xếp vào nhóm dịch vụ tạo nên môi trường ứng dụng có tính sẵn sàng cao và co giãn được.

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

A — "A highly available and scalable Domain Name System (DNS) service" Đây là mô tả của Amazon Route 53, không phải ELB. Route 53 làm việc ở tầng phân giải tên miền: trả về địa chỉ để client biết đi đâu. Route 53 cũng có routing policy và health check nên nghe rất gần với "cân bằng tải", nhưng nó không nằm trên đường đi của lưu lượng ứng dụng — nó chỉ trả lời truy vấn DNS rồi rút lui. ELB thì ngược lại, nhận trọn từng request và chuyển tiếp tới target.

C — "A network service that provides an alternative to using the Internet to connect customers' on-premise sites to AWS" Đây là mô tả của AWS Direct Connect — đường kết nối riêng từ trung tâm dữ liệu của khách hàng vào AWS, thay cho việc đi qua Internet công cộng. Phương án này lạc chủ đề rõ nhất: nó nói về kết nối lai giữa on-premise và AWS, hoàn toàn không đề cập tới chuyện chia lưu lượng cho nhiều target.

D — "Helps you ensure that you have the correct number of Amazon EC2 instances available to handle the load for your application" Đây là phương án gần đúng và dễ chọn nhầm nhất, vì nó mô tả EC2 Auto Scaling. Hai dịch vụ này gần như luôn được dạy chung một bài và thường triển khai cùng nhau, nên rất dễ lẫn. Điểm hỏng nằm ở động từ: phương án D nói về việc đảm bảo đúng SỐ LƯỢNG instance — tức là thêm/bớt instance theo tải. Đó là việc của Auto Scaling. ELB không tạo và không huỷ instance nào cả; nó chỉ chia lưu lượng cho những instance đang tồn tại. Auto Scaling quyết định có bao nhiêu server, ELB quyết định request nào đi tới server nào.

📌 Điểm cần nhớ

• Với câu hỏi dạng "which statement best describes X", hãy đọc cả bốn phương án như bốn định nghĩa của bốn dịch vụ khác nhau, rồi gọi tên từng dịch vụ ra — loại trừ theo cách này nhanh và chắc hơn là cố tìm phương án "nghe hợp lý".
• Phân biệt cặp hay lẫn nhất: ELB = chia lưu lượng cho các target đang có, EC2 Auto Scaling = điều chỉnh số lượng instance. Chúng bổ trợ nhau nhưng làm hai việc khác hẳn.
• Route 53 = DNS, làm việc ở bước phân giải tên miền chứ không nằm trên đường đi của request; Direct Connect = kết nối riêng từ on-premise vào AWS, không liên quan tới cân bằng tải.
• Chú ý từ khoá đặc trưng của ELB trong đề thi: distributes incoming traffic, multiple targets, EC2 instances / containers / IP addresses, healthy targets, multiple Availability Zones.

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

Đề hỏi: "What advantages does the AWS cloud provide in relation to cost? (Select TWO.)" — AWS cloud mang lại lợi thế gì về mặt chi phí, chọn HAI phương án.

Cụm từ quyết định là "in relation to cost" kết hợp với "advantages the AWS cloud provides". Nó giới hạn phạm vi vào những đặc tính chi phí mà bản thân mô hình cloud tạo ra — tức mô hình pay-for-what-you-use. Đây là câu kiểm tra xem người học có nắm đúng cách AWS tính tiền hay không, và các phương án sai đều được dựng theo cùng một mẫu: nghe rất "hợp lý về tài chính" nhưng mô tả thứ không có trên hoá đơn AWS hoặc không phải cách AWS bán hàng.

Vì đề yêu cầu chọn hai, cần tìm hai phát biểu vừa đúng sự thật vừa là lợi thế của cloud, chứ không phải một đặc điểm kế toán bất kỳ.

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

Theo trường dapAnDung trong tệp, hai đáp án đúng là B và C.

B — "Ability to turn off resources and not pay for them": đây chính là biểu hiện trực tiếp nhất của mô hình pay-as-you-go. Với hạ tầng đặt tại chỗ, tiền đã bỏ ra mua máy chủ là chi phí chìm — tắt máy đi cũng không lấy lại được đồng nào. Trên AWS, tài nguyên tính theo mức sử dụng, nên dừng hoặc xoá tài nguyên khi không cần là ngừng phát sinh chi phí cho phần đó. Đây là lợi thế chi phí đặc trưng của cloud.

C — "Fine-grained billing": AWS tính tiền ở mức chi tiết theo từng tài nguyên và theo đơn vị sử dụng nhỏ, thay vì một khoản gộp. Nhờ vậy khách hàng chỉ trả cho đúng phần mình dùng và có thể nhìn ra tiền đi đâu. Bản giải thích gốc gọi thẳng đây là "fine-grained billing … pay for what you use model".

Hai đáp án này bổ trợ nhau: C nói về cách đo và tính tiền, B nói về hệ quả khi ngừng dùng. Cùng nhau chúng mô tả trọn vẹn lợi thế chi phí của AWS cloud.

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

A — "Itemized power costs": hoá đơn AWS không có dòng nào ghi chi phí điện. Tiền điện, làm mát, nhà đặt máy đã nằm sẵn trong giá dịch vụ mà khách hàng trả. Phương án này gần đúng ở chỗ nó chạm vào ý "billing chi tiết", nhưng nó chi tiết hoá sai thứ: cái được liệt kê là dịch vụ đã dùng, không phải thành phần vận hành trung tâm dữ liệu. Đây là bẫy dễ nhầm với C nhất.

D — "Enterprise licensing discounts": AWS không bán hạ tầng theo kiểu chiết khấu giấy phép doanh nghiệp như các nhà cung cấp phần mềm truyền thống. Cách giảm chi phí trên AWS đến từ mô hình sử dụng và các cam kết dùng dài hạn, chứ không phải một chương trình "enterprise licensing discount". Phương án này đánh vào thói quen mua sắm IT cũ nên nghe quen tai, nhưng không mô tả đúng cách AWS định giá.

E — "One-off payments for on-demand resources": đây là phương án gần đúng nhất và cũng nguy hiểm nhất, vì nó trộn hai khái niệm. Trả tiền một lần trọn gói (all upfront) là hình thức có thật, nhưng thuộc về Reserved Instances — tức là đánh đổi bằng cam kết dùng trong một kỳ hạn. Còn on-demand thì theo định nghĩa là trả theo mức sử dụng thực tế, tính liên tục, không có kiểu thanh toán một lần rồi thôi. Ghép "one-off payment" vào "on-demand" là mâu thuẫn ngay trong chính phương án.

📌 Điểm cần nhớ

• Lợi thế chi phí cốt lõi của AWS cloud là pay-for-what-you-use: tính tiền chi tiết theo mức dùng, và ngừng dùng thì ngừng trả tiền.
• Hoá đơn AWS liệt kê dịch vụ đã dùng, không liệt kê chi phí vận hành trung tâm dữ liệu như điện hay làm mát — những khoản đó đã gộp trong giá.
• Phân biệt rõ on-demand (trả theo thực dùng, không cam kết) với Reserved Instances (cam kết kỳ hạn, có thể trả trước toàn bộ). Đề thi rất hay hoán đổi hai khái niệm này để tạo phương án nhiễu.
• Khi gặp câu "advantages in relation to cost", hãy chọn phát biểu mô tả mô hình tiêu dùng, đừng chọn phát biểu mô tả một chương trình chiết khấu hay một dòng kế toán không tồn tại trên hoá đơn.

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

Đề hỏi: Amazon EC2 Auto Scaling cung cấp kiểu scaling nào? Cụm từ quyết định là "type of scaling" gắn với tên dịch vụ EC2 Auto Scaling — câu này không hỏi "scaling policy" (target tracking, step, scheduled) mà hỏi chiều mở rộng: thêm/bớt máy, hay làm máy to ra.

Điểm phân biệt nằm ở chỗ bốn phương án không cùng một hệ quy chiếu. Chỉ có Vertical và Horizontal là hai chiều scaling thật sự trong từ vựng kiến trúc đám mây; Linear và Incremental là những từ mô tả tốc độ hay cách tăng dần của một đại lượng, không phải tên một kiểu scaling. Vì vậy bài toán rút gọn còn một câu hỏi: EC2 Auto Scaling phóng thêm và huỷ bớt instance, hay đổi kích thước instance đang chạy?

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

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

EC2 Auto Scaling hoạt động bằng cách launch thêm EC2 instance khi nhu cầu tăng và terminate bớt instance khi nhu cầu giảm, dựa trên tải thực tế của ứng dụng. Đơn vị mà nó thao tác là số lượng instance trong một Auto Scaling group, được điều khiển qua desired capacity nằm giữa minimum và maximum size. Thêm/bớt các máy giống nhau chạy song song chính là định nghĩa của horizontal scaling (scale out / scale in).

Đây cũng là lý do EC2 Auto Scaling gần như luôn đi kèm một load balancer: có nhiều instance thì phải có chỗ phân phối request giữa chúng, và instance mới phóng ra phải được đăng ký vào target group để nhận lưu lượng.

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

B — Vertical: đây là phương án gần đúng nhất, và cũng là bẫy chính. Vertical scaling (scale up / scale down) nghĩa là giữ nguyên số máy nhưng đổi sang instance type lớn hơn hoặc nhỏ hơn — nhiều CPU hơn, nhiều RAM hơn. EC2 có cho phép đổi instance type, nhưng đó là thao tác thủ công trên một instance đã stop, không phải việc EC2 Auto Scaling làm. Auto Scaling group không bao giờ tự nâng cấp kích thước một instance đang chạy; nó chỉ tăng giảm số lượng. Vertical hỏng ở chỗ nhầm đối tượng thao tác: kích thước máy thay vì số lượng máy.

A — Linear: không phải một kiểu scaling. "Linear" chỉ mô tả một dạng đồ thị tăng trưởng — tăng đều theo thời gian hoặc theo tải. Ngay cả khi một scaling policy tình cờ tạo ra đường tăng gần tuyến tính, đó vẫn là hình dạng của quá trình, không trả lời được câu hỏi "scaling theo chiều nào". Từ này không thuộc từ vựng chuẩn của AWS về scaling.

C — Incremental: cùng loại lỗi với "Linear". Nó chỉ nói rằng thay đổi diễn ra từng bước nhỏ một chứ không nói bước đó là thêm instance hay phóng to instance. Từ này nghe hợp lý vì Auto Scaling đúng là điều chỉnh dần dần chứ không nhảy vọt, nên rất dễ bị chọn nhầm; nhưng nó mô tả nhịp độ, không phải kiểu scaling. AWS không dùng "incremental scaling" như một thuật ngữ chính thức.

📌 Điểm cần nhớ

• Horizontal = thay đổi số lượng instance (scale out / scale in); Vertical = thay đổi kích thước một instance (scale up / scale down). Hỏi "EC2 Auto Scaling scaling kiểu gì" thì đáp án luôn là horizontal.
• EC2 Auto Scaling launch và terminate instance theo nhu cầu thực tế, điều khiển bằng bộ ba minimum / desired / maximum capacity của Auto Scaling group — nó không bao giờ tự đổi instance type.
• Trong đề trắc nghiệm, hãy loại ngay những phương án không phải thuật ngữ thật của lĩnh vực đang hỏi. "Linear" và "Incremental" nghe kỹ thuật nhưng không phải tên một kiểu scaling — chúng chỉ là distractor mô tả nhịp độ thay đổi.
• Horizontal scaling đi liền với load balancer: nhiều instance giống nhau chạy song song thì phải có nơi phân phối lưu lượng và đăng ký instance mới vào.