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

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

📘 Nội dung câu hỏi:
Câu hỏi yêu cầu xác định dịch vụ Azure nào cung cấp tính tương thích cao nhất (highest compatibility) cho các cơ sở dữ liệu được di chuyển (migrated) từ Microsoft SQL Server 2019 Enterprise edition. Đây là phiên bản SQL Server cao cấp nhất trên máy chủ vật lý (on-premises), với đầy đủ tính năng doanh nghiệp như Always On Availability Groups, advanced security, partitioning, và nhiều tính năng nâng cao khác. Khi di chuyển lên Azure, cần dịch vụ giữ nguyên gần như 100% syntax T-SQL, công cụ quản lý, và tính năng để giảm thiểu thay đổi code hoặc cấu hình. Kiến thức dựa trên tài liệu Azure cập nhật đến năm 2026 (Azure SQL Managed Instance hỗ trợ SQL Server 2022 và tương thích ngược với 2019 Enterprise).

✅ Đá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 để tương thích gần như 100% với SQL Server on-premises (bao gồm Enterprise edition 2019). Nó hỗ trợ hầu hết tính năng Enterprise như cross-database queries, SQL Agent jobs, VNet integration, và sys tables giống hệt. Điều này làm cho việc migrate "lift-and-shift" trở nên dễ dàng nhất, với tỷ lệ tương thích lên đến 95-99% mà không cần chỉnh sửa lớn. (Nguồn: Microsoft Docs - Azure SQL Managed Instance compatibility).

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

• Azure SQL Database ❌
  Phân tích sai: Đây là dịch vụ SQL Database thuần PaaS, tập trung vào serverless và hyperscale, nhưng tương thích thấp hơn so với Managed Instance. Nó thiếu nhiều tính năng Enterprise của SQL Server 2019 như SQL Agent, cross-database queries, và một số advanced features (chỉ hỗ trợ ~70-80% T-SQL). Phù hợp migrate đơn giản nhưng cần chỉnh sửa code nhiều. (Nguồn: Azure SQL Database features).

• Azure Database for MySQL ❌
  Phân tích sai: Đây là dịch vụ dành riêng cho MySQL (không phải SQL Server), nên hoàn toàn không tương thích với SQL Server 2019 Enterprise. Không hỗ trợ T-SQL hay bất kỳ tính năng nào của Microsoft SQL Server. Chỉ dùng cho workload MySQL gốc.

• Azure SQL Managed Instance ✅
  Phân tích đúng: Như đã giải thích ở trên, đây là lựa chọn tối ưu với tương thích cao nhất, hỗ trợ đầy đủ SQL Server 2019 Enterprise features trong môi trường managed, VNet-isolated. Giảm thiểu downtime và chi phí refactor. (Nguồn: Migration guide).

• an Azure SQL Database elastic pool ❌
  Phân tích sai: Đây không phải dịch vụ riêng mà là tính năng scaling của Azure SQL Database (nhóm nhiều DB vào pool để chia sẻ tài nguyên). Nó kế thừa hạn chế tương thích của Azure SQL Database, không giải quyết vấn đề migration từ Enterprise edition. Chỉ dùng để optimize chi phí, không phải compatibility. (Nguồn: Elastic pools overview).

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

• Microsoft Learn: Azure SQL comparison.
• Azure Update 2026: Managed Instance tiếp tục dẫn đầu compatibility với SQL Server 2022 CUx (tương thích ngược 2019).

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 câu hỏi trắc nghiệm về Azure Cosmos DB

📖 Giải thích nội dung câu hỏi:
Câu hỏi yêu cầu xác định cài đặt nào chỉ có thể được cấu hình trong quá trình tạo tài khoản Azure Cosmos DB, nghĩa là sau khi tài khoản đã được tạo, bạn không thể thay đổi cài đặt đó nữa. Azure Cosmos DB là dịch vụ cơ sở dữ liệu NoSQL đa mô hình của Microsoft Azure, hỗ trợ nhiều API như SQL, MongoDB, v.v. Khi tạo tài khoản, một số tùy chọn bị "khóa" vĩnh viễn, trong khi các tùy chọn khác có thể chỉnh sửa sau qua Azure Portal, CLI hoặc PowerShell. Câu hỏi tập trung vào sự khác biệt này để kiểm tra kiến thức về quy trình tạo và quản lý tài khoản Cosmos DB (cập nhật theo tài liệu Microsoft đến năm 2026, không có thay đổi lớn về quy tắc này).

✅ Đáp án đúng: API
Lý do lựa chọn: API (như Core (SQL), MongoDB, Cassandra, Gremlin, Table) là cài đặt chỉ chọn được lúc tạo tài khoản và không thể thay đổi sau đó. Nếu chọn sai API, bạn phải tạo tài khoản mới. Điều này đảm bảo tính tương thích dữ liệu và hiệu suất tối ưu cho mô hình dữ liệu cụ thể. (Phiên bản mới nhất 2026 vẫn giữ nguyên quy tắc này).

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

