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

Tìm thấy 100 câu.

Câu 91 Chọn nhiều đáp án Monitor, configure, and optimize database resources (20-25%)
You are tasked with gathering metrics to establish a performance baseline for your SQL Server database. Which of the following tools could you use to achieve this?
  1. A SQL Server Profiler
  2. B Dynamic Management Views (DMVs)
  3. C SQL Server Agent
  4. D Query Store
Xem giải thích

Đáp án

A, B và D — SQL Server Profiler, Dynamic Management Views (DMV), và Query Store.

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

⚠ SQL Server Profiler đã bị Microsoft đánh dấu KHAI TỬ.

Công cụ Trạng thái
⚠ SQL Server Profiler ⚠ ĐÃ KHAI TỬ — thay bằng Extended Events
⚠ DMV ⚠ hiện hành
⚠ Query Store ⚠ hiện hành, khuyến nghị

⚠ KHÔNG sửa khoá — ⚠ về mặt lịch sử, ⚠ Profiler vẫn là công cụ lập đường cơ sở hợp lệ, ⚠ và ⚠ vẫn dùng được với SQL Server trên VM.

⚠ Trong thực tế hôm nay: ⚠ dùng Extended Events thay Profiler.

Vì sao đúng

⚠ Ba công cụ cho ba loại dữ liệu đường cơ sở: | Công cụ | Đóng góp gì | |---|---| | ⚠ Query Store | ⚠ hiệu năng theo TỪNG truy vấn qua thời gian | | ⚠ DMV | ⚠ ảnh chụp trạng thái: chờ đợi, index, bộ nhớ | | ⚠ Profiler / Extended Events | ⚠ bắt sự kiện chi tiết trong khoảng thời gian mẫu |

⚠ Đường cơ sở (baseline) là gì
   ⚠ "hệ thống BÌNH THƯỜNG trông thế nào"
        ↓
⚠ Có baseline mới trả lời được
   ⚠ "hôm nay có bất thường không?"
        ↓
⚠ Không có baseline
   ⚠ mọi con số đều vô nghĩa

Vì sao phương án C sai

  • C (SQL Server Agent) — ⚠ công cụ LẬP LỊCH công việc: ⚠ có thể chạy script thu thập số liệu, ⚠ nhưng ⚠ bản thân nó không thu thập gì.

Ghi nhớ

⚠ Chỉ số nên có trong đường cơ sở — bảng phải thuộc: | Nhóm | Chỉ số | |---|---| | ⚠ Tài nguyên | ⚠ CPU, bộ nhớ, IOPS, độ trễ đĩa | | ⚠ Chờ đợi | ⚠ top wait types và tỉ lệ | | ⚠ Truy vấn | ⚠ thời gian, CPU, số lần đọc của truy vấn chính | | ⚠ Khối lượng | ⚠ số giao dịch/giây, số kết nối | | ⚠ Dung lượng | ⚠ kích thước CSDL, tempdb, log |

Từ khoá nhận diện:

"lập đường cơ sở hiệu năng" → ⚠ Query Store + DMV + Extended Events "lập lịch chạy script" → ⚠ SQL Agent — công cụ chạy, không phải công cụ đo "Profiler" → ⚠ đã khai tử, dùng Extended Events

⚠ Vì sao đường cơ sở quan trọng Lý do
⚠ "Chậm" là khái niệm TƯƠNG ĐỐI ⚠ so với cái gì?
⚠ Phát hiện xu hướng xấu đi TRƯỚC khi thành sự cố
⚠ Chứng minh được thay đổi có cải thiện không
⚠ Đặt ngưỡng cảnh báo hợp lý
⚠ Không có baseline ⚠ mọi cuộc điều tra bắt đầu từ số không
⚠ Lập đường cơ sở thế nào Cách
⚠ Thu thập trong ÍT NHẤT một chu kỳ nghiệp vụ đầy đủ ⚠ một tuần, hoặc một tháng nếu có chu kỳ tháng
⚠ Ghi lại cả giờ cao điểm và giờ thấp điểm
⚠ Lưu ra bảng để so sánh về sau
⚠ Cập nhật lại sau mỗi thay đổi lớn
⚠ Sai lầm ⚠ đo một buổi chiều rồi coi đó là baseline
⚠ Extended Events thay Profiler thế nào Thay thế
⚠ Ảnh hưởng hiệu năng thấp hơn NHIỀU
⚠ Lọc tại nguồn
⚠ Dùng được với Azure SQL Database
⚠ Có giao diện trong SSMS ⚠ XEvent Profiler — trông giống Profiler cũ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có đường cơ sở nào được lưu lại không | | | Baseline có bao phủ đủ một chu kỳ nghiệp vụ không | | | Có so sánh với baseline sau mỗi thay đổi không | |

Và lý do câu hỏi "hệ thống có chậm không" thường không trả lời được: không ai biết bình thường nó nhanh thế nào. Một đường cơ sở tốn vài giờ để lập, và tiết kiệm được vô số giờ tranh cãi về sau.

Câu 92 Implement a secure environment (15-20%)
In Azure SQL Database, to implement a security feature that allows or restricts server-level access based on an originating IP address, you would configure:
  1. A Entra ID Conditional Access.
  2. B Row-level Security.
  3. C SQL Database Firewall rules.
  4. D Transparent Data Encryption (TDE).
Xem giải thích

Đáp án

C — SQL Database Firewall rules.

Vì sao đúng

⚠ Firewall rule của Azure SQL kiểm soát ĐỊA CHỈ IP nào kết nối được: | Cấp | Phạm vi | |---|---| | ⚠ Server-level firewall rule | ⚠ áp cho MỌI CSDL trên server đó | | ⚠ Database-level firewall rule | ⚠ chỉ áp cho một CSDL |

