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

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

Đề mô tả một công ty đã triển khai hạ tầng trên AWS và cần một cơ sở dữ liệu phục vụ thao tác đọc với độ trễ dưới một phần nghìn giây cho các ứng dụng quan trọng.

Cụm từ quyết định đáp án là "reads with a latency of under a millisecond" (đọc với độ trễ dưới một mili-giây). Đây là ràng buộc duy nhất phân biệt bốn phương án. Chú ý hai chi tiết nhỏ trong cụm đó:

• "reads" — chỉ nói về đọc, không nói về ghi bền vững hay giao dịch. Bài toán nghiêng hẳn về phục vụ dữ liệu đọc lại nhiều lần.
• "under a millisecond" — mức này thấp hơn hẳn cái mà một cơ sở dữ liệu đọc từ đĩa (dù là SSD) qua đường mạng thông thường có thể hứa hẹn. Ở mức sub-millisecond, dữ liệu phải nằm sẵn trong bộ nhớ (in-memory).

Nói cách khác, đề không hỏi "cơ sở dữ liệu nào tốt", mà hỏi "dịch vụ nào lưu dữ liệu trong RAM".

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

Đáp án đúng theo tệp là C — Amazon ElastiCache.

ElastiCache là in-memory data store / cache được quản lý, dựng trên Redis hoặc Memcached mã nguồn mở. Vì toàn bộ dữ liệu phục vụ nằm trong bộ nhớ chứ không phải trên đĩa, nó đáp ứng đúng yêu cầu sub-millisecond latency cho các ứng dụng thời gian thực ở quy mô lớn — chính là điều đề bài đòi hỏi.

Một điểm cộng nữa mà phần giải thích gốc nhấn mạnh: vì ElastiCache tương thích với giao thức Redis/Memcached, ứng dụng đang dùng hai công cụ này có thể chuyển sang mà không phải sửa mã. Với đề thi Cloud Practitioner, chỉ cần ghi nhớ liên kết một chiều: hễ thấy chữ "in-memory", "caching" hay "sub-millisecond" thì nghĩ ngay tới ElastiCache.

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

A. Amazon RDS — đây là phương án gần đúng nhất và là bẫy chính của câu hỏi, vì RDS thật sự là một database service đúng như đề bài nói ("There must be a database"). Nhưng RDS là cơ sở dữ liệu quan hệ lưu dữ liệu trên đĩa (block storage), mỗi truy vấn phải qua tầng lưu trữ và tầng xử lý SQL. Nó phù hợp cho dữ liệu giao dịch có cấu trúc, độ trễ tính bằng vài mili-giây trở lên — không đạt được mốc dưới một mili-giây mà đề yêu cầu. Đúng chủng loại nhưng sai bậc hiệu năng, và bậc hiệu năng mới là thứ đề đang hỏi.

B. Amazon EMR — là nền tảng big data được quản lý, dùng để chạy các khung xử lý như Hadoop/Spark trên cụm máy, phục vụ phân tích lô (batch) trên khối dữ liệu lớn. Bản chất công việc của EMR là xử lý hàng loạt, thời gian trả kết quả tính bằng giây, phút hoặc lâu hơn. Nó không phải một cơ sở dữ liệu phục vụ truy vấn độ trễ thấp cho ứng dụng đang chạy.

D. AWS Glue — là dịch vụ ETL (extract–transform–load) không máy chủ, dùng để khám phá, chuẩn bị và chuyển đổi dữ liệu giữa các nguồn, kèm data catalog. Glue không lưu trữ dữ liệu để phục vụ đọc — nó là khâu di chuyển và biến đổi dữ liệu trong đường ống, chạy theo job chứ không đáp ứng từng request của ứng dụng. Hoàn toàn sai vai trò với yêu cầu của đề.

📌 Điểm cần nhớ

• "Sub-millisecond" / "in-memory" / "caching" → ElastiCache. Đây gần như là một phản xạ có điều kiện trong đề thi AWS; không dịch vụ nào khác trong danh sách này lưu dữ liệu phục vụ trong RAM.
• "Là database" chưa đủ, phải xét mức độ trễ. RDS đúng chủng loại nhưng vẫn sai, vì ràng buộc thật nằm ở con số hiệu năng chứ không ở nhãn "database".
• Phân biệt vai trò dịch vụ trước khi so hiệu năng: ElastiCache = lưu trữ để đọc nhanh; RDS = cơ sở dữ liệu quan hệ có giao dịch; EMR = xử lý big data theo lô; Glue = ETL/chuẩn bị dữ liệu. Ba cái sau không đứng ở tuyến phục vụ request của ứng dụng.
• ElastiCache có hai engine — Redis và Memcached — tương thích giao thức, nên ứng dụng đang dùng chúng chuyển sang không cần đổi mã. Đề hay dùng chi tiết "no code changes" làm dấu hiệu nhận biết.

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

Đề hỏi: lợi ích của việc dùng reserved instances là gì? (Chọn HAI).

Cụm từ quyết định đáp án nằm gọn trong hai chữ "reserved instances" — đây là một pricing model (mô hình giá) của EC2, không phải một loại hạ tầng riêng và cũng không phải một kiến trúc triển khai. Người học chọn sai vì trộn lẫn ba khái niệm nghe na ná nhau trong AWS:

• Reserved Instances — cam kết dùng trong một kỳ hạn (1 hoặc 3 năm) để đổi lấy giá rẻ hơn.
• Dedicated Instances / Dedicated Hosts — chạy trên phần cứng vật lý riêng, không chia sẻ với khách hàng khác.
• Multi-AZ / Auto Scaling / load balancer — những thứ thật sự tạo ra high availability.

