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

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

✅ Giải thích nội dung câu hỏi:
Câu hỏi tập trung vào việc xây dựng một data flow trong Azure Data Factory (ADF), nơi dữ liệu được upsert (cập nhật nếu tồn tại, chèn mới nếu chưa có) vào một bảng trong Azure Synapse Analytics dedicated SQL pool (một loại SQL pool chuyên dụng).
Nhiệm vụ là thêm một transformation (biến đổi) vào data flow để chỉ định logic quyết định khi nào một hàng từ dữ liệu đầu vào (input) cần được upsert vào đích (sink).
🛠️ Upsert ở đây yêu cầu kiểm tra điều kiện (ví dụ: dựa trên khóa chính) để quyết định insert hay update, và transformation phải hỗ trợ chính xác logic này trong ADF Data Flows (phiên bản mới nhất đến 2026 vẫn giữ nguyên cơ chế này theo tài liệu Microsoft).

📘 Đáp án đúng: [ĐÚNG] alter row
Lý do lựa chọn:
Alter Row là transformation chuyên dụng trong ADF Data Flows để áp dụng các hành động như insert, update, upsert, delete dựa trên điều kiện tùy chỉnh (sử dụng biểu thức khi Which Condition?). Nó cho phép viết logic chính xác cho upsert, ví dụ: kiểm tra khóa trùng lặp và quyết định hành động. Đây là cách chuẩn và được khuyến nghị bởi Microsoft cho các kịch bản upsert vào Synapse SQL pool. ✅ (Không có thay đổi lớn đến 2026).

🔍 Giải thích chi tiết từng phương án (theo phiên bản ADF mới nhất 2026)

• [SAI] join ❌
  Join transformation dùng để kết hợp (join) hai dataset dựa trên khóa chung (như inner join, left outer join). Nó không hỗ trợ logic upsert hay chỉ định hành động insert/update cho từng hàng riêng lẻ. Sử dụng join chỉ giúp merge dữ liệu, không giải quyết yêu cầu "chỉ định logic upsert" trực tiếp vào sink.

• [ĐÚNG] alter row ✅
  Như đã giải thích, đây là transformation lý tưởng để định nghĩa logic upsert (qua tùy chọn Upsert with condition). Nó kiểm tra điều kiện (ví dụ: match khóa chính từ sink) và tự động generate MERGE statement khi sink là SQL (như Synapse dedicated pool). Hỗ trợ đầy đủ mapping cột và xử lý slowly changing dimensions (SCD).

• [SAI] surrogate key ❌
  Surrogate key dùng để tạo khóa nhân tạo (như incremental ID) cho các hàng dữ liệu, thường áp dụng trước khi insert. Nó không liên quan đến logic upsert hay so sánh với dữ liệu hiện có trong sink, nên không đáp ứng yêu cầu chỉ định "when a row must be upserted".

• [SAI] select ❌
  Select transformation dùng để chọn/lọc cột, đổi tên, map schema hoặc validate kiểu dữ liệu. Nó chỉ chuẩn bị dữ liệu, không có khả năng áp dụng logic hành động như upsert (không generate MERGE hay kiểm tra điều kiện tồn tại).

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

• Microsoft Docs: Alter Row transformation in mapping data flow ✅ (Khuyến nghị chính thức cho upsert).
• Azure Data Factory Data Flow transformations overview 🛠️.
• Synapse Analytics sink in ADF (Hỗ trợ upsert native).

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 mô tả một tình huống thực tế trong Azure: Bạn có cơ sở dữ liệu on-premises tên db1 và một self-hosted integration runtime (IR tự lưu trữ, dùng để kết nối an toàn với nguồn dữ liệu on-premises). Bạn cũng có subscription Azure chứa Azure Data Lake Storage (ADLS) Gen2 tên dl1.
Nhiệm vụ là phát triển 4 dự án data pipeline sử dụng Microsoft Power Query để copy dữ liệu từ db1 sang dl1, với các yêu cầu bắt buộc:

• ✅ Tất cả pipelines phải dùng self-hosted integration runtime (để truy cập on-premises an toàn).
• ✅ Mỗi dự án phải lưu trữ trong một Git repository riêng biệt (hỗ trợ version control độc lập).
• ✅ Giảm thiểu công sức phát triển (cần tool dễ dùng, tích hợp sẵn Power Query và Git).