⚠ Yêu cầu kết nối từ IP x.x.x.x
        ↓
⚠ Kiểm tra database-level rule trước
        ↓ ⚠ không khớp
⚠ Kiểm tra server-level rule
        ↓ ⚠ không khớp
⚠ TỪ CHỐI kết nối

⚠ Đề nói rõ "server-level access based on originating IP" — ⚠ đúng định nghĩa firewall rule.

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

  • A (Entra ID Conditional Access) — ⚠ kiểm soát theo DANH TÍNH và ngữ cảnh: ⚠ người dùng nào, thiết bị nào, rủi ro ra sao; ⚠ không phải cơ chế lọc IP ở tầng máy chủ CSDL.

  • B (Row-level Security) — ⚠ lọc DÒNG dữ liệu sau khi đã kết nối.

  • D (TDE) — ⚠ mã hoá dữ liệu khi lưu, không kiểm soát kết nối.

Ghi nhớ

⚠ Các lớp kiểm soát truy cập Azure SQL — bảng phải thuộc: | Lớp | Kiểm soát | |---|---| | ⚠ Firewall rule | ⚠ IP nào kết nối được | | ⚠ VNet service endpoint | ⚠ subnet nào kết nối được | | ⚠ Private Endpoint | ⚠ IP riêng trong VNet — an toàn nhất | | ⚠ Xác thực (SQL / Entra ID) | ⚠ AI được đăng nhập | | ⚠ Quyền trong CSDL | ⚠ được làm gì | | ⚠ RLS / DDM | ⚠ thấy dòng nào, giá trị nào |

Từ khoá nhận diện:

"cho phép theo địa chỉ IP" → ⚠ firewall rule "chỉ subnet cụ thể" → ⚠ VNet service endpoint "không qua Internet công cộng" → ⚠ Private Endpoint "theo thiết bị và mức rủi ro" → ⚠ Conditional Access

⚠ THIẾT LẬP NGUY HIỂM phải biết Thiết lập
⚠ "Allow Azure services and resources to access this server"
⚠ Nghe như an toàn ⚠ thực chất mở cho tài nguyên Azure của MỌI khách hàng
⚠ Tương đương firewall rule 0.0.0.0
⚠ Nên ⚠ TẮT và dùng VNet rule hoặc Private Endpoint
⚠ Thứ tự ưu tiên bảo mật mạng Thứ tự
⚠ 1. Private Endpoint ⚠ tốt nhất — không lộ ra Internet
⚠ 2. VNet service endpoint
⚠ 3. Firewall rule theo IP cụ thể
⚠ 4. Allow Azure services ⚠ TRÁNH
⚠ 5. Firewall mở rộng ⚠ KHÔNG BAO GIỜ
⚠ Private Endpoint — vì sao tốt nhất Lý do
⚠ CSDL có một IP RIÊNG trong VNet của bạn
⚠ Lưu lượng KHÔNG đi qua Internet công cộng
⚠ Kết hợp với ExpressRoute để truy cập từ tại chỗ
⚠ Tắt hẳn được truy cập công cộng ⚠ Public network access = Disabled
⚠ Chi phí ⚠ có phí cho private endpoint, thường đáng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | "Allow Azure services" có đang bật không | ⚠ kiểm tra ngay | | Có firewall rule nào quá rộng không | | | Đã cân nhắc Private Endpoint chưa | |

Và cấu hình vẫn rất phổ biến dù ai cũng biết là sai: firewall rule cho phép từ 0.0.0.0 tới 255.255.255.255. Nó thường được tạo ra để "thử cho nhanh" trong lúc gỡ lỗi, rồi ở lại vĩnh viễn.

Câu 93 Implement a secure environment (15-20%)

You are managing an SQL database in Azure. Which feature should you configure to obfuscate sensitive data in result sets of queries, without changing the actual data stored in the database?

  1. A Transparent Data Encryption (TDE).
  2. B Always Encrypted.
  3. C Dynamic Data Masking.
  4. D Row-level Security.
Xem giải thích

Đáp án

C — Dynamic Data Masking.

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

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

Câu Hỏi gì
⚠ #17429 (lô 159) ⚠ người dùng thấy "XXXX" thay giá trị thật
⚠ #17489 (câu này) ⚠ che dữ liệu trong kết quả truy vấn mà KHÔNG đổi dữ liệu lưu
⚠ Cùng khoá ⚠ Dynamic Data Masking

Vì sao đúng

⚠ Cụm "không thay đổi dữ liệu thật đang lưu" là dấu hiệu của DDM:

⚠ Dữ liệu trong CSDL: 4111-1111-1111-1234
        ↓ ⚠ người KHÔNG có quyền UNMASK
⚠ Kết quả truy vấn: XXXX-XXXX-XXXX-1234
        ↓ ⚠ người CÓ quyền UNMASK
⚠ Kết quả truy vấn: 4111-1111-1111-1234
        ↓
⚠ Dữ liệu LƯU không hề đổi
Kiểu mặt nạ Kết quả
⚠ Default ⚠ XXXX hoặc 0
⚠ Email ⚠ aXX@XXXX.com
⚠ Random ⚠ số ngẫu nhiên trong khoảng
⚠ Partial ⚠ giữ N ký tự đầu và cuối

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

  • B (Always Encrypted) — ⚠ THAY ĐỔI dữ liệu lưu: ⚠ trong CSDL là bản mã, không phải giá trị gốc; ⚠ trái với yêu cầu của đề.

  • A (TDE) — ⚠ mã hoá ở mức TỆP: ⚠ kết quả truy vấn vẫn là giá trị thật.

  • D (Row-level Security) — ⚠ ẩn DÒNG, không che GIÁ TRỊ trong cột.