Khi đề chỉ nói "reserved", mọi lợi ích phải suy ra từ bản chất cam kết trả tiền trước, chứ không phải từ vị trí đặt máy hay cách phân bổ máy.

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

Đáp án đúng theo tệp là A (Reserve capacity) và B (Reduced cost).

B – Reduced cost: đây là lý do tồn tại của reserved instances. Bạn cam kết một kỳ hạn (1 năm hoặc 3 năm) và đổi lại nhận mức giá thấp hơn đáng kể so với on-demand. Đây là một trong những đòn bẩy tối ưu chi phí kinh điển được nhắc tới trong mảng AWS Cost Management của kỳ thi.

A – Reserve capacity: ngoài chuyện giảm giá, reserved instances còn cho phép giữ chỗ năng lực tính toán trong một availability zone. Nghĩa là khi bạn cần khởi chạy instance đúng loại đó trong AZ đã đặt chỗ, capacity đã được dành sẵn cho bạn thay vì phải tranh với những khách hàng khác đang xin on-demand cùng lúc. Với ứng dụng phải chắc chắn khởi chạy được vào giờ cao điểm, đây là lợi ích thật, tách bạch hẳn với chuyện tiền nong.

Hai lợi ích này chính là hai vế mà đề đang yêu cầu chọn.

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

C – High availability: đây là phương án gần đúng nhất và cũng gây nhầm nhiều nhất, vì "reserve capacity" nghe như "luôn có máy chạy". Nhưng high availability đến từ kiến trúc: trải instance qua nhiều availability zone, đặt sau load balancer, dùng Auto Scaling để thay thế instance hỏng. Reserved instances không tự động làm bất kỳ điều nào trong số đó — nó chỉ đổi cách bạn bị tính tiền cho một instance. Bạn hoàn toàn có thể mua reserved instance rồi chạy đúng một máy trong đúng một AZ, và kiến trúc đó không hề có tính sẵn sàng cao.

D – More flexibility: sai theo đúng chiều ngược lại — reserved instances giảm tính linh hoạt chứ không tăng. Bạn đang cam kết một kỳ hạn dài, và tùy loại reservation mà bị ràng buộc thêm về loại instance hoặc vùng. Nếu điều bạn cần là tự do bật/tắt và đổi cấu hình bất cứ lúc nào thì on-demand mới là lựa chọn đúng, đổi lại giá đắt hơn. Đề bài hỏi "benefits", mà đây là cái giá phải trả, không phải lợi ích.

E – Uses dedicated hardware: nhầm sang một họ khái niệm khác. Dedicated Instances và Dedicated Hosts mới là thứ chạy trên phần cứng vật lý không chia sẻ, thường dùng khi có yêu cầu tuân thủ hoặc ràng buộc bản quyền phần mềm. Reserved instances vẫn chạy trên hạ tầng dùng chung bình thường — chỗ khác biệt duy nhất so với on-demand là hóa đơn. Hai chữ "reserved" và "dedicated" gần nhau trong tiếng Anh nhưng trong AWS là hai thứ hoàn toàn tách biệt.

📌 Điểm cần nhớ

• Reserved instances là một pricing model, không phải một tính năng hạ tầng. Mọi lợi ích của nó phải quy về hai thứ: giá rẻ hơn nhờ cam kết kỳ hạn, và giữ chỗ capacity trong AZ.
• Phân biệt ba chữ dễ lẫn: reserved = cách tính tiền; dedicated = phần cứng riêng (Dedicated Instances/Hosts); multi-AZ + load balancer + Auto Scaling = high availability.
• Đánh đổi cố định trong mảng pricing: cam kết dài hạn thì rẻ hơn nhưng kém linh hoạt; on-demand thì linh hoạt nhưng đắt hơn. Thấy phương án ghi "more flexibility" cho reserved là loại được ngay.
• Trong câu hỏi Cost Management, hãy hỏi: "lợi ích này đến từ hóa đơn hay từ kiến trúc?" — nếu nó đến từ kiến trúc thì gần như chắc chắn không phải lợi ích của một mô hình giá.

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

Đề mô tả một công ty đang phát triển ứng dụng web mới, và nêu rõ một yêu cầu bắt buộc: "Logging into the application through a social identity provider is a must have requirement" — người dùng phải đăng nhập được bằng social identity provider (Facebook, Google, Apple, Amazon...).

Cụm từ quyết định ở đây là "social identity provider" kết hợp với "web application". Hai chi tiết này gộp lại chỉ đúng một hướng: cần dịch vụ quản lý danh tính cho người dùng cuối của ứng dụng (application users), không phải cho nhân viên hay cho tài nguyên AWS.

Đây chính là ràng buộc phân biệt bốn phương án — cả bốn đều là dịch vụ identity, nhưng chúng phục vụ ba nhóm người dùng khác nhau:

• người dùng cuối của app (khách vãng lai, người đăng ký tài khoản)
• nhân viên/workforce của công ty
• danh tính nội bộ dùng để gọi API AWS

Ai đọc lướt và chỉ thấy chữ "login" sẽ dễ chọn nhầm sang các phương án SSO hoặc IAM.

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

Đáp án đúng: B — Amazon Cognito.

Amazon Cognito được thiết kế đúng cho bài toán này: thêm chức năng sign-up, sign-in và access control vào web app và mobile app. Cognito hỗ trợ đăng nhập trực tiếp qua các social identity provider như Apple, Facebook, Google và Amazon, đồng thời cũng hỗ trợ enterprise identity provider qua SAML 2.0 và OpenID Connect.

Nói cách khác, Cognito là dịch vụ AWS đứng ở đúng vị trí mà đề cần: giữa người dùng cuối và ứng dụng web, lo phần federation với bên thứ ba, và có khả năng mở rộng tới lượng người dùng rất lớn của một ứng dụng công khai. Yêu cầu "must have" về social login được đáp ứng nguyên bản, không cần tự viết thêm lớp tích hợp nào.

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

