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

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

Đề mô tả một tình huống rất cụ thể: data engineer đã mở cổng chiều vào (inbound) ở CẢ hai nơi — Security Group của EC2 instance và network ACL của subnet chứa instance đó — nhưng vẫn không kết nối được tới service đang chạy trên instance.

Cụm từ quyết định đáp án là "configured inbound traffic ... in both the Security Group ... as well as the network ACL". Đề cố ý nhấn mạnh rằng người này chỉ đụng tới chiều inbound, và không nói gì đến outbound. Đây chính là chỗ để phân biệt: một trong hai lớp lọc chỉ cần luật inbound là đủ, lớp còn lại thì không.

Câu hỏi thực chất kiểm tra một kiến thức nền của VPC: Security Group là stateful, network ACL là stateless. Nhớ đúng chiều của hai tính chất này là chọn được đáp án; nhớ ngược là rơi ngay vào bẫy.

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

Đáp án đúng theo tệp là B: Security Group stateful nên chỉ cần cho phép inbound tới cổng cần thiết là kết nối chạy được; network ACL stateless nên phải cho phép cả inbound lẫn outbound.

Cơ chế cụ thể: khi một client kết nối tới service, hệ điều hành phía client chọn ngẫu nhiên một cổng trong ephemeral port range làm source port. Gói trả lời từ service sẽ đi ngược ra ngoài với destination port chính là cổng ephemeral đó, chứ không phải cổng service.

• Security Group ghi nhớ trạng thái kết nối (stateful). Đã cho phép chiều vào tới cổng service thì lưu lượng trả lời được tự động cho ra, bất kể luật outbound viết thế nào.
• Network ACL xét từng gói độc lập, không nhớ gì (stateless). Luật inbound cho phép gói đi vào cổng service, nhưng gói trả lời đi ra vẫn bị luật outbound xét lại — và nó nhắm vào dải cổng ephemeral. Nếu network ACL đã bị siết chặt hơn mặc định mà không mở outbound cho dải ephemeral, gói trả lời bị chặn, và triệu chứng đúng như đề mô tả: cấu hình trông có vẻ đủ nhưng kết nối vẫn không thành.

Mặc định network ACL cho phép toàn bộ inbound và outbound, nên vấn đề chỉ xuất hiện khi ai đó đã tự viết luật hạn chế lại. Ngoài ra, giải thích nguồn cũng nhắc: nếu nhận lưu lượng từ Internet thì còn phải có route qua internet gateway, còn qua VPN hoặc AWS Direct Connect thì phải có route qua virtual private gateway.

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

A — "IAM Role khai trong Security Group khác với IAM Role được cấp quyền trong network ACL": sai vì tiền đề không tồn tại. Security Group và network ACL là bộ lọc gói ở tầng mạng, luật của chúng viết bằng protocol, port range và CIDR — không có trường IAM Role nào cả. IAM điều khiển quyền gọi API tới AWS, không tham gia vào việc cho phép hay chặn một gói TCP tới cổng service. Đây là phương án bịa thuần tuý để đánh lạc hướng người chỉ nhìn thấy chữ quen thuộc.

C — "Không được sửa luật network ACL từ command line, sửa bằng command line sẽ khiến luật bị chặn và hành vi thất thường": sai. AWS CLI là một cách chính thức và được hỗ trợ đầy đủ để quản lý network ACL, hoàn toàn tương đương với console. Không tồn tại chuyện luật bị "khoá" hay chạy thất thường vì được tạo qua CLI — mọi thao tác đều đi qua cùng một API. Phương án này nghe giống một lời khuyên vận hành nên dễ gây phân vân, nhưng nó không có cơ sở nào.

D — "Network ACL stateful, chỉ cần inbound; Security Group stateless, phải mở cả hai chiều": đây là phương án nguy hiểm nhất vì đúng cấu trúc lập luận nhưng đảo ngược hai tính chất. Nó dùng đúng khái niệm stateful/stateless, đúng lối giải thích về ephemeral port, chỉ gán nhầm cho từng đối tượng. Thực tế ngược lại: Security Group mới là cái stateful, network ACL mới là cái stateless. Ai chỉ nhớ mang máng "có một cái stateful, một cái stateless" mà không nhớ cái nào là cái nào sẽ có 50% khả năng chọn nhầm vào đây. Chú ý thêm: Security Group thực ra vẫn có luật outbound, nhưng vì nó stateful nên lưu lượng trả lời của một kết nối đã được chấp nhận không bị luật outbound xét lại — đó là điểm D hiểu sai hoàn toàn.

📌 Điểm cần nhớ

• Security Group = stateful, network ACL = stateless. Đây là cặp đối lập bị hỏi đi hỏi lại; học thuộc chiều đúng vì đề thi luôn kèm sẵn phương án đảo ngược.
• Với network ACL, luật inbound mở cổng service là chưa đủ — phải mở thêm outbound cho dải ephemeral port, vì gói trả lời quay về client nhắm vào cổng ephemeral chứ không phải cổng service.
• Mặc định network ACL cho phép mọi chiều; triệu chứng "SG và NACL đều đã mở inbound mà vẫn không kết nối được" gần như luôn trỏ tới một network ACL đã bị siết chặt thủ công và thiếu luật outbound.
• IAM không liên quan tới việc lọc gói mạng. Thấy phương án trộn IAM Role vào Security Group hay network ACL thì loại ngay; tương tự, các phương án viện lý do "không được dùng CLI" thường là distractor bịa đặt vì CLI và console dùng chung một API.

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

Đề mô tả một ứng dụng hai tầng trên AWS: web server chạy trên EC2 ở public subnet, tầng dữ liệu là PostgreSQL trên RDS ở private subnet. Web server cần dùng credentials để kết nối vào database, và câu hỏi là nên lưu — và xoay vòng — bộ credentials đó bằng cách nào.

Cụm từ quyết định đáp án nằm ở câu cuối phần mô tả: "changed every 90 days in an automated way using a built-in integration". Có hai vế và cả hai đều quan trọng:

• "automated" — không được để con người tự đổi tay theo lịch.
• "built-in integration" — cơ chế xoay vòng phải là thứ dịch vụ đã có sẵn, không phải thứ ta tự viết ra.

