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

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

Câu hỏi yêu cầu chọn dịch vụ Azure phù hợp để lưu trữ dữ liệu nhật ký sự kiện (event log data) có cấu trúc bán cấu trúc (semi-structured) và được nhận theo thời gian thực khi sự kiện xảy ra (as the logs occur).
📌 Yêu cầu chính: Dữ liệu cần được lưu trữ nhanh chóng, hỗ trợ khối lượng lớn, không cần schema cố định (phù hợp semi-structured như JSON, logs), và xử lý luồng dữ liệu liên tục (real-time ingestion). Đây là tình huống điển hình trong xử lý logs, telemetry hoặc IoT data trong Azure.

✅ Đáp án đúng: Azure Table storage

Lý do chọn:
Azure Table storage là dịch vụ NoSQL key-value store lý tưởng cho dữ liệu semi-structured như event logs. Nó hỗ trợ:

• Lưu trữ linh hoạt mà không cần schema cố định (partition key + row key).
• Xử lý high-throughput real-time ingestion (hàng triệu records/giây).
• Chi phí thấp, scale tự động, phù hợp logs theo thời gian thực.
  🛠️ Ví dụ sử dụng: Lưu timestamp làm PartitionKey, event ID làm RowKey, properties semi-structured trong JSON.
  📘 Tài liệu tham khảo: Azure Table Storage documentation (Microsoft Learn, cập nhật 2024) – Vẫn là lựa chọn hàng đầu đến 2026 cho semi-structured logs.

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

• Azure Table storage ✅ ĐÚNG
  Lý tưởng cho semi-structured data như event logs nhờ mô hình NoSQL đơn giản, hỗ trợ real-time writes với throughput cao (lên đến 20.000 operations/giây/table). Không yêu cầu schema, dễ query theo key, và tích hợp tốt với Azure Stream Analytics hoặc Functions cho ingestion liên tục. Phù hợp hoàn hảo với yêu cầu "store as logs occur".

• Azure Queue storage ❌ SAI
  Đây là dịch vụ messaging queue dùng để lưu trữ tạm thời messages cho decoupling applications (FIFO queue). Không thiết kế để lưu trữ lâu dài semi-structured logs; chỉ giữ messages tối đa 7 ngày, và không hỗ trợ query phức tạp hay semi-structured properties hiệu quả. Nếu dùng cho logs, sẽ mất dữ liệu sau thời hạn.

• Azure Files ❌ SAI
  Đây là dịch vụ file share SMB/NFS cho dữ liệu cấu trúc đầy đủ (structured files) như documents, images. Không phù hợp semi-structured logs vì yêu cầu mount như file system, overhead cao cho real-time ingestion, và không tối ưu cho query key-value hoặc khối lượng lớn records nhỏ. Dùng cho shared storage giữa VMs chứ không phải logs.

🧠 Kết luận: Azure Table storage là lựa chọn tối ưu nhất theo best practices Azure Data Fundamentals (DP-900). Nếu cần analytics nâng cao, có thể kết hợp với Azure Cosmos DB for Table API (phiên bản premium).
📚 Nguồn bổ sung: Azure Storage comparison (Microsoft Docs, 2024).

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

Câu hỏi tập trung vào Azure Cosmos DB – một dịch vụ cơ sở dữ liệu NoSQL đa mô hình, phân tán toàn cầu của Microsoft Azure. Cụ thể, nó hỏi: "Which Azure Cosmos DB API should you use for a graph database?" (API nào của Azure Cosmos DB nên sử dụng cho cơ sở dữ liệu đồ thị?).
📘 Graph database là loại cơ sở dữ liệu chuyên lưu trữ dữ liệu dưới dạng đồ thị (nodes - đỉnh, edges - cạnh, properties - thuộc tính), phù hợp cho các ứng dụng như mạng xã hội, khuyến nghị, phân tích gian lận, nơi cần truy vấn mối quan hệ phức tạp. Azure Cosmos DB hỗ trợ nhiều API tương thích (multi-model), cho phép chọn API phù hợp với mô hình dữ liệu. Kiến thức cập nhật đến năm 2026: Không có thay đổi lớn về các API cốt lõi này (theo tài liệu Azure Cosmos DB v2.x+).

✅ Đáp án đúng: Gremlin

Lý do lựa chọn: Gremlin là API dành riêng cho graph database trong Azure Cosmos DB, dựa trên tiêu chuẩn Apache TinkerPop Gremlin. Nó hỗ trợ đầy đủ các hoạt động đồ thị như tạo nodes/edges, truy vấn traversal (duyệt đồ thị), và tích hợp với các công cụ như Azure Synapse, Power BI. Sử dụng Gremlin giúp tận dụng engine đồ thị tối ưu của Cosmos DB, đảm bảo hiệu suất cao với quy mô lớn và SLA 99.999% uptime.
🛠️ Ví dụ sử dụng: g.addV('person').property('name', 'Alice').addV('person').property('name', 'Bob').addE('knows')...