A — AWS Identity and Access Management (IAM). Đây là phương án gây nhầm nhất vì tên nó có chữ "Identity". Nhưng IAM quản lý danh tính nội bộ trong tài khoản AWS: user, group, role, policy để cấp quyền truy cập tài nguyên AWS. IAM không cấp quyền cho bên thứ ba bên ngoài, và nó không phải nơi để hàng nghìn người dùng cuối của một web app tạo tài khoản và đăng nhập bằng Facebook. IAM giải quyết "ai được gọi API AWS nào", còn đề đang hỏi "người dùng web app đăng nhập thế nào".

C — AWS Single Sign-On. Cũng rất gần, vì đúng là dịch vụ đăng nhập. Chỗ nó hỏng là đối tượng phục vụ: AWS SSO dùng để tạo hoặc kết nối workforce identity — danh tính nhân viên — rồi quản lý quyền truy cập tập trung trên toàn bộ AWS Organization. Nó nhắm vào nhân viên truy cập tài khoản AWS và ứng dụng doanh nghiệp, không cho phép người dùng đăng nhập qua social identity provider như đề yêu cầu. Đề nói rõ đây là ứng dụng web đang được phát triển, người dùng đăng nhập bằng tài khoản mạng xã hội, chứ không phải nhân viên vào console.

D — AWS Directory Service. AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) cho phép các workload và tài nguyên AWS phụ thuộc directory sử dụng Active Directory được quản lý trên AWS. Nó có liên quan tới permission và authorization, nhưng bản chất là directory doanh nghiệp kiểu Active Directory — không phải cơ chế federation với social identity provider cho người dùng cuối của một web app.

📌 Điểm cần nhớ

• Với các câu identity của AWS, hãy hỏi trước: người đăng nhập là ai? Người dùng cuối của app → Amazon Cognito. Nhân viên/workforce → AWS Single Sign-On. Danh tính gọi API và truy cập tài nguyên AWS → IAM. Workload cần Active Directory → AWS Directory Service.
• Từ khoá "social identity provider" (Facebook, Google, Apple, Amazon) trong đề gần như luôn trỏ thẳng tới Amazon Cognito.
• "Identity" trong tên IAM là bẫy quen thuộc: IAM dành cho danh tính bên trong tài khoản AWS, không phải nơi quản lý tài khoản người dùng cuối của ứng dụng.
• Ngoài social login, Cognito còn hỗ trợ enterprise identity provider qua SAML 2.0 và OpenID Connect — nên đề nhắc tới hai chuẩn này trong ngữ cảnh ứng dụng web/mobile cũng vẫn là Cognito.

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

Đề hỏi: dịch vụ AWS nào giúp triển khai thay đổi cấu hình ứng dụng (application configuration changes), kèm hai đặc điểm cụ thể — validation checks (kiểm tra tính hợp lệ của cấu hình trước khi áp) và triển khai đúng lúc — mà không phải viết thêm code, cũng không phải khởi động lại dịch vụ ứng dụng.

Cụm từ quyết định đáp án là "application configuration changes ... without writing additional code or restarting application services". Hai vế này lọc rất mạnh:

• "configuration changes" chứ không phải "infrastructure resources", cũng không phải "source code" — nên mọi dịch vụ lo hạ tầng hay lo kho mã đều lệch chủ đề.
• "without restarting application services" nghĩa là cấu hình phải đổi được trong lúc ứng dụng đang chạy, ứng dụng tự nhận giá trị mới. Đây là đặc trưng của dynamic configuration, không phải của quy trình deploy lại hạ tầng hay build lại ứng dụng.
• "validation checks" ám chỉ dịch vụ có bước xác thực dữ liệu cấu hình trước khi phát ra ngoài, để một giá trị sai không làm sập ứng dụng.

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

A — AWS AppConfig là dịch vụ chuyên trách việc quản lý và phát hành cấu hình ứng dụng. Nó khớp trọn ba yêu cầu trong đề:

• Cho phép triển khai thay đổi cấu hình một cách nhanh và có kiểm soát, không đòi viết thêm code để tự dựng cơ chế đọc/nạp cấu hình, và không cần restart dịch vụ — ứng dụng lấy được cấu hình mới trong lúc vẫn đang chạy.
• Hỗ trợ validation checks để bảo đảm dữ liệu cấu hình đúng cả về cú pháp lẫn ngữ nghĩa trước khi được triển khai, nhờ đó tránh được sự cố do một giá trị cấu hình hỏng.
• Việc phát hành diễn ra theo tiến trình có kiểm soát chứ không phải đổi đồng loạt tức thì, đúng với ý "timely deployment" trong đề.

Đây chính là bài toán mà AppConfig sinh ra để giải: tách cấu hình khỏi mã nguồn, và đổi cấu hình mà không đụng tới vòng đời của ứng dụng.

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

B — AWS CloudFormation. Đây là phương án gần đúng nhất và cũng dễ nhầm nhất, vì CloudFormation cũng dùng file văn bản để mô tả và triển khai một cách tự động. Nhưng thứ nó mô hình hoá và cung cấp là tài nguyên hạ tầng cần cho ứng dụng, chứ không phải cấu hình bên trong ứng dụng đang chạy. Nó không có cơ chế validation dành riêng cho dữ liệu cấu hình ứng dụng như tình huống mô tả, và thay đổi qua CloudFormation thường kéo theo cập nhật/thay thế tài nguyên — trái hẳn với ràng buộc "không restart dịch vụ".