Vế thứ hai mới là ràng buộc phân biệt thật sự. Ba trong bốn phương án đều "tự động" theo nghĩa nào đó, nhưng đều kèm câu "Write custom code to change the database access credentials" — tức là tự viết mã, đúng thứ mà đề loại bỏ. Chỉ cần đọc thấy "custom code" trong một phương án là biết phương án đó trượt ràng buộc "built-in integration", bất kể nó lưu credentials ở đâu và mã hoá kiểu gì.

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

Đáp án đúng là C — dùng AWS Secrets Manager với rotation interval đặt 90 ngày, web server gọi Secrets Manager để lấy credentials.

Secrets Manager sinh ra đúng cho bài toán này: nó lưu trữ, xoay vòng và trả về database credentials, API key cùng các bí mật khác trong suốt vòng đời của chúng. Ứng dụng lấy bí mật bằng một lời gọi API tới Secrets Manager, nên không còn phải nhúng chuỗi nhạy cảm dạng plain text vào mã nguồn hay vào cấu hình máy.

Điểm khớp then chốt: Secrets Manager có rotation tích hợp sẵn cho Amazon RDS, cùng với Amazon Redshift và Amazon DocumentDB. Vì database ở đây là PostgreSQL trên RDS, việc xoay vòng chỉ là bật tính năng và khai chu kỳ mong muốn — Secrets Manager tự đổi mật khẩu trên RDS và cập nhật giá trị bí mật, không cần ai viết dòng mã xoay vòng nào. Đó chính xác là "built-in integration" mà đề đòi hỏi.

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

A — file text mã hoá bằng KMS đặt trên EFS, web server đọc lúc boot, tự viết mã đổi sau 90 ngày. Phần mã hoá thì ổn, nhưng phần xoay vòng lại là custom code, vi phạm thẳng yêu cầu "built-in integration". Ngoài ra credentials vẫn nằm trong một file bên ngoài — dù đã mã hoá, đây không phải cách làm tốt cho bí mật. Còn một điểm yếu về thực thi mà phương án này im lặng bỏ qua: mã tự viết phải vừa đổi mật khẩu trên RDS vừa cập nhật file, và phải xử lý được lúc hai bên lệch nhau.

B — nhét credentials vào EC2 instance user data, đọc lúc bootstrapping, tự viết mã đổi sau 90 ngày. Đây là phương án tệ nhất trong bốn. Nó vừa dính lỗi custom code như A và D, vừa lưu credentials ở nơi kém an toàn nhất: user data không phải là kho bí mật, nó là dữ liệu cấu hình gắn với instance và bất kỳ tiến trình nào trên máy truy cập được instance metadata đều đọc ra được, ở dạng không mã hoá. Thêm nữa, credentials chỉ được nạp lúc bootstrap, nên sau khi đổi thì instance đang chạy vẫn ôm giá trị cũ.

D — file text mã hoá SSE-S3 đặt trên S3, web server đọc lúc boot, tự viết mã đổi sau 90 ngày. Về bản chất giống hệt A, chỉ khác chỗ đặt file. Vẫn là custom code cho việc xoay vòng, vẫn là lưu bí mật trong file ngoài. Đây là phương án dễ gây lưỡng lự nhất vì S3 với SSE-S3 nghe rất "đúng chuẩn", nhưng mã hoá when-at-rest chỉ giải quyết chuyện lưu trữ, không giải quyết chuyện xoay vòng — mà xoay vòng mới là thứ đề đang hỏi.

📌 Điểm cần nhớ

• Đề nhắc tới rotation tự động cho database credentials thì gần như luôn là AWS Secrets Manager, vì nó có rotation tích hợp sẵn cho RDS, Redshift và DocumentDB.
• Cụm "built-in integration" trong đề là tín hiệu loại bỏ mọi phương án chứa "write custom code" — đọc thấy hai chữ đó là gạch được ngay, không cần phân tích chỗ lưu trữ.
• Mã hoá lúc lưu trữ không thay thế được quản lý vòng đời bí mật. KMS trên EFS hay SSE-S3 trên S3 đều bảo vệ file, nhưng không tự xoay vòng, không tự cập nhật lại phía database.
• EC2 user data không bao giờ là chỗ để credentials. Nó đọc được từ instance metadata, không mã hoá, và chỉ nạp lúc bootstrap nên giá trị dễ bị cũ so với thực tế.

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

Đề mô tả một công ty dược chuyển sang AWS, chạy batch job trên Amazon EC2 với dữ liệu nằm trên Amazon EBS, và CTO lo về tuân thủ HIPAA cho dữ liệu nhạy cảm.

Nhưng phần bối cảnh HIPAA chỉ là lớp vỏ. Cụm từ quyết định nằm ở câu hỏi cuối: "the correct capabilities of an encrypted Amazon EBS volume" — tức là khi volume đã được bật mã hoá, thì những gì được mã hoá theo? Kèm ràng buộc "(Select three)", và sáu phương án được xếp thành ba cặp đối nhau (có mã hoá / KHÔNG mã hoá) trên ba đối tượng: dữ liệu at rest trong volume, dữ liệu di chuyển giữa volume và instance, và snapshot tạo từ volume.

Cấu trúc ba cặp đối lập này chính là gợi ý: mỗi cặp chỉ một vế đúng, nên chọn đúng ba phương án nghĩa là chọn đúng một vế cho mỗi cặp. Không cần phân vân "chọn ba trong sáu" theo kiểu tổ hợp — chỉ cần trả lời ba câu hỏi độc lập.

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

Đáp án theo tệp là B, D, E.

Khi tạo một EBS volume có mã hoá và gắn vào instance type được hỗ trợ, phạm vi bảo vệ trải ra cả bốn thứ: dữ liệu at rest trên volume, dữ liệu đang truyền giữa volume và instance, snapshot tạo từ volume đó, và cả volume tạo lại từ những snapshot ấy.

