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 tập trung vào việc xem trạng thái (status) của một job trong Azure Synapse Analytics được viết bằng ngôn ngữ Scala.

• Azure Synapse Analytics là dịch vụ phân tích dữ liệu tích hợp của Microsoft Azure, hỗ trợ nhiều loại workload như SQL, Spark và Pipeline.
• Job sử dụng Scala thường chạy trên Spark pool (Apache Spark engine) trong Synapse, vì Scala là ngôn ngữ chính cho Spark development (hỗ trợ Spark 3.x trở lên theo phiên bản mới nhất 2024-2026).
• Yêu cầu chính: Tìm cách monitor và xem status job một cách chính xác, thường liên quan đến giao diện Synapse Studio hoặc Azure Monitor.
  Mục tiêu là chọn phương án phù hợp nhất để truy cập trực tiếp thông tin trạng thái job Spark (như Running, Succeeded, Failed, v.v.), theo tài liệu chính thức Azure Synapse cập nhật đến 2026.

✅ Đáp án đúng:
From Synapse Studio, select the workspace. From Monitor, select Apache Sparks applications.
Lý do chọn:
Đây là cách chính thức và trực tiếp nhất để xem status của Spark job (bao gồm Scala jobs) trong Synapse Studio. Trong Monitor hub của Synapse Studio, phần Apache Spark Applications hiển thị danh sách tất cả Spark jobs với chi tiết status thời gian thực (Driver status, Executor logs, YARN UI, v.v.). Điều này được thiết kế dành riêng cho Spark workloads, hỗ trợ phiên bản Synapse runtime 3.4+ (2024-2026).

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

• ✅ [ĐÚNG] From Synapse Studio, select the workspace. From Monitor, select Apache Sparks applications.
  Phương án này hoàn toàn chính xác vì Synapse Studio cung cấp Monitor hub chuyên biệt cho Spark applications. Bạn chọn workspace → Monitor → Apache Spark Applications để xem status job Scala ngay lập tức, bao gồm metrics, logs và history. Đây là giao diện native, dễ sử dụng nhất theo docs Azure (không cần query phức tạp).

• ❌ [SAI] From Synapse Studio, select the workspace. From Monitor, select SQL requests.
  Phương án này sai vì SQL requests chỉ monitor các query chạy trên Dedicated SQL pools hoặc Serverless SQL, không áp dụng cho Spark jobs (Scala). Spark jobs không xuất hiện ở đây, dẫn đến không xem được status.

• ❌ [SAI] From Azure Monitor, run a Kusto query against the AzureDiagnostics table.
  Phương án này sai vì AzureDiagnostics table chủ yếu lưu diagnostics chung cho Synapse (như pipeline runs hoặc SQL), không phải status chi tiết của Spark applications. Kusto query (Log Analytics) ở đây chỉ cho dữ liệu tổng quát, không realtime và không specific cho Scala/Spark job status.

• ❌ [SAI] From Azure Monitor, run a Kusto query against the SparkLoggingEvent_CL table.
  Phương án này sai vì SparkLoggingEvent_CL là custom Log Analytics table cho Spark logs (events như executor logs), nhưng chỉ dùng để query logs chi tiết sau khi job chạy, không phải để xem tổng quan status job (như Running/Succeeded). Nó yêu cầu query phức tạp và không phải cách chính thức đầu tiên để check status.

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

• Monitor Apache Spark applications in Synapse Studio ✅ (Cách chính thức xem Spark job status).
• Synapse Studio Monitor hub (Phân biệt SQL vs Spark).
• Azure Synapse diagnostics và Log Analytics (Logs table như SparkLoggingEvent_CL).

Hy vọng phân tích này giúp bạn nắm vững cách monitor Spark jobs trong Azure Synapse! 🚀

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

Câu hỏi thuộc kỳ thi chứng chỉ Microsoft Azure Data Engineer Associate (DP-203), tập trung vào Azure Synapse Analytics (cụ thể là serverless SQL pool) và Azure Blob Storage.
Tình huống: Bạn có một subscription Azure chứa các tài nguyên:

• storage1: Tài khoản Azure Blob Storage chứa các file TSV (Tab-Separated Values) công khai (publicly accessible), KHÔNG có hàng header (no header row).
• WS1: Azure Synapse Analytics workspace chứa serverless SQL pool (không cần provision compute).

Yêu cầu giải pháp:

• Đọc các file TSV này bằng ad-hoc queries (truy vấn tạm thời, không cần tạo external table).
• Sử dụng hàm OPENROWSET để truy cập dữ liệu từ Blob Storage.
• Phải gán tên cột (assign a name) và ghi đè kiểu dữ liệu suy luận (override the inferred data type) cho từng cột.

Vấn đề chính: File TSV không có header nên SQL pool không tự suy luận được tên cột và kiểu dữ liệu chính xác → cần tùy chỉnh schema trong OPENROWSET.
📸 Phân tích hình ảnh bảng tài nguyên (dựa trên mô tả và ảnh đính kèm):