Ghi nhớ

⚠ Bốn công nghệ theo tiêu chí "dữ liệu lưu có đổi không": | Công nghệ | Dữ liệu lưu | |---|---| | ⚠ Dynamic Data Masking | ⚠ KHÔNG đổi — chỉ che khi hiển thị | | ⚠ Row-level Security | ⚠ KHÔNG đổi — chỉ lọc dòng | | ⚠ TDE | ⚠ đổi ở mức TỆP, ứng dụng không thấy khác biệt | | ⚠ Always Encrypted | ⚠ ĐỔI — lưu bản mã |

Từ khoá nhận diện:

"che kết quả, không đổi dữ liệu lưu" → ⚠ DDM "mã hoá cột, server không đọc được" → ⚠ Always Encrypted "ẩn dòng theo người dùng" → ⚠ RLS "mã hoá tệp" → ⚠ TDE

⚠ GIỚI HẠN của DDM — phải nhắc lại Giới hạn
⚠ KHÔNG chặn được người cố ý suy đoán ⚠ WHERE cot LIKE '4111%' vẫn lọc được
⚠ db_owner và admin LUÔN thấy giá trị thật
⚠ Chỉ giảm lộ TÌNH CỜ
⚠ Cần bảo mật thật ⚠ quyền cấp cột, RLS, hoặc Always Encrypted
⚠ Ca dùng phù hợp của DDM Ca dùng
⚠ Nhân viên hỗ trợ chỉ cần 4 số cuối
⚠ Môi trường dev dùng bản sao dữ liệu thật
⚠ Giảm rủi ro khi chụp màn hình hoặc chia sẻ báo cáo
⚠ KHÔNG dùng ⚠ làm rào cản duy nhất cho dữ liệu cực nhạy cảm
⚠ Cấu hình DDM Cấu hình
⚠ ALTER TABLE ... ALTER COLUMN ... ADD MASKED WITH (FUNCTION = 'default()')
⚠ Cấp quyền UNMASK cho người cần thấy thật
⚠ Từ SQL Server 2022: UNMASK cấp được ở mức CỘT ⚠ chi tiết hơn nhiều
⚠ Trước đó ⚠ UNMASK là quyền toàn CSDL — quá rộng

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 | | | Cột nhạy cảm nhất có cần biện pháp mạnh hơn không | |

Và cách đúng để giới thiệu Dynamic Data Masking với đội ngũ: gọi nó là lớp giảm rủi ro hiển thị, đừng gọi là biện pháp bảo mật. Cách gọi tên quyết định người ta có tin tưởng nó quá mức hay không.

Câu 94 Implement a secure environment (15-20%)
When configuring the Always Encrypted feature in SQL Server, which of the following types of encryption does it utilize?
  1. A Data-at-rest encryption.
  2. B Transparent Data Encryption (TDE).
  3. C Column-level encryption.
  4. D Transport-level encryption.
Xem giải thích

Đáp án

C — Mã hoá cấp cột (column-level encryption).

Vì sao đúng

⚠ Always Encrypted mã hoá theo TỪNG CỘT được chọn:

⚠ Bảng KhachHang
   ├── ⚠ Ten          — thường
   ├── ⚠ Email        — thường
   ├── ⚠ SoCanCuoc    — MÃ HOÁ
   └── ⚠ SoThe        — MÃ HOÁ
        ↓
⚠ Chỉ hai cột nhạy cảm được mã hoá
⚠ Các cột khác truy vấn bình thường
Đặc điểm Nội dung
⚠ Phạm vi ⚠ CỘT, không phải cả CSDL
⚠ Nơi mã hoá ⚠ driver phía CLIENT
⚠ Server thấy ⚠ chỉ bản mã
⚠ Khoá ⚠ CMK nằm NGOÀI CSDL

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

  • B (TDE) — ⚠ mã hoá CẢ CSDL ở mức TỆP: ⚠ không chọn được cột; ⚠ và ⚠ mã hoá ở phía server.

  • A (mã hoá dữ liệu khi lưu) — ⚠ là mô tả CHUNG: ⚠ TDE cũng thuộc loại này; ⚠ không phải đặc trưng phân biệt của Always Encrypted.

  • D (mã hoá tầng truyền tải) — ⚠ đó là TLS: ⚠ bảo vệ dữ liệu trên đường đi, ⚠ không phải khi lưu.

Ghi nhớ

⚠ Phân loại theo phạm vi mã hoá — bảng phải thuộc: | Công nghệ | Phạm vi | Mã hoá ở đâu | |---|---|---| | ⚠ TLS | ⚠ kết nối | ⚠ trên đường truyền | | ⚠ TDE | ⚠ cả CSDL (tệp) | ⚠ server, khi ghi đĩa | | ⚠ Always Encrypted | ⚠ từng CỘT | ⚠ CLIENT |

Từ khoá nhận diện:

"mã hoá cấp cột" → ⚠ Always Encrypted "mã hoá cả CSDL, trong suốt" → ⚠ TDE "mã hoá kết nối" → ⚠ TLS "che khi hiển thị" → ⚠ Dynamic Data Masking — không phải mã hoá

