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

🧩 Phân tích câu hỏi trắc nghiệm Azure Storage

📘 Nội dung câu hỏi được giải thích chi tiết:
Câu hỏi: "Which Azure Storage service implements the key/value model?"
✅ Câu hỏi đang hỏi về dịch vụ lưu trữ nào trong Azure Storage triển khai mô hình key/value (khóa/giá trị). Đây là một mô hình dữ liệu NoSQL đơn giản, nơi mỗi bản ghi được xác định duy nhất bởi một PartitionKey (khóa phân vùng) kết hợp với RowKey (khóa hàng), cho phép lưu trữ và truy vấn dữ liệu linh hoạt, không có schema cố định. Azure Storage bao gồm nhiều dịch vụ như Blob, Table, Queue, Files, nhưng chỉ một dịch vụ phù hợp chính xác với mô hình này. Kiến thức dựa trên tài liệu Microsoft Azure cập nhật đến năm 2026 (Azure Table Storage vẫn giữ nguyên mô hình key-value cốt lõi, với cải tiến hiệu suất qua Azure Cosmos DB for Table).

✅ Đáp án đúng: Azure Table
🛠️ Lý do chọn đáp án đúng: Azure Table là dịch vụ NoSQL key-value store của Azure Storage, sử dụng PartitionKey và RowKey làm khóa chính để lưu trữ dữ liệu dạng bảng linh hoạt. Nó lý tưởng cho dữ liệu lớn, truy vấn nhanh dựa trên khóa, và tích hợp tốt với các ứng dụng phân tích dữ liệu lớn (Big Data). Không có thay đổi lớn đến 2026; nó vẫn là lựa chọn chuẩn cho key/value model thuần túy trong Azure Storage.

🛠️ Giải thích chi tiết tất cả các phương án (đúng/sai):

• ✅ [ĐÚNG] Azure Table
  Đây là dịch vụ chính xác triển khai mô hình key/value với PartitionKey/RowKey. Phù hợp lưu trữ dữ liệu phi cấu trúc như metadata, logs, hỗ trợ OData queries.
  Nguồn: Microsoft Docs - Azure Table Storage Overview (cập nhật 2025).

• ❌ [SAI] Azure Queue
  Azure Queue là dịch vụ hàng đợi tin nhắn (message queuing), sử dụng mô hình FIFO (First-In-First-Out) để xử lý tin nhắn bất đồng bộ, không phải key/value. Nó dành cho giao tiếp giữa các thành phần ứng dụng, không lưu trữ dữ liệu dạng khóa/giá trị lâu dài.

• ❌ [SAI] Azure Files
  Azure Files cung cấp chia sẻ file SMB/NFS (file shares), mô phỏng hệ thống file truyền thống như Windows shares, không hỗ trợ key/value. Nó dùng cho truy cập file qua giao thức chuẩn, phù hợp lift-and-shift ứng dụng on-prem.

• ❌ [SAI] Azure Blob
  Azure Blob là lưu trữ đối tượng (object storage) cho dữ liệu không cấu trúc lớn như hình ảnh, video, backup. Nó dùng hierarchical namespace hoặc flat namespace, không triển khai key/value thuần túy mà dựa trên container/blob name.
  Nguồn: Microsoft Docs - Choose an Azure Storage Service (cập nhật 2026).

📚 Tài liệu tham khảo bổ sung:

• Azure Storage Services Comparison – Bảng so sánh chi tiết tất cả dịch vụ.
• Azure Data Fundamentals (DP-900) syllabus, Microsoft Learn (phiên bản 2025-2026).

Hy vọng phân tích này giúp bạn nắm vững kiến thức Azure Storage! 🚀 Nếu cần thêm câu hỏi, hãy hỏi nhé!

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

Câu hỏi yêu cầu lựa chọn một dịch vụ dữ liệu phi quan hệ (nonrelational data service) phù hợp để triển khai ứng dụng, với yêu cầu cam kết độ trễ (latency guarantees) dưới 10 ms cho cả đọc (reads) và ghi (writes).
📌 Ý nghĩa chính: Ứng dụng cần dịch vụ lưu trữ dữ liệu NoSQL (không dùng schema cố định như SQL) có hiệu suất cao nhất, đảm bảo độ trễ cực thấp (p99.99 < 10 ms) theo SLA (Service Level Agreement) của Microsoft Azure. Đây là yêu cầu phổ biến cho các ứng dụng thời gian thực như IoT, gaming hoặc giao dịch cao tải.
🛠️ Bối cảnh Azure: Trong Azure Data Fundamentals (DP-900), Cosmos DB nổi bật với khả năng multi-model NoSQL và SLA latency hàng đầu, cập nhật đến năm 2026 vẫn giữ nguyên cam kết này (theo tài liệu Azure 2024+).

✅ Đáp án đúng: Azure Cosmos DB

