Ngân hàng đề — AWS Certified Data Engineer Associate

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

Một tập đoàn có hai AWS account tách biệt: account vận hành (operational) sinh application logs và lưu trong Amazon CloudWatch Logs, còn account tuân thủ (compliance) là nơi đội compliance làm việc. Yêu cầu là đưa logs từ account vận hành sang Kinesis Data Stream của đội compliance để xử lý và cảnh báo thời gian thực.

Cụm từ quyết định nằm ở vế cuối của câu hỏi: "to the compliance team's Kinesis Data Stream in their separate AWS account". Đề không hỏi chung chung "làm sao chia sẻ log giữa hai account", mà đã chỉ đích danh nơi đặt stream: account của compliance. Thêm một cụm nữa hỗ trợ: đội compliance "using a different AWS account, needs to analyze these logs" — nơi phân tích, và do đó nơi đặt destination, là account compliance.

Chỉ riêng ràng buộc "stream nằm ở account compliance" đã cắt bỏ được một nửa danh sách. Nửa còn lại (A và C) giống nhau đến mức chỉ khác nhau ở chỗ đặt trust policy ở đâu — đó là điểm phân biệt thứ hai.

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

Đáp án đúng là C: tạo Kinesis Data Stream trong compliance account, rồi tạo một IAM role ở operational account có quyền ghi vào stream đó.

Hướng này khớp cả hai ràng buộc của đề. Destination stream nằm đúng nơi dữ liệu sẽ được xử lý — đội compliance sở hữu, giám sát và trả tiền cho chính stream mà họ đọc, không phải xin quyền vào tài nguyên của người khác. Còn ở phía nguồn, CloudWatch Logs của operational account cần một danh tính có quyền PutRecord lên stream đích; IAM role tạo trong operational account chính là danh tính đó, gắn với subscription filter đẩy log ra ngoài.

Đây cũng là mô hình cross-account chuẩn trên AWS: bên gửi cầm role, bên nhận sở hữu tài nguyên và cấp quyền cho role đó qua resource policy. Dữ liệu chảy một chiều từ nguồn tới đích, không cần đội compliance có quyền gì bên trong account vận hành.

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

A — Stream ở compliance account, nhưng "establish an IAM role with a trust policy in the operational account". Đâ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ị trí stream hoàn toàn đúng, chỉ hỏng ở chi tiết trust policy. Quan hệ tin cậy được thiết lập ở phía account sở hữu tài nguyên — tức compliance account — chứ không phải ở account đi assume role. Đặt trust policy nhầm phía nghĩa là mô tả sai hướng của quan hệ tin cậy, nên A bị loại dù ý tưởng tổng thể trùng với C.

B — Stream đặt ở operational account, cấp cross-account access cho IAM role của compliance. Có dùng cross-account thật, nhưng destination stream lại nằm sai account. Đội compliance sẽ phải đọc dữ liệu nằm trong account vận hành, trái với yêu cầu "compliance team's Kinesis Data Stream in their separate AWS account". Về vận hành cũng bất tiện: compliance không kiểm soát vòng đời, cấu hình hay chi phí của chính stream mình phụ thuộc vào.

D — Stream ở operational account, dùng AWS STS assume role sang compliance account. Mắc cùng lỗi gốc như B: stream sai chỗ, nên logs không tới được account compliance để phân tích. Riêng phần STS thì không sai — assume role qua STS vốn là cơ chế nằm bên dưới mọi truy cập cross-account, kể cả trong đáp án C. Nhưng nhắc đúng một cơ chế phụ không cứu được một kiến trúc đặt destination sai; điểm mấu chốt vẫn là stream phải nằm ở compliance account.

📌 Điểm cần nhớ

• Với câu hỏi cross-account, hãy đọc kỹ ai sở hữu tài nguyên đích. Đề thường nêu thẳng ("their separate AWS account") và chỉ riêng chi tiết đó đã loại được nửa số phương án.
• Nguyên tắc chung: đặt tài nguyên đích ở account tiêu thụ dữ liệu, còn account nguồn cầm IAM role để ghi sang. Dữ liệu chảy tới nơi phân tích, không bắt bên phân tích chạy ngược vào account người khác.
• Trust policy thuộc về account sở hữu role/tài nguyên được truy cập, không thuộc về account đi assume. Nhiều phương án nhiễu chỉ khác đáp án đúng đúng ở chi tiết này.
• CloudWatch Logs đẩy sang Kinesis Data Streams ở account khác là mô hình quen thuộc cho xử lý và cảnh báo thời gian thực — nhận diện cặp "CloudWatch Logs ở account A, phân tích real-time ở account B" là biết ngay hình dạng lời giải.

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

Đề mô tả một công ty phân tích tài chính lưu dữ liệu khách hàng nhạy cảm trong một S3 bucket, và hỏi nên chọn phương thức mã hoá S3 nào cùng cách quản lý khoá nào.

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

• "encrypted at rest using keys that they manage and control" — công ty phải tự quản lý và kiểm soát khoá, chứ không phải chỉ cần "có mã hoá".
• "flexibility to rotate keys" — phải xoay vòng khoá được theo ý mình.
• "enforce least privilege access to the encryption keys" — phải giới hạn quyền truy cập tới chính cái khoá, tức là cần một chỗ để viết chính sách riêng cho khoá.

Cả bốn phương án đều mã hoá at rest, nên "có mã hoá hay không" không phân biệt được gì. Ràng buộc thật nằm ở ai cầm quyền trên khoá và có viết được policy riêng cho khoá hay không.

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

D — Enable S3 server-side encryption with AWS KMS keys and create custom key policies for key rotation and access control.

SSE-KMS với customer managed key trong AWS KMS đáp ứng đủ cả ba ràng buộc:

• Quản lý và kiểm soát khoá: khoá do công ty tạo ra và sở hữu trong KMS, không phải khoá AWS tự dựng sẵn.
• Rotate khoá: KMS cho phép bật xoay vòng khoá, và công ty chủ động quyết định chuyện đó.
• Least privilege: mấu chốt nằm ở cụm custom key policies. KMS key policy (kết hợp IAM) là nơi khai chính xác principal nào được Encrypt/Decrypt/GenerateDataKey bằng khoá này. Đây chính là thứ mà đề đòi, và là thứ chỉ có ở phương án D.