📋 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 nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai), kèm lý do bằng tiếng Việt dựa trên tài liệu chính thức.

• Table ❌
  Sai vì: Table API tương thích với Azure Table Storage (key-value store), dùng cho dữ liệu NoSQL đơn giản như lưu trữ log, telemetry với mô hình Entity-Property. Không hỗ trợ cấu trúc đồ thị (nodes/edges), nên không phù hợp cho graph database – chỉ dùng cho truy vấn đơn giản theo PartitionKey/RowKey.

• Cassandra ❌
  Sai vì: Cassandra API tương thích với Apache Cassandra (wide-column store), lý tưởng cho dữ liệu lớn theo cột như time-series, IoT. Nó sử dụng ngôn ngữ CQL (Cassandra Query Language), không hỗ trợ traversal đồ thị, nên không dùng cho graph database.

• Core (SQL) ❌
  Sai vì: Core (SQL) API là API mặc định của Cosmos DB, dùng cho tài liệu JSON (document database) với truy vấn SQL-like. Tuy hỗ trợ một số truy vấn phức tạp, nhưng không được tối ưu hóa cho đồ thị – thiếu các tính năng traversal chuyên sâu như Gremlin.

• Gremlin ✅
  Đúng vì: Như đã giải thích ở trên, đây là API chuẩn cho graph workloads, hỗ trợ đầy đủ TinkerPop Gremlin, indexing tự động trên edges, và tích hợp vector search (từ 2023+). Hoàn hảo cho các ứng dụng đồ thị thực tế.

📚 Tài liệu tham khảo

• Microsoft Docs: Azure Cosmos DB APIs Overview (cập nhật 2026).
• Gremlin API Specifics.
• Graph Capabilities in Cosmos DB.
  (Lưu ý: Chủ đề chính là Azure, dù đề cập AWS – kiến thức AWS như Neptune Graph không áp dụng ở đây).

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

Câu hỏi này xoay quanh khái niệm ACID (Atomicity, Consistency, Isolation, Durability) trong cơ sở dữ liệu, một tiêu chuẩn cốt lõi để đảm bảo tính toàn vẹn dữ liệu trong các giao dịch (transactions). 📘

Tình huống cụ thể: Một ngân hàng có hệ thống quản lý giao dịch tài chính. Khi chuyển tiền giữa các tài khoản (ví dụ: từ tài khoản nguồn A sang tài khoản đích B), hệ thống KHÔNG ĐƯỢC phép đọc (retrieve) giá trị số dư của tài khoản nguồn trước khi chuyển (balance cũ) và số dư của tài khoản đích sau khi chuyển (balance mới). Điều này có nghĩa là:

• Nếu giao dịch chuyển tiền đang diễn ra (chưa hoàn tất hoặc đang ở trạng thái trung gian), một giao dịch đọc khác không được phép thấy dữ liệu "nửa vời" – ví dụ: A giảm nhưng B chưa tăng, dẫn đến tổng số dư toàn hệ thống bị lệch lạc.
• Đây là vấn đề tính cô lập (isolation) giữa các giao dịch đồng thời, tránh hiện tượng non-repeatable read hoặc dirty read nơi một giao dịch thấy dữ liệu chưa commit của giao dịch khác. 🛠️ Liên quan đến AWS: Trong AWS (cập nhật đến 2026), các dịch vụ như Amazon RDS (hỗ trợ ACID đầy đủ qua các engine như PostgreSQL, MySQL), Amazon DynamoDB Transactions (ra mắt 2018, cập nhật mạnh mẽ với strongly consistent reads từ 2023-2026), và Amazon Aurora đều đảm bảo isolation levels (Read Committed, Repeatable Read, Serializable) để xử lý tình huống này. Ví dụ, DynamoDB Transactions sử dụng optimistic locking để tránh race conditions trong chuyển tiền ngân hàng.

Nguồn tham khảo:

• AWS Documentation: DynamoDB Transactions - ACID compliance (cập nhật 2025).
• RDS ACID Transactions.
• AWS Well-Architected Framework - Reliability Pillar (2024 edition).

✅ Đáp án đúng: isolation

Lý do chọn:

• Isolation đảm bảo các giao dịch chạy độc lập và cô lập lẫn nhau, như thể chúng chạy tuần tự. Trong ví dụ chuyển tiền, isolation ngăn giao dịch đọc thứ hai thấy trạng thái trung gian (nguồn cũ + đích mới) của giao dịch đầu tiên, tránh inconsistent views.
• Nếu không có isolation, hệ thống có thể báo cáo sai tổng số dư, dẫn đến lỗi tài chính nghiêm trọng. AWS hỗ trợ isolation levels cao (Serializable) trong RDS/Aurora để tuân thủ quy định ngân hàng như PCI-DSS. 🏦

