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

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

Đề hỏi: "How much data can a company store in the Amazon S3 service?" — tức là một tổ chức được phép lưu tối đa bao nhiêu dữ liệu trong Amazon S3.

Cụm từ quyết định đáp án là "How much data can a company store" — chủ ngữ là lượng dữ liệu tổng cộng của cả tài khoản, chứ không phải kích thước của một object đơn lẻ, không phải kích thước tối đa của một lần upload, và cũng không phải hạn mức mặc định của một dịch vụ khác. Ba phương án A, B, C đều là những con số cụ thể trông rất "giống hạn mức", và người mới học hay bị chúng dụ vì quen với việc dịch vụ nào cũng có quota. Câu này chính là kiểm tra xem thí sinh có nắm được đặc tính nền tảng của object storage hay không: S3 không đặt trần dung lượng cho tổng dữ liệu và tổng số object.

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

Đáp án đúng theo tệp là D — "Virtually unlimited".

Amazon S3 là dịch vụ object storage được thiết kế để mở rộng gần như không giới hạn: tổng dung lượng dữ liệu và tổng số object bạn lưu trong S3 đều không bị giới hạn. Bạn cứ tiếp tục ghi object vào bucket, AWS lo phần hạ tầng phía dưới, và bạn trả tiền theo lượng dữ liệu thực tế đang lưu.

Chỗ S3 có giới hạn là ở kích thước từng object, chứ không phải ở tổng dung lượng:

• Một object có thể từ 0 byte đến tối đa 5 TB.
• Một lần PUT đơn lẻ chỉ tải lên được tối đa 5 GB; muốn đưa object lớn hơn thì phải dùng multipart upload.

Đây là điểm phân biệt quan trọng: giới hạn của S3 nằm ở đơn vị object, không nằm ở tổng kho. Đề hỏi về tổng dữ liệu của cả công ty, nên câu trả lời đúng là "gần như không giới hạn".

Từ "virtually" (gần như) cũng là cách diễn đạt chuẩn xác — về mặt vật lý không có gì là vô hạn tuyệt đối, nhưng từ góc nhìn của khách hàng thì không tồn tại một con số trần nào mà bạn phải xin nâng hạn mức khi chạm tới.

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

A. 100 PB — Sai. Không tồn tại giới hạn 100 PB nào trong S3. Đây là con số bịa ra để trông "đủ lớn cho doanh nghiệp" nhằm dụ người chọn theo cảm tính rằng "chắc phải có trần ở đâu đó, và trần đó hẳn rất cao". Đây là phương án gần đúng nhất về mặt tâm lý, nhưng nó vẫn sai ở bản chất: sai không phải vì con số quá nhỏ, mà vì bản thân việc tồn tại một con số trần là sai.

B. 100 TB — Sai. Không có giới hạn 100 TB. Con số này còn nhỏ đến mức vô lý: 100 TB là dung lượng mà một hệ thống log hoặc kho dữ liệu media của doanh nghiệp vừa có thể vượt qua trong thời gian ngắn. Nếu S3 thật sự bị chặn ở mức này thì nó đã không thể đóng vai trò kho lưu trữ nền tảng cho data lake và backup như hiện nay.

C. 1 PB — Sai. Cũng không có giới hạn nào như vậy. Phương án này dễ gây nhầm vì con số "1 PB" nghe rất tròn trịa và hay xuất hiện trong tài liệu marketing về quy mô dữ liệu lớn, nhưng nó không phải một hạn mức của S3.

Điểm chung của A, B, C: cả ba đều mắc cùng một lỗi — áp đặt một con số trần cứng lên tổng dung lượng, trong khi mô hình S3 không có khái niệm đó.

📌 Điểm cần nhớ

• S3 không giới hạn tổng dung lượng và không giới hạn tổng số object. Gặp câu hỏi kiểu "công ty lưu được bao nhiêu dữ liệu trong S3", đáp án gần như luôn là "virtually unlimited".
• Phân biệt rõ hai tầng giới hạn: tổng kho (không giới hạn) khác với từng object (tối đa 5 TB) và khác với một lần upload đơn lẻ (tối đa 5 GB, vượt thì dùng multipart upload).
• Trong đề trắc nghiệm, khi ba phương án là ba con số cụ thể còn phương án thứ tư nói "gần như không giới hạn", hãy tự hỏi: dịch vụ này có thực sự công bố một trần cứng không? Với object storage như S3 thì câu trả lời là không.
• Đọc kỹ chủ ngữ của câu hỏi — "a company store" (tổng dữ liệu) khác hẳn "a single object" hay "a single upload". Cùng một dịch vụ nhưng ba cách hỏi này cho ba đáp án hoàn toàn khác nhau.

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

Đề hỏi: khi chạy ứng dụng trên AWS Cloud, những công việc thường ngày (common tasks) nào AWS có thể làm thay cho khách hàng? Chọn HAI.

Cụm từ quyết định đáp án là "AWS manage on behalf of their customers" — tức là việc nằm ở phía AWS trong mô hình trách nhiệm chia sẻ (shared responsibility model). Đây chính là ranh giới phân biệt năm phương án: cả năm đều là việc phải làm khi vận hành một ứng dụng, nhưng chỉ hai trong số đó là việc AWS gánh hộ khi bạn dùng managed service.

Bộ lọc để áp vào từng phương án rất đơn giản: việc đó thuộc về hạ tầng và phần mềm nền (AWS lo), hay thuộc về nội dung và mã nguồn của khách hàng (khách hàng lo)? AWS chăm sóc "of the cloud", khách hàng chăm sóc "in the cloud".

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

