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

Đáp án

C — Transparent Data Encryption.

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

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

Vì sao đúng

⚠ TDE là tính năng NẰM TRONG Azure SQL Database: | Tính năng | Thuộc về | |---|---| | ⚠ Transparent Data Encryption | ⚠ Azure SQL Database — BẬT MẶC ĐỊNH | | ⚠ Azure Firewall | ⚠ dịch vụ tường lửa MẠNG, cấp hạ tầng | | ⚠ Azure Load Balancer | ⚠ cân bằng tải mạng | | ⚠ "Azure Defender" | ⚠ tên cũ, nay là Microsoft Defender for Cloud/SQL |

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

• A ("Azure Defender") — ⚠ bẫy tinh vi: ⚠ Microsoft Defender for SQL ⚠ thật sự là tính năng bảo mật của Azure SQL; ⚠ nhưng ⚠ tên "Azure Defender" là tên cũ đã đổi, ⚠ và ⚠ nó là dịch vụ gắn thêm, không phải tính năng nội tại như TDE.

• B (Azure Firewall) — ⚠ dịch vụ tường lửa mạng của Azure: ⚠ khác với firewall rule của SQL Server (cũng có, nhưng tên khác).

• D (Azure Load Balancer) — ⚠ cân bằng tải mạng, không liên quan bảo mật CSDL.

Ghi nhớ

⚠ Tính năng bảo mật của Azure SQL Database — bảng phải thuộc: | Tính năng | Việc | |---|---| | ⚠ TDE | ⚠ mã hoá dữ liệu khi lưu — mặc định BẬT | | ⚠ Always Encrypted | ⚠ mã hoá cột tại client | | ⚠ Row-Level Security | ⚠ lọc dòng theo danh tính | | ⚠ Dynamic Data Masking | ⚠ che giá trị khi hiển thị | | ⚠ Auditing | ⚠ ghi lại hoạt động | | ⚠ Microsoft Defender for SQL | ⚠ phát hiện đe doạ, đánh giá lỗ hổng | | ⚠ Firewall rule (mức server và CSDL) | ⚠ giới hạn IP kết nối | | ⚠ Private Endpoint | ⚠ truy cập qua mạng riêng, không qua Internet | | ⚠ Microsoft Entra ID authentication | ⚠ đăng nhập bằng danh tính tổ chức |

Từ khoá nhận diện:

"mã hoá at rest" → ⚠ TDE "phát hiện SQL injection, đăng nhập bất thường" → ⚠ Defender for SQL "không cho truy cập qua Internet công cộng" → ⚠ Private Endpoint "đăng nhập bằng tài khoản công ty" → ⚠ Entra ID authentication

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 mở 0.0.0.0 không | | | Defender for SQL đã bật chưa | |

Và thiết lập gây hiểu nhầm nhất trong Azure SQL: "Allow Azure services to access this server". Nó nghe như một hàng rào, nhưng thực chất mở cửa cho tài nguyên Azure của mọi khách hàng khác, không riêng của bạn.

Đáp án

A và D — Đồng bộ dữ liệu giữa các CSDL SQL, và sao chép dữ liệu giữa Azure SQL Database với SQL Server tại chỗ.

Vì sao đúng

⚠ SQL Data Sync đồng bộ HAI CHIỀU theo mô hình hub-and-spoke:

        ⚠ HUB
   ⚠ (Azure SQL Database)
      ↕      ↕      ↕
⚠ Member  Member  Member
   ⚠ Azure SQL DB
   ⚠ SQL Server TẠI CHỖ

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

• B (mã hoá CSDL) — ⚠ đó là việc của TDE: ⚠ Data Sync không mã hoá gì.

• C (sao lưu CSDL) — ⚠ Azure SQL có sao lưu tự động riêng: ⚠ Data Sync ⚠ KHÔNG phải giải pháp sao lưu; ⚠ dữ liệu xoá ở một nơi sẽ lan sang mọi nơi khác.

Ghi nhớ

