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

Câu 61 Relational data

In a relational database, can a foreign key reference another column on the same table?

A No
B Yes

Xem giải thích

Đáp án

B — Có.

Vì sao đúng

⚠ Khoá ngoại TỰ THAM CHIẾU là mẫu thiết kế rất phổ biến:

⚠ Bảng NhanVien
   ⚠ id
   ⚠ ten
   ⚠ quanLyId  →  trỏ về NhanVien.id
        ↓
⚠ Biểu diễn cấu trúc PHÂN CẤP
   ⚠ nhân viên - quản lý
   ⚠ danh mục - danh mục cha
   ⚠ bình luận - bình luận gốc

Ứng dụng	Nội dung
⚠ Sơ đồ tổ chức
⚠ Cây danh mục sản phẩm
⚠ Bình luận có trả lời
⚠ Cây thư mục
⚠ Cây tài khoản kế toán

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

A (Không) — ⚠ SAI: ⚠ SQL hoàn toàn cho phép; ⚠ ràng buộc vẫn hoạt động bình thường.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #19503 ở lô trước về hệ quả của khoá ngoại.

⚠ Lưu ý khi tự tham chiếu: | Lưu ý | Nội dung | |---|---| | ⚠ Cột phải cho phép NULL | ⚠ gốc của cây không có cha | | ⚠ Không dùng được ON DELETE CASCADE | ⚠ SQL Server chặn cascade vòng | | ⚠ Phải tự xử lý khi xoá nút giữa cây | | | ⚠ Nên có chỉ mục trên cột tự tham chiếu | |

Từ khoá nhận diện:

"nhân viên và quản lý cùng bảng" → ⚠ tự tham chiếu "danh mục cha con" → ⚠ tự tham chiếu "truy vấn cả cây" → ⚠ recursive CTE "quan hệ rất nhiều tầng" → ⚠ cân nhắc CSDL đồ thị

⚠ Truy vấn cây trong SQL	Cách
⚠ Recursive CTE	⚠ `WITH ... AS (... UNION ALL ...)`
⚠ Đi từ gốc xuống hoặc từ lá lên
⚠ Nên có điều kiện dừng để tránh vòng lặp vô hạn
⚠ Hiệu năng	⚠ giảm nhanh khi cây sâu — đây là lúc đồ thị thắng thế

⚠ Ba cách lưu cấu trúc cây trong CSDL quan hệ	Cách
⚠ Adjacency list	⚠ cột cha — đơn giản nhất, đề này
⚠ Path enumeration	⚠ lưu đường dẫn dạng chuỗi
⚠ Nested set	⚠ đọc nhanh, ghi phức tạp
⚠ SQL Server còn có	⚠ kiểu dữ liệu hierarchyid

⚠ Rủi ro cần chặn	Rủi ro
⚠ Dữ liệu tạo thành VÒNG	⚠ A là cha B, B là cha A
⚠ Ràng buộc khoá ngoại KHÔNG chặn được vòng
⚠ Phải chặn bằng	⚠ logic ứng dụng hoặc trigger

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cột tự tham chiếu có cho phép NULL không | | | Có cơ chế chặn vòng lặp không | | | Cây sâu bao nhiêu tầng | ⚠ quá sâu thì cân nhắc đồ thị |

Và điều mà ràng buộc khoá ngoại không bảo vệ được trong thiết kế tự tham chiếu, dễ bị bỏ sót cho tới khi truy vấn đệ quy chạy mãi không dừng: dữ liệu tạo thành vòng tròn. Cơ sở dữ liệu chấp nhận nó hoàn toàn hợp lệ.

Câu 62 Non-relational data

What is the cheapest type of storage in Azure per GB stored?

A Azure Table Storage
B Azure Redis Cache
C Cosmos DB document storage
D SQL Server Managed Instance

Xem giải thích

Đáp án

A — Azure Table Storage.

Vì sao đúng

⚠ Trong bốn phương án, Table Storage rẻ nhất theo mỗi GB lưu trữ: | Dịch vụ | Chi phí lưu | |---|---| | ⚠ Table Storage | ⚠ rẻ nhất | | ⚠ Cosmos DB | ⚠ đắt hơn nhiều — trả cả RU | | ⚠ Redis Cache | ⚠ rất đắt — dữ liệu trong BỘ NHỚ | | ⚠ SQL Managed Instance | ⚠ đắt nhất — trả cả compute instance |

⚠ Trong bộ nhớ (Redis) > SSD cao cấp > SSD > HDD > lưu trữ lạnh
        ↓
⚠ Càng gần CPU càng đắt

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

B (Redis Cache) — ⚠ đắt nhất theo GB: ⚠ RAM đắt hơn đĩa rất nhiều.
C (Cosmos DB) — ⚠ trả cả thông lượng cấp phát, không chỉ dung lượng.
D (SQL Managed Instance) — ⚠ trả cho cả vCore của instance.

Ghi nhớ

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

