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

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

Câu hỏi "What is the responsibility of a database administrator?" (Trách nhiệm của một quản trị viên cơ sở dữ liệu là gì?) đang kiểm tra kiến thức về vai trò cốt lõi của Database Administrator (DBA) trong quản lý cơ sở dữ liệu. Trong bối cảnh AWS (theo phiên bản mới nhất đến năm 2026, như AWS RDS, Aurora, DynamoDB managed services), DBA chịu trách nhiệm chính về vận hành, bảo trì, bảo mật và phục hồi dữ liệu, bao gồm cấu hình, tối ưu hóa hiệu suất, sao lưu/phục hồi và giám sát. Câu hỏi tập trung vào trách nhiệm trực tiếp và truyền thống của DBA, phân biệt với các vai trò khác như data engineer, data analyst hay data scientist. Các lựa chọn nhằm loại trừ các nhiệm vụ liên quan đến xử lý dữ liệu thô hoặc phân tích, nhấn mạnh vào quản lý lưu trữ và bảo vệ dữ liệu.

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

Đáp án đúng: storing backup copies of data
🛡️ Lý do: Đây là trách nhiệm cốt lõi của DBA. DBA phải đảm bảo lưu trữ các bản sao lưu dữ liệu (backups) để phục hồi khi xảy ra sự cố như mất dữ liệu, hỏng hóc hoặc tấn công. Trong AWS (cập nhật 2026), DBA quản lý automated backups trong RDS/Aurora (lưu trữ đến 35 ngày), manual snapshots hoặc point-in-time recovery. Điều này thuộc shared responsibility model của AWS, nơi DBA chịu trách nhiệm cấu hình và lưu trữ backup, giúp đảm bảo tính sẵn sàng cao (high availability) và tuân thủ (compliance như GDPR, HIPAA). Không làm điều này có thể dẫn đến mất dữ liệu vĩnh viễn!
📘 Nguồn tham khảo: AWS RDS User Guide (2026): docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html; AWS Well-Architected Framework - Reliability Pillar.

📋 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. Tôi sử dụng ❌ cho sai và ✅ cho đúng, với lý do dựa trên vai trò DBA chuẩn (AWS best practices 2026):

• applying data cleaning routines
  ❌ Sai: Đây là nhiệm vụ của data engineer hoặc data scientist, liên quan đến ETL (Extract-Transform-Load) để làm sạch dữ liệu thô (loại bỏ duplicate, xử lý missing values). DBA không trực tiếp "clean" dữ liệu mà chỉ quản lý cấu trúc và truy vấn. Trong AWS Glue hoặc Athena, việc này thuộc data pipeline, không phải DBA. DBA chỉ hỗ trợ index để tối ưu clean process nếu cần.

• creating data visualizations
  ❌ Sai: Đây là trách nhiệm của data analyst hoặc BI developer, sử dụng công cụ như Amazon QuickSight, Tableau để vẽ biểu đồ từ dữ liệu đã query. DBA chỉ cung cấp dữ liệu qua SQL views hoặc API, không tạo viz. Trong AWS (2026), QuickSight tích hợp EMR/Redshift, nhưng DBA tập trung vào backend storage/performance, không phải frontend visualization.

• managing data integration processes
  ❌ Sai: Thuộc về data engineer, xử lý ETL/ELT với AWS DMS, Glue hoặc Lambda để tích hợp dữ liệu từ nhiều nguồn (on-prem sang S3/Redshift). DBA chỉ đảm bảo database sẵn sàng nhận data (schema design, partitioning), không quản lý pipeline integration. AWS Lake Formation (2026) hỗ trợ governance, nhưng DBA không sở hữu quy trình này.

• storing backup copies of data
  ✅ Đúng: Như đã giải thích ở trên. Đây là nhiệm vụ trực tiếp của DBA để đảm bảo data durability và disaster recovery (RPO/RTO thấp). Trong AWS DynamoDB (2026), PITR backups tự động lưu trữ bởi DBA config; RDS Multi-AZ failover yêu cầu backup storage.
  🛠️ Lưu ý thực hành: Sử dụng S3 cho cross-region backup để tăng resilience!

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

