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

Đáp án

C — SQL Data Sync.

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

⚠ Câu này GẦN TRÙNG với #17418 trong cùng lô.

Vì sao đúng

⚠ SQL Data Sync đúng tên gọi và đúng mục đích:

⚠ CSDL A ↔ ⚠ HUB ↔ ⚠ CSDL B
        ↓
⚠ Đồng bộ HAI CHIỀU theo lịch
        ↓
⚠ Chọn được từng bảng, từng cột

⚠ Hub bắt buộc là Azure SQL Database; ⚠ member có thể là Azure SQL Database khác hoặc SQL Server tại chỗ.

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

• D (Azure Data Factory) — ⚠ công cụ ETL/tích hợp dữ liệu: ⚠ chép và biến đổi dữ liệu theo đường ống ⚠ MỘT CHIỀU; ⚠ dùng được nhưng ⚠ không phải "giữ hai CSDL đồng bộ" theo nghĩa hai chiều.

• B (Azure File Sync) — ⚠ đồng bộ THƯ MỤC TỆP giữa máy chủ file Windows và Azure Files.

• A ("Azure Blob Sync") — ⚠ dịch vụ KHÔNG TỒN TẠI.

Ghi nhớ

⚠ Các cách sao chép dữ liệu trong Azure — bảng phải thuộc: | Cách | Chiều | Ca dùng | |---|---|---| | ⚠ SQL Data Sync | ⚠ HAI chiều | ⚠ phân phối dữ liệu, lai tại chỗ | | ⚠ Active Geo-Replication | ⚠ MỘT chiều | ⚠ DR, bản sao đọc | | ⚠ Data Factory | ⚠ MỘT chiều, có biến đổi | ⚠ ETL, kho dữ liệu | | ⚠ Transactional Replication | ⚠ MỘT chiều | ⚠ phân phối theo thời gian gần thực | | ⚠ Azure File Sync | ⚠ hai chiều | ⚠ TỆP, không phải CSDL |

Từ khoá nhận diện:

"giữ hai CSDL đồng bộ hai chiều" → ⚠ SQL Data Sync "ETL, biến đổi dữ liệu" → ⚠ Data Factory "bản sao dự phòng ở vùng khác" → ⚠ Geo-Replication "đồng bộ thư mục tệp" → ⚠ Azure File Sync

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thật sự cần ghi ở nhiều nơi không | ⚠ nếu không, một chiều đơn giản hơn nhiều | | Quy tắc xử lý xung đột đã chọn chưa | | | Độ trễ đồng bộ có chấp nhận được không | ⚠ tối thiểu 5 phút |

Và câu hỏi nên đặt trước khi dựng bất kỳ hệ thống đồng bộ hai chiều nào: có thể thiết kế lại để chỉ MỘT nơi được ghi không?. Đồng bộ một chiều đơn giản hơn, ít lỗi hơn, và không bao giờ có xung đột.

Đáp án

C — Always Encrypted.

Vì sao đúng

⚠ Always Encrypted mã hoá TẠI MÁY KHÁCH:

⚠ Ứng dụng (driver client)
   ⚠ MÃ HOÁ dữ liệu tại đây
        ↓ ⚠ gửi đi đã mã hoá
⚠ Đường truyền: đã mã hoá
        ↓
⚠ SQL Server: LƯU dạng mã hoá
   ⚠ server KHÔNG có khoá
        ↓
⚠ Đọc về: client tự GIẢI MÃ

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

• A (TDE) — ⚠ mã hoá ở tầng SERVER khi ghi xuống đĩa: ⚠ dữ liệu đi tới server ở dạng THƯỜNG, ⚠ và ⚠ DBA đọc được bình thường.

• D (Row-Level Security) — ⚠ kiểm soát truy cập DÒNG, không mã hoá.

• B ("Object-Level Encryption") — ⚠ không phải thuật ngữ của SQL Server.

Ghi nhớ

