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

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

Đề hỏi: khách hàng dùng dịch vụ AWS phải tự vá (patch) hệ điều hành trên dịch vụ nào?

Cụm từ quyết định đáp án là "customers ... must patch operating systems" — tức là câu hỏi đang kiểm tra ranh giới của shared responsibility model (mô hình trách nhiệm chung): việc gì thuộc về AWS ("security of the cloud") và việc gì thuộc về khách hàng ("security in the cloud").

Vá hệ điều hành là công việc chỉ tồn tại khi khách hàng thực sự nhìn thấy và điều khiển được hệ điều hành. Vì vậy câu hỏi thu gọn lại thành: trong bốn dịch vụ này, dịch vụ nào để lộ operating system ra cho khách hàng quản lý? Chỉ có mô hình IaaS làm điều đó; các mô hình serverless/managed đều giấu tầng OS đi và AWS tự lo việc vá.

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

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

Amazon EC2 là dịch vụ IaaS: AWS chịu trách nhiệm phần hạ tầng vật lý, hypervisor và tầng ảo hoá để chạy một virtual server, còn từ guest operating system trở lên là của khách hàng. Khi bạn khởi tạo một EC2 instance, bạn chọn AMI, bạn có quyền đăng nhập vào instance đó, bạn cài phần mềm lên nó — và đúng theo mô hình trách nhiệm chung, bạn cũng là người phải cài bản vá cho hệ điều hành và cho phần mềm mình đã cài, như một phần của công việc bảo trì định kỳ.

Nói gọn: EC2 là dịch vụ duy nhất trong bốn phương án mà khách hàng có một hệ điều hành để mà vá.

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

B — AWS Fargate. Đây là phương án gần đúng nhất và dễ gây phân vân, vì Fargate rõ ràng có chạy container, mà container thì gợi liên tưởng tới một môi trường hệ điều hành. Nhưng Fargate là chế độ chạy serverless cho container: khách hàng không quản lý, không truy cập và cũng không nhìn thấy máy chủ bên dưới. Chỗ nó "hỏng" so với đề bài là ở đây — khách hàng chỉ chịu trách nhiệm với nội dung của container image mình đóng gói, chứ không vá hệ điều hành của host. Đề hỏi đích danh "patch operating systems", nên Fargate bị loại. (Đây cũng chính là điểm phân biệt Fargate với chế độ chạy container trên EC2 instance do mình quản lý.)

C — Amazon DynamoDB. Đây là NoSQL database do AWS vận hành hoàn toàn. Khách hàng làm việc với nó qua API: tạo table, đọc/ghi item, cấu hình index và quyền truy cập. Không có instance nào để đăng nhập, không có hệ điều hành nào lộ ra cho khách hàng, nên việc vá OS hoàn toàn nằm phía AWS.

D — AWS Lambda. Lambda chạy code theo sự kiện mà không cần cấp phát hay quản lý server. Khách hàng chỉ chịu trách nhiệm với code và cấu hình function (bộ nhớ, timeout, quyền IAM, biến môi trường). Toàn bộ môi trường thực thi bên dưới — gồm cả việc vá hệ điều hành — do AWS lo. Cũng vì lý do này Lambda thường xuất hiện như đáp án sai trong các câu hỏi về trách nhiệm vá lỗi.

📌 Điểm cần nhớ

• Gặp từ khoá "patch the operating system", "manage the OS", hay "install and maintain software" thì gần như chắc chắn đáp án là dịch vụ IaaS — trong phạm vi các dịch vụ compute thì đó là Amazon EC2.
• Serverless đồng nghĩa với "khách hàng không vá OS": Lambda, Fargate và DynamoDB đều rơi vào nhóm này. Nếu một câu hỏi liệt kê nhiều dịch vụ serverless cùng lúc, chúng thường là các phương án nhiễu cho nhau chứ không phải đáp án.
• Fargate là cái bẫy quen thuộc: có container không có nghĩa là khách hàng quản lý host. Với Fargate, trách nhiệm của khách hàng dừng lại ở container image, không chạm tới hệ điều hành bên dưới.
• Cách nhớ chung cho shared responsibility model: càng lên cao trong mô hình dịch vụ (IaaS → serverless/managed), trách nhiệm của khách hàng càng thu hẹp lại. Với EC2 khách hàng lo từ guest OS trở lên; với Lambda chỉ còn lo code và cấu hình.

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

Đề hỏi: "What is one method of protecting against distributed denial of service (DDoS) attacks in the AWS Cloud?" — một phương pháp bảo vệ trước tấn công DDoS trên AWS Cloud.

Cụm từ quyết định đáp án là "protecting against" (bảo vệ, chống lại), chứ không phải "detecting", "logging" hay "monitoring". Đây chính là ràng buộc phân biệt bốn phương án gần giống nhau: cả bốn đều là những việc hợp lệ và nên làm trong một tài khoản AWS, nhưng ba trong số đó chỉ quan sát hệ thống — chúng cho bạn biết chuyện gì đang xảy ra, chứ không đứng chắn giữa kẻ tấn công và tài nguyên của bạn.

Từ khoá thứ hai đáng chú ý là "one method" — đề không đòi một kiến trúc phòng thủ đầy đủ, chỉ cần một biện pháp đúng bản chất. Vì vậy đừng loại đáp án chỉ vì nó "chưa đủ chống được mọi kiểu DDoS".

Vậy nên cách đọc đề đúng là: trong bốn lựa chọn, cái nào thực sự chặn hoặc lọc lưu lượng độc hại trước khi nó chạm tới tài nguyên?

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

Đáp án đúng theo tệp là D — "Configure a firewall in front of resources."

Đặt một firewall ở phía trước tài nguyên là biện pháp giảm thiểu DDoS đúng nghĩa vì nó thu hẹp bề mặt tấn công (attack surface): chỉ những cổng, giao thức và nguồn lưu lượng được cho phép mới đi qua, phần còn lại bị chặn ngay tại lớp biên thay vì tiêu tốn tài nguyên của ứng dụng phía sau. AWS mô tả đây là một trong các mitigation technique nền tảng trong tài liệu best practices về DDoS resiliency.

