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

Đáp án

C — ARM template.

Vì sao đúng

⚠ Đề nhấn "triển khai nhiều tài nguyên như MỘT ĐƠN VỊ":

⚠ ARM template (file JSON)
   ⚠ mô tả: SQL Server, CSDL, mạng ảo,
     quy tắc firewall, Key Vault…
        ↓
⚠ Triển khai bằng MỘT lệnh
        ↓
⚠ Azure Resource Manager tự:
   ⚠ xác định thứ tự phụ thuộc
   ⚠ tạo song song những gì có thể
   ⚠ THẤT BẠI thì rollback được

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

• A (PowerShell script) — ⚠ làm được nhưng là cách MỆNH LỆNH: ⚠ phải tự viết thứ tự, ⚠ tự xử lý lỗi, ⚠ tự kiểm tra tài nguyên đã tồn tại chưa.

• B (Azure Logic Apps) — ⚠ quy trình nghiệp vụ, không phải triển khai hạ tầng.

• D (Azure SQL Server Agent) — ⚠ lập lịch công việc trong CSDL, hoàn toàn khác.

Ghi nhớ

⚠ ARM template — cấu trúc phải thuộc: | Phần | Nội dung | |---|---| | ⚠ parameters | ⚠ giá trị truyền vào — tên, vùng, bậc dịch vụ | | ⚠ variables | ⚠ giá trị tính toán nội bộ | | ⚠ resources | ⚠ danh sách tài nguyên cần tạo | | ⚠ outputs | ⚠ giá trị trả về sau khi triển khai | | ⚠ dependsOn | ⚠ khai phụ thuộc giữa tài nguyên |

Từ khoá nhận diện:

"triển khai nhiều tài nguyên như một đơn vị" → ⚠ ARM template "cú pháp dễ đọc hơn ARM" → ⚠ Bicep "đa đám mây" → ⚠ Terraform "thao tác vận hành một lần" → ⚠ CLI hoặc PowerShell

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã chạy what-if trước khi triển khai chưa | | | Chế độ triển khai là incremental hay complete | ⚠ complete có thể xoá dữ liệu | | Template có được lưu trong Git không | |

Và thao tác đáng hình thành thói quen trước mọi lần triển khai hạ tầng: chạy what-if để xem Azure sẽ tạo, sửa và xoá những gì. Mất mười giây, và nó đã cứu rất nhiều môi trường sản xuất.

Đáp án

C — Database Automatic Tuning (tự động điều chỉnh).

Vì sao đúng

⚠ Automatic Tuning của Azure SQL Database làm ba việc: | Tuỳ chọn | Việc | |---|---| | ⚠ CREATE INDEX | ⚠ tự tạo index còn thiếu | | ⚠ DROP INDEX | ⚠ tự xoá index thừa, trùng lặp | | ⚠ FORCE LAST GOOD PLAN | ⚠ quay lại kế hoạch thực thi tốt trước đó |

⚠ Azure SQL theo dõi liên tục
        ↓
⚠ Phát hiện cơ hội tối ưu
        ↓
⚠ ÁP DỤNG thay đổi
        ↓
⚠ ĐO kết quả
        ↓
⚠ Nếu tệ hơn → ⚠ TỰ HOÀN TÁC

⚠ Điểm mạnh nhất: ⚠ tự kiểm chứng và tự hoàn tác nếu thay đổi làm mọi thứ tệ hơn.

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

• A (Automatic Statistics Update) — ⚠ chỉ cập nhật THỐNG KÊ: ⚠ đó là một phần nhỏ, ⚠ và ⚠ đã bật mặc định; ⚠ không phải tính năng "tự tối ưu hiệu năng".

• B (Azure Metrics Advisor) — ⚠ dịch vụ phát hiện bất thường trong dữ liệu chuỗi thời gian: ⚠ không liên quan tới tối ưu CSDL.

• D (SQL Server Agent) — ⚠ lập lịch công việc: ⚠ và ⚠ Azure SQL Database KHÔNG có SQL Agent.

Ghi nhớ

⚠ Automatic Tuning — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ Dựa trên Query Store | ⚠ cần Query Store bật — mặc định đã bật | | ⚠ Tự kiểm chứng kết quả | ⚠ so sánh trước và sau | | ⚠ Tự hoàn tác nếu tệ hơn | | | ⚠ Bật ở mức server hoặc từng CSDL | | | ⚠ Xem được lịch sử khuyến nghị đã áp dụng | |