🛠️ Mục tiêu chính: Tìm dịch vụ Azure phù hợp nhất để xây dựng pipelines ETL/ELT với Power Query, hỗ trợ self-hosted IR, Git multi-repo, và tối ưu hóa effort.

✅ Đáp án đúng: Azure Data Factory

Lý do lựa chọn:
Azure Data Factory (ADF) là dịch vụ ETL/ELT hàng đầu của Azure, hỗ trợ Mapping Data Flows tích hợp Microsoft Power Query (M language) để transform dữ liệu trực quan, không code.

• 📱 Hỗ trợ self-hosted IR: Hoàn hảo cho nguồn on-premises như db1, copy sang ADLS dl1.
• 🔄 Git integration: Mỗi ADF instance (factory) có thể liên kết với Git repo riêng (Azure DevOps hoặc GitHub), dễ tạo 4 factories riêng cho 4 projects mà không ảnh hưởng lẫn nhau.
• ⚡ Minimize effort: Giao diện Studio thân thiện, drag-and-drop Power Query, publish nhanh, không cần code phức tạp. Phiên bản mới nhất (2024-2026) vẫn giữ ADF v2 làm core cho data pipelines.
  Đây là giải pháp chuẩn Azure cho yêu cầu, tiết kiệm thời gian phát triển nhất!

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

• Azure Data Factory Documentation (Mapping Data Flows & Self-hosted IR).
• Git Integration in ADF (hỗ trợ multi-repo per factory).
• Cập nhật 2026: ADF vẫn là nền tảng chính, tích hợp sâu với Synapse nhưng độc lập cho pipelines thuần tú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 văn bản gốc bằng tiếng Anh, kèm giải thích bằng tiếng Việt vì sao đúng/sai. Sử dụng ✅/❌ để nổi bật.

• Azure Synapse Analytics ❌ SAI
  Synapse là workspace-based analytics platform, hỗ trợ pipelines (tích hợp ADF dưới hood), Power Query trong notebooks/data flows, và self-hosted IR. Tuy nhiên, không phù hợp vì: Synapse thường dùng một workspace duy nhất với Git repo chung, khó tách 4 projects riêng repo mà không phức tạp (phải dùng multiple workspaces, tăng effort). Không minimize development như ADF thuần túy, vì Synapse nặng về big data analytics hơn ETL copy đơn giản.

• Azure Logic Apps ❌ SAI
  Logic Apps là low-code workflow/orchestration cho automation (như API calls, approvals). Không hỗ trợ Power Query native, self-hosted IR cho data copy lớn (chỉ connector cơ bản), và Git integration kém cho data pipelines. Sử dụng sẽ tăng effort vì phải build custom connectors, không dành cho ETL từ on-prem DB sang ADLS.

• Azure Data Factory ✅ ĐÚNG
  Như đã giải thích ở trên: Hoàn hảo khớp tất cả yêu cầu (Power Query, self-hosted IR, separate Git repos per factory, low-effort Studio). Giải pháp tối ưu nhất!

• Microsoft Power BI ❌ SAI
  Power BI là tool visualization/reporting, hỗ trợ Power Query để import/transform dữ liệu (như từ DB on-prem qua gateway tương tự self-hosted IR). Nhưng không copy dữ liệu vĩnh viễn sang ADLS (chỉ load vào dataset tạm thời), không có pipelines/repo Git cho projects, và không phải ETL tool. Sử dụng sẽ vi phạm yêu cầu về data movement & development structure.

🧠 Kết luận: Azure Data Factory là lựa chọn logic nhất, phù hợp kiến trúc Azure hiện đại (2026). Nếu triển khai thực tế, bắt đầu bằng ADF Studio để prototype nhanh! 🚀

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

Câu hỏi thuộc chủ đề Azure Synapse Analytics pipelines (thuộc Azure Data Factory - ADF), không phải AWS như đề cập ban đầu (có thể là nhầm lẫn). Nội dung xoay quanh việc thêm một Set Variable activity vào pipeline hiện có để đảm bảo trạng thái pipeline luôn là "Successful" sau khi hoàn thành, bất kể activity "Business Activity That Fails" có thất bại hay không.