• Bảng có 2 hàng:
  | Name | Azure Type | Contains/Description |
  |-----------|-----------------------------|---------------------------------------|
  | storage1 | Azure Blob storage account | Contains publicly accessible TSV files that do NOT have a header row |
  | WS1 | Azure Synapse Analytics workspace | Contains a serverless SQL pool |
  Hình ảnh nhấn mạnh publicly accessible (không cần SAS token) và no header row → phù hợp dùng OPENROWSET với bulk options cho TSV (field terminator = '\t').

✅ Đáp án đúng: the WITH clause

Lý do chọn:
Trong Azure Synapse serverless SQL pool, hàm OPENROWSET hỗ trợ đọc file TSV từ Blob Storage qua cú pháp:

SELECT * FROM OPENROWSET(
    BULK 'https://storage1.blob.core.windows.net/container/file.tsv',
    FORMAT = 'CSV',
    FIELDTERMINATOR = '\t',  -- Cho TSV
    ROWTERMINATOR = '\n',
    FIRSTROW = 2  -- Bỏ qua hàng đầu nếu cần, nhưng file no header nên bắt đầu từ row 1
) WITH (
    Column1 INT,      -- Gán tên và override kiểu dữ liệu
    Column2 VARCHAR(50),
    ...
);

• WITH clause chính là phần dùng để định nghĩa schema tùy chỉnh: gán tên cột (assign name) và ghi đè kiểu dữ liệu (override inferred types). Không có nó, SQL sẽ suy luận sai (ví dụ: tất cả thành string).
• Phù hợp ad-hoc query, public files (dùng URL trực tiếp, không cần DATA_SOURCE).
  🛠️ Cập nhật mới nhất (2026): Tính năng không thay đổi từ 2021-2026; hỗ trợ Parquet/CSV/TSV ổn định (xem Azure Synapse docs).

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

• ✅ the WITH clause
  Đúng vì đây là clause bắt buộc để gán tên cột và override kiểu dữ liệu khi đọc file không header qua OPENROWSET bulk. Không dùng WITH → không đáp ứng yêu cầu. Ví dụ docs: Microsoft khuyến nghị dùng cho TSV/CSV không schema.

• ❌ the ROWSET_OPTIONS bulk option
  Sai vì ROWSET_OPTIONS không tồn tại trong bulk options của OPENROWSET (Synapse serverless). Bulk options chỉ bao gồm FORMAT, FIELDTERMINATOR, ROWTERMINATOR, FIRSTROW, etc. Không liên quan đến schema override.

• ❌ the DATAFILETYPE bulk option
  Sai vì DATAFILETYPE không phải bulk option chuẩn. Bulk options dùng FORMAT = 'CSV' (cho TSV) để chỉ định loại file, không có DATAFILETYPE. Nó không giúp gán tên/kiểu cột.

• ❌ the DATA_SOURCE parameter
  Sai vì DATA_SOURCE dùng để tham chiếu external data source đã tạo trước (CREATE EXTERNAL DATA SOURCE), phù hợp managed/private storage. Ở đây file publicly accessible → dùng URL trực tiếp trong BULK, không cần DATA_SOURCE. Hơn nữa, nó không override schema (vẫn cần WITH).

📘 Tài liệu tham khảo

• Chính thức Microsoft Docs (cập nhật 2025-2026):
  • OPENROWSET in Synapse serverless SQL pool ✅ (Ví dụ TSV với WITH clause).
  • Query TSV/CSV files 🛠️ (No header → dùng WITH).
• ExamTopics DP-203: Hình ảnh khớp Q#287, xác nhận đáp án WITH clause.
  ⚠️ Lưu ý: Dù câu hỏi Azure, kiến thức dựa trên phiên bản Synapse Analytics 2026 (không thay đổi core syntax). Sử dụng serverless pool để tránh dedicated pool setup.

🧩 Giải thích 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 cho SQL trong Azure Synapse). Bạn đang lập kế hoạch tạo một fact table tên Table1 sử dụng clustered columnstore index (CCI) – đây là loại index nén cột phân tán lý tưởng cho dữ liệu lớn, giúp tối ưu hóa nén dữ liệu (data compression) và hiệu suất truy vấn (query performance).

Vấn đề chính: Số lượng hàng (rows) tối thiểu mà Table1 nên có trước khi phân vùng (partition) để đạt hiệu quả tốt nhất.

• Partitioning giúp quản lý dữ liệu lớn bằng cách chia table thành các phần nhỏ hơn (dựa trên cột date hoặc key khác), hỗ trợ segment elimination (loại bỏ phân vùng không cần thiết khi query), cải thiện maintenance và performance.
• Tuy nhiên, với CCI, partitioning chỉ mang lại lợi ích khi mỗi partition có đủ dữ liệu (đủ rows để CCI nén hiệu quả, tránh overhead từ segment nhỏ). Nếu table quá nhỏ, partitioning có thể giảm performance thay vì tăng.
• Bối cảnh cập nhật 2026: Theo best practices mới nhất của Microsoft Azure Synapse (phiên bản dedicated SQL pool tích hợp AI optimizations), khuyến nghị partitioning khi table đạt quy mô lớn để cân bằng compression ratio (>75% lý tưởng) và query speed.

