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

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

Đề mô tả một trang tin tức lưu lượng cao đang chậm vì read-heavy queries dồn vào database chính, và dữ liệu bị đọc nhiều nhất là user session data và website preferences. Yêu cầu đặt ra là một caching solution cho high throughput và low latency.

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

• "caching solution" — đề hỏi thẳng một lớp cache đặt trước database, không hỏi cách mở rộng bản thân database.
• "user session data and website preferences" — dữ liệu động, thay đổi theo từng người dùng, tra cứu theo khoá.
• "main database" — đề cố tình không nói đó là database gì. Điều này loại ngay mọi phương án chỉ chạy được với một engine cụ thể.

Ba ràng buộc này cộng lại chỉ khớp với một lớp cache in-memory đứng độc lập với engine database bên dưới.

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

B — Amazon ElastiCache là dịch vụ in-memory data store/cache được quản lý, sinh ra đúng cho tình huống này. Ứng dụng hỏi ElastiCache trước; trúng cache thì trả kết quả từ bộ nhớ với độ trễ rất thấp, trượt cache mới đi xuống database rồi ghi kết quả lại vào cache. Nhờ vậy phần lớn lượt đọc lặp lại không còn chạm tới database chính, vừa giảm tải cho database vừa cho throughput cao và latency thấp — đúng hai thứ đề đòi.

Riêng session data và preferences là dạng dữ liệu hợp với ElastiCache: kích thước nhỏ, tra theo khoá, đọc lại rất nhiều lần, và chấp nhận được việc lưu tạm trong bộ nhớ. Quan trọng hơn, ElastiCache không phụ thuộc vào loại database phía sau — đặt trước database quan hệ hay không quan hệ đều được, nên nó là phương án duy nhất không cần thêm giả định nào ngoài những gì đề đã nói.

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

A — DynamoDB với DAX. Đây là phương án gần đúng nhất, vì DAX đúng là một in-memory cache và đúng là giải quyết read-heavy. Chỗ hỏng nằm ở phạm vi áp dụng: DAX chỉ làm cache cho DynamoDB. Đề chỉ nói "main database" chứ không hề nói đó là DynamoDB, nên chọn A tức là tự ý giả định kiến trúc — hoặc tệ hơn, ngầm bắt trang web phải chuyển dữ liệu sang DynamoDB, một việc đề không yêu cầu. Câu hỏi là "thêm cache vào hệ thống đang có", không phải "đổi database".

C — S3 + CloudFront. Cặp này là lớp cache cho nội dung tĩnh phân phối qua edge: ảnh, CSS/JS, file tải về. Session data và preferences thì động và riêng cho từng người dùng — chính đề đã gọi chúng là dữ liệu người dùng. Đẩy loại dữ liệu này ra edge cache là sai cả về kỹ thuật lẫn về an toàn dữ liệu, và nó cũng không hề chặn bớt các truy vấn đọc đang đánh vào database. Chữ "static" trong chính phương án C là dấu hiệu tự tố cáo.

D — RDS read replicas. Read replica có giảm tải đọc thật, nên nghe rất hợp lý. Nhưng nó không phải caching solution — mỗi truy vấn vẫn là một truy vấn database đầy đủ, chỉ chạy trên một máy chủ khác. Kết quả vẫn phải qua parse, execute, đọc từ tầng lưu trữ, nên độ trễ về bản chất là độ trễ database chứ không phải độ trễ của bộ nhớ. Với tra cứu session lặp đi lặp lại ở quy mô lớn, cách này vừa đắt hơn vừa không đạt được mức latency mà một in-memory cache cho. Ngoài ra nó cũng ràng buộc rằng database chính là RDS — điều đề không nói.

📌 Điểm cần nhớ

• Đề hỏi "caching" kèm "low latency" → nghĩ tới in-memory cache, không phải scale-out database. Read replica giảm tải đọc nhưng không phải là cache.
• DAX chỉ dành cho DynamoDB. Đề không nêu rõ loại database thì DAX tự động sai; ngược lại, nếu đề nói thẳng "DynamoDB table" thì DAX mới là đáp án được ưu tiên hơn ElastiCache.
• S3 + CloudFront = nội dung tĩnh. Hễ dữ liệu là động hoặc riêng theo từng người dùng (session, preferences, kết quả truy vấn) thì cặp này bị loại.
• Với session state và user preferences trong đề thi AWS, ElastiCache gần như luôn là câu trả lời mặc định khi database không được chỉ đích danh.

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

Một công ty lưu tài liệu nhạy cảm trong Amazon S3 bucket và muốn chỉ những request xuất phát từ một dải IP nhất định trong mạng nội bộ công ty mới truy cập được.

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

• "originating IP address" — điều kiện lọc dựa trên địa chỉ IP nguồn của request.
• "enforce this policy at the bucket level" — luật phải gắn vào chính cái bucket, áp cho mọi người gọi tới nó, chứ không phải gắn vào từng danh tính hay từng tài nguyên mạng khác.

Ràng buộc "at the bucket level" chính là thứ phân biệt các phương án nghe na ná nhau. S3 là dịch vụ chạy ngoài VPC, truy cập qua endpoint công khai của AWS — nên mọi công cụ mạng gắn vào VPC đều không chạm được tới nó.

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

C — Apply an S3 bucket policy that includes a condition to allow access only from the specified IP address range.

S3 bucket policy là loại resource-based policy gắn trực tiếp lên bucket. Nó có khối Condition, trong đó dùng được khoá điều kiện về IP nguồn của request để giới hạn dải IP được phép gọi tới.

Ba lý do khớp đúng yêu cầu của đề:

• Policy nằm trên bucket, nên áp cho mọi request tới bucket đó — đúng nghĩa "enforce at the bucket level" mà đề đòi.
• Condition cho phép diễn đạt thẳng ràng buộc theo dải IP, không cần thêm hạ tầng mạng nào.
• Đây là cách chuẩn để đặt luật truy cập diện rộng lên dữ liệu trong S3, áp trực tiếp lên dữ liệu chứ không gián tiếp qua danh tính người gọi.

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

A — Security Group gắn vào S3 bucket. Sai ngay ở giả định kỹ thuật: Security Group không gắn được vào S3 bucket. Security Group là bộ lọc traffic vào/ra cho các tài nguyên có giao diện mạng trong VPC như EC2 instance. S3 bucket không phải tài nguyên kiểu đó, nên không có chỗ nào để "attach" cả. Phương án này mô tả một thao tác không tồn tại.

