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

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

Đề mô tả một data engineer đang quản lý nhiều Lambda function cùng dùng chung một bộ thư viện Python cho việc data transformation. Vấn đề hiện tại: mỗi lần thư viện được cập nhật, engineer phải sửa code của từng function một cách thủ công.

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

• "a common set of Python libraries" — đây là thư viện dùng chung, không phải logic nghiệp vụ riêng của từng function. Thư viện dùng chung là đúng thứ Lambda có cơ chế đóng gói riêng.
• "a more efficient method to manage and distribute these shared libraries across multiple Lambda functions" — mục tiêu là quản lý tập trung ở một chỗ rồi phân phối, chứ không phải tự động hoá thao tác cập nhật hàng loạt. Đây chính là ràng buộc tách các phương án gần giống nhau: nhiều phương án có thể làm cho việc cập nhật đỡ nhọc, nhưng chỉ một phương án bỏ hẳn chuyện mỗi function phải mang một bản sao thư viện.

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

B — Package the shared Python scripts into a Lambda Layer and associate this layer with all the relevant Lambda functions.

Lambda Layer sinh ra đúng cho tình huống này: nó là gói code/thư viện tách rời khỏi deployment package của function, được quản lý tập trung và nhiều function cùng tham chiếu tới. Khi bộ thư viện thay đổi, engineer chỉ cần đóng gói và publish lại layer, các function tham chiếu layer đó sẽ dùng được nội dung mới mà không phải sửa và deploy lại code của từng function.

Kết quả: một điểm quản lý duy nhất cho phần dùng chung, deployment package của mỗi function nhỏ gọn hơn vì chỉ còn chứa phần logic riêng, và công sức cập nhật thủ công giảm hẳn — đúng những gì đề yêu cầu.

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

A — Tạo EFS volume chứa các script Python rồi mount vào tất cả Lambda function. Đây là phương án gần đúng nhất, vì Lambda thật sự mount được EFS và code trên đó cũng dùng chung được cho nhiều function. Chỗ nó hỏng là độ phức tạp và mục đích thiết kế: mount EFS kéo theo cấu hình VPC, subnet, security group và access point cho mọi function — nhiều hạ tầng hơn hẳn cho một nhu cầu chỉ là chia sẻ thư viện. EFS hợp với file hoặc dataset lớn không nhét vừa deployment package, còn với thư viện dùng chung thì Lambda Layer là cơ chế trực tiếp và gọn hơn.

C — Lưu script trong AWS CodeCommit rồi dựng CI/CD pipeline tự động deploy. Phương án này tự động hoá việc cập nhật chứ không loại bỏ nó. Bản chất vẫn là: mỗi function tiếp tục mang một bản sao thư viện trong deployment package của mình, và mỗi lần thư viện đổi thì pipeline phải build lại rồi deploy lại toàn bộ các function. Công sức thủ công giảm, nhưng mô hình quản lý code dùng chung không hề thay đổi — vẫn là n bản sao cần đồng bộ. Lambda Layer giải quyết ở tầng gốc: chỉ có một bản.

D — Dùng AWS Step Functions để orchestrate việc cập nhật script trên tất cả function cùng lúc. Đây là dùng sai công cụ. Step Functions là dịch vụ điều phối workflow giữa các bước xử lý và các dịch vụ AWS — nó thuộc về thời điểm chạy ứng dụng, không phải thời điểm phát hành code. Về nguyên tắc ta có thể viết một state machine gọi API cập nhật từng function, nhưng đó là dựng thêm một hệ thống deploy tự chế, phức tạp hơn nhiều mà vẫn không giải quyết được vấn đề gốc: thư viện vẫn nằm rải rác trong từng function.

📌 Điểm cần nhớ

• Đề nói "shared libraries" / "common code" dùng chung cho nhiều Lambda function → phản xạ đầu tiên là Lambda Layer. Đó là cơ chế Lambda dành riêng cho việc tách code dùng chung ra khỏi deployment package.
• Phân biệt "quản lý tập trung" với "tự động hoá thao tác": CodeCommit + CI/CD chỉ làm nhanh việc phải làm nhiều lần, còn Layer khiến việc đó chỉ phải làm một lần. Khi đề nhấn "manage and distribute", hãy chọn cái giảm số bản sao chứ không phải cái deploy nhanh hơn.
• EFS với Lambda dành cho dữ liệu/tệp lớn, cần ghi, hoặc vượt giới hạn kích thước package — không phải lựa chọn mặc định cho thư viện dùng chung, vì nó kéo theo cấu hình VPC.
• Step Functions là orchestration lúc runtime, không phải công cụ quản lý phát hành code. Thấy nó xuất hiện trong câu hỏi về deploy/cập nhật code thì gần như chắc chắn là phương án nhiễu.

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

Đề mô tả một cluster Amazon Redshift chứa hai loại bảng có kích thước rất lệch nhau: bảng giao dịch (fact) trên 500 GB và nhiều bảng dimension dưới 5 MB, được join thường xuyên. Câu hỏi là chọn chiến lược phân bố dữ liệu (distribution style) để tăng tốc truy vấn.

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

• "without additional costs" / "without expanding the cluster" — không được thêm node, nghĩa là mọi cải thiện phải đến từ cách tổ chức dữ liệu trên số node hiện có.
• "numerous smaller dimension tables under 5 MB" kết hợp với "frequently joined" — bảng vừa nhỏ vừa hay tham gia join chính là trường hợp kinh điển của distribution style ALL: nhân bản toàn bộ bảng sang mọi node, chi phí lưu trữ không đáng kể vì bảng chỉ vài MB, đổi lại join không phải chuyển dữ liệu qua mạng giữa các node.

Nhưng chú ý: có tới hai phương án cùng đề xuất ALL cho dimension. Ràng buộc phân biệt chúng nằm ở phần còn lại của câu — sort key.

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

Đáp án đúng theo tệp là B: dùng ALL cho các bảng dimension nhỏ hay được join, đồng thời điều chỉnh sort key để cải thiện hiệu năng truy vấn.