📘 Nguồn tham khảo:

• Microsoft Docs: Best practices for dedicated SQL pool - Partitioning (cập nhật 2024-2026).
• Synapse Analytics CCI Guidelines (khuyến nghị 60M rows/table trước partitioning).

✅ Đáp án đúng: 60 million

Lý do lựa chọn: Theo hướng dẫn chính thức của Microsoft, với dedicated SQL pool và CCI, bạn nên chờ table đạt ít nhất 60 triệu rows trước khi partition. Lúc này, table đủ lớn để partitioning mang lại lợi ích rõ rệt: mỗi partition có hàng triệu rows, hỗ trợ compression tối ưu (rowgroup đầy đủ 1M rows/rowgroup) và query performance cao qua segment pruning. Dưới mức này, CCI hoạt động tốt hơn mà không cần partition (tránh overhead metadata và maintenance). Đây là best practice để cân bằng scale-out và hiệu suất.

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

• 100,000 ❌
  Sai: Số lượng này quá nhỏ cho partitioning trong dedicated SQL pool. CCI cần rowgroups đầy (1M rows/rowgroup) để nén tốt; partition nhỏ sẽ tạo segment rỗng/sparse, làm giảm compression và tăng query latency. Best practice: Không partition table dưới 60M rows.

• 600,000 ❌
  Sai: Vẫn chưa đủ lớn. Table cỡ này partitioning sẽ gây overhead (quản lý nhiều partition nhỏ), không cải thiện performance mà còn làm chậm load/query. Microsoft khuyên dùng heap hoặc CCI không partition cho table nhỏ hơn 60M rows.

• 1 million ❌
  Sai: Gần với kích thước rowgroup lý tưởng (1M rows), nhưng vẫn chưa đạt ngưỡng partitioning. Partitioning ở mức này chỉ phù hợp nếu dữ liệu tăng trưởng nhanh; nếu không, nó làm phức tạp hóa mà không lợi ích rõ (compression kém hơn single partition lớn).

• 60 million ✅
  Đúng: Như đã giải thích, đây là ngưỡng tối thiểu khuyến nghị (Microsoft guideline). Table đạt 60M rows đảm bảo mỗi partition (ví dụ: hàng tháng) có đủ dữ liệu (~5M rows/partition nếu 12 partitions/năm), tối ưu compression (>75%) và query parallelism. Áp dụng cho workload data warehouse lớn.

🔍 Lưu ý thêm: Trong thực tế triển khai Azure Synapse (2026), dùng CREATE TABLE ... WITH (DISTRIBUTION = HASH(...), CLUSTERED COLUMNSTORE INDEX) và monitor qua DMVs như sys.dm_pdw_nodes_rowgroups. Nếu table vượt 60M, partition ngay để tránh hot spots!

🧩 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 (kiểm soát phiên bản) cho các thay đổi trên pipeline artifacts (các tài nguyên pipeline).

• Tình huống hiện tại: Bạn có một ADF tên ADF1, và tất cả thay đổi authoring (tạo/tùy chỉnh pipeline) đều được publish trực tiếp lên ADF1 mà không có version control.
• Yêu cầu giải pháp:
  • Áp dụng version control cho các tài nguyên hiện có trong UX Authoring canvas (giao diện thiết kế trực quan của ADF).
  • Đây là câu hỏi multi-select (chọn nhiều đáp án đúng), mỗi đáp án đúng trị giá 1 điểm.
• Mục tiêu chính: Kết nối ADF với Git repository để quản lý phiên bản, cho phép lưu thay đổi vào branch collaboration, tạo pull request, merge, và deploy an toàn. Giải pháp phải hỗ trợ tài nguyên hiện có trong canvas (không phải tạo mới).

🛠️ Kiến thức cập nhật (đến 2026): Theo tài liệu Azure Data Factory phiên bản mới nhất (v2.x với Git integration cải tiến hỗ trợ Azure DevOps và GitHub), quy trình chuẩn là liên kết repo Git từ UX và publish vào branch dev/collaboration. Không có thay đổi lớn từ 2024-2026, vẫn ưu tiên Azure Repos hoặc GitHub cho source control (xem tài liệu chính thức Microsoft).

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

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

• From the UX Authoring canvas, select Set up code repository.
• Create a Git repository.

Lý do:

• Để triển khai version control cho ADF1, bạn phải tạo Git repository trước (Azure Repos hoặc GitHub) làm nơi lưu trữ artifacts.
• Sau đó, từ UX Authoring canvas của ADF1, chọn Set up code repository để liên kết ADF với repo đó. Lệnh này sẽ sync tài nguyên hiện có từ canvas vào repo (import vào branch adf_publish hoặc collaboration branch), kích hoạt Git mode. Từ lúc này, mọi thay đổi sẽ được lưu versioned thay vì publish trực tiếp.

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

Dưới đây là phân tích từng phương án một cách chi tiết:

✅ From the UX Authoring canvas, select Set up code repository.
Đúng: Đây là bước cốt lõi để kích hoạt Git integration. Nó cho phép liên kết ADF1 với Git repo, tự động sync toàn bộ tài nguyên hiện có trong UX canvas (pipelines, datasets, triggers...) vào repo. Sau khi set up, bạn publish vào branch collaboration thay vì live workspace. (Nguồn: Azure Data Factory CI/CD docs)

✅ Create a Git repository.
Đúng: Bước đầu tiên bắt buộc. ADF yêu cầu một Git repo tồn tại (Azure DevOps Repos hoặc GitHub) trước khi liên kết. Repo này sẽ lưu trữ tất cả artifacts dưới dạng JSON files, hỗ trợ version control đầy đủ (branch, PR, merge). Không có repo thì không thể set up được.

❌ Create a GitHub action.
Sai: GitHub Actions dùng cho CI/CD automation (như build/deploy pipeline), không phải để thiết lập version control cơ bản cho ADF artifacts. Nó chỉ hữu ích sau khi đã có Git integration, ví dụ để auto-deploy sau merge PR. Không áp dụng cho yêu cầu sync tài nguyên hiện có.

❌ Create an Azure Data Factory trigger.
Sai: Trigger trong ADF dùng để chạy pipeline theo lịch/tự động (schedule, tumbling window...), không liên quan đến version control. Nó không giúp quản lý phiên bản artifacts hay sync với Git.

❌ From the UX Authoring canvas, select Publish.
Sai: Publish chỉ deploy thay đổi trực tiếp lên live workspace của ADF1, bỏ qua version control. Điều này chính là vấn đề hiện tại (publish trực tiếp), không giải quyết yêu cầu triển khai Git.

❌ From the UX Authoring canvas, run Publish All.
Sai: Tương tự Publish, Publish All chỉ push tất cả thay đổi pending lên live mà không versioned. Nó không tạo repo hay liên kết Git, vẫn giữ tình trạng "không có version control".

🆕 Lưu ý bổ sung: Sau khi thực hiện 2 bước đúng, bạn có thể migrate data hiện có và sử dụng feature branches cho dev. Nếu dùng Azure DevOps, tích hợp ARM templates cho deployment multi-env. Tham khảo hướng dẫn setup Git đầy đủ để tránh lỗi phổ biến như repo permissions. 🎯

🧩 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 xử lý Slowly Changing Dimension (SCD) Type 2 trong Azure Synapse Analytics sử dụng mapping data flow (Dataflow1) của một pipeline.

• Bối cảnh: Bảng DimSalesPerson là một bảng dimension trong dedicated SQL pool, chứa các cột: RepSourceID, SalesRepID, FirstName, LastName, StartDate, EndDate, Region. Đây là cấu trúc điển hình cho SCD Type 2, nơi StartDate và EndDate dùng để theo dõi lịch sử thay đổi (row hiện tại có EndDate = NULL hoặc ngày xa trong tương lai).

• Nhiệm vụ: Dataflow1 đọc dữ liệu sales team từ nguồn ngoài và áp dụng SCD Type 2 để load vào bảng. Cụ thể, cần update họ (LastName) của một salesperson.

• Yêu cầu hành động: Chọn hai hành động cần thực hiện để xử lý thay đổi này theo cơ chế SCD Type 2 (mỗi lựa chọn đúng đáng 1 điểm).

🛠️ Nguyên lý SCD Type 2 (cập nhật đến phiên bản Azure Synapse Analytics mới nhất 2024-2026): Khi thuộc tính thay đổi (như LastName), KHÔNG overwrite row hiện tại. Thay vào đó:

• Update row cũ: Đánh dấu kết thúc hiệu lực bằng cách set EndDate = ngày hiện tại (chỉ 1 cột thay đổi chính).
• Insert row mới: Với dữ liệu cập nhật, StartDate = ngày hiện tại, EndDate = NULL (hoặc 9999-12-31).

📘 Nguồn tham khảo:

• Microsoft Docs: Slowly changing dimensions in mapping data flow (cập nhật 2024).
• Azure Synapse Analytics: Mapping data flow SCD Type 2 (hỗ trợ surrogate key và hiệu suất tối ưu hóa đến 2026).

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

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

• Insert an extra row.
• Update one column of an existing row.

Lý do (🧩 Phân tích logic SCD Type 2):

• Để update LastName, phải tạo lịch sử đầy đủ: Update chỉ 1 cột (EndDate) trên row cũ để "kết thúc" phiên bản cũ, sau đó insert row mới với LastName mới + các cột tracking date. Điều này đảm bảo truy vấn lịch sử chính xác (ví dụ: WHERE StartDate <= @date AND EndDate >= @date). Mapping data flow tự động xử lý qua SCD Type 2 sink transformation.

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

• ❌ Update three columns of an existing row.
  Sai: SCD Type 2 KHÔNG update nhiều cột trên row cũ (như LastName + StartDate/EndDate + Region). Việc update 3 cột sẽ phá hủy lịch sử, biến thành SCD Type 1 (overwrite). Mapping data flow không hỗ trợ cách này cho Type 2.