B — IAM user policy chặn theo IP. Đây là phương án gần đúng nhất, và đó cũng là chỗ dễ mất điểm. IAM policy thật sự có khối Condition và thật sự lọc được theo IP nguồn. Chỗ nó hỏng nằm ở phạm vi áp dụng: IAM policy gắn vào danh tính (user, group, role), nên luật chỉ có hiệu lực với đúng những danh tính được gắn. Đề yêu cầu luật ở mức bucket — tức mọi request tới bucket đều phải chịu ràng buộc, bất kể ai gọi. Muốn phủ hết bằng IAM thì phải đi gắn và duy trì policy cho từng danh tính một, sót một cái là thủng. Bucket policy làm đúng một lần tại đúng chỗ đề yêu cầu.

D — NACL chặn theo dải IP. Network ACL hoạt động ở mức subnet bên trong VPC, lọc gói tin ra vào subnet đó. Nó không gắn được vào S3 bucket — S3 không nằm trong subnet của bạn. NACL cùng lắm chi phối được traffic của các instance trong subnet, chứ không phải là cơ chế kiểm soát truy cập vào tài nguyên S3 theo IP nguồn.

📌 Điểm cần nhớ

• "At the bucket level" ⇒ nghĩ ngay tới S3 bucket policy. Resource-based policy gắn lên tài nguyên, áp cho mọi người gọi; identity-based policy (IAM) gắn lên danh tính, chỉ áp cho danh tính đó. Đề nhắc phạm vi ở đâu thì chọn loại policy gắn ở đó.
• S3 không nằm trong VPC theo nghĩa thông thường. Mọi phương án dựa vào Security Group hay NACL để "bảo vệ bucket" đều loại được ngay mà không cần đọc kỹ phần còn lại — đó là những công cụ mạng cấp VPC/subnet, không gắn được vào bucket.
• Lọc theo IP nguồn trong AWS là việc của khối Condition trong policy, không phải của tầng mạng. Cùng một khoá điều kiện đó dùng được ở cả bucket policy lẫn IAM policy — khác nhau ở chỗ gắn vào đâu, chứ không phải làm được hay không.
• Khi hai phương án cùng "làm được" về mặt kỹ thuật (ở đây là B và C), hãy quay lại đọc ràng buộc trong đề về phạm vi hoặc nơi thực thi — đó gần như luôn là thứ tách hai phương án ra.

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

Đề mô tả một agency marketing muốn thu thập, phân tích và trực quan hoá dữ liệu web traffic từ nhiều website khách hàng. Câu hỏi yêu cầu chọn tổ hợp dịch vụ AWS phủ đủ bốn việc: collect → search → analyze → visualize.

Cụm từ quyết định nằm ở chính chuỗi động từ đó, cộng với hai ràng buộc phụ trong đoạn mô tả:

• "collect ... web traffic data" — dữ liệu phát sinh liên tục theo luồng từ nhiều nguồn, nên khâu thu thập phải là một đường ống streaming ingestion, không phải một đường kết nối mạng hay một CSDL quan hệ.
• "powerful search capabilities" — cụm này loại thẳng những phương án lấy data warehouse hoặc CSDL quan hệ làm lõi. Tìm kiếm toàn văn, lọc và aggregate trên log là đúng sở trường của OpenSearch Service.
• "interactive dashboard for visualization and analysis" — đây là mấu chốt phân biệt các phương án gần giống nhau, vì cả bốn phương án đều có OpenSearch, chỉ khác vai trò gán cho nó. Ba phương án sai đều bắt OpenSearch làm lớp visualization cuối cùng; chỉ một phương án đặt OpenSearch đúng chỗ (search + analysis) và dùng một dịch vụ BI riêng cho dashboard.

Nói cách khác: đề không hỏi "dịch vụ nào tốt", mà hỏi "gán đúng dịch vụ vào đúng khâu".

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

Đáp án đúng theo tệp là D — Kinesis Data Firehose (collect) + OpenSearch Service (search & analysis) + QuickSight (visualization). Mỗi mảnh khớp đúng một khâu trong đề:

• Amazon Kinesis Data Firehose là dịch vụ delivery stream được quản lý hoàn toàn: nhận dữ liệu streaming, có thể transform trên đường đi, rồi nạp thẳng vào đích như S3, Redshift hay OpenSearch Service. Với web traffic — dữ liệu đến liên tục, khối lượng lớn — đây là khâu ingestion gọn nhất, không phải quản lý cụm hay broker nào.
• Amazon OpenSearch Service đảm nhiệm search and analysis: đánh index dữ liệu traffic, cho phép tìm kiếm, lọc và aggregate ở quy mô lớn. Đúng với yêu cầu "powerful search capabilities" của đề.
• Amazon QuickSight là dịch vụ BI dựng interactive dashboard và báo cáo, phục vụ đúng nhu cầu "marketing insights" mà đề nêu.

Điểm cộng lớn nhất của tổ hợp này là Firehose có sẵn OpenSearch Service làm destination, nên đường đi từ nguồn tới nơi đánh index là một đường ống dựng bằng cấu hình chứ không phải bằng code.

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

A — Direct Connect + RDS + OpenSearch (visualization). Hỏng ngay ở khâu đầu: AWS Direct Connect là đường kết nối mạng riêng, chuyên dụng từ data center on-premises vào AWS. Nó là hạ tầng đường truyền, không phải cơ chế thu thập dữ liệu — đặt nó vào ô "data ingestion" là nhầm tầng khái niệm. Tiếp theo, Amazon RDS là CSDL quan hệ, trong khi web traffic là dữ liệu phi quan hệ, khối lượng lớn, kiểu log — nhét vào RDS thì vừa không hợp mô hình dữ liệu vừa khó mở rộng. Phương án này sai ở cả hai vị trí đầu.

B — S3 + Glue + OpenSearch (search, analysis, visualization). Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất, vì bản thân kiến trúc S3 + Glue + OpenSearch là hoàn toàn hợp lệ trong đời thực. Nó hỏng ở hai chỗ so với đề bài này: (1) thiếu hẳn khâu collect — S3 là nơi lưu trữ, Glue là ETL theo lô, không có thành phần nào nhận luồng traffic đang chảy về; (2) dồn cả visualization cho OpenSearch trong khi đề nhấn mạnh interactive dashboard, mà QuickSight mới là dịch vụ BI đúng vai. Glue thiên về xử lý theo batch, nên khi mục tiêu là phân tích và hiển thị gần thời gian thực thì nó thêm độ trễ chứ không thêm giá trị.