• B — Data at rest inside the volume is encrypted: đây là điều hiển nhiên nhất của EBS encryption, dữ liệu nằm trên volume được mã hoá bằng key quản lý qua AWS KMS.
• E — Data moving between the volume and the instance is encrypted: điểm hay bị bỏ sót. Thao tác mã hoá/giải mã diễn ra trên chính server đang host EC2 instance, nên đoạn đường giữa host đó và bộ nhớ EBS cũng được bảo vệ, không chỉ riêng phần nằm yên trên đĩa.
• D — Any snapshot created from the volume is encrypted: thuộc tính mã hoá thừa kế sang snapshot. Đây là điều quan trọng với HIPAA: nếu snapshot rơi ra ngoài dạng plaintext thì toàn bộ công sức mã hoá volume trở nên vô nghĩa, vì snapshot là bản sao đầy đủ dữ liệu.

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

Ba phương án còn lại là ba vế phủ định, mỗi cái mâu thuẫn trực tiếp với một đáp án đúng ở trên.

• A — Any snapshot created from the volume is NOT encrypted: sai, và đây là bẫy dễ mắc nhất trong ba cái. Nhiều người hình dung mã hoá chỉ áp cho volume đang chạy, còn snapshot là "bản sao ra chỗ khác" nên phải cấu hình riêng. Thực tế mã hoá được kế thừa tự động sang snapshot, và volume khôi phục từ snapshot đó cũng vẫn mã hoá.
• C — Data moving between the volume and the instance is NOT encrypted: sai, nhưng gần đúng theo một hiểu lầm phổ biến — người ta hay tách bạch "encryption at rest" với "encryption in transit" và cho rằng EBS encryption chỉ lo vế đầu, phải làm gì thêm mới có vế sau. Điểm hỏng của lập luận này là quên rằng việc mã hoá xảy ra ở tầng host EC2 chứ không phải ở tầng đĩa, nên dữ liệu đã ở dạng mã hoá trước khi rời host.
• F — Data at rest inside the volume is NOT encrypted: sai một cách trực diện. Nếu dữ liệu at rest không được mã hoá thì cụm từ "encrypted EBS volume" trong đề không còn nghĩa gì. Đây là phương án loại được đầu tiên.

📌 Điểm cần nhớ

• EBS encryption bao trọn gói: at rest trên volume + in transit giữa volume và instance + snapshot + volume tạo lại từ snapshot. Đừng tách nhỏ ra rồi tưởng phải bật từng thứ riêng.
• Mã hoá EBS thực hiện trên host của EC2 instance, đó là lý do dữ liệu in transit tới volume cũng được bảo vệ — nhớ cơ chế này thì không cần học thuộc từng vế.
• Thuộc tính mã hoá kế thừa theo chuỗi volume → snapshot → volume mới. Đây là lý do EBS encryption đủ dùng cho các yêu cầu tuân thủ như HIPAA.
• Key dùng cho EBS encryption do AWS KMS quản lý — câu hỏi về "ai giữ key", "xoay key", hay "kiểm soát quyền truy cập dữ liệu EBS" hầu như luôn dẫn về KMS.
• Mẹo làm bài: khi các phương án xếp thành cặp khẳng định/phủ định và đề yêu cầu chọn n, hãy trả lời từng cặp độc lập thay vì cân nhắc cả tổ hợp.

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

Đề mô tả một hệ thống vừa chuyển từ PostgreSQL sang DynamoDB, và đội kỹ thuật đang tạo bảng mới. Yêu cầu là cho phép ứng dụng truy vấn dữ liệu bằng primary key và một alternate key.

Cụm từ quyết định nằm ở câu cuối phần mô tả: "This option must be added at the outset when you are first creating tables, otherwise, changes cannot be done once the table is created." — tức là thứ cần chọn phải có tính chất chỉ tạo được cùng lúc với bảng, không thêm được sau khi bảng đã tồn tại.

Đây chính là ràng buộc phân biệt hai phương án gần giống nhau nhất trong danh sách: LSI và GSI. Cả hai đều là secondary index, đều cho phép truy vấn theo khoá thay thế, nhưng chỉ một trong hai bị khoá cứng vào thời điểm tạo bảng. Đề không hỏi "index nào tốt hơn", mà hỏi "index nào khớp với ràng buộc vòng đời này".

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

B — Create a Local Secondary Index (LSI)

LSI cho phép bảng có thêm một sort key thay thế, dùng chung partition key với base table. Ứng dụng nhờ vậy truy vấn được dữ liệu theo primary key của bảng và theo khoá thay thế, bằng lệnh Query hoặc Scan nhắm thẳng vào index — đúng nhu cầu đề nêu.

Quan trọng hơn, LSI được tạo cùng lúc với bảng. Đã tạo bảng xong thì không thêm LSI vào được nữa, và LSI hiện có cũng không xoá được. Đặc tính "quyết định một lần lúc thiết kế, sau đó không sửa" ăn khớp chính xác với câu "must be added at the outset… changes cannot be done once the table is created" trong đề. Đây là lý do LSI thắng chứ không phải vì nó mạnh hơn GSI.

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

A — Create DynamoDB Streams Streams ghi lại chuỗi thay đổi ở mức item theo thứ tự thời gian, để ứng dụng khác đọc và phản ứng với sự kiện dữ liệu (trigger, đồng bộ, xử lý near real-time). Nó là cơ chế bắt thay đổi, không phải cơ chế truy vấn — bật Streams lên không cho bạn thêm bất kỳ đường Query nào theo alternate key. Sai về bản chất chức năng.

D — Create a Global Secondary Index (GSI) (phương án gần đúng nhất) GSI cũng là index cho truy vấn theo khoá khác base table, thậm chí linh hoạt hơn LSI vì partition key và sort key đều có thể khác hoàn toàn. Nếu đề chỉ dừng ở "cho phép query theo alternate key" thì GSI hoàn toàn hợp lệ. Chỗ nó hỏng là ràng buộc thời điểm: GSI tạo được cùng lúc với bảng, nhưng cũng thêm được vào bảng đang chạy, và xoá được sau đó. Nó không thoả mãn mệnh đề "phải thêm ngay từ đầu, sau khi tạo bảng thì không thay đổi được". Đề đã cố tình gài mệnh đề này để loại GSI.

C — Migrate away from DynamoDB Đề nói rõ công ty vừa mới hoàn tất việc di chuyển từ PostgreSQL sang DynamoDB. Nhu cầu đặt ra chỉ là thêm một đường truy vấn phụ — chuyện DynamoDB xử lý được bằng tính năng có sẵn. Rời bỏ NoSQL để quay lại mô hình khác kéo theo viết lại đáng kể tầng truy cập dữ liệu, tốn kém hoàn toàn không tương xứng với vấn đề. Đây là phương án "đập đi làm lại" điển hình, gần như luôn sai trong đề thi khi tồn tại một tính năng gốc giải quyết được.