Câu	Hỏi gì	Khoá
⚠ #19502	⚠ vì sao chọn Table Storage thay Cosmos	⚠ rẻ nhất
⚠ #19521	⚠ kho khoá-giá trị tiết kiệm nhất	⚠ Table Storage
⚠ #19552 (câu này)	⚠ lưu trữ rẻ nhất mỗi GB	⚠ Table Storage
⚠ Ba câu	⚠ cùng một khoá
⚠ Lưu ý	⚠ nếu đề đưa cả Blob Archive vào thì Archive còn rẻ hơn — nhưng ở đây không có

⚠ Thang chi phí lưu trữ Azure — từ rẻ tới đắt: | Bậc | Dịch vụ | |---|---| | ⚠ Rẻ nhất | ⚠ Blob Archive | | | ⚠ Blob Cool / Cold | | | ⚠ Table Storage, Blob Hot | | | ⚠ Azure Files | | | ⚠ Azure SQL Database | | | ⚠ Cosmos DB | | ⚠ Đắt nhất | ⚠ Redis (RAM) |

Từ khoá nhận diện:

"rẻ nhất mỗi GB" → ⚠ lưu trữ lạnh hoặc Table Storage "nhanh nhất" → ⚠ Redis, và đắt nhất "cần truy vấn phức tạp" → ⚠ SQL, đắt hơn "cần toàn cầu và SLA" → ⚠ Cosmos, đắt hơn nữa

⚠ Đừng chỉ so giá lưu trữ	Lý do
⚠ Còn phí THAO TÁC đọc ghi
⚠ Còn phí truyền dữ liệu ra ngoài	⚠ egress
⚠ Còn phí thông lượng cấp phát	⚠ Cosmos
⚠ Còn chi phí CON NGƯỜI vận hành
⚠ Tổng chi phí sở hữu	⚠ có thể đảo ngược so sánh giá theo GB

⚠ Egress — khoản hay bị quên	Nội dung
⚠ Đưa dữ liệu VÀO Azure thường miễn phí
⚠ Đưa dữ liệu RA khỏi Azure thì tính tiền
⚠ Chuyển giữa các VÙNG cũng tính
⚠ Thiết kế nên	⚠ giữ tính toán gần dữ liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã tính cả phí thao tác chưa | | | Dữ liệu có phải rời khỏi vùng không | ⚠ phí egress | | Có thật cần tính năng của dịch vụ đắt hơn không | |

Và khoản chi phí đám mây gây bất ngờ nhiều nhất, vì nó không xuất hiện trong bất kỳ bảng so sánh giá lưu trữ nào: phí truyền dữ liệu ra khỏi vùng. Một kiến trúc đặt tính toán và dữ liệu ở hai vùng khác nhau có thể trả nhiều hơn cho việc di chuyển byte so với việc lưu chúng.

Câu 63 Data warehouse

Which of the following can be called semi-structured data?

A Images in a blob storage account
B A printed invoice
C SQL Database table
D Data stored in XML format

Xem giải thích

Đáp án

D — Dữ liệu lưu ở định dạng XML.

Vì sao đúng

⚠ XML có thẻ và phân cấp nhưng không có schema cứng bắt buộc:

⚠ <nhanVien>
⚠   <ho>Nguyen</ho>
⚠   <ten>An</ten>
⚠   <tenDem>Van</tenDem>
⚠ </nhanVien>
⚠ <nhanVien>
⚠   <ho>Tran</ho>
⚠   <ten>Binh</ten>
⚠ </nhanVien>
        ⚠ ← thiếu tenDem, vẫn hợp lệ

Bán cấu trúc gồm	Định dạng
⚠ XML	⚠ đề này
⚠ JSON
⚠ YAML
⚠ Parquet, Avro	⚠ có schema nhúng

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

C (bảng SQL Database) — ⚠ CÓ cấu trúc: ⚠ schema cố định, mọi dòng cùng cột.
A (ảnh trong blob) — ⚠ PHI cấu trúc.
B (hoá đơn đã in ra giấy) — ⚠ không phải dữ liệu số; ⚠ muốn dùng phải OCR trước.

Ghi nhớ

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

Câu	Hỏi gì	Khoá
⚠ #19497	⚠ dữ liệu thiếu trường thuộc loại nào	⚠ bán cấu trúc
⚠ #19507	⚠ cái nào phi cấu trúc	⚠ nội dung blob
⚠ #19547	⚠ Blob lưu loại gì	⚠ phi cấu trúc
⚠ #19553 (câu này)	⚠ cái nào bán cấu trúc	⚠ XML
⚠ Bốn câu	⚠ cùng một bảng ba loại dữ liệu

⚠ Ba loại dữ liệu — bảng dùng cho cả chùm câu: | Loại | Nhận biết | Ví dụ | |---|---|---| | ⚠ Có cấu trúc | ⚠ schema CỐ ĐỊNH | ⚠ bảng SQL, CSV chuẩn | | ⚠ Bán cấu trúc | ⚠ có thẻ/khoá, schema LINH HOẠT | ⚠ JSON, XML, YAML | | ⚠ Phi cấu trúc | ⚠ KHÔNG schema | ⚠ ảnh, video, PDF |

Từ khoá nhận diện:

"XML, JSON, YAML" → ⚠ bán cấu trúc "bảng có cột cố định" → ⚠ có cấu trúc "ảnh, video, tệp nhị phân" → ⚠ phi cấu trúc "giấy tờ in ra" → ⚠ chưa phải dữ liệu số