C — MSK + Redshift + OpenSearch (visualization). Khâu streaming về mặt kỹ thuật thì làm được, nhưng Amazon MSK là Apache Kafka được quản lý: bạn vẫn phải thiết kế topic, viết producer/consumer, vận hành ứng dụng xử lý stream. So với Firehose — vốn chỉ cần khai báo nguồn và đích — MSK phức tạp hơn mức bài toán này cần. Kế đến, Amazon Redshift là data warehouse cho phân tích SQL trên dữ liệu có cấu trúc; nó không đáp ứng yêu cầu "powerful search" theo kiểu tìm kiếm toàn văn như OpenSearch. Cuối cùng, phương án lại đặt OpenSearch vào ô visualization và không có QuickSight, nên phần dashboard vẫn không được phục vụ bằng dịch vụ đúng vai.

📌 Điểm cần nhớ

• Với câu hỏi dạng "tổ hợp dịch vụ", hãy tách đề thành các động từ (collect / search / analyze / visualize) rồi soi từng phương án xem có bỏ trống khâu nào hoặc gán nhầm vai không. Phương án sai thường thiếu đúng một khâu.
• Kinesis Data Firehose = ingestion được quản lý hoàn toàn, nạp thẳng vào S3, Redshift, OpenSearch Service. Thấy "thu thập dữ liệu streaming mà không muốn quản lý hạ tầng" thì nghĩ tới Firehose trước; MSK chỉ nên chọn khi đề nêu rõ yêu cầu về Kafka hoặc cần xử lý stream phức tạp.
• OpenSearch Service = search + analysis trên dữ liệu kiểu log; QuickSight = BI dashboard. Khi đề nhấn "interactive dashboard" mà phương án lại bắt OpenSearch gánh luôn phần trực quan hoá, đó là dấu hiệu phương án sai.
• Phân biệt dịch vụ hạ tầng mạng và dịch vụ dữ liệu: Direct Connect nối on-premises vào AWS, nó không "collect data". Tương tự, RDS/Redshift dành cho dữ liệu quan hệ có cấu trúc, không phải lựa chọn mặc định cho log traffic khối lượng lớn.

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

Đề mô tả một công ty cần phân tích dữ liệu streaming khối lượng lớn để lấy insight theo thời gian thực, với yêu cầu cụ thể là gộp (aggregate) dữ liệu trong khung thời gian 30 phút. Câu hỏi chốt lại: dịch vụ AWS nào phù hợp nhất để làm real-time analytics với ít công sức vận hành nhất.

Có ba cụm từ quyết định, và phải thoả cả ba mới đúng:

1. "aggregate data within a 30-minute time frame" — đây là bài toán windowed aggregation (gộp theo cửa sổ thời gian). Không phải mọi dịch vụ streaming đều có sẵn khái niệm cửa sổ thời gian; đây là ràng buộc lọc mạnh nhất.
2. "real-time insights" — kết quả phải ra ngay khi dữ liệu chảy qua, không phải chạy job rồi đọc kết quả sau.
3. "least operational effort" / "minimizes the need for management and maintenance" — loại thẳng mọi phương án đòi tự dựng và tự nuôi hạ tầng.

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

Đáp án A: Amazon Managed Service for Apache Flink (tên cũ: Amazon Kinesis Data Analytics) với SQL application để thực hiện windowed aggregation.

Đây là dịch vụ được thiết kế đúng cho việc phân tích phức tạp trên dữ liệu streaming bằng SQL chuẩn và Apache Flink. Ba lý do khớp trực tiếp với ba ràng buộc trong đề:

• Nó có sẵn built-in function cho các phép toán windowing theo thời gian — tức là cửa sổ 30 phút mà đề yêu cầu diễn đạt được ngay bằng ngôn ngữ của dịch vụ, không phải tự viết logic gom nhóm.
• Nó chạy liên tục trên luồng dữ liệu, đúng nghĩa real-time analytics chứ không phải xử lý theo mẻ.
• Là managed service: AWS lo hạ tầng bên dưới, tự co giãn tài nguyên, và có khả năng chịu lỗi (fault-tolerant) cao sẵn trong dịch vụ. Đây chính là vế "least operational effort".

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

B — Kinesis Data Streams + Kinesis Data Firehose transformation để gộp dữ liệu trước khi lưu. Đây là phương án gần đúng nhất về mặt "managed", vì Firehose đúng là dịch vụ ít vận hành. Nhưng nó hỏng ở chỗ chức năng: Firehose sinh ra để nạp dữ liệu streaming vào các kho lưu trữ của AWS, không phải để làm analytics. Phần transformation của nó là biến đổi bản ghi trên đường đi, không hỗ trợ sẵn các phép gộp phức tạp theo cửa sổ thời gian như yêu cầu 30 phút của đề. Chú ý cả cách diễn đạt của phương án: "aggregate data before storing it for analysis" — tức là phân tích diễn ra sau khi lưu, đã lệch khỏi "real-time insights" rồi.

C — AWS Glue streaming ETL job đọc từ Kinesis Data Streams và gộp dữ liệu real-time. Glue là managed ETL service và đúng là có thể xử lý dữ liệu streaming, nên nghe rất hợp lý. Nhưng use case chính của Glue không phải real-time analytics — nó thiên về ETL theo mẻ và tích hợp dữ liệu. So với dịch vụ chuyên cho streaming analytics, Glue không mang lại cùng mức độ chịu lỗi và cùng sự đơn giản khi làm windowed aggregation real-time. Chọn Glue ở đây là dùng công cụ tích hợp dữ liệu để giải bài toán phân tích luồng.

D — EC2 fleet có auto-scaling, tự host một aggregation service đọc từ Kinesis Data Streams. Về kỹ thuật thì cách này làm được — bạn tự viết logic cửa sổ 30 phút thì nó chạy. Nhưng nó vi phạm thẳng ràng buộc quan trọng nhất của đề: tự dựng EC2 fleet nghĩa là tự lo cài đặt, bảo trì, vá lỗi, và điều chỉnh scaling cho đám máy chủ đó. Đó là khối lượng vận hành lớn, đối nghịch hoàn toàn với "minimizes the need for management and maintenance". Trong bài thi, phương án tự quản EC2 gần như luôn sai khi đề nhấn "least operational effort".

