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

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

Câu hỏi trắc nghiệm tập trung vào quy trình cơ bản để lưu trữ dữ liệu bằng Azure Table storage – một dịch vụ lưu trữ NoSQL key-value trong Azure Storage, dùng để lưu dữ liệu phi cấu trúc với hiệu suất cao và chi phí thấp. 🛠️

Nội dung câu hỏi: "You need to store data by using Azure Table storage. What should you create first?"
Dịch nghĩa: Bạn cần lưu trữ dữ liệu bằng Azure Table storage. Bạn nên tạo cái gì đầu tiên?
📘 Giải thích rõ ràng: Azure Table storage KHÔNG tồn tại độc lập mà là một phần của Azure Storage Account (tài khoản lưu trữ). Quy trình chuẩn (theo tài liệu Microsoft cập nhật đến năm 2026) là:

1. Tạo Storage Account trước để chứa các dịch vụ lưu trữ như Blob, File, Queue, Table.
2. Sau đó mới tạo Table bên trong Storage Account đó.
   Không thể tạo Table trực tiếp mà không có Storage Account "cha" bao quanh. Điều này đảm bảo quản lý quyền truy cập, sao lưu, và scaling thống nhất. ❌ Bỏ qua bước này sẽ dẫn đến lỗi khi triển khai.

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

Đáp án đúng: a storage account
🧩 Lý do chi tiết: Theo kiến trúc Azure Storage (phiên bản mới nhất 2026, hỗ trợ hierarchical namespace và premium performance), Storage Account là yêu cầu bắt buộc đầu tiên để kích hoạt Azure Table storage. Nó cung cấp endpoint (ví dụ: mystorageaccount.table.core.windows.net), khóa truy cập, và cấu hình bảo mật (như firewall, encryption). Chỉ sau khi có Storage Account, bạn mới có thể tạo Table qua Portal, CLI, hoặc SDK. Không có Storage Account, các dịch vụ con như Table sẽ không khả dụng. ✅ Đây là bước nền tảng, được nhấn mạnh trong quickstart guides của Microsoft.

📋 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 văn bản gốc bằng tiếng Anh, kèm giải thích hoàn toàn bằng tiếng Việt dựa trên kiến thức Azure cập nhật:

• ❌ an Azure Cosmos DB instance
  Phương án này sai vì Azure Cosmos DB là dịch vụ database đa mô hình toàn cầu (multi-model, globally distributed), có API tương thích Table (Table API) nhưng KHÔNG phải Azure Table storage gốc. Table storage thuộc Azure Storage (giá rẻ, regional), còn Cosmos DB yêu cầu tạo account riêng với throughput provisioned. Tạo Cosmos DB không giúp lưu trữ dữ liệu vào Table storage chuẩn. 🛑 Nhầm lẫn phổ biến nhưng hai dịch vụ khác nhau hoàn toàn.

• ✅ a storage account
  Phương án này đúng như đã giải thích ở trên. Đây là bước đầu tiên bắt buộc, hỗ trợ tất cả dịch vụ storage bao gồm Table. Sau khi tạo, bạn dùng lệnh như az storage table create để tiếp tục. 🏆 Hoàn hảo cho kịch bản câu hỏi!

• ❌ a blob container
  Phương án này sai vì Blob container chỉ dùng cho Azure Blob storage (lưu file/object như hình ảnh, video). Nó nằm BÊN TRONG Storage Account nhưng KHÔNG liên quan đến Table storage. Tạo container trước không giúp tạo Table, và Table không lưu dữ liệu dạng blob. 📦 Sai ngữ cảnh hoàn toàn!

• ❌ a table
  Phương án này sai vì bạn KHÔNG THỂ tạo Table trực tiếp mà không có Storage Account bao quanh. Table là entity con (child resource) của Storage Account. Thử tạo qua SDK/Portal sẽ báo lỗi "No storage account found". Thứ tự đúng: Storage Account → Table. 🚫 Đây là bẫy phổ biến cho người mới!

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

• Microsoft Docs chính thức: Quickstart: Azure Table storage using Azure portal – Hướng dẫn rõ bước 1: Tạo Storage Account.
• Azure Storage Overview: Introduction to Azure Storage – Xác nhận Table là service trong Storage Account.
• Azure Updates 2026: Không thay đổi quy trình cốt lõi, chỉ thêm tính năng như customer-managed keys và integration với Microsoft Purview (xem Azure Blog).

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

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

📖 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 khuyến nghị một dịch vụ lưu trữ dữ liệu (data store service) trên Microsoft Azure đáp ứng hai yêu cầu cụ thể:
✑ Native SQL API access: Dịch vụ phải hỗ trợ truy cập API SQL gốc (native), nghĩa là có thể sử dụng ngôn ngữ truy vấn SQL chuẩn mà không cần lớp chuyển đổi, giúp dễ dàng tích hợp với các ứng dụng sử dụng SQL.
✑ Configurable indexes: Dịch vụ phải cho phép tùy chỉnh chỉ mục (indexes) linh hoạt, người dùng có thể cấu hình chính sách lập chỉ mục để tối ưu hóa hiệu suất truy vấn, kiểm soát kích thước dữ liệu và chi phí.