⚠ XML và JSON — so sánh	So sánh
⚠ XML: có namespace, schema XSD, thuộc tính	⚠ nặng hơn, cũ hơn
⚠ JSON: gọn hơn, hợp API web	⚠ phổ biến hơn hiện nay
⚠ Cả hai đều bán cấu trúc
⚠ SQL Server	⚠ hỗ trợ cả kiểu XML lẫn hàm JSON

⚠ Bán cấu trúc lưu ở đâu	Nơi
⚠ Cosmos DB	⚠ JSON, truy vấn được
⚠ Cột JSON trong Azure SQL	⚠ kết hợp quan hệ và linh hoạt
⚠ Data Lake	⚠ tệp JSON, Parquet cho phân tích
⚠ Xu hướng	⚠ CSDL quan hệ ngày càng hỗ trợ tốt JSON

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mọi bản ghi có cùng bộ trường không | | | Schema có thay đổi thường xuyên không | | | Có cần truy vấn theo trường bên trong không | |

Và ranh giới rõ ràng nhất giữa ba loại dữ liệu, dùng được cho cả chùm câu hỏi này: máy có đọc được cấu trúc bên trong không — đọc trọn vẹn là có cấu trúc, đọc được nhưng không cố định là bán cấu trúc, không đọc được gì là phi cấu trúc.

Câu 64 Non-relational data management

When it comes to data security, what is the Zero Trust model?

A Assume that you have been breached.
B Allow users to save a cookie so that they do not have to log in again next time.
C Require a log-in every session from every user.
D Users are prompted with Multi-factor Authentication for extra authentication vertification.

Xem giải thích

Đáp án

A — GIẢ ĐỊNH rằng bạn đã bị xâm nhập.

Vì sao đúng

⚠ Zero Trust đảo ngược giả định nền tảng của bảo mật truyền thống:

⚠ Mô hình CŨ (castle-and-moat)
   ⚠ Bên ngoài: nguy hiểm
   ⚠ Bên trong mạng: TIN TƯỞNG
        ↓ ⚠ kẻ tấn công vào được là đi khắp nơi

⚠ ZERO TRUST
   ⚠ KHÔNG tin gì mặc định
   ⚠ Giả định kẻ tấn công ĐÃ ở bên trong
        ↓
⚠ Xác minh mọi yêu cầu
⚠ Phân đoạn để hạn chế lan rộng

Ba nguyên tắc	Nội dung
⚠ Verify explicitly	⚠ xác minh dựa trên mọi tín hiệu
⚠ Use least privilege	⚠ JIT, JEA
⚠ Assume breach	⚠ đề này

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

D (bắt buộc MFA) và C (yêu cầu đăng nhập mỗi phiên) — ⚠ là BIỆN PHÁP hỗ trợ, ⚠ không phải bản thân mô hình.
B (cho lưu cookie để khỏi đăng nhập lại) — ⚠ NGƯỢC hoàn toàn với tinh thần zero trust.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ cùng nhóm với #19515 và #19524 trong lô — ⚠ ba câu về nguyên tắc bảo mật, ⚠ và cùng một cái bẫy: ⚠ phương án nêu BIỆN PHÁP thay vì NGUYÊN TẮC.

Câu	Hỏi gì	Khoá	Bẫy
⚠ #19515	⚠ ví dụ đặc quyền tối thiểu	⚠ JIT	⚠ Access Reviews
⚠ #19524	⚠ định nghĩa đặc quyền tối thiểu	⚠ chỉ quyền cần thiết	⚠ mô tả JIT
⚠ #19554 (câu này)	⚠ Zero Trust là gì	⚠ giả định đã bị xâm nhập	⚠ MFA
⚠ Mẫu chung	⚠ phân biệt NGUYÊN TẮC với BIỆN PHÁP thực hiện

⚠ Zero Trust áp dụng vào Azure: | Nguyên tắc | Công cụ | |---|---| | ⚠ Verify explicitly | ⚠ Conditional Access, MFA, Identity Protection | | ⚠ Least privilege | ⚠ RBAC, PIM, Access Reviews | | ⚠ Assume breach | ⚠ phân đoạn mạng, mã hoá, Defender, giám sát |

Từ khoá nhận diện:

"giả định đã bị xâm nhập" → ⚠ Zero Trust "chỉ quyền cần thiết" → ⚠ least privilege "nhiều lớp phòng thủ" → ⚠ defense in depth "MFA, cookie, đăng nhập" → ⚠ biện pháp, không phải mô hình

⚠ "Assume breach" dẫn tới hành động gì	Hành động
⚠ PHÂN ĐOẠN mạng và quyền	⚠ hạn chế lan rộng
⚠ Mã hoá mọi nơi, kể cả nội bộ
⚠ Giám sát và ghi log đầy đủ
⚠ Diễn tập ứng phó sự cố
⚠ Câu hỏi cốt lõi	⚠ "nếu tài khoản này bị chiếm, kẻ tấn công đi được tới đâu?"

