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

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

Câu hỏi tập trung vào việc triển khai một instance SQL Server trên Azure Virtual Machines (VMs) trong một Azure subscription. Các yêu cầu chính bao gồm:
✅ Hỗ trợ cấu hình hiệu suất tùy chỉnh (custom performance configuration) như IOPS (Input/Output Operations Per Second), dung lượng (capacity), và throughput (tốc độ truyền dữ liệu).
✅ Tối ưu hóa chi phí (minimize costs) – nghĩa là chọn giải pháp hiệu suất cao nhưng giá rẻ nhất có thể.
🛠️ Bối cảnh: SQL Server trên Azure VMs thường yêu cầu disk hiệu suất cao để xử lý workload database, đặc biệt là I/O-intensive tasks. Chúng ta cần loại disk phù hợp nhất với hai tiêu chí trên, dựa trên các loại Managed Disks của Azure (cập nhật đến năm 2026, theo tài liệu Azure mới nhất).

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

• Azure Disk Storage types (phiên bản mới nhất 2024-2026).
• Premium SSD v2 disks – Giới thiệu từ 2023, hỗ trợ tùy chỉnh IOPS/throughput với giá rẻ hơn Ultra Disk lên đến 60-70%.

✅ Đáp án đúng: Premium SSD v2

Lý do lựa chọn:
Premium SSD v2 là loại disk hỗ trợ tùy chỉnh hoàn toàn IOPS (từ 3.000 đến 1.200.000), throughput (từ 125 đến 10.000 MB/s), và dung lượng (từ 3.84 GiB đến 32 TiB), phù hợp chính xác với yêu cầu custom performance. Đồng thời, nó tối ưu chi phí nhất vì giá tính theo đơn vị provisioned IOPS/throughput (pay-as-you-go), rẻ hơn Ultra Disk 40-60% cho cùng mức hiệu suất, và không yêu cầu VM size đặc biệt. Lý tưởng cho SQL Server trên VMs với workload database cần scale I/O linh hoạt mà không lãng phí chi phí. 🏆

📋 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, kèm giải thích sai/đúng bằng tiếng Việt:

• Premium SSD v2
  ✅ Đúng. Như đã giải thích ở trên, đây là lựa chọn tối ưu nhất với khả năng tùy chỉnh IOPS, throughput, capacity độc lập; giá rẻ hơn các loại premium khác (khoảng 0.05-0.10 USD/1.000 IOPS/tháng). Hỗ trợ SQL Server Always On, failover clusters trên Azure VMs. Không có hạn chế về VM series (hỗ trợ DS/MDv2, DSv3+).

• Premium SSD
  ❌ Sai. Loại disk này chỉ cung cấp hiệu suất cố định dựa trên kích thước disk (ví dụ: P30 ~ 5.000 IOPS, 200 MB/s), không hỗ trợ tùy chỉnh IOPS/capacity/througput độc lập. Mặc dù hiệu suất cao và ổn định cho SQL Server, nhưng không đáp ứng yêu cầu "custom performance" và chi phí cao hơn v2 cho workload tương đương.

• Standard SSD
  ❌ Sai. Đây là disk hiệu suất thấp, không dành cho workload production như SQL Server (IOPS tối đa ~20.000 burst, throughput thấp ~500 MB/s). Không hỗ trợ tùy chỉnh chi tiết, chủ yếu dùng cho dev/test hoặc non-critical apps. Sẽ không đáp ứng custom performance và có thể gây bottleneck I/O, dẫn đến chi phí cao hơn do cần scale VM lớn.

• Ultra SSD
  ❌ Sai. Hỗ trợ tùy chỉnh IOPS (lên 160.000) và throughput (lên 4.000 MB/s), nhưng chi phí rất cao (gấp 1.5-2 lần Premium SSD v2 cho cùng perf, khoảng 0.10-0.20 USD/1.000 IOPS). Chỉ dành cho extreme workloads (như SAP HANA), yêu cầu VM series đặc biệt (Dv5, Ev5+). Không minimize costs như yêu cầu. 🛑

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

Câu hỏi thuộc phần case study của kỳ thi chứng chỉ (có lẽ là DP-300: Administering Microsoft Azure SQL Solutions), mô tả tình huống thực tế tại công ty ADatum Corporation – một công ty dịch vụ tài chính.