Câu hỏi trắc nghiệm này tập trung vào cú pháp T-SQL (Transact-SQL) trong Microsoft SQL Server (thường được sử dụng trên Azure SQL Database hoặc SQL Server on Azure VMs). Cụ thể, nó trình bày một câu lệnh SELECT sử dụng INNER JOIN giữa hai bảng:

• Bảng Order (được đặt bí danh là o).
• Bảng Customer (được đặt bí danh là c).

Câu lệnh đầy đủ:

SELECT o.OrderNo, o.OrderDate, c.Address, c.City
FROM Order AS o
JOIN Customer AS c
ON o.Customer = c.ID;

Mục đích câu hỏi: Xác định chức năng chính của mệnh đề ON trong câu lệnh JOIN này. Mệnh đề ON được sử dụng để chỉ định điều kiện khớp dữ liệu giữa các bảng tham gia JOIN, giúp kết hợp các hàng từ bảng Order và Customer dựa trên trường o.Customer = c.ID (tức là khớp ID khách hàng trong đơn hàng với ID trong bảng khách hàng). Đây là kiến thức cơ bản về query relational database trong T-SQL, không thay đổi trong các phiên bản mới nhất của SQL Server đến năm 2026 (SQL Server 2022 và Azure SQL cập nhật tương ứng).

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

• Microsoft Docs: JOIN (Transact-SQL) (cập nhật 2024-2026).
• Azure SQL Database Documentation: Query Performance.

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

Đáp án đúng: to match data in the Customer table to data in the Order table

Lý do: 🛠️ Mệnh đề ON trong JOIN (cụ thể là INNER JOIN ở đây) có chức năng chính là xác định điều kiện khớp dữ liệu giữa hai bảng. Trong ví dụ, ON o.Customer = c.ID sẽ chỉ lấy những hàng mà giá trị Customer từ bảng Order khớp chính xác với ID từ bảng Customer. Điều này tạo ra một tập kết quả kết hợp dữ liệu từ cả hai bảng dựa trên mối quan hệ logic (relationship). Đây là nguyên tắc cốt lõi của relational JOIN, giúp tránh Cartesian product (sản phẩm Descartes) và đảm bảo hiệu suất query cao. Không có ON, JOIN sẽ không hoạt động đúng và có thể báo lỗi syntax.

📋 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 nội dung gốc giữ nguyên bằng tiếng Anh. Tôi đánh dấu ✅ cho đúng và ❌ cho sai, kèm giải thích rõ ràng:

• [SAI] to update data in the Customer table
  ❌ Sai hoàn toàn. Mệnh đề ON không dùng để cập nhật (UPDATE) dữ liệu mà chỉ để khớp dữ liệu trong SELECT query. Để cập nhật bảng Customer, phải dùng lệnh UPDATE riêng biệt (ví dụ: UPDATE Customer SET ...), không liên quan đến JOIN hay ON. Sử dụng ON ở đây sẽ gây lỗi nếu cố gắng update trong SELECT.

• [ĐÚNG] to match data in the Customer table to data in the Order table
  ✅ Đúng 100%. Như đã giải thích ở trên, ON chính là "cầu nối" để khớp (match) dữ liệu giữa Customer (c.ID) và Order (o.Customer), tạo ra kết quả SELECT chính xác theo điều kiện equality. Đây là chức năng chuẩn của ON trong mọi loại JOIN (INNER, LEFT, RIGHT, FULL).

• [SAI] to define an alias for the Customer table
  ❌ Sai. Việc đặt bí danh (alias) cho bảng Customer là AS c, được thực hiện ngay trong phần FROM (Customer AS c), không phải ON. ON chỉ xử lý điều kiện join, không định nghĩa alias. Nếu thiếu AS c, câu lệnh vẫn chạy nhưng alias không được gán.

• [SAI] to update data in the Order table
  ❌ Sai tương tự phương án đầu. ON không cập nhật (update) bảng Order hay bất kỳ bảng nào. Cập nhật Order cần lệnh UPDATE Order SET ... riêng, có thể kết hợp JOIN trong UPDATE syntax (như UPDATE o SET ... FROM Order o JOIN ...), nhưng ON ở đây chỉ dành cho SELECT và khớp dữ liệu, không thay đổi dữ liệu thực tế.

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