Điểm mấu chốt: firewall hành động trên gói tin — nó drop lưu lượng. Ba phương án còn lại chỉ ghi lại hoặc hiển thị thông tin, và một hệ thống đang bị DDoS thì không tự khá hơn chỉ vì bạn đang nhìn nó. AWS cũng tự động bao gồm sẵn một mức giảm thiểu DDoS cho các dịch vụ của mình, và việc thêm firewall là cách bạn chủ động nâng khả năng chống chịu đó lên.

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

A — "Enable AWS CloudTrail logging." CloudTrail ghi lại các lời gọi API trong tài khoản: ai gọi, gọi gì, lúc nào, từ đâu. Đây là công cụ audit và điều tra sau sự cố, rất giá trị cho governance và forensics. Nhưng DDoS là tấn công vào lưu lượng mạng tới ứng dụng, không phải vào API quản trị của AWS — CloudTrail thậm chí không "nhìn thấy" đợt flood đó, và dù có ghi lại thì việc ghi log không chặn được gói tin nào.

B — "Monitor the AWS Health Dashboard." Đây là phương án dễ nhầm nhất với người mới, vì nghe như "theo dõi sức khoẻ hệ thống". Nhưng Health Dashboard báo cho bạn tình trạng dịch vụ của AWS và các sự kiện ảnh hưởng đến tài nguyên của bạn từ phía AWS. Nó là kênh thông báo một chiều, thụ động — kể cả khi nó hiện thông tin liên quan, bạn vẫn chỉ đang đọc tin, không có hành động phòng thủ nào diễn ra.

C — "Use Amazon CloudWatch monitoring." Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. CloudWatch thu thập metrics và có thể đặt alarm, nên nó thực sự phát hiện được dấu hiệu bất thường: request tăng vọt, băng thông tăng đột biến, latency dựng đứng. Nhiều người chọn nó vì thấy "phát hiện sớm = bảo vệ". Nhưng CloudWatch bản thân nó là performance monitoring — nó báo động chứ không đứng chắn. Một alarm kêu inh ỏi trong khi lưu lượng độc hại vẫn đi thẳng vào server thì hệ thống vẫn sập. Nó là mảnh ghép hữu ích trong quy trình ứng phó, nhưng đề hỏi protecting against, và CloudWatch không lọc gói tin nào cả.

📌 Điểm cần nhớ

• Phân biệt observe và protect. Logging (CloudTrail), monitoring (CloudWatch) và notification (AWS Health Dashboard) đều thuộc nhóm quan sát. Chỉ phương án nào chặn / lọc / hấp thụ lưu lượng mới trả lời được câu hỏi dạng "protect against attack".
• Giảm attack surface là nguyên lý cốt lõi của DDoS mitigation trên AWS. Đặt một lớp lọc ở phía trước tài nguyên, chỉ mở đúng những gì cần mở.
• CloudTrail = API calls, không phải network traffic. Hễ câu hỏi nói về flood mạng, DDoS hay lưu lượng bất thường ở tầng ứng dụng/mạng, CloudTrail gần như luôn là distractor.
• AWS Health Dashboard là kênh thông tin, không phải công cụ bảo mật. Đừng để chữ "Health" hay "Monitor" đánh lừa thành đáp án phòng thủ.
• Đề nói "one method" thì chỉ cần một biện pháp đúng bản chất, không cần phương án hoàn hảo hay đầy đủ nhất — đừng loại đáp án đúng chỉ vì nó chưa chống được mọi biến thể tấn công.

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

Đề mô tả một website mới chạy trên Amazon EC2, với ba ràng buộc chồng lên nhau:

• "highly variable levels of traffic" — lưu lượng lên xuống thất thường, không đoán trước được.
• "must be highly available" — phải sẵn sàng cao, tức là không được có một instance đơn lẻ làm điểm chết duy nhất.
• "MOST cost-effective" — trong số các cách đều chạy được, phải chọn cách rẻ nhất.

Cụm quyết định là cặp "highly variable" + "MOST cost-effective". Nếu đề chỉ nói "highly available", một instance to đặt sau load balancer cũng tạm chấp nhận; nếu đề chỉ nói "cost-effective", có thể nghĩ tới chuyện co nhỏ tài nguyên. Nhưng khi lưu lượng biến động mà lại đòi rẻ nhất, thì lời giải bắt buộc phải tự động co giãn theo nhu cầu — trả tiền theo đúng lượng tài nguyên đang thật sự cần, không nhiều hơn. Chữ MOST viết hoa cũng là tín hiệu quen thuộc: nhiều phương án cùng "làm được việc", ta phải xếp hạng chứ không phải tìm cái duy nhất khả thi.

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

Đáp án đúng là D — Create an Amazon EC2 Auto Scaling group and configure an Elastic Load Balancer.

Cặp này giải quyết trọn cả ba ràng buộc, mỗi thành phần lo một việc:

• EC2 Auto Scaling group theo dõi nhu cầu và tự thêm instance khi tải tăng, tự bớt instance khi tải giảm. Nhờ vậy số instance đang chạy luôn bám sát lưu lượng thật — đây chính là phần trả lời cho "highly variable" và "cost-effective": lúc vắng khách thì không phải nuôi máy thừa.
• Elastic Load Balancer đặt phía trước, phân phối kết nối đến vào các instance đang lành mạnh. Đây là phần trả lời cho "highly available": một instance hỏng thì load balancer ngừng gửi traffic tới nó, còn Auto Scaling group thay thế instance đó, website vẫn phục vụ bình thường.

Điểm mấu chốt là hai dịch vụ này bổ trợ cho nhau chứ không thay thế nhau. Auto Scaling không tự chia traffic, còn load balancer không tự tạo thêm máy. Đề đòi vừa co giãn vừa sẵn sàng cao nên phải có cả hai, và D là phương án duy nhất nêu đủ.

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

A — Use the AWS CLI to launch and terminate Amazon EC2 instances to match demand. Đây là phương án gần đúng nhất về mặt ý tưởng: nó cũng nhắm tới việc khớp số instance với nhu cầu. Chỗ hỏng nằm ở chữ thủ công. Ai đó phải ngồi theo dõi và gõ lệnh; lưu lượng tăng đột ngột lúc nửa đêm thì website quá tải cho tới khi có người phản ứng. Nó cũng không nói gì tới việc phân phối traffic hay thay thế instance hỏng, nên không đáp ứng được yêu cầu "highly available". Auto Scaling chính là bản tự động, có điều kiện kích hoạt, của đúng việc mà phương án này bắt con người làm bằng tay.