⚠ TDE so với Always Encrypted — bảng phải thuộc: | Tiêu chí | ⚠ TDE | ⚠ Always Encrypted | |---|---|---| | ⚠ Mã hoá ở đâu | ⚠ SERVER, khi ghi đĩa | ⚠ CLIENT, trước khi gửi | | ⚠ Phạm vi | ⚠ cả CSDL | ⚠ từng CỘT | | ⚠ DBA đọc được | ⚠ CÓ | ⚠ KHÔNG | | ⚠ Ứng dụng cần sửa | ⚠ KHÔNG | ⚠ CÓ — driver và chuỗi kết nối | | ⚠ Truy vấn | ⚠ bình thường | ⚠ HẠN CHẾ nhiều |

Từ khoá nhận diện:

"mã hoá trước khi rời máy khách" → ⚠ Always Encrypted "mã hoá tệp dữ liệu, trong suốt" → ⚠ TDE "che khi hiển thị" → ⚠ Dynamic Data Masking "DBA không được đọc" → ⚠ Always Encrypted

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn hiện tại có dùng LIKE trên cột đó không | ⚠ sẽ hỏng | | CMK lưu ở đâu, ai truy cập được | | | Ứng dụng đã dùng driver hỗ trợ chưa | |

Và cái giá thật của Always Encrypted không nằm ở hiệu năng: nó nằm ở việc bạn mất gần hết khả năng truy vấn trên cột đó. Hãy chắc chắn rằng cột nhạy cảm đó chỉ cần đọc ra và hiển thị, chứ không phải để tìm kiếm hay lọc.

Đáp án

D — Dynamic Data Masking (DDM).

Vì sao đúng

⚠ DDM che GIÁ TRỊ ở tầng hiển thị, theo quyền của người truy vấn:

⚠ Cùng một câu SELECT
        ↓
⚠ Người có quyền UNMASK
   → ⚠ thấy 4111-1111-1111-1234
⚠ Người KHÔNG có quyền
   → ⚠ thấy XXXX-XXXX-XXXX-1234
        ↓
⚠ Dữ liệu THẬT vẫn nguyên trong CSDL

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

• B (TDE) — ⚠ mã hoá TỆP khi lưu: ⚠ người dùng hợp lệ vẫn thấy giá trị thật.

• C (Data Classification) — ⚠ GẮN NHÃN mức nhạy cảm: ⚠ chỉ để biết và báo cáo, ⚠ không che gì.

• A (Data Compression) — ⚠ nén dữ liệu để tiết kiệm chỗ, không liên quan bảo mật.

Ghi nhớ

⚠ Dynamic Data Masking — điều phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ Che ở tầng HIỂN THỊ | ⚠ dữ liệu thật không đổi | | ⚠ Quyền UNMASK | ⚠ ai có thì thấy giá trị thật | | ⚠ Thành viên db_owner luôn thấy thật | | | ⚠ Không cần sửa ứng dụng | | | ⚠ Cấu hình ở mức CỘT | |

Từ khoá nhận diện:

"thấy XXXX thay vì giá trị thật" → ⚠ Dynamic Data Masking "mã hoá file dữ liệu" → ⚠ TDE "chỉ thấy dòng của mình" → ⚠ Row-Level Security "gắn nhãn nhạy cảm" → ⚠ Data Classification

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đang có quyền UNMASK | | | Có ai là db_owner không cần thiết không | ⚠ họ thấy hết | | Cột nhạy cảm nhất có cần biện pháp mạnh hơn không | |

Và điều phải nói rõ mỗi khi giới thiệu Dynamic Data Masking: nó không phải một biện pháp bảo mật, mà là một lớp giảm rủi ro hiển thị. Ai kiên nhẫn viết vài câu truy vấn vẫn suy ra được giá trị bị che.

Đáp án

A và C — SQL Insights và Query Store.

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

⚠ Azure Monitor (phương án D) cũng giám sát được, nhưng ở mức khác.

⚠ Đề hỏi "hiệu năng TRUY VẤN" → ⚠ hai công cụ đầu; ⚠ Azure Monitor thiên về chỉ số tài nguyên.

Vì sao đúng

⚠ Hai công cụ, hai góc nhìn bổ sung nhau:

⚠ Query Store
   ⚠ "truy vấn nào tốn nhất?"
   ⚠ "kế hoạch có đổi không?"
   ⚠ NẰM TRONG chính CSDL

⚠ SQL Insights
   ⚠ "workload tổng thể thế nào?"
   ⚠ "so sánh nhiều CSDL"
   ⚠ Thu vào Log Analytics

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

