Ngân hàng đề Microsoft Administering Azure SQL

Câu 1 Chọn nhiều đáp án Monitor, configure, and optimize database resources (20–25%)

Which of the following tools or features can be used to identify and resolve problematic queries affecting performance? (Select all that apply)

A Query Store
B Activity Monitor
C Dynamic Management Views (DMVs)
D SQL Alerts

Xem giải thích

Đáp án

A và C — Query Store và Dynamic Management Views (DMV).

Vì sao đúng

⚠ Hai công cụ chẩn đoán truy vấn của SQL Server và Azure SQL: | Công cụ | Việc | |---|---| | ⚠ Query Store | ⚠ GHI LẠI lịch sử kế hoạch thực thi và số liệu hiệu năng | | ⚠ DMV | ⚠ khung nhìn động cho trạng thái HIỆN TẠI của hệ thống |

⚠ Query Store
   ⚠ "truy vấn này trước đây chạy nhanh,
      từ tuần trước thì chậm"
   ⚠ so sánh kế hoạch cũ và mới
   ⚠ ÉP dùng lại kế hoạch tốt

⚠ DMV
   ⚠ "ngay bây giờ truy vấn nào đang chạy?"
   ⚠ "index nào đang thiếu?"
   ⚠ "chờ đợi ở đâu?"

Vì sao các phương án khác sai

B (Activity Monitor) — ⚠ công cụ của SQL Server Management Studio cho SQL Server tại chỗ: ⚠ không dùng được với Azure SQL Database; ⚠ và ⚠ nó chỉ hiện trạng thái tức thời.
D (SQL Alerts) — ⚠ cảnh báo khi có sự kiện xảy ra: ⚠ báo cho biết có vấn đề, ⚠ nhưng ⚠ không giúp phân tích truy vấn nào có vấn đề.

Ghi nhớ

⚠ Công cụ chẩn đoán hiệu năng Azure SQL — bảng phải thuộc: | Công cụ | Việc | |---|---| | ⚠ Query Store | ⚠ lịch sử truy vấn và kế hoạch thực thi | | ⚠ DMV | ⚠ trạng thái hệ thống thời gian thực | | ⚠ Query Performance Insight | ⚠ giao diện trực quan trên cổng Azure | | ⚠ Automatic Tuning | ⚠ tự thêm/bớt index, tự sửa kế hoạch | | ⚠ Extended Events | ⚠ theo dõi chi tiết, thay cho SQL Profiler |

Từ khoá nhận diện:

"truy vấn trước nhanh giờ chậm" → ⚠ Query Store — so sánh kế hoạch "ngay bây giờ đang xảy ra gì" → ⚠ DMV "tự động tối ưu" → ⚠ Automatic Tuning "giao diện đồ hoạ dễ nhìn" → ⚠ Query Performance Insight

⚠ Query Store — làm được gì	Việc
⚠ Lưu lịch sử mọi kế hoạch thực thi
⚠ Ghi thời gian chạy, CPU, I/O theo từng truy vấn
⚠ Phát hiện KẾ HOẠCH BỊ THOÁI HOÁ (plan regression)
⚠ ÉP dùng một kế hoạch cụ thể	⚠ force plan
⚠ Trong Azure SQL Database	⚠ BẬT MẶC ĐỊNH

⚠ DMV hay dùng	DMV
⚠ `sys.dm_exec_requests`	⚠ truy vấn đang chạy
⚠ `sys.dm_exec_query_stats`	⚠ thống kê truy vấn đã thực thi
⚠ `sys.dm_db_missing_index_details`	⚠ index còn thiếu
⚠ `sys.dm_os_wait_stats`	⚠ hệ thống đang chờ ở đâu
⚠ `sys.dm_db_index_usage_stats`	⚠ index nào không ai dùng

⚠ Quy trình chẩn đoán truy vấn chậm	Bước
⚠ 1. Query Store tìm truy vấn tốn nhất
⚠ 2. Xem kế hoạch thực thi
⚠ 3. Kiểm tra index thiếu hoặc thừa
⚠ 4. Xem wait stats để biết nghẽn ở đâu
⚠ 5. Sửa truy vấn hoặc thêm index rồi ĐO LẠI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Query Store đã bật chưa | ⚠ Azure SQL bật sẵn | | Truy vấn nào tốn CPU nhất | | | Có index nào chưa bao giờ được dùng không | ⚠ index thừa làm chậm việc ghi |

Và giá trị lớn nhất của Query Store so với mọi công cụ trước nó: nó trả lời được câu hỏi "trước đây nó chạy thế nào". Không có lịch sử thì mọi cuộc điều tra hiệu năng đều bắt đầu bằng phỏng đoán.

Câu 2 Plan and implement data platform resources (20–25%)

To ensure optimal performance for a production-based workload, you need to host an SQL Server Instance on an Azure virtual machine. The underlying disks must have a storage latency of less than 1 ms. What options are available to achieve this requirement?

A
Standard HDD
B
Standard SSD
C
Premium SSD
D
Ultra-Disks

Xem giải thích

Đáp án

D — Ultra Disk.

Vì sao đúng

⚠ Bốn loại đĩa của Azure và độ trễ: | Loại đĩa | Độ trễ | Dùng cho | |---|---|---| | ⚠ Standard HDD | ⚠ cao nhất | ⚠ sao lưu, dữ liệu ít truy cập | | ⚠ Standard SSD | ⚠ trung bình | ⚠ web, môi trường phát triển | | ⚠ Premium SSD | ⚠ thấp, vài mili giây | ⚠ CSDL sản xuất thông thường | | ⚠ Ultra Disk | ⚠ DƯỚI 1 mili giây | ⚠ CSDL đòi hỏi khắt khe nhất — đề này |

⚠ Yêu cầu: độ trễ DƯỚI 1 ms
        ↓
⚠ Chỉ Ultra Disk cam kết được
        ↓