• Môi trường hiện tại (Existing Environment):

  • Datacenter on-premises kết nối với Azure subscription Sub1 qua Site-to-Site VPN.
  • Các server SQL: SVR1 (SQL 2016, Always On AG2 chứa DB1/DB2), SVR2 (SQL 2016, Always On AG1 chứa DB1/DB2), SVR3 (SQL 2019 chứa DB3).
  • DB3 lưu trữ dữ liệu compliance cho App2/App3, được monitor bằng Extended Events với target event_file lưu vào file share trên local disk của SVR3.
  • Resource Governor quản lý tài nguyên DB3.

• Kế hoạch thay đổi (Planned Changes): Migrate DB3 sang Azure SQL Database (không phải Managed Instance như DB1/DB2).

• Yêu cầu quản lý (Management Requirements):

  • Tiếp tục sử dụng Extended Events để monitor DB3 sau migration.
  • Sử dụng elastic jobs với database-scoped credentials để tự động hóa quản lý DB3 trong Azure SQL Database.

📌 Vấn đề cốt lõi: Sau khi migrate DB3 sang Azure SQL Database, cần xác định event_file target mới cho Extended Events để đáp ứng yêu cầu tiếp tục monitoring mà không thay đổi cách tiếp cận cơ bản. Azure SQL Database không hỗ trợ file system local (như hiện tại trên SVR3), nên phải dùng target phù hợp với cloud.

✅ Đáp án đúng: an Azure Blob Storage container

Lý do lựa chọn:

• Trong Azure SQL Database (phiên bản cập nhật đến 2026), Extended Events hỗ trợ event_file target chỉ dành cho Azure Blob Storage container (dạng blob append). Điều này cho phép lưu trữ file .xel (Extended Events log) vào Blob Storage một cách an toàn, scalable, và dễ truy cập từ xa.
• Đáp ứng management requirements: Tiếp tục dùng Extended Events như cũ, kết hợp elastic jobs (dùng database-scoped credentials để truy cập Blob). Không cần thay đổi code monitoring lớn, giảm administrative effort và chi phí (Blob Storage rẻ, minimize costs).
• Hình ảnh server (SVR3) chỉ nhấn mạnh môi trường on-premises hiện tại không còn dùng được sau migration – phải chuyển sang cloud-native storage.
• Cập nhật 2026: Azure SQL hỗ trợ XEvent với Blob target ổn định, tích hợp tốt với Azure Monitor và elastic jobs (từ Azure SQL Elastic Jobs preview đến GA đầy đủ).

Nguồn tham khảo 📘:

• Extended events in Azure SQL Database (Microsoft Docs, cập nhật 2024-2026).
• Create event file target.

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

• ❌ a SQL Server filegroup
  Sai vì filegroup là tính năng lưu trữ dữ liệu bảng/index trong SQL Server on-premises hoặc Managed Instance, không hỗ trợ làm event_file target cho Extended Events. Azure SQL Database không cho phép filegroup cho XEvent (và DB3 migrate sang PaaS, không cần filegroup). Sử dụng sẽ vi phạm yêu cầu migrate và monitoring.

• ❌ an Azure SQL database
  Sai vì Azure SQL Database không hỗ trợ lưu event_file trực tiếp vào database khác làm target. Event_file cần storage blob-based, không phải relational DB. Điều này sẽ tăng chi phí không cần thiết và không meet "minimize costs", đồng thời elastic jobs không tương thích tốt.

• ❌ an Azure Files share
  Sai vì Azure Files (SMB/NFS share) không được hỗ trợ chính thức làm event_file target trong Azure SQL Database Extended Events (chỉ Blob Storage). Hiện tại DB3 dùng local file share trên SVR3, nhưng sau migration PaaS không mount Files share trực tiếp cho XEvent. Vi phạm "continue using Extended Events" seamless.

• ✅ an Azure Blob Storage container
  (Đã giải thích ở trên) – Hoàn hảo cho Azure SQL DB, hỗ trợ append-only blobs, tích hợp IAM/database-scoped credentials cho elastic jobs. Giảm downtime, meet tất cả requirements. 🛠️

