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

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

Câu hỏi thuộc kỳ thi Microsoft Azure Data Engineer Associate (DP-203), tập trung vào việc triển khai Azure Synapse Link cho Azure SQL Database.

📋 Tình huống: Bạn có một subscription Azure chứa các tài nguyên sau (dựa trên hình ảnh bảng tài nguyên):

• workspace1: Azure Synapse Analytics workspace (không có mô tả đặc biệt).
• sql1: Azure SQL Database server (không có mô tả đặc biệt).
• SQLDB1 và SQLDB2: Hai Azure SQL Database được host trên server sql1.

🎯 Yêu cầu: Để triển khai Azure Synapse Link (tính năng liên kết đồng bộ dữ liệu liên tục, low-latency từ Azure SQL Database sang Synapse Analytics), bạn cần thực hiện hai hành động nào trên sql1 (Azure SQL Database server). Đây là câu hỏi multiple correct answers (mỗi đáp án đúng worth 1 point).

🛠️ Bối cảnh kỹ thuật (cập nhật đến 2026): Azure Synapse Link hỗ trợ Azure SQL Database Hyperscale hoặc Serverless (General Purpose Serverless), cho phép tạo "linked database" trong Synapse để query dữ liệu OLTP trực tiếp mà không cần ETL. Trên sql1 (logical server), cần cấu hình bảo mật và xác thực để Synapse workspace (workspace1) có thể liên kết và đồng bộ dữ liệu an toàn. Không cần thay đổi trên database cụ thể (SQLDB1/SQLDB2), mà tập trung vào server level.

✅ Đáp án đúng (hai lựa chọn cần thực hiện trên sql1)

Hai hành động chính xác là:

• Update the firewall rules to allow Azure services to access sql1.
  Lý do: Azure Synapse Link yêu cầu server sql1 mở firewall để cho phép các dịch vụ Azure (như Synapse service) truy cập mà không cần IP cụ thể. Nếu không, liên kết sẽ bị chặn. Đây là bước bắt buộc đầu tiên trong tài liệu chính thức. ✅

• Enable the system-assigned managed identity.
  Lý do: System-assigned managed identity trên sql1 (logical server) cung cấp xác thực Microsoft Entra ID (Azure AD) cho Synapse Link. Synapse sử dụng identity này để pull dữ liệu từ SQL DB một cách an toàn, không cần SQL credentials. Bước này kích hoạt Azure AD-only authentication trên server. ✅

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

Dưới đây là giải thích chi tiết từng phương án (giữ nguyên văn bản gốc tiếng Anh), với lý do đúng/sai dựa trên quy trình triển khai Azure Synapse Link mới nhất:

• Update the firewall rules to allow Azure services to access sql1.
✅ Đúng. Như đã giải thích, firewall rule "Allow Azure services and resources to access this server" phải được bật trên sql1 để Synapse workspace1 có thể kết nối từ backend services của Azure. Không bật sẽ báo lỗi kết nối. 🛡️

• Enable the system-assigned managed identity.
✅ Đúng. Managed identity system-assigned trên Azure SQL logical server (sql1) là yêu cầu để enable Microsoft Entra authentication cho Synapse Link. Sau khi enable, bạn set ALTER SERVER SET AZURE_AD_ONLY_AUTHENTICATION = ON nếu cần. Synapse dùng identity này để authenticate và sync dữ liệu. 🔑

• From the Access control (IAM) settings, assign the Contributor role to the system-assigned managed identity of workspace1.
❌ Sai. Hành động này không thực hiện trên sql1, mà trên IAM của workspace1 hoặc Synapse resources. Managed identity của workspace1 không cần Contributor role trên sql1; ngược lại, identity của sql1 dùng để Synapse truy cập DB. Assign role này là thừa và không liên quan đến bước setup trên server. 🚫

• Disable Transparent Data Encryption (TDE).
❌ Sai. TDE (mã hóa dữ liệu tại rest) không ảnh hưởng đến Azure Synapse Link và được khuyến nghị giữ nguyên để bảo mật. Synapse Link hỗ trợ TDE đầy đủ; disable chỉ làm giảm security mà không giải quyết vấn đề liên kết. 🔒

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

• Microsoft Docs chính thức: Azure Synapse Link for Azure SQL Database – Prerequisites: Firewall + System-assigned MI on logical server.
• Quickstart Guide: Create Azure Synapse Link – Xác nhận hai bước trên sql1.
• ExamTopics/DP-203 Reference: Hình ảnh và câu hỏi khớp với scenario thực tế (workspace1 + sql1 hosting SQLDBs).
• Azure Updates 2024-2026: Synapse Link hỗ trợ Serverless preview đầy đủ, nhưng prerequisites không thay đổi.

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

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

Câu hỏi tập trung vào Azure Synapse Analytics dedicated SQL pool (một dịch vụ lưu trữ dữ liệu phân tán dành riêng trong Azure Synapse).
Yêu cầu là xây dựng một pipeline (dòng dữ liệu) để:

• Thực thi một stored procedure (thủ tục lưu trữ) trong dedicated SQL pool.
• Sử dụng kết quả trả về (result set) từ stored procedure đó làm đầu vào (input) cho một hoạt động (activity) tiếp theo trong pipeline.
• Giảm thiểu nỗ lực phát triển (minimize development effort), nghĩa là chọn giải pháp đơn giản, không cần code phức tạp.

Mục tiêu chính là tìm loại activity phù hợp trong pipeline của Azure Synapse (dựa trên Azure Data Factory integration), hỗ trợ thực thi SQL/stored procedure và truyền result set downstream một cách dễ dàng nhất. Kiến thức dựa trên phiên bản Azure Synapse cập nhật đến năm 2026 (Azure Synapse Analytics v2024+ với Data Factory pipelines).

✅ Đáp án đúng: Script

Lý do lựa chọn:
Activity Script (hay Script activity) là lựa chọn tối ưu vì nó cho phép chạy trực tiếp SQL script (bao gồm lệnh EXEC stored procedure) trên dedicated SQL pool, và trả về result set dưới dạng dataset để sử dụng làm input cho activity downstream. Điều này giảm thiểu nỗ lực phát triển vì chỉ cần viết script SQL đơn giản, không cần wrapper code phức tạp. Script activity hỗ trợ output dataset động, phù hợp hoàn hảo với yêu cầu.

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

• U-SQL ❌
  Sai vì: U-SQL là ngôn ngữ query dành cho Azure Data Lake Analytics (không phải dedicated SQL pool). Nó không hỗ trợ thực thi stored procedure trên SQL pool và không trả về result set dễ dàng cho pipeline downstream. Sử dụng U-SQL sẽ yêu cầu phát triển phức tạp hơn, vi phạm yêu cầu minimize effort.

• Stored Procedure ❌
  Sai vì: Stored Procedure activity chỉ thực thi stored procedure trên SQL pool/Data Factory linked service, nhưng không hỗ trợ trả về result set làm dataset input cho downstream activity. Nó chỉ xử lý output parameters (như scalar values), không phù hợp với yêu cầu sử dụng "returned result set". Phải dùng thêm activity khác để lấy dữ liệu, tăng effort phát triển.

• Script ✅
  Đúng vì: Như đã giải thích ở trên, Script activity chạy SQL script (EXEC SP), trả về toàn bộ result set dưới dạng output dataset, dễ dàng chain với activity sau. Hỗ trợ dedicated SQL pool native, zero-code thêm, minimize effort tối đa. Trong Azure Synapse pipelines (2024+), đây là best practice cho SQL execution với output.

• Notebook ❌
  Sai vì: Notebook activity dùng cho Apache Spark (Synapse Spark pools), không chạy trực tiếp trên dedicated SQL pool. Để gọi stored procedure từ notebook cần code PySpark/SQL magic phức tạp, không trả về result set đơn giản cho pipeline downstream, và tăng đáng kể effort phát triển so với Script.

📘 Tài liệu tham khảo

• Azure Synapse Analytics - Script activity documentation (cập nhật 2024-2026).
• Execute stored procedures with output in Synapse Pipelines (so sánh Script vs Stored Procedure).
• Synapse Pipeline activities overview (best practices minimize effort).

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

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

Câu hỏi gốc (dịch và giải thích rõ ràng):
Bạn có một subscription Azure chứa một cơ sở dữ liệu Azure Cosmos DB. Azure Synapse Link đã được triển khai trên cơ sở dữ liệu này. ✅
Bạn cấu hình full fidelity schema cho analytical store (kho lưu trữ phân tích). 🛠️

Sau đó, bạn thực hiện hai hành động chèn dữ liệu vào container:
• Chèn document đầu tiên: {"customerID": 12, "customer": "Tailspin Toys"}
(Lưu ý: customerID là kiểu number/integer - giá trị 12).
• Chèn document thứ hai: {"customerID": "14", "customer": "Contoso"}
(Lưu ý: customerID là kiểu string - giá trị "14").

Câu hỏi yêu cầu: Analytical store sẽ chứa bao nhiêu cột (columns)? 📊

Giải thích ngữ cảnh:
Azure Synapse Link cho Cosmos DB (phiên bản cập nhật mới nhất đến 2026) cho phép đồng bộ dữ liệu từ operational store (container Cosmos DB) sang analytical store một cách tự động, không ảnh hưởng hiệu suất. Với full fidelity schema (tính năng được giới thiệu từ 2021 và cải tiến liên tục), analytical store giữ nguyên schema gốc bao gồm cả kiểu dữ liệu (data types). 🧠

• Khi một trường (field) có nhiều kiểu dữ liệu khác nhau qua các document (ở đây customerID: number ở doc1, string ở doc2), hệ thống sẽ tạo cột riêng biệt cho từng kiểu (ví dụ: customerID_integer và customerID_string).
• Trường customer ở cả hai document đều là string, nên chỉ tạo 1 cột.
  Kết quả: Tổng cộng 3 cột trong analytical store.

✅ Đáp án đúng: 3

Lý do chi tiết:
Với full fidelity schema, analytical store phân tích schema động (schema evolution):

