Ngân hàng đề — Microsoft Azure Data Fundamentals

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

Câu hỏi: "Which statement is an example of Data Manipulation Language (DML)?"
✅ Giải thích rõ ràng: Câu hỏi đang kiểm tra kiến thức về các loại ngôn ngữ SQL cơ bản, cụ thể là phân loại Data Manipulation Language (DML) – ngôn ngữ dùng để thao tác, chỉnh sửa dữ liệu trong cơ sở dữ liệu (như thêm, sửa, xóa, truy vấn dữ liệu). Đây là khái niệm chuẩn trong SQL, áp dụng chung cho các dịch vụ cơ sở dữ liệu trên AWS như Amazon RDS (hỗ trợ MySQL, PostgreSQL, SQL Server, Oracle) hoặc Amazon Aurora. Theo tài liệu AWS cập nhật đến năm 2026 (phiên bản RDS mới nhất), DML bao gồm các lệnh như SELECT, INSERT, UPDATE, DELETE để thay đổi dữ liệu thực tế trong bảng, không ảnh hưởng đến cấu trúc cơ sở dữ liệu.
📘 Tài liệu tham khảo:

• AWS RDS Documentation: SQL Statements in Amazon RDS (cập nhật 2026).
• AWS Certified Database - Specialty Exam Guide (2026 edition).

✅ Đáp án đúng: UPDATE

Lý do lựa chọn: UPDATE là lệnh điển hình của DML vì nó dùng để cập nhật (thay đổi) dữ liệu hiện có trong bảng cơ sở dữ liệu, ví dụ: UPDATE employees SET salary = 50000 WHERE id = 1;. Lệnh này chỉ thao tác dữ liệu mà không thay đổi cấu trúc bảng. Trong AWS RDS, UPDATE được hỗ trợ đầy đủ trên tất cả engine (MySQL 8.4+, PostgreSQL 16+, v.v.) và là một phần cốt lõi của DML theo chuẩn ANSI SQL.

🛠️ Giải thích tất cả các phương án

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh:

• REVOKE ❌ Sai: REVOKE thuộc Data Control Language (DCL), dùng để thu hồi quyền truy cập (permissions) cho người dùng hoặc role, ví dụ: REVOKE SELECT ON table FROM user;. Nó không thao tác dữ liệu mà chỉ kiểm soát bảo mật. Trong AWS RDS IAM Database Authentication (cập nhật 2026), REVOKE được dùng cho quyền IAM nhưng vẫn là DCL, không phải DML.

• DISABLE ❌ Sai: DISABLE không phải lệnh SQL chuẩn của DML mà thuộc DDL (Data Definition Language) hoặc lệnh quản trị, dùng để vô hiệu hóa index, trigger, hoặc constraint, ví dụ: ALTER TABLE DISABLE TRIGGER trig_name; (PostgreSQL trên RDS). Nó ảnh hưởng cấu trúc hoặc hành vi bảng, không chỉnh sửa dữ liệu trực tiếp. AWS RDS hỗ trợ qua pgAdmin hoặc SQL client, nhưng không xếp vào DML.

• CREATE ❌ Sai: CREATE là lệnh điển hình của DDL, dùng để tạo mới các đối tượng cơ sở dữ liệu như bảng, view, index (ví dụ: CREATE TABLE employees (id INT);). Nó định nghĩa cấu trúc, không thao tác dữ liệu. Trong AWS DMS hoặc RDS Schema Management (2026), CREATE được dùng rộng rãi nhưng thuộc DDL.

• UPDATE ✅ Đúng: Như đã giải thích ở trên, UPDATE là DML chuẩn để sửa dữ liệu. Trong AWS Redshift hoặc Aurora Serverless v2 (2026), nó hỗ trợ transaction-safe UPDATE với performance cao, phù hợp cho workload OLTP.

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

Câu hỏi tập trung vào việc tạo một tài nguyên Azure để lưu trữ dữ liệu trong Azure Table storage. Azure Table storage là dịch vụ NoSQL key-value store thuộc Azure Storage, dùng để lưu trữ dữ liệu bảng lớn với hiệu suất cao và chi phí thấp.

📌 Yêu cầu chính: Người dùng cần chạy lệnh Azure CLI (Command Line Interface) để tạo tài nguyên gốc (resource) hỗ trợ Azure Table storage. Lưu ý rằng Azure Table storage không tồn tại độc lập mà phải nằm trong một Azure Storage Account. Do đó, bước đầu tiên và bắt buộc là tạo Storage Account trước khi có thể tạo bảng (table) bên trong nó.

🛠️ Bối cảnh: Đây là câu hỏi kiểm tra kiến thức cơ bản về Azure CLI và cấu trúc dịch vụ lưu trữ Azure (dựa trên tài liệu chính thức Microsoft Learn, cập nhật đến năm 2024-2026, không có thay đổi lớn về yêu cầu tạo Storage Account cho Table storage).

✅ Đáp án đúng: az storage account create