Ngoài ra, mọi lần khoá được dùng đều ghi lại trong AWS CloudTrail, nên công ty audit được ai giải mã dữ liệu lúc nào — thứ rất hợp với dữ liệu tài chính nhạy cảm.

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

A — SSE-KMS với AWS managed keys và default KMS key policies. Đây là phương án gần đúng nhất và là bẫy chính của câu này. Nó vẫn dùng KMS, vẫn có CloudTrail — nhưng hỏng ở hai chữ "AWS managed" và "default policies". Khoá do AWS quản lý thì công ty không cầm quyền điều khiển vòng đời của nó, và key policy mặc định thì không sửa được để siết quyền theo ý mình. Đề đòi enforce least privilege access to the encryption keys, mà policy mặc định thì đúng nghĩa là "dùng cái AWS dựng sẵn" — không có chỗ nào để công ty áp least privilege cả. Cùng một công nghệ, khác nhau ở quyền kiểm soát.

B — SSE-S3 (Amazon S3-managed keys). Có mã hoá at rest thật, nhưng khoá do AWS quản lý hoàn toàn. Công ty không nhìn thấy khoá, không viết policy cho khoá, không chủ động rotate được. Nó trượt cả ba ràng buộc trong đề cùng lúc — đây là lựa chọn cho trường hợp "chỉ cần có mã hoá, không cần kiểm soát", ngược hẳn với tình huống ở đây.

C — SSE-C, quản lý khoá on-premises. Đúng là công ty tự giữ khoá — nghe rất khớp với "keys that they manage and control", nên đây là bẫy thứ hai. Nhưng SSE-C bắt gửi kèm khoá mã hoá trong mỗi request HTTP tới S3, nghĩa là công ty phải tự dựng toàn bộ hạ tầng lưu trữ, phân phối và bảo vệ khoá đó ở on-premises. Đổi lại, nó không có key policy để áp least privilege, không có cơ chế rotate được quản lý sẵn, và không có phần audit tích hợp như KMS. Nó chuyển gánh nặng vận hành sang công ty mà vẫn không cho họ đúng những công cụ kiểm soát mà đề yêu cầu.

📌 Điểm cần nhớ

• Đọc kỹ "keys that they manage" — cụm này gần như luôn loại SSE-S3 và đẩy đáp án về KMS với customer managed key.
• Phân biệt AWS managed key và customer managed key trong KMS: chỉ loại thứ hai mới cho sửa key policy, chủ động rotate và áp least privilege. Đề nhắc tới key policy hay quyền trên khoá thì đáp án phải là customer managed.
• SSE-C ≠ đáp án ngon cho "tự quản lý khoá": nó bắt gửi khoá theo từng request và thiếu key policy lẫn audit tích hợp, nên trong bài thi nó thường là bẫy cho những ai chỉ đọc lướt chữ "customer-provided".
• Khi đề nhấn mạnh audit / truy vết ai giải mã dữ liệu, KMS là hướng đúng vì việc dùng khoá được ghi lại qua CloudTrail.

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

Đề mô tả một ứng dụng stateful chạy trên Amazon EC2 với hai nhu cầu lưu trữ tách bạch:

1. Chỗ chứa tạm thời để xử lý tập dữ liệu lớn, đòi hỏi maximum I/O.
2. Một phần nhỏ essential state data phải tồn tại lâu hơn vòng đời của instance.

Hai cụm từ quyết định đáp án nằm ngay trong đề: "temporary storage ... with maximum I/O" và "not lost if the EC2 instance is stopped or terminated". Cụm thứ nhất trỏ thẳng tới instance store — ổ đĩa gắn vật lý vào máy chủ vật lý nên cho I/O cao nhất, nhưng dữ liệu biến mất khi instance dừng hoặc bị huỷ. Cụm thứ hai trỏ thẳng tới EBS — volume tồn tại độc lập với vòng đời instance.

Câu hỏi không bắt chọn một loại storage, mà bắt ghép đúng loại vào đúng vai trò. Mọi phương án sai đều sai ở chỗ đặt nhầm vai.

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

Đáp án A: instance store cho dữ liệu tạm, EBS cho essential state data.

• Instance store là ổ gắn trực tiếp vào host vật lý chạy instance, không đi qua mạng lưu trữ, nên đạt thông lượng và độ trễ tốt nhất trong các lựa chọn có ở đây. Đúng cho phần "processing large datasets with maximum I/O". Dữ liệu trên đó mất khi instance stop/terminate — nhưng đề nói rõ phần này chỉ là temporary, nên mất cũng không sao. Ngoài ra instance store đã nằm trong giá của instance type hỗ trợ nó, không tính phí storage riêng.
• EBS là block storage qua mạng, tồn tại như một tài nguyên riêng: instance stop rồi start lại vẫn còn dữ liệu, instance bị terminate thì volume vẫn detach ra được và attach sang instance khác. Đúng cho "essential data is not lost if the EC2 instance is stopped or terminated".

Ghép hai thứ lại là đúng cả hai vế của đề: tốc độ cho phần nặng, độ bền cho phần quan trọng.

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

B — instance store cho I/O + EBS snapshots làm backup hằng ngày cho essential data. Đây là phương án gần đúng nhất và cũng là bẫy chính. Vế I/O đúng, nhưng vế lưu trữ bền thì hiểu sai bản chất EBS snapshot: snapshot là bản chụp sao lưu của một EBS volume, không phải nơi ứng dụng ghi dữ liệu trực tiếp. Muốn có snapshot thì trước hết phải có một EBS volume để chụp — mà phương án này không hề gắn volume nào. Hơn nữa "daily backups" nghĩa là mọi thay đổi kể từ lần chụp gần nhất sẽ mất khi instance biến mất, trái với yêu cầu "not lost". Snapshot bổ sung cho persistent storage chứ không thay thế nó.

C — EBS cho essential state data + DynamoDB cho dữ liệu tạm. Vế essential data đúng, nhưng vế dữ liệu tạm sai vai. DynamoDB là NoSQL database truy cập qua API mạng, không phải block storage gắn cục bộ; ứng dụng đang xử lý dataset lớn tại chỗ không thể coi nó như một ổ đĩa làm việc. So với instance store gắn thẳng vào host, đường đi qua service endpoint không cho được mức I/O mà đề yêu cầu bằng chữ "maximum".