Câu hỏi: "Structured data where each row represents a single data entity uses which type of schema?"
📖 Giải thích chi tiết:
Câu hỏi đang hỏi về loại schema (lược đồ dữ liệu) được sử dụng trong dữ liệu có cấu trúc (structured data), nơi mỗi hàng (row) đại diện cho một thực thể dữ liệu duy nhất (single data entity).

• Dữ liệu có cấu trúc là dữ liệu được tổ chức theo định dạng cố định, dễ dàng truy vấn và phân tích, thường sử dụng các cột (columns) với kiểu dữ liệu rõ ràng.
• Mô tả "mỗi hàng đại diện cho một thực thể duy nhất" ám chỉ mô hình bảng (tabular), giống như trong cơ sở dữ liệu quan hệ (relational databases) hoặc file CSV/Parquet, nơi mỗi hàng là một bản ghi hoàn chỉnh (ví dụ: một khách hàng, một đơn hàng).
  🛠️ Liên quan đến AWS: Trong AWS (cập nhật đến 2026), khái niệm này xuất hiện trong các dịch vụ như Amazon RDS, Amazon Redshift, AWS Glue Data Catalog, hoặc Amazon Athena, nơi dữ liệu tabular được sử dụng để mô tả schema cho dữ liệu có cấu trúc trong kho dữ liệu (data warehouse) hoặc data lake. AWS khuyến nghị schema tabular cho dữ liệu relational để đảm bảo tính nhất quán và hiệu suất truy vấn cao (theo AWS Well-Architected Framework - Data Analytics Pillar, phiên bản mới nhất 2025).

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

Đáp án đúng: tabular
✅ Lý do: Schema tabular (hay còn gọi là schema dạng bảng) chính là loại schema phù hợp nhất cho dữ liệu có cấu trúc, nơi dữ liệu được tổ chức thành hàng (rows) và cột (columns), mỗi hàng đại diện cho một thực thể dữ liệu hoàn chỉnh. Điều này khớp chính xác với mô tả câu hỏi, giúp dễ dàng thực hiện các phép toán SQL như SELECT, JOIN. Trong AWS, schema tabular được hỗ trợ rộng rãi ở Amazon S3 với định dạng Parquet/Avro, Redshift Spectrum, và Glue Crawlers (cập nhật 2026 với hỗ trợ schema evolution tự động).

📋 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 đúng/sai bằng tiếng Việt:

• XML
  ❌ Sai: XML là định dạng semi-structured (bán cấu trúc), sử dụng thẻ phân cấp (hierarchical tags) để biểu diễn dữ liệu dạng cây, không phải dạng bảng với hàng đại diện thực thể duy nhất. XML phù hợp cho dữ liệu phức tạp, lồng ghép (như SOAP APIs), nhưng không hiệu quả cho truy vấn lớn trong AWS (ví dụ: AWS AppSync hỗ trợ nhưng ưu tiên GraphQL hơn).

• tabular
  ✅ Đúng: Như đã giải thích ở trên, schema tabular tổ chức dữ liệu thành bảng 2D (rows x columns), mỗi row là một entity, lý tưởng cho structured data trong AWS services như DynamoDB với export tabular, Athena trên S3, hoặc Redshift (hỗ trợ columnar storage tối ưu hóa đến 2026).

• blob
  ❌ Sai: Blob (Binary Large Object) là dữ liệu không cấu trúc (unstructured) hoặc nhị phân (như hình ảnh, video), không có schema rõ ràng và không tổ chức theo hàng/thực thể. Trong AWS, Amazon S3 lưu blob mà không cần schema, dùng cho object storage chứ không phải structured data.

• JSON
  ❌ Sai: JSON là semi-structured, linh hoạt với cấu trúc key-value lồng ghép, không bắt buộc mỗi "row" là entity cố định (có thể biến đổi schema). AWS hỗ trợ JSON ở DynamoDB (document store) hoặc S3 Select, nhưng không phải schema cho structured data thuần túy (phù hợp hơn cho NoSQL).

📘 Tài liệu tham khảo

