Ngân hàng đề — Microsoft Azure Data Fundamentals

Đáp án

D — Tường lửa IP ở cấp SERVER.

Vì sao đúng

⚠ Yêu cầu của đề: ai vào được database này thì cũng phải vào được database kia:

⚠ Hai database, CÙNG một nhóm người dùng
        ↓
⚠ Luật cấp SERVER
   ⚠ áp cho MỌI database trên server
        ↓
⚠ Khai một lần, áp cho cả hai
        ↓
⚠ Ít việc bảo trì hơn

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

• B (tường lửa cấp database) — ⚠ phải khai HAI lần, ⚠ mỗi database một bộ luật; ⚠ đúng về kết quả nhưng ⚠ tốn công và dễ lệch nhau; ⚠ đề hỏi cách cấu hình cho tình huống này, ⚠ và cấp server là câu trả lời gọn.

• A (Network Security Group) — ⚠ không áp cho endpoint công khai của Azure SQL.

• C (Azure Firewall) — ⚠ tường lửa mạng cho VNet, không phải cơ chế của Azure SQL.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp ĐỐI XỨNG với #19531 ở lô trước — ⚠ cùng bộ phương án, ⚠ khoá NGƯỢC nhau.

⚠ Chọn cấp luật tường lửa: | Tình huống | Chọn | |---|---| | ⚠ Mọi database dùng chung nhóm khách | ⚠ cấp SERVER | | ⚠ Mỗi database một nhóm khách riêng | ⚠ cấp DATABASE, và BỎ luật server | | ⚠ Cần cách ly triệt để | ⚠ private endpoint hoặc tách server |

Từ khoá nhận diện:

"áp cho mọi database" → ⚠ server-level "chỉ một database" → ⚠ database-level "không được truy cập chéo" → ⚠ database-level + bỏ luật server "chặn hẳn Internet" → ⚠ private endpoint

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hai database có cùng nhóm người dùng không | | | Có cần cách ly không | ⚠ quyết định cấp luật | | Luật server có đang mở quá rộng không | |

Và cặp câu hỏi này dạy được một điều quan trọng hơn cả bản thân đáp án: cùng một bộ phương án có thể có hai đáp án khác nhau, và yêu cầu nghiệp vụ trong đề là thứ duy nhất phân định.

Đáp án

B — Pipeline.

Vì sao đúng

⚠ Pipeline là đơn vị ĐIỀU PHỐI của Data Factory:

⚠ Pipeline
   ⚠ Copy từ nguồn vào staging
        ↓
   ⚠ Data Flow làm sạch và biến đổi
        ↓
   ⚠ Copy vào đích cuối
        ↓
   ⚠ Stored Procedure cập nhật trạng thái
        ↓
⚠ Toàn bộ chạy như MỘT quy trình có thứ tự

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

• A (Activities) — ⚠ là TỪNG BƯỚC, ⚠ không phải cơ chế điều phối chúng.

• C (SQL statements) — ⚠ có thể là một activity, không phải phương thức điều phối.

• D (HDInsight clusters) — ⚠ là hạ tầng tính toán cho một số hoạt động biến đổi.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ gần trùng #19544 ở lô trước — ⚠ cùng khoá Pipeline, ⚠ chỉ khác cách diễn đạt câu hỏi.

⚠ Điều kiện nối giữa các activity: | Điều kiện | Khi nào chạy tiếp | |---|---| | ⚠ Success | ⚠ bước trước thành công | | ⚠ Failure | ⚠ bước trước THẤT BẠI | | ⚠ Completion | ⚠ xong dù thành công hay không | | ⚠ Skipped | ⚠ bước trước bị bỏ qua | | ⚠ Dùng Failure để | ⚠ gửi cảnh báo hoặc dọn dẹp khi lỗi |

Từ khoá nhận diện:

"điều phối, nhóm hoạt động" → ⚠ pipeline "một bước công việc" → ⚠ activity "khởi động theo lịch" → ⚠ trigger "hạ tầng chạy" → ⚠ integration runtime

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy lại pipeline có nhân đôi dữ liệu không | | | Có nhánh xử lý khi thất bại chưa | | | Có cảnh báo khi pipeline lỗi chưa | |

