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

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

Đề mô tả một công ty IoT chuyển hạ tầng lên AWS và liệt kê một chuỗi yêu cầu rất cụ thể cho lớp lưu trữ dữ liệu. Bốn cụm từ quyết định đáp án, và phải thoả đồng thời:

• "fully managed NoSQL persistent data store" — phải là NoSQL, phải bền vững (persistent), và phải là dịch vụ được quản lý hoàn toàn.
• "with in-memory caching" — bản thân dịch vụ đó phải có sẵn lớp cache in-memory đi kèm, chứ không phải mình tự ghép thêm một dịch vụ khác vào.
• "low latency which is critical for real-time data processing" — độ trễ thấp là ràng buộc bắt buộc, không phải mong muốn.
• "well versed with the access patterns" và "concurrent users to touch up to a million... scale elastically" — biết trước mẫu truy cập là dấu hiệu kinh điển của thiết kế key-value; kèm theo là yêu cầu mở rộng đàn hồi ở quy mô rất lớn.

Cụm quyết định nhất là "NoSQL persistent... with in-memory caching" — nó ghép hai yêu cầu vào một dịch vụ duy nhất, và chính chỗ ghép này loại được các phương án chỉ thoả một nửa.

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

Đáp án đúng: B — DynamoDB.

DynamoDB là cơ sở dữ liệu key-value và document được quản lý hoàn toàn, cho hiệu năng độ trễ mức mili-giây đơn ở mọi quy mô. Nó khớp từng vế của đề:

• NoSQL persistent: đúng kiểu dữ liệu key-value/document, dữ liệu lưu bền vững chứ không phải cache tạm.
• Fully managed: không phải quản lý máy chủ, có sẵn bảo mật tích hợp, backup và restore.
• In-memory caching: đây là điểm mấu chốt. DynamoDB có DAX (DynamoDB Accelerator) — lớp cache in-memory tương thích trực tiếp với DynamoDB, dùng khi cần khối lượng đọc lớn hoặc độ trễ đọc dưới mili-giây. Nghĩa là yêu cầu "NoSQL bền vững + cache in-memory" được đáp ứng trong cùng một hệ, không cần lắp ghép.
• Scale elastically tới cả triệu người dùng đồng thời: DynamoDB được thiết kế cho quy mô internet-scale.

Việc đội kỹ thuật đã nắm rõ access patterns cũng ủng hộ DynamoDB: mô hình key-value đòi hỏi thiết kế khoá và truy vấn từ trước, và khi biết trước mẫu truy cập thì đó lại là thế mạnh chứ không phải hạn chế.

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

A — RDS. RDS là dịch vụ cơ sở dữ liệu quan hệ được quản lý, giúp dựng, vận hành và mở rộng database quan hệ trên cloud, tự động hoá các việc như cấp phát phần cứng, cài đặt, vá lỗi, sao lưu. Nó trượt ngay ở yêu cầu đầu tiên: không phải NoSQL. Ngoài ra mô hình mở rộng của database quan hệ cũng không phải hướng đàn hồi tự nhiên cho mức cả triệu người dùng đồng thời như đề mô tả.

C — DocumentDB. Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. DocumentDB đúng là NoSQL (document database, hỗ trợ workload MongoDB), đúng là fully managed, có tính sẵn sàng cao và lưu trữ, truy vấn, đánh chỉ mục dữ liệu JSON dễ dàng. Nó thoả gần hết đề — nhưng không có lớp in-memory caching đi kèm. Chính vế "with in-memory caching" trong đề là thứ tách DocumentDB khỏi DynamoDB. Nếu bỏ cụm đó ra khỏi đề, DocumentDB sẽ trở thành một ứng viên hợp lý.

D — ElastiCache. Ngược lại với DocumentDB: nó thoả vế cache nhưng trượt vế database. ElastiCache cho phép dựng các in-memory data store mã nguồn mở phổ biến (Redis, Memcached) trên cloud, dùng để tăng tốc ứng dụng hoặc bù cho database phía sau bằng độ trễ thấp và thông lượng cao. Nhưng nó đóng vai trò lớp cache, không phải một NoSQL database được quản lý hoàn toàn để làm nơi lưu trữ chính. Đề yêu cầu "persistent data store" — chọn ElastiCache là chọn lớp đệm mà không có kho dữ liệu bền vững phía sau.

📌 Điểm cần nhớ

• Khi đề yêu cầu NoSQL fully managed + in-memory caching trong cùng một giải pháp, đó là mô tả DynamoDB kèm DAX. DAX là lớp cache tương thích trực tiếp với DynamoDB, dành cho khối lượng đọc lớn hoặc yêu cầu độ trễ đọc dưới mili-giây.
• Phân biệt vai trò: ElastiCache là lớp cache, không phải data store bền vững chính. Nếu đề nói "persistent data store", ElastiCache đứng một mình là sai.
• DocumentDB và DynamoDB đều là NoSQL fully managed; điểm tách chúng trong dạng câu này thường là lớp cache in-memory tích hợp, hoặc kiểu dữ liệu (document/tương thích MongoDB so với key-value).
• RDS là quan hệ, không phải NoSQL — chỉ cần đề có chữ "NoSQL" là loại được ngay, không cần đọc tiếp các ràng buộc còn lại.
• Cụm "well versed with the access patterns" trong đề AWS thường là tín hiệu nghiêng về thiết kế key-value, vì mô hình đó đòi hỏi biết trước mẫu truy vấn.

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

Đề mô tả một công ty muốn dựng hạ tầng hybrid cloud: một phần chạy trên AWS (ví dụ Amazon S3), một phần vẫn nằm ở on-premises data center. Câu hỏi yêu cầu chọn hai phương án cho đường nối giữa hai nơi.

Ba cụm từ trong đề quyết định hoàn toàn đáp án, và chúng nằm ở đúng thứ tự cần đọc:

• "a dedicated private connection" — đường chính phải là đường riêng, không đi qua Internet. Trong danh sách chỉ có một dịch vụ đáp ứng được: AWS Direct Connect.
• "In case of failures... needs to guarantee uptime" — phải có đường dự phòng, tức là bài toán hai đường chứ không phải chọn một.
• "is willing to use the public internet for an encrypted connection" — câu này chỉ định rõ đường dự phòng đi qua public internet và phải được mã hoá. Đó chính là mô tả của AWS Site-to-Site VPN (IPSec qua Internet).

Chú ý chữ "is willing to": nó có nghĩa là công ty chấp nhận dùng Internet — nhưng chỉ cho tình huống dự phòng. Đây là chỗ phân biệt giữa "VPN làm primary" và "VPN làm backup", hai phương án trông rất giống nhau trong danh sách.

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