• geo-redundancy ❌
  Sai vì: Cài đặt geo-redundancy (phân phối địa lý với sao lưu đa vùng) có thể cấu hình hoặc thay đổi sau khi tạo tài khoản. Bạn có thể thêm/xóa vùng (regions), thiết lập ưu tiên failover qua Azure Portal hoặc SDK. Ví dụ: Bắt đầu single-region, sau thêm multi-region read mà không cần tạo lại account.

• multi-region writes ❌
  Sai vì: Tùy chọn multi-region writes (ghi dữ liệu đa vùng) có thể kích hoạt/tắt sau khi tạo (đặc biệt cho tài khoản tạo từ 08/02/2023 trở đi, mặc định bật). Sử dụng lệnh Azure CLI như az cosmosdb update --capabilities EnableMultiRegionWrite=true để thay đổi, không yêu cầu tạo mới.

• production or non-production account type ❌
  Sai vì: Loại tài khoản production/non-production (liên quan đến preview hoặc capacity mode như serverless/provisioned) có thể điều chỉnh hoặc migrate sau. Ví dụ: Chuyển từ preview sang production qua Azure support, hoặc scale capacity mode (serverless chỉ chọn lúc tạo nhưng provisioned linh hoạt hơn). Không bị khóa cứng như API.

• API ✅
  Đúng vì: Như đã giải thích, đây là cài đặt duy nhất bị khóa vĩnh viễn lúc tạo. Tài liệu chính thức xác nhận: "The API type cannot be changed after account creation" – buộc tạo tài khoản mới nếu cần switch (ví dụ: từ SQL sang MongoDB).

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

• Microsoft Docs: Create an Azure Cosmos DB account (cập nhật 2026: Phần "Account settings" nhấn mạnh API immutable).
• Azure Cosmos DB FAQs (xác nhận multi-region writes editable).
• Change multi-region writes (hướng dẫn post-creation config).

Hy vọng phân tích này giúp bạn nắm vững kiến thức Azure Cosmos DB! 🚀 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 trắc nghiệm

Nội dung câu hỏi:
Câu hỏi hỏi về các thiết lập (settings) có thể cấu hình ở cấp độ container (container level) trong một tài khoản Azure Cosmos DB sử dụng Core (SQL) API. Đây là loại câu hỏi chọn nhiều đáp án đúng (multi-select), với hai đáp án đúng, mỗi đáp án đúng chiếm 1 điểm. Azure Cosmos DB là dịch vụ NoSQL đa mô hình của Microsoft Azure, cho phép lưu trữ và truy vấn dữ liệu với tính sẵn sàng cao, phân bố toàn cầu. Container (trước đây gọi là collection) là đơn vị lưu trữ dữ liệu cơ bản, nơi bạn có thể tùy chỉnh một số thiết lập riêng biệt so với cấp độ tài khoản (account level). Câu hỏi tập trung vào việc phân biệt những gì có thể config ở container level thay vì account level, dựa trên kiến thức cập nhật mới nhất của Azure Cosmos DB đến năm 2026 (phiên bản hiện tại hỗ trợ serverless, autoscale throughput, và multi-region writes).

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

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

• the throughput
• the partition key

Lý do:
🛠️ Trong Azure Cosmos DB, throughput (lượng thông lượng RU/s - Request Units per second) và partition key (khóa phân vùng) là hai thiết lập có thể cấu hình độc lập ở cấp độ container. Điều này cho phép tối ưu hóa hiệu suất và phân phối dữ liệu linh hoạt cho từng container riêng lẻ, ngay cả khi tài khoản đã được tạo với Core (SQL) API. Throughput hỗ trợ chế độ provisioned (manual/autoscale) hoặc serverless ở cấp container, còn partition key quyết định cách dữ liệu được phân vùng logic để scale ngang.

📋 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 bằng tiếng Anh:

• ✅ the throughput
  Đúng! 📈 Thiết lập throughput (RU/s) có thể được cấu hình trực tiếp ở cấp độ container thông qua Azure Portal, CLI, SDK hoặc ARM template. Bạn có thể chọn chế độ provisioned throughput (manual hoặc autoscale lên đến 100.000 RU/s/container) hoặc serverless. Điều này cho phép scale độc lập từng container mà không ảnh hưởng toàn tài khoản. (Cập nhật 2026: Hỗ trợ infinite scale với autoscale.)

• ❌ the read region
  Sai! 🌍 Thiết lập "read region" (vùng đọc) thuộc về cấp độ tài khoản (account level), cụ thể trong phần multi-region replication. Bạn chỉ có thể enable/disable read regions toàn cục cho tài khoản Cosmos DB, không config riêng cho từng container. Container chỉ kế thừa từ account.