📌 Điểm cần nhớ

• Thấy "windowed aggregation", "tumbling/sliding window", hay bất kỳ cụm "gộp dữ liệu trong khoảng N phút" trên luồng dữ liệu → nghĩ ngay tới Amazon Managed Service for Apache Flink (tên cũ Kinesis Data Analytics). Đây là dịch vụ duy nhất trong nhóm Kinesis có sẵn khái niệm cửa sổ thời gian.
• Phân biệt vai trò trong họ Kinesis: Data Streams = đường ống nhận và giữ dữ liệu; Data Firehose = nạp dữ liệu vào kho lưu trữ (S3, Redshift, OpenSearch…), biến đổi nhẹ; Managed Service for Apache Flink = phân tích và tính toán trên luồng. Đề hỏi phân tích thì đừng chọn dịch vụ vận chuyển.
• AWS Glue là ETL và data integration. Nó có chế độ streaming, nhưng khi đề đối đầu trực tiếp Glue với một dịch vụ streaming analytics chuyên dụng cho bài toán real-time, Glue là phương án gần đúng chứ không phải phương án đúng.
• Cụm "least operational effort" là bộ lọc đầu tiên nên áp: nó loại ngay mọi phương án tự host trên EC2, kể cả khi phương án đó có kèm auto-scaling nghe rất "tự động". Auto-scaling giảm việc chỉnh dung lượng, không xoá được việc quản lý máy chủ.

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

Một công ty game mobile có tải tăng vọt đều đặn vào tối thứ Sáu, còn những ngày khác thì thấp hơn nhiều. Dữ liệu người chơi nằm trong một bảng Amazon DynamoDB đang chạy ở provisioned capacity mode. Yêu cầu: giữ chi phí thấp nhưng server vẫn phản hồi tốt lúc cao điểm.

Cụm từ quyết định đáp án là "predictable spikes" (tải tăng có thể đoán trước) kết hợp với "keeps costs low". Hai vế này khoá chặt lựa chọn:

• "Predictable" loại bỏ hướng đi dành cho tải không đoán trước được.
• "Costs low" loại bỏ hướng để capacity đứng yên ở mức đỉnh cả tuần.
• Và vì đề nói rõ bảng đang ở provisioned mode, câu hỏi thực chất là: làm sao để provisioned capacity tự lên xuống theo chu kỳ đã biết?

Đó chính xác là việc của DynamoDB auto scaling.

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

A — Implement DynamoDB auto-scaling để tự điều chỉnh provisioned capacity theo usage pattern.

DynamoDB auto scaling dựa trên AWS Application Auto Scaling: bạn đặt khoảng min–max cho read/write capacity units và một mức target utilization, rồi dịch vụ tự tăng provisioned throughput khi lượng tiêu thụ vượt ngưỡng, và tự hạ xuống khi tải giảm.

Áp vào bài toán này:

• Tối thứ Sáu tải lên, auto scaling nâng capacity để bảng không bị throttle → game server vẫn phản hồi.
• Hết cao điểm, capacity tự hạ về mức thấp → không phải trả tiền cho throughput không dùng tới.
• Toàn bộ diễn ra không cần ai can thiệp, nên không lệ thuộc vào việc có người trực hay không.

Ngoài ra, với chu kỳ đã biết trước như "tối thứ Sáu", Application Auto Scaling còn cho phép đặt scheduled scaling — nâng min capacity trước giờ cao điểm — nên capacity đã sẵn sàng ngay từ đầu đợt tăng tải thay vì phải đợi phản ứng theo metric. Đây vẫn nằm trong cùng một cơ chế mà phương án A mô tả.

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

B — Tách dữ liệu người chơi ra nhiều bảng DynamoDB để phân tán tải, chỉnh provisioned capacity cho từng bảng.

Sai ở chỗ chẩn đoán nhầm vấn đề. Vấn đề ở đây là tổng throughput theo thời gian, không phải một bảng đơn lẻ chạm trần. Tách bảng khiến bạn phải quản lý capacity cho nhiều bảng thay vì một, ứng dụng phải biết dữ liệu người chơi nằm ở bảng nào, và các truy vấn cần dữ liệu chéo bảng trở nên phức tạp. Chi phí không giảm — tổng capacity phải mua vẫn thế, chỉ chia nhỏ ra. Đây là công sức tăng lên mà không giải quyết được gì.

C — Chỉnh tay provisioned capacity mỗi thứ Sáu rồi hạ xuống sau khi hết cao điểm.

Đây là phương án gần đúng nhất và đáng phân tích kỹ: về mặt kết quả, nó đúng hướng — nâng lúc cần, hạ lúc không cần. Chỗ hỏng nằm ở chữ "manually". Nó biến một việc lặp lại hằng tuần thành thao tác thủ công phụ thuộc con người: quên một tuần là bảng bị throttle đúng lúc đông người chơi nhất; hạ trễ thì trả tiền thừa. Auto scaling làm đúng việc đó nhưng tự động và bám theo lưu lượng thật. Trong đề thi AWS, khi một phương án thủ công và một phương án tự động cùng cho ra kết quả giống nhau, phương án tự động luôn là đáp án.

D — Chuyển sang on-demand capacity mode để bảng tự co giãn theo tải.

Cũng gần đúng, và cũng đáng phân tích kỹ. On-demand đúng là tự co giãn và không cần quản lý capacity. Nhưng on-demand được thiết kế cho workload không đoán trước được hoặc mới ra mắt chưa biết hình dạng tải — bạn trả tiền theo từng request, đổi lấy sự linh hoạt. Đề bài lại nói thẳng tải ở đây là predictable. Với một chu kỳ đã biết rõ, provisioned capacity kèm auto scaling thường rẻ hơn on-demand vì bạn cam kết trước mức throughput và không phải trả phần phụ trội cho tính linh hoạt mình không cần. Chữ "predictable" trong đề chính là thứ loại D ra.

📌 Điểm cần nhớ