Đáp án đúng là A và D.

A — Patching database software. Với managed database service như Amazon RDS, AWS chịu trách nhiệm vá hệ điều hành của database host và vá cả phần mềm database engine. Khách hàng không SSH vào máy, không tự chạy lệnh cập nhật — AWS thực hiện các hoạt động patch management đó thay bạn. Đây đúng nghĩa "common IT task" mà managed service giúp bạn tiết kiệm thời gian.

D — Taking a backup of a database. Amazon RDS thực hiện sao lưu tự động cho database của bạn như một tính năng sẵn có của dịch vụ. Bạn không phải dựng script backup, không phải quản lý nơi lưu bản sao — AWS lo phần vận hành đó.

Điểm chung của A và D: cả hai đều là thao tác vận hành trên tầng nền của dịch vụ, không đụng đến logic hay nội dung riêng của ứng dụng bạn.

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

B — Creating a database schema. Đây là phương án dễ nhầm nhất vì nó cũng nói về database, cùng chủ đề với A và D. Nhưng schema là thiết kế dữ liệu của riêng ứng dụng bạn: bảng nào, cột nào, quan hệ ra sao. AWS không biết và không thể biết mô hình dữ liệu của bạn. RDS cấp cho bạn một database engine đã chạy sẵn, còn đổ schema vào là việc của khách hàng. Ranh giới: AWS quản lý engine, khách hàng quản lý dữ liệu và cấu trúc dữ liệu.

C — Application source code auditing. AWS không rà soát mã nguồn của bạn. Mã nguồn là tài sản và trách nhiệm của khách hàng. Có công cụ Amazon CodeGuru đưa ra khuyến nghị cải thiện mã, nhưng đó là dịch vụ bạn chủ động dùng, không phải việc AWS tự làm thay cho bạn — mà đề đang hỏi việc AWS quản lý hộ.

E — Application security testing. AWS không kiểm thử bảo mật ứng dụng của khách hàng. AWS bảo vệ hạ tầng bên dưới, còn lỗ hổng trong chính ứng dụng bạn viết — lỗi xác thực, injection, phân quyền sai — thì AWS không phát hiện thay bạn. Đây cũng là phương án gần đúng vì "bảo mật" nghe như phần AWS lo, nhưng nó hỏng ở chỗ: bảo mật của cloud là AWS, bảo mật trong cloud (ứng dụng của bạn) là bạn.

📌 Điểm cần nhớ

• Câu hỏi có cụm "AWS manage on behalf of customers" gần như luôn quy về shared responsibility model: hạ tầng, hệ điều hành, phần mềm nền của managed service → AWS; dữ liệu, mã nguồn, cấu hình ứng dụng → khách hàng.
• Với Amazon RDS, cặp việc kinh điển AWS làm thay là patching và backup. Nhớ cặp này là loại được nhiều phương án nhiễu.
• Bất cứ thứ gì mang chữ "application" hoặc gắn với nội dung riêng của bạn (source code, schema, security testing của app) đều rơi về phía khách hàng.
• Mẹo phân biệt nhanh: hỏi "AWS có cần biết gì về nghiệp vụ ứng dụng của tôi để làm việc này không?" — nếu có, thì đó không phải việc AWS làm thay.

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

Đề hỏi: "Which of the following is a sole responsibility of AWS?" — điều nào chỉ riêng AWS chịu trách nhiệm.

Cụm từ quyết định đáp án là "sole responsibility". Đây không phải câu hỏi "AWS có liên quan tới việc gì", mà là "việc gì AWS làm hoàn toàn một mình, khách hàng không đụng vào phần nào cả". Trong Shared Responsibility Model, các đầu việc chia thành ba nhóm: việc thuần của AWS (security of the cloud), việc thuần của khách hàng (security in the cloud), và một nhóm ở giữa — việc chia sẻ, mỗi bên lo một lớp. Từ "sole" loại thẳng nhóm thứ ba, kể cả khi AWS thật sự có làm một phần của nó.

Ranh giới cần nhớ để phân loại: AWS lo phần hạ tầng vật lý và nền tảng toàn cầu — Regions, Availability Zones, Edge locations, phần cứng, mạng, lớp ảo hoá. Khách hàng lo mọi thứ chạy bên trên — ứng dụng, dữ liệu, cấu hình quyền truy cập, hệ điều hành khách trên EC2.

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

C — Availability Zone management.

Availability Zone là một thành phần của hạ tầng toàn cầu AWS: trung tâm dữ liệu vật lý, nguồn điện, làm mát, đường mạng nối các AZ trong cùng Region. Khách hàng chỉ chọn triển khai vào AZ nào, còn việc dựng, vận hành, bảo trì và cách ly lỗi giữa các AZ là do AWS làm — khách hàng không có cách nào tác động vào, và cũng không có phần việc nào chia lại cho họ trong hạng mục này. Đây đúng nghĩa là security of the cloud, nên nó thoả ràng buộc "sole".

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

A — Application deployment. Ngược hẳn: đây là trách nhiệm thuần của khách hàng. AWS cung cấp nền tảng để chạy ứng dụng, còn viết gì, đóng gói ra sao, đưa lên lúc nào là việc của người dùng. Đúng là AWS có dịch vụ hỗ trợ triển khai, nhưng chúng chỉ là công cụ — nội dung và quyết định triển khai vẫn thuộc về khách hàng.

B — Customer data access controls. Cũng là trách nhiệm thuần của khách hàng, và là hạng mục kinh điển nhất của security in the cloud. Khách hàng quyết định ai được đọc dữ liệu nào, cấu hình quyền, chính sách truy cập. AWS cung cấp cơ chế để làm việc đó nhưng không bao giờ tự đặt quyền thay khách hàng — chính chỗ này là nơi cấu hình sai của người dùng gây lộ dữ liệu, không phải lỗi của AWS.