📋 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 một cách chi tiết, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm lý do bằng tiếng Việt rõ ràng:

• atomicity ❌
  Sai vì: Atomicity chỉ đảm bảo giao dịch là "tất cả hoặc không gì cả" (all-or-nothing), nghĩa là nếu chuyển tiền thất bại, cả hai tài khoản đều không thay đổi. Nhưng câu hỏi không nói về việc rollback toàn bộ, mà tập trung vào việc đọc dữ liệu giữa các giao dịch đồng thời – atomicity không xử lý isolation giữa tx khác nhau.

• durability ❌
  Sai vì: Durability đảm bảo dữ liệu đã commit thì bền vững ngay cả khi hệ thống crash (ghi vào non-volatile storage). Câu hỏi không liên quan đến việc lưu trữ lâu dài sau commit, mà là tránh đọc inconsistent data trong lúc tx đang chạy – durability chỉ áp dụng sau khi tx hoàn tất.

• consistency ❌
  Sai vì: Consistency yêu cầu dữ liệu luôn ở trạng thái hợp lệ theo rules kinh doanh (ví dụ: tổng số dư không âm). Mặc dù chuyển tiền cần consistency, nhưng câu hỏi nhấn mạnh vấn đề đọc cross-tx inconsistent views (nguồn cũ + đích mới), không phải vi phạm rules nội tại của một tx – đây thuộc isolation, consistency chỉ kiểm tra sau tx.

• isolation ✅
  Đúng vì: Như giải thích trên, isolation ngăn các giao dịch can thiệp lẫn nhau, đảm bảo mỗi tx thấy snapshot nhất quán (không lẫn lộn dữ liệu trung gian). Trong AWS, isolation levels như Serializable trong RDS/DynamoDB trực tiếp giải quyết kịch bản ngân hàng này. 🎯

🧩 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: "A data engineer is responsible for which task?" (Một kỹ sư dữ liệu chịu trách nhiệm nhiệm vụ nào?)
🛠️ Câu hỏi này tập trung vào vai trò chính của Data Engineer (Kỹ sư dữ liệu) trong môi trường AWS, đặc biệt liên quan đến các workload phân tích dữ liệu (analytical workloads). Data Engineer là người xây dựng hạ tầng dữ liệu vững chắc, bao gồm thiết kế và triển khai các kho dữ liệu (data stores) để hỗ trợ phân tích lớn, như data lakes, data warehouses hoặc pipelines dữ liệu thời gian thực. Điều này phù hợp với các dịch vụ AWS mới nhất như Amazon S3 cho data lakes, Amazon Redshift cho data warehousing, AWS Glue cho ETL, và Amazon EMR cho xử lý dữ liệu lớn (cập nhật đến 2026 với các tính năng như Redshift serverless và Glue 4.0 hỗ trợ ML inference). Câu hỏi kiểm tra sự phân biệt rõ ràng giữa Data Engineer với các vai trò khác như Data Analyst, Data Scientist hay DBA.

✅ Đáp án đúng:
Design and implement data stores for analytical workloads.
Lý do chọn đáp án này:
🟢 Đây là trách nhiệm cốt lõi của Data Engineer theo khung AWS Certified Data Engineer - Associate (DP-203 tương đương, nhưng AWS-specific). Họ thiết kế và triển khai các data stores như data lakes (S3 + Lake Formation), data warehouses (Redshift), hoặc streaming stores (Kinesis Data Streams), đảm bảo scalability, security và performance cho analytical workloads. Điều này khớp với AWS Well-Architected Framework for Analytics (2024-2026 updates), nhấn mạnh Data Engineer build infrastructure để hỗ trợ BI và ML.

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

• ❌ Phương án SAI: Explore data to identify trends.
  Phương án này mô tả công việc của Data Analyst hoặc Data Scientist, không phải Data Engineer. Họ sử dụng công cụ như Amazon QuickSight hoặc Athena để khám phá dữ liệu (data exploration) và tìm xu hướng (trends), trong khi Data Engineer chỉ tập trung vào xây dựng hạ tầng dữ liệu, không phải phân tích nội dung.

• ❌ Phương án SAI: Implement policies, tools, and processes for backup and recovery plans.
  Đây là trách nhiệm của Database Administrator (DBA) hoặc SysOps Engineer, sử dụng AWS Backup, RDS snapshots, hoặc S3 versioning. Data Engineer không quản lý backup/recovery mà chỉ thiết kế data stores; việc này thuộc operational tasks theo AWS Shared Responsibility Model.