• customer → 1 cột customer_string.
• customerID (number ở doc1) → 1 cột customerID_integer (hoặc tương đương như customerID_number).
• customerID (string ở doc2) → 1 cột customerID_string.
  Tổng: 3 cột. Điều này đảm bảo truy vấn phân tích chính xác kiểu dữ liệu, hỗ trợ Spark/Power BI trong Synapse. 🚀

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

• [SAI] 1
  ❌ Sai vì: Phương án này giả định analytical store chỉ tạo 1 cột duy nhất (như gộp tất cả thành string hoặc bỏ qua kiểu dữ liệu). Nhưng full fidelity schema không làm vậy - nó tôn trọng kiểu dữ liệu gốc, dẫn đến nhiều cột hơn nếu có sự khác biệt kiểu (type divergence). Nếu dùng chế độ mặc định cũ (không full fidelity), có thể chỉ 2 cột, nhưng câu hỏi chỉ rõ full fidelity.

• [SAI] 2
  ❌ Sai vì: Phương án này nghĩ chỉ có 2 trường (customerID và customer), nên 2 cột. Nhưng customerID có 2 kiểu khác nhau (number vs string), nên full fidelity tách thành 2 cột riêng cho customerID, cộng với 1 cột cho customer → tổng 3. Đây là đặc trưng schema evolution mới nhất của Cosmos DB (2023+).

• [ĐÚNG] 3
  ✅ Đúng vì: Như giải thích trên, analytical store tạo:

  1. customer_string (chung cho cả 2 doc).
  2. customerID_integer (cho doc1).
  3. customerID_string (cho doc2).
     Hoàn toàn khớp với hành vi full fidelity schema đến 2026.

• [SAI] 4
  ❌ Sai vì: Phương án này có thể nghĩ mỗi document tạo cột riêng hoặc thêm cột ID ẩn, nhưng analytical store không tạo cột thừa. Chỉ dựa trên fields và types thực tế → chính xác 3 cột, không hơn.

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

• Azure Docs: Azure Synapse Link for Azure Cosmos DB - Full fidelity schema 🖋️ (Mô tả chi tiết schema evolution với type-specific columns).
• Azure Cosmos DB Analytical Store Overview (Xác nhận hành vi với multi-type fields).
• Blog cập nhật 2024: "Enhancements to Cosmos DB Synapse Link" trên Azure Blog (tính năng full fidelity ổn định từ 2023).

Hy vọng phân tích này giúp bạn nắm vững! Nếu cần demo code hoặc query Synapse, 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 tập trung vào Azure Data Factory (ADF), một dịch vụ ETL/ELT mạnh mẽ của Microsoft Azure dùng để xây dựng pipeline dữ liệu. Cụ thể:

• Bạn có một cơ sở dữ liệu Azure SQL Database tên DB1.
• Có một pipeline tên pipeline1 trong ADF.
• Đã cấu hình linked service từ ADF đến DB1 (để kết nối dữ liệu).
• Trong DB1, tạo stored procedure tên SP1, trả về một hàng dữ liệu duy nhất với 4 cột.
• Yêu cầu: Thêm một activity vào pipeline1 để thực thi SP1, và lưu giá trị các cột vào pipeline variables (biến pipeline, dùng để truyền dữ liệu giữa các activity).

📌 Mục tiêu chính: Tìm hai loại activity có thể thực thi SP1 và capture output (giá trị 4 cột) vào variables. Đây là câu hỏi multiple correct answers (mỗi đáp án đúng worth 1 point).

🛠️ Ngữ cảnh cập nhật: Theo tài liệu Microsoft ADF mới nhất (phiên bản 2024-2026, không thay đổi lớn ở các activity này), các activity hỗ trợ execute SQL proc và map output parameters/variables qua output parameters hoặc firstRow mechanisms.

✅ Đáp án đúng: Script và Stored Procedure

Lý do lựa chọn:

• Cả hai activity này đều hỗ trợ thực thi stored procedure trên Azure SQL DB qua linked service.
• Chúng cho phép capture output từ SP1 (single row, 4 columns) và map trực tiếp vào pipeline variables (qua tab Output hoặc Parameters).
• Hoàn hảo cho yêu cầu: Execute SP1 → Lưu columns vào variables để dùng ở activity sau.

Nguồn tham khảo:

• 📘 Microsoft Learn: Stored procedure activity
• 📘 Microsoft Learn: Script activity
• 📘 ADF UI Docs: Pipeline variables mapping (cập nhật 2024).

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

• ✅ Script
  Đúng: Activity Script cho phép chạy script SQL tùy chỉnh (bao gồm EXEC SP1), hỗ trợ multiple SQL statements. Output từ SP1 (single row) có thể capture qua @activity('ScriptName').output.firstRow và map vào pipeline variables. Lý tưởng cho stored proc phức tạp, linh hoạt cao. ✅ Hoàn thành yêu cầu đầy đủ.

• ❌ Copy
  Sai: Activity Copy dùng để copy dữ liệu từ source dataset sang sink dataset (như table-to-table). Không hỗ trợ execute stored procedure trực tiếp, chỉ dùng stored proc cho pre-copy/post-copy scripts (không capture output columns vào variables dễ dàng). Không phù hợp vì SP1 cần execute và lưu output ngay. ❌ Không hoàn thành yêu cầu.