⚠ Cộng thêm: IOPS và thông lượng
   ĐIỀU CHỈNH ĐỘC LẬP, đổi được
   khi đang chạy

Vì sao các phương án khác sai

C (Premium SSD) — ⚠ bẫy gần nhất: ⚠ rất tốt cho phần lớn CSDL sản xuất, ⚠ nhưng ⚠ độ trễ vài mili giây, ⚠ không đạt mức dưới 1 ms.
B (Standard SSD) — ⚠ độ trễ cao hơn, không cho tải sản xuất nặng.
A (Standard HDD) — ⚠ chậm nhất, hoàn toàn không phù hợp.

Ghi nhớ

⚠ Ultra Disk — đặc điểm phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ Độ trễ | ⚠ dưới 1 mili giây | | ⚠ IOPS và thông lượng | ⚠ cấu hình ĐỘC LẬP với dung lượng | | ⚠ Đổi được khi VM đang chạy | ⚠ không cần khởi động lại | | ⚠ Hạn chế | ⚠ không dùng làm đĩa HỆ ĐIỀU HÀNH | | ⚠ Hạn chế | ⚠ không hỗ trợ mọi vùng và mọi loại VM | | ⚠ Chi phí | ⚠ cao nhất |

Từ khoá nhận diện:

"độ trễ dưới 1 ms" → ⚠ Ultra Disk "CSDL sản xuất thông thường" → ⚠ Premium SSD "cần điều chỉnh IOPS mà không đổi dung lượng" → ⚠ Ultra Disk hoặc Premium SSD v2 "lưu trữ giá rẻ" → ⚠ Standard HDD

⚠ Premium SSD v2 — lựa chọn giữa hai	Đặc điểm
⚠ IOPS và thông lượng độc lập với dung lượng
⚠ Rẻ hơn Ultra Disk
⚠ Độ trễ dưới mili giây ở nhiều tình huống
⚠ Cân nhắc	⚠ thường là điểm cân bằng tốt giữa Premium SSD và Ultra Disk

⚠ Tối ưu SQL Server trên Azure VM	Tối ưu
⚠ Tách đĩa DATA, LOG, TEMPDB
⚠ Log cần độ trễ ghi thấp nhất	⚠ ứng viên hàng đầu cho Ultra Disk
⚠ TempDB nên ở đĩa tạm cục bộ (nếu phù hợp)
⚠ Bật read caching cho đĩa data	⚠ KHÔNG bật cho đĩa log
⚠ Chọn VM có đủ băng thông đĩa	⚠ VM giới hạn IOPS tổng

⚠ Bẫy hay gặp	Bẫy
⚠ Đĩa nhanh nhưng VM giới hạn IOPS	⚠ nút thắt ở VM, không phải đĩa
⚠ Bật write caching cho đĩa log	⚠ rủi ro mất dữ liệu
⚠ Dùng chung một đĩa cho mọi thứ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Loại VM có đủ băng thông cho đĩa không | | | Đĩa log có tách riêng không | | | Đã đo độ trễ thực tế chưa | ⚠ đừng chỉ tin thông số |

Và sai lầm hay gặp khi nâng cấp đĩa để tăng tốc CSDL: quên rằng chính VM cũng có trần IOPS. Gắn Ultra Disk vào một VM cỡ nhỏ thì nút thắt chỉ đơn giản chuyển sang chỗ khác.

Câu 3 Plan and configure a high availability and disaster recovery

If a company wants to ensure their SQL databases hosted on Azure virtual machines remain highly available, what should they configure? (Select the best answer)

A Azure Geo-Replication
B Always On Failover Cluster Instances on Azure VMs
C Azure Always On availability groups
D Differential Backup

Xem giải thích

Đáp án

B — Always On Failover Cluster Instances (FCI) trên Azure VM.

Ghi nhớ về chất lượng câu hỏi

⚠ Câu này và #17402 trong cùng lô nhìn qua có vẻ mâu thuẫn.

Câu	Khoá	Vì sao
⚠ #17399 (câu này)	⚠ FCI trên Azure VM	⚠ hỏi HA cho SQL trên MÁY ẢO
⚠ #17402	⚠ Geo-Replication và Always On AG	⚠ hỏi giải pháp RIÊNG CỦA AZURE

⚠ Không mâu thuẫn — ⚠ hai câu hỏi hai khía cạnh khác nhau: ⚠ một bên là kỹ thuật HA truyền thống dùng được trên VM, ⚠ một bên là dịch vụ đặc thù của nền tảng Azure.

Vì sao đúng

⚠ Always On FCI cho SQL Server trên Azure VM:

⚠ Nhiều node VM trong một cụm
        ↓
⚠ MỘT instance SQL Server duy nhất
   ⚠ chạy trên node đang hoạt động
        ↓
⚠ Dùng CHUNG kho lưu trữ
   ⚠ (Azure Shared Disk, Premium File Share)
        ↓
⚠ Node hỏng → ⚠ instance TỰ CHUYỂN
   sang node khác

Đặc điểm FCI	Nội dung
⚠ Bảo vệ ở mức INSTANCE	⚠ toàn bộ máy chủ SQL, mọi CSDL
⚠ Không mất dữ liệu khi chuyển	⚠ cùng một kho lưu trữ
⚠ Có thời gian gián đoạn ngắn khi chuyển

Vì sao các phương án khác sai

C (Azure Always On availability groups) — ⚠ cũng là giải pháp HA hợp lệ và rất phổ biến: ⚠ nhưng ⚠ đề hỏi "câu trả lời TỐT NHẤT" cho HA của instance trên VM; ⚠ AG bảo vệ ở mức CSDL, không phải toàn bộ instance.
A (Azure Geo-Replication) — ⚠ là tính năng của Azure SQL DATABASE (PaaS): ⚠ không dùng cho SQL Server trên VM; ⚠ và ⚠ thiên về khôi phục thảm hoạ, không phải HA cục bộ.
D (Differential Backup) — ⚠ là sao lưu, KHÔNG phải HA: ⚠ khôi phục từ sao lưu mất hàng giờ.

