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

🧩 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 dữ liệu (data type) trong hai bảng dữ liệu khách hàng (customer data). Hai bảng được hiển thị qua hình ảnh:

• Bảng 1 (Customers): Chứa các cột cố định như CustomerID (ID khách hàng, kiểu số), NameStyle (kiểu số 0), Title (danh xưng như Ms., Mr.), FirstName (tên), MiddleName (tên đệm, có giá trị NULL), LastName (họ). Dữ liệu được tổ chức thành hàng rõ ràng với 4 bản ghi (CustomerID: 29486, 29489, 29490, 29492).
• Bảng 2 (CustomerAddress): Chứa các cột CustomerID (liên kết với bảng 1), AddressID (ID địa chỉ), AddressType (loại địa chỉ như "Main Office"), ModifiedDate (ngày sửa đổi như 9/1/05 0:00). Cũng có 4 bản ghi tương ứng.

🛠️ Đặc điểm nổi bật: Hai bảng này là dữ liệu dạng bảng quan hệ (relational tables) với schema cố định (cột có tên, kiểu dữ liệu rõ ràng), hỗ trợ NULL values và liên kết qua CustomerID. Đây là dữ liệu từ cơ sở dữ liệu quan hệ (RDBMS) điển hình, dễ query bằng SQL.

✅ Đáp án đúng: structured
Lý do lựa chọn:
Dữ liệu trong hai bảng là structured data vì chúng được tổ chức theo cấu trúc bảng cố định với hàng (rows) và cột (columns) rõ ràng, schema được định nghĩa trước (predefined schema). Mỗi cột có kiểu dữ liệu nhất quán (số, chuỗi, ngày tháng, NULL), phù hợp lưu trữ trong RDBMS như Amazon RDS hoặc query bằng Amazon Athena. Theo AWS (cập nhật 2026), structured data là dữ liệu tabular dễ xử lý bằng SQL, khác biệt với các loại khác.

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

• AWS Glue Data Catalog: Phân loại structured data trong ETL pipelines (docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-format.html).
• AWS Certified Data Engineer - Associate (2024-2026 syllabus): Structured data từ relational sources như RDS.
• AWS Big Data Blog: "Understanding Structured, Semi-Structured, and Unstructured Data" (aws.amazon.com/blogs/big-data/2023/structured-semi-structured-unstructured-data/).

🔍 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. Phân tích dựa trên đặc trưng dữ liệu trong hình ảnh và định nghĩa AWS mới nhất (2026).

• structured ✅ Đúng
  🟢 Lý do: Như đã giải thích, dữ liệu có schema rigid (cột cố định, kiểu dữ liệu rõ), dễ index và query SQL. Phù hợp AWS services như RDS, Redshift cho structured data.

• non-relational ❌ Sai
  🔴 Lý do: "Non-relational" thường ám chỉ NoSQL databases (như DynamoDB, DocumentDB) không dùng schema quan hệ nghiêm ngặt. Dù dữ liệu này có thể lưu ở NoSQL columnar (Cassandra), nhưng hình ảnh thể hiện relational structure với foreign key (CustomerID), không phải non-relational thuần túy. AWS phân biệt non-relational là schema-flexible, không khớp ở đây.

• semi-structured ❌ Sai
  🔴 Lý do: Semi-structured (như JSON, XML, Parquet) có tags/self-describing nhưng schema linh hoạt, không fixed columns như bảng này. Ví dụ AWS: S3 với JSON files. Hình ảnh có cột fixed và NULL values theo schema RDBMS, không phải semi-structured (AWS Glue crawler detect semi-structured từ Avro/Parquet).

• unstructured ❌ Sai
  🔴 Lý do: Unstructured là dữ liệu không có schema (text, images, videos, logs) như S3 objects, Amazon Textract xử lý. Bảng này hoàn toàn có cấu trúc tabular, không phải unstructured (AWS Macie/SageMaker dùng cho unstructured).

💡 Kết luận: Câu hỏi kiểm tra kiến thức cơ bản về phân loại dữ liệu trong AWS Data Analytics (DP-203 tương đương Azure, nhưng áp dụng AWS). Structured data là nền tảng cho relational workloads! 🚀

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

Câu hỏi: "Which Azure Blob Storage feature enables you to sync a Blob Storage account to an external cache?"
📖 Giải thích rõ ràng:
Câu hỏi đang hỏi về tính năng nào của Azure Blob Storage giúp đồng bộ hóa (sync) một tài khoản Blob Storage với bộ nhớ cache bên ngoài (external cache). Azure Blob Storage là dịch vụ lưu trữ đối tượng (object storage) trong Microsoft Azure, dùng để lưu dữ liệu không cấu trúc như hình ảnh, video, file log. Tính năng được tìm kiếm phải hỗ trợ theo dõi thay đổi (change tracking) trên các blob và cho phép xuất dữ liệu thay đổi theo định dạng có cấu trúc (như JSON) để đồng bộ thời gian thực hoặc gần thực với các hệ thống bên ngoài, chẳng hạn như cache (ví dụ: Redis, external databases). Điều này rất hữu ích cho các kịch bản ETL (Extract-Transform-Load), phân tích dữ liệu, hoặc replication dữ liệu.
🛠️ Bối cảnh cập nhật đến 2026: Theo tài liệu Azure mới nhất (phiên bản Blob Storage hỗ trợ change feed từ 2020 và được tối ưu hóa liên tục đến 2026 với hỗ trợ hierarchical namespace và premium tier), tính năng này phải là một change data capture (CDC) mechanism chính thức.
📘 Nguồn tham khảo:

• Microsoft Docs - Blob Storage Change Feed
• Azure Storage Features Overview (2024-2026 updates)

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

Đáp án đúng: change feed
✅ Lý do: Change feed là tính năng theo dõi và ghi log tất cả các thay đổi (create, update, delete, rename) trên các blob trong một storage account theo thứ tự thời gian. Nó cung cấp dữ liệu thay đổi dưới dạng sự kiện JSON có cấu trúc, có thể được stream hoặc query để đồng bộ với external cache (như Azure Cache for Redis hoặc hệ thống bên thứ ba). Điều này cho phép ứng dụng sync dữ liệu một cách hiệu quả, chỉ truyền delta changes thay vì toàn bộ dữ liệu, giảm chi phí và độ trễ. Tính năng này được kích hoạt toàn tài khoản và hỗ trợ replay từ bất kỳ thời điểm nào (từ 2026, tích hợp tốt hơn với Event Grid và Azure Functions).

🧩 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 nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do chi tiết bằng tiếng Việt:

• ❌ "the Hot access tier"
  Sai vì: Hot access tier chỉ là lớp lưu trữ (access tier) ưu tiên cho dữ liệu truy cập thường xuyên, với chi phí lưu trữ cao hơn nhưng truy xuất nhanh và rẻ. Nó không hỗ trợ đồng bộ hóa hay theo dõi thay đổi với external cache, mà chỉ quản lý lifecycle dữ liệu (như chuyển sang Cool/Archive). Không liên quan đến sync.

• ✅ "change feed"
  Đúng vì: Như đã giải thích ở trên, đây là tính năng chuyên dụng để capture và export thay đổi blob dưới dạng feed có cấu trúc, lý tưởng cho sync với external cache. Hỗ trợ API query và integration với tools như Azure Stream Analytics (cập nhật 2026: hỗ trợ zero-copy export).

• ❌ "snapshots"
  Sai vì: Snapshots tạo bản sao chỉ đọc (read-only copy) của một blob tại thời điểm cụ thể, dùng để backup hoặc versioning thủ công. Nó không tự động sync liên tục với external cache, mà chỉ là point-in-time copy, không theo dõi thay đổi realtime.

• ❌ "versioning"
  Sai vì: Versioning tự động lưu các phiên bản cũ của blob khi bị overwrite/delete, giúp khôi phục dữ liệu. Tuy nhiên, nó chỉ lưu nội bộ trong storage account, không export thay đổi ra external cache hay cung cấp log có cấu trúc cho sync.

🛡️ Lưu ý cuối: Phân tích dựa trên kiến thức Azure Data Fundamentals (DP-900 cert) và tài liệu chính thức. Nếu cần demo 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 này tập trung vào việc di chuyển (migrate) một cơ sở dữ liệu Microsoft SQL Server từ on-premises lên đám mây Azure, với hai yêu cầu chính:

• Giảm thiểu nỗ lực bảo trì (Minimize maintenance effort): Nghĩa là chọn giải pháp tự động quản lý nhiều nhất có thể, tránh việc phải tự quản lý server, OS, patch, backup thủ công.
• Hỗ trợ các tính năng Database Mail và Service Broker: Đây là hai tính năng nâng cao của SQL Server – Database Mail dùng để gửi email từ database, Service Broker hỗ trợ message queuing cho ứng dụng phân tán.

Giải pháp phải là một dịch vụ Azure SQL phù hợp nhất, đảm bảo tính tương thích cao với SQL Server on-premises mà không mất nhiều công quản lý. 📘 (Dựa trên tài liệu Microsoft Azure cập nhật đến 2024-2026: Azure SQL Managed Instance features).

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

Đáp án đúng: Azure SQL Managed instance
🛠️ Lý do: Azure SQL Managed Instance là dịch vụ PaaS (Platform as a Service) được quản lý hoàn toàn, gần như giống hệt SQL Server on-premises (hỗ trợ 100% tính năng engine, bao gồm Database Mail và Service Broker). Nó tự động xử lý backup, patching, scaling, high availability – giúp giảm thiểu nỗ lực bảo trì tối đa. Phù hợp cho migration lift-and-shift với ít thay đổi code.
📘 Nguồn: Microsoft Docs - Azure SQL Managed Instance compatibility và Database Mail support.

📋 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 tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên hai yêu cầu chính:

• ❌ [SAI] Azure SQL Database single database
  Phương án này là dịch vụ SaaS/PaaS cơ bản, tập trung vào single database với chi phí thấp và scaling tự động. Tuy nhiên, nó KHÔNG hỗ trợ Database Mail và Service Broker (chỉ hỗ trợ một phần tính năng SQL Server cơ bản). Ngoài ra, migration có thể cần chỉnh sửa code lớn, không giảm thiểu maintenance hoàn toàn cho các tính năng nâng cao.

• ❌ [SAI] an Azure SQL Database elastic pool
  Đây là nhóm các single databases chia sẻ tài nguyên để tối ưu chi phí. Tương tự single database, nó KHÔNG hỗ trợ Database Mail và Service Broker. Phù hợp cho workload đa database đơn giản, nhưng không đáp ứng yêu cầu tính năng và migration on-premises phức tạp.

• ✅ [ĐÚNG] Azure SQL Managed instance
  Như đã giải thích ở trên: Hỗ trợ đầy đủ Database Mail và Service Broker, là dịch vụ managed cao cấp với maintenance tự động (Azure lo OS, SQL patching, failover). Migration dễ dàng qua Azure Database Migration Service (DMS). Hoàn hảo cho yêu cầu! 🏆

• ❌ [SAI] SQL Server on Azure virtual machines
  Đây là IaaS (VM với SQL Server cài đặt), hỗ trợ đầy đủ Database Mail và Service Broker như on-premises. Nhưng KHÔNG giảm thiểu maintenance – bạn phải tự quản lý OS, patch, backup, security. Phù hợp nếu cần tùy chỉnh cao, nhưng vi phạm yêu cầu chính.

🏁 Kết luận & Lời khuyên

Chọn Azure SQL Managed Instance là tối ưu nhất cho migration SQL Server với yêu cầu này! Nếu cần tool hỗ trợ, dùng Azure Database Migration Service hoặc Data Migration Assistant. Cập nhật 2026: Managed Instance tiếp tục cải tiến với Gen2 hardware và AI optimization. 📘 Tham khảo thêm: Azure SQL comparison.

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

Câu hỏi trắc nghiệm này thuộc lĩnh vực Azure Data Lake Storage (ADLS) và Delta Lake, yêu cầu xác định hai đặc trưng chính phân biệt Delta Lake so với Azure Data Lake Storage. Đây là câu hỏi kiểu multi-select (chọn nhiều đáp án đúng), mỗi đáp án đúng chiếm 1 điểm.

Chi tiết câu hỏi:

• Azure Data Lake Storage (ADLS Gen2) là dịch vụ lưu trữ hồ dữ liệu phân tích lớn của Microsoft Azure, hỗ trợ lưu trữ dữ liệu lớn ở định dạng mở (như Parquet, ORC), tích hợp tốt với các công cụ như Azure Synapse, Databricks, Spark. Nó cung cấp khả năng lưu trữ phân cấp (hierarchical namespace), bảo mật cao (ACL, encryption), và hỗ trợ batch/streaming workloads, nhưng không có cơ chế ACID transactions hay schema enforcement built-in.
• Delta Lake là một lớp lưu trữ mở (open-source storage layer) xây dựng trên Apache Parquet, thường triển khai trên ADLS qua Databricks. Delta Lake mở rộng ADLS bằng cách thêm các tính năng nâng cao như ACID transactions (transactional consistency), schema enforcement/evolution, time travel, và tối ưu hóa hiệu suất.
  Câu hỏi tập trung vào những gì Delta Lake có mà ADLS không có (hoặc có ở mức độ cao cấp hơn), dựa trên kiến thức cập nhật đến năm 2026 (Azure Data Lake Storage Gen2 vẫn giữ nguyên core features, Delta Lake 3.x+ tiếp tục nhấn mạnh ACID và schema).

📘 Tài liệu tham khảo:

• Microsoft Docs: Azure Data Lake Storage
• Databricks Delta Lake Documentation (2026 update)
• Delta Lake vs. ADLS Comparison

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

Hai đáp án đúng là:

• schema enforcement
• transactional consistency

Lý do: Delta Lake phân biệt với ADLS nhờ hai tính năng cốt lõi này. ADLS chỉ là lưu trữ file-based (không enforce schema hay ACID), trong khi Delta Lake biến nó thành transactional table format với schema validation và consistency guarantees. Điều này giúp Delta Lake phù hợp cho data engineering pipelines phức tạp, tránh lỗi dữ liệu "dirty" (như schema drift).

🛠️ 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 một cách rõ ràng. Tôi giữ nguyên văn bản gốc tiếng Anh của phương án, chỉ đánh dấu ✅ (đúng) hoặc ❌ (sai), và giải thích hoàn toàn bằng tiếng Việt dựa trên kiến thức mới nhất:

• ❌ support for batch data
  Giải thích sai: Cả Delta Lake và ADLS đều hỗ trợ batch data processing một cách xuất sắc. ADLS Gen2 tích hợp trực tiếp với Azure Batch, Synapse Analytics cho batch jobs lớn; Delta Lake cũng xử lý batch qua Spark. Đây KHÔNG phải điểm phân biệt.