Kết luận 🎯: Lựa chọn này đảm bảo tính liên tục, bảo mật (audit changes cho DB3), và tối ưu chi phí/toàn cầu hóa sau migration!

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

Câu hỏi tập trung vào việc migrate một cơ sở dữ liệu Microsoft SQL Server dung lượng 14 TB từ on-premises datacenter sang Azure SQL Managed Instance.
✅ Yêu cầu chính: Xác định ba service tiers (cấp độ dịch vụ) được hỗ trợ cho Azure SQL Managed Instance, vì đây là câu hỏi trắc nghiệm đa lựa chọn (mỗi lựa chọn đúng chiếm 1 điểm).
🛠️ Bối cảnh kỹ thuật: Azure SQL Managed Instance là dịch vụ PaaS toàn quản lý, hỗ trợ gần như đầy đủ tính năng của SQL Server on-premises. Service tiers quyết định hiệu suất, lưu trữ và tính sẵn sàng (ví dụ: General Purpose ưu tiên chi phí thấp, Business Critical ưu tiên hiệu suất cao với local SSD). Với database 14 TB, cần tiers hỗ trợ lưu trữ lớn (lên đến 16 TB+ tùy tier). Không có hạn chế đặc biệt về kích thước ở đây, nhưng phải chọn đúng các tiers được Azure hỗ trợ chính thức.
📘 Kiến thức cập nhật: Dựa trên tài liệu Microsoft Azure mới nhất (tính đến 2026), Azure SQL Managed Instance hỗ trợ các hardware generations như Standard-series (Gen5), Premium-series (Gen5), và Memory optimized Premium-series (Gen5) dưới hai mô hình chính: General Purpose và Business Critical (provisioned/serverless).

✅ Đáp án đúng (3 lựa chọn)

Các đáp án đúng là:

• General Purpose Standard
• Business Critical Memory Optimized Premium
• General Purpose Premium

Lý do lựa chọn: Đây chính là ba service tiers được Azure hỗ trợ đầy đủ cho SQL Managed Instance, dựa trên cấu hình hardware cụ thể: Standard-series cho General Purpose cơ bản, Premium-series cho General Purpose nâng cao, và Memory Optimized Premium-series cho Business Critical siêu hiệu suất (tối ưu OLTP với RAM lớn). Chúng phù hợp migrate database lớn 14 TB, hỗ trợ vCore provisioning/serverless, lưu trữ lên đến 32 TB+, và tính sẵn sàng cao. Các tiers sai không tồn tại hoặc không được phân loại chính xác theo docs Azure.

🧩 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 tiếng Anh, với lý do đúng/sai dựa trên tài liệu chính thức (không dịch phương án).

✅ General Purpose Standard
Phương án này đúng 🟢 vì đây là service tier cơ bản của General Purpose trên hardware Standard-series (Gen5), hỗ trợ migrate database lớn với chi phí thấp, lưu trữ đến 16 TB+, IOPS cân bằng và không yêu cầu local SSD. Phù hợp cho workload OLTP/OLAP thông thường.

✅ Business Critical Memory Optimized Premium
Phương án này đúng 🟢 vì thuộc Business Critical trên hardware Memory optimized Premium-series (Gen5), tối ưu cho workload hiệu suất cao (RAM lớn gấp đôi, local SSD 3x dung lượng compute), hỗ trợ database 14 TB với RPO <5s, HA tích hợp Always On. Lý tưởng cho mission-critical apps.

✅ General Purpose Premium
Phương án này đúng 🟢 vì là General Purpose trên hardware Premium-series (Gen5), cung cấp IOPS cao hơn Standard-series (lên 250k IOPS), lưu trữ lớn, phù hợp scale database 14 TB mà không cần Business Critical. Hỗ trợ serverless provisioning linh hoạt.

❌ Business Critical Premium
Phương án này sai 🔴 vì không phải tên service tier chính thức; Azure gọi là Premium-series (Gen5) dưới Business Critical, nhưng không có khái niệm "Business Critical Premium" riêng biệt (nó bị gộp chung, không liệt kê độc lập như Memory Optimized). Sử dụng sẽ gây nhầm lẫn với Premium-series thông thường.