Ghi nhớ

⚠ FCI so với Availability Group — bảng phải thuộc: | Tiêu chí | ⚠ FCI | ⚠ Always On AG | |---|---|---| | ⚠ Bảo vệ mức | ⚠ INSTANCE (cả máy chủ) | ⚠ từng CSDL hoặc nhóm CSDL | | ⚠ Lưu trữ | ⚠ DÙNG CHUNG | ⚠ mỗi node có bản sao RIÊNG | | ⚠ Bản sao đọc được | ⚠ KHÔNG | ⚠ CÓ — readable secondary | | ⚠ Qua nhiều vùng | ⚠ khó | ⚠ được | | ⚠ Dùng khi | ⚠ HA đơn giản cho cả instance | ⚠ HA + DR + tách tải đọc |

Từ khoá nhận diện:

"HA cho SQL trên Azure VM, mức instance" → ⚠ FCI "bản sao đọc được ở vùng khác" → ⚠ Always On AG hoặc Geo-Replication "Azure SQL Database (PaaS)" → ⚠ Geo-Replication, không phải FCI "khôi phục về một thời điểm" → ⚠ Point in Time Restore

⚠ Ba mô hình triển khai SQL trên Azure	Mô hình
⚠ SQL Server trên Azure VM (IaaS)	⚠ toàn quyền, tự lo HA — FCI, AG
⚠ Azure SQL Managed Instance (PaaS)	⚠ gần như tương thích SQL Server, HA sẵn
⚠ Azure SQL Database (PaaS)	⚠ CSDL đơn lẻ, HA sẵn có, Geo-Replication
⚠ Đề nói "trên Azure VM"	⚠ là mô hình IaaS — tự lo HA

⚠ Yêu cầu hạ tầng cho FCI trên Azure	Yêu cầu
⚠ Windows Server Failover Cluster
⚠ Kho lưu trữ dùng chung	⚠ Azure Shared Disk, Premium Files, hoặc Storage Spaces Direct
⚠ Availability Set hoặc Availability Zone	⚠ để node không cùng một máy chủ vật lý
⚠ Azure Load Balancer	⚠ cho địa chỉ IP của cụm
⚠ Phức tạp hơn tại chỗ	⚠ vì Azure không có subnet chia sẻ kiểu truyền thống

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Node có nằm ở Availability Zone khác nhau không | | | Đã thử chuyển đổi dự phòng thật chưa | ⚠ quan trọng nhất | | Thời gian chuyển thực tế là bao lâu | |

Và điều duy nhất chứng minh một giải pháp HA thật sự hoạt động: đã từng chuyển đổi dự phòng thành công trong một bài diễn tập có kế hoạch. Cấu hình trên giấy và hành vi lúc 3 giờ sáng là hai chuyện khác nhau.

Câu 4 Plan and configure a high availability and disaster recovery

You need to provide a secondary read-only database in a different Azure region for reporting purposes and for disaster recovery. Which feature should you use? (Select the best answer)

A Azure Geo-Replication
B Log Shipping
C Differential Backup
D Azure Failover Cluster

Xem giải thích

Đáp án

A — Azure Geo-Replication.

Vì sao đúng

⚠ Đề cần hai thứ cùng lúc: | Yêu cầu | Geo-Replication | |---|---| | ⚠ Bản sao CHỈ ĐỌC ở vùng Azure KHÁC | ⚠ secondary có thể ĐỌC ĐƯỢC | | ⚠ Phục vụ báo cáo | ⚠ tách tải đọc khỏi CSDL chính | | ⚠ Khôi phục thảm hoạ | ⚠ nâng secondary lên primary khi cần |

⚠ Primary ở vùng A
        ↓ ⚠ nhân bản BẤT ĐỒNG BỘ
⚠ Secondary chỉ đọc ở vùng B
        ↓
⚠ Báo cáo chạy trên secondary
⚠ Vùng A sập → ⚠ nâng B lên primary

⚠ Active Geo-Replication cho tối đa 4 secondary ở các vùng khác nhau.

Vì sao các phương án khác sai

B (Log Shipping) — ⚠ kỹ thuật truyền thống của SQL Server: ⚠ chuyển và khôi phục file log định kỳ; ⚠ không có ở Azure SQL Database (PaaS); ⚠ và ⚠ secondary thường ở chế độ khôi phục, khó dùng để đọc.
D (Azure Failover Cluster) — ⚠ cho HA CỤC BỘ: ⚠ dùng lưu trữ chung, ⚠ không tạo bản sao đọc được ở vùng khác.
C (Differential Backup) — ⚠ là SAO LƯU: ⚠ không phải bản sao trực tuyến, ⚠ không đọc được như một CSDL.

Ghi nhớ

⚠ Giải pháp DR của Azure SQL — bảng phải thuộc: | Giải pháp | Đặc điểm | |---|---| | ⚠ Active Geo-Replication | ⚠ tối đa 4 secondary ĐỌC ĐƯỢC, chuyển đổi THỦ CÔNG | | ⚠ Auto-failover group | ⚠ tự chuyển, có endpoint không đổi, cho nhóm CSDL | | ⚠ Geo-restore | ⚠ khôi phục từ sao lưu địa lý — RTO lâu nhất | | ⚠ Zone-redundant | ⚠ HA trong CÙNG vùng, qua nhiều zone |

Từ khoá nhận diện:

"bản sao chỉ đọc ở vùng khác" → ⚠ Active Geo-Replication "tự động chuyển đổi, chuỗi kết nối không đổi" → ⚠ Auto-failover group "HA trong cùng vùng" → ⚠ zone-redundant configuration "khôi phục về một thời điểm" → ⚠ Point in Time Restore