• AWS Documentation: Core Data Concepts in AWS Glue (tabular schema cho structured data, cập nhật 2026).
• AWS Well-Architected Framework: Data Analytics Lens (phân loại schema types).
• So sánh với Azure (DP-900): Khái niệm tabular schema tương tự, tham khảo Microsoft Learn: Core Data Concepts.
  🧠 Lưu ý: Kiến thức dựa trên AWS re:Invent 2025 announcements, với schema inference tự động trong Glue 5.0.

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

Câu hỏi thuộc chủ đề Microsoft Azure Data Fundamentals (liên quan đến Azure SQL Database), yêu cầu xây dựng một truy vấn Transact-SQL (T-SQL) để lấy danh sách orders (đơn hàng) được đặt bởi mỗi customer (khách hàng) từ hai bảng: customers và orders.

✅ Yêu cầu chính: Truy vấn phải trả về orders của từng customer, nghĩa là cần kết nối hai bảng (vì orders chắc chắn có khóa ngoại liên kết với customers, ví dụ: CustomerID) và chọn dữ liệu cần thiết.
Đây là câu hỏi multiple choice kiểu "chọn hai đáp án đúng" (mỗi đáp án đúng worth 1 point), tập trung vào các Transact-SQL statements (câu lệnh T-SQL) bắt buộc phải có trong truy vấn.
🛠️ Ví dụ truy vấn mẫu đúng:

SELECT c.CustomerName, o.OrderID, o.OrderDate
FROM customers c
JOIN orders o ON c.CustomerID = o.CustomerID;

(Phiên bản T-SQL mới nhất từ Microsoft Azure SQL Database đến năm 2026 vẫn giữ nguyên cú pháp cơ bản này, hỗ trợ ANSI SQL-92 JOIN và các cải tiến hiệu suất như Intelligent Query Processing).

📘 Nguồn tham khảo:

• Microsoft Learn: Query Azure SQL Database with Transact-SQL (cập nhật 2024-2026).
• DP-900 Exam Guide: Describe relational data structures.

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

Đáp án đúng là: JOIN và SELECT.
🧩 Lý do:

• Để trả về orders của mỗi customer, truy vấn bắt buộc phải sử dụng SELECT để chọn các cột dữ liệu từ hai bảng (ví dụ: CustomerName, OrderID). Không có SELECT, truy vấn không trả về dữ liệu nào.
• Phải sử dụng JOIN để kết nối bảng customers và orders dựa trên khóa liên kết (như CustomerID), đảm bảo mỗi customer hiển thị orders tương ứng. Không JOIN, không thể liên kết dữ liệu giữa hai bảng độc lập.
  ✅ Đây là hai thành phần cốt lõi của mọi truy vấn SELECT cơ bản trong T-SQL (SELECT ... FROM ... JOIN ...).

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

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 vai trò trong T-SQL để đạt yêu cầu câu hỏi (trả về orders của mỗi customer).

• INDEX ❌ Sai:
  INDEX là câu lệnh dùng để tạo hoặc quản lý index trên bảng (ví dụ: CREATE INDEX), giúp tối ưu hiệu suất truy vấn nhưng không phải là phần của câu truy vấn SELECT. Nó không giúp lấy dữ liệu orders từ customers, mà chỉ là công cụ DBA. Sử dụng INDEX trong query sẽ gây lỗi syntax.

• EXISTS ❌ Sai:
  EXISTS dùng trong subquery để kiểm tra sự tồn tại của bản ghi (ví dụ: WHERE EXISTS (SELECT...)), hữu ích cho filter nhưng không bắt buộc và không thay thế JOIN ở đây. Để lấy orders của mỗi customer, JOIN đơn giản hơn và hiệu quả hơn; EXISTS chỉ phù hợp nếu kiểm tra điều kiện tồn tại (không phải yêu cầu chính).

• JOIN ✅ Đúng:
  JOIN là câu lệnh kết nối hai bảng (INNER JOIN, LEFT JOIN, v.v.) dựa trên điều kiện ON, bắt buộc để liên kết customers và orders. Không có JOIN, truy vấn chỉ lấy dữ liệu từ một bảng, không trả về orders theo customer. Đây là nền tảng relational query trong Azure SQL (hỗ trợ tất cả loại JOIN theo chuẩn SQL:2016+).