❌ Business Critical Standard
Phương án này sai 🔴 vì không tồn tại trong Azure SQL Managed Instance; Business Critical chỉ hỗ trợ Premium-series hoặc Memory Optimized Premium-series (không có "Standard" variant). Standard-series chỉ dành cho General Purpose, không phù hợp với yêu cầu HA cao của Business Critical.

📘 Tài liệu tham khảo

• Service tiers overview - Azure SQL Managed Instance
• General Purpose service tier
• Business Critical service tier (cập nhật 2025-2026: thêm serverless và hardware mới).
  🛠️ Lời khuyên DBA: Khi migrate 14 TB, dùng Azure Database Migration Service (DMS) + Offline/Online mode, kiểm tra vCore/storage limits trước khi deploy!

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

📘 Nội dung câu hỏi:
Câu hỏi mô tả một máy ảo Azure tên Server1 chạy hệ điều hành Windows Server 2022, trên đó có instance Microsoft SQL Server 2022 tên SQL1 và một cơ sở dữ liệu tên DB1. Bạn đã tạo master key trong master database của SQL1. Nhiệm vụ là tạo một bản sao lưu (backup) được mã hóa (encrypted backup) cho DB1.
🛠️ Mục tiêu chính: Xác định bước tiếp theo cần thiết để thực hiện backup mã hóa trong SQL Server 2022. Trong SQL Server, để mã hóa backup, bạn cần sử dụng lệnh BACKUP DATABASE ... WITH ENCRYPTION = 'Certificate "TênCert"' hoặc symmetric key, nhưng điều kiện tiên quyết là phải có certificate hoặc asymmetric key nằm trong master database (đã có master key để bảo vệ chúng). Đây là tính năng backup encryption được hỗ trợ từ SQL Server 2008 trở lên, và vẫn là chuẩn mới nhất đến SQL Server 2022 (không thay đổi cơ bản đến năm 2026 theo tài liệu Microsoft).

✅ Đáp án đúng: Create a certificate in the master database of SQL1.
Lý do lựa chọn:
Sau khi có master key trong master database, bước tiếp theo chính xác là tạo certificate ngay trong master database của SQL1. Certificate này sẽ được sử dụng trực tiếp trong lệnh backup với tùy chọn WITH ENCRYPTION. SQL Server yêu cầu certificate phải nằm ở master database để mã hóa backup toàn instance, đảm bảo an toàn và tương thích. Không cần TDE (Transparent Data Encryption) cho backup encryption riêng lẻ.
🛠️ Ví dụ lệnh thực hiện:

USE master;
CREATE CERTIFICATE BackupCert WITH SUBJECT = 'Backup Encryption Cert';
BACKUP DATABASE DB1 TO DISK = 'D:\Backup\DB1.bak' WITH ENCRYPTION (CERTIFICATE BackupCert);

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

• ❌ Create a symmetric key in DB1.
  Phương án này sai vì symmetric key (nếu dùng cho backup encryption) phải được tạo trong master database và được bảo vệ bởi certificate/master key ở đó. Tạo symmetric key trong DB1 (user database) chỉ dùng cho mã hóa dữ liệu bên trong DB1 (như column-level encryption), không hỗ trợ backup encryption toàn bộ database. Việc này sẽ gây lỗi khi chạy lệnh BACKUP ... WITH ENCRYPTION vì SQL Server yêu cầu key/certificate ở master.

• ❌ Enable virtualization-based security (VBS) on Server1.
  Phương án này sai vì VBS (Virtualization-Based Security) là tính năng bảo mật cấp hệ điều hành Windows (sử dụng Hyper-V để cô lập kernel), không liên quan đến mã hóa backup trong SQL Server. VBS giúp chống tấn công phần mềm độc hại trên VM Azure nhưng không ảnh hưởng đến cơ chế BACKUP WITH ENCRYPTION của SQL. Đây là nhầm lẫn giữa bảo mật OS và bảo mật database.

• ❌ Create a certificate in DB1.
  Phương án này sai vì certificate cho backup encryption phải nằm trong master database, không phải user database như DB1. Nếu tạo ở DB1, certificate chỉ mã hóa dữ liệu cục bộ trong DB1 (qua TDE), nhưng lệnh backup sẽ thất bại với lỗi "Cannot find the certificate" vì SQL Server chỉ tìm certificate ở master cho backup toàn cục.