Đáp án đúng là B + E: Direct Connect làm primary, Site-to-Site VPN làm backup.

E — AWS Direct Connect connection as a primary connection. Direct Connect thiết lập một kết nối mạng chuyên dụng giữa mạng của bạn và một Direct Connect location. Nó không đi qua Internet mà dùng đường mạng riêng giữa intranet của công ty và Amazon VPC; kết nối này có thể chia thành nhiều virtual interface bằng VLAN chuẩn 802.1q. Đúng với yêu cầu "dedicated private connection", và vì đường riêng nên hiệu năng lẫn độ ổn định đều tốt hơn Internet — hợp vai trò đường chính.

B — AWS Site-to-Site VPN as a backup connection. Site-to-Site VPN nối on-premises network vào Amazon VPC bằng IPSec, chạy trên public internet. Nó dựng được trong vài phút, hợp với nhu cầu băng thông vừa phải và chấp nhận được sự dao động vốn có của đường Internet. Đúng khớp với câu "willing to use the public internet for an encrypted connection" — mã hoá có, nhưng đường truyền công cộng nên chỉ dùng khi đường chính hỏng.

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

A — Use AWS Site-to-Site VPN as a primary connection. Đây là phương án gần đúng nhất và cũng là bẫy chính. VPN đúng là kết nối được on-premises với VPC và có mã hoá, nhưng đề nói rõ Internet chỉ dành cho failover. Đặt VPN làm đường chính là mâu thuẫn trực tiếp với yêu cầu "dedicated private connection" cho đường chính — VPN đi trên đường công cộng, không phải đường riêng.

D — Use AWS Direct Connect connection as a backup connection. Cũng gần đúng, và về mặt kỹ thuật thì chạy được. Hỏng ở hai chỗ: thứ nhất, nếu Direct Connect là backup thì primary buộc phải là VPN — quay lại đúng lỗi của phương án A. Thứ hai, Direct Connect là kết nối vật lý, tốn kém và mất thời gian thiết lập; bỏ công dựng nó rồi để nằm không làm dự phòng là ngược với logic thiết kế. Direct Connect được đặt ở vai trò đường chính mới đáng đồng tiền.

C — Use Internet Gateway as a backup connection. Sai về bản chất chứ không phải sai về vai trò. Internet Gateway là một thành phần của VPC, có tính sẵn sàng cao và co giãn ngang, giúp các EC2 instance bên trong VPC đi ra Internet. Nó không phải là cơ chế nối on-premises data center vào AWS, và cũng không cung cấp đường hầm mã hoá giữa hai mạng. Chọn nó là nhầm giữa "cho tài nguyên trong VPC ra Internet" và "nối hai mạng lại với nhau".

📌 Điểm cần nhớ

• "Dedicated private connection" = Direct Connect. Cụm từ này gần như là chữ ký nhận dạng của Direct Connect trong đề thi AWS; thấy nó là loại ngay VPN khỏi vai trò đường chính.
• "Encrypted connection over the public internet" giữa on-prem và VPC = Site-to-Site VPN. IPSec qua Internet, dựng nhanh, phù hợp làm dự phòng.
• Mẫu kiến trúc chuẩn cho hybrid có yêu cầu uptime: Direct Connect làm primary, Site-to-Site VPN làm backup. Ghép ngược lại vẫn "chạy" nhưng sai về ý đồ thiết kế lẫn chi phí.
• Internet Gateway không nối được on-premises với AWS. Nó chỉ mở đường ra Internet cho tài nguyên bên trong VPC — mỗi khi thấy nó xuất hiện trong câu hỏi về hybrid connectivity thì đó là phương án gây nhiễu.

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

Đề mô tả một ứng dụng chạy trên Amazon RDS for MySQL đang bị chậm, và bước khảo sát ban đầu đã xác nhận CPU utilization trên RDS instance ở mức cao. Câu hỏi là: với vai trò data engineer, bạn troubleshoot vấn đề này thế nào.

Có hai cụm từ quyết định đáp án:

• "high CPU utilization" — nút thắt nằm ở CPU, không phải ở I/O, không phải ở throughput ghi. Mọi phương án đi chữa một loại nghẽn khác đều lạc đề.
• "how will you troubleshoot" — đề hỏi cách tìm ra nguyên nhân, chứ không hỏi cách nâng cấu hình. Một hành động thay đổi hạ tầng mà không chỉ ra được câu truy vấn nào đang ngốn CPU thì không phải là troubleshooting.

Ghép hai ràng buộc lại: cần một công cụ quan sát tải database và quy tải đó về từng câu SQL cụ thể.

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

Đáp án đúng là A — dùng Performance Insights của RDS để tìm ra các query gây tốn CPU, rồi tối ưu chúng.

Performance Insights là tính năng theo dõi và tinh chỉnh hiệu năng database ngay trong RDS. Nó dựng một dashboard trực quan hoá database load, giúp cả người không phải chuyên gia database cũng thấy được tải đang đến từ đâu, vào lúc nào — và quan trọng nhất với câu này: statement SQL nào đang tạo ra tải đó, vì lý do gì.

Đúng hai điều đề cần:

• Nó đo tải theo nguyên nhân, nên CPU cao sẽ được quy trực tiếp về những câu truy vấn cụ thể — đó chính là bước troubleshoot mà đề hỏi.
• Cơ chế thu thập dữ liệu là lightweight, không làm ảnh hưởng hiệu năng ứng dụng, và không đòi cấu hình hay bảo trì gì thêm. Bật lên là dùng được, không phải trả giá bằng chính hiệu năng đang muốn cứu.

Performance Insights hỗ trợ cả Amazon Aurora (bản tương thích PostgreSQL và MySQL), RDS for PostgreSQL, MySQL, MariaDB, SQL Server và Oracle — nên RDS for MySQL trong đề nằm gọn trong phạm vi hỗ trợ.

Sau khi biết query nào nặng, việc tối ưu chúng mới giải quyết được gốc rễ, thay vì phủ lên bằng phần cứng mạnh hơn.

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

B — dùng RDS Optimized Writes for MySQL. RDS Optimized Writes cải thiện write transaction throughput, có thể đạt tới gấp đôi so với bình thường. Vấn đề: đề không hề nói workload này thiên về ghi. Nó chỉ nói CPU cao. Áp một tính năng chuyên trị nghẽn ghi vào một triệu chứng CPU là chữa sai bệnh — và kể cả nếu có cải thiện, bạn vẫn không biết query nào đang ngốn CPU.

