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

Đáp án

D — Business Critical.

Vì sao đúng

⚠ Bốn bậc dịch vụ của Azure SQL Database: | Bậc | Lưu trữ | Đặc điểm | |---|---|---| | ⚠ Basic / Standard | ⚠ từ xa | ⚠ workload nhẹ, tiết kiệm | | ⚠ General Purpose | ⚠ từ xa (remote) | ⚠ cân bằng chi phí và hiệu năng | | ⚠ Business Critical | ⚠ SSD CỤC BỘ | ⚠ độ trễ thấp nhất, có replica đọc — đề này | | ⚠ Hyperscale | ⚠ kiến trúc phân tầng | ⚠ lên tới 100 TB, co giãn nhanh |

⚠ Business Critical
   ⚠ SSD gắn CỤC BỘ trên máy chủ
   ⚠ nhóm bốn node Always On
   ⚠ MỘT replica chỉ đọc MIỄN PHÍ
        ↓
⚠ Độ trễ IO thấp nhất
⚠ Hiệu năng DỰ ĐOÁN ĐƯỢC
⚠ SLA 99,995% (zone-redundant)

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

• A (General Purpose) — ⚠ lưu trữ TỪ XA: ⚠ độ trễ cao hơn và ⚠ biến động hơn; ⚠ đủ cho phần lớn workload nhưng ⚠ không phải "hiệu năng dự đoán được cao nhất".

• B (Hyperscale) — ⚠ mạnh về QUY MÔ và tốc độ khôi phục: ⚠ nhưng ⚠ độ trễ IO không thấp bằng Business Critical.

• C (Basic) — ⚠ bậc thấp nhất: ⚠ cho môi trường phát triển và ứng dụng rất nhẹ.

Ghi nhớ

⚠ Chọn bậc dịch vụ — bảng phải thuộc: | Nhu cầu | Bậc | |---|---| | ⚠ Độ trễ IO thấp nhất, hiệu năng ổn định | ⚠ Business Critical | | ⚠ CSDL rất lớn (trên 4 TB), khôi phục nhanh | ⚠ Hyperscale | | ⚠ Cân bằng chi phí, workload thông thường | ⚠ General Purpose | | ⚠ Tải thất thường, muốn tự tạm dừng | ⚠ Serverless (trong General Purpose) | | ⚠ Dev/test | ⚠ Basic / Standard |

Từ khoá nhận diện:

"tài nguyên riêng, hiệu năng dự đoán được" → ⚠ Business Critical "CSDL nhiều TB" → ⚠ Hyperscale "tải thất thường, muốn tiết kiệm khi rảnh" → ⚠ Serverless "cân bằng chung" → ⚠ General Purpose

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nút thắt hiện tại là IO hay CPU | ⚠ quyết định có cần Business Critical không | | Có tận dụng replica đọc miễn phí không | | | Đã so sánh chi phí giữa các bậc chưa | |

Và tính năng của Business Critical thường bị bỏ quên dù đã trả tiền cho nó: replica chỉ đọc đi kèm miễn phí. Chỉ cần thêm ApplicationIntent=ReadOnly vào chuỗi kết nối là toàn bộ tải báo cáo rời khỏi CSDL chính.

Đáp án

A và C — Vá lỗi (patching) các instance SQL Server, và giám sát tập trung.

Vì sao đúng

⚠ Azure Arc đưa máy chủ NGOÀI Azure vào quản lý bằng công cụ Azure:

⚠ SQL Server tại chỗ, hoặc ở đám mây khác
        ↓ ⚠ cài Azure Arc agent
⚠ Xuất hiện như một tài nguyên Azure
        ↓
⚠ Quản bằng Portal, Policy, Monitor
   ⚠ như thể nó nằm trong Azure

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

• B (nâng cấp PHIÊN BẢN SQL Server) — ⚠ Arc quản VÁ LỖI, không tự nâng cấp phiên bản lớn: ⚠ nâng từ 2019 lên 2022 vẫn là quy trình riêng có kế hoạch.

• D (auto-tuning cho Azure SQL Database) — ⚠ là tính năng của Azure SQL Database (PaaS): ⚠ Arc dành cho máy chủ NGOÀI Azure, ⚠ không liên quan.

