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

🧩 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 mô tả tình huống bạn có một tài nguyên Azure Data Factory (ADF) phiên bản 2 (V2) tên là Df1, trong đó chứa một linked service (dịch vụ liên kết). Bạn cũng có một Azure Key Vault tên vault1 chứa encryption key tên key1. Mục tiêu là mã hóa Df1 bằng key1 (sử dụng Customer-Managed Key - CMK từ Key Vault). Câu hỏi yêu cầu xác định bước đầu tiên cần thực hiện để đạt được điều này.

🛠️ Bối cảnh kỹ thuật: Trong Azure Data Factory, để kích hoạt mã hóa dữ liệu bằng CMK từ Key Vault, ADF yêu cầu một số điều kiện tiên quyết nghiêm ngặt. Linked service thường chứa thông tin nhạy cảm như credentials, và chúng phải được loại bỏ trước khi enable CMK để tránh xung đột và đảm bảo tính toàn vẹn dữ liệu. Đây là quy trình chuẩn theo tài liệu Azure mới nhất (cập nhật đến 2026, không có thay đổi lớn ở phiên bản ADF V2).

✅ Đáp án đúng: Remove the linked service from Df1.

Lý do lựa chọn:
Đây là bước đầu tiên bắt buộc theo hướng dẫn chính thức của Microsoft. Khi enable CMK encryption cho ADF, hệ thống sẽ yêu cầu xóa toàn bộ linked services hiện có trong Data Factory vì chúng có thể chứa metadata hoặc credentials xung đột với cơ chế mã hóa mới. Sau khi xóa, bạn có thể recreate linked services và cấp quyền truy cập Key Vault cho Managed Identity của ADF. Nếu không xóa trước, quá trình enable CMK sẽ thất bại.

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

• Encrypt data in Azure Data Factory with customer-managed keys (Microsoft Docs, cập nhật 2024-2026).
• Phần "Prerequisites": "Before you enable CMK encryption, remove all linked services from your data factory."

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

• ❌ Add a private endpoint connection to vault1.
  Phương án này sai vì private endpoint chỉ dùng để secure network access đến Key Vault qua Private Link (tăng bảo mật, tránh public endpoint). Đây không phải bước đầu tiên cho việc mã hóa ADF; nó chỉ là tùy chọn sau khi enable CMK và cần truy cập KV an toàn. Nếu làm trước, vẫn không thể enable CMK nếu linked service chưa xóa.

• ❌ Enable Azure role-based access control on vault1.
  Phương án này sai vì Key Vault mặc định dùng access policies, và enable RBAC là để chuyển sang mô hình Azure RBAC (hỗ trợ từ 2021). Tuy ADF hỗ trợ RBAC cho KV access, nhưng không bắt buộc làm trước khi xóa linked service. Bước này chỉ cần sau, khi cấp role như "Key Vault Crypto Officer" cho ADF's managed identity.

• ✅ Remove the linked service from Df1.
  Đúng như giải thích ở trên. Đây là prerequisite đầu tiên và duy nhất được docs nhấn mạnh: xóa linked service để tránh lỗi khi enable CMK. Sau đó, proceed với các bước như grant Key Vault permissions cho ADF.

• ❌ Create a self-hosted integration runtime.
  Phương án này sai vì self-hosted IR dùng cho on-premises data integration hoặc hybrid scenarios, không liên quan đến mã hóa ADF instance. Mã hóa CMK áp dụng cho toàn bộ ADF metadata và storage, không yêu cầu IR mới. ADF dùng AutoResolveIntegrationRuntime mặc định cho cloud activities.

💡 Lưu ý cuối: Quy trình đầy đủ sau bước đầu: Xóa linked service → Assign Key Vault permissions → Enable CMK trên ADF properties. Test kỹ để tránh downtime! Nếu cần code ARM template hoặc PowerShell, liên hệ thêm nhé! 🚀

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

Câu hỏi tập trung vào việc thiết kế một Azure Databricks interactive cluster (cluster tương tác trên Azure Databricks) được sử dụng không thường xuyên (infrequently) và được cấu hình tự động terminate (auto-termination).
Mục tiêu chính là đảm bảo cấu hình cluster được lưu trữ vĩnh viễn (retained indefinitely) sau khi cluster bị terminate, đồng thời giảm thiểu chi phí tối đa (minimize costs).
🛠️ Vấn đề cốt lõi: Khi cluster terminate tự động (do idle), cấu hình mặc định có thể bị xóa hoặc không lưu lâu dài, dẫn đến phải tạo lại từ đầu lần sau – tốn thời gian và công sức. Giải pháp cần giữ nguyên cấu hình mà không chạy cluster liên tục (để tiết kiệm tiền).

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

Đáp án đúng: Pin the cluster.
🧩 Lý do: Trong Azure Databricks, tính năng Pin cluster cho phép "ghim" (pin) cluster, giữ nguyên toàn bộ cấu hình (như instance type, node number, libraries, tags, v.v.) vĩnh viễn sau khi terminate. Cluster pinned không bị xóa tự động và có thể restart nhanh chóng mà không tốn chi phí chạy (chỉ tính phí khi active). Điều này lý tưởng cho cluster dùng ít, auto-terminate, và tối ưu chi phí nhất vì không cần tài nguyên chạy nền.
📘 Nguồn tham khảo: Tài liệu chính thức Azure Databricks (cập nhật 2024-2026): Databricks Cluster Management và Azure Databricks Pricing.

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