B — Launch the website using an Amazon EC2 instance running on a dedicated host. Sai ở cả hai tiêu chí. Dedicated host là hình thức thuê nguyên máy chủ vật lý — đây là lựa chọn đắt, chỉ dùng khi có nhu cầu đặc thù như cách ly vật lý tài nguyên hay cần nhìn thấy thông tin của host vật lý (thường liên quan tới yêu cầu tuân thủ hoặc giấy phép phần mềm tính theo lõi/socket). Website thường không có nhu cầu đó, nên trả thêm tiền cho nó là ngược hẳn với "MOST cost-effective". Ngoài ra đề ghi rõ một instance — một điểm chết duy nhất, không có "highly available".

C — Determine the highest expected traffic and use an appropriate instance type. Đây là kiểu over-provisioning: chọn cỡ máy đủ gánh lúc cao điểm rồi chạy cố định như thế mãi. Nó có thể chịu được đỉnh tải, nhưng chính vì lưu lượng "highly variable" nên phần lớn thời gian máy chạy không hết công suất, và ta vẫn trả tiền đầy đủ cho phần dư — trái với yêu cầu rẻ nhất. Thêm nữa, đây vẫn là một instance đơn: nó hỏng là website chết, nên yêu cầu "highly available" cũng không đạt. Phương án này cũng dựa trên giả định rằng ta đoán đúng mức đỉnh — với một website mới thì đó là giả định yếu.

📌 Điểm cần nhớ

• "Variable traffic" + "cost-effective" ⇒ Auto Scaling. Đây là cặp từ khoá gần như luôn đi cùng nhau trong đề thi AWS: chỉ trả tiền cho tài nguyên đang thật sự cần, thay vì cấp phát cố định theo mức đỉnh.
• "Highly available" ⇒ nhiều instance + Elastic Load Balancer. Bất kỳ phương án nào chỉ nêu một EC2 instance đều rớt tiêu chí này, dù cấu hình máy có mạnh đến đâu.
• Auto Scaling và ELB là bộ đôi, không phải hai lựa chọn thay thế. Auto Scaling lo số lượng instance, ELB lo phân phối traffic và bỏ qua instance không lành mạnh.
• Thao tác thủ công (CLI, script chạy tay) hầu như luôn là đáp án sai khi đề hỏi cách tốt nhất, vì nó không phản ứng kịp và phụ thuộc vào con người.
• Dedicated host là lựa chọn đắt tiền, có mục đích hẹp — cách ly vật lý hoặc yêu cầu tuân thủ/giấy phép. Thấy nó xuất hiện trong câu hỏi về chi phí thì gần như chắc chắn là mồi nhử.

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

Đề hỏi: dịch vụ AWS nào dùng để gửi cả tin nhắn văn bản (text/SMS) lẫn email từ các ứng dụng phân tán (distributed applications)?

Cụm từ quyết định đáp án là "both text and email messages" — chữ both mới là chỗ phân loại. Nếu đề chỉ hỏi "gửi email" thì có tới hai phương án nghe hợp lý; chính yêu cầu một dịch vụ duy nhất phủ được cả hai kênh SMS và email mới loại được các phương án gần đúng.

Cụm thứ hai đáng chú ý là "from distributed applications" — nó đặt câu hỏi vào nhóm Application Integration (đúng như trường linhVuc của câu này), tức là nhóm các dịch vụ dùng để nối rời (decouple) các thành phần: SQS, SNS, SWF. Đọc hai cụm này cùng nhau: cần một dịch vụ tích hợp ứng dụng có khả năng đẩy thông báo ra tới người dùng cuối qua nhiều kênh.

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

Đáp án đúng theo tệp là D — Amazon Simple Notification Service (Amazon SNS).

SNS là dịch vụ nhắn tin pub/sub được quản lý hoàn toàn, dùng để tách rời microservices, hệ thống phân tán và ứng dụng serverless. Mô hình của nó là topic: hệ thống publisher đẩy một message vào topic, và topic fan out message đó tới nhiều subscriber endpoint để xử lý song song.

Điểm khiến SNS khớp với đề là danh sách endpoint mà nó hỗ trợ. Ngoài các endpoint kiểu hệ thống (hàng đợi Amazon SQS, hàm AWS Lambda, webhook HTTP/S), SNS còn đẩy thông báo được thẳng tới người dùng cuối qua mobile push, SMS và email. Đó chính là "both text and email" mà đề yêu cầu — một dịch vụ, hai kênh, gọi từ ứng dụng phân tán.

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

A — Amazon Simple Workflow Service (Amazon SWF): SWF giúp lập trình viên xây dựng, chạy và mở rộng các background job có các bước tuần tự hoặc song song. Có thể hình dung SWF như một bộ theo dõi trạng thái (state tracker) và điều phối tác vụ (task coordinator) được quản lý trên cloud. Nó điều phối công việc, không phải kênh gửi tin ra ngoài — SWF không gửi SMS hay email cho người dùng cuối. Sai cả hai vế của đề.

B — Amazon Simple Email Service (Amazon SES): đây là phương án gần đúng nhất, và cũng là bẫy chính của câu. SES đúng là dịch vụ chuyên để gửi email — nếu đề chỉ hỏi email thì SES là câu trả lời tự nhiên. Chỗ nó hỏng là vế còn lại: SES không gửi tin nhắn SMS. Đề đòi một dịch vụ làm được cả hai, nên chỉ phủ một nửa yêu cầu là bị loại. Đây đúng là kiểu câu mà bỏ qua chữ both sẽ chọn nhầm.

C — Amazon Simple Queue Service (Amazon SQS): SQS là dịch vụ hàng đợi message được quản lý hoàn toàn, dùng để tách rời và mở rộng microservices, hệ thống phân tán, ứng dụng serverless. Nó có phần "distributed applications" của đề, nên nghe cũng khá lọt tai. Nhưng mô hình của SQS là hàng đợi kiểu kéo (poll): consumer phải chủ động đọc message ra khỏi hàng đợi. SQS không đẩy thông báo tới người dùng cuối, không có endpoint SMS cũng không có endpoint email. Sai vì nhầm giữa chuyển message giữa các thành phần trong hệ thống và gửi thông báo ra tới con người.