Ghi nhớ

⚠ Họ Azure Arc — bảng phải thuộc: | Sản phẩm | Quản gì | |---|---| | ⚠ Arc-enabled servers | ⚠ máy chủ Windows/Linux ngoài Azure | | ⚠ Arc-enabled Kubernetes | ⚠ cụm K8s ở bất kỳ đâu | | ⚠ Arc-enabled SQL Server | ⚠ instance SQL Server ngoài Azure — đề này | | ⚠ Arc-enabled data services | ⚠ chạy Azure SQL MI hoặc PostgreSQL trên hạ tầng của bạn |

Từ khoá nhận diện:

"quản máy chủ NGOÀI Azure bằng công cụ Azure" → ⚠ Azure Arc "chạy dịch vụ Azure trên hạ tầng của mình" → ⚠ Arc-enabled data services "vá lỗi VM TRONG Azure" → ⚠ Azure Update Manager "vá SQL Server trên Azure VM" → ⚠ SQL IaaS Agent Extension

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức có biết chính xác đang chạy bao nhiêu instance SQL không | ⚠ Arc trả lời được | | Máy chủ ngoài Azure có được vá đều không | | | Log của chúng có gom về một nơi không | |

Và câu hỏi mà Azure Arc trả lời được nhưng rất nhiều tổ chức không tự trả lời nổi: chúng ta đang chạy bao nhiêu instance SQL Server, phiên bản nào, vá tới đâu?. Không có bản kiểm kê đó thì mọi chương trình bảo mật đều có lỗ hổng không nhìn thấy.

Đáp án

B — Range partitioning trên cột ngày tháng.

Vì sao đúng

⚠ Phân vùng theo KHOẢNG NGÀY là mẫu chuẩn cho dữ liệu lớn: | Lợi ích | Nội dung | |---|---| | ⚠ Partition elimination | ⚠ truy vấn theo ngày chỉ đọc phân vùng cần | | ⚠ Bảo trì theo phân vùng | ⚠ rebuild index từng phân vùng | | ⚠ Sliding window | ⚠ thêm tháng mới, chuyển tháng cũ ra bảng lưu trữ — GẦN NHƯ TỨC THÌ | | ⚠ Nén theo phân vùng | ⚠ dữ liệu cũ nén mạnh hơn | | ⚠ Khớp với cách truy vấn thực tế | ⚠ hầu hết truy vấn có điều kiện thời gian |

⚠ Bảng nhiều TB
   ├── ⚠ Phân vùng 2024-01
   ├── ⚠ Phân vùng 2024-02
   └── ⚠ Phân vùng 2024-03
        ↓
⚠ WHERE ngay >= '2024-03-01'
        ↓
⚠ CHỈ đọc phân vùng tháng 3

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

• D (hash partitioning) — ⚠ rải đều nhưng MẤT partition elimination theo thời gian: ⚠ truy vấn theo khoảng ngày ⚠ phải đọc MỌI phân vùng; ⚠ và ⚠ SQL Server không hỗ trợ hash partitioning gốc như một số CSDL khác.

• C (list partitioning) — ⚠ hợp khi phân theo tập giá trị rời rạc: ⚠ khu vực, mã quốc gia; ⚠ không hợp cho dữ liệu tăng theo thời gian.

• A ("row-based partitioning") — ⚠ không phải thuật ngữ chuẩn của SQL Server.

Ghi nhớ

⚠ Phân vùng bảng — điều phải thuộc: | Thành phần | Vai trò | |---|---| | ⚠ Partition function | ⚠ định nghĩa các mốc ranh giới | | ⚠ Partition scheme | ⚠ ánh xạ phân vùng vào filegroup | | ⚠ Partitioned table/index | ⚠ bảng dùng scheme đó | | ⚠ SWITCH | ⚠ chuyển phân vùng ra/vào bảng khác — thao tác METADATA, tức thì |

Từ khoá nhận diện:

"bảng lớn, truy vấn theo thời gian" → ⚠ range partition theo ngày "xoá dữ liệu cũ nhanh" → ⚠ SWITCH phân vùng ra rồi TRUNCATE "phân theo khu vực" → ⚠ list partition "đối chiếu BigQuery" → ⚠ partition theo ngày + cluster

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn có lọc theo khoá phân vùng không | ⚠ nếu không thì phân vùng vô ích | | Execution plan có hiện partition elimination không | | | Có quy trình tự tạo phân vùng mới không | ⚠ quên là dữ liệu dồn vào phân vùng cuối |

Và sự cố kinh điển với bảng phân vùng theo ngày: không ai tạo phân vùng cho năm mới. Toàn bộ dữ liệu mới dồn vào phân vùng cuối cùng, và mọi lợi ích của phân vùng lặng lẽ biến mất.

Đáp án

B — Gián đoạn tối thiểu (minimal downtime).

Vì sao đúng

⚠ So sánh hai chiến lược di trú: | Tiêu chí | ⚠ Offline | ⚠ Online | |---|---|---| | ⚠ Downtime | ⚠ bằng cả thời gian chép dữ liệu | ⚠ chỉ vài phút lúc cutover | | ⚠ Độ phức tạp | ⚠ THẤP | ⚠ CAO hơn | | ⚠ Tốc độ tổng thể | ⚠ NHANH hơn | ⚠ chậm hơn (đồng bộ liên tục) | | ⚠ Rủi ro | ⚠ thấp hơn | ⚠ nhiều thành phần hơn |

⚠ Offline
   ⚠ DỪNG ứng dụng → ⚠ chép → ⚠ mở lại
   ⚠ downtime = thời gian chép

⚠ Online
   ⚠ chép ban đầu (ứng dụng VẪN chạy)
   ⚠ đồng bộ thay đổi liên tục
   ⚠ CUTOVER trong vài phút

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

• A (giảm độ phức tạp) — ⚠ NGƯỢC LẠI: ⚠ online phức tạp hơn vì phải theo dõi đồng bộ và chọn thời điểm cutover.

• D (tốc độ di trú nhanh hơn) — ⚠ cũng ngược: ⚠ online thường tổng thể lâu hơn vì phải chạy đồng bộ song song.

• C (không cần sao lưu) — ⚠ SAI và NGUY HIỂM: ⚠ LUÔN phải có sao lưu trước mọi cuộc di trú, ⚠ bất kể chiến lược nào.

Ghi nhớ

⚠ Chọn chiến lược di trú — bảng phải thuộc: | Tình huống | Chiến lược | |---|---| | ⚠ Có cửa sổ bảo trì đủ dài | ⚠ offline — đơn giản hơn | | ⚠ Hệ thống 24/7, downtime rất đắt | ⚠ online | | ⚠ CSDL nhỏ, chép nhanh | ⚠ offline | | ⚠ CSDL rất lớn | ⚠ online, vì chép offline sẽ mất quá lâu |

Từ khoá nhận diện:

"gián đoạn tối thiểu" → ⚠ online migration "đơn giản, có cửa sổ bảo trì" → ⚠ offline "công cụ thực hiện" → ⚠ Azure Database Migration Service "đánh giá trước" → ⚠ Data Migration Assistant

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Downtime chấp nhận được là bao lâu | ⚠ quyết định chiến lược | | Đã có kế hoạch quay lui chưa | | | Đã diễn tập cutover chưa | |

Và điều đáng nhớ khi cân nhắc di trú trực tuyến: nó mua sự liên tục bằng độ phức tạp. Nếu hệ thống chịu được vài giờ dừng vào cuối tuần, thì offline vừa rẻ hơn vừa ít chỗ hỏng hơn.

Đáp án

A — Azure SQL Data Sync.

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

⚠ Đây là câu THỨ BA về SQL Data Sync trong cùng lô.

Vì sao đúng

⚠ Data Sync hỗ trợ member là SQL Server tại chỗ:

⚠ HUB: Azure SQL Database (BẮT BUỘC)
      ↕
⚠ MEMBER: SQL Server tại chỗ
   ⚠ cần cài Data Sync Agent
      ↕
⚠ MEMBER: Azure SQL Database khác
        ↓
⚠ Đồng bộ HAI CHIỀU theo lịch

⚠ Đây là kịch bản lai điển hình mà Data Sync được thiết kế cho.

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