• ALL khiến mỗi node giữ một bản sao đầy đủ của bảng dimension. Khi join với bảng giao dịch lớn, Redshift không cần redistribute dữ liệu giữa các node — đây chính là chi phí đắt nhất trong nhiều truy vấn join. Với bảng dưới 5 MB, cái giá phải trả (dung lượng nhân lên theo số node, và ghi chậm hơn) gần như không đáng kể.
• Bảng giao dịch lớn giữ nguyên distribution hiện tại (EVEN), tức là dàn đều dữ liệu ra các node, tránh skew.
• Phần sort key là thứ bổ sung mà ALL không thay thế được: sort key quyết định thứ tự lưu vật lý trong từng block, cho phép Redshift bỏ qua các block không liên quan khi lọc theo khoảng giá trị — rất hợp với dữ liệu giao dịch lịch sử thường lọc theo thời gian. Đây là tối ưu không tốn thêm hạ tầng, đúng với ràng buộc của đề.

Nói cách khác, B là phương án duy nhất kết hợp cả hai đòn bẩy miễn phí: giảm data movement bằng ALL, và giảm lượng dữ liệu phải quét bằng sort key.

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

A — EVEN cho bảng giao dịch + ALL cho dimension hay join. Đây là phương án gần đúng nhất, và về mặt distribution thì nội dung của nó không sai. Chỗ hỏng: nó dừng lại ở việc chọn distribution style mà không đả động gì tới sort key. Khi đề đã nhấn mạnh phải tăng hiệu năng mà không mở rộng cluster, bỏ qua sort key là bỏ mất một nửa phần tối ưu sẵn có. So sánh trực tiếp với B, B bao trùm A.

C — giữ EVEN cho bảng giao dịch, chuyển dimension sang KEY. Sai ở chỗ áp KEY cho bảng dimension nhỏ. KEY băm dữ liệu theo một cột và đặt các dòng cùng giá trị lên cùng node; nó chỉ có ích khi cả hai phía của join đều được phân bố theo cùng cột đó. Ở đây bảng giao dịch vẫn EVEN, nên join vẫn phải redistribute — không thu được lợi ích co-location như phương án hứa hẹn. Thêm nữa, nếu cột chọn làm distribution key có phân bố lệch thì sinh ra data skew, một số node ôm nhiều dữ liệu hơn hẳn. Với bảng chỉ vài MB, ALL rẻ hơn và chắc ăn hơn nhiều.

D — chuyển bảng lớn sang KEY theo cột join, giữ EVEN cho bảng nhỏ. Đảo ngược đúng cái nên làm. Áp KEY cho bảng trên 500 GB là rủi ro lớn nhất về skew: chỉ cần cột join có vài giá trị chiếm tỉ trọng cao (một mã chứng khoán, một sàn giao dịch được giao dịch nhiều) là một node phải gánh phần dữ liệu lớn bất thường, và truy vấn chạy chậm theo node chậm nhất — có thể tệ hơn cả trước khi tối ưu. Đồng thời giữ EVEN cho các bảng dimension nhỏ là bỏ lỡ đúng trường hợp mà ALL được sinh ra để phục vụ.

📌 Điểm cần nhớ

• Bảng nhỏ + hay join → ALL. Nhân bản vài MB sang mọi node là cái giá rẻ để loại bỏ hoàn toàn việc redistribute khi join.
• KEY chỉ đáng dùng khi cả hai bảng join cùng phân bố theo đúng cột đó, và cột đó phải có giá trị phân tán đều. Áp KEY lên bảng fact khổng lồ theo một cột lệch là công thức tạo data skew.
• EVEN là lựa chọn an toàn cho bảng lớn khi chưa xác định được cột join ổn định — dàn đều, không skew.
• Distribution style và sort key là hai đòn bẩy khác nhau: distribution giảm dữ liệu phải di chuyển giữa các node, sort key giảm dữ liệu phải quét trên đĩa. Đề hỏi "tối ưu mà không thêm chi phí" thì phương án nhắc tới cả hai thường là phương án đầy đủ nhất.

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

Một công ty phân tích truyền thông đang dùng Amazon Athena để chạy các tác vụ ETL bằng SQL, và tạo bảng mới bằng tính năng CTAS (Create Table As Select). Giờ họ muốn dùng Apache Spark để phân tích sâu hơn trên chính những bảng CTAS đó.

Cụm từ quyết định nằm ở vế cuối của đề: "Which Athena feature should the company use to enable Apache Spark to access and analyze CTAS-generated tables". Hai chi tiết cần chú ý:

• "Athena feature" — câu hỏi giới hạn phạm vi trong các thành phần cấu hình của chính Athena, chứ không hỏi về một công cụ kết nối bên ngoài.
• "enable Apache Spark to access" — thứ cần tìm phải là nơi thiết lập môi trường chạy cho Spark bên trong Athena, chứ không phải nơi lưu metadata hay nơi cất câu lệnh SQL.

Athena có hai kiểu engine: engine SQL truyền thống và engine Apache Spark. Việc chọn engine nào, cùng toàn bộ cấu hình đi kèm, được quyết định ở tầng workgroup — đó chính là mấu chốt phân biệt phương án đúng với ba phương án còn lại.

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

A – Athena Workgroup configuration.

Workgroup trong Athena là ranh giới cấu hình cho môi trường truy vấn: nó quy định engine được dùng, vị trí lưu kết quả, các thiết lập truy cập dữ liệu và giới hạn áp cho nhóm người dùng chạy trong đó. Muốn chạy Apache Spark trong Athena, bạn phải làm việc trong một workgroup được cấu hình cho mục đích đó — đây là điểm vào duy nhất ở phía Athena để bật và điều khiển phần tính toán bằng Spark.

Theo lời giải thích gốc, bằng cách cấu hình workgroup, công ty dựng được một môi trường trỏ đúng tới vị trí dữ liệu và các thiết lập liên quan tới những bảng sinh ra từ CTAS, nhờ đó Spark truy cập và phân tích chúng một cách liền mạch qua Athena. Nói ngắn gọn: workgroup là nơi tổ chức và cho phép việc phân tích bằng Spark diễn ra, còn ba phương án kia chỉ chạm tới những mảnh rời rạc của bức tranh.

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

B – Athena JDBC driver. Đây là phương án gần đúng nhất và dễ chọn nhầm nhất, vì JDBC driver đúng là cách để một ứng dụng bên ngoài — kể cả Apache Spark — mở kết nối tới Athena. Chỗ nó hỏng: driver chỉ là đường ống kết nối chung chung. Nó không bật được engine Spark trong Athena, không cấu hình được môi trường chạy, và không cung cấp khả năng quản lý/truy cập có chủ đích dành riêng cho bảng CTAS như workgroup làm được. Đề hỏi "Athena feature" để enable Spark, không hỏi "cách kết nối tới Athena".