D — EBS phụ cho dữ liệu tạm + root device volume cho essential state data. Về mặt bền vững thì phương án này không sai (EBS ở cả hai vai đều persist được, miễn root volume không bị đặt xoá khi terminate), nhưng nó hỏng ở vế I/O và chi phí: dùng EBS cho khối lượng xử lý nặng là bỏ qua lựa chọn nhanh hơn và đã trả tiền sẵn là instance store. Đề nhấn mạnh "maximum I/O", nên phương án dùng storage qua mạng cho phần đó không phải lựa chọn tốt nhất. Thêm nữa, dồn state quan trọng lên root device là buộc số phận dữ liệu vào chính volume hệ điều hành — kém tách bạch hơn hẳn một volume dữ liệu riêng.

📌 Điểm cần nhớ

• Instance store = nhanh nhất, nhưng ephemeral. Dữ liệu mất khi instance stop hoặc terminate. Thấy đề nói "temporary", "scratch", "maximum I/O" là nghĩ ngay tới nó.
• EBS = persistent, độc lập với vòng đời instance. Thấy "must persist beyond the life of the instance" hoặc "not lost if stopped or terminated" là chọn EBS.
• EBS snapshot là backup, không phải nơi ghi dữ liệu. Phương án nào dùng snapshot thay cho volume để lưu state đang hoạt động thì loại; snapshot theo lịch luôn để lọt phần dữ liệu phát sinh sau lần chụp cuối.
• Câu hỏi ghép cặp thì đọc từng vai một. Một phương án chỉ cần sai một vế là loại, dù vế kia đúng hoàn toàn — B và C đều đúng một nửa.
• DynamoDB là database, không phải block storage. Đừng để nó chiếm vai "ổ đĩa làm việc tốc độ cao" của instance store.

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

Một tập đoàn đa quốc gia hoạt động ở nhiều AWS Region, mỗi region có một nhóm nghiên cứu riêng. Toàn bộ dữ liệu độc quyền nằm trong một data warehouse dựng trên Amazon S3. Yêu cầu: mỗi nhóm nghiên cứu chỉ được truy vấn đúng tập dữ liệu thuộc region của mình, giải pháp phải scalable và operational overhead thấp nhất. Chọn HAI hành động.

Cụm từ quyết định nằm ở ba chỗ:

• "each research team can only query datasets pertaining to their specific region" — đây là phân quyền theo thuộc tính của dữ liệu (dataset này thuộc region nào), chứ không phải phân quyền theo vị trí mạng mà request xuất phát. Đọc nhầm chỗ này là rơi ngay vào phương án C và D.
• "query" — người dùng truy vấn dữ liệu, nên lớp kiểm soát nên nằm ở tầng data catalog / quyền truy cập dữ liệu.
• "scalable ... least amount of operational overhead" — loại bỏ mọi cách phải dựng thêm một cấu trúc riêng cho từng region và bảo trì thủ công khi thêm region hay thêm dataset mới.

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

B — AWS Lake Formation với cross-account data sharing và region-based access control. Lake Formation là lớp quản trị quyền tập trung cho data lake trên S3: thay vì viết quyền theo từng prefix S3 rải rác, ta cấp quyền ở mức database/table/column trong catalog, và Lake Formation ép quyền đó xuống các engine truy vấn. Vì mô hình ở đây là nhiều region với nhiều nhóm (thường nằm ở account khác nhau), cross-account data sharing của Lake Formation cho phép chia sẻ đúng phần dữ liệu của một region sang đúng nhóm mà không phải sao chép dữ liệu hay dựng lại hạ tầng cho từng nhóm. Thêm một region mới chỉ là thêm quyền trong Lake Formation — đúng tinh thần "minimal operational overhead".

E — Tag-based access control: gắn tag region cho từng dataset và cho IAM role đọc theo tag. Đây là kiểu phân quyền theo thuộc tính: dataset được gắn nhãn region, còn policy của role thì viết một lần theo dạng "được truy cập những gì có tag region khớp với mình". Ưu điểm quyết định là policy không phải sửa lại khi thêm dataset mới — dataset mới chỉ cần được gắn tag đúng là tự động rơi vào đúng nhóm. Đó chính là tính scalable mà đề đòi hỏi, và Lake Formation cũng có mô hình tag-based access control (LF-Tags) đi cùng ý này.

Hai phương án bổ trợ nhau: B lo lớp quản trị và chia sẻ dữ liệu, E lo cơ chế biểu diễn "dataset này thuộc region nào" một cách khai báo.

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

A — Đăng ký từng dataset region vào các external schema riêng của Amazon Redshift Spectrum, rồi hạn chế bằng IAM policy. Đây là phương án gần đúng nhất vì Redshift Spectrum thật sự truy vấn được dữ liệu S3. Chỗ hỏng: nó bắt phải dựng và bảo trì một external schema riêng cho mỗi region, và mỗi lần thêm region hay thêm dataset là thêm việc thủ công — trái hẳn với "least operational overhead" và "scalable". Ngoài ra bản thân việc tách schema không tự sinh ra kiểm soát truy cập; vẫn phải cấu hình thêm quyền ở tầng khác thì mới chặn được, nên nó là công phức tạp hơn chứ không phải giải pháp gọn hơn.

C — S3 bucket policy cấp quyền có điều kiện dựa trên region xuất phát của request. Đây là bẫy đọc nhầm: đề nói về region của dữ liệu, còn phương án này lọc theo region của nơi gọi request. Hai thứ khác nhau hoàn toàn — một nhà nghiên cứu hoàn toàn có thể gọi từ bất kỳ đâu, và ngược lại nhiều nhóm có thể cùng gọi từ một nơi. Bucket policy hợp với việc cấp quyền ở mức rộng cho cả bucket, không phải công cụ để phân quyền tinh theo từng dataset ở quy mô nhiều nhóm.

D — Tạo S3 endpoint riêng cho từng region qua Amazon VPC rồi gắn với IAM role của từng nhóm. Sai ở tầng khái niệm: VPC endpoint là chuyện định tuyến mạng, không phải chuyện quyền truy cập dữ liệu. Nó có thể giới hạn đường đi tới S3 nhưng không diễn đạt được "nhóm này chỉ đọc dataset của region này". Kèm theo là phải dựng và bảo trì hạ tầng mạng cho từng region — thêm việc, thêm chỗ hỏng, và không mở rộng được khi số nhóm hay số dataset tăng.

📌 Điểm cần nhớ

