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

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

Câu hỏi gốc (bằng tiếng Anh):
How is raw data stored in a data lakehouse?

✅ Giải thích nội dung câu hỏi:
Câu hỏi này tập trung vào cách lưu trữ dữ liệu thô (raw data) trong một data lakehouse – một kiến trúc dữ liệu hiện đại kết hợp ưu điểm của data lake (lưu trữ dữ liệu lớn, linh hoạt, chi phí thấp) và data warehouse (hỗ trợ truy vấn hiệu suất cao, quản lý schema). Trong data lakehouse, dữ liệu thô được lưu trữ ở lớp lưu trữ cơ bản mà không cần xử lý trước hoặc áp đặt cấu trúc. Chủ đề liên quan đến AWS, nơi data lakehouse thường được xây dựng trên Amazon S3 kết hợp với các dịch vụ như AWS Lake Formation, Amazon Athena hoặc EMR. Theo kiến thức cập nhật đến năm 2026 (phiên bản AWS Lake Formation mới nhất), raw data luôn được lưu trữ dưới dạng tệp tin linh hoạt để hỗ trợ quy mô lớn và đa dạng định dạng (như Parquet, ORC, JSON, CSV). Điều này khác biệt với data warehouse truyền thống yêu cầu schema-on-write.

✅ Đáp án đúng: as files
Lý do lựa chọn: Trong data lakehouse trên AWS (như S3-based lakehouse), raw data được lưu trữ trực tiếp dưới dạng files (tệp tin) trong object storage như Amazon S3. Điều này cho phép lưu trữ dữ liệu thô mà không cần chuyển đổi schema trước, hỗ trợ schema-on-read và tích hợp với các công cụ như Delta Lake hoặc Apache Iceberg (hỗ trợ ACID transactions đến 2026). Files đảm bảo tính linh hoạt, khả năng mở rộng petabyte-scale và chi phí thấp. Ví dụ: Dữ liệu log, IoT streams hay unstructured data được dump trực tiếp thành files Parquet/ORC trên S3.

📋 Giải thích chi tiết tất cả các phương án (sử dụng kiến thức AWS mới nhất 2026)

🛠️ Phân tích từng lựa chọn:

• ❌ as tables
  Sai vì: Tables (bảng) là cấu trúc có schema được định nghĩa trước, thường dùng trong data warehouse như Amazon Redshift hoặc data lakehouse sau khi xử lý (processed data). Raw data trong lakehouse không được lưu dưới dạng tables mà là files thô; tables chỉ xuất hiện khi áp dụng metadata layer (qua Glue Catalog hoặc Lake Formation) để truy vấn. Nếu lưu raw data as tables, sẽ mất tính linh hoạt và tăng chi phí không cần thiết.

• ❌ as queues
  Sai vì: Queues (hàng đợi) dùng cho xử lý streaming hoặc message passing, như Amazon SQS/Kinesis, không phải lưu trữ raw data lâu dài trong lakehouse. Lakehouse tập trung vào batch/streaming storage, không dùng queues làm lớp lưu trữ chính. Queues chỉ tạm thời để ingest data trước khi dump thành files trên S3.

• ✅ as files (Đáp án đúng, như đã giải thích ở trên)
  Đúng vì: Raw data được lưu trữ trực tiếp dưới dạng files trên object storage (S3), hỗ trợ open formats và transaction engines như Apache Iceberg (tích hợp sâu với AWS EMR/Athena đến 2026). Điều này cho phép governance, ACID compliance mà vẫn giữ tính "lake-like" cho raw data.

• ❌ as disks
  Sai vì: Disks (đĩa) ám chỉ block storage như EBS, dùng cho EC2 instances hoặc databases có cấu trúc cao (như RDS), không phù hợp cho data lakehouse quy mô lớn. Lakehouse dùng object storage (S3) thay vì disks để đảm bảo durability 99.999999999%, scalability và serverless access – disks sẽ giới hạn throughput và tăng chi phí quản lý.

📘 Tài liệu tham khảo (AWS cập nhật 2026)

• AWS Lake Formation Documentation: Build a data lake using a data lakehouse architecture – Xác nhận raw data stored as files in S3.
• Amazon S3 for Data Lakes: What is an Amazon S3 data lake? – Nhấn mạnh open file formats cho raw/processed data.
• Apache Iceberg on AWS (2026 updates): Integration with Lake Formation – Hỗ trợ file-based storage với metadata cho lakehouse.
• Microsoft Azure so sánh (từ góc nhìn Azure Data Fundamentals): Azure Synapse Lakehouse cũng lưu raw data as files trên ADLS Gen2, tương tự AWS S3.

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ụ thực hành, hãy hỏi nhé.

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