D — Patch management. Đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì AWS thật sự có vá lỗi. Nhưng nó hỏng đúng ở chữ "sole": patch management là trách nhiệm chia sẻ. AWS vá hạ tầng nền và phần nền của các dịch vụ được quản lý; còn hệ điều hành khách, cơ sở dữ liệu và phần mềm khách hàng tự cài trên EC2 thì chính khách hàng phải vá. Vì cả hai bên đều có phần việc, nó không thể là trách nhiệm riêng của AWS.

📌 Điểm cần nhớ

• Từ khoá "sole" trong đề là bộ lọc: nó loại cả nhóm trách nhiệm chia sẻ, không chỉ loại nhóm của khách hàng. Đọc lướt qua chữ này là chọn nhầm D.
• Chia đôi theo câu thần chú: AWS lo security of the cloud (hạ tầng toàn cầu — Region, Availability Zone, Edge location, phần cứng, mạng, lớp ảo hoá); khách hàng lo security in the cloud (ứng dụng, dữ liệu, quyền truy cập, OS khách).
• Ba hạng mục hay được hỏi ở dạng "chia sẻ": patch management, cấu hình và nhận thức, đào tạo. Gặp chúng trong câu hỏi có chữ "sole"/"only" thì gần như chắc chắn là bẫy.
• Càng lên cao trong chồng dịch vụ (managed service) thì AWS gánh càng nhiều, nhưng phần dữ liệu và quyền truy cập vào dữ liệu thì không bao giờ chuyển sang AWS.

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

Đề nói một công ty muốn chuyển một loạt ứng dụng cũ (legacy applications) lên AWS Cloud, và giải pháp phải tiết kiệm chi phí (cost-effective).

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

• "legacy applications" — ứng dụng cũ, viết theo lối truyền thống, thường là tiến trình chạy dài trên máy chủ, phụ thuộc hệ điều hành, thư viện cũ, đôi khi cả trạng thái lưu trên đĩa. Cụm này loại thẳng mọi phương án đòi viết lại ứng dụng theo mô hình mới.
• "cost-effective" — trong bốn phương án, luôn có cái chạy được nhưng đắt hơn cần thiết. Cụm này dùng để phân biệt hai phương án EC2 đứng cạnh nhau.

Nói cách khác, đề đang hỏi: cách chuyển đổi nào vừa không bắt viết lại ứng dụng, vừa không trả tiền thừa.

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

A. Rehost the applications on Amazon EC2 instances that are right-sized.

Rehost là chuyển ứng dụng nguyên trạng sang máy ảo trên đám mây, thường gọi là "lift and shift". Ứng dụng cũ vẫn thấy một hệ điều hành đầy đủ như trên máy chủ vật lý trước đây, nên không phải sửa mã, không phải đổi kiến trúc — đúng thứ mà "legacy applications" cần.

Phần thứ hai của phương án, right-sizing, chính là mảnh trả lời cho "cost-effective". Right-sizing là việc chọn đúng loại và cỡ instance sao cho tài nguyên (CPU, RAM) khớp với nhu cầu thật của từng ứng dụng, không dư thừa. Ứng dụng cũ chạy trên phần cứng đặt mua từ nhiều năm trước thường được cấp phát dư rất nhiều; giữ nguyên cỡ đó khi lên EC2 là trả tiền cho tài nguyên không dùng tới. Chọn đúng cỡ instance là cách giảm chi phí trực tiếp nhất mà không đụng gì vào ứng dụng.

Vì vậy A ghép được cả hai ràng buộc của đề: chạy được với ứng dụng cũ, và tối ưu chi phí.

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

B. Use AWS Lambda to host the legacy applications in the cloud. Lambda chạy mã theo mô hình hàm được kích hoạt bởi sự kiện, mỗi lần gọi là một lần chạy ngắn, không giữ trạng thái giữa các lần gọi, và chỉ hỗ trợ một số runtime nhất định. Ứng dụng cũ hầu như không được thiết kế theo mô hình đó — muốn đưa lên Lambda thì phải viết lại (refactor), tức là làm đúng điều mà chữ "legacy" trong đề ngụ ý là nên tránh. Đây không phải phương án "chạy được nhưng đắt", mà là phương án không đơn giản chạy được.

C. Use an Amazon S3 static website to host the legacy application code. S3 static website chỉ phục vụ nội dung tĩnh — HTML, CSS, JavaScript, ảnh. Nó không thực thi mã phía máy chủ. Đưa mã ứng dụng lên đó thì mã sẽ được trả về như một tệp văn bản chứ không chạy. Phương án này sai về mặt kỹ thuật ngay từ đầu, không phải sai vì chi phí.

D. Migrate the applications to dedicated hosts on Amazon EC2. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. Về mặt kỹ thuật nó hoàn toàn chạy được: dedicated host vẫn là EC2, vẫn cho ứng dụng cũ một hệ điều hành đầy đủ, vẫn là rehost. Chỗ nó hỏng là ở chữ cost-effective: dedicated host cho bạn nguyên một máy chủ vật lý dành riêng, không chia sẻ với khách hàng khác, và bạn trả tiền theo cả máy chủ đó thay vì theo từng instance. Đó là lựa chọn dành cho các yêu cầu về tuân thủ, cách ly, hoặc mang giấy phép phần mềm tính theo socket/core sang dùng. Đề không nêu bất kỳ yêu cầu nào như vậy — chỉ nêu yêu cầu chi phí. Trả tiền cho mức cách ly mà đề không đòi hỏi chính là chi phí thừa.