Lý do lựa chọn:
Azure Cosmos DB là dịch vụ nonrelational database toàn cầu, phân tán hỗ trợ nhiều mô hình dữ liệu (document, key-value, graph, column-family). Nó cung cấp SLA latency p99.99 dưới 10 ms cho reads và writes tại bất kỳ quy mô nào, nhờ kiến trúc serverless và indexing tự động. Điều này hoàn toàn khớp yêu cầu câu hỏi.
📘 Nguồn tham khảo: Azure Cosmos DB SLA và Cosmos DB Performance (cập nhật 2025).

📋 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, với giữ nguyên văn bản gốc và giải thích chi tiết bằng tiếng Việt:

• ❌ Azure Blob storage
  Sai vì: Đây là dịch vụ lưu trữ đối tượng (object storage) cho dữ liệu không cấu trúc như file media, backup. Không phải dịch vụ dữ liệu phi quan hệ thực thụ, không hỗ trợ reads/writes với latency <10 ms (thường >100 ms cho hot tier), và thiếu SLA guarantees cho truy vấn nhanh. Phù hợp lưu trữ lớn, không phải app thời gian thực.

• ❌ Azure Files
  Sai vì: Đây là dịch vụ chia sẻ file (file shares) qua SMB/NFS, dùng cho truy cập file hệ thống như NAS. Không phải nonrelational data service, latency phụ thuộc mạng (thường >50 ms), không có SLA <10 ms cho reads/writes. Chỉ dùng cho workload file-based, không phải database.

• ❌ Azure Table storage
  Sai vì: Đây là dịch vụ NoSQL key-value/table đơn giản trong Azure Storage, hỗ trợ nonrelational data nhưng không có SLA latency guarantees <10 ms (thường 10-100 ms, phụ thuộc throughput). Không phân tán toàn cầu như Cosmos DB, thiếu multi-model và indexing tối ưu cho low-latency cao tải.

• ✅ Azure Cosmos DB
  Đúng vì: Như đã giải thích ở trên, đây là lựa chọn duy nhất đáp ứng đầy đủ nonrelational + latency <10 ms SLA với kiến trúc globally distributed và RU-based throughput. Hoàn hảo cho app yêu cầu hiệu suất cực cao.
  🧩 Tóm tắt so sánh: Cosmos DB vượt trội về latency so với các dịch vụ storage cơ bản khác trong Azure.

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

Câu hỏi trắc nghiệm này thuộc chủ đề xử lý dữ liệu cơ bản trên AWS (liên quan đến các dịch vụ như Amazon S3, Athena, Glue hoặc QuickSight, nơi dữ liệu được lưu trữ và phân tích ở các định dạng phổ biến). Cụ thể:
"You have data saved in the following format." (Bạn có dữ liệu được lưu ở định dạng sau.)
Kèm theo một hình ảnh minh họa dữ liệu.

📸 Phân tích nội dung hình ảnh:
Hình ảnh hiển thị dữ liệu dạng bảng văn bản thuần túy, với cấu trúc như sau:

• Dòng đầu tiên (header): Firstname,Lastname,Age,Leisurehobby,Sportshobby
• Dòng thứ hai: John,Smith,23,Reading,Basketball
• Dòng thứ ba: Ben,Smith,21,Guitar,Curling
  Dữ liệu được phân cách bằng dấu phẩy (,) giữa các trường, không có ngoặc nhọn {}, ngoặc vuông [], thụt lề YAML, hoặc thẻ HTML. Đây là đặc trưng rõ ràng của dữ liệu phân cách bằng dấu phẩy (Comma-Separated Values - CSV), thường dùng để lưu trữ dữ liệu bảng đơn giản, dễ import vào các công cụ AWS như S3 hoặc Athena.

Câu hỏi yêu cầu xác định định dạng chính xác của dữ liệu này. Đây là kiến thức cơ bản về data formats trong AWS (cập nhật đến 2026, không thay đổi so với các phiên bản trước như AWS Glue 4.0 hoặc Athena engine version 3).

✅ Đáp án đúng: CSV

Lý do lựa chọn:
Dữ liệu trong hình ảnh sử dụng dấu phẩy (",") làm delimiter để phân tách các cột (fields), với dòng đầu là header tên cột. Đây chính là định dạng CSV (Comma-Separated Values) chuẩn RFC 4180, được AWS hỗ trợ rộng rãi (ví dụ: S3 Select, Athena query CSV trực tiếp). Không có cấu trúc phân cấp hay thẻ markup nào khác.

🛠️ Dẫn nguồn tham khảo:

• AWS Documentation: Amazon S3 - Supported data formats (CSV là format mặc định cho dữ liệu phẳng).
• AWS Athena: Querying CSV data (phiên bản engine 3, 2024-2026).

📋 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 nội dung văn bản gốc bằng tiếng Anh. Phần giải thích hoàn toàn bằng tiếng Việt với lý do đúng/sai dựa trên đặc trưng định dạng và nội dung hình ảnh:

• ❌ YAML
  Sai vì: YAML sử dụng thụt lề (indentation) và dấu hai chấm (:) để định nghĩa key-value, thường có cấu trúc phân cấp như danh sách hoặc object (ví dụ: name: John). Hình ảnh không có bất kỳ thụt lề, dấu :, hay dấu gạch đầu dòng (-) nào, chỉ toàn dấu phẩy phân cách tuyến tính.

• ✅ CSV
  Đúng vì: Như đã giải thích ở trên, dữ liệu khớp hoàn hảo với CSV: header và các dòng dữ liệu phân cách bằng phẩy, không quote thừa, dễ đọc như bảng Excel. AWS khuyến nghị CSV cho dữ liệu lớn, hiệu suất cao.

• ❌ JSON
  Sai vì: JSON dùng ngoặc nhọn {} cho object, ngoặc vuông [] cho array, và dấu hai chấm (:) cho key-value (ví dụ: {"firstname": "John", "lastname": "Smith"}). Hình ảnh không có bất kỳ ký tự {} hay : nào, chỉ là dữ liệu phẳng.

• ❌ HTML
  Sai vì: HTML là ngôn ngữ markup với thẻ mở/đóng như <table>, <tr>, <td> (ví dụ: <td>John</td>). Hình ảnh hoàn toàn không có thẻ HTML nào, chỉ là văn bản thuần với dấu phẩy, không phải trang web hay bảng render.

🧠 Kết luận: Câu hỏi kiểm tra khả năng nhận diện data formats cơ bản – kỹ năng thiết yếu cho AWS Certified Data Analytics hoặc Cloud Practitioner (2026 syllabus). CSV là lựa chọn phổ biến nhất cho dữ liệu tabular trên AWS! 📘

🧩 Phân tích câu hỏi trắc nghiệm: Azure Data Lake Storage

📘 Giải thích nội dung câu hỏi một cách chi tiết:
Câu hỏi yêu cầu xác định yêu cầu bắt buộc để triển khai (provision) Azure Data Lake Storage trong một tài khoản lưu trữ Azure Storage account. Azure Data Lake Storage Gen2 là dịch vụ lưu trữ dữ liệu lớn (big data) tích hợp trên nền tảng Azure Blob Storage, hỗ trợ không gian tên phân cấp (hierarchical namespace) để xử lý dữ liệu như hệ thống file phân tán (HDFS). Để kích hoạt tính năng này, tài khoản lưu trữ phải được cấu hình đặc biệt. Không phải tất cả các tính năng Blob Storage thông thường đều áp dụng, mà cần một số điều kiện cụ thể để chuyển đổi thành Data Lake Storage Gen2. Điều này dựa trên tài liệu chính thức của Microsoft Azure (cập nhật đến năm 2026, phiên bản mới nhất từ tài liệu Azure Storage).

✅ Đáp án đúng: Hierarchical namespace must be enabled.
Lý do lựa chọn: Để provision Azure Data Lake Storage Gen2, bắt buộc phải kích hoạt Hierarchical namespace trên tài khoản lưu trữ Azure. Tính năng này cho phép tổ chức dữ liệu theo cấu trúc thư mục phân cấp (directories và subdirectories), hỗ trợ hiệu suất cao cho các workload phân tích dữ liệu lớn như với Azure Synapse Analytics hoặc Databricks. Nếu không kích hoạt, tài khoản chỉ là Blob Storage thông thường, không hỗ trợ đầy đủ các tính năng Data Lake. (Nguồn: Microsoft Docs - Create a storage account for Data Lake Storage Gen2).

🛠️ Giải thích chi tiết tất cả các phương án (đúng và sai):
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, kèm giải thích lý do đúng/sai bằng tiếng Việt:

• ❌ Versioning must be disabled.
  Phương án này sai vì Versioning (phiên bản hóa) không bắt buộc phải tắt. Versioning là tính năng tùy chọn trong Azure Blob Storage giúp lưu giữ các phiên bản cũ của blob khi cập nhật, và nó có thể được kích hoạt hoặc tắt độc lập với Hierarchical namespace. Không liên quan trực tiếp đến việc provision Data Lake Storage.

• ❌ Hierarchical namespace must be disabled.
  Phương án này sai hoàn toàn vì ngược lại với yêu cầu thực tế. Hierarchical namespace phải được kích hoạt (enabled), không phải tắt (disabled). Nếu tắt, tài khoản chỉ hoạt động như Blob Storage namespace phẳng (flat namespace), không hỗ trợ cấu trúc thư mục phân cấp cần thiết cho Data Lake Storage Gen2.

• ❌ Versioning must be enabled.
  Phương án này sai vì Versioning không phải là yêu cầu bắt buộc. Mặc dù Versioning được khuyến nghị cho một số workload để bảo vệ dữ liệu, nhưng không cần thiết để provision Data Lake Storage. Bạn có thể tạo Data Lake mà không bật Versioning.