• Pin the cluster.
  ✅ Đúng: Như đã giải thích ở trên, đây là cách chính thức và hiệu quả nhất để lưu cấu hình indefinitely mà không tốn chi phí (cluster pinned chỉ lưu metadata, không chạy). Phù hợp hoàn hảo với yêu cầu auto-termination và infrequent use.

• Create an Azure runbook that starts the cluster every 90 days.
  ❌ Sai: Azure Runbook (Automation) chỉ dùng để tự động start cluster định kỳ, nhưng không giữ cấu hình vĩnh viễn sau terminate (cấu hình có thể mất nếu không pin). Hơn nữa, start mỗi 90 ngày sẽ tăng chi phí (tính phí compute ngay cả khi chỉ start ngắn), vi phạm yêu cầu minimize costs. Không giải quyết gốc rễ vấn đề retain config.

• Terminate the cluster manually when processing completes.
  ❌ Sai: Terminate thủ công chỉ kiểm soát thời gian tắt, nhưng không đảm bảo retain config indefinitely (cấu hình vẫn có thể bị xóa theo policy mặc định). Cluster vẫn auto-terminate nếu idle, và cách này không tự động hóa, không giảm chi phí so với auto-terminate, thậm chí còn tốn công quản lý thủ công.

• Clone the cluster after it is terminated.
  ❌ Sai: Không thể clone cluster sau khi đã terminate (Databricks yêu cầu cluster phải tồn tại để clone). Ngay cả nếu clone trước, bạn phải lưu clone thủ công và tạo mới mỗi lần, không indefinite và tốn thời gian/nhân công. Không minimize costs vì phải quản lý nhiều cluster clone.

🛠️ Kết luận: "Pin the cluster" là giải pháp chuẩn theo best practices Azure Databricks (Unity Catalog era 2024+), giúp scale linh hoạt mà tiết kiệm. Nếu triển khai, truy cập Databricks workspace > Clusters > Pin icon! 🚀

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

Câu hỏi tập trung vào việc thiết kế một dedicated SQL pool trong Azure Synapse Analytics.
Mục tiêu chính là đảm bảo có thể audit (kiểm toán, ghi log truy cập) đối với Personally Identifiable Information (PII - thông tin cá nhân có thể nhận dạng).
✅ Dedicated SQL pool là một dịch vụ phân tích dữ liệu lớn trong Azure Synapse, hỗ trợ lưu trữ và xử lý dữ liệu SQL theo mô hình phân tán (MPP - Massively Parallel Processing).
🛠️ Để audit truy cập PII, giải pháp cần phân loại dữ liệu nhạy cảm và tích hợp với cơ chế audit của Azure, giúp theo dõi ai truy cập dữ liệu nào, khi nào, từ đâu.
📘 Đây là tính năng bảo mật dữ liệu theo chuẩn Microsoft, cập nhật đến năm 2026 (Azure Synapse Analytics v2024.x, tích hợp Microsoft Purview cho sensitivity labels).

✅ Đáp án đúng: sensitivity classifications

Lý do lựa chọn:
Sensitivity classifications (phân loại độ nhạy cảm) cho phép gán nhãn (label) cho các cột dữ liệu chứa PII như SSN, email, số điện thoại (ví dụ: "PII", "Highly Sensitive").
Sau khi classify, Azure Synapse tự động tích hợp với Advanced Threat Protection (ATP) và auditing logs để ghi lại mọi truy cập vào dữ liệu nhạy cảm.
🛡️ Logs được lưu trong Azure Monitor/Log Analytics hoặc Microsoft Purview, hỗ trợ query và báo cáo.
Đây là giải pháp chính xác và trực tiếp cho yêu cầu audit PII, không chỉ masking mà còn tracking.
Nguồn tham khảo:

• Microsoft Docs: Data discovery & classification in Azure Synapse (cập nhật 2024).
• Azure SQL Auditing for sensitivity labels.

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

• column-level security:
  ❌ Sai, vì không tồn tại tính năng "column-level security" chuẩn trong Azure Synapse dedicated SQL pool. Đây có thể nhầm với Always Encrypted (mã hóa cột), nhưng nó chỉ bảo vệ dữ liệu tại rest/in-transit, không hỗ trợ audit truy cập PII. Không có cơ chế log truy cập theo cột cụ thể.

• dynamic data masking:
  ❌ Sai, Dynamic Data Masking (DDM) chỉ che giấu (mask) dữ liệu nhạy cảm khi query (ví dụ: hiển thị **** thay vì số thật), dựa trên quyền user. Nó không audit truy cập, mà chỉ obfuscate dữ liệu runtime. Không phù hợp cho logging PII access.

• row-level security (RLS):
  ❌ Sai, Row-Level Security (RLS) lọc hàng dữ liệu dựa trên predicate functions (ví dụ: user chỉ thấy row của mình). Nó bảo vệ dữ liệu theo hàng, nhưng không classify PII hay audit truy cập. RLS tập trung vào authorization, không phải auditing.