📸 Phân tích hình ảnh pipeline (dựa trên mô tả và sơ đồ ASCII):

• Pipeline có các activity chính:
  • Lookup activity: Thành công (dấu ✓ xanh).
  • Business Activity That Fails: Thất bại (dấu ✗ đỏ) – đây là activity kinh doanh cố tình fail để test.
• Từ "Business Activity That Fails", có hai nhánh dependency:
  • Nhánh Upon Success (mũi tên xanh với "(x)" – có thể chỉ skipped/crossed vì activity fail): Dẫn đến Upon Success activity (✓).
  • Nhánh Upon Failure (mũi tên đỏ với "(x)"): Dẫn đến Upon Failure activity (✓).
• Set Variable (màu xám): Có vẻ là activity hiện có hoặc placeholder, kết nối từ hai nhánh trên.
• Vấn đề: Nếu "Business Activity That Fails" fail, nhánh success bị skipped, dẫn đến pipeline có thể mark "Failed". Cần thêm Set Variable mới ở cuối để "bắt" tất cả trường hợp, force status Successful bằng cách xử lý dependencies thông minh (sử dụng skipped dependency để chạy ngay cả khi path bị skip).

Mục tiêu: Sử dụng dependencies (Upon Success, Upon Failure, Skipped, Completed) của ADF để Set Variable luôn chạy và succeed, tránh propagate failure lên pipeline level. Kiến thức cập nhật đến 2026 (Azure Synapse/ADF v2.x, không thay đổi core dependency logic).

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

• Microsoft Docs: Control flow in Azure Data Factory
• ADF Dependencies: Skipped, Success, Failure
• Exam DP-203 sample: Pattern force pipeline success.

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

Đáp án đúng: a skipped dependency on the Upon Success activity

Lý do 🛠️:

• Trong pipeline, "Upon Success activity" nằm trên nhánh success của "Business Activity That Fails".
  • Nếu activity success → "Upon Success" chạy bình thường.
  • Nếu activity fail → nhánh success skipped → "Upon Success" không chạy.
• Config skipped dependency trên "Upon Success activity" cho Set Variable mới nghĩa là: Set Variable sẽ chạy ngay cả khi "Upon Success" bị skipped (tức trường hợp fail).
• Kết hợp với dependency mặc định/success từ "Upon Failure activity" (nhánh fail), Set Variable luôn chạy ở cả hai trường hợp, succeed (không fail), và không propagate failure → pipeline status luôn Successful.
• Đây là pattern chuẩn trong ADF để ignore/override failure ở level pipeline (không dùng fault tolerance toàn cục vì chỉ target cụ thể).

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

• ❌ [SAI] a skipped dependency on the Upon Failure activity
  Sai vì: Skipped dependency trên "Upon Failure activity" chỉ chạy Set Variable khi nhánh failure bị skipped (tức activity success, không fail). Trường hợp fail → "Upon Failure" chạy → Set Variable không chạy → failure propagate → pipeline Failed. Không đảm bảo always successful.

• ✅ [ĐÚNG] a skipped dependency on the Upon Success activity
  Đúng vì: Như giải thích trên, bắt đúng skipped path của success nhánh khi fail, kết hợp failure nhánh → Set Variable luôn execute và succeed → pipeline Successful. Pattern tối ưu cho diagram (fail activity + hai nhánh Upon Success/Upon Failure).

• ❌ [SAI] a success dependency on the Business Activity That Fails activity
  Sai vì: Success dependency chỉ chạy Set Variable khi "Business Activity That Fails" success. Khi fail → Set Variable không chạy → pipeline Failed ngay. Không handle failure case.

• ❌ [SAI] a failure dependency on the Upon Failure activity
  Sai vì: Failure dependency trên "Upon Failure activity" yêu cầu "Upon Failure" phải fail mới chạy Set Variable. Nhưng "Upon Failure" thường là dummy/succeed activity → không fail → Set Variable không chạy → không cover success case, pipeline có thể partial fail.

Kết luận 🎯: Config này tận dụng dependency conditions (Skipped) linh hoạt của ADF, đảm bảo pipeline robust cho data engineering workflows. Nếu implement thực tế, test với Debug mode! 🚀

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