⚠ SQL Data Sync — điều phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ Đồng bộ hai chiều | ⚠ thay đổi ở đâu cũng lan đi | | ⚠ KHÔNG phải giải pháp HA hay DR | | | ⚠ KHÔNG phải sao lưu | | | ⚠ Có xử lý xung đột | ⚠ hub thắng hoặc member thắng | | ⚠ Độ trễ tối thiểu 5 phút | | | ⚠ Bảng phải có KHOÁ CHÍNH | |

Từ khoá nhận diện:

"đồng bộ hai chiều, có cả tại chỗ" → ⚠ SQL Data Sync "bản sao chỉ đọc ở vùng khác" → ⚠ Active Geo-Replication "khôi phục thảm hoạ" → ⚠ failover group, geo-restore "di trú một lần" → ⚠ Database Migration Service

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mọi bảng đồng bộ có khoá chính không | | | Quy tắc xử lý xung đột đã chọn đúng chưa | | | Có ai nhầm Data Sync với sao lưu không | ⚠ hiểu lầm nguy hiểm |

Và hiểu lầm nguy hiểm nhất về mọi cơ chế đồng bộ hai chiều: coi nó như một bản sao lưu. Xoá nhầm một bảng ở một nơi và thao tác đó sẽ được đồng bộ trung thực tới mọi nơi còn lại.

Đáp án

B — Azure Database Migration Service (DMS).

Vì sao đúng

⚠ DMS là dịch vụ chuyên cho di trú CSDL: | Chế độ | Đặc điểm | |---|---| | ⚠ Offline | ⚠ dừng hệ thống, chép một lần | | ⚠ Online | ⚠ chép liên tục, chỉ dừng vài phút lúc CHUYỂN — đề này |

⚠ DMS chế độ ONLINE
        ↓
⚠ Chép dữ liệu ban đầu
        ↓
⚠ Đồng bộ liên tục thay đổi mới
   ⚠ hệ thống cũ VẪN chạy
        ↓
⚠ Khi độ trễ gần bằng 0 → ⚠ CUTOVER
        ↓
⚠ Gián đoạn tối thiểu

⚠ Hỗ trợ nhiều nguồn: ⚠ SQL Server, MySQL, PostgreSQL, Oracle, MongoDB.

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

• A (Azure Backup) và D (Azure Backup Service) — ⚠ hai phương án gần như trùng nhau, đều là SAO LƯU: ⚠ khôi phục từ sao lưu là ⚠ quy trình OFFLINE có gián đoạn dài.

• C (Azure Recovery Services Vault) — ⚠ kho chứa cho sao lưu và Site Recovery: ⚠ dùng cho khôi phục thảm hoạ, ⚠ không phải công cụ di trú CSDL.

Ghi nhớ

⚠ Bộ công cụ di trú CSDL sang Azure — bảng phải thuộc: | Công cụ | Việc | |---|---| | ⚠ Data Migration Assistant (DMA) | ⚠ ĐÁNH GIÁ trước: tương thích, chặn ở đâu | | ⚠ Database Migration Service (DMS) | ⚠ THỰC HIỆN di trú, có chế độ online | | ⚠ Azure Migrate | ⚠ đánh giá và di trú TOÀN BỘ hạ tầng | | ⚠ BACPAC / bacpac export-import | ⚠ di trú thủ công, CSDL nhỏ | | ⚠ Transactional replication | ⚠ cách thủ công có ít downtime |

Từ khoá nhận diện:

"di trú trực tuyến, ít gián đoạn" → ⚠ DMS chế độ online "đánh giá trước khi di trú" → ⚠ Data Migration Assistant "di trú cả máy chủ vật lý/máy ảo" → ⚠ Azure Migrate "khôi phục thảm hoạ" → ⚠ Site Recovery, không phải DMS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | DMA báo bao nhiêu vấn đề chặn | ⚠ chạy TRƯỚC khi lên kế hoạch | | Đích nào phù hợp: Database, MI hay VM | | | Đã diễn tập cutover chưa | |

