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

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

Đề hỏi: theo shared responsibility model, việc bảo mật nào thuộc trách nhiệm của khách hàng (customer)?

Cụm từ quyết định đáp án là "responsibility of the customer" — chỉ ba chữ này thôi, nhưng nó lật ngược toàn bộ cách chấm. Bốn phương án đều là việc bảo mật hợp lệ và đều có người làm; câu hỏi không kiểm tra bạn có biết việc đó cần làm hay không, mà kiểm tra bạn biết ai làm.

Cụm phân biệt thứ hai nằm ngay trong các phương án: "physical", "at a hardware level", "at AWS data centers". Ba từ khoá này đều trỏ về tầng vật lý — hạ tầng mà khách hàng không bao giờ chạm tới được. Trong shared responsibility model, AWS chịu trách nhiệm security of the cloud (cơ sở vật chất, phần cứng, mạng vật lý, tầng ảo hoá), còn khách hàng chịu security in the cloud (dữ liệu, cấu hình, phân quyền, mã hoá). Nhận ra từ khoá vật lý là loại được ba phương án trong vài giây.

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

D — Maintaining server-side encryption.

Mã hoá dữ liệu — cả client-side encryption lẫn server-side encryption — là trách nhiệm của khách hàng dùng AWS Cloud. Đây là một trong những mục được ghi rõ ở nửa "customer" của sơ đồ shared responsibility model.

Điểm dễ gây nhầm là chữ "server-side": nghe như việc diễn ra trên máy chủ của AWS nên tưởng AWS lo. Nhưng "server-side" ở đây mô tả nơi thao tác mã hoá xảy ra, không phải ai quyết định. Khách hàng vẫn là người bật hay không bật mã hoá, chọn phương thức mã hoá, quản lý khoá, và duy trì cấu hình đó theo thời gian. AWS cung cấp cơ chế mã hoá; việc bật lên và giữ cho nó đúng là phần của khách hàng. Đó chính là ranh giới "security in the cloud".

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

A — Maintaining physical networking configuration. Cấu hình mạng vật lý — cáp, thiết bị chuyển mạch, định tuyến trong trung tâm dữ liệu — thuộc về AWS. Đây là phương án gần đúng nhất về mặt bẫy, vì khách hàng có làm việc mạng thật: dựng VPC, subnet, route table, security group. Chỗ nó hỏng là chữ "physical": mọi thứ khách hàng cấu hình đều là mạng ảo nằm trên hạ tầng vật lý của AWS. Bỏ chữ "physical" đi thì phương án này thành đúng — nên phải đọc kỹ.

B — Maintaining firewall configurations at a hardware level. Cùng kiểu bẫy như A. Khách hàng đúng là quản lý firewall — security group, network ACL — nhưng đó là firewall phần mềm/ảo. Cụm "at a hardware level" đẩy nó về thiết bị tường lửa vật lý trong data center, và phần đó là trách nhiệm AWS. Ai đọc lướt chỉ thấy chữ "firewall" rất dễ chọn nhầm phương án này.

C — Securing servers and racks at AWS data centers. Sai rõ ràng nhất trong bốn phương án. Bảo vệ máy chủ và tủ rack ngay trong AWS data centers là an ninh vật lý thuần tuý: kiểm soát ra vào, giám sát, bảo vệ cơ sở. Khách hàng không có quyền vào trung tâm dữ liệu của AWS, nên về mặt vật lý cũng không thể làm việc này. Đây là phần lõi của "security of the cloud".

📌 Điểm cần nhớ

• AWS: security of the cloud — khách hàng: security in the cloud. Một câu này giải được phần lớn câu hỏi về shared responsibility model.
• Thấy các từ khoá physical, hardware, data center, rack, hypervisor, tầng ảo hoá → gần như chắc chắn là trách nhiệm AWS.
• Thấy dữ liệu, mã hoá (cả client-side lẫn server-side), quản lý khoá, IAM và phân quyền, cấu hình security group / network ACL, vá hệ điều hành khách → trách nhiệm khách hàng.
• Đừng để chữ "server-side" đánh lừa: nó nói nơi mã hoá diễn ra, không nói ai chịu trách nhiệm. Cả hai kiểu mã hoá đều thuộc phía khách hàng.
• Bẫy phổ biến của dạng câu này là lấy một việc đúng của khách hàng (mạng, firewall) rồi gắn thêm một tính từ vật lý để lật ngược đáp án — hãy đọc trọn vẹn phương án trước khi chọn.

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

Đề hỏi: một Cloud Practitioner dùng AWS Total Cost of Ownership (TCO) Calculator để làm gì?

Cụm từ quyết định đáp án nằm ngay trong tên công cụ: "Total Cost of Ownership" — tổng chi phí sở hữu. Đây không phải khái niệm "hoá đơn AWS tháng tới bao nhiêu", mà là khái niệm dùng để so sánh hai mô hình vận hành: giữ hạ tầng tại chỗ (on-premises) so với chuyển lên AWS Cloud. TCO tính cả những khoản mà một bảng giá dịch vụ không thể hiện: máy chủ, kho lưu trữ, thiết bị mạng, điện, làm mát, diện tích trung tâm dữ liệu, nhân sự vận hành.

Bốn phương án ở đây đều là những việc "liên quan tới chi phí trên AWS", nên phải phân biệt bằng thời điểm và mục đích:

• Chi phí đã phát sinh rồi, đem ra mổ xẻ → công cụ báo cáo.
• Chi phí sẽ phát sinh trên AWS, ước tính trước → công cụ tính giá.
• Chi phí đang phát sinh, cần cảnh báo khi vượt ngưỡng → công cụ giám sát.
• So sánh AWS với on-premises để ra con số tiết kiệm → đúng phần việc của TCO Calculator.

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

D — "Estimate savings when comparing the AWS Cloud to an on-premises environment" là đáp án đúng theo tệp.

TCO Calculator được dựng riêng cho tình huống ra quyết định chuyển dịch: người dùng khai các giả định về môi trường on-premises hiện tại, công cụ dựng lên chi phí tương đương nếu chạy trên AWS, rồi trả về mức tiết kiệm ước tính kèm bộ báo cáo đủ chi tiết để mang đi thuyết trình cho ban lãnh đạo. Công cụ cũng cho phép sửa lại các giả định mặc định cho khớp với đặc thù doanh nghiệp, vì mỗi tổ chức có cấu trúc chi phí hạ tầng khác nhau.