⚠ Geo-Replication so với Auto-failover group	So sánh
⚠ Geo-Replication: chuyển đổi THỦ CÔNG	⚠ ứng dụng phải đổi chuỗi kết nối
⚠ Auto-failover group: TỰ ĐỘNG, endpoint cố định
⚠ Geo-Replication: từng CSDL
⚠ Auto-failover group: NHÓM CSDL cùng chuyển
⚠ Cho hệ thống sản xuất	⚠ auto-failover group thường tốt hơn

⚠ Nhân bản bất đồng bộ — hệ quả	Hệ quả
⚠ Secondary có thể TRỄ vài giây
⚠ Chuyển đổi khẩn cấp có thể MẤT dữ liệu	⚠ RPO không bằng 0
⚠ Báo cáo trên secondary thấy dữ liệu hơi cũ	⚠ thường chấp nhận được
⚠ Muốn RPO = 0	⚠ cần nhân bản đồng bộ — chỉ có trong cùng vùng

⚠ Lợi ích phụ: tách tải báo cáo	Lợi ích
⚠ Truy vấn báo cáo nặng không ảnh hưởng CSDL chính
⚠ Không tranh chấp khoá với giao dịch
⚠ Cùng một khoản đầu tư phục vụ hai mục đích
⚠ Mẫu chung	⚠ giống read replica của Cloud SQL bên Google Cloud

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ trễ nhân bản là bao nhiêu | ⚠ quyết định RPO thực tế | | Đã diễn tập chuyển đổi chưa | | | Ứng dụng có xử lý được việc đổi endpoint không | |

Và điều cần nói rõ với người dùng báo cáo chạy trên bản sao: số liệu họ thấy trễ vài giây so với hệ thống chính. Với hầu hết báo cáo thì không sao, nhưng phải nói ra trước khi có người đối chiếu hai màn hình và hoảng lên.

Câu 5 Plan and configure a high availability and disaster recovery

For a critical production database, you want to be able to restore to any point in the last 24 hours. Which feature should you enable? (Select the best answer)

A Differential Backup
B Point in Time Restore
C Full Backup
D Log Backup

Xem giải thích

Đáp án

B — Point in Time Restore (khôi phục về một thời điểm).

Vì sao đúng

⚠ Đề cần khôi phục về BẤT KỲ thời điểm nào trong 24 giờ qua:

⚠ Azure SQL Database tự động:
   ⚠ sao lưu ĐẦY ĐỦ hằng tuần
   ⚠ sao lưu VI SAI vài giờ một lần
   ⚠ sao lưu LOG GIAO DỊCH mỗi 5-10 phút
        ↓
⚠ Ghép ba loại lại
        ↓
⚠ Khôi phục về BẤT KỲ giây nào
   trong thời hạn lưu

Đặc điểm	Nội dung
⚠ Bật SẴN, không phải cấu hình gì	⚠ với Azure SQL Database
⚠ Thời hạn mặc định	⚠ 7 ngày (một số bậc), tối đa 35 ngày
⚠ Khôi phục thành CSDL MỚI	⚠ không ghi đè cái đang chạy

Vì sao các phương án khác sai

A (Differential Backup) và C (Full Backup) và D (Log Backup) — ⚠ cả ba là THÀNH PHẦN, không phải tính năng: ⚠ chúng là các loại sao lưu ⚠ mà Point in Time Restore ghép lại để dùng; ⚠ riêng lẻ thì chỉ khôi phục về thời điểm sao lưu đó, ⚠ không phải bất kỳ thời điểm nào.

Ghi nhớ

⚠ Ba loại sao lưu và vai trò — bảng phải thuộc: | Loại | Nội dung | Tần suất Azure SQL | |---|---|---| | ⚠ Full | ⚠ toàn bộ CSDL | ⚠ hằng tuần | | ⚠ Differential | ⚠ thay đổi TỪ lần full gần nhất | ⚠ 12-24 giờ | | ⚠ Transaction log | ⚠ mọi giao dịch | ⚠ 5-10 phút | | ⚠ Ghép cả ba | ⚠ = Point in Time Restore | |

Từ khoá nhận diện:

"khôi phục về bất kỳ thời điểm nào" → ⚠ Point in Time Restore "CSDL đã bị XOÁ" → ⚠ Restore deleted database "khôi phục sang vùng khác" → ⚠ Geo-restore "giữ sao lưu nhiều năm" → ⚠ Long-term retention (LTR)

⚠ Thời hạn lưu sao lưu Azure SQL	Thời hạn
⚠ Short-term retention	⚠ 1-35 ngày, mặc định 7
⚠ Long-term retention (LTR)	⚠ tới 10 NĂM
⚠ LTR lưu bản full hằng tuần/tháng/năm
⚠ Với yêu cầu 24 giờ trong đề	⚠ mặc định đã dư

⚠ Điều phải nhớ về khôi phục	Điều
⚠ Khôi phục tạo CSDL MỚI	⚠ phải đổi tên hoặc đổi chuỗi kết nối
⚠ Thời gian khôi phục phụ thuộc KÍCH THƯỚC	⚠ có thể hàng giờ với CSDL lớn
⚠ Đó là RTO thực tế của bạn
⚠ Nên	⚠ ĐO thời gian khôi phục thật cho CSDL của mình

⚠ RPO và RTO của Point in Time Restore	Con số
⚠ RPO	⚠ rất nhỏ — log sao lưu mỗi 5-10 phút
⚠ RTO	⚠ LỚN — phải chờ khôi phục xong
⚠ Vì vậy	⚠ PITR chống lỗi CON NGƯỜI và hỏng dữ liệu, không phải giải pháp HA
⚠ Muốn RTO nhỏ	⚠ cần HA hoặc failover group

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thời hạn lưu sao lưu đặt bao nhiêu ngày | | | Đã thử khôi phục thật chưa | ⚠ và mất bao lâu | | Có cần long-term retention không | |

Và điều mà chỉ một cuộc diễn tập mới nói cho bạn biết: khôi phục một cơ sở dữ liệu lớn mất bao lâu. Con số đó chính là RTO thật của bạn, và nó thường lớn hơn nhiều so với những gì mọi người tưởng.