📘 Nội dung câu hỏi:
Câu hỏi tập trung vào mô hình dữ liệu phân tích (analytical data model), thường được sử dụng trong kho dữ liệu (data warehouse) như star schema hoặc snowflake schema trên các nền tảng đám mây AWS (ví dụ: Amazon Redshift, Amazon EMR, hoặc AWS Glue). Cụ thể, nó hỏi về loại bảng nào chứa các thực thể (entities) dùng để tổng hợp (aggregate) các giá trị số (numeric values), trong đó mỗi thực thể được biểu diễn bởi một hàng (row) với giá trị khóa duy nhất (unique key value).

🛠️ Giải thích chi tiết:

• Trong mô hình dữ liệu phân tích (theo phương pháp Kimball Dimensional Modeling, được AWS hỗ trợ đầy đủ đến năm 2026), dữ liệu được tổ chức thành các bảng fact (chứa số liệu đo lường) và dimension (chứa thuộc tính mô tả).
• Loại bảng này phải tập trung vào việc tổng hợp số liệu (như tổng doanh số, số lượng bán hàng), và mỗi hàng đại diện cho một sự kiện hoặc grain dữ liệu với khóa chính duy nhất.
• Đây là khái niệm cốt lõi trong AWS Lake Formation hoặc Redshift Spectrum, nơi fact table là trung tâm để chạy các truy vấn OLAP (Online Analytical Processing).

✅ Đáp án đúng: fact

Lý do lựa chọn:
🟢 Bảng fact chính là loại bảng chứa các thực thể dùng để tổng hợp giá trị số (measures như sales_amount, quantity), mỗi hàng đại diện cho một sự kiện kinh doanh cụ thể với khóa duy nhất (fact key hoặc surrogate key). Điều này phù hợp hoàn hảo với mô tả câu hỏi, giúp tối ưu hóa hiệu suất tổng hợp trong AWS Redshift (phiên bản mới nhất 2026 hỗ trợ materialized views cho fact tables).

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

• AWS Documentation: Dimensional Modeling in Amazon Redshift (cập nhật 2025-2026).
• Kimball Group: "The Data Warehouse Toolkit" (fact table definition).

🔍 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 bằng tiếng Việt:

• ❌ bridge
  ❌ Sai vì: Bảng bridge (cầu nối) dùng để xử lý mối quan hệ many-to-many giữa các dimension tables trong snowflake schema (ví dụ: liên kết product-category). Nó không chứa giá trị số để tổng hợp, mà chỉ lưu khóa tham chiếu, không có row với unique key đại diện thực thể số liệu. Trong AWS Glue (2026), bridge table chỉ hỗ trợ metadata mapping, không phải aggregation.

• ❌ dimension
  ❌ Sai vì: Bảng dimension chứa thuộc tính mô tả (descriptive attributes) như customer_name, date, product_category, với row đại diện thực thể mô tả và unique key (surrogate key). Nó không dùng để tổng hợp numeric values (chỉ slowly changing dimensions - SCD), mà hỗ trợ lọc/join với fact table. AWS Athena/Redshift (2026) dùng dimension cho slicing/dicing, không aggregate.

• ✅ fact
  ✅ Đúng vì: Như đã giải thích ở trên, bảng fact chứa measures số để aggregate (SUM, AVG), mỗi row là unique grain với foreign keys đến dimensions. Hoàn hảo cho analytical workloads trên AWS (ví dụ: federated queries trong Redshift 2026).

🎯 Kết luận: Câu hỏi kiểm tra kiến thức cơ bản về star schema trên AWS. Hãy thực hành với AWS Free Tier để xây dựng fact table thực tế! 🚀

🧩 Phân tích câu hỏi trắc nghiệm: Cơ sở dữ liệu Fully Denormalized

📖 Giải thích nội dung câu hỏi một cách chi tiết:
Câu hỏi tập trung vào khái niệm fully denormalized database (cơ sở dữ liệu hoàn toàn phi chuẩn hóa). Trong thiết kế cơ sở dữ liệu, denormalization (phi chuẩn hóa) là quá trình ngược lại với normalization (chuẩn hóa), nơi dữ liệu được lặp lại và lưu trữ dư thừa ở nhiều nơi để tối ưu hóa tốc độ đọc dữ liệu (read performance), thường dùng trong các hệ thống NoSQL, data warehouse hoặc ứng dụng cần truy vấn nhanh như AWS DynamoDB hoặc Amazon Redshift.

Fully denormalized nghĩa là tất cả thông tin liên quan đến một single entity (thực thể đơn lẻ, ví dụ: một khách hàng hoặc một sản phẩm) được tập trung hoàn toàn vào MỘT BẢNG DUY NHẤT, không có quan hệ JOIN giữa các bảng. Do đó:

• Đọc dữ liệu (read): Chỉ cần truy vấn một bảng duy nhất để lấy đầy đủ thông tin entity, tránh JOIN phức tạp.
• Ghi dữ liệu (write): Cập nhật hoặc chèn dữ liệu cũng chỉ vào một bảng duy nhất, vì mọi thuộc tính đã được denormalize vào đó.
  Câu hỏi kiểm tra sự hiểu biết cơ bản về trade-off của denormalization: ưu tiên read nhanh nhưng có thể tốn kém hơn về storage và write consistency. Khái niệm này không thay đổi đến năm 2026, vẫn là nền tảng trong AWS services như DynamoDB (single-table design) và Athena ( columnar storage denormalized).