⚠ Hai loại mã hoá của Always Encrypted Loại
⚠ Deterministic ⚠ cùng giá trị → cùng bản mã; so sánh BẰNG, JOIN, GROUP BY được
⚠ Randomized ⚠ an toàn hơn; KHÔNG so sánh, KHÔNG index được
⚠ Deterministic rủi ro gì ⚠ phân tích tần suất có thể suy ra giá trị
⚠ Chọn thế nào ⚠ randomized trừ khi bắt buộc phải tra cứu theo cột đó
⚠ Phân cấp khoá Khoá
⚠ Column Encryption Key (CEK) ⚠ mã hoá dữ liệu; LƯU TRONG CSDL ở dạng đã mã hoá
⚠ Column Master Key (CMK) ⚠ mã hoá CEK; nằm NGOÀI — Key Vault, certificate store, HSM
⚠ CSDL chỉ lưu ⚠ đường dẫn tới CMK
⚠ Vì vậy ⚠ server không bao giờ giải mã được
⚠ Cái giá phải trả Cái giá
⚠ KHÔNG dùng được LIKE trên cột mã hoá
⚠ KHÔNG so sánh khoảng
⚠ KHÔNG tính toán trên cột đó
⚠ Ứng dụng phải dùng driver hỗ trợ
⚠ Mở rộng ⚠ secure enclaves cho phép LIKE và so sánh khoảng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cột đó có bị dùng trong LIKE hay so sánh không | | | Ai có quyền trên CMK | ⚠ DBA KHÔNG nên có | | Đã chọn deterministic hay randomized | |

Và nguyên tắc chọn cột cho Always Encrypted: chỉ mã hoá cột mà bạn chỉ cần đọc ra và hiển thị. Cột dùng để tìm kiếm, lọc hay tính toán sẽ mất phần lớn giá trị sau khi mã hoá.

Câu 95 Chọn nhiều đáp án Implement a secure environment (15-20%)
You're attempting to authenticate users in your Azure SQL Database. Which two methods can you use to authenticate against Azure SQL using identities in Entra ID?
  1. A Password Authentication
  2. B Managed Identity Authentication
  3. C Integrated Windows Authentication
  4. D Azure Service Token Authentication
Xem giải thích

Đáp án

A và B — Password Authentication và Managed Identity Authentication.

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

⚠ Phương án C dùng thuật ngữ dễ gây nhầm.

Phương án Thực tế
⚠ C — "Integrated Windows Authentication" ⚠ Azure SQL CÓ "Entra ID Integrated" — dùng danh tính Entra từ máy đã gia nhập miền
⚠ Nhưng "Integrated Windows Authentication" thuần ⚠ là cơ chế của SQL Server tại chỗ với Active Directory — KHÔNG dùng với Azure SQL

⚠ KHÔNG sửa khoá — ⚠ với cách diễn đạt trong đề, ⚠ C được hiểu là cơ chế Windows truyền thống, ⚠ không áp dụng cho Azure SQL Database.

Vì sao đúng

⚠ Hai phương thức dùng danh tính Entra ID: | Phương thức | Cách hoạt động | |---|---| | ⚠ Password | ⚠ nhập tài khoản Entra ID và mật khẩu | | ⚠ Managed Identity | ⚠ ứng dụng dùng danh tính do Azure quản — KHÔNG có mật khẩu |

⚠ Managed Identity
   ⚠ gán cho VM, App Service, Function
        ↓
⚠ Ứng dụng lấy token từ Azure
        ↓
⚠ Kết nối Azure SQL bằng token
        ↓
⚠ KHÔNG có mật khẩu ở đâu cả

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

  • C (Integrated Windows Authentication) — ⚠ cơ chế của môi trường Active Directory tại chỗ: ⚠ không dùng trực tiếp với Azure SQL Database.

  • D ("Azure Service Token Authentication") — ⚠ không phải tên phương thức chính thức.

Ghi nhớ

⚠ Các phương thức xác thực Azure SQL — bảng phải thuộc: | Phương thức | Dùng cho | |---|---| | ⚠ SQL Authentication | ⚠ tài khoản trong CSDL — nên hạn chế | | ⚠ Entra ID Password | ⚠ người dùng nhập tài khoản 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ố | | ⚠ Managed Identity | ⚠ ỨNG DỤNG — TỐT NHẤT | | ⚠ Service Principal | ⚠ ứng dụng, có secret hoặc chứng chỉ |

Từ khoá nhận diện:

"ứng dụng xác thực không cần mật khẩu" → ⚠ Managed Identity "người dùng đăng nhập bằng tài khoản công ty" → ⚠ Entra ID Password / Integrated "tài khoản riêng trong CSDL" → ⚠ SQL Authentication "bắt buộc MFA" → ⚠ Entra ID Universal with MFA

⚠ Managed Identity — vì sao tốt nhất cho ứng dụng Lý do
⚠ KHÔNG có mật khẩu hay secret nào để lộ
⚠ Azure tự cấp và tự xoay vòng token
⚠ Gắn với vòng đời tài nguyên ⚠ xoá VM là danh tính biến mất
⚠ Không cần lưu gì trong Key Vault
⚠ Đối chiếu Google Cloud ⚠ tương đương service account gắn vào VM
⚠ Hai loại Managed Identity Loại
⚠ System-assigned ⚠ gắn với MỘT tài nguyên, xoá tài nguyên là mất
⚠ User-assigned ⚠ độc lập, gán cho NHIỀU tài nguyên
⚠ Chọn ⚠ user-assigned khi nhiều tài nguyên cần cùng quyền
⚠ Cấu hình Managed Identity với Azure SQL Bước
⚠ 1. Bật managed identity cho tài nguyên
⚠ 2. CREATE USER [ten-managed-identity] FROM EXTERNAL PROVIDER
⚠ 3. Gán vai trò CSDL cho user đó
⚠ 4. Chuỗi kết nối dùng Authentication=Active Directory Default
⚠ Kết quả ⚠ không còn mật khẩu nào trong cấu hình ứng dụng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng có còn mật khẩu trong chuỗi kết nối không | | | Còn tài khoản SQL Authentication nào không | | | Quyền cấp cho nhóm Entra hay cho từng người | |