Và bước quyết định thành bại của một cuộc di trú CSDL: chạy đánh giá tương thích trước khi hứa ngày hoàn thành. Rất nhiều dự án trượt tiến độ vì phát hiện một tính năng không được hỗ trợ vào tuần cuối.

Đáp án

A và C — vCore Rescaling và Automatic Tuning.

Vì sao đúng

⚠ Hai cách cải thiện hiệu năng Managed Instance: | Cách | Nội dung | |---|---| | ⚠ vCore Rescaling | ⚠ tăng số vCore và bộ nhớ — thêm TÀI NGUYÊN | | ⚠ Automatic Tuning | ⚠ tự tạo/xoá index, sửa kế hoạch — dùng tài nguyên HIỆU QUẢ HƠN |

⚠ Hai hướng bổ sung nhau
        ↓
⚠ Rescaling: cho nhiều tài nguyên hơn
   ⚠ hiệu quả ngay, tốn tiền
        ↓
⚠ Automatic Tuning: dùng tài nguyên khôn hơn
   ⚠ miễn phí, cần thời gian học

⚠ Nên thử Automatic Tuning trước — ⚠ nếu vẫn chậm thì mới tăng vCore.

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

• B (Data Encryption) — ⚠ là tính năng BẢO MẬT: ⚠ TDE ⚠ làm hiệu năng giảm nhẹ, không tăng.

• D (Geo-Replication) — ⚠ là tính năng KHÔI PHỤC THẢM HOẠ: ⚠ bản sao ở vùng khác; ⚠ không tăng hiệu năng của primary; ⚠ (secondary đọc được thì có thể tách tải đọc, nhưng đó không phải mục đích chính và MI có hạn chế riêng).

Ghi nhớ

⚠ Cải thiện hiệu năng Azure SQL — thứ tự phải thuộc: | Thứ tự | Cách | |---|---| | ⚠ 1. Sửa truy vấn và INDEX | ⚠ rẻ nhất, hiệu quả nhất | | ⚠ 2. Bật Automatic Tuning | ⚠ miễn phí | | ⚠ 3. Cập nhật thống kê | | | ⚠ 4. Tăng vCore / bậc dịch vụ | ⚠ tốn tiền, hiệu quả ngay | | ⚠ 5. Đổi thế hệ phần cứng | | | ⚠ Sai lầm phổ biến | ⚠ nhảy thẳng tới bước 4 |

Từ khoá nhận diện:

"tăng hiệu năng Managed Instance" → ⚠ vCore rescaling + Automatic Tuning "khôi phục thảm hoạ" → ⚠ Geo-Replication, failover group "bảo mật dữ liệu" → ⚠ TDE, Always Encrypted

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã thử tối ưu truy vấn trước khi tăng vCore chưa | | | Nút thắt là CPU, IO hay chờ khoá | ⚠ wait stats trả lời | | Automatic Tuning đã bật chưa | |

Và sai lầm tốn kém nhất khi xử lý cơ sở dữ liệu chậm: tăng cấu hình trước khi tìm hiểu nguyên nhân. Một truy vấn thiếu index sẽ tiêu hết mọi vCore bạn ném vào nó, và hoá đơn thì tăng vĩnh viễn.

Đáp án

C — SQL Server IaaS Agent Extension.

Vì sao đúng

⚠ Extension này là cầu nối giữa Azure và SQL Server chạy trong VM: | Chức năng | Nội dung | |---|---| | ⚠ Automated Patching | ⚠ tự cài bản vá theo cửa sổ bảo trì — đề này | | ⚠ Automated Backup | ⚠ sao lưu tự động sang Blob Storage | | ⚠ Azure Key Vault integration | ⚠ quản khoá mã hoá | | ⚠ Quản lý giấy phép | ⚠ đổi giữa PAYG và Azure Hybrid Benefit | | ⚠ Cấu hình lưu trữ | ⚠ tối ưu đĩa cho SQL |