Lý do lựa chọn:
Lệnh az storage account create dùng để tạo Azure Storage Account, đây là tài nguyên cha (parent resource) bắt buộc cho Azure Table storage. Sau khi tạo Storage Account với tính năng Table được kích hoạt (mặc định hỗ trợ), bạn mới có thể tạo và lưu dữ liệu vào các bảng Table storage bằng lệnh như az storage table create. Không có Storage Account, bạn không thể sử dụng Table storage. Đây là bước đầu tiên chính xác theo quy trình Azure (xem tài liệu: Azure CLI - az storage account create).

📘 Giải thích tất cả các phương án

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai kèm lý do chi tiết dựa trên tài liệu Azure CLI mới nhất (2024-2026):

• ❌ az storage share create
  Lệnh này dùng để tạo Azure File Share (chia sẻ file SMB) bên trong một Storage Account đã tồn tại. Nó chỉ hỗ trợ dịch vụ Azure Files, không liên quan đến Table storage (Table là NoSQL, không phải file storage). Nếu chạy lệnh này mà chưa có Storage Account, lệnh sẽ thất bại. (Tài liệu: Azure CLI - az storage share create).

• ✅ az storage account create
  Đúng như đã giải thích ở trên. Đây là lệnh tạo Storage Account với các dịch vụ con bao gồm Blob, File, Queue, và Table storage. Sau khi tạo, bạn kích hoạt Table qua thuộc tính --enable-table nếu cần (mặc định bật). Quy trình chuẩn: Tạo account → Tạo table → Lưu dữ liệu. (Tài liệu: Microsoft Learn - Azure Table Storage Overview).

• ❌ az cosmosdb create
  Lệnh này tạo Azure Cosmos DB account, một dịch vụ NoSQL đa mô hình (bao gồm Table API). Tuy nhiên, không phải Azure Table storage gốc (Table storage là phần của Azure Storage, rẻ hơn và đơn giản hơn Cosmos DB). Câu hỏi chỉ định rõ "Azure Table storage", nên Cosmos DB là lựa chọn sai. (Tài liệu: Azure CLI - az cosmosdb create).

• ❌ az storage container create
  Lệnh này tạo Blob Container (chứa blob objects) bên trong một Storage Account đã tồn tại. Nó chỉ dành cho Blob storage, không hỗ trợ Table storage (Table dùng entity/table riêng biệt). Lệnh yêu cầu Storage Account trước, nên không phải bước tạo resource gốc. (Tài liệu: Azure CLI - az storage container create).

🛡️ Lưu ý bổ sung

• Quy trình đầy đủ để sử dụng Table storage:
  1. ✅ Tạo Storage Account (az storage account create).
  2. Tạo table (az storage table create).
  3. Thêm dữ liệu (az storage table entity insert).
• Nguồn tham khảo chính thức (cập nhật 2026):
  📖 Azure Storage Account CLI
  📖 Azure Table Storage Quickstart
  📖 Azure CLI Reference

Hy vọng phân tích này giúp bạn nắm vững kiến thức Azure Data Fundamentals! 🚀 Nếu cần ví dụ code thực tế, hãy hỏi thêm.

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

Câu hỏi tập trung vào cơ sở dữ liệu quan hệ (relational database), cụ thể là cách sửa đổi một view bằng cách thêm một cột mới (adding a new column).
📘 View là một đối tượng ảo trong cơ sở dữ liệu, đại diện cho một tập hợp dữ liệu từ các bảng gốc, không lưu trữ dữ liệu thực tế mà chỉ là câu lệnh SELECT được lưu trữ. Để thêm cột mới vào view, bạn cần thay đổi định nghĩa (definition) của view đó, không phải thêm dữ liệu vật lý.
🛠️ Đây là kiến thức SQL chuẩn, áp dụng cho các hệ quản trị cơ sở dữ liệu quan hệ như SQL Server, MySQL, PostgreSQL (hỗ trợ trên AWS RDS theo phiên bản mới nhất 2026), không thay đổi cơ bản từ các phiên bản trước.
Mục tiêu: Xác định lệnh SQL đúng để thực hiện việc này một cách an toàn và hiệu quả.

✅ Đáp án đúng: ALTER

Lý do lựa chọn:
Lệnh ALTER được sử dụng để sửa đổi cấu trúc của các đối tượng cơ sở dữ liệu, bao gồm ALTER VIEW để thêm cột mới vào định nghĩa view. Ví dụ: ALTER VIEW TenView AS SELECT CotMoi, * FROM Bang;. Điều này cập nhật view mà không ảnh hưởng dữ liệu gốc, phù hợp hoàn hảo với yêu cầu.
📘 Nguồn tham khảo:

• AWS RDS Documentation (2026): Amazon RDS SQL Server ALTER VIEW.
• Microsoft SQL Docs: ALTER VIEW (Transact-SQL).

🔍 Giải thích tất cả các phương án (đúng và sai)