C — chuyển storage từ General Purpose sang Provisioned IOPS. Đây là phương án nghe hợp lý nhất trong nhóm sai, nhưng hỏng ở ba chỗ. Thứ nhất, Provisioned IOPS xử lý nghẽn I/O, trong khi triệu chứng đã được xác nhận là CPU — không mang lại lợi ích gì về CPU usage. Thứ hai, bản thân việc đổi storage type tiêu tốn I/O capacity và có thể làm DB instance chậm đi trong lúc đang chuyển, tức là làm tình hình xấu hơn trước khi (có thể) tốt lên; nếu instance chạy single-AZ thì còn kèm downtime. Thứ ba, và cốt lõi: nó không chỉ ra nguyên nhân gốc, mà đề đang hỏi cách troubleshoot.

D — xem tham số long_query_time để biết top 5 query chạy lâu nhất. Đây là bẫy tinh vi nhất, vì nửa sau của câu ("tối ưu query để giảm CPU") trùng với đáp án đúng. Cái sai nằm ở nửa đầu: long_query_time là ngưỡng do chính bạn đặt, không phải một báo cáo. Nó chỉ định nghĩa "chậm là bao nhiêu giây"; muốn biết query nào vượt ngưỡng đó thì phải đi phân tích MySQL Slow Query Logs. Bản thân việc "check tham số long_query_time" không trả về top 5 query nào cả — mô tả trong phương án sai về mặt cơ chế.

📌 Điểm cần nhớ

• Đọc kỹ loại nghẽn mà đề nêu: CPU, I/O hay write throughput là ba vấn đề khác nhau, và mỗi cái có một nhóm giải pháp riêng. Đề nói CPU thì Provisioned IOPS và Optimized Writes tự động loại.
• Câu hỏi dạng "troubleshoot" ưu tiên công cụ chẩn đoán (quan sát, quy tải về nguyên nhân) hơn hành động thay đổi hạ tầng. Đổi cấu hình khi chưa biết nguyên nhân là đoán mò, không phải troubleshoot.
• Performance Insights là câu trả lời mặc định cho "database load cao, không biết vì sao" trên RDS/Aurora: dashboard trực quan, chỉ đích danh SQL statement gây tải, thu thập nhẹ, không cần cấu hình.
• Phân biệt tham số cấu hình với nguồn dữ liệu chẩn đoán. long_query_time chỉ là ngưỡng bạn tự đặt; dữ liệu thật nằm trong Slow Query Logs. Phương án nào mô tả sai cơ chế của công cụ thì sai, dù kết luận cuối ("tối ưu query") nghe rất đúng.

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

Một công ty giao dịch muốn chuyển cụm Apache Hadoop tại chỗ lên Amazon EMR. Đề đưa ra ba ràng buộc, và mỗi ràng buộc quyết định đúng một trong ba đáp án cần chọn:

• "only operational during normal business hours" và "the cluster is terminated at the end of each business day" — cụm bị xoá hẳn mỗi tối, không phải dừng lại. Mọi thứ nằm trên đĩa của node hoặc trong tiến trình chạy trên node đều biến mất.
• "The data must survive when the cluster is terminated" — dữ liệu phải sống ngoài vòng đời cụm. Cụm từ này loại thẳng mọi hình thức lưu trữ gắn với instance.
• "highly available to prevent intraday cluster failures" — hỏng trong ngày, tức là hỏng thành phần bên trong cụm khi cụm đang chạy, chứ không phải hỏng cả một Availability Zone. Đây là cụm từ tinh tế nhất, vì nó là thứ phân biệt B với C.

Chú ý thêm: Hive metastore cũng là dữ liệu (schema, vị trí bảng, phân vùng). Nếu metastore chết theo cụm thì sáng hôm sau dựng cụm mới sẽ không còn bảng nào để truy vấn, dù file dữ liệu vẫn nguyên vẹn.

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

F — Use EMR File System (EMRFS): EMRFS là bản cài đặt cho phép cụm EMR đọc/ghi thẳng vào Amazon S3 bằng đúng các API kiểu HDFS. Dữ liệu nằm ở S3 nên nó độc lập hoàn toàn với vòng đời cụm: xoá cụm buổi tối, sáng hôm sau dựng cụm mới trỏ vào cùng đường dẫn S3 là có lại toàn bộ dữ liệu. Đây chính là đáp cho ràng buộc "data must survive".

C — Multiple master nodes trong một Availability Zone duy nhất: master node là điểm chết đơn lẻ của cụm EMR (nó chạy YARN ResourceManager, HDFS NameNode, các daemon điều phối). Cụm nhiều master node cho phép khi một master hỏng thì các master còn lại tiếp quản và cụm chạy tiếp không gián đoạn — đúng nghĩa "prevent intraday cluster failures". Việc chúng nằm trong cùng một AZ không phải là khuyết điểm ở đây mà là kiến trúc bắt buộc của EMR, xem phần giải thích cho B bên dưới.

E — AWS Glue Data Catalog làm metastore cho Apache Hive: Glue Data Catalog là dịch vụ quản lý bên ngoài cụm, giữ vị trí, schema và metadata của dữ liệu. Đặt metastore ở đây nghĩa là định nghĩa bảng Hive tồn tại độc lập với cụm; cụm mới sáng hôm sau chỉ cần trỏ vào cùng catalog là dùng lại được ngay các bảng cũ. Ghép với EMRFS thì được bộ đôi trọn vẹn: file ở S3, metadata ở Glue, cụm EMR trở thành tầng tính toán thuần tuý, dựng lên xoá đi tuỳ ý.

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

A — Dùng HDFS làm nơi lưu trữ: HDFS bản thân nó là một hệ thống file phân tán tốt, có nhân bản dữ liệu qua nhiều instance nên chịu được lỗi một node. Nhưng HDFS trên EMR dùng đĩa gắn với các instance của cụm, tức là storage tạm — huỷ cụm là dung lượng đó được thu hồi và dữ liệu mất theo. Nó chống được lỗi node nhưng không chống được chuyện đề nói: cụm bị terminate mỗi tối. Đây là phương án gần đúng nhất trong nhóm sai, và nó hỏng đúng ở chữ "survive termination".

D — Cài MySQL trên master node làm metastore cho Hive: MySQL tự quản trên master node đúng là một cách chạy Hive metastore, nhưng nó nằm trong cụm. Master node biến mất khi cụm bị huỷ thì database metastore biến mất cùng, và mọi định nghĩa bảng Hive mất theo. Ngoài ra nó còn mâu thuẫn với chính yêu cầu HA: metastore đặt trên một node cụ thể lại thành điểm chết đơn lẻ mới.