⚠ Không có extension
   ⚠ SQL Server trong VM là "hộp đen"
     với Azure
        ↓ ⚠ Cài extension
   ⚠ Azure Portal quản được
     bản vá, sao lưu, giấy phép

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

• A (Azure Update Manager) — ⚠ bẫy gần nhất: ⚠ quản bản vá cho HỆ ĐIỀU HÀNH của VM; ⚠ ⚠ không quản bản vá riêng cho SQL Server như extension này.

• B ("Azure SQL Agent") — ⚠ không phải tên dịch vụ Azure: ⚠ SQL Server Agent là thành phần trong SQL Server, ⚠ dùng để lập lịch job.

• D ("Azure Patch Scheduler") — ⚠ dịch vụ KHÔNG TỒN TẠI.

Ghi nhớ

⚠ SQL Server IaaS Agent Extension — chế độ quản lý: | Chế độ | Nội dung | |---|---| | ⚠ Lightweight | ⚠ chỉ quản giấy phép và phiên bản, không khởi động lại SQL | | ⚠ Full | ⚠ đủ tính năng: patching, backup, Key Vault — cần khởi động lại SQL khi cài | | ⚠ NoAgent | ⚠ cho SQL Server 2008/2008 R2 trên Windows 2008 R2 |

Từ khoá nhận diện:

"tự cập nhật SQL Server trên Azure VM" → ⚠ SQL Server IaaS Agent Extension "vá hệ điều hành" → ⚠ Azure Update Manager "lập lịch job trong CSDL" → ⚠ SQL Server Agent "Azure SQL Database tự vá" → ⚠ Microsoft lo, không phải việc của bạn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Extension đã cài ở chế độ nào | | | Cửa sổ bảo trì có rơi vào giờ cao điểm không | | | Có đang dùng Azure Hybrid Benefit không | ⚠ nếu có giấy phép thì nên bật |

Và khoản tiết kiệm hay bị bỏ quên khi chạy SQL Server trên Azure VM: Azure Hybrid Benefit. Nhiều tổ chức đã có giấy phép SQL Server với Software Assurance mà vẫn trả tiền giấy phép lần thứ hai trong giá VM.

Đáp án

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

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

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

Vì sao đúng

⚠ Hai sản phẩm CSDL chủ lực của Azure: | Dịch vụ | Loại | |---|---| | ⚠ Azure SQL Database | ⚠ quan hệ, PaaS | | ⚠ Azure Cosmos DB | ⚠ NoSQL, phân tán toàn cầu |

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

• C (Azure Storage Account) — ⚠ kho lưu trữ: ⚠ chứa blob, file, queue, table; ⚠ Table Storage là NoSQL đơn giản nhưng ⚠ Storage Account không phải "dịch vụ CSDL" theo nghĩa của đề.

• D (Azure Virtual Network) — ⚠ hạ tầng MẠNG: ⚠ hoàn toàn không phải CSDL.

Ghi nhớ

⚠ Chọn CSDL Azure theo nhu cầu — bảng phải thuộc: | Nhu cầu | Dịch vụ | |---|---| | ⚠ Quan hệ, T-SQL, ứng dụng doanh nghiệp | ⚠ Azure SQL Database | | ⚠ Cần tính năng SQL Server đầy đủ hơn | ⚠ Managed Instance | | ⚠ NoSQL, toàn cầu, độ trễ mili giây | ⚠ Cosmos DB | | ⚠ MySQL / PostgreSQL | ⚠ Azure Database for MySQL/PostgreSQL | | ⚠ Bộ nhớ đệm | ⚠ Azure Cache for Redis | | ⚠ Phân tích dữ liệu lớn | ⚠ Synapse Analytics |

Từ khoá nhận diện:

"CSDL quan hệ" → ⚠ Azure SQL Database "NoSQL, nhiều mô hình API" → ⚠ Cosmos DB "lưu blob, file" → ⚠ Storage Account "mạng riêng ảo" → ⚠ Virtual Network

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng cần quan hệ hay tài liệu | | | Với Cosmos DB: partition key đã chọn kỹ chưa | ⚠ không đổi được | | Mức nhất quán chọn có phù hợp không | ⚠ ảnh hưởng cả chi phí lẫn độ trễ |

Và điểm chung đáng chú ý giữa các cơ sở dữ liệu phân tán, dù của nhà cung cấp nào: khoá phân mảnh là quyết định gần như không đảo ngược được. Cosmos DB gọi là partition key, Bigtable gọi là row key, Spanner gọi là primary key — cùng một bài toán.

Đáp án

C — Azure Resource Manager (ARM) template.

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

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

⚠ Ba câu này nhìn qua có vẻ mâu thuẫn — ⚠ nhưng ⚠ #17406 hỏi "công cụ nào TỰ ĐỘNG HOÁ ĐƯỢC" (chọn nhiều), ⚠ còn hai câu kia hỏi cách CHÍNH để định nghĩa và triển khai hạ tầng.

Vì sao đúng

⚠ ARM template là cách KHAI BÁO chuẩn của Azure:

⚠ Một file JSON mô tả:
   ⚠ SQL Server, CSDL, firewall rule,
     Key Vault, mạng ảo
        ↓
⚠ Triển khai một lần
        ↓
⚠ Chạy lại nhiều lần vẫn ra
   ⚠ CÙNG một trạng thái

⚠ Đây là hạ tầng dạng mã — ⚠ lưu được trong Git, ⚠ rà soát được, ⚠ dựng lại được.

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

• B (Azure CLI) — ⚠ tự động hoá được nhưng là cách MỆNH LỆNH: ⚠ mô tả các bước, ⚠ không mô tả trạng thái mong muốn; ⚠ script phức tạp thì khó bảo trì.

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

• D (Entra ID) — ⚠ dịch vụ QUẢN LÝ DANH TÍNH (tên cũ Azure AD): ⚠ hoàn toàn khác.

Ghi nhớ

⚠ Ba câu cùng chủ đề trong lô này — cách phân biệt: | Đề hỏi | Trả lời | |---|---| | ⚠ "công cụ nào tự động hoá được" (chọn nhiều) | ⚠ CLI + PowerShell | | ⚠ "triển khai nhiều tài nguyên như một đơn vị" | ⚠ ARM template | | ⚠ "công cụ chính để tự động hoá triển khai" | ⚠ ARM template | | ⚠ Nguyên tắc | ⚠ hỏi CÁCH CHÍNH/KHAI BÁO → ARM; hỏi liệt kê công cụ → CLI và PowerShell |

Từ khoá nhận diện:

"định nghĩa hạ tầng, triển khai lặp lại" → ⚠ ARM template / Bicep "script thao tác" → ⚠ CLI hoặc PowerShell "quy trình nghiệp vụ" → ⚠ Logic Apps "quản danh tính" → ⚠ Entra ID

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Môi trường prod có dựng lại được từ mã không | | | Ba môi trường có dùng chung template không | | | Có ai sửa tay trên Portal không | ⚠ gây trôi cấu hình |

Và phép thử đơn giản cho mọi hạ tầng đám mây: nếu resource group này bị xoá sạch, bao lâu thì dựng lại được?. Câu trả lời cho biết hạ tầng của bạn thật sự đang nằm ở đâu — trong mã, hay trong trí nhớ của một người nào đó.

Đáp án

D — Azure ExpressRoute.

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

⚠ Phương án C cũng cần thiết trong thực tế.

⚠ Không mâu thuẫn — ⚠ ExpressRoute là loại kết nối, ⚠ Virtual Network Gateway là thành phần kỹ thuật để hiện thực nó. ⚠ Đề hỏi ở mức giải pháp kết nối lai.

⚠ KHÔNG sửa khoá — ⚠ nhưng nhớ rằng ⚠ triển khai ExpressRoute vẫn cần một ExpressRoute Gateway trong VNet.