• [SAI] MERGE
  ❌ Phương án sai: Lệnh MERGE dùng để kết hợp INSERT, UPDATE, DELETE dựa trên điều kiện khớp dữ liệu (upsert operation), thường áp dụng cho bảng (table) chứ không phải view. Nó không sửa đổi cấu trúc view hay thêm cột mới. Sử dụng MERGE ở đây sẽ gây lỗi syntax.

• [ĐÚNG] ALTER
  ✅ Phương án đúng: Như đã giải thích ở trên, ALTER VIEW là cách chuẩn để thay đổi định nghĩa view, thêm cột mới một cách linh hoạt. Đây là lựa chọn duy nhất phù hợp với yêu cầu sửa đổi cấu trúc.

• [SAI] INSERT
  ❌ Phương án sai: Lệnh INSERT chỉ dùng để thêm hàng dữ liệu mới (rows) vào bảng hoặc view updatable, không thêm cột vào cấu trúc view. View thường không cho phép INSERT trực tiếp trừ trường hợp đặc biệt, và dù sao cũng không giải quyết vấn đề thêm cột.

• [SAI] UPDATE
  ❌ Phương án sai: Lệnh UPDATE dùng để cập nhật giá trị dữ liệu hiện có trong các hàng của bảng hoặc view updatable, không thay đổi cấu trúc (như thêm cột). Nó chỉ ảnh hưởng dữ liệu, không phải định nghĩa view.

🛡️ Lưu ý bổ sung: Trong AWS RDS (2026), tất cả các engine như PostgreSQL 16+ hay MySQL 8.4+ đều hỗ trợ ALTER VIEW tương tự, đảm bảo tính tương thích cao. Nếu view phức tạp (materialized view), có thể cần REFRESH sau ALTER, nhưng câu hỏi cơ bản nên ALTER là đủ!

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

Câu hỏi trắc nghiệm: "Which Azure storage solution provides native support for POSIX-compliant access control lists (ACLs)?"
📖 Giải thích rõ ràng: Câu hỏi đang tìm kiếm giải pháp lưu trữ dữ liệu trong Microsoft Azure hỗ trợ tự nhiên (native) các Access Control Lists (ACLs) tuân thủ chuẩn POSIX. POSIX ACLs là cơ chế kiểm soát truy cập chi tiết theo chuẩn Unix/Linux (Portable Operating System Interface), cho phép quản lý quyền truy cập ở mức thư mục và file một cách tinh vi (như read, write, execute cho owner, group, others, và các ACL mở rộng). "Native support" nghĩa là dịch vụ hỗ trợ trực tiếp mà không cần lớp trung gian hoặc cấu hình phức tạp. Đây là kiến thức cốt lõi trong Azure Storage cho big data và analytics, cập nhật đến năm 2026 với Azure Data Lake Storage Gen2 (ADLS Gen2) làm nền tảng chính (phiên bản mới nhất tích hợp hierarchical namespace và ACL POSIX đầy đủ).

✅ Đáp án đúng: Azure Data Lake Storage

Lý do lựa chọn:
🛠️ Azure Data Lake Storage (cụ thể là Gen2) hỗ trợ native POSIX ACLs ngay từ hierarchical namespace, cho phép kiểm soát truy cập tinh vi ở mức file/thư mục theo chuẩn POSIX (bao gồm ACL cơ bản và mở rộng). Điều này lý tưởng cho workload big data, analytics với tích hợp Apache Hadoop, Spark. Không cần SMB hay NFS gateway, hỗ trợ trực tiếp qua REST API, ABFS driver.
📘 Dẫn nguồn: Microsoft Docs - Access control model in Data Lake Storage Gen2 (cập nhật 2025-2026, xác nhận POSIX ACLs là tính năng core).

📋 Giải thích tất cả các phương án (đúng/sai)

• Azure Table storage ❌ Sai: Đây là dịch vụ NoSQL key-value store cho dữ liệu semi-structured (như JSON), không hỗ trợ ACLs POSIX vì không phải file storage. Quyền truy cập chỉ qua Shared Access Signature (SAS) hoặc RBAC/IAM, không có khái niệm file/folder POSIX. Phù hợp metadata/query nhanh, không phải analytics file-based.
• Azure Data Lake Storage ✅ Đúng: Như đã giải thích ở trên, native hỗ trợ POSIX ACLs đầy đủ (rwx permissions, named users/groups), tích hợp với Azure AD và ACLs cho security model lai. Hoàn hảo cho data lake scenarios.
• Azure Queue storage ❌ Sai: Dịch vụ message queuing cho decoupling apps (FIFO queues), không liên quan đến file storage hay ACLs POSIX. Chỉ hỗ trợ message-level access qua SAS/RBAC, không có file hierarchy.
• Azure Files ❌ Sai: Hỗ trợ SMB/NFS shares với NTFS ACLs (Windows-style) hoặc SMB ACLs, không native POSIX ACLs. Có thể map POSIX qua NFS 4.1 (experimental ở 2026), nhưng yêu cầu gateway và không "native" như ADLS Gen2. Phù hợp file shares enterprise, không phải data lake.