✅ Đáp án đúng và lý do lựa chọn:
Đáp án đúng là: Data is read from a single table and written to a single table.
Lý do: Trong fully denormalized database, dữ liệu của một single entity được lưu trữ hoàn toàn trong một bảng duy nhất (single-table design). Do đó, cả read (truy vấn) và write (chèn/cập nhật) đều chỉ diễn ra trên bảng đó, giúp tối ưu hiệu suất read mà không cần JOIN. Đây là nguyên tắc cốt lõi của denormalization, đặc biệt trong AWS DynamoDB's best practices (single-item operations).

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

• ✅ Data is read from a single table and written to a single table.
  Đúng: Như đã giải thích, fully denormalized tập trung toàn bộ dữ liệu entity vào một bảng, nên read/write chỉ cần một bảng duy nhất. Điều này phù hợp với mô hình NoSQL AWS, giảm latency và tăng throughput.

• ❌ Data is read from multiple tables and written to a single table.
  Sai: Read từ multiple tables yêu cầu JOIN, trái với mục đích denormalization (tránh JOIN để read nhanh). Write chỉ một bảng thì không khớp fully denormalized, vì dữ liệu entity không được duplicate đầy đủ.

• ❌ Data is read from a single table and written to multiple tables.
  Sai: Read từ single table là đúng cho denormalized, nhưng write vào multiple tables chỉ xảy ra ở normalized DB (cần update nhiều bảng liên quan). Fully denormalized tránh điều này để đơn giản hóa write.

• ❌ Data is read from multiple tables and written to multiple tables.
  Sai: Đây là đặc trưng của fully normalized database (chuẩn hóa hoàn toàn, 3NF+), nơi dữ liệu phân tán nhiều bảng để tránh redundancy, dẫn đến read/write phức tạp với JOIN và transaction multi-table. Hoàn toàn ngược với denormalized.

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