Và tính chất quyết định một luồng dữ liệu có vận hành được lâu dài hay không, quan trọng hơn cả tốc độ: chạy lại được mà không gây hại. Sớm muộn cũng có ngày bạn phải chạy lại nó.

Đáp án

B — Nội dung của một bảng SQL Database.

Vì sao đúng

⚠ Bảng quan hệ là ví dụ chuẩn mực nhất của dữ liệu có cấu trúc: | Đặc điểm | Nội dung | |---|---| | ⚠ Schema CỐ ĐỊNH | ⚠ khai trước khi có dữ liệu | | ⚠ Mọi dòng CÙNG bộ cột | | | ⚠ Mỗi cột có KIỂU dữ liệu xác định | | | ⚠ Có ràng buộc bảo đảm tính hợp lệ | | | ⚠ Truy vấn được bằng SQL | |

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

• D (dữ liệu JSON) — ⚠ BÁN cấu trúc: ⚠ có khoá nhưng schema linh hoạt.

• A (tệp blob) — ⚠ PHI cấu trúc.

• C (bảng tính Excel) — ⚠ xem mục chất lượng câu hỏi.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án C ⚠ gây tranh cãi.

⚠ Ba loại dữ liệu — bảng chốt: | Loại | Cưỡng chế schema | Ví dụ | |---|---|---| | ⚠ Có cấu trúc | ⚠ CÓ, chặt chẽ | ⚠ bảng SQL | | ⚠ Bán cấu trúc | ⚠ KHÔNG, nhưng có khoá | ⚠ JSON, XML, Excel lỏng lẻo | | ⚠ Phi cấu trúc | ⚠ không có gì | ⚠ ảnh, video |

Từ khoá nhận diện:

"bảng SQL, schema cố định" → ⚠ có cấu trúc "JSON, XML" → ⚠ bán cấu trúc "ảnh, video, PDF" → ⚠ phi cấu trúc "Excel" → ⚠ ranh giới, thường xếp có cấu trúc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Schema có được CƯỠNG CHẾ không | ⚠ câu hỏi phân định | | Mọi bản ghi có cùng bộ trường không | | | Nguồn có thể tự ý đổi cấu trúc không | |

Và câu hỏi phân định chính xác nhất giữa "có cấu trúc" và "bán cấu trúc", rõ hơn cả việc nhìn định dạng tệp: có ai cưỡng chế cấu trúc đó không? Bảng SQL từ chối dữ liệu sai; Excel thì nhận tất.

Đáp án

A — Azure Blob Storage.

Vì sao đúng

⚠ Bốn manh mối trong đề đều dẫn về Blob: | Manh mối | Kết luận | |---|---| | ⚠ Dữ liệu NHỊ PHÂN | ⚠ ảnh và video | | ⚠ Nhiều GB mỗi ngày | ⚠ cần co giãn lớn, rẻ | | ⚠ Mỗi tệp có KHOÁ duy nhất | ⚠ tên blob | | ⚠ Dùng khoá để lấy lại | ⚠ truy cập theo tên, không cần truy vấn |

⚠ Container / ten-duy-nhat.mp4
        ↓
⚠ Lấy trực tiếp bằng URL
⚠ Không cần truy vấn theo trường

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

• C (Table Storage) — ⚠ cho dữ liệu khoá-giá trị NHỎ: ⚠ giới hạn ⚠ 1MB mỗi thực thể, ⚠ không lưu được video.

• B (Cosmos DB) — ⚠ cho tài liệu JSON, ⚠ giới hạn 2MB mỗi item và ⚠ rất đắt cho hàng GB nhị phân.

• D (Azure SQL Database) — ⚠ nhồi video vào cột nhị phân là thiết kế tệ: ⚠ phình CSDL, sao lưu chậm, chi phí cao.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ áp dụng kiến thức của #19526 và #19547 vào tình huống cụ thể.

⚠ Giới hạn kích thước — con số quyết định: | Dịch vụ | Giới hạn mỗi mục | |---|---| | ⚠ Table Storage | ⚠ 1 MB mỗi thực thể | | ⚠ Cosmos DB | ⚠ 2 MB mỗi item | | ⚠ Queue Storage | ⚠ 64 KB mỗi tin nhắn | | ⚠ Blob | ⚠ tới hàng TB mỗi blob | | ⚠ Câu hỏi nhắc "video" | ⚠ loại ngay ba dịch vụ đầu |