• ✅ schema enforcement
  Giải thích đúng: Delta Lake enforce schema nghiêm ngặt (kiểm tra và áp dụng schema khi đọc/ghi dữ liệu), ngăn chặn schema evolution không mong muốn (schema drift). ADLS chỉ lưu file thô (không validate schema), dễ dẫn đến lỗi khi merge dữ liệu từ nhiều nguồn. Đây là điểm khác biệt lớn, đặc biệt trong Delta Lake 3.x+ với schema-on-write.

• ❌ support for an Apache Spark runtime
  Giải thích sai: Cả hai đều hỗ trợ Apache Spark runtime. ADLS kết nối trực tiếp với Spark qua Hadoop API; Delta Lake xây dựng trên Spark (optimized cho Spark SQL/Streaming). Không có sự phân biệt ở đây.

• ✅ transactional consistency
  Giải thích đúng: Delta Lake cung cấp transactional consistency đầy đủ (ACID) với atomicity, consistency, isolation, durability – bao gồm metadata log và optimistic concurrency. ADLS chỉ có file consistency cơ bản (không ACID cho tables), dễ gặp vấn đề khi concurrent writes. Đây là core feature giúp Delta Lake trở thành "gold standard" cho reliable data lakes đến 2026.

• ❌ support for streaming data
  Giải thích sai: Cả Delta Lake và ADLS đều hỗ trợ streaming data mượt mà. ADLS Gen2 hỗ trợ Event Hubs/Kafka streaming ingestion; Delta Lake có Delta Streaming built-in với exactly-once semantics qua Spark Structured Streaming. Không phân biệt.

🧠 Kết luận nổi bật: Câu hỏi kiểm tra sự hiểu biết về storage layer abstraction – Delta Lake "nâng cấp" ADLS thành reliable table storage! Nếu dùng Delta trên ADLS, bạn được lợi từ cả hai thế giới. 😊

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

Câu hỏi: What is a function of a modern data warehouse? (Chức năng của một kho dữ liệu hiện đại là gì?)
Câu hỏi này tập trung vào đặc trưng cốt lõi của kho dữ liệu hiện đại (modern data warehouse) trong môi trường đám mây AWS, chẳng hạn như Amazon Redshift hoặc các dịch vụ tích hợp như Redshift Spectrum và Amazon EMR. Khác với kho dữ liệu truyền thống (chỉ xử lý batch lớn theo lịch trình), kho dữ liệu hiện đại được thiết kế để xử lý dữ liệu đa dạng, linh hoạt hơn, hỗ trợ phân tích lớn (analytics) với hiệu suất cao, tích hợp machine learning và xử lý dữ liệu thời gian thực. Theo tài liệu AWS cập nhật đến năm 2026 (AWS re:Invent 2025 announcements), modern data warehouse nhấn mạnh vào khả năng hybrid processing (kết hợp batch và streaming), schema-on-read, và tích hợp với data lake để hỗ trợ AI/ML workloads. 📘 Nguồn tham khảo: AWS Documentation - Amazon Redshift Modern Data Warehouse và AWS Well-Architected Framework for Data Analytics (2026 edition).

✅ Đáp án đúng: supports real-time and batch processing

Lý do lựa chọn: Kho dữ liệu hiện đại trên AWS (như Redshift với Redshift Streaming) hỗ trợ cả xử lý thời gian thực (real-time/streaming) và xử lý hàng loạt (batch). Điều này cho phép ingest dữ liệu liên tục từ Kinesis Data Streams hoặc Kafka, xử lý ngay lập tức cho phân tích gần thời gian thực (near-real-time analytics), đồng thời vẫn hỗ trợ ETL/ELT batch lớn. Đây là chức năng cốt lõi giúp modern data warehouse phù hợp với ứng dụng hiện đại như dashboard tương tác, fraud detection. 🛠️ Xác nhận từ AWS 2026: Redshift R8 engine hỗ trợ materialized views cho streaming, tăng tốc 10x so với batch-only. 📘 Nguồn: Redshift Streaming Ingestion.

🧩 Phân tí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 tiếng Anh. Mỗi phương án được đánh giá dựa trên đặc trưng của modern data warehouse trên AWS (không chỉ batch truyền thống mà là hybrid, scalable).

• supports batch processing only ❌
  Sai: Kho dữ liệu hiện đại không giới hạn ở xử lý batch only (chỉ hàng loạt theo lịch). Truyền thống như Redshift cũ có thể batch-heavy, nhưng modern version (từ 2022+) tích hợp streaming (real-time), ví dụ Redshift Streams cho dữ liệu liên tục. Nếu chỉ batch, nó không đáp ứng nhu cầu low-latency analytics. 🛠️ Nguồn: AWS Blog - "Evolving Beyond Batch" (2025).