• Phân biệt cho được region của dữ liệu với region/vị trí mạng của người gọi. Đề nói "datasets pertaining to their region" là vế đầu; phương án nói "originating region of the request" hay VPC endpoint là vế sau.
• Câu nào có cụm "least operational overhead" + "scalable" thì loại ngay những phương án phải dựng một cấu trúc riêng cho mỗi nhóm/mỗi region (schema riêng, endpoint riêng).
• Với data lake trên S3 cần phân quyền tinh cho nhiều nhóm, AWS Lake Formation là lớp quản trị mặc định — cấp quyền ở mức catalog và chia sẻ được cross-account mà không phải nhân bản dữ liệu.
• Tag-based access control thắng ở chỗ policy viết một lần và tự áp cho dữ liệu mới chỉ nhờ gắn tag; đó là lý do nó luôn là ứng viên mạnh khi đề nhấn mạnh khả năng mở rộng.
• Kiểm soát mạng (VPC endpoint) không thay thế được kiểm soát truy cập (IAM/Lake Formation) — đừng để chúng lẫn vào nhau khi chọn đáp án.

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

Đề mô tả một web application chạy trên Amazon EC2, dùng Amazon DynamoDB kèm DynamoDB Accelerator (DAX) làm lớp cache. Người quản trị mạng phải cấu hình security group của EC2 instance sao cho ứng dụng nói chuyện được với cả hai.

Cụm từ quyết định nằm ở hai chỗ:

• "security group for the EC2 instance" — câu hỏi không hỏi ứng dụng dùng giao thức gì nói chung, mà hỏi cổng nào cần mở trong security group. Đây là câu hỏi về đường đi mạng bên trong VPC, không phải về HTTPS ngoài Internet.
• "DynamoDB along with DAX" — hai thành phần có bản chất mạng khác hẳn nhau. DynamoDB là dịch vụ AWS quản lý, truy cập qua endpoint công khai của AWS. DAX thì ngược lại: nó là một cluster gồm các node chạy trong chính VPC của bạn, có ENI riêng, và vì thế có security group riêng chi phối lưu lượng vào nó.

Sự khác biệt đó chính là cái đề đang thử: chỉ có một trong hai thành phần thật sự cần khai báo cổng.

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

C — mở port 8111 cho DAX, giữ nguyên cấu hình mặc định cho DynamoDB.

DAX cluster lắng nghe trên port 8111 cho lưu lượng từ DAX client (cổng dành cho kết nối không mã hoá; cluster bật encryption in transit dùng một cổng khác). Vì DAX node nằm trong VPC, ứng dụng trên EC2 kết nối tới nó như tới bất kỳ tài nguyên nội bộ nào — nghĩa là rule của security group thật sự có hiệu lực và phải cho phép cổng đó, nếu không kết nối bị chặn ngay ở tầng mạng.

Vế thứ hai của đáp án cũng quan trọng: DynamoDB không cần mở thêm gì cả. Security group là stateful và mặc định cho phép toàn bộ outbound traffic; lời gọi API tới DynamoDB là kết nối đi ra từ EC2 tới endpoint của AWS, phản hồi được tự động cho quay về. Không có kết nối nào từ bên ngoài chủ động đi vào EC2 vì DynamoDB, nên không có inbound rule nào phải thêm.

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

A — mở port 22 cho SSH. Port 22 là SSH: đăng nhập vào máy, copy file, port forwarding. Nó phục vụ người quản trị, hoàn toàn không liên quan tới đường dữ liệu giữa ứng dụng và DynamoDB/DAX. Mở nó chẳng giúp ứng dụng chạy, mà còn mở rộng bề mặt tấn công vô ích.

B — mở port 443 cho HTTPS. Đây là phương án gần đúng nhất và cũng là cái bẫy chính. Đúng là lời gọi API tới DynamoDB đi bằng HTTPS trên port 443 — nên thoạt nhìn có vẻ hợp lý. Chỗ hỏng nằm ở chiều lưu lượng: đó là traffic đi ra, mà outbound mặc định đã được cho phép và security group lại stateful, nên không cần khai thêm rule nào. Còn với DAX thì con số cũng sai — DAX không phục vụ trên 443 mà trên cổng riêng của nó. Phương án này chọn đúng giao thức nhưng sai cả về chiều lẫn về thành phần thật sự cần cấu hình.

D — mở port 80 cho HTTP. Sai nặng hơn B. Không có thành phần nào trong đề dùng HTTP thuần: giao tiếp với DynamoDB được mã hoá, còn DAX dùng giao thức riêng chứ không phải HTTP trên port 80. Ngoài ra vẫn dính đúng lỗi của B: đây là hướng đi ra, không cần inbound rule.

📌 Điểm cần nhớ

• DAX nằm trong VPC, DynamoDB thì không. Đây là ranh giới quyết định trong mọi câu hỏi kiểu này: dịch vụ có ENI trong VPC thì security group mới thực sự chi phối; dịch vụ truy cập qua endpoint AWS thì không cần rule riêng.
• Port 8111 là cổng đặc trưng của DAX (kết nối không mã hoá); thấy DAX trong đề mà phương án nhắc tới cổng này thì gần như chắc chắn đó là hướng đúng.
• Security group là stateful và mở sẵn outbound. Lưu lượng ứng dụng chủ động gọi ra ngoài — kể cả HTTPS 443 tới API của AWS — không đòi thêm rule. Đáp án nào bảo "mở 443 để gọi dịch vụ AWS" thường là bẫy.
• Đọc kỹ đề hỏi cổng nào cần mở, chứ không phải giao thức nào đang được dùng. Hai câu hỏi này cho ra hai đáp án khác nhau.

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

Một data engineer ở công ty phân tích tài chính cần làm giàu (enrich) data lake trên Amazon S3 bằng dữ liệu từ bên thứ ba: dữ liệu thị trường chứng khoán và các chỉ số kinh tế do các nhà cung cấp dữ liệu (data providers) phát hành. Yêu cầu là cập nhật định kỳ và đưa vào S3 để xử lý tiếp.

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

• "external financial datasets ... from various data providers" — nguồn dữ liệu không phải hệ thống nội bộ, cũng không phải SaaS app mà công ty đang dùng, mà là bộ dữ liệu thương mại do bên thứ ba bán/phát hành.
• "with minimal effort" — đây là ràng buộc phân biệt. Cả bốn phương án đều có thể đưa được dữ liệu vào S3 theo cách nào đó; câu hỏi không hỏi "cách nào chạy được" mà hỏi cách nào ít công sức vận hành và phát triển nhất.