• ✅ Create a certificate in the master database of SQL1.
  Như đã giải thích ở trên, đây là đúng và là bước chuẩn xác tiếp theo. Certificate ở master được bảo vệ bởi master key đã có, cho phép mã hóa backup ngay lập tức.

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

• Microsoft Docs chính thức: Create an Encrypted Backup (SQL Server) – Xác nhận certificate phải ở master database.
• SQL Server 2022 Backup Encryption: Backup Overview – Không thay đổi đến 2026.
• Azure SQL VM Docs: Security for SQL Server on Azure VMs – Hỗ trợ đầy đủ tính năng này trên Azure VM.

🛠️ Lưu ý từ Azure DBA: Trong môi trường Azure, sau khi backup encrypted, hãy lưu certificate backup file (.cer) an toàn bằng BACKUP CERTIFICATE để restore sau này! Nếu cần TDE cho mã hóa liên tục, thêm bước CREATE DATABASE ENCRYPTION KEY trong DB1.

🧩 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 chuẩn bị triển khai failover cluster instances (FCIs) của Microsoft SQL Server 2022 trên ba máy ảo (VMs) chạy Red Hat Enterprise Linux (RHEL) trong một Azure subscription. Mục tiêu là tạo một môi trường highly available (có tính sẵn sàng cao) bằng cách sử dụng FCIs.

• Bối cảnh chính: Bạn cần thực hiện bước đầu tiên (first) trên từng server (mỗi máy ảo) để chuẩn bị triển khai. FCIs trên Linux (như RHEL) yêu cầu sử dụng cluster resource manager như Pacemaker để quản lý failover, thay vì Windows Server Failover Clustering (WSFC).
• Yêu cầu then chốt: Bước đầu tiên phải là thiết lập nền tảng cluster trước khi cấu hình đĩa, mạng, hoặc cài đặt SQL Server instance, vì cluster là yêu cầu bắt buộc cho FCIs trên Linux.
• Phiên bản cập nhật: Dựa trên tài liệu Microsoft mới nhất (SQL Server 2022 và Azure Stack HCI/RHEL hỗ trợ đến 2026), quy trình chuẩn bị FCIs trên RHEL bao gồm cài đặt Pacemaker và resource agent trước tiên. (📘 Nguồn: Microsoft Docs - SQL Server FCI on Linux, cập nhật 2024-2026).

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

Đáp án đúng: Install the cluster resource manager and the FCI resource agent.

Lý do (🛠️ Chi tiết phân tích):

• Đây là bước đầu tiên bắt buộc trên từng node (máy ảo RHEL) để triển khai FCIs.
  • Cluster resource manager (thường là Pacemaker + Corosync) quản lý tài nguyên cluster và failover.
  • FCI resource agent (như ocf:mssql:fci) là plugin cho Pacemaker để hỗ trợ SQL Server FCI.
• Không có cluster, bạn không thể tạo resources (đĩa, mạng) hoặc cài SQL instance cho FCI. Quy trình Microsoft chính thức: Cài Pacemaker trước, sau đó mới cấu hình cluster và SQL.
• ✅ Xác nhận cập nhật 2026: Pacemaker vẫn là tiêu chuẩn cho RHEL 8/9 trên Azure (không thay đổi lớn từ SQL 2022).

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

• ❌ [SAI] Create the FCI disk and network resources.
  Phương án này sai vì việc tạo đĩa (shared disk qua Azure Disks/SMB) và tài nguyên mạng (Azure Load Balancer) chỉ thực hiện sau khi cluster đã được cài đặt và cấu hình. Bước đầu tiên phải là cluster manager; nếu tạo sớm, chúng sẽ không được quản lý bởi Pacemaker, dẫn đến thất bại failover. (🧩 Lý do loại: Microsoft yêu cầu cluster trước resources).

