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

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

Một doanh nghiệp toàn cầu chạy production trên Amazon RDS. CISO yêu cầu một giải pháp cho phép phân tích bảo mật và audit hoạt động, biết được ai đã làm gì, và — đây mới là chỗ quyết định — giải pháp còn phải theo dõi được cả các lời gọi API tới dịch vụ Amazon RDS, kể cả khi chúng không trực tiếp thay đổi dữ liệu trong database.

Cụm từ chốt hạ là: "track API calls made to the Amazon RDS service, even if they do not directly modify the database".

Cụm này kéo bài toán ra khỏi tầng database engine (metric hệ điều hành, câu SQL, wait event) và đẩy sang tầng control plane của AWS — tức những thao tác gọi vào chính dịch vụ RDS như DescribeDBInstances, CreateDBSnapshot, ModifyDBInstance. Những lời gọi kiểu Describe* chỉ đọc, không đụng gì tới dữ liệu bên trong DB, nên bất kỳ công cụ nào chỉ nhìn vào bên trong instance đều không thấy chúng. Thêm vào đó, yêu cầu "which user performed which action" đòi danh tính người gọi (IAM identity) đi kèm từng hành động, chứ không phải số liệu tổng hợp.

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

Đáp án đúng theo tệp là D — Activate AWS CloudTrail.

CloudTrail ghi lại lịch sử hoạt động của tài khoản AWS: các hành động thực hiện qua AWS Management Console, AWS SDK, command line tools và qua các dịch vụ AWS khác. Mỗi bản ghi sự kiện gắn kèm danh tính đã gọi, hành động nào được gọi, vào lúc nào và từ đâu — đúng khớp với yêu cầu "ai đã làm gì".

Quan trọng hơn, CloudTrail hoạt động ở tầng API của tài khoản, nên nó bắt được cả những lời gọi chỉ đọc tới dịch vụ Amazon RDS — chính là vế "even if they do not directly modify the database" trong đề. Đây là dịch vụ được thiết kế cho governance, compliance, operational auditing và risk auditing, tức đúng bài toán mà CISO đặt ra, và nó lưu giữ lại lịch sử đó để phục vụ phân tích bảo mật về sau.

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

A — Amazon RDS Enhanced Monitoring. Đây là công cụ giám sát hệ điều hành mà RDS instance đang chạy trên đó, cung cấp metric thời gian thực (CPU, tiến trình, I/O ở mức OS). Nó nói cho bạn biết máy đang khoẻ hay yếu, chứ không theo dõi hoạt động của người dùng và không ghi lại API call nào. Vế "which user performed which action" hoàn toàn nằm ngoài khả năng của nó.

B — Amazon RDS Performance Insights. Đây là phương án dễ mắc bẫy nhất, vì nó có lọc dữ liệu theo user và host, nghe rất giống "ai làm gì". Nhưng bản chất Performance Insights là công cụ tinh chỉnh hiệu năng: nó đo tải database và bổ nó ra theo câu SQL, wait event, user, host để tìm nguyên nhân chậm. Đó là dữ liệu hiệu năng, không phải bản ghi audit — nó không cho bạn dấu vết audit của hành động người dùng, và tuyệt đối không thấy các lời gọi API tới dịch vụ RDS. Trượt đúng ràng buộc phân biệt của đề.

C — AWS Config. Config ghi nhận và đánh giá cấu hình của tài nguyên AWS, theo dõi thay đổi cấu hình theo thời gian và kiểm tra chúng có tuân thủ rule hay không. Nó trả lời "tài nguyên này đang ở trạng thái nào, đã đổi từ trạng thái nào" — góc nhìn trạng thái, chứ không phải góc nhìn hành động. Nó không được thiết kế để audit hành động của người dùng database hay các RDS API call ở mức chi tiết như CloudTrail làm. Ngoài ra những lời gọi chỉ đọc, không làm đổi cấu hình, sẽ chẳng để lại dấu vết nào trong Config.

📌 Điểm cần nhớ

• Thấy chữ "API calls", "who did what", "audit", "governance", "compliance" ở mức tài khoản AWS → nghĩ ngay tới AWS CloudTrail. Đây là phản xạ đúng cho hầu hết câu hỏi kiểu này.
• Phân biệt rạch ròi ba nhóm công cụ quanh RDS: Enhanced Monitoring = metric của OS; Performance Insights = tinh chỉnh hiệu năng database; CloudTrail = dấu vết audit các lời gọi API. Chúng nghe giống nhau vì đều "monitoring", nhưng phục vụ ba mục đích khác hẳn.
• AWS Config trả lời "cái gì đã thay đổi", CloudTrail trả lời "ai đã gọi cái gì". Khi đề nhấn vào danh tính người thực hiện và vào cả những thao tác chỉ đọc, CloudTrail mới là đáp án.
• Việc Performance Insights lọc được theo user và host là mồi nhử kinh điển — dữ liệu hiệu năng phân theo user vẫn không phải là audit log.

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

Đề mô tả một hệ thống analytics của công ty e-commerce phải nuốt nhiều định dạng dữ liệu cùng lúc: dữ liệu structured từ relational database, và dữ liệu semi-structured từ web traffic log. Câu hỏi cuối cùng là: chọn service nào để tự động phát hiện (detect) và xử lý các schema khác nhau rồi đưa dữ liệu vào Amazon S3.

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

• "accommodate schema changes, particularly for the web logs that are frequently updated" — schema không cố định, thay đổi liên tục. Cụm này loại ngay mọi phương án đòi khai báo schema cứng hoặc phải viết code dò schema bằng tay.
• "automate the detection ... of these varied data schemas" — đề hỏi thẳng về schema detection tự động, tức là một tính năng có sẵn của service, không phải thứ mình tự dựng.
• "structured data from relational databases and semi-structured data from web traffic logs" — nguồn dữ liệu hỗn hợp, không thuần streaming và cũng không thuần database.

Cụm SLA 15 phút chỉ là ràng buộc phụ: nó loại các kiến trúc phải viết code và orchestrate nhiều bước, chứ không phải tiêu chí chọn chính.

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

C — AWS Glue với tính năng schema detection.

AWS Glue là ETL service được quản lý hoàn toàn, và điểm mấu chốt khớp đề là nó có schema detection sẵn có: Glue crawler quét dữ liệu nguồn, tự suy ra schema và ghi vào Data Catalog, rồi cập nhật lại khi schema nguồn đổi. Đây đúng là thứ đề bài yêu cầu — "automate the detection", không phải "tự viết code detect".