Ghép hai cụm lại: cần một dịch vụ vốn sinh ra để đăng ký (subscribe) dữ liệu bên thứ ba và tự đẩy vào S3, chứ không phải một dịch vụ dùng chung mà ta phải tự viết logic tích hợp.

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

Đáp án C — AWS Data Exchange.

AWS Data Exchange là nơi để tìm, đăng ký và sử dụng dữ liệu của nhà cung cấp bên thứ ba ngay trong AWS. Nó đúng khớp với ngữ cảnh đề bài: dữ liệu thị trường chứng khoán và chỉ số kinh tế là loại dữ liệu thương mại được các provider phát hành sẵn trên nền tảng này.

Sau khi đăng ký một dataset, người dùng có thể cho AWS Data Exchange xuất/nhập dữ liệu thẳng vào bucket S3, và các bản phát hành mới (revision) của provider được đưa về data lake mà gần như không cần thao tác tay. Kết quả: không phải viết code gọi API, không phải xử lý phân trang, xác thực, retry, phát hiện dữ liệu mới hay bắt lỗi — phần "đường ống" đã nằm trong dịch vụ. Đó chính là nghĩa của "minimal effort" trong đề.

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

A. AWS Lambda chạy định kỳ, gọi API của bên thứ ba rồi upload lên S3. Đây là phương án chạy được nhưng sai tiêu chí, và là bẫy gần đúng nhất. Về mặt kỹ thuật hoàn toàn khả thi, nhưng đội kỹ thuật phải tự viết và tự nuôi toàn bộ phần tích hợp: xác thực với từng provider, phân tích định dạng phản hồi, xử lý lỗi và thử lại, theo dõi xem dữ liệu đã cập nhật hay chưa, rồi bảo trì khi provider đổi API. Mỗi provider mới là thêm một khối code nữa. Đó là custom-coded solution, ngược hẳn với "minimal effort".

B. AWS Glue crawler để trích xuất dữ liệu từ nguồn ngoài rồi nạp vào data lake. Sai vì hiểu nhầm chức năng của crawler. Glue crawler quét dữ liệu đã tồn tại và điền metadata (schema, partition) vào AWS Glue Data Catalog. Nó là công cụ khám phá lược đồ, không phải công cụ ingestion: nó không đi lấy dữ liệu mới từ nhà cung cấp bên ngoài về. Sau khi dữ liệu đã nằm trong S3 thì crawler mới có việc để làm — tức là nó thuộc bước sau, không giải quyết được yêu cầu của đề.

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

D. Amazon AppFlow tạo flow giữa các data provider và S3. Đây là phương án gần đúng thứ hai, và cần nói rõ nó hỏng ở đâu. AppFlow chuyên trao đổi dữ liệu giữa các dịch vụ AWS và các ứng dụng SaaS (kiểu CRM, ticketing, marketing) thông qua các connector có sẵn cho từng ứng dụng. Nhà cung cấp dữ liệu tài chính trong đề không phải là SaaS application mà công ty đang vận hành — họ là bên phát hành dataset. AppFlow không được thiết kế để mua/đăng ký dữ liệu từ một marketplace, nên với tình huống này nó vừa không đúng mô hình, vừa đòi hỏi cấu hình và tuỳ biến nhiều hơn AWS Data Exchange.

📌 Điểm cần nhớ

• Dữ liệu của bên thứ ba, cần đăng ký/mua → AWS Data Exchange. Đây là từ khoá gần như một-đối-một trong đề thi: hễ thấy "third-party data", "data providers", "external datasets" thì nghĩ ngay tới dịch vụ này.
• "Minimal effort" / "least operational overhead" là ràng buộc chọn đáp án, không phải câu tô điểm. Khi nhiều phương án đều chạy được, chọn cái mà AWS đã làm sẵn phần tích hợp, loại cái buộc ta tự viết code (Lambda tự gọi API).
• Glue crawler = khám phá schema và điền Data Catalog, không phải ingestion. Nó không kéo dữ liệu mới từ nguồn ngoài về; nhầm chỗ này là bẫy lặp lại nhiều lần ở Domain 1.
• AppFlow = AWS ↔ SaaS applications. Đúng khi nguồn là một ứng dụng SaaS mà công ty đang dùng; sai khi nguồn là một dataset thương mại trên marketplace.

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

Đề mô tả một mô hình kho dữ liệu rất quen thuộc trên Amazon Redshift: một bảng sales lớn, hàng triệu dòng (fact table) và một bảng products nhỏ hơn (dimension table). Truy vấn thường xuyên join hai bảng này với nhau, và câu hỏi là chọn distribution style nào cho từng bảng.

Cụm từ quyết định đáp án nằm ở chỗ đối lập kích thước: "a large sales table with millions of rows" và "a smaller products table". Đây không phải hai bảng ngang cỡ nhau — đó chính là thứ loại bỏ các phương án đối xứng. Cụm thứ hai là "Queries often join these two tables": mục tiêu tối ưu là giảm việc di chuyển dữ liệu giữa các node khi join, chứ không phải tối ưu quét toàn bảng hay tối ưu ghi.

Ba distribution style xuất hiện trong các phương án cần phân biệt rõ:

• KEY — chia dòng theo giá trị băm của một cột; các dòng cùng giá trị nằm chung node.
• EVEN — rải dòng đều vòng tròn, không quan tâm nội dung.
• ALL — nhân bản toàn bộ bảng lên mọi node.
• AUTO — để Redshift tự chọn kiểu phân phối dựa trên kích thước bảng và cách bảng được truy vấn, và tự đổi khi bảng lớn dần.

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

Đáp án đúng theo tệp là B: sales dùng AUTO, products dùng ALL.

Với bảng nhỏ products, ALL distribution đặt một bản sao đầy đủ của bảng trên mỗi node của cluster. Khi join, mỗi node đã có sẵn toàn bộ dimension ở local nên không cần redistribute dữ liệu qua mạng — đúng thứ tốn kém nhất trong một phép join phân tán. Vì bảng nhỏ, cái giá phải trả (tốn thêm dung lượng lưu trữ vì nhân bản, tốn thêm công khi ghi/cập nhật) là chấp nhận được.