Từ khoá nhận diện:

"tự động tối ưu hiệu năng" → ⚠ Automatic Tuning "lịch sử kế hoạch thực thi" → ⚠ Query Store "trạng thái hiện tại của hệ thống" → ⚠ DMV "giao diện xem truy vấn tốn nhất" → ⚠ Query Performance Insight

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Query Store đã bật chưa | ⚠ điều kiện cần | | Đã bật những tuỳ chọn tuning nào | | | Có xem lại khuyến nghị đã áp dụng không | |

Và tính năng đáng bật đầu tiên nếu chỉ được chọn một: FORCE LAST GOOD PLAN. Nó chống lại đúng loại sự cố khó chịu nhất — truy vấn tự nhiên chậm đi mà không ai đổi gì cả.

Đáp án

C — Execution plan (kế hoạch thực thi).

Vì sao đúng

⚠ Execution plan cho biết SQL Server ĐÃ hoặc SẼ làm gì: | Xem được | Nội dung | |---|---| | ⚠ Thứ tự các phép toán | ⚠ quét bảng, tìm index, join, sắp xếp | | ⚠ CHI PHÍ ước tính của từng bước | ⚠ phần trăm tổng chi phí | | ⚠ Số dòng ước tính và số dòng THỰC TẾ | | | ⚠ Cảnh báo | ⚠ thiếu index, tràn tempdb, ép kiểu ngầm |

⚠ Kế hoạch ƯỚC TÍNH (estimated)
   ⚠ không chạy truy vấn
        ↓
⚠ Kế hoạch THỰC TẾ (actual)
   ⚠ chạy thật, có số dòng THẬT
        ↓
⚠ So sánh ước tính và thực tế
        ↓
⚠ Lệch nhiều = ⚠ THỐNG KÊ đã cũ

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

• B (SQL Insights Dashboard) — ⚠ giám sát TỔNG THỂ ở mức instance: ⚠ CPU, bộ nhớ, chờ đợi; ⚠ không phân tích một truy vấn cụ thể tới từng bước.

• A (Server Logs) — ⚠ ghi lỗi và sự kiện hệ thống: ⚠ không có thông tin thực thi truy vấn.

• D (Resource Governor) — ⚠ GIỚI HẠN tài nguyên cho nhóm người dùng: ⚠ là công cụ kiểm soát, ⚠ không phải công cụ chẩn đoán.

Ghi nhớ

⚠ Đọc execution plan — dấu hiệu xấu phải thuộc: | Dấu hiệu | Ý nghĩa | |---|---| | ⚠ Table Scan / Clustered Index Scan | ⚠ quét toàn bộ — thường thiếu index | | ⚠ Key Lookup | ⚠ index không đủ cột — cân nhắc INCLUDE | | ⚠ Sort tốn chi phí lớn | ⚠ cân nhắc index theo thứ tự đó | | ⚠ Ước tính lệch thực tế nhiều lần | ⚠ thống kê CŨ — cập nhật lại | | ⚠ Cảnh báo ép kiểu ngầm | ⚠ làm index vô dụng | | ⚠ Spill to tempdb | ⚠ thiếu bộ nhớ cấp cho truy vấn |

Từ khoá nhận diện:

"truy vấn này chạy thế nào, bước nào chậm" → ⚠ execution plan "trước đây nhanh, giờ chậm" → ⚠ Query Store so sánh kế hoạch "hệ thống đang chờ ở đâu" → ⚠ wait statistics (DMV) "giới hạn tài nguyên theo nhóm" → ⚠ Resource Governor

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Số dòng ước tính có gần số thực tế không | ⚠ lệch nhiều thì cập nhật thống kê | | Có cảnh báo ép kiểu ngầm không | | | Có phép quét toàn bảng nào không cần thiết không | |

Và điều đầu tiên nên nhìn khi mở một execution plan: so sánh số dòng ước tính với số dòng thực tế. Nếu hai con số lệch nhau hàng trăm lần, thì mọi lựa chọn phía sau của bộ tối ưu đều dựa trên một giả định sai.

Đáp án

A và C — Azure SQL Database và Azure Cosmos DB.

Vì sao đúng

⚠ Phân biệt CSDL với các loại dịch vụ khác: | Dịch vụ | Loại | |---|---| | ⚠ Azure SQL Database | ⚠ CSDL quan hệ (PaaS) | | ⚠ Azure Cosmos DB | ⚠ CSDL NoSQL đa mô hình, phân tán toàn cầu | | ⚠ Azure Blob Storage | ⚠ kho ĐỐI TƯỢNG, không phải CSDL | | ⚠ Azure Kubernetes Service | ⚠ điều phối CONTAINER |

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