Glue xử lý được cả structured lẫn semi-structured, nên một service duy nhất phủ được cả dữ liệu từ relational database lẫn web traffic log — khớp với vế "varied data formats" của đề. Glue cũng ghi kết quả thẳng vào Amazon S3, và vì AWS quản lý hạ tầng bên dưới nên không phải lo cấp phát tài nguyên để chạy kịp SLA. Operational overhead thấp là lý do phụ, nhưng lý do chính vẫn là: Glue là service duy nhất trong bốn phương án có schema detection như một tính năng dựng sẵn.

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

A — AWS DMS replication kèm schema conversion, load liên tục vào S3. DMS mạnh ở đúng việc nó sinh ra để làm: migrate database và replicate liên tục. Nhưng nó xoay quanh nguồn là database, không phải công cụ ETL cho web traffic log dạng semi-structured. Phần "schema conversion" của DMS cũng khác hẳn "schema detection" mà đề hỏi: nó chuyển đổi cấu trúc giữa hai database engine, chứ không phải tự suy ra schema của dữ liệu log đang thay đổi. Chọn A là bỏ hẳn một nửa nguồn dữ liệu trong đề.

B — Data Pipeline orchestrate + Lambda tự làm schema detection. Đây là phương án gần đúng nhất về mặt "làm được", và chính vì vậy nó là bẫy. Data Pipeline điều phối workflow được, Lambda xử lý dữ liệu được — nhưng phần schema detection phải tự viết code. Đề bài hỏi "automate the detection", nghĩa là muốn tính năng có sẵn; ở đây bạn phải tự xây và tự bảo trì mỗi lần web log đổi cấu trúc. Thêm nữa, ghép nhiều thành phần rời rồi orchestrate qua từng bước làm tăng độ trễ, dễ vượt SLA 15 phút. Sai vì cách làm, không phải vì bất khả thi.

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

D — Kinesis Data Analytics detect schema trên streaming + Firehose load vào S3. Cụm này hợp lý khi dữ liệu đến thuần dưới dạng stream. Vấn đề là đề có cả dữ liệu từ relational database — thứ không tự nhiên chảy vào Kinesis stream. Kiến trúc này không phù hợp cho phần dữ liệu dạng batch từ nhiều nguồn khác nhau như đề mô tả. Từ khoá "real-time" và "15 minutes" trong đề dễ khiến người học phản xạ chọn Kinesis, nhưng ràng buộc thật sự là schema đa dạng và hay đổi, không phải độ trễ mili-giây.

📌 Điểm cần nhớ

• Thấy "schema detection" / "schema changes" / "evolving schema" trong đề AWS data engineering → nghĩ tới AWS Glue trước tiên; Glue crawler + Data Catalog là câu trả lời mặc định cho nhóm từ khoá này.
• Phân biệt schema conversion (DMS) với schema detection (Glue): cái đầu chuyển cấu trúc giữa hai database engine, cái sau tự suy ra schema từ dữ liệu chưa biết cấu trúc.
• Phương án "orchestration + Lambda tự code" gần như luôn thua service có sẵn tính năng, khi đề dùng chữ "automate" — đề đang hỏi tính năng dựng sẵn, không hỏi cách tự xây.
• Đừng để chữ "real-time" tự động kéo về Kinesis. Phải xét nguồn dữ liệu: có relational database trộn với log thì kiến trúc thuần streaming không phủ hết.

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

Đề mô tả một ứng dụng di động ghi nhận hoạt động người dùng, dữ liệu được liên tục đẩy vào Amazon Kinesis Data Streams. Yêu cầu: xử lý luồng đó real-time và cập nhật hồ sơ người dùng đang nằm trong Amazon DynamoDB.

Cụm từ quyết định là "process this data in real-time" đặt cạnh "continuously streamed to Kinesis Data Streams". Cả bốn phương án đều có thể đọc dữ liệu rồi ghi vào DynamoDB nếu ta chịu khó dựng đủ thứ quanh nó — nên điểm phân biệt không phải "làm được hay không", mà là độ trễ xử lý và mức vận hành phải gánh. Cụm thứ hai đáng chú ý là "update user profiles ... based on the activity data": đây là thao tác ghi từng bản ghi nhỏ, theo sự kiện, chứ không phải quét lại toàn bộ tập dữ liệu.

Đọc đề theo hai trục này thì các phương án tự tách ra: thứ nào gắn trực tiếp vào Kinesis theo mô hình sự kiện, và thứ nào phải chờ gom lô hoặc phải nuôi hạ tầng.

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

Đáp án đúng theo tệp là D — dùng AWS Lambda xử lý dữ liệu từ Kinesis Data Streams rồi cập nhật bản ghi trong DynamoDB.

Lambda có tích hợp sẵn với Kinesis Data Streams làm nguồn sự kiện (event source mapping): dịch vụ tự đọc các bản ghi từ shard và gọi hàm của bạn ngay khi dữ liệu tới, không cần bạn viết consumer, không cần tự quản lý checkpoint hay vòng lặp polling. Trong thân hàm, bạn chạy đúng phần logic nghiệp vụ — đọc bản ghi hoạt động, suy ra thay đổi, rồi gọi UpdateItem lên bảng hồ sơ trong DynamoDB.

Đây là mô hình serverless: không có máy chủ nào để vá, để giám sát hay để chỉnh kích thước. Mức độ song song bám theo cấu trúc shard của stream, nên khi lượng sự kiện từ app tăng thì phần xử lý giãn theo mà không phải can thiệp tay. Chi phí cũng bám theo lượng gọi thực tế thay vì theo thời gian một cụm máy chạy không. Với bài toán "sự kiện đến → biến đổi nhỏ → ghi một item", đây đúng là hình dạng công việc mà cặp Kinesis + Lambda sinh ra để giải.

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

A. AWS Glue trích xuất và biến đổi dữ liệu streaming rồi nạp vào DynamoDB. Đây là phương án gần đúng nhất về mặt "serverless", và Glue đúng là dịch vụ tích hợp dữ liệu không cần quản lý máy chủ. Nhưng trọng tâm của Glue là các job ETL theo lô — chuẩn bị dữ liệu, chuyển đổi định dạng, nạp vào kho dữ liệu. Nó không phải công cụ tự nhiên cho việc phản ứng theo từng sự kiện để cập nhật hồ sơ người dùng ngay lập tức, và đưa Glue vào đây là chọn một cỗ máy ETL nặng cho một thao tác ghi rất nhẹ.