• ❌ Update two columns of an existing row.
  Sai: Tương tự, update 2 cột (ví dụ EndDate + LastName) vẫn là overwrite một phần, không tạo row mới. Điều này vi phạm nguyên tắc SCD Type 2, dẫn đến mất dữ liệu lịch sử và không khớp với cấu hình data flow.

• ✅ Insert an extra row.
  Đúng: Bắt buộc insert row mới với dữ liệu cập nhật (LastName mới, StartDate hiện tại, EndDate NULL). Dataflow1 sử dụng SCD sink để tự động generate surrogate key (RepSourceID) và duplicate row hiện tại làm base cho row mới.

• ✅ Update one column of an existing row.
  Đúng: Chỉ update EndDate trên row cũ (match qua SalesRepID hoặc business key) để đánh dấu "hết hiệu lực". Đây là bước chuẩn trong SCD Type 2, giữ nguyên các cột khác (FirstName cũ, LastName cũ, v.v.) cho lịch sử.

🛠️ Lưu ý thực hành: Trong Dataflow1, cấu hình Sink transformation với SCD Type 2, chọn business key (SalesRepID), changing attributes (LastName), và enable "Mark expired rows" để tự động update EndDate. Test trên dedicated SQL pool để đảm bảo hiệu suất với DWU scale-out (cập nhật 2026).

🧩 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 xoay quanh Azure Synapse Analytics, cụ thể là một dedicated SQL pool có tên SQLPool1 đang ở trạng thái paused (tạm dừng để tiết kiệm chi phí). Nhiệm vụ là restore (khôi phục) trạng thái hiện tại của SQLPool1 sang một SQL pool mới.
🛠️ Yêu cầu chính: Xác định bước đầu tiên cần thực hiện để đạt được mục tiêu này. Trong Azure Synapse, dedicated SQL pools hỗ trợ pause/resume, restore points (điểm khôi phục), và clone/restore sang pool mới. Tuy nhiên, khi pool đang paused, nhiều hoạt động như tạo restore point hoặc clone yêu cầu pool phải ở trạng thái running (đang chạy). Do đó, câu hỏi kiểm tra kiến thức về quy trình xử lý pool paused trước khi thực hiện restore/clone.

📘 Kiến thức cập nhật (đến 2026): Theo tài liệu Azure Synapse Analytics phiên bản mới nhất (Synapse workspace với SQL pools hỗ trợ auto-pause và advanced restore features), để restore hoặc clone một dedicated SQL pool paused, bước đầu tiên bắt buộc là resume pool để kích hoạt metadata và data snapshots. Không có thay đổi lớn từ 2023-2026 về quy trình này.

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

• Azure Synapse SQL Pool Restore
• Pause and Resume SQL Pools
• Clone a SQL Pool

✅ Đáp án đúng: Resume SQLPool1

Lý do lựa chọn:
Khi SQLPool1 đang paused, bạn không thể tạo restore point, clone hoặc restore trực tiếp vì hệ thống cần truy cập metadata và data hiện tại (current state). Bước đầu tiên bắt buộc là resume (khởi động lại) pool để đưa nó về trạng thái running. Sau đó, bạn có thể sử dụng tính năng Clone hoặc Restore to new pool từ automatic restore point (tự động tạo mỗi 8 giờ) hoặc geo-restore. Điều này đảm bảo dữ liệu hiện tại được snapshot và copy sang pool mới mà không mất mát.

🛠️ Giải thích tất cả các phương án (Đúng/Sai với lý do chi tiết):

• ❌ Create a workspace.
  Sai vì: Workspace đã tồn tại (SQLPool1 thuộc một workspace hiện có). Tạo workspace mới không liên quan đến việc restore pool paused; đây chỉ là container cấp cao, không kích hoạt restore process. Restore/clone phải thực hiện trong cùng workspace hoặc cross-workspace qua export/import.

• ❌ Create a user-defined restore point.
  Sai vì: Không thể tạo user-defined restore point khi pool đang paused. Tính năng này yêu cầu pool ở trạng thái running để snapshot dữ liệu. Nếu paused, hệ thống chỉ có automatic restore points từ trước khi pause, nhưng để restore current state chính xác, phải resume trước rồi mới tạo point mới.

• ✅ Resume SQLPool1.
  Đúng vì: Đây là bước đầu tiên và bắt buộc. Resume kích hoạt pool, làm cho current state (dữ liệu, schema) khả dụng để clone hoặc restore sang pool mới qua portal/PowerShell/CLI. Sau resume, dùng lệnh như New-AzSynapseSqlPool -WorkspaceName ... -Name NewPool -ComputePerformance DW100c -RestorePointName ....

• ❌ Create a new SQL pool.
  Sai vì: Tạo pool mới chỉ tạo một empty pool trống, không restore dữ liệu từ SQLPool1. Để có "current state" (dữ liệu hiện tại), cần resume trước rồi clone/restore; nếu không, pool mới sẽ không chứa dữ liệu từ pool paused.

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