• B (Azure Blob Storage) — ⚠ lưu tệp và đối tượng nhị phân: ⚠ không có truy vấn, không có lược đồ, ⚠ không có giao dịch; ⚠ tương đương Cloud Storage của Google.

• D (Azure Kubernetes Service) — ⚠ chạy container: ⚠ có thể chạy CSDL BÊN TRONG, nhưng ⚠ bản thân nó không phải dịch vụ CSDL.

Ghi nhớ

⚠ Họ dịch vụ CSDL của Azure — bảng phải thuộc: | Dịch vụ | Loại | |---|---| | ⚠ Azure SQL Database | ⚠ SQL Server dạng PaaS, CSDL đơn lẻ | | ⚠ Azure SQL Managed Instance | ⚠ gần như tương thích SQL Server đầy đủ | | ⚠ SQL Server on Azure VM | ⚠ IaaS, toàn quyền | | ⚠ Azure Cosmos DB | ⚠ NoSQL đa mô hình, toàn cầu | | ⚠ Azure Database for MySQL / PostgreSQL / MariaDB | ⚠ mã nguồn mở được quản | | ⚠ Azure Cache for Redis | ⚠ bộ nhớ đệm | | ⚠ Azure Synapse Analytics | ⚠ kho dữ liệu phân tích |

Từ khoá nhận diện:

"CSDL quan hệ được quản" → ⚠ Azure SQL Database "NoSQL toàn cầu, độ trễ thấp" → ⚠ Cosmos DB "lưu tệp, ảnh, sao lưu" → ⚠ Blob Storage "kho dữ liệu phân tích" → ⚠ Synapse Analytics

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng cần tính năng SQL Server nào | ⚠ quyết định chọn Database hay Managed Instance | | Có cần phân tán toàn cầu không | | | Đã ước tính chi phí theo mô hình tính phí của từng dịch vụ chưa | |

Và câu hỏi quyết định khi chọn giữa ba mô hình SQL trên Azure: bạn cần bao nhiêu quyền kiểm soát, và sẵn sàng gánh bao nhiêu việc vận hành?. Càng lên PaaS thì càng ít việc, nhưng cũng càng ít lối thoát khi gặp một yêu cầu đặc thù.

Đáp án

D — Extended Events.

Vì sao đúng

⚠ Extended Events (XEvents) được thiết kế để thay thế SQL Profiler: | Tiêu chí | ⚠ Extended Events | ⚠ SQL Profiler | |---|---|---| | ⚠ Ảnh hưởng hiệu năng | ⚠ RẤT THẤP | ⚠ CAO | | ⚠ Trạng thái | ⚠ hiện hành | ⚠ ĐÃ BỊ KHAI TỬ | | ⚠ Lọc sự kiện | ⚠ lọc TẠI NGUỒN | ⚠ thu hết rồi mới lọc | | ⚠ Azure SQL Database | ⚠ hỗ trợ | ⚠ KHÔNG hỗ trợ |

⚠ Extended Events lọc NGAY tại chỗ
   sinh sự kiện
        ↓
⚠ Sự kiện không quan tâm thì
   KHÔNG được tạo ra
        ↓
⚠ Chi phí gần như bằng không

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

• C (SQL Server Profiler) — ⚠ bẫy vì quen thuộc: ⚠ Microsoft ⚠ đã đánh dấu KHAI TỬ; ⚠ ảnh hưởng hiệu năng lớn, ⚠ không dùng được với Azure SQL Database.

• A (Activity Monitor) — ⚠ chỉ xem trạng thái TỨC THỜI trong SSMS: ⚠ không ghi lại sự kiện để phân tích sau.

• B (SQL Insights) — ⚠ giám sát ở mức tổng thể: ⚠ không thu thập sự kiện chi tiết theo yêu cầu.

Ghi nhớ

⚠ Extended Events — khái niệm phải thuộc: | Khái niệm | Nội dung | |---|---| | ⚠ Event | ⚠ điều cần bắt: truy vấn hoàn tất, deadlock, lỗi đăng nhập | | ⚠ Predicate | ⚠ điều kiện lọc TẠI NGUỒN | | ⚠ Action | ⚠ thông tin thu thêm: SQL text, session id | | ⚠ Target | ⚠ nơi ghi ra: ring buffer, file, bộ đếm | | ⚠ Session | ⚠ một cấu hình thu thập hoàn chỉnh |