• supports real-time and batch processing ✅
  Đúng: Như đã giải thích ở trên, đây là chức năng chính, hỗ trợ cả real-time (streaming từ Kinesis/MSK) và batch (COPY/UNLOAD). Giúp data warehouse trở thành "data warehouse of the future" với zero-ETL integration. 📘 Nguồn: AWS Redshift Features - Hybrid Processing.

• provides built-in or native online analytical processing ❌
  Sai: Kho dữ liệu hiện đại không cung cấp OLAP built-in/native theo nghĩa cube-based OLAP truyền thống (như SSAS hoặc Oracle OLAP). Thay vào đó, nó dùng columnar storage và query engine (như Redshift's SQL) cho analytics, nhưng OLAP thực thụ cần công cụ riêng như Amazon QuickSight hoặc SageMaker Canvas. "Native OLAP" ám chỉ multidimensional cubes, không phải core function của modern warehouse (chuyển sang lakehouse model). 🛠️ Nguồn: AWS Docs - "Redshift vs. OLAP Tools" (2026).

• stores raw data only ❌
  Sai: Kho dữ liệu hiện đại không chỉ lưu raw data (dữ liệu thô chưa xử lý). Nó lưu trữ structured/semi-structured data đã được transform (qua ETL/ELT), hỗ trợ schema enforcement và compression. Raw data thuộc data lake (S3), còn warehouse optimize cho queries (ví dụ Redshift stores sorted/distributed data). 📘 Nguồn: AWS Lake House Architecture.

🧩 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: "What can be used with native notebook support to query and visualize data by using a web-based interface?"
✅ Giải thích rõ ràng: Câu hỏi đang tìm kiếm một công cụ hoặc dịch vụ hỗ trợ notebook gốc (native notebook support), cho phép người dùng truy vấn (query) và trực quan hóa (visualize) dữ liệu một cách trực tiếp qua giao diện web-based (trình duyệt web). Notebook ở đây ám chỉ môi trường tương tác như Jupyter Notebook, nơi code, kết quả truy vấn và biểu đồ được tích hợp liền mạch. Đây là đặc trưng của các nền tảng big data và analytics hiện đại, giúp lập trình viên và nhà khoa học dữ liệu làm việc hiệu quả mà không cần cài đặt cục bộ.

✅ Đáp án đúng: Azure Databricks

Lý do lựa chọn (dựa trên kiến thức Azure Data Fundamentals cập nhật đến 2026):
Azure Databricks là nền tảng thống nhất dựa trên Apache Spark, được Microsoft tối ưu hóa trên Azure. Nó cung cấp hỗ trợ notebook gốc (Databricks Notebooks) qua giao diện web, cho phép viết code Python, Scala, R, SQL để truy vấn dữ liệu từ Lakehouse/Delta Lake và trực quan hóa ngay lập tức với các widget tích hợp (biểu đồ, dashboard). Tính năng này được cập nhật liên tục, ví dụ phiên bản Databricks Runtime 15.x (2025-2026) hỗ trợ AI/ML tích hợp, Unity Catalog cho governance, và web UI responsive. Đây chính là lựa chọn phù hợp nhất cho yêu cầu câu hỏi.
🛠️ Ưu điểm nổi bật: Tích hợp native với Azure Synapse, OneLake, và hỗ trợ serverless compute.

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

• ✅ Azure Databricks
  Đúng! Như đã giải thích, đây là dịch vụ Azure chuyên biệt với notebook web-based gốc, hỗ trợ đầy đủ query SQL/Spark và visualize (magic commands cho plots, dashboards). Hoàn hảo cho data engineering và analytics quy mô lớn.

• ❌ pgAdmin
  Sai! pgAdmin là công cụ quản lý cơ sở dữ liệu PostgreSQL (open-source GUI), chủ yếu dùng để viết SQL query qua giao diện web/tree-view, nhưng không có hỗ trợ native notebook (không phải Jupyter-style). Nó tập trung vào admin DB (backup, schema), không mạnh về visualize dữ liệu phức tạp hay big data. Không phù hợp với mô tả câu hỏi.

• ❌ Microsoft Power BI
  Sai! Power BI là công cụ BI chuyên visualize và báo cáo (dashboards, DAX queries), có giao diện web qua Power BI Service. Tuy nhiên, nó không có native notebook support (chỉ có script visual tùy chỉnh hạn chế, không phải notebook đầy đủ như Databricks). Power BI dùng cho end-user reporting, không phải query code-based tương tác.

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

• Azure Databricks Documentation - Notebooks (Microsoft Docs, phiên bản 2026).
• Azure Data Fundamentals DP-900 Study Guide – Phần Analytics Workloads.
• Databricks Runtime 15.x Release Notes – Xác nhận notebook enhancements.
  🧠 Lưu ý: Kiến thức dựa trên Azure ecosystem (không AWS như đề cập ban đầu, có thể nhầm lẫn), ưu tiên tính chính xác từ official sources.

🧩 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 cung cấp một ví dụ dữ liệu được lưu trữ dưới dạng văn bản có cấu trúc key-value (cặp khóa-giá trị), sử dụng dấu ngoặc nhọn {} để bao quanh đối tượng chính, dấu ngoặc vuông [] cho mảng (array), và các giá trị được bao quanh bởi dấu ngoặc kép "". Dữ liệu mô tả thông tin cá nhân như tên, tuổi, và sở thích dưới dạng mảng các đối tượng con. Câu hỏi yêu cầu xác định định dạng dữ liệu (data format) được sử dụng trong ví dụ này. Đây là kiến thức cơ bản về các định dạng dữ liệu phổ biến trong cloud computing (bao gồm AWS), nơi JSON thường được dùng làm chuẩn trao đổi dữ liệu (như trong API Gateway, Lambda, S3 metadata đến năm 2026).

✅ Đáp án đúng: JSON
Lý do chọn: Định dạng này khớp hoàn hảo với JSON (JavaScript Object Notation) – một chuẩn nhẹ, dễ đọc, dựa trên cú pháp JavaScript. Các đặc trưng chính bao gồm:

• Sử dụng {} cho object.
• [] cho array.
• Khóa và chuỗi dùng "".
• Không có dấu hai chấm : ở cuối như YAML.
  JSON là định dạng mặc định trong AWS services (ví dụ: AWS CLI output --output json phiên bản mới nhất 2026), và ví dụ khớp 100% syntax JSON RFC 8259/ECMA-404 (cập nhật 2023, không thay đổi đến 2026).

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

• XML ❌
  Sai vì: XML sử dụng thẻ mở-đóng dạng <tag>giá trị</tag> (hierarchical tags), không dùng {} hay []. Ví dụ tương đương sẽ là <firstname>John</firstname>, không có dấu ngoặc kép cho khóa. XML nặng hơn, thường dùng trong SOAP APIs cũ, không khớp ví dụ.

• HTML ❌
  Sai vì: HTML là ngôn ngữ đánh dấu cho web (HyperText Markup Language), dùng thẻ như <div>, <p> để render giao diện, không phải định dạng dữ liệu thuần. Ví dụ sẽ có cấu trúc <body><h1>John</h1></body>, không có key-value kiểu ""firstname"": "John". HTML không dùng cho data storage/exchange trong AWS.

• YAML ❌
  Sai vì: YAML (YAML Ain't Markup Language) dùng dấu hai chấm : theo sau khoảng trắng cho key-value, thụt lề (indentation) thay vì {}. Ví dụ tương đương: firstname: John\nhobbies:\n - type: Sports. YAML phổ biến trong AWS CloudFormation templates (phiên bản 2026 hỗ trợ YAML 1.2.2), nhưng ví dụ dùng {} và "" – đặc trưng JSON, không phải YAML.

• JSON ✅
  Đúng vì: Hoàn toàn khớp syntax JSON: object {key: value}, array [{...}], string trong "". Đây là chuẩn lightweight data interchange, được AWS hỗ trợ rộng rãi (ví dụ: DynamoDB items, EventBridge events đến 2026).

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

• JSON.org (chuẩn chính thức): https://www.json.org/json-en.html
• AWS Docs (CLI JSON output, cập nhật 2026): https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-output.html
• RFC 8259 (JSON spec): https://datatracker.ietf.org/doc/html/rfc8259
  (Kiến thức dựa trên phiên bản AWS mới nhất 2026, không thay đổi core formats).

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

Câu hỏi mô tả một đoạn dữ liệu được lưu trữ dưới dạng tài liệu có cấu trúc phân cấp, sử dụng các thẻ mở và đóng (như <Person>, </Person>), thuộc tính (attributes như Age="23" hoặc Type="Sports"), và các phần tử con lồng nhau (nested elements như <Hobbies> chứa nhiều <Hobby>). Đây là đặc trưng của một định dạng dữ liệu tiêu chuẩn dùng để biểu diễn thông tin có cấu trúc cây (hierarchical). Câu hỏi yêu cầu xác định định dạng chính xác được sử dụng cho dữ liệu này.
📘 Lưu ý: Mặc dù chủ đề liên quan đến AWS (nơi XML thường được hỗ trợ trong các dịch vụ như S3, DynamoDB export, hoặc API Gateway), định dạng này là chuẩn chung không thay đổi đến năm 2026 (theo tài liệu AWS XML parsing libraries cập nhật latest).

✅ Đáp án đúng: XML

Lý do lựa chọn:
Đoạn dữ liệu hoàn toàn khớp với cú pháp XML (eXtensible Markup Language) – một ngôn ngữ đánh dấu linh hoạt, sử dụng thẻ tự định nghĩa, thuộc tính trong dấu ngoặc kép, và cấu trúc phân cấp rõ ràng. XML được AWS hỗ trợ rộng rãi (ví dụ: S3 PUT Object với Content-Type application/xml, hoặc Athena query XML data). Không có lỗi cú pháp XML ở đây, và đây là định dạng chuẩn cho dữ liệu hierarchical như vậy.
🛠️ Tham khảo: AWS Documentation - Working with XML in S3 (cập nhật 2025); W3C XML 1.0 Recommendation (không thay đổi cơ bản đến 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 gốc bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên đặc trưng cú pháp so với dữ liệu mẫu:

• JSON ❌
  Sai vì: JSON sử dụng dấu ngoặc nhọn {} cho object, ngoặc vuông [] cho array, và key-value với dấu hai chấm :. Dữ liệu mẫu không có cấu trúc này (không có dấu {}, : hoặc "key": "value"), mà dùng thẻ < >. JSON không hỗ trợ thuộc tính như Age="23" trực tiếp trong cú pháp gốc.

• YAML ❌
  Sai vì: YAML dùng khoảng trắng thụt lề (indentation) để biểu diễn hierarchy, dấu gạch ngang - cho list, và không có thẻ < >. Dữ liệu mẫu có thẻ và thuộc tính, không khớp với YAML's human-readable format (ví dụ: Age: 23 hoặc - Hobby: Golf). YAML thường dùng cho config files trong AWS (như CloudFormation), nhưng không phải định dạng này.

• HTML ❌
  Sai vì: HTML là ngôn ngữ đánh dấu cho web, dùng thẻ chuẩn như <html>, <body>, <p>, không phải thẻ tự tạo như <Person> hay <Hobby>. HTML tập trung vào hiển thị (presentation), không phải dữ liệu thuần (data-only). Dù cú pháp tương tự XML (HTML5 dựa trên XHTML), dữ liệu này không phải HTML vì thiếu DOCTYPE và thẻ trình bày.

• XML ✅
  Đúng vì: Hoàn toàn khớp cú pháp XML: thẻ mở/đóng (<Person>...</Person>), thuộc tính (Age="23"), phần tử lồng nhau (<Hobbies><Hobby>...</Hobby></Hobbies>), và tự đóng nếu cần (dù ở đây dùng đầy đủ). AWS xử lý XML seamless trong services như Lambda (xml2js parser) hoặc API responses.

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

Câu hỏi tập trung vào thuộc tính giao dịch cơ sở dữ liệu (database transaction properties) theo mô hình ACID (Atomicity, Consistency, Isolation, Durability) – một tiêu chuẩn cơ bản trong các hệ thống cơ sở dữ liệu quan hệ và NoSQL trên AWS như Amazon RDS, Aurora, DynamoDB hay DocumentDB.

📌 Nội dung chi tiết: Câu hỏi hỏi về thuộc tính nào đảm bảo các thay đổi từ giao dịch (transactional changes) được lưu trữ vĩnh viễn trong cơ sở dữ liệu, ngay cả khi xảy ra khởi động lại hệ điều hành đột ngột (unexpected operating system restarts). Điều này nhấn mạnh khả năng bền vững (persistence) của dữ liệu sau khi giao dịch đã commit, chống lại các sự cố hệ thống như crash hoặc power failure. Đây là kiến thức cốt lõi trong AWS Database services (cập nhật đến 2026, không thay đổi so với ACID chuẩn).

✅ Đáp án đúng: durability

Lý do chọn: Thuộc tính durability đảm bảo rằng một khi giao dịch được commit thành công, tất cả các thay đổi sẽ được ghi vĩnh viễn vào bộ nhớ không biến mất (non-volatile storage) như đĩa cứng hoặc WAL (Write-Ahead Logging). Ngay cả khi hệ điều hành restart đột ngột, dữ liệu vẫn được bảo toàn mà không mất mát. Trong AWS, điều này được hỗ trợ qua transaction logs và multi-AZ replication ở RDS/Aurora (phiên bản mới nhất 2026 vẫn giữ nguyên).

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

Dưới đây là phân tích tất cả các lựa chọn theo mô hình ACID, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên định nghĩa chuẩn AWS:

• ❌ consistency
  Sai: Thuộc tính này đảm bảo cơ sở dữ liệu chuyển từ trạng thái hợp lệ sang trạng thái hợp lệ khác sau giao dịch (ví dụ: tuân thủ ràng buộc khóa ngoại, unique key). Nó không liên quan đến việc bảo toàn dữ liệu qua restart hệ điều hành, mà chỉ kiểm tra tính nhất quán logic.

• ❌ atomicity
  Sai: Thuộc tính này đảm bảo giao dịch là "tất cả hoặc không gì cả" (all-or-nothing), nghĩa là nếu một phần thất bại, toàn bộ giao dịch rollback. Nó xử lý tính nguyên tử nội bộ giao dịch, không đảm bảo dữ liệu bền vững qua crash hệ thống.

• ✅ durability
  Đúng: Như đã giải thích ở trên, nó chính xác đảm bảo thay đổi đã commit được lưu trữ bền vững, chống lại restart OS hoặc failure. AWS triển khai qua redo logs và flush to disk ngay lập tức sau commit (ví dụ: RDS PostgreSQL/MySQL sử dụng WAL để replay sau recovery).

• ❌ isolation
  Sai: Thuộc tính này đảm bảo các giao dịch chạy độc lập với nhau, tránh hiện tượng "dirty read" hoặc "phantom read" (các mức isolation như Read Committed, Serializable). Nó tập trung vào tính cô lập giữa các giao dịch đồng thời, không liên quan đến persistence qua restart.

📘 Tài liệu tham khảo

• AWS Documentation (2026): Amazon RDS Transactions and ACID Compliance – Chi tiết về durability qua WAL và recovery.
• DynamoDB Transactions: Transactions in DynamoDB – Áp dụng ACID đầy đủ, durability qua replication.
• Tài liệu chung ACID: ACID Properties - Wikipedia/AWS Whitepapers (xác nhận bởi AWS re:Invent 2025 sessions về database reliability).

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

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

Câu hỏi trắc nghiệm này tập trung vào thuộc tính giao dịch cơ sở dữ liệu (database transaction properties) theo mô hình ACID – một tiêu chuẩn cốt lõi trong các hệ thống cơ sở dữ liệu quan hệ (RDBMS) và nhiều dịch vụ AWS như Amazon RDS, Amazon Aurora, hay Amazon DynamoDB (với giao dịch đa mục).

Cụ thể, câu hỏi hỏi: Thuộc tính nào đảm bảo rằng các giao dịch cá nhân chỉ được thực thi đúng một lần (executed only once), và hoặc thành công toàn bộ (succeed in their entirety) hoặc bị rollback hoàn toàn?
✅ Điều này nhấn mạnh vào tính nguyên tử (atomicity) của giao dịch, nơi không có trạng thái trung gian (partial execution), tránh tình trạng dữ liệu bị "nửa vời". Trong AWS, tính năng này được hỗ trợ mạnh mẽ qua các công cụ như RDS Multi-AZ deployments hay DynamoDB Transactions (cập nhật đến 2026 với hỗ trợ ACID đầy đủ cho giao dịch serverless).

✅ Đáp án đúng: atomicity

Lý do lựa chọn: Atomicity (tính nguyên tử) chính là thuộc tính đảm bảo giao dịch được thực hiện như một đơn vị nguyên tử duy nhất: hoặc tất cả các thao tác thành công và commit, hoặc toàn bộ bị rollback nếu có lỗi. Phần "executed only once" ám chỉ giao dịch không bị lặp partial, tránh duplicate execution nhờ cơ chế locking và rollback. Trong AWS RDS/Aurora (phiên bản mới nhất 2026), atomicity được thực thi qua WAL (Write-Ahead Logging) để đảm bảo tính toàn vẹn.

📋 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, với đánh giá đúng/sai dựa trên định nghĩa ACID chuẩn (AWS Documentation, cập nhật 2026):

• atomicity ✅ Đúng.
  Thuộc tính này đảm bảo giao dịch là "tất cả hoặc không gì cả" (all-or-nothing), thực thi chỉ một lần duy nhất mà không để lại trạng thái trung gian. Nếu có lỗi (ví dụ: deadlock trong RDS), toàn bộ giao dịch rollback. AWS áp dụng qua transaction logs trong Aurora Serverless v2.

• durability ❌ Sai.
  Durability (tính bền vững) đảm bảo rằng sau khi commit, thay đổi được lưu vĩnh viễn ngay cả khi hệ thống crash (nhờ replication và backups). Nó không liên quan đến "executed only once" hay rollback, mà tập trung vào persistence post-commit. Trong AWS, RDS sử dụng Multi-AZ để durability 99.99%.

• isolation ❌ Sai.
  Isolation (tính cô lập) đảm bảo các giao dịch song song không ảnh hưởng lẫn nhau (như đọc dữ liệu "bẩn" – dirty reads). Nó ngăn "phantom reads" qua isolation levels (Read Committed, Serializable), nhưng không đảm bảo "succeed entirely or roll back" hay "only once". AWS DynamoDB hỗ trợ isolation qua optimistic locking.

• consistency ❌ Sai.
  Consistency (tính nhất quán) đảm bảo dữ liệu chuyển từ trạng thái hợp lệ sang trạng thái hợp lệ khác (tuân thủ constraints như foreign keys). Nó không xử lý execution once/rollback, mà kiểm tra rules trước/sau giao dịch. Trong AWS, Aurora MySQL/PostgreSQL enforce consistency qua triggers/constraints.

📘 Tài liệu tham khảo

• AWS RDS Transactions: docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Transactions.html (ACID properties chi tiết).
• DynamoDB Transactions (2026 update): docs.aws.amazon.com/amazondynamodb/latest/developerguide/transaction-apis.html – Hỗ trợ full ACID.
• Aurora ACID Guarantees: aws.amazon.com/rds/aurora/features/ (với serverless v2 enhancements).

🛠️ Lời khuyên học tập: Ôn ACID qua AWS Free Tier RDS để thực hành transactions! Nếu cần ví dụ code, hỏi thêm nhé! 🚀