Và mục tiêu nên hướng tới cho mọi ứng dụng chạy trên Azure: không còn mật khẩu nào trong file cấu hình. Managed Identity làm được điều đó, và nó cũng xoá luôn cả bài toán xoay vòng bí mật.

Câu 96 Plan and implement data platform resources (20-25%)
Which Azure service facilitates seamless data synchronization between multiple SQL databases across both on-premises and cloud-based environments?
  1. A Azure Data Factory.
  2. B Azure SQL Data Sync.
  3. C Azure Data Lake.
  4. D Azure Cosmos DB.
Xem giải thích

Đáp án

B — Azure SQL Data Sync.

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

⚠ Đây là câu THỨ TƯ về SQL Data Sync trong hai lô liên tiếp.

Câu Góc hỏi
⚠ #17418 (lô 159) ⚠ Data Sync làm được gì
⚠ #17427 (lô 159) ⚠ giữ hai Azure SQL đồng bộ
⚠ #17451 (lô 159) ⚠ đồng bộ tại chỗ với Azure SQL
⚠ #17492 (câu này) ⚠ đồng bộ nhiều CSDL cả tại chỗ lẫn đám mây
⚠ Cùng khoá ⚠ SQL Data Sync

Vì sao đúng

⚠ Đề nêu đúng ba đặc điểm của Data Sync: | Đề nói | Data Sync | |---|---| | ⚠ "nhiều CSDL SQL" | ⚠ mô hình hub-and-spoke, nhiều member | | ⚠ "cả tại chỗ lẫn đám mây" | ⚠ member có thể là SQL Server tại chỗ | | ⚠ "đồng bộ liền mạch" | ⚠ tự động theo lịch, hai chiều |

        ⚠ HUB
   ⚠ Azure SQL Database
      ↕      ↕      ↕
⚠ Azure SQL  ⚠ SQL tại chỗ  ⚠ Azure SQL
   (vùng A)                    (vùng B)

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

  • A (Azure Data Factory) — ⚠ ETL MỘT CHIỀU có biến đổi: ⚠ mạnh cho đường ống dữ liệu, ⚠ không phải cơ chế đồng bộ hai chiều liên tục.

  • C (Azure Data Lake) — ⚠ kho lưu trữ cho dữ liệu lớn: ⚠ không đồng bộ CSDL.

  • D (Azure Cosmos DB) — ⚠ một CSDL NoSQL: ⚠ không phải dịch vụ đồng bộ.

Ghi nhớ

⚠ Bốn cách chuyển/đồng bộ dữ liệu — 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 | | ⚠ Data Factory | ⚠ một chiều, có biến đổi | ⚠ ETL, kho dữ liệu | | ⚠ Transactional replication | ⚠ một chiều, gần thời gian thực | ⚠ phân phối đọc | | ⚠ Geo-replication | ⚠ một chiều | ⚠ DR |

Từ khoá nhận diện:

"đồng bộ hai chiều, nhiều CSDL, có tại chỗ" → ⚠ SQL Data Sync "ETL có biến đổi" → ⚠ Data Factory "kho dữ liệu lớn phi cấu trúc" → ⚠ Data Lake "DR cho Azure SQL" → ⚠ geo-replication, failover group

⚠ Hạn chế Data Sync — nhắc lại vì hay bị bỏ qua Hạn chế
⚠ Bảng PHẢI có khoá chính
⚠ Độ trễ tối thiểu 5 phút
⚠ Hub BẮT BUỘC là Azure SQL Database
⚠ Thay đổi lược đồ phải cấu hình lại sync group
⚠ Có chi phí hiệu năng do trigger theo dõi
⚠ KHÔNG phải ⚠ giải pháp HA, DR, hay sao lưu
⚠ Xử lý xung đột Xử lý
⚠ Hub wins ⚠ thay đổi ở hub thắng
⚠ Member wins ⚠ thay đổi ở member thắng
⚠ Không có ⚠ cơ chế hợp nhất thông minh
⚠ Vì vậy ⚠ thiết kế sao cho mỗi dữ liệu chỉ được GHI ở MỘT nơi
⚠ Lựa chọn hiện đại hơn cho ca dùng lai Lựa chọn
⚠ Managed Instance link ⚠ nhân bản gần thời gian thực từ SQL Server sang MI
⚠ Azure Arc-enabled data services
⚠ Transactional replication sang Azure SQL
⚠ Data Sync hợp nhất khi ⚠ thật sự cần GHI ở nhiều nơi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thật sự cần ghi ở nhiều nơi không | | | Mọi bảng đồng bộ có khoá chính không | | | Ai giám sát sync group | ⚠ hỏng thì im lặng |

Và điều hay xảy ra với các sync group sau vài tháng: chúng lặng lẽ ngừng đồng bộ và không ai biết. Cần một cảnh báo dựa trên thời điểm đồng bộ thành công gần nhất, không chỉ dựa trên lỗi.

Câu 97 Plan and implement data platform resources (20-25%)
To optimize a large SQL Server table for faster query performance, which technique divides a table into smaller, more manageable pieces and distributes the rows based on the values in one or more columns?
  1. A Data compression.
  2. B Sharding
  3. C Table partitioning.
  4. D Indexing
Xem giải thích

Đáp án

C — Table partitioning (phân vùng bảng).

Vì sao đúng

⚠ Đề mô tả chính xác định nghĩa của phân vùng: | Đề nói | Phân vùng | |---|---| | ⚠ "chia bảng thành phần nhỏ hơn" | ⚠ chia thành các partition | | ⚠ "dễ quản lý hơn" | ⚠ bảo trì, xoá, lưu trữ theo từng phần | | ⚠ "phân bố dòng theo giá trị của một hoặc nhiều cột" | ⚠ theo partition key |

