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

Đáp án

D — Premium, Transaction Optimized, Hot, Cool.

Vì sao đúng

⚠ Azure Files có bốn bậc, chia làm hai nhóm phần cứng: | Bậc | Phần cứng | Đặc điểm | |---|---|---| | ⚠ Premium | ⚠ SSD | ⚠ độ trễ thấp nhất, trả theo dung lượng CẤP | | ⚠ Transaction Optimized | ⚠ HDD | ⚠ phí thao tác thấp nhất trong nhóm HDD | | ⚠ Hot | ⚠ HDD | ⚠ cân bằng | | ⚠ Cool | ⚠ HDD | ⚠ lưu rẻ nhất, thao tác đắt nhất |

⚠ Trong nhóm HDD
   ⚠ Transaction Optimized → Hot → Cool
        ↓
⚠ Giá LƯU tăng dần theo chiều ngược
⚠ Giá THAO TÁC giảm dần theo chiều ngược

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

• C (Premium, Hot, Cold, Glacier) — ⚠ Glacier là dịch vụ của AWS, không phải Azure.

• B (Basic, Standard, Premium, Isolated) — ⚠ là các bậc của App Service Plan.

• A (S1, S2, S3, S4) — ⚠ là ký hiệu bậc của một số dịch vụ khác, không phải Files.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ hoàn chỉnh chủ đề Azure Files cùng #19498, #19593, #19599.

⚠ Cẩn thận với tên bậc của các dịch vụ khác nhau: | Dịch vụ | Bậc | |---|---| | ⚠ Azure Files | ⚠ Premium, Transaction Optimized, Hot, Cool | | ⚠ Blob Storage | ⚠ Premium, Hot, Cool, Cold, Archive | | ⚠ App Service | ⚠ Free, Shared, Basic, Standard, Premium, Isolated | | ⚠ Redis | ⚠ Basic, Standard, Premium, Enterprise | | ⚠ Rất dễ nhầm | ⚠ đề thường trộn bậc của dịch vụ này vào câu hỏi về dịch vụ kia |

Từ khoá nhận diện:

"Transaction Optimized" → ⚠ CHỈ có ở Azure Files "Archive" → ⚠ CHỈ có ở Blob "Isolated" → ⚠ App Service "Glacier" → ⚠ AWS, không phải Azure

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Số thao tác so với dung lượng là bao nhiêu | ⚠ quyết định bậc HDD | | Có cần độ trễ SSD không | | | Đang nhầm bậc của dịch vụ nào không | |

Và cái bẫy hay gặp ở nhóm câu hỏi về bậc dịch vụ: đề trộn tên bậc của một dịch vụ khác vào danh sách phương án. Nhận ra "Glacier là của AWS" hay "Isolated là của App Service" loại được ngay một nửa.

Đáp án

D — Azure Data Lake Storage.

Vì sao đúng

⚠ Đề mô tả đúng vai trò của data lake trong kiến trúc kho dữ liệu: | Yêu cầu đề nêu | Data Lake | |---|---| | ⚠ Khối lượng lớn dữ liệu THÔ, chưa xử lý | ⚠ nhận mọi định dạng | | ⚠ Tốc độ rất nhanh | ⚠ ghi song song, thông lượng cao | | ⚠ Nơi kho dữ liệu chứa dữ liệu thô trước khi nạp | ⚠ đúng vai trò staging |

⚠ Nguồn đa dạng
        ↓
⚠ DATA LAKE (thô, giữ nguyên trạng)
        ↓ ⚠ biến đổi
⚠ Kho dữ liệu (đã chuẩn hoá)
        ↓
⚠ Báo cáo và phân tích

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

• A (Azure SQL Database) — ⚠ đòi schema TRƯỚC khi ghi; ⚠ dữ liệu thô đa dạng không nạp thẳng vào được.

• B (Table Storage) — ⚠ kho khoá-giá trị, ⚠ giới hạn 1MB mỗi thực thể.

• C (Queue Storage) — ⚠ hàng đợi TIN NHẮN, ⚠ không phải kho lưu trữ.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ gần trùng #19616 trong cùng lô.

⚠ Vì sao data lake giữ dữ liệu THÔ: | Lý do | Nội dung | |---|---| | ⚠ Chưa biết sẽ dùng để làm gì | ⚠ schema-on-read | | ⚠ Lưu trữ rẻ nên giữ được | | | ⚠ Xử lý lại được khi phát hiện logic sai | ⚠ giá trị lớn nhất | | ⚠ Nhiều đội dùng cùng nguồn theo cách khác nhau | | | ⚠ Ngược với kho dữ liệu | ⚠ nơi schema phải định nghĩa TRƯỚC |

Từ khoá nhận diện:

"dữ liệu thô, chưa xử lý, khối lượng lớn" → ⚠ Data Lake "đã chuẩn hoá, sẵn sàng báo cáo" → ⚠ kho dữ liệu "hàng đợi tin nhắn" → ⚠ Queue Storage "schema định nghĩa trước" → ⚠ CSDL quan hệ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có quy ước tổ chức thư mục chưa | | | Có danh mục mô tả dữ liệu chưa | | | Dữ liệu thô có được giữ lại để xử lý lại không | |

Và ranh giới giữa một data lake hữu ích và một đầm lầy dữ liệu, không nằm ở công nghệ mà ở kỷ luật: có ai mô tả được trong đó đang có gì và dữ liệu nào tin được không.

Đáp án

C — SELECT * FROM Employees;

Vì sao đúng

⚠ Cú pháp SELECT cơ bản:

⚠ SELECT <danh sách cột>
⚠ FROM   <bảng>
⚠ [WHERE <điều kiện>]
        ↓
⚠ SELECT *        → MỌI cột
⚠ FROM Employees  → từ bảng Employees
⚠ không có WHERE  → MỌI dòng

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

• A (SELECT Employees WHERE Location = 'Idaho';) — ⚠ sai cú pháp (⚠ thiếu FROM) ⚠ và ⚠ có WHERE nên chỉ lấy một phần dòng.

• B (SELECT TABLE Employees;) — ⚠ không có cú pháp này trong SQL.

• D (SELECT VIEW Employees;) — ⚠ cũng không tồn tại.

Ghi nhớ

⚠ Thứ tự viết và thứ tự THỰC THI của SELECT: | Thứ tự VIẾT | Thứ tự THỰC THI | |---|---| | ⚠ SELECT | ⚠ 5. SELECT | | ⚠ FROM | ⚠ 1. FROM và JOIN | | ⚠ WHERE | ⚠ 2. WHERE | | ⚠ GROUP BY | ⚠ 3. GROUP BY | | ⚠ HAVING | ⚠ 4. HAVING | | ⚠ ORDER BY | ⚠ 6. ORDER BY | | ⚠ Giải thích | ⚠ vì sao không dùng được bí danh cột trong WHERE |

Từ khoá nhận diện:

"tất cả cột và tất cả dòng" → ⚠ SELECT * FROM bảng "lọc dòng" → ⚠ WHERE "lọc sau khi gom nhóm" → ⚠ HAVING "sắp xếp" → ⚠ ORDER BY

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn có dùng SELECT * trong mã sản phẩm không | | | Điều kiện nên ở WHERE hay HAVING | | | Có thiếu FROM không | |

Và thói quen nhỏ nên hình thành từ sớm khi viết SQL: liệt kê rõ các cột cần thay vì dùng dấu sao. Nó làm truy vấn nhanh hơn, ổn định hơn khi lược đồ thay đổi, và tự nói rõ ý định của người viết.

Đáp án

D — Batching.

Vì sao đúng

⚠ Batching đúng nghĩa là xử lý dữ liệu THEO NHÓM:

⚠ Gom dữ liệu lại thành khối
        ↓ ⚠ đủ điều kiện (đủ số lượng, tới giờ)
⚠ Xử lý CẢ KHỐI một lần
        ↓
⚠ Hiệu quả hơn xử lý từng cái

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

• C (Streaming) — ⚠ NGƯỢC: ⚠ xử lý từng bản ghi khi nó tới.

• B (Buffering) — ⚠ là kỹ thuật ĐỆM tạm, một chi tiết kỹ thuật.

• A (Templating) — ⚠ không liên quan tới xử lý dữ liệu.

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 #19627 trong cùng lô.

⚠ Bảng thuật ngữ — chốt lại lần cuối: | Thuật ngữ | Nghĩa | |---|---| | ⚠ Batching | ⚠ xử lý theo NHÓM | | ⚠ Streaming | ⚠ xử lý KHI TỚI | | ⚠ Buffering | ⚠ đệm tạm | | ⚠ Micro-batching | ⚠ lô rất nhỏ, gần thời gian thực | | ⚠ Windowing | ⚠ cắt dòng thành cửa sổ |

Từ khoá nhận diện:

"theo nhóm, theo khối" → ⚠ batching "khi dữ liệu tới" → ⚠ streaming "đệm tạm" → ⚠ buffering "mỗi đêm, cuối tháng" → ⚠ batching

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu được gom lại hay xử lý ngay | | | Kích thước lô là bao nhiêu | ⚠ quá lớn thì tốn bộ nhớ, quá nhỏ thì mất hiệu quả | | Có cần độ trễ thấp không | |