📌 Điểm cần nhớ

• SNS = push, fan-out, nhiều kênh. Một topic đẩy ra nhiều subscriber cùng lúc: SQS queue, Lambda, HTTP/S webhook, và tới người dùng cuối qua mobile push, SMS, email. Đề nào nhắc tới "notify users", "SMS", "fan out" thì nghĩ tới SNS trước.
• SQS = pull, một message cho một consumer xử lý. Dùng để nối rời hai thành phần trong hệ thống, không phải để báo tin cho con người. Đừng lẫn SNS với SQS chỉ vì cả hai đều thuộc nhóm Application Integration.
• SES chuyên sâu về email, SNS thì rộng kênh. Câu chỉ nói email (marketing, transactional, khối lượng lớn) → nghiêng về SES; câu nói cả SMS lẫn email trong một dịch vụ → SNS.
• Đọc kỹ các từ ràng buộc như "both", "single service", "only". Trong bộ câu hỏi này, các phương án thường đều đúng một phần; chính từ ràng buộc mới quyết định phương án nào phủ đủ yêu cầu.
• SWF là điều phối luồng công việc, không phải kênh gửi tin — thấy SWF trong câu hỏi về thông báo thì gần như chắc chắn là phương án gây nhiễu.

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

Đề hỏi: một tổ chức làm thế nào để tận dụng tiered pricing (giá theo bậc dùng nhiều rẻ hơn) trải rộng qua nhiều business unit trong cùng tổ chức.

Cụm từ quyết định đáp án là "take advantage of tiered pricing across multiple business units". Hai chi tiết trong cụm này lọc sạch các phương án:

• "tiered pricing" — đây là cách tính giá bậc thang: càng dùng nhiều thì đơn giá càng giảm (điển hình là S3 storage, data transfer). Muốn hưởng bậc giá tốt hơn thì mức sử dụng phải được cộng gộp lại, chứ không phải tính riêng lẻ.
• "across multiple business units" — trong thực tế mỗi business unit thường có AWS account riêng. Nếu mỗi account tự tính tiền riêng, mỗi account đứng ở bậc thấp của mình và tổ chức mất phần giảm giá.

Vậy câu hỏi thực chất là: cơ chế nào gộp mức sử dụng của nhiều account lại để tính giá chung? Không phải cơ chế nào giúp xem chi phí, cũng không phải cơ chế nào đặt giới hạn quyền.

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

B — AWS Organizations consolidated billing.

Consolidated billing gom việc lập hóa đơn và thanh toán của nhiều AWS account về một paying account duy nhất. Lợi ích quan trọng nhất ở đây là combined usage: mức sử dụng của tất cả account trong organization được cộng lại khi tính tiền, nên tổ chức được hưởng volume pricing discount ở bậc cao hơn, đồng thời chia sẻ được cả Reserved Instance discount và Savings Plans giữa các account.

Đó chính xác là điều đề bài hỏi: nhiều business unit, mỗi bên một account, nhưng khi tính giá thì được xem như một khối lượng sử dụng duy nhất. Ngoài ra consolidated billing còn cho một hóa đơn duy nhất, dễ theo dõi chi phí xuyên account, và không tính thêm phí cho bản thân tính năng này.

Cần nhớ thêm về mô hình account: paying account chịu trách nhiệm thanh toán và không vì thế mà truy cập được tài nguyên của các account khác; các linked account vẫn hoạt động độc lập với nhau.

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

A — All Upfront Reserved Instances. Đây là một tùy chọn thanh toán của Reserved Instances cho EC2: trả trước toàn bộ để có mức chiết khấu sâu nhất. Nó là chuyện giảm giá cho một loại tài nguyên cụ thể, không phải cơ chế tổ chức hóa đơn giữa nhiều business unit, và bản thân nó không gộp mức sử dụng của nhiều account. Lưu ý điểm dễ nhầm: RI discount có được chia sẻ giữa các account — nhưng chính consolidated billing mới là thứ làm việc chia sẻ đó, chứ không phải kiểu trả trước All Upfront.

C — Cost Explorer utilization reports. Đây là công cụ quan sát: xem, phân tích, báo cáo mức sử dụng và chi phí, nhận diện chỗ lãng phí. Nó không quyết định chiến lược lập hóa đơn và không thay đổi cách AWS tính bậc giá. Nhìn thấy chi phí không làm chi phí giảm đi — đây là phương án "gần đúng" vì cũng thuộc mảng cost management, nhưng nó ở nhầm vai: báo cáo chứ không phải cơ chế gộp.

D — AWS Organizations service control policies (SCPs). Đúng dịch vụ (AWS Organizations) nhưng sai tính năng. SCP đặt trần quyền tối đa cho các account/Organizational Unit — tức là công cụ quản trị (governance), giới hạn hành động nào được phép thực hiện. Nó có thể gián tiếp kiềm chế chi tiêu bằng cách cấm dùng dịch vụ đắt tiền, nhưng hoàn toàn không liên quan tới việc cộng gộp usage để hưởng tiered pricing. Đây là bẫy phổ biến nhất của câu này: thấy "AWS Organizations" là chọn, mà không đọc tiếp vế sau.

📌 Điểm cần nhớ

• Tiered / volume pricing → nghĩ ngay tới consolidated billing. Từ khóa "gộp usage nhiều account để giá rẻ hơn" gần như luôn dẫn về AWS Organizations consolidated billing.
• AWS Organizations có hai mặt tách bạch: consolidated billing lo tiền, SCP lo quyền. Câu hỏi về chi phí thì chọn vế billing; câu hỏi về giới hạn hành động thì chọn SCP.
• Phân biệt "xem chi phí" với "giảm chi phí". Cost Explorer, Billing dashboard, Budgets thuộc nhóm quan sát/cảnh báo; consolidated billing, Reserved Instances, Savings Plans thuộc nhóm thực sự thay đổi số tiền phải trả.
• Paying account không có quyền lên tài nguyên của linked account. Gộp hóa đơn không đồng nghĩa gộp quyền truy cập — đây là chi tiết hay bị hỏi ngược trong đề.

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