• ❌ Phương án SAI: Design and build analytical models.
  Công việc này thuộc Data Scientist hoặc ML Engineer, sử dụng SageMaker hoặc Glue ML để xây dựng mô hình phân tích (analytical models) như regression hoặc clustering. Data Engineer chỉ cung cấp dữ liệu sạch cho họ, không thiết kế models (theo AWS ML Competency Framework 2025).

• ✅ Phương án ĐÚNG: Design and implement data stores for analytical workloads.
  Như đã giải thích ở trên, đây là nhiệm vụ chính của Data Engineer: Xây dựng data stores (e.g., Redshift Spectrum cho petabyte-scale analytics, cập nhật 2026 với zero-ETL integrations). Hoàn hảo khớp vai trò!

📘 Tài liệu tham khảo

• AWS Certified Data Engineer - Associate Exam Guide (2024): aws.amazon.com/certification/certified-data-engineer-associate
• AWS Well-Architected Framework: Analytics Lens (2025 update): docs.aws.amazon.com/wellarchitected/latest/analytics-lens
• AWS Big Data Blog: Data Engineer roles (2026 posts về Lake Formation Gen2).
  (Kiến thức dựa trên tài liệu chính thức AWS đến Q1/2026)

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

Câu hỏi yêu cầu xác định định dạng file nào có các đặc điểm sau:

• Định nghĩa rõ ràng tên (names) và kiểu dữ liệu (data types) cho từng cột (tức là có schema cố định, không phải dữ liệu không cấu trúc).
• Sử dụng lưu trữ dạng cột (columnar storage) được nén (compressed), giúp tối ưu hóa cho việc truy vấn dữ liệu lớn, phân tích dữ liệu (analytics) và tiết kiệm không gian lưu trữ.

Đây là chủ đề liên quan đến AWS (Amazon Web Services), đặc biệt trong các dịch vụ như Amazon S3, Amazon Athena, AWS Glue hoặc Amazon EMR, nơi các định dạng file columnar như Parquet được ưu tiên để xử lý dữ liệu lớn hiệu quả. Kiến thức dựa trên phiên bản AWS mới nhất đến năm 2026, với Parquet vẫn là định dạng chuẩn cho columnar storage trong hệ sinh thái AWS (không có thay đổi lớn từ các bản cập nhật 2024-2026).

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

• AWS Documentation - Parquet
• Apache Parquet Official (tích hợp sâu trong AWS Glue và Athena).

✅ Đáp án đúng: Apache Parquet

Lý do lựa chọn:
Apache Parquet là định dạng file columnar (lưu trữ theo cột thay vì theo hàng), hỗ trợ schema đầy đủ với tên cột và kiểu dữ liệu được định nghĩa rõ ràng (self-describing). Nó sử dụng nén columnar hiệu quả (như Snappy, GZIP) giúp giảm kích thước file lên đến 75-80% so với các định dạng row-based, tối ưu cho truy vấn SQL trên dữ liệu lớn trong AWS (ví dụ: Athena query Parquet nhanh gấp 10x so với CSV). Đây là lựa chọn chuẩn cho data lake trên S3.

🛠️ Ưu điểm nổi bật trong AWS (cập nhật 2026): Hỗ trợ partitioning, predicate pushdown, và tích hợp với AWS Lake Formation cho governance dữ liệu.

📋 Phân tích tất cả các phương án

Dưới đây là giải thích chi tiết từng lựa chọn, đánh dấu ✅ đúng hoặc ❌ sai:

• HTML ❌
  Sai vì: HTML là ngôn ngữ đánh dấu hypertext dùng để hiển thị web, không phải định dạng dữ liệu tabular. Nó không có schema cố định cho cột/kiểu dữ liệu, không hỗ trợ columnar storage hay nén dữ liệu. Chỉ dùng cho nội dung web, không phù hợp lưu trữ dữ liệu lớn trên S3.

• CSV ❌
  Sai vì: CSV (Comma-Separated Values) là định dạng row-based (lưu trữ theo hàng), không định nghĩa schema (tên cột và kiểu dữ liệu phải infer thủ công). Không có nén columnar tích hợp, dẫn đến file lớn và query chậm trên Athena/Glue (AWS khuyến nghị chuyển sang Parquet để tối ưu).

• Apache Parquet ✅
  Đúng vì: Như đã giải thích ở trên, đây là định dạng columnar storage chuẩn với schema (tên và data types rõ ràng), nén hiệu quả, và được AWS ưu tiên cho analytics workloads (hỗ trợ đầy đủ trong S3 Select, EMR, Redshift Spectrum đến 2026).