Và tối ưu đơn giản nhất cho mọi quy trình ghi dữ liệu, áp dụng được kể cả trong hệ thống thời gian thực: gom nhiều bản ghi lại rồi ghi một lần. Chi phí cố định của mỗi lần ghi thường lớn hơn nhiều so với chính dữ liệu.

Đáp án

A — Chi phí đầu tư ban đầu (capital expenditure) THẤP NHẤT.

Vì sao đúng

⚠ PaaS xoá bỏ hoàn toàn khoản đầu tư hạ tầng ban đầu: | Mô hình | Chi phí ban đầu | |---|---| | ⚠ Tại chỗ | ⚠ mua máy chủ, giấy phép, phòng máy — CAO NHẤT | | ⚠ IaaS | ⚠ không mua máy nhưng phải dựng và cấu hình | | ⚠ PaaS | ⚠ tạo dịch vụ trong vài phút — THẤP NHẤT |

⚠ CapEx (đầu tư)  →  OpEx (vận hành)
   ⚠ mua trước, khấu hao
        ↓
⚠ Trả theo tháng, theo mức dùng
        ↓
⚠ Bắt đầu nhỏ, mở rộng khi cần

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

• D (chi phí vận hành mỗi ngày rẻ nhất) — ⚠ KHÔNG chắc chắn: ⚠ với tải lớn và ổn định, ⚠ chi phí vận hành PaaS có thể ⚠ cao hơn máy chủ tại chỗ đã khấu hao xong.

• B (giữ kiểm soát dữ liệu trong môi trường doanh nghiệp) — ⚠ là ưu điểm của TẠI CHỖ.

• C (tối đa hoá kiểm soát cấu hình phần cứng) — ⚠ là ưu điểm của tại chỗ hoặc IaaS; ⚠ PaaS ⚠ giấu hết phần cứng đi.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án D ⚠ đáng bàn thêm.

⚠ CapEx và OpEx — khái niệm nền: | Khái niệm | Nội dung | |---|---| | ⚠ CapEx | ⚠ chi ĐẦU TƯ: mua tài sản, khấu hao nhiều năm | | ⚠ OpEx | ⚠ chi VẬN HÀNH: trả đều theo kỳ | | ⚠ Đám mây | ⚠ chuyển CapEx thành OpEx | | ⚠ Lợi ích tài chính | ⚠ không cần vốn lớn ban đầu, dự đoán được dòng tiền |

Từ khoá nhận diện:

"đầu tư ban đầu thấp" → ⚠ ưu điểm đám mây "kiểm soát dữ liệu tại chỗ" → ⚠ ưu điểm on-premises "kiểm soát phần cứng" → ⚠ on-premises hoặc IaaS "co giãn theo nhu cầu" → ⚠ ưu điểm đám mây

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải là thất thường hay ổn định | ⚠ quyết định đám mây có kinh tế không | | Đã dùng reserved instance chưa | | | Có tài nguyên nào bật mà không dùng không | |

Và điều cần nói rõ khi trình bày lợi ích kinh tế của đám mây, để tránh hứa quá lời: nó chắc chắn giảm chi phí đầu tư ban đầu, nhưng không tự động rẻ hơn về tổng chi phí dài hạn. Điều đó phụ thuộc vào cách bạn sử dụng.

Đáp án

D — Azure Data Studio.

Vì sao đúng

⚠ Đề liệt kê đúng các đặc điểm của Azure Data Studio: | Đặc điểm đề nêu | Azure Data Studio | |---|---| | ⚠ Trình soạn thảo hiện đại | ⚠ xây trên nền VS Code | | ⚠ IntelliSense | ⚠ gợi ý mã | | ⚠ Code snippet | | | ⚠ Tích hợp quản lý mã nguồn | ⚠ Git | | ⚠ Terminal tích hợp | | | ⚠ Thêm nữa | ⚠ notebook, đa nền tảng, tiện ích mở rộng |

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

• A (sqlcmd) — ⚠ công cụ DÒNG LỆNH thuần, không có trình soạn thảo.

• B (Query editor trên Portal) — ⚠ rất đơn giản, không có Git hay terminal.

• C (Visual Studio) — ⚠ IDE phát triển phần mềm; ⚠ có SQL Server Data Tools nhưng không phải công cụ truy vấn được mô tả ở đây.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ công cụ trong khoá ⚠ đã được thông báo NGỪNG.

⚠ Công cụ làm việc với SQL Server và Azure SQL: | Công cụ | Đặc điểm | Trạng thái | |---|---|---| | ⚠ SSMS | ⚠ đầy đủ nhất, chỉ Windows | ⚠ còn | | ⚠ Azure Data Studio | ⚠ nhẹ, đa nền tảng, notebook | ⚠ sẽ ngừng 2/2026 | | ⚠ VS Code + MSSQL extension | ⚠ hướng đi mới | ⚠ được khuyến nghị | | ⚠ sqlcmd, bcp | ⚠ dòng lệnh | ⚠ còn | | ⚠ Query editor trên Portal | ⚠ nhanh, đơn giản | ⚠ còn |