C — AWS CodeCommit. Đây là dịch vụ source control do AWS vận hành, dùng để lưu trữ và quản lý mã nguồn cùng các tài sản khác một cách riêng tư trên cloud. Nó là nơi cất giữ phiên bản, không phải nơi triển khai cấu hình ra ứng dụng đang chạy. Có thể để file cấu hình trong repo, nhưng bản thân CodeCommit không phát cấu hình đó tới ứng dụng, không có validation check khi phát hành, và tất nhiên không giải quyết chuyện restart.

D — AWS CodeStar. Nó cung cấp một giao diện hợp nhất để quản lý các hoạt động phát triển phần mềm ở cùng một chỗ. Đây là lớp gom nhóm/điều phối cho quy trình phát triển, không phải dịch vụ chuyên xử lý việc triển khai thay đổi cấu hình ứng dụng với các đặc điểm mà đề nêu. Nó lệch cả về đối tượng (quy trình dev, không phải cấu hình runtime) lẫn về tính năng (không có validation cho dữ liệu cấu hình).

📌 Điểm cần nhớ

• Bắt từ khoá theo đối tượng bị thay đổi: "application configuration" → AppConfig; "infrastructure resources / stack" → CloudFormation; "source code repository" → CodeCommit; "unified interface for development activities" → CodeStar.
• Ràng buộc "không restart / không viết thêm code" gần như luôn trỏ tới dynamic configuration, tức là AppConfig, chứ không phải bất kỳ dịch vụ deploy hạ tầng nào.
• Validation trước khi phát hành là điểm bán hàng riêng của AppConfig trong nhóm bốn dịch vụ này — mục đích là chặn cấu hình sai gây gián đoạn ngay từ trước khi nó đến tay ứng dụng.
• Đừng để chữ "deploy" đánh lừa: cả bốn dịch vụ đều dính tới chữ đó theo cách nào đó, nên phải đọc tiếp xem cái gì được deploy thì mới phân biệt được.

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

Đề hỏi: phương thức xác thực nào được dùng cho các lời gọi mang tính lập trình (programmatic calls) tới các dịch vụ AWS?

Cụm từ quyết định đáp án là "programmatic calls" — tức là gọi tới AWS bằng API, AWS CLI hoặc SDK, chứ không phải con người ngồi gõ tay đăng nhập vào giao diện web. Cả bốn phương án đều là những thứ có thật trong AWS và đều liên quan tới "xác thực" theo nghĩa nào đó, nên nếu chỉ đọc lướt thì phương án nào cũng có vẻ hợp lý. Ràng buộc phân biệt nằm ở chỗ: mỗi loại thông tin xác thực (credential) trong AWS phục vụ một kênh truy cập riêng, và đề đang chỉ đích danh kênh API/CLI/SDK.

Hãy ghim vào đầu cặp đối lập kinh điển mà đề đang khai thác: người dùng đăng nhập Console ↔ chương trình gọi API. Xác định được đề đang nói về vế nào là chọn xong đáp án.

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

Đáp án đúng là B — Access keys.

Access key là một cặp gồm access key ID và secret access key. Đây chính là loại credential mà AWS CLI, các AWS SDK và mọi lời gọi trực tiếp tới AWS API sử dụng để ký request và chứng minh danh tính của người gọi. Khi bạn cấu hình aws configure, thứ bạn nhập vào chính là cặp khoá này; khi ứng dụng dùng SDK để gọi S3, DynamoDB hay EC2 API, request cũng được ký bằng cặp khoá đó.

Nói gọn: access key = danh tính dành cho máy/chương trình, đúng với cụm "programmatic calls" trong đề.

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

A — Console password. Đây là phương án gần đúng nhất và cũng là bẫy chính. Console password đúng là một credential hợp lệ của IAM user, nhưng nó chỉ phục vụ một mục đích duy nhất: cho người dùng đăng nhập vào AWS Management Console qua trình duyệt. Nó không được dùng để ký các lời gọi API. Một IAM user hoàn toàn có thể chỉ có password mà không có access key (chỉ vào được Console), hoặc chỉ có access key mà không có password (chỉ gọi được API) — điều này cho thấy hai loại credential là hai kênh tách bạch. Đề hỏi kênh lập trình, nên password bị loại.

C — Server certificate. Server certificate liên quan tới việc thiết lập kết nối HTTPS/TLS — nó chứng minh danh tính của máy chủ với client và mã hoá đường truyền. Đúng là các lời gọi tới AWS đi qua HTTPS, nhưng đó là lớp bảo mật ở tầng vận chuyển, không phải cơ chế xác định "ai đang gọi" và "người đó được phép làm gì" trong AWS. Certificate không thay thế được access key trong việc ký request API.

D — Key pair. Đây là phương án dễ nhầm nhất về mặt tên gọi — "key pair" nghe rất giống "access key" vì cả hai đều là "khoá" và đều đi theo cặp. Nhưng key pair (public key + private key) trong AWS gắn với việc truy cập vào bên trong EC2 instance: bạn dùng private key để SSH vào Linux instance hoặc để giải mã mật khẩu Administrator của Windows instance. Đó là xác thực với hệ điều hành chạy trên instance, không phải xác thực với AWS API. Bạn không thể dùng EC2 key pair để gọi lệnh AWS CLI. Chính vì cái tên na ná nhau mà đề thi rất hay đặt hai phương án này cạnh nhau.

📌 Điểm cần nhớ

• "Programmatic access / programmatic calls / API / CLI / SDK" → access keys. Thấy bất kỳ cụm nào trong nhóm này là nghĩ ngay tới cặp access key ID + secret access key.
• "Console / sign in / trình duyệt" → username + password (kèm MFA nếu bật). Đây là kênh dành cho người, tách hoàn toàn khỏi kênh dành cho chương trình.
• Đừng lẫn "key pair" với "access key". Key pair là để vào trong EC2 instance (SSH / lấy mật khẩu Windows); access key là để gọi dịch vụ AWS.
• Server certificate thuộc tầng TLS, lo việc mã hoá và xác thực máy chủ, không phải cơ chế xác định danh tính người gọi trong IAM.

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