• B (Azure Data Factory) — ⚠ làm được nhưng MỘT CHIỀU: ⚠ là công cụ ETL, ⚠ không phải cơ chế đồng bộ hai chiều liên tục.

• C (Azure Site Recovery) — ⚠ khôi phục thảm hoạ cho MÁY ẢO: ⚠ nhân bản cả máy chủ, ⚠ không đồng bộ dữ liệu ở mức bảng.

• D (Azure Blob Storage) — ⚠ kho lưu trữ đối tượng, không liên quan.

Ghi nhớ

⚠ Đồng bộ dữ liệu lai — bảng phải thuộc: | Nhu cầu | Giải pháp | |---|---| | ⚠ Đồng bộ HAI CHIỀU, có tại chỗ | ⚠ SQL Data Sync | | ⚠ Nhân bản MỘT CHIỀU tới Azure | ⚠ Transactional replication, Managed Instance link | | ⚠ ETL có biến đổi | ⚠ Data Factory | | ⚠ Di trú một lần | ⚠ Database Migration Service | | ⚠ DR cho máy ảo | ⚠ Azure Site Recovery |

Từ khoá nhận diện:

"đồng bộ hai chiều tại chỗ ↔ Azure" → ⚠ SQL Data Sync "nhân bản liên tục sang Managed Instance" → ⚠ MI link "chép và biến đổi dữ liệu" → ⚠ Data Factory "DR cho cả máy chủ" → ⚠ Site Recovery

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thật sự cần ghi ở cả hai nơi không | ⚠ một chiều đơn giản hơn nhiều | | Mọi bảng đồng bộ có khoá chính không | | | Độ trễ 5 phút có chấp nhận được không | |

Và câu hỏi nên đặt trước khi dựng bất kỳ cơ chế đồng bộ lai nào: đây là trạng thái tạm thời hay vĩnh viễn?. Nếu là bước đệm trong quá trình di trú thì rất hợp lý; nếu định duy trì mãi thì cái giá về vận hành sẽ tích luỹ theo năm tháng.

Đáp án

B — Query Performance Insight.

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

⚠ Query Performance Insight là tính năng trên cổng Azure dành cho Azure SQL DATABASE.

⚠ KHÔNG sửa khoá — ⚠ trong bốn phương án, ⚠ đây vẫn là công cụ chuyên về hiệu năng TRUY VẤN, ⚠ và ⚠ nguồn dữ liệu của nó là Query Store — thứ Managed Instance cũng có.

⚠ Cách nhớ an toàn: ⚠ Query Store là nền tảng chung; ⚠ Query Performance Insight chỉ là giao diện trực quan trên đó.

Vì sao đúng (về mặt khái niệm)

⚠ Công cụ này trả lời đúng câu hỏi của đề: | Xem được | Nội dung | |---|---| | ⚠ Truy vấn tốn CPU nhất | | | ⚠ Truy vấn tốn thời gian nhất | | | ⚠ Truy vấn tốn IO nhất | | | ⚠ Xu hướng theo thời gian | ⚠ so sánh trước và sau di trú | | ⚠ Chi tiết từng truy vấn | |

⚠ Với tình huống "chậm hơn sau khi di trú" — ⚠ đây chính là nơi bắt đầu.

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

• C ("Azure SQL Analytics") — ⚠ giải pháp giám sát cũ trong Log Analytics: ⚠ đã được thay bằng SQL Insights và Azure Monitor; ⚠ và ⚠ nó thiên về tổng thể chứ không phải một truy vấn.

• D (Azure Monitor logs) — ⚠ lưu và truy vấn log: ⚠ cần biết KQL, ⚠ không phải công cụ chuyên hiệu năng truy vấn.

• A (Azure Advisor) — ⚠ khuyến nghị chung về chi phí, bảo mật, hiệu năng ở mức TÀI NGUYÊN: ⚠ không phân tích từng truy vấn.

Ghi nhớ