• D (Azure Monitor) — ⚠ giám sát chỉ số hạ tầng: ⚠ cho biết CSDL có bị nghẽn tài nguyên không, ⚠ nhưng ⚠ không chỉ ra truy vấn nào gây ra.

• B (Azure Logic Apps) — ⚠ nền tảng quy trình nghiệp vụ, ⚠ hoàn toàn không phải công cụ giám sát.

Ghi nhớ

⚠ Bốn tầng giám sát Azure SQL — bảng phải thuộc: | Tầng | Công cụ | Trả lời | |---|---|---| | ⚠ Tài nguyên | ⚠ Azure Monitor | ⚠ CPU/IO có đầy không | | ⚠ Workload | ⚠ SQL Insights | ⚠ tổng thể thế nào, chờ ở đâu | | ⚠ Truy vấn | ⚠ Query Store | ⚠ câu nào tốn, kế hoạch đổi ra sao | | ⚠ Sự kiện | ⚠ Extended Events | ⚠ bắt deadlock, lỗi cụ thể |

Từ khoá nhận diện:

"hiệu năng truy vấn" → ⚠ Query Store, SQL Insights "CPU, DTU, kết nối" → ⚠ Azure Monitor "deadlock, timeout" → ⚠ Extended Events "ai truy cập dữ liệu" → ⚠ Auditing

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Query Store có đang ở chế độ READ_WRITE không | ⚠ đầy thì tự chuyển READ_ONLY | | Báo cáo Regressed Queries có gì | | | Có cảnh báo trên chỉ số tài nguyên không | |

Và trạng thái âm thầm khiến Query Store ngừng có ích: nó bị đầy và tự chuyển sang chỉ đọc. Từ lúc đó nó không ghi thêm gì nữa, và không ai biết cho tới khi cần điều tra một sự cố mới.

Đáp án

B — Query Store.

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

⚠ Câu này chỉ có BA phương án (A, B, C) thay vì bốn — ⚠ dấu hiệu đề bị cắt mất một dòng khi nhập.

⚠ Ngoài ra ⚠ cùng chủ đề với #17430 trong lô này (Query Store là công cụ giám sát hiệu năng truy vấn).

Vì sao đúng

⚠ Query Store lưu lịch sử và xếp hạng truy vấn theo tài nguyên tiêu thụ:

⚠ Mọi truy vấn thực thi
        ↓ ⚠ Query Store ghi lại
   ⚠ văn bản truy vấn
   ⚠ kế hoạch thực thi
   ⚠ thời gian, CPU, đọc đĩa, bộ nhớ
        ↓
⚠ Báo cáo "Top Resource Consuming Queries"
        ↓
⚠ Xếp hạng theo CPU, thời gian,
   số lần đọc, bộ nhớ

⚠ Đúng cụm từ trong đề: ⚠ "expensive queries executed RECENTLY" — ⚠ Query Store có dữ liệu lịch sử gần đây.

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

• A (Extended Events) — ⚠ bắt được truy vấn tốn kém nhưng phải CẤU HÌNH TRƯỚC: ⚠ nếu chưa dựng session từ trước thì ⚠ không có dữ liệu về quá khứ; ⚠ Query Store thì luôn ghi sẵn.

• C (SQL Data Sync) — ⚠ đồng bộ dữ liệu giữa các CSDL: ⚠ hoàn toàn không liên quan tới hiệu năng.

Ghi nhớ

⚠ Query Store so với Extended Events — bảng phải thuộc: | Tiêu chí | ⚠ Query Store | ⚠ Extended Events | |---|---|---| | ⚠ Cần cấu hình trước | ⚠ KHÔNG (đã bật sẵn) | ⚠ CÓ | | ⚠ Dữ liệu quá khứ | ⚠ CÓ sẵn | ⚠ chỉ từ lúc bật session | | ⚠ Phạm vi | ⚠ truy vấn và kế hoạch | ⚠ mọi loại sự kiện | | ⚠ Ca dùng | ⚠ điều tra hiệu năng thường ngày | ⚠ điều tra sự kiện cụ thể |

Từ khoá nhận diện:

"truy vấn tốn kém gần đây" → ⚠ Query Store "bắt deadlock, sự kiện cụ thể" → ⚠ Extended Events "trạng thái NGAY BÂY GIỜ" → ⚠ DMV "tại sao truy vấn này chậm" → ⚠ execution plan

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Query Store giữ dữ liệu bao nhiêu ngày | | | Truy vấn tốn nhất theo TỔNG là câu nào | | | Có truy vấn nào chạy rất nhiều lần không | |

Và sai lầm phổ biến khi tìm nguyên nhân hệ thống chậm: chỉ nhìn truy vấn chạy lâu nhất. Thủ phạm thật thường là một câu truy vấn nhanh nhưng được gọi hàng vạn lần mỗi phút.

Đáp án

A và D — Index Scan và Hash Match.

Vì sao đúng

⚠ Hai phép toán này thường báo hiệu vấn đề: | Phép toán | Vì sao đáng nghi | |---|---| | ⚠ Index Scan | ⚠ QUÉT TOÀN BỘ index thay vì tìm trực tiếp — thường do thiếu index phù hợp hoặc điều kiện lọc không dùng được index | | ⚠ Hash Match | ⚠ JOIN hoặc tổng hợp bằng bảng băm trong BỘ NHỚ — tốn RAM, có thể TRÀN sang tempdb |

⚠ Index SEEK
   ⚠ đi thẳng tới dòng cần — TỐT

⚠ Index SCAN
   ⚠ đọc hết rồi lọc — ĐÁNG NGỜ

⚠ Hash Match
   ⚠ dựng bảng băm cho tập lớn
   ⚠ tràn tempdb thì rất chậm

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

• C (Seek Predicate) — ⚠ là DẤU HIỆU TỐT: ⚠ nghĩa là điều kiện lọc dùng được index để tìm trực tiếp.

• B (Nested Loops) — ⚠ KHÔNG xấu về bản chất: ⚠ rất hiệu quả với tập dữ liệu NHỎ; ⚠ chỉ thành vấn đề khi số dòng lớn — ⚠ nhưng đề chọn hai phương án rõ ràng hơn.

Ghi nhớ

⚠ Phép toán trong execution plan — bảng phải thuộc: | Phép toán | Đánh giá | |---|---| | ⚠ Index Seek | ⚠ TỐT — tìm trực tiếp | | ⚠ Index Scan / Table Scan | ⚠ đáng ngờ — quét toàn bộ | | ⚠ Key Lookup | ⚠ đáng ngờ — index thiếu cột, cân nhắc INCLUDE | | ⚠ Nested Loops | ⚠ tốt cho tập nhỏ | | ⚠ Merge Join | ⚠ hiệu quả khi cả hai bên đã sắp xếp | | ⚠ Hash Match | ⚠ cho tập lớn, tốn bộ nhớ | | ⚠ Sort | ⚠ tốn kém — cân nhắc index theo thứ tự đó |

Từ khoá nhận diện:

"quét toàn bộ" → ⚠ thiếu index, hoặc điều kiện không dùng được index "key lookup nhiều" → ⚠ thêm cột vào INCLUDE của index "spill to tempdb" → ⚠ ước tính số dòng sai, hoặc thiếu bộ nhớ "warning ép kiểu ngầm" → ⚠ index bị vô hiệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Số dòng ước tính có gần thực tế không | ⚠ gốc của phần lớn vấn đề | | Có cảnh báo spill hay ép kiểu ngầm không | | | Truy vấn có thật sự cần đọc nhiều dòng vậy không | |

Và nguyên nhân gốc đứng sau phần lớn các phép toán tốn kém trong execution plan: bộ tối ưu ước tính sai số dòng. Sửa thống kê thường hiệu quả hơn nhiều so với việc cố ép một kế hoạch cụ thể.

Đáp án

B — Phát hiện vấn đề hiệu năng.

Vì sao đúng

⚠ DMV (Dynamic Management View) là cửa sổ nhìn vào trạng thái nội bộ của SQL Server: | Nhóm DMV | Cho biết | |---|---| | ⚠ sys.dm_exec_* | ⚠ truy vấn đang chạy, thống kê thực thi | | ⚠ sys.dm_os_* | ⚠ chờ đợi, bộ nhớ, luồng của hệ điều hành | | ⚠ sys.dm_db_* | ⚠ index, phân mảnh, thống kê CSDL | | ⚠ sys.dm_tran_* | ⚠ giao dịch, khoá | | ⚠ sys.dm_io_* | ⚠ thống kê vào ra đĩa |