B. Dựng các instance Amazon EC2 để tiêu thụ và xử lý stream, rồi ghi vào DynamoDB. Về mặt kỹ thuật thì chạy được: bạn hoàn toàn có thể viết một consumer đọc Kinesis trên EC2. Chỗ hỏng nằm ở chi phí vận hành, không ở tính khả thi. Bạn phải tự lo scaling khi lưu lượng lên xuống, tự vá hệ điều hành, tự giám sát tiến trình sống chết, tự xử lý khi một instance chết giữa chừng. Toàn bộ khối việc đó là thứ tích hợp Lambda–Kinesis đã làm sẵn, nên trong một câu hỏi so sánh các lựa chọn, đây là phương án thua vì thừa gánh nặng chứ không phải vì sai nguyên lý.

C. Cấu hình Amazon EMR xử lý luồng và cập nhật DynamoDB bằng các batch job. Chính cụm "batch jobs" trong phương án tự tố cáo nó: đề đòi xử lý real-time, mà batch job thì theo định nghĩa là gom dữ liệu lại rồi chạy theo chu kỳ. EMR mạnh ở xử lý quy mô lớn kiểu phân tích, và dựng một cụm cho kịch bản này vừa phức tạp vừa tốn kém hơn mức bài toán cần, trong khi vẫn không cho ra độ trễ thấp mà đề yêu cầu.

📌 Điểm cần nhớ

• Kinesis Data Streams + AWS Lambda là cặp mặc định cho xử lý streaming real-time. Thấy đề nói "stream" cộng "real-time" cộng "ít vận hành", hãy nghĩ tới Lambda trước.
• Đọc kỹ động từ chỉ nhịp xử lý trong phương án. Chữ "batch job" nằm cùng một câu với yêu cầu "real-time" gần như luôn là dấu hiệu loại bỏ, kể cả khi dịch vụ đứng đằng trước nó rất mạnh.
• AWS Glue thuộc nhóm ETL theo lô; EMR thuộc nhóm xử lý phân tích quy mô lớn. Cả hai đều không phải lựa chọn đầu tiên cho việc phản ứng theo từng sự kiện.
• Khi nhiều phương án đều "làm được", tiêu chí phân định thường là operational overhead. Giải pháp serverless thắng giải pháp tự quản EC2 trong các câu hỏi kiểu "what combination of services should be used", trừ khi đề nêu ràng buộc bắt buộc phải kiểm soát máy chủ.

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

Đề mô tả một doanh nghiệp lớn chuẩn bị đưa nhiều ứng dụng on-premises lên AWS, và nêu hai nhu cầu tách bạch:

1. Trước khi di chuyển, họ muốn hiểu các dependency và đặc tính hiệu năng của ứng dụng đang chạy dưới on-premises.
2. Họ muốn một cách di chuyển hiệu quả, với thời gian ngừng dịch vụ tối thiểu (minimal downtime).

Câu hỏi chốt lại bằng "Which combination of AWS services" — nghĩa là phải chọn một cặp dịch vụ, trong đó mỗi dịch vụ khớp đúng một nhu cầu. Đây chính là ràng buộc phân biệt: nhiều phương án có một nửa nghe hợp lý, nhưng chỉ một phương án có cả hai vế đều là dịch vụ sinh ra để làm migration.

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

• "discover application dependencies" — không phải kiểm kê tài nguyên AWS, mà là dò quan hệ phụ thuộc và hiệu năng của máy chủ đang nằm ngoài AWS. Mọi dịch vụ chỉ nhìn thấy tài nguyên bên trong AWS đều bị loại ngay ở vế này.
• "migrate ... with minimal downtime" — không phải triển khai lại hay đóng gói lại ứng dụng, mà là chuyển nguyên trạng workload đang chạy sang AWS. Cơ chế phù hợp là replication liên tục rồi cutover, chứ không phải build hình ảnh máy hay deploy mã nguồn lên môi trường mới.

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

Đáp án đúng theo tệp là C — AWS Application Discovery Service + AWS Application Migration Service (MGN).

AWS Application Discovery Service được thiết kế riêng cho các tổ chức đang lên kế hoạch di chuyển lên cloud. Nó thu thập thông tin về tài sản IT trong data center, các mối phụ thuộc giữa các máy chủ và dữ liệu hiệu năng — đúng cả hai thứ đề bài yêu cầu ở giai đoạn trước migration. Kết quả đó dùng để lập kế hoạch và tối ưu dự án migration: biết ứng dụng nào nói chuyện với ứng dụng nào thì mới xếp được nhóm nào phải chuyển cùng một đợt.

AWS Application Migration Service (MGN) — dịch vụ kế tục AWS Server Migration Service — lo phần thực thi: tự động hoá việc chuyển ứng dụng và máy chủ on-premises đang chạy sang AWS, giảm thiểu downtime và giữ cho quá trình chuyển đổi mượt mà. Đây là dịch vụ lift-and-shift mặc định của AWS, nên nó khớp thẳng với vế "minimal downtime" trong đề.

Cặp này là câu trả lời chuẩn của mẫu câu "discover rồi migrate": một dịch vụ cho giai đoạn khảo sát, một dịch vụ cho giai đoạn chuyển.

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

A. AWS Systems Manager + AWS CloudFormation. Systems Manager cho khả năng quan sát và điều khiển hạ tầng, nhưng nó không chuyên về việc dò dependency chi tiết phục vụ migration — đó không phải mục đích thiết kế của nó. CloudFormation là dịch vụ infrastructure-as-code, tự động hoá việc cấp phát tài nguyên AWS; nó dựng ra hạ tầng mới theo mô tả, chứ không xử lý được sự phức tạp của việc di chuyển ứng dụng on-premises đang chạy. Đây là phương án gần đúng nhất về mặt cảm giác ("orchestrating the migration process" nghe rất hợp), nhưng hỏng ở chỗ: CloudFormation không sao chép dữ liệu và trạng thái của máy chủ nguồn, nên không có cơ chế nào để đạt minimal downtime.