• sensitivity classifications:
  ✅ Đúng (như đã giải thích ở trên). Đây là lựa chọn duy nhất hỗ trợ audit trực tiếp truy cập PII qua classification labels và integration với Azure auditing.

🛡️ Lưu ý cuối: Trong thực tế triển khai Azure Synapse (2026), kết hợp sensitivity classifications với Microsoft Purview để governance toàn diện dữ liệu PII!

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

Câu hỏi mô tả một giải pháp dữ liệu trên Azure Synapse Analytics với kho dữ liệu doanh nghiệp tên DW1.

• Nhiều người dùng chạy ad hoc queries (các truy vấn ngẫu hứng, không theo lịch) đồng thời trên DW1.
• Đồng thời, hệ thống thường xuyên thực hiện automated data loads (tải dữ liệu tự động) vào DW1.
• Vấn đề cần giải quyết: Đảm bảo các tải dữ liệu tự động có đủ bộ nhớ (memory) để hoàn thành nhanh chóng và thành công, ngay cả khi các ad hoc queries đang chạy song song.

📘 Bối cảnh kỹ thuật (dựa trên Azure Synapse Analytics dedicated SQL pools, cập nhật đến 2026):
Synapse Analytics phân bổ tài nguyên (CPU, memory) cho các truy vấn dựa trên resource classes (lớp tài nguyên như smallrc, medrc, largerc, xlargerc). Khi nhiều truy vấn chạy đồng thời, chúng cạnh tranh tài nguyên. Ad hoc queries có thể chiếm hết memory, làm chậm hoặc fail các data loads. Giải pháp cần ưu tiên memory cho data loads mà không ảnh hưởng lớn đến ad hoc queries.

🛠️ Mục tiêu: Tối ưu hóa phân bổ memory cho data loads để tránh concurrency issues (vấn đề đồng thời).

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

Đáp án đúng: Assign a larger resource class to the automated data load queries.

Lý do:

• Trong Azure Synapse Analytics, resource class lớn hơn (ví dụ: largerc hoặc xlargerc) cấp phát nhiều memory và CPU hơn cho truy vấn cụ thể.
• Data loads thường cần memory lớn để xử lý bulk insert nhanh (ví dụ: PolyBase hoặc COPY INTO). Assign largerc cho data loads đảm bảo chúng có đủ tài nguyên để hoàn thành ngay cả khi ad hoc queries (thường dùng smallrc/medrc) đang chạy, tránh timeout hoặc failure.
• Đây là best practice từ Microsoft để prioritize workload (ưu tiên tải dữ liệu). Không ảnh hưởng toàn cục, chỉ apply cho queries cụ thể qua SET SESSION LEVEL RESOURCE GOVERNOR.
  ✅ Hiệu quả cao: Giảm thời gian load từ hàng giờ xuống phút, tăng throughput.

❌ Phân tích tất cả các phương án (đúng/sai)

• Hash distribute the large fact tables in DW1 before performing the automated data loads.
  ❌ Sai: Hash distribution giúp tối ưu skew và joins trong queries, nhưng không trực tiếp cấp thêm memory cho data loads. Thay đổi distribution yêu cầu rebuild table (downtime lớn), và chỉ cải thiện performance sau load, không giải quyết concurrency memory ngay lập tức. Không phù hợp với yêu cầu "enough memory available to complete quickly".

• Assign a smaller resource class to the automated data load queries.
  ❌ Sai: Resource class nhỏ hơn (smallrc) cấp ít memory hơn, làm data loads chậm hơn hoặc fail do thiếu tài nguyên khi ad hoc queries chiếm hết. Điều này ngược hoàn toàn với nhu cầu "complete quickly and successfully".

• Assign a larger resource class to the automated data load queries.
  ✅ Đúng (như đã giải thích ở trên): Trực tiếp cấp thêm memory cho data loads, đảm bảo ưu tiên trong môi trường concurrent.

• Create sampled statistics for every column in each table of DW1.
  ❌ Sai: Sampled statistics cải thiện query optimizer (cardinality estimation), giúp ad hoc queries nhanh hơn, nhưng không tăng memory allocation. Data loads ít phụ thuộc statistics (chủ yếu bulk ops), và tạo stats cho mọi cột tốn thời gian rebuild, không giải quyết vấn đề memory shortage.

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

• Microsoft Docs: Resource classes in Synapse Analytics – Giải thích chi tiết largerc/xlargerc cho workloads nặng như loads.
• Synapse Workload Management – Best practices cho concurrency và memory isolation (Gen2 pools).
• PolyBase/CTAS Performance Tuning – Khuyến nghị resource classes lớn cho data loading.

🧩 Kết luận: Sử dụng larger resource class là cách đơn giản, hiệu quả nhất để prioritize memory cho data loads trong Synapse! 🚀

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