C – Athena Saved Queries. Đây thuần túy là tiện ích lưu lại câu SQL hay dùng để mở ra chạy lại. Nó thuộc phạm trù quản lý câu truy vấn, không dính gì tới việc tích hợp một engine phân tích bên ngoài. Lưu một câu CTAS lại không làm Spark thấy được bảng mà câu đó sinh ra.

D – Athena Data Catalog. Đây là phương án dễ gây do dự thứ hai, vì Data Catalog quản lý metadata: định nghĩa bảng, schema, nguồn dữ liệu — và bảng CTAS đúng là được ghi định nghĩa vào đó. Nhưng catalog chỉ trả lời câu hỏi "bảng này có cấu trúc gì, dữ liệu nằm đâu"; nó không trả lời câu hỏi "chạy Spark ở đâu và với cấu hình nào". Metadata là điều kiện cần chứ không phải cơ chế bật tích hợp Spark, nên nó không phải thứ đề bài đang hỏi.

📌 Điểm cần nhớ

• Workgroup là ranh giới cấu hình của Athena — engine (SQL hay Apache Spark), vị trí kết quả, thiết lập truy cập và giới hạn đều đặt ở đây. Câu hỏi nào nhắc tới "cấu hình môi trường chạy trong Athena" thì workgroup là ứng viên đầu tiên.
• Phân biệt "kết nối tới" và "bật lên": JDBC/ODBC driver là đường ống cho client bên ngoài gọi vào Athena; workgroup mới là nơi quyết định engine và môi trường. Đề hỏi enable thì chọn workgroup, đề hỏi connect from an external app thì mới cân nhắc driver.
• Data Catalog = metadata, không phải compute. Nó mô tả bảng và schema, không quyết định việc phân tích chạy bằng engine nào.
• Saved Queries chỉ là tiện ích lưu SQL, không có vai trò gì trong tích hợp hay phân quyền — gặp nó trong danh sách phương án thì gần như luôn là nhiễu.
• CTAS tạo ra bảng thật kèm dữ liệu trên S3, nên phân tích tiếp bằng Spark là chuyện bình thường; vấn đề còn lại chỉ là dựng đúng môi trường Spark trong Athena.

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

Đề bài dựng một tình huống: doanh nghiệp muốn triển khai kiến trúc data mesh, đã chọn AWS Glue để catalog dữ liệu và chạy ETL, và hỏi hai dịch vụ/tổ hợp nào bổ sung vào đó để hoàn thiện data mesh.

Cụm từ quyết định nằm ngay ở câu mô tả yêu cầu: "enable centralized data governance and access management while facilitating comprehensive data analysis". Đây là hai yêu cầu tách bạch, và cũng chính là lý do đề bảo chọn TWO — mỗi đáp án đúng lấp một vế:

• Vế governance + access management → cần một lớp quản trị quyền truy cập tập trung, chi tiết trên data lake.
• Vế storage + analysis → cần nơi chứa dữ liệu quy mô lớn và cách truy vấn dữ liệu đó.

Chi tiết "đã chọn AWS Glue" cũng là một ràng buộc ngầm: dữ liệu sẽ nằm trong một data lake được Glue Data Catalog mô tả, nên các phương án đưa ra hệ quản trị CSDL riêng biệt (DynamoDB, RDS) là đi lệch khỏi mô hình mà đề đã chốt.

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

A — Amazon S3 cho lưu trữ + Amazon Athena cho truy vấn serverless. S3 là object storage co giãn và bền, phù hợp làm nơi chứa dữ liệu của từng domain trong data mesh. Athena bổ trợ trực tiếp cho S3: truy vấn SQL ngay trên dữ liệu nằm trong S3, không phải dựng máy chủ và không phải nạp dữ liệu sang nơi khác. Athena đọc metadata từ Glue Data Catalog — đúng thứ đề bài nói đã chọn — nên cặp này khớp liền mạch với vế "comprehensive data analysis".

C — AWS Lake Formation cho governance tập trung và fine-grained access control. Lake Formation là phần mở rộng của Glue về mặt quản trị: nó quản lý data lake và cấp quyền ở mức chi tiết (theo bảng, theo cột, theo dòng) một cách tập trung, thay vì để mỗi domain tự đặt policy riêng. Đây chính là lời đáp cho cụm "centralized data governance and access management", và cũng là mảnh ghép làm cho data mesh giữ được tính "governed" khi quyền sở hữu dữ liệu bị phân tán về các domain.

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

B — DynamoDB + SageMaker. DynamoDB là NoSQL key-value, phục vụ truy cập theo khoá với độ trễ thấp, không phải nền tảng lưu trữ cho data lake phân tích. SageMaker là nền tảng machine learning, không phải công cụ phân tích dữ liệu phổ quát. Quan trọng hơn: cả hai đều không đóng góp gì cho vế governance, trong khi đề nêu đó là yêu cầu hàng đầu.

D — S3 + QuickSight. Đây là phương án gần đúng nhất, và cần chỉ rõ nó hỏng ở đâu: vế S3 hoàn toàn hợp lý, chính A cũng dùng S3. Chỗ hỏng là QuickSight. QuickSight là công cụ BI/trực quan hoá — nó nằm ở đầu ra, tiêu thụ kết quả truy vấn để vẽ dashboard, chứ không phải lớp truy vấn dữ liệu trong lake. So với A, A cho ta khả năng truy vấn trực tiếp dữ liệu trong S3; D chỉ cho ta cách hiển thị. Với đề bài đang nói về governance và ETL, QuickSight không phải thành phần cốt lõi của data mesh.

E — RDS + Redshift. RDS là CSDL quan hệ cho workload giao dịch (OLTP), không phải nơi chứa dữ liệu của data mesh. Redshift là data warehouse, có thật sự làm được phân tích — nên phương án này không hoàn toàn vô lý về mặt "analysis". Nhưng nó vẫn trượt vì không có bất kỳ thành phần nào giải quyết vế governance tập trung, và vì mô hình RDS → Redshift là kiến trúc warehouse tập trung truyền thống, ngược với tinh thần data mesh (dữ liệu ở lại domain, được truy vấn tại chỗ).