B — Multiple master nodes trải ra nhiều Availability Zone: nghe rất "cloud-native" nên đây là bẫy chính của câu này, nhưng một cụm EMR chỉ nằm trong một Availability Zone duy nhất. Toàn bộ node của cụm được đặt trong cùng một AZ, nên không có cách nào cấu hình master node ở nhiều AZ. Phương án này bất khả thi về mặt kiến trúc chứ không phải chỉ là "không tối ưu" — và đó là lý do C mới là đáp án cho phần high availability.

📌 Điểm cần nhớ

• Cụm EMR nằm gọn trong một AZ. Bất kỳ phương án nào nói "trải EMR qua nhiều Availability Zone" đều sai theo kiến trúc; HA của EMR đạt được bằng nhiều master node trong cùng một AZ.
• Phân biệt hai lớp lỗi mà đề mô tả: hỏng thành phần trong ngày (giải bằng multiple master nodes) khác hẳn mất cả AZ (EMR không giải được, và đề cũng không hỏi).
• Cụm còn sống hay không quyết định chọn storage: HDFS là ephemeral, gắn với vòng đời cụm; EMRFS đẩy dữ liệu xuống S3 nên sống lâu hơn cụm. Thấy chữ "transient cluster", "terminated at the end of the day" thì gần như chắc chắn đáp án là EMRFS/S3.
• Metastore cũng phải "sống sót" như dữ liệu. Metastore chạy trên node của cụm (MySQL trên master node) chết theo cụm; AWS Glue Data Catalog nằm ngoài cụm nên là lựa chọn chuẩn cho mô hình cụm dựng-xoá hằng ngày.
• Mẫu kiến trúc rút ra và dùng lại được: tách compute khỏi storage và khỏi metadata — EMR chỉ là compute, S3 giữ dữ liệu, Glue giữ metadata.

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

Một công ty y tế vừa chuyển sang Amazon Redshift, cluster đặt ở Region eu-west-1 và đã được mã hoá bằng AWS KMS. Nhóm kỹ thuật cần copy snapshot của Redshift sang một Region khác để đáp ứng yêu cầu Disaster Recovery. Câu hỏi: cấu hình nào là đúng?

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

• "encrypted via AWS KMS" — nếu cluster không mã hoá thì chỉ cần bật copy snapshot là xong, không cần grant gì cả. Chính vì có mã hoá KMS nên mới sinh ra khái niệm snapshot copy grant. Điểm cốt lõi: KMS key là tài nguyên gắn với từng Region, key ở eu-west-1 không dùng được ở Region đích, nên snapshot khi hạ cánh ở Region đích phải được mã hoá lại bằng một KMS key của chính Region đích.
• "copy the Redshift snapshots to another Region" — đây là tính năng cross-Region snapshot copy, và nó được bật ở Region nguồn (nơi cluster đang chạy), vì cluster nguồn mới là bên chủ động đẩy snapshot đi.

Ghép hai điều đó lại: grant nằm ở đích, cấu hình copy bật ở nguồn.

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

Đáp án C: Tạo snapshot copy grant ở Region đích cho một KMS key thuộc Region đích, rồi cấu hình cross-Region snapshots ở Region nguồn.

Đây đúng là quy trình AWS mô tả cho việc copy snapshot của cluster mã hoá KMS sang Region khác:

1. Ở Region đích, tạo một snapshot copy grant cho KMS key của Region đích. Grant này cho phép Amazon Redshift dùng key đó để mã hoá bản snapshot sao chép sang.
2. Ở Region nguồn, bật copy snapshot sang Region kia và chọn đúng grant vừa tạo.

Lý do phải làm theo thứ tự này: bạn không thể tái sử dụng KMS key của Region nguồn ở Region đích — KMS key là tài nguyên theo Region. Snapshot ở Region đích buộc phải được mã hoá bằng key nằm ở Region đích, và snapshot copy grant chính là cầu nối uỷ quyền để Redshift dùng key "lạ Region" ấy thay mặt bạn.

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

A — grant ở đích cho key ở đích (đúng), nhưng cấu hình "Redshift cross-Region replication" ở Region nguồn. Đây là phương án gần đúng nhất, nửa đầu hoàn toàn chính xác. Chỗ hỏng nằm ở tên tính năng: Redshift không có thứ gọi là cross-Region replication. Cái Redshift có là cross-Region snapshot copy. Khái niệm cross-Region replication (CRR) thuộc về Amazon S3, không phải Redshift. Đây là loại bẫy đổi tên dịch vụ — đọc lướt rất dễ chọn nhầm vì mọi từ khác đều đúng.

B — grant ở Region nguồn cho key ở Region nguồn, cấu hình cross-Region snapshots ở Region đích. Sai cả hai vế, đúng kiểu "đảo ngược hoàn toàn":

• Grant phải ở đích cho key ở đích, vì bản sao snapshot sẽ nằm ở đó và cần key ở đó để mã hoá. Key nguồn đã mã hoá cluster gốc rồi, không giúp gì cho bản sao.
• Việc bật copy snapshot làm ở nguồn, không phải ở đích. Cluster nguồn là bên phát snapshot đi.

D — tạo IAM role ở Region đích có quyền truy cập KMS key ở Region nguồn, rồi tạo snapshot copy grant ở Region đích cho key của Region nguồn, cấu hình cross-Region snapshots ở Region nguồn. Vế cuối đúng, nhưng vế giữa là điều không làm được: bạn không thể tạo snapshot copy grant ở Region đích trỏ tới một KMS key nằm ở Region nguồn, vì KMS key gắn chặt với Region của nó. Việc thêm một IAM role ở giữa chỉ làm phương án trông có vẻ chặt chẽ hơn — IAM role có thể là global, nhưng nó không "kéo" được KMS key vượt biên giới Region. Đây là distractor nhắm vào người nhớ mang máng rằng "cứ có IAM role là truy cập chéo được".

📌 Điểm cần nhớ

• KMS key là tài nguyên theo Region. Bất kỳ phương án nào nói "dùng KMS key của Region A ở Region B" đều loại được ngay, kể cả khi có thêm IAM role.
• Snapshot copy grant: tạo ở Region ĐÍCH, cho key của Region ĐÍCH; bật copy ở Region NGUỒN rồi chọn grant đó. Nhớ cặp "grant ở đích – cấu hình ở nguồn" là giải được cả họ câu hỏi này.
• Redshift có cross-Region snapshot copy, không có cross-Region replication. Cross-Region replication (CRR) là thuật ngữ của S3 — thấy nó gắn vào Redshift thì đó là bẫy đặt tên.
• Snapshot copy grant chỉ cần thiết khi cluster được mã hoá bằng KMS; đọc đề thấy chữ "encrypted via AWS KMS" là biết ngay grant sẽ xuất hiện trong đáp án.

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