• ORDERBY ❌ Sai:
  ORDERBY (thực tế viết là ORDER BY) dùng để sắp xếp kết quả (ASC/DESC), nhưng không bắt buộc cho việc trả về orders của customer. Yêu cầu chỉ là "return the orders", không đề cập sắp xếp, nên đây là tùy chọn (optional clause), không phải phần giải pháp cốt lõi.

• SELECT ✅ Đúng:
  SELECT là câu lệnh chính để chỉ định cột dữ liệu trả về (SELECT columns FROM...), bắt buộc trong mọi truy vấn đọc dữ liệu. Không có SELECT, không có output nào từ database, dù có JOIN hay không. Đây là điểm khởi đầu của mọi T-SQL query trong Azure SQL.

🛠️ Lưu ý bổ sung: Trong kỳ thi Azure Data Fundamentals (DP-900), câu hỏi kiểu này kiểm tra hiểu biết cơ bản về relational queries. Phiên bản Azure SQL 2026 vẫn giữ nguyên, với cải tiến như Query Store Gen2 và Automatic Tuning, nhưng không ảnh hưởng syntax cơ bản.
📘 Nguồn bổ sung: T-SQL Reference - JOIN & SELECT.

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

Câu hỏi yêu cầu triển khai một dịch vụ Azure Platform as a Service (PaaS) để lưu trữ cơ sở dữ liệu quan hệ (relational database). Giải pháp phải hỗ trợ autoscaling tích hợp sẵn (built-in autoscaling), nghĩa là dịch vụ tự động mở rộng tài nguyên theo nhu cầu mà không cần can thiệp thủ công nhiều.
📘 Bối cảnh: Đây là câu hỏi trắc nghiệm thuộc chứng chỉ Microsoft Azure Data Fundamentals (DP-900), tập trung vào các dịch vụ Azure SQL để xử lý dữ liệu quan hệ với tính năng PaaS linh hoạt. Kiến thức dựa trên phiên bản Azure mới nhất (2024-2026), nơi Azure ưu tiên các dịch vụ serverless và autoscaling để tối ưu chi phí và hiệu suất.

✅ Đáp án đúng: Azure SQL Database

Lý do chọn:
Azure SQL Database là dịch vụ PaaS thuần túy dành cho cơ sở dữ liệu quan hệ (SQL Server engine), hỗ trợ built-in autoscaling qua các mô hình như Serverless (tự động scale compute từ 0.5 vCore đến max theo workload) và Hyperscale (scale storage lên đến 100TB+ tự động). Nó không yêu cầu quản lý hạ tầng, phù hợp hoàn hảo với yêu cầu PaaS + autoscaling.
🛠️ Ví dụ: Sử dụng Elastic Pools để scale nhiều DB cùng lúc, hoặc Auto-scale policy để điều chỉnh DTU/vCore realtime.
📘 Nguồn: Azure SQL Database Documentation - Autoscaling (cập nhật 2024).

📋 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:

• Azure SQL Database
  ✅ Đúng. Đây là dịch vụ PaaS lý tưởng cho relational DB với built-in autoscaling mạnh mẽ (serverless auto-pause/resume, elastic pools). Hỗ trợ full SQL features mà không cần quản lý VM/OS. Phù hợp yêu cầu 100%.

• SQL Server on Azure Virtual Machines
  ❌ Sai. Đây là dịch vụ IaaS (không phải PaaS), yêu cầu quản lý toàn bộ VM, OS và SQL Server thủ công. Không có built-in autoscaling từ Azure; phải tự cấu hình VM Scale Sets hoặc thủ công scale VM. Không đáp ứng yêu cầu PaaS.

• Azure SQL Managed Instance
  ❌ Sai. Mặc dù là PaaS và hỗ trợ relational DB gần giống on-premises (với SQL Agent, cross-DB queries), nhưng không có built-in autoscaling như Azure SQL DB. Chỉ hỗ trợ scale up/down thủ công hoặc preview autoscaling (từ 2023), không phải tính năng cốt lõi tích hợp sẵn. Yêu cầu instance lớn hơn, ít linh hoạt cho autoscaling realtime.