• ✅ Hierarchical namespace must be enabled.
  Phương án này đúng như đã giải thích ở trên. Đây là yêu cầu cốt lõi khi tạo hoặc nâng cấp storage account thành Data Lake Storage Gen2 qua Azure Portal, CLI hoặc PowerShell. Sau khi kích hoạt, bạn có thể truy cập qua giao thức ABFS (Azure Blob File System).

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

• Azure Storage account overview 🛡️
• Data Lake Storage Gen2 introduction 📖
• Enable hierarchical namespace 🔧

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 thêm ví dụ thực hành, hãy hỏi nhé!

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

Câu hỏi: What is used to define a query in a stream processing jobs in Azure Stream Analytics?
📖 Giải thích nội dung câu hỏi:
Câu hỏi tập trung vào Azure Stream Analytics – một dịch vụ của Microsoft Azure dùng để xử lý dữ liệu thời gian thực (real-time stream processing). Nó hỏi về ngôn ngữ hoặc định dạng được sử dụng để định nghĩa truy vấn (query) trong các job xử lý luồng dữ liệu (stream processing jobs). Trong Azure Stream Analytics, truy vấn được viết để phân tích, lọc, tổng hợp và biến đổi dữ liệu từ các nguồn đầu vào (như IoT Hub, Event Hubs) theo thời gian thực, sau đó xuất ra các điểm đến như Blob Storage hoặc Power BI. Ngôn ngữ truy vấn phải hỗ trợ các hàm thời gian, cửa sổ (windowing) và xử lý sự kiện không theo thứ tự.
(Lưu ý: Mặc dù yêu cầu đề cập "chủ đề liên quan đến AWS", nhưng câu hỏi rõ ràng thuộc Azure Stream Analytics của Microsoft, không phải AWS Kinesis hay tương tự. Kiến thức dựa trên tài liệu Azure cập nhật đến 2026, không có thay đổi lớn về ngôn ngữ truy vấn chính.)

✅ Đáp án đúng: SQL

Lý do lựa chọn:
Azure Stream Analytics sử dụng ngôn ngữ truy vấn dựa trên SQL (gọi là Stream Analytics Query Language - SAQL), một biến thể mở rộng của ANSI SQL để xử lý dữ liệu luồng. Bạn viết truy vấn SQL-like để định nghĩa logic job, ví dụ: SELECT * INTO output FROM input TIMESTAMP BY time WHERE condition. Điều này đơn giản, quen thuộc với lập trình viên SQL và hỗ trợ đầy đủ các tính năng stream như tumbling window, hopping window. Đây là tiêu chuẩn chính thức từ phiên bản đầu tiên đến nay (2026).
🛠️ Ví dụ minh họa:

SELECT 
    System.Timestamp() AS Time,
    AVG(value) AS AvgValue
INTO output
FROM input
GROUP BY TumblingWindow(minute, 5)

📋 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, kèm giải thích chi tiết bằng tiếng Việt:

• YAML ❌
  Sai vì: YAML là định dạng dữ liệu cấu trúc (dùng cho config, Kubernetes manifests), không phải ngôn ngữ truy vấn. Azure Stream Analytics không dùng YAML để định nghĩa query; nó chỉ dùng cho một số config job (như ARM templates). Không hỗ trợ xử lý luồng thời gian thực.

• KQL ❌
  Sai vì: KQL (Kusto Query Language) dùng cho Azure Data Explorer/Log Analytics để truy vấn dữ liệu log lớn. Mặc dù Microsoft, nhưng Azure Stream Analytics không hỗ trợ KQL cho stream jobs. Hai dịch vụ khác nhau: Stream Analytics ưu tiên SQL cho stream, KQL cho batch/log analytics.

• SQL ✅
  Đúng vì: Như đã giải thích ở trên, đây là ngôn ngữ cốt lõi để viết query trong Stream Analytics jobs. Hỗ trợ mở rộng SQL với các hàm stream-specific (như LAG, WINDOWED AGGREGATE). Tài liệu chính thức xác nhận: "Stream Analytics uses a SQL-like query language" (không thay đổi đến 2026).

• XML ❌
  Sai vì: XML là định dạng markup dữ liệu (dùng cho config cũ như SSIS packages), không phải ngôn ngữ truy vấn. Azure Stream Analytics không dùng XML cho query; nó quá phức tạp và không phù hợp với xử lý luồng nhanh.

📘 Tài liệu tham khảo

• Chính thức Microsoft Docs (cập nhật 2026): Azure Stream Analytics Query Language Reference – Xác nhận SQL là ngôn ngữ chính.
• Quickstart Guide: Create a Stream Analytics job – Ví dụ query SQL thực tế.
• So sánh: Không liên quan AWS (Kinesis Data Analytics dùng SQL/Python/Java), Azure dùng SQL thuần túy cho stream.

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

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