⚠ DMV = ⚠ ảnh chụp trạng thái HIỆN TẠI
        ↓
⚠ "Truy vấn nào đang chạy?"
⚠ "Đang chờ cái gì?"
⚠ "Index nào thiếu?"
⚠ "Index nào không ai dùng?"

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

• A (mã hoá dữ liệu) — ⚠ là việc của TDE và Always Encrypted: ⚠ DMV chỉ ĐỌC, không thay đổi gì.

• C (thiết lập geo-replication) — ⚠ cấu hình qua Portal, CLI hoặc T-SQL: ⚠ DMV chỉ quan sát.

• D (cấu hình data masking) — ⚠ dùng lệnh ALTER TABLE ... ADD MASKED WITH.

Ghi nhớ

⚠ DMV quan trọng nhất phải thuộc: | DMV | Cho biết | |---|---| | ⚠ sys.dm_exec_requests | ⚠ truy vấn đang chạy NGAY BÂY GIỜ | | ⚠ sys.dm_exec_query_stats | ⚠ thống kê tích luỹ theo truy vấn | | ⚠ sys.dm_os_wait_stats | ⚠ hệ thống chờ ở đâu — QUAN TRỌNG NHẤT | | ⚠ sys.dm_db_missing_index_details | ⚠ index đang thiếu | | ⚠ sys.dm_db_index_usage_stats | ⚠ index nào không ai dùng | | ⚠ sys.dm_tran_locks | ⚠ khoá đang giữ | | ⚠ sys.dm_db_resource_stats | ⚠ tài nguyên Azure SQL 14 ngày gần đây |

Từ khoá nhận diện:

"trạng thái hiện tại của hệ thống" → ⚠ DMV "lịch sử truy vấn" → ⚠ Query Store "bắt sự kiện cụ thể" → ⚠ Extended Events "chỉ số hạ tầng theo thời gian" → ⚠ Azure Monitor

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Loại chờ đợi hàng đầu là gì | | | Có index nào chưa bao giờ được dùng không | ⚠ làm chậm việc ghi vô ích | | DMV có bị reset gần đây không | ⚠ số liệu ngắn thì chưa đại diện |

Và câu truy vấn đáng chạy đầu tiên khi một cơ sở dữ liệu chạy chậm: sys.dm_os_wait_stats xếp theo thời gian chờ. Loại chờ đứng đầu bảng thường thu hẹp phạm vi điều tra từ hàng chục khả năng xuống còn hai ba.

Đáp án

E — Service Tier và Performance Level

Vì sao đúng

Trong Azure SQL Database, tài nguyên được cấp phát thông qua service tier (General Purpose, Business Critical, Hyperscale) và performance level (số DTU hoặc số vCore). Đây chính là nút điều chỉnh để mỗi loại khối lượng công việc nhận đúng mức tính toán, bộ nhớ và thông lượng vào ra mà nó cần — và cũng là nơi quyết định chi phí.

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

• B. Resource Governor — tính năng của SQL Server tại chỗ dùng để chia tài nguyên giữa các nhóm khối lượng công việc; không có trong Azure SQL Database. Đây là bẫy chính của câu.
• A. SQL Insights — công cụ giám sát, cho biết tình hình chứ không cấp phát tài nguyên.
• C. SQL Server Agent — bộ lập lịch công việc, và cũng không có trong Azure SQL Database.
• D. Dynamic Data Masking — tính năng bảo mật che dữ liệu, không liên quan tới tài nguyên.

Đáp án

A và C — Azure CLI và ARM template.

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

⚠ Câu này và #17406 trong cùng lô có KHOÁ KHÁC NHAU cho câu hỏi gần giống nhau.

⚠ Bài học: ⚠ với câu "chọn tất cả", ⚠ đọc kỹ danh sách phương án — ⚠ đáp án đúng phụ thuộc vào những gì được đưa ra.

⚠ Ba công cụ CLI, PowerShell, ARM đều tự động hoá triển khai được.

