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

Tìm thấy 328 câu.

Câu 141 Non-relational DB
What type of non-relational data revolves around nodes and the relationships between the nodes? This would be a good data type for databases that need to navigate from node to related nodes, like a company organization chart or a social network.
  1. A MongoDB data
  2. B Core (SQL) data
  3. C Document data
  4. D Graph data
Xem giải thích

Đáp án

D — Dữ liệu ĐỒ THỊ (graph data).

Vì sao đúng

⚠ Đề mô tả chính xác mô hình đồ thị: | Đặc điểm đề nêu | Đồ thị | |---|---| | ⚠ Nút và quan hệ giữa các nút | ⚠ vertex và edge | | ⚠ Điều hướng từ nút này sang nút liên quan | ⚠ traversal | | ⚠ Sơ đồ tổ chức công ty | ⚠ cấu trúc phân cấp | | ⚠ Mạng xã hội | ⚠ ứng dụng kinh điển |

⚠ (An) ──quản lý──▶ (Bình)
⚠   │                  │
⚠ đồng nghiệp      quản lý
⚠   ▼                  ▼
⚠ (Chi) ──bạn bè──▶ (Dũng)

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

  • C (dữ liệu tài liệu) — ⚠ JSON có cấu trúc, ⚠ không tối ưu cho việc đi theo quan hệ nhiều tầng.

  • A (MongoDB data) và B (Core SQL data) — ⚠ là tên API, không phải LOẠI dữ liệu; ⚠ và cả hai đều là mô hình tài liệu.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ tư về năm mô hình phi quan hệ qua ba lô.

Câu Mô tả Khoá
⚠ #19555 ⚠ một giá trị mỗi khoá, không truy vấn nội dung ⚠ key-value
⚠ #19595 ⚠ JSON, XML, có truy vấn nội dung ⚠ document
⚠ #19602 ⚠ API nào cho đồ thị ⚠ Gremlin
⚠ #19631 (câu này) ⚠ nút và quan hệ ⚠ graph
⚠ Bốn câu ⚠ cùng bảng năm mô hình
⚠ Lưu ý ⚠ phương án A và B ở đây nhầm lẫn giữa TÊN API và LOẠI DỮ LIỆU

⚠ Năm mô hình phi quan hệ — bảng cuối cùng: | Mô hình | Nhận diện | API Cosmos | |---|---|---| | ⚠ Đối tượng | ⚠ tệp nhị phân | ⚠ (Blob) | | ⚠ Khoá-giá trị | ⚠ tra theo khoá | ⚠ Table | | ⚠ Tài liệu | ⚠ JSON, truy vấn nội dung | ⚠ NoSQL, MongoDB | | ⚠ Cột rộng | ⚠ nhiều cột thưa | ⚠ Cassandra | | ⚠ Đồ thị | ⚠ nút và cạnh | ⚠ Gremlin |

Từ khoá nhận diện:

"nút, cạnh, quan hệ, điều hướng" → ⚠ graph "JSON, truy vấn theo trường" → ⚠ document "tra theo khoá" → ⚠ key-value "sơ đồ tổ chức, mạng xã hội" → ⚠ graph

⚠ Vì sao đồ thị hơn quan hệ ở đây Lý do
⚠ Sơ đồ tổ chức có độ sâu KHÔNG BIẾT TRƯỚC
⚠ SQL cần recursive CTE, chậm dần theo độ sâu
⚠ Đồ thị đi theo cạnh, chi phí gần như không đổi
⚠ Điểm gãy ⚠ từ ba tầng quan hệ trở lên
⚠ Ứng dụng đồ thị trong thực tế Ứng dụng
⚠ "Người bạn có thể biết" ⚠ mạng xã hội
⚠ Phát hiện gian lận theo vòng liên kết
⚠ Gợi ý sản phẩm theo hành vi tương tự
⚠ Phân tích chuỗi cung ứng
⚠ Quản lý quyền phân cấp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn đi qua mấy tầng quan hệ | ⚠ từ ba tầng thì cân nhắc đồ thị | | Độ sâu có biết trước không | | | Quan hệ có thay đổi thường xuyên không | |

Và dấu hiệu rõ nhất cho thấy bài toán thuộc về cơ sở dữ liệu đồ thị: bạn không biết trước truy vấn sẽ phải đi qua bao nhiêu tầng quan hệ.

Câu 142 Data analytics core concepts
Which data loading approach is more suitable for situations that require scaling, and is ideal for large volumes of data?
  1. A ETL
  2. B ELT
Xem giải thích

Đáp án

B — ELT.

Vì sao đúng

⚠ ELT co giãn tốt hơn vì tận dụng sức mạnh của KHO ĐÍCH:

⚠ ETL
   ⚠ Biến đổi ở tầng TRUNG GIAN
   ⚠ tầng đó thành nút thắt khi dữ liệu lớn
        ↓
⚠ ELT
   ⚠ Nạp thô vào kho (nhanh, song song)
   ⚠ Biến đổi BẰNG chính kho đích
        ↓
⚠ Synapse, Databricks, Snowflake
   ⚠ co giãn hàng trăm node