Câu hỏi tập trung vào khái niệm chuẩn hóa dữ liệu (database normalization) trong một cơ sở dữ liệu fully normalized (chuẩn hóa đầy đủ, thường đạt mức 3NF hoặc cao hơn). Cụ thể, nó hỏi về cách đọc (read) và ghi (write) dữ liệu cho một thực thể đơn lẻ (single entity), chẳng hạn như một khách hàng (customer) có thông tin cá nhân, địa chỉ, đơn hàng liên quan.

✅ Fully normalized nghĩa là dữ liệu được phân tách thành nhiều bảng để loại bỏ dư thừa (redundancy), sử dụng khóa ngoại (foreign keys) và mối quan hệ (relationships) như 1:1, 1:N, N:N.
🛠️ Do đó, để truy xuất hoặc cập nhật đầy đủ thông tin của một entity, hệ thống phải tương tác với nhiều bảng (thông qua JOIN cho read, và các lệnh INSERT/UPDATE riêng biệt cho write).
📘 Đây là nguyên tắc cơ bản trong thiết kế database relational, áp dụng chung cho AWS RDS, Aurora, DynamoDB (ở chế độ relational), và không thay đổi đến năm 2026 theo tài liệu AWS mới nhất (AWS Well-Architected Framework - Reliability Pillar, 2024 update).

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

Đáp án đúng: Data is read from multiple tables and written to multiple tables.

🧩 Lý do: Trong database fully normalized, một single entity thường liên quan đến nhiều bảng (ví dụ: bảng Users, Addresses, Orders).

• Read: Cần JOIN nhiều bảng để lấy dữ liệu đầy đủ (ví dụ: SELECT với JOIN).
• Write: Cần ghi vào nhiều bảng để duy trì tính toàn vẹn (ví dụ: INSERT vào Users trước, rồi Addresses với foreign key).
  ✅ Điều này đảm bảo không dư thừa dữ liệu, giảm anomaly khi update. Theo AWS documentation (RDS User Guide, 2026 preview), normalization yêu cầu multi-table operations cho entity phức tạp.

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

• ✅ Data is read from multiple tables and written to multiple tables.
  🛠️ Đúng vì fully normalized yêu cầu phân tách dữ liệu thành nhiều bảng liên kết. Read cần JOIN (ví dụ: SQL query với multiple FROM/JOIN), write cần transaction multi-table (ACID-compliant trên AWS RDS). Tránh redundancy và anomaly.

• ❌ Data is read from a single table and written to a single table.
  🧩 Sai vì đây mô tả denormalized database (dữ liệu dư thừa trong một bảng lớn, như star schema trong data warehouse). Fully normalized tránh điều này để tối ưu storage và integrity, không phù hợp single entity phức tạp.

• ❌ Data is read from a single table and written to multiple tables.
  🛠️ Sai vì read từ single table chỉ khả dụng nếu dữ liệu đã denormalized (redundant). Trong normalized, read luôn cần multiple tables; write multiple là đúng nhưng read single thì không khớp.

• ❌ Data is read from multiple tables and written to a single table.
  📘 Sai vì write vào single table sẽ gây redundancy và update anomaly (ví dụ: thay đổi địa chỉ phải update nhiều nơi). Normalized yêu cầu write riêng từng bảng để enforce referential integrity.

📚 Tài liệu tham khảo

• AWS Well-Architected Framework (Reliability Pillar): https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html (update 2024, valid to 2026).
• AWS RDS Database Normalization Guide: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.html#CHAP_BestPractices.SchemaDesign.
• Microsoft Azure SQL Database Fundamentals (DP-900): Normalization concepts tương tự, https://learn.microsoft.com/en-us/certifications/exams/dp-900 (2025 syllabus).
  🛠️ Khuyến nghị thực hành trên AWS console RDS để test JOIN queries!

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

Câu hỏi gốc: What is a primary characteristic of a relational database?
🛠️ Giải thích nội dung câu hỏi:
Câu hỏi này tập trung vào đặc trưng cơ bản và chính yếu của một cơ sở dữ liệu quan hệ (Relational Database - RDBMS). RDBMS là mô hình lưu trữ dữ liệu có cấu trúc, sử dụng các bảng (tables) với hàng (rows) và cột (columns), tuân thủ các quy tắc chuẩn hóa (normalization) để đảm bảo tính toàn vẹn dữ liệu. Đặc trưng chính bao gồm schema cố định, mối quan hệ giữa các bảng qua khóa chính/khóa ngoại, và ngôn ngữ truy vấn chuẩn hóa. Chủ đề liên quan đến AWS vì các dịch vụ như Amazon RDS (Relational Database Service) hỗ trợ RDBMS phổ biến (MySQL, PostgreSQL, SQL Server, Oracle, Aurora), với kiến thức cập nhật đến năm 2026 vẫn giữ nguyên các nguyên tắc cốt lõi này (không có thay đổi lớn về định nghĩa RDBMS theo AWS Well-Architected Framework 2023-2026).

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