• ✅ the partition key
  Đúng! 🔑 Partition key được định nghĩa bắt buộc ở cấp độ container khi tạo container. Nó quyết định cách dữ liệu được phân vùng (partitioning path, ví dụ /userId), hỗ trợ scale ngang và hiệu suất truy vấn. Không thể thay đổi sau khi tạo container, nhưng có thể tạo container mới với key khác.

• ❌ the API
  Sai! 🔒 API type (như Core/SQL, MongoDB, Cassandra, etc.) được chọn một lần duy nhất ở cấp độ tài khoản khi tạo account. Không thể thay đổi hoặc config riêng cho container; tất cả container trong account phải tuân theo API đã chọn.

📘 Tài liệu tham khảo

• Azure Cosmos DB container concepts (Microsoft Docs, cập nhật 2026).
• Provision throughput on containers – Chi tiết throughput/container.
• Partitioning in Azure Cosmos DB – Về partition key.
• Multi-region accounts – Xác nhận read region ở account level.

Hy vọng phân tích này giúp bạn nắm vững kiến thức Azure Cosmos DB! 🚀 Nếu cần thêm ví dụ code hoặc demo, hãy 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 thiết kế một data store phù hợp để lưu trữ dữ liệu sinh viên (student data). Dữ liệu được trình bày dưới dạng bảng với hai cột chính:

• Student Number (số định danh sinh viên, ví dụ: 7634634 lặp lại nhiều lần).
• Student Information (thông tin chi tiết của sinh viên, được lưu trữ dưới dạng các cặp key-value như "First name: Ben", "Last name: Smith", "Preferred Name: Benjamin", "Email Address: dpaiha@contoso.com", "MCP ID: 931817", "Phone number: 514-555-1101", v.v.).

📊 Phân tích hình ảnh bảng dữ liệu (dựa trên nội dung hình được cung cấp):

• Bảng có cấu trúc columnar rõ rệt: Dữ liệu được tổ chức theo cột dọc (columns), với Student Number lặp lại cho cùng một sinh viên trên nhiều hàng để chứa các thuộc tính khác nhau.
• Student Information chứa dữ liệu semi-structured (bán cấu trúc), với các trường linh hoạt như tên, email, ID, số điện thoại – không phải dạng JSON thuần hay graph, mà giống như dữ liệu được nén và truy vấn theo cột hiệu quả cho phân tích (analytics).
• Đặc trưng: Phù hợp cho analytical workloads (xử lý phân tích lớn), nơi cần quét nhanh các cột cụ thể (ví dụ: tổng hợp theo Student Number hoặc lọc theo email). Không phù hợp row-oriented (hàng ngang) vì dữ liệu phân tán theo cột.
  Ví dụ minh họa từ bảng:
• Student 7634634 có nhiều hàng: Tên Ben Smith (Preferred: Benjamin) và Dominik Paiha (email + MCP ID).
  Điều này gợi ý columnar data store như Amazon Redshift hoặc định dạng Parquet trong AWS (cập nhật đến 2026, hỗ trợ columnar storage tối ưu hóa cho ML/AI queries).

🛠️ Mục tiêu: Chọn loại data store phù hợp nhất cho dữ liệu columnar format này trên AWS.

✅ Đáp án đúng: columnar

Lý do lựa chọn:
Dữ liệu trong bảng được lưu trữ theo hướng cột (column-oriented), nơi các giá trị thuộc tính (như tên, email) nằm dọc theo cột Student Information, với ID sinh viên lặp lại để hỗ trợ truy vấn phân tích nhanh (ví dụ: aggregate theo cột). Columnar data stores (như Amazon Redshift, Apache Parquet trên S3/Athena) tối ưu hóa cho OLAP workloads, nén dữ liệu tốt, scan nhanh cột cụ thể mà không đọc toàn bộ hàng. Phù hợp dữ liệu semi-structured như thế này (cập nhật AWS 2026: Redshift hỗ trợ columnar tables với auto-scaling và ML integration).

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

• ❌ graph:
  Phương án sai vì dữ liệu không có mối quan hệ phức tạp (relationships) như nút- cạnh (nodes-edges) giữa sinh viên, lớp học hay bạn bè. Graph databases (như Amazon Neptune) dùng cho social networks hoặc recommendations, không phù hợp dữ liệu tabular đơn giản theo cột này.

• ❌ key/value:
  Phương án sai vì dữ liệu không chỉ là cặp key đơn giản - value đơn giản (như DynamoDB với key=StudentNumber, value=JSON nhỏ). Ở đây, dữ liệu phân tán theo nhiều hàng/cột với nhiều thuộc tính lặp ID, cần truy vấn columnar phức tạp hơn key-value thuần túy.

• ❌ object:
  Phương án sai vì dữ liệu không phải unstructured blobs (như file ảnh/video trên Amazon S3). Object storage dùng cho raw objects không có schema rõ ràng, trong khi dữ liệu này có cấu trúc cột rõ rệt cần query analytics, không phải lưu trữ file lớn.