⚠ Vì sao mô hình cũ thất bại	Lý do
⚠ Làm việc từ xa xoá nhoà ranh giới mạng
⚠ Dịch vụ đám mây nằm ngoài tường lửa
⚠ Thiết bị cá nhân truy cập dữ liệu công ty
⚠ Không còn	⚠ "bên trong" để mà tin tưởng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nếu một tài khoản bị chiếm, thiệt hại tới đâu | ⚠ câu hỏi trung tâm | | Mạng nội bộ có được tin tưởng mặc định không | | | Có phân đoạn để hạn chế lan rộng chưa | |

Và câu hỏi mà toàn bộ tư duy Zero Trust rút gọn lại được, đáng đặt cho mọi hệ thống đang vận hành: nếu kẻ tấn công đã ở bên trong rồi, họ đi được tới đâu?

Câu 65 Non-relational DB

What type of non-relational data revolves around quickly storing and retrieving a single value per unique item? It is not optimized for queries that requiring examining the contents of the data, such as a WHERE clause in a typical relational query, but is extremely scalable and designed for storing data across multiple nodes on separate machines.

A Document data
B Object data
C Graph data
D Key-value data

Xem giải thích

Đáp án

D — Dữ liệu KHOÁ-GIÁ TRỊ.

Vì sao đúng

⚠ Đề mô tả chính xác đặc điểm của kho khoá-giá trị: | Đặc điểm đề nêu | Khoá-giá trị | |---|---| | ⚠ Lưu và lấy MỘT giá trị cho mỗi mục | ⚠ đúng mô hình | | ⚠ KHÔNG tối ưu cho truy vấn xét NỘI DUNG | ⚠ không có WHERE hiệu quả | | ⚠ Cực kỳ co giãn | ⚠ phân tán qua nhiều node dễ dàng |

⚠ Khoá → Giá trị (khối dữ liệu bất kỳ)
        ↓
⚠ Tra theo khoá: O(1), rất nhanh
⚠ Tìm theo nội dung: phải QUÉT TẤT CẢ

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

A (tài liệu) — ⚠ CÓ truy vấn theo nội dung: ⚠ đó chính là điểm khác biệt chính; ⚠ đề nói rõ ⚠ không tối ưu cho việc đó.
B (đối tượng) — ⚠ cho tệp nhị phân lớn: ⚠ ảnh, video.
C (đồ thị) — ⚠ tối ưu cho QUAN HỆ, ngược hẳn với mô tả.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ năm về khoá-giá trị qua hai lô — ⚠ #19496, #19508, #19521, #19539, #19546 đều cùng chủ đề.

⚠ Khoá-giá trị và tài liệu — ranh giới quyết định: | Tiêu chí | Khoá-giá trị | Tài liệu | |---|---|---| | ⚠ Truy vấn theo khoá | ⚠ rất nhanh | ⚠ rất nhanh | | ⚠ Truy vấn theo trường khác | ⚠ KÉM hoặc không có | ⚠ TỐT, có chỉ mục | | ⚠ CSDL hiểu nội dung | ⚠ KHÔNG | ⚠ CÓ | | ⚠ Chi phí | ⚠ rẻ hơn | ⚠ đắt hơn | | ⚠ Câu hỏi phân định | ⚠ có cần lọc theo trường bên trong không |

Từ khoá nhận diện:

"một giá trị mỗi khoá, không truy vấn nội dung" → ⚠ key-value "truy vấn theo nhiều trường" → ⚠ document "tệp nhị phân lớn" → ⚠ object "đường đi, quan hệ nhiều tầng" → ⚠ graph

⚠ Vì sao khoá-giá trị co giãn tốt	Lý do
⚠ Mỗi mục ĐỘC LẬP với mọi mục khác
⚠ Băm khoá là biết dữ liệu nằm ở node nào
⚠ Thêm node chỉ cần chia lại một phần khoá
⚠ Không có JOIN nên không cần dữ liệu ở cùng chỗ
⚠ Đây là	⚠ lý do mô hình này thắng ở quy mô rất lớn

⚠ Mẹo mở rộng khả năng truy vấn	Mẹo
⚠ Thiết kế KHOÁ chứa thông tin cần lọc	⚠ "user:1024:2026-09"
⚠ Tạo bảng chỉ mục phụ thủ công
⚠ Đồng bộ sang công cụ tìm kiếm
⚠ Nhưng nếu	⚠ phải làm nhiều mẹo như vậy thì nên chuyển sang mô hình tài liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn có luôn biết khoá không | | | Có nhu cầu lọc theo trường bên trong không | | | Khoá có thiết kế để hỗ trợ mẫu truy cập chưa | |

Và dấu hiệu cho thấy bạn đã chọn nhầm mô hình khoá-giá trị, thường xuất hiện sau vài tháng: phải dựng thêm bảng chỉ mục phụ để tìm kiếm. Đó chính là lúc mô hình tài liệu đáng giá hơn phần chênh lệch chi phí.

Câu 66 Non-relational DB

Your company is expecting terabytes of data to come in as non-structured JSON data. You can store it as a key-value pair. There is no requirement for maintaining relationships between the different entities at all, and your main consideration is speed of storing data and price. Which is the best non-relational data store for this scenario that you would recommend?

A Azure Table Storage
B Cosmos DB
C Redis Cache
D Azure Queue Storage

Xem giải thích

Đáp án

A — Azure Table Storage.