• "Predictable traffic" → provisioned capacity + auto scaling. "Unpredictable/spiky/mới ra mắt" → on-demand. Đây là cặp phân biệt xuất hiện rất nhiều trong đề DynamoDB; đọc thấy chữ nào thì chọn vế tương ứng.
• Thủ công thua tự động khi cả hai cho cùng kết quả. Phương án có chữ "manually adjust", "each Friday", "an engineer will…" gần như luôn là mồi nhử.
• Auto scaling có hai kiểu bổ trợ nhau: target tracking (phản ứng theo utilization) và scheduled scaling (nâng min capacity trước giờ cao điểm đã biết). Với chu kỳ cố định, kiểu thứ hai giúp capacity sẵn sàng ngay từ đầu đợt tăng tải.
• Tách bảng không phải cách giải bài toán chi phí throughput. Sharding chỉ hợp lý khi vấn đề là hot partition hoặc giới hạn kích thước item/bảng — không phải khi tải chỉ đơn giản là lên xuống theo giờ.

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

Đề mô tả một data lake trên Amazon S3 dùng partition theo kiểu Hive (year=2023/month=01/day=01), và yêu cầu AWS Glue Data Catalog phải đồng bộ với S3 mỗi khi có partition mới được thêm vào bucket.

Cụm từ quyết định nằm ở câu cuối: "with the LEAST latency" — độ trễ thấp nhất. Cả bốn phương án đều có thể đăng ký partition mới vào Data Catalog; chúng chỉ khác nhau ở chỗ mất bao lâu kể từ lúc dữ liệu rơi xuống S3 cho tới lúc catalog biết. Cụm từ thứ hai đáng chú ý là "when the company adds new partitions" — sự kiện kích hoạt là hành động ghi dữ liệu, chứ không phải một mốc thời gian trong ngày. Hễ trong đề thi thấy "least latency" đi kèm một sự kiện ghi dữ liệu, hãy tìm phương án gắn việc cập nhật catalog vào chính lúc ghi, thay vì chạy theo lịch hay chạy tay.

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

C. Use code that writes data to Amazon S3 to invoke the Boto3 AWS Glue create_partition API call.

Đây là phương án duy nhất event-driven: chính đoạn code đang ghi dữ liệu lên S3 sẽ gọi luôn create_partition của Glue ngay sau đó. Partition xuất hiện trong Data Catalog gần như cùng lúc với dữ liệu, nên độ trễ về cơ bản bằng thời gian của một lời gọi API — không có khoảng chờ nào giữa "dữ liệu đã có" và "catalog biết".

Ngoài chuyện độ trễ, cách này còn chính xác và rẻ hơn: code ghi dữ liệu vốn đã biết chính xác giá trị year, month, day và đường dẫn S3 của partition vừa tạo, nên nó đăng ký thẳng đúng một partition đó. Không có bước nào phải đi quét bucket để đoán ra partition mới, tức là không tốn công liệt kê object và không phụ thuộc vào kích thước của data lake.

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

A. Manually run the AWS Glue CreatePartition API twice each day. Đúng API, sai cách vận hành. Gọi tay hai lần mỗi ngày nghĩa là partition mới có thể nằm chờ đến gần nửa ngày mới vào catalog — trái thẳng với yêu cầu "least latency". Chưa kể phần "manually": người vận hành phải tự biết những partition nào vừa sinh ra để khai báo, việc này không mở rộng được và rất dễ sót.

B. Run the MSCK REPAIR TABLE command from the AWS Glue console. Lệnh này quả thực quét S3 và nạp các partition thiếu vào Data Catalog, nên về mặt kết quả thì đạt. Nhưng nó hỏng ở hai chỗ: (1) nó là thao tác thủ công, phải có ai đó bấm chạy sau khi dữ liệu đã tới, nên độ trễ phụ thuộc vào con người; (2) nó quét toàn bộ prefix để tìm partition chưa đăng ký, càng nhiều partition thì càng chậm và càng tốn — data lake phân vùng theo ngày sẽ phình ra rất nhanh.

D. Schedule an AWS Glue crawler to run every morning. Đây là phương án gần đúng nhất và cũng là bẫy hay gặp: crawler tự động phát hiện partition mới, nghe rất hợp với chữ "synchronizes". Nhưng nó chạy theo lịch, ở đây là mỗi sáng — partition tạo lúc 9 giờ sáng sẽ phải đợi tới hôm sau mới vào catalog. Rút ngắn lịch chạy cũng không cứu được: crawler vẫn phải quét S3 mỗi lượt, nên chạy càng dày thì chi phí và tải càng tăng, mà độ trễ vẫn không thể bằng cách gọi API ngay lúc ghi.

📌 Điểm cần nhớ

• "LEAST latency" ⇒ ưu tiên event-driven, đừng chọn scheduled. Bất cứ phương án nào có chữ "every morning", "twice each day", "nightly" đều đã tự khai độ trễ của nó.
• "Manually" gần như luôn là đáp án sai trong câu hỏi về đồng bộ hoá tự động, kể cả khi lệnh/API được nêu là đúng lệnh.
• Glue crawler và MSCK REPAIR TABLE đều thuộc nhóm "quét để tìm ra partition", còn create_partition (Boto3 / Glue API) thuộc nhóm "khai báo thẳng partition đã biết". Nhóm sau nhanh hơn và không phụ thuộc kích thước bucket.
• Khi code ghi dữ liệu vốn đã biết giá trị partition, hãy để chính nó cập nhật Data Catalog — vừa giảm độ trễ, vừa bỏ được toàn bộ chi phí quét S3.

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

Đề mô tả một data engineer muốn tăng tốc truy vấn Amazon Athena. Dữ liệu hiện nằm trên S3 ở dạng .csv không nén, và điểm mấu chốt nằm ở cụm từ: "The queries primarily filter on one column" — các truy vấn chủ yếu lọc theo một cột.

Cụm từ thứ hai quyết định không kém: "most effectively" — đề không hỏi "cách nào có tác dụng", mà hỏi cách nào hiệu quả nhất. Nhiều phương án trong danh sách đều giúp ích ở mức nào đó; chỉ có một phương án đánh trúng cả hai đặc điểm của bài toán cùng lúc: truy vấn theo cột, và dữ liệu chưa được nén.

Athena tính chi phí và thời gian theo lượng dữ liệu quét từ S3. Nên câu hỏi thực chất là: cách nào giảm số byte phải đọc nhiều nhất cho một truy vấn chỉ đụng tới vài cột?

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