📌 Điểm cần nhớ

• LSI: tạo cùng bảng, không thêm và không xoá về sau. GSI: thêm/xoá lúc nào cũng được. Đây là điểm khác biệt hay bị hỏi nhất giữa hai loại index của DynamoDB.
• LSI dùng chung partition key với base table và chỉ đổi sort key; GSI đổi được cả partition key lẫn sort key.
• Khi đề nhấn mạnh cụm kiểu "at the outset", "cannot be changed after creation", hãy coi đó là tín hiệu chọn theo ràng buộc vòng đời chứ không theo mức độ linh hoạt của tính năng.
• DynamoDB Streams phục vụ bắt thay đổi dữ liệu, không phải truy vấn — đừng nhầm nó với secondary index.
• Phương án "chuyển sang công nghệ khác" hiếm khi đúng khi dịch vụ hiện tại đã có tính năng đáp ứng yêu cầu.

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

Đề mô tả một hệ thống theo dõi phương tiện thời gian thực, chạy NoSQL database trên một Amazon EC2 instance, và khối lượng công việc vừa I/O-intensive vừa throughput-intensive.

Nhưng cụm từ quyết định đáp án không nằm ở mấy chữ mô tả nghiệp vụ đó, mà nằm ở con số: "needs to support up to 25,000 IOPS per volume". Đây là một ràng buộc định lượng, và nó lập tức biến câu hỏi thành phép so sánh trần IOPS tối đa trên mỗi volume của bốn loại EBS volume — chứ không phải cuộc thảo luận xem loại nào "phù hợp về mặt khái niệm".

Chú ý thêm chữ per volume: đề không hỏi làm sao ghép nhiều volume lại thành RAID để cộng dồn IOPS, mà hỏi loại volume nào tự nó đạt được mức đó.

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

Đáp án đúng là A — Provisioned IOPS SSD (io1).

io1 dùng nền solid-state drive (SSD) và là dòng EBS volume được thiết kế riêng cho các workload database quan trọng, nhạy I/O, đồng thời cũng phục vụ tốt các workload cần throughput cao — đúng hai đặc điểm mà đề nêu ra.

Điểm mấu chốt: io1 cho phép provision mức IOPS mong muốn, và trần IOPS trên mỗi volume của nó cao hơn hẳn ba lựa chọn còn lại — thừa sức bao trọn con số 25.000 IOPS mà đề yêu cầu. Chữ "Provisioned" trong tên gọi chính là tính chất phân biệt: bạn khai báo mức hiệu năng cần và EBS cam kết duy trì mức đó một cách ổn định, thay vì để hiệu năng phụ thuộc vào dung lượng volume hay vào cơ chế tích luỹ tín dụng.

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

C — General Purpose SSD (gp2): Đây là phương án gần đúng nhất và là cái bẫy thật sự của câu hỏi. gp2 cũng là SSD, cũng phục vụ tốt nhiều loại transactional workload, dev/test, ứng dụng tương tác độ trễ thấp và boot volume. Nó hỏng ở đúng một chỗ: trần IOPS trên mỗi volume của gp2 thấp hơn mức 25.000 mà đề đòi hỏi (16.000 IOPS/volume). Loại SSD đúng, mô tả workload nghe cũng hợp, nhưng không chạm nổi ngưỡng — thế là loại. Đây là lý do vì sao phải bám vào con số trong đề chứ không đọc theo cảm giác.

B — Cold HDD (sc1): Nền hard disk drive, sinh ra cho dữ liệu lạnh, ít được truy cập, khối lượng lớn và chi phí thấp nhất trong họ EBS. Trần IOPS mỗi volume của nó chỉ ở mức vài trăm (250 IOPS/volume) — kém mức yêu cầu tới hai bậc độ lớn. Hoàn toàn ngược với một database thời gian thực.

D — Throughput Optimized HDD (st1): Cũng nền HDD, tối ưu cho throughput với dữ liệu lớn và kích thước I/O lớn — MapReduce, Kafka, xử lý log, data warehouse, ETL. Đây là phương án dễ mắc bẫy thứ hai, vì đề có nhắc chữ "throughput-intensive" và st1 mang đúng chữ "Throughput Optimized" trong tên. Nhưng st1 mạnh về băng thông tuần tự, còn trần IOPS mỗi volume chỉ khoảng 500 — không đáp ứng được yêu cầu 25.000 IOPS. Từ khớp tên gọi không đồng nghĩa với khớp yêu cầu.

📌 Điểm cần nhớ

• Khi đề EBS đưa ra một con số IOPS cụ thể, hãy coi đó là bộ lọc đầu tiên: đối chiếu trần IOPS/volume của từng loại rồi loại thẳng những loại không với tới, trước khi bàn tới chuyện "loại nào hợp về khái niệm".
• Chia đôi họ EBS cho nhanh: SSD (io1, gp2) tối ưu cho IOPS, HDD (st1, sc1) tối ưu cho throughput hoặc chi phí. Bất kỳ đề nào đòi IOPS cao đều loại sạch nhóm HDD ngay từ đầu.
• gp2 và io1 khác nhau ở trần hiệu năng và ở khả năng cam kết mức hiệu năng. gp2 là mặc định hợp lý cho phần lớn workload; chỉ khi yêu cầu vượt trần của gp2 hoặc cần hiệu năng ổn định đã cam kết thì mới lên io1.
• Cẩn thận với từ khoá trùng tên dịch vụ: đề nhắc "throughput-intensive" không có nghĩa đáp án là "Throughput Optimized HDD". Ràng buộc định lượng luôn thắng sự trùng khớp từ ngữ.

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

Đề mô tả một ứng dụng game online mà phần lớn lưu lượng đến từ việc người dùng tải các tài nguyên tĩnh (static assets): báo cáo bảng xếp hạng lịch sử và tài liệu chiến thuật chơi game. Hạ tầng hiện tại không gánh nổi lượng truy cập này nên các trang bị treo.

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