Vì sao đúng

⚠ Bốn ràng buộc trong đề, tất cả đều dẫn về Table Storage: | Ràng buộc | Kết luận | |---|---| | ⚠ Hàng terabyte JSON phi cấu trúc | ⚠ cần kho co giãn lớn | | ⚠ Lưu được dạng khoá-giá trị | ⚠ loại quan hệ | | ⚠ KHÔNG cần quan hệ giữa các thực thể | ⚠ loại đồ thị và quan hệ | | ⚠ Ưu tiên TỐC ĐỘ GHI và GIÁ | ⚠ loại Cosmos DB |

⚠ Không cần: truy vấn phức tạp, quan hệ, toàn cầu
⚠ Cần: ghi nhanh, rẻ, co giãn lớn
        ↓
⚠ Table Storage

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

B (Cosmos DB) — ⚠ đáp ứng được nhưng ĐẮT hơn nhiều; ⚠ đề nêu rõ ⚠ giá là cân nhắc chính.
C (Redis Cache) — ⚠ dữ liệu trong BỘ NHỚ: ⚠ hàng terabyte trong RAM là ⚠ cực kỳ đắt, và Redis là cache chứ không phải kho chính.
D (Queue Storage) — ⚠ hàng đợi TIN NHẮN, ⚠ không phải kho lưu trữ; ⚠ tin nhắn còn có giới hạn kích thước và thời gian sống.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ ba cùng khoá Table Storage vì lý do giá trong hai lô.

Câu	Ràng buộc chính	Khoá
⚠ #19521	⚠ tiết kiệm nhất, dữ liệu tạm	⚠ Table Storage
⚠ #19552	⚠ rẻ nhất mỗi GB	⚠ Table Storage
⚠ #19556 (câu này)	⚠ terabyte, ưu tiên tốc độ và giá	⚠ Table Storage
⚠ Ba câu	⚠ cùng khoá, không mâu thuẫn
⚠ Bài học	⚠ khi đề nhấn "chi phí là cân nhắc chính", Cosmos gần như luôn bị loại

⚠ Cách đọc đề nhiều ràng buộc: | Bước | Cách | |---|---| | ⚠ Gạch chân từng ràng buộc | | | ⚠ Loại phương án vi phạm ràng buộc CỨNG trước | ⚠ mô hình dữ liệu | | ⚠ Rồi mới xét ràng buộc MỀM | ⚠ chi phí, hiệu năng | | ⚠ Ràng buộc cuối cùng | ⚠ thường là thứ phân định hai phương án còn lại |

Từ khoá nhận diện:

"giá là cân nhắc chính" → ⚠ Table Storage, Blob "toàn cầu, độ trễ cam kết" → ⚠ Cosmos DB "cache tăng tốc" → ⚠ Redis "hàng đợi giữa các dịch vụ" → ⚠ Queue hoặc Service Bus

⚠ Giới hạn của Table Storage cần biết trước	Giới hạn
⚠ Thực thể tối đa 1MB
⚠ Tối đa 255 thuộc tính
⚠ Chỉ mục CHỈ trên PartitionKey + RowKey
⚠ Giao dịch chỉ trong một phân vùng, tối đa 100 thực thể
⚠ Nếu vượt các giới hạn này	⚠ phải cân nhắc Cosmos DB

⚠ Với JSON hàng terabyte, còn lựa chọn nào	Lựa chọn
⚠ Data Lake Gen2	⚠ nếu chủ yếu để PHÂN TÍCH theo lô
⚠ Table Storage	⚠ nếu cần tra cứu theo khoá
⚠ Đề nói "khoá-giá trị"	⚠ nên Table Storage là đáp án

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ràng buộc cứng nhất của đề là gì | | | Dữ liệu có vượt giới hạn 1MB mỗi thực thể không | | | Sẽ tra cứu theo khoá hay phân tích theo lô | |

Và tín hiệu rõ nhất trong đề thi để loại Cosmos DB khỏi danh sách, dù nó luôn là phương án nghe hấp dẫn nhất: khi đề nói chi phí là cân nhắc chính. Cosmos đắt vì nó bán những năng lực mà kịch bản đó không dùng đến.

Câu 67 Analytics Workload

A customer just purchased a service from your company, and a new data row was added to table SALES to indicate this event as soon as it happened. What type of database is this?

A Caching database
B Analytics database
C Transactional database
D Data warehouse

Xem giải thích

Đáp án

C — Cơ sở dữ liệu GIAO DỊCH (transactional database).

Vì sao đúng

⚠ Ghi một dòng NGAY KHI sự kiện xảy ra là đặc trưng của OLTP:

⚠ Khách mua dịch vụ
        ↓ ⚠ NGAY LẬP TỨC
⚠ INSERT vào bảng SALES
        ↓
⚠ Ghi nhỏ, nhanh, thường xuyên
⚠ Cần ACID để không mất giao dịch

Đặc điểm OLTP	Nội dung
⚠ Nhiều thao tác NGẮN
⚠ Ghi và đọc trộn lẫn
⚠ Cần giao dịch ACID
⚠ Dữ liệu HIỆN TẠI
⚠ Chuẩn hoá cao

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