Câu 6 Chọn nhiều đáp án Plan and configure a high availability and disaster recovery

Which of the following solutions are specific to Azure for High Availability and Disaster Recovery? (Select all that apply)

A Azure Geo-Replication
B Windows Server Failover Clustering
C Azure Always On availability groups
D Log Shipping

Xem giải thích

Đáp án

A và C — Azure Geo-Replication và Azure Always On availability groups.

Ghi nhớ về chất lượng câu hỏi

⚠ Đối chiếu với #17399 trong cùng lô để tránh nhầm lẫn.

Câu	Hỏi gì	Khoá
⚠ #17399	⚠ HA TỐT NHẤT cho SQL trên Azure VM	⚠ FCI
⚠ #17402 (câu này)	⚠ giải pháp RIÊNG của Azure	⚠ Geo-Replication + Always On AG
⚠ Không mâu thuẫn	⚠ hai câu hỏi hai tiêu chí khác nhau

Vì sao đúng

⚠ Tiêu chí: "riêng của Azure" (specific to Azure): | Giải pháp | Nguồn gốc | |---|---| | ⚠ Azure Geo-Replication | ⚠ tính năng CHỈ CÓ trên Azure SQL | | ⚠ Azure Always On availability groups | ⚠ có tích hợp riêng với Azure: Load Balancer, Availability Zone | | ⚠ Windows Server Failover Clustering | ⚠ công nghệ WINDOWS truyền thống, chạy ở đâu cũng được | | ⚠ Log Shipping | ⚠ kỹ thuật SQL Server cũ, không riêng Azure |

Vì sao các phương án khác sai

B (Windows Server Failover Clustering) — ⚠ là nền tảng của Windows Server: ⚠ có từ trước Azure rất lâu, ⚠ dùng được tại chỗ và ở mọi đám mây.
D (Log Shipping) — ⚠ kỹ thuật SQL Server truyền thống: ⚠ chuyển file log giữa các máy chủ; ⚠ không phải tính năng Azure.

Ghi nhớ

⚠ HA/DR cho SQL — riêng Azure hay không — bảng phải thuộc: | Giải pháp | Riêng Azure | |---|---| | ⚠ Active Geo-Replication | ⚠ CÓ — Azure SQL Database | | ⚠ Auto-failover group | ⚠ CÓ | | ⚠ Zone-redundant configuration | ⚠ CÓ | | ⚠ Always On AG (có tích hợp Azure) | ⚠ có phiên bản riêng cho Azure | | ⚠ WSFC | ⚠ KHÔNG — của Windows Server | | ⚠ Log Shipping, Mirroring | ⚠ KHÔNG — kỹ thuật SQL Server cũ |

Từ khoá nhận diện:

"riêng của Azure" → ⚠ Geo-Replication, failover group, zone-redundant "kỹ thuật SQL Server truyền thống" → ⚠ Log Shipping, Mirroring, WSFC "PaaS (Azure SQL Database)" → ⚠ Geo-Replication "IaaS (SQL trên VM)" → ⚠ FCI hoặc AG

⚠ Bậc thang HA/DR của Azure SQL	Bậc
⚠ 1. HA tích hợp trong một vùng	⚠ có sẵn, không cần cấu hình
⚠ 2. Zone-redundant	⚠ chịu được sập một zone
⚠ 3. Active Geo-Replication	⚠ chịu được sập một VÙNG
⚠ 4. Auto-failover group	⚠ thêm tự động hoá và endpoint cố định
⚠ Chi phí tăng dần	⚠ chọn theo mức thiệt hại khi ngừng dịch vụ

⚠ Kỹ thuật SQL Server truyền thống — vì sao vẫn hỏi	Lý do
⚠ Nhiều tổ chức di trú từ tại chỗ mang theo
⚠ Log Shipping vẫn dùng được trên VM
⚠ Database Mirroring đã bị KHAI TỬ	⚠ thay bằng Always On AG
⚠ Xu hướng	⚠ chuyển sang PaaS thì được HA sẵn, đỡ hẳn phần này

⚠ Vì sao PaaS hấp dẫn cho HA	Lý do
⚠ HA cục bộ có sẵn, SLA 99,99%
⚠ Không phải dựng cụm, không phải vá hệ điều hành
⚠ Sao lưu tự động
⚠ Geo-Replication bật bằng vài thao tác
⚠ Đánh đổi	⚠ ít quyền kiểm soát, một số tính năng SQL Server không có

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang dùng IaaS hay PaaS | ⚠ quyết định giải pháp HA khả dụng | | SLA cam kết với người dùng là bao nhiêu | | | Đã diễn tập chuyển vùng chưa | |

Và lý do đáng cân nhắc chuyển từ SQL trên VM sang Azure SQL Database: phần lớn công việc HA biến mất khỏi bảng công việc của bạn. Đổi lại là mất một số quyền kiểm soát — và với nhiều tổ chức, đó là một cuộc trao đổi rất có lợi.

Câu 7 Plan and configure a high availability and disaster recovery

Your organization requires a database recovery solution that minimizes data loss but does not require instantaneous recovery. Which of the following strategies best aligns with these requirements? (Select the best answer)

A Low RPO and High RTO
B High RPO and Low RTO
C Low RPO and Low RTO
D High RPO and High RTO

Xem giải thích

Đáp án

A — RPO thấp và RTO cao.

Vì sao đúng

⚠ Dịch yêu cầu của đề sang hai chỉ số: | Yêu cầu | Chỉ số | |---|---| | ⚠ "Giảm thiểu MẤT DỮ LIỆU" | ⚠ RPO THẤP | | ⚠ "KHÔNG cần khôi phục tức thì" | ⚠ RTO CAO là chấp nhận được |