B — chuyển .csv sang định dạng cột Apache Parquet kèm nén Snappy.

Parquet là định dạng lưu trữ theo cột (columnar), được thiết kế cho tải công việc phân tích. Với .csv, dữ liệu xếp theo dòng, nên muốn đọc một cột thì engine vẫn phải quét qua toàn bộ dòng — nghĩa là đọc mọi cột dù không cần. Với Parquet, các giá trị của cùng một cột nằm liền nhau, nên Athena chỉ đọc đúng những cột mà truy vấn tham chiếu. Với một truy vấn "chủ yếu lọc trên một cột" như đề mô tả, đây chính là kiểu tối ưu mà định dạng này sinh ra để phục vụ.

Snappy bổ sung tầng thứ hai: nén làm file nhỏ lại nên số byte đọc từ S3 giảm tiếp, trong khi thuật toán này giải nén nhanh và tốn ít CPU, lại được Athena hỗ trợ trực tiếp. Chọn Snappy thay vì một thuật toán nén mạnh nhưng chậm là để phần tiết kiệm I/O không bị ăn ngược lại bởi chi phí giải nén.

Cộng lại: đọc ít cột hơn và mỗi cột chiếm ít byte hơn. Đó là lý do B vượt các phương án còn lại về mức độ hiệu quả.

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

A — Partition file .csv theo cột hay được truy vấn.

Đây là phương án gần đúng nhất và đáng phân tích kỹ. Partitioning thật sự có ích: nó cho phép Athena bỏ qua hẳn những thư mục không khớp điều kiện lọc. Nhưng nó hỏng ở chỗ dữ liệu vẫn là .csv không nén, vẫn theo dòng — trong mỗi partition được đọc, Athena vẫn phải quét toàn bộ mọi cột của mọi dòng. Ngoài ra partition chỉ phát huy khi cột đó có số giá trị phân biệt vừa phải; partition theo một cột có độ phân tán cao sẽ đẻ ra rất nhiều file nhỏ và làm hại hiệu năng. So với B, nó giải quyết được một nửa vấn đề mà bỏ qua cả định dạng lẫn nén.

C — Chuyển sang XML và nén GZIP.

Phần nén GZIP có giúp giảm dung lượng, nhưng phần đổi định dạng thì đi lùi. XML vẫn là định dạng theo dòng, lại còn kèm rất nhiều thẻ đánh dấu nên bản thân dữ liệu phình ra so với .csv, và việc phân tích cú pháp nặng hơn. Không có bất kỳ lợi ích "đọc riêng một cột" nào ở đây. Đổi .csv sang XML để tăng tốc truy vấn phân tích là chọn sai hướng ngay từ đầu.

D — Bật Amazon S3 Select trên các file .csv.

S3 Select cho phép đẩy phép lọc xuống tầng S3 để trả về ít dữ liệu hơn, nên về nguyên tắc có giảm lượng dữ liệu truyền. Nhưng nó vẫn làm việc trên file .csv theo dòng: S3 vẫn phải đọc và phân tích cú pháp toàn bộ đối tượng để lọc ra phần cần. Nó xử lý triệu chứng ở tầng truyền dữ liệu chứ không sửa gốc rễ là cách dữ liệu được bố trí trên đĩa. Vì thế mức cải thiện không bằng việc chuyển sang định dạng cột.

📌 Điểm cần nhớ

• Athena tính theo lượng dữ liệu quét; mọi tối ưu hiệu năng cho Athena đều quy về câu hỏi "làm sao đọc ít byte hơn".
• Truy vấn lọc/chiếu theo một vài cột → tín hiệu kinh điển cho định dạng cột (Parquet, ORC). Định dạng theo dòng (.csv, JSON, XML) buộc phải đọc cả dòng.
• Snappy là lựa chọn nén mặc định hợp lý khi ưu tiên tốc độ giải nén; nén mạnh mà chậm có thể triệt tiêu phần lợi từ việc đọc ít byte.
• Partitioning và định dạng cột không thay thế nhau, chúng bổ sung cho nhau. Khi đề bắt chọn một, hãy xem ràng buộc nào được nêu: lọc theo cột → định dạng cột; lọc theo một khoá phân vùng rõ ràng như ngày/vùng → partitioning.
• Đổi định dạng lưu trữ sửa gốc rễ vấn đề; các cơ chế lọc ở tầng truy xuất như S3 Select chỉ giảm phần dữ liệu trả về chứ không đổi cách dữ liệu nằm trên đĩa.

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

Đề mô tả một công ty phân tích tài chính lưu file CSV lớn chứa dữ liệu giao dịch trong một Amazon S3 bucket, và muốn các data engineer chạy được SQL query trực tiếp trên chính những file CSV đó.

Cụm từ quyết định đáp án nằm ở vế cuối: "without the need for additional data transformation or loading into a database" — không được biến đổi thêm, không được nạp vào cơ sở dữ liệu. Cộng thêm chữ "directly on these CSV files stored in S3", ràng buộc trở thành: dữ liệu phải nằm yên tại chỗ trong S3, và lớp truy vấn phải đọc thẳng từ đó.

Ràng buộc này rất quan trọng vì cả bốn phương án đều có thể cho ra kết quả SQL trên dữ liệu CSV. Chúng khác nhau ở chỗ phải dựng thêm bao nhiêu hạ tầng và có phải di chuyển dữ liệu hay không. Đây là kiểu câu hỏi chọn giải pháp đơn giản nhất thoả yêu cầu, chứ không phải chọn giải pháp mạnh nhất.

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

A — Amazon Athena. Athena là dịch vụ truy vấn tương tác, cho phép phân tích dữ liệu nằm sẵn trong S3 bằng SQL chuẩn. Nó khớp từng chữ với yêu cầu của đề:

• Serverless — không có cluster hay node nào để tạo, chỉnh kích thước hay tắt bật. Data engineer chỉ cần khai báo bảng trỏ vào đường dẫn S3 rồi gõ SQL.
• Đọc trực tiếp định dạng CSV (cùng nhiều định dạng khác) ngay tại vị trí file trong S3 — không cần bước ETL, không cần copy dữ liệu sang nơi khác. Đúng với "no additional data transformation or loading".
• Vì không phải nuôi hạ tầng chạy thường trực, chi phí vận hành cho tình huống truy vấn theo nhu cầu như thế này là thấp nhất trong bốn phương án.