🧠 Kết luận: Câu hỏi kiểm tra sự khác biệt giữa storage types trong Azure – ADLS Gen2 dẫn đầu về POSIX compliance cho big data! Nếu cần thực hành lab, thử Azure Portal tạo ADLS Gen2 và set ACLs. 🚀

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

📘 Nội dung câu hỏi:
Câu hỏi yêu cầu xác định loại cơ sở dữ liệu của Azure Database for PostgreSQL. Đây là một dịch vụ cơ sở dữ liệu được cung cấp bởi Microsoft Azure, dựa trên công cụ mã nguồn mở PostgreSQL. Câu hỏi tập trung vào mô hình triển khai (deployment model) của dịch vụ này trên đám mây Azure, giúp phân biệt giữa các loại dịch vụ đám mây khác nhau như PaaS, IaaS, hoặc các hình thức triển khai khác. Azure Database for PostgreSQL cho phép người dùng tập trung vào ứng dụng mà không cần quản lý hạ tầng bên dưới, với các tính năng như tự động scale, backup, và bảo mật được Azure quản lý hoàn toàn. (Kiến thức cập nhật đến 2026: Dịch vụ vẫn duy trì mô hình PaaS chính, với các tùy chọn như Flexible Server và Hyperscale (Citus) – theo tài liệu Azure mới nhất).

✅ Đáp án đúng: Platform as a service (PaaS)
Lý do lựa chọn: Azure Database for PostgreSQL là dịch vụ PaaS thuần túy, nơi Microsoft quản lý toàn bộ hạ tầng, hệ điều hành, và các tác vụ bảo trì cơ bản (như patching, backup tự động, scaling). Người dùng chỉ cần cấu hình và sử dụng database mà không lo lắng về máy chủ vật lý hoặc ảo. Điều này phù hợp với định nghĩa PaaS của Azure, giúp phát triển nhanh chóng và tiết kiệm chi phí. (Nguồn: Microsoft Docs - Azure Database for PostgreSQL overview).

🛠️ Giải thích tất cả các phương án trả lời

• ✅ Platform as a service (PaaS):
  Đúng! Đây là mô hình chính xác. Azure Database for PostgreSQL thuộc loại PaaS, cung cấp database-as-a-service (DBaaS) đầy đủ, với Azure chịu trách nhiệm quản lý hạ tầng, giúp developer tập trung vào dữ liệu và ứng dụng. Không cần cài đặt PostgreSQL thủ công.

• ❌ Infrastructure as a service (IaaS):
  Sai! IaaS chỉ cung cấp tài nguyên hạ tầng cơ bản như máy ảo (VM), lưu trữ, mạng (ví dụ: Azure Virtual Machines). Với IaaS, người dùng phải tự quản lý OS, database engine, và bảo trì – không giống Azure Database for PostgreSQL, vốn là PaaS đã được quản lý sẵn.

• ❌ Microsoft SQL Server:
  Sai! Microsoft SQL Server là một hệ quản trị cơ sở dữ liệu quan hệ (RDBMS) riêng biệt của Microsoft, không phải loại hình triển khai. Azure Database for PostgreSQL dựa trên PostgreSQL mã nguồn mở, không phải SQL Server (dù Azure có Azure SQL Database cho SQL Server).

• ❌ on-premises:
  Sai! "On-premises" nghĩa là triển khai tại chỗ (trên phần cứng vật lý của doanh nghiệp), không phải dịch vụ đám mây. Azure Database for PostgreSQL chỉ chạy trên hạ tầng đám mây Azure, không hỗ trợ triển khai on-premises (dù bạn có thể cài PostgreSQL thủ công trên server on-prem).

📚 Tài liệu tham khảo chính thức (cập nhật 2026):

• Azure Database for PostgreSQL - Microsoft Learn
• Cloud deployment models on Azure
  Hy vọng phân tích này giúp bạn nắm vững kiến thức Azure Data Fundamentals! 🚀

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

Câu hỏi trắc nghiệm: "Which storage solution supports access control lists (ACLs) at the file and folder level?"
📖 Giải thích rõ ràng: Câu hỏi đang hỏi về giải pháp lưu trữ nào trong Azure hỗ trợ Access Control Lists (ACLs) ở mức độ file (tệp) và folder (thư mục). ACLs là cơ chế kiểm soát quyền truy cập chi tiết (như đọc, ghi, thực thi) theo kiểu POSIX, cho phép quản lý quyền truy cập mịn màng ở cấp độ phân cấp (hierarchical namespace). Đây là tính năng quan trọng cho các workload phân tích dữ liệu lớn (big data), nơi cần kiểm soát quyền truy cập chính xác mà không chỉ giới hạn ở cấp container hoặc bucket.
🛠️ Bối cảnh Azure: Trong Azure Storage, không phải tất cả dịch vụ đều hỗ trợ ACLs ở mức file/folder. Tính năng này được thiết kế đặc biệt cho các giải pháp lưu trữ phân tích dữ liệu, cập nhật mới nhất đến năm 2026 (Azure Data Lake Storage Gen2 với hierarchical namespace enabled).