⚠ Chẩn đoán "chậm hơn sau khi di trú" — bảng phải thuộc: | Nguyên nhân | Cách kiểm tra | |---|---| | ⚠ THỐNG KÊ chưa cập nhật | ⚠ UPDATE STATISTICS sau di trú | | ⚠ Compatibility level đổi | ⚠ bộ tối ưu mới chọn kế hoạch khác | | ⚠ Bậc dịch vụ không đủ tài nguyên | ⚠ so sánh với máy chủ cũ | | ⚠ Độ trễ mạng từ ứng dụng tới CSDL | ⚠ ứng dụng còn ở tại chỗ? | | ⚠ Index chưa được rebuild | | | ⚠ Nguyên nhân số một | ⚠ thống kê và compatibility level |

Từ khoá nhận diện:

"truy vấn nào tốn tài nguyên nhất" → ⚠ Query Performance Insight / Query Store "khuyến nghị chung về tài nguyên" → ⚠ Azure Advisor "phân tích workload sâu" → ⚠ SQL Insights "chậm sau khi di trú" → ⚠ kiểm tra thống kê và compatibility level TRƯỚC

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã cập nhật thống kê sau di trú chưa | ⚠ việc đầu tiên | | Compatibility level là bao nhiêu | | | Ứng dụng có cùng vùng với CSDL không | |

Và nguyên nhân phổ biến nhất khiến truy vấn chậm đi ngay sau khi di trú, dù cấu hình mới mạnh hơn: thống kê chưa được cập nhật. Một lệnh UPDATE STATISTICS thường giải quyết được nhiều hơn cả một lần nâng bậc dịch vụ.

Đáp án

D — Xác thực dựa trên token của Entra ID (Entra ID Token-based).

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

⚠ Cả ba phương thức Entra ID đều hỗ trợ đăng nhập bằng NHÓM.

⚠ Điểm chung: ⚠ mọi phương thức Entra ID đều cho phép ⚠ tạo user trong CSDL từ một NHÓM, ⚠ và ⚠ thành viên nhóm kế thừa quyền.

⚠ KHÔNG sửa khoá — ⚠ phương án duy nhất chắc chắn sai là ⚠ SQL Authentication.

Vì sao đúng

⚠ Cơ chế đăng nhập theo nhóm Entra ID:

CREATE USER [Nhom-BaoCao] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [Nhom-BaoCao];

⚠ Người dùng thuộc nhóm đăng nhập
        ↓
⚠ Token chứa thông tin NHÓM
        ↓
⚠ SQL Database khớp với user tạo từ nhóm
        ↓
⚠ Kế thừa quyền của nhóm

⚠ Lợi ích lớn nhất: ⚠ thêm/bớt người chỉ cần làm ở Entra ID, ⚠ không đụng tới CSDL.

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

• A (SQL Authentication) — ⚠ CHẮC CHẮN SAI: ⚠ tài khoản SQL truyền thống ⚠ không biết gì về nhóm Entra ID; ⚠ phải tạo và quản từng tài khoản trong CSDL.

• B (Entra ID Password) và C (Entra ID Integrated) — ⚠ cũng hỗ trợ nhóm: ⚠ khác biệt giữa chúng là cách lấy token, không phải khả năng dùng nhóm.

Ghi nhớ

⚠ Các phương thức xác thực Azure SQL — bảng phải thuộc: | Phương thức | Đặc điểm | |---|---| | ⚠ SQL Authentication | ⚠ tài khoản trong CSDL, quản mật khẩu riêng | | ⚠ Entra ID Password | ⚠ nhập tài khoản Entra ID và mật khẩu | | ⚠ Entra ID Integrated | ⚠ đăng nhập một lần từ máy đã gia nhập miền | | ⚠ Entra ID Universal with MFA | ⚠ hỗ trợ xác thực đa yếu tố | | ⚠ Entra ID Token-based | ⚠ ứng dụng lấy token rồi truyền vào | | ⚠ Managed Identity | ⚠ KHÔNG có mật khẩu — tốt nhất cho ứng dụng |

Từ khoá nhận diện:

"kế thừa quyền từ nhóm" → ⚠ bất kỳ phương thức Entra ID nào "ứng dụng xác thực không cần mật khẩu" → ⚠ Managed Identity "tài khoản riêng trong CSDL" → ⚠ SQL Authentication "bắt buộc MFA" → ⚠ Entra ID với MFA

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn tài khoản SQL Authentication nào không | | | Quyền cấp cho nhóm hay cho từng người | | | Ứng dụng có dùng Managed Identity chưa | |