📌 Điểm cần nhớ

• Câu hỏi "Select TWO" thường ghép hai yêu cầu vào một câu mô tả — hãy tách chúng ra trước, rồi tìm phương án lấp từng vế. Ở đây là governance và analysis.
• Trong ngữ cảnh AWS, cụm "centralized governance" + "fine-grained access control" trên data lake gần như luôn trỏ tới Lake Formation; Glue lo catalog và ETL, Lake Formation lo quyền.
• S3 + Athena + Glue Catalog là bộ ba mặc định cho "lưu trữ và truy vấn dữ liệu trong lake mà không dựng hạ tầng". Athena truy vấn, QuickSight trực quan hoá — đừng lẫn hai vai này khi đề hỏi về phân tích dữ liệu.
• Phương án chỉ có dịch vụ mạnh nhưng không chạm vào ràng buộc mà đề nêu (ở đây là governance) thì vẫn sai, dù bản thân dịch vụ đó rất hợp lý cho việc khác.

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

Một hãng hàng không đang lưu dữ liệu chuyến bay hằng ngày dưới dạng .csv trên Amazon S3, tổ chức theo ngày, và dùng Athena để truy vấn. Dữ liệu ngày càng lớn nên họ muốn cải thiện hiệu năng truy vấn.

Cụm từ quyết định nằm ở ba chỗ ghép lại:

• "querying ... .csv files" — định dạng hiện tại là CSV, tức là row-oriented, mỗi lần đọc là đọc trọn dòng kể cả những cột không dùng tới.
• "data organized by date" — dữ liệu đã được phân vùng theo ngày rồi. Đây là chi tiết quan trọng: nó loại bỏ trước mọi phương án xoay quanh cách sắp xếp key/prefix trên S3.
• "MOST effective solution for enhancing query efficiency" — hỏi cái hiệu quả nhất, không phải cái "có ích một chút".

Athena tính chi phí và thời gian theo lượng dữ liệu quét được từ S3. Vậy đòn bẩy lớn nhất còn lại, khi đã phân vùng xong, chính là đổi định dạng lưu trữ để giảm số byte phải đọc.

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

B — chuyển .csv sang định dạng cột như Apache Parquet.

Parquet lưu dữ liệu theo cột thay vì theo dòng. Khi truy vấn chỉ cần vài cột (ví dụ số hiệu chuyến và độ trễ), Athena chỉ đọc đúng các cột đó thay vì phải nạp toàn bộ dòng như với CSV. Ngoài ra Parquet mang theo metadata thống kê ở mức row group (min/max của từng cột), nên Athena có thể bỏ qua nguyên cả khối dữ liệu không thoả điều kiện WHERE — đây chính là predicate pushdown mà đề nhắc tới. Parquet cũng nén tốt hơn nhiều so với văn bản thuần.

Kết quả trực tiếp: ít dữ liệu quét hơn → truy vấn nhanh hơn và rẻ hơn, đúng với cả hai vế "increasing data volume" và "query efficiency".

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

A — chuyển .csv sang JSON, tối ưu schema theo mẫu truy vấn.

Đây là phương án gần đúng nhất và cũng là bẫy chính. JSON có thể giúp mô tả dữ liệu lồng nhau tiện hơn, nhưng nó vẫn là định dạng row-oriented: đọc một bản ghi là đọc hết mọi trường. Không có tổ chức theo cột thì không có predicate pushdown ở mức cột, không có thống kê row group để bỏ qua khối. Tệ hơn, JSON còn lặp lại tên khoá ở mỗi bản ghi nên thường phình to hơn cả CSV — với Athena tính tiền theo byte quét, đây là bước lùi chứ không phải bước tiến.

C — đặt bucket S3 cùng Region với Athena.

Đây là thực hành tốt về độ trễ và chi phí truyền dữ liệu, nhưng đề không hề nói hai thứ đang khác Region. Nó cũng không giải quyết vấn đề gốc: dù cùng Region, Athena vẫn phải quét toàn bộ CSV. Cùng Region là điều kiện nền, không phải đòn bẩy hiệu năng khi khối lượng dữ liệu tăng lên.

D — rải ngẫu nhiên S3 key prefix để tăng throughput request.

Đây là lời khuyên đã lỗi thời và cũng lệch vấn đề. S3 hiện tự mở rộng theo prefix nên việc rải ngẫu nhiên không còn cần thiết như trước. Nguy hại hơn: đề nói dữ liệu đang tổ chức theo ngày, tức là cấu trúc prefix đó chính là partition mà Athena dựa vào để cắt bớt dữ liệu đọc. Làm ngẫu nhiên prefix sẽ phá luôn partition pruning, khiến truy vấn chậm đi. Nút thắt ở đây là lượng byte phải quét, không phải số request/giây.

📌 Điểm cần nhớ

• Với Athena, hiệu năng và chi phí đều đi theo lượng dữ liệu quét được. Mọi câu hỏi kiểu "tối ưu truy vấn Athena" hãy tự hỏi: cách nào làm giảm số byte đọc?
• Hai đòn bẩy chuẩn, theo thứ tự: partition (cắt bớt số file phải mở) và định dạng cột như Parquet/ORC (cắt bớt số cột và số row group phải đọc). Đề đã cho sẵn partition thì đáp án còn lại gần như chắc chắn là định dạng cột.
• Row-oriented vs columnar mới là ranh giới, không phải "text vs không-text". CSV và JSON đều là row-oriented, nên đổi CSV sang JSON không mua được gì về hiệu năng quét.
• Cẩn thận với các phương án chỉ là "thực hành tốt chung" (cùng Region, rải prefix): chúng đúng trong ngữ cảnh khác nhưng không chạm vào nút thắt mà đề mô tả — và đôi khi còn phá thứ đề đã làm đúng.

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

Đề mô tả một công ty tài chính chạy database giao dịch trên Amazon RDS for PostgreSQL. Có ba ràng buộc chồng lên nhau:

1. "credentials are rotated every 30 days" — mật khẩu database phải được xoay vòng định kỳ.
2. "do not want to make code changes each time the credentials are rotated" — ứng dụng phải luôn lấy được bộ credentials mới nhất mà không phải sửa và deploy lại code.
3. "LEAST operational effort" — trong số các cách làm được, chọn cách ít việc vận hành nhất.