Vì sao đúng

⚠ ExpressRoute cho kết nối lai chất lượng cao: | Đặc điểm | Nội dung | |---|---| | ⚠ Đường RIÊNG, KHÔNG qua Internet công cộng | | | ⚠ Băng thông cao | ⚠ 50 Mbps tới 100 Gbps | | ⚠ Độ trễ THẤP và ỔN ĐỊNH | | | ⚠ Có SLA | | | ⚠ Qua nhà cung cấp kết nối đối tác | |

⚠ Trung tâm dữ liệu tại chỗ
        ↓ ⚠ ExpressRoute (đường riêng)
⚠ Azure VNet
        ↓
⚠ SQL Server trên VM, Managed Instance

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

• C (Azure Virtual Network Gateway) — ⚠ đúng là thành phần cần thiết: ⚠ nhưng ⚠ nó là cổng chung cho cả VPN Gateway và ExpressRoute Gateway; ⚠ đề hỏi giải pháp kết nối lai ⚠ hiệu năng cao.

• B (Azure Traffic Manager) — ⚠ cân bằng tải theo DNS ở mức toàn cầu: ⚠ điều hướng người dùng, ⚠ không tạo kết nối mạng riêng.

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

Ghi nhớ

⚠ Kết nối lai Azure — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | ⚠ Site-to-Site VPN | ⚠ IPsec qua Internet — rẻ, dựng nhanh | | ⚠ ExpressRoute | ⚠ đường riêng, băng thông cao, SLA — đắt hơn | | ⚠ Point-to-Site VPN | ⚠ một máy khách nối vào VNet | | ⚠ Azure Virtual WAN | ⚠ quản nhiều kết nối tập trung | | ⚠ Cả VPN và ExpressRoute | ⚠ đều cần Virtual Network Gateway |

Từ khoá nhận diện:

"kết nối lai hiệu năng cao, không qua Internet" → ⚠ ExpressRoute "nối nhanh, chi phí thấp" → ⚠ Site-to-Site VPN "điều hướng người dùng toàn cầu theo DNS" → ⚠ Traffic Manager "đối chiếu Google Cloud" → ⚠ ExpressRoute ↔ Cloud Interconnect; VPN Gateway ↔ Cloud VPN

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cần mã hoá trên ExpressRoute không | ⚠ mặc định KHÔNG mã hoá | | Có đường dự phòng khi ExpressRoute hỏng không | | | CSDL có Private Endpoint chưa | |

Và điều hay bị hiểu nhầm về ExpressRoute: đường riêng không có nghĩa là đường đã mã hoá. Lưu lượng không đi qua Internet công cộng, nhưng nếu quy định bắt mã hoá đầu-cuối thì vẫn phải cấu hình thêm.

Đáp án

C — Automatic Tuning.

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

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

Vì sao đúng

⚠ Chữ "adapt automatically" (tự thích nghi) chỉ đúng Automatic Tuning:

⚠ Theo dõi workload liên tục
        ↓
⚠ Đề xuất thay đổi
        ↓
⚠ ÁP DỤNG
        ↓
⚠ ĐO kết quả
        ↓
⚠ Tệ hơn → ⚠ TỰ HOÀN TÁC

⚠ Vòng lặp khép kín này là điều làm nó "thích nghi" — ⚠ không chỉ khuyến nghị, ⚠ mà tự hành động và tự sửa sai.

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

• A ("Azure SQL Advisor") — ⚠ chỉ ĐƯA KHUYẾN NGHỊ: ⚠ con người phải quyết định và áp dụng; ⚠ ⚠ không tự động; ⚠ (tên chính xác là SQL Database Advisor).

• B (Performance Insights) — ⚠ HIỂN THỊ dữ liệu hiệu năng: ⚠ giúp người phân tích, ⚠ không tự thay đổi gì.

• D (Azure Monitor) — ⚠ nền tảng giám sát và cảnh báo: ⚠ báo cho biết có vấn đề, ⚠ không tự sửa.