Từ khoá nhận diện:

"bắt sự kiện mà ít ảnh hưởng hiệu năng" → ⚠ Extended Events "SQL Profiler" → ⚠ đã khai tử, thường là bẫy "giám sát tổng thể workload" → ⚠ SQL Insights "lịch sử kế hoạch truy vấn" → ⚠ Query Store

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã xem session system_health chưa | ⚠ có sẵn deadlock gần đây | | Predicate đã lọc đủ chặt chưa | | | Session điều tra cũ có bị bỏ quên đang chạy không | |

Và nơi nên nhìn đầu tiên khi nghi có deadlock: session system_health đã chạy sẵn từ lúc SQL Server khởi động. Rất nhiều người dựng session Extended Events mới trong khi câu trả lời đã nằm sẵn ở đó.

Đáp án

B — SQL Insights.

Vì sao đúng

⚠ SQL Insights là giải pháp giám sát chuyên cho Azure SQL: | Đặc điểm | Nội dung | |---|---| | ⚠ Thu thập từ DMV | ⚠ qua một máy ảo thu thập riêng | | ⚠ Hỗ trợ nhiều dạng triển khai | ⚠ Azure SQL Database, Managed Instance, SQL trên VM | | ⚠ Lưu vào Log Analytics | ⚠ truy vấn bằng KQL, giữ lâu dài | | ⚠ Dashboard và cảnh báo sẵn | | | ⚠ So sánh nhiều CSDL cùng lúc | |

⚠ Đề dùng đúng cụm "deep insights about SQL workloads" — ⚠ đó là mô tả của sản phẩm này.

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

• C (Azure Monitor) — ⚠ là NỀN TẢNG giám sát chung của Azure: ⚠ SQL Insights ⚠ là một phần CHẠY TRÊN nó; ⚠ Azure Monitor một mình cho chỉ số hạ tầng, ⚠ không phân tích sâu workload SQL.

• A (SQL Server Management Studio) — ⚠ công cụ quản trị tương tác: ⚠ xem được nhiều thứ nhưng ⚠ không phải giải pháp giám sát liên tục.

• D (Azure Portal Activity Log) — ⚠ ghi thao tác trên MẶT PHẲNG QUẢN LÝ: ⚠ ai tạo, sửa, xoá tài nguyên; ⚠ không có gì về truy vấn bên trong CSDL.

Ghi nhớ

⚠ Các lớp giám sát Azure SQL — bảng phải thuộc: | Lớp | Công cụ | |---|---| | ⚠ Thao tác trên tài nguyên Azure | ⚠ Activity Log | | ⚠ Chỉ số hạ tầng (CPU, DTU, IO) | ⚠ Azure Monitor metrics | | ⚠ Workload SQL chi tiết | ⚠ SQL Insights — đề này | | ⚠ Lịch sử truy vấn và kế hoạch | ⚠ Query Store | | ⚠ Sự kiện chi tiết theo yêu cầu | ⚠ Extended Events | | ⚠ Ai truy cập dữ liệu nào | ⚠ SQL Auditing |

Từ khoá nhận diện:

"phân tích sâu workload SQL" → ⚠ SQL Insights "ai tạo/xoá tài nguyên Azure" → ⚠ Activity Log "ai đọc bảng nào" → ⚠ SQL Auditing "truy vấn nào chậm dần theo thời gian" → ⚠ Query Store

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Loại chờ đợi hàng đầu là gì | ⚠ chỉ thẳng vào nút thắt | | Có dashboard giám sát liên tục không | | | Cảnh báo có đến đúng người không | |

Và câu hỏi hiệu quả nhất khi một cơ sở dữ liệu chạy chậm: nó đang CHỜ cái gì?. Loại chờ đợi hàng đầu thường chỉ thẳng vào nguyên nhân, nhanh hơn nhiều so với đoán mò từ biểu đồ CPU.

Đáp án

C — Row-Level Security (bảo mật cấp dòng).

Vì sao đúng

⚠ RLS lọc DÒNG dữ liệu theo danh tính người dùng, ngay trong CSDL:

⚠ Người dùng chạy: SELECT * FROM DonHang
        ↓
⚠ RLS tự động thêm điều kiện lọc
   ⚠ WHERE NhanVienID = USER_NAME()
        ↓
⚠ Người dùng CHỈ thấy dòng của mình
        ↓