Từ khoá nhận diện:

"trình soạn thảo hiện đại, Git, terminal" → ⚠ Azure Data Studio (nay là VS Code MSSQL) "đầy đủ tính năng quản trị" → ⚠ SSMS "dòng lệnh" → ⚠ sqlcmd "truy vấn nhanh trên trình duyệt" → ⚠ Portal query editor

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Công cụ đang dùng còn được hỗ trợ không | | | Quy trình có phụ thuộc vào một công cụ không | | | Script có chạy được ngoài IDE không | |

Và điều đáng rút ra khi một công cụ quen thuộc bị khai tử: kiến thức về SQL và cơ sở dữ liệu vẫn nguyên giá trị, chỉ có giao diện là thay đổi. Đầu tư vào hiểu biết luôn bền hơn đầu tư vào thao tác trên một phần mềm cụ thể.

Đáp án

B — BLOB (Binary Large Object)

Vì sao đúng

Câu này tìm thứ không phải đối tượng cơ sở dữ liệu. BLOB là một kiểu dữ liệu — kiểu của một cột dùng để chứa dữ liệu nhị phân lớn như ảnh hay tệp. Nó nằm ở tầng khác hẳn với ba phương án còn lại, vốn đều là đối tượng lược đồ mà bạn tạo và quản lý bằng lệnh DDL.

Vì sao các phương án khác sai (chúng là đối tượng cơ sở dữ liệu)

• C. Table — nơi dữ liệu thật sự nằm.
• A. Index — cấu trúc phụ để tăng tốc truy vấn.
• D. View — truy vấn được đặt tên, dùng như một bảng ảo.

Đáp án

B — JSON (JavaScript Object Notation)

Vì sao đúng

JSON biểu diễn được dữ liệu phân cấp: một đối tượng chứa đối tượng khác, một trường chứa cả một mảng. Ba ứng dụng mà đề liệt kê — tệp cấu hình, trao đổi dữ liệu, lưu trữ trong cơ sở dữ liệu NoSQL — đều tận dụng đúng đặc điểm đó.

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

• A. CSV — cấu trúc phẳng hoàn toàn: chỉ có hàng và cột, không lồng nhau được.
• D. Bảng quan hệ — cũng phẳng; quan hệ phân cấp phải biểu diễn gián tiếp qua khoá ngoại và phép nối.
• C. XML — đây là phương án nhiễu gần nhất vì XML cũng phân cấp được. Khác biệt nằm ở chỗ JSON gọn hơn nhiều và đã trở thành định dạng mặc định của cơ sở dữ liệu NoSQL — mà đề nhắc đích danh NoSQL.

Đáp án

B — Azure Machine Learning

Vì sao đúng

Azure Machine Learning là nền tảng phủ toàn bộ vòng đời của một mô hình: chuẩn bị dữ liệu, huấn luyện (kể cả AutoML và huấn luyện phân tán), theo dõi thí nghiệm, đăng ký và quản lý phiên bản mô hình, rồi triển khai thành endpoint và giám sát.

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

• A. Azure AI Services — cung cấp mô hình dựng sẵn qua API (thị giác, ngôn ngữ, giọng nói); bạn dùng chứ không huấn luyện chúng.
• C. Azure Synapse Analytics — nền tảng phân tích dữ liệu; có tích hợp với ML nhưng không phải nơi huấn luyện và triển khai mô hình.
• D. Azure Data Factory — điều phối và di chuyển dữ liệu.

Đáp án

C — Redis API

Vì sao đúng

Cosmos DB hỗ trợ nhiều API để tương thích với các cơ sở dữ liệu phổ biến, nhờ đó ứng dụng đang chạy chuyển sang mà gần như không phải sửa mã: SQL (Core), MongoDB, Cassandra, Gremlin, Table.

Redis không nằm trong đó, và lý do có tính bản chất: Redis là kho dữ liệu trong bộ nhớ dùng làm bộ nhớ đệm, còn Cosmos DB là cơ sở dữ liệu lưu trữ bền vững. Hai thứ giải hai bài toán khác nhau — đó là lý do Azure có dịch vụ riêng Azure Cache for Redis.

Vì sao các phương án khác sai (chúng đều được hỗ trợ)

• A. SQL API — API gốc của Cosmos DB.
• B. Cassandra API và D. MongoDB API — hai API tương thích cho việc chuyển ứng dụng sang.