• JSON ❌
  Sai vì: JSON là định dạng hierarchical/noSQL (dữ liệu dạng object/nested), không có schema columnar cố định (phải dùng JSON Schema riêng). Lưu trữ row-based hoặc semi-structured, không nén columnar, dẫn đến hiệu suất kém khi query lớn trên AWS Athena (chậm hơn Parquet 5-10x).

🧩 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 việc phân loại một hệ thống điểm bán hàng (Point of Sale - POS) trong lĩnh vực bán lẻ thuộc loại giải pháp dữ liệu nào. Hệ thống POS là một ứng dụng xử lý giao dịch thời gian thực, chẳng hạn như quét mã vạch sản phẩm, tính tiền, cập nhật kho hàng ngay lập tức và ghi nhận thanh toán từ khách hàng. Nó yêu cầu tốc độ cao, độ tin cậy tuyệt đối (ACID properties), khả năng xử lý hàng nghìn giao dịch đồng thời mà không bị lỗi, thường liên quan đến cơ sở dữ liệu quan hệ với các hoạt động đọc/ghi nhanh chóng. Trong bối cảnh AWS (theo kiến thức cập nhật đến năm 2026), đây là đặc trưng của các workload giao dịch trực tuyến, khác biệt với các hệ thống phân tích dữ liệu lớn hoặc xử lý dữ liệu hàng loạt.

✅ Đáp án đúng: online transaction processing (OLTP)
Lý do lựa chọn: Hệ thống POS là ví dụ điển hình của OLTP vì nó được thiết kế để xử lý các giao dịch nhỏ, nhanh chóng và liên tục (như insert, update, delete dữ liệu thời gian thực) với số lượng lớn người dùng đồng thời. Trong AWS, OLTP thường được triển khai trên các dịch vụ như Amazon RDS, Aurora hoặc DynamoDB để đảm bảo hiệu suất cao, độ trễ thấp và tính nhất quán dữ liệu. Điều này phù hợp với phiên bản AWS mới nhất (2026), nơi OLTP nhấn mạnh vào micro-transactions và real-time processing trong môi trường bán lẻ.

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

• a data warehouse ❌
  Phương án này sai vì data warehouse (kho dữ liệu) dùng để lưu trữ và phân tích dữ liệu lịch sử lớn ở cấp độ tổng hợp (như báo cáo doanh số hàng tháng), không phải xử lý giao dịch thời gian thực. Trong AWS, data warehouse như Amazon Redshift tập trung vào OLAP và query phức tạp trên terabytes dữ liệu, không phù hợp với POS cần tốc độ cao cho từng giao dịch cá nhân.

• online analytical processing (OLAP) ❌
  Phương án này sai vì OLAP dành cho phân tích đa chiều, query phức tạp trên dữ liệu lớn (ví dụ: phân tích xu hướng bán hàng theo khu vực), không xử lý giao dịch nhanh. AWS hỗ trợ OLAP qua Redshift hoặc Athena, nhưng POS không cần tính năng này mà ưu tiên transaction throughput cao, khác biệt hoàn toàn với OLAP theo tài liệu AWS Well-Architected Framework (2026).

• extract, transform, and load (ETL) ❌
  Phương án này sai vì ETL là quy trình xử lý dữ liệu hàng loạt (trích xuất từ nguồn, biến đổi và tải vào kho dữ liệu), không phải hệ thống xử lý giao dịch trực tiếp. Trong AWS Glue hoặc EMR (cập nhật 2026), ETL dùng cho data pipeline lớn, chậm hơn và không real-time như POS yêu cầu.

• online transaction processing (OLTP) ✅
  Phương án này đúng vì OLTP chính là hệ thống xử lý giao dịch trực tuyến với đặc tính tốc độ cao, concurrency lớn và tính toàn vẹn dữ liệu, hoàn hảo cho POS. AWS khuyến nghị OLTP cho các ứng dụng như bán lẻ qua RDS/Aurora với hỗ trợ serverless scaling mới nhất (2026).

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

• AWS Documentation: Database - OLTP vs OLAP (cập nhật 2026).
• AWS Well-Architected Framework: Reliability Pillar cho OLTP workloads (Reliability Whitepaper, version 2026).
• Amazon RDS/Aurora User Guide: OLTP use cases như POS systems.

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

Câu hỏi tập trung vào dữ liệu có cấu trúc ở định dạng bảng (structured data in tabular format), một khái niệm cơ bản trong cơ sở dữ liệu quan hệ (relational databases). Đây là dữ liệu được tổ chức theo hàng và cột, giống như một bảng Excel hoặc các dịch vụ như Amazon RDS, Amazon Redshift trên AWS.

Cụ thể, câu hỏi hỏi: "What represents an individual instance of a data entity?" – Nghĩa là cái gì đại diện cho một cá thể riêng lẻ (individual instance) của một thực thể dữ liệu (data entity)?