Cụm quyết định là "rotated every 30 days" đi kèm "LEAST operational effort". Nhiều phương án trong danh sách lưu trữ được credentials một cách an toàn, nhưng chỉ một phương án vừa lưu vừa tự xoay vòng mà không cần ai viết thêm cơ chế rotation. Đó là chỗ tách bốn lựa chọn ra.

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

C — AWS Secrets Manager. Đây là dịch vụ được thiết kế riêng cho việc quản lý secrets, và nó có sẵn tính năng automatic rotation tích hợp với các database engine như RDS for PostgreSQL: Secrets Manager tự đổi mật khẩu trong database, tự cập nhật giá trị secret, theo lịch mà bạn khai báo. Ứng dụng chỉ gọi API của Secrets Manager để lấy secret mỗi khi cần kết nối, nên sau mỗi lần xoay vòng nó nhận về giá trị mới mà không cần sửa một dòng code nào — đúng yêu cầu số 2 của đề.

Về mặt operational effort, cả ba việc (lưu an toàn, xoay vòng theo lịch, phân phối tới ứng dụng) đều do dịch vụ lo. Đó là lý do nó thắng các phương án tự lắp ghép ở dưới.

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

A — KMS tạo/quản lý encryption key, lưu credentials đã mã hoá trong DynamoDB. Đây là phương án tự chế một hệ thống secrets. Nó giải quyết được phần mã hoá — KMS là dịch vụ quản lý khoá mã hoá, không phải dịch vụ quản lý secrets — nhưng hoàn toàn không có cơ chế xoay vòng mật khẩu database. Bạn vẫn phải tự viết code đổi mật khẩu trong PostgreSQL, tự cập nhật item trong DynamoDB, tự lên lịch chạy, tự xử lý lỗi giữa chừng. Nhiều việc vận hành hơn hẳn, trong khi đề yêu cầu ít nhất.

B — IAM role cấp quyền vào database, ứng dụng lấy temporary credentials từ role. Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất, vì nghe rất "AWS best practice". Vấn đề: IAM role sinh ra temporary credentials của AWS, dùng để gọi các API dịch vụ AWS — nó không phải là cơ chế xoay vòng mật khẩu database mà công ty đang có chính sách bắt buộc. Đề nói rõ chính sách là xoay credentials 30 ngày một lần và phải tuân thủ chính sách đó; chuyển sang mô hình IAM là thay đổi bản chất cách xác thực chứ không phải đáp ứng yêu cầu rotation đã nêu. Phương án này không thoả mãn ràng buộc "rotated every 30 days" của đề.

D — Lưu credentials trong S3 bucket đã mã hoá, dùng bucket policy kiểm soát truy cập. Cũng là kiểu tự chế như A, chỉ đổi nơi cất từ DynamoDB sang S3. Encryption và bucket policy giúp bảo vệ file, nhưng S3 chỉ là kho lưu object — nó không biết gì về mật khẩu database, không có tính năng rotation, không tích hợp với RDS. Lưu credentials trong bucket cũng không phải cách làm được khuyến nghị cho secrets management: rủi ro cấu hình quyền sai cao, và mọi việc xoay vòng vẫn phải làm thủ công.

📌 Điểm cần nhớ

• Thấy đồng thời "database credentials" + "rotation" + "least operational effort" thì gần như chắc chắn là AWS Secrets Manager — nó là dịch vụ duy nhất trong nhóm này có rotation tích hợp sẵn cho RDS.
• Phân biệt vai trò: KMS quản lý khoá mã hoá, Secrets Manager quản lý bản thân secret kèm vòng đời của nó. Mã hoá được secret không có nghĩa là quản lý được secret.
• IAM role → temporary credentials cho AWS API; đó không phải cơ chế xoay mật khẩu database. Đừng để cụm "temporary credentials" đánh lừa khi đề đang nói về password rotation.
• Mọi phương án kiểu "cất credentials vào S3/DynamoDB rồi tự lo phần còn lại" đều thua ở tiêu chí operational effort, vì phần rotation và cập nhật phải tự viết và tự vận hành.

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

Một công ty nghiên cứu thị trường thu thập dữ liệu khảo sát dưới dạng .csv với rất nhiều cột, đưa vào S3 data lake để truy vấn bằng Amazon Athena. Câu hỏi yêu cầu chọn cách nạp dữ liệu sao cho tối ưu về hiệu năng truy vấn và chi phí.

Cụm từ quyết định nằm ở hai chi tiết trong đề:

• "data analysts primarily focus on a subset of columns for most of their queries" — người dùng chỉ đọc một phần nhỏ số cột.
• "full file scans are rare" — quét toàn bộ tệp là chuyện hiếm.

Hai cụm này cùng chỉ về một hướng: cần định dạng lưu trữ theo cột (columnar). Athena tính tiền theo lượng dữ liệu quét được, mà .csv là định dạng theo dòng — muốn đọc 3 cột trong 200 cột thì vẫn phải đọc hết cả dòng. Chuyển sang columnar là cách trực tiếp cắt lượng dữ liệu Athena phải chạm tới.

Chi tiết thứ ba, kín hơn: đề hỏi "ingest into the S3 data lake" — đích đến phải vẫn là S3, không phải một kho dữ liệu khác.

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

B. AWS Glue ETL job xử lý .csv rồi lưu vào data lake dưới dạng Apache Parquet.

Parquet là định dạng lưu trữ columnar, được thiết kế đúng cho tình huống này:

• Dữ liệu của cùng một cột nằm cạnh nhau trên đĩa, nên khi truy vấn chỉ chọn vài cột, Athena chỉ đọc phần dữ liệu của những cột đó và bỏ qua phần còn lại. Ít byte quét hơn nghĩa là tiền Athena ít hơn và truy vấn nhanh hơn.
• Vì mỗi cột chỉ chứa một kiểu dữ liệu, tỉ lệ nén và cách mã hoá hiệu quả hơn hẳn văn bản .csv, nên chi phí lưu trữ trên S3 cũng giảm.
• AWS Glue ETL là dịch vụ ETL có quản lý, đọc .csv và ghi ra Parquet là công việc chuẩn của nó, không phải viết và bảo trì mã tuỳ biến.