• ❌ [SAI] Install a named SQL Server instance.
  Phương án này sai vì SQL Server instance (named hoặc default) chỉ cài sau khi cluster sẵn sàng. Cài instance trước sẽ không tích hợp được với FCI resource agent, gây lỗi khi join cluster. Bước đầu là hạ tầng cluster, không phải SQL. (🛠️ Lý do loại: Docs Microsoft: "Install SQL Server after setting up Pacemaker").

• ✅ [ĐÚNG] Install the cluster resource manager and the FCI resource agent.
  Như đã giải thích ở trên, đây là bước đầu tiên chính xác trên mỗi server. Pacemaker và agent tạo nền tảng cho toàn bộ FCI, cho phép quản lý failover tự động trên Azure VMs RHEL. (📘 Xác nhận: Bước 1 trong hướng dẫn chính thức).

• ❌ [SAI] Install the default SQL Server instance.
  Phương án này sai tương tự named instance: Cài default instance trước cluster sẽ không hỗ trợ FCI (yêu cầu named instance cho FCI trên Linux). Phải có Pacemaker trước để instance được quản lý như resource. (🧩 Lý do loại: Default instance không dành cho FCI; cluster là prerequisite).

💡 Lời khuyên từ Azure DBA: Sau bước này, tiếp theo là cấu hình cluster (pcs status, crm configure), tạo shared storage (Azure Premium Files), và install SQL. Test failover bằng pcs cluster start để đảm bảo HA! (📘 Nguồn bổ sung: Azure SQL FCI on Linux).

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

📖 Nội dung câu hỏi:
Câu hỏi mô tả tình huống bạn đang có một instance Microsoft SQL Server 2022 chạy on-premises, chứa cơ sở dữ liệu sản xuất (production database) có dung lượng 60 TB tên là DB1. Bạn cần di chuyển (migrate) DB1 lên Azure và khuyến nghị một giải pháp hosting phù hợp cho DB1 trên Azure SQL Database. Cụ thể, câu hỏi yêu cầu chọn service tier (cấp độ dịch vụ) của Azure SQL Database để host DB1.

🛠️ Bối cảnh quan trọng:

• Dung lượng 60 TB là rất lớn (hyperscale-level), đòi hỏi tier hỗ trợ lưu trữ cao, khả năng mở rộng nhanh chóng, và tương thích với SQL Server.
• Azure SQL Database có các service tier chính: General Purpose (GP), Business Critical (BC), và Hyperscale (dành riêng cho database khổng lồ).
• Kiến thức cập nhật đến 2026 (dựa trên Azure SQL Database vCore model mới nhất năm 2024-2026): Hyperscale hỗ trợ lên đến 100 TB+ (thực tế đã đạt 128 TB theo docs mới), trong khi các tier khác giới hạn ở 4-16 TB.

✅ Đáp án đúng: Hyperscale
Lý do lựa chọn: Hyperscale là service tier duy nhất của Azure SQL Database được thiết kế dành riêng cho các database cực lớn (multi-terabyte) như 60 TB. Nó sử dụng kiến trúc disaggregated storage (lưu trữ tách biệt), cho phép scale storage độc lập lên đến 100 TB+ mà không downtime, read replicas nhanh (local/global), và hỗ trợ migrate từ SQL Server on-premises dễ dàng qua Azure Database Migration Service (DMS). Các tính năng như auto-scaling storage và columnar indexes làm nó lý tưởng cho workload production lớn.

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

• ✅ Hyperscale (ĐÚNG):
  Đây là lựa chọn tối ưu vì hỗ trợ dung lượng tối đa lên đến 100 TB+ (cập nhật 2026: 128 TB theo Microsoft announcements), scale storage riêng biệt với compute, phù hợp migrate 60 TB DB1 mà không giới hạn. Hiệu suất cao với up to 128 vCores, read scale-out, và backup nhanh (instant backup).

• ❌ Business Critical (SAI):
  Tier này ưu tiên high availability và performance (local redundancy, Always On AG), nhưng giới hạn storage tối đa 4 TB (vCore model). Không thể host 60 TB DB1, sẽ fail khi provision hoặc scale. Phù hợp workload OLTP nhỏ hơn, không dành cho hyperscale DB.