Ghi nhớ

⚠ Ba mức tự động hoá — bảng phải thuộc: | Mức | Ví dụ | |---|---| | ⚠ QUAN SÁT | ⚠ Azure Monitor, Performance Insights | | ⚠ KHUYẾN NGHỊ | ⚠ SQL Database Advisor | | ⚠ TỰ HÀNH ĐỘNG | ⚠ Automatic Tuning — đề này | | ⚠ Chỉ mức ba | ⚠ mới gọi là "tự thích nghi" |

Từ khoá nhận diện:

"tự động điều chỉnh, tự thích nghi" → ⚠ Automatic Tuning "đưa ra khuyến nghị" → ⚠ Advisor "hiển thị và cảnh báo" → ⚠ Azure Monitor, Query Performance Insight

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

Và giá trị lớn nhất của tự động hoá có vòng phản hồi: nó dám thử và biết rút lui. Một hệ thống chỉ đưa khuyến nghị sẽ chờ mãi một con người rảnh rỗi; một hệ thống dám hành động mà không biết đo lường thì còn nguy hiểm hơn.

Đáp án

B — Azure SQL Data Migration Assistant (DMA).

Vì sao đúng

⚠ DMA làm hai việc TRƯỚC khi di trú: | Việc | Nội dung | |---|---| | ⚠ Assessment (đánh giá) | ⚠ tìm tính năng không tương thích với đích | | ⚠ Discovery | ⚠ liệt kê tính năng đang dùng, khuyến nghị đích phù hợp | | ⚠ Migration (di trú nhỏ) | ⚠ chuyển lược đồ và dữ liệu cho CSDL nhỏ |

⚠ Chạy DMA trên CSDL nguồn
        ↓
⚠ Báo cáo:
   ⚠ Blocking issue — CHẶN, phải sửa
   ⚠ Behavior change — hoạt động khác đi
   ⚠ Deprecated feature — sắp bị bỏ
        ↓
⚠ Biết CHÍNH XÁC phải sửa gì
   ⚠ TRƯỚC khi bắt đầu

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

• A (Azure Cost Management) — ⚠ quản lý CHI PHÍ: ⚠ theo dõi và tối ưu hoá đơn, ⚠ không đánh giá tương thích kỹ thuật.

• C (Azure DevOps) — ⚠ nền tảng CI/CD và quản lý dự án: ⚠ không phân tích CSDL.

• D (Azure Logic Apps) — ⚠ quy trình nghiệp vụ, không liên quan.

Ghi nhớ

⚠ Bộ công cụ di trú — phân vai rõ ràng: | Công cụ | Giai đoạn | |---|---| | ⚠ Data Migration Assistant (DMA) | ⚠ ĐÁNH GIÁ trước khi di trú | | ⚠ Database Migration Service (DMS) | ⚠ THỰC HIỆN di trú | | ⚠ Azure Migrate | ⚠ đánh giá và di trú toàn bộ hạ tầng | | ⚠ SQL Server Migration Assistant (SSMA) | ⚠ từ Oracle, MySQL, DB2 sang SQL Server |

Từ khoá nhận diện:

"đánh giá trước khi di trú" → ⚠ DMA "thực hiện di trú, ít gián đoạn" → ⚠ DMS "di trú từ Oracle sang SQL" → ⚠ SSMA "đánh giá cả máy chủ, máy ảo" → ⚠ Azure Migrate

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bao nhiêu vấn đề chặn | ⚠ quyết định khối lượng công việc | | Có behavior change nào ảnh hưởng kết quả nghiệp vụ không | | | Đích khuyến nghị có khớp với ngân sách không | |

Và loại phát hiện đáng lo nhất trong báo cáo của DMA không phải là những gì bị chặn: đó là những thay đổi hành vi. Chúng không gây lỗi, không hiện cảnh báo — chỉ lặng lẽ cho ra một con số khác với hệ thống cũ.