Kết quả vẫn nằm trong S3 data lake, Athena vẫn truy vấn trực tiếp — đúng kiến trúc mà đề mô tả.

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

A. Glue ETL chuyển .csv sang JSON, tập trung vào các cột hay được truy vấn. Sai ở chỗ cốt lõi: JSON không phải định dạng columnar, nó vẫn lưu theo bản ghi. Đọc vài trường trong một tài liệu JSON vẫn phải quét qua cả bản ghi, nên lượng dữ liệu Athena quét không giảm được như Parquet — thậm chí JSON còn lặp lại tên trường ở mọi bản ghi nên phình to hơn. Vế "focusing on the columns most frequently queried" nghe có vẻ đúng ý đề, nhưng đó là cắt bớt cột vĩnh viễn: những cột bị bỏ sẽ không truy vấn được nữa, trong khi đề chỉ nói phần lớn truy vấn dùng một tập cột chứ không nói các cột kia là vô dụng.

C. Dùng Lambda phân tích .csv rồi nạp vào một Redshift database chuẩn hoá để Athena truy vấn. Đây là phương án lệch kiến trúc nặng nhất. Nó rời khỏi S3 data lake — đích mà đề yêu cầu — để dựng một data warehouse, tức thêm hẳn một hệ thống phải vận hành và trả tiền, trong khi bài toán chỉ là đổi định dạng tệp. Lambda cũng buộc phải viết mã phân tích .csv thủ công thay vì dùng công cụ ETL có sẵn. Và quan trọng: nạp vào Redshift không đem lại lợi ích của định dạng columnar trên S3 cho Athena như Parquet đem lại.

D. Glue PySpark job chuyển .csv sang .orc rồi nạp vào data lake. Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. ORC cũng là định dạng columnar, cũng nén tốt, cũng giúp Athena quét ít dữ liệu — về nguyên lý nó giải quyết đúng vấn đề. Nó không sai về mặt kỹ thuật, chỉ không phải lựa chọn được ưu tiên: trong hệ sinh thái AWS, Parquet là định dạng columnar mặc định được khuyến nghị cho S3 data lake truy vấn bằng Athena, tích hợp và hiệu năng đều mượt hơn. Khi một đề thi đặt Parquet và ORC cạnh nhau trong cùng bối cảnh Athena + S3, Parquet là đáp án được chờ đợi.

📌 Điểm cần nhớ

• Đề nhắc "nhiều cột nhưng chỉ truy vấn một phần", "hiếm khi quét toàn bộ", hay "giảm chi phí Athena" → phản xạ đầu tiên là chuyển sang định dạng columnar, và trong ngữ cảnh AWS thì đó là Parquet.
• Athena tính tiền theo lượng dữ liệu quét. Mọi thứ làm giảm số byte phải đọc — columnar, nén, partition — đều là câu trả lời hướng "cost-effective".
• CSV và JSON đều là định dạng theo dòng, không cứu được chi phí quét dù có ETL đẹp đến đâu. Thấy JSON trong phương án tối ưu truy vấn Athena thì gần như chắc chắn loại.
• Khi đề nói "ingest into the S3 data lake", phương án nào chuyển dữ liệu sang một kho khác (Redshift, RDS…) là đã đổi kiến trúc so với yêu cầu — thường là bẫy "over-engineering".
• ORC và Parquet cùng là columnar; đặt cạnh nhau trong câu hỏi về Athena thì chọn Parquet, đừng mất thời gian tìm lỗi kỹ thuật của ORC vì nó không sai về nguyên lý.

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

Đề mô tả một chuỗi hai bước: một AWS Lambda function xử lý dữ liệu, sau đó kích hoạt một AWS Glue ETL job. Câu hỏi là dùng dịch vụ AWS nào để orchestrate chuỗi này.

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

• "simple to manage and fully integrated within the AWS ecosystem" — ưu tiên dịch vụ sinh ra để nối các sự kiện giữa các dịch vụ AWS với nhau, không phải dịch vụ phải dựng thêm hạ tầng hay dùng sai mục đích.
• "with minimal administrative effort" — đây là cụm quen thuộc trong đề AWS: khi nhiều phương án đều chạy được về mặt kỹ thuật, cụm này loại hết những cái đòi cấu hình thừa hoặc vận hành nặng, chỉ giữ lại cái tự nhiên nhất.

Thêm một ràng buộc kỹ thuật ngầm: chuỗi bắt đầu từ Lambda rồi mới tới Glue. Phương án nào không gọi được Lambda thì tự loại, bất kể nó tiện đến đâu với Glue.

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

B — Configure Amazon EventBridge to trigger the Lambda function and then the AWS Glue job upon successful completion.

Amazon EventBridge là dịch vụ event bus được thiết kế cho đúng kiểu workflow hướng sự kiện này, và tích hợp sẵn với cả Lambda lẫn Glue trong cùng hệ sinh thái AWS. Cách dựng:

• Một EventBridge rule kích hoạt Lambda function khi điều kiện đầu vào được thoả mãn.
• Một rule khác bắt sự kiện Lambda hoàn tất thành công và kích hoạt AWS Glue job.

Toàn bộ chỉ là cấu hình rule — không có server, không có pipeline phải bảo trì, không phải viết lớp keo nối riêng. Đúng với yêu cầu "simple to manage", "fully integrated" và "minimal administrative effort" mà đề đặt ra.

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

A — AWS Batch quản lý job workflow, chạy Lambda như một job rồi tới Glue job. AWS Batch dùng để chạy khối lượng tính toán dạng batch (job chạy trên container/EC2, có hàng đợi và độ ưu tiên). Nó không sinh ra để điều phối Lambda và Glue; ép Batch vào vai orchestrator ở đây phải dựng thêm compute environment, job queue, job definition — tức là thêm hẳn một lớp hạ tầng phải quản lý cho một luồng vốn chỉ có hai bước. Đi ngược trực tiếp với "minimal administrative effort".