⚠ RPO (Recovery Point Objective)
   ⚠ "chấp nhận MẤT bao nhiêu dữ liệu"
   ⚠ đo bằng THỜI GIAN dữ liệu bị mất
   ⚠ THẤP = ⚠ mất ít

⚠ RTO (Recovery Time Objective)
   ⚠ "bao lâu thì hệ thống chạy lại"
   ⚠ CAO = ⚠ chấp nhận chờ lâu

⚠ Ví dụ hệ thống phù hợp: ⚠ sao lưu log giao dịch mỗi 5 phút (RPO thấp), ⚠ khôi phục mất vài giờ (RTO cao).

Vì sao các phương án khác sai

B (RPO cao, RTO thấp) — ⚠ NGƯỢC yêu cầu: ⚠ nghĩa là chấp nhận mất nhiều dữ liệu nhưng phải khôi phục nhanh.
C (RPO thấp, RTO thấp) — ⚠ lý tưởng nhưng ĐẮT NHẤT: ⚠ đề nói rõ ⚠ không cần khôi phục tức thì — ⚠ trả tiền cho RTO thấp là lãng phí.
D (RPO cao, RTO cao) — ⚠ rẻ nhất nhưng KHÔNG đáp ứng yêu cầu giảm thiểu mất dữ liệu.

Ghi nhớ

⚠ RPO và RTO — bảng phải thuộc: | Chỉ số | Câu hỏi | Quyết định | |---|---|---| | ⚠ RPO | ⚠ "mất bao nhiêu dữ liệu là chấp nhận được?" | ⚠ TẦN SUẤT sao lưu / nhân bản | | ⚠ RTO | ⚠ "ngừng bao lâu là chấp nhận được?" | ⚠ KIẾN TRÚC dự phòng |

Từ khoá nhận diện:

"không được mất dữ liệu" → ⚠ RPO thấp "phải chạy lại ngay" → ⚠ RTO thấp "cả hai đều thấp" → ⚠ rất đắt — hot standby, nhân bản đồng bộ "cả hai đều cao" → ⚠ rẻ — sao lưu và khôi phục thủ công

⚠ Bốn mẫu DR theo RPO/RTO	Mẫu
⚠ Backup and restore	⚠ RPO và RTO cao — rẻ nhất
⚠ Pilot light	⚠ RTO trung bình, hạ tầng tối thiểu chạy sẵn
⚠ Warm standby	⚠ RTO thấp hơn, hệ thống thu nhỏ chạy sẵn
⚠ Hot standby / multi-site	⚠ RPO và RTO gần bằng 0 — đắt nhất
⚠ Đề này	⚠ nhân bản thường xuyên nhưng khôi phục thủ công

⚠ Vì sao RPO thấp không đòi RTO thấp	Lý do
⚠ RPO quyết định TẦN SUẤT sao chép dữ liệu	⚠ rẻ hơn nhiều
⚠ RTO quyết định có HẠ TẦNG DỰ PHÒNG chạy sẵn hay không	⚠ đắt
⚠ Có thể sao lưu log mỗi 5 phút mà không giữ máy chủ dự phòng
⚠ Đây là cách	⚠ tối ưu chi phí đúng theo nhu cầu thật

⚠ Xác định RPO và RTO thế nào	Cách
⚠ Hỏi NGHIỆP VỤ, không hỏi kỹ thuật
⚠ Ước lượng thiệt hại mỗi giờ ngừng dịch vụ
⚠ Ước lượng thiệt hại khi mất một giờ dữ liệu
⚠ So sánh với chi phí giải pháp
⚠ Sai lầm phổ biến	⚠ ai cũng trả lời "không được mất gì, phải chạy ngay" cho đến khi thấy giá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | RPO và RTO đã được nghiệp vụ xác nhận bằng văn bản chưa | | | RTO đo được thực tế là bao nhiêu | ⚠ diễn tập | | Chi phí giải pháp có tương xứng thiệt hại không | |

Và cách hiệu quả nhất để có một con số RPO/RTO thực tế: đưa kèm bảng giá. Yêu cầu "không được mất dữ liệu và phải chạy lại ngay lập tức" thường được điều chỉnh rất nhanh khi người ra yêu cầu nhìn thấy chi phí của nó.

Câu 8 Configure and manage automation of tasks (15–20%)

You want to create a workflow to automatically process data from an Azure SQL Database and send a notification when the process is complete. Which service should you use? (Select the best answer)

A Azure CLI
B PowerShell
C Azure Logic Apps
D ARM templates

Xem giải thích

Đáp án

C — Azure Logic Apps.

Vì sao đúng

⚠ Đề cần một QUY TRÌNH tự động: xử lý dữ liệu → rồi GỬI THÔNG BÁO.

⚠ Trigger (lịch, hoặc sự kiện)
        ↓
⚠ Connector Azure SQL Database
   ⚠ chạy truy vấn, đọc/ghi dữ liệu
        ↓
⚠ Điều kiện, vòng lặp, xử lý lỗi
        ↓
⚠ Connector Outlook / Teams / SendGrid
   ⚠ gửi thông báo

Vì sao Logic Apps hợp	Lý do
⚠ Có sẵn connector cho Azure SQL	⚠ không phải viết mã kết nối
⚠ Có sẵn connector gửi mail, Teams, Slack
⚠ Thiết kế bằng giao diện trực quan
⚠ Tự thử lại và ghi lịch sử chạy

Vì sao các phương án khác sai

A (Azure CLI) và B (PowerShell) — ⚠ là công cụ RA LỆNH, không phải nền tảng quy trình: ⚠ viết được script nhưng ⚠ phải tự lo lập lịch, thử lại, thông báo, ghi log.
D (ARM template) — ⚠ để TRIỂN KHAI hạ tầng: ⚠ mô tả tài nguyên cần tạo, ⚠ không chạy quy trình nghiệp vụ.

Ghi nhớ