Vì sao ELT hợp khối lượng lớn Lý do
⚠ Kho đích hiện đại rất mạnh
⚠ Nạp thô nhanh hơn nạp đã biến đổi
⚠ Co giãn tính toán độc lập với lưu trữ
⚠ Giữ được bản thô để xử lý lại

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

  • A (ETL) — ⚠ tầng biến đổi trung gian trở thành nút thắt khi khối lượng tăng; ⚠ phải mở rộng riêng tầng đó.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ tạo thành bộ ba với #19540 và #19622, ⚠ và có một ⚠ CĂNG THẲNG đáng chú ý.

Câu Hỏi gì Khoá
⚠ #19540 ⚠ dữ liệu đã đúng định dạng ⚠ ELT
⚠ #19622 ⚠ ETL giúp gì cho quyền riêng tư ⚠ lọc dữ liệu nhạy cảm trước khi nạp
⚠ #19632 (câu này) ⚠ cách nào hợp co giãn và khối lượng lớn ⚠ ELT
⚠ Căng thẳng ⚠ #19622 bênh ETL, #19632 bênh ELT
⚠ KHÔNG mâu thuẫn ⚠ hai câu xét hai TIÊU CHÍ khác nhau
⚠ Kết luận thực tế ⚠ khối lượng lớn → ELT; dữ liệu nhạy cảm → ETL hoặc ELT có phân quyền chặt tầng thô

⚠ ETL và ELT — bảng đánh đổi đầy đủ: | Tiêu chí | ETL | ELT | |---|---|---| | ⚠ Co giãn | ⚠ hạn chế bởi tầng trung gian | ⚠ TỐT | | ⚠ Khối lượng lớn | ⚠ khó | ⚠ TỐT | | ⚠ Quyền riêng tư | ⚠ TỐT — lọc trước | ⚠ cần phân quyền chặt | | ⚠ Giữ dữ liệu thô | ⚠ thường không | ⚠ CÓ | | ⚠ Xử lý lại khi sai logic | ⚠ phải lấy lại từ nguồn | ⚠ chạy lại từ tầng thô |

Từ khoá nhận diện:

"co giãn, khối lượng lớn" → ⚠ ELT "lọc dữ liệu nhạy cảm trước khi nạp" → ⚠ ETL "giữ bản thô để xử lý lại" → ⚠ ELT "kho đích mạnh" → ⚠ ELT

⚠ Cách dung hoà trong thực tế Cách
⚠ Dùng ELT làm mặc định
⚠ Nhưng LỌC dữ liệu cực nhạy cảm ngay ở bước trích
⚠ Tầng bronze phân quyền rất chặt
⚠ Chỉ tầng silver và gold mở rộng cho người dùng
⚠ Kết quả ⚠ vừa co giãn vừa kiểm soát được rủi ro

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khối lượng dữ liệu là bao nhiêu | ⚠ lớn thì ELT | | Có dữ liệu nhạy cảm không | ⚠ có thì cân nhắc lọc sớm | | Ai truy cập được tầng dữ liệu thô | |

Và cách dung hoà hai câu trả lời tưởng như trái ngược nhau trong cùng một bộ đề: chọn ELT vì khối lượng, nhưng lọc những trường nhạy cảm nhất ngay từ bước trích xuất. Không phải chọn một bỏ một.

Câu 143 Relational data workloads
Which of the following columns would make a good ID field for a data table?
  1. A Email address
  2. B Customer name
  3. C A sequential number starting from 1 that increments by 1 every time a data row is added to the table
  4. D A timestamp field with the current date and time, down to the second
Xem giải thích

Đáp án

C — Một số TUẦN TỰ bắt đầu từ 1 và tăng thêm 1 mỗi khi thêm một dòng dữ liệu.

Vì sao đúng

⚠ Đó là khoá thay thế (surrogate key) — lựa chọn chuẩn: | Tiêu chí của khoá tốt | Số tự tăng | |---|---| | ⚠ DUY NHẤT | ⚠ CSDL bảo đảm | | ⚠ KHÔNG BAO GIỜ đổi | ⚠ không mang nghĩa nên không cần đổi | | ⚠ HẸP | ⚠ 4 hoặc 8 byte | | ⚠ TĂNG DẦN | ⚠ tốt cho clustered index | | ⚠ Không lộ thông tin | |

⚠ id INT IDENTITY(1,1) PRIMARY KEY

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

  • A (địa chỉ email) — ⚠ CÓ THỂ ĐỔI: ⚠ người dùng đổi email là phải cập nhật mọi bảng con; ⚠ và cũng rộng hơn nhiều.

  • B (tên khách hàng) — ⚠ KHÔNG duy nhất và CÓ THỂ ĐỔI: ⚠ nhiều người trùng tên hoàn toàn bình thường.

  • D (dấu thời gian tới giây) — ⚠ KHÔNG bảo đảm duy nhất: ⚠ hai bản ghi trong cùng một giây là chuyện thường.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #19575 ở lô trước.

Câu Hỏi gì Khoá
⚠ #19575 ⚠ hệ quả của khoá chính ⚠ cưỡng chế duy nhất
⚠ #19633 (câu này) ⚠ cột nào làm khoá tốt ⚠ số tự tăng
⚠ Bổ sung nhau ⚠ một hỏi tính chất, một hỏi cách chọn