Câu hỏi này thuộc lĩnh vực Azure Data Factory (ADF), tập trung vào việc thiết lập pipeline để sao chép dữ liệu từ nguồn dữ liệu on-premises (tại chỗ) sang lưu trữ đám mây Azure. Cụ thể:

• Bạn có một máy chủ Linux on-premises chứa cơ sở dữ liệu tên DB1 (không phải cơ sở dữ liệu đám mây, mà nằm trong mạng nội bộ doanh nghiệp).
• Trong Azure subscription, có ADF1 (Azure Data Factory) và ADLS1 (Azure Data Lake Storage Gen2).
• Nhiệm vụ: Tạo pipeline trong ADF1 để copy data từ DB1 sang ADLS1.
• Câu hỏi trọng tâm: Loại Integration Runtime (IR) nào nên sử dụng để đọc dữ liệu từ DB1?

Lý do câu hỏi quan trọng: Integration Runtime là "cầu nối" thực thi các hoạt động copy dữ liệu trong ADF. Với nguồn on-premises, ADF cần IR có khả năng truy cập mạng nội bộ an toàn, không qua public internet (tránh firewall, bảo mật dữ liệu nhạy cảm). Kiến thức dựa trên phiên bản ADF mới nhất (tính đến 2026: ADF v2 với hỗ trợ tự động scale SHIR và hybrid data movement). 📘

✅ Đáp án đúng: self-hosted integration runtime

Lý do lựa chọn:

• Self-hosted Integration Runtime (SHIR) là lựa chọn duy nhất phù hợp cho nguồn dữ liệu on-premises như DB1 trên Linux server.
• SHIR được cài đặt trực tiếp trên máy on-premises (hỗ trợ Linux từ ADF 2019+), cho phép ADF kết nối an toàn qua mạng nội bộ, hỗ trợ firewall outbound, và xử lý dữ liệu lớn mà không cần expose DB1 ra internet.
• Quy trình: Cài SHIR node trên Linux server gần DB1 → Đăng ký với ADF1 → Sử dụng trong Linked Service cho DB1 → Copy sang ADLS1.
• Ưu điểm mới (2024-2026): Hỗ trợ auto-scale lên đến 100+ nodes, VNet integration, và secure credentials store với Azure Key Vault. 🛠️

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

• ✅ self-hosted integration runtime
  Đúng hoàn toàn! Như giải thích trên, đây là IR dành riêng cho hybrid scenarios (on-premises ↔ cloud). Nó chạy trên infrastructure của bạn, hỗ trợ các connector như generic ODBC/JDBC cho DB trên Linux. Không dùng SHIR sẽ không thể đọc được DB1 do hạn chế mạng. (Tham khảo: Microsoft Docs - Self-hosted IR).

• ❌ Azure integration runtime
  Sai! Azure IR chạy hoàn toàn trên cloud Azure (public/auto-resolved regions), chỉ phù hợp với nguồn cloud-native (như Azure SQL, ADLS). Nó không thể truy cập on-premises DB1 vì thiếu kết nối mạng nội bộ, dẫn đến lỗi "network unreachable". Dùng cho trường hợp này sẽ fail ngay bước test connection. 🛑

• ❌ Azure-SQL Server Integration Services (SSIS)
  Sai! Đây không phải là loại Integration Runtime trong ADF. SSIS là công cụ ETL riêng (chạy trên Azure-SSIS IR trong ADF), dùng cho SSIS packages phức tạp, không phải copy đơn giản từ on-premises DB. ADF hỗ trợ SSIS cho migration legacy, nhưng câu hỏi yêu cầu copy activity trực tiếp → cần SHIR, không phải SSIS. (Tham khảo: Microsoft Docs - SSIS in ADF). 🚫

📚 Tài liệu tham khảo chính thức (cập nhật 2026)

• Azure Data Factory Integration Runtimes Overview ✅ (Hướng dẫn chọn IR theo scenario).
• Tutorial: Copy on-premises data with SHIR 🛠️.
• ADF Release Notes 2024-2026: Hỗ trợ Linux SHIR v5+ với ARM64.

Nếu cần demo pipeline hoặc troubleshoot, hãy cung cấp thêm chi tiết! 😊

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