⚠ Công cụ tự động hoá của Azure — bảng phải thuộc: | Công cụ | Dùng cho | |---|---| | ⚠ Logic Apps | ⚠ quy trình có nhiều bước, nhiều hệ thống, ít mã | | ⚠ Azure Functions | ⚠ mã tuỳ chỉnh chạy theo sự kiện | | ⚠ Azure Automation | ⚠ runbook PowerShell cho việc vận hành | | ⚠ Data Factory | ⚠ đường ống ETL dữ liệu lớn | | ⚠ ARM / Bicep | ⚠ triển khai hạ tầng | | ⚠ Elastic Jobs | ⚠ chạy T-SQL trên NHIỀU CSDL Azure SQL |

Từ khoá nhận diện:

"quy trình nhiều bước + thông báo" → ⚠ Logic Apps "triển khai tài nguyên" → ⚠ ARM template / Bicep "chạy T-SQL định kỳ trên Azure SQL Database" → ⚠ Elastic Jobs "chạy job trên SQL trên VM" → ⚠ SQL Server Agent

⚠ Logic Apps so với Azure Functions	So sánh
⚠ Logic Apps: ÍT MÃ, kéo thả, nhiều connector sẵn
⚠ Functions: viết mã, linh hoạt tối đa
⚠ Logic Apps: tính phí theo số HÀNH ĐỘNG
⚠ Functions: tính phí theo lần chạy và thời gian
⚠ Kết hợp	⚠ Logic Apps điều phối, gọi Function cho phần logic phức tạp

⚠ Điều Azure SQL Database KHÔNG có	Thiếu
⚠ KHÔNG có SQL Server Agent	⚠ khác hẳn SQL Server trên VM
⚠ Thay bằng Elastic Jobs hoặc Logic Apps
⚠ Managed Instance thì CÓ SQL Agent
⚠ Đây là khác biệt	⚠ hay bị hỏi trong đề

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quy trình lỗi thì ai được báo | | | Logic App có ghi lịch sử chạy không | ⚠ có sẵn, rất hữu ích khi gỡ lỗi | | Chi phí theo số hành động đã ước tính chưa | ⚠ vòng lặp lớn có thể đắt |

Và khác biệt lớn nhất giữa một script và một quy trình thật: script chạy xong rồi thôi, quy trình biết mình đã chạy tới đâu và báo cho ai khi hỏng. Đó chính là phần mà mọi người hay bỏ qua cho tới lần đầu tiên nó hỏng lúc nửa đêm.

Câu 9 Configure and manage automation of tasks (15–20%)

You're facing an issue where a SQL Server Agent job is failing intermittently. Which feature should you configure to get an immediate notification upon job failure? (Select the best answer)

A Configure job alerts
B ARM templates
C Azure Logic Apps
D Elastic jobs

Xem giải thích

Đáp án

A — Cấu hình job alert (cảnh báo cho công việc).

Vì sao đúng

⚠ SQL Server Agent có cơ chế cảnh báo tích hợp sẵn:

⚠ Job chạy → ⚠ THẤT BẠI
        ↓
⚠ Job alert được kích hoạt
        ↓
⚠ Operator được thông báo
   ⚠ email, pager, net send
        ↓
⚠ Người trực biết NGAY

Cấu hình gồm	Nội dung
⚠ Operator	⚠ người nhận thông báo và địa chỉ email
⚠ Database Mail	⚠ cấu hình gửi mail
⚠ Notification trên job	⚠ gửi khi thất bại / thành công / hoàn tất

⚠ Đây là cách đơn giản nhất và có sẵn — ⚠ không phải dựng thêm gì.

Vì sao các phương án khác sai

C (Azure Logic Apps) — ⚠ làm được nhưng THỪA: ⚠ phải dựng một quy trình riêng để theo dõi job; ⚠ trong khi ⚠ SQL Agent đã có sẵn cơ chế.
D (Elastic Jobs) — ⚠ để CHẠY T-SQL trên nhiều CSDL: ⚠ không phải cơ chế cảnh báo.
B (ARM template) — ⚠ triển khai hạ tầng, không liên quan.

Ghi nhớ

⚠ Thành phần thông báo của SQL Server Agent — bảng phải thuộc: | Thành phần | Vai trò | |---|---| | ⚠ Operator | ⚠ định danh người nhận | | ⚠ Alert | ⚠ phản ứng với SỰ KIỆN hoặc chỉ số hiệu năng | | ⚠ Job notification | ⚠ báo khi job kết thúc theo trạng thái | | ⚠ Database Mail | ⚠ thành phần gửi mail — PHẢI cấu hình trước | | ⚠ Quên Database Mail | ⚠ cảnh báo im lặng không đến ai cả |

Từ khoá nhận diện:

"báo ngay khi job SQL Agent hỏng" → ⚠ job alert + operator "chạy job trên nhiều CSDL Azure SQL" → ⚠ Elastic Jobs "quy trình nhiều hệ thống" → ⚠ Logic Apps "giám sát chỉ số hạ tầng" → ⚠ Azure Monitor alert

⚠ Ba loại alert của SQL Server Agent	Loại
⚠ SQL Server event alert	⚠ theo mã lỗi hoặc mức nghiêm trọng
⚠ Performance condition alert	⚠ theo bộ đếm hiệu năng
⚠ WMI event alert	⚠ theo sự kiện hệ điều hành
⚠ Với job hỏng	⚠ dùng notification trên chính job đó là gọn nhất

⚠ Chẩn đoán job hỏng KHÔNG THƯỜNG XUYÊN	Chẩn đoán
⚠ Xem job history — bước nào hỏng
⚠ Bật ghi log ra file cho từng bước
⚠ Kiểm tra tranh chấp tài nguyên vào giờ đó	⚠ job khác chạy trùng giờ
⚠ Kiểm tra deadlock và timeout
⚠ Lỗi ngắt quãng	⚠ thường do TRANH CHẤP hoặc phụ thuộc bên ngoài, không phải do mã