Với bảng lớn sales, AUTO để Redshift tự quyết định kiểu phân phối phù hợp theo kích thước thực tế và mẫu truy vấn, thay vì bắt người vận hành chọn cứng một kiểu ngay từ đầu. Đây là lựa chọn an toàn cho một fact table đang lớn dần: Redshift theo dõi bảng và điều chỉnh, còn phần join thì đã được bản sao ALL của products lo rồi.

Nói ngắn gọn: giải quyết bài toán join bằng phía bảng nhỏ, và để phía bảng lớn cho Redshift tự lo.

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

A. KEY cho cả sales lẫn products theo cột join. Đây là phương án gần đúng nhất và đáng phân tích kỹ. Về nguyên lý, co-location theo KEY đúng là cách kinh điển để join không phải redistribute. Nhưng nó chỉ phát huy khi hai bảng có kích thước tương đối cân nhau và cột join có giá trị phân bố đều. Ở đây products nhỏ: băm nó theo cột join sẽ dồn dữ liệu về một số node theo giá trị khoá, dễ gây lệch dữ liệu (skew) — một số slice ôm nhiều dòng, số khác gần như trống, khiến node bị lệch thành nút thắt cổ chai. Chọn KEY còn buộc phải chọn đúng cột và khoá cứng thiết kế đó cho một mẫu join; khi bảng được join theo cột khác thì lợi ích biến mất. Với cặp fact lớn – dimension nhỏ, ALL cho phía nhỏ đơn giản và bền hơn.

C. sales EVEN, products KEY. Sai ở cả hai vế. EVEN rải đều sales nhưng không quan tâm cột join, nên khi join Redshift vẫn phải chuyển dữ liệu qua mạng — đúng thứ đề bài muốn tránh. Còn KEY trên products chỉ tối ưu nếu bảng nhỏ này thường xuyên join trên đúng cột đó và giá trị phân bố đều; với một dimension nhỏ thì ALL gần như luôn hiệu quả hơn vì loại bỏ hẳn nhu cầu redistribute.

D. sales ALL, products EVEN. Đây là phương án đảo ngược đúng nguyên tắc — và là bẫy dành cho người nhớ "ALL tốt cho join" mà không nhớ nó tốt cho bảng nào. Nhân bản một bảng hàng triệu dòng lên mọi node làm dung lượng lưu trữ phình lên theo số node, kéo theo chi phí ghi và bảo trì rất lớn; ALL chỉ dành cho bảng nhỏ. Đồng thời EVEN cho products không mang lại lợi ích join nào, nên phương án này vừa tốn kém vừa không giải quyết được vấn đề.

📌 Điểm cần nhớ

• ALL distribution dành cho bảng nhỏ (dimension), không bao giờ cho fact table lớn — nó nhân bản toàn bộ bảng lên mọi node, nên chi phí tăng theo kích thước bảng và số node.
• Mẫu fact lớn + dimension nhỏ, join thường xuyên → cách xử lý kinh điển là ALL cho bảng nhỏ, còn bảng lớn dùng AUTO (hoặc EVEN/KEY tuỳ mẫu truy vấn).
• KEY hợp khi hai bảng lớn tương đương nhau và join trên một cột phân bố đều; chọn sai cột thì vừa không hết redistribute vừa sinh data skew.
• EVEN không biết gì về cột join, nên tự nó không cải thiện hiệu năng join — chỉ đảm bảo dữ liệu trải đều.
• Khi đề nhấn mạnh chênh lệch kích thước giữa hai bảng, đó chính là ràng buộc phân biệt các phương án đối xứng: đọc kỹ bảng nào lớn, bảng nào nhỏ trước khi chọn.

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

Đề bài đặt ra một công ty muốn giảm chi phí lưu trữ khối lượng dữ liệu lớn trên Amazon S3, nhưng kèm hai ràng buộc rất chặt:

1. "access patterns are unpredictable" — không đoán trước được dữ liệu nào sẽ bị đọc, đọc lúc nào, đọc bao nhiêu lần.
2. "require millisecond retrieval times for all data" — thời gian lấy dữ liệu phải ở mức mili-giây, và là cho toàn bộ dữ liệu, không có ngoại lệ.

Cụm quyết định là cặp "unpredictable" + "millisecond retrieval for all data". Cụm thứ nhất loại bỏ mọi cách tiếp cận phải tự đặt luật (lifecycle policy, chuyển hàng loạt sang một lớp lưu trữ cố định) — vì muốn đặt luật thì phải biết trước dữ liệu nguội đi theo quy tắc nào. Cụm thứ hai loại bỏ mọi lớp lưu trữ mang tính lưu trữ dài hạn/archive, nơi việc lấy dữ liệu cần thao tác khôi phục mất từ vài phút tới nhiều giờ.

Chỉ còn đúng một phương án thoả cả hai vế cùng lúc.

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

A — Implement S3 Intelligent-Tiering for automatic cost optimization.

S3 Intelligent-Tiering được thiết kế đúng cho tình huống không biết trước hoặc không đoán được mẫu truy cập. Thay vì bắt người vận hành phải khai báo "sau N ngày thì chuyển sang lớp rẻ hơn", S3 tự theo dõi việc truy cập từng object và tự dịch chuyển nó giữa các access tier sao cho tối ưu chi phí. Object nguội đi thì tự rơi xuống tier rẻ hơn; khi bị truy cập trở lại, nó tự quay lên tier nóng — không cần người can thiệp và không cần đoán đúng.

Quan trọng với đề này: việc dịch chuyển giữa các tier truy cập thường xuyên/không thường xuyên không làm mất tính chất truy xuất tức thời — dữ liệu vẫn đọc được ở mức mili-giây như S3 Standard. Đây chính là điểm mà các phương án còn lại đều thua: chúng hoặc đánh đổi thời gian truy xuất lấy giá rẻ, hoặc đánh đổi độ bền/tính sẵn sàng.

Nói gọn: A cho tiết kiệm chi phí tự động mà không hy sinh yêu cầu mili-giây, và không đòi hỏi phải biết trước access pattern — trùng khít cả ba yêu cầu của đề.

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

B — Move all data to S3 Glacier for long-term storage. S3 Glacier phục vụ dữ liệu lưu trữ dài hạn, nơi việc lấy dữ liệu đi qua một thao tác khôi phục và có độ trễ đáng kể — thường tính bằng phút tới giờ tuỳ chế độ khôi phục. Đề nói thẳng "millisecond retrieval times for all data", nên riêng vế thời gian đã loại phương án này. Ngoài ra "move all data" cũng mâu thuẫn với chính chữ "unpredictable": chuyển tất cả sang lớp archive là giả định trước rằng chẳng cái gì cần đọc gấp.