⚠ Khoá tự nhiên và khoá thay thế: | Loại | Ví dụ | Rủi ro | |---|---|---| | ⚠ Natural key | ⚠ CCCD, mã số thuế, email | ⚠ có thể đổi, có thể trùng, lộ thông tin | | ⚠ Surrogate key | ⚠ IDENTITY, GUID | ⚠ không mang nghĩa — đó là ưu điểm | | ⚠ Thực tế | ⚠ phần lớn hệ thống dùng surrogate key | | ⚠ Vẫn nên | ⚠ đặt UNIQUE constraint trên khoá tự nhiên |

Từ khoá nhận diện:

"số tự tăng, IDENTITY" → ⚠ khoá thay thế tốt "email, số điện thoại" → ⚠ có thể đổi, không nên làm khoá "tên" → ⚠ không duy nhất "GUID" → ⚠ duy nhất nhưng rộng và ngẫu nhiên

⚠ Ba tiêu chí của khoá chính tốt Tiêu chí
⚠ Ổn định ⚠ không bao giờ phải đổi giá trị
⚠ Hẹp ⚠ mọi chỉ mục khác đều tham chiếu tới nó
⚠ Tăng dần ⚠ tránh chia trang khi chèn
⚠ Email vi phạm ⚠ cả ba
⚠ GUID — khi nào cần và cái giá Điểm
⚠ Cần khi tạo id ở nhiều nơi rồi gộp lại ⚠ hệ phân tán, offline-first
⚠ 16 byte, gấp bốn lần INT
⚠ NGẪU NHIÊN → chia trang liên tục
⚠ Nếu buộc dùng ⚠ cân nhắc sequential GUID hoặc tách khoá phân cụm riêng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Giá trị khoá có bao giờ phải đổi không | ⚠ câu hỏi quan trọng nhất | | Khoá rộng bao nhiêu byte | | | Khoá tự nhiên đã có UNIQUE constraint chưa | |

Và câu hỏi duy nhất cần đặt khi cân nhắc dùng một cột dữ liệu thật làm khoá chính: giá trị này có bao giờ phải thay đổi không? Chỉ cần câu trả lời là "có thể", đó không phải khoá tốt.

Câu 144 Relational data workloads
What data structure allows a database server to find data much faster than without it?
  1. A Foreign Keys
  2. B Columns
  3. C Rows
  4. D Indexes
Xem giải thích

Đáp án

D — Chỉ mục (Indexes).

Vì sao đúng

⚠ Chỉ mục là cấu trúc tra cứu giúp bỏ qua việc quét toàn bảng:

⚠ Không chỉ mục
   ⚠ WHERE email = 'a@b.com'
   ⚠ → quét 10 triệu dòng
        ↓ ⚠ thêm chỉ mục
⚠ Đi theo cây B
   ⚠ → vài lần đọc trang
        ↓
⚠ Nhanh hơn hàng nghìn lần
Loại chỉ mục Nội dung
⚠ Clustered ⚠ sắp xếp chính dữ liệu, một cái
⚠ Nonclustered ⚠ cấu trúc riêng có con trỏ, nhiều cái
⚠ Columnstore ⚠ cho phân tích
⚠ Filtered ⚠ chỉ một phần dòng

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

  • A (khoá ngoại) — ⚠ bảo đảm TOÀN VẸN THAM CHIẾU; ⚠ nó không tự tạo chỉ mục và không phải để tăng tốc.

  • B (cột) và C (dòng) — ⚠ là thành phần cấu trúc bảng, không phải cấu trúc tăng tốc.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ ba về chỉ mục qua hai lô.

Câu Hỏi gì Khoá
⚠ #19525 ⚠ clustered và nonclustered khác gì ⚠ clustered sắp xếp chính dữ liệu
⚠ #19590 ⚠ INDEX là gì ⚠ cấu trúc tăng tốc truy xuất
⚠ #19634 (câu này) ⚠ cấu trúc nào giúp tìm nhanh hơn ⚠ indexes
⚠ Ba câu ⚠ cùng một khái niệm, ba cách hỏi

⚠ Điều cần nhớ về khoá ngoại và chỉ mục: | Điểm | Nội dung | |---|---| | ⚠ Khoá CHÍNH tự tạo chỉ mục | ⚠ thường là clustered | | ⚠ Khoá NGOẠI KHÔNG tự tạo chỉ mục | ⚠ điểm rất hay bị quên | | ⚠ Thiếu chỉ mục trên khoá ngoại | ⚠ làm JOIN và xoá cha rất chậm | | ⚠ Thực hành tốt | ⚠ luôn tạo chỉ mục trên cột khoá ngoại |

Từ khoá nhận diện:

"tìm nhanh hơn" → ⚠ index "bảo đảm toàn vẹn" → ⚠ foreign key "duy nhất, không NULL" → ⚠ primary key "phân tích, lưu theo cột" → ⚠ columnstore index