Câu hỏi yêu cầu thiết kế một giải pháp lưu trữ dữ liệu (data retention) cho dữ liệu từ Twitter feed (dữ liệu dòng tweet), nhằm đáp ứng yêu cầu phân tích cảm xúc khách hàng (customer sentiment analytics). Cụ thể, cần chọn chức năng của Azure Storage phù hợp để quản lý việc giữ dữ liệu trong thời gian nhất định, tránh lưu trữ vô thời hạn gây tốn kém, đồng thời đảm bảo dữ liệu có sẵn cho phân tích.
📘 Bối cảnh: Twitter feed là dữ liệu lớn, thời gian thực, thường cần retention policy để tự động xóa hoặc chuyển tier (như từ Hot sang Archive) sau một khoảng thời gian, giúp tối ưu chi phí và tuân thủ quy định dữ liệu. Kiến thức dựa trên Azure Blob Storage phiên bản mới nhất (cập nhật đến 2026, hỗ trợ quy tắc lifecycle linh hoạt hơn với điều kiện lọc metadata và tags).

✅ Đáp án đúng: lifecycle management

Lý do lựa chọn:
Lifecycle management là chức năng cốt lõi của Azure Blob Storage dùng để quản lý vòng đời dữ liệu tự động, cho phép thiết lập quy tắc (rules) dựa trên tuổi dữ liệu (age), loại blob (block/append/page), hoặc tags để:

• Chuyển blob từ tier Hot/Cool sang Archive sau thời gian retention nhất định (ví dụ: giữ Hot 30 ngày cho analytics, sau đó Archive).
• Xóa tự động blob hết hạn retention (ví dụ: xóa sau 90 ngày để tránh tích tụ dữ liệu Twitter cũ không cần thiết).
  Điều này hoàn hảo cho sentiment analytics vì dữ liệu mới nhất cần truy cập nhanh (Hot tier), dữ liệu cũ chỉ lưu trữ rẻ tiền hoặc xóa. Không cần can thiệp thủ công, tiết kiệm chi phí lên đến 90% so với lưu trữ Hot lâu dài.
  🛠️ Ví dụ quy tắc: Nếu blob > 30 ngày → TierToCool; > 90 ngày → Delete.
  📘 Nguồn: Azure Storage lifecycle management overview (cập nhật 2024-2026, hỗ trợ advanced filtering).

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

• change feed ❌
  Sai vì: Change feed chỉ ghi lại và lưu trữ các thay đổi (thêm/sửa/xóa) trên dữ liệu trong container Blob theo thứ tự thời gian, dùng cho auditing, replication hoặc ETL (như đồng bộ dữ liệu Twitter sang analytics pipeline). Nó không quản lý retention (giữ/xóa dữ liệu), mà chỉ theo dõi thay đổi – không đáp ứng yêu cầu xóa hoặc archive dữ liệu cũ cho sentiment analytics.

• soft delete ❌
  Sai vì: Soft delete bảo vệ dữ liệu khỏi xóa nhầm bằng cách giữ phiên bản "mềm" (soft-deleted) trong thời gian retention (7-365 ngày), có thể khôi phục. Tuy hữu ích chống mất dữ liệu Twitter quan trọng, nhưng không tự động quản lý retention dài hạn (như xóa hàng loạt sau 90 ngày) và không tối ưu chi phí tiering cho analytics lớn.

• time-based retention ❌
  Sai vì: Time-based retention (hay Blob immutability retention policy) dùng cho lưu trữ bất biến (immutable) chống sửa/xóa trong thời gian cố định (legal hold hoặc governance mode), phù hợp quy định pháp lý nghiêm ngặt. Tuy nhiên, nó không linh hoạt cho analytics (dữ liệu Twitter cần tiering/xóa tự động dựa trên tuổi, không phải khóa vĩnh viễn), và chỉ áp dụng cho versioning/immutability, không phải quản lý vòng đời toàn diện.

• lifecycle management ✅
  (Đã giải thích chi tiết ở trên – đây là lựa chọn tối ưu nhất cho data retention tự động, chi phí thấp).

🧩 Kết luận: Lifecycle management là giải pháp chuẩn cho Azure Data Engineer khi xử lý dữ liệu lớn như Twitter feed, đảm bảo hiệu suất analytics và tuân thủ retention. Nếu triển khai, kết hợp với Azure Data Factory để ingest dữ liệu! 📘

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

Câu hỏi gốc (bằng tiếng Anh để giữ tính chính xác):
"You have a SQL pool in Azure Synapse. You discover that some queries fail or take a long time to complete. You need to monitor for transactions that have rolled back. Which dynamic management view should you query?"

Giải thích rõ ràng bằng tiếng Việt:
🔍 Tình huống: Bạn đang quản lý một SQL pool (hay còn gọi là Dedicated SQL pool) trong Azure Synapse Analytics. Một số truy vấn thất bại hoặc chạy rất lâu, và bạn cần giám sát các giao dịch (transactions) đã bị rollback (hủy bỏ). Rollback xảy ra khi giao dịch gặp lỗi, timeout hoặc bị hủy thủ công, dẫn đến mất dữ liệu thay đổi và có thể gây chậm hệ thống.
🛠️ Yêu cầu chính: Xác định Dynamic Management View (DMV) phù hợp để query nhằm theo dõi các transactions đã rollback. DMV trong Azure Synapse giúp giám sát hiệu suất ở cấp độ PolyBase Data Warehouse (PDW), đặc biệt với kiến trúc phân tán (nodes).
📈 Mục tiêu: Phát hiện transactions rollback để phân tích nguyên nhân (như deadlock, resource contention) và tối ưu hóa, dựa trên phiên bản Azure Synapse mới nhất (cập nhật đến 2026, hỗ trợ Gen2 pools với improved monitoring).

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