📌 Điểm cần nhớ

• Thấy "legacy application" trong đề: nghiêng ngay về rehost lên EC2. Các phương án serverless hay static hosting đòi viết lại ứng dụng hoặc không chạy được mã phía máy chủ.
• Thấy "cost-effective": đó thường là từ dùng để tách hai phương án cùng chạy được. Hãy tìm phương án nào cung cấp mức cách ly, hiệu năng hoặc năng lực cao hơn mức đề yêu cầu — đó là phương án bị loại.
• Right-sizing là câu trả lời chuẩn cho tối ưu chi phí trên EC2: chọn loại và cỡ instance khớp nhu cầu thật, không cấp phát dư.
• Dedicated host chỉ đúng khi đề nhắc tới tuân thủ, cách ly phần cứng, hoặc giấy phép phần mềm tính theo phần cứng vật lý. Không có mấy từ khoá đó thì nó là bẫy chi phí.
• S3 static website chỉ phục vụ nội dung tĩnh, không thực thi mã phía máy chủ — luôn loại ngay khi đề nói tới việc chạy một ứng dụng.

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

Đề bài đặt ra một tình huống rất gọn: một Cloud Practitioner cần theo dõi mức sử dụng CPU và network của một EC2 instance mới, và phải chọn đúng dịch vụ AWS để làm việc đó.

Cụm từ quyết định đáp án là "monitor ... CPU and network utilization". Hai chi tiết trong cụm này định hướng toàn bộ lựa chọn:

• "utilization" — đây là số đo hiệu năng (metric) của tài nguyên, chứ không phải nhật ký hành động, không phải lỗ hổng bảo mật, cũng không phải trạng thái bản vá.
• "monitor" — việc cần làm là quan sát và theo dõi theo thời gian, chứ không phải thay đổi hay quản trị instance.

Khi đề bài hỏi về số đo hiệu năng của tài nguyên AWS, câu trả lời gần như luôn là dịch vụ chuyên thu thập metric. Ba phương án còn lại đều là dịch vụ hợp lệ và đều liên quan tới EC2, nhưng mỗi cái phục vụ một mục đích khác — đó chính là chỗ đề bài đánh lừa.

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

Đáp án đúng là A — Amazon CloudWatch.

CloudWatch là dịch vụ giám sát hiệu năng của AWS. Các dịch vụ AWS tự động gửi metric về mức sử dụng tài nguyên của mình sang CloudWatch, và CloudWatch làm nhiệm vụ thu thập, lưu trữ những số đo đó. Với EC2, các metric như mức sử dụng CPU và lưu lượng network nằm sẵn trong nhóm metric mặc định mà instance phát ra — người dùng không phải dựng thêm hạ tầng thu thập nào.

Sau khi metric đã về CloudWatch, bạn có thể:

• Xem kết quả trực tiếp trong CloudWatch dưới dạng đồ thị theo thời gian.
• Cấu hình alarm để được báo khi một metric vượt ngưỡng bạn đặt ra.

Đúng hai việc "theo dõi CPU và network" mà đề bài yêu cầu, không thừa không thiếu.

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

B — Amazon Inspector. Đây là dịch vụ bảo mật tự động, làm việc đánh giá tình trạng an ninh của workload. Nó có động tới EC2 thật, nên dễ gây phân vân, nhưng thứ nó báo cho bạn là vấn đề bảo mật chứ không phải phần trăm CPU hay lưu lượng network. Chọn Inspector là nhầm giữa "giám sát an ninh" và "giám sát hiệu năng".

C — AWS Systems Manager. Đây là phương án gần đúng nhất và cũng nguy hiểm nhất. Systems Manager đúng là dùng để làm việc với EC2 instance — cụ thể là quản trị chúng: cài bản vá, cài và cập nhật phần mềm, thao tác vận hành trên instance. Chỗ nó hỏng so với đề bài nằm ở động từ: đề hỏi monitor (quan sát số đo), còn Systems Manager thiên về manage (tác động, thay đổi). Nó là công cụ của người quản trị máy, không phải nơi bạn mở ra để xem biểu đồ CPU.

D — AWS CloudTrail. Rất hay bị đổi chỗ với CloudWatch vì tên gần giống và cả hai đều "ghi lại thứ gì đó". CloudTrail phục vụ auditing — ghi lại ai đã gọi API nào, vào lúc nào, từ đâu. Nó trả lời câu hỏi "ai đã khởi chạy instance này?", chứ không trả lời "instance này đang dùng bao nhiêu CPU?". Đề bài hỏi vế thứ hai, nên CloudTrail sai.

📌 Điểm cần nhớ

• Thấy từ khoá metric, utilization, CPU, network, alarm, ngưỡng cảnh báo → nghĩ ngay tới Amazon CloudWatch.
• Phân biệt cặp hay lẫn: CloudWatch = hiệu năng (chuyện gì đang xảy ra với tài nguyên), CloudTrail = audit (ai đã làm gì qua API).
• Phân biệt monitor và manage: CloudWatch để quan sát, AWS Systems Manager để tác động lên instance (vá lỗi, cài phần mềm).
• Amazon Inspector thuộc nhóm bảo mật — chỉ chọn khi đề nói tới đánh giá an ninh, không bao giờ chọn cho câu hỏi về hiệu năng.

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