Câu hỏi tập trung vào việc cấu hình Scheduled Trigger (basic mode) trong Azure Data Factory (ADF) để pipeline có tên P1 chạy đúng vào 4 thời điểm cố định hàng ngày:

• 10:15 AM (tức 10:15 sáng)
• 12:15 PM (tức 12:15 trưa)
• 2:15 PM (tức 14:15 chiều)
• 4:15 PM (tức 16:15 chiều)

🛠️ Yêu cầu chính: Sử dụng frequency (tần suất: Minute/Giờ/Ngày/Tuần/Tháng) và interval (khoảng cách lặp lại) trong chế độ basic của Scheduled Trigger.
Các thời điểm này có mẫu lặp lại đều đặn mỗi 2 giờ, bắt đầu từ 10:15 AM. Trong ADF (phiên bản mới nhất đến 2026, không thay đổi cơ bản từ v2), Scheduled Trigger basic sẽ kích hoạt từ start time và lặp lại theo frequency × interval liên tục (không tự reset ngày trừ khi cấu hình thêm end time hoặc dùng cron advanced). Để khớp chính xác, cần set start time = 10:15 AM theo timezone phù hợp (ví dụ: UTC+7 cho Việt Nam). Lưu ý: Câu hỏi không yêu cầu chỉ chạy đúng 4 lần (mà "run at" các thời điểm này), nên cấu hình có thể chạy thêm sau 16:15 nếu không set end time (có thể điều chỉnh end time ~17:00 để giới hạn).

✅ Đáp án đúng: Frequency: Hour - Interval: 2

Lý do lựa chọn:

• Với Frequency: Hour (theo giờ) và Interval: 2 (mỗi 2 đơn vị), kết hợp start time 10:15 AM, trigger sẽ kích hoạt chính xác:
  10:15 AM → +2 giờ = 12:15 PM → +2 giờ = 14:15 (2:15 PM) → +2 giờ = 16:15 (4:15 PM) hàng ngày.
• Đây là cách tối ưu và chuẩn cho mẫu lặp đều đặn theo giờ trong ADF basic trigger (không cần cron phức tạp). Nếu muốn giới hạn chỉ 4 lần, thêm end time sau 16:15 hoặc dùng Tumbling Window Trigger.
• Phù hợp kiến thức ADF cập nhật 2026: Basic schedule hỗ trợ regular interval như vậy.

📌 Phân tích chi tiết tất cả các phương án

Dưới đây là giải thích từng lựa chọn giữ nguyên văn bản gốc bằng tiếng Anh, kèm phân tích đúng/sai hoàn toàn bằng tiếng Việt:

• Frequency: Month - Interval: 1 ❌ SAI
  Phương án này chỉ kích hoạt mỗi tháng 1 lần tại start time (ví dụ: ngày 1 mỗi tháng lúc 10:15). Không khớp yêu cầu hàng ngày và chỉ 1 lần/tháng, bỏ lỡ hoàn toàn các thời điểm khác. Không phù hợp cho lịch daily.

• Frequency: Day - Interval: 1 ❌ SAI
  Phương án kích hoạt chỉ 1 lần mỗi ngày tại start time (ví dụ: chỉ 10:15 AM hàng ngày). Không thể chạy thêm 3 lần còn lại (12:15 PM, 2:15 PM, 4:15 PM) vì Day mode chỉ lặp 1 lần/ngày, không hỗ trợ multiple executions trong ngày.

• Frequency: Minute - Interval: 60 ❌ SAI
  Tương đương mỗi 60 phút (tức mỗi giờ 1 lần) từ start time (ví dụ: 10:15 → 11:15 → 12:15 → 13:15 → ...). Sẽ chạy quá nhiều lần (khoảng 24 lần/ngày), bao gồm cả các giờ không cần như 11:15, 1:15 PM, 3:15 PM..., không khớp chính xác mẫu 2 giờ/lần.

• Frequency: Hour - Interval: 2 ✅ ĐÚNG
  Như giải thích trên: Kích hoạt mỗi 2 giờ từ start time 10:15 AM, khớp hoàn hảo 10:15 AM → 12:15 PM → 2:15 PM → 4:15 PM hàng ngày. Đây là cấu hình chuẩn cho regular interval theo giờ trong ADF Scheduled Trigger basic.