C — AWS CodePipeline, stage đầu chạy Lambda, stage sau kích hoạt Glue job. Đây là phương án gần đúng nhất về mặt hình thức: CodePipeline thật sự có khái niệm các stage chạy tuần tự, và stage có thể invoke Lambda. Nhưng CodePipeline là dịch vụ CI/CD dùng để tự động hoá quy trình phát hành phần mềm — nó gắn với source, build, deploy, chứ không phải để chạy data pipeline định kỳ. Chỗ hỏng: dùng một release pipeline làm bộ điều phối dữ liệu là dùng sai công cụ, kéo theo cấu hình và mô hình vận hành thừa thãi so với hai rule EventBridge. Nó "làm được" nhưng không phải "the most straightforward approach" mà đề đang hỏi.

D — Dùng AWS Glue triggers để lần lượt kích hoạt Lambda rồi Glue job. Phương án này nghe rất hợp lý vì Glue trigger đúng là cơ chế điều phối chuẩn bên trong Glue: chạy ETL job, crawler, nối chúng thành Glue workflow theo lịch hoặc theo điều kiện job trước hoàn tất. Nhưng nó hỏng ở đúng bước đầu tiên của đề: Glue trigger không gọi trực tiếp được Lambda function — phạm vi của nó giới hạn trong các thành phần của Glue. Vế "Glue job" thì đúng, vế "initiate the Lambda function" thì không thực hiện được, nên cả chuỗi không dựng nổi.

📌 Điểm cần nhớ

• EventBridge là lựa chọn mặc định để nối các dịch vụ AWS khác nhau theo sự kiện. Thấy đề mô tả "dịch vụ X xong thì chạy dịch vụ Y", cả hai đều là dịch vụ AWS, và yêu cầu ít công vận hành — EventBridge gần như luôn là đáp án.
• Kiểm tra phạm vi của công cụ điều phối trước khi kiểm tra sự tiện lợi. Glue trigger chỉ điều phối được các thành phần Glue; một phương án chỉ cần không với tới được một mắt xích trong chuỗi là loại ngay, không cần so tiếp về độ đơn giản.
• "Minimal administrative effort" là cụm loại trừ, không phải cụm mô tả. Nó dùng để gạt những phương án chạy được nhưng phải dựng thêm hạ tầng (AWS Batch) hoặc dùng sai loại dịch vụ (CodePipeline).
• Phân biệt dịch vụ theo mục đích sinh ra, không theo "có làm được hay không". CodePipeline dành cho CI/CD, AWS Batch dành cho batch compute, Glue trigger dành cho nội bộ Glue — trong đề trắc nghiệm, dùng đúng mục đích luôn thắng dùng sáng tạo.

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

Đề mô tả một ứng dụng chạy trên Amazon ECS với launch type là Fargate, và ứng dụng đó cần persistent storage để giữ stateful data. Câu hỏi yêu cầu chọn kiểu storage gắn được vào container.

Cụm từ quyết định là "using Fargate" kết hợp với "persistent storage". Hai chữ này khoá chặt phạm vi trả lời:

• Fargate nghĩa là bạn không sở hữu, không nhìn thấy, không quản lý EC2 instance bên dưới. Mọi phương án đòi hỏi thao tác ở tầng hạ tầng máy chủ đều bị loại ngay từ đầu.
• Persistent nghĩa là dữ liệu phải sống lâu hơn vòng đời của task. Container có thể bị dừng và lên lại ở một chỗ hoàn toàn khác, nên storage phải tách rời khỏi nơi task đang chạy.

Bỏ chữ "Fargate" đi thì câu này có nhiều đáp án tranh cãi được; giữ nó lại thì chỉ còn đúng một lựa chọn.

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

A — Use Amazon Elastic File System (EFS) volumes with the ECS containers.

EFS là dịch vụ file storage được quản lý hoàn toàn, truy cập qua giao thức file system tiêu chuẩn trên mạng. ECS có tích hợp sẵn cho phép khai báo EFS volume trong task definition rồi mount vào container, và cách này hoạt động với cả Fargate lẫn EC2 launch type — đúng thứ đề đang cần.

Hai tính chất khiến EFS khớp với yêu cầu của đề:

• Dữ liệu nằm ngoài task. File system tồn tại độc lập; task dừng, bị thay thế, hay được xếp lên hạ tầng khác thì dữ liệu vẫn còn nguyên. Đó chính là định nghĩa của persistent storage trong ngữ cảnh container.
• Nhiều container mount chung một file system. Nhiều task hoặc nhiều service trong ECS cùng đọc/ghi trên một EFS volume, phù hợp với ứng dụng stateful cần chia sẻ dữ liệu.

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

B — Attach EBS volumes directly to the ECS containers.

Đây là phương án gần đúng nhất, vì EBS đúng là block storage bền vững và đúng là dùng để giữ stateful data. Chỗ hỏng nằm ở chữ "directly to the ECS containers" trong bối cảnh Fargate: EBS vốn là volume gắn vào EC2 instance, còn Fargate thì che hoàn toàn tầng instance nên bạn không có chỗ nào để thực hiện thao tác attach đó. Thêm nữa, mô hình block storage gắn vào một máy không hợp với container có thể bị lên lịch lại ở hạ tầng khác — trong khi file system truy cập qua mạng như EFS thì đi theo task đến bất cứ đâu.

C — Mount S3 buckets directly onto the ECS containers.

S3 là object storage, không phải file system. Nó làm việc theo thao tác API trên object (PUT/GET) chứ không phải theo ngữ nghĩa file system, nên không phải thứ để khai báo làm volume mount trong task definition như đề đang hỏi. Ứng dụng hoàn toàn có thể đọc ghi dữ liệu trên S3, nhưng đó là chuyện gọi API từ trong code — khác hẳn với yêu cầu "attached storage" mà câu hỏi đặt ra.

D — Instance store volumes provided by the underlying EC2 instances of Fargate.

Phương án này sai ở hai tầng cùng lúc, nên là phương án dễ loại nhất:

1. Fargate trừu tượng hoá hạ tầng bên dưới, bạn không có quyền truy cập tới instance store của máy chủ vật lý — mệnh đề "underlying EC2 instances of Fargate" tự nó đã mâu thuẫn với mô hình serverless của Fargate.
2. Instance store bản chất là ephemeral: dữ liệu gắn với vòng đời của instance, instance mất là dữ liệu mất. Ngay cả khi truy cập được thì nó vẫn không thoả mãn chữ "persistent" trong đề.

📌 Điểm cần nhớ