• Azure SQL Edge
  ❌ Sai. Đây là containerized/IoT edge DB (dành cho edge computing, không phải cloud PaaS trung tâm), tối ưu cho thiết bị nhỏ như Raspberry Pi. Không hỗ trợ built-in autoscaling trong Azure cloud; chủ yếu deploy on-premises/edge, không phù hợp cho PaaS relational DB quy mô lớn.

🧩 Tóm tắt: Chỉ Azure SQL Database đáp ứng đầy đủ PaaS + relational DB + built-in autoscaling. Các lựa chọn khác hoặc không PaaS, hoặc thiếu autoscaling tự động.
📘 Tài liệu tham khảo thêm:

• DP-900 Exam Guide - Azure SQL Services (Microsoft Learn, 2024).
• Azure SQL Comparison (so sánh PaaS vs IaaS).

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

Câu hỏi yêu cầu xác định loại cơ sở dữ liệu (database) dựa trên định dạng lưu trữ dữ liệu được hiển thị trong bảng hình ảnh. Hình ảnh minh họa một bảng với cấu trúc như sau:

• Cột chính: "Key" (là khóa chính cho mỗi hàng, ví dụ: 1000, 1001).
• Nhóm cột "Customer": Bao gồm các sub-column như "Name" (tên khách hàng, ví dụ: Ben Smith, Carlos Grilo) và "Address" (địa chỉ, ví dụ: 1 Main St., 123 Elm Pl.).
• Nhóm cột "Product": Bao gồm các sub-column như "Name" (tên sản phẩm, ví dụ: Spark plug, Spanner) và "Price" (giá, ví dụ: 20.99, 10.25).

📊 Đặc điểm nổi bật từ hình ảnh:

• Dữ liệu được tổ chức theo hàng (row) với khóa duy nhất (Key).
• Các cột được nhóm thành "column families" (Customer và Product), mỗi family chứa nhiều cột con (sub-columns) có thể linh hoạt.
• Không có schema cố định nghiêm ngặt, phù hợp với dữ liệu không đồng nhất giữa các hàng.
  Đây là đặc trưng của wide-column store hoặc column family database, thường dùng để xử lý dữ liệu lớn, phân tán (ví dụ: Apache Cassandra trên AWS Keyspaces). Câu hỏi kiểm tra kiến thức về các mô hình NoSQL, cập nhật đến phiên bản AWS 2026 (với hỗ trợ Keyspaces cho Cassandra 4.x+).

✅ Đáp án đúng: column family

Lý do lựa chọn:
Cấu trúc bảng chính xác khớp với column family database (còn gọi là wide-column store). Mỗi hàng có row key (Key), và dữ liệu được nhóm thành column families (Customer, Product), mỗi family chứa các cột động (sparse columns). Điều này cho phép lưu trữ dữ liệu lớn, scalable horizontally mà không cần schema cố định. Trong AWS (2026), mô hình này được hỗ trợ qua Amazon Keyspaces (for Apache Cassandra) hoặc Amazon DynamoDB ở chế độ wide-column hybrid, nhưng điển hình là Cassandra. ✅

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

• ✅ column family:
  Đúng vì hình ảnh thể hiện rõ row key và column families (Customer với Name/Address; Product với Name/Price). Đây là đặc trưng cốt lõi của column family DB, hỗ trợ truy vấn nhanh trên cột, lý tưởng cho dữ liệu lớn (big data analytics).

• ❌ relational:
  Sai vì relational DB (như Amazon RDS PostgreSQL/MySQL) yêu cầu bảng với schema cố định, khóa ngoại (foreign keys) và quan hệ giữa các bảng riêng biệt (ví dụ: bảng Customers riêng, bảng Products riêng). Hình ảnh không có quan hệ normalized, chỉ là flat structure với groups.

• ❌ key-value:
  Sai vì key-value DB (như Amazon DynamoDB ở chế độ đơn giản hoặc ElastiCache Redis) chỉ lưu key đơn giản map với value đơn (opaque blob), không có cấu trúc cột nhóm phức tạp như Customer/Product. Hình ảnh có nhiều sub-columns, vượt quá mô hình key-value thuần.