Đề nêu một công ty cần dùng phần mềm của bên thứ ba (third-party software) cho workload chạy trên AWS, và hỏi AWS có tính năng hay dịch vụ nào để công ty mua (purchase) phần mềm đó hay không.

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

• "third-party software" — phần mềm do nhà cung cấp ngoài AWS làm ra, không phải dịch vụ AWS tự vận hành.
• "purchase" — hành động cần làm là tìm và mua, tức là khâu mua sắm (procurement), chứ không phải khâu quản lý sau khi đã có phần mềm, cũng không phải khâu vận hành hạ tầng.

Đây là chỗ dễ trượt: cả bốn phương án đều là dịch vụ có thật và đều đứng gần chủ đề "phần mềm / tài nguyên / quản lý", nhưng chỉ một dịch vụ đóng vai nơi bán hàng. Cứ bám vào động từ "purchase" là loại được ba phương án còn lại.

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

C — AWS Marketplace.

AWS Marketplace là một danh mục số (digital catalog) đã được kiểm duyệt, nơi tập hợp hàng nghìn sản phẩm phần mềm của các nhà cung cấp bên thứ ba. Nó phục vụ trọn vòng đời mua sắm phần mềm: discover (tìm kiếm), procure (mua), entitle (cấp quyền sử dụng), provision (triển khai) và govern (quản trị).

Các sản phẩm trên đó trải rộng nhiều nhóm — security, business applications, data & analytics — và cả theo ngành dọc như healthcare, financial services, public sector. Đúng với những gì đề bài mô tả: công ty cần phần mềm bên thứ ba cho workload trên AWS, và cần một con đường chính thống để mua nó.

Điểm mạnh thực tế của Marketplace là chi phí phần mềm được gộp chung vào hoá đơn AWS, nên nhóm mua sắm không phải mở thêm một hợp đồng riêng với từng nhà cung cấp — đây cũng là lý do câu hỏi này được xếp vào lĩnh vực AWS Cost Management.

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

A — AWS License Manager. Đây là phương án gần đúng nhất và cũng là cái bẫy chính, vì nó đúng là dịch vụ dính tới phần mềm. Nhưng vai trò của nó là quản lý giấy phép phần mềm mà bạn đã có sẵn: theo dõi số license đang dùng, gắn quy tắc để không vượt hạn mức đã mua, xử lý các mô hình license tính theo core/socket/máy. Nó bắt đầu làm việc sau khi hợp đồng license đã ký, chứ bản thân nó không phải nơi để mua phần mềm. Đề hỏi "purchase", nên License Manager lệch mất một bước trong quy trình.

B — AWS Managed Services. Đây là dịch vụ giúp vận hành hạ tầng AWS thay cho khách hàng — khách hàng không phải tự provisioning và tự chạy phần vận hành. Nó nói về ai vận hành hạ tầng, hoàn toàn không phải một kênh bán phần mềm. Chọn phương án này thường là do đọc lướt thấy chữ "Managed" rồi liên tưởng tới "được lo hết", nhưng cái được lo ở đây là operations, không phải procurement.

C — (đáp án đúng, xem mục trên).

D — AWS Resource Access Manager (RAM). Dịch vụ này dùng để chia sẻ tài nguyên AWS giữa các tài khoản trong cùng một AWS Organization hoặc giữa các OU — ví dụ chia sẻ subnet, Transit Gateway. Chữ "Resource" và chữ "Manager" nghe rộng nên dễ gây phân vân, nhưng nó chỉ làm việc với tài nguyên AWS của chính bạn giữa các tài khoản nội bộ, không liên quan gì đến phần mềm bên thứ ba và cũng không có chức năng mua bán.

📌 Điểm cần nhớ

• Thấy cụm "third-party software" đi kèm động từ mua / procure / purchase trong đề AWS → gần như chắc chắn đáp án là AWS Marketplace.
• Phân biệt theo giai đoạn trong vòng đời phần mềm: Marketplace = tìm và mua; License Manager = quản lý license đã mua. Hai dịch vụ nối tiếp nhau chứ không thay thế nhau.
• Chữ "Manager"/"Managed" trong tên dịch vụ AWS không có nghĩa gì thống nhất — AWS Managed Services là vận hành hạ tầng, Resource Access Manager là chia sẻ tài nguyên giữa các account. Đọc kỹ chức năng thật thay vì đoán theo tên.
• AWS Marketplace liên quan tới chi phí vì phần mềm mua qua đó được tính chung vào hoá đơn AWS, đó là lý do câu hỏi kiểu này hay xuất hiện ở nhóm Cost Management.

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

Đề kể chuyện một công ty eCommerce muốn dùng AWS Cloud để "quickly deliver new functionality in an iterative manner, minimizing the time to market" — tức là tung tính năng mới ra nhanh, làm theo từng vòng lặp ngắn, rút ngắn thời gian đưa sản phẩm ra thị trường. Câu hỏi chốt lại: đặc tính nào của AWS Cloud mang lại điều đó?

Cụm từ quyết định là "minimizing the time to market" (và người anh em của nó, "iterative manner"). Đây là câu hỏi về tốc độ đưa ý tưởng thành sản phẩm chạy được, chứ không phải về chi phí, không phải về khả năng chịu lỗi, cũng không phải về co giãn theo tải. Bốn phương án đều là những lợi ích có thật của cloud và nghe đều "tốt", nên phải bám đúng vào ràng buộc thời gian ra thị trường để loại.

Một mẹo đọc đề dạng này: mỗi lợi ích của cloud trả lời một câu hỏi khác nhau — nhanh ra thị trường?, chịu được hỏng hóc?, tốn bao nhiêu tiền?, tải tăng thì sao?. Ghép câu hỏi trong đề với đúng lợi ích là xong.

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

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

Trong môi trường cloud, tài nguyên IT mới chỉ cách vài cú nhấp chuột: thời gian để một lập trình viên có được máy chủ, cơ sở dữ liệu hay môi trường thử nghiệm giảm từ hàng tuần xuống còn vài phút. Không phải chờ mua sắm phần cứng, không phải chờ lắp đặt trong data center, không phải chờ phê duyệt ngân sách cho một khoản đầu tư lớn.