⚠ Bảng DonHang (500 triệu dòng)
   ├── ⚠ Partition 2023-Q1
   ├── ⚠ Partition 2023-Q2
   ├── ⚠ Partition 2023-Q3
   └── ⚠ Partition 2023-Q4
        ↓
⚠ WHERE NgayDat >= '2023-10-01'
        ↓
⚠ CHỈ đọc partition Q4

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

  • B (sharding) — ⚠ bẫy gần nhất: ⚠ sharding chia dữ liệu ra ⚠ NHIỀU MÁY CHỦ hoặc nhiều CSDL khác nhau; ⚠ partitioning chia ⚠ TRONG CÙNG một bảng, một CSDL.

  • D (indexing) — ⚠ tạo cấu trúc TÌM KIẾM: ⚠ không chia bảng thành phần.

  • A (data compression) — ⚠ giảm dung lượng lưu trữ: ⚠ không chia gì cả.

Ghi nhớ

⚠ Phân vùng so với sharding — bảng phải thuộc: | Tiêu chí | ⚠ Partitioning | ⚠ Sharding | |---|---|---| | ⚠ Phạm vi | ⚠ trong MỘT CSDL | ⚠ NHIỀU CSDL/máy chủ | | ⚠ Trong suốt với ứng dụng | ⚠ CÓ | ⚠ thường KHÔNG — ứng dụng phải biết | | ⚠ Mục đích chính | ⚠ quản lý và hiệu năng truy vấn | ⚠ MỞ RỘNG quy mô ngang | | ⚠ Trên Azure SQL | ⚠ hỗ trợ sẵn | ⚠ dùng Elastic Database tools |

Từ khoá nhận diện:

"chia bảng trong một CSDL" → ⚠ partitioning "chia dữ liệu ra nhiều CSDL" → ⚠ sharding "cấu trúc tìm kiếm nhanh" → ⚠ index "giảm dung lượng" → ⚠ compression

⚠ Lợi ích thật của partitioning Lợi ích
⚠ Partition elimination ⚠ truy vấn chỉ đọc partition cần
⚠ SWITCH partition ⚠ xoá/lưu trữ dữ liệu cũ TỨC THÌ
⚠ Bảo trì index theo từng partition
⚠ Nén khác nhau cho từng partition ⚠ dữ liệu cũ nén mạnh
⚠ Lợi ích LỚN NHẤT ⚠ quản lý dữ liệu cũ, không phải tốc độ truy vấn
⚠ Hiểu lầm phổ biến Hiểu lầm
⚠ "Phân vùng luôn làm truy vấn nhanh hơn" ⚠ SAI
⚠ Chỉ nhanh khi truy vấn LỌC theo partition key
⚠ Truy vấn không lọc theo key có thể CHẬM HƠN
⚠ Muốn nhanh ⚠ index đúng thường quan trọng hơn phân vùng
⚠ Chọn partition key Chọn
⚠ Cột xuất hiện trong điều kiện lọc phần lớn truy vấn
⚠ Cột dùng để xoá/lưu trữ dữ liệu cũ
⚠ Thường là cột NGÀY
⚠ Số partition vừa phải ⚠ hàng nghìn partition gây chi phí quản lý

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn có lọc theo partition key không | | | Có quy trình tự tạo partition mới không | ⚠ quên là dữ liệu dồn vào partition cuối | | Việc xoá dữ liệu cũ có dùng SWITCH không | ⚠ thay vì DELETE |

Và lý do thực dụng nhất để phân vùng một bảng lớn, thường quan trọng hơn cả hiệu năng truy vấn: xoá dữ liệu cũ bằng SWITCH mất vài giây thay vì vài giờ. Một lệnh DELETE trên hai trăm triệu dòng có thể làm đầy log và khoá bảng cả buổi.

Câu 98 Plan and implement data platform resources (20-25%)
When preparing to migrate a SQL Server database to Azure, what strategy would allow for minimal downtime?
  1. A Offline migration.
  2. B Backup and restore.
  3. C Online migration.
  4. D Manual copy of database files.
Xem giải thích

Đáp án

C — Di trú trực tuyến (online migration).

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

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

Câu Hỏi gì
⚠ #17450 (lô 159) ⚠ ƯU ĐIỂM chính của di trú trực tuyến là gì
⚠ #17494 (câu này) ⚠ CHIẾN LƯỢC nào cho gián đoạn tối thiểu
⚠ Cùng kết luận ⚠ online migration ↔ minimal downtime

Vì sao đúng

⚠ So sánh hai chiến lược: | Tiêu chí | ⚠ Offline | ⚠ Online | |---|---|---| | ⚠ Downtime | ⚠ bằng thời gian chép toàn bộ | ⚠ vài phút lúc cutover | | ⚠ Độ phức tạp | ⚠ thấp | ⚠ cao hơn | | ⚠ Thời gian tổng | ⚠ ngắn hơn | ⚠ dài hơn |

⚠ Online migration
   ⚠ chép ban đầu — hệ thống VẪN CHẠY
        ↓
   ⚠ đồng bộ liên tục thay đổi mới
        ↓
   ⚠ độ trễ ≈ 0 → ⚠ CUTOVER
        ↓
   ⚠ gián đoạn chỉ vài phút

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

  • A (offline migration) — ⚠ downtime bằng cả thời gian chép: ⚠ với CSDL lớn có thể hàng giờ.

  • B (backup and restore) — ⚠ là một dạng offline: ⚠ sao lưu, chuyển file, khôi phục; ⚠ downtime dài.

  • D (chép thủ công file CSDL) — ⚠ cũng offline và còn rủi ro hơn: ⚠ phải detach CSDL, ⚠ dễ sai sót.