⚠ Ứng dụng KHÔNG cần sửa gì

⚠ Điểm mạnh: ⚠ cưỡng chế ở tầng CSDL — ⚠ mọi ứng dụng, mọi công cụ báo cáo đều bị áp.

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

• A (Dynamic Data Masking) — ⚠ che GIÁ TRỊ trong CỘT, không ẩn DÒNG: ⚠ người dùng vẫn thấy đủ số dòng, ⚠ chỉ là số thẻ hiện thành XXXX-1234.

• B (Microsoft Defender for SQL) — ⚠ phát hiện mối đe doạ và đánh giá lỗ hổng: ⚠ không kiểm soát truy cập dữ liệu.

• D (Data Change Tracking) — ⚠ theo dõi dòng nào đã THAY ĐỔI: ⚠ dùng cho đồng bộ, ⚠ không phải bảo mật.

Ghi nhớ

⚠ Các lớp bảo vệ dữ liệu Azure SQL — bảng phải thuộc: | Tính năng | Bảo vệ gì | |---|---| | ⚠ Row-Level Security | ⚠ DÒNG nào được thấy | | ⚠ Dynamic Data Masking | ⚠ che GIÁ TRỊ hiển thị trong cột | | ⚠ Column-level permission | ⚠ cột nào được đọc | | ⚠ Always Encrypted | ⚠ mã hoá cột, server KHÔNG đọc được | | ⚠ TDE | ⚠ mã hoá TỆP dữ liệu khi lưu | | ⚠ Auditing | ⚠ GHI LẠI ai làm gì |

Từ khoá nhận diện:

"chỉ thấy dòng của mình" → ⚠ Row-Level Security "che số thẻ, email khi hiển thị" → ⚠ Dynamic Data Masking "DBA cũng không được đọc" → ⚠ Always Encrypted "mã hoá file dữ liệu" → ⚠ TDE

Ba việc kiểm chứng: | Việc | Cách | |---|---| | RLS đã thử với mọi vai trò người dùng chưa | | | Predicate function có làm chậm truy vấn không | | | Ai có quyền tắt security policy | ⚠ danh sách phải rất ngắn |

Và lý do RLS mạnh hơn việc lọc trong ứng dụng: nó áp cho MỌI đường vào cơ sở dữ liệu. Một báo cáo Excel nối trực tiếp hay một truy vấn chạy tay trong SSMS đều bị lọc như nhau — điều mà logic trong mã ứng dụng không bao giờ làm được.

Đáp án

C — Azure SQL Database Auditing.

Vì sao đúng

⚠ Auditing ghi lại SỰ KIỆN xảy ra trong CSDL: | Ghi được gì | Nội dung | |---|---| | ⚠ AI | ⚠ danh tính người dùng hoặc ứng dụng | | ⚠ LÀM GÌ | ⚠ câu lệnh đã chạy | | ⚠ KHI NÀO | ⚠ dấu thời gian | | ⚠ TỪ ĐÂU | ⚠ địa chỉ IP máy khách | | ⚠ KẾT QUẢ | ⚠ thành công hay thất bại |

⚠ Bật Auditing
        ↓
⚠ Chọn nơi lưu nhật ký
   ⚠ Storage Account
   ⚠ Log Analytics
   ⚠ Event Hub
        ↓
⚠ Truy vấn và cảnh báo trên nhật ký đó

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

• A (Dynamic Data Masking) — ⚠ CHE dữ liệu khi hiển thị: ⚠ không ghi lại gì.

• B (Data Classification) — ⚠ GẮN NHÃN mức nhạy cảm cho cột: ⚠ giúp biết dữ liệu nào quan trọng, ⚠ không ghi lại hành vi; ⚠ nhưng ⚠ kết hợp với Auditing thì rất mạnh.

• D (Azure SQL Firewall) — ⚠ kiểm soát IP nào KẾT NỐI ĐƯỢC: ⚠ chặn ở cửa vào, ⚠ không ghi lại hoạt động bên trong.

Ghi nhớ

⚠ Auditing — điều phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ Bật ở mức SERVER hoặc từng CSDL | ⚠ mức server áp cho mọi CSDL | | ⚠ Ba đích lưu | ⚠ Storage, Log Analytics, Event Hub | | ⚠ Nhóm hành động cấu hình được | ⚠ đăng nhập, thay đổi lược đồ, truy cập dữ liệu | | ⚠ Log Analytics cho phép truy vấn KQL | | | ⚠ Lưu ý | ⚠ audit ở mức server và CSDL cùng bật sẽ ghi TRÙNG |