Hệ quả trực tiếp là chi phí và công sức để thử nghiệm một ý tưởng giảm mạnh. Đội phát triển dựng môi trường, thử, thấy không hợp thì xoá đi và làm lại — đúng cái "iterative manner" mà đề nhắc tới. Đó chính là định nghĩa của agility (tính linh hoạt, nhanh nhạy) trong tài liệu về lợi thế của điện toán đám mây của AWS, và nó gắn thẳng vào "minimizing the time to market" mà đề yêu cầu.

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

• A — Fault tolerance (khả năng chịu lỗi): nói về việc ứng dụng vẫn tiếp tục phục vụ khi một thành phần nào đó hỏng. Đây là chuyện độ sẵn sàng và độ tin cậy khi hệ thống đã chạy, không liên quan gì tới việc đưa tính năng mới ra nhanh hay chậm. Một hệ thống chịu lỗi rất tốt vẫn có thể mất sáu tháng mới ra được tính năng mới.

• B — Cost effectiveness (hiệu quả chi phí): đây là phương án gây nhiễu khá mạnh, vì agility và tiết kiệm chi phí có liên hệ với nhau — thử nghiệm rẻ hơn thì mới dám thử nhiều hơn. Nhưng nó hỏng ở chỗ trả lời sai câu hỏi: cost effectiveness nói về việc trả tiền theo mức dùng thay vì đầu tư trước, tức là lợi ích về tiền. Đề không hỏi tiền, đề hỏi thời gian ra thị trường. Khi hai phương án cùng "có phần đúng", hãy chọn cái trực tiếp trả lời ràng buộc trong đề.

• C — Elasticity (tính co giãn): cũng là phương án gần đúng, và là bẫy phổ biến nhất ở nhóm câu này vì nhiều người thấy "cloud + nhanh" là nghĩ ngay tới elasticity. Nhưng elasticity nói về việc hạ tầng tự tăng giảm theo nhu cầu tải: lúc cao điểm thì thêm tài nguyên, lúc thấp điểm thì bớt đi, nhờ vậy ứng dụng vừa chạy tốt vừa không lãng phí. Nó tối ưu cho ứng dụng đang chạy trước biến động lưu lượng, chứ không rút ngắn chu kỳ phát triển và phát hành tính năng mới.

📌 Điểm cần nhớ

• Agility = tốc độ đưa ý tưởng ra thị trường. Thấy trong đề các cụm "time to market", "innovate faster", "experiment quickly", "iterate", "provision in minutes instead of weeks" thì gần như chắc chắn đáp án là agility.
• Elasticity = co giãn theo tải, gắn với "spike in traffic", "scale in/out", "seasonal demand" — nói về hạ tầng phản ứng với nhu cầu, không nói về chu kỳ phát triển phần mềm.
• Fault tolerance trả lời câu hỏi "hỏng một chỗ thì hệ thống còn chạy không", thuộc nhóm độ tin cậy/độ sẵn sàng, không dính tới tốc độ phát hành.
• Cost effectiveness là lợi ích về tiền (trả theo mức dùng, không đầu tư trước). Khi một phương án "cũng đúng một phần" thì hãy hỏi lại: đề đang hỏi tiền, thời gian, tải, hay độ tin cậy? — chỉ giữ phương án trả lời đúng câu hỏi đó.

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

Đề mô tả một ứng dụng có "highly dynamic usage patterns" — tải lên xuống thất thường, lúc cao lúc thấp — rồi hỏi đặc tính nào của AWS Cloud khiến kiểu workload đó trở nên tiết kiệm chi phí, chọn HAI.

Cụm từ quyết định đáp án nằm ở hai chỗ, phải đọc cả hai mới lọc đúng:

• "highly dynamic" — nhu cầu tài nguyên thay đổi liên tục. Đặc tính được chọn phải liên quan tới việc hạ tầng co giãn theo tải, chứ không phải một phẩm chất chung chung của đám mây.
• "cost-effective" — đây là ràng buộc phân biệt thật sự. Cả năm phương án đều là những đặc tính có thật và đáng mong muốn của AWS Cloud, nên nếu chỉ đọc "AWS Cloud có đặc tính nào?" thì phương án nào cũng đúng. Câu hỏi thu hẹp lại: chỉ những đặc tính trực tiếp làm giảm tiền phải trả mới được tính.

Kiểu câu này gặp rất nhiều trong AWS Certified Cloud Practitioner: một danh sách toàn từ khoá quen tai, và người ra đề dựa vào việc thí sinh không đọc kỹ tính từ giới hạn ("cost-effective", "dynamic") mà chọn theo phản xạ.

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

Đáp án theo tệp là B (Pay-as-you-go pricing) và D (Elasticity). Hai đặc tính này ăn khớp chính xác với hai cụm từ trong đề, và chỉ có nghĩa trọn vẹn khi đi cùng nhau:

• D — Elasticity: hạ tầng tự thêm tài nguyên khi tải tăng và tự trả lại tài nguyên khi tải giảm. Với usage pattern dao động mạnh, đây là thứ cho phép bạn không phải mua sẵn năng lực cho mức đỉnh rồi để nó nằm không suốt phần lớn thời gian. Vế "trả lại khi tải giảm" mới là vế sinh ra tiết kiệm — chỉ scale lên thôi thì không rẻ đi.
• B — Pay-as-you-go pricing: bạn chỉ trả tiền cho phần tài nguyên thực sự dùng, theo thời gian thực dùng, không cam kết trước. Đây là thứ biến việc trả lại tài nguyên thành tiền tiết kiệm được.

Cơ chế ghép đôi: elasticity làm mức tiêu thụ tài nguyên bám theo đường nhu cầu, pay-as-you-go làm hoá đơn bám theo mức tiêu thụ. Kết quả là chi phí bám theo nhu cầu thật. Thiếu elasticity thì tài nguyên vẫn chạy không tải và pay-as-you-go vẫn tính tiền; thiếu pay-as-you-go (ví dụ trả trọn gói cho năng lực cố định) thì có scale xuống cũng chẳng hoàn lại được đồng nào.

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