C — Transition to S3 One Zone-Infrequent Access for all data. Đây là phương án gần đúng nhất, và cần nói rõ nó hỏng ở đâu. One Zone-IA có trả dữ liệu ở mức mili-giây, nên nó vượt qua được vế thời gian truy xuất — khác hẳn B và D. Nó hỏng ở hai chỗ khác:

• Tên lớp đã nói rõ: nó dành cho dữ liệu infrequent access. Chuyển toàn bộ dữ liệu sang đây khi mẫu truy cập là "unpredictable" nghĩa là đặt cược rằng dữ liệu ít bị đọc. Cược sai thì mỗi lần đọc đều phát sinh phí truy xuất, và chi phí có thể đội lên cao hơn thay vì giảm — đúng thứ đề bài muốn tránh.
• Nó chỉ lưu dữ liệu trong một Availability Zone. Mất AZ đó là mất dữ liệu, không có khả năng chống chịu như các lớp lưu trên nhiều AZ. Đem toàn bộ dữ liệu của công ty đặt vào một AZ là một đánh đổi về độ bền/tính sẵn sàng mà đề không hề cho phép.

D — Create S3 Lifecycle policies to archive data to S3 Glacier Deep Archive. Glacier Deep Archive là lớp rẻ nhất, nhưng đánh đổi bằng thời gian khôi phục dài nhất — ở mức nhiều giờ, không phải mili-giây. Phương án này còn sai kép: bản thân lifecycle policy buộc phải khai báo luật theo tuổi của object ("sau X ngày thì chuyển"), tức là giả định dữ liệu nguội đi theo thời gian một cách dự đoán được. Đề nói mẫu truy cập là unpredictable, nên một object 300 ngày tuổi vẫn có thể bị đọc bất ngờ — và lúc đó nó đang nằm trong Deep Archive, phải chờ hàng giờ.

📌 Điểm cần nhớ

• Từ khoá "unknown / unpredictable / changing access patterns" trong đề gần như luôn trỏ tới S3 Intelligent-Tiering. Ngược lại, lifecycle policy là câu trả lời khi đề mô tả một quy luật nguội đi rõ ràng theo thời gian.
• "Millisecond retrieval" là bộ lọc cứng: nó loại sạch S3 Glacier và S3 Glacier Deep Archive, bất kể chúng rẻ tới đâu. Đọc yêu cầu về thời gian truy xuất trước khi so giá.
• Đọc kỹ chữ "for all data". Nó biến những phương án dạng "chuyển tất cả sang lớp X" thành một đánh cược vào mẫu truy cập — thứ mà đề vừa nói là không đoán được.
• S3 One Zone-IA vẫn cho truy xuất mili-giây, nên đừng loại nó bằng lý do sai. Nó thua vì hai điểm khác: chỉ một Availability Zone (kém bền vững hơn), và phí truy xuất khiến dữ liệu bị đọc nhiều trở nên đắt hơn thay vì rẻ hơn.

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

Đề đặt bối cảnh một công ty dịch vụ tài chính muốn tối ưu hiệu năng các instance Amazon RDS for MySQL, và các DBA cần thu thập rồi phân tích số liệu để tìm nút thắt cổ chai.

Cụm từ quyết định nằm ngay giữa câu: "operating system-level metrics" — số liệu ở mức hệ điều hành, được minh hoạ tiếp bằng danh sách CPU utilization, read IOPS, write IOPS, và memory pressure. Đây chính là ràng buộc phân biệt, vì cả bốn phương án đều là công cụ quan sát hợp lệ của AWS và ba trong số đó thực sự có liên quan tới RDS. Câu hỏi không hỏi "cách nào theo dõi database", mà hỏi cách nào lấy được số đo từ chính hệ điều hành đang chạy dưới instance RDS.

Chi tiết "memory pressure" đáng chú ý riêng: đó là thứ nhìn thấy được từ bên trong OS (các chỉ số bộ nhớ như free, cached, swap), không phải thứ động cơ cơ sở dữ liệu tự báo cáo ra ngoài.

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

A — Activate Amazon RDS Enhanced Monitoring.

Enhanced Monitoring lấy số liệu từ hệ điều hành mà instance RDS đang chạy trên đó, cung cấp hơn 50 chỉ số về CPU, bộ nhớ, file system và disk I/O theo thời gian thực. Chính vì nó đọc ở tầng OS chứ không đọc qua tầng dịch vụ RDS, nên nó thấy được đúng những gì đề liệt kê: CPU utilization chi tiết, read/write IOPS, và áp lực bộ nhớ.

Điểm mạnh thứ hai là độ mịn: dữ liệu Enhanced Monitoring chi tiết hơn nhóm metric cơ bản mà RDS đẩy ra mặc định, nên khi DBA đi tìm bottleneck — thứ thường chỉ lộ ra trong những khoảng thời gian rất ngắn — đây mới là nguồn dữ liệu đủ dùng.

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

C — Amazon RDS Performance Insights. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Performance Insights đúng là công cụ chuyên để phân tích và gỡ rối hiệu năng RDS, nhưng góc nhìn của nó là database load: nó cho thấy tải của cơ sở dữ liệu, câu lệnh SQL nào tốn nhiều nhất, chờ đợi ở đâu bên trong engine. Nó không cung cấp số liệu ở mức hệ điều hành. Nếu đề hỏi "truy vấn nào đang làm chậm hệ thống" thì C là đáp án; nhưng đề hỏi CPU/IOPS/memory pressure của OS, nên C hỏng đúng ở chỗ khác tầng quan sát.

D — AWS CloudWatch. Phương án gần đúng thứ hai. CloudWatch thực sự giám sát tài nguyên AWS và có metric cho RDS, đặt được alarm khi vượt ngưỡng. Nhưng nó chỉ đưa ra các chỉ số cơ bản nhìn từ bên ngoài instance, không đạt tới mức chi tiết OS-level như Enhanced Monitoring. Nói cách khác, D không sai về loại công cụ, mà sai về độ sâu dữ liệu — vẫn thiếu đúng nhóm chỉ số mà đề đòi.