D (kho dữ liệu) và B (CSDL phân tích) — ⚠ nhận dữ liệu theo LÔ, ⚠ không ghi từng dòng ngay khi sự kiện xảy ra; ⚠ chúng phục vụ báo cáo.
A (CSDL cache) — ⚠ lưu tạm để tăng tốc đọc, ⚠ không phải nơi ghi nhận giao dịch chính thức.

Ghi nhớ

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

Câu	Hỏi gì	Khoá
⚠ #19534	⚠ truy vấn sâu chạy hàng giờ	⚠ OLAP
⚠ #19557 (câu này)	⚠ ghi dòng ngay khi bán hàng	⚠ OLTP
⚠ Cặp đối xứng	⚠ hai đầu của cùng một trục
⚠ Điểm phân biệt	⚠ GHI NHẬN sự kiện hay PHÂN TÍCH sự kiện

⚠ OLTP và OLAP — bảng chốt: | Tiêu chí | OLTP | OLAP | |---|---|---| | ⚠ Việc chính | ⚠ ghi nhận giao dịch | ⚠ phân tích | | ⚠ Truy vấn | ⚠ nhiều, ngắn | ⚠ ít, dài | | ⚠ Dữ liệu | ⚠ hiện tại | ⚠ lịch sử | | ⚠ Lưu trữ | ⚠ theo dòng | ⚠ theo cột | | ⚠ Azure | ⚠ SQL Database, Cosmos | ⚠ Synapse, Fabric |

Từ khoá nhận diện:

"ghi ngay khi sự kiện xảy ra" → ⚠ OLTP "báo cáo, tổng hợp nhiều năm" → ⚠ OLAP "tăng tốc đọc dữ liệu hay dùng" → ⚠ cache "kho tập trung nhiều nguồn" → ⚠ data warehouse

⚠ ACID — vì sao OLTP cần	Tính chất
⚠ Atomicity	⚠ trừ tiền và ghi đơn hàng phải cùng thành công
⚠ Consistency	⚠ không để tồn kho âm
⚠ Isolation	⚠ hai người mua cùng lúc không giẫm lên nhau
⚠ Durability	⚠ đã xác nhận là không mất, kể cả mất điện
⚠ Đây là	⚠ lý do hệ thống bán hàng dùng CSDL quan hệ

⚠ Dữ liệu đi từ OLTP sang OLAP thế nào	Cách
⚠ ETL/ELT theo lịch	⚠ Data Factory
⚠ Change Data Capture	⚠ bắt thay đổi tăng dần
⚠ Synapse Link	⚠ gần thời gian thực, không đụng hệ giao dịch
⚠ Vì sao không phân tích thẳng trên OLTP	⚠ truy vấn nặng làm chậm việc bán hàng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hệ thống này ghi nhận hay phân tích | | | Có báo cáo nặng nào đang chạy trên CSDL giao dịch không | | | Có cần ACID nghiêm ngặt không | |

Và lý do các tổ chức tách hai hệ thống ra dù nghe như trùng lặp: một truy vấn báo cáo nặng chạy trên cơ sở dữ liệu bán hàng có thể làm chậm chính việc bán hàng. Đó là cái giá trả bằng doanh thu thật.

Câu 68 Data Warehouse

Which Azure service is a managed-version of the open-source Apache Spark application, or provides a Spark environment in Azure?

A Azure Synapse Analytics, Azure ML Studio
B SQL Database, SQL Managed Instance
C Azure Blob Storage, Azure Table Storage
D Azure HDInsight, Azure Databricks

Xem giải thích

Đáp án

D — Azure HDInsight và Azure Databricks.

Vì sao đúng

⚠ Cả hai đều cung cấp môi trường Apache Spark được quản lý: | Dịch vụ | Đặc điểm | |---|---| | ⚠ Azure HDInsight | ⚠ cụm Hadoop/Spark/Kafka/HBase mã nguồn mở | | ⚠ Azure Databricks | ⚠ nền tảng Spark tối ưu, do chính người tạo Spark xây |

⚠ Apache Spark
   ⚠ xử lý dữ liệu lớn phân tán trong bộ nhớ
        ↓ ⚠ tự dựng thì rất mất công
⚠ Dịch vụ được quản lý
   ⚠ dựng cụm bằng vài thao tác
   ⚠ tự co giãn, tự vá lỗi

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

A (Synapse Analytics, Azure ML Studio) — ⚠ bẫy đáng chú ý: ⚠ Synapse ⚠ CÓ Spark pool, ⚠ nhưng Azure ML Studio thì không phải môi trường Spark; ⚠ cặp này không đúng cả hai.
B (SQL Database, Managed Instance) — ⚠ CSDL quan hệ, không phải Spark.
C (Blob Storage, Table Storage) — ⚠ là kho LƯU TRỮ, không tính toán.

Ghi nhớ

⚠ Ba lựa chọn Spark trên Azure — phân biệt: | Dịch vụ | Điểm mạnh | |---|---| | ⚠ Databricks | ⚠ hiệu năng cao, notebook cộng tác, MLflow, Delta Lake | | ⚠ HDInsight | ⚠ nhiều framework mã nguồn mở, kiểm soát cụm | | ⚠ Synapse Spark pool | ⚠ tích hợp trong không gian phân tích chung | | ⚠ Cả ba | ⚠ đều chạy Spark |

