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

Đáp án

C — Elasticity (tính co giãn)

Vì sao đúng

Tính co giãn là khả năng lấy tài nguyên khi cần và trả lại khi không cần nữa — và đó chính là thứ chấm dứt thói quen cấp phát dư cho lúc cao điểm.

Đề mô tả rất chính xác vấn đề: trên hạ tầng tại chỗ, bạn buộc phải mua đủ cho ngày đông nhất trong năm, rồi 364 ngày còn lại tài nguyên nằm không. Trên đám mây, bạn cấp phát cho mức bình thường và để hệ thống tự giãn ra khi cần.

Vế trả lại mới là phần tạo ra tiết kiệm — và cũng là phần mà tư duy cũ hay bỏ quên.

Vì sao các phương án khác sai

• B. Horizontal scaling — là cách kỹ thuật để đạt tính co giãn (thêm bớt instance), nhưng bản thân nó là một kỹ thuật chứ không phải đặc tính của đám mây mà đề hỏi. Đây là phương án nhiễu chính.
• A. Reliability — khả năng hệ thống hoạt động đúng theo thời gian.
• D. Resiliency — khả năng phục hồi sau sự cố.

Phân biệt với một khái niệm rất gần

Đáp án

B — Amazon DynamoDB Accelerator (DAX)

Vì sao đúng

DAX là lớp cache trong bộ nhớ được thiết kế riêng cho DynamoDB, và nó giải đúng vấn đề trong đề: yêu cầu đọc tăng vọt vào mùa cao điểm làm cạn tài nguyên cơ sở dữ liệu.

Ba lý do nó là lựa chọn tốt nhất ở đây:

• Giảm độ trễ từ mili giây xuống micro giây cho các lượt đọc trúng cache.
• Giảm tải cho bảng DynamoDB, nên yêu cầu ghi không bị tranh chấp tài nguyên với yêu cầu đọc.
• Tương thích API với DynamoDB — ứng dụng chỉ đổi endpoint, không phải viết lại logic cache.

Vế cuối là điểm quan trọng nhất về công sức triển khai.

Vì sao các phương án khác sai

• A. Amazon ElastiCache — cũng là cache trong bộ nhớ và dùng được, nhưng bạn phải tự viết logic cache trong ứng dụng: kiểm tra cache trước, ghi vào cache sau, xử lý việc làm mới. Nhiều công hơn hẳn DAX. Đây là phương án nhiễu chính.
• C. Amazon CloudFront — cache nội dung web ở edge; nó không đứng trước cơ sở dữ liệu.
• D. "Amazon DynamoDB Regulator" — không tồn tại.

Đáp án

C và E

Vì sao đúng

• C. Với Elastic Beanstalk, bạn triển khai và quản lý ứng dụng nhanh chóng mà không phải tìm hiểu về hạ tầng chạy chúng — đúng, và đây là mô tả cốt lõi của dịch vụ.
• E. Không có phí thêm cho Elastic Beanstalk; bạn chỉ trả cho các tài nguyên AWS bên dưới mà ứng dụng tiêu thụ — đúng: bản thân nền tảng miễn phí, bạn trả cho EC2, ELB và EBS mà nó cấp phát.

Vì sao các phương án khác sai

• A. Beanstalk tự động hoá việc cấp phát năng lực, cân bằng tải và triển khai ứng dụng... — nội dung này đúng về mặt sự thật, nhưng theo khoá đáp án nó không nằm trong hai lựa chọn. Đây là chỗ khiến câu này khó: hai phương án đúng được chấm là C và E, dù A cũng mô tả chính xác dịch vụ.
• *B. Beanstalk hỗ trợ Java, .NET, PHP nhưng không hỗ trợ ứng dụng Docker — sai: Beanstalk có hỗ trợ Docker, cả single-container lẫn multi-container.
• *D. Beanstalk không dùng được để triển khai ứng dụng không phải web — sai: nó có loại môi trường worker dành riêng cho tiến trình nền xử lý hàng đợi SQS.

Ghi chú về cách chọn

Khi một câu "chọn hai" mà thấy ba phương án đều đúng, hãy chọn hai câu mô tả đặc điểm định danh của dịch vụ (giá trị mang lại và mô hình chi phí) thay vì câu liệt kê chi tiết kỹ thuật.

Đáp án

D — Dự đoán lưu lượng truy cập website trong vài tuần tới

Vì sao đúng

