Ngân hàng đề — Microsoft Azure Database Administrator

🧩 Giải thích nội dung câu hỏi

Câu hỏi thuộc dạng case study (phần của loạt câu hỏi cùng scenario), tập trung vào việc triển khai disaster recovery (DR) cho cơ sở dữ liệu Azure SQL có tên Sales. Các yêu cầu cụ thể:

• Trong hoạt động bình thường, phải cung cấp ít nhất hai bản sao có thể đọc được (readable copies) của Sales (nghĩa là có thể dùng cho workload đọc, không chỉ primary read-write).
• Đảm bảo Sales vẫn khả dụng nếu một datacenter thất bại (datacenter ở đây thường ám chỉ Availability Zone - AZ trong Azure, vì Azure SQL được thiết kế HA qua zone-redundancy).

Giải pháp đề xuất (Solution): Triển khai (deploy) một Azure SQL database sử dụng General Purpose service tier và failover groups.

Câu hỏi: Giải pháp này có đáp ứng mục tiêu không? (Yes/No).

📘 Lưu ý từ Azure docs (cập nhật 2024-2026): General Purpose tier hỗ trợ failover groups cho geo-DR (cross-region), với secondary replica readable ở region khác. Tuy nhiên, không hỗ trợ read scale-out (multiple readable replicas local trong primary region). Zone-redundancy phải enable riêng cho HA qua AZ failure. Failover groups chủ yếu cho region failure, không tự động failover khi AZ fail ở primary region.

✅ Đáp án đúng: No

Lý do lựa chọn:

• Giải pháp không triển khai DR cho Sales hiện có, mà chỉ mô tả "deploy an Azure SQL database" mới ở General Purpose + failover groups. Không đề cập cấu hình Sales (primary) vào failover group, tạo secondary replica cho nó, hoặc enable zone-redundancy. Kết quả: Không tạo ít nhất hai readable copies cho Sales, và không đảm bảo availability khi datacenter (AZ) fail ở primary region (chỉ xử lý region fail).
• General Purpose không hỗ trợ read scale-out local (chỉ có ở Business Critical/Hyperscale), nên chỉ có 1 readable copy local (primary). Geo-secondary (nếu có) là remote, latency cao, không tính là "normal operations" multiple copies hiệu quả.
• Không đáp ứng đầy đủ hai yêu cầu DR.

🛠️ Nguồn tham khảo:

• Azure SQL Auto-failover groups (hỗ trợ tất cả tier, nhưng secondary readable chỉ cross-region).
• Service tiers - General Purpose (no read scale-out; zone-redundancy optional).
• High availability & DR (AZ failure cần zone-redundant; datacenter outage thường = AZ).

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

• Yes ❌ SAI: Giải pháp KHÔNG đáp ứng vì:

  • Chỉ "deploy một DB mới" ở General Purpose + failover groups, không liên kết/triển khai DR trực tiếp cho Sales hiện có (không tạo secondary replica cho Sales).
  • General Purpose thiếu read scale-out → chỉ 1 readable copy local (primary), geo-secondary (nếu tạo) không đủ "at least two readable copies" trong normal operations hiệu quả (không local, không load-balance reads).
  • Không đảm bảo availability khi datacenter (AZ) fail: Failover groups chỉ auto-failover region-wide outage, không AZ; cần zone-redundant riêng (không đề cập).

• No ✅ ĐÚNG: Như giải thích trên, giải pháp không chính xác implement DR cho Sales, thiếu multiple readable copies local và full HA cho AZ failure. Cần giải pháp như Business Critical tier (với read scale-out + zone-redundant) + failover groups, hoặc Hyperscale.

🧩 Tóm tắt nhanh: Giải pháp mơ hồ, không target Sales, và General Purpose hạn chế về readable replicas → Không meet goal! Để đúng, cần cấu hình chính xác cho Sales với tier hỗ trợ read scale-out + full redundancy.

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

Câu hỏi tập trung vào việc thay đổi mật khẩu (password) cho private key của một private certificate có tên là Sales trong cơ sở dữ liệu Azure SQL tên DB1. Certificate này đang lưu trữ private key được mã hóa bằng một mật khẩu cũ. Để thay đổi mật khẩu, chúng ta cần sử dụng câu lệnh Transact-SQL (T-SQL) phù hợp với cú pháp ALTER CERTIFICATE.

📘 Chi tiết ngữ cảnh:

• Private certificate trong Azure SQL (dựa trên SQL Server engine) được sử dụng để mã hóa dữ liệu, ký số, hoặc các mục đích bảo mật khác.
• Private key của certificate được mã hóa bằng password để bảo vệ.
• Để thay đổi password, phải giải mã (DECRYPTION) bằng password cũ và mã hóa lại (ENCRYPTION) bằng password mới trong cùng một câu lệnh ALTER.
• Đây là tính năng chuẩn của SQL Server từ các phiên bản cũ đến mới nhất (SQL Server 2022 và Azure SQL Database cập nhật đến 2026), không có thay đổi lớn về syntax này.

🛠️ Mục tiêu: Chọn câu lệnh T-SQL chính xác để thực hiện thay đổi mà không làm mất dữ liệu hoặc gây lỗi syntax.

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

Đáp án đúng: ALTER CERTIFICATE Sales WITH PRIVATE KEY (DECRYPTION BY PASSWORD = 'Mb^68K&*w%'), ENCRYPTION BY PASSWORD = ' 6YY9YcD!pV');