✅ Đáp án đúng: Azure Data Lake Storage

Lý do lựa chọn:
✅ Azure Data Lake Storage (Gen2) hỗ trợ đầy đủ ACLs POSIX-compliant ở mức root, folder và file level, cho phép thiết lập quyền truy cập chi tiết cho từng người dùng, nhóm hoặc dịch vụ (như Owner, Access ACLs). Điều này lý tưởng cho môi trường đa người dùng, tích hợp với Azure AD và tích hợp liền mạch với Azure Synapse, Databricks. Không có giải pháp nào khác trong danh sách hỗ trợ mức độ chi tiết tương tự.
📘 Nguồn tham khảo: Microsoft Docs - Access control model in Azure Data Lake Storage Gen2 (cập nhật 2025-2026).

📋 Giải thích tất cả các phương án

Dưới đây là phân tích từng lựa chọn (giữ nguyên văn bản gốc tiếng Anh), với lý do đúng/sai dựa trên tính năng Azure mới nhất:

✅ Azure Data Lake Storage

• Đúng vì: Như đã giải thích ở trên, hỗ trợ ACLs đầy đủ ở file/folder level với hierarchical namespace. 🏆

❌ Azure Queue storage

• Sai vì: Đây là dịch vụ lưu trữ hàng đợi tin nhắn (queues) cho messaging patterns (FIFO), chỉ hỗ trợ Shared Access Signatures (SAS) hoặc Azure AD auth ở mức queue level, không có khái niệm file/folder hay ACLs POSIX. Không phù hợp cho dữ liệu phân cấp. 🚫

❌ Azure Blob storage

• Sai vì: Blob Storage (standard) hỗ trợ ACLs chỉ ở mức container và blob level (không hierarchical folders thực thụ trừ khi enable Data Lake Gen2). ACLs cơ bản hơn, không hỗ trợ POSIX-style ở folder/file như Data Lake. Blob coi thư mục là prefix ảo, thiếu ACL mịn màng. 🔒

❌ Azure Cosmos DB

• Sai vì: Đây là NoSQL database đa model (document, graph, key-value), hỗ trợ RBAC và IAM qua Azure AD, nhưng không phải storage file-based, không có file/folder hay ACLs POSIX. Tập trung vào truy vấn JSON dữ liệu, không phải hierarchical filesystem. 🗄️

🧠 Kết luận: Câu hỏi kiểm tra sự khác biệt giữa các dịch vụ Azure Storage, nhấn mạnh Azure Data Lake Storage là lựa chọn tối ưu cho access control chi tiết trong analytics workloads. Nếu cần thực hành, hãy thử tạo ACL qua Azure Portal hoặc CLI! 🎯

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

Câu hỏi gốc: What is a characteristic of batch processing?
(Dịch nghĩa: Đặc điểm nào của xử lý theo lô (batch processing)?)

🛠️ Giải thích nội dung câu hỏi:
Câu hỏi tập trung vào một đặc trưng cốt lõi của batch processing (xử lý theo lô) trong lĩnh vực dữ liệu lớn và điện toán đám mây, đặc biệt liên quan đến AWS. Batch processing là phương pháp xử lý dữ liệu theo các lô lớn (batch) được thu thập trong một khoảng thời gian, thay vì xử lý thời gian thực (real-time). Nó phù hợp cho các công việc không yêu cầu độ trễ thấp, như báo cáo hàng ngày, phân tích lịch sử dữ liệu, ETL (Extract-Transform-Load) lớn. Trong AWS, các dịch vụ như AWS Batch, Amazon EMR (với Hadoop/Spark), AWS Glue hỗ trợ batch processing hiệu quả cho dữ liệu quy mô lớn, với kiến thức cập nhật đến năm 2026 (phiên bản AWS Batch v2.0+ hỗ trợ container orchestration linh hoạt hơn). Câu hỏi kiểm tra sự hiểu biết về sự khác biệt giữa batch (có độ trễ) và stream processing (real-time).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: There is a noticeable time delay between ingesting data and obtaining the data processing results.

Lý do:
🧩 Đây là đặc trưng chính của batch processing: dữ liệu được thu thập, lưu trữ tạm thời (ví dụ: vào S3), sau đó xử lý theo lịch trình hoặc kích hoạt thủ công, dẫn đến độ trễ đáng kể (thường từ phút đến giờ/ngày) giữa việc ingest dữ liệu và nhận kết quả. Trong AWS Batch (cập nhật 2026), job queue xử lý lô lớn có thể mất thời gian để scale resources, khác biệt rõ với streaming (như Kinesis với latency <1 giây). Điều này giúp tối ưu chi phí cho workload không khẩn cấp.

📋 Giải thích tất cả các phương án (đúng/sai)

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá với lý do chi tiết dựa trên kiến thức AWS mới nhất:

• ❌ [SAI] The data ingested during batch processing must be processed as soon as the data is received.
  Giải thích sai: Phương án này mô tả stream processing (xử lý luồng), không phải batch. Trong batch processing (AWS Batch/EMR), dữ liệu được buffer và xử lý sau, không yêu cầu "ngay lập tức" để tránh lãng phí tài nguyên. Ví dụ: AWS Glue job chạy hàng giờ một lần, không real-time.

• ❌ [SAI] Large datasets must be split into batches of less than 1 GB before the data can be processed.
  Giải thích sai: Batch processing hỗ trợ dataset lớn vượt quá 1GB (thậm chí petabyte-scale) mà không cần split cứng nhắc dưới 1GB. AWS EMR/Spark xử lý partition tự động theo cluster size (cập nhật 2026: hỗ trợ instance lớn hơn với Graviton4). Giới hạn 1GB là không chính xác, chỉ là best practice tùy trường hợp.

• ✅ [ĐÚNG] There is a noticeable time delay between ingesting data and obtaining the data processing results.
  Giải thích đúng: Như đã nêu ở trên, đây là đặc trưng cốt lõi: độ trễ tồn tại do dữ liệu chờ batch đầy đủ hoặc lịch trình. AWS Well-Architected Framework (Data Analytics Lens 2026) nhấn mạnh batch phù hợp cho "non-latency-sensitive" workloads.

• ❌ [SAI] Batch processing can only process data that is structured.
  Giải thích sai: Batch processing linh hoạt với cả structured (SQL) và unstructured/semi-structured (JSON, logs, images). AWS Glue/EMR hỗ trợ Spark cho dữ liệu đa dạng, không giới hạn structured (cập nhật 2026: tích hợp Iceberg cho schema evolution).

📘 Tài liệu tham khảo

• AWS Batch User Guide: docs.aws.amazon.com/batch/latest/userguide/what-is-batch.html (cập nhật 2026: Batch on Fargate/EKS).
• AWS Well-Architected Framework - Data Analytics Lens: aws.amazon.com/architecture/well-architected/lenses/data-analytics.
• Amazon EMR Documentation: docs.aws.amazon.com/emr/latest/ManagementGuide/emr-overview.html.

Hy vọng phân tích này giúp bạn nắm vững khái niệm! 🚀 Nếu cần thêm ví dụ AWS, hãy hỏi nhé!

🧩 Giải thích nội dung câu hỏi

Câu hỏi tập trung vào thuộc tính của một workload giao dịch (transactional workload) trong hệ thống cơ sở dữ liệu, cụ thể là thuộc tính nào đảm bảo rằng mỗi giao dịch được xử lý như một đơn vị duy nhất (single unit), nghĩa là giao dịch hoặc thành công hoàn toàn (succeeds completely) hoặc thất bại hoàn toàn (fails completely).

📘 Đây là một phần của nguyên tắc ACID (Atomicity, Consistency, Isolation, Durability) – nền tảng cho các hệ thống cơ sở dữ liệu giao dịch đáng tin cậy. Trong AWS (như Amazon RDS, Aurora, DynamoDB với chế độ transaction), các thuộc tính này đảm bảo tính toàn vẹn dữ liệu. Kiến thức này không thay đổi đến năm 2026, vẫn dựa trên chuẩn ACID từ phiên bản AWS mới nhất (Aurora MySQL/PostgreSQL v3.x hỗ trợ ACID đầy đủ). Câu hỏi kiểm tra sự hiểu biết cơ bản về Atomicity trong ngữ cảnh workload giao dịch.

✅ Đáp án đúng: atomicity

Lý do lựa chọn: Atomicity chính là thuộc tính đảm bảo giao dịch được coi như một đơn vị nguyên tử (atomic unit) – tất cả các thao tác trong giao dịch phải thành công cùng lúc hoặc không thao tác nào được thực hiện (rollback). Điều này khớp chính xác với mô tả "succeeds completely or fails completely" trong câu hỏi. Trong AWS, ví dụ RDS sử dụng atomicity để tránh trạng thái dữ liệu nửa vời.

🛠️ Phân tích chi tiết tất cả các phương án

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với giải thích bằng tiếng Việt:

• atomicity ✅ ĐÚNG
  Thuộc tính này đảm bảo giao dịch là một đơn vị không thể chia cắt: nếu bất kỳ phần nào thất bại, toàn bộ giao dịch sẽ bị hủy bỏ (rollback), tránh dữ liệu không nhất quán. Trong AWS DynamoDB Transactions (từ 2018, cập nhật 2026 vẫn giữ nguyên), atomicity hỗ trợ multi-item transactions chính xác như vậy.

• isolation ❌ SAI
  Isolation đảm bảo các giao dịch khác nhau không ảnh hưởng lẫn nhau, như đọc dữ liệu "bẩn" (dirty reads) hoặc phantom reads. Nó không liên quan đến việc giao dịch thành công/fail hoàn toàn, mà tập trung vào sự cô lập giữa các giao dịch song song. AWS Aurora sử dụng isolation levels như Serializable để kiểm soát điều này.