Câu hỏi yêu cầu thiết kế một Azure Synapse Analytics workspace và đề xuất giải pháp để cung cấp double encryption (mã hóa kép) cho tất cả dữ liệu tại chỗ nghỉ (data at rest).

• Double encryption ở đây nghĩa là áp dụng hai lớp mã hóa độc lập:
  1. Infrastructure encryption (mã hóa cơ sở hạ tầng do Microsoft quản lý mặc định, nhưng có thể dùng CMK - Customer-Managed Key).
  2. Transparent Data Encryption (TDE) cho SQL pools (dùng CMK khác).
• Đây là câu hỏi multiple correct answers (mỗi đáp án đúng 1 điểm), cần chọn hai thành phần để kích hoạt tính năng này.
• Bối cảnh: Azure Synapse Analytics hỗ trợ double encryption từ các phiên bản mới nhất (cập nhật đến 2026), yêu cầu sử dụng Azure Key Vault với purge protection và RSA key cho CMK để đảm bảo an toàn dữ liệu.
  📘 Tài liệu tham khảo:
• Azure Synapse Analytics - Encryption at rest (cập nhật 2024-2026).
• Double encryption for Synapse dedicated SQL pools.

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

Hai đáp án đúng là:
🛠️ an RSA key: Đây là loại khóa mã hóa bắt buộc (RSA 2048-bit hoặc cao hơn) dùng cho cả infrastructure encryption và TDE protector trong Synapse. Không dùng key khác như EC để đảm bảo tương thích double encryption.
🛠️ an Azure key vault that has purge protection enabled: Key Vault phải bật purge protection (cùng soft-delete) để ngăn xóa vĩnh viễn key, đảm bảo dữ liệu không bị mất mã hóa. Đây là yêu cầu bắt buộc cho CMK trong double encryption Synapse.

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

• ❌ an X.509 certificate: Phương án sai vì X.509 certificate dùng cho xác thực (authentication) như TLS/SSL, không phải khóa mã hóa dữ liệu at rest trong Synapse. Double encryption yêu cầu RSA key trong Key Vault, không phải certificate.
• ✅ an RSA key: Phương án đúng vì RSA key (ít nhất 2048-bit) là loại khóa chuẩn cho CMK trong Azure Synapse, áp dụng cho cả hai lớp mã hóa (infrastructure và TDE). Tài liệu AWS không liên quan, đây là tính năng Azure thuần túy.
• ❌ an Azure virtual network that has a network security group (NSG): Phương án sai vì VNet + NSG chỉ kiểm soát network traffic (bảo mật kết nối), không liên quan đến mã hóa dữ liệu at rest. Double encryption tập trung vào storage encryption, không phải networking.
• ❌ an Azure Policy initiative: Phương án sai vì Azure Policy dùng cho governance và compliance (enforce rules), không trực tiếp cung cấp mã hóa. Nó có thể giám sát nhưng không phải thành phần cốt lõi cho double encryption.
• ✅ an Azure key vault that has purge protection enabled: Phương án đúng vì Key Vault lưu trữ CMK phải bật purge protection (90 ngày giữ soft-deleted keys) để tránh mất key dẫn đến dữ liệu không giải mã được. Bắt buộc cho Synapse double encryption theo docs 2026.

🧩 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 serverless SQL pool (tên là Pool1) và Azure Data Lake Storage Gen2 (tên là storage1), với thuộc tính AllowBlobPublicAccess bị tắt (disabled). Điều này có nghĩa là tài khoản storage không cho phép truy cập công khai qua blob public, nên cần cơ chế xác thực an toàn để Azure Active Directory (Azure AD) users có thể truy cập dữ liệu từ storage1 thông qua Pool1.

📌 Mục tiêu chính: Tạo một external data source để kết nối và truy vấn dữ liệu từ ADLS Gen2. Tuy nhiên, câu hỏi nhấn mạnh "What should you create first?" (Tạo gì trước tiên?), nghĩa là bước đầu tiên cần thiết trước khi tạo external data source.

🛠️ Bối cảnh kỹ thuật (dựa trên tài liệu Azure Synapse mới nhất đến năm 2024-2026):

• Serverless SQL pool không hỗ trợ truy cập anonymous/public khi AllowBlobPublicAccess = false.
• Để Azure AD users truy cập, cần sử dụng Managed Identity của Synapse workspace hoặc Service Principal, nhưng bắt buộc phải tạo database-scoped credential trước để lưu trữ thông tin xác thực.
• Sau credential, mới tạo external data source với cú pháp: CREATE EXTERNAL DATA SOURCE ... WITH (CREDENTIAL = [credential_name]).

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

Đáp án đúng: database scoped credentials

🧠 Lý do chi tiết:

• Đây là bước bắt buộc đầu tiên để thiết lập xác thực cho external data source khi truy cập ADLS Gen2 private.
• Sử dụng lệnh CREATE DATABASE SCOPED CREDENTIAL [credential_name] WITH IDENTITY = 'Managed Identity'; (hoặc Service Principal với SECRET).
• Credential này cho phép Synapse serverless SQL pool sử dụng Managed Identity của workspace để authenticate với Azure AD, đảm bảo an toàn mà không cần SAS token công khai.
• Chỉ sau khi có credential, mới có thể tạo external data source: CREATE EXTERNAL DATA SOURCE ... LOCATION = 'abfss://...@storage1.dfs.core.windows.net/', CREDENTIAL = [credential_name];.
• Điều này phù hợp với best practice bảo mật của Azure Synapse (không role assignment trực tiếp lên storage cho public access).

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

• ❌ an external resource pool
  Sai vì: External resource pool dùng cho Spark pools trong Synapse để quản lý tài nguyên compute (như executor cores, memory) khi chạy Spark jobs. Không liên quan đến truy cập external storage từ serverless SQL pool. Đây là tính năng riêng cho on-demand Spark, không phải authentication cho SQL queries.

• ❌ an external library
  Sai vì: External library dùng để upload và quản lý thư viện Python/R/Java (.whl, .jar) cho Spark jobs trong Synapse workspaces. Không hỗ trợ tạo external data source hoặc xác thực storage. Chỉ dùng cho custom code execution, không phải kết nối dữ liệu.

• ✅ database scoped credentials
  Đúng vì: Như đã giải thích ở trên, đây là bước đầu tiên và bắt buộc để lưu trữ thông tin xác thực (Managed Identity hoặc Service Principal) cho external data source. Synapse serverless SQL pool yêu cầu credential này để Azure AD users truy cập ADLS Gen2 private mà không cần public access. Hỗ trợ T-SQL syntax an toàn, scoped chỉ trong database.

• ❌ a remote service binding
  Sai vì: Remote service binding dùng cho SQL Server external tables kết nối với remote SQL endpoints (như Azure SQL Database) qua OLE DB providers. Không áp dụng cho ADLS Gen2 (file-based storage). Đây là tính năng legacy/on-prem, không dùng trong Synapse serverless cho blob storage.

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

• Microsoft Docs: Create external data source - Azure Synapse Analytics (hướng dẫn credential trước data source).
• Microsoft Docs: Database-scoped credentials for serverless SQL pool.
• Azure Storage security: Disable public access.
• Best practices từ Azure Well-Architected Framework: Sử dụng Managed Identity cho Synapse + ADLS (2024 updates).

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần ví dụ T-SQL code, 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, một dịch vụ phân tích dữ liệu tích hợp của Microsoft Azure. Cụ thể:

• Bạn có một workspace Azure Synapse Analytics tên WS1, chứa một Apache Spark pool tên Pool1 (có thể là Spark pool on-demand hoặc provisioned).
• Kế hoạch: Tạo một database tên DB1 trong Pool1.
• Yêu cầu chính: Khi tạo các tables trong DB1, những tables này phải tự động được expose (có sẵn) dưới dạng external tables cho built-in serverless SQL pool của workspace (không cần cấu hình thủ công).
• Vấn đề cốt lõi: Chọn file format phù hợp cho các tables trong DB1 để đạt được tính năng tích hợp tự động giữa Spark pool và serverless SQL pool.

📘 Ngữ cảnh kỹ thuật: Trong Azure Synapse, Spark pools hỗ trợ tạo managed tables (bảng được quản lý bởi Spark). Để chúng tự động trở thành external tables trong serverless SQL pool (cho phép query qua T-SQL), tables phải sử dụng định dạng Parquet. Điều này dựa trên cơ chế integration tự động của Synapse, giúp dữ liệu Spark dễ dàng truy cập từ SQL mà không cần CREATE EXTERNAL TABLE thủ công.

🛠️ Kiến thức cập nhật (đến 2026): Theo tài liệu Azure Synapse Analytics phiên bản mới nhất (Spark 3.4+ trong Synapse runtime 1.0xx), tính năng này vẫn giữ nguyên: Chỉ Parquet managed tables từ Spark được tự động register làm external tables trong serverless SQL pool.

📚 Nguồn tham khảo:

• Apache Spark tables in Azure Synapse Analytics (Microsoft Docs, cập nhật 2024).
• Query Spark tables from serverless SQL pool (xem phần "Spark Parquet tables").

✅ Đáp án đúng: Parquet

Lý do lựa chọn:

• Khi tạo managed tables trong database Spark (như DB1) với định dạng Parquet, Azure Synapse tự động đăng ký chúng làm external tables trong serverless SQL pool của workspace.
• Điều này cho phép query trực tiếp qua T-SQL mà không cần script bổ sung (ví dụ: SELECT * FROM db1.table1).
• Parquet là columnar storage format tối ưu cho analytics, hỗ trợ schema evolution và tích hợp native với Synapse.

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

• ✅ Parquet
  Đúng: Đây là định dạng duy nhất được Azure Synapse hỗ trợ tự động expose managed Spark tables thành external tables cho serverless SQL pool. Không cần cấu hình LOCATION hay credential thủ công. Tính năng này giúp seamless integration giữa Spark (ETL/processing) và SQL (querying).