Đề mô tả một công ty muốn lưu trữ (archive) dữ liệu từ on-premises lên AWS, và dữ liệu đó chỉ được truy cập khoảng một tuần trong một năm. Câu hỏi yêu cầu chọn dịch vụ MOST cost-optimal.

Có hai cụm từ quyết định đáp án, và phải đọc cả hai mới loại được hết nhiễu:

1. "POSIX-compliant file storage system" — đây là ràng buộc cứng, không thương lượng được. POSIX-compliant nghĩa là hệ thống tệp thật: có cây thư mục, có quyền user/group, có file locking, mount được bằng NFS và ứng dụng đọc ghi bằng lời gọi hệ thống tệp thông thường. Cụm từ này một mình đã cắt bỏ mọi phương án object storage.
2. "accessed for just about a week in a year" — tần suất truy cập rất thấp. Cụm này không dùng để chọn loại storage, mà dùng để chọn storage class trong loại đã bị ràng buộc ở điểm 1.

Thứ tự đọc rất quan trọng: lọc theo POSIX trước, rồi mới tối ưu chi phí trong nhóm còn lại. Làm ngược lại — thấy "archive" và "rẻ nhất" rồi lao vào S3 — là cái bẫy chính của câu này.

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

B. Amazon EFS Infrequent Access là đáp án đúng theo tệp.

Amazon EFS là dịch vụ file system NFS được quản lý hoàn toàn, elastic, dùng được cho cả AWS Cloud services lẫn tài nguyên on-premises — tức là nó thoả đúng yêu cầu POSIX-compliant mà đề đặt ra.

Trong EFS, EFS Infrequent Access (EFS IA) là storage class được thiết kế cho đúng kiểu dữ liệu mà đề mô tả: các tệp không được truy cập hằng ngày. Giá lưu trữ của EFS IA thấp hơn đáng kể so với EFS Standard (theo tài liệu AWS được dẫn trong nguồn, mức chênh lệch rất lớn), đổi lại là phí truy xuất khi thực sự đọc tệp. Với hồ sơ truy cập "một tuần trong một năm", phần lớn thời gian dữ liệu chỉ nằm yên, nên tối ưu giá lưu trữ là hướng đúng và tổng chi phí sẽ thấp hơn hẳn.

Cách bật cũng đơn giản: kích hoạt EFS Lifecycle Management trên file system và chọn lifecycle policy phù hợp, EFS sẽ tự chuyển các tệp nguội sang IA.

Vậy B là phương án duy nhất vừa giữ được ngữ nghĩa file system POSIX, vừa tối ưu chi phí cho dữ liệu truy cập thưa.

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

A. Amazon S3 Standard — sai ở cả hai tiêu chí. S3 là object storage, không phải POSIX-compliant file system: không có file locking, không có ngữ nghĩa thư mục thật (tiền tố chỉ là quy ước đặt tên khoá), không mount như một filesystem thông thường. Ngoài ra S3 Standard là lớp dành cho dữ liệu truy cập thường xuyên, nên ngay cả khi bỏ qua ràng buộc POSIX thì nó vẫn không phải lựa chọn rẻ nhất cho dữ liệu một năm động tới một tuần.

D. Amazon S3 Standard-IA — đây là phương án gần đúng nhất và nguy hiểm nhất. Phần "IA" khớp hoàn hảo với mô tả tần suất truy cập, nên rất dễ chọn theo phản xạ. Nhưng nó hỏng ở đúng chỗ A hỏng: vẫn là object storage, vẫn không POSIX-compliant. Ràng buộc POSIX trong đề là điều kiện loại trừ, không phải điều kiện "nên có" — chọn đúng lớp chi phí trên sai loại storage vẫn là sai.

C. Amazon EFS Standard — phương án này qua được vòng lọc POSIX, vì nó cũng là EFS. Nó hỏng ở vòng thứ hai: EFS Standard là lớp dành cho dữ liệu được truy cập thường xuyên và có giá lưu trữ cao hơn EFS IA. Đề hỏi MOST cost-optimal, mà dữ liệu chỉ được đọc khoảng một tuần mỗi năm — trả giá của lớp truy cập thường xuyên cho dữ liệu nằm yên gần như cả năm là lãng phí. C không sai về kỹ thuật, chỉ sai về tối ưu chi phí — và đề hỏi tối ưu chi phí.

📌 Điểm cần nhớ

• "POSIX-compliant" hoặc "file system" trong đề = EFS (hoặc FSx), không bao giờ là S3. Đây là ràng buộc loại trừ: gặp cụm này thì gạch mọi phương án object storage trước, rồi mới so sánh phần còn lại.
• Lọc theo loại storage trước, tối ưu chi phí sau. Câu này cố tình đặt sẵn một phương án S3 có nhãn "IA" để bắt người đọc lướt qua cụm POSIX. Đúng lớp chi phí trên sai loại storage vẫn là đáp án sai.
• "Infrequent Access" là tên một storage class, tồn tại độc lập trong cả EFS lẫn S3. Nhận ra hồ sơ truy cập thưa mới chỉ giải quyết được nửa câu hỏi — vẫn phải biết nó thuộc họ dịch vụ nào.
• IA đánh đổi phí lưu trữ thấp lấy phí truy xuất khi đọc. Nó chỉ có lợi khi dữ liệu thực sự nằm yên phần lớn thời gian, đúng như mô tả "một tuần trong một năm". Nếu đề nói dữ liệu được đọc thường xuyên thì lựa chọn sẽ đảo ngược sang lớp Standard tương ứng.
• EFS IA bật qua EFS Lifecycle Management, không phải một dịch vụ riêng — nhớ chi tiết này để phân biệt với các câu hỏi về việc chuyển lớp lưu trữ tự động.

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

Đề mô tả một nền tảng ad targeting cần chuyển từ on-premises lên AWS Cloud, và liệt kê một chuỗi ràng buộc kỹ thuật rất cụ thể. Câu hỏi là: chọn database nào cho đúng.

Bốn cụm từ trong đề quyết định đáp án, và phải thoả cả bốn cùng lúc:

1. "millions of requests per second" + "low predictable latency" — đây là workload OLTP kiểu key-value ở quy mô Internet, không phải workload phân tích.
2. "deploy this ad-targeting platform in more than one AWS Region" — cần database ghi được ở nhiều Region, không chỉ đọc.
3. "The structure of the incoming data varies depending on the event" — schema không cố định, tức là cần NoSQL chứ không phải bảng quan hệ có schema cứng.
4. "maximum size of an event is 200 KB" — con số này đưa ra để bạn kiểm tra xem item có vượt giới hạn kích thước của DynamoDB hay không. Nó không vượt.

Ràng buộc phân biệt mạnh nhất là multi-Region kèm ghi ở nhiều nơi, vì nó loại được cả những phương án NoSQL nhìn qua rất giống.

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