Vì sao đúng

⚠ Cả hai đều lưu được trong Git và chạy được trong pipeline.

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

• B (Azure Logic Apps) — ⚠ nền tảng QUY TRÌNH nghiệp vụ: ⚠ nối các dịch vụ, xử lý sự kiện; ⚠ 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ớ

⚠ Ba công cụ triển khai — khi nào dùng cái nào: | Công cụ | Dùng khi | |---|---| | ⚠ ARM template / Bicep | ⚠ định nghĩa hạ tầng, triển khai lặp lại nhiều môi trường | | ⚠ Azure CLI | ⚠ script hoá thao tác, nhúng vào bash và CI/CD | | ⚠ Azure PowerShell | ⚠ như CLI, hợp môi trường Windows và xử lý đối tượng | | ⚠ Thực tế | ⚠ thường KẾT HỢP: pipeline dùng CLI để gọi lệnh triển khai template |

Từ khoá nhận diện:

"tự động hoá triển khai" (chọn nhiều) → ⚠ đọc kỹ danh sách phương án "cách CHÍNH để định nghĩa hạ tầng" → ⚠ ARM / Bicep "quy trình nghiệp vụ" → ⚠ Logic Apps "quản trị CSDL" → ⚠ SSMS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài nguyên sản xuất có được định nghĩa bằng mã không | | | Dev, test, prod có dùng chung template không | | | Pipeline có chạy what-if trước khi triển khai không | |

Và mẹo hữu ích cho mọi câu hỏi "chọn tất cả các đáp án đúng": xét từng phương án một cách độc lập. Câu hỏi này và #17406 chứng minh vì sao — cùng một chủ đề, khác danh sách phương án, và vì thế khác đáp án.

Đáp án

C — Job Alerts.

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

⚠ Câu này GẦN TRÙNG với #17405 trong cùng lô.

Vì sao đúng

⚠ Cơ chế thông báo tích hợp của SQL Server Agent:

⚠ Job thất bại
        ↓
⚠ Job notification / alert kích hoạt
        ↓
⚠ Database Mail gửi tới OPERATOR
        ↓
⚠ Người trực nhận được

⚠ Ba thứ phải cấu hình đủ: ⚠ Database Mail, ⚠ Operator, ⚠ Notification trên job.

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

• A (Azure Monitor Alerts) — ⚠ giám sát tài nguyên AZURE: ⚠ theo dõi được VM và CSDL, ⚠ nhưng ⚠ không biết trạng thái job của SQL Server Agent trừ khi đẩy log ra ngoài.

• B (SQL Server Profiler) — ⚠ công cụ theo dõi sự kiện ĐÃ KHAI TỬ: ⚠ không phải cơ chế cảnh báo.

• D (Resource Governor) — ⚠ GIỚI HẠN tài nguyên theo nhóm workload: ⚠ hoàn toàn khác.

Ghi nhớ

⚠ Cảnh báo theo tầng — bảng phải thuộc: | Tầng | Công cụ | |---|---| | ⚠ Job trong SQL Server Agent | ⚠ Job alert + Operator + Database Mail | | ⚠ Sự kiện SQL Server (mã lỗi) | ⚠ SQL Agent alert | | ⚠ Tài nguyên Azure (CPU, lưu trữ) | ⚠ Azure Monitor alert | | ⚠ Quy trình Logic Apps | ⚠ Azure Monitor alert | | ⚠ Bảo mật | ⚠ Microsoft Defender for SQL |

Từ khoá nhận diện:

"job SQL Agent hỏng" → ⚠ job alert "CPU vượt ngưỡng" → ⚠ Azure Monitor alert "đăng nhập bất thường" → ⚠ Defender for SQL "Azure SQL Database" → ⚠ không có SQL Agent — dùng Elastic Jobs + Monitor

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã thử cho job hỏng để kiểm chứng chưa | ⚠ cách duy nhất chắc chắn | | Operator có phải nhóm không | | | Mail profile của SQL Agent đã bật chưa | |

Và cách duy nhất để biết một hệ thống cảnh báo có hoạt động: cố tình gây ra sự cố và xem có ai nhận được không. Cấu hình đúng trên màn hình không đảm bảo email thật sự tới nơi.