Từ khoá nhận diện:

"ai đã làm gì và khi nào" → ⚠ SQL Auditing "phát hiện tấn công, SQL injection" → ⚠ Microsoft Defender for SQL "gắn nhãn dữ liệu nhạy cảm" → ⚠ Data Discovery & Classification "chặn IP kết nối" → ⚠ firewall rule

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhật ký kiểm toán có ai xoá được không | | | Có cảnh báo cho hành vi bất thường không | ⚠ hay chỉ lưu rồi để đó | | Thời hạn lưu có đáp ứng quy định không | |

Và điều biến nhật ký kiểm toán từ một khoản chi phí thành một tài sản: có cảnh báo tự động đọc nó. Một kho nhật ký không ai truy vấn chỉ chứng minh được rằng bạn đã ghi, chứ không phát hiện được gì.

Đáp án

B — Transparent Data Encryption (TDE).

Vì sao đúng

⚠ TDE mã hoá dữ liệu KHI LƯU TRỮ (at rest):

⚠ Dữ liệu ghi xuống đĩa
        ↓ ⚠ TDE mã hoá
⚠ Tệp .mdf, .ldf, .bak đều được mã hoá
        ↓
⚠ Ai lấy được TỆP cũng không đọc được
        ↓
⚠ Ứng dụng KHÔNG cần sửa gì
   ⚠ (đó là chữ "transparent")

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

• A (Always Encrypted) — ⚠ mã hoá ở tầng CLIENT, cho từng CỘT: ⚠ mạnh hơn ở chỗ ⚠ server KHÔNG BAO GIỜ thấy dữ liệu thật; ⚠ nhưng ⚠ đề hỏi mã hoá DỮ LIỆU KHI LƯU nói chung → ⚠ TDE.

• D (Row-Level Security) — ⚠ kiểm soát TRUY CẬP dòng, không mã hoá gì.

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

Ghi nhớ

⚠ Ba lớp mã hoá của SQL Server — bảng phải thuộc: | Lớp | Bảo vệ khỏi | Đặc điểm | |---|---|---| | ⚠ TDE | ⚠ ai lấy được TỆP hoặc bản sao lưu | ⚠ trong suốt, mã hoá at rest | | ⚠ TLS (mã hoá kết nối) | ⚠ nghe lén đường truyền | ⚠ in transit | | ⚠ Always Encrypted | ⚠ CẢ DBA và người quản hạ tầng | ⚠ mã hoá tại client, theo cột |

Từ khoá nhận diện:

"mã hoá dữ liệu khi lưu trữ" → ⚠ TDE "DBA cũng không được đọc" → ⚠ Always Encrypted "mã hoá đường truyền" → ⚠ TLS / Encrypt=true trong chuỗi kết nối "che khi hiển thị" → ⚠ Dynamic Data Masking

Ba việc kiểm chứng: | Việc | Cách | |---|---| | TDE đã bật chưa | ⚠ Azure SQL bật sẵn; SQL trên VM thì phải tự bật | | Bản sao lưu có được mã hoá không | ⚠ TDE thì có | | Có cột nào cần Always Encrypted không | |

Và giới hạn mà tên gọi TDE dễ khiến người ta quên: nó không bảo vệ dữ liệu khỏi người có quyền truy cập hợp lệ. Một tài khoản bị chiếm hay một DBA bất mãn vẫn đọc được mọi thứ như bình thường.

Đáp án

A — Microsoft Entra ID

Vì sao đúng

Azure SQL Database hỗ trợ xác thực tích hợp qua Microsoft Entra ID (tên cũ là Azure Active Directory). Nhờ đó người dùng và ứng dụng đăng nhập bằng chính danh tính của tổ chức, hưởng luôn xác thực đa yếu tố và chính sách truy cập theo điều kiện, thay vì phải quản lý một bộ tài khoản SQL riêng.

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

• B. Active Directory tại chỗ — Azure SQL Database là dịch vụ PaaS, không gia nhập miền AD tại chỗ; muốn dùng danh tính đó thì phải đồng bộ chúng lên Entra ID.
• C. OAuth — là giao thức uỷ quyền nằm bên dưới, không phải chế độ xác thực bạn chọn khi cấu hình CSDL.
• D. Shared Access Signature — cơ chế cấp quyền tạm thời của Azure Storage, không áp dụng cho SQL Database.