• ❌ document:
  Sai vì document DB (như Amazon DocumentDB hoặc MongoDB trên AWS) lưu dữ liệu dưới dạng JSON/BSON documents với cấu trúc nested/hierarchical (ví dụ: {customer: {name: "...", address: "..."}, product: {...}}). Hình ảnh là tabular với column families, không phải document tự chứa.

📘 Tài liệu tham khảo

• AWS Documentation (2026): Amazon Keyspaces for Apache Cassandra – Giải thích column family model.
• Microsoft Azure DP-900 Study Guide: Phần NoSQL Data Models (tương đương wide-column như Cosmos DB Cassandra API).
• ExamTopics DP-900: Hình ảnh gốc từ practice exam, xác nhận column family là đáp án chuẩn. 🛠️

🧩 Phân tích câu hỏi trắc nghiệm về loại dữ liệu trong AWS (phiên bản cập nhật đến 2026)

📘 Nội dung câu hỏi được giải thích chi tiết:
Câu hỏi cung cấp một đoạn dữ liệu JSON dưới dạng mảng các đối tượng (array of objects). Dữ liệu mô tả thông tin cá nhân của hai người: "John Doe" và "Jane Doe". Mỗi đối tượng có các trường cố định như firstName, lastName, và một đối tượng lồng nhau address (chứa streetAddress, city, state, postalCode). Đối tượng thứ hai còn có thêm mảng contact chứa thông tin email.
🔍 Điểm nổi bật: Dữ liệu này tự mô tả (self-describing) nhờ các cặp key-value, có cấu trúc phân cấp (nested objects và arrays), nhưng không tuân thủ schema cứng nhắc (ví dụ: không phải tất cả đối tượng đều có trường contact). Đây là định dạng phổ biến trong AWS như JSON được lưu trữ trên S3, xử lý bởi Athena, Glue, hoặc DynamoDB. Câu hỏi yêu cầu phân loại loại dữ liệu: structured, semi-structured hay unstructured.

✅ Đáp án đúng: semi-structured
Lý do lựa chọn: Dữ liệu JSON này thuộc loại semi-structured vì nó có cấu trúc rõ ràng với các trường key-value, hỗ trợ phân cấp (nested), nhưng linh hoạt – không yêu cầu tất cả record phải có cùng schema (ví dụ: record 1 thiếu contact). Trong AWS (cập nhật 2026), semi-structured data được định nghĩa như vậy trong các dịch vụ như Amazon S3 với Athena (query JSON trực tiếp), AWS Glue (schema discovery), và DynamoDB (document model). Điều này khác với structured (bảng cố định) và unstructured (không schema).

🛠️ Giải thích tất cả các phương án (giữ nguyên văn bản gốc):

• unstructured ❌ Sai vì: Loại dữ liệu unstructured là dữ liệu không có cấu trúc hoặc schema cố định, như văn bản tự do (text logs), hình ảnh, video, hoặc email thô. Dữ liệu JSON ở đây có cấu trúc rõ ràng với key-value và phân cấp, không phải "không cấu trúc" – AWS phân loại unstructured cho các file như PDF, MP4 trên S3 mà không dùng schema inference.
• semi-structured ✅ Đúng vì: Như đã giải thích ở trên, JSON là điển hình của semi-structured data trong AWS. Nó có tags/schema nhẹ (keys) nhưng linh hoạt về số lượng trường, phù hợp query bằng SQL-like (Athena) hoặc NoSQL (DynamoDB). AWS Glue Catalog (2026) tự động crawl và infer schema từ JSON/XML/CSV.
• structured ❌ Sai vì: Structured data phải có schema cố định, tabular như bảng relational (cột cố định, hàng đồng nhất) trong RDS, Redshift hoặc Snowflake on AWS. JSON ở đây không tabular, có nested và optional fields, nên không phải structured – AWS yêu cầu transform semi-structured sang Parquet/Avro để thành fully structured trước khi load vào data warehouse.

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