Đề hỏi dịch vụ AWS nào cung cấp một IDE (integrated development environment) chạy trên nền cloud, cho phép viết, chạy và gỡ lỗi mã với chỉ một trình duyệt, không phải cài phần mềm và không phải cấu hình máy chủ.

Cụm từ quyết định đáp án là "integrated development environment (IDE)" đi kèm "write, run, and debug your code with just a browser". Đây là ba động tác của một môi trường lập trình, không phải của một máy ảo desktop hay một dịch vụ build tự động. Vế "without needing to install any software" loại tiếp những phương án bắt người dùng dựng sẵn một máy hoặc cài công cụ lên đó.

Nói cách khác, đề mô tả đúng một thứ: trình soạn thảo mã + terminal + debugger, truy cập qua browser. Ai đọc lướt và chỉ bắt được chữ "developer" hay "code" sẽ dễ chọn nhầm sang nhóm dịch vụ CI/CD trong họ AWS Code*.

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

C — AWS Cloud9 là dịch vụ cung cấp đúng một cloud-based IDE. Nó chạy hoàn toàn trong trình duyệt: có trình soạn thảo mã, terminal, và debugger tích hợp sẵn. Người dùng mở Cloud9 lên là code được ngay, không cần cài IDE lên máy cá nhân, không cần tự cấu hình môi trường phát triển trên một server.

Ba yêu cầu trong đề khớp một-một với ba khả năng của Cloud9: write (editor), run (terminal/môi trường thực thi), debug (debugger). Không phương án nào khác gom đủ cả ba trong một giao diện web.

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

A — Amazon WorkSpaces: đây là dịch vụ Desktop-as-a-Service (DaaS) — cung cấp một máy tính để bàn ảo được quản lý, truy cập từ xa. Phương án này gần đúng ở chỗ "không cần cài gì trên máy bạn", nhưng nó hỏng ở chỗ: WorkSpaces đưa cho bạn một desktop, chứ bản thân nó không phải là một IDE. Muốn code trên WorkSpaces, bạn vẫn phải tự cài IDE vào cái desktop ảo đó — tức là vẫn vướng đúng ràng buộc "without needing to install any software" mà đề nêu ra. WorkSpaces phục vụ nhu cầu máy trạm doanh nghiệp nói chung, không phải riêng việc phát triển phần mềm.

B — AWS CodeStar: đây là phương án gây nhiễu mạnh nhất, vì nó cũng dành cho developer và cũng giúp nhanh chóng phát triển, build, deploy ứng dụng trên AWS. Nhưng vai trò của nó là gom nhóm và điều phối — dựng sẵn khung dự án, gắn kết các công cụ CI/CD và quản lý dự án lại một chỗ, kèm dashboard theo dõi. Nó không tự cung cấp môi trường soạn thảo và gỡ lỗi mã trong trình duyệt. Việc viết và debug code vẫn phải làm ở một IDE khác. CodeStar là lớp quản lý dự án, không phải nơi bạn gõ từng dòng mã.

D — AWS CodeBuild: là dịch vụ continuous integration được quản lý hoàn toàn — biên dịch mã nguồn, chạy test, và tạo ra gói phần mềm sẵn sàng deploy. Nó có "run" theo nghĩa chạy build, nhưng đó là chạy tự động theo kịch bản đã khai báo, không phải người lập trình ngồi tương tác. CodeBuild không có editor và không có debugger tương tác; bạn không mở CodeBuild ra để gõ code. Nó nằm ở giai đoạn sau khi mã đã viết xong và được đẩy lên repository.

📌 Điểm cần nhớ

• Thấy cụm "IDE" + "write, run, and debug" + "just a browser" trong đề thi AWS thì gần như chắc chắn đáp án là AWS Cloud9 — đây là dịch vụ duy nhất trong danh sách được định vị làm môi trường phát triển.
• Phân biệt rõ ba lớp trong vòng đời phát triển: Cloud9 là nơi viết mã; CodeBuild là nơi biên dịch và kiểm thử tự động; CodeStar là lớp điều phối gộp các công cụ đó lại. Đề nhấn vào động tác nào thì chọn theo lớp đó.
• Amazon WorkSpaces cho bạn một desktop ảo, không cho bạn một IDE. "Không cần cài gì trên laptop" và "không cần cài gì cả" là hai điều khác nhau — WorkSpaces chỉ thoả vế đầu.
• Trong nhóm dịch vụ tên bắt đầu bằng AWS Code*, hãy đọc kỹ động từ trong đề (build, deploy, quản lý dự án, lưu trữ mã) thay vì chọn theo cảm giác "dành cho lập trình viên" — chúng phục vụ những giai đoạn khác nhau và đề thường cố tình xếp nhiều dịch vụ cùng họ vào chung một câu.

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

Đề bài đặt trong bối cảnh CTO muốn chuyển hệ thống lên cloud, và hỏi: lợi thế về chi phí (cost advantages) của việc chuyển lên cloud là gì.

Cụm từ quyết định ở đây là "cost advantages" — nghĩa là phương án đúng phải là một lợi ích thực sự thuộc về mô hình chi phí của cloud, chứ không phải một lời hứa hẹn chung chung hay một khoản chi phí bị hiểu nhầm là được miễn. Đây là dạng câu rất hay gặp trong AWS Certified Cloud Practitioner: đề đưa ra bốn câu nghe đều "có vẻ tốt cho túi tiền", nhưng ba trong số đó mô tả những thứ cloud không hề miễn cho bạn.