• Thấy Fargate + persistent storage trong đề thi thì phản xạ đầu tiên là EFS — đó là kiểu volume mount được vào task Fargate và tồn tại độc lập với task.
• Fargate = không có quyền chạm vào hạ tầng bên dưới. Bất kỳ phương án nào nhắc tới attach EBS trực tiếp, instance store, hay thao tác trên EC2 instance đều tự loại trong ngữ cảnh Fargate.
• Phân biệt ba loại storage theo bản chất: EFS = file system chia sẻ qua mạng, EBS = block storage gắn vào một instance, S3 = object storage gọi qua API. Đề hỏi "gắn/mount vào container" thì chỉ file system trả lời được.
• Ephemeral ≠ persistent. Instance store nhanh nhưng mất theo vòng đời hạ tầng, nên không bao giờ là đáp án cho câu hỏi về dữ liệu stateful cần giữ lại.

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

Một công ty bán lẻ dùng Amazon Aurora để quản lý dữ liệu tồn kho. DB cluster nằm trong private subnet. Một AWS Lambda function cần cập nhật mức tồn kho trong cluster đó. Đề hỏi: làm sao để Lambda kết nối tới Aurora hoàn toàn qua mạng riêng, với công sức quản trị tối thiểu? Chọn HAI.

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

• "resides in a private subnet" — cluster không có đường ra Internet, nên mọi phương án dựa vào đường công cộng đều bị loại ngay từ đầu.
• "only through the private network" — đây là ràng buộc gắt nhất. Không phải "kết nối được là xong", mà là traffic không được đi qua public internet.
• "minimal administrative effort" — loại những phương án dựng thêm hạ tầng mạng không cần thiết.

Và một chi tiết ngầm rất quan trọng: đề chỉ nhắc tới một VPC duy nhất — VPC chứa Aurora. Không hề có VPC thứ hai. Đây chính là chỗ bẫy phương án E.

Bản chất bài toán: Lambda mặc định chạy trong môi trường mạng do AWS quản lý, nằm ngoài VPC của bạn. Muốn nó chạm được vào tài nguyên trong private subnet thì cần đúng hai lớp — lớp định tuyến (đưa Lambda vào trong VPC) và lớp cho phép (security group mở cổng). Thiếu một trong hai thì kết nối không thành.

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

C — Cấu hình Lambda function chạy trong cùng VPC với Aurora DB cluster, trong private subnet.

Đây là lớp định tuyến. Khi bật VPC configuration cho Lambda, AWS gắn network interface vào subnet bạn chỉ định, và từ lúc đó Lambda có địa chỉ IP riêng bên trong VPC. Nó nói chuyện với Aurora qua private IP, traffic không rời khỏi VPC và không chạm public internet — đúng yêu cầu "only through the private network". Đặt Lambda trong cùng private subnet nơi Aurora ở càng làm đường đi ngắn và đơn giản nhất.

B — Sửa security group của Aurora DB cluster để cho phép kết nối đến ở cổng phù hợp từ Lambda function.

Đây là lớp cho phép. Security group hoạt động theo nguyên tắc mặc định từ chối với inbound: đưa Lambda vào đúng VPC nhưng không mở inbound rule ở cổng database thì kết nối vẫn bị chặn im lặng. Cách gọn nhất là cho phép inbound từ security group của Lambda thay vì từ một dải IP cứng — Lambda có thể được cấp IP khác nhau theo thời gian, tham chiếu theo security group thì không phải bảo trì gì thêm, đúng tinh thần "minimal administrative effort".

B và C bổ trợ nhau chứ không thay thế nhau — đó là lý do đề bắt chọn hai.

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

A — Đặt Lambda trong public subnet và cấu hình NAT Gateway cho kết nối đi ra.

Sai ở đúng chỗ đề nhấn mạnh: traffic sẽ được định tuyến qua đường công cộng, trái với yêu cầu "only through the private network". Ngoài ra NAT Gateway sinh ra để cho tài nguyên trong private subnet đi ra ngoài Internet, không phải để chạm vào một database nằm trong cùng VPC — dùng nó ở đây là dựng thêm hạ tầng tốn kém mà không giải quyết đúng vấn đề.

D — Bật tính năng private DNS name cho Aurora DB cluster endpoint.

Đây là phương án gần đúng nhất và dễ mắc bẫy, vì chữ "private" nghe rất khớp với đề. Nhưng DNS chỉ phân giải tên thành địa chỉ — nó không tạo ra đường mạng và cũng không cấp quyền truy cập. Endpoint của Aurora vốn đã phân giải về private IP trong VPC theo mặc định, nên chọn D là chọn một thứ không thay đổi gì cả. Có tên phân giải đúng mà Lambda vẫn ở ngoài VPC thì gói tin vẫn không tới nơi.

E — Thiết lập VPC peering giữa VPC chứa Lambda và VPC chứa Aurora.

Phương án này giả định có hai VPC riêng biệt, trong khi đề không hề nói vậy — và cách làm đúng (C) là đặt Lambda vào chính VPC của Aurora. Khi cả hai đã ở cùng một VPC thì peering không có gì để nối. Ngay cả nếu chấp nhận kịch bản hai VPC, nó vẫn thua ở tiêu chí "minimal administrative effort": phải tạo peering connection, sửa route table ở cả hai phía, rồi vẫn phải mở security group.

📌 Điểm cần nhớ

• Lambda truy cập tài nguyên trong private subnet luôn cần đủ hai lớp: đưa Lambda vào VPC (định tuyến) và mở security group (cho phép). Câu hỏi dạng "Select TWO" về Lambda–RDS/Aurora gần như luôn là cặp này.
• Security group mặc định chặn inbound. Tham chiếu theo security group của bên gọi thay vì dải IP cứng — gọn hơn và không phải bảo trì khi IP đổi.
• DNS không phải là đường mạng. Phân giải tên và khả năng kết nối là hai chuyện tách biệt; đừng chọn phương án DNS khi vấn đề là kết nối.
• NAT Gateway dành cho traffic đi ra Internet, không dành cho giao tiếp nội bộ trong cùng VPC. Đề nào có chữ "không qua public internet" thì NAT Gateway thường là phương án loại.
• Đọc kỹ xem đề có mấy VPC. VPC peering chỉ có nghĩa khi thật sự tồn tại hai VPC — nếu gộp được về một VPC thì đó luôn là lựa chọn ít công sức hơn.