A – DynamoDB Global Tables.

DynamoDB là database key-value và document được quản lý hoàn toàn, cho độ trễ ở mức mili-giây một chữ số ở mọi quy mô. Nó khớp từng ràng buộc của đề:

• Request rate và latency: DynamoDB được thiết kế cho đúng dạng tải hàng triệu request mỗi giây với latency thấp và ổn định — đây là mẫu use case ad-tech kinh điển mà AWS vẫn lấy làm ví dụ.
• Schema thay đổi theo event: là NoSQL nên mỗi item có thể mang tập thuộc tính khác nhau, không cần khai báo trước.
• Kích thước item: giới hạn kích thước một item của DynamoDB là 400 KB, lớn hơn mức tối đa 200 KB mà đề nêu — nên event lớn nhất vẫn lưu được, và trung bình 10 KB thì càng thoải mái.
• Nhiều Region: Global Tables sao chép bảng tự động sang các Region bạn chọn, cho multi-Region multi-master — ứng dụng ở mỗi Region đọc và ghi cục bộ trên bản sao gần mình.

Đúng phần thứ tư này mới là lý do đáp án là "Global Tables" chứ không chỉ là "DynamoDB".

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

B – Amazon RDS. Đây là database quan hệ, schema cố định, nên đã vướng ngay ràng buộc "structure of the incoming data varies". Nghiêm trọng hơn: RDS không được thiết kế để phục vụ mức hàng triệu request mỗi giây với độ trễ thấp và ổn định — mở rộng ghi trên một engine quan hệ đòi hỏi sharding thủ công. Loại.

C – DocumentDB. Đây là phương án gần đúng nhất và cũng là cái bẫy chính, vì DocumentDB cũng là NoSQL và cũng lưu được dữ liệu có cấu trúc thay đổi. Chỗ nó hỏng nằm ở yêu cầu multi-Region: một cluster DocumentDB triển khai trong phạm vi một Region cụ thể, và Global Cluster của DocumentDB có kiến trúc một Region chính cộng thêm các Region phụ chỉ đọc — không phải multi-master như Global Tables. Với nền tảng cần ghi event ngay tại nhiều Region, mô hình một điểm ghi duy nhất không đáp ứng được. Ngoài ra DocumentDB cũng không nhắm tới mức request rate mà đề nêu.

D – Amazon Redshift. Redshift là data warehouse cho workload OLAP — phân tích trên khối dữ liệu lớn, quét nhiều dòng, truy vấn chạy trong khoảng giây trở lên. Đề này là workload OLTP phục vụ trực tiếp: tra cứu từng bản ghi, latency thấp, số lượng request cực lớn. Sai loại workload ngay từ gốc, chưa cần xét tới chuyện multi-Region.

📌 Điểm cần nhớ

• Thấy đồng thời "millions of requests per second" + "low predictable latency" + schema thay đổi thì nghĩ ngay tới DynamoDB; thêm "more than one AWS Region" thì đáp án là DynamoDB Global Tables chứ không dừng ở DynamoDB.
• Phân biệt multi-master với primary + read-only secondary: Global Tables cho ghi ở nhiều Region, còn Global Cluster của DocumentDB chỉ có một Region ghi. Đề nào yêu cầu ghi cục bộ ở nhiều Region là chỗ hai thứ này tách nhau.
• Con số kích thước event trong đề thường là bài kiểm tra ngầm về giới hạn item 400 KB của DynamoDB. Dưới ngưỡng thì DynamoDB vẫn dùng được; vượt ngưỡng mới phải tính cách khác.
• OLTP hay OLAP là câu hỏi phải trả lời trước tiên. Redshift xuất hiện trong phương án của đề OLTP gần như luôn là mồi nhử — nó là data warehouse, không phục vụ tra cứu độ trễ thấp ở tần suất cao.
• RDS bị loại vì cả hai lý do độc lập: schema cố định và không mở rộng ghi tới quy mô đề yêu cầu. Chỉ cần một lý do là đủ, nhưng nhận ra cả hai giúp loại nhanh hơn.

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

Đề mô tả hàng nghìn thiết bị mạng (switch, router, cáp) liên tục phát dữ liệu trạng thái theo thời gian thực. Có hai ứng dụng khác nhau cần chính luồng dữ liệu đó: một ứng dụng gửi thông báo, một ứng dụng phân tích để tìm những đường kết nối có thể chết theo thiết bị hỏng.

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

• "real-time status data" — đây là bài toán streaming, không phải bài toán hàng đợi công việc.
• "both the applications can consume the real-time status data concurrently" — hai bên tiêu thụ đồng thời và độc lập trên cùng một dòng dữ liệu.

Chữ concurrently là ràng buộc phân biệt. Nó loại ngay mọi kiến trúc mà một message chỉ được đọc bởi đúng một consumer, và đòi hỏi dữ liệu phải nằm lại trong stream đủ lâu để nhiều ứng dụng cùng đọc theo nhịp riêng của mình.

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

C — Amazon Kinesis Data Streams.

Kinesis Data Streams sinh ra đúng cho tình huống này. Dữ liệu ghi vào stream được lưu giữ lại trong một khoảng thời gian cấu hình được, chứ không biến mất ngay khi có người đọc. Nhờ vậy nhiều ứng dụng khác nhau có thể cùng đọc một stream đồng thời và độc lập — ứng dụng thông báo đọc để bắn cảnh báo, ứng dụng phân tích đọc cùng những bản ghi đó để dựng bản đồ đường kết nối bị ảnh hưởng. Mỗi ứng dụng giữ vị trí đọc riêng, không ai "tiêu thụ mất" dữ liệu của ai.

Hai đặc tính khác cũng khớp với đề:

• Giữ thứ tự bản ghi trong từng shard, và Kinesis Client Library (KCL) định tuyến mọi bản ghi cùng partition key về cùng một record processor. Với dữ liệu thiết bị, nghĩa là toàn bộ trạng thái của một thiết bị đi về một chỗ xử lý — rất tiện cho việc đếm, gộp, lọc và suy ra ảnh hưởng dây chuyền.
• Đọc lại (replay) được các bản ghi theo đúng thứ tự cũ, nên một ứng dụng chạy chậm hơn vẫn bắt kịp mà không mất dữ liệu.

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