• ❌ ORC
  Sai: ORC (Optimized Row Columnar) là định dạng tốt cho Hive/Spark, hỗ trợ compression và predicate pushdown. Tuy nhiên, Synapse không tự động register ORC tables từ Spark làm external tables trong serverless SQL pool. Bạn phải tạo external table thủ công với CREATE EXTERNAL TABLE.

• ❌ JSON
  Sai: JSON là định dạng semi-structured, dễ đọc nhưng kém hiệu suất cho large-scale analytics (không columnar, schema inference phức tạp). Synapse không hỗ trợ tự động expose JSON tables từ Spark thành external tables; cần parse thủ công qua OPENROWSET hoặc tạo external table riêng.

• ❌ HIVE
  Sai: "HIVE" ám chỉ Hive SerDe format (thường là text-based với Hive metastore). Spark hỗ trợ Hive tables, nhưng Synapse không tự động làm chúng thành external tables cho serverless SQL pool. Hive format thiếu columnar efficiency và yêu cầu metastore sync thủ công (không native integration).

🧩 Lưu ý cuối: Chọn Parquet không chỉ đáp ứng yêu cầu tự động mà còn tối ưu performance (partitioning, ACID với Delta Lake nếu kết hợp). Nếu dùng Delta Lake trên Parquet, tính năng vẫn hoạt động tương tự! 🚀

🧩 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 Data Factory (ADF) khi sử dụng tích hợp Git để quản lý mã nguồn (source control):

• Bạn có pipeline tên Pipeline1 chứa copy activity để copy dữ liệu từ nguồn vào Azure Data Lake Storage Gen2 (ADLS Gen2).
• Pipeline này được kích hoạt bởi schedule trigger (lịch trình định kỳ).
• Bạn thay đổi sink (điểm đến) của copy activity sang một storage account mới, sau đó merge các thay đổi vào collaboration branch (nhánh hợp tác dùng để phát triển).
• Sau khi Pipeline1 chạy (do trigger kích hoạt), dữ liệu KHÔNG được copy vào storage account mới.
• Vấn đề cốt lõi: Thay đổi chưa được triển khai (deploy) lên môi trường live/production, nên pipeline chạy phiên bản cũ.
• Mục tiêu: Đảm bảo dữ liệu được copy vào storage account mới cho các lần chạy tiếp theo.

🛠️ Nguyên nhân gốc rễ: Trong ADF với Git integration (phiên bản mới nhất 2024-2026), thay đổi chỉ lưu trong Git repo (collaboration branch) sau khi merge. Để active live, phải Publish từ collaboration branch, tạo/cập nhật branch adf_publish – đây là branch ARM template deploy thực tế cho factory live.

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

• Azure Data Factory CI/CD with Git (cập nhật 2024).
• Source control in Azure Data Factory (giải thích quy trình Publish từ collaboration branch).

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

Đáp án đúng: Publish from the collaboration branch.

Lý do:

• Sau khi merge thay đổi vào collaboration branch, ADF chưa tự động deploy. Việc Publish từ branch này sẽ generate ARM template trên branch adf_publish, deploy changes live vào factory.
• Lúc này, lần chạy Pipeline1 tiếp theo (do schedule trigger) sẽ sử dụng copy activity với sink mới → dữ liệu copy đúng storage account mới.
• Đây là bước bắt buộc theo quy trình CI/CD chuẩn của ADF Git (không cần redeploy toàn bộ factory).

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

• ✅ Publish from the collaboration branch.
  Đúng vì: Như đã giải thích, Publish là bước cuối cùng để sync thay đổi từ collaboration branch sang live environment qua adf_publish branch. Không Publish thì factory vẫn chạy code cũ, dù Git đã update. Giải quyết chính xác vấn đề mà không ảnh hưởng trigger hoặc storage.

• ❌ Create a pull request.
  Sai vì: Câu hỏi đã nêu "merge the changes into the collaboration branch" → thay đổi đã được merge, không cần tạo PR nữa. PR chỉ dùng để review/merge giữa branches (ví dụ: feature → collaboration), nhưng ở đây focus vào deploy live.

• ❌ Modify the schedule trigger.
  Sai vì: Schedule trigger chỉ kiểm soát thời gian chạy pipeline, không ảnh hưởng đến nội dung pipeline (như sink của copy activity). Trigger vẫn fire bình thường nhưng dùng version cũ → dữ liệu vẫn sai vị trí. Modify trigger (ví dụ: interval, timezone) vô ích.

• ❌ Configure the change feed of the new storage account.
  Sai vì: Change feed là tính năng event-driven của ADLS Gen2 để capture delta changes (dùng với Stream Analytics hoặc ADF event trigger), không liên quan đến copy activity sink. Sink chỉ cần linked service đúng, không cần config change feed để nhận data.

🛠️ Lời khuyên thực hành: Luôn kiểm tra branch hiện tại trong ADF UI (Live vs. Collaboration), Publish sau merge, và test bằng Debug/Trigger Now trước production! 🚀