Lý do:

• Cú pháp hoàn chỉnh: Sử dụng DECRYPTION BY PASSWORD để chỉ định password cũ ('Mb^68K&w%') nhằm giải mã private key hiện tại, sau đó ENCRYPTION BY PASSWORD để mã hóa lại bằng password mới ('6YY9YcD!pV').
• Dấu phẩy (,) giữa hai clause là bắt buộc theo syntax chính thức.
• Lưu ý: '&' trong câu hỏi là mã HTML cho ký tự '&', nên password cũ thực tế là 'Mb^68K&w%'.
• Câu lệnh này sẽ thành công mà không cần file ngoài hoặc các bước trung gian, phù hợp với Azure SQL (hỗ trợ đầy đủ master key và certificate management).

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

• Phương án 1 ❌
  ALTER CERTIFICATE Sales WITH PRIVATE KEY (DECRYPTION BY PASSWORD = ' EWYx9Xk+$#');
  Sai vì: Chỉ có DECRYPTION BY PASSWORD (giải mã bằng password giả định là cũ), nhưng thiếu ENCRYPTION BY PASSWORD để mã hóa lại bằng password mới. Kết quả: Câu lệnh sẽ thất bại vì SQL Server yêu cầu cả hai clause khi thay đổi password cho private key hiện có (không phải import mới).

• Phương án 2 ❌
  ALTER CERTIFICATE Sales WITH PRIVATE KEY (ENCRYPTION BY PASSWORD = ' 6YY9YcD!pV');
  Sai vì: Chỉ có ENCRYPTION BY PASSWORD (mã hóa bằng password mới), nhưng thiếu DECRYPTION BY PASSWORD để giải mã private key cũ. SQL Server không thể truy cập private key mà không giải mã trước, dẫn đến lỗi "Cannot find the certificate" hoặc tương tự.

• Phương án 3 ✅ (Đúng)
  ALTER CERTIFICATE Sales WITH PRIVATE KEY (DECRYPTION BY PASSWORD = 'Mb^68K&*w%'), ENCRYPTION BY PASSWORD = ' 6YY9YcD!pV');
  Đúng vì: Kết hợp chính xác DECRYPTION BY PASSWORD (password cũ) và ENCRYPTION BY PASSWORD (password mới), với dấu phẩy phân cách. Đây là syntax chuẩn để thay đổi password trực tiếp cho private key mà không cần export/import file.