Nói gọn: đề hỏi "chạy SQL thẳng trên file trong S3, không dựng thêm gì" — đó chính là mô tả bài toán mà Athena sinh ra để giải.

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

B — Amazon Redshift Spectrum. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Spectrum thật sự query được dữ liệu ngoài nằm trong S3, dữ liệu vẫn ở nguyên chỗ. Chỗ nó hỏng là: Spectrum là một tính năng của Redshift, nên bạn vẫn phải có và quản lý một Redshift cluster làm điểm vào để chạy query. So với yêu cầu "chỉ muốn gõ SQL lên mấy file CSV", việc dựng và duy trì cả một data warehouse là phức tạp và tốn kém hơn mức cần thiết. Spectrum hợp lý khi bạn đã dùng Redshift và muốn nối dữ liệu trong warehouse với dữ liệu lịch sử trong S3 — đề này không có bối cảnh đó.

C — Amazon EMR với Hive metastore. Cũng query được CSV trong S3, nhưng cái giá là bạn phải dựng cluster EMR, cấu hình Hive metastore, chọn loại instance, lo chuyện chạy/tắt cluster. Đó là hạ tầng cần quản lý và điều chỉnh — đi ngược tinh thần "không cần thêm gì cả" của đề. EMR xứng đáng khi cần xử lý dữ liệu lớn tuỳ biến bằng Spark/Hive, chứ không phải để chạy vài câu SQL khám phá dữ liệu.

D — AWS Data Pipeline chuyển CSV từ S3 sang Amazon RDS. Đây là phương án sai rõ ràng nhất vì nó vi phạm trực diện ràng buộc trong đề: nó chính là bước "loading into a database" mà đề nói là không cần. Ngoài ra nó còn thêm một lớp orchestration để di chuyển dữ liệu, sinh ra bản sao thứ hai phải đồng bộ, và khiến dữ liệu mới đổ vào S3 không truy vấn được cho tới khi pipeline chạy lại.

📌 Điểm cần nhớ

• Thấy đề ghép "SQL" + "dữ liệu nằm trong S3" + "không cần ETL / không cần dựng hạ tầng" → nghĩ ngay tới Athena. Đây gần như là chữ ký nhận dạng của dịch vụ này trong đề thi.
• Athena và Redshift Spectrum đều query dữ liệu ngoài trong S3. Phân biệt bằng câu hỏi: đề có sẵn/có muốn một Redshift cluster không? Không có → Athena. Có, và cần nối dữ liệu warehouse với dữ liệu S3 → Spectrum.
• EMR là phương án "có hạ tầng để quản lý". Khi đề nhấn mạnh giảm chi phí vận hành hoặc "serverless", EMR gần như luôn bị loại, dù về mặt kỹ thuật nó làm được.
• Phương án nào di chuyển dữ liệu sang một database khác (như D) sẽ tự loại mình ngay khi đề nói "query in place" hoặc "no data loading" — đọc kỹ vế phủ định trong đề trước khi so sánh các dịch vụ.

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

Đề mô tả một công ty lưu tài liệu nhạy cảm trong một S3 bucket ở region US East (N. Virginia), và vì chính sách dự phòng dữ liệu (data redundancy) nên cần một bản sao lưu ở bucket thuộc region EU (Frankfurt).

Cụm từ quyết định đáp án là: "automatically replicated to the second bucket in a different region" — tức là tự động sao chép object sang bucket khác region. Ba yếu tố nằm trong cụm này:

• replicated — nhân bản object, chứ không phải chuyển storage class hay giữ nhiều phiên bản của cùng một object
• automatically — S3 tự làm khi object được ghi, không cần script hay thao tác tay
• different region — phạm vi là liên region, không phải trong cùng một region

Đề đang hỏi thẳng "which Amazon S3 feature", nghĩa là câu trả lời phải là một tính năng có sẵn của S3, đúng tên gọi. Ai bám đủ ba yếu tố trên thì chỉ còn đúng một phương án khớp cả ba.

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

Đáp án đúng là C — S3 Cross-Region Replication (CRR).

CRR là tính năng của S3 được sinh ra đúng cho tình huống này: sao chép object từ một bucket nguồn sang một bucket đích nằm ở AWS region khác, một cách tự động. Sau khi bật replication rule, mỗi object ghi vào bucket ở N. Virginia sẽ được S3 tự nhân bản sang bucket ở Frankfurt mà không cần công ty viết thêm bất kỳ tiến trình đồng bộ nào.

Điều này thoả mãn yêu cầu data redundancy trong đề: tài liệu nhạy cảm có một bản nằm ở region hoàn toàn khác, nên sự cố phạm vi region ở N. Virginia không làm mất dữ liệu. Đây cũng là cách cấu hình đơn giản — khai báo ở mức bucket, không phải xây dựng hệ thống sao lưu riêng.

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

A — S3 Lifecycle Policies. Lifecycle policy quản lý vòng đời của object trong bucket: chuyển object sang storage class khác sau một khoảng thời gian, hoặc xoá object khi hết hạn. Nó đúng ở chỗ "tự động" nên dễ gây nhầm, nhưng nó không tạo thêm một bản sao ở bucket khác — nó chỉ tác động lên chính object đang có. Không có cơ chế nhân bản liên region trong lifecycle policy, nên yêu cầu cốt lõi của đề không được đáp ứng.

B — S3 Versioning. Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. Versioning giữ lại mọi phiên bản của một object trong cùng bucket, giúp khôi phục khi người dùng ghi đè hay xoá nhầm. Nó cũng mang màu sắc "bảo vệ dữ liệu", nên dễ bị chọn. Vấn đề: mọi phiên bản vẫn nằm trong đúng một bucket ở đúng một region — không hề có bản sao ở Frankfurt. Thêm nữa, versioning là điều kiện đi kèm của replication chứ không thay thế được replication: bật versioning thôi thì dữ liệu vẫn chỉ tồn tại ở N. Virginia.

D — S3 Transfer Acceleration. Tính năng này dùng edge location của CloudFront để tăng tốc việc upload/download với bucket S3 khi client ở xa bucket về mặt địa lý. Nó liên quan tới khoảng cách địa lý nên nghe có vẻ "liên region", nhưng bản chất chỉ là tối ưu đường truyền cho request của client. Nó không tự sinh ra bản sao nào, không có bucket đích, và hoàn toàn không phải cơ chế replication.