B. AWS Config + Amazon EC2 Image Builder. Config rất tốt cho việc theo dõi cấu hình tài nguyên AWS và kiểm tra tuân thủ, nhưng nó không tập trung vào application discovery phục vụ lập kế hoạch migration — và vế "tài nguyên AWS" là điểm chết: ứng dụng còn đang ở on-premises. EC2 Image Builder tự động hoá việc tạo machine image; nó thiên về quản lý và phát hành image hơn là di chuyển ứng dụng on-premises hiện hữu. Tạo được image không có nghĩa là chuyển được một hệ thống đang phục vụ người dùng mà không ngắt dịch vụ.

D. AWS CloudTrail + AWS Elastic Beanstalk. CloudTrail phục vụ governance, compliance và audit hoạt động trên các tài khoản AWS. Nó ghi lại lời gọi API — hoàn toàn không cho biết dependency giữa các ứng dụng on-premises, vốn là thứ đề bài hỏi. Elastic Beanstalk đơn giản hoá việc deploy và scale ứng dụng trên AWS, nhưng nó phục vụ mô hình triển khai lại mã nguồn lên nền tảng mới, chứ không nhắm vào quy trình migration của ứng dụng on-premises sẵn có. Đi đường này là re-platform, kèm theo sửa ứng dụng và downtime — trái ngược yêu cầu của đề.

📌 Điểm cần nhớ

• Đề nhắc "on-premises" thì mọi dịch vụ chỉ nhìn được tài nguyên bên trong AWS (AWS Config, CloudTrail) đều không phải công cụ discovery hợp lệ.
• Cặp chuẩn cho kịch bản khảo sát rồi di chuyển là AWS Application Discovery Service → AWS Application Migration Service (MGN); MGN là tên hiện tại thay cho AWS Server Migration Service cũ.
• Phân biệt ba nhóm dễ lẫn: cấp phát hạ tầng mới (CloudFormation), deploy/scale ứng dụng (Elastic Beanstalk), tạo machine image (EC2 Image Builder) — không cái nào là migration ứng dụng đang chạy.
• Cụm "minimal downtime" là tín hiệu chỉ thẳng tới cơ chế lift-and-shift có replication rồi cutover, chứ không phải tới việc build lại và triển khai lại ứng dụng.

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

Đề mô tả một nhóm data engineering quản lý kho video trong một bucket Amazon S3. Yêu cầu: mỗi khi có file video mới được tải lên, phải khởi động quy trình trích xuất metadata rồi ghi metadata vào database để làm catalog.

Cụm từ quyết định đáp án là "automatically trigger ... as soon as a new video file is uploaded" — tức là cần một cơ chế đẩy (push) theo sự kiện, kích hoạt ngay tại thời điểm upload, chứ không phải một cơ chế phát hiện file mới sau đó. Chính chữ "as soon as" loại bỏ mọi kiểu quét định kỳ, và chữ "trigger" đòi hỏi phương án phải thực sự có khả năng phát sinh sự kiện, chứ không phải chỉ là một tính năng liên quan tới S3.

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

Đáp án đúng theo tệp là B — cấu hình Amazon S3 Event Notifications để kích hoạt một AWS Lambda function làm việc trích xuất metadata.

S3 Event Notifications là tính năng có sẵn của chính S3, cho phép khai báo: khi loại sự kiện nào đó xảy ra trên bucket (ví dụ tạo object mới) thì gửi thông báo tới một đích được cấu hình — Lambda là một trong các đích đó. Khi file video mới được ghi vào bucket, S3 tự phát ra sự kiện và gọi Lambda kèm thông tin về object vừa tạo, nên Lambda biết ngay cần đọc file nào.

Điểm mạnh khớp đúng đề bài:

• Tức thời: quy trình chạy ngay sau khi upload, không có khoảng chờ.
• Không tốn công vận hành: không có lịch quét, không có tiến trình nào phải nuôi sống, không cần thao tác tay.
• Đúng đơn vị xử lý: mỗi object mới sinh ra một lần gọi, phù hợp với việc trích metadata theo từng file.

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

A. Lambda poll bucket theo chu kỳ. Đây là phương án gần đúng nhất vì cuối cùng vẫn dùng Lambda để trích metadata, nhưng nó hỏng ở cách phát hiện file mới. Poll nghĩa là liệt kê bucket theo lịch rồi so sánh xem có gì mới — file tải lên ngay sau một lượt quét phải nằm chờ tới lượt sau, nên vi phạm thẳng yêu cầu "as soon as". Nó cũng tốn tài nguyên vô ích: phần lớn các lượt quét chạy khi chẳng có gì mới, và bucket càng nhiều object thì việc liệt kê để dò càng nặng. Bản thân nhóm còn phải tự lưu trạng thái "đã xử lý những file nào" — công việc mà S3 Event Notifications làm giúp.

C. EventBridge rule giám sát bucket rồi gọi AWS Batch job cho mỗi file. Về nguyên tắc EventBridge có thể nhận sự kiện liên quan tới S3, nhưng ở tình huống này nó là đường vòng: sự kiện vốn phát ra từ chính S3, thêm một lớp định tuyến ở giữa chỉ làm kiến trúc dài hơn mà không thêm giá trị nào cho một tác vụ đơn giản là đọc metadata của một file. Đích xử lý cũng lệch: AWS Batch dành cho khối lượng tính toán theo lô, cần định nghĩa job, môi trường tính toán, hàng đợi — khởi động cả bộ máy đó cho mỗi file video là quá nặng so với một hàm ngắn. Đây là lựa chọn "chạy được nhưng không phải cách trực tiếp và hiệu quả nhất", và câu hỏi đang hỏi tính năng nào nên dùng.

D. S3 Transfer Acceleration để phát hiện file mới rồi kích hoạt Step Functions. Sai ở mức khái niệm. Transfer Acceleration là tính năng tăng tốc độ truyền dữ liệu lên/xuống S3 qua đường mạng biên của AWS, hữu ích khi client ở xa vùng chứa bucket. Nó hoàn toàn không có cơ chế phát hiện sự kiện hay kích hoạt bất cứ quy trình nào. Vế "Step Functions" nghe hợp lý nhưng vô nghĩa khi không có thứ gì khởi động được nó — mệnh đề đầu của phương án đã sai thì cả phương án sai.

📌 Điểm cần nhớ