Câu hỏi này thuộc chủ đề lựa chọn dịch vụ dữ liệu phù hợp trong kỳ thi Microsoft Azure Data Fundamentals (DP-900), tập trung vào các dịch vụ NoSQL và đa mô hình dữ liệu trên Azure. Mặc dù người dùng đề cập "liên quan đến AWS", nhưng nội dung câu hỏi hoàn toàn dựa trên hệ sinh thái Azure (không phải AWS). Kiến thức được cập nhật theo tài liệu chính thức Microsoft đến năm 2026, với Azure Cosmos DB vẫn là lựa chọn hàng đầu cho các yêu cầu này (phiên bản mới nhất hỗ trợ SQL API Core và indexing policy nâng cao với hierarchical partitioning).

✅ Đáp án đúng: Azure Cosmos DB
Lý do lựa chọn: Azure Cosmos DB là dịch vụ multi-model database toàn cầu, phân tán, hỗ trợ native SQL API (gọi là Core (SQL) API) cho phép truy vấn dữ liệu JSON bằng cú pháp SQL chuẩn. Đồng thời, nó cung cấp configuring indexes qua Indexing Policy, cho phép tùy chỉnh chỉ mục tự động hoặc thủ công, loại trừ trường dữ liệu cụ thể để tối ưu hóa lưu trữ và hiệu suất. Điều này hoàn hảo đáp ứng cả hai yêu cầu, với SLA 99.999% uptime và multi-region replication.

🛠️ Giải thích chi tiết 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 văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên hai yêu cầu chính:

• Azure Files ❌ (Sai hoàn toàn)
Đây là dịch vụ file sharing dựa trên SMB/NFS, dùng để lưu trữ file hệ thống (như chia sẻ file cho VM hoặc ứng dụng). Nó không hỗ trợ native SQL API (chỉ truy cập qua file protocol) và không có khái niệm configurable indexes vì không phải database. Phù hợp cho backup file hoặc shared storage, không phải data store cho truy vấn SQL.

• Azure Blob storage ❌ (Sai)
Đây là dịch vụ object storage giá rẻ cho dữ liệu không cấu trúc (unstructured data) như hình ảnh, video, logs. Nó không có native SQL API (chỉ hỗ trợ REST API hoặc SDK, không truy vấn SQL trực tiếp) và không hỗ trợ configurable indexes (chỉ metadata cơ bản, không indexing policy). Dùng cho lưu trữ lớn, phân tích dữ liệu với Azure Synapse, nhưng không đáp ứng yêu cầu.

• Azure Table storage ❌ (Sai)
Đây là dịch vụ NoSQL key-value store (phần của Azure Storage) cho dữ liệu semi-structured với partition key và row key. Nó hỗ trợ OData query (gần giống SQL nhưng không phải native SQL API đầy đủ) và indexing cố định dựa trên key (không configurable indexes linh hoạt). Không đáp ứng "native SQL API" chuẩn và thiếu tùy chỉnh chỉ mục chi tiết.

• Azure Cosmos DB ✅ (Đúng)
Như đã giải thích ở trên, đây là lựa chọn lý tưởng với native SQL API (SQL querying trên JSON documents) và configuring indexes qua policy XML/JSON (ví dụ: range, spatial indexes). Hỗ trợ scale-out tự động, multi-API (SQL, MongoDB, Cassandra,...).

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

• Azure Cosmos DB Indexing Policies (Microsoft Docs).
• Choose the right data store - Azure (Guidance cho DP-900).
• DP-900 Exam Study Guide (Microsoft Learn, phiên bản mới nhất).

Hy vọng phân tích này giúp bạn ôn thi hiệu quả! 🚀 Nếu cần thêm câu hỏi, hãy hỏi nhé!

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

Câu hỏi yêu cầu thiết kế một database để minh họa các mối quan hệ giữa mức sử dụng (utilization levels) của các thiết bị mạng cá nhân trong một mạng cục bộ (LAN).
📌 Chi tiết vấn đề:

• Chúng ta cần lưu trữ và biểu diễn mối quan hệ phức tạp giữa các thiết bị (ví dụ: thiết bị A ảnh hưởng đến thiết bị B qua lưu lượng mạng, độ trễ, hoặc tải sử dụng).
• Không chỉ dữ liệu đơn lẻ, mà tập trung vào cấu trúc liên kết (relationships) như đồ thị (nodes là thiết bị, edges là mối quan hệ sử dụng).
• Đây là tình huống điển hình cho mạng lưới dữ liệu (network data), nơi graph database vượt trội trong việc query và visualize relationships.
  🛠️ Ngữ cảnh AWS (cập nhật đến 2026): AWS cung cấp các dịch vụ NoSQL đa dạng như DynamoDB (key-value), DocumentDB (document), Amazon Keyspaces (wide-column), và Amazon Neptune (graph database) – phiên bản mới nhất hỗ trợ RDF/SPARQL và Gremlin, tối ưu cho graph analytics với ML integration (Neptune Analytics).

✅ Đáp án đúng: graph

Lý do chọn:
Graph database lý tưởng cho việc mô hình hóa mối quan hệ động giữa các entities (thiết bị mạng). Mỗi thiết bị là node, mức sử dụng là properties, và tương tác (traffic flow, dependencies) là edges. Điều này cho phép query hiệu quả như "Tìm đường dẫn tải cao nhất từ thiết bị X đến Y" bằng Cypher/Gremlin. Trong AWS, Amazon Neptune (graph store) xử lý hàng tỷ relationships với độ trễ thấp, phù hợp LAN monitoring.
📘 Nguồn: AWS Neptune Documentation (2026) – docs.aws.amazon.com/neptune.

📋 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 đặc tính dữ liệu relationships-heavy của câu hỏi:

• ✅ graph
  Đúng vì: Như đã giải thích, graph chuyên xử lý mối quan hệ phức tạp (nodes-edges-properties), hoàn hảo cho mạng LAN nơi cần traverse relationships nhanh chóng (ví dụ: shortest path giữa thiết bị overload). Neptune hỗ trợ property graph và RDF, scale đến petabyte graphs (cập nhật 2026 với vector search cho ML).

• ❌ key/value
  Sai vì: Key-value (như DynamoDB) chỉ lưu dữ liệu đơn giản theo cặp key-value, không hỗ trợ query relationships phức tạp. Phù hợp cache/simple lookups (e.g., session data), nhưng không minh họa mạng lưới thiết bị – thiếu edges traversal, dẫn đến query kém hiệu quả.

• ❌ document
  Sai vì: Document (như DocumentDB/MongoDB-compatible) lưu JSON/BSON documents với schema linh hoạt, tốt cho hierarchical data (e.g., logs thiết bị). Tuy nhiên, relationships phải embed hoặc reference thủ công, kém hiệu quả cho graph-like queries so với native graph (dễ explode data size trong LAN lớn).

• ❌ columnar
  Sai vì: Columnar (wide-column như Amazon Keyspaces/Cassandra) tối ưu analytics trên columns lớn (e.g., time-series metrics), với rows phân tán. Không thiết kế cho relationships traversal; query graph sẽ chậm và phức tạp, phù hợp hơn OLAP reports chứ không phải network topology visualization.

🧠 Kết luận: Graph là lựa chọn tối ưu cho mối quan hệ mạng động! Nếu triển khai AWS, bắt đầu với Neptune Serverless (2025+).
📘 Tài liệu tham khảo thêm:

• AWS Database Blog: "Choosing the Right Database" (2026) – aws.amazon.com/blogs/database.
• Neptune Best Practices: docs.aws.amazon.com/neptune/latest/userguide/best-practices.html.

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

Câu hỏi mô tả tình huống: Bạn quản lý một ứng dụng lưu trữ dữ liệu trong một thư mục chia sẻ (shared folder) trên máy chủ Windows. Nhiệm vụ là di chuyển thư mục chia sẻ này sang Azure Storage. Câu hỏi yêu cầu xác định loại Azure Storage phù hợp nhất để thay thế thư mục chia sẻ SMB (Server Message Block) truyền thống trên Windows, đảm bảo ứng dụng có thể tiếp tục truy cập qua giao thức chia sẻ file quen thuộc mà không cần thay đổi lớn.

🛠️ Mục tiêu chính: Azure Storage cung cấp nhiều dịch vụ lưu trữ khác nhau (Blob, File, Queue, Table), nhưng chỉ một loại hỗ trợ chia sẻ file SMB giống như thư mục chia sẻ trên Windows server, cho phép mount như một drive mạng (ví dụ: \storageaccount.file.core.windows.net\share).

📘 Dẫn nguồn: Tài liệu chính thức Microsoft Azure Storage (cập nhật đến 2026): Azure Files documentation và Azure Storage services overview.

✅ Đáp án đúng: file

Lý do lựa chọn: Azure Files (hay Azure File Shares) là dịch vụ lưu trữ file được thiết kế đặc biệt để thay thế thư mục chia sẻ SMB trên Windows/Linux. Nó hỗ trợ giao thức SMB 3.0/3.1.1 (và NFS 4.1 từ 2023+), cho phép di chuyển seamless mà ứng dụng không cần code lại. Bạn có thể mount share qua UNC path, hỗ trợ Active Directory integration, và scale lên đến 100 TiB/share (tăng dần theo cập nhật 2025-2026). Đây là lựa chọn tối ưu cho legacy apps dùng shared folders.

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