• durability ❌ SAI
  Durability đảm bảo rằng sau khi giao dịch commit thành công, dữ liệu sẽ được lưu trữ vĩnh viễn, ngay cả khi hệ thống gặp sự cố (nhờ write-ahead logging). Nó không đảm bảo "single unit succeeds/fails", mà chỉ về tính bền vững sau commit. AWS RDS Multi-AZ deployment tăng cường durability lên 99.99%.

• consistency ❌ SAI
  Consistency đảm bảo dữ liệu luôn tuân thủ các quy tắc toàn vẹn (constraints, triggers) trước và sau giao dịch, đưa cơ sở dữ liệu từ trạng thái hợp lệ này sang hợp lệ khác. Nó không trực tiếp xử lý việc giao dịch là đơn vị hoàn chỉnh, mà về tính nhất quán dữ liệu. DynamoDB hỗ trợ consistency qua strong/global consistency models.

📘 Tài liệu tham khảo

• AWS Documentation: Amazon RDS ACID Compliance (cập nhật 2024-2026).
• AWS DynamoDB Transactions: Developer Guide.
• Nguyên tắc ACID chuẩn: IBM & Oracle docs, áp dụng chung cho cloud databases.

Hy vọng phân tích này giúp bạn nắm vững kiến thức Azure Data Fundamentals liên quan đến khái niệm database chung! 🚀

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

📖 Nội dung câu hỏi:
Câu hỏi yêu cầu xác định loại data store (kho lưu trữ dữ liệu) dựa trên cấu trúc được minh họa trong hình ảnh. Hình ảnh thể hiện một biểu đồ đồ thị (graph) với các nút (nodes) đại diện cho các thực thể như Employee (Nhân viên) và Department (Phòng ban), được kết nối bởi các cạnh (edges) có nhãn chỉ mối quan hệ như "Works in" (Làm việc tại) và "Reports to" (Báo cáo cho).

Cụ thể, từ hình ảnh:

• Employee (Sue) → Works in → Department (Sales).
• Sue → Reports to → Employee (Frank).
• Employee (Bob) → Works in → Department (Accounts).
• Frank → Reports to → (mối quan hệ khác, nhưng tổng thể là cây đồ thị).
• Employee (Jon) → Works in → Department (Marketing).

🛠️ Đặc trưng chính: Cấu trúc này không phải là dữ liệu phẳng (như bảng), mà là mạng lưới các mối quan hệ phức tạp, nơi dữ liệu được lưu trữ dưới dạng nút và cạnh, rất phù hợp để truy vấn mối quan hệ (ví dụ: "Ai báo cáo cho Sue?" hoặc "Nhân viên nào làm ở Sales?"). Đây là đặc trưng điển hình của graph database trong AWS, như dịch vụ Amazon Neptune (hỗ trợ Property Graph và RDF, cập nhật đến 2026 với các tính năng như Neptune Analytics cho graph queries nhanh hơn).

✅ Đáp án đúng: graph
Lý do lựa chọn: ✅ Cấu trúc hình ảnh rõ ràng là graph data store vì nó sử dụng nodes (Employee, Department) và directed edges (Works in, Reports to) để biểu diễn mối quan hệ. Trong AWS, graph databases như Neptune được thiết kế chính xác cho mô hình này, cho phép truy vấn hiệu quả các mối quan hệ phức tạp (sử dụng Gremlin hoặc SPARQL). Kiến thức cập nhật 2026: Neptune hỗ trợ serverless và IAM authentication mới, lý tưởng cho workload graph như khuyến nghị sản phẩm hoặc mạng xã hội.

📘 Giải thích tất cả các phương án (đúng/sai)

• key/value ❌
  ❌ Sai vì key/value store (như Amazon DynamoDB) lưu trữ dữ liệu dưới dạng cặp khóa-giá trị đơn giản (key → value blob), không hỗ trợ cấu trúc mối quan hệ phức tạp như nút-cạnh trong hình. Hình ảnh có nhiều mối quan hệ đa hướng (works in, reports to), không phải lookup đơn lẻ.

• object data ❌
  ❌ Sai vì object data store (như Amazon S3) lưu trữ dữ liệu dưới dạng file/object không cấu trúc (hình ảnh, video), tập trung vào lưu trữ scalable với metadata đơn giản. Hình không phải file blob mà là mạng lưới quan hệ có cấu trúc.

• graph ✅
  ✅ Đúng như đã giải thích ở trên. Đây là mô hình chuẩn của graph database, tối ưu cho traversal (duyệt đồ thị) và pattern matching. Trong AWS, Neptune là dịch vụ chính (cập nhật 2026: hỗ trợ Neptune Streams cho CDC và integration với SageMaker).

• time series ❌
  ❌ Sai vì time series store (như Amazon Timestream) chuyên lưu trữ dữ liệu theo thời gian (timestamp + measures), ví dụ IoT metrics hoặc logs. Hình ảnh không có yếu tố thời gian, chỉ là mối quan hệ tĩnh giữa entities.