Đáp án đúng: sys.dm_pdw_nodes_tran_database_transactions

Lý do chi tiết (bằng tiếng Việt):
✅ DMV này cung cấp thông tin chi tiết về các transactions đang hoạt động hoặc đã kết thúc trên từng node trong SQL pool, bao gồm trạng thái rollback. Nó có các cột quan trọng như transaction_state (giá trị 'R' cho rolled back), transaction_begin_time, transaction_end_time, và database_id.
🧩 Tại sao phù hợp? Để monitor rollback cụ thể, bạn query DMV này để lọc transactions có transaction_state = 'R', giúp xác định thời gian rollback, database liên quan và node nào gây vấn đề. Đây là cách chính thức từ Microsoft để troubleshoot long-running queries và failures do rollback (theo docs Synapse 2024-2026). Không DMV nào khác cung cấp dữ liệu transaction-level chi tiết như vậy.

📋 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 nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm giải thích đầy đủ bằng tiếng Việt:

• sys.dm_pdw_request_steps ❌ [SAI]
  🛑 Lý do sai: DMV này chỉ hiển thị các bước chi tiết (steps) của một request đang chạy hoặc đã hoàn thành, như execute time của từng step trong query plan. Nó không theo dõi transactions hay trạng thái rollback, mà tập trung vào phân tích execution steps để debug query performance. Không có cột liên quan đến transaction rollback.

• sys.dm_pdw_nodes_tran_database_transactions ✅ [ĐÚNG]
  🟢 Lý do đúng: Như đã giải thích ở trên, đây là DMV duy nhất cung cấp dữ liệu transaction-level trên từng node, bao gồm trạng thái rollback ('R' trong transaction_state). Hoàn hảo để monitor transactions rolled back gây chậm queries. Query ví dụ: SELECT * FROM sys.dm_pdw_nodes_tran_database_transactions WHERE transaction_state = 'R';.

• sys.dm_pdw_waits ❌ [SAI]
  🛑 Lý do sai: DMV này theo dõi các loại wait (chờ đợi) như resource waits, lock waits trong requests. Nó hữu ích cho bottleneck analysis nhưng không hiển thị thông tin transactions cụ thể hay rollback. Chỉ có dữ liệu về wait types, không phải transaction lifecycle.

• sys.dm_pdw_exec_sessions ❌ [SAI]
  🛑 Lý do sai: DMV này liệt kê các session đang thực thi (login time, status, CPU usage), giúp monitor user sessions. Tuy nhiên, nó không chi tiết về transactions nội bộ hay rollback, chỉ ở mức session-level tổng quát.

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

• Microsoft Docs chính thức: Monitor database transactions using DMVs (Azure Synapse Analytics) – Chi tiết sys.dm_pdw_nodes_tran_database_transactions cho rollback monitoring (version 2024-2026).
• Synapse Monitoring Guide: Troubleshoot query performance in dedicated SQL pools – Khuyến nghị DMV này cho transactions issues.
• Gen2 SQL Pools Update (2025+): Hỗ trợ enhanced transaction visibility với integration Azure Monitor.

Hy vọng phân tích này giúp bạn nắm vững! Nếu cần query mẫu hoặc demo, hãy hỏi thêm nhé 🚀.

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

Câu hỏi này thuộc chủ đề Azure Data Factory (ADF) – một dịch vụ ETL/ELT trên nền tảng Azure, dùng để xây dựng và quản lý các pipeline dữ liệu.

Tình huống cụ thể:
Bạn có một Azure Data Factory chứa 10 pipelines. Nhiệm vụ là gán nhãn (label) cho từng pipeline dựa trên mục đích chính:

• ingest (thu thập dữ liệu),
• transform (chuyển đổi dữ liệu),
• load (tải dữ liệu).

Các nhãn này phải có thể sử dụng để grouping (nhóm) và filtering (lọc) trong giao diện monitoring (giám sát) của Data Factory.

Mục tiêu: Tìm cách thêm yếu tố nào vào từng pipeline để hỗ trợ tính năng này một cách hiệu quả nhất.

Lưu ý từ kiến thức cập nhật (tính đến 2026): Trong Azure Data Factory phiên bản mới nhất (v2.x với các cải tiến monitoring hub năm 2024-2026), tính năng monitoring experience cho phép lọc và nhóm pipeline runs dựa trên metadata linh hoạt như annotations, giúp quản lý quy mô lớn (hàng nghìn pipelines).

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

• Azure Data Factory Monitoring documentation (cập nhật 2025).
• Pipeline annotations for grouping/filtering.

✅ Đáp án đúng: an annotation

Lý do lựa chọn:
🛠️ Annotation là một cặp key-value metadata được thêm trực tiếp vào pipeline (hoặc activity) trong ADF. Chúng được thiết kế đặc biệt để hỗ trợ grouping và filtering trong monitoring hub của Data Factory.