Và lợi ích thực dụng nhất của việc gắn quyền CSDL vào nhóm Entra ID: quy trình nghỉ việc chỉ còn một bước. Gỡ người đó khỏi nhóm, và mọi quyền truy cập cơ sở dữ liệu biến mất theo — không cần ai nhớ tới danh sách người dùng trong từng CSDL.

Đáp án

B — Always Encrypted.

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

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

Vì sao đúng

⚠ Always Encrypted là công nghệ DUY NHẤT mã hoá theo CỘT: | Đặc điểm | Nội dung | |---|---| | ⚠ Phạm vi | ⚠ từng CỘT được chọn | | ⚠ Nơi mã hoá | ⚠ driver ở phía CLIENT | | ⚠ Server thấy gì | ⚠ chỉ thấy bản mã | | ⚠ DBA đọc được | ⚠ KHÔNG |

⚠ Chọn cột: SoCanCuoc, SoTheTinDung
        ↓
⚠ Driver mã hoá tại ứng dụng
        ↓
⚠ CSDL lưu bản mã
        ↓
⚠ Cột KHÁC vẫn bình thường

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

• A (TDE) — ⚠ mã hoá CẢ CSDL ở mức tệp: ⚠ không chọn được cột; ⚠ và ⚠ người dùng hợp lệ vẫn thấy dữ liệu thật.

• C (Dynamic Data Masking) — ⚠ CHE khi hiển thị, KHÔNG mã hoá: ⚠ dữ liệu thật vẫn nằm nguyên.

• D (Row-Level Security) — ⚠ lọc DÒNG theo danh tính, không mã hoá gì.

Ghi nhớ

⚠ Bốn công nghệ bảo vệ dữ liệu — phân biệt theo phạm vi: | Công nghệ | Phạm vi | Có mã hoá | |---|---|---| | ⚠ TDE | ⚠ cả CSDL (mức tệp) | ⚠ CÓ | | ⚠ Always Encrypted | ⚠ từng CỘT | ⚠ CÓ, tại client | | ⚠ Dynamic Data Masking | ⚠ từng CỘT (hiển thị) | ⚠ KHÔNG | | ⚠ Row-Level Security | ⚠ từng DÒNG | ⚠ KHÔNG |

Từ khoá nhận diện:

"mã hoá CỘT cụ thể" → ⚠ Always Encrypted "mã hoá cả CSDL, trong suốt" → ⚠ TDE "che khi hiển thị" → ⚠ DDM "lọc dòng theo người dùng" → ⚠ RLS

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 | | | Ai có quyền trên Column Master Key | ⚠ DBA KHÔNG nên có | | Ứng dụng đã dùng driver hỗ trợ chưa | |

Và điều làm Always Encrypted mất hết ý nghĩa dù đã cấu hình đúng: cấp cho DBA quyền truy cập Column Master Key trong Key Vault. Toàn bộ mục đích của công nghệ này là tách hai vai trò đó ra.

Đáp án

C — TLS.

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

⚠ Đề nói TLS mã hoá "cả khi TRUYỀN và khi LƯU TRỮ" — điều này KHÔNG ĐÚNG.

⚠ KHÔNG sửa khoá — ⚠ trong bốn phương án, ⚠ TLS vẫn là giao thức đúng cho kết nối tới Azure SQL Database.

⚠ Cách hiểu đúng: ⚠ Azure SQL bảo vệ dữ liệu bằng ⚠ TLS khi truyền + ⚠ TDE khi lưu, ⚠ hai công nghệ khác nhau, cả hai đều bật mặc định.

Vì sao đúng (phần kết nối)

⚠ TLS bảo vệ kết nối tới Azure SQL Database:

⚠ Ứng dụng
        ↓ ⚠ TLS 1.2 trở lên
⚠ Azure SQL Database
        ↓
⚠ Chống nghe lén và sửa đổi trên đường

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

• A (HTTPS) — ⚠ là HTTP CHẠY TRÊN TLS: ⚠ dùng cho web, ⚠ không phải giao thức kết nối CSDL (SQL dùng TDS trên TLS).