• "static assets" — dữ liệu tĩnh, chỉ đọc, không cần truy vấn hay xử lý theo từng request. Đây là lý do mọi phương án dựa trên database (RDS, DynamoDB) đều lệch bản chất bài toán.
• "cost-optimal... LEAST operational overhead" — vừa rẻ vừa ít việc phải vận hành. Cụm này loại bỏ những kiến trúc phải quản lý instance, schema, patch, hay tính toán capacity.

Ghép hai ràng buộc lại: cần một nơi lưu file tĩnh không cần quản lý máy chủ, cộng thêm một lớp cache phân tán để giảm tải và đưa nội dung tới gần người dùng.

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

C — Use Amazon CloudFront with Amazon S3 as the storage solution for the static assets.

Amazon S3 là kho lưu trữ object serverless: bạn không phải dự trù dung lượng vì bucket tự co giãn, không phải vá hay quản lý máy chủ lưu file — chỉ put và get. Với các file báo cáo và tài liệu chiến thuật, đây đúng là mô hình truy cập cần thiết. Ngay cả khi ứng dụng vẫn cần một máy chủ cho phần động, máy chủ đó cũng có thể nhỏ hơn vì không còn phải phục vụ nội dung tĩnh — đúng vào chỗ hạ tầng hiện tại đang nghẽn.

Amazon CloudFront là CDN, phát nội dung tĩnh lẫn động qua mạng lưới Edge Location toàn cầu. Khi người dùng yêu cầu một file, request được định tuyến tới Edge Location gần nhất; nếu CloudFront đã cache file đó, nó trả về ngay với độ trễ thấp. Nếu chưa, CloudFront lấy từ origin (chính là bucket S3), rồi lần yêu cầu sau tại khu vực đó sẽ được phục vụ từ cache.

Về chi phí: cache ở Edge Location làm giảm tải lên bucket S3, và truyền dữ liệu ra Internet qua CloudFront thường tiết kiệm hơn so với phát trực tiếp từ S3. Ngoài ra không mất phí truyền dữ liệu từ S3 sang CloudFront — bạn chỉ trả cho phần CloudFront đẩy ra Internet cộng phí request. Đây chính là nghĩa của "cost-optimal" trong đề.

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

A — CloudFront với DynamoDB làm nơi chứa static assets. Đây là phương án gần đúng nhất và là cái bẫy chính: nó có CloudFront, đúng một nửa. Nhưng DynamoDB là cơ sở dữ liệu key-value/document, sinh ra để phục vụ truy vấn bản ghi với độ trễ mili-giây, không phải để làm kho chứa file tải xuống. Dùng nó cho use case này là dùng quá mức cần thiết và sẽ rất đắt. Mấu chốt: sai không nằm ở CloudFront mà nằm ở lựa chọn origin.

B — Lambda + ElastiCache + RDS để phục vụ static assets. Phương án này nhồi ba dịch vụ cho một việc mà một dịch vụ lưu trữ làm được. RDS là relational database, hoàn toàn không cần thiết khi thứ phải phục vụ chỉ là trang tĩnh và file lịch sử tải xuống — S3 hợp hơn hẳn. Thêm ElastiCache và Lambda vào chỉ nhân lên số thành phần phải cấu hình và theo dõi, đi ngược thẳng ràng buộc "LEAST operational overhead".

D — Lambda với RDS để có kiến trúc serverless. Nhãn "serverless" ở đây dễ gây hiểu nhầm: Lambda là serverless, nhưng ghép với RDS thì vẫn còn nguyên gánh nặng vận hành của một hệ quản trị cơ sở dữ liệu. Và như trên, RDS không phải lựa chọn đúng cho bài toán này khi S3 đã giải quyết trọn vẹn. Phương án này cũng thiếu hẳn lớp CDN, nên vấn đề gốc — lưu lượng tải file dồn hết vào hạ tầng gốc — không được xử lý.

📌 Điểm cần nhớ

• Thấy "static assets" / "static content" trong đề, phản xạ đầu tiên là S3 làm origin + CloudFront làm lớp phát. Database (RDS, DynamoDB) chỉ hợp với dữ liệu cần truy vấn, không phải file tải xuống.
• "LEAST operational overhead" hướng về các dịch vụ được quản lý hoàn toàn và về kiến trúc ít thành phần nhất. Một phương án gộp ba, bốn dịch vụ gần như luôn thua trong nhóm câu hỏi có cụm từ này.
• CloudFront không chỉ tăng tốc mà còn giảm chi phí: cache ở edge làm giảm số request về origin, và không có phí truyền dữ liệu từ S3 sang CloudFront.
• Phương án bẫy thường đúng một nửa (ở đây là A: đúng CloudFront, sai origin). Hãy soi từng thành phần trong phương án chứ đừng chọn chỉ vì thấy tên dịch vụ quen thuộc xuất hiện.

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

Đề mô tả nhiều ứng dụng di động của khách hàng doanh nghiệp đang đẩy dữ liệu vào Amazon Kinesis Data Streams, và producer nhận lỗi ProvisionedThroughputExceededException. Phần chẩn đoán đã được đề nói thẳng: "messages are being sent one by one at a high rate" — tức là mỗi bản ghi là một lời gọi PutRecord riêng, tốc độ rất cao.

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

• "sent one by one at a high rate" — nguyên nhân gốc không phải là stream quá nhỏ, mà là cách producer gửi dữ liệu. Kinesis Data Streams giới hạn cả số bản ghi mỗi giây lẫn dung lượng mỗi giây trên từng shard, nên gửi từng bản ghi lẻ sẽ chạm trần số lời gọi trước khi chạm trần băng thông. Shard vẫn còn dung lượng trống mà vẫn bị từ chối.
• "while keeping costs at a minimum" — ràng buộc chi phí. Cụm này loại thẳng mọi giải pháp phải mua thêm tài nguyên, và ép ta chọn cách dùng hiệu quả hơn phần đang có.

Ghép hai ràng buộc lại: cần một cách gộp nhiều bản ghi vào ít lời gọi hơn, không tốn thêm tiền.

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

C — Use batch messages.