• AWS DynamoDB Developer Guide: "Single-table design pattern" (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-use-singletable.html) – Nhấn mạnh denormalization cho single entity.
• Amazon Redshift Best Practices: Denormalized wide tables for analytics (https://docs.aws.amazon.com/redshift/latest/dg/c_designing-tables-best-practices.html).
• AWS Well-Architected Framework (Data Analytics Pillar, 2024+): Khuyến nghị denormalization cho read-heavy workloads.
  (Nguồn chính thức AWS, không thay đổi cơ bản đến 2026).

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

📘 Giải thích nội dung câu hỏi:
Câu hỏi tập trung vào độ trễ (latency) điển hình cho các hoạt động đọc (read operations) đối với tệp media được lưu trữ trong Cool access tier của Azure Blob Storage.

• Azure Blob Storage là dịch vụ lưu trữ đối tượng (object storage) trong Microsoft Azure, hỗ trợ nhiều lớp truy cập (access tiers): Hot (truy cập thường xuyên), Cool (truy cập không thường xuyên), Cold và Archive (truy cập hiếm).
• Cool access tier dành cho dữ liệu được truy cập ít hơn một lần/tháng, với chi phí lưu trữ thấp hơn Hot nhưng vẫn đảm bảo độ trễ thấp cho đọc dữ liệu (không cần thời gian phục hồi như Archive).
• Media files (như video, hình ảnh) thường lớn, nhưng câu hỏi nhấn mạnh typical latency (độ trễ điển hình) cho read operations từ Cool tier. Theo tài liệu Azure mới nhất (cập nhật đến 2024-2026), tất cả các tier Hot/Cool đều cung cấp truy cập low-latency (thấp mili giây), khác biệt chủ yếu ở chi phí và thời gian lưu trữ tối thiểu.

✅ Đáp án đúng: a few milliseconds
Lý do: Trong Cool tier, Azure Blob Storage sử dụng SSD-based storage và geo-redundant replication, đảm bảo độ trễ đọc điển hình chỉ vài mili giây (single-digit milliseconds) từ vị trí gần nhất. Điều này phù hợp cho media files, không bị ảnh hưởng bởi tier vì Cool không yêu cầu "retrieval time" như Archive (có thể mất giờ). Dữ liệu được phục vụ ngay lập tức từ cache/hot storage layers.

🛠️ Giải thích chi tiết từng phương án (theo phiên bản Azure Blob Storage mới nhất 2024-2026):

• ✅ a few milliseconds: Đúng! 🏆 Độ trễ điển hình cho read từ Cool tier là vài mili giây, tương tự Hot tier. Azure đảm bảo low-latency access cho dữ liệu không thường xuyên, lý tưởng cho media backup hoặc infrequently accessed content. Không có thời gian phục hồi (retrieval) như Archive.
• ❌ a few seconds: Sai! Độ trễ không đạt mức giây vì Cool tier được thiết kế cho immediate access (truy cập ngay lập tức). Chỉ vài giây có thể xảy ra trong trường hợp edge cases như network congestion, nhưng không phải typical.
• ❌ a few minutes: Sai! Hoàn toàn không đúng. Minutes chỉ áp dụng cho Cold tier trong một số scenarios hiếm hoặc partial retrieval, nhưng Cool tier vẫn là milliseconds.
• ❌ a few hours: Sai! Đây là đặc trưng của Archive tier (standard retrieval mất 1-15 giờ, bulk 4-24 giờ). Cool tier không yêu cầu rehydration như vậy.

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

• Azure Blob Storage access tiers - Microsoft Learn (cập nhật 2024): Xác nhận "Cool provides low-latency access with milliseconds retrieval times".
• Azure Storage pricing and performance (2026 preview): Latency cho Hot/Cool: <10ms typical cho reads.
• Azure Data Fundamentals DP-900 study guide (chương Blob Storage).

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 thêm câu hỏi, hãy hỏi nhé! 😊

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

Câu hỏi trắc nghiệm này thuộc lĩnh vực Azure Data Fundamentals (DP-900), yêu cầu chọn ba dịch vụ Azure hỗ trợ Apache Spark – một framework mã nguồn mở mạnh mẽ cho xử lý dữ liệu lớn (big data processing), phân tích thời gian thực và machine learning. Mỗi lựa chọn đúng chiếm 1 điểm.
Lưu ý quan trọng: Apache Spark được tích hợp native trong các dịch vụ Azure để chạy Spark jobs trên cloud, hỗ trợ các workload như ETL, batch processing và streaming (theo tài liệu Microsoft cập nhật đến năm 2026, với các tính năng mới như Spark 3.5+ trong Azure Synapse và Databricks).
📘 Nguồn tham khảo:

• Microsoft Docs: Apache Spark on Azure
• Azure Synapse Analytics Spark Pools
• Azure HDInsight Spark

✅ Đáp án đúng (3 lựa chọn)

Các dịch vụ hỗ trợ Apache Spark đầy đủ là:
🟢 Azure Synapse Analytics
🟢 Azure Databricks
🟢 Azure HDInsight

Lý do chọn các đáp án đúng: Những dịch vụ này cho phép triển khai và chạy Apache Spark engine trực tiếp, hỗ trợ Spark SQL, Spark Streaming, MLlib và GraphX. Chúng là complete solutions cho big data analytics với Spark, tích hợp seamless với Azure ecosystem (cập nhật 2026: hỗ trợ Spark 4.0 preview trong Databricks Runtime 16.x).

🛠️ 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 tiếng Anh, kèm giải thích đúng/sai bằng tiếng Việt dựa trên tính năng mới nhất:

• Azure Data Explorer ❌
  Sai: Azure Data Explorer (Kusto) là dịch vụ phân tích dữ liệu log và time-series với engine KQL riêng, không hỗ trợ Apache Spark native. Nó dùng cho exploratory analytics nhưng không chạy Spark jobs (không có Spark pools hoặc clusters). Thay vào đó, dùng plugin để query từ Spark, nhưng không phải "support Apache Spark" đầy đủ.

• Azure Synapse Analytics ✅
  Đúng: Dịch vụ integrated analytics hỗ trợ Spark pools (serverless/on-demand), chạy Apache Spark trực tiếp cho data engineering, ML và BI. Tích hợp Lakehouse architecture với Delta Lake (cập nhật 2026: Spark 3.5+ với autoscaling improved).

• Azure Databricks ✅
  Đúng: Platform dựa trên Apache Spark™ optimized cho Azure, cung cấp interactive notebooks, clusters và jobs cho Spark workloads. Hỗ trợ Delta Lake, MLflow (phiên bản 2026: Databricks Runtime 16.x với Spark 4.0, Photon engine cho performance cao gấp 10x).

• Azure Stream Analytics ❌
  Sai: Dịch vụ streaming analytics thời gian thực dùng ngôn ngữ ASAQL (dựa SQL), không hỗ trợ Apache Spark. Nó xử lý stream data từ IoT/Kafka nhưng không chạy Spark engine (dùng cho low-latency queries, không phải big data batch như Spark).

• Azure HDInsight ✅
  Đúng: Dịch vụ managed Hadoop/Spark clusters trên Azure, hỗ trợ Apache Spark clusters cho big data processing. Bao gồm Spark 3.x với Hive, HBase integration (cập nhật 2026: hỗ trợ E2 instances và auto-scaling cho Spark workloads).

Kết luận: Chọn đúng 3 đáp án trên để đạt 3 điểm đầy đủ! 🚀 Nếu cần thực hành lab, thử Azure Free Tier cho Databricks/Synapse.

🧩 Phân tích câu hỏi trắc nghiệm về loại dữ liệu trong AWS

📝 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 loại dữ liệu dựa trên một bảng dữ liệu dạng bảng (tabular format). Hình ảnh đính kèm hiển thị một bảng đơn giản với các cột tiêu đề rõ ràng: ID, First name, Last name, và Email. Bảng có hai hàng dữ liệu mẫu:

• Hàng 1: ID = 1001, First name = Ben, Last name = Smith, Email = bensmith@contoso.com.
• Hàng 2: ID = 1001 (lặp lại), First name = Carlos, Last name = Grilo, Email = carlosgrilo@contoso.com.

🖼️ Phân tích kỹ nội dung hình ảnh:
Hình ảnh minh họa một bảng dữ liệu có cấu trúc cố định, với các cột được định nghĩa rõ ràng (ID là số nguyên, First name và Last name là chuỗi ký tự, Email là địa chỉ email). Dữ liệu được tổ chức theo hàng và cột, dễ dàng truy vấn bằng SQL hoặc lưu trữ trong cơ sở dữ liệu quan hệ (relational database) như Amazon RDS hoặc Amazon Redshift trên AWS. Đây không phải dữ liệu lộn xộn mà có schema (lược đồ) nghiêm ngặt, phù hợp với khái niệm structured data theo phân loại dữ liệu tiêu chuẩn của AWS (cập nhật đến 2026).

✅ Đáp án đúng: structured data
Lý do lựa chọn: Dữ liệu trong bảng có cấu trúc rõ ràng với các cột cố định, kiểu dữ liệu nhất quán và dễ dàng xử lý bằng các công cụ relational như SQL. Trong AWS, structured data thường được lưu trữ trong các dịch vụ như Amazon RDS, DynamoDB (ở chế độ relational), hoặc S3 với Athena cho truy vấn SQL, giúp dễ dàng phân tích và quản lý. Điều này khớp chính xác với định nghĩa từ tài liệu AWS Well-Architected Framework (Data Analytics Lens, 2026).

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

• structured data ✅ Đúng: Đây là dữ liệu có cấu trúc (structured), tổ chức theo bảng với schema cố định (cột, hàng, kiểu dữ liệu). Phù hợp với cơ sở dữ liệu quan hệ trên AWS như RDS hoặc Redshift, dễ truy vấn bằng SQL mà không cần parsing phức tạp.
• unstructured data ❌ Sai: Dữ liệu không cấu trúc (unstructured) bao gồm văn bản tự do, hình ảnh, video, âm thanh (ví dụ: file PDF, ảnh JPEG trên Amazon S3 mà không có schema). Bảng ở đây có cấu trúc rõ ràng, không phải unstructured.
• semi-structured data ❌ Sai: Dữ liệu bán cấu trúc (semi-structured) có tag hoặc key linh hoạt như JSON, XML, Avro (ví dụ: log files trên Amazon S3 hoặc Amazon Glue). Bảng này có schema rigid (cố định), không linh hoạt như semi-structured.
• document ❌ Sai: "Document" ám chỉ dữ liệu dạng tài liệu trong NoSQL document database như Amazon DocumentDB (dựa trên MongoDB), lưu trữ JSON/BSON tự do. Bảng tabular này không phải document mà là relational structure.

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

• AWS Documentation: Data types classification (cập nhật 2026).
• AWS Certified Data Analytics - Specialty Exam Guide: Phân loại structured/semi-structured/unstructured.
• Microsoft Azure DP-900 (tương đương): Relational data models trong Azure SQL Database (áp dụng tương tự AWS).

Hy vọng phân tích này giúp bạn nắm vững khái niệm dữ liệu trên AWS! 🚀

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

Câu hỏi gốc: What can you use to create data ingestion pipelines?
Dịch nghĩa: Bạn có thể sử dụng gì để tạo các pipeline thu thập dữ liệu (data ingestion pipelines)?

🛤️ 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 dịch vụ đám mây nào trong hệ sinh thái Microsoft Azure phù hợp để xây dựng data ingestion pipelines – tức là các quy trình tự động hóa việc thu thập, chuyển đổi và tải dữ liệu từ nhiều nguồn khác nhau (như file, database, API, stream dữ liệu) vào kho dữ liệu đích. Đây là một phần quan trọng trong quy trình ETL/ELT (Extract, Transform, Load/Extract, Load, Transform). Trong Azure, các pipeline này cần hỗ trợ tích hợp dữ liệu hybrid (on-premises và cloud), xử lý dữ liệu lớn (big data), và tích hợp với các công cụ analytics khác. Kiến thức dựa trên phiên bản Azure Data Factory mới nhất (tính đến 2026, bao gồm Data Factory v2 với hỗ trợ serverless integration runtime và mapping data flows nâng cao).

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

Đáp án đúng: Azure Data Factory
📘 Lý do: Azure Data Factory (ADF) là dịch vụ cloud-based data integration service chuyên dụng để tạo, lên lịch và quản lý các data pipelines một cách dễ dàng. Nó hỗ trợ đầy đủ data ingestion từ hàng trăm connector (như Azure Blob, SQL Server, Kafka, Salesforce), xử lý dữ liệu thời gian thực hoặc batch, và tích hợp với Azure Synapse Analytics. ADF cho phép thiết kế pipeline qua giao diện kéo-thả hoặc code (JSON/ARM templates), với tính năng như triggers, parameters và monitoring tích hợp. Đây là lựa chọn chuẩn theo tài liệu chính thức Microsoft (cập nhật 2026).

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

• Azure HDInsight ❌
  Phân tích sai: Azure HDInsight là dịch vụ managed Hadoop/Spark cluster dùng cho big data processing (như Hive, Spark, Storm), không phải công cụ chính để tạo data ingestion pipelines. Nó tập trung vào xử lý và phân tích dữ liệu lớn sau khi ingestion, chứ không hỗ trợ thiết kế pipeline end-to-end. Nếu cần ingestion vào HDInsight, bạn vẫn phải dùng ADF hoặc công cụ khác để đưa dữ liệu vào trước.

• Azure SQL Database ❌
  Phân tích sai: Azure SQL Database là fully managed relational database service (dựa trên SQL Server), dùng để lưu trữ và query dữ liệu có cấu trúc. Nó không có tính năng native để tạo pipelines ingestion từ nhiều nguồn; chỉ hỗ trợ import/export cơ bản qua SSIS hoặc bcp utility. Không phù hợp cho pipeline phức tạp đa nguồn.

• Azure Data Factory ✅
  Phân tích đúng: Như đã giải thích ở trên, ADF là dịch vụ ETL/ELT orchestration lý tưởng cho data ingestion pipelines. Nó hỗ trợ hơn 100 connectors, data flows, và integration runtime (self-hosted hoặc Azure-hosted), với các tính năng mới 2026 như enhanced Spark integration và AI-driven pipeline optimization. Hoàn hảo cho hybrid/multi-cloud scenarios.

• Azure Cosmos DB ❌
  Phân tích sai: Azure Cosmos DB là globally distributed NoSQL database với multi-model support (document, key-value, graph, columnar). Nó hỗ trợ ingestion qua SDK/API hoặc change feed, nhưng không phải công cụ để tạo pipelines – chỉ là đích đến lưu trữ. Không có giao diện thiết kế pipeline như ADF.

📚 Tài liệu tham khảo

• Azure Data Factory Documentation (Microsoft Learn, cập nhật liên tục đến 2026).
• Introduction to Azure Data Factory – Chi tiết về pipelines và ingestion.
• Azure Data Fundamentals (DP-900) Study Guide – Phù hợp với chứng chỉ DP-900.

🛠️ Lời khuyên: Để thực hành, hãy thử tạo pipeline đơn giản trên Azure Portal với ADF – rất trực quan! Nếu cần ví dụ code hoặc demo, hãy hỏi thêm nhé! 🚀

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

Câu hỏi gốc (bằng tiếng Anh):
"Which service is optimized for IoT scenarios that involve streaming time series data?"

Giải thích nội dung câu hỏi:
🛠️ Câu hỏi đang hỏi về dịch vụ nào được tối ưu hóa dành riêng cho các kịch bản IoT (Internet of Things), đặc biệt liên quan đến dữ liệu chuỗi thời gian (time series data) dạng streaming (dữ liệu được truyền liên tục theo thời gian thực từ các thiết bị IoT như cảm biến, máy móc công nghiệp).
📘 Trong bối cảnh Microsoft Azure, đây là câu hỏi kiểm tra kiến thức về các dịch vụ cơ sở dữ liệu được thiết kế cho môi trường edge computing (xử lý dữ liệu tại biên, gần thiết bị IoT) với khả năng xử lý dữ liệu thời gian thực hiệu quả, hỗ trợ các tính năng như time series analytics, streaming queries qua T-SQL, và tích hợp với Azure IoT Edge. Câu hỏi nhấn mạnh vào sự tối ưu hóa (optimized) cho IoT, không phải các dịch vụ SQL thông thường.

Đáp án đúng: ✅ Azure SQL Edge
Lý do lựa chọn:
🟢 Azure SQL Edge là phiên bản SQL Server siêu nhẹ, được thiết kế dành riêng cho các thiết bị edge trong môi trường IoT. Nó hỗ trợ streaming time series data qua các tính năng như T-SQL streaming, time series insights, last observed value (LOV), và aggregation thời gian thực. Dịch vụ này chạy trên Linux containers, dễ dàng triển khai trên Azure IoT Edge, giúp xử lý dữ liệu tại chỗ mà không cần gửi hết về cloud, giảm độ trễ và chi phí. Đây là lựa chọn tối ưu nhất cho IoT theo tài liệu Microsoft cập nhật đến năm 2026 (phiên bản Azure SQL Edge 2.0+ vẫn duy trì các tính năng này).

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai), kèm giải thích bằng tiếng Việt dựa trên kiến thức Azure mới nhất (2026).