• B (SFTP) — ⚠ truyền TỆP qua SSH: ⚠ không phải giao thức CSDL.

• D (SSH) — ⚠ truy cập dòng lệnh từ xa: ⚠ không dùng để kết nối Azure SQL Database.

Ghi nhớ

⚠ Ba trạng thái dữ liệu và cách bảo vệ — bảng phải thuộc: | Trạng thái | Công nghệ | |---|---| | ⚠ In transit (đang truyền) | ⚠ TLS | | ⚠ At rest (đang lưu) | ⚠ TDE, Always Encrypted | | ⚠ In use (đang xử lý) | ⚠ Confidential Computing, secure enclaves | | ⚠ Đừng lẫn | ⚠ TLS KHÔNG bảo vệ dữ liệu khi lưu |

Từ khoá nhận diện:

"mã hoá kết nối" → ⚠ TLS "mã hoá dữ liệu trên đĩa" → ⚠ TDE "mã hoá cột tại client" → ⚠ Always Encrypted "bảo vệ cả khi đang xử lý" → ⚠ Confidential Computing

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chuỗi kết nối có TrustServerCertificate=True không | ⚠ nên là False | | Minimal TLS version đặt bao nhiêu | | | Có hiểu rõ TLS không thay được TDE không | |

Và một cách nhớ gọn để không bao giờ lẫn: TLS bảo vệ dữ liệu trên đường đi, TDE bảo vệ dữ liệu khi nó đã tới nơi. Hai công nghệ khác nhau, chặn hai mối đe doạ khác nhau, và không cái nào thay được cái nào.

Đáp án

D — Database Auditing.

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

⚠ Câu này GẦN TRÙNG với #17414 ở lô trước.

Vì sao đúng

⚠ Auditing ghi lại các NHÓM HÀNH ĐỘNG cụ thể: | Nhóm hành động | Ghi gì | |---|---| | ⚠ SELECT | ⚠ ai đọc dữ liệu nào | | ⚠ INSERT, UPDATE, DELETE | ⚠ ai thay đổi dữ liệu | | ⚠ EXECUTE | ⚠ chạy thủ tục | | ⚠ SCHEMA_OBJECT_CHANGE_GROUP | ⚠ đổi cấu trúc | | ⚠ FAILED_DATABASE_AUTHENTICATION_GROUP | ⚠ đăng nhập thất bại |

⚠ Cấu hình audit ở mức server hoặc CSDL
        ↓
⚠ Chọn nhóm hành động cần ghi
        ↓
⚠ Chọn đích: Storage / 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

• C (SQL Server Profiler) — ⚠ công cụ theo dõi ĐÃ KHAI TỬ: ⚠ dùng để gỡ lỗi tạm thời, ⚠ không phải cơ chế kiểm toán tuân thủ; ⚠ và ⚠ không dùng được với Azure SQL Database.

• A (Dynamic Data Masking) — ⚠ che giá trị khi hiển thị: ⚠ không ghi lại gì.

• B (TDE) — ⚠ mã hoá tệp dữ liệu: ⚠ không ghi lại gì.

Ghi nhớ

⚠ Auditing cho tuân thủ — điểm phải thuộc: | Điểm | Nội dung | |---|---| | ⚠ Cấp áp dụng | ⚠ server (mọi CSDL) hoặc từng CSDL | | ⚠ Ba đích lưu | ⚠ Storage Account, Log Analytics, Event Hub | | ⚠ Ghi cả câu lệnh và tham số | | | ⚠ Ghi IP nguồn và danh tính | | | ⚠ Bật cả hai cấp | ⚠ sẽ ghi TRÙNG — chọn một |

Từ khoá nhận diện:

"kiểm toán SELECT/INSERT/UPDATE/DELETE" → ⚠ Database Auditing "phát hiện tấn công" → ⚠ Microsoft Defender for SQL "gỡ lỗi sự kiện tạm thời" → ⚠ Extended Events "che dữ liệu hiển thị" → ⚠ Dynamic Data Masking

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhật ký audit có ai xoá được không | | | Có cảnh báo tự động đọc nhật ký không | | | Khối lượng ghi có kiểm soát được không | |

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