Từ khoá nhận diện:

"Spark được quản lý" → ⚠ Databricks, HDInsight, Synapse Spark "Hadoop, Kafka, HBase" → ⚠ HDInsight "notebook, MLflow, Delta Lake" → ⚠ Databricks "kho dữ liệu + Spark + pipeline một chỗ" → ⚠ Synapse

⚠ Vì sao Spark phổ biến cho dữ liệu lớn	Lý do
⚠ Xử lý trong BỘ NHỚ, nhanh hơn MapReduce nhiều
⚠ Một API cho batch, stream, SQL, ML
⚠ Viết được bằng Python, Scala, SQL, R
⚠ Tự phân tán công việc qua nhiều node

⚠ Delta Lake — đáng biết	Nội dung
⚠ Lớp lưu trữ trên data lake
⚠ Thêm GIAO DỊCH ACID cho tệp trên lake
⚠ Time travel: đọc lại phiên bản cũ
⚠ Schema enforcement
⚠ Giải quyết	⚠ điểm yếu cố hữu của data lake là thiếu tính nhất quán

⚠ Chi phí Spark — lưu ý	Lưu ý
⚠ Cụm tính tiền theo THỜI GIAN CHẠY
⚠ Bật auto-termination cho cụm rảnh	⚠ quan trọng nhất
⚠ Dùng cụm job thay vì cụm tương tác cho việc tự động
⚠ Sai lầm	⚠ để cụm chạy qua đêm mà không ai dùng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cụm có tự tắt khi rảnh không | ⚠ khoản lãng phí lớn nhất | | Có thật sự cần Spark không | ⚠ dữ liệu nhỏ thì SQL đủ rồi | | Đang dùng Delta Lake hay tệp thô | |

Và khoản lãng phí phổ biến nhất trong mọi nền tảng dữ liệu lớn, lộ ra vào cuối tháng: một cụm tính toán bật từ hôm trước mà không ai dùng. Tự động tắt khi rảnh là cấu hình đáng bật ngay từ lúc tạo cụm.

Câu 69 Non-relational data management

By default, what is the security model of Cosmos DB?

A A valid authorization token
B Security client certificate
C User name and password
D Azure Active Directory

Xem giải thích

Đáp án

A — Một authorization token hợp lệ.

Vì sao đúng

⚠ Mặc định, Cosmos DB xác thực bằng khoá và token chứ không phải tài khoản người dùng: | Cơ chế | Nội dung | |---|---| | ⚠ Primary / secondary key | ⚠ quyền TOÀN PHẦN trên tài khoản | | ⚠ Read-only key | ⚠ chỉ đọc | | ⚠ Resource token | ⚠ quyền hẹp, có thời hạn |

⚠ Client gửi request
   ⚠ kèm header Authorization
        ↓
⚠ Token ký bằng khoá tài khoản
        ↓
⚠ Cosmos DB xác minh rồi cho phép

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

C (tên đăng nhập và mật khẩu) — ⚠ không phải mô hình của Cosmos DB; ⚠ đó là kiểu của CSDL quan hệ.
D (Azure Active Directory) — ⚠ HỖ TRỢ được nhưng KHÔNG phải mặc định: ⚠ xem ghi chú bên dưới.
B (chứng chỉ client) — ⚠ không phải cơ chế của Cosmos DB.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ khoá vẫn đúng nhưng ⚠ thực hành khuyến nghị đã thay đổi.

Vấn đề	Thực tế hiện nay
⚠ Token dựa trên khoá vẫn là MẶC ĐỊNH	⚠ khoá A đúng
⚠ Nhưng Microsoft KHUYẾN NGHỊ dùng Entra ID + RBAC
⚠ Tắt hẳn xác thực bằng khoá được	⚠ `disableLocalAuth`
⚠ Managed identity là cách tốt nhất hiện nay
⚠ Giữ nguyên khoá	⚠ A theo bộ đề gốc
⚠ Đối chiếu	⚠ #19495 lô trước, cùng khuyến nghị bỏ khoá cho Storage

⚠ Vì sao nên bỏ xác thực bằng khoá: | Lý do | Nội dung | |---|---| | ⚠ Khoá là quyền TOÀN PHẦN, không phân cấp | | | ⚠ Lộ khoá là mất cả tài khoản | | | ⚠ Không biết ai đang dùng khoá | | | ⚠ Luân chuyển khoá gây gián đoạn | | | ⚠ Entra ID cho phép | ⚠ phân quyền chi tiết, có nhật ký, thu hồi từng danh tính |

Từ khoá nhận diện:

"mặc định, token, khoá tài khoản" → ⚠ key-based auth "phân quyền chi tiết, có nhật ký" → ⚠ Entra ID + RBAC "ứng dụng không cần lưu bí mật" → ⚠ managed identity "quyền hẹp cho người dùng cuối" → ⚠ resource token

⚠ Resource token — cơ chế đáng biết	Nội dung
⚠ Dịch vụ trung gian cấp token hẹp cho từng người dùng
⚠ Giới hạn tới container hoặc partition key cụ thể
⚠ Có thời hạn ngắn
⚠ Dùng khi	⚠ ứng dụng di động truy cập trực tiếp Cosmos DB
⚠ Không bao giờ	⚠ nhúng khoá tài khoản vào ứng dụng client