• ❌ SQL Server on Azure Virtual Machines
  🛑 Sai vì: Đây là dịch vụ chạy SQL Server truyền thống trên máy ảo Azure (VM), không được tối ưu hóa cho IoT edge hay streaming time series. Nó phù hợp cho workload enterprise lớn, nhưng nặng nề, tốn tài nguyên và không hỗ trợ native streaming IoT như containers edge. Phải tự quản lý VM, không lý tưởng cho thiết bị IoT hạn chế tài nguyên.

• ❌ Azure SQL Managed Instance
  🛑 Sai vì: Đây là dịch vụ PaaS managed SQL Server với tính năng gần như on-premises, hỗ trợ database lớn và migration. Tuy nhiên, nó chạy hoàn toàn trên cloud, không dành cho edge devices IoT, thiếu hỗ trợ streaming time series native và không tích hợp IoT Edge. Phù hợp cho ứng dụng doanh nghiệp, không phải IoT thời gian thực.

• ❌ Azure SQL Database
  🛑 Sai vì: Đây là dịch vụ serverless SQL PaaS trên cloud, hỗ trợ hyperscale và auto-scaling tốt cho OLTP/OLAP. Nhưng nó không được thiết kế cho IoT edge, thiếu tính năng streaming time series chuyên biệt, và yêu cầu kết nối cloud liên tục – không phù hợp với môi trường IoT offline hoặc low-latency tại biên.