Đề mô tả một Cloud Practitioner biết trước rằng lưu lượng ứng dụng sẽ tăng vào một thời điểm cụ thể trong tương lai — một sự kiện bán hàng — và hỏi cấu hình Amazon EC2 Auto Scaling thế nào để có đủ số instance sẵn sàng trước khi sự kiện diễn ra.

Cụm từ quyết định đáp án là "a future date and time" kết hợp với "ahead of the event". Hai mảnh này nói rõ hai điều:

• Thời điểm tăng tải là đã biết chính xác, do con người nắm được từ kế hoạch kinh doanh chứ không phải suy ra từ dữ liệu.
• Năng lực phải có trước khi tải đến, tức là không được chờ chỉ số vượt ngưỡng rồi mới phản ứng.

Cả bốn phương án đều là cơ chế scaling hợp lệ của EC2 Auto Scaling, nên phải phân loại chúng theo trục chủ động theo lịch — dự đoán theo xu hướng — phản ứng theo chỉ số.

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

Đáp án đúng theo tệp là B — Configure a scheduled scaling policy.

Scheduled scaling cho phép bạn tự đặt lịch thay đổi năng lực theo những biến động tải đoán trước được: khai báo mốc thời gian cùng giá trị desired/min/max capacity, và Auto Scaling sẽ điều chỉnh nhóm đúng vào mốc đó. Ví dụ kinh điển trong tài liệu AWS: lưu lượng web tăng vào thứ Tư, giữ cao thứ Năm, giảm dần thứ Sáu — bạn hẹn lịch tăng capacity thứ Tư và giảm thứ Sáu.

Áp vào đề: người vận hành đã biết ngày giờ của sự kiện bán hàng, nên chỉ cần hẹn lịch nâng capacity ở một mốc sớm hơn giờ bắt đầu, đủ để instance kịp khởi động và vào trạng thái phục vụ. Đây là cách duy nhất trong danh sách bảo đảm được vế "sẵn sàng trước sự kiện", vì lịch được kích hoạt bởi đồng hồ chứ không bởi tải thực tế.

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

A — Predictive scaling. Đây là phương án gần đúng nhất và cũng là phương án chủ động duy nhất còn lại: nó dự báo nhu cầu rồi bổ sung capacity trước. Nhưng nó dự báo dựa trên xu hướng lặp lại theo ngày và theo tuần rút ra từ dữ liệu lịch sử. Một sự kiện bán hàng là biến cố một lần, không nằm trong chu kỳ lặp, nên mô hình không có căn cứ để nhìn thấy nó. Quan trọng hơn: ở đây con người đã biết chắc thời điểm, chẳng có lý do gì giao cho một mô hình đoán lại thứ mình đang nắm trong tay.

C — Target tracking scaling policy. Chính sách này giữ một chỉ số (ví dụ mức sử dụng CPU trung bình) quanh giá trị mục tiêu. Nó chỉ hành động sau khi chỉ số đã lệch khỏi mục tiêu — nghĩa là tải phải ập đến, instance hiện có phải bị đẩy lên cao rồi mới sinh thêm máy. Vế "sẵn sàng trước sự kiện" không được đáp ứng.

D — Step scaling policy. Cùng bản chất phản ứng như C, chỉ khác ở chỗ nó thêm bao nhiêu instance theo từng bậc tuỳ mức độ vượt ngưỡng của cảnh báo. Vẫn phải chờ nhu cầu xuất hiện, và giữa lúc cảnh báo kích hoạt với lúc instance thực sự phục vụ được luôn có độ trễ. Trong cú tăng tải dốc đứng của một sự kiện bán hàng, độ trễ đó chính là quãng người dùng gặp lỗi.

📌 Điểm cần nhớ

• Đề nói biết trước ngày giờ cụ thể → scheduled scaling. Đề nói tải lặp lại theo chu kỳ ngày/tuần mà không nêu mốc cụ thể → predictive scaling.
• Target tracking và step scaling đều là cơ chế phản ứng: chúng chạy sau khi chỉ số đã đổi, nên không bao giờ là câu trả lời cho yêu cầu "sẵn sàng trước".
• Phân biệt predictive và scheduled bằng nguồn của thông tin: predictive để mô hình tự suy từ lịch sử, scheduled để con người khai báo thứ mình đã biết.
• Cụm "ahead of / before the event" trong đề bài Auto Scaling gần như luôn loại sạch nhóm chính sách dựa trên CloudWatch alarm.

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

Đề hỏi: "What is the best practice for managing AWS IAM access keys?" — đâu là thực hành tốt nhất khi quản lý IAM access key.

Hai cụm từ quyết định đáp án nằm ngay trong câu hỏi:

• "best practice" — đề không hỏi "cách duy nhất được phép" hay "quy tắc tuyệt đối". Nó hỏi khuyến nghị. Vì vậy mọi phương án mang giọng cực đoan ("never", "no need") đều đáng ngờ ngay từ hình thức.
• "managing" — hàm ý đây là việc ai đó phải làm, tức là có một chủ thể chịu trách nhiệm. Câu hỏi bẫy đúng ở chỗ này: chủ thể là khách hàng hay là AWS? Đây chính là ranh giới của shared responsibility model — thứ mà bài thi Cloud Practitioner kiểm tra rất nhiều.

Ghép hai cụm lại, phương án đúng phải là: khách hàng chủ động làm, và là khuyến nghị chứ không phải mệnh lệnh tuyệt đối.

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

B — "Customers should rotate access keys regularly."

Xoay vòng (rotate) access key định kỳ là thực hành bảo mật tiêu chuẩn của IAM. Lý do rất trực tiếp: access key là thông tin xác thực dài hạn — nó không tự hết hạn. Một cặp AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY lỡ rò ra ngoài (commit nhầm vào Git, nằm trong log, nằm trong file cấu hình cũ) sẽ còn dùng được mãi cho tới khi có người vô hiệu hoá nó.