Từ khoá nhận diện:

"ảnh, video, nhị phân, hàng GB" → ⚠ Blob Storage "JSON nhỏ, truy vấn nhiều trường" → ⚠ Cosmos DB "khoá-giá trị nhỏ, rẻ" → ⚠ Table Storage "quan hệ, giao dịch" → ⚠ Azure SQL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kích thước mỗi tệp bao nhiêu | ⚠ loại ngay các dịch vụ giới hạn nhỏ | | Có cần truy vấn theo nội dung không | | | Đã có lifecycle policy cho tệp cũ chưa | |

Và cách loại phương án nhanh nhất ở nhóm câu hỏi chọn kho lưu trữ: nhìn vào KÍCH THƯỚC mỗi mục dữ liệu. Chỉ riêng chữ "video" trong đề đã loại được ba trong bốn phương án.

Đáp án

B — Cơ sở dữ liệu cưỡng chế TÍNH DUY NHẤT, và không dòng nào khác được có cùng giá trị khoá chính.

Vì sao đúng

⚠ Khoá chính có hai tính chất bắt buộc: | Tính chất | Nội dung | |---|---| | ⚠ DUY NHẤT | ⚠ không hai dòng trùng nhau | | ⚠ KHÔNG NULL | ⚠ luôn phải có giá trị | | ⚠ Tự tạo chỉ mục | ⚠ thường là clustered index | | ⚠ Là đích cho khoá ngoại | |

⚠ INSERT dòng có khoá chính trùng
        ↓
⚠ CSDL TỪ CHỐI
   ⚠ "Violation of PRIMARY KEY constraint"

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

• A (mọi bảng BẮT BUỘC phải có đúng một khoá chính) — ⚠ SAI ở chữ "bắt buộc": ⚠ bảng ⚠ không có khoá chính vẫn tạo được (gọi là heap); ⚠ đó là thực hành tệ nhưng hợp lệ.

• D (một bảng có nhiều khoá chính) — ⚠ SAI: ⚠ chỉ MỘT khoá chính, ⚠ nhưng khoá đó ⚠ ghép nhiều cột được.

• C (mọi mục trong một logical partition có cùng giá trị khoá chính) — ⚠ là khái niệm của Cosmos DB, ⚠ nói về partition key, không phải khoá chính quan hệ.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ cùng chùm với #19503 và #19551 về ràng buộc quan hệ.

⚠ Khoá chính và khoá duy nhất — phân biệt: | Tiêu chí | PRIMARY KEY | UNIQUE | |---|---|---| | ⚠ Số lượng mỗi bảng | ⚠ 1 | ⚠ nhiều | | ⚠ Cho phép NULL | ⚠ KHÔNG | ⚠ CÓ, thường một NULL | | ⚠ Chỉ mục mặc định | ⚠ clustered | ⚠ nonclustered | | ⚠ Làm đích khoá ngoại | ⚠ thường dùng | ⚠ dùng được |

Từ khoá nhận diện:

"duy nhất, không NULL, một cái" → ⚠ primary key "duy nhất nhưng cho NULL, nhiều cái" → ⚠ unique constraint "trỏ sang bảng khác" → ⚠ foreign key "logical partition" → ⚠ Cosmos DB, không phải quan hệ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng đã có khoá chính chưa | | | Khoá chính có hẹp và tăng dần không | | | Có dùng GUID ngẫu nhiên làm clustered key không | ⚠ ảnh hưởng hiệu năng ghi |

Và lựa chọn kỹ thuật tưởng nhỏ nhưng ảnh hưởng hiệu năng ghi suốt vòng đời bảng: kiểu dữ liệu của khoá chính. Một GUID ngẫu nhiên làm khoá phân cụm khiến mỗi lần chèn là một lần xáo trộn trang dữ liệu.

Đáp án

A — Một nhóm gồm một hoặc nhiều câu lệnh SQL.

Vì sao đúng

⚠ Stored procedure là mã lệnh được đặt tên và lưu trong CSDL:

⚠ CREATE PROCEDURE sp_TaoDonHang
⚠   @khachHangId INT, @tongTien MONEY
⚠ AS
⚠ BEGIN
⚠   BEGIN TRANSACTION
⚠   INSERT INTO DonHang ...
⚠   UPDATE TonKho ...
⚠   COMMIT
⚠ END

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

• B (bảng ảo định nghĩa bằng truy vấn) — ⚠ đó là VIEW.

• C (đối tượng chứa toàn bộ dữ liệu) — ⚠ đó là TABLE.

• D (chỉ kích hoạt khi dòng dữ liệu được chèn, sửa, xoá) — ⚠ đó là TRIGGER.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ ba dùng chung bộ định nghĩa trong lô.

⚠ Bốn đối tượng — bảng chốt: | Đối tượng | Định nghĩa một câu | |---|---| | ⚠ Table | ⚠ nơi dữ liệu thật nằm | | ⚠ View | ⚠ truy vấn được đặt tên | | ⚠ Stored procedure | ⚠ nhóm câu lệnh, gọi bằng EXEC | | ⚠ Trigger | ⚠ thủ tục TỰ chạy khi có thao tác dữ liệu |

Từ khoá nhận diện:

"nhóm câu lệnh, có tham số, gọi bằng EXEC" → ⚠ stored procedure "tự chạy khi INSERT/UPDATE/DELETE" → ⚠ trigger "bảng ảo" → ⚠ view "trả về giá trị, dùng trong SELECT" → ⚠ function

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Logic nghiệp vụ nên ở CSDL hay ứng dụng | | | Có trigger nào đang chạy ngầm không | | | Có scalar function nào trong WHERE không | ⚠ rà soát hiệu năng |

Và điều làm việc gỡ lỗi một cơ sở dữ liệu trở nên khó chịu nhất: trigger chạy ngầm mà không ai nhớ là nó tồn tại. Dữ liệu thay đổi mà không có dòng mã ứng dụng nào giải thích được vì sao.

Đáp án

A — Hỗ trợ nhiều KIỂU dữ liệu khác nhau thay vì bị ép vào mô hình hàng/cột.

Vì sao đúng

⚠ Đây là ưu điểm nền tảng của CSDL phi quan hệ: | Mô hình | Dữ liệu phù hợp | |---|---| | ⚠ Tài liệu | ⚠ JSON lồng nhau, schema linh hoạt | | ⚠ Khoá-giá trị | ⚠ tra cứu nhanh theo khoá | | ⚠ Cột rộng | ⚠ hàng triệu cột thưa | | ⚠ Đồ thị | ⚠ quan hệ nhiều tầng | | ⚠ Đối tượng | ⚠ tệp nhị phân lớn |

⚠ Quan hệ: MỌI thứ phải thành hàng và cột
        ↓ ⚠ dữ liệu lồng nhau phải tách bảng
⚠ Phi quan hệ: chọn mô hình HỢP với dữ liệu

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

• B (dùng khoá ngoại cưỡng chế toàn vẹn) — ⚠ đó là ưu điểm của QUAN HỆ, ⚠ và NoSQL thường ⚠ không có.

• D (dùng chỉ mục để tìm nhanh) — ⚠ cả hai loại đều có chỉ mục, không phải điểm phân biệt.

• C (theo mô hình mã nguồn mở) — ⚠ không liên quan: ⚠ có CSDL quan hệ mã nguồn mở và NoSQL thương mại.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp đối xứng với #19506 ở lô trước.

⚠ Ưu và nhược của NoSQL — bảng cân bằng: | Ưu | Nhược | |---|---| | ⚠ Nhiều mô hình dữ liệu | ⚠ ít bảo đảm nhất quán | | ⚠ Schema linh hoạt | ⚠ ứng dụng phải tự kiểm tra | | ⚠ Co giãn ngang tốt | ⚠ truy vấn phức tạp hạn chế | | ⚠ Thông lượng cao | ⚠ không có JOIN mạnh |

Từ khoá nhận diện:

"linh hoạt, nhiều kiểu dữ liệu, co giãn" → ⚠ ưu điểm NoSQL "toàn vẹn, giao dịch, JOIN" → ⚠ ưu điểm quan hệ "mã nguồn mở" → ⚠ không phải điểm phân biệt "chỉ mục" → ⚠ cả hai đều có

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu có tự nhiên là hàng và cột không | | | Có cần giao dịch qua nhiều bản ghi không | | | Đội có kỹ năng vận hành công nghệ đó không | |