📘 Tài liệu tham khảo

• Microsoft Docs chính thức (cập nhật 2024-2026): Create a schedule trigger in Azure Data Factory – Chi tiết basic vs advanced mode, frequency/interval.
• Pipeline execution and triggers: Concepts-pipeline-execution-triggers – Ví dụ cấu hình Hour/Interval cho multiple daily runs.
• Best practices: Sử dụng cron advanced nếu cần times không đều (e.g., "0 15 10,12,14,16 * * *").

Hy vọng phân tích này giúp bạn nắm vững ADF triggers! 🚀 Nếu cần demo code ARM/JSON, hãy hỏi thêm.

🧩 Phân tích 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 trên Microsoft Azure dùng để xây dựng pipeline dữ liệu. Cụ thể, bạn đang tạo một pipeline ADF và cần thêm một activity để thực thi một stored procedure (SP) Transact-SQL với các đặc tính sau:

• SP trả về số lượng hóa đơn bán hàng cho ngày hiện tại (một giá trị số, ví dụ: count của invoices).
• SP không yêu cầu input parameters (không cần tham số đầu vào).

Mục tiêu là chọn activity phù hợp để gọi SP và lấy kết quả trả về (result set hoặc scalar value) mà không cần input. Đây là tình huống phổ biến trong ADF khi cần query dữ liệu đơn giản để sử dụng sau (ví dụ: trong điều kiện If Condition hoặc Set Variable).

📘 Kiến thức cập nhật: Theo tài liệu Microsoft ADF phiên bản mới nhất (tính đến 2026, ADF v2 với các tính năng Lookup hỗ trợ SP không param và return first row/dataset slice), Lookup là lựa chọn tối ưu cho trường hợp này. (Nguồn: Microsoft Docs - Lookup Activity).

✅ Đáp án đúng: Lookup

Lý do lựa chọn:
Lookup activity được thiết kế để thực thi SQL query hoặc stored procedure và trả về kết quả dưới dạng dataset (hàng đầu tiên nếu dùng @dataset().firstRow, hoặc toàn bộ slice nếu <5000 rows). Với SP không input param và chỉ return một giá trị số (như count invoices), Lookup hoàn hảo vì:

• Hỗ trợ gọi SP trực tiếp qua Stored procedure name trong dataset SQL.
• Không cần param, dễ config.
• Kết quả có thể dùng động trong pipeline (ví dụ: @{activity('LookupSP').output.firstRow.countInvoiced}).
  🛠️ Đây là best practice cho lookup data nhỏ, hiệu suất cao, không side-effect như Stored Procedure activity.

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

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên chức năng ADF:

• ❌ Stored Procedure:
  Activity này dùng để thực thi SP trên SQL Database với hỗ trợ input/output parameters. Nó phù hợp khi SP có param hoặc thực hiện hành động (insert/update/delete) mà không cần return dataset. Sai vì: SP ở đây không param và cần return value để sử dụng (như count), Stored Procedure chỉ execute mà không expose result set dễ dàng như Lookup. (Không phù hợp cho read-only lookup).

• ❌ Get Metadata:
  Activity này lấy metadata của file/folder/dataset (như size, last modified, childItems) từ Data Lake/Blob Storage. Sai vì: Không liên quan đến thực thi SP SQL hay query database, chỉ dùng cho file-based sources, không execute T-SQL.

• ❌ Append Variable:
  Activity này thêm giá trị vào biến pipeline (string/array). Sai vì: Chỉ là control flow để manipulate variable, không execute SP hay query database. Nó cần giá trị sẵn có từ activity trước, không tự gọi SP.

• ✅ Lookup:
  Như đã giải thích ở đáp án đúng: Hoàn hảo cho SP không param, return result set/scalar để dùng linh hoạt. Hỗ trợ SQL Server/ Synapse, config đơn giản qua dataset. (Xác nhận từ docs: Lookup hỗ trợ SP từ ADF 2018+ và cập nhật đến 2026 với scale-out).

🛠️ Lời khuyên thực hành: Trong ADF Studio, tạo Linked Service SQL → Dataset → Lookup activity → Chọn "Stored procedure" và nhập tên SP. Test với sample pipeline để verify count invoices.

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

