Ngân hàng đề — Microsoft Azure Data Fundamentals
Tìm thấy 328 câu.
- A Azure Analysis Services
- B Synapse Analytics (formerly SQL Data Warehouse)
- C SQL Query Analyzer
- D Power BI
Xem giải thích
Đáp án
D — Power BI.
Vì sao đúng
⚠ Power BI là bộ công cụ phân tích nghiệp vụ hoàn chỉnh: | Thành phần | Vai trò | |---|---| | ⚠ Power BI Desktop | ⚠ tạo mô hình và báo cáo — miễn phí | | ⚠ Power BI Service | ⚠ chia sẻ, dashboard, lịch làm mới | | ⚠ Power BI Mobile | ⚠ xem trên điện thoại | | ⚠ Report Builder | ⚠ báo cáo phân trang | | ⚠ Power Query | ⚠ kết nối và biến đổi dữ liệu | | ⚠ DAX | ⚠ ngôn ngữ tính toán |
Vì sao các phương án khác sai
-
B (Synapse Analytics) — ⚠ là kho DỮ LIỆU và nền tảng phân tích, ⚠ không phải công cụ trực quan hoá cho nhà phân tích.
-
A (Azure Analysis Services) — ⚠ là tầng MÔ HÌNH ngữ nghĩa dạng bảng, ⚠ Power BI kết nối vào nó chứ nó không tạo dashboard.
-
C (SQL Query Analyzer) — ⚠ công cụ CŨ của SQL Server để chạy truy vấn, ⚠ nay đã được thay bằng SSMS.
Ghi nhớ
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là câu thứ tư về Power BI qua hai lô.
| Câu | Hỏi gì | Khoá |
|---|---|---|
| ⚠ #19491 | ⚠ báo cáo cho phép lọc và drill-through | ⚠ Interactive report |
| ⚠ #19522 | ⚠ hàng nghìn dòng để in | ⚠ Paginated report |
| ⚠ #19543 | ⚠ dashboard để làm gì | ⚠ tổng quan một trang |
| ⚠ #19561 (câu này) | ⚠ sản phẩm nào là bộ công cụ phân tích | ⚠ Power BI |
| ⚠ Bốn câu | ⚠ vẽ trọn hệ sinh thái Power BI |
⚠ Vị trí Power BI trong luồng dữ liệu: | Tầng | Dịch vụ | |---|---| | ⚠ Nguồn | ⚠ SQL, Cosmos, Excel, API | | ⚠ Nạp và biến đổi | ⚠ Data Factory, Power Query | | ⚠ Lưu và tính toán | ⚠ Synapse, Data Lake, Fabric | | ⚠ Mô hình ngữ nghĩa | ⚠ Analysis Services, mô hình Power BI | | ⚠ Trình bày | ⚠ Power BI |
Từ khoá nhận diện:
"dashboard đẹp, báo cáo cho nhà phân tích" → ⚠ Power BI "kho dữ liệu quy mô lớn" → ⚠ Synapse "mô hình ngữ nghĩa dùng chung" → ⚠ Analysis Services "nền tảng gộp tất cả" → ⚠ Microsoft Fabric
| ⚠ Ba chế độ kết nối dữ liệu | Chế độ |
|---|---|
| ⚠ Import | ⚠ nạp vào mô hình — nhanh nhất, cần lịch làm mới |
| ⚠ DirectQuery | ⚠ truy vấn thẳng nguồn — luôn mới, chậm hơn |
| ⚠ Composite | ⚠ kết hợp cả hai |
| ⚠ Chọn sai | ⚠ báo cáo chậm hoặc dữ liệu cũ |
| ⚠ Giấy phép — điều hay bị vướng | Giấy phép |
|---|---|
| ⚠ Desktop miễn phí | |
| ⚠ Chia sẻ báo cáo cần Pro | |
| ⚠ Paginated report cần Premium hoặc PPU | |
| ⚠ Dung lượng lớn, làm mới nhiều cần Premium | |
| ⚠ Lập kế hoạch | ⚠ tính giấy phép TRƯỚC khi hứa với người dùng |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu cần mới tới mức nào | ⚠ Import hay DirectQuery | | Bao nhiêu người sẽ xem báo cáo | ⚠ ảnh hưởng giấy phép | | Có cần báo cáo in ấn không | ⚠ cần Premium |
Và quyết định kỹ thuật ảnh hưởng lớn nhất tới trải nghiệm người dùng Power BI: chọn Import hay DirectQuery. Import cho báo cáo nhanh nhưng dữ liệu chỉ mới tới lần làm mới gần nhất; DirectQuery luôn mới nhưng mỗi thao tác lọc là một truy vấn gửi xuống nguồn.
- A 3
- B 1
- C 2
- D 6
Xem giải thích
Đáp án
D — 6 bản sao.
Vì sao đúng
⚠ GRS nhân bản ba bản ở vùng chính và ba bản ở vùng ghép đôi:
⚠ Vùng CHÍNH
⚠ 3 bản sao (như LRS)
↓ ⚠ nhân bản BẤT ĐỒNG BỘ
⚠ Vùng PHỤ (paired region)
⚠ 3 bản sao
↓
⚠ Tổng: 6 bản
| Mức | Số bản | Chịu được |
|---|---|---|
| ⚠ LRS | ⚠ 3 | ⚠ hỏng ổ, hỏng rack |
| ⚠ ZRS | ⚠ 3 | ⚠ mất một zone |
| ⚠ GRS | ⚠ 6 | ⚠ mất cả VÙNG |
| ⚠ GZRS | ⚠ 6 | ⚠ mất zone VÀ mất vùng |
Vì sao các phương án khác sai
-
A (3) — ⚠ đó là LRS hoặc ZRS.
-
C (2) và B (1) — ⚠ không có mức nào của Azure Storage giữ ít hơn ba bản.
Ghi nhớ
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp trực tiếp với #19512 ở lô trước.
| Câu | Mức | Khoá |
|---|---|---|
| ⚠ #19512 | ⚠ ZRS | ⚠ 3 bản, ba zone |
| ⚠ #19562 (câu này) | ⚠ GRS | ⚠ 6 bản, hai vùng |
| ⚠ Cặp bổ sung | ⚠ cùng dạng câu hỏi, hai mức khác nhau | |
| ⚠ Mẹo nhớ | ⚠ có chữ G (Geo) là 6 bản, không có G là 3 bản |
⚠ Bốn mức nhân bản — bảng chốt: | Mức | Bản sao | Phân bố | |---|---|---| | ⚠ LRS | ⚠ 3 | ⚠ một trung tâm dữ liệu | | ⚠ ZRS | ⚠ 3 | ⚠ ba zone, một vùng | | ⚠ GRS | ⚠ 6 | ⚠ 3 + 3 ở hai vùng | | ⚠ GZRS | ⚠ 6 | ⚠ 3 zone + 3 ở vùng phụ | | ⚠ Biến thể RA- | ⚠ cho phép ĐỌC từ vùng phụ |
Từ khoá nhận diện:
"6 bản, hai vùng" → ⚠ GRS hoặc GZRS "3 bản, ba zone" → ⚠ ZRS "3 bản, một chỗ, rẻ nhất" → ⚠ LRS "đọc được ở vùng phụ" → ⚠ RA-GRS
| ⚠ Paired region — khái niệm cần biết | Nội dung |
|---|---|
| ⚠ Mỗi vùng Azure có một vùng GHÉP ĐÔI cố định | |
| ⚠ Do Microsoft định sẵn, thường cùng khu vực địa lý | ⚠ quan trọng cho tuân thủ dữ liệu |
| ⚠ Bạn KHÔNG chọn được vùng phụ | |
| ⚠ Bảo trì có kế hoạch không diễn ra đồng thời ở hai vùng ghép |
| ⚠ Nhân bản BẤT ĐỒNG BỘ — hệ quả | Hệ quả |
|---|---|
| ⚠ Có ĐỘ TRỄ giữa vùng chính và vùng phụ | |
| ⚠ Mất vùng chính có thể mất dữ liệu gần nhất | |
| ⚠ Sau khi failover, tài khoản thành LRS ở vùng mới | |
| ⚠ Nhớ | ⚠ bật lại nhân bản sau khi chuyển đổi |
| ⚠ Nhắc lại: nhân bản KHÔNG phải sao lưu | Nhắc lại |
|---|---|
| ⚠ Xoá nhầm sẽ được nhân bản sang cả 6 bản | |
| ⚠ Vẫn cần | ⚠ soft delete, versioning, sao lưu riêng |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cần chịu mất zone hay mất cả vùng | | | Vùng ghép đôi có nằm trong phạm vi pháp lý cho phép không | | | Đã có soft delete và versioning chưa | |
Và điều cần kiểm tra khi bật GRS cho dữ liệu chịu ràng buộc pháp lý về nơi lưu trữ: vùng ghép đôi do Microsoft định sẵn, bạn không chọn được. Với dữ liệu bắt buộc phải ở trong một quốc gia, đó là chi tiết phải xác nhận trước.
- A A VIEW is a group of one or more Transact-SQL statements.
- B A VIEW is a special type of stored procedure that automatically runs with INSERT, UPDATE or DELETE statements take place.
- C A VIEW is a collection of tables that stores a specific set of structured data.
- D A VIEW is a virtual table whose contents are defined by a query.
Xem giải thích
Đáp án
D — VIEW là một BẢNG ẢO mà nội dung được định nghĩa bằng một câu truy vấn.
Vì sao đúng
⚠ View không lưu dữ liệu, nó lưu CÂU TRUY VẤN:
⚠ CREATE VIEW v_DonHangGanDay AS
⚠ SELECT dh.id, kh.ten, dh.tongTien
⚠ FROM DonHang dh JOIN KhachHang kh ON ...
⚠ WHERE dh.ngay >= DATEADD(day,-30,GETDATE())
↓
⚠ SELECT * FROM v_DonHangGanDay
↓
⚠ SQL Server chạy lại truy vấn gốc
| Lợi ích của view | Nội dung |
|---|---|
| ⚠ Giấu độ phức tạp | ⚠ người dùng không cần biết JOIN |
| ⚠ Kiểm soát truy cập | ⚠ cấp quyền trên view thay vì bảng gốc |
| ⚠ Giao diện ổn định | ⚠ đổi bảng gốc mà không phá ứng dụng |
| ⚠ Tái dùng logic |
Vì sao các phương án khác sai
-
B (thủ tục đặc biệt tự chạy khi INSERT/UPDATE/DELETE) — ⚠ đó là TRIGGER.
-
A (nhóm một hoặc nhiều câu lệnh T-SQL) — ⚠ đó là STORED PROCEDURE.
-
C (tập hợp các bảng lưu dữ liệu có cấu trúc) — ⚠ đó là mô tả của DATABASE hoặc SCHEMA.
Ghi nhớ
⚠ Bốn đối tượng CSDL hay bị hỏi lẫn: | Đối tượng | Là gì | |---|---| | ⚠ Table | ⚠ nơi LƯU dữ liệu thật | | ⚠ View | ⚠ truy vấn được đặt tên, không lưu dữ liệu | | ⚠ Stored procedure | ⚠ nhóm câu lệnh, gọi bằng EXEC | | ⚠ Trigger | ⚠ TỰ chạy khi có thao tác dữ liệu | | ⚠ Function | ⚠ trả về giá trị, dùng được trong SELECT |
Từ khoá nhận diện:
"bảng ảo, định nghĩa bằng truy vấn" → ⚠ view "tự động chạy khi có INSERT" → ⚠ trigger "gọi bằng EXEC, có tham số" → ⚠ stored procedure "view có lưu dữ liệu" → ⚠ chỉ khi là indexed view
| ⚠ Indexed view — ngoại lệ đáng nhớ | Nội dung |
|---|---|
| ⚠ View thường KHÔNG lưu dữ liệu | |
| ⚠ Indexed view (materialized) CÓ lưu kết quả | |
| ⚠ Cập nhật tự động khi bảng gốc đổi | |
| ⚠ Đổi lại | ⚠ làm chậm thao tác ghi lên bảng gốc |
| ⚠ Có ràng buộc | ⚠ nhiều điều kiện phải thoả mới tạo được |
| ⚠ View dùng cho bảo mật | Cách |
|---|---|
| ⚠ Cấp quyền SELECT trên view, KHÔNG cấp trên bảng gốc | |
| ⚠ View chỉ chứa cột và dòng người dùng được xem | |
| ⚠ Cách hiện đại hơn | ⚠ row-level security và column-level permission |
| ⚠ Cảnh báo hiệu năng | Cảnh báo |
|---|---|
| ⚠ View lồng view lồng view | ⚠ rất khó tối ưu |
| ⚠ Bộ tối ưu phải mở rộng hết mọi tầng | |
| ⚠ Nên | ⚠ giữ độ lồng nhau ở mức tối thiểu |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | View có bị lồng nhiều tầng không | | | Có nên dùng RLS thay cho view bảo mật không | | | Truy vấn qua view có chậm hơn truy vấn thẳng không | |
Và điều dễ quên nhất về view, khiến người ta ngạc nhiên khi truy vấn chậm: nó không lưu sẵn kết quả nào cả. Mỗi lần bạn gọi view là một lần truy vấn gốc chạy lại từ đầu.
- A Encrypt the database
- B Resource Tokens
- C Network Security Group (NSG)
- D Access Key and Endpoint
Xem giải thích
Đáp án
B — Resource Token.
Vì sao đúng
⚠ Resource token là cơ chế cấp quyền HẸP và CÓ HẠN cho Cosmos DB:
⚠ Dịch vụ trung gian của bạn
⚠ giữ khoá tài khoản (không lộ ra ngoài)
↓ ⚠ xác thực người dùng
⚠ Tạo user và permission trong Cosmos DB
↓
⚠ Cấp RESOURCE TOKEN
⚠ chỉ đọc
⚠ chỉ container hoặc partition cụ thể
⚠ có thời hạn (mặc định 1 giờ)
↓
⚠ Client dùng token đó
| So sánh | Nội dung |
|---|---|
| ⚠ Khoá chính | ⚠ quyền TOÀN PHẦN — không bao giờ đưa ra client |
| ⚠ Khoá chỉ đọc | ⚠ đọc TOÀN BỘ tài khoản |
| ⚠ Resource token | ⚠ hẹp tới từng tài nguyên, có hạn |
Vì sao các phương án khác sai
-
D (access key và endpoint) — ⚠ bẫy gần đúng: ⚠ có khoá chỉ đọc thật, ⚠ nhưng nó cho đọc ⚠ toàn bộ tài khoản, ⚠ không giới hạn được tới một người hay một phần dữ liệu.
-
C (Network Security Group) — ⚠ kiểm soát MẠNG, không phải quyền dữ liệu.
-
A (mã hoá cơ sở dữ liệu) — ⚠ không liên quan tới phân quyền.
Ghi nhớ
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #19559 ở lô trước về mô hình bảo mật mặc định của Cosmos DB.
| Câu | Hỏi gì | Khoá |
|---|---|---|
| ⚠ #19559 | ⚠ mô hình bảo mật mặc định | ⚠ authorization token |
| ⚠ #19564 (câu này) | ⚠ cách giới hạn quyền chỉ đọc | ⚠ resource token |
| ⚠ Bổ sung nhau | ⚠ một hỏi cơ chế chung, một hỏi cách phân quyền hẹp |
⚠ Ba cấp phân quyền Cosmos DB: | Cấp | Phạm vi | |---|---| | ⚠ Master key | ⚠ toàn quyền tài khoản | | ⚠ Read-only key | ⚠ đọc toàn tài khoản | | ⚠ Resource token | ⚠ một user, một tài nguyên, có hạn | | ⚠ Entra ID + RBAC | ⚠ khuyến nghị hiện nay |
Từ khoá nhận diện:
"chỉ đọc một phần, cho người dùng cuối" → ⚠ resource token "ứng dụng backend truy cập" → ⚠ managed identity + RBAC "toàn quyền" → ⚠ master key, đừng đưa ra ngoài
| ⚠ Kiến trúc token broker | Kiến trúc |
|---|---|
| ⚠ Ứng dụng di động KHÔNG giữ khoá | |
| ⚠ Gọi API trung gian để xin token | |
| ⚠ API xác thực người dùng rồi cấp token hẹp | |
| ⚠ Token hết hạn thì xin lại | |
| ⚠ Ưu điểm | ⚠ khoá không bao giờ rời khỏi máy chủ của bạn |
| ⚠ Vì sao không nhúng khoá vào ứng dụng client | Lý do |
|---|---|
| ⚠ Ứng dụng di động và web đều dịch ngược được | |
| ⚠ Khoá trong mã nguồn là khoá đã bị lộ | |
| ⚠ Áp dụng cho | ⚠ mọi loại khoá, không riêng Cosmos DB |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có khoá nào đang nằm trong mã client không | | | Token cấp cho người dùng có thời hạn bao lâu | | | Có thể chuyển hẳn sang Entra ID không | |
Và nguyên tắc bất di bất dịch khi thiết kế ứng dụng client truy cập dữ liệu: khoá toàn quyền không bao giờ được rời khỏi máy chủ của bạn. Mọi thứ gửi tới thiết bị người dùng đều phải coi như đã công khai.
- A Tables are database objects that contain all the data in a database.
- B Tables are collections of key-value pairs.
- C Data can be stored directly into a relational database, and the use of tables are optional.
- D Tables are a collection of views.
Xem giải thích
Đáp án
A — Bảng là đối tượng cơ sở dữ liệu CHỨA TOÀN BỘ dữ liệu trong một cơ sở dữ liệu.
Vì sao đúng
⚠ Trong CSDL quan hệ, bảng là nơi duy nhất dữ liệu thật sự nằm:
⚠ Database
⚠ TABLE ← dữ liệu THẬT nằm ở đây
⚠ View ← chỉ là truy vấn
⚠ Index ← cấu trúc phụ trợ
⚠ Procedure ← mã lệnh
| Cấu trúc bảng | Nội dung |
|---|---|
| ⚠ Cột | ⚠ có tên và KIỂU DỮ LIỆU |
| ⚠ Dòng | ⚠ một bản ghi |
| ⚠ Khoá chính | ⚠ định danh duy nhất |
| ⚠ Ràng buộc | ⚠ bảo đảm dữ liệu hợp lệ |
Vì sao các phương án khác sai
-
C (dữ liệu lưu thẳng vào CSDL, bảng là tuỳ chọn) — ⚠ SAI: ⚠ trong mô hình quan hệ, ⚠ không có bảng thì không có dữ liệu.
-
B (tập hợp các cặp khoá-giá trị) — ⚠ đó là mô hình NoSQL, không phải bảng quan hệ.
-
D (tập hợp các view) — ⚠ NGƯỢC: ⚠ view được dựng TỪ bảng.
Ghi nhớ
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp với #19563 trong cùng lô — ⚠ hai câu định nghĩa hai đối tượng cơ bản, ⚠ và mỗi câu đều có phương án mô tả đối tượng kia.
| Câu | Định nghĩa | Khoá |
|---|---|---|
| ⚠ #19563 | ⚠ VIEW | ⚠ bảng ảo từ truy vấn |
| ⚠ #19565 (câu này) | ⚠ TABLE | ⚠ nơi chứa dữ liệu thật |
| ⚠ Mẹo | ⚠ phân biệt được hai cái là loại được nhiễu ở cả hai câu |
⚠ Các đối tượng trong một CSDL quan hệ: | Đối tượng | Vai trò | |---|---| | ⚠ Table | ⚠ lưu dữ liệu | | ⚠ Index | ⚠ tăng tốc tìm kiếm | | ⚠ View | ⚠ truy vấn đặt tên | | ⚠ Stored procedure | ⚠ mã nghiệp vụ | | ⚠ Function | ⚠ trả về giá trị | | ⚠ Trigger | ⚠ phản ứng tự động | | ⚠ Constraint | ⚠ quy tắc dữ liệu | | ⚠ Schema | ⚠ nhóm logic và phân quyền |
Từ khoá nhận diện:
"nơi dữ liệu thật sự nằm" → ⚠ table "truy vấn đặt tên" → ⚠ view "cặp khoá-giá trị" → ⚠ NoSQL, không phải bảng quan hệ
| ⚠ Chọn kiểu dữ liệu cho cột | Nguyên tắc |
|---|---|
| ⚠ Chọn kiểu NHỎ NHẤT đủ dùng | |
| ⚠ Dùng NVARCHAR cho tiếng Việt | ⚠ VARCHAR mất dấu |
| ⚠ Tránh NVARCHAR(MAX) khi không cần | |
| ⚠ Dùng kiểu ngày tháng chuyên dụng | ⚠ không lưu ngày dưới dạng chuỗi |
| ⚠ Ảnh hưởng | ⚠ dung lượng, hiệu năng chỉ mục, tính đúng đắn |
| ⚠ Schema — khái niệm hay bị bỏ qua | Nội dung |
|---|---|
| ⚠ Nhóm logic các đối tượng trong database | ⚠ sales.DonHang |
| ⚠ Phân quyền theo schema thay vì từng bảng | |
| ⚠ Tránh trùng tên giữa các mảng nghiệp vụ | |
| ⚠ Mặc định | ⚠ dbo |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cột chuỗi có dùng NVARCHAR không | ⚠ quan trọng với tiếng Việt | | Kiểu dữ liệu có rộng quá mức cần thiết không | | | Bảng đã có khoá chính chưa | |
Và lỗi thiết kế bảng gây hậu quả lâu dài nhất với dữ liệu tiếng Việt, thường chỉ phát hiện khi đã có hàng triệu dòng: dùng VARCHAR thay vì NVARCHAR. Dấu tiếng Việt mất đi rồi thì không khôi phục lại được.
- A Core SQL
- B Cassandra API
- C MongoDB API
- D Graph API
Xem giải thích
Đáp án
A — Core SQL API.
Vì sao đúng
⚠ Core (SQL) là API GỐC của Cosmos DB, thiết kế cho tài liệu JSON: | Đặc điểm | Nội dung | |---|---| | ⚠ Lưu tài liệu JSON | | | ⚠ Truy vấn bằng cú pháp giống SQL | ⚠ SELECT ... FROM c WHERE ... | | ⚠ Được cập nhật tính năng SỚM NHẤT | | | ⚠ Hỗ trợ đầy đủ nhất | ⚠ change feed, stored procedure, trigger |
⚠ Ứng dụng MỚI với JSON
↓
⚠ Core SQL API là lựa chọn mặc định
Vì sao các phương án khác sai
-
C (MongoDB API) — ⚠ bẫy hợp lý: ⚠ Mongo ⚠ cũng là CSDL tài liệu, ⚠ nhưng API này dành cho ⚠ DI CHUYỂN ứng dụng Mongo sẵn có, ⚠ không phải lựa chọn tốt nhất cho ứng dụng mới.
-
B (Cassandra API) — ⚠ cột rộng.
-
D (Graph API) — ⚠ Gremlin, cho đồ thị.
Ghi nhớ
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ tên API trong khoá ⚠ đã được đổi.
| Vấn đề | Thực tế |
|---|---|
| ⚠ "Core (SQL) API" | ⚠ tên CŨ |
| ⚠ Nay gọi là "Azure Cosmos DB for NoSQL" | ⚠ API for NoSQL |
| ⚠ Các API khác cũng đổi tên tương tự | ⚠ for MongoDB, for Cassandra, for Gremlin, for Table |
| ⚠ Bản chất | ⚠ KHÔNG đổi, chỉ đổi cách gọi |
| ⚠ Giữ nguyên khoá | ⚠ A theo bộ đề gốc |
| ⚠ Khi ôn thi | ⚠ nhớ CẢ HAI tên vì đề cũ và tài liệu mới dùng khác nhau |
⚠ Năm API — tên cũ và tên mới: | Tên cũ | Tên mới | |---|---| | ⚠ Core (SQL) API | ⚠ API for NoSQL | | ⚠ MongoDB API | ⚠ API for MongoDB | | ⚠ Cassandra API | ⚠ API for Apache Cassandra | | ⚠ Gremlin API | ⚠ API for Apache Gremlin | | ⚠ Table API | ⚠ API for Table |
Từ khoá nhận diện:
"JSON, ứng dụng mới" → ⚠ Core SQL / API for NoSQL "di chuyển từ MongoDB" → ⚠ API for MongoDB "khoá-giá trị" → ⚠ API for Table "đồ thị" → ⚠ API for Gremlin
| ⚠ Vì sao nên chọn API gốc cho ứng dụng mới | Lý do |
|---|---|
| ⚠ Tính năng mới ra ở đây TRƯỚC | |
| ⚠ Hỗ trợ đầy đủ nhất | |
| ⚠ Tài liệu và ví dụ nhiều nhất | |
| ⚠ Tích hợp tốt nhất với Synapse Link, vector search | |
| ⚠ API tương thích | ⚠ luôn chậm hơn một nhịp về tính năng |
| ⚠ Change feed — tính năng đáng nhớ của API gốc | Nội dung |
|---|---|
| ⚠ Dòng các thay đổi theo THỨ TỰ | |
| ⚠ Kích hoạt Azure Function khi có thay đổi | |
| ⚠ Dùng cho đồng bộ, kiểm toán, cập nhật cache | |
| ⚠ Giống | ⚠ change data capture của CSDL quan hệ |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng mới hay đang di chuyển | ⚠ quyết định API | | Có cần tính năng mới nhất không | | | Đang đọc tài liệu dùng tên cũ hay tên mới | |
Và điều cần lưu ý khi ôn thi bằng ngân hàng câu hỏi cũ về Cosmos DB: toàn bộ tên API đã được đổi. Bản chất không đổi, nhưng bạn cần nhận ra cả hai cách gọi để không lúng túng trong phòng thi.
- A The ability to create detailed reports that are intended to be printed and shared.
- B The ability to create customizable online web reports, that are beautiful and can be customized and modified in various complex ways.
- C The ability to create dashboards that give you a visual look at the status of the business.
Xem giải thích
Đáp án
B — Khả năng tạo báo cáo web trực tuyến, đẹp, có thể tuỳ biến và chỉnh sửa theo nhiều cách phức tạp.
Vì sao đúng
⚠ Interactive report tối ưu cho việc KHÁM PHÁ trên màn hình: | Khả năng | Nội dung | |---|---| | ⚠ Slicer và bộ lọc | ⚠ người dùng tự đổi | | ⚠ Lọc chéo giữa các trực quan | ⚠ bấm một cột, cả trang phản ứng | | ⚠ Drill down và drill through | | | ⚠ Bookmark, tooltip tuỳ biến | | | ⚠ Nhiều trang, điều hướng giữa các trang | |
⚠ Người dùng ĐẶT CÂU HỎI MỚI
⚠ ngay trên báo cáo
↓
⚠ Không cần yêu cầu người làm báo cáo sửa
Vì sao các phương án khác sai
-
A (báo cáo chi tiết để IN và chia sẻ) — ⚠ đó là PAGINATED report.
-
C (dashboard cho cái nhìn trực quan về tình hình) — ⚠ đó là DASHBOARD.
Ghi nhớ
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ năm về ba loại nội dung Power BI qua hai lô.
| Câu | Hỏi gì | Khoá |
|---|---|---|
| ⚠ #19491 | ⚠ cần lọc, sắp xếp, drill-through | ⚠ Interactive |
| ⚠ #19522 | ⚠ hàng nghìn dòng để in | ⚠ Paginated |
| ⚠ #19543 | ⚠ dashboard để làm gì | ⚠ tổng quan một trang |
| ⚠ #19561 | ⚠ bộ công cụ phân tích | ⚠ Power BI |
| ⚠ #19567 (câu này) | ⚠ tính năng của Interactive report | ⚠ báo cáo web tuỳ biến |
| ⚠ Năm câu | ⚠ cùng một bảng ba loại nội dung | |
| ⚠ Nhận xét | ⚠ ba phương án của câu này chính là ba loại nội dung — đề tự tóm tắt luôn bảng cần thuộc |
⚠ Ba loại nội dung — bảng chốt cuối: | Loại | Tối ưu cho | Số trang | |---|---|---| | ⚠ Interactive report | ⚠ khám phá trên màn hình | ⚠ nhiều | | ⚠ Paginated report | ⚠ in ra giấy | ⚠ nhiều, cố định | | ⚠ Dashboard | ⚠ tổng quan nhanh | ⚠ một |
Từ khoá nhận diện:
"tuỳ biến, tương tác, web" → ⚠ Interactive "in ra, chia sẻ bản cứng" → ⚠ Paginated "nhìn nhanh tình hình" → ⚠ Dashboard
| ⚠ Tính năng tương tác đáng nhớ | Tính năng |
|---|---|
| ⚠ Cross-filtering | ⚠ bấm một phần tử, cả trang lọc theo |
| ⚠ Bookmark | ⚠ lưu trạng thái lọc để kể chuyện |
| ⚠ Drill through | ⚠ sang trang chi tiết theo ngữ cảnh |
| ⚠ Tooltip là cả một trang | ⚠ hiện biểu đồ khi rê chuột |
| ⚠ Q&A | ⚠ hỏi bằng ngôn ngữ tự nhiên |
| ⚠ Thiết kế báo cáo tốt | Nguyên tắc |
|---|---|
| ⚠ Mỗi trang trả lời MỘT câu hỏi | |
| ⚠ Không quá nhiều trực quan trên một trang | |
| ⚠ Đặt bộ lọc ở chỗ dễ thấy | |
| ⚠ Kiểm thử tốc độ tải với dữ liệu thật | |
| ⚠ Sai lầm | ⚠ nhồi mọi thứ vào một trang rồi báo cáo tải rất chậm |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người dùng cần khám phá, in ra, hay nhìn nhanh | | | Trang có quá nhiều trực quan không | | | Báo cáo tải mất bao lâu với dữ liệu thật | |
Và điều làm báo cáo tương tác có giá trị hơn hẳn một bản in đẹp: người dùng tự đặt được câu hỏi tiếp theo mà không phải chờ ai làm lại báo cáo.
- A Provide ways to create backups and restore from backups.
- B Determine which users and logins can access data and perform operations.
- C Affect the information stored in the database.
- D Define data structures.
Xem giải thích
Đáp án
C — Tác động tới THÔNG TIN được lưu trong cơ sở dữ liệu.
Vì sao đúng
⚠ DML = Data MANIPULATION Language, thao tác trên nội dung: | Câu lệnh | Việc | |---|---| | ⚠ SELECT | ⚠ đọc | | ⚠ INSERT | ⚠ thêm | | ⚠ UPDATE | ⚠ sửa | | ⚠ DELETE | ⚠ xoá | | ⚠ MERGE | ⚠ kết hợp thêm và sửa |
Vì sao các phương án khác sai
-
D (định nghĩa cấu trúc dữ liệu) — ⚠ đó là DDL.
-
B (quyết định ai truy cập được) — ⚠ đó là DCL.
-
A (tạo bản sao lưu và khôi phục) — ⚠ lệnh quản trị, không thuộc bốn nhóm chuẩn.
Ghi nhớ
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ tư 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 (câu này) | ⚠ DML làm gì | ⚠ tác động lên thông tin |
| ⚠ Bốn câu | ⚠ cùng một bảng, bốn chiều hỏi | |
| ⚠ Nhận xét | ⚠ #19529 và #19568 dùng CHUNG bộ bốn phương án, chỉ đổi tên nhóm trong câu hỏi |
⚠ Bảng bốn nhóm — dùng cho cả chùm: | Nhóm | Việc | Câu lệnh | |---|---|---| | ⚠ DDL | ⚠ cấu trúc | ⚠ CREATE, ALTER, DROP | | ⚠ DML | ⚠ thông tin | ⚠ SELECT, INSERT, UPDATE, DELETE | | ⚠ DCL | ⚠ quyền | ⚠ GRANT, REVOKE | | ⚠ TCL | ⚠ giao dịch | ⚠ COMMIT, ROLLBACK |
Từ khoá nhận diện:
"tác động lên thông tin, dữ liệu" → ⚠ DML "định nghĩa cấu trúc" → ⚠ DDL "ai được truy cập" → ⚠ DCL "sao lưu và khôi phục" → ⚠ lệnh quản trị, KHÔNG thuộc bốn nhóm
| ⚠ UPDATE và DELETE — cảnh báo thực tế | Cảnh báo |
|---|---|
| ⚠ Quên WHERE là sửa hoặc xoá TOÀN BỘ bảng | |
| ⚠ Nên viết SELECT trước để xem sẽ đụng bao nhiêu dòng | |
| ⚠ Chạy trong giao dịch để rollback được | |
| ⚠ Trên môi trường thật | ⚠ thói quen này đã cứu vô số người |
| ⚠ MERGE — câu lệnh mạnh nhưng cần cẩn thận | Nội dung |
|---|---|
| ⚠ Gộp INSERT, UPDATE, DELETE trong một lệnh | |
| ⚠ Rất hữu ích cho việc đồng bộ dữ liệu | |
| ⚠ Cú pháp phức tạp, dễ viết sai | |
| ⚠ Nhớ | ⚠ kết thúc bằng dấu chấm phẩy — bắt buộc |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lệnh UPDATE/DELETE đã có WHERE chưa | | | Đã chạy SELECT thử trước chưa | | | Có nằm trong giao dịch không | |
Và thói quen đơn giản nhất giúp tránh được sự cố dữ liệu nghiêm trọng nhất trong nghề: viết SELECT với đúng mệnh đề WHERE đó trước, xem số dòng, rồi mới đổi thành UPDATE hay DELETE.
- A Gremlin
- B Cassandra
- C MongoDB
- D MaxDB
Xem giải thích
Đáp án
D — MaxDB.
Vì sao đúng
⚠ Đây là câu PHỦ ĐỊNH — tìm API KHÔNG tồn tại.
⚠ SAP MaxDB là một cơ sở dữ liệu quan hệ của SAP, ⚠ không liên quan gì tới Cosmos DB.
| API Cosmos DB có thật | Mô hình |
|---|---|
| ⚠ NoSQL (Core SQL) | ⚠ tài liệu |
| ⚠ MongoDB | ⚠ tài liệu |
| ⚠ Cassandra | ⚠ cột rộng |
| ⚠ Gremlin | ⚠ đồ thị |
| ⚠ Table | ⚠ khoá-giá trị |
| ⚠ PostgreSQL | ⚠ thêm sau, cho Citus phân tán |
Vì sao các phương án khác sai
- A (Gremlin), B (Cassandra), C (MongoDB) — ⚠ đều là API có thật, nên không phải đáp án của câu phủ định.
Ghi nhớ
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ ba về danh sách API Cosmos DB trong hai lô.
| Câu | Hỏi gì | Khoá |
|---|---|---|
| ⚠ #19539 | ⚠ API nào cho khoá-giá trị | ⚠ Table API |
| ⚠ #19566 | ⚠ API nào cho JSON | ⚠ Core SQL |
| ⚠ #19569 (câu này) | ⚠ cái nào KHÔNG phải API | ⚠ MaxDB |
| ⚠ Ba câu | ⚠ thuộc danh sách năm API là trả lời được cả ba |
⚠ Danh sách API — kèm tên mới: | Tên cũ | Tên mới | |---|---| | ⚠ Core (SQL) | ⚠ API for NoSQL | | ⚠ MongoDB | ⚠ API for MongoDB | | ⚠ Cassandra | ⚠ API for Apache Cassandra | | ⚠ Gremlin | ⚠ API for Apache Gremlin | | ⚠ Table | ⚠ API for Table | | ⚠ Ngoài ra | ⚠ Cosmos DB for PostgreSQL — sản phẩm riêng dựa trên Citus |
Từ khoá nhận diện:
"MaxDB, Oracle, DB2, SQL Server" → ⚠ KHÔNG phải API Cosmos DB "MongoDB, Cassandra, Gremlin, Table" → ⚠ là API tương thích "Core SQL / NoSQL" → ⚠ API gốc
| ⚠ Cách làm câu phủ định về danh sách | Cách |
|---|---|
| ⚠ Nhớ danh sách ĐẦY ĐỦ và NGẮN | ⚠ năm API dễ thuộc |
| ⚠ Đánh dấu từng phương án có trong danh sách không | |
| ⚠ Cái duy nhất không có là đáp án | |
| ⚠ Ưu điểm | ⚠ thuộc một danh sách ngắn tốt hơn đoán từng câu |
| ⚠ Vì sao Cosmos DB có nhiều API | Lý do |
|---|---|
| ⚠ Giảm rào cản DI CHUYỂN | |
| ⚠ Ứng dụng Mongo hoặc Cassandra chuyển sang gần như không sửa mã | |
| ⚠ Bên dưới vẫn là CÙNG một engine | |
| ⚠ Đánh đổi | ⚠ API tương thích không hỗ trợ hết tính năng mới |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đề có chữ NOT hay KHÔNG không | | | Tên này có trong danh sách năm API không | | | Đang là tên cũ hay tên mới | |
Và lý do Cosmos DB duy trì nhiều API tương thích như vậy, đáng hiểu hơn là chỉ học thuộc danh sách: để một ứng dụng MongoDB hay Cassandra đang chạy chuyển sang mà gần như không phải sửa mã nguồn.
- A Data movement, Data transformation, and Control
- B Hive, Pig, Spark
- C Copy Data, MapReduce, Stored Procedure
- D Data set, Activity, Pipeline
Xem giải thích
Đáp án
A — Data movement, Data transformation và Control.
Vì sao đúng
⚠ Ba nhóm hoạt động của Data Factory: | Nhóm | Hoạt động tiêu biểu | |---|---| | ⚠ Data movement | ⚠ Copy activity | | ⚠ Data transformation | ⚠ Mapping Data Flow, Databricks, HDInsight, Stored Procedure | | ⚠ Control | ⚠ If Condition, ForEach, Until, Switch, Wait, Lookup, Execute Pipeline |
⚠ CONTROL quyết định LÀM GÌ, THEO THỨ TỰ NÀO
⚠ MOVEMENT chuyển dữ liệu từ A sang B
⚠ TRANSFORMATION biến đổi dữ liệu
Vì sao các phương án khác sai
-
D (Dataset, Activity, Pipeline) — ⚠ là ba KHÁI NIỆM cấu trúc, ⚠ không phải ba loại hoạt động.
-
C (Copy Data, MapReduce, Stored Procedure) — ⚠ là ba hoạt động cụ thể, ⚠ không phải ba LOẠI; ⚠ và MapReduce không phải hoạt động của ADF.
-
B (Hive, Pig, Spark) — ⚠ là công nghệ trong hệ sinh thái Hadoop.
Ghi nhớ
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ tư về Data Factory trong hai lô.
| Câu | Hỏi gì | Khoá |
|---|---|---|
| ⚠ #19514 | ⚠ hoạt động nào là control flow | ⚠ If Condition |
| ⚠ #19517 | ⚠ dịch vụ chuyển và biến đổi dữ liệu | ⚠ Data Factory |
| ⚠ #19544 | ⚠ nhóm logic các hoạt động | ⚠ Pipeline |
| ⚠ #19570 (câu này) | ⚠ ba loại hoạt động | ⚠ movement, transformation, control |
| ⚠ Bốn câu | ⚠ cùng một dịch vụ, bốn tầng khái niệm | |
| ⚠ Lưu ý | ⚠ phương án D chính là khoá của #19544 — đề tái sử dụng khái niệm làm nhiễu |
⚠ Hai bảng cần phân biệt rõ: | Bảng | Nội dung | |---|---| | ⚠ Ba LOẠI hoạt động | ⚠ movement, transformation, control | | ⚠ Các KHÁI NIỆM cấu trúc | ⚠ pipeline, activity, dataset, linked service, IR, trigger | | ⚠ Đề hay trộn | ⚠ hai bảng này vào cùng một danh sách phương án |
Từ khoá nhận diện:
"ba loại hoạt động" → ⚠ movement, transformation, control "nhóm logic các hoạt động" → ⚠ pipeline "chuỗi kết nối" → ⚠ linked service "hạ tầng thực thi" → ⚠ integration runtime
| ⚠ Hoạt động transformation — các lựa chọn | Lựa chọn |
|---|---|
| ⚠ Mapping Data Flow | ⚠ kéo thả, chạy trên Spark, KHÔNG cần code |
| ⚠ Databricks Notebook | ⚠ viết Python hoặc Scala |
| ⚠ Stored Procedure | ⚠ biến đổi ngay trong CSDL |
| ⚠ Azure Function | ⚠ logic tuỳ ý |
| ⚠ Chọn theo | ⚠ kỹ năng của đội và độ phức tạp của phép biến đổi |
| ⚠ Copy activity — điều đáng biết | Điều |
|---|---|
| ⚠ Hơn 100 connector sẵn có | |
| ⚠ Sao chép SONG SONG để tăng tốc | |
| ⚠ Có staging qua blob khi cần | |
| ⚠ Ánh xạ cột tự động hoặc thủ công | |
| ⚠ Đây là | ⚠ hoạt động được dùng nhiều nhất trong ADF |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đề hỏi loại hoạt động hay khái niệm cấu trúc | | | Phép biến đổi cần code hay kéo thả là đủ | | | Copy có bật song song chưa | |
Và cái bẫy thường gặp ở nhóm câu hỏi về Data Factory: đề trộn lẫn "ba loại hoạt động" với "các khái niệm cấu trúc" vào cùng danh sách phương án. Đọc kỹ câu hỏi đang hỏi bảng nào là loại được ngay một nửa.