Rotate định kỳ giới hạn khung thời gian mà một khoá bị lộ còn giá trị. Nó không ngăn được việc lộ khoá, nhưng biến một lỗ hổng vĩnh viễn thành một lỗ hổng có hạn.

Phương án B cũng nêu đúng chủ thể: customer. Trong shared responsibility model, IAM credential thuộc phần "security in the cloud" — AWS lo hạ tầng, khách hàng lo danh tính và quyền truy cập của chính mình.

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

A — "AWS rotate access keys on a schedule." Sai ở chủ thể, không sai ở hành động. Việc rotate là đúng, nhưng AWS không tự xoay vòng access key của bạn. Nếu AWS tự đổi khoá thì mọi script, ứng dụng, CI job đang dùng khoá đó sẽ hỏng đồng loạt mà không báo trước. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi: nó chỉ khác B đúng một chữ — ai làm.

C — "Never use access keys, always use IAM roles." Sai vì quá tuyệt đối. Về nguyên lý, dùng IAM role thường an toàn hơn thật — role cấp credential tạm thời, tự hết hạn, không phải lưu trữ ở đâu cả; với workload chạy trên AWS thì đây là lựa chọn được khuyến nghị. Nhưng "never" là quá đà: vẫn có những tình huống hợp lệ cần access key, ví dụ công cụ chạy bên ngoài AWS cần gọi API. Phương án này biến một khuyến nghị đúng thành một luật cấm sai, và đề chỉ hỏi "best practice" chứ không hỏi "điều bị cấm".

D — "There is no need to manage access keys." Sai hoàn toàn, không có phần nào đúng. Access key là credential trực tiếp mở cửa vào tài khoản AWS; bỏ mặc không quản lý là để chúng tồn tại vô thời hạn, không ai biết khoá nào còn dùng, khoá nào đã bỏ quên. Đây là phương án dễ loại nhất trong bốn phương án.

📌 Điểm cần nhớ

• Đọc kỹ chủ thể của câu. Nhiều câu Cloud Practitioner phân biệt phương án đúng/sai chỉ bằng việc "AWS làm" hay "customer làm". IAM user, access key, permission, mật khẩu — đều thuộc trách nhiệm của khách hàng.
• Access key là credential dài hạn, không tự hết hạn → phải rotate định kỳ để giới hạn thiệt hại khi bị lộ. IAM role thì ngược lại: credential tạm thời, tự hết hạn.
• Cảnh giác với "never" và "always". Trong đề thi AWS, phương án tuyệt đối thường sai — trừ một số quy tắc bảo mật thật sự cứng. "Ưu tiên IAM role" là đúng; "không bao giờ dùng access key" là sai.
• Phương án phủ nhận hoàn toàn việc quản lý ("no need to manage", "không cần cấu hình gì") gần như luôn là distractor để loại đầu tiên.

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

Đề mô tả một công ty đang chuyển một monolithic application không mở rộng quy mô tốt lên cloud, đồng thời refactor nó thành microservices architecture. Câu hỏi yêu cầu chỉ ra best practice nào của AWS Well-Architected Framework ứng với kế hoạch đó.

Cụm từ quyết định là "refactoring it into a microservices architecture" — chứ không phải "migrating" hay "does not scale well". Ba mảnh của đề đóng vai trò khác nhau:

• "does not scale well" là lý do họ làm, không phải best practice họ áp dụng.
• "migrating ... into the cloud" là bối cảnh chung, đúng với gần như mọi câu hỏi loại này nên không phân biệt được phương án nào.
• "refactoring into microservices" là hành động kỹ thuật cụ thể, và đây mới là thứ ánh xạ thẳng vào một best practice có tên trong framework.

Bản chất của microservices là tách khối lớn thành các thành phần độc lập, giao tiếp với nhau qua interface rõ ràng thay vì gọi trực tiếp trong cùng một tiến trình. Đó chính là định nghĩa của loose coupling. Phải đọc ra được liên hệ "microservices ⇒ loosely coupled" thì mới khoá được đáp án.

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

B — Implement loosely coupled services.

Khi khối monolith bị tách thành nhiều service nhỏ, mỗi thành phần có thể scale độc lập và cập nhật độc lập với phần còn lại. Đây đúng là thứ đề bài đang tìm: ứng dụng cũ "không scale tốt" vì mọi thứ dính vào nhau, muốn tăng năng lực cho một chức năng thì phải nhân bản cả khối.

Loose coupling còn giúp giảm phụ thuộc giữa các hệ thống: các service trao đổi với nhau qua thông điệp và dữ liệu, và những thông điệp/dữ liệu đó có thể được lưu trữ một cách tin cậy, bền bỉ trên đường đi giữa các thành phần. Nhờ vậy một thành phần chậm hoặc tạm hỏng không kéo sập cả ứng dụng — trong monolith thì điều ngược lại mới là mặc định.

Đây là best practice được nêu tên trực tiếp trong AWS Well-Architected Framework, nên nó khớp với câu hỏi cả về nội dung lẫn về cách diễn đạt.

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

A — Manage change in automation. Đây là một best practice thật, nói về việc thay đổi hạ tầng nên được thực hiện qua tự động hoá thay vì thao tác tay. Nó gần đúng ở chỗ cũng thuộc Well-Architected Framework và cũng liên quan tới quá trình hiện đại hoá ứng dụng. Nhưng đề không hề nhắc tới automation, pipeline, hay quy trình quản lý thay đổi — cái được mô tả là thay đổi kiến trúc ứng dụng, không phải cách thức triển khai thay đổi. Chọn A là gán thêm chi tiết mà đề không cho.