Amazon Forecast là dịch vụ dự báo chuỗi thời gian dựa trên học máy: đưa vào dữ liệu lịch sử theo thời gian, nhận về ước tính cho tương lai.

Dự đoán lưu lượng website khớp chính xác — đó là chuỗi số theo thời gian, có tính mùa vụ (ngày trong tuần, giờ trong ngày) và xu hướng dài hạn, đúng những thứ Forecast xử lý sẵn.

Nó cũng nhận dữ liệu liên quan như ngày lễ hay chiến dịch quảng cáo để cải thiện độ chính xác, và trả về khoảng dự báo theo phân vị (p10, p50, p90) chứ không chỉ một con số.

Vì sao các phương án khác sai

Ba phương án còn lại là mô tả của dịch vụ khác:

• C. Gợi ý sản phẩm cá nhân hoá dựa trên lịch sử mua hàng — Amazon Personalize. Đây là phương án nhiễu chính vì cả hai đều "dự đoán dựa trên dữ liệu quá khứ"; điểm phân biệt là Forecast dự đoán một con số theo thời gian, còn Personalize dự đoán sở thích của từng cá nhân.
• A. Dịch vụ tìm kiếm tài liệu rút được câu trả lời từ văn bản — Amazon Kendra.
• B. Phát triển và kiểm thử mô hình học máy đầy đủ — Amazon SageMaker.

Đáp án

C — AWS Cost Explorer

Vì sao đúng

Cost Explorer có tính năng dự báo (forecasting): dựa trên lịch sử chi tiêu và mức sử dụng, nó dùng mô hình học máy để ước tính chi phí trong tương lai — tới 12 tháng tới, đúng con số đề hỏi.

Dự báo đi kèm khoảng tin cậy (mức cao nhất và thấp nhất), nên bạn thấy được độ chắc chắn chứ không chỉ một con số.

Điều kiện: cần ít nhất vài tuần dữ liệu lịch sử; tài khoản mới tinh chưa dùng được.

Vì sao các phương án khác sai

• B. AWS Pricing Calculator — ước tính chi phí trước khi dùng, dựa trên cấu hình bạn tự khai; nó không nhìn vào lịch sử của bạn. Đây là phương án nhiễu chính, và điểm phân biệt là:

  	Pricing Calculator	Cost Explorer
  Dựa trên	Cấu hình bạn khai	Lịch sử chi tiêu thật
  Dùng khi	Chưa có tài khoản hoặc lập kế hoạch mới	Đã chạy một thời gian

• D. Consolidated Billing của AWS Organizations — gộp hoá đơn nhiều tài khoản, không dự báo.

• A. AWS Marketplace — cửa hàng mua phần mềm.

Đáp án

A và D

Vì sao đúng

• A. AWS Control Tower là dịch vụ native của AWS cung cấp bộ blueprint và guardrail dựng sẵn để triển khai landing zone cho các tài khoản AWS mới — đúng. Control Tower tự động dựng một môi trường đa tài khoản theo thực hành tốt: tổ chức OU, tài khoản log và audit, SSO, và các guardrail.
• D. Service Control Policy là một loại chính sách tổ chức dùng để quản lý quyền trong tổ chức — đúng: SCP đặt trần quyền tối đa cho tài khoản, kể cả root user.

Vì sao các phương án khác sai

• C. SCP có thể cấp quyền cho các tài khoản trong tổ chức — sai và là điểm quan trọng nhất: SCP không bao giờ cấp quyền, nó chỉ giới hạn quyền tối đa. Người dùng vẫn cần chính sách IAM cho phép thì mới làm được việc. Đây là phương án nhiễu chính.

  Quyền thực tế = (những gì IAM policy CHO PHÉP)  ∩  (những gì SCP KHÔNG CẤM)
  

• E. SCP mặc định ảnh hưởng tới mọi người dùng trong tổ chức, phải cấu hình mới chỉ áp cho tài khoản thành viên — sai: SCP không áp cho tài khoản quản lý (management account) dù có gắn ở đâu.

• *B. Control Tower giúp triển khai môi trường đa tài khoản và vận hành với lời nhắc và khuyến nghị hằng ngày — vế sau bịa; Control Tower cung cấp bảng điều khiển tuân thủ, không gửi lời nhắc hằng ngày.

Đáp án

A — AWS IoT Core

Vì sao đúng

IoT Core là dịch vụ được quản lý cho phép kết nối số lượng thiết bị IoT bất kỳ tới đám mây mà không cần cấp phát hay quản lý máy chủ nào.