• Ví dụ: Thêm annotation {"Purpose": "ingest"} cho pipeline ingest → Có thể lọc tất cả pipeline "ingest" trong monitoring view.
• Ưu điểm: Hiển thị trực tiếp trong pipeline runs list, hỗ trợ query/filter động (như theo tag "transform" hoặc "load"). Không ảnh hưởng đến tài nguyên Azure, chỉ là metadata nhẹ.
• Đây là best practice chính thức từ Microsoft cho việc tổ chức pipeline lớn (như 10 pipelines ở đây).

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

• ❌ a resource tag
  Phân tích sai: Resource tag là nhãn gắn trên tài nguyên Azure (như ADF instance) để quản lý chi phí, quyền truy cập (RBAC), hoặc báo cáo billing (Azure Cost Management). Chúng không hiển thị hoặc hỗ trợ grouping/filtering trực tiếp trong monitoring experience của ADF (chỉ dùng cho resource group level). Không phù hợp cho pipeline-specific labeling.

• ❌ a correlation ID
  Phân tích sai: Correlation ID dùng để trace và correlate các pipeline runs liên quan qua các service (như Log Analytics). Nó dành cho debugging/debug log, không phải để label mục đích (ingest/transform/load) hay grouping/filtering trong monitoring UI. Chỉ là ID tạm thời cho run, không persistent cho pipeline metadata.

• ❌ a run group ID
  Phân tích sai: Run group ID dùng để nhóm các pipeline runs cụ thể (ví dụ: batch runs cùng trigger) trong monitoring, giúp theo dõi execution group. Tuy nhiên, nó không attach vào pipeline definition để label mục đích cố định, và không hỗ trợ filtering semantic như "ingest/transform/load". Chỉ hiệu quả cho runtime grouping, không phải design-time labeling.

• ✅ an annotation
  (Đã giải thích chi tiết ở phần đáp án đúng ở trên).

🧩 Tóm tắt insight: Annotation là lựa chọn tối ưu vì tích hợp native với ADF monitoring (từ v2), giúp scale dễ dàng cho >10 pipelines. Nếu triển khai, vào ADF Studio → Pipeline → Properties → Annotations → Add key-value!

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

Câu hỏi tập trung vào Azure Synapse Analytics (một dịch vụ data warehouse mạnh mẽ của Microsoft Azure, trước đây gọi là Azure SQL Data Warehouse). Yêu cầu cụ thể là đảm bảo dữ liệu trong data warehouse được mã hóa tại chỗ nghỉ (encrypted at rest), nghĩa là bảo vệ dữ liệu khi nó được lưu trữ trên đĩa mà không ảnh hưởng đến hoạt động truy vấn.
📌 Mục tiêu chính: Xác định tính năng cần kích hoạt để mã hóa dữ liệu lưu trữ tĩnh, giúp tuân thủ các tiêu chuẩn bảo mật như GDPR hoặc HIPAA. Đây là tính năng cốt lõi trong Azure Synapse, với kiến thức cập nhật đến năm 2026 (phiên bản Azure Synapse Analytics mới nhất hỗ trợ TDE tự động hoặc thủ công qua Azure portal/PowerShell).

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

Đáp án đúng: Transparent Data Encryption (TDE)
🛡️ Lý do: Transparent Data Encryption (TDE) là tính năng chuẩn của Azure Synapse Analytics để mã hóa toàn bộ dữ liệu tại rest (bao gồm dữ liệu người dùng, backup, và tempdb) bằng AES 256-bit. Nó hoạt động "minh bạch" – không yêu cầu thay đổi code ứng dụng, tự động mã hóa database files và log files. Trong Azure Synapse (2026), TDE được enable mặc định cho các workspace mới, nhưng bạn có thể kích hoạt thủ công qua Azure portal (Dedicated SQL pool > Security > Transparent data encryption) hoặc T-SQL (ALTER DATABASE [dwname] SET ENCRYPTION ON;). Điều này trực tiếp đáp ứng yêu cầu "encrypted at rest".

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

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên chức năng thực tế trong Azure Synapse Analytics (cập nhật 2026):

• Advanced Data Security for this database ❌
  Sai: Tính năng này thuộc Azure Defender for SQL (nay là Microsoft Defender for Cloud), chủ yếu dành cho Azure SQL Database/Managed Instance để phát hiện threat và vulnerability assessment. Nó không mã hóa dữ liệu at rest mà tập trung vào bảo mật nâng cao (như auditing, advanced threat protection). Trong Synapse Analytics, nó không áp dụng trực tiếp cho data warehouse và không giải quyết encrypted at rest.

• Transparent Data Security (TDE) ✅
  Đúng: Như đã giải thích ở trên, đây là giải pháp chuẩn cho mã hóa at rest trong Synapse. Nó mã hóa toàn bộ database engine, bảo vệ chống truy cập vật lý vào storage, và tích hợp với Customer-Managed Keys (CMK) qua Azure Key Vault cho kiểm soát cao hơn.