C — Use multiple solutions to improve performance. Phương án này bám vào từ khoá "does not scale well" nên nghe có vẻ hợp lý. Nhưng nó nói về việc dùng nhiều giải pháp/công nghệ khác nhau để tối ưu hiệu năng, còn công ty ở đây làm đúng một việc: tái cấu trúc ứng dụng thành microservices. Đề không mô tả họ thử nhiều phương án hay kết hợp nhiều công nghệ để tăng hiệu năng. Đây là best practice bị nhầm vì trùng chủ đề "hiệu năng", chứ không trùng hành động.

D — Stop spending money on undifferentiated heavy lifting. Đây là best practice quen thuộc, nói về việc ngừng bỏ công sức vào những việc nặng nhọc mà không tạo khác biệt cho doanh nghiệp. Nó gần đúng vì "migrate lên cloud" thường đi kèm ý này. Chỗ hỏng: đề không nói gì về chi phí, vận hành hạ tầng, hay chuyển giao công việc nặng nhọc cho AWS — trọng tâm hoàn toàn nằm ở việc tách khối ứng dụng. Nếu đề mô tả công ty bỏ tự quản lý máy chủ để dùng dịch vụ managed thì D mới là lựa chọn.

📌 Điểm cần nhớ

• Microservices ⇔ loose coupling. Hễ đề nhắc tới tách monolith thành microservices, thành phần độc lập, hay giao tiếp qua message, thì best practice được hỏi gần như chắc chắn là implement loosely coupled services.
• Phân biệt lý do với hành động. "Does not scale well" là vấn đề cần giải quyết; best practice phải khớp với việc công ty làm, không phải với lý do họ làm.
• Cả bốn phương án đều là best practice có thật trong AWS Well-Architected Framework. Không loại được phương án bằng cách hỏi "cái này có đúng không", mà phải hỏi "cái này có được đề mô tả không".
• Đừng suy diễn thêm chi tiết ngoài đề. Automation, chi phí, hay việc thử nhiều giải pháp đều không xuất hiện trong đoạn mô tả — mà thi trắc nghiệm chỉ chấm theo những gì đề viết ra.

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

Đề hỏi: dịch vụ nào giúp người dùng biết được họ có cần xin nâng service limit của Amazon EC2 hay không.

Cụm từ quyết định là "determine if they need to request a service limit increase" — tức là cần một công cụ theo dõi mức sử dụng hiện tại so với hạn mức (service limit / quota) và cảnh báo khi đang tiến sát ngưỡng. Đây không phải câu hỏi về "sự cố dịch vụ", cũng không phải về "tiền", mà về khoảng cách giữa mức dùng và hạn mức.

Chú ý thêm hai chữ "service limit": rất nhiều câu trong đề AWS Certified Cloud Practitioner đặt các phương án gần nghĩa nhau ở chỗ "đều cho bạn xem một thứ gì đó về tài khoản" — Trusted Advisor, Health Dashboard, Cost Explorer đều là công cụ quan sát. Cái phân biệt chúng là đối tượng được quan sát: best practice và service limit, sự kiện ảnh hưởng tài nguyên, hay chi phí.

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

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

AWS Trusted Advisor là công cụ đưa ra khuyến nghị theo thời gian thực, đối chiếu tài khoản của bạn với best practice của AWS trên các nhóm: tối ưu chi phí, hiệu năng, bảo mật, khả năng chịu lỗi — và service limits. Nhóm kiểm tra service limits chính là thứ đề bài cần: nó so mức sử dụng hiện tại với hạn mức của từng dịch vụ theo từng Region và cảnh báo khi bạn đang dùng gần chạm ngưỡng.

Nhờ đó, người dùng nhìn vào Trusted Advisor là biết ngay EC2 trong Region đó còn dư bao nhiêu chỗ, từ đó quyết định có cần mở yêu cầu nâng limit hay không — đúng nghĩa "determine if they need to request an increase".

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

A — Amazon RDS: đây là dịch vụ cơ sở dữ liệu quan hệ được quản lý, không phải công cụ quản trị hay giám sát tài khoản. Nó không liên quan gì tới việc theo dõi service limit, càng không liên quan tới limit của EC2. Đây là phương án lạc đề rõ nhất trong bốn phương án.

C — AWS Health Dashboard: đây là phương án gần đúng nhất và cũng dễ nhầm nhất, vì nó cũng là bảng thông tin cảnh báo về tài khoản của bạn. Nhưng đối tượng của nó là các sự kiện và vấn đề đang hoặc sắp ảnh hưởng tới tài nguyên của bạn — sự cố dịch vụ, bảo trì theo lịch, thay đổi có tác động. Nó nói cho bạn biết "có chuyện gì đang xảy ra", chứ không đo mức sử dụng so với hạn mức và không báo rằng bạn sắp chạm service limit. Chọn C là nhầm giữa "sức khoẻ dịch vụ" và "mức dùng so với quota".

D — AWS Cost Explorer: công cụ xem và phân tích chi phí và mức chi tiêu theo thời gian, theo dịch vụ, theo tag. Nó có thể cho thấy bạn đang chạy nhiều EC2 hơn trước (vì hoá đơn tăng), nhưng đó là tín hiệu về tiền, không phải về hạn mức. Cost Explorer không biết limit của bạn là bao nhiêu, nên không trả lời được câu hỏi "đã sát trần chưa, có cần xin nâng không".

📌 Điểm cần nhớ