Nó lo trọn những thứ khó của IoT:

• Message broker hỗ trợ MQTT, HTTPS và WebSocket — MQTT là giao thức nhẹ dựng riêng cho thiết bị có tài nguyên hạn chế.
• Xác thực từng thiết bị bằng chứng chỉ X.509, cùng phân quyền chi tiết.
• Device Shadow — giữ trạng thái mong muốn của thiết bị ngay cả khi thiết bị đang mất kết nối.
• Rules Engine — định tuyến thông điệp thẳng tới Lambda, DynamoDB, Kinesis, S3 mà không cần mã trung gian.

Vì sao các phương án khác sai

• B. "AWS IoT Gateway" — không tồn tại; đây là tên bịa. (Có AWS IoT Greengrass chạy phần mềm AWS trên thiết bị biên, nhưng tên khác hẳn.)
• C. Amazon Connect — dịch vụ trung tâm liên lạc; tên có chữ "Connect" nhưng không liên quan tới IoT. Đây là bẫy theo tên gọi.
• D. AWS Control Tower — dựng môi trường đa tài khoản.

Đáp án

B — Amazon Aurora

Vì sao đúng

Ứng dụng CRM chạy trên MySQL là ứng dụng quan hệ truyền thống, và Aurora là lựa chọn tự nhiên vì nó tương thích MySQL: ứng dụng kết nối bằng chính driver MySQL, câu lệnh SQL giữ nguyên, gần như không phải sửa mã.

Đổi lại, bạn được những thứ MySQL tự vận hành không có:

• Nhanh hơn tới 5 lần so với MySQL tiêu chuẩn nhờ tầng lưu trữ được thiết kế lại.
• Nhân bản 6 bản sao qua 3 Availability Zone, tự phục hồi khi hỏng.
• Lưu trữ tự co giãn tới 128 TB, không phải khai trước.
• Chuyển dự phòng dưới 30 giây.

Vì sao các phương án khác sai

• C. Amazon DynamoDB — NoSQL; ứng dụng CRM viết cho MySQL sẽ phải viết lại toàn bộ tầng dữ liệu. Đây là phương án nhiễu chính vì DynamoDB là dịch vụ nổi tiếng.
• A. Amazon Neptune — cơ sở dữ liệu đồ thị, cho bài toán quan hệ nhiều bước.
• D. Amazon ElastiCache — cache trong bộ nhớ, không phải cơ sở dữ liệu chính.

Lưu ý

Amazon RDS for MySQL cũng là lựa chọn hợp lý và rẻ hơn; Aurora đáng chọn khi cần hiệu năng và tính sẵn sàng cao hơn. RDS không nằm trong bốn phương án của câu này.

Đáp án

C — Amazon EC2

Vì sao đúng

Chi tiết quyết định trong đề: đội CNTT sẽ tự thực hiện việc quản trị cơ sở dữ liệu.

Nếu công ty muốn tự quản trị — tự cài đặt, tự vá, tự tinh chỉnh, tự sao lưu — thì họ cần quyền truy cập hệ điều hành, và chỉ EC2 cho điều đó. Bạn cài cơ sở dữ liệu quan hệ bất kỳ lên EC2 và có toàn quyền như trên máy chủ vật lý.

Đây là lựa chọn hợp lý trong vài trường hợp thật: cần phiên bản cơ sở dữ liệu mà RDS không hỗ trợ, cần cài extension hoặc agent đặc biệt, hoặc phần mềm có yêu cầu giấy phép buộc phải kiểm soát máy chủ.

Vì sao các phương án khác sai

• B. Amazon Redshift — là cơ sở dữ liệu quan hệ, nhưng được quản lý và dựng cho phân tích (OLAP) chứ không phải giao dịch. Đây là phương án nhiễu chính.
• D. Amazon DynamoDB — NoSQL, không phải quan hệ.
• A. Amazon ElastiCache — cache trong bộ nhớ.

Ghi chú về cách đọc đề

Nếu đề không nêu điều kiện "tự quản trị", câu trả lời đúng sẽ là Amazon RDS — dịch vụ quan hệ được quản lý. Chính cụm "IT department will perform database administration" là chỗ loại RDS ra, vì với RDS thì phần lớn công việc quản trị do AWS làm.

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