A — SQS kết hợp SNS. Đây là phương án gần đúng nhất, vì mô hình fan-out (SNS topic đẩy sang nhiều SQS queue, mỗi ứng dụng một queue) đúng là cho phép hai ứng dụng cùng nhận dữ liệu. Nhưng nó hỏng ở chỗ đây vẫn là messaging/queue chứ không phải stream processing: SQS thiết kế cho các message được xử lý độc lập từng cái một, có ack/fail ở mức từng message, và message bị xoá khỏi queue sau khi xử lý xong — không có khái niệm đọc lại toàn bộ dòng dữ liệu, cũng không có bảo đảm thứ tự và định tuyến theo key như KCL. Với yêu cầu nhiều ứng dụng cùng tiêu thụ một luồng thời gian thực và phân tích trên dòng dữ liệu đó, Kinesis là lựa chọn phù hợp hơn hẳn.

B — Chỉ SNS. SNS là dịch vụ pub/sub thông báo, topic đẩy message tới các subscriber. Nó giải quyết được việc "gửi cho nhiều nơi", nhưng bản chất là dịch vụ thông báo, không phải nền tảng xử lý dữ liệu thời gian thực: không lưu giữ dòng dữ liệu để đọc lại, không có thứ tự và cơ chế phân vùng để ứng dụng phân tích làm việc trên chuỗi trạng thái thiết bị. Ứng dụng thông báo thì tạm dùng được, ứng dụng phân tích thì không.

D — SQS kết hợp Amazon AppFlow. Sai vì AppFlow lạc đề hoàn toàn. AppFlow là dịch vụ tích hợp có quản lý dùng để chuyển dữ liệu giữa các ứng dụng SaaS và AWS (kiểu Salesforce, ServiceNow… sang S3, Redshift). Nó không dính gì tới việc thu nhận telemetry từ thiết bị phần cứng, cũng không giúp hai ứng dụng cùng tiêu thụ một luồng thời gian thực. Ghép thêm SQS cũng không sửa được vấn đề đã nêu ở phương án A.

📌 Điểm cần nhớ

• Thấy "nhiều ứng dụng cùng tiêu thụ một luồng dữ liệu thời gian thực" thì nghĩ tới Kinesis Data Streams trước tiên — dữ liệu được giữ lại nên mỗi consumer đọc độc lập theo vị trí riêng.
• Phân biệt bản chất: SQS = hàng đợi, message xử lý xong là xoá; SNS = thông báo pub/sub, đẩy đi rồi thôi; Kinesis Data Streams = dòng dữ liệu lưu lại, đọc lại và đọc song song được.
• Các từ khoá kéo về Kinesis Data Streams: giữ thứ tự bản ghi, replay dữ liệu cũ, định tuyến theo partition key về cùng một record processor, nhiều ứng dụng đọc đồng thời.
• AppFlow chỉ xuất hiện đúng chỗ khi đề nói tới tích hợp dữ liệu với ứng dụng SaaS; gặp trong bài streaming telemetry 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

Bài toán: một nhóm data engineering chạy nhiều loại Amazon ECS task trên các EC2 instance thuộc cùng một ECS cluster. Toàn bộ output và state data của mọi task phải được lưu lại. Ba con số được nêu ra có chủ đích rõ ràng:

• mỗi task sinh ra khoảng 20 MB dữ liệu,
• có thể có hàng trăm task chạy cùng lúc,
• output cũ được archive nên tổng dung lượng không vượt quá 1 TB.

Câu hỏi chốt lại bằng cụm quyết định: "optimized solution for high-frequency reading and writing".

Ghép hai chi tiết lại là ra đáp án. Thứ nhất, hàng trăm task cùng lúc đòi hỏi một kho lưu trữ dùng chung, truy cập song song từ nhiều instance — đây là điểm loại storage gắn với một instance. Thứ hai, và quan trọng hơn: dung lượng nhỏ (≤ 1 TB) nhưng nhu cầu throughput cao. Đó chính là tỷ lệ throughput-to-storage cao — đúng tình huống mà Bursting Throughput mode không phục vụ tốt, vì trong chế độ đó throughput được cấp tỷ lệ theo lượng dữ liệu đang lưu. Dữ liệu lại còn bị archive bớt đi, nên nền dung lượng càng thấp, throughput khả dụng càng bị bó.

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

B — Use Amazon EFS with Provisioned Throughput mode.

Amazon EFS phân tán dữ liệu trên rất nhiều storage server, nhờ vậy file system co giãn tới quy mô petabyte và cho phép truy cập song song ồ ạt từ nhiều compute cùng lúc — EC2, ECS, Lambda. Hàng trăm ECS task trên nhiều EC2 instance đều mount chung một file system và cùng đọc/ghi được: đúng thứ kịch bản này cần.

Phần "optimized" nằm ở chế độ throughput. Provisioned Throughput mode sinh ra cho đúng các ứng dụng có tỷ lệ throughput-to-storage (MiB/s trên mỗi TiB) cao, hoặc có nhu cầu vượt mức Bursting cấp được. Ở đây lượng dữ liệu lưu trữ nhỏ so với nhu cầu đọc/ghi, nên khai báo thẳng mức throughput cần là cách lấy được hiệu năng mong muốn mà không phải độn thêm dữ liệu rác vào file system chỉ để "mua" thêm throughput.

Chế độ này cũng linh hoạt: tăng mức provisioned bất cứ lúc nào; còn giảm mức, hoặc đổi qua lại giữa Provisioned và Bursting, thì phải cách lần thay đổi trước một khoảng thời gian tối thiểu.

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

A — Amazon EBS volume mounted to the ECS cluster instances. EFS có throughput cao hơn EBS. Ngoài ra EBS chỉ gắn được vào nhiều EC2 instance khi volume thuộc loại io1/io2 và instance thuộc dòng Nitro — đề bài không cho biết loại volume hay loại instance, nên không có căn cứ để giả định điều kiện đó thoả mãn. Không có multi-attach thì mỗi instance chỉ thấy volume của riêng nó, và "output và state data của tất cả task" không nằm chung một chỗ được.

C — Amazon EFS with Bursting Throughput mode. Đây là phương án gần đúng nhất: vẫn là EFS, vẫn chia sẻ được cho hàng trăm task. Nó hỏng ở đúng một chỗ — cơ chế cấp throughput. Với Bursting, throughput của file system tăng theo lượng dữ liệu đang lưu ở standard storage class. Mô hình này hợp với workload dạng nhấp nhô: bùng lên trong thời gian ngắn rồi im ắng phần lớn thời gian. Còn ở đây đề yêu cầu high-frequency reading and writing liên tục, trên một file system dung lượng nhỏ và còn bị archive bớt — mức burst được cấp sẽ không đủ và không được bảo đảm. AWS khuyến nghị mặc định dùng Bursting, nhưng cũng chỉ rõ khi cần throughput cao ổn định thì chuyển sang Provisioned.