• ✅ Azure SQL Edge
  🟢 Đúng vì: Như đã giải thích ở trên, đây là dịch vụ duy nhất được Microsoft tối ưu hóa cho IoT, với kích thước nhỏ (dưới 500MB), hỗ trợ JSON, time series data streaming, và tích hợp Azure Stream Analytics/IoT Hub. Cập nhật 2026: Vẫn là lựa chọn hàng đầu cho industrial IoT (IIoT) với hỗ trợ AI edge.

📚 Tài liệu tham khảo

• Microsoft Docs chính thức (cập nhật 2026): Azure SQL Edge Overview – Chi tiết tính năng IoT streaming.
• Azure IoT Docs: What's new in Azure SQL Edge – Xác nhận hỗ trợ time series đến phiên bản mới nhất.
• Cert Guide DP-900 (Azure Data Fundamentals): Nhấn mạnh Azure SQL Edge cho IoT scenarios.

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 câu hỏi, hãy hỏi nhé!

🧩 Giải thích nội dung câu hỏi một cách chi tiết và rõ ràng
Câu hỏi này tập trung vào phân loại các loại câu lệnh SQL (Structured Query Language) theo chức năng chuẩn trong cơ sở dữ liệu quan hệ. Cụ thể, nó hỏi GRANT, REVOKE, và DENY là ví dụ của loại câu lệnh SQL nào.