Khi một host cần gửi rất nhiều record mỗi giây, gọi PutRecord trong vòng lặp là cách làm không đủ sức. Mỗi lời gọi mang theo chi phí cố định của một HTTP request riêng và tính vào hạn mức số bản ghi/giây của shard. Gộp nhiều bản ghi lại rồi gửi theo lô (PutRecords, hoặc dùng Kinesis Producer Library để tự gom) làm giảm phần chi phí cố định đó và tăng thông lượng thực tế, đồng thời khai thác shard đang có một cách tối ưu hơn.

Điểm mấu chốt: batching sửa đúng nguyên nhân mà đề đã chỉ ra (gửi lẻ từng bản ghi) và không phát sinh chi phí thêm — chỉ là thay đổi ở phía producer.

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

A — Decrease the Stream retention duration. Retention chỉ quy định dữ liệu nằm lại trong stream bao lâu để consumer đọc lại, hoàn toàn không liên quan tới hạn mức ghi vào. Giảm retention không làm producer bớt bị từ chối một chút nào, mà còn rút ngắn cửa sổ đọc lại — nếu consumer đang chậm hoặc cần replay, đây là nước đi gây mất dữ liệu. Sai cả về cơ chế lẫn về hậu quả.

B — Increase the number of shards. Đây là phương án gần đúng nhất và cũng là cái bẫy chính. Thêm shard đúng là nâng được hạn mức tổng nên lỗi sẽ tạm biến mất — nhưng nó hỏng ở hai chỗ. Thứ nhất, chi phí Kinesis Data Streams tính theo shard, nên tăng shard là tăng tiền trực tiếp, đâm thẳng vào ràng buộc "keeping costs at a minimum". Thứ hai, nó không sửa cái đang lãng phí: producer vẫn gửi lẻ từng bản ghi, vẫn tiêu hạn mức số lời gọi trong khi băng thông shard còn thừa. Kết quả là trả tiền cho shard mà không dùng hết.

D — Use Exponential Backoff. Backoff là cách phản ứng với lỗi chứ không phải cách phòng lỗi: nó chỉ thử lại chậm dần sau khi đã bị từ chối. Ở đây tốc độ gửi vốn đã vượt khả năng xử lý, nên backoff chỉ giúp trong ngắn hạn; hễ tốc độ request tăng lên là ProvisionedThroughputExceededException xuất hiện trở lại. Ngoài ra retry còn kéo theo độ trễ và nguy cơ dồn ứ ở phía producer. Đây là lớp phòng vệ nên có, nhưng không phải lời giải cho câu hỏi này.

📌 Điểm cần nhớ

• ProvisionedThroughputExceededException trong Kinesis Data Streams có hai nguyên nhân khác hẳn nhau: vượt hạn mức dung lượng (cần thêm shard) hoặc vượt hạn mức số bản ghi/giây do gửi lẻ (cần batching). Đọc kỹ đề để biết là ca nào — đề luôn gợi ý qua mô tả hành vi producer.
• Cụm "at a minimum cost" trong đề thi AWS gần như luôn loại phương án "mua thêm tài nguyên" (thêm shard, tăng size) và nghiêng về phương án tối ưu cách dùng tài nguyên hiện có.
• Batching (PutRecords / Kinesis Producer Library) là cách chuẩn để producer đạt thông lượng cao: gộp nhiều record, giảm số HTTP request, kết hợp gửi song song.
• Exponential backoff xử lý triệu chứng, không xử lý nguyên nhân. Khi đề nói tốc độ gửi liên tục cao chứ không phải đột biến nhất thời, backoff luôn là đáp án nhiễu.
• Retention duration thuộc về phía đọc (bao lâu dữ liệu còn đọc lại được), không dính gì tới hạn mức ghi — đừng nhầm hai trục này.

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

Đề mô tả hai thư mục trên Amazon S3, mỗi thư mục 10 file JSON, nhưng tỷ lệ trộn schema khác nhau:

• INPUT-FOLDER1: 8 file SCH_A + 2 file SCH_B → 80% / 20%
• INPUT-FOLDER2: 7 file SCH_A + 3 file SCH_B → 70% / 30%

Hai schema hoàn toàn không liên quan nhau: SCH_A có id, first_name, last_name; SCH_B có city, country. Câu hỏi là AWS Glue crawler sẽ tạo ra bao nhiêu bảng khi crawl từng đường dẫn riêng biệt.

Cụm từ quyết định đáp án chính là hai con số 8/2 và 7/3 — chứ không phải nội dung schema. Glue crawler suy ra schema ở mức thư mục và gộp các file thành một bảng khi schema đa số vượt ngưỡng partition 70%. Đây là ngưỡng lớn hơn 70%, không phải bằng hoặc lớn hơn. Nhận ra chi tiết "higher than 0.7" là nhận ra vì sao hai thư mục nhìn na ná nhau lại cho kết quả trái ngược.

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

Đáp án đúng là C: INPUT-FOLDER1 ra một bảng chứa cột của cả hai schema, còn INPUT-FOLDER2 ra hai bảng riêng.

Crawler đánh giá độ tương đồng schema theo hai điều kiện: tỷ lệ schema chiếm đa số phải cao hơn ngưỡng partition 0.7, và số schema khác nhau (số "cluster") không được vượt quá 5.

• INPUT-FOLDER1: 8/10 = 80% file theo SCH_A, cao hơn 70% → ngưỡng được thoả. Số schema khác nhau là 2, chưa chạm giới hạn cluster. Crawler coi các file này là partition của cùng một bảng, và bảng đó gộp cột của cả SCH_A lẫn SCH_B (id, first_name, last_name, city, country).
• INPUT-FOLDER2: 7/10 = 70% — đúng bằng ngưỡng chứ không vượt qua. Điều kiện "higher than 0.7" không thoả, nên crawler không gộp; nó tách ra thành các bảng riêng, mỗi bảng mang cột của một schema.

Kết quả có thể kiểm chứng qua log của crawler trong Amazon CloudWatch để xem bảng nào đã được tạo.

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