Nói cách khác, đầu ra của TCO Calculator là một phép so sánh giữa hai môi trường, không phải một con số hoá đơn đơn lẻ. Đó chính là điều làm nó khác hẳn ba phương án còn lại.

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

A — "Generate reports that break down AWS Cloud compute costs by duration, resource, or tags"

Đây là mô tả của AWS Cost & Usage Report. Điểm hỏng: phương án này nói về chi phí đã dùng thật trên AWS, bóc tách theo khoảng thời gian, theo từng tài nguyên hoặc theo tag. TCO Calculator không có dữ liệu sử dụng thật của tài khoản nào cả — nó chạy trên các giả định do người dùng nhập vào, nên không thể bóc tách theo tag hay theo resource cụ thể. Chú ý dấu hiệu nhận biết: "by tags" gần như luôn trỏ tới nhóm công cụ báo cáo/phân tích chi phí thực tế.

B — "Enable billing alerts to monitor actual AWS costs compared to estimated costs"

Việc bật cảnh báo hoá đơn thuộc về Amazon CloudWatch (billing alarm). Phương án này sai ở bản chất công cụ: TCO Calculator là công cụ tính toán một lần, chạy trước khi ra quyết định — nó không theo dõi liên tục, không có ngưỡng, không gửi thông báo. Từ khoá "alerts" / "monitor" cho thấy đây là chuyện giám sát vận hành, không phải chuyện lập dự toán.

C — "Estimate a monthly bill for the AWS Cloud resources that will be used"

Đâ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ó đúng ở chỗ "ước tính" và "trước khi dùng", nên rất dễ chọn nhầm. Nhưng nó mô tả AWS Pricing Calculator (trước đây là Simple Monthly Calculator): khai ra danh sách tài nguyên AWS định dùng, nhận về hoá đơn hàng tháng ước tính.

Chỗ nó hỏng: kết quả chỉ có một phía là AWS, không hề có mặt môi trường on-premises để đối chiếu, nên không ra được con số "tiết kiệm". Mà chữ "Total Cost of Ownership" trong đề đòi đúng phép so sánh đó. Quy tắc phân biệt: chỉ ước tính hoá đơn AWS → Pricing Calculator; so AWS với trung tâm dữ liệu tự vận hành → TCO Calculator.

📌 Điểm cần nhớ

• TCO Calculator = so sánh AWS với on-premises, đầu ra là mức tiết kiệm ước tính kèm báo cáo dùng cho thuyết trình lãnh đạo. Có mặt chữ "on-premises" hoặc "savings" trong phương án là dấu hiệu rất mạnh.
• AWS Pricing Calculator (Simple Monthly Calculator) = ước tính hoá đơn AWS trước khi dùng, chỉ một phía AWS, không có phép so sánh.
• AWS Cost & Usage Report = bóc tách chi phí đã phát sinh theo thời gian, tài nguyên, tag. Thấy chữ "tags" hay "break down" là nghĩ tới nhóm báo cáo chi phí thực tế.
• Billing alerts thuộc Amazon CloudWatch, không phải bất kỳ công cụ tính giá nào — cảnh báo là giám sát liên tục, còn calculator chỉ tính một lần.
• Mẹo chung cho nhóm câu hỏi AWS Cost Management: phân loại phương án theo mốc thời gian — trước khi dùng (ước tính/so sánh), đang dùng (cảnh báo/giám sát), sau khi dùng (báo cáo/phân tích).

Đáp án

C — THIẾT KẾ ĐỂ CHỊU LỖI (design for failure).

Vì sao đúng

⚠ Vùng sẵn sàng (Availability Zone) là gì: | Yếu tố | Nội dung | |---|---| | ⚠ Mỗi Vùng sẵn sàng là một hoặc nhiều trung tâm dữ liệu RIÊNG BIỆT | ⚠ nguồn điện, làm mát, mạng độc lập | | ⚠ Các AZ trong cùng một Region cách nhau về mặt vật lý | ⚠ nhưng nối bằng đường truyền độ trễ thấp | | ⚠ Một AZ hỏng thì các AZ khác vẫn chạy | ⚠ đó chính là mục đích | | ⚠ Triển khai qua nhiều AZ = loại bỏ điểm chết đơn lẻ | | | ⚠ Kết luận | ⚠ giả định rằng mọi thứ đều có thể hỏng, rồi thiết kế để hệ thống vẫn sống — đó là "design for failure" |

⚠ Câu nói nổi tiếng của AWS: ⚠ "Everything fails, all the time" ⚠ — ⚠ nên kiến trúc tốt không phải kiến trúc không bao giờ hỏng, mà là kiến trúc vẫn phục vụ được khi một phần đã hỏng.

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