• queue ❌ Sai: Azure Queue Storage dùng để lưu trữ tin nhắn hàng đợi (messages) cho giao tiếp bất đồng bộ giữa các thành phần ứng dụng (như decoupling microservices). Không hỗ trợ file sharing hay SMB, chỉ phù hợp cho queuing tasks, không thay thế được shared folder chứa dữ liệu file.

• blob ❌ Sai: Azure Blob Storage lưu trữ dữ liệu phi cấu trúc lớn như images, videos, backups qua HTTP/HTTPS (REST API hoặc SDK). Không hỗ trợ SMB sharing trực tiếp (chỉ có static website hoặc premium block blobs), nên không thể mount như thư mục chia sẻ Windows. Phù hợp cho object storage, không phải file shares.

• file ✅ Đúng: Như giải thích ở trên, Azure File Shares hỗ trợ SMB/NFS shares giống hệt shared folder trên Windows, dễ dàng migrate bằng công cụ như Storage Migration Service (SMS). Hỗ trợ đa protocol, ACL, và tích hợp với Azure AD DS/AD (cập nhật 2026 với SMB over QUIC cho hiệu suất cao hơn).

• table ❌ Sai: Azure Table Storage là NoSQL key-value store cho dữ liệu semi-structured (như metadata, logs) với truy vấn nhanh O(1). Không lưu trữ file binary hay hỗ trợ sharing, chỉ dùng cho analytics/scalability dữ liệu lớn kiểu bảng, không thay thế shared folder.

🧠 Lưu ý bổ sung: Trong thực tế migrate (theo best practices Azure 2026), dùng Azure File Sync để đồng bộ dữ liệu từ on-prem sang Azure Files, đảm bảo zero-downtime. Không liên quan AWS vì câu hỏi thuần Azure! 🚀

🧩 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 tập trung vào việc thiết kế cơ sở dữ liệu (database) lưu trữ session data cho một website. Session data bao gồm:

• Notifications (thông báo),
• Personalization attributes (thuộc tính cá nhân hóa, như sở thích người dùng),
• Products added to shopping cart (sản phẩm đã thêm vào giỏ hàng).

Yêu cầu chính là chọn loại data store nào cung cấp latency thấp nhất (lowest latency) khi truy xuất dữ liệu (retrieve the data).
🛠️ Bối cảnh AWS (phiên bản cập nhật 2026): Session data thường có đặc tính tạm thời, đọc/ghi nhanh, truy vấn đơn giản dựa trên key (như session ID), không cần phân tích phức tạp. AWS khuyến nghị sử dụng các dịch vụ NoSQL với độ trễ cực thấp cho workload web real-time như DynamoDB (key-value) hoặc ElastiCache (in-memory key-value), đạt sub-millisecond latency cho point lookups. Các store khác như columnar phù hợp hơn cho analytics lớn.

✅ Đáp án đúng: key/value
Lý do lựa chọn:
Key/value store (như AWS DynamoDB hoặc ElastiCache với Redis/Memcached) được tối ưu hóa cho truy xuất dữ liệu theo key đơn giản, mang lại latency thấp nhất (thường <1ms) nhờ cấu trúc đơn giản, phân vùng tự động và hỗ trợ in-memory caching. Session data chỉ cần lưu giá trị theo session ID làm key, không yêu cầu query phức tạp – phù hợp hoàn hảo với nhu cầu website cao tải. Theo AWS Well-Architected Framework 2026, đây là best practice cho web sessions để đảm bảo scalability và low-latency reads.

🔍 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. Mỗi phương án được đánh giá đúng/sai dựa trên đặc tính kỹ thuật AWS mới nhất:

• key/value ✅ (Đúng)
  Phương án này lý tưởng cho session data vì hỗ trợ truy xuất O(1) siêu nhanh qua key (ví dụ: session ID → toàn bộ data). AWS DynamoDB cung cấp single-digit millisecond latency, hỗ trợ TTL cho data tạm thời như sessions. Không cần schema rigid, dễ scale horizontally.

• graph ❌ (Sai)
  Graph store (như Amazon Neptune) chuyên xử lý mối quan hệ phức tạp (relationships) giữa entities, ví dụ mạng xã hội. Không tối ưu cho session data đơn giản – truy xuất graph query chậm hơn (có thể hàng chục ms) do traversal nodes/edges, dẫn đến latency cao hơn key/value.

• columnar ❌ (Sai)
  Columnar store (như Amazon Redshift hoặc Timestream) dành cho OLAP/analytics trên dữ liệu lớn, nén cột để query aggregate nhanh (scan hàng tỷ rows). Với session data, truy xuất single record có latency cao (giây đến phút do batch processing), không phù hợp real-time retrieval.