Ràng buộc phân biệt thứ hai nằm ở chỗ phương án đúng phải gắn với mô hình pay-as-you-go — trả tiền theo mức dùng thật, và điều chỉnh tài nguyên theo nhu cầu. Cứ phương án nào nói tới việc "được miễn phí" một khoản gì đó, hãy nghi ngờ ngay.

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

D — "You provision only what you need and adjust to peak load" là đáp án đúng.

Đây chính là mô tả gọn nhất của lợi thế chi phí cốt lõi khi dùng cloud. Trong mô hình on-premises, bạn phải mua sẵn phần cứng đủ để chịu được peak load — tức là mức tải cao nhất có thể xảy ra trong năm — rồi để phần lớn công suất đó nằm không suốt thời gian còn lại. Tiền đã bỏ ra rồi thì không lấy lại được, dù máy chạy 5% hay 95% công suất.

Trên cloud, bạn provision đúng lượng tài nguyên đang cần, và khi nhu cầu tăng thì mở rộng thêm, khi nhu cầu giảm thì thu lại. Vì tính tiền theo mức sử dụng thực tế, chi phí đi theo sát đường cong nhu cầu thay vì phải bám theo đỉnh của nó. Đúng như phần giải thích gốc nêu: bạn chỉ trả tiền cho những gì mình đang dùng.

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

A — "You can reduce your marketing costs": Marketing là hoạt động kinh doanh, không liên quan gì tới nơi hệ thống CNTT của bạn chạy. Chuyển workload lên cloud không làm tổ chức bớt phải làm marketing đi, nên khoản chi này giữ nguyên. Phương án này thậm chí không nằm cùng phạm trù với câu hỏi — nó là một khoản chi phí doanh nghiệp, không phải chi phí hạ tầng.

B — "You don't need to pay for application licensing": Đây là phương án gây nhầm nhiều nhất, vì nó gần đúng một nửa. Cloud có thay đổi cách bạn trả tiền license — một số AMI trên Amazon EC2 đã gộp sẵn license vào giá theo giờ, nên bạn không phải mua license riêng trả trước. Nhưng "thay đổi cách trả" không phải là "không phải trả". Khi chạy phần mềm có bản quyền trên EC2, chi phí license vẫn còn đó, chỉ là nằm trong hóa đơn theo giờ hoặc được mang sang từ license bạn đã sở hữu. Câu khẳng định tuyệt đối "don't need to pay" vì thế là sai.

C — "You get free data transfer into and out of the cloud": Sai vì chữ "and out of". Chiều dữ liệu đi vào AWS thường không bị tính phí, nên nửa đầu câu nghe hợp lý — và đây chính là cái bẫy. Nhưng dữ liệu đi ra khỏi cloud (outbound data transfer) là một khoản AWS có tính phí. Phương án gộp cả hai chiều vào một chữ "free" nên phá vỡ ở nửa sau. Muốn phương án này đúng thì nó phải chỉ nói về chiều inbound.

📌 Điểm cần nhớ

• Lợi thế chi phí đặc trưng nhất của cloud là pay-as-you-go: provision đúng nhu cầu và co giãn theo tải, thay vì mua sẵn hạ tầng đủ chịu peak load rồi để dư thừa. Gặp câu hỏi về "cost advantage", hãy tìm phương án mang ý này.
• Cảnh giác với mọi phương án chứa từ "free" hoặc "don't need to pay". Cloud dịch chuyển chi phí từ CapEx sang OpEx, chứ hiếm khi xóa hẳn một loại chi phí.
• Với data transfer, ghi nhớ theo hướng: chiều vào và chiều ra được đối xử khác nhau. Một phương án gộp cả hai chiều thành "miễn phí" gần như luôn sai.
• License phần mềm vẫn theo bạn lên cloud. Cái thay đổi là hình thức thanh toán (gộp theo giờ, hoặc mang license sẵn có sang), không phải sự tồn tại của khoản chi đó.

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

Đề hỏi: IAM entity nào dùng để gán quyền (permissions) cho nhiều user cùng lúc?

Cụm từ quyết định nằm ở cuối câu: "multiple users" — gán quyền cho nhiều người dùng, chứ không phải cho một người dùng, cũng không phải cho một service hay một phiên làm việc tạm thời. Chỉ cần nắm cụm đó là bốn phương án tách hẳn ra:

• Cái nào đại diện cho một tập hợp user? → đúng
• Cái nào chỉ đại diện một danh tính đơn lẻ? → sai vì không "multiple"
• Cái nào không gán permissions cho user chút nào? → sai vì sai luôn bản chất

Ràng buộc thứ hai, mờ hơn nhưng vẫn quan trọng: đề nói "assigning permissions" — tức là quyền đính kèm thường trực vào danh tính, chứ không phải quyền có được sau khi thực hiện một thao tác bổ sung.

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

Đáp án đúng theo tệp: C — IAM Group.

IAM Group là một tập hợp các IAM user, và policy được gắn (attach) thẳng vào group. Cách làm chuẩn là: tạo group → đưa các user vào group → viết IAM policy với quyền cần thiết → attach policy vào group. Mọi user nằm trong group lập tức thừa hưởng quyền đó.

Đây chính là cơ chế được sinh ra để giải bài toán "một policy, nhiều user": thay vì attach cùng một policy vào từng user một (rồi phải nhớ sửa từng chỗ khi quyền thay đổi), ta sửa đúng một chỗ trên group. Thêm người mới vào team thì chỉ cần bỏ họ vào group, quyền tự có; người rời đi thì gỡ khỏi group, quyền tự mất.

Group cũng khớp với vế "assigning permissions": quyền là thường trực với mọi thành viên, không cần thao tác nào thêm.

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