📚 Tài liệu tham khảo

• AWS Neptune Documentation: Graph Databases on AWS (cập nhật 2026 features tại AWS re:Invent 2025).
• AWS Data Store Types: Choosing the Right Database – Phân loại rõ graph vs. key-value/object/time-series.
• Exam reference: ExamTopics AZ-900/AWS Certified Cloud Practitioner (hình ảnh từ practice exam 04277).

Hy vọng phân tích này giúp bạn nắm vững kiến thức data fundamentals! 🚀

🧩 Giải thích nội dung câu hỏi

Câu hỏi "Which type of database contains nodes and edges?" đang hỏi về loại cơ sở dữ liệu nào chứa các nút (nodes) và các cạnh (edges). Đây là khái niệm cốt lõi trong thiết kế cơ sở dữ liệu, nơi nodes đại diện cho các thực thể (như người dùng, sản phẩm) và edges đại diện cho mối quan hệ giữa chúng (như "bạn bè với", "mua từ"). Loại cơ sở dữ liệu này rất phù hợp để xử lý dữ liệu có cấu trúc phức tạp với nhiều mối quan hệ, thường được sử dụng trong các ứng dụng như mạng xã hội, khuyến nghị sản phẩm hoặc phát hiện gian lận. Trong AWS, dịch vụ tiêu biểu là Amazon Neptune (graph database), hỗ trợ các mô hình như Property Graph và RDF, với cập nhật mới nhất đến năm 2026 vẫn giữ nguyên kiến trúc nodes-edges làm nền tảng (theo AWS re:Invent 2025 announcements).

✅ Đáp án đúng: graph

Lý do chọn đáp án này:
Graph database là loại cơ sở dữ liệu duy nhất được thiết kế chuyên biệt để lưu trữ dữ liệu dưới dạng nodes (nút) và edges (cạnh), cho phép truy vấn mối quan hệ nhanh chóng và hiệu quả qua các ngôn ngữ như Gremlin hoặc SPARQL. Trong AWS, Amazon Neptune là dịch vụ graph database hỗ trợ đa mô hình, xử lý hàng tỷ nodes/edges với độ trễ thấp (cập nhật Neptune Serverless v2.0 năm 2025 tăng scalability lên 10x). Đây là lựa chọn chuẩn xác nhất! 🏆

📋 Phân tích tất cả các phương án (dựa trên kiến thức AWS mới nhất đến 2026)

• graph ✅ Đúng: Như đã giải thích, đây là loại database cốt lõi sử dụng nodes và edges để mô hình hóa dữ liệu quan hệ. AWS Neptune là ví dụ điển hình, hỗ trợ Gremlin, SPARQL và tích hợp IAM authentication mới (2025). Không có loại nào khác khớp chính xác khái niệm này.
  Nguồn: AWS Neptune Documentation (docs.aws.amazon.com/neptune/ latest/userguide/what-is-neptune.html).

• key/value ❌ Sai: Key/value database (như Amazon DynamoDB) lưu trữ dữ liệu dưới dạng cặp khóa-giá trị đơn giản (key-value pairs), không sử dụng nodes hay edges. Nó tối ưu cho dữ liệu không cấu trúc, truy xuất nhanh theo key, nhưng không xử lý mối quan hệ phức tạp. DynamoDB cập nhật 2026 với Global Tables v2 vẫn giữ mô hình này.
  Nguồn: AWS DynamoDB Developer Guide (docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html).

• columnar ❌ Sai: Columnar database (hay column-family, như Amazon Redshift hoặc Cassandra) lưu trữ dữ liệu theo cột (columns) để tối ưu phân tích OLAP và nén dữ liệu lớn. Không có nodes/edges; tập trung vào hàng/cột. Redshift RA3 nodes (2025 update) cải thiện analytics nhưng vẫn columnar thuần túy.
  Nguồn: AWS Redshift User Guide (docs.aws.amazon.com/redshift/latest/mgmt/welcome.html).

• time series ❌ Sai: Time series database (như Amazon Timestream) chuyên lưu dữ liệu theo chuỗi thời gian (timestamps với metrics), tối ưu cho IoT, monitoring. Không sử dụng nodes/edges mà dùng partitions theo thời gian. Timestream for LiveAnalytics (2026 preview) thêm ML integration nhưng vẫn giữ mô hình time-based.
  Nguồn: AWS Timestream Developer Guide (docs.aws.amazon.com/timestream/latest/developerguide/what-is.html).

🛠️ Lời khuyên học tập: Hãy thực hành với AWS Free Tier trên Neptune để query graph dữ liệu thực tế (ví dụ: dùng Gremlin console). Nếu cần Azure tương đương, Gremlin API trên Cosmos DB cũng hỗ trợ graph! 📘 Tài liệu tổng hợp: AWS Database Blog (aws.amazon.com/blogs/database/) - cập nhật 2026.