Ghi nhớ

⚠ Công cụ di trú theo chiến lược — bảng phải thuộc: | Chiến lược | Công cụ | |---|---| | ⚠ Online | ⚠ Azure Database Migration Service chế độ online | | ⚠ Online (thủ công) | ⚠ transactional replication, log shipping | | ⚠ Offline | ⚠ DMS offline, BACPAC, backup/restore | | ⚠ Đánh giá trước | ⚠ Data Migration Assistant |

Từ khoá nhận diện:

"gián đoạn tối thiểu" → ⚠ online migration "có cửa sổ bảo trì, đơn giản" → ⚠ offline "đánh giá tương thích" → ⚠ DMA "thực hiện di trú" → ⚠ DMS

⚠ Quy trình cutover của online migration Bước
⚠ 1. Theo dõi tới khi độ trễ ≈ 0
⚠ 2. DỪNG ghi vào nguồn
⚠ 3. Chờ đồng bộ nốt
⚠ 4. ĐỐI CHIẾU số bản ghi hai bên ⚠ đừng bỏ qua
⚠ 5. Chuyển ứng dụng sang đích
⚠ 6. Theo dõi sát vài giờ
⚠ Kế hoạch quay lui Kế hoạch
⚠ LUÔN phải có và viết ra TRƯỚC
⚠ Giữ nguồn ở trạng thái khôi phục được
⚠ Xác định "điểm không quay lại"
⚠ Tiêu chí rõ ràng để quyết định quay lui
⚠ Sai lầm ⚠ chỉ có kế hoạch tiến
⚠ Chọn chiến lược theo tình huống Chọn
⚠ CSDL nhỏ, có cửa sổ cuối tuần ⚠ offline — đơn giản, ít rủi ro hơn
⚠ Hệ thống 24/7, downtime rất đắt ⚠ online
⚠ CSDL rất lớn ⚠ online, vì offline mất quá lâu
⚠ Cân nhắc ⚠ online mua sự liên tục bằng độ phức tạp

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

Và điều nên cân nhắc trước khi chọn di trú trực tuyến: nếu hệ thống chịu được vài giờ dừng vào đêm chủ nhật, offline vừa rẻ hơn vừa ít chỗ hỏng hơn. Độ phức tạp thêm vào cũng là rủi ro thêm vào.

Câu 99 Plan and implement data platform resources (20-25%)
What is the primary security benefit of using Transparent Data Encryption (TDE) in Azure SQL Database?
  1. A Protects data at rest.
  2. B Encrypts data in transit.
  3. C Provides two-factor authentication.
  4. D Masks sensitive data in query results.
Xem giải thích

Đáp án

A — Bảo vệ dữ liệu khi lưu trữ (data at rest).

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

⚠ Đây là câu THỨ BA về TDE trong hai lô.

Câu Góc hỏi
⚠ #17415 (lô 159) ⚠ phương pháp nào mã hoá dữ liệu khi lưu
⚠ #17417 (lô 159) ⚠ tính năng bảo mật nào có trong Azure SQL
⚠ #17495 (câu này) ⚠ LỢI ÍCH bảo mật chính của TDE
⚠ Cùng một kiến thức ⚠ TDE = mã hoá at rest

Vì sao đúng

⚠ TDE mã hoá dữ liệu khi ghi xuống đĩa:

⚠ Dữ liệu ghi xuống
        ↓ ⚠ TDE mã hoá bằng AES-256
⚠ Tệp .mdf (dữ liệu)
⚠ Tệp .ldf (log)
⚠ Tệp .bak (SAO LƯU)
        ↓
⚠ Ai lấy được TỆP cũng không đọc được
Bảo vệ khỏi Nội dung
⚠ Đánh cắp file dữ liệu
⚠ Đánh cắp bản sao lưu ⚠ quan trọng — sao lưu hay bị lơ là
⚠ Lấy ổ đĩa vật lý

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

  • B (mã hoá dữ liệu khi truyền) — ⚠ đó là TLS: ⚠ TDE không liên quan tới đường truyền.

  • D (che dữ liệu nhạy cảm trong kết quả truy vấn) — ⚠ đó là Dynamic Data Masking.

  • C (xác thực hai yếu tố) — ⚠ đó là MFA của Entra ID: ⚠ chuyện danh tính, không phải mã hoá.

Ghi nhớ

⚠ Ba trạng thái dữ liệu — bảng phải thuộc: | Trạng thái | Công nghệ | |---|---| | ⚠ At rest (đang lưu) | ⚠ TDE | | ⚠ In transit (đang truyền) | ⚠ TLS | | ⚠ In use (đang xử lý) | ⚠ Confidential Computing, secure enclaves | | ⚠ Ở tầng cột, tại client | ⚠ Always Encrypted |

Từ khoá nhận diện:

"bảo vệ dữ liệu khi lưu" → ⚠ TDE "bảo vệ trên đường truyền" → ⚠ TLS "che khi hiển thị" → ⚠ DDM "DBA không đọc được" → ⚠ Always Encrypted