A — IAM Role. Đây là phương án gần đúng nhất và là bẫy chính của câu này. Role có gắn permission policy, và nhiều danh tính khác nhau có thể dùng chung một role. Nhưng role hỏng ở chỗ: nó không phải là một tập hợp user, và quyền của role không được "gán cho user" theo nghĩa thường trực — người dùng phải assume role, nhận credential tạm thời, rồi mới có quyền đó trong phiên làm việc. Role sinh ra chủ yếu cho việc uỷ quyền tạm thời: cho AWS service, cho ứng dụng chạy trên EC2, cho danh tính từ hệ thống bên ngoài. Đề hỏi entity nào dùng để gán quyền cho nhiều user, và câu trả lời chuẩn mực cho ý đó là group, không phải role.

B — IAM password policy. Sai về bản chất, không liên quan tới permissions. Password policy quy định yêu cầu đối với mật khẩu của user trong tài khoản: độ dài tối thiểu, có bắt buộc chữ hoa/số/ký tự đặc biệt hay không, có bắt đổi mật khẩu định kỳ hay không. Nó đúng là áp cho nhiều user thật — đó là lý do phương án này được đặt vào đây — nhưng nó kiểm soát cách đăng nhập, chứ không cấp cho ai quyền gọi API hay truy cập tài nguyên nào cả.

D — IAM User. IAM User đại diện cho đúng một danh tính — một người hoặc một ứng dụng. Bạn có thể attach policy trực tiếp vào user, nhưng policy đó chỉ có tác dụng với riêng user đó. Muốn nhiều người có cùng quyền thì phải lặp lại thao tác cho từng user, đúng thứ mà câu hỏi đang muốn tránh. Trực tiếp trái với chữ "multiple" trong đề.

📌 Điểm cần nhớ

• Group = gán quyền cho nhiều user cùng lúc. Thấy "multiple users", "a team", "a set of users" kèm "permissions" trong đề IAM thì group gần như luôn là đáp án.
• Group vs Role: group gom user và cấp quyền thường trực; role được assume để nhận quyền tạm thời, và thường dùng cho service hoặc danh tính bên ngoài. Đọc kỹ xem đề nói "users" hay "service/application/temporary access".
• Password policy không phải permission. Nó thuộc nhóm kiểm soát đăng nhập (cùng họ với MFA), không cấp quyền truy cập tài nguyên.
• User là danh tính đơn lẻ. Attach policy trực tiếp vào user thì chạy được nhưng không mở rộng được — practice khuyến nghị là attach vào group rồi bỏ user vào group.

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

Đề hỏi: AWS Global Infrastructure gồm những thành phần nào? Câu hỏi chỉ chọn một đáp án.

Cụm từ quyết định là "Global Infrastructure". Đây là thuật ngữ có nghĩa hẹp và cố định trong AWS: nó chỉ hạ tầng vật lý toàn cầu mà AWS xây dựng và vận hành — Regions, Availability Zones, Edge Locations/Points of Presence, Local Zones... Nó không phải là "danh sách các dịch vụ AWS".

Đây chính là cái bẫy của câu này: ba phương án còn lại đều là tên dịch vụ AWS thật, hoàn toàn hợp lệ và quen thuộc, nên người học dễ nghĩ "cái nào cũng là AWS cả". Nhưng "là một dịch vụ của AWS" khác hẳn "là một thành phần cấu tạo nên hạ tầng toàn cầu của AWS". Đọc kỹ hai chữ Infrastructure là loại được ngay ba phương án kia.

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

B — AWS Regions.

Region là một vị trí địa lý vật lý trên thế giới, nơi AWS gom cụm nhiều Availability Zone lại. Mỗi Region gồm nhiều AZ tách biệt, cô lập với nhau và cách xa nhau về mặt vật lý trong cùng một khu vực địa lý. Region chính là đơn vị cấu thành cơ bản nhất của AWS Global Infrastructure — khi bạn chọn nơi triển khai tài nguyên, chọn nơi lưu dữ liệu để đáp ứng yêu cầu chủ quyền dữ liệu, hay thiết kế kiến trúc chịu lỗi, bạn đang làm việc trực tiếp với khái niệm này.

Region là hạ tầng, không phải dịch vụ bạn "bật lên dùng". Đó là điểm phân biệt nó với cả ba phương án còn lại.

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

A — Amazon Alexa. Đây là công nghệ trợ lý ảo (virtual assistant), thuộc nhóm sản phẩm tương tác giọng nói của Amazon. Nó chạy trên hạ tầng AWS chứ không phải là một phần cấu tạo nên hạ tầng đó. Phương án này thường dễ loại nhất vì Alexa còn nổi tiếng ở mảng thiết bị tiêu dùng hơn là mảng cloud.

C — Amazon Lightsail. Đây là phương án gần đúng nhất và cũng dễ gây nhầm nhất, vì Lightsail cung cấp virtual private server (VPS) — nghe rất "hạ tầng". Lightsail là cách đơn giản nhất để bắt đầu với AWS dành cho lập trình viên, doanh nghiệp nhỏ, sinh viên và những ai cần một giải pháp gọn nhẹ để dựng và host ứng dụng trên cloud. Chỗ nó hỏng: Lightsail là một dịch vụ compute mà khách hàng thuê, được đặt trong các Region của AWS. Nó là thứ tiêu thụ hạ tầng, không phải thứ tạo nên hạ tầng. Nhớ nguyên tắc: nếu bạn phải vào console bật nó lên và trả tiền theo tài nguyên đã tạo, thì đó là dịch vụ chứ không phải Global Infrastructure.