• Lookup Activity - MS Docs
• Stored Procedure Activity - MS Docs
• ADF Runtime 2026: Không thay đổi core behavior cho các activity này (chỉ cải thiện performance với Spark/Delta Lake integration).

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

Câu hỏi tập trung vào Microsoft Purview (một dịch vụ quản lý dữ liệu thống nhất trong Azure), cụ thể là cách tìm kiếm trong Data Catalog để xác định các tài sản (assets) có thuộc tính assetType là Table hoặc View.

• Bối cảnh: Bạn có một tài khoản Microsoft Purview trong subscription Azure. Data Catalog là nơi lưu trữ metadata của các assets dữ liệu (như bảng, view từ các nguồn dữ liệu khác nhau).
• Yêu cầu chính: Viết query tìm kiếm đúng cú pháp để lọc assets thỏa mãn điều kiện assetType bằng Table HOẶC View.
• Lưu ý cú pháp: Microsoft Purview sử dụng ngôn ngữ tìm kiếm dựa trên Lucene/KQL (cập nhật đến phiên bản mới nhất 2024-2026), hỗ trợ tìm kiếm full-text với các toán tử như :, OR, AND. Tìm kiếm không phân biệt chữ hoa/thường (case-insensitive), và cú pháp cho trường (field) cụ thể là field:value.
  📘 Tài liệu tham khảo:
• Microsoft Purview Data Catalog search syntax (cập nhật 2024).
• Purview search operators (hỗ trợ field:value1 OR field:value2 cho multiple values).

✅ Đáp án đúng: assetType:Table OR assetType:view

Lý do lựa chọn:

• Đây là cú pháp chuẩn của Microsoft Purview Data Catalog. Sử dụng field:value để chỉ định giá trị chính xác cho trường assetType, kết hợp OR để lọc Table HOẶC View.
• Purview không phân biệt hoa/thường, nên Table và view đều hợp lệ (thường khuyến nghị viết hoa cho Table, nhưng lowercase cho view vẫn khớp).
• Query này sẽ trả về tất cả assets có assetType là Table hoặc View một cách chính xác và hiệu quả. 🛠️
  Ví dụ thực tế: Chạy query này trong giao diện Purview portal sẽ liệt kê đúng các bảng và view từ các nguồn như Azure SQL, Synapse, v.v.

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

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh dấu ✅/❌ kèm lý do bằng tiếng Việt:

• ❌ assetType IN ('Table', 'View')
  Sai vì: Cú pháp IN với dấu ngoặc đơn và dấu nháy kép giống SQL (như trong Azure SQL hoặc T-SQL), không được hỗ trợ trong Purview Data Catalog search. Purview không dùng toán tử SQL-style mà dùng OR cho multiple values. Nếu chạy, query sẽ báo lỗi cú pháp hoặc không khớp kết quả.

• ✅ assetType:Table OR assetType:view
  Đúng vì: Như đã giải thích ở phần đáp án đúng. Đây là cú pháp chuẩn, linh hoạt và chính xác theo docs Purview mới nhất (2024-2026). Hỗ trợ tìm kiếm nhanh trên metadata lớn. 🏆

• ❌ assetType = (Table OR View)
  Sai vì: Dùng dấu = (toán tử bằng trong KQL/SQL) kết hợp ngoặc đơn là không hợp lệ trong Purview search. Purview yêu cầu : cho field lookup, không hỗ trợ = hoặc ngoặc nhóm như vậy. Query này sẽ không parse được và trả về zero results.

• ❌ assetType:(Table OR View)
  Sai vì: Cú pháp với dấu : theo sau ngoặc đơn (Table OR View) giống Lucene advanced query ở một số công cụ khác (như Elasticsearch), nhưng Purview không hỗ trợ dạng này cho assetType. Phải dùng assetType:Table OR assetType:View riêng lẻ. Nếu chạy, sẽ không khớp hoặc chỉ tìm partial matches không mong muốn.

Kết luận tổng quát 🎯: Chọn đúng query giúp tối ưu hóa tìm kiếm metadata trong Purview, hỗ trợ governance dữ liệu Azure hiệu quả. Nếu triển khai thực tế, test query trực tiếp trên Purview portal để verify! 🚀

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