• ❌ General Purpose (SAI):
  Tier tiết kiệm chi phí cho workload đa số (serverless hoặc provisioned), nhưng giới hạn storage 4 TB (provisioned) hoặc 16 TB (serverless). Không hỗ trợ 60 TB, thiếu read replicas mạnh mẽ và scale storage nhanh như Hyperscale. Chỉ dùng cho DB dưới 4 TB.

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

• Azure SQL Database Hyperscale ✅ (Chi tiết limits: 100+ TB storage).
• Azure SQL service tiers comparison 🛠️ (So sánh GP/BC/Hyperscale).
• Migrate large SQL Server to Azure SQL Hyperscale (Hướng dẫn migrate 60 TB+).

Hy vọng phân tích này giúp bạn hiểu rõ! 🚀 Nếu cần thêm chi tiết migrate, hãy hỏi nhé!

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

📖 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 sở hữu một Azure subscription (tài khoản đăng ký Azure) và dự định triển khai một Azure SQL database duy nhất (single database). Yêu cầu chính là đảm bảo cơ sở dữ liệu này hỗ trợ autoscaling của compute resources (tự động mở rộng/thu hẹp tài nguyên tính toán, tức là CPU/vCores dựa trên tải công việc mà không cần can thiệp thủ công).
🛠️ Autoscaling compute ở đây ám chỉ tính năng serverless compute trong Azure SQL Database, cho phép vCores tự động điều chỉnh từ mức tối thiểu đến tối đa (ví dụ: 0.5-4 vCores ban đầu, lên đến 80 vCores) và tự động tạm dừng khi không hoạt động để tiết kiệm chi phí. Đây là tính năng chỉ có ở một số service tier cụ thể trong mô hình vCore-based (không phải DTU-based). Câu hỏi tập trung vào việc chọn service tier phù hợp để kích hoạt tính năng này cho single database.

✅ Đáp án đúng: General Purpose
Lý do lựa chọn:
Service tier General Purpose (trong mô hình vCore) hỗ trợ chế độ Serverless compute, cho phép autoscaling compute resources tự động dựa trên workload. Khi tải tăng, vCores sẽ scale up ngay lập tức (trong vài giây); khi tải giảm hoặc idle > 1 giờ, database tự động pause và resume khi cần. Điều này lý tưởng cho single database với tải biến động, giúp tối ưu chi phí và hiệu suất. (Cập nhật đến 2026: Tính năng này vẫn là chuẩn trong Azure SQL Database vCore model, không thay đổi lớn từ 2023).

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

• Premium ❌ Sai:
  Đây là service tier thuộc mô hình DTU-based (không phải vCore). Nó chỉ hỗ trợ compute cố định (provisioned), không có autoscaling compute hay serverless. Premium tập trung vào hiệu suất cao cho workload ổn định, nhưng yêu cầu cấu hình thủ công vCores/storage. Không phù hợp với yêu cầu autoscaling.

• General Purpose ✅ Đúng:
  Như đã giải thích ở trên, tier này hỗ trợ Serverless với autoscaling compute (scale từ 0.5 vCores tối thiểu, auto-pause/resume). Hoàn hảo cho single database có tải không đều, đảm bảo tính sẵn sàng cao mà không lãng phí tài nguyên.

• Business Critical ❌ Sai:
  Tier này (vCore-based) chỉ hỗ trợ provisioned compute với local SSD và high availability (Always On), ưu tiên hiệu suất cực cao cho mission-critical workload. Không có serverless hay autoscaling compute tự động; phải scale thủ công qua portal/CLI.

• Standard ❌ Sai:
  Thuộc mô hình DTU-based, chỉ hỗ trợ compute cố định với giới hạn DTU thấp hơn Premium. Không có autoscaling compute, serverless hay khả năng scale động. Phù hợp workload nhẹ nhưng không đáp ứng yêu cầu câu hỏi.

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

• Azure SQL Database service tiers – Chi tiết về General Purpose Serverless.
• Serverless compute autoscaling – Hướng dẫn cấu hình autoscaling.
• So sánh DTU vs vCore – Lý do Premium/Standard không hỗ trợ.

🛠️ Lời khuyên từ Azure DBA: Để triển khai, chọn General Purpose > Serverless khi create database qua Azure Portal/ARM template, đặt min/max vCores phù hợp workload!