⚠ Azure SQL Database thì sao	Khác biệt
⚠ KHÔNG có SQL Server Agent
⚠ Dùng Elastic Jobs + Azure Monitor alert
⚠ Hoặc Logic Apps
⚠ Managed Instance	⚠ CÓ SQL Agent đầy đủ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Database Mail đã cấu hình và thử gửi chưa | ⚠ bước hay bị bỏ sót | | Operator có địa chỉ còn dùng được không | ⚠ người nghỉ việc là mất cảnh báo | | Job có ghi log chi tiết từng bước không | |

Và cách một hệ thống cảnh báo âm thầm chết: địa chỉ email của operator thuộc về một người đã nghỉ việc từ lâu. Job vẫn hỏng, cảnh báo vẫn gửi, và không ai nhận được.

Câu 10 Chọn nhiều đáp án Configure and manage automation of tasks (15–20%)

Which of the following tools or platforms can you use to automate deployment in Azure? (Select all that apply)

A Azure CLI
B Azure Logic Apps
C PowerShell
D SQL Server Management Studio

Xem giải thích

Đáp án

A và C — Azure CLI và PowerShell.

Vì sao đúng

⚠ Hai công cụ dòng lệnh chính thức của Azure: | Công cụ | Đặc điểm | |---|---| | ⚠ Azure CLI (az) | ⚠ đa nền tảng, cú pháp gọn, hợp với script bash | | ⚠ Azure PowerShell (Az module) | ⚠ mạnh cho môi trường Windows, xử lý đối tượng |

⚠ Cả hai đều: ⚠ script hoá được, ⚠ nhúng vào CI/CD được, ⚠ tạo và cấu hình được mọi tài nguyên Azure.

Vì sao các phương án khác sai

B (Azure Logic Apps) — ⚠ là nền tảng QUY TRÌNH nghiệp vụ: ⚠ để nối các dịch vụ và tự động hoá công việc, ⚠ không phải công cụ triển khai hạ tầng.
D (SQL Server Management Studio) — ⚠ công cụ quản trị CSDL bằng giao diện: ⚠ không triển khai tài nguyên Azure.

Ghi nhớ

⚠ Công cụ triển khai Azure — bảng phải thuộc: | Công cụ | Kiểu | |---|---| | ⚠ Azure CLI | ⚠ mệnh lệnh (imperative) — làm từng bước | | ⚠ Azure PowerShell | ⚠ mệnh lệnh | | ⚠ ARM template / Bicep | ⚠ KHAI BÁO (declarative) — mô tả kết quả mong muốn | | ⚠ Terraform | ⚠ khai báo, đa đám mây | | ⚠ Azure Portal | ⚠ thủ công, không lặp lại được |

Từ khoá nhận diện:

"tự động hoá triển khai bằng script" → ⚠ CLI hoặc PowerShell "triển khai nhiều tài nguyên như một đơn vị" → ⚠ ARM template / Bicep "đa đám mây" → ⚠ Terraform "quy trình nghiệp vụ" → ⚠ Logic Apps

⚠ Mệnh lệnh so với khai báo	So sánh
⚠ Mệnh lệnh: mô tả CÁC BƯỚC phải làm	⚠ chạy lại có thể lỗi vì tài nguyên đã tồn tại
⚠ Khai báo: mô tả TRẠNG THÁI mong muốn	⚠ chạy lại an toàn (idempotent)
⚠ Thực tế hay dùng	⚠ khai báo cho hạ tầng, mệnh lệnh cho thao tác vận hành

⚠ Azure CLI so với PowerShell	So sánh
⚠ CLI: `az sql db create ...`	⚠ cú pháp ngắn, học nhanh
⚠ PowerShell: `New-AzSqlDatabase ...`	⚠ trả về ĐỐI TƯỢNG, xử lý tiếp được
⚠ CLI: hợp với bash, Linux, macOS
⚠ PowerShell: hợp với hệ sinh thái Windows
⚠ Cả hai	⚠ chạy được trong Azure Cloud Shell, không cần cài

⚠ Đưa vào CI/CD	Cách
⚠ Azure DevOps Pipelines hoặc GitHub Actions
⚠ Xác thực bằng service principal hoặc managed identity
⚠ Lưu script trong Git	⚠ có lịch sử, có rà soát
⚠ Nguyên tắc	⚠ thao tác tay trên Portal thì không ai dựng lại được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hạ tầng có được mô tả bằng mã không | | | Script có chạy lại được an toàn không | | | Có ai còn tạo tài nguyên bằng tay trên Portal không | ⚠ gây trôi cấu hình |

Và lý do nên chuyển từ thao tác tay trên cổng quản trị sang script: không phải để nhanh hơn, mà để LẶP LẠI được. Một môi trường dựng bằng tay không bao giờ dựng lại được giống hệt, và điều đó chỉ lộ ra vào lúc khẩn cấp nhất.

Ngân hàng đề — Microsoft Administering Azure SQL

Đáp án

Vì sao đúng

Vì sao các phương án khác sai

Ghi nhớ

Đáp án

Vì sao đúng

Vì sao các phương án khác sai

Ghi nhớ

Đáp án

Ghi nhớ về chất lượng câu hỏi

Vì sao đúng

Vì sao các phương án khác sai

Ghi nhớ

Đáp án

Vì sao đúng

Vì sao các phương án khác sai

Ghi nhớ

Đáp án

Vì sao đúng

Vì sao các phương án khác sai

Ghi nhớ

Đáp án

Ghi nhớ về chất lượng câu hỏi

Vì sao đúng

Vì sao các phương án khác sai

Ghi nhớ

Đáp án

Vì sao đúng

Vì sao các phương án khác sai

Ghi nhớ

Đáp án

Vì sao đúng

Vì sao các phương án khác sai

Ghi nhớ

Đáp án

Vì sao đúng

Vì sao các phương án khác sai

Ghi nhớ

Đáp án

Vì sao đúng

Vì sao các phương án khác sai

Ghi nhớ