Và cách chọn giữa quan hệ và phi quan hệ ít sai lầm nhất, ngược với cách thường được bàn: bắt đầu từ HÌNH DẠNG dữ liệu và MẪU TRUY VẤN, không bắt đầu từ tên công nghệ.

Đáp án

B — Chuyển toàn bộ ứng dụng sang dùng khoá 2, RỒI mới tạo lại khoá 1.

Vì sao đúng

⚠ Hai khoá tồn tại chính là để luân chuyển KHÔNG GIÁN ĐOẠN:

⚠ Bước 1: cập nhật ứng dụng dùng KHOÁ 2
        ↓ ⚠ ứng dụng vẫn chạy bình thường
⚠ Bước 2: tạo lại (regenerate) KHOÁ 1
        ↓ ⚠ khoá bị lộ mất hiệu lực
⚠ Bước 3 (tuỳ chọn): chuyển về khoá 1 mới,
   ⚠ rồi tạo lại khoá 2
        ↓
⚠ Cả hai khoá đều mới, KHÔNG có phút gián đoạn nào

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

• A (tạo lại khoá 1 ngay) — ⚠ đúng về bảo mật nhưng GÂY GIÁN ĐOẠN: ⚠ mọi ứng dụng đang dùng khoá 1 sẽ ⚠ lỗi xác thực ngay lập tức.

• C (tạo tài khoản mới và di chuyển dữ liệu) — ⚠ phản ứng thái quá: ⚠ tốn kém, chậm, và không cần thiết.

• D (chỉ thêm luật tường lửa) — ⚠ KHÔNG đủ: ⚠ khoá vẫn còn hiệu lực; ⚠ tường lửa là lớp bổ sung, không thay thế việc thu hồi khoá.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #19559 và #19564 về mô hình khoá của Cosmos DB.

⚠ Quy trình ứng phó khi khoá bị lộ: | Bước | Việc | |---|---| | ⚠ 1. Đánh giá phạm vi | ⚠ lộ ở đâu, bao lâu, ai thấy | | ⚠ 2. Chuyển ứng dụng sang khoá phụ | | | ⚠ 3. Tạo lại khoá bị lộ | | | ⚠ 4. Kiểm tra nhật ký truy cập bất thường | ⚠ hay bị bỏ qua | | ⚠ 5. Rà soát vì sao khoá lọt ra ngoài | | | ⚠ 6. Cân nhắc chuyển sang managed identity | |

Từ khoá nhận diện:

"khoá bị lộ" → ⚠ luân chuyển qua khoá phụ "không được gián đoạn" → ⚠ hai khoá luân phiên "không muốn giữ khoá nữa" → ⚠ managed identity + RBAC "giới hạn IP" → ⚠ lớp bổ sung, không thay thế

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng lấy khoá từ đâu | ⚠ nên là Key Vault | | Đã kiểm nhật ký truy cập bất thường chưa | | | Có thể bỏ khoá và dùng managed identity không | |

Và bước hay bị bỏ qua nhất sau khi đã thu hồi một khoá bị lộ: kiểm tra nhật ký xem trong khoảng thời gian đó có ai đã dùng nó chưa. Thu hồi khoá chặn được tương lai, không nói gì về những gì đã xảy ra.

Đáp án

B — Azure Disk Encryption.

Vì sao đúng

⚠ Azure Disk Encryption mã hoá ổ đĩa của máy ảo — đúng nghĩa "data at rest": | Cơ chế | Nội dung | |---|---| | ⚠ BitLocker cho VM Windows | | | ⚠ dm-crypt cho VM Linux | | | ⚠ Khoá lưu trong Azure Key Vault | | | ⚠ Mã hoá cả đĩa hệ điều hành và đĩa dữ liệu | |

⚠ Đĩa VM
        ↓ ⚠ Azure Disk Encryption
⚠ Nội dung đĩa được mã hoá
        ↓
⚠ Lấy được ảnh đĩa cũng không đọc được

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

• D (HTTPS/SSL) — ⚠ bảo vệ khi TRUYỀN, không phải khi lưu.