• A — Strict security: bảo mật là đặc tính có thật và quan trọng của AWS Cloud, nhưng nó nói về việc bảo vệ dữ liệu và quyền truy cập, không hề liên hệ với biến động tải hay với hoá đơn. Một workload dynamic không rẻ đi hay đắt lên vì hạ tầng bảo mật chặt hay lỏng. Đây là phương án bị loại nhanh nhất trong năm cái.
• C — High availability: đây là phương án gần đúng và dễ chọn nhầm nhất, vì high availability cũng đạt được bằng cách chạy nhiều tài nguyên và thường được nhắc chung chỗ với auto scaling. Chỗ nó hỏng: high availability nói về khả năng dịch vụ vẫn phục vụ được khi có thành phần hỏng — chạy dự phòng trên nhiều Availability Zone chẳng hạn. Đó là chuyện chịu lỗi, không phải chuyện bám theo nhu cầu; và nếu có ảnh hưởng tới chi phí thì theo hướng làm tăng chi phí (phải nuôi thêm phần dự phòng), chứ không giảm.
• E — Reliability: cùng nhóm nhầm lẫn với C. Reliability là khả năng hệ thống thực hiện đúng chức năng và phục hồi sau sự cố. Nó nói về chất lượng vận hành, không nói gì về việc năng lực hạ tầng có co giãn theo tải hay không, cũng không quyết định cách tính tiền. Câu hỏi đòi đặc tính dẫn tới cost-effectiveness, và reliability không nằm trong đường nhân quả đó.

Điểm chung của A, C, E: cả ba đều là đặc tính đúng của AWS Cloud, nhưng không có cái nào kết nối được biến động tải với số tiền phải trả — đúng cái cầu nối mà đề đang hỏi.

📌 Điểm cần nhớ

• Đọc kỹ tính từ giới hạn trong đề. Với danh sách toàn từ khoá đều đúng, thứ loại phương án luôn là ràng buộc phụ — ở đây là cost-effective và dynamic usage patterns.
• Elasticity = năng lực co giãn theo nhu cầu (cả lên và xuống). High availability / Reliability = chịu lỗi và vận hành ổn định. Ba khái niệm này hay bị gộp, nhưng trong đề thi chúng trả lời ba câu hỏi khác nhau và không thay thế nhau được.
• Elasticity và pay-as-you-go pricing là một cặp: cái thứ nhất làm tài nguyên bám theo nhu cầu, cái thứ hai làm hoá đơn bám theo tài nguyên. Đề hỏi về tiết kiệm chi phí cho tải biến động mà cho chọn hai thì cặp này gần như luôn là đáp án.
• High availability và reliability thường làm tăng chi phí vì phải nuôi phần dự phòng — nên khi đề hỏi "cái gì giúp rẻ hơn", hai từ này là bẫy chứ không phải đáp án.

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

Đề hỏi: theo AWS Shared Responsibility Model, hai việc nào thuộc trách nhiệm của AWS (không phải của khách hàng)?

Cụm từ quyết định là "are the responsibility of AWS". Cả năm phương án đều là những việc có thật trong một hệ thống chạy trên AWS — điểm khác nhau duy nhất là ai làm. Mô hình này chia đôi rất rạch ròi:

• AWS chịu trách nhiệm về security of the cloud — phần hạ tầng: nhà trạm, phần cứng, mạng vật lý, tầng ảo hoá, và toàn bộ phần "bên dưới" của các dịch vụ managed.
• Khách hàng chịu trách nhiệm về security in the cloud — thứ họ đưa lên và cách họ cấu hình: dữ liệu, phân quyền, mã hoá phía client, hệ điều hành của những instance do chính họ dựng.

Cụm thứ hai đáng chú ý nằm trong phương án C: "of Amazon S3". Vá hệ điều hành nghe rất giống việc của khách hàng, nhưng chỉ đúng khi đó là OS của EC2 instance do khách hàng quản lý. Với S3 — một dịch vụ fully managed — khách hàng không hề nhìn thấy máy chủ nào để mà vá.

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

B — Provide physical security for Availability Zones. An ninh vật lý của data center và Availability Zone nằm trọn trong phần "security of the cloud". Khách hàng không có bất kỳ quyền tiếp cận nào tới cơ sở hạ tầng vật lý, cũng không biết nó được vận hành và bảo vệ ra sao — nên đây bắt buộc phải là việc của AWS.

C — Patch the operating system of Amazon S3. Amazon S3 là dịch vụ lưu trữ object được AWS quản lý hoàn toàn. Người dùng chỉ gọi API để đọc/ghi object; toàn bộ hạ tầng bên dưới, hệ điều hành, việc vá lỗi và bảo trì đều do AWS lo. Khách hàng không có cách nào chạm vào lớp OS của S3, nên trách nhiệm này thuộc về AWS.

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

A — Manage customer data. Đây là việc của khách hàng. AWS không nhìn vào nội dung dữ liệu khách hàng lưu trên nền tảng; phân loại dữ liệu, quyết định lưu gì, giữ bao lâu, xoá khi nào đều do chủ sở hữu dữ liệu quyết định. Phương án này mô tả đúng nửa "in the cloud".

D — Encrypt client-side data and authenticate data integrity. Đây là phương án dễ nhầm nhất, vì AWS có cung cấp công cụ mã hoá. Nhưng chữ client-side đã tự loại nó: mã hoá phía client nghĩa là dữ liệu được mã hoá trước khi rời khỏi phía khách hàng, nên chỉ khách hàng mới nắm khoá và mới thực hiện được. Việc quyết định có mã hoá hay không, dùng khoá nào, và kiểm tra tính toàn vẹn dữ liệu đều nằm bên khách hàng — AWS chỉ đưa ra công cụ, không tự bật giúp.

E — Perform identity and access management. Cũng gần đúng: IAM là dịch vụ do AWS xây dựng và vận hành. Nhưng đề hỏi ai thực hiện việc quản lý danh tính và quyền truy cập, chứ không hỏi ai xây dịch vụ. Chỉ khách hàng mới biết ai trong tổ chức mình cần quyền gì, nên chỉ khách hàng mới tạo được user, group, role và gắn policy. AWS vận hành IAM (thuộc "of the cloud"), còn cấu hình IAM là "in the cloud" — thuộc khách hàng.

📌 Điểm cần nhớ