Câu hỏi thuộc chủ đề Azure Synapse Analytics với tích hợp Git (Azure Repos), không phải AWS như mô tả ban đầu (có thể là nhầm lẫn). Cụ thể:

• Bạn có một Azure subscription chứa Azure Synapse Analytics account, được tích hợp với repository Azure Repos tên Repo1.
• Trong Repo1, có pipeline tên Pipeline1.
• Repository có các branches được mô tả trong hình ảnh (bảng sau đã được trích xuất chính xác từ hình ảnh): | Name | Description | |------------------|-------------------| | featuredev | Working branch | | main | Collaboration branch | | pipeline1_publish | Publish branch |

📊 Phân tích hình ảnh quan trọng:

• featuredev: Branch làm việc (working branch) – nơi developer thực hiện thay đổi, test pipeline.
• main: Branch hợp tác (collaboration branch) – nơi review code, merge pull request từ các working branch.
• pipeline1_publish: Branch xuất bản (publish branch) – chứa phiên bản đã publish/live của pipeline, được Synapse tự động sync sau khi merge vào collaboration branch.

Quy trình: Bạn đã develop và test changes cho Pipeline1 trên branch featuredev. Bây giờ cần publish changes (đưa thay đổi lên môi trường live/published). 🛠️ Quy trình publish chuẩn trong Azure Synapse Git integration (cập nhật đến 2026):

• Thay đổi được lưu ở working branch (saved/live mode trong Synapse Studio).
• Để publish: Tạo pull request (PR) từ working branch vào collaboration branch (main).
• Sau khi review/merge PR → Synapse tự động hoặc thủ công publish từ collaboration branch sang publish branch (pipeline1_publish), cập nhật môi trường live.
• First step luôn là tạo PR từ branch đang làm việc (featuredev).

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

Đáp án đúng: From featuredev, create a pull request.

Lý do (🧩 Phân tích chi tiết):

• Trong Azure Synapse với Git integration (Azure Repos), sau khi develop/test trên working branch (featuredev), bước đầu tiên để publish là tạo pull request từ featuredev vào collaboration branch (main).
• PR này cho phép review code, merge thay đổi vào main → Synapse sẽ sync sang publish branch (pipeline1_publish) để activate changes ở môi trường live.
• Đây là best practice theo quy trình CI/CD của Synapse (không publish trực tiếp từ working branch để tránh lỗi).
• 📘 Nguồn tham khảo:
  • Azure Synapse Analytics - Git integration (cập nhật 2024-2026).
  • Publish Synapse artifacts – Xác nhận "Create a pull request from your feature branch to the collaboration branch".

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

• ✅ From featuredev, create a pull request.
  Đúng 🟢: Như phân tích trên, đây là bước đầu tiên bắt buộc. Tạo PR từ working branch (featuredev) vào collaboration branch (main) để review/merge, sau đó publish tự động sang pipeline1_publish. Quy trình này đảm bảo kiểm soát phiên bản và tránh deploy trực tiếp code chưa review.

• ❌ From main, create a pull request.
  Sai 🔴: Thay đổi đang ở featuredev (working branch), không phải main. Tạo PR từ main là vô nghĩa vì main đã là collaboration branch (không có changes mới để merge). Nếu làm vậy, bạn không thể đưa code từ featuredev lên publish branch.

• ❌ Add a Publish_config.json file to the root folder of the collaboration branch.
  Sai 🔴: File Publish_config.json không tồn tại trong quy trình Synapse Git standard (cập nhật 2026). Đây có thể nhầm lẫn với config ở các tool khác (như Azure DevOps YAML), nhưng Synapse không yêu cầu file này để publish. Publish dựa vào PR/merge, không cần config thủ công ở root của collaboration branch (main).

• ❌ Switch to live mode.
  Sai 🔴: Synapse Studio có Live (working changes, chưa publish) và Published modes, nhưng "switch to live mode" không publish gì cả – nó chỉ hiển thị changes tạm thời. Publish thực sự yêu cầu merge PR và sync sang publish branch, không phải chỉ switch mode.

🛠️ Lời khuyên: Luôn sử dụng Synapse Studio UI hoặc Azure DevOps để tạo PR. Test trên feature branch trước khi merge để tránh downtime pipeline! 🚀