• C (Azure Active Directory) — ⚠ dịch vụ DANH TÍNH, không mã hoá dữ liệu.

• A (Azure Information Protection) — ⚠ phân loại và gắn nhãn TÀI LIỆU: ⚠ có mã hoá tệp Office nhưng ⚠ không phải cơ chế mã hoá lưu trữ hạ tầng như đề hỏi.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ tư về ba trạng thái dữ liệu qua hai lô.

⚠ Mã hoá at rest theo từng dịch vụ: | Dịch vụ | Cơ chế | |---|---| | ⚠ Máy ảo | ⚠ Azure Disk Encryption, hoặc SSE trên managed disk | | ⚠ SQL Database | ⚠ TDE — bật mặc định | | ⚠ Storage Account | ⚠ SSE — bật sẵn, không tắt được | | ⚠ Cosmos DB | ⚠ bật sẵn |

Từ khoá nhận diện:

"mã hoá ổ đĩa VM" → ⚠ Azure Disk Encryption "mã hoá CSDL SQL" → ⚠ TDE "mã hoá đường truyền" → ⚠ TLS/HTTPS "gắn nhãn và bảo vệ tài liệu" → ⚠ Information Protection / Purview

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đĩa tạm và cache có được mã hoá không | ⚠ hay bị bỏ sót | | Khoá do Microsoft hay do bạn quản lý | | | Key Vault đã bật purge protection chưa | |

Và phần dữ liệu hay bị bỏ sót khi bàn về mã hoá đĩa máy ảo: ổ đĩa tạm và bộ nhớ đệm. Đó cũng là nơi dữ liệu nhạy cảm đi qua, và không phải cấu hình nào cũng bao phủ chúng.

Đáp án

B — Azure SQL Database, single instance (database đơn lẻ).

Vì sao đúng

⚠ Ba manh mối trong đề đều dẫn về database đơn lẻ: | Manh mối | Kết luận | |---|---| | ⚠ CSDL nhỏ, ít được dùng | ⚠ không cần cấu hình lớn | | ⚠ CHỈ dùng tính năng SQL Server chuẩn | ⚠ không cần Managed Instance | | ⚠ Mục tiêu là TIẾT KIỆM | ⚠ chọn lựa chọn rẻ nhất |

⚠ Ít dùng + tính năng chuẩn + muốn rẻ
        ↓
⚠ Single database
   ⚠ có bậc Basic rất rẻ
   ⚠ có chế độ SERVERLESS tự tạm dừng
        ↓
⚠ Không dùng thì gần như không tốn tiền tính toán

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

• C (SQL Managed Instance) — ⚠ đắt nhất trong ba lựa chọn: ⚠ trả cho cả một instance; ⚠ chỉ đáng khi cần tính năng cấp instance.

• A (elastic pool) — ⚠ chỉ tiết kiệm khi có NHIỀU database tải lệch giờ nhau; ⚠ đề chỉ có ⚠ một database.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp đối xứng với #19532 ở lô trước.

⚠ Ba lựa chọn SQL trên Azure — chọn theo yêu cầu: | Yêu cầu chính | Chọn | |---|---| | ⚠ Rẻ, đơn giản, tính năng chuẩn | ⚠ Single database | | ⚠ Nhiều DB tải lệch giờ | ⚠ Elastic pool | | ⚠ Cần SQL Agent, cross-database query | ⚠ Managed Instance | | ⚠ Cần tương thích tuyệt đối, cấu hình OS | ⚠ SQL Server trong VM |

Từ khoá nhận diện:

"tiết kiệm, ít dùng, tính năng chuẩn" → ⚠ single database "nhiều database dùng chung" → ⚠ elastic pool "cần tương thích cao" → ⚠ Managed Instance "không đổi một dòng mã" → ⚠ VM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã chạy đánh giá tương thích chưa | | | CSDL có ngủ được không | ⚠ serverless tiết kiệm rất nhiều | | Người dùng có chịu được độ trễ khi thức dậy không | |

Và lựa chọn tiết kiệm nhất cho một cơ sở dữ liệu nội bộ ít người dùng, thường bị bỏ qua vì ít được nhắc tới: bậc serverless tự tạm dừng. Một ứng dụng quản trị chỉ dùng vài giờ mỗi tuần gần như không tốn chi phí tính toán.