• GRANT: Cấp quyền truy cập (ví dụ: cấp quyền SELECT cho user).
• REVOKE: Thu hồi quyền đã cấp (ví dụ: thu hồi quyền INSERT).
• DENY: Từ chối quyền cụ thể (ví dụ: cấm quyền UPDATE dù đã được cấp gián tiếp).
  Những lệnh này liên quan đến quyền truy cập và bảo mật dữ liệu, không phải tạo/xóa cấu trúc hay thao tác dữ liệu. Đây là kiến thức cơ bản SQL, áp dụng chung cho các nền tảng như Microsoft Azure SQL Database, AWS RDS (hỗ trợ SQL Server, MySQL, PostgreSQL), và vẫn giữ nguyên đến năm 2026 theo chuẩn ANSI SQL và các phiên bản mới nhất (SQL Server 2022, PostgreSQL 17).

✅ Đáp án đúng: Data Control Language (DCL)
Lý do lựa chọn: DCL là loại câu lệnh SQL chuyên dùng để kiểm soát quyền truy cập dữ liệu (Data Control Language). GRANT, REVOKE, DENY chính xác thuộc nhóm này vì chúng quản lý quyền người dùng (permissions) trên các đối tượng cơ sở dữ liệu như bảng, view, stored procedure. Trong thực tế, DCL đảm bảo bảo mật bằng cách quyết định "ai được làm gì" trên dữ liệu, không thay đổi cấu trúc hay nội dung dữ liệu. Điều này được xác nhận trong các hệ thống đám mây như Azure SQL và AWS RDS.

🛠️ Phân tích tất cả các phương án (đúng và sai):

• [SAI] Data Definition language (DDL) ❌
  Giải thích sai: DDL dùng để định nghĩa và quản lý cấu trúc cơ sở dữ liệu (như CREATE TABLE, ALTER TABLE, DROP INDEX, TRUNCATE TABLE). GRANT/REVOKE/DENY không tạo/xóa/sửa cấu trúc, mà chỉ kiểm soát quyền, nên không thuộc DDL.