• Data entity: Là một đối tượng logic, ví dụ "Khách hàng" hoặc "Đơn hàng".
• Individual instance: Là một ví dụ cụ thể của entity đó, như "Khách hàng tên Nguyễn Văn A với ID 123". 🛠️ Trong mô hình dữ liệu quan hệ (dùng ER model), một instance là một bản ghi hoàn chỉnh đại diện cho một thực thể duy nhất.

✅ Đáp án đúng: a row

Lý do chọn đáp án này: Trong dữ liệu bảng, a row (hàng) chính là một instance riêng lẻ của data entity. Mỗi hàng chứa đầy đủ thông tin về một thực thể cụ thể (ví dụ: một khách hàng với tất cả thuộc tính như tên, tuổi, địa chỉ). Điều này phù hợp với các dịch vụ AWS như Amazon DynamoDB (dù NoSQL nhưng có khái niệm item tương đương row) hoặc RDS (SQL tables). Kiến thức cập nhật đến 2026 vẫn giữ nguyên nguyên tắc này theo AWS Well-Architected Framework cho Data Analytics.

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

• a column ❌
  Sai vì: Một cột (column) đại diện cho thuộc tính (attribute) của entity, không phải instance riêng lẻ. Ví dụ: cột "Tên" mô tả thuộc tính chung cho tất cả khách hàng, chứ không phải một khách hàng cụ thể.

• a table ❌
  Sai vì: Một bảng (table) là tập hợp (collection) của nhiều instance của cùng một entity. Nó chứa hàng trăm hoặc hàng triệu rows, không đại diện cho chỉ một cá thể riêng lẻ.

• a cell ❌
  Sai vì: Một ô (cell) chỉ là giá trị đơn lẻ tại giao điểm của row và column, ví dụ giá trị "Nguyễn Văn A" ở cột Tên. Nó không đại diện đầy đủ cho toàn bộ instance của entity.

• a row ✅
  Đúng vì: Như đã giải thích ở trên, row là instance hoàn chỉnh của data entity, chứa tất cả thuộc tính cần thiết cho một thực thể cụ thể. Đây là chuẩn mực trong SQL và các công cụ AWS như Athena, Glue Data Catalog.

📘 Tài liệu tham khảo

• AWS Official Docs: Relational Database Concepts và AWS Certified Data Engineer - Associate Exam Guide (cập nhật 2025-2026, nhấn mạnh tabular data modeling).
• AWS Training: Digital Training "DP-203: Data Fundamentals" tương đương, module về Structured Data (dù Azure nhưng khái niệm chung với AWS).
• Khái niệm chuẩn: Codd's Relational Model (1970, vẫn áp dụng đến 2026).

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é!

🧩 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 đang hỏi về dịch vụ Azure SQL nào cung cấp tương thích gần 100% với các instance Microsoft SQL Server on-premises (tức là SQL Server chạy trên máy chủ tại chỗ của doanh nghiệp), đồng thời hỗ trợ tự động hóa các tác vụ cập nhật (updates), sao lưu (backups) và bảo trì (maintenance tasks). Đây là một câu hỏi tập trung vào các dịch vụ Azure SQL, nhấn mạnh vào tính tương thích cao với SQL Server truyền thống và mô hình PaaS (Platform as a Service) để giảm gánh nặng quản trị.
✅ Mục tiêu chính: Tìm dịch vụ cân bằng giữa tính tương thích đầy đủ và tự động hóa quản lý, phù hợp cho việc di chuyển (migration) từ on-premises sang cloud mà không cần thay đổi lớn mã nguồn ứng dụng.

✅ Đáp án đúng: Azure SQL Managed Instance

Lý do lựa chọn:
Azure SQL Managed Instance là dịch vụ PaaS được thiết kế đặc biệt để mang lại tương thích gần 100% (hơn 99% tính năng SQL Server on-premises), hỗ trợ hầu hết các công cụ, tính năng và hành vi giống hệt SQL Server (bao gồm SQL Agent, cross-database queries, v.v.). Đồng thời, nó tự động xử lý updates, backups và maintenance mà không yêu cầu quản trị thủ công, giúp tiết kiệm chi phí và thời gian. Đây là lựa chọn lý tưởng cho các workload enterprise cần lift-and-shift migration.
(Kiến thức cập nhật đến 2026: Vẫn giữ nguyên tính tương thích cao theo tài liệu Microsoft Azure mới nhất, với hỗ trợ SQL Server 2022 và các cải tiến bảo mật như Ledger.)

🛠️ 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 với đánh giá đúng/sai:

• Azure SQL Managed Instance
  ✅ Đúng. Như đã giải thích ở trên, đây là dịch vụ duy nhất đáp ứng đầy đủ cả hai yêu cầu: tương thích gần 100% với SQL Server on-premises và tự động hóa hoàn toàn updates, backups, maintenance. Nó hỗ trợ hầu hết T-SQL features và system views giống on-premises.

• SQL Server on Azure Virtual Machines
  ❌ Sai. Đây là dịch vụ IaaS (Infrastructure as a Service), cho phép chạy SQL Server đầy đủ trên VM Azure, đạt tương thích 100% với on-premises. Tuy nhiên, không tự động hóa updates, backups hay maintenance – người dùng phải tự quản lý thủ công như on-premises, dẫn đến gánh nặng vận hành cao hơn.

• Azure SQL Database
  ❌ Sai. Đây là dịch vụ PaaS serverless/hyperscale với tự động hóa đầy đủ updates, backups và maintenance. Nhưng tương thích chỉ khoảng 80-90% với SQL Server on-premises, thiếu một số tính năng như SQL Agent, cross-database queries, hoặc certain collations, không phù hợp cho migration phức tạp.

• Azure SQL Edge
  ❌ Sai. Đây là phiên bản lightweight dành cho IoT/Edge computing (chạy trên thiết bị biên), có tương thích cơ bản với SQL Server nhưng không đạt gần 100% và không tập trung vào tự động hóa enterprise-level. Nó ưu tiên kích thước nhỏ, không phù hợp cho workload on-premises lớn.

📚 Tài liệu tham khảo

• Microsoft Docs: Azure SQL Managed Instance overview (cập nhật 2024-2026).
• So sánh dịch vụ: Azure SQL options comparison.
• Migration guide: Lift-and-shift to Managed Instance.

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

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

Câu hỏi: "Which type of Azure resource supports the serverless configuration of an Azure SQL database?"
📘 Giải thích rõ ràng: Câu hỏi đang hỏi về loại tài nguyên Azure nào hỗ trợ cấu hình serverless (không cần quản lý máy chủ) cho cơ sở dữ liệu Azure SQL.

• Serverless trong Azure SQL Database là một mô hình tính toán tự động scale (mở rộng/mở rộng theo nhu cầu), tạm dừng khi không sử dụng để tiết kiệm chi phí, chỉ áp dụng cho một số loại tài nguyên cụ thể.
• Đây là tính năng của Azure SQL Database (PaaS), giúp người dùng không cần lo lắng về hạ tầng máy chủ. Kiến thức dựa trên phiên bản mới nhất của Azure đến năm 2026 (Azure SQL Database vCore model, General Purpose tier hỗ trợ serverless từ 2021 và vẫn duy trì).
  🛠️ Mục tiêu: Xác định tài nguyên chính xác hỗ trợ tùy chọn serverless compute tier.

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

Đáp án đúng: a single database in Azure SQL Database
📘 Lý do chi tiết:

• Đây là loại tài nguyên duy nhất trong Azure SQL Database hỗ trợ serverless compute tier (trong General Purpose service tier).
• Serverless cho phép auto-pause (tự động tạm dừng sau 1 giờ không hoạt động), auto-scale CPU từ 0.5-80 vCores, và tính phí theo sử dụng thực tế (storage riêng biệt).
• Không áp dụng cho elastic pool, Managed Instance hay VM.
  🔗 Nguồn tham khảo: Microsoft Docs - Azure SQL Database serverless (cập nhật 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 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 dấu ✅ (đúng) hoặc ❌ (sai), kèm lý do bằng tiếng Việt:

• SQL Server on Azure Virtual Machines ❌
  🛠️ Giải thích sai: Đây là mô hình IaaS (Infrastructure as a Service), người dùng phải tự cài đặt và quản lý SQL Server trên máy ảo Azure VM. Không hỗ trợ serverless vì yêu cầu quản lý thủ công toàn bộ máy chủ, không có auto-scale hay auto-pause tự động như PaaS.

• an Azure SQL Database elastic pool ❌
  🛠️ Giải thích sai: Elastic pool dùng để chia sẻ tài nguyên cho nhiều single databases (vCore hoặc DTU model), nhưng không hỗ trợ serverless tier. Serverless chỉ dành riêng cho single database riêng lẻ, elastic pool tập trung vào chia sẻ tài nguyên cố định chứ không auto-pause.

• a single database in Azure SQL Database ✅
  🛠️ Giải thích đúng: Như đã nêu ở phần đáp án, đây là tài nguyên duy nhất hỗ trợ serverless configuration trong General Purpose tier. Tự động scale, pause/resume, phù hợp workload không liên tục, tiết kiệm chi phí lên đến 100% khi idle.

• Azure SQL Managed Instance ❌
  🛠️ Giải thích sai: Đây là PaaS gần giống on-premises SQL Server (hỗ trợ vCore, premium series), nhưng không có serverless tier. Nó yêu cầu instance luôn chạy, không auto-pause, và tập trung vào compatibility cao hơn là serverless linh hoạt.

🧩 Kết luận: Câu hỏi kiểm tra sự hiểu biết sâu về các deployment options của Azure SQL (Single DB vs. Elastic Pool vs. Managed Instance vs. VM). Serverless là tính năng "hot" từ 2021, vẫn là best practice đến 2026 cho workload biến động! 📘

🧩 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 sự khác biệt chính giữa dữ liệu có cấu trúc (structured data) và dữ liệu bán cấu trúc (semi-structured data).

• Dữ liệu có cấu trúc (structured data): Là dữ liệu được tổ chức theo định dạng cố định, thường lưu trữ trong các cơ sở dữ liệu quan hệ (relational databases) như bảng với các cột và hàng rõ ràng, schema được định nghĩa trước (fixed schema). Ví dụ: Dữ liệu trong Amazon RDS hoặc SQL Server.
• Dữ liệu bán cấu trúc (semi-structured data): Là dữ liệu có cấu trúc linh hoạt, không yêu cầu schema cố định nghiêm ngặt, thường ở định dạng như JSON, XML, CSV không chuẩn, hoặc NoSQL documents. Chúng có thể thay đổi cấu trúc mà không làm hỏng dữ liệu. Ví dụ: Dữ liệu trong Amazon DynamoDB, Amazon S3 với JSON, hoặc AWS Glue Catalog hỗ trợ semi-structured.
  Câu hỏi tập trung vào điểm khác biệt cốt lõi về schema (lược đồ dữ liệu), dựa trên định nghĩa chuẩn của AWS (cập nhật đến 2026, theo AWS Well-Architected Framework và dịch vụ như Athena, Glue hỗ trợ query semi-structured data với schema-on-read).

✅ Đáp án đúng:
Structured data has a fixed schema and semi-structured data has a flexible schema.
Lý do lựa chọn: Đây là sự khác biệt cơ bản nhất theo tài liệu AWS. Structured data yêu cầu schema fixed để đảm bảo tính nhất quán (ví dụ: Amazon RDS với SQL schema predefined), trong khi semi-structured data cho phép schema flexible (schema-on-read), phù hợp với dữ liệu động như logs, IoT data trong AWS IoT Core hoặc S3. Điều này giúp xử lý dữ liệu lớn linh hoạt mà không cần ETL phức tạp (theo AWS Lake Formation 2026 updates).

🛠️ Giải thích chi tiết từng 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), đánh dấu ✅ đúng hoặc ❌ sai, kèm giải thích bằng tiếng Việt:

• Structured data has a fixed schema and semi-structured data has a flexible schema.
  ✅ Đúng. Như đã giải thích ở trên, đây là khác biệt cốt lõi. AWS định nghĩa structured data với fixed schema trong relational DB (RDS, Redshift), còn semi-structured với flexible schema trong NoSQL (DynamoDB) hoặc file-based (S3 JSON). Hỗ trợ query hiệu quả qua Athena với schema inference.

• Only Structured data supports entities.
  ❌ Sai. Cả structured và semi-structured data đều hỗ trợ "entities" (thực thể, như records hoặc objects). Trong AWS, entities tồn tại ở DynamoDB documents (semi-structured) và RDS tables (structured). Khái niệm entities không độc quyền structured data; AWS Entity Resolution service (2025+) xử lý cả hai loại.

• Structured data has a flexible schema and semi-structured data has a fixed schema.
  ❌ Sai. Đây là đảo ngược hoàn toàn định nghĩa chuẩn. Structured data không có flexible schema (sẽ gây lỗi nếu thay đổi), còn semi-structured có flexible schema. AWS khuyến nghị dùng Glue cho semi-structured để tự động detect schema động (theo AWS docs 2026).

• Only Structured data supports attributes.
  ❌ Sai. "Attributes" (thuộc tính) tồn tại ở cả hai loại. Trong structured: columns là attributes fixed; trong semi-structured: fields trong JSON/XML là attributes linh hoạt (ví dụ: DynamoDB attributes). AWS OpenSearch Service (2026) query attributes từ cả structured và semi-structured data.

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

• AWS Documentation: Data types in Amazon S3 Select and Athena (phân biệt structured/semi-structured).
• AWS Glue Developer Guide: Working with semi-structured data.
• AWS Well-Architected Framework - Data Analytics Lens (2026 edition): Nhấn mạnh schema fixed vs flexible.
• Microsoft Azure Data Fundamentals (DP-900) tương đương: Xác nhận khái niệm chung, nhưng AWS-specific ở DynamoDB/S3.

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