• Thấy cụm "as soon as / immediately after upload" gắn với S3: nghĩ ngay tới S3 Event Notifications, và loại mọi phương án dựa trên polling theo lịch.
• Polling không chỉ chậm mà còn đắt và phải tự quản lý trạng thái "đã xử lý"; kiến trúc hướng sự kiện đẩy trách nhiệm đó về cho dịch vụ.
• Phân biệt tính năng phát sinh sự kiện (S3 Event Notifications) với tính năng tối ưu truyền tải (Transfer Acceleration) — tên đều gắn với S3 nhưng giải quyết hai bài toán không liên quan.
• Chọn đích xử lý theo tầm vóc công việc: tác vụ ngắn, chạy theo từng object thì hợp với Lambda; AWS Batch dành cho tính toán theo lô, nặng và kéo dài.

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

Đề mô tả một ứng dụng y tế chạy trên Amazon EC2, dữ liệu bệnh nhân nhạy cảm nằm trên các EBS volume gắn vào instance, và chính sách bảo mật của công ty yêu cầu tuân thủ quy định ngành.

Cụm từ quyết định đáp án là: "all data at rest be encrypted" — mã hoá dữ liệu khi lưu trữ, kết hợp với "data is stored on EBS volumes".

Hai chi tiết này khoá chặt cả loại mã hoá lẫn nơi áp dụng:

• at rest (chứ không phải in transit) → loại ngay mọi giải pháp thuộc về mã hoá đường truyền.
• EBS volumes (chứ không phải S3 bucket) → loại mọi cơ chế mã hoá gắn với dịch vụ lưu trữ khác.

Chỉ cần đọc đúng hai cụm này là ba trong bốn phương án tự rụng.

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

B — Enable EBS encryption with AWS Key Management Service (KMS) keys.

Amazon EBS có sẵn cơ chế mã hoá riêng cho volume và snapshot, dùng khoá quản lý trong AWS KMS. Bật tính năng này lên là đúng công cụ tự nhiên (native) cho đúng loại tài nguyên mà đề nêu:

• Dữ liệu trên volume được mã hoá at rest, đúng yêu cầu của chính sách bảo mật.
• Khoá do KMS quản lý, nên việc tạo, xoay vòng, phân quyền và ghi vết sử dụng khoá đều nằm trong một dịch vụ quản trị khoá chuyên trách — điều mà các chuẩn tuân thủ ngành y tế thường đòi hỏi.
• Quá trình mã hoá/giải mã diễn ra trong suốt với ứng dụng: không phải sửa mã nguồn, không phải thay đổi cách EC2 đọc ghi dữ liệu, và không ảnh hưởng tới hiệu năng của volume.
• Snapshot tạo từ volume đã mã hoá cũng được mã hoá theo, nên dữ liệu không bị hở ra ở bản sao lưu.

Đây là phương án vừa đáp ứng yêu cầu kỹ thuật, vừa ít công vận hành nhất.

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

A — Use AWS Certificate Manager to apply SSL/TLS certificates to the EBS volumes. Sai về loại mã hoá. AWS Certificate Manager dùng để cấp phát, quản lý và triển khai chứng chỉ SSL/TLS, tức là bảo vệ dữ liệu in transit trên các kết nối mạng. Nó không hề cung cấp mã hoá at rest cho EBS. Ngoài ra, EBS volume không phải là một endpoint mạng để "gắn chứng chỉ" vào — bản thân thao tác mà phương án mô tả cũng không tồn tại.

C — Run a third-party encryption tool to encrypt data on the EBS volumes before storage. Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất: về mặt kết quả, một công cụ mã hoá của bên thứ ba có thể làm cho dữ liệu ở trạng thái đã mã hoá. Chỗ nó hỏng là chi phí vận hành. Chọn hướng này nghĩa là công ty phải tự cài đặt, tự vận hành, tự sinh và tự bảo quản khoá, tự lo việc xoay vòng khoá và tự chứng minh quy trình đó đạt chuẩn khi bị kiểm toán — trong khi AWS đã có sẵn cơ chế native làm đúng việc đó, tích hợp thẳng với KMS. Nó cũng không "trong suốt" như EBS encryption: quy trình mã hoá trước khi ghi phải được ứng dụng hoặc một lớp phần mềm nào đó chủ động thực hiện, dễ có chỗ lọt. Với cùng một kết quả bảo mật, giải pháp đòi hỏi nhiều thao tác thủ công hơn luôn là đáp án thua.

D — Encrypt the EBS volumes with Amazon S3 server-side encryption. Sai về đối tượng áp dụng. Server-side encryption (SSE) là cơ chế của Amazon S3, dành cho object nằm trong S3 bucket. Nó không phải là một nút bấm có thể chĩa sang một EBS volume — EBS là block storage với cơ chế mã hoá riêng của nó. Phương án này ghép tên hai dịch vụ không liên quan lại với nhau, nghe hợp lý với người chỉ nhớ mang máng "AWS có server-side encryption" mà không phân biệt block storage với object storage.

📌 Điểm cần nhớ

• At rest → nghĩ tới KMS; in transit → nghĩ tới TLS/ACM. Đọc đề thấy chữ at rest là gạch ngay mọi phương án có SSL/TLS hay Certificate Manager, và ngược lại.
• Mã hoá gắn liền với từng dịch vụ lưu trữ, không dùng chéo được. EBS có EBS encryption, S3 có S3 server-side encryption, RDS có mã hoá của RDS. Thấy phương án ghép tên cơ chế của dịch vụ này áp lên tài nguyên của dịch vụ kia là dấu hiệu sai kinh điển.
• Giải pháp native của AWS thắng công cụ bên thứ ba khi đề nhắc tới tuân thủ hoặc ít công vận hành. Bên thứ ba không sai về kỹ thuật, nhưng thua ở gánh nặng quản lý khoá và vận hành.
• Mã hoá EBS là trong suốt với ứng dụng và mở rộng sang cả snapshot — đây là lý do nó luôn là câu trả lời chuẩn cho yêu cầu bảo vệ dữ liệu trên volume của EC2.

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

Đề mô tả một ứng dụng serverless: AWS Lambda đọc và ghi dữ liệu vào một bảng DynamoDB cụ thể. Câu hỏi là cấu hình IAM role cho Lambda thế nào.

Cụm từ quyết định đáp án là "the principle of least privilege" (nguyên tắc đặc quyền tối thiểu), được nhấn mạnh hai lần — cả trong phần mô tả lẫn trong chính câu hỏi. Cụm từ thứ hai cũng quan trọng không kém: "a specific DynamoDB table" — phạm vi cần cấp là một bảng, không phải toàn bộ DynamoDB.