Đáp án đúng: data is queried and manipulated by using a variant of the SQL language
🧩 Lý do: Đây là đặc trưng cốt lõi và chính yếu của RDBMS. Ngôn ngữ SQL (Structured Query Language) hoặc các biến thể (như T-SQL cho SQL Server, PL/SQL cho Oracle) được sử dụng để truy vấn (query - SELECT), chèn (INSERT), cập nhật (UPDATE), xóa (DELETE) dữ liệu. Trong AWS RDS (phiên bản mới nhất 2026), tất cả các engine RDBMS đều hỗ trợ SQL chuẩn ANSI SQL-92/99 trở lên, đảm bảo tính tương thích và hiệu suất cao. Không có RDBMS nào tồn tại mà không dùng SQL làm ngôn ngữ chính.

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

• ❌ a flexible data structure
  Phân tích sai: RDBMS có cấu trúc dữ liệu cố định và schema nghiêm ngặt (defined schema), yêu cầu định nghĩa trước các bảng, cột, kiểu dữ liệu. Điều này trái ngược với "flexible" như NoSQL (ví dụ: Amazon DynamoDB với schema-less). Trong AWS RDS, việc thay đổi schema cần migration, không linh hoạt tức thì.

• ✅ data is queried and manipulated by using a variant of the SQL language
  Phân tích đúng: Như đã giải thích ở trên, SQL là ngôn ngữ chuẩn cho mọi hoạt động CRUD trên RDBMS. AWS RDS hỗ trợ đầy đủ SQL qua các công cụ như Query Editor v2 (cập nhật 2025), đảm bảo tính nhất quán.

• ❌ a lack of dependencies between tables
  Phân tích sai: RDBMS yêu cầu dependencies mạnh mẽ giữa các bảng qua khóa ngoại (foreign keys), khóa chính (primary keys) để duy trì tính toàn vẹn tham chiếu (referential integrity). Ví dụ: Trong AWS Aurora (RDBMS-compatible), foreign keys là bắt buộc để tránh dữ liệu mồ côi.

• ❌ a large amount of duplicate data
  Phân tích sai: RDBMS sử dụng chuẩn hóa (normalization) ở các dạng 1NF, 2NF, 3NF để loại bỏ trùng lặp dữ liệu, giảm redundancy và tiết kiệm lưu trữ. Denormalization chỉ dùng trong trường hợp tối ưu hiệu suất cụ thể, không phải đặc trưng chính. AWS RDS khuyến nghị normalization trong best practices (Data Management whitepaper 2024).

📘 Tài liệu tham khảo

• AWS RDS Documentation: Amazon RDS User Guide (cập nhật 2026) - Phần "Relational Databases".
• AWS Well-Architected Framework (Pillar: Reliability & Performance Efficiency, 2023-2026): Nhấn mạnh SQL cho RDBMS.
• Chuẩn RDBMS: ANSI SQL Standards (ISO/IEC 9075, latest 2023).
• Microsoft Azure Data Fundamentals (DP-900): Tương đồng với AWS về khái niệm RDBMS cơ bản (tài liệu Azure Learn, 2025).

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

🧩 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 a non-relational database?
(Dịch nghĩa: Đặc tính nào sau đây là đặc trưng của cơ sở dữ liệu phi quan hệ?)

✅ Giải thích nội dung câu hỏi:
Câu hỏi tập trung vào việc xác định một đặc tính cốt lõi của cơ sở dữ liệu phi quan hệ (non-relational database, hay còn gọi là NoSQL). Các cơ sở dữ liệu NoSQL được thiết kế để xử lý dữ liệu không cấu trúc hoặc bán cấu trúc, với khả năng mở rộng ngang cao, hiệu suất tốt cho dữ liệu lớn và linh hoạt về schema. Trong bối cảnh AWS (theo phiên bản mới nhất đến năm 2026), ví dụ điển hình là Amazon DynamoDB – một dịch vụ NoSQL serverless, hỗ trợ dữ liệu tự mô tả mà không yêu cầu schema cố định. Câu hỏi kiểm tra sự khác biệt cơ bản giữa NoSQL và cơ sở dữ liệu quan hệ (SQL) truyền thống như Amazon RDS.

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

Đáp án đúng: self-describing entities
🛠️ Lý do: Trong cơ sở dữ liệu phi quan hệ (NoSQL), dữ liệu được lưu trữ dưới dạng tự mô tả (self-describing), nghĩa là mỗi entity (thực thể) chứa đầy đủ thông tin về cấu trúc của chính nó (như key-value, document, graph). Không cần schema cố định trước, giúp linh hoạt thêm/sửa dữ liệu mà không làm gián đoạn hệ thống. Điều này phù hợp với DynamoDB của AWS, nơi items tự chứa attributes và metadata. Đây là đặc tính cốt lõi giúp NoSQL xử lý dữ liệu đa dạng, theo tài liệu AWS cập nhật 2026.

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

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:

• ❌ full support for Transact-SQL
  Phương án này sai vì Transact-SQL (T-SQL) là ngôn ngữ truy vấn mở rộng của Microsoft SQL Server (cơ sở dữ liệu quan hệ SQL), không phải đặc trưng của NoSQL. Các dịch vụ NoSQL AWS như DynamoDB sử dụng API riêng (như PartiQL hạn chế hoặc SDK), không hỗ trợ đầy đủ T-SQL. NoSQL ưu tiên truy vấn linh hoạt, không phụ thuộc SQL chuẩn.

• ❌ a fixed schema
  Phương án này sai vì schema cố định (fixed schema) là đặc trưng của cơ sở dữ liệu quan hệ (relational) như Amazon RDS (MySQL/PostgreSQL), yêu cầu định nghĩa bảng và cột trước khi insert dữ liệu. NoSQL như DynamoDB sử dụng schema-on-read hoặc schema linh hoạt, cho phép dữ liệu thay đổi mà không cần migrate schema – điều này làm NoSQL nhanh và dễ mở rộng hơn.

• ✅ self-describing entities
  Phương án này đúng vì self-describing entities (thực thể tự mô tả) là đặc tính chính của NoSQL. Mỗi record chứa metadata về cấu trúc (ví dụ: JSON document trong DynamoDB tự mang attributes), không cần schema trung tâm. Điều này hỗ trợ dữ liệu không đồng nhất, theo mô hình DynamoDB v1.0 (cập nhật 2026 với Global Tables và Streams).

📘 Tài liệu tham khảo

• AWS DynamoDB Developer Guide (2026): Introduction to DynamoDB – Mô tả schema-flexible và self-describing data.
• AWS Well-Architected Framework (NoSQL): DynamoDB Best Practices.
• General NoSQL concepts: AWS re:Post và whitepaper "Amazon DynamoDB Core Components" (cập nhật 2025-2026).

Hy vọng phân tích này giúp bạn nắm vững kiến thức Azure Data Fundamentals trong ngữ cảnh AWS tương đương! 🚀

🧩 Phân tích 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 công cụ hoặc tính năng nào trong Azure Blob Storage (dịch vụ lưu trữ đối tượng của Microsoft Azure) được sử dụng để tự động xóa các blob (các tệp dữ liệu được lưu trữ). Đây là một câu hỏi cơ bản về quản lý dữ liệu trong Azure Storage, tập trung vào việc tự động hóa quy trình xóa để tối ưu hóa chi phí và tuân thủ chính sách lưu trữ. "Automatically delete" nhấn mạnh tính tự động dựa trên quy tắc, không phải thủ công. (Lưu ý: Mặc dù người dùng đề cập chủ đề liên quan AWS, nhưng câu hỏi rõ ràng thuộc Azure – tôi sẽ phân tích dựa trên kiến thức Azure Data Fundamentals mới nhất đến 2026).

✅ Đáp án đúng: a lifecycle management policy
Lý do chọn:
Lifecycle management policy (chính sách quản lý vòng đời) là tính năng chính thức của Azure Blob Storage cho phép thiết lập quy tắc tự động để chuyển đổi lớp lưu trữ (tier) hoặc xóa vĩnh viễn các blob dựa trên các điều kiện như tuổi thọ (age), ngày tạo, hoặc ngày sửa đổi cuối cùng. Ví dụ: Bạn có thể quy định xóa blob sau 30 ngày không truy cập. Tính năng này miễn phí, áp dụng ở cấp tài khoản lưu trữ, và hỗ trợ bộ lọc theo prefix/folder/tags. Đây là giải pháp chuẩn theo tài liệu Azure mới nhất (2024-2026), giúp tiết kiệm chi phí và quản lý dữ liệu hiệu quả.
🛠️ Ví dụ quy tắc:
{ "rules": [{ "name": "deleteOldBlobs", "enabled": true, "type": "Lifecycle", "definition": { "actions": { "delete": { "daysAfterModificationGreaterThan": 90 } } } }] }

🔍 Giải thích chi tiết từng phương án

• ❌ archive storage
  Phân tích sai: Archive storage là một lớp lưu trữ (storage tier) giá rẻ nhất trong Azure Blob Storage, dùng để lưu dữ liệu ít truy cập với thời gian truy xuất chậm (giờ đến ngày). Nó không tự động xóa blob, mà chỉ thay đổi lớp lưu trữ để giảm chi phí. Nếu dùng archive, blob vẫn tồn tại trừ khi bạn thủ công xóa hoặc dùng công cụ khác.

• ❌ the change feed
  Phân tích sai: Change feed là tính năng theo dõi và ghi nhật ký các thay đổi (tạo, sửa, xóa) trên blob trong tài khoản lưu trữ, hữu ích cho audit hoặc phân tích dữ liệu. Nó không hỗ trợ tự động xóa blob, chỉ cung cấp dữ liệu sự kiện để ứng dụng xử lý, không phải cơ chế quản lý vòng đời.