⚠ Khi nào chỉ mục KHÔNG giúp được Khi nào
⚠ Truy vấn lấy phần lớn số dòng ⚠ quét bảng còn nhanh hơn
⚠ Dùng hàm lên cột trong WHERE ⚠ YEAR(ngay) = 2026 làm chỉ mục vô dụng
⚠ LIKE bắt đầu bằng ký tự đại diện ⚠ '%abc'
⚠ Cột có rất ít giá trị khác nhau ⚠ cột giới tính
⚠ Cách sửa ⚠ viết lại điều kiện để cột đứng một mình
⚠ Chi phí của chỉ mục Chi phí
⚠ Mỗi INSERT, UPDATE, DELETE phải cập nhật chỉ mục
⚠ Tốn dung lượng
⚠ Chỉ mục không dùng chỉ có hại
⚠ Rà soát bằng ⚠ sys.dm_db_index_usage_stats

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cột khoá ngoại đã có chỉ mục chưa | ⚠ rất hay thiếu | | Có hàm nào bọc quanh cột trong WHERE không | | | Có chỉ mục nào chưa từng được dùng không | |

Và lý do phổ biến nhất khiến một truy vấn vẫn chậm dù đã có chỉ mục đúng cột: một hàm được bọc quanh cột trong mệnh đề WHERE. Chỉ mục lập tức trở thành vô dụng, và không có cảnh báo nào.

Câu 145 Relational data security
Can a SQL Database server have both Server-level IP firewall rules AND Database-level IP firewall rules? Or must you choose one or the other?
  1. A No, you must choose one or the other
  2. B Any IPs in the database-level firewall must also exist in the server-level firewall
  3. C You can have both server-level rules and database-level rules
Xem giải thích

Đáp án

C — Bạn có thể có CẢ luật cấp server LẪN luật cấp database.

Vì sao đúng

⚠ Hai tập luật tồn tại song song và CỘNG với nhau:

⚠ Kết nối tới DB1
        ↓
⚠ 1. Kiểm luật DATABASE của DB1
   ⚠ khớp → CHO VÀO
        ↓ ⚠ không khớp
⚠ 2. Kiểm luật SERVER
   ⚠ khớp → CHO VÀO
        ↓ ⚠ không khớp
⚠ TỪ CHỐI
Kết hợp thường dùng Nội dung
⚠ Luật server cho dải chung ⚠ văn phòng, VPN công ty
⚠ Luật database cho khách riêng ⚠ mở rộng thêm cho từng DB
⚠ Kết quả ⚠ quản lý tập trung mà vẫn linh hoạt

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

  • A (phải chọn một trong hai) — ⚠ SAI: ⚠ dùng được cả hai.

  • B (IP trong luật database cũng phải có trong luật server) — ⚠ SAI: ⚠ luật database ⚠ độc lập và ⚠ mở rộng được vượt phạm vi luật server — ⚠ chính là tình huống của #19499.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ HOÀN CHỈNH chùm năm câu về tường lửa Azure SQL qua ba lô.

Câu Hỏi gì Khoá
⚠ #19499 ⚠ luật DB rộng hơn server ⚠ Yes — khớp ở bước một
⚠ #19550 ⚠ luật DB hẹp hơn server ⚠ Yes — rơi xuống luật server
⚠ #19531 ⚠ cách ly hai nhóm khách ⚠ cấp database
⚠ #19571 ⚠ hai DB dùng chung nhóm khách ⚠ cấp server
⚠ #19635 (câu này) ⚠ dùng được cả hai không ⚠ CÓ
⚠ Năm câu ⚠ vẽ trọn vẹn cơ chế tường lửa, không câu nào mâu thuẫn

⚠ Bốn quy tắc tổng kết: | Quy tắc | Nội dung | |---|---| | ⚠ 1. Dùng được cả hai cấp | ⚠ câu này | | ⚠ 2. Luật database xét TRƯỚC | | | ⚠ 3. Khớp bất kỳ cái nào là cho vào | | | ⚠ 4. Luật database MỞ RỘNG, không thu hẹp | ⚠ hệ quả quan trọng nhất |

Từ khoá nhận diện:

"dùng cả hai" → ⚠ được "cách ly" → ⚠ chỉ dùng luật database, BỎ luật server rộng "dùng chung" → ⚠ luật server "chặn hẳn Internet" → ⚠ private endpoint

⚠ Chiến lược khuyến nghị Chiến lược
⚠ Ưu tiên luật cấp DATABASE ⚠ phạm vi hẹp hơn
⚠ Luật server chỉ cho dải quản trị
⚠ Với môi trường thật: private endpoint
⚠ Rà soát định kỳ, xoá luật IP không còn dùng
⚠ Luật database đi theo database Điểm hay
⚠ Lưu TRONG chính database
⚠ Sao chép hoặc khôi phục database thì luật đi theo
⚠ Luật server thì không
⚠ Hữu ích khi ⚠ di chuyển database sang server khác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật server có đang quá rộng không | | | Có cần cách ly giữa các database không | | | Còn luật IP nào của người đã nghỉ không | |