• ❌ Lookup
  Sai: Activity Lookup dùng để query dữ liệu từ dataset (SELECT statement), trả về rows (firstRow cho single row). Không hỗ trợ execute stored procedure (chỉ SQL query thuần). Dù có thể lưu firstRow vào variables, nhưng không gọi được SP1. ❌ Không thực thi SP1.

• ✅ Stored Procedure
  Đúng: Activity Stored Procedure chuyên biệt để thực thi stored proc trên SQL DB. Hỗ trợ input/output parameters và map output columns trực tiếp vào pipeline variables (qua Stored procedure parameters tab). Với SP1 trả single row, dễ dàng capture 4 columns. ✅ Hoàn thành yêu cầu hoàn hảo, đơn giản nhất.

🧮 Tóm tắt: Chỉ Script và Stored Procedure đáp ứng cả execute SP1 lẫn lưu output vào variables. Các activity khác thiếu một phần yêu cầu cốt lõi! 🚀

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

Câu hỏi tập trung vào Azure Data Factory (ADF), cụ thể là cách triển khai version control (quản lý phiên bản) cho các thay đổi trên pipeline artifacts trong một ADF có tên ADF1.

• Tình huống hiện tại: Bạn đang publish trực tiếp tất cả thay đổi authoring (tức là các chỉnh sửa pipeline, dataset, v.v.) lên ADF1 mà không có version control. Điều này có nghĩa là không có lịch sử thay đổi, không rollback được, và rủi ro cao khi collaborate.
• Yêu cầu giải pháp:
  • Triển khai version control để theo dõi và quản lý thay đổi.
  • Đảm bảo áp dụng version control cho các resources hiện có trong Azure Data Factory Studio của ADF1 (không phải tạo mới từ đầu).
• Định dạng: Đây là câu hỏi multi-select (chọn 2 actions đúng), mỗi lựa chọn đúng đáng 1 điểm. Giải pháp phải là hai bước cụ thể để integrate Git repo vào ADF.

Mục tiêu chính: Kết nối ADF với Git (Azure DevOps Git hoặc GitHub) để live mode authoring chuyển sang Git-integrated mode, nơi tất cả thay đổi được lưu vào repo trước khi publish lên data factory thực tế (collaboration branch).

📘 Kiến thức cập nhật: Theo tài liệu Azure Data Factory mới nhất (tính đến 2026, phiên bản ADF Gen2 với Git integration cải tiến), quy trình này không thay đổi cơ bản từ 2021-2025. Xem Azure Docs: Source control in Azure Data Factory và Set up a repository.

✅ Đáp án đúng (hai lựa chọn hoàn chỉnh giải pháp)

• Create a Git repository.
  Lý do: Đây là bước đầu tiên bắt buộc. Bạn cần tạo một Git repo (trên Azure DevOps hoặc GitHub) để lưu trữ các artifacts ADF dưới dạng JSON files. Repo này sẽ sync với ADF Studio, cho phép version control (commit, branch, PR). Không có repo thì không thể integrate.

• From the Azure Data Factory Studio, select Set up code repository.
  Lý do: Sau khi có repo, từ ADF Studio (trong ADF1), chọn Set up code repository để kết nối repo với ADF hiện tại. Lúc này, ADF sẽ tự động migrate (import) tất cả resources hiện có vào repo (adfc.json, pipelines, datasets,...), kích hoạt Git mode. Thay đổi sau sẽ yêu cầu publish từ feature branch sang main trước khi deploy.

Tổng giải pháp: Tạo repo → Set up trong Studio → ADF chuyển sang Git mode, resources cũ được versioned ngay lập tức. 🛠️ Hoàn hảo cho collaboration!

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

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

• ✅ Create a Git repository.
  Bước bắt buộc đầu tiên để có nơi lưu trữ versioned cho artifacts ADF. ADF hỗ trợ Azure DevOps Git (miễn phí cho team nhỏ) hoặc GitHub. Sau khi tạo, bạn configure repo URL, branch (thường là main/master), và quyền truy cập. Không có repo thì không integrate được Git. (Phù hợp yêu cầu migrate resources hiện có).

• ✅ From the Azure Data Factory Studio, select Set up code repository.
  Từ Home page của ADF Studio (trong ADF1), chọn nút này để link repo với ADF instance. ADF sẽ tự import toàn bộ resources hiện tại vào repo dưới dạng ARM templates + JSON, kích hoạt Git integration. Sau đó, authoring ở feature branch, publish chỉ sync lên collaboration branch.

• ❌ From the Azure Data Factory Studio, run Publish All.
  Publish All chỉ dùng để deploy tất cả thay đổi từ draft sang live trong live mode (không Git). Nó không tạo version control, không migrate resources, và không liên quan đến Git setup. Nếu đang ở Git mode, nó sync từ local branch nhưng không giúp implement từ đầu.

• ❌ Create an Azure Data Factory trigger.
  Trigger dùng để tự động chạy pipeline theo lịch/sự kiện (tumbling window, event-based). Hoàn toàn không liên quan đến version control hay Git integration. Đây là tính năng runtime, không phải authoring/source control.