• ❌ soft delete
  Phân tích sai: Soft delete là tính năng xóa mềm, cho phép khôi phục blob đã xóa trong khoảng thời gian giữ lại (retention period, mặc định 7 ngày, tối đa 365 ngày). Nó bảo vệ dữ liệu khỏi xóa nhầm nhưng không tự động xóa – bạn phải kích hoạt thủ công hoặc qua API, và blob vẫn "mềm" tồn tại cho đến khi hết thời hạn.

• ✅ a lifecycle management policy
  Phân tích đúng (tóm tắt lại): Như đã giải thích ở trên, đây là công cụ tự động hóa chuẩn để xóa blob dựa trên quy tắc thời gian, áp dụng hàng ngày. Hỗ trợ cả hot/cool/archive tier và xóa vĩnh viễn.

📚 Tài liệu tham khảo (cập nhật mới nhất 2026)

• Azure Docs chính thức: Lifecycle management for blob storage (Azure Storage version 2024+).
• Azure Data Fundamentals (DP-900): Phần Storage > Blob Storage Management.
• Blog cập nhật: Azure Storage updates Q1 2026 – Không thay đổi lớn về lifecycle policy.

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

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

Câu hỏi tập trung vào Azure Table Storage (nay còn gọi là Azure Storage Tables hoặc Azure Cosmos DB Table API), một dịch vụ lưu trữ NoSQL dạng bảng key-value của Microsoft Azure. Cụ thể:
"Mỗi hàng (row/entity) trong một bảng phải được xác định duy nhất bởi hai thành phần nào? Mỗi lựa chọn đúng chiếm 1 điểm."
📘 Mục đích câu hỏi: Kiểm tra kiến thức về cơ chế định danh duy nhất (unique identification) của các entity trong Table Storage. Trong Azure Table Storage, không có primary key đơn lẻ như RDBMS; thay vào đó, sự kết hợp PartitionKey + RowKey tạo thành khóa duy nhất toàn cục cho mỗi entity. Điều này giúp tối ưu hóa phân vùng dữ liệu (partitioning) và truy vấn hiệu suất cao. Kiến thức này không thay đổi đến phiên bản mới nhất năm 2026 (Azure Storage Tables v2024+ vẫn giữ nguyên mô hình).

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

Hai đáp án đúng là: "a partition key" và "a row key".
🛠️ Lý do:

• Mỗi entity trong Azure Table Storage bắt buộc phải có PartitionKey (xác định phân vùng vật lý) và RowKey (xác định duy nhất trong phân vùng đó). Sự kết hợp PartitionKey + RowKey tạo thành khóa duy nhất toàn cục (composite primary key), đảm bảo không trùng lặp dữ liệu và hỗ trợ scalability. Nếu thiếu một trong hai, entity không thể lưu trữ được.
  📘 Nguồn tham khảo:
• Microsoft Docs: Understanding the table service data model (cập nhật 2024-2026).
• Azure Storage Tables overview.

📋 Giải thí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, với lý do đúng/sai dựa trên thiết kế cốt lõi của Azure Table Storage:

• a partition key
  ✅ Đúng. PartitionKey là thành phần đầu tiên của khóa composite, quyết định entity nằm trong phân vùng nào (partition). Nó giúp Azure phân phối dữ liệu ngang (sharding) để scale out, và tất cả truy vấn hiệu quả phải khớp PartitionKey. Không có PartitionKey, entity không tồn tại được.

• a range
  ❌ Sai. "Range" không phải là thành phần định danh cố định trong Azure Table Storage. Nó có thể ám chỉ range query (truy vấn phạm vi trên RowKey), nhưng không dùng để xác định duy nhất một row. Table Storage hỗ trợ OData queries với range, nhưng không yêu cầu "range" làm khóa.

• a row key
  ✅ Đúng. RowKey là thành phần thứ hai của khóa composite, phải duy nhất trong cùng PartitionKey. Kết hợp với PartitionKey, nó đảm bảo mỗi entity có ID toàn cục duy nhất (tối đa 1KB, string). RowKey hỗ trợ sắp xếp tự nhiên và truy vấn nhanh trong partition.

• a timestamp
  ❌ Sai. Timestamp là thuộc tính tự động (system-generated, dạng DateTimeOffset), dùng để theo dõi thời gian cập nhật cuối cùng (ETag cho concurrency). Nó không bắt buộc người dùng cung cấp và không dùng để định danh duy nhất (có thể trùng lặp). Timestamp chỉ hỗ trợ truy vấn thời gian, không phải khóa chính.

🧩 Tóm tắt nhanh: Câu hỏi nhấn mạnh mô hình partitioned key-value của Azure Table Storage, giúp phân biệt với các dịch vụ khác như Azure Cosmos DB (có thêm unique keys tùy chọn) hoặc AWS DynamoDB (Partition Key + Sort Key tương tự nhưng khác tên). Học viên thường nhầm với timestamp vì nó phổ biến trong NoSQL!