Và điều quan trọng nhất rút ra từ cả chùm năm câu hỏi về tường lửa Azure SQL: luật cấp database chỉ mở thêm cửa, không đóng bớt cửa nào. Muốn cách ly thật sự thì phải siết ở tầng server trước tiên.

Câu 146 SQL Query
Which type of SQL query language is used to creating and modifying the structure of a database?
  1. A DQL
  2. B DCL
  3. C DML
  4. D DDL
Xem giải thích

Đáp án

D — DDL (Data Definition Language).

Vì sao đúng

⚠ DDL là nhóm câu lệnh tạo và sửa CẤU TRÚC: | Câu lệnh | Việc | |---|---| | ⚠ CREATE | ⚠ tạo database, bảng, view, chỉ mục | | ⚠ ALTER | ⚠ sửa cấu trúc | | ⚠ DROP | ⚠ xoá đối tượng | | ⚠ TRUNCATE | ⚠ xoá sạch dữ liệu, giữ bảng |

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

  • C (DML) — ⚠ thao tác trên DỮ LIỆU, không phải cấu trúc.

  • B (DCL) — ⚠ cấp và thu QUYỀN.

  • A (DQL) — ⚠ Data Query Language: ⚠ một số tài liệu tách SELECT thành nhóm riêng; ⚠ dù sao cũng là truy vấn dữ liệu, không phải cấu trúc.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ năm về phân nhóm câu lệnh SQL qua ba lô.

Câu Hỏi gì Khoá
⚠ #19493 ⚠ SELECT thuộc nhóm nào ⚠ DML
⚠ #19529 ⚠ DDL làm gì ⚠ định nghĩa cấu trúc
⚠ #19535 ⚠ ví dụ nào là DML ⚠ SELECT, INSERT, UPDATE
⚠ #19568 ⚠ DML làm gì ⚠ tác động lên thông tin
⚠ #19636 (câu này) ⚠ nhóm nào tạo và sửa cấu trúc ⚠ DDL
⚠ Năm câu ⚠ cùng một bảng bốn nhóm
⚠ Lưu ý ⚠ câu này lần đầu đưa DQL vào phương án

⚠ Bốn (hoặc năm) nhóm câu lệnh SQL: | Nhóm | Tên | Câu lệnh | |---|---|---| | ⚠ DDL | ⚠ Definition | ⚠ CREATE, ALTER, DROP | | ⚠ DML | ⚠ Manipulation | ⚠ INSERT, UPDATE, DELETE | | ⚠ DQL | ⚠ Query | ⚠ SELECT — một số tài liệu tách riêng | | ⚠ DCL | ⚠ Control | ⚠ GRANT, REVOKE | | ⚠ TCL | ⚠ Transaction | ⚠ COMMIT, ROLLBACK |

⚠ Lưu ý về DQL: ⚠ chuẩn ANSI và tài liệu Microsoft xếp ⚠ SELECT vào DML; ⚠ nhưng một số giáo trình tách thành DQL. ⚠ Trong đề thi, ⚠ nếu có cả DML và DQL trong phương án và câu hỏi về SELECT thì cần đọc kỹ ngữ cảnh.

Từ khoá nhận diện:

"tạo, sửa cấu trúc" → ⚠ DDL "thêm, sửa, xoá dữ liệu" → ⚠ DML "đọc dữ liệu" → ⚠ DML (hoặc DQL tuỳ tài liệu) "cấp quyền" → ⚠ DCL

⚠ DDL trên môi trường thật — cảnh báo Cảnh báo
⚠ ALTER TABLE có thể KHOÁ bảng
⚠ DROP không hỏi lại
⚠ Nên chạy trong giao dịch nếu hệ hỗ trợ
⚠ Nên có sao lưu trước khi đổi lược đồ
⚠ Thực hành tốt ⚠ quản lý thay đổi lược đồ bằng migration script trong Git

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lệnh này đụng cấu trúc hay dữ liệu | | | Thay đổi lược đồ có được kiểm soát phiên bản không | | | Có sao lưu trước khi chạy DDL không | |

Và thực hành giúp tránh phần lớn sự cố liên quan tới thay đổi cấu trúc cơ sở dữ liệu: coi mọi thay đổi lược đồ là mã nguồn — viết migration script, đưa vào Git, review trước khi chạy.

Câu 147 SQL Query
Does MySQL, PostgreSQL and SQL Database share the exact same SQL syntax?
  1. A No, even though SQL is a standard, each database has it's own version of that standard that is not 100% the same.
  2. B Yes, SQL is a standard and all Azure managed databases use the same version of SQL.
Xem giải thích

Đáp án

A — Không. Dù SQL là một chuẩn, mỗi hệ cơ sở dữ liệu có phiên bản riêng của chuẩn đó và không giống nhau 100%.

Vì sao đúng

⚠ Mỗi hệ CSDL có PHƯƠNG NGỮ SQL riêng: | Hệ | Phương ngữ | |---|---| | ⚠ SQL Server | ⚠ T-SQL | | ⚠ PostgreSQL | ⚠ PL/pgSQL | | ⚠ MySQL | ⚠ SQL của MySQL | | ⚠ Oracle | ⚠ PL/SQL |

⚠ Giống nhau: SELECT, INSERT, JOIN, WHERE
        ↓ ⚠ nhưng khác ở