• Câu thần chú phân loại nhanh: AWS lo security of the cloud, khách hàng lo security in the cloud. Gặp câu Shared Responsibility Model thì áp thẳng lằn ranh này trước khi đọc kỹ từng phương án.
• Bất cứ thứ gì vật lý — data center, Availability Zone, phần cứng, mạng vật lý, huỷ ổ đĩa — luôn là AWS, vì khách hàng không có quyền tiếp cận.
• "Patch OS" không có một câu trả lời cố định — phải xem OS của cái gì: OS của EC2 instance là việc khách hàng, còn OS bên dưới một dịch vụ fully managed như Amazon S3 là việc của AWS.
• Phân biệt "ai xây và vận hành dịch vụ" với "ai cấu hình dịch vụ". IAM là ví dụ kinh điển: AWS vận hành IAM, nhưng tạo user/role/policy là việc khách hàng. Tương tự, AWS cung cấp công cụ mã hoá, còn quyết định bật mã hoá và giữ khoá là việc khách hàng.

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

Đề hỏi: công nghệ nào tự động điều chỉnh compute capacity khi nhu cầu của ứng dụng tăng hoặc giảm?

Cụm từ quyết định nằm ở hai chỗ, phải đọc cùng nhau:

• "automatically adjust" — công nghệ đó phải tự nó thay đổi thứ gì đó, không cần người vào bấm nút.
• "compute capacity" — thứ bị thay đổi là năng lực tính toán, tức là số lượng/kích cỡ máy chủ đang phục vụ, chứ không phải cách phân phối lưu lượng hay khả năng chịu lỗi.
• "as demand ... increases or decreases" — hai chiều: tăng thì thêm, giảm thì bớt.

Bốn phương án đều là khái niệm nền tảng hay bị nhắc chung một chỗ trong tài liệu AWS (Auto Scaling, load balancing, fault tolerance, high availability), nên rất dễ lẫn. Ràng buộc phân biệt chúng chính là "compute capacity" thay đổi được cả hai chiều một cách tự động — chỉ đúng một công nghệ trong danh sách làm việc đó.

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

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

Amazon EC2 Auto Scaling giúp duy trì tính sẵn sàng của ứng dụng bằng cách tự động thêm hoặc gỡ EC2 instance theo các điều kiện bạn định nghĩa. Đây là công nghệ duy nhất trong danh sách trực tiếp tạo ra và huỷ bỏ năng lực tính toán.

Nó khớp từng chữ với đề bài:

• "automatically" — bạn khai điều kiện (ví dụ CPU trung bình của nhóm vượt một ngưỡng), hệ thống tự hành động, không cần thao tác tay.
• "adjust compute capacity" — thứ được thêm/bớt chính là EC2 instance, tức compute capacity.
• "increases or decreases" — Auto Scaling co giãn hai chiều: tải lên thì mở thêm instance, tải xuống thì thu về.

Phần giải thích tiếng Anh còn nêu hai kiểu scaling: dynamic scaling (phản ứng theo nhu cầu đang thay đổi) và predictive scaling (lên lịch sẵn số instance dựa trên nhu cầu dự đoán), dùng chung được để co giãn nhanh hơn. Ngoài ra Auto Scaling còn có nhóm tính năng fleet management để giữ cho đội instance luôn khoẻ và sẵn sàng — instance hỏng thì bị thay.

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

A — Fault tolerance (khả năng chịu lỗi). Đây là một thuộc tính kiến trúc, không phải một công nghệ tự điều chỉnh capacity. Fault tolerance nghĩa là hệ thống được thiết kế sao cho hỏng một thành phần bất kỳ cũng không ảnh hưởng tới ứng dụng. Nó nói về chịu được sự cố, còn đề hỏi về đáp ứng thay đổi nhu cầu — hai vấn đề khác nhau. Sai vì lệch hẳn chủ đề: không có yếu tố "tăng/giảm theo demand" nào ở đây.

C — Load balancing (cân bằng tải). Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi, vì load balancer đúng là đứng trước một nhóm instance và làm việc tự động theo lưu lượng. Nhưng nó hỏng ở chỗ: load balancing không bàn về compute capacity, nó chỉ phân phối các kết nối đến ra nhiều instance đang có sẵn. Load balancer không tự tạo thêm instance nào, cũng không xoá instance nào — nếu cả nhóm phía sau đều quá tải thì nó vẫn chỉ chia đều phần quá tải đó. Trong thực tế load balancing và Auto Scaling hay đi cùng nhau, nên rất dễ chọn nhầm; ranh giới cần nhớ là ai chia lưu lượng (load balancing) khác với ai thay đổi số lượng máy (Auto Scaling).

D — High availability (tính sẵn sàng cao). Cũng là một mục tiêu thiết kế, không phải cơ chế điều chỉnh capacity. High availability nhằm tối đa hoá thời gian ứng dụng còn phục vụ được, bằng cách thiết kế hệ thống phục hồi được sau sự cố. Auto Scaling có góp phần đạt được high availability, nhưng bản thân high availability không phải là thứ "tự động thêm/bớt compute capacity" — nó là kết quả mong muốn, còn đề đang hỏi công cụ. Sai vì nhầm mục tiêu với phương tiện.

📌 Điểm cần nhớ

• Thấy cụm "automatically adjust/add/remove capacity" theo demand → nghĩ ngay tới Auto Scaling. Đây là mấu chốt nhận dạng gần như tuyệt đối ở mức Cloud Practitioner.
• Phân biệt cho rõ cặp hay đi chung: Auto Scaling thay đổi số lượng instance, load balancing chỉ phân phối kết nối tới các instance đã có. Đề hỏi "capacity" → Auto Scaling; đề hỏi "distribute traffic/requests" → load balancing.
• Fault tolerance và high availability là thuộc tính/mục tiêu kiến trúc, không phải dịch vụ hay cơ chế hành động. Khi đề hỏi "công nghệ nào làm việc gì đó", hai khái niệm này thường là mồi nhử.
• Auto Scaling co giãn cả hai chiều — không chỉ thêm khi tải cao mà còn bớt khi tải thấp, và đó chính là lý do nó gắn với việc tối ưu chi phí trong các câu hỏi khác cùng chủ đề.