• B (kích hoạt tính đàn hồi — enable elasticity) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đàn hồi cũng là một nguyên tắc trụ cột của AWS và cũng liên quan tới việc chạy nhiều máy chủ: ⚠ nhưng ⚠ đàn hồi nói về việc TĂNG GIẢM tài nguyên theo NHU CẦU, không nói về khả năng chịu lỗi ⚠; ⚠ dịch vụ lo phần đàn hồi là Auto Scaling (xem #1473 cùng lô), còn nhiều AZ lo phần sẵn sàng; ⚠ hai khái niệm hay bị gộp: đàn hồi trả lời "đủ tài nguyên khi tải tăng", chịu lỗi trả lời "vẫn chạy khi có thứ hỏng".

• A (thiết kế để linh hoạt) — ⚠ nói về khả năng thay đổi nhanh của kiến trúc; ⚠ không phải mục đích của việc trải qua nhiều AZ.

• D (tự động hoá hạ tầng) — ⚠ nói về việc dùng mã để quản lý hạ tầng; ⚠ hữu ích nhưng không liên quan trực tiếp tới nhiều AZ.

Ghi nhớ

⚠ Ba tầng cách ly của AWS: | Tầng | Nội dung | |---|---| | ⚠ REGION (vùng) | ⚠ khu vực địa lý, ví dụ ap-southeast-1 | | ⚠ AVAILABILITY ZONE (vùng sẵn sàng) | ⚠ trung tâm dữ liệu độc lập trong một Region | | ⚠ EDGE LOCATION (điểm biên) | ⚠ dùng cho CloudFront, gần người dùng cuối | | ⚠ Quy tắc kiến trúc | ⚠ triển khai qua ÍT NHẤT HAI AZ là mức tối thiểu cho một hệ thống sản xuất — đó là bài học xuất hiện trong hầu hết mọi câu hỏi về tính sẵn sàng |

⚠ Phân biệt các khái niệm hay bị lẫn: | Khái niệm | Trả lời câu hỏi | |---|---| | ⚠ Tính sẵn sàng cao (High Availability) | ⚠ hệ thống có chạy liên tục không | | ⚠ Chịu lỗi (Fault Tolerance) | ⚠ có chạy được khi một phần hỏng không | | ⚠ Khôi phục thảm hoạ (Disaster Recovery) | ⚠ khôi phục thế nào khi cả Region gặp sự cố | | ⚠ Đàn hồi (Elasticity) | ⚠ có tự tăng giảm theo tải không | | ⚠ Mẹo phân biệt | ⚠ nhắc tới NHIỀU AZ thì nghĩ tới sẵn sàng và chịu lỗi; nhắc tới NHIỀU REGION thì nghĩ tới khôi phục thảm hoạ; nhắc tới TẢI THAY ĐỔI thì nghĩ tới đàn hồi |

Từ khoá nhận diện:

"nhiều Vùng sẵn sàng" → ⚠ THIẾT KẾ ĐỂ CHỊU LỖI, loại bỏ điểm chết đơn lẻ "đàn hồi" → ⚠ tăng giảm theo NHU CẦU, không phải chịu lỗi "nhiều Region" → ⚠ khôi phục thảm hoạ "Everything fails, all the time" → ⚠ triết lý nền của kiến trúc AWS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hệ thống của bạn có chạy trên nhiều AZ không | | | Nếu một AZ mất điện thì chuyện gì xảy ra | | | Bạn có điểm chết đơn lẻ nào không | |

Và điều mà nguyên tắc thiết kế để chịu lỗi thay đổi trong cách nghĩ về hạ tầng: câu hỏi thôi là "làm sao để nó không hỏng" và trở thành "khi nó hỏng thì chuyện gì xảy ra tiếp theo".

Đáp án

A — AWS TRUSTED ADVISOR.

Vì sao đúng

⚠ Trusted Advisor làm gì: | Chức năng | Nội dung | |---|---| | ⚠ Tự động KIỂM TRA tài khoản theo các thực hành tốt | ⚠ không cần cấu hình gì | | ⚠ Có mục kiểm tra security group mở quá rộng | ⚠ đúng nhu cầu của đề | | ⚠ Đưa ra khuyến nghị cụ thể, có mức cảnh báo | ⚠ xanh, vàng, đỏ | | ⚠ Cách dùng ĐƠN GIẢN: chỉ cần mở bảng điều khiển | ⚠ đề nhấn mạnh chữ "simple method" | | ⚠ Kết luận | ⚠ đây là dịch vụ duy nhất trong bốn phương án tự phát hiện cấu hình sai và khuyến nghị sửa |

⚠ Năm nhóm kiểm tra của Trusted Advisor: ⚠ tối ưu chi phí, hiệu năng, BẢO MẬT, khả năng chịu lỗi, và giới hạn dịch vụ ⚠ — ⚠ câu hỏi này thuộc nhóm bảo mật.

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

• D (VPC Flow Logs) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó liên quan trực tiếp tới lưu lượng mạng và security group, và bạn CÓ THỂ phân tích nhật ký để suy ra cổng nào đang mở: ⚠ nhưng ⚠ Flow Logs ghi lại LƯU LƯỢNG THẬT đã đi qua, chứ không kiểm tra CẤU HÌNH ⚠; ⚠ một cổng mở toang mà chưa ai truy cập sẽ không xuất hiện trong Flow Logs — nhưng nó vẫn là lỗ hổng; ⚠ và việc phân tích nhật ký không phải là "phương pháp đơn giản" như đề yêu cầu; xem #1555 cùng lô về công dụng thật của Flow Logs.

• B (Amazon CloudWatch) — ⚠ giám sát chỉ số và nhật ký vận hành; ⚠ nó theo dõi hiệu năng, không kiểm tra cấu hình bảo mật.

• C (AWS CloudTrail) — ⚠ ghi lại AI đã gọi API nào, khi nào; ⚠ nó trả lời "ai đã mở cổng này" chứ không trả lời "cổng nào đang mở".

Ghi nhớ

⚠ Bốn dịch vụ trong đề, phân biệt nhanh: | Dịch vụ | Trả lời câu hỏi | |---|---| | ⚠ TRUSTED ADVISOR | ⚠ cấu hình của tôi có sai thực hành tốt không — ĐÁP ÁN | | ⚠ CloudWatch | ⚠ hệ thống đang chạy thế nào | | ⚠ CloudTrail | ⚠ AI đã làm gì trong tài khoản | | ⚠ VPC Flow Logs | ⚠ lưu lượng mạng nào đã đi qua — xem #1555 cùng lô | | ⚠ Mẹo nhớ ba chữ | ⚠ Advisor khuyên, Watch giám sát, Trail truy vết — ba việc khác nhau và hầu như mọi câu hỏi đều tách được bằng ba động từ này |

⚠ Các dịch vụ bảo mật khác cần biết: | Dịch vụ | Chức năng | |---|---| | ⚠ AWS Config | ⚠ theo dõi cấu hình tài nguyên theo thời gian, kiểm tra tuân thủ quy tắc | | ⚠ Amazon GuardDuty | ⚠ phát hiện mối đe doạ bằng phân tích thông minh | | ⚠ AWS Security Hub | ⚠ tổng hợp cảnh báo bảo mật từ nhiều nguồn | | ⚠ IAM Access Analyzer | ⚠ tìm tài nguyên chia sẻ ra ngoài tài khoản | | ⚠ Lưu ý cho kỳ thi | ⚠ ở mức Cloud Practitioner, Trusted Advisor là câu trả lời cho hầu hết các câu hỏi dạng "cách ĐƠN GIẢN để phát hiện vấn đề cấu hình" — các dịch vụ chuyên sâu hơn thường xuất hiện ở các chứng chỉ cao hơn |

Từ khoá nhận diện:

"cách đơn giản để phát hiện security group mở quá rộng" → ⚠ TRUSTED ADVISOR "VPC Flow Logs" → ⚠ ghi lưu lượng ĐÃ đi qua, không kiểm tra cấu hình "CloudTrail" → ⚠ ai đã gọi API nào "CloudWatch" → ⚠ giám sát chỉ số và nhật ký vận hành

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đã mở Trusted Advisor trong tài khoản của mình chưa | | | Có security group nào đang mở 0.0.0.0/0 không | | | Bạn phân biệt được ba dịch vụ Advisor, Watch và Trail chưa | |

Và lý do một cổng mở toang mà chưa ai truy cập vẫn nguy hiểm hơn nhiều so với vẻ yên tĩnh của nó: nhật ký lưu lượng chỉ cho biết ai đã vào, còn cấu hình mới cho biết ai có thể vào.

Đáp án

C — VAI TRÒ IAM (AWS IAM role).

Vì sao đúng

⚠ Vì sao IAM role là cách đúng: | Đặc điểm | Nội dung | |---|---| | ⚠ Cấp thông tin xác thực TẠM THỜI, tự động xoay vòng | ⚠ đúng yêu cầu "không dùng khoá dài hạn" | | ⚠ Gắn vào EC2 instance qua instance profile | ⚠ ứng dụng lấy được tự động | | ⚠ KHÔNG có khoá nào nằm trong mã hay tệp cấu hình | ⚠ không thể bị rò rỉ qua mã nguồn | | ⚠ Quyền được kiểm soát bằng chính sách IAM | | | ⚠ Kết luận | ⚠ đây là thực hành tốt nhất và gần như luôn là đáp án cho dạng câu hỏi này |

⚠ Nguyên tắc vàng của AWS: ⚠ không bao giờ nhúng khoá truy cập vào mã nguồn hay tệp cấu hình trên máy chủ ⚠ — ⚠ dùng vai trò cho mọi thứ chạy bên trong AWS.

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

• B (khoá truy cập IAM — access key) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó CHẠY ĐƯỢC: gắn khoá vào ứng dụng thì ứng dụng ghi được vào S3, và rất nhiều hệ thống cũ vẫn làm như vậy: ⚠ nhưng ⚠ khoá truy cập là thông tin xác thực DÀI HẠN — đúng thứ mà đề bài yêu cầu tránh ⚠; ⚠ nó không tự xoay vòng, thường bị bỏ quên trong mã nguồn hoặc trong ảnh máy ảo, và một lần rò rỉ là kẻ tấn công có quyền vô thời hạn; ⚠ đây là dạng bẫy đưa ra một giải pháp hoạt động được nhưng vi phạm chính ràng buộc mà đề đã nêu — hãy luôn đọc kỹ ràng buộc trước khi chọn.

• D (AWS Systems Manager) — ⚠ là bộ công cụ quản lý và vận hành máy chủ; ⚠ Parameter Store của nó có lưu bí mật được nhưng bản thân nó không phải cơ chế cấp quyền cho EC2 truy cập S3.

• A (Amazon Connect) — ⚠ là dịch vụ tổng đài chăm sóc khách hàng; ⚠ hoàn toàn không liên quan.

Ghi nhớ

⚠ Ba cách xác thực với AWS, xếp theo mức an toàn: | Cách | Đánh giá | |---|---| | ⚠ IAM ROLE | ⚠ an toàn nhất, tạm thời, tự xoay vòng — ĐÁP ÁN | | ⚠ IAM Identity Center / liên kết danh tính | ⚠ cho con người truy cập | | ⚠ Khoá truy cập dài hạn | ⚠ kém an toàn nhất, chỉ dùng khi không còn cách khác | | ⚠ Quy tắc thực dụng | ⚠ mọi thứ chạy BÊN TRONG AWS đều dùng vai trò; khoá dài hạn chỉ dành cho các trường hợp ngoại lệ như ứng dụng chạy tại chỗ không nối được với AWS |

⚠ Vai trò IAM dùng ở đâu: | Tình huống | Nội dung | |---|---| | ⚠ EC2 truy cập S3, DynamoDB, ... | ⚠ instance profile — câu này | | ⚠ Hàm Lambda truy cập dịch vụ khác | ⚠ execution role | | ⚠ Tài khoản này truy cập tài khoản kia | ⚠ cross-account role | | ⚠ Người dùng liên kết từ hệ thống danh tính công ty | | | ⚠ Điểm chung của mọi vai trò | ⚠ thông tin xác thực có THỜI HẠN và được cấp qua STS — nên ngay cả khi bị lộ, cửa sổ khai thác cũng rất hẹp |

⚠ Nếu buộc phải dùng khoá dài hạn: | Biện pháp | Nội dung | |---|---| | ⚠ Lưu trong Secrets Manager, không nhúng vào mã | ⚠ liên hệ #3603 cùng lô | | ⚠ Xoay vòng định kỳ | | | ⚠ Cấp quyền tối thiểu cần thiết | | | ⚠ Bật ghi nhật ký để giám sát việc sử dụng | | | ⚠ Nhận xét | ⚠ mọi biện pháp trên đều là cách giảm thiểu rủi ro của một lựa chọn vốn đã kém an toàn — nên nếu có thể dùng vai trò thì đừng bao giờ chọn khoá dài hạn |

Từ khoá nhận diện:

"không dùng thông tin xác thực dài hạn" → ⚠ IAM ROLE "IAM access key" → ⚠ chính là thông tin xác thực DÀI HẠN mà đề yêu cầu tránh "Systems Manager" → ⚠ quản lý vận hành, không phải cơ chế cấp quyền "Amazon Connect" → ⚠ tổng đài chăm sóc khách hàng, không liên quan

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng của bạn có khoá nào nằm trong mã nguồn không | | | Các EC2 của bạn có dùng vai trò không | | | Có khoá truy cập nào chưa bao giờ được xoay vòng không | |

Và lý do một khoá truy cập dài hạn nguy hiểm hơn nhiều so với vẻ tiện lợi của nó: nó không có ngày hết hạn, nên một lần rò rỉ là một cánh cửa mở vĩnh viễn cho tới khi có người nhận ra.

Đáp án

C — AWS CLOUDHSM.

Vì sao đúng

⚠ CloudHSM là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Mô đun bảo mật phần cứng CHUYÊN DỤNG | ⚠ đúng cụm "dedicated hardware appliance" của đề | | ⚠ Khách hàng TOÀN QUYỀN kiểm soát khoá | ⚠ AWS không truy cập được | | ⚠ Đạt chuẩn FIPS 140-2 Cấp 3 | ⚠ yêu cầu tuân thủ cao nhất | | ⚠ Là thiết bị đơn tenant, chỉ phục vụ một khách hàng | | | ⚠ Kết luận | ⚠ dùng khi yêu cầu pháp lý hoặc hợp đồng đòi hỏi phần cứng riêng và quyền kiểm soát khoá tuyệt đối |

⚠ Từ khoá quyết định trong đề: ⚠ "dedicated hardware appliances" ⚠ — ⚠ chỉ CloudHSM đáp ứng được yêu cầu về phần cứng chuyên dụng.

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

• A (AWS Key Management Service — KMS) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ KMS cũng là dịch vụ quản lý khoá mã hoá, cũng dùng phần cứng HSM ở bên dưới, và trong đa số trường hợp thì KMS mới là lựa chọn đúng: ⚠ nhưng ⚠ KMS là dịch vụ ĐA TENANT được quản lý hoàn toàn — bạn không có thiết bị riêng và không kiểm soát phần cứng ⚠; ⚠ đề yêu cầu rõ "thiết bị phần cứng CHUYÊN DỤNG", và đó chính là điểm khác biệt duy nhất giữa hai dịch vụ; ⚠ quy tắc phân biệt: cần tuân thủ FIPS 140-2 Cấp 3 hoặc phải tự quản lý khoá tuyệt đối thì chọn CloudHSM, còn lại thì chọn KMS vì nó đơn giản và rẻ hơn nhiều.

• B (AWS Directory Service) — ⚠ là dịch vụ thư mục, tương đương Active Directory; ⚠ dùng để quản lý danh tính, không quản lý khoá mã hoá.

• D (AWS Secrets Manager) — ⚠ lưu và tự động xoay vòng BÍ MẬT như mật khẩu, chuỗi kết nối; ⚠ không phải thiết bị phần cứng — xem #3603 cùng lô.

Ghi nhớ

⚠ KMS và CloudHSM, bảng so sánh: | Yếu tố | KMS | CloudHSM | |---|---|---| | ⚠ Mô hình | ⚠ đa tenant, được quản lý hoàn toàn | ⚠ đơn tenant, thiết bị riêng | | ⚠ Ai kiểm soát khoá | ⚠ AWS quản lý hạ tầng | ⚠ KHÁCH HÀNG toàn quyền | | ⚠ Chuẩn tuân thủ | ⚠ FIPS 140-2 Cấp 3 với khoá đặc biệt | ⚠ FIPS 140-2 Cấp 3 | | ⚠ Chi phí và độ phức tạp | ⚠ thấp | ⚠ cao hơn nhiều | | ⚠ Tích hợp với dịch vụ AWS | ⚠ rất sâu, gần như mọi dịch vụ | ⚠ hạn chế hơn | | ⚠ Cách chọn | ⚠ mặc định dùng KMS; chỉ chuyển sang CloudHSM khi có yêu cầu tuân thủ hoặc hợp đồng BẮT BUỘC phần cứng riêng — đó cũng chính là tình huống mà đề bài mô tả |

⚠ Các dịch vụ bảo mật dữ liệu, phân biệt nhanh: | Dịch vụ | Dùng cho | |---|---| | ⚠ KMS | ⚠ tạo và quản lý khoá mã hoá cho các dịch vụ AWS | | ⚠ CLOUDHSM | ⚠ phần cứng chuyên dụng, kiểm soát khoá tuyệt đối — ĐÁP ÁN | | ⚠ Secrets Manager | ⚠ lưu và xoay vòng mật khẩu, chuỗi kết nối | | ⚠ Certificate Manager (ACM) | ⚠ quản lý chứng chỉ TLS | | ⚠ Mẹo nhớ | ⚠ HSM có chữ "Hardware" ngay trong tên — nên mọi câu hỏi nhắc tới thiết bị phần cứng chuyên dụng đều dẫn về CloudHSM |

Từ khoá nhận diện:

"thiết bị phần cứng chuyên dụng" → ⚠ CLOUDHSM "KMS" → ⚠ đa tenant, được quản lý, mặc định cho hầu hết trường hợp "Directory Service" → ⚠ dịch vụ thư mục, quản lý danh tính "Secrets Manager" → ⚠ lưu và xoay vòng bí mật, xem #3603 cùng lô

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Yêu cầu tuân thủ của bạn có đòi phần cứng riêng không | | | Bạn có cần AWS hoàn toàn không truy cập được khoá không | | | Nếu không có hai yêu cầu trên thì KMS đã đủ chưa | |

Và lý do CloudHSM không phải lựa chọn mặc định dù nó an toàn hơn: quyền kiểm soát tuyệt đối cũng có nghĩa là trách nhiệm tuyệt đối — mất khoá trong CloudHSM là mất luôn dữ liệu, và không có ai để nhờ khôi phục.

Đáp án

A — AMAZON EC2.

Vì sao đúng

⚠ Snowball Edge là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Thiết bị vật lý để di chuyển dữ liệu quy mô lớn | ⚠ hàng chục tới hàng trăm terabyte | | ⚠ Có sẵn NĂNG LỰC TÍNH TOÁN ngay trên thiết bị | ⚠ điểm khác biệt so với Snowball thường | | ⚠ Chạy được các phiên bản EC2 ngay tại chỗ | ⚠ ĐÁP ÁN | | ⚠ Cũng chạy được hàm Lambda | | | ⚠ Dùng ở nơi mạng yếu hoặc không có mạng | ⚠ tàu biển, mỏ dầu, hiện trường xa | | ⚠ Kết luận | ⚠ chữ "Edge" trong tên nghĩa là xử lý được ngay tại biên, chứ không chỉ chở dữ liệu |

⚠ Vì sao tính năng này hữu ích: ⚠ dữ liệu có thể được LỌC và XỬ LÝ ngay tại chỗ trước khi chuyển về AWS ⚠ — ⚠ giảm khối lượng phải vận chuyển và cho kết quả ngay tại hiện trường.

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

• B (AWS Database Migration Service — DMS) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ cả hai đều là công cụ DI CHUYỂN dữ liệu lên AWS, nên chúng nghe như thuộc cùng một họ và có thể phối hợp với nhau: ⚠ nhưng ⚠ DMS là dịch vụ chạy TRÊN ĐÁM MÂY, di chuyển cơ sở dữ liệu qua đường mạng ⚠; ⚠ nó không phải thứ chạy BÊN TRONG một thiết bị Snowball Edge; ⚠ câu hỏi hỏi Snowball Edge hỗ trợ SẴN dịch vụ nào chạy trên chính nó, và câu trả lời là năng lực tính toán EC2.

• C (AWS Server Migration Service) — ⚠ di chuyển máy ảo tại chỗ lên AWS qua mạng; ⚠ cũng không chạy trên thiết bị Snowball.

• D (AWS Trusted Advisor) — ⚠ dịch vụ khuyến nghị cấu hình; ⚠ hoàn toàn không liên quan — xem #1466 cùng lô.

Ghi nhớ

⚠ Họ dịch vụ Snow, phân biệt theo dung lượng: | Thiết bị | Dung lượng và đặc điểm | |---|---| | ⚠ Snowcone | ⚠ nhỏ nhất, vài terabyte, xách tay được | | ⚠ SNOWBALL EDGE | ⚠ hàng chục terabyte, CÓ năng lực tính toán — câu này | | ⚠ Snowmobile | ⚠ xe container, tới hàng trăm petabyte | | ⚠ Cách chọn | ⚠ tính xem chuyển qua mạng mất bao lâu: nếu quá vài tuần thì dùng thiết bị vật lý — với đường truyền phổ thông, 100 terabyte có thể mất hàng tháng qua mạng nhưng chỉ vài ngày bằng đường chuyển phát |

⚠ Hai chế độ của Snowball Edge: | Chế độ | Nội dung | |---|---| | ⚠ Storage Optimized | ⚠ tối ưu cho dung lượng lưu trữ | | ⚠ Compute Optimized | ⚠ nhiều năng lực tính toán hơn, có tuỳ chọn GPU | | ⚠ Điểm chung | ⚠ cả hai đều chạy được EC2 và Lambda ngay trên thiết bị — đó là thứ phân biệt Snowball Edge với các cách chuyển dữ liệu thuần tuý |

⚠ Các cách đưa dữ liệu lên AWS: | Cách | Phù hợp khi | |---|---| | ⚠ Qua Internet trực tiếp | ⚠ dữ liệu nhỏ, mạng tốt | | ⚠ AWS Direct Connect | ⚠ đường truyền riêng, chuyển thường xuyên | | ⚠ DataSync | ⚠ đồng bộ liên tục qua mạng | | ⚠ Họ SNOW | ⚠ dữ liệu rất lớn hoặc mạng yếu — câu này | | ⚠ Nguyên tắc chọn | ⚠ so sánh THỜI GIAN chuyển qua mạng với thời gian chuyển phát thiết bị — đó là phép tính duy nhất cần làm, và nó thường cho câu trả lời rất rõ ràng |

Từ khoá nhận diện:

"Snowball Edge hỗ trợ sẵn dịch vụ nào" → ⚠ AMAZON EC2 (và Lambda) "DMS" → ⚠ di chuyển cơ sở dữ liệu qua MẠNG, chạy trên đám mây "SMS" → ⚠ di chuyển máy ảo qua mạng "Edge" → ⚠ nghĩa là xử lý được ngay tại biên, không chỉ chở dữ liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu của bạn chuyển qua mạng mất bao lâu | | | Nơi lấy dữ liệu có mạng ổn định không | | | Bạn có cần xử lý dữ liệu ngay tại chỗ không | |

Và điều mà chữ "Edge" trong tên thiết bị thật sự nói lên: nó không chỉ là một ổ cứng biết đi, mà là một mẩu đám mây được mang tới nơi không có đám mây.

Đáp án

A — AMAZON DYNAMODB.

Vì sao đúng

⚠ Vì sao DynamoDB là lựa chọn đúng: | Yêu cầu | DynamoDB đáp ứng thế nào | |---|---| | ⚠ Công ty đang dùng cơ sở dữ liệu NoSQL | ⚠ DynamoDB là dịch vụ NoSQL của AWS | | ⚠ Cần THAY THẾ bằng dịch vụ tương đương trên đám mây | ⚠ cùng mô hình dữ liệu khoá – giá trị và tài liệu | | ⚠ Được quản lý hoàn toàn | ⚠ không phải vận hành máy chủ | | ⚠ Mở rộng tự động, độ trễ vài mili giây | | | ⚠ Kết luận | ⚠ đây là dịch vụ NoSQL duy nhất trong bốn phương án |

⚠ Ghép cặp cần nhớ: ⚠ NoSQL thì nghĩ tới DynamoDB, quan hệ thì nghĩ tới RDS hoặc Aurora ⚠ — ⚠ đây là cặp ghép xuất hiện trong rất nhiều câu hỏi.

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

• D (Amazon QLDB — cơ sở dữ liệu sổ cái) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ QLDB cũng KHÔNG phải cơ sở dữ liệu quan hệ truyền thống, nên nếu chỉ loại theo tiêu chí "không phải SQL" thì nó vẫn còn lại: ⚠ nhưng ⚠ QLDB là cơ sở dữ liệu SỔ CÁI — nó ghi lại một lịch sử thay đổi bất biến và có thể kiểm chứng bằng mật mã ⚠; ⚠ nó dành cho các bài toán cần vết kiểm toán không thể sửa đổi như hồ sơ tài chính hay chuỗi cung ứng; ⚠ thay một cơ sở dữ liệu NoSQL thông thường bằng QLDB là chọn sai loại hoàn toàn — cùng "không phải SQL" nhưng phục vụ mục đích khác hẳn.

• B (Amazon RDS for MySQL) — ⚠ là cơ sở dữ liệu QUAN HỆ; ⚠ khác mô hình dữ liệu, sẽ phải thiết kế lại toàn bộ.

• C (Amazon Redshift) — ⚠ là kho dữ liệu phân tích; ⚠ tối ưu cho truy vấn phân tích lớn, không cho giao dịch nhanh.

Ghi nhớ

⚠ Các loại cơ sở dữ liệu của AWS và khi nào dùng: | Loại | Dịch vụ | Dùng cho | |---|---|---| | ⚠ QUAN HỆ | ⚠ RDS, Aurora | ⚠ dữ liệu có cấu trúc, giao dịch, JOIN | | ⚠ NoSQL khoá – giá trị | ⚠ DYNAMODB | ⚠ truy cập nhanh theo khoá, quy mô lớn — ĐÁP ÁN | | ⚠ KHO DỮ LIỆU | ⚠ Redshift | ⚠ phân tích trên khối dữ liệu lớn | | ⚠ SỔ CÁI | ⚠ QLDB | ⚠ lịch sử bất biến, kiểm toán được | | ⚠ BỘ NHỚ ĐỆM | ⚠ ElastiCache | ⚠ truy cập cực nhanh trong bộ nhớ | | ⚠ ĐỒ THỊ | ⚠ Neptune | ⚠ quan hệ phức tạp, mạng xã hội | | ⚠ CHUỖI THỜI GIAN | ⚠ Timestream | ⚠ dữ liệu cảm biến, giám sát | | ⚠ Cách học bảng này | ⚠ đề thi hầu như luôn cho một từ khoá về LOẠI dữ liệu hoặc KIỂU TRUY CẬP — nhận ra từ khoá đó là chọn được dịch vụ mà không cần biết chi tiết kỹ thuật |

⚠ Đặc điểm nổi bật của DynamoDB: | Đặc điểm | Nội dung | |---|---| | ⚠ Không cần quản lý máy chủ | ⚠ serverless hoàn toàn | | ⚠ Độ trễ ổn định vài mili giây ở mọi quy mô | | | ⚠ Tự động mở rộng theo lưu lượng | | | ⚠ Có chế độ theo yêu cầu và chế độ định sẵn | ⚠ chọn theo mức dự đoán được của tải | | ⚠ Sao lưu và khôi phục theo thời điểm | | | ⚠ Đánh đổi cần biết | ⚠ DynamoDB rất nhanh khi truy cập theo khoá, nhưng các truy vấn phức tạp kiểu JOIN thì không làm được — nên việc chuyển từ NoSQL sang NoSQL là hợp lý, còn chuyển từ quan hệ sang DynamoDB thì phải thiết kế lại mô hình dữ liệu |

Từ khoá nhận diện:

"NoSQL" → ⚠ DYNAMODB "QLDB" → ⚠ sổ cái bất biến, dùng cho kiểm toán "RDS / Aurora" → ⚠ cơ sở dữ liệu quan hệ "Redshift" → ⚠ kho dữ liệu phân tích

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu của bạn được truy cập theo khoá hay theo truy vấn phức tạp | | | Bạn có cần JOIN giữa các bảng không | | | Mô hình dữ liệu hiện tại có chuyển thẳng sang được không | |

Và nguyên tắc chọn cơ sở dữ liệu trên đám mây, khác hẳn thời chỉ có một lựa chọn: chọn theo CÁCH DỮ LIỆU ĐƯỢC TRUY CẬP chứ không theo thói quen — vì mỗi loại được thiết kế cho một kiểu truy cập rất cụ thể.

Đáp án

B — AWS GLUE.

Vì sao đúng

⚠ AWS Glue làm gì: | Chức năng | Nội dung | |---|---| | ⚠ Dịch vụ ETL được quản lý hoàn toàn | ⚠ trích xuất, biến đổi, nạp — đúng đề hỏi | | ⚠ Có Data Catalog lưu siêu dữ liệu về các nguồn | | | ⚠ Có Crawler tự dò cấu trúc dữ liệu | | | ⚠ Chạy không cần máy chủ | ⚠ serverless, trả theo lượng dùng | | ⚠ Chuẩn bị dữ liệu cho Athena, Redshift, QuickSight | ⚠ đúng cụm "prepare data for analytics" | | ⚠ Kết luận | ⚠ đây là dịch vụ ETL chính thức của AWS |

⚠ Ghép cặp cần nhớ: ⚠ nhắc tới ETL thì nghĩ ngay tới Glue ⚠ — ⚠ đó là ghép cặp một–một, hầu như không có ngoại lệ ở mức Cloud Practitioner.

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

• A (Amazon Athena) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ Athena cũng thuộc bộ công cụ phân tích, cũng làm việc với dữ liệu trên S3, và thường được dùng NGAY SAU Glue trong cùng một luồng công việc: ⚠ nhưng ⚠ Athena là dịch vụ TRUY VẤN — nó chạy câu lệnh SQL trên dữ liệu đã có sẵn ở S3 ⚠; ⚠ nó KHÔNG biến đổi hay nạp dữ liệu, tức là không làm phần T và L của ETL; ⚠ quan hệ thật giữa hai dịch vụ: Glue chuẩn bị và lập danh mục dữ liệu, rồi Athena truy vấn dữ liệu đó — chúng bổ sung nhau chứ không thay thế nhau.

• C (Amazon S3 Select) — ⚠ cho phép lấy một PHẦN nội dung của một đối tượng S3 bằng SQL đơn giản; ⚠ nó tiết kiệm băng thông chứ không phải công cụ ETL.

• D (Amazon QuickSight) — ⚠ là công cụ trực quan hoá và bảng điều khiển; ⚠ nó nằm ở CUỐI luồng, sau khi dữ liệu đã sẵn sàng.

Ghi nhớ

⚠ Luồng phân tích dữ liệu điển hình trên AWS: | Bước | Dịch vụ | |---|---| | ⚠ 1. Thu thập và lưu trữ thô | ⚠ S3, Kinesis | | ⚠ 2. ETL: làm sạch và biến đổi | ⚠ AWS GLUE — ĐÁP ÁN | | ⚠ 3. Truy vấn | ⚠ Athena (trên S3), Redshift (kho dữ liệu) | | ⚠ 4. Trực quan hoá | ⚠ QuickSight | | ⚠ Cách nhớ cả luồng | ⚠ lưu, dọn, hỏi, vẽ — bốn động từ tương ứng bốn nhóm dịch vụ, và hầu hết câu hỏi về phân tích dữ liệu chỉ hỏi bạn đang ở bước nào |

⚠ Ba thành phần chính của Glue: | Thành phần | Nội dung | |---|---| | ⚠ Data Catalog | ⚠ kho siêu dữ liệu chung, Athena và Redshift đều dùng được | | ⚠ Crawler | ⚠ tự dò cấu trúc và cập nhật danh mục | | ⚠ ETL Jobs | ⚠ công việc biến đổi dữ liệu, viết bằng Python hoặc Scala | | ⚠ Giá trị của Data Catalog | ⚠ nó là điểm chung mà nhiều dịch vụ phân tích cùng tham chiếu — nên định nghĩa một lần rồi dùng được ở Athena, Redshift Spectrum và EMR, thay vì khai báo lại ở từng nơi |

Từ khoá nhận diện:

"ETL, chuẩn bị dữ liệu cho phân tích" → ⚠ AWS GLUE "Athena" → ⚠ TRUY VẤN SQL trên dữ liệu đã có ở S3 "S3 Select" → ⚠ lấy một phần nội dung của một đối tượng "QuickSight" → ⚠ trực quan hoá, ở cuối luồng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu của bạn có cần làm sạch trước khi phân tích không | | | Bạn có danh mục siêu dữ liệu dùng chung không | | | Bạn đang ở bước nào trong bốn bước của luồng phân tích | |

Và lý do bước ETL thường tốn công nhất trong mọi dự án dữ liệu: phần lớn thời gian của một nhà phân tích không dành cho việc phân tích, mà dành cho việc làm cho dữ liệu đủ sạch để phân tích được.

Đáp án

D và E — LƯU TRỮ TRANG WEB TĨNH và LƯU TRỮ MEDIA (chọn HAI).

Vì sao đúng

⚠ Amazon S3 phù hợp với hai trường hợp này thế nào: | Trường hợp | Vì sao phù hợp | |---|---| | ⚠ TRANG WEB TĨNH | ⚠ S3 phục vụ trực tiếp HTML, CSS, JS, ảnh | | ⚠ Không cần máy chủ web, chi phí rất thấp | ⚠ kết hợp CloudFront để tăng tốc toàn cầu | | ⚠ LƯU TRỮ MEDIA | ⚠ ảnh, video, tệp âm thanh dung lượng lớn | | ⚠ Độ bền 99,999999999% (mười một số chín) | ⚠ gần như không mất dữ liệu | | ⚠ Bản chất của S3 | ⚠ lưu trữ ĐỐI TƯỢNG — mỗi tệp là một đối tượng có khoá, siêu dữ liệu và nội dung |

⚠ Điểm mấu chốt của lưu trữ đối tượng: ⚠ truy cập qua HTTP theo khoá, không phải theo khối như ổ đĩa ⚠ — ⚠ nên nó tuyệt vời cho tệp tĩnh và rất kém cho những thứ cần ghi sửa liên tục ở mức khối.

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

• A (bộ nhớ đệm trong RAM) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ cả hai đều là "lưu trữ" và người mới học dễ gộp mọi dịch vụ lưu trữ lại với nhau: ⚠ nhưng ⚠ S3 truy cập qua mạng với độ trễ hàng chục mili giây, còn bộ nhớ đệm cần độ trễ dưới một mili giây ⚠; ⚠ dịch vụ đúng cho việc này là Amazon ElastiCache (Redis hoặc Memcached); ⚠ chênh lệch độ trễ giữa hai loại là hàng trăm lần, nên chúng phục vụ những bài toán hoàn toàn khác nhau dù cùng mang chữ "lưu".

• B (hàng đợi tin nhắn) — ⚠ đó là việc của Amazon SQS; ⚠ S3 không có cơ chế hàng đợi, tuy nó có thể phát sự kiện khi có tệp mới.

• C (cài đặt hệ điều hành) — ⚠ hệ điều hành cần lưu trữ KHỐI để khởi động và ghi liên tục; ⚠ đó là việc của Amazon EBS, không phải S3.

Ghi nhớ

⚠ BA LOẠI lưu trữ của AWS, phân biệt dứt khoát: | Loại | Dịch vụ | Dùng cho | |---|---|---| | ⚠ ĐỐI TƯỢNG (object) | ⚠ S3 | ⚠ tệp, ảnh, video, sao lưu, web tĩnh — ĐÁP ÁN | | ⚠ KHỐI (block) | ⚠ EBS | ⚠ ổ đĩa cho EC2, cài hệ điều hành, cơ sở dữ liệu | | ⚠ TỆP (file) | ⚠ EFS, FSx | ⚠ hệ thống tệp chia sẻ cho nhiều máy chủ | | ⚠ Câu hỏi phân biệt nhanh | ⚠ "cái này có cần gắn vào một máy chủ như một ổ đĩa không" — cần thì là khối; nhiều máy cùng đọc ghi như thư mục chung thì là tệp; truy cập qua HTTP theo tên tệp thì là đối tượng |

⚠ Các trường hợp dùng S3 phổ biến: | Trường hợp | Nội dung | |---|---| | ⚠ Lưu trữ media và tệp người dùng tải lên | ⚠ ĐÁP ÁN | | ⚠ Trang web tĩnh | ⚠ ĐÁP ÁN | | ⚠ Sao lưu và lưu trữ dài hạn | ⚠ với các lớp Glacier | | ⚠ Hồ dữ liệu cho phân tích | ⚠ liên hệ #1471 cùng lô | | ⚠ Phân phối nội dung kết hợp CloudFront | | | ⚠ Điều S3 KHÔNG làm được | ⚠ không dùng làm ổ đĩa hệ điều hành, không dùng làm bộ nhớ đệm độ trễ thấp, không dùng làm hàng đợi — ba việc này tương ứng với ba phương án nhiễu của câu hỏi |

⚠ Các lớp lưu trữ của S3: | Lớp | Dùng khi | |---|---| | ⚠ Standard | ⚠ truy cập thường xuyên | | ⚠ Intelligent-Tiering | ⚠ mẫu truy cập không đoán trước được | | ⚠ Standard-IA / One Zone-IA | ⚠ truy cập không thường xuyên | | ⚠ Glacier và Deep Archive | ⚠ lưu trữ dài hạn, lấy ra chậm, rẻ nhất | | ⚠ Cách tiết kiệm chi phí | ⚠ đặt quy tắc vòng đời để tự chuyển tệp cũ sang lớp rẻ hơn — với dữ liệu media thì đây thường là khoản tiết kiệm lớn nhất mà không tốn công gì |

Từ khoá nhận diện:

"trang web tĩnh" và "lưu trữ media" → ⚠ AMAZON S3 "bộ nhớ đệm trong RAM" → ⚠ ElastiCache, độ trễ dưới một mili giây "hàng đợi tin nhắn" → ⚠ Amazon SQS "cài hệ điều hành" → ⚠ Amazon EBS, lưu trữ KHỐI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn phân biệt được ba loại lưu trữ đối tượng, khối và tệp chưa | | | Dữ liệu của bạn có được đặt quy tắc vòng đời không | | | Có tệp cũ nào đang nằm ở lớp Standard mà không ai truy cập không | |

Và điều làm cho lưu trữ đối tượng khác hẳn ổ đĩa truyền thống, dù cả hai đều "chứa tệp": bạn không gắn nó vào máy nào cả — nó là một địa chỉ trên Internet, và đó là lý do nó phục vụ được cả thế giới cùng lúc.