Khi đề đã nêu thẳng least privilege, mọi phương án chứa chữ FullAccess hay full access đều bị loại ngay, dù chúng vẫn "chạy được". Đây là kiểu câu mà tất cả các phương án đều khiến ứng dụng hoạt động; thứ phân biệt chúng là thừa bao nhiêu quyền.

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

D. Tạo custom IAM policy với các quyền cụ thể GetItem, PutItem, UpdateItem trên đúng bảng DynamoDB đó, rồi gắn vào IAM role của Lambda.

Đây là cách duy nhất trong danh sách khớp cả hai chiều của least privilege:

• Đúng hành động: đề nói Lambda cần "read and write data". GetItem là đọc, PutItem và UpdateItem là ghi. Không cấp thêm DeleteItem, Scan, hay quyền quản trị bảng như DeleteTable — những thứ hàm không dùng tới.
• Đúng phạm vi tài nguyên: custom policy cho phép đặt Resource là ARN của chính bảng đó, thay vì *. Đây là điều mà managed policy không làm được — managed policy do AWS viết sẵn, không thể biết bảng nào là bảng của bạn.

Vẫn cấp đủ quyền để hàm hoạt động, nhưng không dư ra phần nào có thể bị lợi dụng nếu Lambda bị chiếm quyền.

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

B. Gắn managed policy AmazonDynamoDBFullAccess — đây là phương án gần đúng nhất, và cũng là bẫy chính. Nó thực sự cấp đủ quyền để hàm chạy được, nên nếu chỉ đọc lướt "cần đọc/ghi DynamoDB" thì rất dễ chọn. Chỗ hỏng: FullAccess cấp mọi thao tác DynamoDB trên mọi bảng trong tài khoản — kể cả xoá bảng, xoá dữ liệu ở những bảng chẳng liên quan gì tới ứng dụng này. Nó vi phạm least privilege ở cả hai chiều: thừa action và thừa resource.

A. Dùng managed policy AWSLambdaFullAccess — sai theo một kiểu khác, và sai nặng hơn B. Policy này xoay quanh việc quản trị bản thân Lambda (tạo, sửa, gọi function), chứ không phải quyền để function truy cập bảng DynamoDB của bạn. Nghĩa là nó vừa có thể không đủ cho việc đề bài yêu cầu, vừa thừa một loạt quyền quản trị Lambda mà hàm không cần. Chọn nó là hiểu sai bản chất execution role: role của Lambda là để hàm gọi các dịch vụ khác, không phải để quản lý chính Lambda.

C. Tạo IAM policy cấp full access tới toàn bộ dịch vụ AWS — đây là vi phạm nặng nhất. Tuy có chữ "create an IAM policy" nghe giống D (tự viết policy, không dùng managed), nhưng nội dung policy lại là toàn quyền mọi dịch vụ — tương đương quyền quản trị. Bài học: tự viết policy không tự động đồng nghĩa với least privilege; thứ quyết định là nội dung policy chứ không phải nó do ai viết.

📌 Điểm cần nhớ

• Đề nhắc "principle of least privilege" → gạch ngay mọi phương án có FullAccess hoặc full access, kể cả khi chúng làm ứng dụng chạy đúng. Câu hỏi không hỏi "cách nào chạy được", mà hỏi "cách nào an toàn nhất".
• Least privilege có hai chiều: giới hạn Action (chỉ những API thật sự gọi) và giới hạn Resource (ARN của đúng tài nguyên đó). Managed policy của AWS chỉ có thể siết chiều thứ nhất, không bao giờ siết được chiều thứ hai — nên khi đề nói "a specific table/bucket/resource", custom policy gần như luôn là đáp án.
• Phân biệt AWSLambdaFullAccess (quyền quản trị dịch vụ Lambda) với execution role của Lambda (quyền để code trong hàm gọi DynamoDB, S3, …). Hai thứ khác nhau hoàn toàn; nhầm lẫn này bị dùng làm mồi trong rất nhiều câu.
• Ánh xạ yêu cầu ngôn ngữ tự nhiên sang API DynamoDB: "read" → GetItem/Query, "write" → PutItem/UpdateItem. Chỉ cấp đúng những gì đề mô tả — đề không nhắc xoá thì đừng cấp DeleteItem.

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

Công ty đã và đang dùng AWS Glue kết hợp Amazon EMR để di chuyển và biến đổi dữ liệu vào data lake trên S3. Họ không hỏi "nên xây ETL bằng gì", mà hỏi lấy gì để tự động hoá và điều phối (orchestrate) chính những workflow ETL đang có.

Cụm từ quyết định đáp án là "with minimal manual intervention", đi kèm với bối cảnh "currently use ... AWS Glue and Amazon EMR". Đây là câu kiểu "chọn dịch vụ ít tốn công vận hành nhất" — cả bốn phương án đều có thể chạy được ETL theo nghĩa nào đó, nên thứ phân biệt chúng không phải là khả năng mà là độ chuyên dụng và độ tích hợp sẵn có. Khi đề đã nói rõ nền tảng hiện tại là Glue, phương án nào nằm ngay trong Glue sẽ thắng phương án nào phải dựng thêm một lớp điều phối bên ngoài.

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

D — AWS Glue workflows. Glue workflows sinh ra đúng để tự động hoá và điều phối nhiều Glue job liên quan nhau. Trong một workflow, ta khai báo được cả chuỗi: crawler, job, trigger (theo lịch, theo sự kiện, hoặc theo điều kiện thành công/thất bại của bước trước), cùng nguồn và đích dữ liệu — tất cả nằm gọn trong dịch vụ Glue.

Vì công ty đã chạy ETL trên Glue, dùng Glue workflows nghĩa là không phải thêm hạ tầng mới, không phải học công cụ mới, không phải viết lớp keo nối các job lại. Đó chính là "minimal manual intervention" mà đề yêu cầu: môi trường được quản lý sẵn, chuyên dụng cho ETL, và giảm được chi phí vận hành.

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

C — AWS Step Functions. Đây là phương án gần đúng nhất và đáng bàn kỹ. Step Functions thật sự điều phối được workflow xuyên nhiều dịch vụ AWS, gọi được cả Glue job lẫn EMR step, xử lý được rẽ nhánh, thử lại, chờ đợi. Nhưng nó là công cụ đa dụng, không chuyên cho ETL: ta phải tự định nghĩa state machine, tự nối từng bước, tự xử lý chuyện truyền tham số giữa các job. So với Glue workflows — nơi các thành phần ETL đã có sẵn dưới dạng khái niệm dựng sẵn — Step Functions đòi hỏi nhiều thiết lập và quản lý hơn, tức là nhiều "manual intervention" hơn. Nó sai ở tiêu chí của đề, không sai ở khả năng.