D — AWS Organizations. Đây là công cụ quản trị nhiều tài khoản dưới một tài khoản gốc (root account) — dùng để gom tài khoản thành organization, áp chính sách chung, gộp hoá đơn. Đây thuần tuý là lớp quản lý và quản trị (governance), hoàn toàn mang tính logic, không liên quan gì tới máy chủ, trung tâm dữ liệu hay vị trí địa lý. Không phải một phần của Global Infrastructure.

📌 Điểm cần nhớ

• AWS Global Infrastructure = hạ tầng vật lý: Regions và các Availability Zone bên trong chúng, cùng mạng lưới edge. Đề nhắc "Global Infrastructure" thì chỉ tìm các phương án mang tính địa lý/vật lý, bỏ qua mọi tên dịch vụ.
• Region là cụm các AZ trong một khu vực địa lý, các AZ cô lập và tách biệt vật lý với nhau — đây là nền tảng cho mọi thiết kế high availability trong AWS.
• Phân biệt "dịch vụ chạy trên hạ tầng" với "chính hạ tầng": Lightsail, Alexa đều chạy trên hạ tầng AWS nhưng không phải là thành phần của nó.
• Dịch vụ quản trị không phải hạ tầng: AWS Organizations quản lý tài khoản và chính sách ở mức logic, không đại diện cho bất kỳ vị trí vật lý nào.

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

Đề mô tả một kiến trúc rất cụ thể: một nhóm web server chạy trên Amazon EC2, được đặt trong Auto Scaling group, và phía trước là một Elastic Load Balancer. Sau đó hỏi kiến trúc này minh hoạ best practice nào của AWS Well-Architected Framework.

Cụm từ quyết định đáp án chính là sự kết hợp "Auto Scaling groups" + "placed behind an Elastic Load Balancer". Đây không phải một chi tiết trang trí — đó là cặp thành phần kinh điển để một hệ thống tự chịu đựng được sự cố: Auto Scaling group phát hiện instance hỏng và thay bằng instance mới, còn load balancer ngừng gửi traffic tới instance không còn khoẻ. Câu hỏi không nói gì về hàng đợi, về mã hoá, về xác thực, hay về việc thử nghiệm nhiều kiến trúc song song — nên mọi phương án gắn với những chủ đề đó đều nằm ngoài dữ kiện của đề.

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

Đáp án đúng là D — Design for failure.

Nguyên tắc "design for failure" nói rằng ta phải giả định thành phần nào cũng có lúc hỏng, và thiết kế sao cho hệ thống vẫn phục vụ được khi điều đó xảy ra. Cách đơn giản nhất để làm việc này với EC2 chính là mô hình mà đề mô tả:

• Auto Scaling group gom một tập EC2 instance thành một nhóm logic để quản lý và scale tự động. Nó có health check replacement: instance nào trượt health check sẽ bị thay thế, và nhóm được giữ ở đúng số lượng instance mong muốn. Đây là khả năng tự phục hồi mà một EC2 instance đơn lẻ không có.
• Elastic Load Balancer phân phối tải tới các web server trong nhóm. Nhờ đó traffic không dồn vào một máy duy nhất, và khi một máy mất, phần còn lại vẫn nhận request.

Kết hợp hai thứ này cho ra high availability: hỏng một instance không làm sập dịch vụ. Đó chính xác là ví dụ điển hình của "design for failure" mà Well-Architected dùng để minh hoạ.

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

A — Think parallel. Nguyên tắc này nói về việc khai thác khả năng làm nhiều việc song song và thử nghiệm nhiều kiến trúc cùng lúc để so sánh. Đề bài không hề nhắc tới một kiến trúc thứ hai nào được dựng song song để đối chiếu với mô hình Auto Scaling group + ELB. Không có dữ kiện, nên không chọn được.

B — Decouple infrastructure components. Đây là phương án gần đúng và dễ bẫy nhất, vì load balancer đúng là đứng chắn giữa client và các instance nên nghe qua có vẻ "tách rời". Nhưng decoupling theo nghĩa Well-Architected là làm cho các thành phần không phụ thuộc trực tiếp vào nhau, thường bằng cách chèn một lớp trung gian bất đồng bộ — vai trò của những dịch vụ như Amazon SQS hoặc AWS Lambda. Auto Scaling group và Elastic Load Balancer không sinh ra để làm việc đó; mục đích chính của chúng là scale và phân phối tải, ELB vẫn gọi backend đồng bộ. Chọn B là gán cho hai dịch vụ này một vai trò không phải của chúng.

C — Secure the workload. Elastic Load Balancer có mang lại một vài lợi ích bảo mật phụ (ví dụ instance không cần lộ trực tiếp ra ngoài), nhưng đó không phải lý do người ta dựng nó. Lý do chính là để gắn vào Auto Scaling group và phân phối traffic tới các instance bên trong. Đề cũng không nhắc gì tới mã hoá, kiểm soát truy cập hay bất kỳ biện pháp bảo mật nào — chọn C là đọc thêm thứ không có trong đề.

📌 Điểm cần nhớ

• Auto Scaling group + Elastic Load Balancer = design for failure / high availability. Thấy đúng cặp này trong đề thì gần như chắc chắn câu hỏi đang nhắm tới khả năng chịu lỗi, không phải bảo mật hay decoupling.
• Auto Scaling group không chỉ để scale. Health check replacement và việc giữ đúng số instance mong muốn là phần "tự phục hồi" — đó mới là điểm khiến nó gắn với design for failure.
• Decoupling gắn với SQS/Lambda, không gắn với ELB. Load balancer phân phối tải đồng bộ; đừng nhầm "đứng chắn ở giữa" với "tách rời phụ thuộc".
• Chỉ chọn nguyên tắc mà đề có dữ kiện chống lưng. "Think parallel" cần đề nhắc tới nhiều kiến trúc được thử song song; "secure the workload" cần đề nhắc tới biện pháp bảo mật. Không có dấu hiệu thì loại.