• A — cả hai thư mục đều ra một bảng gộp cột hai schema: đúng phần INPUT-FOLDER1 nhưng sai phần INPUT-FOLDER2. Đây là phương án dễ chọn nhất nếu người học nhớ ngưỡng là "70% trở lên" thay vì "cao hơn 70%". Với tỷ lệ 7/3, phép so sánh rơi đúng vào biên và không thoả, nên INPUT-FOLDER2 không được gộp thành một bảng.
• B — đảo ngược kết quả của hai thư mục: nói INPUT-FOLDER2 ra một bảng gộp còn INPUT-FOLDER1 ra hai bảng. Đây chính là kết luận lộn ngược: thư mục có tỷ lệ đồng nhất cao hơn (80%) mới là thư mục được gộp, còn thư mục phân mảnh hơn (70/30) mới bị tách. Phương án này mâu thuẫn trực tiếp với cách ngưỡng partition hoạt động.
• D — cả hai thư mục đều ra hai bảng: đúng phần INPUT-FOLDER2 nhưng sai phần INPUT-FOLDER1. Người chọn phương án này thường suy luận rằng vì hai schema không có cột nào chung nên crawler chắc chắn phải tách. Nhưng crawler không quyết định dựa trên mức độ giống nhau về cột — nó quyết định dựa trên tỷ lệ file theo schema đa số. Với 80% file thuộc SCH_A, ngưỡng thoả và crawler vẫn gộp, dù city/country chẳng liên quan gì tới id/first_name.

📌 Điểm cần nhớ

• Glue crawler suy ra schema ở mức thư mục, rồi so sánh schema giữa các thư mục; nếu khớp thì coi là partition của cùng một bảng, không khớp thì mỗi thư mục thành một bảng riêng — dẫn tới số bảng tăng lên.
• Điều kiện gộp là tỷ lệ schema đa số phải cao hơn ngưỡng partition 0.7 (70%). Đây là so sánh nghiêm ngặt: đúng 70% là không thoả. Đề thi rất hay đặt bẫy ngay ở biên này.
• Điều kiện thứ hai: số schema khác nhau (cluster) không vượt quá 5. Trộn quá nhiều dạng dữ liệu trong một đường dẫn cũng làm crawler tách bảng dù tỷ lệ có nghiêng hẳn về một phía.
• Khi ngưỡng thoả, bảng kết quả gộp cột của tất cả schema có mặt, kể cả những schema thiểu số hoàn toàn không liên quan. Mức độ giống nhau về tên cột không phải tiêu chí quyết định — tỷ lệ file mới là.
• Muốn biết crawler thực sự đã tạo những bảng nào, đọc log crawler trong Amazon CloudWatch.

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

Đề mô tả một bảng DynamoDB được cấp phát sẵn 500 WCU, 5000 RCU và 50 GB dung lượng, rồi hỏi bảng sẽ được chia thành bao nhiêu partition.

Cụm từ quyết định nằm ở chỗ đề cho cả ba con số cùng lúc: hai con số về throughput (WCU, RCU) và một con số về dung lượng lưu trữ (GB). Đây chính là ràng buộc phân biệt các phương án gần giống nhau — nếu chỉ nhìn throughput bạn ra một số, chỉ nhìn dung lượng bạn ra một số khác, và các đáp án nhiễu được dựng đúng từ hai cách tính phiến diện đó.

Số partition của một bảng DynamoDB phải thoả đồng thời hai giới hạn:

• Mỗi partition chỉ phục vụ được một mức throughput trần nhất định (1.000 WCU và 3.000 RCU cho một partition).
• Mỗi partition chỉ chứa được một lượng dữ liệu trần (10 GB).

Vì phải thoả cả hai, kết quả là giá trị lớn hơn trong hai phép tính, không phải tổng và cũng không phải giá trị nhỏ hơn.

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

Đáp án đúng là B — 5 partitions.

Tính theo throughput:

500 WCU / 1.000 WCU  = 0,5
5.000 RCU / 3.000 RCU = 1,67
Tổng = 2,17  →  làm tròn lên = 3 partitions

Lưu ý cách cộng: RCU và WCU được quy về "phần trăm sức chứa của một partition" rồi mới cộng lại, vì cùng một partition vừa gánh đọc vừa gánh ghi. Sau khi cộng mới làm tròn lên, chứ không làm tròn từng thành phần rồi mới cộng.

Tính theo dung lượng:

50 GB / 10 GB = 5 partitions

Lấy giá trị lớn hơn:

Max(3, 5) = 5 partitions

Ba partition đủ để gánh throughput nhưng chỉ chứa được 30 GB — không đủ chỗ cho 50 GB dữ liệu. Ngược lại, 5 partition thì thừa sức gánh throughput đã cấp phát. Vì vậy dung lượng mới là ràng buộc quyết định trong câu này, và câu trả lời là 5.

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

A — 3 partitions. Đây là phương án gần đúng nhất và cũng là cái bẫy chính. Con số 3 chính là kết quả của phép tính throughput: Roundup(0,5 + 1,67) = 3. Nó hỏng ở chỗ bỏ qua hoàn toàn ràng buộc dung lượng: 3 partition chỉ chứa được khoảng 30 GB, trong khi đề nói rõ cần 50 GB. Ai chọn A là đã dừng lại sau nửa bài toán.

D — 6 partitions. Đây là hệ quả của việc làm tròn lên từng thành phần rồi mới cộng, hoặc cộng nhầm hai kết quả với nhau. Ví dụ Roundup(0,5) + Roundup(1,67) = 1 + 2 = 3, rồi lại cộng thêm... hoặc 5 + 1 = 6. Dù đi theo lối nào thì lỗi cũng cùng một bản chất: cộng hai ràng buộc thay vì lấy giá trị lớn hơn. Throughput và dung lượng không cộng dồn với nhau — cùng một partition vừa chứa dữ liệu vừa phục vụ request, nên hai phép tính là hai cách đo cùng một tập partition, không phải hai nhóm partition riêng biệt.

C — 8 partitions. Sai theo cùng kiểu như D nhưng lệch xa hơn: 5 + 3 = 8, tức là cộng thẳng kết quả tính theo dung lượng với kết quả tính theo throughput. Đây là phiên bản "cộng" rõ ràng nhất của lỗi ở D. Không có công thức nào của DynamoDB cho ra 8 với dữ kiện này.

📌 Điểm cần nhớ