D — Amazon DynamoDB table accessible by all ECS cluster instances. Vướng ràng buộc cứng về kích thước: mỗi output của một task khoảng 20 MB, trong khi giới hạn kích thước mỗi item của DynamoDB là 400 KB. Muốn nhét vào thì phải tự viết code cắt output thành nhiều item rồi ghép lại khi đọc — thêm hẳn một lớp phức tạp do mình tự gánh, không phải "optimized solution". DynamoDB là key-value/document store cho item nhỏ truy cập tần suất cao, không phải nơi chứa các khối output kích thước hàng chục MB.

📌 Điểm cần nhớ

• Dung lượng nhỏ + throughput cao = Provisioned Throughput mode. Bursting cấp throughput tỷ lệ theo lượng dữ liệu đang lưu, nên file system nhỏ mà nhu cầu đọc/ghi lớn thì Bursting luôn là lựa chọn sai. Nhận diện qua cụm "high-frequency reading/writing" đi kèm một con số dung lượng khiêm tốn.
• Nhiều instance / nhiều task cùng ghi vào một chỗ → nghĩ tới EFS. EBS mặc định gắn với một instance; multi-attach chỉ có với io1/io2 trên Nitro, và đề không nêu thì đừng tự giả định.
• Đối chiếu kích thước bản ghi với giới hạn của dịch vụ trước khi chọn. Giới hạn 400 KB mỗi item của DynamoDB loại thẳng mọi kịch bản lưu payload hàng chục MB; "viết thêm code để lách" không bao giờ là đáp án "optimized".
• Khi hai phương án chỉ khác nhau ở chế độ cấu hình của cùng một dịch vụ (Bursting vs Provisioned), điểm phân biệt nằm ở đặc tính workload trong đề, không nằm ở bản thân dịch vụ.

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

Đề mô tả một batch job trong workflow big data analytics chạy bằng AWS Lambda: hàm kéo dữ liệu từ Amazon S3, xử lý, rồi ghi kết quả ngược lại S3. Câu hỏi yêu cầu chỉ ra root cause của sự cố, chứ không hỏi cách khắc phục.

Cụm từ quyết định nằm ở hai con số đặt cạnh nhau trong đề:

• "a similar job runs for 30 minutes on average" — khối lượng công việc thực tế cần khoảng nửa tiếng.
• "abruptly failed after 15 minutes of execution" — hàm chết đúng ở mốc 15 phút.

Mốc 15 phút chính là giới hạn thời gian thực thi tối đa của một lần gọi AWS Lambda. Một job cần 30 phút chạy trên nền tảng chỉ cho phép tối đa 15 phút thì không thể nào chạy hết được. Thêm một tín hiệu nữa: từ "abruptly" — hàm bị cắt ngang chứ không phải rơi vào một lỗi ứng dụng cụ thể. Hai chi tiết này gộp lại loại được toàn bộ các phương án còn lại.

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

Đáp án đúng: B — The AWS Lambda function is timing out.

AWS Lambda cho phép chạy code mà không cần cấp phát hay quản lý máy chủ, chỉ trả tiền theo thời gian tính toán thực dùng. Đổi lại sự tiện lợi đó là một ràng buộc cứng: mỗi lần thực thi Lambda có thời lượng tối đa 15 phút. Timeout của hàm được cấu hình trong khoảng từ 1 giây tới trần 15 phút — không có cách nào đặt cao hơn.

Job trong đề trung bình cần 30 phút, tức là gấp đôi trần cho phép. Khi chạm mốc timeout, Lambda chấm dứt lần thực thi ngay lập tức, đúng như mô tả "abruptly failed after 15 minutes". Thời điểm hỏng trùng khít với giới hạn nền tảng là bằng chứng đủ mạnh — nếu là lỗi logic hay lỗi tài nguyên thì thời điểm hỏng sẽ phụ thuộc vào dữ liệu, không đứng yên ở một con số tròn trịa như vậy.

Bài học nền tảng: AWS Lambda không dành cho các tác vụ chạy dài (long-running jobs).

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

A. The AWS Lambda function is running out of memory — Đây là phương án gần đúng nhất, vì hết bộ nhớ đúng là một nguyên nhân phổ biến làm hàm Lambda hỏng, và một batch job xử lý dữ liệu lớn thì rất dễ ngốn RAM. Nhưng nó hỏng ở chỗ cách biểu hiện: lỗi bộ nhớ sẽ sinh ra thông báo lỗi cụ thể trong log, chứ không phải một cái chết lặng lẽ đúng mốc 15 phút. Ngoài ra, mức tiêu thụ bộ nhớ phụ thuộc vào kích thước dữ liệu, không có lý do gì để nó luôn cạn đúng vào phút thứ 15.

C. The AWS Lambda function is missing IAM permissions — Thiếu quyền IAM là một nguyên nhân hợp lý cho các lỗi liên quan tới S3, nhưng lỗi phân quyền lộ ra rất sớm, ngay khi hàm cố gọi tới S3 lúc mới bắt đầu. Nếu thiếu quyền, hàm sẽ không thực thi được trọn vẹn 15 phút — nó sẽ hỏng gần như lập tức. Việc hàm chạy được suốt 15 phút chứng minh nó đã đọc được dữ liệu từ S3, tức quyền không phải vấn đề.

D. The AWS Lambda function chosen runtime is wrong — Chọn sai runtime (ví dụ code Python mà khai runtime Node.js) khiến hàm hỏng ngay lúc khởi tạo, trước cả khi chạm vào dữ liệu. Cũng như phương án C, giả thuyết này mâu thuẫn với việc hàm đã chạy thành công 15 phút.

Điểm chung của C và D: cả hai đều là lỗi hỏng-ngay-từ-đầu, không giải thích nổi 15 phút chạy trơn tru trước khi chết.

📌 Điểm cần nhớ

• AWS Lambda có trần thời gian thực thi 15 phút cho mỗi lần gọi, cấu hình được từ 1 giây tới trần đó nhưng không vượt qua được. Thấy đề nhắc tới mốc 15 phút hoặc một workload dài hơn 15 phút, hãy nghĩ ngay tới timeout.
• Lambda không thiết kế cho long-running jobs. Đề bài nói job cần 30 phút mà lại chạy trên Lambda là dấu hiệu kiến trúc sai ngay từ đầu.
• Dùng thời điểm hỏng để loại phương án. Lỗi IAM và lỗi runtime xuất hiện ngay đầu lần thực thi; lỗi chạy được một lúc lâu rồi mới chết thì phải tìm nguyên nhân khác.
• Chết đột ngột không kèm thông báo lỗi rõ ràng khác với lỗi ứng dụng. Lỗi bộ nhớ, lỗi quyền, lỗi runtime đều để lại thông báo cụ thể trong log; timeout thì cắt ngang lần thực thi.