• AWS Glossary: What is Semi-Structured Data? – Xác nhận JSON/XML là semi-structured.
• AWS Documentation: Athena Querying Semi-Structured Data – Hỗ trợ JSON trực tiếp.
• AWS Glue: Schema Discovery for JSON – Crawler infer schema linh hoạt.

Hy vọng phân tích này giúp bạn nắm vững khái niệm data types trong AWS! 🚀

🧠 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 một cách chi tiết:
🧩 Câu hỏi: "Which service can be used to build extract, transform, and load (ETL) pipelines?"
Câu hỏi này tập trung vào việc xác định dịch vụ đám mây Microsoft Azure phù hợp nhất để xây dựng các pipeline ETL (Extract - Trích xuất dữ liệu từ nguồn gốc; Transform - Chuyển đổi dữ liệu theo yêu cầu; Load - Tải dữ liệu vào đích đến). ETL là quy trình cốt lõi trong xử lý dữ liệu lớn (big data), tích hợp dữ liệu từ nhiều nguồn đa dạng (như cơ sở dữ liệu, file, API) và chuẩn bị cho phân tích. Trong Azure, dịch vụ này cần hỗ trợ thiết kế pipeline trực quan, tích hợp hybrid (on-premises và cloud), và tự động hóa quy trình ETL mà không cần code phức tạp. (Lưu ý: Mặc dù chủ đề đề cập AWS, nhưng các lựa chọn toàn bộ là dịch vụ Azure, nên phân tích dựa trên Azure theo phiên bản mới nhất 2026 với hỗ trợ AI mapping data flows và integration runtime nâng cao).

✅ Đáp án đúng: Azure Data Factory
Lý do lựa chọn: Azure Data Factory là dịch vụ chuyên biệt cho ETL/ELT pipelines trong Azure, cho phép xây dựng, lên lịch và quản lý quy trình di chuyển dữ liệu quy mô lớn. Nó hỗ trợ hơn 90+ connectors (kết nối nguồn dữ liệu), data flows với chế độ tự code-free sử dụng Spark engine, và tích hợp Synapse Analytics cho real-time processing. Theo cập nhật 2026, nó có thêm tính năng AI-driven data transformation và zero-ETL với Fabric. Đây là lựa chọn tối ưu cho ETL theo best practices của Microsoft.

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

• ✅ Azure Data Factory: Đúng! Đây là dịch vụ cốt lõi để xây dựng ETL pipelines với giao diện kéo-thả, hỗ trợ mapping data flows, copy activity, và orchestration. Phù hợp cho hybrid/multi-cloud ETL, xử lý petabyte-scale dữ liệu mà không cần quản lý infrastructure.

• ❌ Azure Pipelines: Sai! Azure Pipelines thuộc Azure DevOps, chuyên dùng cho CI/CD pipelines (Continuous Integration/Continuous Deployment) trong phát triển phần mềm, như build, test và deploy code. Không hỗ trợ ETL dữ liệu lớn mà tập trung vào automation code release.

• ❌ Azure SQL Database: Sai! Đây là dịch vụ cơ sở dữ liệu quan hệ PaaS (PaaSQL), dùng để lưu trữ và query dữ liệu SQL với hyperscale. Không phải công cụ xây dựng pipeline ETL, chỉ là đích đến (sink) hoặc nguồn (source) trong Data Factory.

• ❌ Azure Cosmos DB: Sai! Đây là cơ sở dữ liệu NoSQL multi-model toàn cầu, tối ưu cho high-throughput, low-latency apps. Có thể dùng làm nguồn/đích dữ liệu nhưng không hỗ trợ xây dựng ETL pipelines; thay vào đó, dùng change feeds cho streaming.

• ❌ Azure Databricks: Sai! Azure Databricks là nền tảng analytics dựa trên Apache Spark cho big data processing, ML và ETL notebooks. Có thể code ETL bằng Spark jobs nhưng không phải dịch vụ chuyên pipeline orchestration như Data Factory (thiếu visual designer, scheduling native).

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

• Azure Data Factory Documentation – Hướng dẫn ETL pipelines và data flows.
• Microsoft Azure Fundamentals: Data Services – Ôn tập DP-900.
• AWS tương đương: AWS Glue (nhưng không áp dụng ở đây vì lựa chọn Azure).

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