• ❌ Create a GitHub action.
  GitHub Actions là CI/CD workflow trên GitHub repo. Nó không phải bước setup Git cho ADF. Bạn có thể dùng Actions sau để automate deploy (CI/CD pipeline), nhưng không giúp integrate Git với ADF Studio hoặc migrate resources hiện có.

• ❌ From the Azure Data Factory Studio, select Publish.
  Publish (nút đơn lẻ) chỉ deploy thay đổi hiện tại từ draft/live, không tạo repo hay version control. Trong Git mode, nó tạo PR/merge, nhưng ở đây ADF1 chưa có Git nên không áp dụng. Không migrate resources vào Git.

Kết luận: Chỉ hai bước ✅ mới giải quyết đúng vấn đề implement version control cho ADF1 hiện có. Các bước khác hoặc thừa hoặc lạc đề! 🚀 Nếu áp dụng, test ngay trên dev ADF để tránh downtime production.

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

Câu hỏi xoay quanh việc tạo trigger cho pipeline trong Azure Data Factory (ADF), cụ thể là pipeline tên Pipeline1 trong factory ADF1.
Pipeline cần chạy định kỳ mỗi 30 phút với offset 15 phút (ví dụ: chạy lúc 00:15, 00:45, 01:15, 01:45,... thay vì đúng giờ chẵn).
Trigger phải đáp ứng 4 yêu cầu chính:

• Backfill dữ liệu: Có thể chạy lại từ đầu ngày (00:00) đến thời điểm hiện tại để lấp đầy dữ liệu bị thiếu.
• Xử lý thất bại: Nếu pipeline fail, cho phép re-execute trong cùng khoảng thời gian 30 phút đó (không trượt sang window sau).
• Concurrency control: Chỉ cho phép một execution đồng thời (không overlap).
• Tối ưu hóa: Giảm thiểu công sức phát triển và cấu hình (minimize effort).

Mục tiêu là chọn loại trigger phù hợp nhất trong Azure Data Factory (phiên bản cập nhật đến 2026, dựa trên tài liệu Microsoft chính thức).

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

• Azure Data Factory Triggers - Microsoft Learn (cập nhật 2024-2026).
• Tumbling Window Trigger Properties.

✅ Đáp án đúng: tumbling window

Lý do lựa chọn:
Tumbling Window trigger là loại trigger dựa trên cửa sổ thời gian cố định (fixed windows), hoàn hảo cho lịch chạy định kỳ như mỗi 30 phút với offset. Nó hỗ trợ tất cả 4 yêu cầu:

• Backfill tự động từ đầu ngày (sử dụng @Trigger.startTime và @Pipeline().TriggerTime để tính toán).
• Retry trong window: Sử dụng retry và delay để re-run nếu fail, vẫn giữ nguyên window 30 phút (không trượt).
• Concurrency = 1: Thiết lập maxConcurrency = 1 để tránh overlap.
• Minimize effort: Cấu hình đơn giản qua UI/JSON, không cần code phức tạp, tự động hóa backfill/retry.
  Đây là lựa chọn tối ưu nhất theo best practices ADF (không cần custom logic như Schedule trigger).

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

• ❌ schedule
  Schedule trigger chỉ chạy theo lịch cố định (cron expression), hỗ trợ offset cơ bản nhưng KHÔNG hỗ trợ backfill tự động từ đầu ngày (phải manual hoặc custom pipeline). Không có cơ chế window để retry trong 30 phút chính xác, dễ overlap nếu concurrency cao. Cần thêm cấu hình phức tạp để mimic tumbling window → Không minimize effort, không đáp ứng đầy đủ yêu cầu.

• ❌ event-based
  Event-based trigger (như Storage Event) kích hoạt dựa trên sự kiện (file upload, blob change), KHÔNG phù hợp cho lịch chạy định kỳ 30 phút. Không hỗ trợ backfill thời gian, retry window, hoặc concurrency control tự nhiên cho schedule → Hoàn toàn sai với yêu cầu định kỳ và backfill.

• ❌ manual
  Manual trigger chỉ chạy thủ công qua UI/REST API, không tự động mỗi 30 phút. Không backfill, không retry tự động, không concurrency control → Chỉ dùng test/debug, không đáp ứng bất kỳ yêu cầu tự động nào.

• ✅ tumbling window
  (Như đã giải thích ở trên) Đúng hoàn toàn, hỗ trợ đầy đủ backfill (backfill property), retry trong window (retry/delay), concurrency (maxConcurrency=1), và cấu hình đơn giản cho offset 15 phút (frequency: "30:00:00", offset: "00:15:00").

🧩 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 phát triển một giải pháp streaming dữ liệu đến Azure Stream Analytics, nơi có hai loại dữ liệu chính:

• Streaming data (dữ liệu dòng thời gian thực, liên tục, như dữ liệu từ cảm biến hoặc log).
• Reference data (dữ liệu tham chiếu, thường là dữ liệu tĩnh hoặc thay đổi chậm, dùng để join hoặc enrich streaming data, ví dụ: danh sách mã sản phẩm, địa chỉ IP, v.v.).