B — AWS Lambda kích hoạt ETL theo sự kiện. Lambda phản ứng theo sự kiện, nhưng bản thân nó không phải một dịch vụ điều phối. Nó không giữ trạng thái của cả quy trình, không biết bước nào đã xong, bước nào phải chờ. Muốn dùng Lambda làm bộ điều phối thì phải tự dựng thêm chỗ lưu trạng thái và tự viết logic sắp xếp thứ tự các job — công sức vận hành tăng lên chứ không giảm. Lambda cũng hợp với tác vụ ngắn, còn ETL trên Glue/EMR thì thường chạy dài.

A — Amazon MWAA (Managed Workflows for Apache Airflow). MWAA là dịch vụ được quản lý cho Apache Airflow và hoàn toàn điều phối được workflow phức tạp, kể cả ETL. Vấn đề là nó nặng hơn nhu cầu ở đây: phải viết DAG bằng Python, phải hiểu mô hình của Airflow, và phù hợp nhất với đội đã quen Airflow từ trước. Đề không hề nói công ty đang dùng Airflow — họ đang dùng Glue và EMR. Đưa MWAA vào là thêm một hệ thống mới phải học và vận hành, đi ngược lại yêu cầu "minimal manual intervention".

📌 Điểm cần nhớ

• "Minimal manual intervention" / "least operational overhead" gần như luôn đẩy đáp án về dịch vụ chuyên dụng nhất cho đúng bài toán đó, không phải dịch vụ mạnh nhất hay linh hoạt nhất.
• Khi đề mô tả nền tảng hiện tại (ở đây là Glue + EMR), hãy coi đó là ràng buộc: tính năng nằm sẵn trong nền tảng đó thắng công cụ ngoài phải tích hợp thêm.
• Phân biệt ba mức: Glue workflows = điều phối ETL trong lòng Glue; Step Functions = điều phối đa dụng xuyên dịch vụ; MWAA = điều phối dạng Airflow cho quy trình phức tạp và đội đã quen Airflow.
• Lambda là compute theo sự kiện, không phải orchestrator. Thấy phương án dùng Lambda để "quản lý chuỗi nhiều bước có trạng thái" thì gần như luôn loại được.

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

Đề mô tả một chuỗi dữ liệu genomic tốc độ cao đổ vào Amazon Kinesis Data Streams, cần được xử lý rồi lưu vào Amazon Redshift Serverless để phân tích. Yêu cầu gồm hai vế: phân tích dữ liệu ngay khi nó đang chảy vào (as it streams in), và tổng hợp dữ liệu của 24 giờ gần nhất.

Cụm từ quyết định nằm ở câu hỏi cuối: "the most efficient method ... with minimal management effort", cộng với "immediate and subsequent analysis". Đây là hai ràng buộc đi cùng nhau và loại bỏ lẫn nhau với các phương án khác:

• minimal management effort → càng ít thành phần trung gian phải dựng, cấu hình và vận hành càng tốt;
• immediate / as it streams in → không chấp nhận độ trễ do gom lô (batching) hay do một tầng xử lý riêng.

Bất cứ phương án nào thêm một dịch vụ nữa vào giữa Kinesis Data Streams và Redshift đều đi ngược lại cả hai vế.

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

Đáp án đúng theo tệp là A — dùng tính năng streaming ingestion sẵn có của Amazon Redshift để nạp và truy vấn thẳng từ Kinesis data stream.

Redshift có tính năng nạp dữ liệu streaming trực tiếp: kho dữ liệu đọc thẳng từ Kinesis data stream mà không cần một tầng xử lý hay một nơi lưu trữ trung gian nào ở giữa. Dữ liệu đến là truy vấn được ngay, đúng vế "immediate analysis". Vì bản chất là một tính năng của chính Redshift chứ không phải một dịch vụ phải dựng thêm, kiến trúc gọn nhất có thể và chi phí vận hành thấp nhất — đúng vế "minimal management effort".

Vế thứ hai của đề, tổng hợp dữ liệu 24 giờ gần nhất, cũng được đáp ứng: một khi dữ liệu đã nằm trong Redshift Serverless thì đây chỉ là truy vấn SQL phân tích thông thường trên kho dữ liệu, không cần cơ chế gì thêm.

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

B — Dùng Amazon MSK làm bộ đệm trung gian trước khi nạp vào Redshift Serverless. MSK là dịch vụ Apache Kafka được quản lý, hoàn toàn có khả năng làm bộ đệm cho dữ liệu streaming. Nhưng đề đã có sẵn Kinesis Data Streams làm nơi nhận dữ liệu — thêm MSK là chồng một hệ thống streaming lên trên một hệ thống streaking khác, tức thêm một lớp phải cấu hình, giám sát và vận hành mà chẳng giải quyết được vấn đề nào. Đây là phương án tốn công quản lý nhất trong bốn phương án, ngược hẳn với "minimal management effort".

C — Dùng Kinesis Data Firehose để đưa dữ liệu thẳng vào Redshift Serverless. Đây là phương án gần đúng nhất và là cái bẫy chính của câu hỏi. Firehose đúng là dịch vụ giao dữ liệu streaming được quản lý, gần như không phải vận hành gì, và Redshift đúng là một đích đến hợp lệ của nó. Chỗ hỏng nằm ở độ trễ: Firehose làm việc theo cơ chế gom dữ liệu thành lô rồi mới giao, nên luôn có một khoảng trễ trước khi dữ liệu xuất hiện trong Redshift. Với yêu cầu phân tích ngay khi dữ liệu đang chảy vào, cơ chế gom lô đó không đáp ứng được. Nói cách khác: Firehose thắng về mức độ dễ quản lý nhưng thua ở vế "immediate", còn A thắng cả hai.