B — AWS X-Ray. Sai xa nhất. X-Ray là công cụ tracing dành cho việc phân tích và gỡ lỗi ứng dụng phân tán, theo dấu một request đi qua các thành phần microservice. Nó không được thiết kế để đo hiệu năng cơ sở dữ liệu, càng không đọc được chỉ số hệ điều hành của instance RDS. Cách diễn đạt "trace user requests as they travel through the RDS databases" trong phương án cũng mô tả sai vai trò của X-Ray.

📌 Điểm cần nhớ

• Thấy cụm "operating system-level metrics" hoặc các chỉ số OS (memory pressure, file system, disk I/O chi tiết) gắn với RDS → nghĩ ngay tới RDS Enhanced Monitoring.
• Phân biệt ba tầng quan sát của RDS: CloudWatch = metric cơ bản nhìn từ ngoài + alarm; Enhanced Monitoring = tầng hệ điều hành; Performance Insights = tầng database load và truy vấn.
• Nếu đề hỏi "truy vấn nào gây tải, chờ đợi ở đâu trong engine" thì đáp án đảo lại thành Performance Insights — cùng bộ phương án, chỉ khác một cụm từ trong đề.
• AWS X-Ray thuộc nhóm tracing ứng dụng phân tán; nó xuất hiện trong câu hỏi giám sát database gần như luôn là phương án nhiễu.

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

Đề mô tả một ứng dụng web chạy trên nhiều Amazon EC2 instance nằm trong một Auto Scaling group, và hỏi nên dùng dịch vụ lưu trữ nào của AWS.

Cụm từ quyết định đáp án nằm ở câu thứ hai: "a shared file system that can be accessed concurrently by all EC2 instances for reading and writing", cộng thêm ràng buộc "must also support high availability and scalability".

Bóc ra thành bốn yêu cầu tách bạch để đối chiếu với từng phương án:

1. Phải là file system — tức là truy cập theo kiểu thư mục/tệp, không phải block, không phải object.
2. Nhiều instance dùng chung cùng lúc, cả đọc lẫn ghi.
3. Bền vững và sẵn sàng cao — dữ liệu không được biến mất khi một instance chết.
4. Co giãn được, vì Auto Scaling group nghĩa là số instance thay đổi liên tục, không cố định.

Yêu cầu số 2 kết hợp với Auto Scaling group là chỗ phân biệt mạnh nhất: instance có thể được tạo mới hoặc bị chấm dứt bất cứ lúc nào, nên kho lưu trữ phải tồn tại độc lập với vòng đời của instance và phải cho phép instance vừa mới sinh ra gắn vào đúng dữ liệu mà những instance khác đang dùng.

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

Đáp án đúng theo tệp là C — Amazon Elastic File System (EFS).

EFS là dịch vụ file system NFS được AWS quản lý hoàn toàn. Nó khớp đủ bốn yêu cầu ở trên:

• Nó cho ngữ nghĩa file system thật (đường dẫn, thư mục, khoá tệp), nên ứng dụng web chỉ cần mount rồi đọc ghi như với đĩa cục bộ, không phải sửa mã.
• Nhiều EC2 instance mount cùng một file system và đọc ghi đồng thời, điều này chính là mục đích thiết kế của EFS — đây là điểm mà bản giải thích tiếng Anh nhấn mạnh: nó bảo đảm tính nhất quán và sẵn sàng của dữ liệu khi mọi instance cùng thao tác.
• Nó là dịch vụ elastic: dung lượng tự lớn lên hoặc nhỏ đi theo lượng dữ liệu, người dùng không phải cấp phát trước — hợp với môi trường số instance biến động.
• Nó được thiết kế theo hướng highly available, tồn tại độc lập với instance nào cả, nên instance mới do Auto Scaling group tạo ra chỉ việc mount vào là thấy ngay dữ liệu chung.

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

A — Amazon EBS with shared volumes. Đây là phương án gần đúng nhất và cũng là bẫy chính. EBS là lưu trữ block-level, gắn vào EC2 instance như một ổ đĩa. Hai chỗ hỏng: thứ nhất, EBS về bản chất là ổ dành cho một instance, không phải kho dùng chung cho cả nhóm instance thay đổi liên tục. Thứ hai — và quan trọng hơn — kể cả khi một volume được nhiều instance nhìn thấy, nó vẫn chỉ đưa ra các khối dữ liệu thô, không phải file system dùng chung; muốn nhiều máy cùng ghi an toàn thì phải tự dựng thêm một cluster file system bên trên. Đề yêu cầu "a shared file system", tức là muốn thứ dùng được ngay, không phải một tầng mà mình phải tự xây.

B — EC2 instance store volumes. Hỏng ở hai yêu cầu cùng lúc. Instance store là lưu trữ tạm, gắn cứng với vòng đời của instance — instance bị chấm dứt là dữ liệu mất, mà chấm dứt instance chính là việc Auto Scaling group làm hằng ngày. Ngoài ra nó là ổ cục bộ của từng instance, không có cách nào để các instance khác đọc ghi vào đó, nên yêu cầu "shared" trượt hoàn toàn. Chính phương án tự khai "temporary" — đó là dấu hiệu loại ngay khi đề đòi high availability.

D — Amazon S3. Phương án này thoả scalability và high availability, nên rất dễ bị chọn nhầm. Nó hỏng ở yêu cầu số 1: S3 là object storage, không phải file system. Ứng dụng thao tác qua API đối tượng chứ không qua đường dẫn tệp, và nó không cung cấp ngữ nghĩa file system như file locking hay ghi đè một phần tệp — đúng điểm mà bản giải thích gốc nêu ra. Đề nói rõ "shared file system" với "reading and writing" đồng thời, nên S3 không đáp ứng dù nó bền và co giãn tốt.

📌 Điểm cần nhớ

• Thấy cụm "shared file system" + nhiều EC2 instance đọc ghi đồng thời trong đề thì gần như luôn là EFS. Đây là cặp từ khoá nên nhớ thuộc lòng.
• Phân biệt ba kiểu lưu trữ theo giao diện truy cập, đừng chỉ so độ bền: EBS/instance store = block, EFS = file, S3 = object. Đề hỏi "file system" thì loại luôn hai kiểu kia bất kể chúng bền và rẻ đến đâu.
• Auto Scaling group trong đề là tín hiệu ngầm rằng dữ liệu phải sống lâu hơn instance. Bất cứ phương án nào gắn với vòng đời instance (instance store) đều bị loại ngay.
• Chữ "temporary" hay "ephemeral" trong một phương án là dấu hiệu loại trừ khi đề nhắc tới high availability hoặc persistent.