• Công thức partition của DynamoDB là Max(partition theo throughput, partition theo dung lượng) — lấy giá trị lớn hơn, tuyệt đối không cộng hai vế lại.
• Phía throughput: quy RCU và WCU về tỷ lệ trên trần của một partition (1.000 WCU / 3.000 RCU), cộng trước rồi mới làm tròn lên. Làm tròn từng vế rồi cộng sẽ ra số lớn hơn thực tế.
• Phía dung lượng: 10 GB là trần của một partition, chia tổng dung lượng cho 10 GB rồi làm tròn lên.
• Khi đề cho đủ cả ba con số WCU, RCU và GB, gần như chắc chắn đề đang kiểm tra xem bạn có nhớ phải so hai vế hay không — và đáp án nhiễu thường chính là kết quả của một vế bị bỏ quên hoặc của phép cộng sai. Tính cả hai vế rồi mới nhìn danh sách đáp án.

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

Kiến trúc trong đề: ứng dụng chat ghi dữ liệu streaming vào Amazon Kinesis Data Streams, phân vùng theo user id; một AWS Lambda function đọc từ stream, kiểm tra tính hợp lệ của nội dung rồi ghi sang Amazon OpenSearch Service. Vào giờ cao điểm, độ trễ từ lúc dữ liệu vào Kinesis Data Streams cho tới lúc tới OpenSearch Service rất cao, dẫn tới sai lệch dữ liệu.

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

• "partitioned by user id" cộng với "must receive the data of a specific user in the sequence... without changing the order" — thứ tự chỉ được bảo đảm trong phạm vi một partition key. Ràng buộc này loại bỏ mọi phương án làm xáo trộn cách dữ liệu được phân vùng hoặc thay hẳn nền tảng streaming.
• "the least amount of operational overhead" — đây là cụm từ phân loại kinh điển: mọi phương án đòi dựng thêm hạ tầng mới hoặc viết lại đường ống đều bị loại, kể cả khi về mặt kỹ thuật chúng có thể xử lý được tải.

Nguyên nhân gốc của lag ở đây là năng lực của stream trong giờ cao điểm, chứ không phải là lỗi thiết kế của khâu validation.

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

A. Tăng số shard trong Kinesis data stream để đáp ứng lượng dữ liệu tăng trong giờ cao điểm.

Năng lực của một Kinesis data stream được định nghĩa bởi số shard trong stream đó. Giới hạn có thể bị vượt theo throughput dữ liệu hoặc theo số lượng bản ghi PUT. Khi vượt hạn mức, lời gọi ghi dữ liệu bị từ chối với ngoại lệ ProvisionedThroughputExceeded. Nếu đó chỉ là đợt tăng tạm thời, producer thử lại là xong; nhưng nếu tốc độ dữ liệu đầu vào tăng kéo dài — đúng như mô tả "giờ cao điểm" trong đề — thì cách xử lý đúng là tăng số shard để có đủ năng lực cho các lời gọi ghi thành công một cách ổn định. CloudWatch metrics cho biết tốc độ dữ liệu đầu vào thay đổi ra sao và ngoại lệ ProvisionedThroughputExceeded có xuất hiện hay không.

Kinesis Data Streams hỗ trợ resharding, cho phép điều chỉnh số shard để thích ứng với thay đổi của tốc độ dòng dữ liệu. Thao tác split làm tăng số shard, do đó tăng năng lực dữ liệu của stream. Đây là thay đổi cấu hình trên chính dịch vụ đang dùng, không phải viết lại kiến trúc — nên thoả mãn ràng buộc "least operational overhead". Lưu ý về chi phí: vì tính tiền theo shard, split sẽ làm tăng chi phí của stream.

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

B. Chuyển khâu validation từ AWS Lambda sang Amazon Firehose. Đây là phương án gần đúng nhất và cũng dễ nhầm nhất, vì người học hay nghi ngờ Lambda là điểm nghẽn. Nhưng Lambda là dịch vụ compute có khả năng mở rộng cao: bạn còn có thể tăng mức xử lý đồng thời bằng cách cho Lambda xử lý nhiều batch song song trên mỗi shard, và ngay cả khi tăng số batch đồng thời trên mỗi shard, Lambda vẫn bảo đảm thứ tự xử lý ở mức partition key — tức là đúng yêu cầu "dữ liệu của một user giữ nguyên thứ tự" trong đề. Vậy nên thay Lambda bằng Firehose không phải là cách chữa đúng vấn đề.

C. Thay Kinesis Data Streams bằng Apache Kafka. Phương án này rơi thẳng vào bẫy của cụm "least amount of operational overhead". Chuyển sang Apache Kafka đòi hỏi công sức phát triển đáng kể để đưa vào giải pháp hiện có — thay nền tảng streaming, viết lại producer và consumer, vận hành thêm một hệ thống mới. Dù Kafka có xử lý được lưu lượng lớn, nó vi phạm chính ràng buộc mà đề nêu ra.

D. Nhiều consumer application cùng đọc từ stream làm vượt giới hạn per-shard; tách Data Stream riêng cho từng consumer. Phương án này suy diễn ra một chi tiết không hề có trong đề. Use case chỉ mô tả đúng một consumer là Lambda function làm validation, không nói gì tới nhiều consumer application. Vì tiền đề của phương án không tồn tại trong đề bài, nó không liên quan tới tình huống được hỏi.

📌 Điểm cần nhớ

• Năng lực của Kinesis Data Streams được đo bằng số shard; lag kéo dài hoặc ProvisionedThroughputExceeded do tải tăng bền vững thì cách chữa trực tiếp là resharding (split) để tăng số shard, đổi lại chi phí tăng theo shard.
• Cụm "least operational overhead" trong đề gần như luôn loại các phương án thay nền tảng hoặc dựng hạ tầng tự quản (như thay Kinesis bằng Kafka), và ưu tiên chỉnh cấu hình trên dịch vụ managed đang dùng.
• Thứ tự trong Kinesis chỉ được bảo đảm theo partition key. Lambda giữ đúng thứ tự ở mức partition key kể cả khi xử lý nhiều batch song song trên mỗi shard — nên tăng độ song song của Lambda không phá vỡ yêu cầu về thứ tự.
• Cẩn thận với phương án tự thêm giả định không có trong đề (ví dụ "chắc là có nhiều consumer"). Nếu use case không nhắc tới, phương án đó là mồi nhử.