⚠ Hai khoá primary và secondary	Vì sao có hai
⚠ Để LUÂN CHUYỂN mà không gián đoạn
⚠ Chuyển ứng dụng sang khoá phụ, tạo lại khoá chính, rồi đổi ngược
⚠ Nếu chỉ có một khoá	⚠ mọi lần đổi khoá là một lần dịch vụ gián đoạn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn ứng dụng nào dùng khoá tài khoản không | | | Có thể chuyển sang managed identity không | | | Khoá lần cuối được luân chuyển khi nào | |

Và hướng đi chung của toàn bộ hệ sinh thái Azure về xác thực, đúng cho cả Cosmos DB lẫn Storage: bỏ dần bí mật chia sẻ để chuyển sang danh tính có phân quyền và nhật ký. Một khoá bị lộ là mất tất cả; một danh tính bị lộ chỉ mất đúng phần quyền của nó.

Câu 70 Relational data security

Which of the following methods is commonly used to secure data in transit?

A One-way hash function
B Bitlocker Encryption
C Secure Sockets Layer (SSL) or HTTPS
D Azure Disk Encryption

Xem giải thích

Đáp án

C — Secure Sockets Layer (SSL) hoặc HTTPS.

Vì sao đúng

⚠ TLS/SSL mã hoá dữ liệu trên ĐƯỜNG TRUYỀN giữa hai đầu:

⚠ Client                    ⚠ Server
   ⚠ Bắt tay TLS
   ⚠ Thoả thuận khoá phiên
        ↓
⚠ Mọi gói tin đi qua mạng đều MÃ HOÁ
        ↓
⚠ Kẻ nghe lén chỉ thấy dữ liệu vô nghĩa

Bảo vệ khỏi	Nội dung
⚠ Nghe lén trên đường truyền
⚠ Tấn công người ở giữa	⚠ nhờ xác thực chứng chỉ
⚠ Sửa đổi gói tin

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

B (BitLocker) và D (Azure Disk Encryption) — ⚠ đều mã hoá ĐĨA, ⚠ tức là bảo vệ dữ liệu ⚠ khi lưu.
A (hàm băm một chiều) — ⚠ không phải mã hoá: ⚠ băm ⚠ không đảo ngược được, ⚠ dùng để kiểm tra toàn vẹn và lưu mật khẩu, ⚠ không dùng để truyền dữ liệu cần đọc lại.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ hoàn chỉnh bộ ba trạng thái dữ liệu cùng #19538 và #19548 trong lô.

Câu	Trạng thái	Khoá
⚠ #19538	⚠ TDE bảo vệ gì	⚠ at rest
⚠ #19548	⚠ at rest là gì	⚠ dữ liệu tĩnh trên đĩa
⚠ #19560 (câu này)	⚠ bảo vệ in transit bằng gì	⚠ SSL/HTTPS
⚠ Ba câu	⚠ vẽ đủ bức tranh ba trạng thái

⚠ Ba trạng thái và cơ chế — bảng chốt: | Trạng thái | Cơ chế | |---|---| | ⚠ At rest | ⚠ TDE, BitLocker, Disk Encryption, SSE | | ⚠ In transit | ⚠ TLS/SSL, HTTPS, VPN, ExpressRoute | | ⚠ In use | ⚠ Always Encrypted, confidential computing |

Từ khoá nhận diện:

"trên đường truyền, giữa client và server" → ⚠ TLS/HTTPS "trên đĩa, trong file" → ⚠ mã hoá khi lưu "băm, hash" → ⚠ toàn vẹn và mật khẩu, KHÔNG phải mã hoá "secure transfer required" → ⚠ ép HTTPS trên Storage

⚠ Mã hoá và băm — khác biệt căn bản	Khác biệt
⚠ Mã hoá: ĐẢO NGƯỢC được bằng khoá	⚠ để đọc lại dữ liệu
⚠ Băm: MỘT CHIỀU, không đảo ngược	⚠ để kiểm tra, so sánh
⚠ Mật khẩu nên BĂM, không mã hoá
⚠ Nhầm hai khái niệm	⚠ là lỗi thiết kế bảo mật kinh điển

⚠ Thực hành TLS trên Azure	Thực hành
⚠ Đặt phiên bản TLS tối thiểu là 1.2
⚠ Bật "secure transfer required" cho Storage
⚠ Ép HTTPS trên App Service
⚠ Dùng chứng chỉ được quản lý, tự gia hạn
⚠ Sự cố kinh điển	⚠ chứng chỉ hết hạn mà không ai theo dõi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phiên bản TLS tối thiểu đặt là bao nhiêu | | | Có endpoint nào còn chấp nhận HTTP không | | | Chứng chỉ hết hạn ngày nào và ai theo dõi | |

Và sự cố gián đoạn dịch vụ dễ đoán trước nhất mà vẫn xảy ra thường xuyên: chứng chỉ TLS hết hạn. Nó có ngày hết hạn ghi sẵn từ đầu, và vẫn không ai đặt lời nhắc.

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

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