⚠ TDE KHÔNG bảo vệ khỏi gì — nhắc lại Không bảo vệ
⚠ Người có quyền đăng nhập hợp lệ ⚠ họ đọc bình thường
⚠ DBA
⚠ Tài khoản bị chiếm
⚠ SQL injection
⚠ TDE chỉ bảo vệ ⚠ khỏi việc TỆP bị lấy đi
⚠ Trạng thái mặc định Mặc định
⚠ Azure SQL Database ⚠ TDE BẬT SẴN
⚠ Azure SQL Managed Instance ⚠ BẬT SẴN
⚠ SQL Server trên VM ⚠ PHẢI TỰ BẬT
⚠ Khoá ⚠ service-managed mặc định; BYOK qua Key Vault nếu cần kiểm soát
⚠ Cảnh báo với BYOK (customer-managed key) Cảnh báo
⚠ Xoá khoá trong Key Vault = CSDL KHÔNG mở được
⚠ Cần bật soft delete và purge protection trên Key Vault
⚠ Cần theo dõi hạn của khoá
⚠ Đánh đổi ⚠ kiểm soát nhiều hơn, rủi ro vận hành cũng nhiều hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | TDE đã bật chưa | ⚠ SQL trên VM thì phải tự bật | | Bản sao lưu có được mã hoá không | ⚠ TDE thì có | | Nếu dùng BYOK, Key Vault đã bật purge protection chưa | |

Và điều dễ bị đánh giá thấp về TDE: nó mã hoá luôn cả các bản sao lưu. Trong nhiều vụ rò rỉ, thứ bị lấy không phải cơ sở dữ liệu đang chạy mà là một file sao lưu nằm quên trên một ổ chia sẻ.

Câu 100 Plan and implement data platform resources (20-25%)
For an application that needs a highly responsive database with automatic backups and performance tuning, which Azure SQL offering would be the most appropriate?
  1. A SQL Server on Azure Virtual Machines.
  2. B Azure SQL Database.
  3. C Azure Blob Storage.
  4. D Azure Table Storage.
Xem giải thích

Đáp án

B — Azure SQL Database.

Vì sao đúng

⚠ Đề nêu ba yêu cầu, cả ba đều là đặc trưng của PaaS: | Yêu cầu | Azure SQL Database | |---|---| | ⚠ Phản hồi nhanh | ⚠ bậc dịch vụ chọn được, Business Critical cho độ trễ thấp | | ⚠ Sao lưu TỰ ĐỘNG | ⚠ có sẵn, không cấu hình gì | | ⚠ Tự tinh chỉnh hiệu năng | ⚠ Automatic Tuning |

⚠ Azure SQL Database (PaaS)
   ⚠ Microsoft lo: vá lỗi, sao lưu,
     HA, tinh chỉnh
        ↓
⚠ Bạn lo: lược đồ, truy vấn, dữ liệu

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

  • A (SQL Server trên Azure VM) — ⚠ IaaS, phải TỰ LO mọi thứ: ⚠ tự cấu hình sao lưu, ⚠ tự vá, ⚠ không có Automatic Tuning tự tạo index.

  • C (Azure Blob Storage) — ⚠ kho lưu trữ đối tượng, không phải CSDL.

  • D (Azure Table Storage) — ⚠ kho khoá-giá trị đơn giản: ⚠ không có SQL, ⚠ không có tinh chỉnh hiệu năng.

Ghi nhớ

⚠ Ba mô hình SQL trên Azure — gánh nặng vận hành: | Mô hình | Ai lo vá lỗi | Ai lo sao lưu | Auto-tuning | |---|---|---|---| | ⚠ SQL trên VM (IaaS) | ⚠ BẠN | ⚠ BẠN | ⚠ hạn chế | | ⚠ Managed Instance (PaaS) | ⚠ Microsoft | ⚠ Microsoft | ⚠ CÓ | | ⚠ Azure SQL Database (PaaS) | ⚠ Microsoft | ⚠ Microsoft | ⚠ CÓ, đầy đủ |

Từ khoá nhận diện:

"ít vận hành nhất, tự động hoá cao" → ⚠ Azure SQL Database "cần tính năng SQL Server đầy đủ" → ⚠ Managed Instance "toàn quyền kiểm soát" → ⚠ SQL trên VM "lưu tệp" → ⚠ Blob Storage — không phải CSDL

⚠ Những gì Azure SQL Database lo hộ Lo hộ
⚠ Vá lỗi hệ điều hành và SQL Server
⚠ Sao lưu tự động, PITR 7-35 ngày
⚠ HA tích hợp, SLA 99,99%
⚠ Automatic Tuning
⚠ Threat detection (nếu bật Defender)
⚠ Đổi lại ⚠ một số tính năng SQL Server không có
⚠ Những gì Azure SQL Database KHÔNG có Không có
⚠ SQL Server Agent
⚠ Cross-database query
⚠ Linked server
⚠ CLR assembly
⚠ Service Broker, FILESTREAM
⚠ Cần những thứ này ⚠ chọn Managed Instance
⚠ Khi nào chọn từng mô hình Chọn
⚠ Ứng dụng mới, thiết kế cho đám mây ⚠ Azure SQL Database
⚠ Di trú ứng dụng cũ dùng nhiều tính năng SQL Server ⚠ Managed Instance
⚠ Cần phiên bản SQL cụ thể, cần cài phần mềm bên thứ ba ⚠ VM
⚠ Xu hướng ⚠ càng lên PaaS càng ít việc, nên chọn PaaS trừ khi có lý do rõ ràng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng có cần tính năng nào PaaS không có không | ⚠ chạy DMA để biết | | Đội có sẵn sàng vận hành VM không | | | Đã so sánh tổng chi phí sở hữu chưa | ⚠ PaaS đắt hơn về giá dịch vụ nhưng rẻ hơn về nhân sự |

Và cách so sánh chi phí công bằng giữa IaaS và PaaS: cộng cả thời gian con người vào. Giá dịch vụ của một VM luôn thấp hơn, cho tới khi tính tới người vá lỗi, người trực HA và người xử lý sao lưu.