⚠ Hàm chuỗi và ngày tháng
⚠ Cú pháp giới hạn số dòng
⚠ Kiểu dữ liệu
⚠ Cú pháp thủ tục
Ví dụ khác biệt Nội dung
⚠ Giới hạn dòng ⚠ TOP (SQL Server) so với LIMIT (MySQL, Postgres)
⚠ Nối chuỗi ⚠ **+ so với `
⚠ Ngày hiện tại ⚠ GETDATE() so với NOW() so với CURRENT_DATE
⚠ Tự tăng ⚠ IDENTITY so với AUTO_INCREMENT so với SERIAL
⚠ Dấu định danh ⚠ [ ] so với so với " "

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

  • B (SQL là chuẩn nên mọi CSDL Azure dùng cùng phiên bản) — ⚠ SAI: ⚠ Azure Database for MySQL và PostgreSQL là ⚠ chính các engine mã nguồn mở đó, giữ nguyên phương ngữ riêng.

Ghi nhớ

⚠ Phần nào của SQL là chuẩn chung: | Chuẩn chung | Khác nhau | |---|---| | ⚠ SELECT, FROM, WHERE | ⚠ hàm chuỗi, ngày tháng | | ⚠ JOIN cơ bản | ⚠ giới hạn số dòng | | ⚠ INSERT, UPDATE, DELETE | ⚠ kiểu dữ liệu | | ⚠ GROUP BY, ORDER BY | ⚠ thủ tục và hàm | | ⚠ Ràng buộc cơ bản | ⚠ cú pháp phân trang |

Từ khoá nhận diện:

"phương ngữ, dialect" → ⚠ mỗi hệ một kiểu "T-SQL" → ⚠ SQL Server "PL/pgSQL" → ⚠ PostgreSQL "chuyển CSDL sang hệ khác" → ⚠ phải sửa truy vấn

⚠ Hệ quả khi di chuyển giữa các hệ Hệ quả
⚠ Truy vấn đơn giản chạy được ngay
⚠ Thủ tục và hàm phải viết lại
⚠ Kiểu dữ liệu phải ánh xạ
⚠ Cú pháp phân trang khác nhau
⚠ Công cụ ⚠ Data Migration Assistant liệt kê chỗ không tương thích
⚠ Ba dịch vụ CSDL mã nguồn mở trên Azure Dịch vụ
⚠ Azure Database for MySQL
⚠ Azure Database for PostgreSQL
⚠ Azure Database for MariaDB ⚠ đã ngừng, kết thúc 9/2025
⚠ Đều là ⚠ engine gốc được quản lý, giữ nguyên phương ngữ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn có dùng hàm đặc thù của hệ nào không | | | Có thủ tục lưu trữ cần viết lại không | | | Đã chạy công cụ đánh giá tương thích chưa | |

Và ngộ nhận phổ biến khiến nhiều dự án di chuyển cơ sở dữ liệu bị chậm tiến độ: cho rằng SQL là chuẩn nên truy vấn chạy đâu cũng được. Phần lõi thì đúng, nhưng mọi thứ hữu ích nhất lại nằm ở phần khác nhau.

Câu 148 Non-relational DB management
What method of provisioning a non-relational database would be best for users that only need to do this one time?
  1. A ARM templates
  2. B PowerShell scripting
  3. C Bicep scripting
  4. D Azure Portal
Xem giải thích

Đáp án

D — Azure Portal.

Vì sao đúng

⚠ Đề nói rõ: chỉ làm MỘT LẦN DUY NHẤT: | Yếu tố | Kết luận | |---|---| | ⚠ Chỉ làm một lần | ⚠ không cần tự động hoá | | ⚠ Không cần lặp lại | ⚠ không cần lưu vào Git | | ⚠ Muốn nhanh và trực quan | ⚠ Portal |

⚠ Viết template hay script
   ⚠ tốn thời gian học và gỡ lỗi
        ↓
⚠ Chỉ để chạy đúng MỘT lần
        ↓
⚠ Không đáng

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

  • A (ARM template) và C (Bicep) — ⚠ đầu tư cho việc LẶP LẠI: ⚠ đáng khi triển khai nhiều môi trường hoặc nhiều lần.

  • B (PowerShell script) — ⚠ cũng để tự động hoá, ⚠ thừa cho một lần.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ hoàn chỉnh bộ ba về cách cấp phát qua hai lô.

Câu Tình huống Khoá
⚠ #19513 ⚠ viết script chạy từ dòng lệnh ⚠ PowerShell / CLI
⚠ #19630 ⚠ tệp JSON đưa vào quản lý mã ⚠ ARM template
⚠ #19638 (câu này) ⚠ chỉ làm một lần ⚠ Portal
⚠ Ba câu ⚠ cùng bộ phương án, ba tình huống, ba khoá khác nhau
⚠ Bài học ⚠ chọn công cụ theo SỐ LẦN sẽ làm, không theo mức độ hiện đại

⚠ Chọn cách cấp phát theo tình huống: | Tình huống | Chọn | |---|---| | ⚠ Một lần, khám phá, học | ⚠ Portal | | ⚠ Tác vụ vận hành lặp lại | ⚠ CLI hoặc PowerShell | | ⚠ Triển khai nhiều môi trường | ⚠ Bicep hoặc ARM | | ⚠ Nhúng trong ứng dụng | ⚠ SDK |

Từ khoá nhận diện:

"một lần duy nhất" → ⚠ Portal "script tự động hoá" → ⚠ CLI, PowerShell "Infrastructure as Code" → ⚠ ARM, Bicep "nhiều môi trường giống nhau" → ⚠ template

⚠ Mẹo hữu ích của Portal Mẹo
⚠ Nút "Download a template for automation"
⚠ Xuất ARM template của thứ bạn vừa tạo
⚠ Dùng làm điểm khởi đầu cho template
⚠ Kết hợp tốt ⚠ thử trên Portal, xuất template, chỉnh rồi đưa vào Git
⚠ Nhược điểm của Portal Nhược điểm
⚠ Không lặp lại chính xác được
⚠ Không có lịch sử ai đổi gì ⚠ ngoài Activity Log
⚠ Dễ sai sót khi nhiều bước
⚠ Không review được trước khi chạy
⚠ Vì vậy ⚠ chỉ nên dùng cho việc thật sự làm một lần

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Việc này sẽ làm bao nhiêu lần | ⚠ câu hỏi quyết định | | Có cần dựng lại y hệt sau này không | | | Có nên xuất template để dành không | |

Và mẹo tận dụng cả hai cách, hữu ích khi chưa quen với template: tạo tài nguyên trên Portal rồi bấm xuất ARM template. Bạn có được cả tốc độ của giao diện lẫn khả năng lặp lại của mã.

Câu 149 Chọn nhiều đáp án Azure Storage
What feature of Azure Blob Storage would allow recovery of a file that was accidentally deleted? Choose two.
  1. A Blob versioning
  2. B Immutable blobs
  3. C Soft delete
  4. D Change feed
Xem giải thích

Đáp án

A và C — Blob versioning và Soft delete.

Vì sao đúng

⚠ Hai tính năng bổ sung nhau, cùng bảo vệ khỏi mất dữ liệu: | Tính năng | Cứu khi nào | |---|---| | ⚠ Soft delete | ⚠ blob bị XOÁ | | ⚠ Versioning | ⚠ blob bị GHI ĐÈ | | ⚠ Cả hai | ⚠ đều cho phép khôi phục nội dung cũ |

⚠ Xoá blob
        ↓ ⚠ soft delete bật
⚠ Chuyển sang trạng thái "đã xoá mềm"
⚠ Khôi phục được trong thời hạn

⚠ Ghi đè blob
        ↓ ⚠ versioning bật
⚠ Phiên bản CŨ được giữ lại tự động
⚠ Khôi phục về phiên bản bất kỳ

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

  • B (Immutable blobs) — ⚠ NGĂN xoá ngay từ đầu: ⚠ chính sách WORM cho tuân thủ; ⚠ nó ⚠ phòng ngừa chứ không ⚠ khôi phục.

  • D (Change feed) — ⚠ nhật ký thay đổi có thứ tự: ⚠ cho biết ĐÃ có gì thay đổi, ⚠ không khôi phục nội dung.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ mở rộng #19505 ở lô trước.

Câu Hỏi gì Khoá
⚠ #19505 ⚠ tính năng nào khôi phục tệp đã xoá ⚠ Soft delete (chọn 1)
⚠ #19639 (câu này) ⚠ chọn HAI tính năng ⚠ versioning VÀ soft delete
⚠ KHÔNG mâu thuẫn ⚠ câu này cho chọn hai nên thêm versioning
⚠ Bài học ⚠ đọc kỹ "choose two" — nó đổi cả cách trả lời

⚠ Năm tính năng bảo vệ dữ liệu Blob: | Tính năng | Chức năng | |---|---| | ⚠ Soft delete (blob) | ⚠ khôi phục blob đã xoá | | ⚠ Soft delete (container) | ⚠ khôi phục cả container | | ⚠ Versioning | ⚠ giữ mọi phiên bản khi ghi đè | | ⚠ Snapshot | ⚠ ảnh chụp thủ công | | ⚠ Point-in-time restore | ⚠ khôi phục container về mốc thời gian | | ⚠ Immutability | ⚠ CẤM xoá và sửa |

Từ khoá nhận diện:

"khôi phục tệp đã xoá" → ⚠ soft delete "khôi phục nội dung bị ghi đè" → ⚠ versioning "cấm xoá vì tuân thủ" → ⚠ immutable "theo dõi mọi thay đổi" → ⚠ change feed

⚠ Vì sao cần CẢ HAI Lý do
⚠ Xoá và ghi đè là HAI cách mất dữ liệu khác nhau
⚠ Mã độc tống tiền thường GHI ĐÈ, không xoá
⚠ Chỉ soft delete thì không cứu được ca đó
⚠ Bật cả hai ⚠ mới bao phủ đủ
⚠ Cái giá cần cân nhắc Cái giá
⚠ Phiên bản cũ vẫn tính tiền lưu trữ
⚠ Blob ghi đè thường xuyên sẽ sinh rất nhiều phiên bản
⚠ Kiểm soát bằng ⚠ lifecycle policy xoá phiên bản cũ sau N ngày
⚠ Không có policy ⚠ chi phí lưu trữ tăng âm thầm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã bật cả soft delete lẫn versioning chưa | | | Có lifecycle policy dọn phiên bản cũ chưa | | | Thời hạn giữ là bao nhiêu ngày | |

Và lỗ hổng thường gặp trong kế hoạch bảo vệ dữ liệu blob, chỉ lộ ra khi thật sự cần: bật soft delete mà quên versioning. Mã độc tống tiền không xoá tệp của bạn — nó ghi đè lên chúng bằng bản đã mã hoá.

Câu 150 Azure Databricks
Which of the following statements best describes Azure Databricks?
  1. A A relational database
  2. B A machine learning platform
  3. C A data analytics platform optimized for Azure cloud services
  4. D A non-relational data store
Xem giải thích

Đáp án

C — Một nền tảng PHÂN TÍCH DỮ LIỆU được tối ưu cho các dịch vụ đám mây Azure.

Vì sao đúng

⚠ Databricks là nền tảng phân tích, không phải một loại cơ sở dữ liệu: | Databricks là | Nội dung | |---|---| | ⚠ Nền tảng phân tích dựa trên Spark | | | ⚠ Tối ưu riêng cho Azure | ⚠ hợp tác giữa Microsoft và Databricks | | ⚠ Tích hợp Entra ID, Data Lake, Synapse | | | ⚠ Bao gồm cả năng lực ML | |

⚠ Databricks KHÔNG phải nơi LƯU dữ liệu
   ⚠ dữ liệu nằm ở Data Lake
        ↓
⚠ Databricks là nơi XỬ LÝ và PHÂN TÍCH

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

  • B (nền tảng học máy) — ⚠ gần đúng nhưng THU HẸP quá mức: ⚠ ML là ⚠ một phần; ⚠ Databricks còn làm ETL, phân tích, kho dữ liệu.

  • A (cơ sở dữ liệu quan hệ) và D (kho phi quan hệ) — ⚠ SAI về bản chất: ⚠ Databricks là nền tảng ⚠ TÍNH TOÁN, không phải kho lưu trữ.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ ba về Databricks qua hai lô.

Câu Hỏi gì Khoá
⚠ #19601 ⚠ dịch vụ có môi trường ML đầu-cuối ⚠ Databricks
⚠ #19612 ⚠ không gian cộng tác trên cụm Spark ⚠ Databricks
⚠ #19640 (câu này) ⚠ mô tả nào đúng về Databricks ⚠ nền tảng phân tích dữ liệu
⚠ Ba câu ⚠ cùng một dịch vụ, ba góc mô tả
⚠ Lưu ý ⚠ phương án "nền tảng học máy" ở câu này là bẫy vì nó ĐÚNG MỘT PHẦN

⚠ Phân biệt kho LƯU TRỮ và nền tảng TÍNH TOÁN: | Lưu trữ | Tính toán | |---|---| | ⚠ Data Lake Gen2 | ⚠ Databricks | | ⚠ Blob Storage | ⚠ Synapse Spark pool | | ⚠ Azure SQL | ⚠ Azure ML | | ⚠ Cosmos DB | ⚠ Stream Analytics | | ⚠ Đặc điểm hiện đại | ⚠ TÁCH RỜI lưu trữ và tính toán |

Từ khoá nhận diện:

"nền tảng phân tích, Spark" → ⚠ Databricks "nơi lưu dữ liệu" → ⚠ Data Lake, Blob "chỉ học máy" → ⚠ Azure ML "kho dữ liệu SQL" → ⚠ Synapse dedicated pool

⚠ Vì sao tách lưu trữ và tính toán quan trọng Lý do
⚠ Co giãn ĐỘC LẬP hai bên
⚠ Tắt tính toán khi không dùng, dữ liệu vẫn còn
⚠ Nhiều công cụ cùng đọc một kho
⚠ Chi phí lưu trữ rẻ, chỉ trả tính toán khi chạy
⚠ Đây là ⚠ khác biệt lớn nhất so với kho dữ liệu truyền thống
⚠ Databricks trên Azure có gì riêng Riêng
⚠ Tích hợp Entra ID và RBAC
⚠ Kết nối trực tiếp Data Lake Gen2
⚠ Xuất hiện như tài nguyên Azure, chung hoá đơn
⚠ Kết nối được VNet
⚠ Đó là ý nghĩa của ⚠ "tối ưu cho Azure" trong đáp án

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đây là kho lưu trữ hay nền tảng tính toán | | | Dữ liệu nằm ở đâu khi cụm tắt | | | Cụm có tự tắt khi rảnh không | |

Và đặc điểm kiến trúc quan trọng nhất của nền tảng dữ liệu hiện đại, thể hiện rõ ở Databricks: lưu trữ và tính toán tách rời nhau. Bạn tắt hết cụm đi mà dữ liệu vẫn nguyên vẹn, và hoá đơn tính toán về gần bằng không.