• Phương án 4 ❌
  ALTER CERTIFICATE Sales WITH PRIVATE KEY (FILE = 'D:\importkeys\SalesNew, (DECRYPTION BY PASSWORD = ' Mb^68K&*w%');
  Sai vì: Sử dụng FILE để import certificate từ file ngoài ('D:\importkeys\SalesNew'), không phải thay đổi password cho certificate hiện có. Syntax cũng lỗi (dấu phẩy thừa và ngoặc không đóng đúng). Phương án này dùng cho trường hợp import certificate mới, không phù hợp với yêu cầu "change the password".

📚 Tài liệu tham khảo

• Microsoft Docs chính thức (cập nhật 2024-2026): ALTER CERTIFICATE (Transact-SQL) – Xác nhận syntax đầy đủ cho việc thay đổi private key password.
• Azure SQL Security Guide: Certificates in Azure SQL Database – Hỗ trợ đầy đủ tính năng này từ Azure SQL Managed Instance và Hyperscale.
• SQL Server 2022 Reference: Không thay đổi syntax từ phiên bản 2016 trở lên.

🛡️ Lưu ý từ Azure DBA: Luôn backup certificate/master key trước khi ALTER, và chạy lệnh trong context database đúng (USE DB1). Nếu gặp lỗi, kiểm tra service master key bằng SELECT * FROM sys.certificates.

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

✅ Nội dung câu hỏi được giải thích rõ ràng:
Câu hỏi mô tả tình huống bạn đang quản lý một Azure Synapse Analytics Apache Spark pool có tên là Pool1. Bạn cần load các file JSON từ một container Azure Data Lake Storage Gen2 vào các bảng trong Pool1. Đặc biệt, cấu trúc (schema) và kiểu dữ liệu (data types) của các file JSON thay đổi khác nhau giữa các file. Yêu cầu giải pháp phải giữ nguyên kiểu dữ liệu nguồn (maintain the source data types) mà không bị thay đổi hoặc ép kiểu.
🛠️ Mục tiêu chính: Tìm cách load dữ liệu linh hoạt, hỗ trợ schema inference tự động cho JSON với cấu trúc biến thiên, và đảm bảo tương thích với Spark pool trong Azure Synapse Analytics (phiên bản mới nhất đến 2026 vẫn giữ nguyên cách tiếp cận này).

🟢 Đáp án đúng: Load the data by using PySpark.
📘 Lý do lựa chọn chi tiết:
PySpark là ngôn ngữ lập trình chính thức và mạnh mẽ nhất cho Apache Spark pools trong Azure Synapse Analytics. Nó hỗ trợ đọc file JSON từ Azure Data Lake Storage Gen2 qua spark.read.json() với các tùy chọn như mergeSchema=true để tự động suy luận và hợp nhất schema từ nhiều file có cấu trúc khác nhau. Điều này đảm bảo giữ nguyên data types nguồn (như string, int, array, struct) mà không bị ép kiểu mặc định. Spark pools được thiết kế dành riêng cho xử lý dữ liệu lớn, schema-on-read linh hoạt, phù hợp hoàn hảo với yêu cầu. (Cập nhật đến 2026: Azure Synapse Spark runtime 3.4+ vẫn ưu tiên PySpark cho workload này).

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

✅ Load the data by using PySpark
🟢 Đúng vì: PySpark cho phép load JSON trực tiếp vào Spark DataFrame với schema inference động (spark.read.option("multiline", true).option("mergeSchema", true).json(path)), xử lý được cấu trúc và data types biến thiên từ nhiều file, và ghi vào bảng Delta/Parquet trong Spark pool mà không thay đổi data types nguồn. Hoàn hảo cho Azure Synapse Spark pool.
📘 Nguồn: Azure Docs - Load JSON into Spark & Spark JSON options.

❌ Load the data by using the OPENROWSET Transact-SQL command in an Azure Synapse Analytics serverless SQL pool
🔴 Sai vì: OPENROWSET chỉ dùng trong serverless SQL pool (không phải Spark pool), và mặc định ép kiểu dữ liệu JSON sang SQL types (varchar, bigint...), không hỗ trợ schema biến thiên phức tạp mà không cần CETAS hoặc external tables. Không tương thích với Spark pool Pool1 và không maintain data types nguồn một cách linh hoạt.
📘 Nguồn: Azure Docs - OPENROWSET for serverless.

❌ Use a Get Metadata activity in Azure Data Factory
🔴 Sai vì: Get Metadata chỉ lấy thông tin metadata (như kích thước file, schema cơ bản) chứ không load dữ liệu thực tế vào bảng. Nó hữu ích để kiểm tra trước khi load nhưng không thực hiện việc ingest data vào Spark pool, và không xử lý data types JSON phức tạp.
📘 Nguồn: Azure Data Factory - Get Metadata.

❌ Use a Conditional Split transformation in an Azure Synapse data flow
🔴 Sai vì: Conditional Split là transformation trong Synapse Data Flow (dùng để phân nhánh dữ liệu dựa trên điều kiện sau khi source đã được load), không phải công cụ load JSON ban đầu. Data Flow yêu cầu định nghĩa schema cố định trước, không linh hoạt với cấu trúc biến thiên, và không maintain data types nguồn tự động mà cần mapping thủ công. Không phù hợp trực tiếp cho Spark pool tables.
📘 Nguồn: Synapse Data Flow - Transformations.

🛠️ Kết luận: PySpark là lựa chọn tối ưu, tận dụng sức mạnh Spark cho big data JSON linh hoạt trong Azure Synapse (cập nhật 2026: Tích hợp tốt hơn với Unity Catalog cho governance). Nếu triển khai, sử dụng notebook Spark để test! 🚀

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

Câu hỏi xoay quanh một giải pháp dữ liệu Azure sử dụng Azure Synapse Analytics (data warehouse có tên DW1).

• Tình huống: Nhiều người dùng chạy adhoc queries (các truy vấn ngẫu hứng, không theo lịch) đồng thời trên DW1. Đồng thời, hệ thống thường xuyên thực hiện automated data loads (tải dữ liệu tự động).
• Vấn đề cần giải quyết: Đảm bảo các automated data loads có đủ bộ nhớ (memory) để hoàn thành nhanh chóng và thành công, ngay cả khi các adhoc queries đang chạy song song.
• Bối cảnh kỹ thuật (cập nhật đến 2026): Trong Azure Synapse Analytics dedicated SQL pools (phiên bản mới nhất), tài nguyên như bộ nhớ được quản lý qua resource classes (lớp tài nguyên) hoặc workload management (quản lý workload). Khi nhiều queries chạy đồng thời, tài nguyên bị chia sẻ, dẫn đến data loads có thể thiếu memory nếu không được ưu tiên. Giải pháp cần tập trung vào việc phân bổ tài nguyên động để ưu tiên data loads.

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

• Azure Synapse Analytics - Workload management (cập nhật 2024-2026).
• Resource classes in Synapse (phiên bản mới nhất hỗ trợ dynamic resource allocation).

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

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

Lý do:
🛠️ Trong Azure Synapse Analytics, resource class lớn hơn (như largerc, xlargerc) cấp phát nhiều bộ nhớ hơn (memory) và CPU cho query cụ thể. Khi adhoc queries (thường dùng resource class mặc định nhỏ) chạy đồng thời, data loads cần resource class lớn để tránh tranh chấp tài nguyên, đảm bảo hoàn thành nhanh và thành công. Điều này phù hợp với workload isolation trong Synapse (cập nhật 2026), giúp data loads được ưu tiên mà không ảnh hưởng toàn bộ pool.

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

Dưới đây là phân tích từng lựa chọn, giữ nguyên nội dung gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên cơ chế hoạt động của Azure Synapse Analytics:

• ❌ [SAI] Assign a smaller resource class to the automated data load queries.
  🧩 Giải thích sai: Resource class nhỏ hơn (như smallrc) sẽ giảm bộ nhớ và tài nguyên cấp cho data loads, làm chúng chậm hơn và dễ thất bại khi tranh chấp với adhoc queries. Điều này ngược hoàn toàn với yêu cầu cần "đủ memory để hoàn thành nhanh".

• ❌ [SAI] Create sampled statistics to every column in each table of DW1.
  🧩 Giải thích sai: Sampled statistics (thống kê mẫu) giúp query optimizer lập kế hoạch tốt hơn cho adhoc queries, cải thiện hiệu suất truy vấn đọc. Tuy nhiên, nó không ảnh hưởng trực tiếp đến memory cho data loads (chủ yếu là INSERT/LOAD operations). Tạo stats cho mọi cột còn tốn thời gian maintain và không giải quyết tranh chấp tài nguyên đồng thời.

• ✅ [ĐÚNG] Assign a larger resource class to the automated data load queries.
  🧩 Giải thích đúng: Như đã nêu ở phần đáp án, resource class lớn tăng memory grant (phân bổ bộ nhớ động) cho data loads, ưu tiên chúng so với adhoc queries. Synapse hỗ trợ assign qua SET SESSION RESOURCE CLASS hoặc workload classifiers (mới nhất 2026), đảm bảo data loads thành công ngay cả trong concurrency cao.

• ❌ [SAI] Hash distribute the large fact tables in DW1 before performing the automated data loads.
  🧩 Giải thích sai: Hash distribute (phân phối hash) là thiết kế bảng để tối ưu join/query trên fact tables lớn, giúp hiệu suất query dài hạn. Nhưng nó không cấp thêm memory cho data loads và có thể làm chậm quá trình load ban đầu (do redistribution). Không giải quyết vấn đề tranh chấp tài nguyên thời gian thực với adhoc queries.

🛡️ Lưu ý bổ sung: Trong phiên bản Synapse 2026, khuyến nghị kết hợp với Workload Groups để tự động hóa resource allocation, nhưng assign larger resource class vẫn là giải pháp trực tiếp nhất cho tình huống này.

🧩 Giải thích nội dung câu hỏi

Câu hỏi tập trung vào việc triển khai cảnh báo (alerts) bằng Azure Monitor cho một Azure SQL Managed Instance tên là SQLMI1, chứa 10 cơ sở dữ liệu (databases).
Yêu cầu chính:

• Minimize costs (giảm thiểu chi phí tối đa) 🛡️️.
• Aggregate Intelligent Insights telemetry from each database (tập hợp dữ liệu telemetry từ Intelligent Insights của từng database) 📊.

Intelligent Insights là tính năng thông minh của Azure SQL, phân tích dữ liệu telemetry (như CPU, IO, waits, errors) để phát hiện vấn đề hiệu suất tự động, và gửi insights dưới dạng logs (log category: SqlInsights).
Để tạo alerts qua Azure Monitor, cần gửi dữ liệu này đến Log Analytics workspace (cho phép query KQL và thiết lập alerts dựa trên logs). Câu hỏi nhấn mạnh việc aggregate từ từng database trên instance, đồng thời giữ chi phí thấp (tránh ingestion dữ liệu dư thừa hoặc cấu hình nhiều lần).
📘 Phiên bản cập nhật mới nhất (2024-2026): Intelligent Insights trên Azure SQL Managed Instance được cấu hình tại mức instance, tự động aggregate telemetry từ tất cả databases trên đó (không cần per-database).

✅ Đáp án đúng

From the Diagnostic settings of SQLMI1, select Send to Log Analytics.

Lý do lựa chọn:

• Cấu hình Diagnostic settings tại mức SQLMI1 (instance) với log category SqlInsights sẽ tự động aggregate Intelligent Insights telemetry từ tất cả 10 databases mà không cần cấu hình riêng lẻ 🧩.
• Minimize costs: Chỉ cần một diagnostic setting duy nhất, dữ liệu được ingest một lần vào Log Analytics (chi phí dựa trên ingestion và retention), tránh tốn kém từ việc cấu hình 10 databases riêng (có thể dẫn đến dữ liệu trùng lặp hoặc ingestion nhiều hơn) 💰.
• Azure Monitor alerts hoạt động hoàn hảo với Log Analytics (sử dụng log queries để alert trên insights) 🚨.
• Xác nhận: Log category SqlInsights chỉ available tại instance level trên SQL MI, không có ở database level.

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

• ✅ From the Diagnostic settings of SQLMI1, select Send to Log Analytics.
  Phương án ĐÚNG như giải thích trên. Nó đáp ứng đầy đủ aggregate telemetry từ each database (tự động tại instance), minimize costs (single config), và hỗ trợ alerts qua Azure Monitor.

• ❌ From the Diagnostic settings of each database, select Send to Log Analytics.
  Phương án SAI. Trên Azure SQL Managed Instance, database-level diagnostics không hỗ trợ log category SqlInsights (Intelligent Insights). Các categories available chỉ là Errors, Deadlocks, Blocks, v.v. – không aggregate được Intelligent Insights đầy đủ từ telemetry. Hơn nữa, cấu hình cho 10 databases sẽ tăng chi phí ingestion cao hơn (10 lần config, dữ liệu riêng lẻ) ❌.

• ❌ From the Diagnostic settings of each database, select Stream to an event hub.
  Phương án SAI. Tương tự trên, database-level không có SqlInsights. Stream to Event Hub dùng cho real-time streaming (custom processing qua Functions/Stream Analytics), không tối ưu cho alerts Azure Monitor (cần thêm bước trung gian, tăng complexity và costs). Không aggregate hiệu quả, và Event Hub tính phí theo throughput/events 📈.

• ❌ From the Diagnostic settings of SQLMI1, select Stream to an event hub.
  Phương án SAI. Mặc dù instance-level hỗ trợ SqlInsights và aggregate tốt, nhưng Stream to Event Hub không phải lựa chọn minimize costs cho alerts (Event Hub đắt hơn Log

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

Câu hỏi mô tả tình huống: Bạn đang lập kế hoạch di chuyển hai cơ sở dữ liệu (database) mỗi cái 100 GB lên Azure. Yêu cầu chính là có thể scale (mở rộng/thu hẹp) tài nguyên động dựa trên workload (tải công việc), đồng thời giảm thiểu thời gian downtime (ngừng hoạt động) trong quá trình scaling.
📌 Mục tiêu cốt lõi: Giải pháp phải hỗ trợ scaling linh hoạt cho nhiều database cùng lúc, tự động điều chỉnh CPU, storage, IOPS dựa trên nhu cầu biến động, và tránh gián đoạn dịch vụ lớn. Đây là nhu cầu phổ biến trong môi trường cloud PaaS (Platform as a Service) cho SQL Server.

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

Đáp án đúng: two Azure SQL Databases in an elastic pool
🛠️ Lý do chi tiết:

• Azure SQL Elastic Pool là dịch vụ PaaS cho phép đặt nhiều Azure SQL Databases vào một "pool" chung, chia sẻ tài nguyên (vCPU, storage, I/O) động.
• Scaling động: Có thể scale toàn bộ pool lên/xuống chỉ trong phút (thường <1 phút) mà không gây downtime cho các database riêng lẻ, vì workload biến động được tự động cân bằng giữa các DB trong pool. Lý tưởng cho 2 DB 100 GB với tải thay đổi.
• Tối ưu chi phí: Trả phí theo pool, không phải từng DB riêng. Hỗ trợ Hyperscale cho storage lớn (đến 100 TB+ theo cập nhật 2024-2026).
• Phù hợp hoàn hảo với yêu cầu "dynamically scale resources based on workloads" và "minimize downtime".

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

• Azure SQL Elastic Pools Overview (Cập nhật mới nhất 2025).
• Scale elastic pool resources – Xác nhận scaling không downtime.

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

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

• ✅ two Azure SQL Databases in an elastic pool
  🟢 Đúng vì: Như đã giải thích trên, elastic pool hỗ trợ scaling động cho nhiều DB, chia sẻ tài nguyên, và downtime gần như bằng 0 (chỉ scale pool, DBs vẫn available). Hoàn hảo cho 2 DB 100 GB với workload biến động.

• ❌ two databases hosted in SQL Server on an Azure virtual machine
  🔴 Sai vì: Đây là IaaS (VM tự quản lý SQL Server). Scaling yêu cầu resize VM thủ công hoặc dùng Availability Set, gây downtime dài (5-30 phút) khi thay đổi CPU/RAM/storage. Không hỗ trợ scaling động tự động cho từng DB riêng lẻ, phải dừng DB toàn bộ. Không phù hợp minimize downtime.

• ❌ two databases in an Azure SQL Managed instance
  🔴 Sai vì: Azure SQL Managed Instance là PaaS gần với on-prem nhất, nhưng scaling là scale toàn bộ instance (không phải từng DB riêng), có thể gây downtime ngắn (vài phút) khi vCore/storage thay đổi. Không linh hoạt cho "dynamically scale based on workloads" của nhiều DB độc lập như elastic pool. Phù hợp hơn cho migration lớn, không phải multi-DB varying load (cập nhật 2025: vẫn cần failover groups để minimize downtime).

• ❌ two single Azure SQL databases
  🔴 Sai vì: Mỗi single Azure SQL DB scale riêng lẻ (DTU/vCore), nhưng không chia sẻ tài nguyên, dẫn đến chi phí cao và khó quản lý 2 DB riêng. Scaling từng DB gây downtime ngắn (1-5 phút/DB), không tối ưu cho workload biến động chung. Elastic pool mới giải quyết multi-DB hiệu quả.

🧠 Tóm tắt nhanh: Elastic pool là lựa chọn PaaS tốt nhất cho multi-DB scaling không downtime trên Azure (cập nhật 2026 vẫn giữ vị thế hàng đầu). Nếu cần tư vấn triển khai cụ thể, hãy cung cấp thêm chi tiết workload! 🚀

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

📖 Nội dung câu hỏi:
Câu hỏi yêu cầu thiết kế một bảng date dimension table (bảng chiều ngày tháng) trong Azure Synapse Analytics dedicated SQL pool (một loại kho dữ liệu phân tán với các node tính toán). Bảng này sẽ được tất cả các fact tables (bảng sự kiện chứa dữ liệu giao dịch lớn) sử dụng, thường qua các phép JOIN. Mục tiêu là chọn distribution type (phương thức phân phối dữ liệu qua các node) để minimize data movement (giảm thiểu việc di chuyển dữ liệu giữa các node trong quá trình query, đặc biệt là JOIN).

🛠️ Lý do quan trọng: Trong dedicated SQL pool, dữ liệu được phân phối qua các distribution (phân vùng) trên các node để song song hóa xử lý. Nếu phân phối không phù hợp, JOIN giữa fact và dimension có thể gây data skew hoặc data movement lớn, làm chậm query. Date dimension thường nhỏ (chỉ vài nghìn hàng cho nhiều năm), nên cần loại phân phối tránh shuffle dữ liệu.

✅ Đáp án đúng: REPLICATE
Lý do chọn:
REPLICATE sao chép toàn bộ bảng dimension lên mọi distribution trên tất cả node. Khi JOIN với bất kỳ fact table nào (dù fact phân phối HASH hay ROUND_ROBIN), không cần di chuyển dữ liệu từ dimension vì nó đã có sẵn khắp nơi. Điều này tối ưu hóa cho dimension nhỏ (< 2GB, date table thường rất nhỏ), giảm data movement đáng kể, tăng tốc query lên đến hàng chục lần. Theo best practices Azure Synapse (cập nhật 2024-2026), REPLICATE lý tưởng cho small dimension tables dùng chung bởi nhiều fact tables.

🧐 Giải thích tất cả các phương án (giữ nguyên text gốc):

• HASH ❌ (Sai)
  Phân phối dựa trên hash của một cột (ví dụ: date key). Nếu fact tables cũng HASH trên cùng cột JOIN, thì JOIN local (không movement). Nhưng date dimension dùng bởi tất cả fact tables (có thể HASH khác cột), dẫn đến data movement lớn khi JOIN không co-located. Không phù hợp cho dimension nhỏ, dễ gây skew nếu date key không uniform.

• REPLICATE ✅ (Đúng)
  Sao chép toàn bộ bảng lên mọi distribution. Zero data movement cho JOIN với bất kỳ fact table nào, vì dimension luôn local trên mọi node. Hoàn hảo cho small shared dimensions như date table (thường <1GB), tránh broadcast hoặc redistribute. Giới hạn: Chỉ dùng nếu bảng <2GB/compute node để tránh overhead lưu trữ.

• ROUND_ROBIN ❌ (Sai)
  Phân phối ngẫu nhiên đều qua các distribution. JOIN với fact tables yêu cầu reshuffle toàn bộ dữ liệu (data movement cao), làm chậm query lớn. Không hiệu quả cho frequent JOIN, chỉ tốt cho staging hoặc tải nhỏ không JOIN thường xuyên.

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

• Microsoft Docs: Choose the right distribution for your data – Khuyến nghị REPLICATE cho small dimensions.
• Azure Synapse Best Practices: Dimension Modeling – Xác nhận REPLICATE minimize movement cho shared dims.
• Synapse Analytics Gen2 Updates (2025) – Không thay đổi core distribution types.

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

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

Câu hỏi gốc (bằng tiếng Anh):
You have a data warehouse in Azure Synapse Analytics.
You need to ensure that the data in the data warehouse is encrypted at rest.
What should you enable?

Giải thích nội dung câu hỏi:
📘 Câu hỏi tập trung vào Azure Synapse Analytics (một dịch vụ data warehouse mạnh mẽ của Microsoft Azure, trước đây gọi là Azure SQL Data Warehouse). Yêu cầu chính là bảo vệ dữ liệu bằng mã hóa tại chỗ (encrypted at rest), nghĩa là dữ liệu được lưu trữ trên đĩa hoặc lưu trữ đám mây phải được mã hóa tự động mà không ảnh hưởng đến hiệu suất truy vấn.
🛠️ Trong Azure Synapse, mã hóa at rest là tính năng quan trọng để tuân thủ các tiêu chuẩn bảo mật như GDPR, HIPAA. Câu hỏi yêu cầu chọn tính năng enable (kích hoạt) phù hợp nhất để đạt được điều này. Lưu ý: Theo tài liệu Microsoft cập nhật đến năm 2026, TDE là phương pháp chuẩn cho Synapse Analytics (dựa trên nền tảng SQL engine).

✅ Đáp án đúng: Transparent Data Encryption (TDE)
Lý do chọn đáp án đúng:
Transparent Data Encryption (TDE) là tính năng mã hóa toàn bộ cơ sở dữ liệu tại chỗ (at rest) trong Azure Synapse Analytics. Nó mã hóa các file dữ liệu, log và backup một cách tự động, minh bạch (không yêu cầu thay đổi ứng dụng). Theo mặc định, TDE đã được kích hoạt trên các workspace mới từ năm 2020, nhưng có thể enable thủ công nếu cần. Điều này đảm bảo dữ liệu an toàn ngay cả khi đĩa bị truy cập vật lý.
(Nguồn: Microsoft Docs - Transparent data encryption (TDE) in Synapse Analytics, cập nhật 2025).

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

• ✅ Transparent Data Encryption (TDE)
  Đúng vì: 🛡️ TDE được thiết kế chuyên biệt để mã hóa dữ liệu at rest trong Azure Synapse Analytics, bao gồm dedicated SQL pools. Nó sử dụng AES-256 và tích hợp với Azure Key Vault cho quản lý khóa. Hiệu suất gần như không ảnh hưởng, phù hợp cho data warehouse lớn. Đây là lựa chọn chuẩn theo best practices của Microsoft.

• ❌ Advanced Data Security for this database
  Sai vì: 🕵️‍♂️ Advanced Data Security (nay là Microsoft Defender for SQL) là gói bảo mật nâng cao cho Azure SQL Database và Synapse, tập trung vào phát hiện mối đe dọa (threat detection), đánh giá lỗ hổng và mã hóa cột động (dynamic data masking). Nó không phải là công cụ chính để enable mã hóa at rest toàn bộ data warehouse.

• ❌ Always Encrypted for all columns
  Sai vì: 🔒 Always Encrypted là tính năng mã hóa dữ liệu nhạy cảm ở phía client (client-side), bảo vệ dữ liệu cả at rest lẫn in transit/in use. Tuy nhiên, nó chỉ áp dụng cho các cột cụ thể (không phải toàn bộ database), yêu cầu thay đổi schema và ứng dụng, không phù hợp để mã hóa toàn bộ data warehouse lớn như Synapse.

• ❌ Secure transfer required
  Sai vì: 🚫 Secure transfer required chỉ bắt buộc mã hóa dữ liệu trong quá trình truyền (in transit) qua TLS 1.2+, áp dụng cho kết nối từ client đến server. Nó không liên quan đến mã hóa at rest (dữ liệu lưu trữ), mà chỉ bảo vệ dữ liệu đang di chuyển.

Tóm tắt khuyến nghị từ Azure DBA: 🏆 Để triển khai thực tế, sử dụng Azure Portal > Synapse workspace > SQL pools > Security > Transparent data encryption để enable TDE. Kết hợp với Customer-Managed Keys (CMK) cho kiểm soát tốt hơn!
(Nguồn bổ sung: Azure Synapse security overview, cập nhật 2026).

🧩 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 giám sát một công việc (job) Azure Stream Analytics.
📊 Bạn phát hiện chỉ số Backlogged Input Events (sự kiện đầu vào bị tồn đọng) đang tăng dần một cách chậm và luôn luôn khác không (non-zero).
🛠️ Vấn đề cốt lõi: Công việc Stream Analytics không xử lý kịp thời lượng sự kiện đầu vào, dẫn đến tình trạng ùn tắc (backlog) tích tụ.
🎯 Mục tiêu: Đảm bảo job có thể xử lý tất cả các sự kiện một cách hiệu quả, tránh mất dữ liệu hoặc độ trễ cao.
🔍 Đây là tình huống phổ biến trong xử lý dữ liệu thời gian thực (real-time streaming), nơi tài nguyên tính toán cần được mở rộng để theo kịp luồng dữ liệu đầu vào từ nguồn như Event Hubs hoặc IoT Hub (theo tài liệu Azure cập nhật đến 2026).

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

Đáp án đúng: Increase the number of streaming units (SUs).

🧩 Lý do chi tiết:

• Streaming Units (SUs) là đơn vị đo lường tài nguyên tính toán (CPU, memory) dành cho job Stream Analytics. Mỗi SU cung cấp khả năng xử lý một lượng sự kiện nhất định mỗi giây.
• Khi Backlogged Input Events tăng, điều này cho thấy job thiếu công suất xử lý (under-provisioned). Tăng số lượng SUs sẽ scale up (mở rộng theo chiều dọc) job, tăng tốc độ xử lý đầu vào, giảm backlog về 0 và đảm bảo xử lý toàn bộ sự kiện.
• 📈 Theo hướng dẫn Azure mới nhất (2026), đây là giải pháp đầu tiên và hiệu quả nhất cho vấn đề backlog input, có thể thực hiện qua Azure Portal, CLI hoặc ARM template mà không gián đoạn job.
• Nguồn tham khảo: Troubleshoot Stream Analytics job performance & Monitor Stream Analytics (Microsoft Docs, cập nhật 2026).

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

• ❌ [SAI] Remove any named consumer groups from the connection and use $default.
  🧩 Phương án này liên quan đến Event Hubs (nguồn đầu vào phổ biến cho Stream Analytics), nơi consumer groups giúp phân vùng dữ liệu. Tuy nhiên, việc chuyển về $Default chỉ tối ưu hóa phân vùng nếu có xung đột group, không giải quyết backlog do thiếu tài nguyên xử lý. Backlog vẫn tăng nếu job không đủ SU. (Không áp dụng trực tiếp cho vấn đề scale).

• ❌ [SAI] Change the compatibility level of the Stream Analytics job.
  🛠️ Compatibility level kiểm soát cú pháp query (ví dụ: hỗ trợ hàm mới từ v1.0 đến v1.2+). Thay đổi nó chỉ ảnh hưởng tính tương thích code, không tăng công suất xử lý hay giảm backlog input. Job vẫn thiếu SU để "tiêu hóa" sự kiện. (Cập nhật 2026: Không liên quan performance metrics).

• ❌ [SAI] Create an additional output stream for the existing input stream.
  📤 Tạo output stream bổ sung chỉ phân tán kết quả đầu ra, không xử lý thêm sự kiện đầu vào. Backlog xảy ra ở input side (chưa xử lý kịp), nên thêm output làm chậm hơn do tăng tải. Giải pháp sai hướng!

• ✅ [ĐÚNG] Increase the number of streaming units (SUs).
  🚀 Như đã giải thích ở trên: Tăng SU trực tiếp scale compute, xử lý backlog hiệu quả. Azure tự động phân bổ tài nguyên, hỗ trợ lên đến 1,200 SU/job (2026). Khuyến nghị monitoring SU utilization >80% trước khi scale.

🛡️ Lời khuyên từ Azure DBA

🔍 Best practice: Sử dụng Azure Monitor theo dõi metrics như Backlogged Events, SU Utilization, Watermark Delay. Nếu backlog dai dẳng sau scale SU, kiểm tra query optimization hoặc partitioning input. Test với Preview mode trước production!
📘 Tài liệu chính: Scale Azure Stream Analytics jobs (Microsoft Learn, 2026).

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

Câu hỏi mô tả một pipeline trong Azure Data Factory (ADF) được kích hoạt hàng giờ (hourly trigger), đã chạy thành công 100% trong 7 ngày qua. Tuy nhiên, lần chạy mới nhất thất bại, kèm theo hai lần retry cách nhau 15 phút cũng thất bại. Lỗi cụ thể trả về là UserErrorFileNotFound từ hoạt động với Azure Data Lake Storage Gen2 (ADLS Gen2):

ErrorCode=UserErrorFileNotFound, 
'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=ADLS Gen2 operation failed for: Operation returned an invalid status code 'NotFound'. Account: 'contosoproduksouth' FileSystem: wwi. Path: 'BIKES/CARBON/year=2021/month=01/day=10/hour=06'. ErrorCode: 'PathNotFound'.Message: 'The specified path does not exist.'. RequestId: '6d269b78-901f-001b-4924-e7a7bc000000'. TimeStamp: 'Sun, 10 Jan 2021 07:45:05'

📌 Ý nghĩa lỗi chính:

• Path không tồn tại (PathNotFound): ADF đang cố gắng truy cập thư mục cụ thể /BIKES/CARBON/year=2021/month=01/day=10/hour=06 trong filesystem wwi của storage account contosoproduksouth.
• Thời gian lỗi: 07:45 ngày 10/01/2021, tương ứng với dữ liệu giờ 06:00-07:00 (hour=06).
• Đây là lỗi UserError, thường do cấu hình pipeline sai (không phải lỗi hệ thống AWS/Azure), liên quan đến partitioning dữ liệu theo định dạng Hive-style (year/month/day/hour).

🛠️ Ngữ cảnh: Pipeline có lẽ đang đọc dữ liệu từ ADLS Gen2 theo cấu trúc phân vùng thời gian (time-partitioned data). Vì thành công trước đó, vấn đề chỉ xảy ra với path cụ thể này. Câu hỏi yêu cầu nguyên nhân có thể (possible cause) gây lỗi NotFound.

(Kiến thức cập nhật: Dựa trên Azure Data Factory v2 và ADLS Gen2 phiên bản mới nhất đến 2026, lỗi PathNotFound vẫn giữ nguyên cơ chế xử lý như tài liệu Microsoft Learn 2024-2026. Không liên quan AWS trực tiếp, dù chủ đề đề cập – có thể nhầm lẫn với Azure services).

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

• Microsoft Docs: ADF Copy Activity Errors
• ADLS Gen2 Error Codes
• ADF Pipeline Parameters & Expressions

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

Đáp án đúng: The parameter used to generate year=2021/month=01/day=10/hour=06 was incorrect.

🧩 Lý do chi tiết:

• Path lỗi là year=2021/month=01/day=10/hour=06, thường được tự động generate bằng pipeline parameters hoặc expressions trong ADF (ví dụ: @formatDateTime(utcnow(), 'yyyy/MM/dd/HH') hoặc pipeline variables).
• Nếu parameter sai (ví dụ: múi giờ lệch, format date sai, hoặc biến trigger time bị lỗi), ADF sẽ tạo path không khớp với dữ liệu thực tế trên ADLS Gen2 → dẫn đến PathNotFound.
• Pipeline chạy hourly và thành công trước, nên chỉ path cụ thể này sai → chỉ ra vấn đề parameter generation. Retry không giúp vì parameter vẫn sai.
• Đây là nguyên nhân phổ biến nhất cho lỗi UserErrorFileNotFound với partitioned paths (xác nhận qua case studies Microsoft 2024+).

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

• From 06:00 to 07:00 on January 10, 2021, there was no data in wwi/BIKES/CARBON.
  ❌ Sai: Lỗi chỉ báo path cụ thể /BIKES/CARBON/year=2021/month=01/day=10/hour=06 không tồn tại, không phải toàn bộ thư mục wwi/BIKES/CARBON. Có thể dữ liệu tồn tại ở path khác (do partition khác), hoặc folder cha có data nhưng sub-path thiếu. ADF partitioning yêu cầu path chính xác, không scan toàn bộ.

• The parameter used to generate year=2021/month=01/day=10/hour=06 was incorrect.
  ✅ Đúng: Như giải thích trên, parameter/expression sai dẫn đến path generate không tồn tại. Phù hợp với thời gian lỗi (07:45 cho hour=06) và lịch sử thành công trước đó.

• From 06:00 to 07:00 on January 10, 2021, the file format of data in wwi/BIKES/CARBON was incorrect.
  ❌ Sai: Lỗi là NotFound (path không tồn tại), không liên quan file format. Nếu format sai, ADF sẽ báo lỗi như InvalidFormat hoặc SchemaMismatch (ParseError), không phải UserErrorFileNotFound. Retry cũng không ảnh hưởng format.

• The pipeline was triggered too early.
  ❌ Sai: Pipeline đã thành công 7 ngày, chạy hourly ổn định → trigger time đúng. Có 2 retry cách 15 phút (tổng ~30 phút delay), vẫn fail → không phải "quá sớm". Nếu early, data chưa sẵn sàng, nhưng lỗi cụ thể là path sai, không phải chờ data.