• [ĐÚNG] Data Control Language (DCL) ✅
  Giải thích đúng: Như đã nêu, DCL chuyên quản lý quyền truy cập (GRANT, REVOKE, DENY). Đây là loại câu lệnh cốt lõi cho bảo mật, thường yêu cầu quyền sysadmin để thực thi, và được hỗ trợ đầy đủ trong Azure SQL Database cũng như AWS RDS cho SQL Server/PostgreSQL (phiên bản 2026 không thay đổi phân loại này).

• [SAI] Data Manipulation Language (DML) ❌
  Giải thích sai: DML dùng để thao tác dữ liệu (như SELECT, INSERT, UPDATE, DELETE, MERGE). Những lệnh này chỉ đọc/thay đổi dữ liệu, không liên quan đến quyền truy cập, nên GRANT/REVOKE/DENY hoàn toàn không thuộc DML.

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

• Microsoft Docs (Azure SQL): SQL Server Permissions (cập nhật 2023-2026).
• AWS RDS Documentation: Managing Permissions in RDS for SQL Server (hỗ trợ GRANT/REVOKE/DENY chuẩn SQL).
• ANSI SQL Standard (ISO/IEC 9075): Phân loại DCL rõ ràng cho quyền truy cập.

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

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

Câu hỏi gốc (bằng tiếng Anh):
Which statement is an example of Data Definition Language (DDL)?

🛠️ Giải thích nội dung câu hỏi:
Câu hỏi này kiểm tra kiến thức cơ bản về các loại câu lệnh SQL, cụ thể là phân biệt Data Definition Language (DDL) - ngôn ngữ định nghĩa dữ liệu. DDL dùng để xác định cấu trúc cơ sở dữ liệu, như tạo, sửa đổi hoặc xóa các đối tượng (bảng, schema, index...). Đây là khái niệm chuẩn trong SQL, áp dụng cho các dịch vụ AWS như Amazon RDS (hỗ trợ MySQL, PostgreSQL, SQL Server...), Amazon Aurora, hoặc Amazon Redshift (phiên bản mới nhất 2026 vẫn giữ nguyên phân loại DDL/DML theo chuẩn ANSI SQL). Câu hỏi yêu cầu xác định câu lệnh nào thuộc DDL trong các lựa chọn, giúp đánh giá hiểu biết về quản lý dữ liệu trên đám mây AWS. Không liên quan trực tiếp đến Azure nhưng kiến thức SQL là chung.

✅ Đáp án đúng: CREATE

Lý do chọn đáp án đúng:
CREATE là câu 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 (CREATE TABLE), cơ sở dữ liệu (CREATE DATABASE), view, index... Ví dụ: CREATE TABLE users (id INT PRIMARY KEY);. Trong AWS RDS hoặc Aurora (cập nhật 2026), CREATE vẫn là DDL cốt lõi, hỗ trợ đầy đủ các engine SQL chuẩn. Điều này phù hợp với định nghĩa DDL theo chuẩn SQL (ANSI/ISO).

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

• SELECT ❌
  Sai vì: SELECT thuộc Data Manipulation Language (DML), dùng để truy vấn và lấy dữ liệu từ bảng (ví dụ: SELECT * FROM users;). Không thay đổi cấu trúc dữ liệu, chỉ đọc dữ liệu. Trong AWS Redshift hoặc RDS (2026), SELECT là DML thuần túy, không phải DDL.

• INSERT ❌
  Sai vì: INSERT thuộc DML, dùng để thêm dữ liệu mới vào bảng (ví dụ: INSERT INTO users VALUES (1, 'Alice');). Nó thao tác trên dữ liệu bên trong bảng, không định nghĩa cấu trúc. AWS Athena hoặc RDS xác nhận INSERT là DML, không ảnh hưởng schema.

• CREATE ✅
  Đúng vì: Như đã giải thích ở trên, CREATE là DDL chuẩn để tạo đối tượng dữ liệu. Hỗ trợ đầy đủ trong AWS Glue, RDS, DynamoDB migrations (qua SQL), và các dịch vụ 2026 như Amazon Aurora Serverless v3.

• MERGE ❌
  Sai vì: MERGE thuộc DML (hoặc đôi khi gọi là DML mở rộng), dùng để kết hợp INSERT, UPDATE, DELETE dựa trên điều kiện (ví dụ: MERGE INTO target USING source...). Không tạo/sửa cấu trúc, chỉ thao tác dữ liệu. Trong PostgreSQL trên RDS AWS (2026), MERGE là DML từ SQL:2016.

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

• AWS RDS Documentation: SQL Commands Reference - Phân loại DDL/DML rõ ràng.
• Amazon Redshift SQL Reference: DDL Statements - CREATE là DDL chính.
• Chuẩn SQL ANSI/ISO: ISO/IEC 9075-2:2023 (Information technology - Database languages - SQL).
• Microsoft Azure Docs (tương đương, để so sánh): SQL DDL - Xác nhận CREATE là DDL (dù vai trò Azure Fundamentals).

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