• Nhắc tới service limits / quota trong đề Cloud Practitioner thì AWS Trusted Advisor gần như luôn là câu trả lời — nó có hẳn một nhóm kiểm tra dành riêng cho việc này.
• Phân biệt ba công cụ quan sát hay bị trộn lẫn: Trusted Advisor = best practice + service limit; AWS Health Dashboard = sự kiện, sự cố, bảo trì ảnh hưởng tài nguyên; Cost Explorer = chi phí và xu hướng chi tiêu.
• Đọc kỹ danh từ đứng sau động từ chính trong đề (limit, event, cost, security) — nó chỉ thẳng vào dịch vụ cần chọn, kể cả khi các phương án nghe đều "hợp lý".
• Một dịch vụ hạ tầng thuần tuý như Amazon RDS xuất hiện giữa các công cụ quản trị thường chỉ là phương án gây nhiễu; loại nó ra trước để rút gọn còn ba lựa chọn thật.

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

Đề mô tả một công ty truyền thông muốn "find and subscribe to third-party data sources" — tìm và đăng ký thuê bao các nguồn dữ liệu của bên thứ ba — nhằm làm giàu (enrich) bộ dữ liệu sẵn có của họ.

Cụm từ quyết định là "subscribe to third-party data sources". Đây không phải bài toán xử lý, biến đổi hay phân tích dữ liệu mà công ty đã có; đây là bài toán lấy dữ liệu từ bên ngoài tổ chức về, thông qua một hình thức thương mại là đăng ký thuê bao với nhà cung cấp dữ liệu. Ba phương án còn lại đều là những dịch vụ làm việc với dữ liệu bạn đã sở hữu — đó chính là ranh giới phân biệt.

Một dấu hiệu phụ: "enrich their existing datasets with new insights" hàm ý dữ liệu mới đến từ nguồn ngoài, ghép thêm vào dữ liệu nội bộ, chứ không phải sinh ra từ chính dữ liệu nội bộ.

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

A — AWS Data Exchange là dịch vụ được thiết kế đúng cho việc tìm kiếm, đăng ký thuê bao và sử dụng dữ liệu của bên thứ ba trên cloud. Nó đóng vai trò như một nơi tập hợp các sản phẩm dữ liệu (data products) do nhiều nhà cung cấp dữ liệu khác nhau đăng lên; khách hàng duyệt danh mục, chọn sản phẩm phù hợp và đăng ký sử dụng.

Ánh xạ vào tình huống của đề: công ty truyền thông cần dữ liệu họ không tự có để bổ sung insight mới. AWS Data Exchange cho phép họ tìm ra nguồn dữ liệu đó và đăng ký, rồi đưa dữ liệu vào quy trình phân tích hiện tại của mình. Đây là dịch vụ duy nhất trong bốn phương án giải quyết đúng vế "find and subscribe".

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

B — AWS Glue. Đây là dịch vụ ETL (extract, transform, load) được quản lý hoàn toàn, dùng để chuẩn bị và nạp dữ liệu phục vụ phân tích. Phương án này gần đúng ở chỗ nó thật sự làm việc với dữ liệu và thường xuất hiện trong các kiến trúc phân tích — nhưng nó hỏng ở đúng chỗ đề nhấn mạnh: Glue không phải nơi tìm và đăng ký thuê bao nguồn dữ liệu bên thứ ba. Glue chỉ vào cuộc sau khi bạn đã có dữ liệu trong tay.

C — AWS Data Pipeline. Dịch vụ này phục vụ việc xử lý và di chuyển dữ liệu giữa các dịch vụ AWS và các nguồn dữ liệu on-premises. Nó cũng "gần đúng" theo nghĩa liên quan đến việc đưa dữ liệu từ chỗ này sang chỗ khác, nhưng những nguồn đó là nguồn bạn đã có quyền truy cập. Nó không cung cấp cơ chế thương mại để tìm kiếm và đăng ký dữ liệu của nhà cung cấp bên ngoài.

D — AWS Redshift. Đây là dịch vụ data warehouse, dùng để phân tích dữ liệu bằng SQL chuẩn và các công cụ Business Intelligence sẵn có. Redshift là nơi dữ liệu đến để được truy vấn, không phải nơi bạn tìm ra dữ liệu mới. Nó hoàn toàn không có chức năng duyệt danh mục và đăng ký thuê bao sản phẩm dữ liệu của bên thứ ba.

📌 Điểm cần nhớ

• Thấy các từ khoá "third-party data", "subscribe", "data provider", "find data products" → nghĩ ngay tới AWS Data Exchange. Đây gần như là chữ ký nhận dạng của dịch vụ này trong đề thi.
• Phân biệt theo vị trí trong vòng đời dữ liệu: Data Exchange = lấy dữ liệu từ bên ngoài về; Glue = biến đổi/chuẩn bị dữ liệu (ETL); Data Pipeline = di chuyển dữ liệu giữa các nơi mình đã có; Redshift = phân tích dữ liệu bằng SQL. Bốn vai trò khác nhau, không thay thế cho nhau.
• Một dịch vụ "có liên quan tới dữ liệu" chưa đủ để thành đáp án. Hãy đọc kỹ động từ trong đề (find, subscribe, transform, query, move) — chính động từ đó chỉ ra dịch vụ nào được thiết kế cho việc đó.
• "Enrich existing datasets" gợi ý dữ liệu bổ sung đến từ ngoài tổ chức; nếu đề chỉ nói làm sạch hay chuẩn hoá dữ liệu nội bộ thì câu trả lời sẽ ngả về hướng ETL chứ không phải Data Exchange.