📌 Điểm cần nhớ

• Trong đề S3, cứ thấy "replicate to another region" / "cross-region backup" tự động thì đó là Cross-Region Replication (CRR) — đây là tính năng duy nhất trong nhóm này tạo ra bản sao ở bucket đích thuộc region khác.
• Phân biệt bốn tính năng theo việc chúng làm, đừng theo cảm giác: Lifecycle = đổi storage class / xoá theo thời gian; Versioning = nhiều phiên bản trong cùng bucket; CRR = nhân bản sang bucket khác region; Transfer Acceleration = tăng tốc đường truyền, không tạo bản sao.
• Versioning là điều kiện đi kèm của replication, không phải phương án thay thế. Câu hỏi hỏi "làm sao có bản sao ở region khác" thì versioning luôn sai; câu hỏi hỏi "cần bật gì trước khi cấu hình replication" thì versioning mới đúng.
• Đọc kỹ phạm vi trong đề: cùng bucket / cùng region / khác region là ba mức khác nhau, và mỗi mức tương ứng một tính năng khác nhau. Bỏ qua chi tiết region trong đề là mất luôn cơ sở loại phương án.

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

Đề mô tả một bảng products trong Amazon RDS for PostgreSQL với bốn cột id, name, price, quantity_in_stock, rồi hỏi câu SQL nào lấy đúng dữ liệu: sản phẩm có price lớn hơn 50 và quantity_in_stock nhỏ hơn 100.

Cụm từ quyết định không nằm ở phần AWS mà nằm ở chính yêu cầu: "write an SQL query" và "price greater than $50 and quantity in stock less than 100". Đây là câu kiểm tra cú pháp SQL chuẩn, không phải câu kiểm tra kiến thức về RDS — RDS for PostgreSQL chỉ là bối cảnh cho biết engine chạy SQL chuẩn ANSI. Bốn phương án khác nhau ở đúng ba chỗ: động từ truy vấn, từ khoá mở đầu mệnh đề lọc, và cách viết toán tử so sánh / toán tử logic. Chỉ cần một trong ba chỗ đó sai là câu lệnh không phân tích cú pháp được.

Chú ý thêm một cái bẫy nhỏ: dấu $ trong đề ($50) là ký hiệu tiền tệ của văn xuôi tiếng Anh, không phải một phần của giá trị cần so sánh. Cột price là cột số, nên trong SQL phải viết số trần.

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

B — SELECT * FROM products WHERE price > 50 AND quantity_in_stock < 100;

Đây là dạng chuẩn của một câu truy vấn SQL và chạy được trên PostgreSQL:

• SELECT * — động từ lấy dữ liệu trong SQL là SELECT; * lấy toàn bộ cột, khớp với yêu cầu "find all products" mà đề không giới hạn cột nào.
• FROM products — chỉ đúng bảng nguồn.
• WHERE — mệnh đề lọc dòng theo điều kiện.
• price > 50 — so sánh số bằng toán tử >, giá trị viết trần không kèm ký hiệu tiền tệ.
• AND — toán tử logic của SQL, buộc cả hai điều kiện cùng đúng, khớp với chữ "and" trong đề.
• quantity_in_stock < 100 — vế còn lại, dùng < cho "less than".

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

A — GET * FROM products WHEN price > 50 & quantity_in_stock < 100; Sai ba chỗ cùng lúc. GET không phải từ khoá SQL (đúng ra là SELECT); WHEN chỉ dùng bên trong biểu thức CASE, không phải mệnh đề lọc của SELECT — chỗ đó phải là WHERE; và & không phải toán tử logic AND trong SQL (trong PostgreSQL & là toán tử bitwise trên số nguyên, hoàn toàn khác ý nghĩa cần dùng). Câu này sai từ từ đầu tiên.

C — SELECT * FROM products WHERE price > $50 AND quantity_in_stock < 100; Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi: khung SELECT ... FROM ... WHERE ... AND ... hoàn toàn chuẩn, hai toán tử > và < cũng đúng. Chỗ duy nhất hỏng là $50. Giá trị số trong SQL không được gắn ký hiệu tiền tệ — $ chỉ là cách viết trong câu văn tiếng Anh của đề. Trong PostgreSQL, $ còn mang nghĩa riêng (tham số dạng $1, $2, hay dấu trích dẫn dollar-quoting $$), nên $50 ở vị trí này không cho ra số 50 mà làm câu lệnh hỏng. Bài học: cùng một điều kiện nghiệp vụ, chỉ một ký tự thừa cũng đủ loại phương án.

D — FIND * IN products WHERE price IS GREATER THAN 50 AND quantity_in_stock IS LESS THAN 100; Đúng tinh thần nhưng sai toàn bộ cú pháp: FIND không phải từ khoá SQL, bảng nguồn khai bằng FROM chứ không phải IN, và IS GREATER THAN / IS LESS THAN là tiếng Anh đời thường chứ không phải toán tử — SQL dùng ký hiệu > và <. Điểm duy nhất đúng là WHERE và AND. Phương án này viết theo kiểu "đọc lên nghe hợp lý", đúng dạng mồi nhử hay gặp ở câu hỏi cú pháp.

📌 Điểm cần nhớ

• Câu hỏi SQL trong đề chứng chỉ AWS thường không kiểm tra dịch vụ (RDS, Redshift, Athena) mà kiểm tra cú pháp chuẩn; engine chỉ là bối cảnh. Cứ soi bốn từ khoá xương sống: SELECT – FROM – WHERE – AND/OR.
• Giá trị số trong SQL viết trần: không ký hiệu tiền tệ, không dấu phân cách hàng nghìn. Ký hiệu $ trong đề bài là văn xuôi, không phải cú pháp — và trong PostgreSQL $ còn có nghĩa riêng (tham số $1, dollar-quoting).
• Toán tử logic là từ khoá AND / OR / NOT, không phải & hay |; so sánh là ký hiệu > < >= <= = <>, không phải cụm chữ như IS GREATER THAN.
• Khi hai phương án chỉ khác nhau một ký tự, đó chính là điểm chấm: loại theo lỗi cú pháp nhỏ nhất chứ đừng đọc lướt phần khung câu lệnh giống nhau.