Đề mô tả một website có tập khách hàng toàn cầu ("a global customer base") và người dùng báo hiệu năng kém khi kết nối tới site. Câu hỏi chốt lại: dịch vụ AWS nào cải thiện trải nghiệm khách hàng bằng cách giảm latency?

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

• "global customer base" — vấn đề là khoảng cách địa lý giữa người dùng và nơi đặt nội dung. Người ở xa region thì gói tin phải đi qua nhiều chặng mạng hơn, và không có cách nào rút ngắn quãng đường đó bằng việc làm cho máy chủ gốc mạnh hơn.
• "reducing latency" — đề nói thẳng là giảm độ trễ, chứ không phải tăng thông lượng, không phải chịu tải cao hơn, cũng không phải giảm chi phí.

Ràng buộc phân biệt ở đây là: cần một dịch vụ đưa nội dung tới gần người dùng cuối về mặt địa lý. Phương án nào chỉ tác động tới phía backend hoặc tới một đường kết nối riêng lẻ đều trượt yêu cầu này.

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

A. Amazon CloudFront là dịch vụ CDN (content delivery network) của AWS. Nó phân phối dữ liệu, video, ứng dụng và API tới người dùng trên toàn cầu với độ trễ thấp và tốc độ truyền cao.

Cách nó giải quyết đúng vấn đề trong đề: CloudFront có mạng lưới edge location trải khắp thế giới. Yêu cầu của người dùng được định tuyến tới edge location gần họ nhất thay vì đi thẳng về origin. Nội dung đã được cache tại edge thì trả về ngay tại đó — quãng đường mạng ngắn lại, latency giảm theo. Ngay cả nội dung không cache được cũng đi qua mạng backbone của AWS thay vì đường Internet công cộng nhiều chặng.

Đây chính xác là kịch bản đề đưa ra: người dùng ở nhiều nơi trên thế giới, hiệu năng kém vì ở xa, cần kéo nội dung lại gần họ.

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

B. Amazon ElastiCache — đây là phương án gần đúng nhất và cũng dễ bẫy nhất, vì nó cũng có chữ "cache". Nhưng ElastiCache là dịch vụ caching cho database (Redis/Memcached), đặt giữa ứng dụng và cơ sở dữ liệu để giảm số lần truy vấn xuống DB. Nó không dùng để cache website, và quan trọng hơn: nó nằm trong region, cùng chỗ với ứng dụng của bạn. Người dùng ở châu Âu truy cập hệ thống đặt ở Mỹ vẫn phải vượt qua đúng quãng đường mạng đó — ElastiCache chỉ rút ngắn phần xử lý ở phía server, không rút ngắn phần đường truyền vốn là nguyên nhân trong đề.

C. Amazon EC2 Auto Scaling — Auto Scaling khởi tạo và huỷ bỏ EC2 instance theo nhu cầu. Nó giải quyết bài toán tải, không phải bài toán khoảng cách. Nếu đề nói site chậm vì lượng truy cập tăng đột biến làm server quá tải thì Auto Scaling mới hợp lý. Nhưng đề nhấn vào "global customer base": thêm bao nhiêu instance trong cùng một region cũng không làm gói tin từ Úc về Mỹ đi nhanh hơn.

D. AWS Direct Connect — Direct Connect là kết nối mạng riêng giữa một data center on-premises và AWS. Nó đúng là giảm latency, nhưng chỉ cho đúng một đường: từ cơ sở hạ tầng riêng của doanh nghiệp tới AWS. Người dùng cuối trên Internet toàn cầu không hề đi qua đường đó. Ngoài ra, đề không hề nhắc tới hệ thống on-premises hay môi trường hybrid nào — dấu hiệu rõ ràng cho thấy đây không phải bối cảnh của Direct Connect.

📌 Điểm cần nhớ

• Thấy "global users" + "latency" trong đề bài AWS, phản xạ đầu tiên là CloudFront — đưa nội dung ra edge location gần người dùng.
• Phân biệt hai loại cache: CloudFront cache nội dung web/API tại biên mạng cho người dùng cuối; ElastiCache cache dữ liệu truy vấn cho ứng dụng, nằm trong region. Chữ "cache" giống nhau nhưng bài toán khác hẳn.
• Auto Scaling giải bài toán tải, không giải bài toán khoảng cách. Nếu đề không nói tới lưu lượng tăng đột biến hay server quá tải thì thường không phải đáp án.
• Direct Connect chỉ có nghĩa khi đề nhắc tới on-premises / hybrid. Không có data center riêng trong đề thì loại ngay.