• document ❌ (Sai)
  Document store (như Amazon DocumentDB hoặc MongoDB Atlas on AWS) tốt cho JSON semi-structured data với query linh hoạt. Tuy nhiên, latency cao hơn key/value (vài ms đến >10ms) do parsing documents và index phức tạp hơn so với simple key lookup cho sessions.

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

• AWS DynamoDB: docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html – Nhấn mạnh low-latency cho sessions.
• AWS Well-Architected Storage Lens: aws.amazon.com/architecture/well-architected/storage-data-best-practices/ – Khuyến nghị key-value cho web apps.
• ElastiCache cho sessions: aws.amazon.com/elasticache/session-store/.

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

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

Câu hỏi tập trung vào một ứng dụng chạy trên Windows cần truy cập vào mapped drive (ổ đĩa được ánh xạ như một ổ mạng).
📌 Yêu cầu chính: Tìm dịch vụ Azure phù hợp để cung cấp khả năng chia sẻ file qua giao thức SMB (Server Message Block), cho phép ứng dụng Windows mount (ánh xạ) như một ổ đĩa mạng thông thường (ví dụ: Z:).
🛠️ Bối cảnh: Đây là nhu cầu lưu trữ file chia sẻ, tương thích với Windows, không phải lưu trữ object, database hay key-value store. Kiến thức dựa trên phiên bản Azure Storage mới nhất (cập nhật đến 2026), nơi Azure Files hỗ trợ SMB 3.1.1, tích hợp AD DS và Azure AD.

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

Lý do lựa chọn:
Azure Files là dịch vụ lưu trữ file hoàn toàn quản lý, cung cấp file shares qua SMB và NFS, cho phép ứng dụng Windows mapped drive trực tiếp mà không cần thay đổi code. Nó hỗ trợ quyền truy cập đa người dùng, tích hợp Active Directory, và hiệu suất cao cho workload Windows. Đây là lựa chọn chuẩn cho các ứng dụng legacy cần UNC path (\storageaccount.file.core.windows.net\share).
📘 Nguồn tham khảo: Azure Files documentation - Microsoft Learn (cập nhật 2025-2026, hỗ trợ SMB multichannel và REST API).

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

• Azure Files ✅ Đúng: Như đã giải thích, đây là dịch vụ chuyên biệt cho file sharing SMB/NFS, lý tưởng cho mapped drive trên Windows. Hỗ trợ Premium tier cho hiệu suất cao (lên đến 100.000 IOPS/file share năm 2026).
• Azure Blob storage ❌ Sai: Đây là lưu trữ object (block/blob/page blobs) qua HTTP/HTTPS, không hỗ trợ SMB hoặc mapped drive trực tiếp. Bạn phải dùng công cụ như AzCopy hoặc mount qua BlobFuse (không native như drive Windows), không phù hợp cho ứng dụng yêu cầu file system semantics.
• Azure Cosmos DB ❌ Sai: Đây là database NoSQL đa mô hình (document, key-value, graph), dùng cho dữ liệu JSON/XML lớn, không phải file storage hay mapped drive. Không hỗ trợ SMB và tập trung vào query/query performance cao.
• Azure Table storage ❌ Sai: Đây là dịch vụ NoSQL key-value cho dữ liệu semi-structured (OData protocol), không cung cấp file shares hay mapped drive. Chỉ dùng cho metadata/table data, không thay thế file system.

🧠 Lưu ý bổ sung: Trong Azure (phiên bản 2026), Azure Files là lựa chọn duy nhất native cho SMB mapped drives, tích hợp seamless với Windows Server/VM. Nếu cần cross-platform, có thể dùng NFS 4.1. Tránh nhầm lẫn với AWS (EFS/EC2), vì chủ đề là Azure thuần túy!

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

Câu hỏi này thuộc chủ đề lựa chọn loại data store phù hợp trong hệ sinh thái AWS (Amazon Web Services), cụ thể là trong các kỳ thi chứng chỉ như AWS Certified Cloud Practitioner hoặc AWS Certified Data Analytics - Specialty.

📖 Nội dung câu hỏi:
Công ty của bạn đang thiết kế một ứng dụng sẽ ghi (write) một lượng lớn dữ liệu JSON (high volume of JSON data) và có schema do ứng dụng tự định nghĩa (application-defined schema). Bạn cần chọn loại data store phù hợp nhất.

🔍 Phân tích ngữ cảnh:

• JSON data: Đây là dữ liệu semi-structured (nửa cấu trúc), linh hoạt, không cần schema cứng nhắc như relational database.
• High volume: Cần hỗ trợ throughput cao, scalability tự động, phù hợp với NoSQL databases trên AWS.
• Application-defined schema: Schema được ứng dụng quản lý, không phải database enforce, nên ưu tiên các store linh hoạt như document-oriented.
  Câu hỏi nhấn mạnh vào NoSQL data models (mô hình dữ liệu NoSQL) để xử lý dữ liệu JSON hiệu quả, dựa trên kiến thức cập nhật đến năm 2026 (AWS vẫn giữ nguyên phân loại NoSQL core: document, key-value, columnar, graph – theo AWS Documentation 2025+).

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

Đáp án đúng: document

🛠️ Lý do chi tiết:
Loại document data store (như Amazon DocumentDB hoặc DynamoDB với document support) được thiết kế chuyên biệt để lưu trữ dữ liệu dạng JSON/BSON documents. Nó hỗ trợ:

• Schema linh hoạt: Application-defined schema, không cần predefined schema.
• High volume writes: Tối ưu cho ingestion lớn JSON data với partition key và scalability ngang (horizontal scaling).
• Query hiệu quả: Sử dụng index trên fields trong JSON, hỗ trợ aggregation pipelines (MongoDB-compatible trong DocumentDB).
  Theo AWS Well-Architected Framework (Data Stores pillar, cập nhật 2025), document stores lý tưởng cho ứng dụng web/mobile với JSON payloads cao volume.

📋 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 dựa trên đặc tính AWS services (2026):

• columnar ❌ Sai:
  Columnar stores (như Amazon Redshift hoặc Apache Cassandra trên AWS) tối ưu cho analytical queries trên dữ liệu wide tables với compression cao, phù hợp OLAP (Online Analytical Processing) chứ không phải high-volume writes JSON. Chúng yêu cầu schema columnar cố định, không linh hoạt với application-defined schema JSON. (Không phù hợp write-heavy workloads).

• key/value ❌ Sai:
  Key-value stores (như Amazon DynamoDB cơ bản hoặc ElastiCache) chỉ lưu simple pairs (key -> value blob), không hỗ trợ query sâu vào cấu trúc JSON phức tạp. Mặc dù DynamoDB có thể lưu JSON as value, nhưng thiếu native indexing trên fields bên trong document, kém hiệu quả cho schema-defined JSON high volume.

• document ✅ Đúng:
  Như đã giải thích ở trên, document stores (Amazon DocumentDB, DynamoDB Document API) hoàn hảo cho JSON semi-structured data với schema linh hoạt, hỗ trợ high-throughput writes (lên đến hàng triệu requests/giây) và query rich (dot notation indexing). Đây là lựa chọn chuẩn theo AWS best practices cho app logs, user profiles JSON.

• graph ❌ Sai:
  Graph stores (Amazon Neptune) chuyên cho relationships và traversals (nodes/edges), như social networks hoặc fraud detection. Không tối ưu cho pure JSON storage/write volume mà không có graph semantics; schema graph phức tạp hơn application-defined JSON đơn giản.

📘 Tài liệu tham khảo

• AWS Documentation: Choosing the Right Database (cập nhật 2025).
• AWS Well-Architected: Data Stores Lens.
• DynamoDB/DocumentDB Guides: JSON Handling in DynamoDB và DocumentDB JSON Support.

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

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

Câu hỏi yêu cầu khuyến nghị một loại kho dữ liệu phi quan hệ (non-relational data store) được tối ưu hóa cho việc lưu trữ và truy xuất các tệp văn bản, video, luồng âm thanh, và hình ảnh đĩa ảo (virtual disk images). Kho dữ liệu này phải hỗ trợ lưu trữ dữ liệu chính (data), một số siêu dữ liệu (metadata), và một ID duy nhất cho mỗi tệp (unique ID).

📘 Bối cảnh AWS (cập nhật đến 2026): Trong AWS, các loại kho dữ liệu phi quan hệ được phân loại rõ ràng theo mô hình dữ liệu (data model). Câu hỏi tập trung vào dữ liệu không cấu trúc (unstructured data) như tệp lớn, media, không cần truy vấn phức tạp mà ưu tiên độ bền, khả năng mở rộng và truy xuất nhanh qua ID duy nhất. Đây là đặc trưng của object storage, không phải các mô hình NoSQL khác.

✅ Đáp án đúng: object

Lý do lựa chọn 🛠️:
Loại object storage (như Amazon S3 - phiên bản mới nhất 2026 với S3 Object Lambda và Intelligent-Tiering) được thiết kế chuyên biệt cho dữ liệu không cấu trúc như tệp văn bản, video, audio, và virtual disk images. Mỗi object bao gồm:

• Dữ liệu chính (object data): Nội dung tệp bất kỳ kích thước (từ byte đến TB).
• Metadata: Thuộc tính tùy chỉnh (user-defined metadata) như tags, MIME types.
• Unique ID (key): Tên object duy nhất trong bucket làm khóa truy xuất.
  S3 hỗ trợ lưu trữ vô hạn, độ bền 99.999999999% (11 9's), tích hợp CDN (CloudFront) cho streaming media, và tính năng như versioning, encryption tự động. Đây là lựa chọn chuẩn cho workload này theo AWS Well-Architected Framework (Data Storage Lens pillar).

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

• ❌ key/value
  Phương án này sai vì key/value store (như Amazon DynamoDB key-value mode) tối ưu cho dữ liệu nhỏ, đơn giản (như cache, sessions), không phù hợp lưu trữ tệp lớn như video hay disk images (giới hạn kích thước item ~400KB). Không hỗ trợ tốt metadata phong phú hoặc streaming media.

• ❌ columnar
  Phương án này sai vì columnar store (như Amazon Redshift hoặc Athena với columnar format) dành cho dữ liệu có cấu trúc, phân tích OLAP (aggregation trên cột lớn). Không tối ưu cho tệp binary không cấu trúc như audio/video, thiếu hỗ trợ unique ID cho từng tệp riêng lẻ.

• ✅ object
  Phương án này đúng như đã giải thích ở trên. Object storage là lựa chọn lý tưởng cho mọi loại tệp không cấu trúc, với unique key/object name, metadata mở rộng, và hiệu suất cao cho upload/download lớn. (Áp dụng phiên bản S3 mới nhất 2026 với S3 Express One Zone cho latency thấp).

• ❌ document
  Phương án này sai vì document store (như DynamoDB document model hoặc MongoDB Atlas on AWS) phù hợp dữ liệu JSON/BSON có cấu trúc semi-structured (user profiles, logs). Không hiệu quả cho tệp binary lớn (video/disk images vượt giới hạn 400KB/item), thiếu tối ưu hóa streaming và metadata file-oriented.

📚 Tài liệu tham khảo

• AWS S3 Documentation: https://aws.amazon.com/s3/features/ (Object storage overview).
• AWS Well-Architected Framework (2026 edition): https://aws.amazon.com/architecture/well-architected/ - Reliability pillar cho storage.
• DynamoDB Limits: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html (Xác nhận giới hạn item size).

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

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

Câu hỏi mô tả tình huống công ty đang thiết kế một kho dữ liệu (data store) cho các cảm biến nhiệt độ kết nối internet. Dữ liệu thu thập được sử dụng để phân tích xu hướng nhiệt độ (temperature trends).
📈 Yêu cầu chính: Chọn loại kho dữ liệu phù hợp nhất. Đây là dữ liệu thời gian thực (time-based) từ IoT sensors, với đặc trưng là dữ liệu lớn, liên tục tăng theo thời gian, cần query hiệu quả trên khoảng thời gian (ví dụ: trung bình nhiệt độ theo giờ/ngày/tháng).
🛠️ Bối cảnh AWS (cập nhật 2026): AWS khuyến nghị sử dụng các dịch vụ chuyên biệt cho dữ liệu IoT/time-series để tối ưu chi phí, hiệu suất và scalability, theo AWS Well-Architected Framework (phiên bản mới nhất 2023+ với cập nhật ML/IoT).

✅ Đáp án đúng: time series

Lý do chọn:
Dữ liệu từ cảm biến nhiệt độ là dữ liệu chuỗi thời gian (time series data) điển hình – mỗi điểm dữ liệu gắn với timestamp (thời điểm đo) và giá trị (nhiệt độ). Phân tích xu hướng cần query theo thời gian (aggregation, anomaly detection, forecasting).
🧮 Ưu điểm time series DB: Hỗ trợ nén dữ liệu thời gian, tự động expire dữ liệu cũ, tích hợp ML cho dự báo. Trong AWS, Amazon Timestream (ra mắt 2020, cập nhật 2026 với multi-measure support và serverless scaling) là lựa chọn lý tưởng cho IoT workloads.
📘 Nguồn: AWS Timestream Documentation & AWS IoT Analytics.

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

• relational ❌ Sai:
  Loại cơ sở dữ liệu quan hệ (RDBMS) như Amazon RDS/Aurora phù hợp cho dữ liệu có cấu trúc cố định, mối quan hệ phức tạp (joins). Không tối ưu cho dữ liệu time-series lớn vì query thời gian kém hiệu quả, tốn tài nguyên index timestamp, dễ bottleneck với volume cao từ sensors. Không hỗ trợ native time-series functions.

• time series ✅ Đúng:
  Như đã giải thích ở trên, đây là lựa chọn hoàn hảo cho dữ liệu IoT theo thời gian, với hiệu suất cao cho queries như rolling averages, interpolations. AWS Timestream xử lý hàng tỷ events/ngày mà không cần quản lý infra.

• graph ❌ Sai:
  Cơ sở dữ liệu đồ thị (Graph DB) như Amazon Neptune dùng cho dữ liệu mối quan hệ phức tạp (nodes/edges), ví dụ mạng xã hội hoặc recommendation. Không phù hợp với dữ liệu cảm biến tuyến tính theo thời gian – không có relationships phức tạp, chỉ là sequences of measurements.

• columnar ❌ Sai:
  Lưu trữ cột (columnar storage) như Amazon Redshift tối ưu cho analytics OLAP trên dữ liệu lớn, scan nhanh các cột cụ thể. Tuy hỗ trợ time-series một phần (với partitioning), nhưng không chuyên biệt cho real-time ingestion từ sensors, tốn kém hơn cho high-velocity data so với time-series DB thuần.

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

✅ Time series là lựa chọn tối ưu theo best practices AWS cho IoT temperature monitoring (ví dụ: smart cities, weather apps).
🔄 Cập nhật 2026: AWS tích hợp Timestream với Amazon Bedrock cho ML forecasting trends.
📚 Tài liệu tham khảo thêm:

• AWS Database Blog: Time-Series Workloads
• AWS Certified Data Engineer Associate Guide (cho kiến thức fundamentals).

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

Câu hỏi này thuộc kỳ thi Microsoft Azure Data Fundamentals (DP-900), tập trung vào Azure Cosmos DB – một dịch vụ cơ sở dữ liệu NoSQL đa mô hình của Microsoft Azure. Cụ thể, câu hỏi hỏi về hai mức độ (levels) mà bạn có thể thiết lập throughput (tốc độ xử lý, đo bằng RU/s - Request Units per second) cho một tài khoản Azure Cosmos DB.

• Throughput là tài nguyên chính quyết định khả năng mở rộng và hiệu suất của Cosmos DB, có thể cấu hình ở mức tự động (autoscale) hoặc cố định (manual).
• Câu hỏi là dạng multi-select (chọn nhiều đáp án), với hai đáp án đúng, mỗi đáp án đúng chiếm 1 điểm.
• Lưu ý: Không phải tất cả các mức đều hỗ trợ thiết lập throughput trực tiếp; một số chỉ là khái niệm nội bộ.

Kiến thức dựa trên tài liệu Azure Cosmos DB mới nhất (cập nhật 2024-2026): Throughput chỉ có thể set ở database và container levels. 📘 Nguồn tham khảo:

• Microsoft Docs: Set throughput for Azure Cosmos DB containers and databases
• Azure Cosmos DB capacity planning

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

Hai đáp án đúng là: "database" và "container".
🛠️ Lý do: Trong Azure Cosmos DB, bạn có thể provision (cung cấp) throughput ở hai mức chính để kiểm soát chi phí và hiệu suất:

• Database level: Áp dụng throughput chia sẻ cho toàn bộ database và các container con (shared throughput).
• Container level: Áp dụng throughput riêng biệt cho từng container (dedicated throughput).
  Điều này cho phép linh hoạt mở rộng theo nhu cầu, hỗ trợ autoscale lên đến 100.000 RU/s/container hoặc cao hơn ở database level.

📋 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 văn bản gốc bằng tiếng Anh. Phần giải thích hoàn toàn bằng tiếng Việt:

• ✅ "database"
  🟢 Đúng: Đây là mức cao hơn, nơi bạn set throughput chia sẻ (shared database throughput) cho toàn bộ database. Tất cả container trong database sẽ sử dụng chung RU/s này, giúp tiết kiệm chi phí cho workload nhỏ. Hỗ trợ autoscale từ 400-100.000 RU/s (mới nhất 2026). Ví dụ: Tạo database với 1000 RU/s, các container con tự chia sẻ.

• ❌ "item"
  🔴 Sai: Item (hay document) là mức dữ liệu nhỏ nhất trong container, không hỗ trợ set throughput trực tiếp. Throughput được quản lý ở mức cao hơn (container/database), và RU/s được tính toán dựa trên kích thước/độ phức tạp của từng item khi query. Không có tùy chọn provision RU/s cho item riêng lẻ.

• ✅ "container"
  🟢 Đúng: Đây là mức phổ biến nhất, nơi bạn set throughput dành riêng (provisioned throughput) cho từng container. Hỗ trợ autoscale linh hoạt (từ 400 RU/s đến không giới hạn), phù hợp cho workload lớn. Ví dụ: Container cho ứng dụng web có thể set 5000 RU/s độc lập.

• ❌ "partition"
  🔴 Sai: Partition (logical partition) là cơ chế phân vùng nội bộ tự động của Cosmos DB để scale dữ liệu horizontally dựa trên partition key. Không thể set throughput trực tiếp trên partition; throughput được áp dụng ở container/database và phân bổ tự động qua các physical partitions. Đây chỉ là khái niệm kỹ thuật, không phải level provision.

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