• ✅ columnar:
  (Như đã giải thích ở trên) Hoàn toàn phù hợp với định dạng bảng column-oriented, tối ưu cho phân tích dữ liệu lớn.

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

• AWS Documentation: Amazon Redshift - Columnar Storage (hỗ trợ columnar tables với SORTKEY/DISTKEY cho performance cao).
• [Apache Parquet on AWS](https://aws.amazon.com/big-data/datalakes-and-analytics/ columnar-storage/) (định dạng columnar mặc định cho Athena/S3, tối ưu compression 2026).
• Exam reference: AWS Certified Data Engineer/Analytics - Specialty (phiên bản 2024-2026), tương tự DP-100 Azure nhưng map sang AWS columnar workloads.

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ụ code/query, hãy hỏi 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 storage solution supports role-based access control (RBAC) at the file and folder level?

📝 Giải thích nội dung câu hỏi một cách chi tiết:
Câu hỏi này tập trung vào việc xác định giải pháp lưu trữ nào trong hệ sinh thái Microsoft Azure hỗ trợ Role-Based Access Control (RBAC) ở mức độ chi tiết là file (tệp) và folder (thư mục).

• RBAC là cơ chế kiểm soát truy cập dựa trên vai trò (roles), được tích hợp sâu trong Azure Active Directory (Azure AD), cho phép gán quyền truy cập dựa trên các vai trò như Owner, Contributor, Reader.
• Mức độ file và folder level nghĩa là kiểm soát truy cập phải granular (chi tiết), không chỉ ở cấp account hoặc container mà còn ở cấp thư mục con và tệp riêng lẻ, thường thông qua POSIX-style Access Control Lists (ACLs) kết hợp với RBAC.
• Chủ đề liên quan đến các dịch vụ lưu trữ Azure, nhấn mạnh khả năng hierarchical namespace (cấu trúc thư mục phân cấp) và fine-grained access control. Đây là kiến thức cốt lõi trong Microsoft Azure Data Fundamentals (DP-900), với cập nhật mới nhất đến năm 2026 từ tài liệu Azure (ADLS Gen2 vẫn là tiêu chuẩn, hỗ trợ RBAC + ACLs đầy đủ).

✅ Đáp án đúng: Azure Data Lake Storage
Lý do lựa chọn: Azure Data Lake Storage Gen2 (ADLS Gen2) là giải pháp lưu trữ phân tích lớn, hỗ trợ đầy đủ RBAC ở mức file và folder level thông qua hai lớp kiểm soát:

• Azure RBAC ở cấp account, container (root).
• POSIX ACLs granular ở cấp thư mục và file (rwx permissions cho user/group/other).
  Điều này lý tưởng cho big data analytics (tích hợp với Azure Synapse, Databricks). Kiến thức cập nhật 2026: ADLS Gen2 vẫn dẫn đầu với hierarchical namespace enabled, hỗ trợ multi-protocol access (Blob + Data Lake API).

🛠️ Phân tích tất cả các phương án (giữ nguyên văn bản gốc bằng tiếng Anh):

• Azure Disk Storage ❌
  Giải thích sai: Đây là dịch vụ lưu trữ block-level cho máy ảo (VMs), chỉ hỗ trợ RBAC ở cấp disk hoặc VM resource group (qua Azure RBAC). Không hỗ trợ cấu trúc file/folder, vì nó là raw block storage (như SSD/HDD ảo), không có filesystem phân cấp. Không phù hợp cho access control granular.

• Azure Data Lake Storage ✅
  Giải thích đúng: Như đã nêu ở trên, hỗ trợ RBAC kết hợp ACLs ở file/folder level với hierarchical namespace. Ví dụ: Bạn có thể set ACLs như user::rwx cho một file cụ thể. Hoàn hảo cho enterprise data lakes.

• Azure Blob storage ❌
  Giải thích sai: Blob Storage (flat namespace) hỗ trợ RBAC ở cấp account/container/blob, nhưng không có native file/folder level ACLs trừ khi enable hierarchical namespace (lúc đó nó trở thành ADLS Gen2). Phiên bản chuẩn chỉ coarse-grained (shared access signatures - SAS). Không granular như ADLS.

• Azure Queue storage ❌
  Giải thích sai: Đây là dịch vụ lưu trữ message queue cho decoupling apps (FIFO messages), không có khái niệm file/folder. RBAC chỉ ở cấp queue level, không hỗ trợ hierarchical access control. Dùng cho messaging, không phải file storage.

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

• Azure Data Lake Storage Gen2 - Access Control Model ✅ (Chi tiết RBAC + ACLs).
• Azure Storage Security Guide (So sánh các dịch vụ).
• DP-900 Exam Guide: Describe core data storage concepts in Azure (Microsoft Learn, 2026 edition).
  (Nguồn chính thức từ Microsoft Docs, không liên quan AWS vì câu hỏi rõ ràng về Azure).

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

📖 Nội dung câu hỏi:
Câu hỏi yêu cầu chọn storage tier phù hợp nhất cho Azure Blob Storage để lưu trữ dữ liệu trong 7 năm nhằm đáp ứng yêu cầu tuân thủ (compliance) của công ty. Thời gian truy xuất dữ liệu không quan trọng (retrieval time unimportant), và giải pháp phải giảm thiểu chi phí lưu trữ tối đa (minimize storage costs).
🛠️ Đây là tình huống điển hình cho dữ liệu lưu trữ dài hạn, ít truy cập, nơi chi phí lưu trữ thấp là ưu tiên hàng đầu, không cần tốc độ truy xuất nhanh. Azure Blob Storage cung cấp các tier như Hot, Cool, Cold và Archive để tối ưu hóa chi phí dựa trên tần suất sử dụng (theo tài liệu Microsoft cập nhật đến 2026).

✅ Đáp án đúng: Archive
Lý do lựa chọn:
Archive tier được thiết kế dành riêng cho dữ liệu lưu trữ dài hạn (hàng năm hoặc lâu hơn) như lưu trữ backup, compliance hoặc archival. Nó có chi phí lưu trữ thấp nhất (khoảng 0.00099 USD/GB/tháng theo giá 2026), phù hợp hoàn hảo với yêu cầu 7 năm lưu trữ mà không cần truy xuất thường xuyên. Thời gian truy xuất chậm (12-15 giờ cho rehydration) không ảnh hưởng vì câu hỏi nhấn mạnh retrieval time không quan trọng. Sử dụng Archive giúp tiết kiệm chi phí lên đến 95% so với Hot tier!
📘 Nguồn tham khảo: Microsoft Docs - Azure Blob Storage Tiers (cập nhật 2025-2026).

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

• Archive
  ✅ Đúng vì tier này tối ưu hóa cho dữ liệu ít hoặc không truy cập, với chi phí lưu trữ rẻ nhất trong Azure Blob Storage. Phù hợp lý tưởng cho compliance 7 năm, nơi dữ liệu "ngủ đông" lâu dài. Rehydration time dài (giờ đến ngày) nhưng không vấn đề theo yêu cầu.

• Hot
  ❌ Sai vì Hot tier dành cho dữ liệu truy cập thường xuyên (frequent access), có chi phí lưu trữ cao nhất (khoảng 0.0184 USD/GB/tháng). Sử dụng cho trường hợp này sẽ lãng phí chi phí lớn cho dữ liệu lưu 7 năm ít dùng, không đáp ứng minimize costs.

• Cool
  ❌ Sai vì Cool tier phù hợp dữ liệu truy cập không thường xuyên (infrequent access, như hàng tháng), chi phí trung bình (khoảng 0.01 USD/GB/tháng). Với 7 năm lưu trữ và retrieval không quan trọng, Cool vẫn đắt hơn Archive rất nhiều (khoảng 10 lần), không phải lựa chọn tối ưu chi phí.

💡 Lưu ý thêm: Theo cập nhật Azure 2026, có thêm Cold tier (preview đầy đủ từ 2025) cho truy cập hiếm (rare access), nhưng Archive vẫn là lựa chọn rẻ nhất cho archival dài hạn. Luôn kiểm tra giá khu vực cụ thể qua Azure Pricing Calculator! 🛡️

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

Câu hỏi tập trung vào các loại cơ sở dữ liệu phi quan hệ (non-relational data store) trong AWS, cụ thể là loại nào hỗ trợ schema linh hoạt (flexible schema), lưu trữ dữ liệu dưới dạng tệp JSON, và lưu toàn bộ dữ liệu của một thực thể (entity) trong cùng một tài liệu (document).

📘 Giải thích rõ ràng:

• Non-relational data store (NoSQL) được thiết kế để xử lý dữ liệu không cấu trúc hoặc bán cấu trúc, khác với cơ sở dữ liệu quan hệ (SQL) có schema cố định.
• Flexible schema: Không yêu cầu định nghĩa schema trước, cho phép thêm/sửa trường dữ liệu dễ dàng.
• Lưu trữ như JSON: Dữ liệu được biểu diễn dưới dạng tài liệu JSON (hoặc tương tự như BSON trong MongoDB/DynamoDB).
• Toàn bộ entity trong một document: Tránh join phức tạp, toàn bộ thông tin liên quan đến một đối tượng nằm trong một tài liệu duy nhất, tối ưu cho đọc/ghi nhanh.
• Chủ đề liên quan đến Amazon DynamoDB (document store) hoặc các dịch vụ NoSQL khác của AWS như DocumentDB.

Câu hỏi kiểm tra kiến thức về phân loại NoSQL theo AWS (cập nhật đến 2026: AWS vẫn phân loại NoSQL thành document, key-value, columnar, graph, time series...).

✅ Đáp án đúng: document

Lý do lựa chọn 🛠️:

• Document store (như Amazon DynamoDB hoặc DocumentDB) chính xác khớp với tất cả tiêu chí:
  • Schema linh hoạt: Có thể lưu documents với cấu trúc khác nhau trong cùng collection/table.
  • Lưu trữ dữ liệu như JSON: Sử dụng định dạng JSON/BSON, ví dụ một document user có thể chứa { "id": 1, "name": "John", "address": {...} }.
  • Toàn bộ entity trong một document: Không cần join, toàn bộ dữ liệu của entity (ví dụ profile user + orders) nằm trong một document duy nhất, hỗ trợ truy vấn nhanh với secondary indexes.
• Đây là đặc trưng cốt lõi của document databases theo tài liệu AWS mới nhất (2026).

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

• ✅ document:
  Đúng vì hoàn toàn phù hợp: schema linh hoạt, dữ liệu JSON, entity trong một document duy nhất. Ví dụ DynamoDB lưu items như JSON objects.

• ❌ columnar:
  Sai vì columnar store (như Amazon Redshift hoặc Apache Parquet trên S3) tối ưu cho phân tích cột (column-oriented), không dùng JSON mà dùng định dạng columnar nén, schema thường cố định hơn, dữ liệu phân tán theo cột chứ không gom entity vào document.

• ❌ graph:
  Sai vì graph store (như Amazon Neptune) lưu trữ dưới dạng nodes/edges/relationships, không dùng JSON document mà dùng property graph hoặc RDF, schema linh hoạt nhưng tập trung vào quan hệ (traversal), không gom toàn bộ entity vào một document đơn lẻ.

• ❌ time series:
  Sai vì time series store (như Amazon Timestream) chuyên cho dữ liệu thời gian (metrics, logs), schema semi-structured nhưng ưu tiên timestamp + measures/dimensions, không lưu như JSON document đầy đủ entity mà tối ưu cho append-only time-based queries.

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

• AWS Documentation: Amazon DynamoDB - Document Model (xác nhận JSON-like items).
• AWS Well-Architected Framework: NoSQL Data Modeling (phân loại document vs. others).
• AWS Re:Invent 2025/2026 sessions: DynamoDB vẫn là gold standard cho document stores với PartiQL queries hỗ trợ JSON.
• Microsoft Learn (Azure tương đương): Cosmos DB Document Model – so sánh để học cross-cloud.

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

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

Câu hỏi tập trung vào việc provision (cung cấp) một tài khoản Azure Cosmos DB, và hỏi về tính năng nào cung cấp sự dư thừa (redundancy) bên trong một Azure region (vùng Azure).
✅ Mục tiêu chính: Azure Cosmos DB là dịch vụ NoSQL đa mô hình với SLA 99.999% availability. Sự dư thừa trong region nghĩa là bảo vệ dữ liệu khỏi sự cố phần cứng hoặc mạng cục bộ bằng cách replicate dữ liệu qua nhiều Availability Zones (AZs) độc lập trong cùng một region. Điều này khác với multi-region replication (dư thừa giữa các region).
📘 Kiến thức cập nhật (đến 2026): Theo tài liệu Microsoft Azure mới nhất (phiên bản GA 2024-2026), khi tạo Cosmos DB account, bạn có thể enable Availability Zones để đạt redundancy intra-region (RA-GZRS hoặc tương tự), đảm bảo zero-downtime trong region.

✅ Đáp án đúng: Availability Zones

Lý do lựa chọn:
Availability Zones là tính năng cốt lõi của Azure, cung cấp sự dư thừa vật lý bên trong một region bằng cách phân phối replicas dữ liệu qua 3+ AZs độc lập (mỗi AZ có data center riêng, cách nhau 3-10km). Khi provision Cosmos DB, enable AZs sẽ tự động replicate dữ liệu synchronously trong region, chống lại sự cố AZ-specific (như mất điện). SLA tăng lên 99.99% với AZs.
🛠️ Cách áp dụng: Trong Azure Portal > Create Cosmos DB > chọn "Enable Availability Zones" trong tab Networking hoặc Replication.
📘 Nguồn: Microsoft Docs - High availability for Azure Cosmos DB & Availability Zones overview (cập nhật 2025).

📋 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 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 dựa trên kiến thức Azure Cosmos DB mới nhất:

• multi-master replication ❌
  Sai vì: Đây là tính năng cho multi-region replication (nhiều region toàn cầu), cho phép ghi dữ liệu từ nhiều region (active-active). Nó cung cấp redundancy giữa các region, không phải trong một region. Multi-master chỉ hoạt động khi account có multi-region writes enabled, không phải intra-region redundancy cơ bản.

• Availability Zones ✅
  Đúng vì: Như đã giải thích ở trên, AZs đảm bảo redundancy vật lý trong region bằng cách replicate qua các zone riêng biệt. Đây là lựa chọn mặc định cho high availability intra-region khi provision account, chống single-zone failure mà không cần multi-region.

• the strong consistency level ❌
  Sai vì: Strong consistency là mô hình nhất quán dữ liệu (R=1, đọc từ leader replica), đảm bảo dữ liệu luôn mới nhất nhưng không cung cấp redundancy. Nó chỉ ảnh hưởng đến độ trễ và hành vi đọc/ghi, không liên quan đến phân phối replicas vật lý trong region. Cosmos DB hỗ trợ 5 consistency levels, nhưng chúng độc lập với AZs.

• automatic failover ❌
  Sai vì: Automatic failover là cơ chế chuyển vùng tự động giữa các region (cho multi-region accounts), với thời gian <60s. Nó dùng cho disaster recovery giữa regions, không phải redundancy trong một region. Chỉ áp dụng khi có writable regions >1, và không thay thế AZs cho intra-region protection.

🛠️ Lời khuyên thực hành: Khi provision Cosmos DB, luôn chọn "Zone-redundant" storage để enable AZs tự động. Kiểm tra metrics qua Azure Monitor để xác nhận replica distribution!
📘 Tài liệu tham khảo thêm:

• Cosmos DB consistency models (2026 update).
• Provision Cosmos DB account (best practices 2025).

🧩 Phân tích câu hỏi trắc nghiệm: Lợi ích của Azure Cosmos DB Table API so với Azure Table Storage

📘 Giải thích nội dung câu hỏi:
Câu hỏi yêu cầu xác định lợi ích nổi bật của Azure Cosmos DB Table API khi so sánh với Azure Table Storage. Đây là hai dịch vụ lưu trữ dữ liệu NoSQL dạng bảng (table storage) trong hệ sinh thái Azure.

• Azure Table Storage: Là dịch vụ lưu trữ đơn giản, chi phí thấp, hỗ trợ lưu trữ dữ liệu semi-structured với mô hình key-value/table cơ bản. Nó chỉ hỗ trợ single-region (một vùng duy nhất) và geo-redundant storage (GRS) để sao lưu, nhưng không hỗ trợ ghi dữ liệu đa vùng tự động.
• Azure Cosmos DB Table API: Là API tương thích ngược với Azure Table Storage (có thể migrate dễ dàng), nhưng kế thừa đầy đủ tính năng cao cấp của Cosmos DB như global distribution, low latency, SLA 99.999%, và đặc biệt là multi-master replication (ghi dữ liệu đồng thời ở nhiều vùng).
  Câu hỏi tập trung vào lợi ích vượt trội (benefit) của Cosmos DB Table API, dựa trên kiến thức cập nhật đến năm 2026 (Azure Cosmos DB phiên bản mới nhất hỗ trợ multi-region writes, conflict resolution tự động, và Table API v2 với cải tiến scalability).

✅ Đáp án đúng: supports a multi-master model
Lý do lựa chọn: Azure Cosmos DB Table API hỗ trợ multi-master model (mô hình chủ đa vùng), cho phép ghi dữ liệu đồng thời ở nhiều vùng Azure với conflict resolution tự động (sử dụng vector timestamps hoặc custom logic). Điều này mang lại high availability toàn cầu và zero-downtime khi mở rộng, trong khi Azure Table Storage chỉ hỗ trợ single-master (ghi chính ở một vùng chính, sao chép read-only sang vùng phụ). Đây là lợi ích cốt lõi giúp Cosmos DB vượt trội cho ứng dụng phân tán toàn cầu. (Cập nhật 2026: Cosmos DB hỗ trợ multi-region writes mặc định cho Table API với SLA cao hơn).

🔍 Giải thích chi tiết từng phương án (dựa trên so sánh trực tiếp):

• ❌ provides resiliency if an Azure region fails
  Phân tích sai: Cả hai dịch vụ đều cung cấp resiliency (khả năng phục hồi) khi vùng Azure thất bại. Azure Table Storage hỗ trợ Locally Redundant Storage (LRS), Zone-Redundant Storage (ZRS), và Geo-Redundant Storage (GRS/RA-GRS) với automatic failover. Cosmos DB Table API cũng có resiliency tương tự nhưng tốt hơn nhờ multi-region active-active. Tuy nhiên, đây không phải lợi ích độc quyền của Cosmos DB Table API, vì Table Storage đã có sẵn resiliency cơ bản.

• ❌ supports partitioning
  Phân tích sai: Cả hai đều hỗ trợ partitioning (phân vùng dữ liệu) một cách tự động dựa trên PartitionKey. Azure Table Storage sử dụng partition key + row key để scale horizontally. Cosmos DB Table API kế thừa hoàn toàn mô hình này (tương thích 100%), nên không phải lợi ích khác biệt. Partitioning ở Cosmos DB chỉ linh hoạt hơn với custom partitioning ở các API khác, nhưng không phải điểm nổi bật so sánh.

• ❌ provides a higher storage capacity
  Phân tích sai: Azure Table Storage cung cấp storage capacity gần như không giới hạn (hàng PB, chỉ giới hạn bởi account limits). Cosmos DB Table API có giới hạn per container (20 GiB cho serverless, lên đến 100s TB với provisioned throughput, nhưng yêu cầu chia nhỏ containers). Do đó, Table Storage thực tế có capacity cao hơn và rẻ hơn cho workload lớn đơn giản, không phải lợi ích của Cosmos DB.

• ✅ supports a multi-master model
  Phân tích đúng: Như đã giải thích, đây là lợi ích cốt lõi. Cosmos DB Table API cho phép multi-master replication (active-active writes đa vùng), hỗ trợ low-latency global access (<10ms worldwide) và automatic conflict resolution. Table Storage thiếu tính năng này, chỉ hỗ trợ read replication. (Cập nhật 2026: Cosmos DB hỗ trợ multi-master với vector clocks và session consistency mặc định cho Table API).

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

• Microsoft Docs: Azure Cosmos DB Table API vs. Azure Table Storage (cập nhật 2025-2026).
• Cosmos DB Global Distribution – Chi tiết multi-master.
• Azure Table Storage Limits – So sánh capacity/resiliency.

🛠️ Lời khuyên học tập: Hãy thực hành migrate Table Storage sang Cosmos DB qua Azure Portal để trải nghiệm multi-master! Nếu cần thêm ví dụ code, hãy 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 thiết kế một database để hiển thị cách thay đổi lưu lượng mạng (network traffic) ở một khu vực của mạng ảnh hưởng đến các khu vực khác. Đây là tình huống điển hình cần mô hình hóa mối quan hệ phức tạp giữa các nút (nodes) đại diện cho các khu vực mạng và các cạnh (edges) đại diện cho luồng traffic hoặc ảnh hưởng giữa chúng.
📘 Mục tiêu chính: Xác định loại data store phù hợp nhất trong AWS để xử lý dữ liệu có cấu trúc graph-like (dạng đồ thị), nơi các mối quan hệ là yếu tố cốt lõi, không chỉ dữ liệu độc lập.
🛠️ Ngữ cảnh AWS: AWS cung cấp các dịch vụ như Amazon Neptune (graph database) để xử lý các kịch bản mạng, phân tích dependency, và recommendation systems (cập nhật đến 2026 với hỗ trợ Gremlin, SPARQL, và tích hợp IAM mới nhất).

✅ Đáp án đúng: graph

Lý do lựa chọn:
Graph database là lựa chọn tối ưu vì nó được thiết kế chuyên biệt để lưu trữ và truy vấn mối quan hệ (relationships) giữa các thực thể. Trong trường hợp này:

• Các khu vực mạng là nodes (nút).
• Ảnh hưởng của traffic là edges (cạnh) với thuộc tính như cường độ, hướng, thời gian.
• Truy vấn graph (như shortest path, PageRank) giúp phân tích tác động lan tỏa nhanh chóng, hiệu suất cao hơn so với các loại khác (O(1) cho traversal).
  🛠️ Ví dụ AWS: Sử dụng Amazon Neptune để mô hình hóa network topology, hỗ trợ cả Property Graph và RDF (phiên bản mới nhất 2026 tích hợp Neptune Analytics cho fast querying).
  📘 Nguồn tham khảo: AWS Neptune Documentation & Graph Use Cases.

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

• graph
  ✅ Đúng: Như giải thích trên, graph lý tưởng cho dữ liệu có mối quan hệ phức tạp như network traffic propagation. AWS Neptune xử lý hàng triệu nodes/edges với độ trễ thấp, phù hợp cho real-time analysis (cập nhật 2026: hỗ trợ serverless Neptune).

• key/value
  ❌ Sai: Key-value stores (như Amazon DynamoDB) chỉ lưu trữ dữ liệu đơn giản dưới dạng cặp key-value, không hỗ trợ truy vấn mối quan hệ phức tạp. Không thể hiệu quả mô hình hóa "ảnh hưởng giữa các khu vực" mà không cần join thủ công tốn kém.

• document
  ❌ Sai: Document stores (như Amazon DocumentDB với MongoDB compatibility) lưu trữ dữ liệu dạng JSON/BSON linh hoạt, phù hợp cho hierarchical data. Tuy nhiên, thiếu native support cho relationships traversal, dẫn đến query chậm khi phân tích network dependencies.

• columnar
  ❌ Sai: Columnar stores (như Amazon Redshift) tối ưu cho analytical queries trên dữ liệu lớn với compression cao, phù hợp OLAP. Không thiết kế cho graph traversal hoặc real-time relationship queries, gây overhead lớn cho network impact analysis.