📌 Mục tiêu câu hỏi: Xác định input type phù hợp nhất cho reference data trong Azure Stream Analytics (ASA). ASA hỗ trợ reference data để thực hiện các phép join hiệu quả mà không làm chậm pipeline streaming. Reference data phải được lưu trữ ở nơi hỗ trợ đọc định kỳ hoặc snapshot, không phải nguồn streaming thuần túy.

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

Lý do lựa chọn:
Azure Blob Storage là lựa chọn chuẩn và được khuyến nghị cho reference data trong ASA (theo tài liệu chính thức Microsoft Azure cập nhật đến 2024-2026).
🛠️ Cách hoạt động:

• Reference data được lưu dưới dạng file JSON/CSV nhỏ (≤ 1MB cho single blob, hoặc partitioned cho lớn hơn).
• ASA tự động reload reference data định kỳ (mặc định 1 phút, cấu hình được) khi file thay đổi.
• Hỗ trợ versioning và snapshot, tránh downtime khi update.
• Tích hợp seamless với ASA jobs qua portal/CLI/PowerShell.

Ví dụ sử dụng: Trong job ASA, định nghĩa input reference như WITH referenceData AS ( SELECT * FROM inputAlias REFERENCEINPUT SETTINGS Path='mystorage.blob.core.windows.net/container/file.json', ... ).

📘 Nguồn tham khảo:

• Azure Stream Analytics Reference Data Documentation (cập nhật 2024).
• ASA Input Types (hỗ trợ Blob cho reference đến 2026).

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

• Azure Blob storage ✅
  Đúng vì đây là input type chính thức dành riêng cho reference data trong ASA. Nó hỗ trợ dữ liệu tĩnh/chậm thay đổi, reload tự động, và tối ưu chi phí/performance. Không dùng cho streaming high-volume.

• Azure Service Bus ❌
  Sai vì Service Bus là messaging queue/topic dành cho streaming data hoặc command patterns (queues/topics). Không hỗ trợ reference data trực tiếp trong ASA; nếu dùng, phải custom logic để convert sang blob, phức tạp và không hiệu quả.

• Azure IoT Hub ❌
  Sai vì IoT Hub là nguồn streaming thuần túy từ thiết bị IoT (telemetry data). ASA hỗ trợ nó như input streaming, nhưng không dùng cho reference data vì dữ liệu IoT là real-time/high-velocity, không phù hợp tĩnh reference.

• Azure Event Hubs ❌
  Sai vì Event Hubs là streaming platform cho high-throughput events (partitioned streams). ASA dùng nó cho streaming input chính, nhưng reference data không tương thích vì Event Hubs không hỗ trợ reload snapshot như blob; sẽ gây lag và chi phí cao không cần thiết.

🧩 Kết luận: Lựa chọn Azure Blob storage đảm bảo giải pháp scalable, fault-tolerant theo best practices Azure Data Engineering! Nếu cần demo code/job config, hãy cho tôi biết nhé. 🚀

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

Câu hỏi tập trung vào tình huống thực tế trong Azure Synapse Analytics với Apache Spark pool. Cụ thể:

• Bạn có Azure Data Lake Storage Gen2 (tên account1) và Azure Event Hubs (tên Hub1).
• Dữ liệu được ghi vào account1 thông qua tính năng Event Hubs Capture (một cơ chế tự động lưu dữ liệu streaming từ Event Hubs vào storage dưới dạng file).
• Mục tiêu: Tạo một notebook trong Synapse để ingest (hấp thụ) dữ liệu từ account1 và query bằng Spark pool.
• Yêu cầu chính (phải đáp ứng đồng thời):
  • 📥 Retrieve multiple rows of records in their entirety: Đọc toàn bộ nhiều hàng dữ liệu một cách đầy đủ, không bị cắt xén.
  • ⏱️ Minimize query execution time: Giảm thời gian thực thi truy vấn.
  • ⚡ Minimize data processing: Giảm thiểu xử lý dữ liệu (như scanning, decompression).

Event Hubs Capture mặc định ghi dữ liệu dưới dạng Avro (theo tài liệu Azure cập nhật đến 2026), nhưng để tối ưu query Spark trên dữ liệu lớn (batch analytics), cần chọn format phù hợp cho việc đọc và xử lý. Spark hỗ trợ nhiều format, nhưng format lý tưởng phải columnar (cột hóa), hỗ trợ compression cao, predicate pushdown (đẩy lọc xuống storage), và schema evolution để giảm I/O và CPU.

🛠️ Kiến thức cập nhật: Theo Azure Synapse Analytics (phiên bản 2026), Spark pool (Databricks runtime-based) ưu tiên Parquet cho analytics nhờ hiệu suất vượt trội trên Data Lake Gen2 (hierarchical namespace enabled).

✅ Đáp án đúng: Parquet

Lý do lựa chọn:

• Parquet là định dạng columnar storage (lưu trữ theo cột), lý tưởng cho Spark queries trên dữ liệu lớn từ Data Lake.
• ✅ Đáp ứng retrieve multiple rows entirely: Đọc toàn bộ records mà không mất dữ liệu, hỗ trợ schema phức tạp từ Event Hubs (như Avro gốc).
• ✅ Minimize query time: Predicate pushdown, columnar pruning (chỉ đọc cột cần), và vectorized processing giúp Spark scan nhanh hơn 5-10x so với row-based formats.
• ✅ Minimize data processing: Compression Snappy/Parquet-native (tỷ lệ nén cao ~75%), giảm I/O từ Data Lake Gen2.
• Trong notebook Spark: spark.read.parquet("abfss://container@account1.dfs.core.windows.net/path") sẽ ingest nhanh, đặc biệt với Auto Loader hoặc Delta Lake.

Dẫn nguồn:

• 📘 Azure Event Hubs Capture (xác nhận Avro gốc, nhưng recommend convert sang Parquet cho analytics).
• 📘 Synapse Spark Parquet Optimization (hiệu suất Parquet trên ADLS Gen2, cập nhật 2025-2026).

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

• Parquet
  ✅ Đúng vì đây là định dạng tối ưu nhất cho yêu cầu. Columnar format giúp Spark chỉ đọc dữ liệu cần thiết, giảm thời gian query xuống mức thấp nhất (partition pruning, bloom filters). Hỗ trợ đầy đủ Avro schema từ Event Hubs Capture, nén hiệu quả, và tích hợp native với Synapse Spark pool – lý tưởng cho "multiple rows entirely" mà không tốn processing.

• Avro
  ❌ Sai vì Avro là row-oriented (lưu trữ theo hàng), phù hợp streaming/write từ Event Hubs Capture nhưng kém cho batch query. Đọc toàn bộ row làm tăng I/O và thời gian query (không pruning cột), xử lý dữ liệu nhiều hơn, không minimize được execution time/processing so với Parquet.

• ORC
  ❌ Sai vì ORC (Optimized Row Columnar) tương tự Parquet nhưng kém tối ưu hơn trên Azure ecosystem. ORC chủ yếu dùng trong Hadoop/Hive (AWS EMR), thiếu hỗ trợ schema evolution tốt bằng Parquet trên Spark/Synapse. Tăng thời gian query và processing do compatibility kém với Data Lake Gen2 partitions.

• JSON
  ❌ Sai vì JSON là text-based, schema-less (không có schema cố định), dẫn đến parsing chậm, nén kém (chỉ ~20-30%), và phải đọc toàn bộ file. Không hỗ trợ columnar pruning, làm query time cao gấp nhiều lần, processing dữ liệu lớn – hoàn toàn không đáp ứng minimize requirements.

Kết luận 🏆: Chuyển đổi từ Avro (Event Hubs Capture) sang Parquet trong notebook Spark là best practice để tối ưu Synapse Analytics! Nếu cần code sample, 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 tập trung vào Azure Synapse Analytics workspace trong một Azure subscription. Yêu cầu là cấp quyền cho người dùng User1 để có thể tạo một lake database mới bằng cách sử dụng Azure Synapse database template từ Gallery (thư viện mẫu có sẵn trong Synapse Studio). Giải pháp phải tuân thủ nguyên tắc least privilege (quyền hạn tối thiểu, chỉ cấp đúng những quyền cần thiết mà không thừa thãi).

🛠️ Bối cảnh kỹ thuật:

• Lake database là một tính năng trong Azure Synapse Analytics, cho phép tạo cơ sở dữ liệu trên Azure Data Lake Storage Gen2, hỗ trợ quản lý metadata và truy vấn dữ liệu không schema (schema-on-read).
• Việc tạo từ Gallery template yêu cầu quyền truy cập vào Synapse Studio, quản lý workspace resources, và tương tác với storage account liên kết.
• Không cần quyền admin toàn cục, mà chỉ cần quyền contributor phù hợp tại mức workspace để tránh rủi ro bảo mật.

📘 Kiến thức cập nhật (đến 2026): Theo tài liệu chính thức Microsoft Azure Synapse Analytics (phiên bản mới nhất 2024-2026), quyền được quản lý qua Azure RBAC (Role-Based Access Control) tại scope Synapse workspace. Không có thay đổi lớn về roles cốt lõi này trong các bản cập nhật gần đây.

✅ Đáp án đúng: Synapse Contributor

Lý do lựa chọn:

• Role Synapse Contributor cấp quyền tạo và quản lý hầu hết các resources trong Synapse workspace, bao gồm lake databases, pipelines, datasets, và templates từ Gallery.
• Nó cho phép User1 tạo lake database mới từ template mà không cần quyền admin cao hơn, hoàn toàn tuân thủ least privilege (chỉ contributor, không phải administrator).
• Cụ thể, role này bao gồm các action như Microsoft.Synapse/workspaces/* (trừ delete workspace), đủ để truy cập Synapse Studio, chọn template từ Gallery, và triển khai lake database lên Data Lake Storage.

Nguồn tham khảo:

• Azure Synapse RBAC roles (Microsoft Docs, cập nhật 2024).
• Lake database permissions (xác nhận contributor role cho create operations).

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

• ✅ Synapse Contributor
  Đúng 🟢: Như đã giải thích, role này cung cấp quyền chính xác để tạo lake database từ Gallery template trong workspace, với các permissions như Microsoft.Synapse/workspaces/lakeDatabases/write. Đáp ứng least privilege vì không cấp quyền quản trị toàn diện.

• ❌ Synapse Administrator
  Sai 🔴: Role này cấp quyền full control trên toàn bộ workspace (bao gồm delete, manage security, v.v.), vượt quá nhu cầu chỉ tạo lake database. Vi phạm least privilege vì thừa quyền admin không cần thiết.

• ❌ Synapse User
  Sai 🔴: Role này chỉ cho phép truy cập read-only hoặc chạy queries cơ bản trên existing resources (như SQL pools hoặc Spark jobs), không có quyền tạo mới lake database hoặc sử dụng templates từ Gallery. User1 sẽ không thể thực hiện hành động yêu cầu.

• ❌ Storage Blob Data Contributor
  Sai 🔴: Role này chỉ cấp quyền quản lý blobs trong Storage Account (như read/write/delete files), nhưng không liên kết với Synapse workspace hoặc quyền tạo lake database từ template. Thiếu permissions Synapse-specific, nên User1 không thể truy cập Studio hoặc Gallery.

🛡️ Lời khuyên thực hành: Để assign role, sử dụng Azure Portal > Synapse workspace > Access control (IAM) > Add role assignment > Chọn "Synapse Contributor" cho User1 tại scope workspace. Kiểm tra bằng cách login Synapse Studio với tài khoản User1 và thử tạo template từ Gallery > Lake databases.

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

Câu hỏi này thuộc về Azure Data Factory (ADF), một dịch vụ ETL/ELT mạnh mẽ trong Microsoft Azure, dùng để orchestration các pipeline xử lý dữ liệu. Cụ thể:

• Bạn có một Azure Blob Storage account tên blob1 (nơi lưu trữ dữ liệu không cấu trúc như file).
• Và một Azure Data Factory pipeline tên pipeline1 (luồng công việc xử lý dữ liệu).
• Yêu cầu: Đảm bảo pipeline1 tự động chạy ngay khi một file bị xóa (delete event) từ một container trong blob1.
• Điều kiện quan trọng: Giải pháp phải tối thiểu hóa nỗ lực phát triển (minimize development effort), nghĩa là ưu tiên các trigger sẵn có, không cần code phức tạp hay polling thủ công.

📘 Ngữ cảnh kỹ thuật: Azure Blob Storage tích hợp với Event Grid để phát hiện các sự kiện (events) như tạo file (BlobCreated), xóa file (BlobDeleted), v.v. ADF hỗ trợ các loại trigger để kích hoạt pipeline dựa trên sự kiện này một cách tự động và hiệu quả. ✅

✅ Đáp án đúng: storage event

Lý do lựa chọn:

• Storage event trigger trong Azure Data Factory là loại trigger tự động lắng nghe sự kiện từ Azure Blob Storage qua Event Grid, bao gồm cả sự kiện BlobDeleted (file bị xóa).
• Nó minimize development effort vì chỉ cần cấu hình trigger trong ADF UI (không code, không polling), chỉ định container/path, và loại sự kiện (BlobDeleted).
• Cập nhật mới nhất (2026): Theo tài liệu Azure Data Factory v2 (phiên bản hiện tại và tương lai), storage event trigger hỗ trợ đầy đủ các sự kiện Blob như Created, Deleted, Renamed, với độ trễ thấp (<1 phút) và scale tự động. 🛠️ Hoàn hảo cho yêu cầu!

Dẫn nguồn:

• Tạo Storage Event Trigger - Microsoft Learn
• Sự kiện Blob Storage với Event Grid

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

• schedule ❌
  Sai vì: Đây là trigger chạy pipeline theo lịch cố định (cron expression, như hàng giờ/ngày), không phản ứng với sự kiện thực tế như file bị xóa. Phải dùng polling thủ công (ví dụ: GetMetadata activity kiểm tra file), tăng effort phát triển và tốn tài nguyên không cần thiết.

• storage event ✅
  Đúng vì: Như đã giải thích ở trên, đây là lựa chọn tối ưu, trực tiếp lắng nghe BlobDeleted event từ Blob Storage, kích hoạt pipeline ngay lập tức mà không cần code thêm. Hỗ trợ filter theo container/path/suffix để chính xác hóa.

• tumbling window ❌
  Sai vì: Đây là loại schedule trigger nâng cao với cửa sổ thời gian cố định (fixed intervals, hỗ trợ backfill), dùng cho batch processing theo thời gian (như hourly data). Không liên kết với sự kiện storage, nên không phù hợp với delete event và vẫn cần phát triển thêm logic kiểm tra.

• custom event ❌
  Sai vì: Trigger này dành cho Event Grid custom topics (sự kiện tùy chỉnh từ ứng dụng bên ngoài), không phải sự kiện native từ Blob Storage. Để dùng, phải tự tạo Event Grid topic/subscription và code handler, tăng effort phát triển đáng kể so với storage event trigger sẵn có. 🧩