• Secure transfer required ❌
  Sai: Đây là tùy chọn bảo mật kết nối (in-transit), buộc tất cả kết nối phải dùng HTTPS/SSL/TLS (enable qua connection string hoặc firewall rules). Nó không liên quan đến encrypted at rest, chỉ bảo vệ dữ liệu khi truyền tải giữa client và server, không ảnh hưởng đến dữ liệu lưu trữ.

• Dynamic Data Masking ❌
  Sai: Dynamic Data Masking (DDM) là tính năng che giấu dữ liệu động khi query (ví dụ: thay email bằng XXX@XXX.com cho user không đủ quyền). Nó không mã hóa gì cả, chỉ obfuscate dữ liệu hiển thị cho người dùng cuối, không bảo vệ dữ liệu at rest trên storage.

📘 Tài liệu tham khảo

• Official Docs: Transparent data encryption (TDE) in Synapse Analytics (Cập nhật 2025-2026).
• Security Best Practices: Azure Synapse security overview – Xác nhận TDE là default cho at-rest encryption.
• Azure Portal Guide: Tìm "Dedicated SQL pool" > "Security" để enable TDE.

🛡️ Lời khuyên từ Azure Data Engineer: Luôn kết hợp TDE với Column-level encryption hoặc Always Encrypted cho bảo mật toàn diện. Nếu dùng serverless pools, kiểm tra integration với Purview cho governance!

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

✅ Giải thích nội dung câu hỏi:
Câu hỏi mô tả tình huống bạn đang giám sát một Azure Stream Analytics job (công việc xử lý dữ liệu thời gian thực trên Azure). Bạn phát hiện chỉ số Backlogged Input Events (số lượng sự kiện đầu vào bị ùn tắc) đang tăng dần một cách chậm chạp và luôn khác zero (không bao giờ về 0). Điều này cho thấy job không xử lý kịp lượng sự kiện đầu vào, dẫn đến dữ liệu bị tích tụ backlog.
Mục tiêu: Đảm bảo job có thể xử lý tất cả các sự kiện một cách hiệu quả, tránh mất dữ liệu hoặc độ trễ cao. Đây là vấn đề phổ biến trong xử lý stream khi throughput đầu vào vượt quá khả năng xử lý hiện tại của job.
📘 Theo tài liệu Azure Stream Analytics (cập nhật mới nhất đến 2024, không thay đổi lớn đến 2026): Metrics như Backlogged Input Events được theo dõi qua Azure Monitor, và backlog tăng thường do thiếu tài nguyên xử lý (streaming units).

🟢 Đáp án đúng:
Increase the number of streaming units (SUs).
Lý do lựa chọn:
Streaming Units (SUs) là đơn vị tài nguyên chính quyết định throughput và khả năng song song hóa của Stream Analytics job. Mỗi SU cung cấp CPU, memory và I/O cố định (ví dụ: 1 SU xử lý khoảng 1 MB/s tùy workload). Khi backlog tăng chậm và liên tục non-zero, job đang bị quá tải nhẹ → tăng SUs sẽ scale horizontally (tăng instance xử lý song song), giúp tiêu thụ input nhanh hơn, giảm backlog về 0. Đây là giải pháp chuẩn theo best practices của Microsoft.
🛠️ Cách thực hiện: Trong Azure Portal > Stream Analytics Job > Scale > Tăng SUs (tối đa 500 SUs/job).
📘 Nguồn: Azure Stream Analytics Monitoring Documentation và Scaling Guidance (2024).

📋 Giải thích tất cả các phương án (đúng/sai):
Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Tôi đánh dấu ✅ cho đúng, ❌ cho sai, kèm lý do cụ thể bằng tiếng Việt:

• ❌ Change the compatibility level of the Stream Analytics job.
  Phương án này sai vì compatibility level chỉ thay đổi hành vi syntax/query (ví dụ: từ 1.0 sang 1.2 để hỗ trợ tính năng mới như GeoJSON), không ảnh hưởng đến tài nguyên xử lý hoặc throughput. Nó không giải quyết backlog input mà chỉ liên quan đến tương thích code, có thể gây lỗi nếu thay đổi không đúng.

• ✅ Increase the number of streaming units (SUs).
  Như đã giải thích ở trên, đây là đúng vì trực tiếp tăng công suất xử lý stream, giúp job bắt kịp input events. Backlog giảm nhanh chóng sau khi scale (thường trong vài phút).

• ❌ Remove any named consumer groups from the connection and use $default.
  Phương án này sai vì consumer groups (trong Event Hubs/IoT Hub làm input) dùng để chia sẻ partition độc lập, giúp scale consumer. Chuyển về $Default chỉ đơn giản hóa config nhưng không tăng throughput job, thậm chí có thể làm giảm parallelism nếu có nhiều consumer. Backlog vẫn tăng nếu SUs không đủ.

• ❌ Create an additional output stream for the existing input stream.
  Phương án này sai vì thêm output chỉ tăng tải xử lý (job phải fan-out dữ liệu ra nhiều output), làm backlog tăng nhanh hơn thay vì giảm. Vấn đề là input bị ùn tắc, không phải output; scale output không giúp input consumption.

🔍 Lời khuyên bổ sung từ Azure Data Engineer:

• Theo dõi thêm metrics như Input Events, Function Events, Watermark Delay qua Azure Monitor để chẩn đoán sâu.
• Nếu backlog vẫn dai dẳng sau tăng SUs, kiểm tra query optimization (sử dụng PARTITION BY, giảm stateful operators).
• Test scale tự động với Autoscale (preview đến 2024, stable 2026).
  📘 Tài liệu tham khảo chính: Microsoft Docs - Stream Analytics Troubleshooting (2024).
  Hy vọng phân tích này giúp bạn nắm vững! 🚀

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

Câu hỏi tập trung vào việc thiết kế mô hình dữ liệu nhân viên (employee data) trong Azure Synapse Analytics dedicated SQL pool (một phần của Azure Synapse, trước đây gọi là Azure SQL Data Warehouse). Các yêu cầu cụ thể bao gồm:

• 📅 Trả về bản ghi nhân viên từ một thời điểm cụ thể (point in time): Cần hỗ trợ truy vấn lịch sử dữ liệu tại bất kỳ thời điểm nào trong quá khứ.
• 🔄 Duy trì thông tin nhân viên mới nhất (latest employee information): Luôn có bản ghi hiện hành dễ dàng truy xuất.
• 🛠️ Giảm thiểu độ phức tạp của truy vấn (minimizes query complexity): Mô hình phải đơn giản, không yêu cầu JOIN phức tạp hoặc logic lập trình rườm rà.

Đây là vấn đề điển hình trong data warehousing (kho dữ liệu), nơi cần xử lý slowly changing dimensions (SCD) cho dữ liệu thay đổi theo thời gian như thông tin nhân viên (ví dụ: thay đổi bộ phận, lương, địa chỉ). Azure Synapse dedicated SQL pool có một số hạn chế về tính năng so với SQL Server chuẩn, nên cần chọn mô hình phù hợp.

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

Đáp án đúng: as a Type 2 slowly changing dimension (SCD) table

🧠 Lý do chi tiết:

• Type 2 SCD là kỹ thuật chuẩn trong Kimball data warehousing, lưu toàn bộ lịch sử thay đổi bằng cách tạo bản ghi mới mỗi khi dữ liệu thay đổi, kèm theo cột ValidFrom (ngày bắt đầu hiệu lực) và ValidTo (ngày kết thúc hiệu lực, NULL cho bản ghi hiện tại), cùng surrogate key (khóa giả).
• 📅 Point in time: Truy vấn đơn giản WHERE @date BETWEEN ValidFrom AND ValidTo.
• 🔄 Latest info: Truy vấn WHERE ValidTo IS NULL hoặc IsCurrent = 1.
• 🛠️ Query complexity thấp: Chỉ cần filter cơ bản, không JOIN phức tạp, phù hợp với dedicated SQL pool.
• Đây là cách manual implement phổ biến vì Synapse dedicated SQL pool không hỗ trợ temporal tự động, giúp tối ưu performance trong môi trường phân tán lớn.

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

• ❌ as a temporal table
  Phương án này sai vì Azure Synapse Analytics dedicated SQL pool không hỗ trợ temporal tables (system-versioned temporal tables). Temporal table (từ SQL Server 2016) tự động lưu history với FOR SYSTEM_TIME AS OF, rất đơn giản cho point-in-time và latest (period columns SysStartTime/SysEndTime). Tuy nhiên, tính năng này chỉ khả dụng ở Azure SQL Database hoặc Synapse serverless SQL pool, không phải dedicated pool (do hạn chế engine PolyBase và phân tán). Sử dụng sẽ báo lỗi syntax.

• ❌ as a SQL graph table
  Phương án này sai vì SQL graph tables dùng cho mối quan hệ graph (node/edge như social network), không liên quan đến history/point-in-time. Nó hỗ trợ MATCH cho traversal, nhưng không lưu effective dates hay latest info, dẫn đến query phức tạp và không đáp ứng yêu cầu. Synapse dedicated hỗ trợ graph cơ bản, nhưng không phù hợp.

• ❌ as a degenerate dimension table
  Phương án này sai vì degenerate dimension (junk dimension) dùng cho thuộc tính không cần hierarchy như OrderID, TransactionID (lưu trực tiếp trong fact table để tiết kiệm JOIN). Nó không hỗ trợ history hay point-in-time, chỉ lưu giá trị hiện tại, vi phạm yêu cầu latest + history. Query sẽ phức tạp nếu force thêm logic thời gian.

• ✅ as a Type 2 slowly changing dimension (SCD) table
  Như đã giải thích ở trên, đây là lựa chọn đúng hoàn hảo, đáp ứng đầy đủ 3 yêu cầu với query đơn giản, manual nhưng hiệu quả cao trong Synapse dedicated SQL pool.

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

• Azure Synapse docs - Features supported in dedicated SQL pool: Microsoft Learn - Unsupported features (xác nhận temporal tables không hỗ trợ).
• SCD Type 2 best practices: Microsoft Learn - Slowly changing dimensions (hướng dẫn implement SCD2 trong Synapse).
• Kimball Dimensional Modeling: Sách "The Data Warehouse Toolkit" (phương pháp chuẩn cho Type 2 SCD).

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần ví dụ code SQL implement SCD2, hãy cho tôi biết nhé!