D — Viết một AWS Lambda function đọc Kinesis data stream rồi nạp vào Redshift Serverless. Về mặt kỹ thuật thì chạy được: Lambda tiêu thụ được bản ghi từ Kinesis và ghi được vào Redshift. Nhưng nó đòi bạn tự viết và tự bảo trì mã: logic xử lý bản ghi, logic ghi vào kho dữ liệu, xử lý lỗi, thử lại, và mở rộng theo khối lượng dữ liệu tốc độ cao như genomic sequencing. Đó chính là "operational effort" mà đề yêu cầu giảm tối đa. Phương án này là giải pháp tự dựng trong khi đã có tính năng dựng sẵn làm đúng việc đó.

📌 Điểm cần nhớ

• Khi đề nói "minimal management effort" / "least operational overhead", hãy ưu tiên tính năng có sẵn của chính dịch vụ đích hơn là dựng thêm dịch vụ trung gian hay tự viết mã.
• Phân biệt rõ hai mức độ "thời gian thực": Kinesis Data Firehose gom lô nên có độ trễ, còn Redshift streaming ingestion đọc thẳng từ stream. Đề nhấn "immediate / as it streams in" thì chọn cái sau; đề chấp nhận "near real-time" và đích là data lake/S3 thì Firehose lại là lựa chọn đúng.
• Lambda tự viết hầu như luôn thua trong các câu so sánh về công sức vận hành, dù nó chạy được về mặt kỹ thuật — nó là dấu hiệu của giải pháp thủ công.
• Đề đã có sẵn một hệ thống streaming (Kinesis) thì thêm MSK là thừa; hai dịch vụ này là lựa chọn thay thế nhau chứ không xếp chồng lên nhau.

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

Đề mô tả một bảng CustomerDetails trong Amazon Redshift, có cột FirstName, và yêu cầu lấy về những khách hàng có tên bắt đầu bằng "Jo" hoặc "Ja".

Cụm từ quyết định đáp án là "whose first names begin with" — tức là so khớp theo mẫu ở đầu chuỗi, chứ không phải so khớp bằng đúng một giá trị. Ngay khi đọc thấy "begin with", "ends with", "contains", bài toán đã chuyển từ phép so sánh bằng (=, IN) sang phép so khớp mẫu (pattern matching). Bốn phương án ở đây được dựng lên đúng để thử xem người học có phân biệt được hai nhóm toán tử đó không: chỉ một phương án dùng đúng toán tử so khớp mẫu của SQL, ba phương án còn lại hoặc bịa ra cú pháp không tồn tại, hoặc dùng toán tử so sánh bằng rồi nhét ký tự đại diện vào chuỗi.

Chữ "efficiently" trong đề chỉ là cách nói "câu truy vấn hợp lệ và lấy đúng dữ liệu", không phải gợi ý về chỉ mục hay phân phối dữ liệu — không phương án nào bàn về những thứ đó.

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

Đáp án đúng theo tệp là B:

SELECT * FROM CustomerDetails WHERE FirstName LIKE 'Jo%' OR FirstName LIKE 'Ja%';

LIKE là toán tử so khớp mẫu chuẩn của SQL và được Redshift hỗ trợ. Trong mẫu của LIKE, ký tự % là wildcard khớp với một chuỗi ký tự bất kỳ, kể cả chuỗi rỗng. Vì vậy:

• 'Jo%' khớp mọi giá trị bắt đầu bằng Jo — John, Jonathan, Josephine, và cả đúng chữ "Jo".
• 'Ja%' khớp mọi giá trị bắt đầu bằng Ja — James, Jane, Jack.

Vì % đặt ở cuối mẫu chứ không đặt ở đầu, điều kiện diễn tả chính xác ngữ nghĩa "begin with" mà đề yêu cầu. Hai điều kiện nối bằng OR nên bản ghi chỉ cần thoả một trong hai là được lấy về — khớp với chữ "or" trong đề.

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

A. WHERE FirstName STARTS WITH 'Jo' OR FirstName STARTS WITH 'Ja'

Đây là phương án gây nhầm nhất, vì nó đọc lên đúng y hệt câu tiếng Anh trong đề — "starts with". Nhưng SQL không có toán tử STARTS WITH; đây không phải chuyện Redshift thiếu tính năng mà là cú pháp không tồn tại trong SQL nói chung. Câu lệnh sẽ hỏng ngay ở bước phân tích cú pháp, không trả về dòng nào. Bài học: một phương án diễn đạt lại đề bằng tiếng Anh trơn tru thường là bẫy, vì đề bài viết bằng ngôn ngữ tự nhiên còn câu trả lời phải viết bằng cú pháp thật.

C. WHERE FirstName IN ('Jo%', 'Ja%')

IN là cách viết gọn của một chuỗi phép so sánh bằng: nó tương đương FirstName = 'Jo%' OR FirstName = 'Ja%'. Bên trong IN, ký tự % không được hiểu là wildcard mà chỉ là một ký tự phần trăm bình thường trong chuỗi. Câu này cú pháp hợp lệ nên chạy được — và đó chính là chỗ nguy hiểm: nó không báo lỗi, chỉ lặng lẽ trả về tập rỗng (trừ khi trong bảng có ai đó tên đúng là "Jo%"). Wildcard chỉ có ý nghĩa khi đứng trong mẫu của LIKE, không phải ở mọi chỗ có chuỗi ký tự.

D. WHERE FirstName = 'Jo*' OR FirstName = 'Ja*'

Hai lỗi chồng lên nhau. Thứ nhất, = là phép so sánh bằng chính xác, không diễn giải wildcard dưới bất kỳ dạng nào. Thứ hai, ngay cả khi đã dùng LIKE, ký tự đại diện trong SQL là % và _, không phải * — dấu sao là quy ước của shell glob và của một số cú pháp tìm kiếm khác, không phải của SQL. Kết quả cũng giống C: chạy được, không lỗi, trả về rỗng.

📌 Điểm cần nhớ

• "Begin with / end with / contain" trong đề là tín hiệu phải dùng LIKE, với % đặt tương ứng ở cuối / đầu / cả hai đầu của mẫu.
• % khớp chuỗi ký tự bất kỳ (kể cả rỗng), _ khớp đúng một ký tự. * không là wildcard trong SQL.
• IN và = là so sánh bằng; nhét % vào trong chúng không biến chúng thành so khớp mẫu, và lỗi này không báo cú pháp mà chỉ trả về kết quả rỗng — kiểu lỗi khó phát hiện nhất.
• Phương án nào chép lại nguyên văn cách diễn đạt tiếng Anh của đề (STARTS WITH) thường là cú pháp bịa; hãy đối chiếu với toán tử SQL thật sự tồn tại.