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

Tìm thấy 328 câu.

Câu 101 Non-relational DB
What is the maximum amount of data that can be stored in a Azure Table Storage database?
  1. A Unlimited
  2. B 100 TB
  3. C 1 TB
  4. D 5 PB
Xem giải thích

Đáp án

D — 5 PB (petabyte).

Vì sao đúng

⚠ Giới hạn dung lượng của một Storage Account là 5 PB: | Giới hạn | Con số | |---|---| | ⚠ Dung lượng mỗi Storage Account | ⚠ 5 PB | | ⚠ Kích thước mỗi thực thể Table | ⚠ 1 MB | | ⚠ Số thuộc tính mỗi thực thể | ⚠ 255 | | ⚠ Số bảng, số thực thể | ⚠ không giới hạn trong phạm vi dung lượng |

⚠ 5 PB là RẤT lớn
   ⚠ đủ cho gần như mọi ứng dụng
        ↓
⚠ Cần hơn thì tạo THÊM storage account

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

  • A (không giới hạn) — ⚠ SAI: ⚠ mọi dịch vụ đám mây đều có hạn mức.

  • B (100 TB) — ⚠ là hạn mức CŨ, đã được nâng lên.

  • C (1 TB) — ⚠ quá nhỏ so với thực tế.

Ghi nhớ

⚠ Các giới hạn hay bị hỏi của Azure Storage: | Giới hạn | Con số | |---|---| | ⚠ Dung lượng tài khoản | ⚠ 5 PB | | ⚠ Block blob tối đa | ⚠ khoảng 190 TB | | ⚠ Thực thể Table | ⚠ 1 MB | | ⚠ Tin nhắn Queue | ⚠ 64 KB | | ⚠ File share | ⚠ 100 TB (bật large file share) | | ⚠ Thời gian tin nhắn Queue sống | ⚠ mặc định 7 ngày |

Từ khoá nhận diện:

"5 PB" → ⚠ dung lượng storage account "1 MB" → ⚠ thực thể Table "64 KB" → ⚠ tin nhắn Queue "không giới hạn" → ⚠ hiếm khi đúng trên đám mây

⚠ Vì sao cần biết giới hạn Lý do
⚠ Thiết kế phải chia tài khoản nếu vượt
⚠ Giới hạn IOPS và băng thông cũng theo tài khoản ⚠ thường chạm trước giới hạn dung lượng
⚠ Nhiều ứng dụng chung một tài khoản gây tranh chấp
⚠ Thực hành tốt ⚠ tách tài khoản theo ứng dụng hoặc theo môi trường
⚠ Giới hạn thường chạm trước dung lượng Giới hạn
⚠ Băng thông vào ra mỗi tài khoản
⚠ Số giao dịch mỗi giây
⚠ Với Table: 20.000 thực thể mỗi giây mỗi tài khoản
⚠ Với một phân vùng: 2.000 thực thể mỗi giây ⚠ hot partition dễ chạm
⚠ Nghĩa là ⚠ thiết kế partition key quan trọng hơn lo về 5 PB

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có phân vùng nào bị nóng không | ⚠ giới hạn 2.000/giây mỗi phân vùng | | Nhiều ứng dụng có dùng chung tài khoản không | | | Băng thông tài khoản đã dùng bao nhiêu phần trăm | |

Và giới hạn thực tế cản trở hệ thống trước con số 5 PB rất lâu: hạn mức giao dịch trên MỘT phân vùng. Một partition key thiết kế kém sẽ chạm trần đó khi dung lượng còn chưa tới một phần nghìn.

Câu 102 Non-relational data management
How do you implement the Zero Trust model of security?
  1. A Require all users to be registered in Azure Active Directory for access.
  2. B Add Multi-Factor Authentication using Azure AD Conditional Access.
  3. C Use Azure's Advanced Threat Protection feature for AI monitoring of activities.
  4. D Verify each request as though it originated from an uncontrolled network.
Xem giải thích

Đáp án

D — Xác minh MỌI yêu cầu như thể nó đến từ một mạng KHÔNG được kiểm soát.

Vì sao đúng

⚠ Đó chính là cách thực hiện Zero Trust:

⚠ Yêu cầu từ máy trong văn phòng?
   ⚠ Vẫn xác minh đầy đủ
⚠ Yêu cầu từ dịch vụ nội bộ?
   ⚠ Vẫn xác minh đầy đủ
        ↓
⚠ KHÔNG có "vùng tin cậy"
        ↓
⚠ Danh tính, thiết bị, vị trí, rủi ro
   ⚠ được xét ở MỌI yêu cầu
Xác minh dựa trên Tín hiệu
⚠ Danh tính người dùng
⚠ Tình trạng thiết bị ⚠ có tuân thủ không
⚠ Vị trí và mạng
⚠ Mức rủi ro của phiên đăng nhập
⚠ Ứng dụng và dữ liệu đang truy cập

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

  • B (thêm MFA qua Conditional Access) — ⚠ là một BIỆN PHÁP quan trọng, ⚠ nhưng chỉ là một phần của việc "xác minh tường minh".

  • A (mọi người dùng phải đăng ký trong Entra ID) — ⚠ điều kiện cần, không phải cách thực hiện.

  • C (dùng Advanced Threat Protection) — ⚠ thuộc PHÁT HIỆN, không phải nguyên tắc xác minh.

Ghi nhớ

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

Câu Hỏi gì Khoá
⚠ #19554 ⚠ Zero Trust LÀ GÌ ⚠ giả định đã bị xâm nhập
⚠ #19592 (câu này) ⚠ THỰC HIỆN Zero Trust thế nào ⚠ xác minh mọi yêu cầu như từ mạng không tin cậy
⚠ Cùng mô hình ⚠ một hỏi định nghĩa, một hỏi cách làm
⚠ Cùng cái bẫy ⚠ phương án nêu MFA — biện pháp cụ thể thay vì nguyên tắc

⚠ Ba nguyên tắc Zero Trust và cách thực hiện: | Nguyên tắc | Thực hiện trên Azure | |---|---| | ⚠ Verify explicitly | ⚠ Conditional Access, MFA, device compliance | | ⚠ Least privilege | ⚠ RBAC, PIM, JIT, Access Reviews | | ⚠ Assume breach | ⚠ phân đoạn, mã hoá, Defender, giám sát |

Từ khoá nhận diện:

"xác minh mọi yêu cầu, không tin mạng nào" → ⚠ Zero Trust "MFA, Conditional Access" → ⚠ biện pháp của Verify explicitly "phân đoạn để hạn chế lan rộng" → ⚠ Assume breach "chỉ quyền cần thiết" → ⚠ Least privilege

⚠ Conditional Access — công cụ trung tâm Nội dung
⚠ Nếu (tín hiệu) thì (yêu cầu) hoặc (chặn)
⚠ Tín hiệu: người dùng, thiết bị, vị trí, rủi ro, ứng dụng
⚠ Yêu cầu: MFA, thiết bị tuân thủ, chấp nhận điều khoản
⚠ Đây là ⚠ nơi Zero Trust được biến thành cấu hình cụ thể
⚠ Cẩn thận ⚠ luôn chừa tài khoản khẩn cấp (break-glass) ngoài chính sách
⚠ Sáu trụ cột của Zero Trust Trụ cột
⚠ Danh tính
⚠ Thiết bị
⚠ Ứng dụng
⚠ Dữ liệu
⚠ Hạ tầng
⚠ Mạng
⚠ Áp dụng ⚠ nguyên tắc xác minh cho cả sáu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có tài khoản break-glass ngoài Conditional Access chưa | ⚠ tránh tự khoá mình | | Lưu lượng nội bộ có được xác minh không | | | Thiết bị không tuân thủ có bị chặn không | |

Và biện pháp phòng ngừa bắt buộc khi triển khai Conditional Access nghiêm ngặt, đã cứu nhiều tổ chức khỏi thảm hoạ: giữ vài tài khoản khẩn cấp nằm ngoài mọi chính sách. Một quy tắc viết sai có thể khoá toàn bộ quản trị viên ra khỏi hệ thống của chính họ.

Câu 103 Azure Storage
What is the primary difference between the Standard tier of Azure File Share, and the Premium tier?
  1. A The standard tier supports less data capacity while the premium tier can support more files
  2. B Standard tier uses hard disk-based storage, while Premium tier uses solid-state disks
  3. C File storage must be attached to a single VM, and must be detatched before another VM can use it
  4. D File storage is built on the container model, with data stored in blobs
Xem giải thích

Đáp án

B — Bậc Standard dùng lưu trữ trên ĐĨA CỨNG (HDD), còn bậc Premium dùng ổ THỂ RẮN (SSD).

Vì sao đúng

⚠ Khác biệt nền tảng là phần cứng bên dưới: | Tiêu chí | Standard | Premium | |---|---|---| | ⚠ Phần cứng | ⚠ HDD | ⚠ SSD | | ⚠ Độ trễ | ⚠ cao hơn | ⚠ rất thấp | | ⚠ IOPS | ⚠ thấp hơn | ⚠ cao | | ⚠ Mô hình tính tiền | ⚠ theo dung lượng DÙNG + thao tác | ⚠ theo dung lượng CẤP PHÁT | | ⚠ Loại tài khoản | ⚠ general purpose v2 | ⚠ FileStorage riêng |

⚠ Premium tính tiền theo phần ĐÃ CẤP
        ↓
⚠ Cấp 1TB dùng 100GB vẫn trả cho 1TB

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

  • A (Standard ít dung lượng hơn, Premium nhiều tệp hơn) — ⚠ SAI: ⚠ khác biệt là hiệu năng, không phải số lượng.

  • C (phải gỡ khỏi VM này mới gắn được vào VM khác) — ⚠ SAI: ⚠ Azure Files ⚠ cho phép nhiều máy gắn cùng lúc — đó là điểm mạnh của nó.

  • D (xây trên mô hình container, dữ liệu lưu trong blob) — ⚠ nhầm sang Blob Storage.

Ghi nhớ

⚠ Azure Files — điểm mạnh riêng: | Điểm | Nội dung | |---|---| | ⚠ Giao thức SMB và NFS | ⚠ mount như ổ đĩa mạng | | ⚠ NHIỀU máy gắn CÙNG LÚC | ⚠ khác managed disk | | ⚠ Dùng được từ cả tại chỗ lẫn đám mây | | | ⚠ Azure File Sync để đồng bộ chi nhánh | | | ⚠ Xác thực bằng Entra ID hoặc AD DS | |

Từ khoá nhận diện:

"SSD, độ trễ thấp" → ⚠ Premium file share "nhiều VM cùng gắn một ổ" → ⚠ Azure Files "một VM một đĩa" → ⚠ managed disk "lưu ảnh, video qua HTTP" → ⚠ Blob

⚠ Khi nào cần Premium file share Khi nào
⚠ Ứng dụng nhạy độ trễ ⚠ CSDL, ERP
⚠ Nhiều thao tác tệp nhỏ
⚠ Container cần lưu trữ dùng chung nhanh
⚠ Standard đủ cho ⚠ chia sẻ tệp văn phòng, sao lưu, kho tài liệu
⚠ Azure Files và Blob — chọn cái nào Chọn
⚠ Ứng dụng cũ cần đường dẫn tệp ⚠ Files
⚠ Nhiều máy cùng đọc ghi một thư mục ⚠ Files
⚠ Ứng dụng mới truy cập qua API ⚠ Blob, rẻ hơn
⚠ Lưu trữ khối lượng lớn ⚠ Blob
⚠ Sai lầm hay gặp ⚠ dùng Files cho việc mà Blob rẻ hơn nhiều

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng có cần giao thức SMB không | ⚠ nếu không thì Blob rẻ hơn | | Premium có đang cấp phát dư không | ⚠ trả theo phần cấp | | Có cần nhiều máy truy cập đồng thời không | |

Và lý do duy nhất thật sự cần Azure Files thay vì Blob Storage: ứng dụng của bạn nói giao thức SMB và cần một đường dẫn tệp. Ngoài trường hợp đó, Blob thường rẻ hơn và co giãn tốt hơn.

Câu 104 Non-relational data
Why would someone choose Azure Cosmos DB Table API instead of Azure Table Storage?
  1. A Programmable using an SDK in almost any programming language
  2. B Single-digit millisecond latency for reads and writes
  3. C It has a 99.99% SLA
  4. D Less expensive option
Xem giải thích

Đáp án

B — Độ trễ MỘT CHỮ SỐ mili giây cho cả đọc lẫn ghi.

Vì sao đúng

⚠ Đó là năng lực Cosmos DB có mà Table Storage không có: | Tiêu chí | Table Storage | Cosmos Table API | |---|---|---| | ⚠ Cam kết độ trễ | ⚠ KHÔNG | ⚠ dưới 10ms ở phân vị 99 | | ⚠ Chỉ mục | ⚠ chỉ khoá chính | ⚠ MỌI thuộc tính, tự động | | ⚠ Nhân bản toàn cầu | ⚠ giới hạn | ⚠ đa vùng chủ động | | ⚠ SLA sẵn sàng | ⚠ 99,9% | ⚠ tới 99,999% khi đa vùng | | ⚠ Chi phí | ⚠ RẺ HƠN NHIỀU | ⚠ đắt hơn |

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

  • D (lựa chọn rẻ hơn) — ⚠ NGƯỢC: ⚠ đó là lý do chọn ⚠ Table Storage.

  • A (lập trình bằng SDK ở hầu hết ngôn ngữ) — ⚠ CẢ HAI đều có SDK đa ngôn ngữ.

  • C (có SLA 99,99%) — ⚠ con số này gây nhầm: ⚠ Cosmos có SLA cao hơn nữa khi đa vùng, ⚠ và Table Storage cũng có SLA riêng; ⚠ đây không phải điểm phân biệt sắc nét như độ trễ.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp NGƯỢC hoàn hảo với #19502 ở lô trước.

Câu Hỏi gì Khoá
⚠ #19502 ⚠ vì sao chọn Table Storage thay Cosmos ⚠ RẺ NHẤT
⚠ #19594 (câu này) ⚠ vì sao chọn Cosmos thay Table Storage ⚠ độ trễ cam kết
⚠ Cặp đối xứng ⚠ hỏi ngược nhau nên khoá ngược nhau
⚠ Bẫy ⚠ mỗi câu đều có phương án là khoá của câu kia
⚠ Cách làm ⚠ xác định câu hỏi đang bênh vực dịch vụ NÀO trước khi đọc phương án

⚠ Chiến thuật cho dạng "vì sao chọn A thay vì B": | Bước | Cách | |---|---| | ⚠ Xác định A là dịch vụ ĐẮT hay RẺ | | | ⚠ Nếu A rẻ → khoá gần như luôn là GIÁ | | | ⚠ Nếu A đắt → khoá là NĂNG LỰC mà A có thêm | | | ⚠ Loại nhanh | ⚠ mọi phương án cả hai dịch vụ đều có |

Từ khoá nhận diện:

"độ trễ cam kết, toàn cầu, chỉ mục đầy đủ" → ⚠ Cosmos DB "rẻ nhất" → ⚠ Table Storage "SDK đa ngôn ngữ" → ⚠ cả hai, không phân biệt được

⚠ Khi nào việc nâng cấp là xứng đáng Khi nào
⚠ Ứng dụng nhạy độ trễ, người dùng cảm nhận được
⚠ Người dùng ở nhiều châu lục
⚠ Cần truy vấn theo trường không phải khoá
⚠ Cần SLA cao cho nghiệp vụ trọng yếu
⚠ Thuận lợi ⚠ cùng API nên mã nguồn thay đổi rất ít
⚠ Đường nâng cấp Đường
⚠ Bắt đầu bằng Table Storage
⚠ Đo độ trễ và chi phí thật
⚠ Chuyển sang Cosmos Table API khi cần
⚠ Ưu điểm ⚠ không phải quyết định đúng ngay từ đầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Câu hỏi đang bênh vực dịch vụ nào | ⚠ quyết định hướng trả lời | | Độ trễ hiện tại có thật sự là vấn đề không | | | Chênh lệch chi phí là bao nhiêu | |

Và cách xử lý gọn nhất cho cặp câu hỏi đối xứng kiểu này: hỏi xem dịch vụ được nêu trước là cái rẻ hay cái đắt. Cái rẻ thì lý do luôn là giá; cái đắt thì lý do luôn là một năng lực mà cái rẻ không có.

Câu 105 Non-relational DB
What type of non-relational data revolves around data that is formatted in a readable format (JSON, XML, YAML, etc)? It is sometimes called semi-structured data. It can support queries that require examining the contents of the data, such as a WHERE clause, but as well can support scaling globally for quick reads and writes.
  1. A Object data
  2. B Document data
  3. C Key-value data
  4. D Graph data
Xem giải thích

Đáp án

B — Dữ liệu TÀI LIỆU (document data).

Vì sao đúng

⚠ Đề mô tả chính xác mô hình tài liệu: | Đặc điểm đề nêu | Tài liệu | |---|---| | ⚠ Định dạng đọc được: JSON, XML, YAML | ⚠ đúng | | ⚠ Còn gọi là bán cấu trúc | ⚠ đúng | | ⚠ HỖ TRỢ truy vấn xét nội dung, có WHERE | ⚠ điểm phân biệt then chốt | | ⚠ Co giãn toàn cầu, đọc ghi nhanh | ⚠ Cosmos DB |

⚠ Khoá-giá trị: CSDL KHÔNG hiểu nội dung
⚠ Tài liệu:     CSDL HIỂU và đánh chỉ mục nội dung
        ↓
⚠ Đó là khác biệt duy nhất quan trọng

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

  • C (khoá-giá trị) — ⚠ bẫy chính: ⚠ cũng co giãn tốt, ⚠ nhưng ⚠ KHÔNG hỗ trợ truy vấn theo nội dung — ⚠ đề nói rõ là có.

  • A (đối tượng) — ⚠ cho tệp nhị phân.

  • D (đồ thị) — ⚠ cho quan hệ nhiều tầng.

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 #19555 ở lô trước.

Câu Mô tả trong đề Khoá
⚠ #19555 ⚠ KHÔNG tối ưu cho truy vấn nội dung ⚠ key-value
⚠ #19595 (câu này) ⚠ HỖ TRỢ truy vấn nội dung ⚠ document
⚠ Cặp đối xứng ⚠ cùng bộ phương án, khác một câu mô tả
⚠ Điểm phân định ⚠ có WHERE được hay không
⚠ Cùng với #19526, #19546, #19553 ⚠ sáu câu về mô hình dữ liệu qua hai lô

⚠ Năm mô hình phi quan hệ — bảng chốt cuối: | Mô hình | CSDL hiểu nội dung | Ví dụ | |---|---|---| | ⚠ Đối tượng | ⚠ KHÔNG | ⚠ Blob | | ⚠ Khoá-giá trị | ⚠ KHÔNG | ⚠ Table, Redis | | ⚠ Tài liệu | ⚠ CÓ | ⚠ Cosmos NoSQL | | ⚠ Cột rộng | ⚠ CÓ, theo cột | ⚠ Cassandra | | ⚠ Đồ thị | ⚠ CÓ, cả quan hệ | ⚠ Gremlin |

Từ khoá nhận diện:

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

⚠ Vì sao mô hình tài liệu phổ biến nhất Lý do
⚠ Cân bằng giữa linh hoạt và khả năng truy vấn
⚠ JSON khớp tự nhiên với đối tượng trong mã
⚠ Không cần ORM phức tạp
⚠ Dữ liệu lồng nhau lưu nguyên vẹn ⚠ không phải tách bảng
⚠ Đây là ⚠ lý do API NoSQL là mặc định của Cosmos DB
⚠ Đánh đổi của tài liệu Đánh đổi
⚠ Chỉ mục mọi trường tốn RU khi GHI
⚠ Tài liệu quá lớn thì đọc tốn kém
⚠ Dữ liệu lặp lại giữa các tài liệu ⚠ phi chuẩn hoá có chủ đích
⚠ Cập nhật dữ liệu lặp ⚠ phải sửa nhiều nơi — trách nhiệm của ứng dụng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cần lọc theo trường bên trong không | ⚠ câu hỏi phân định | | Tài liệu có quá lớn không | | | Có trường nào không cần đánh chỉ mục không | |

Và câu hỏi duy nhất phân định khoá-giá trị với tài liệu, đủ để trả lời cả cặp câu hỏi đối xứng này: cơ sở dữ liệu có cần HIỂU nội dung bên trong không?

Câu 106 Non-relational data management
Generally speaking, regardless of which region, which is the lowest cost redundancy option for Blob Storage?
  1. A LRS
  2. B ZRS
  3. C GRS
  4. D GZRS
Xem giải thích

Đáp án

A — LRS (Locally Redundant Storage).

Vì sao đúng

⚠ LRS là mức nhân bản đơn giản nhất nên rẻ nhất: | Mức | Bản sao | Phạm vi | Giá | |---|---|---|---| | ⚠ LRS | ⚠ 3 | ⚠ một trung tâm dữ liệu | ⚠ RẺ NHẤT | | ⚠ ZRS | ⚠ 3 | ⚠ ba zone | ⚠ cao hơn | | ⚠ GRS | ⚠ 6 | ⚠ hai vùng | ⚠ cao hơn nữa | | ⚠ GZRS | ⚠ 6 | ⚠ zone + vùng | ⚠ cao nhất |

⚠ Càng nhiều bản sao, càng xa nhau
        ↓
⚠ Càng chịu được sự cố lớn
        ↓
⚠ Càng đắt

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

  • B (ZRS), C (GRS), D (GZRS) — ⚠ đều đắt hơn LRS vì cung cấp mức bảo vệ cao hơn.

Ghi nhớ

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

Câu Hỏi gì Khoá
⚠ #19512 ⚠ ZRS giữ bao nhiêu bản ⚠ 3
⚠ #19562 ⚠ GRS giữ bao nhiêu bản ⚠ 6
⚠ #19596 (câu này) ⚠ mức nào rẻ nhất ⚠ LRS
⚠ Ba câu ⚠ cùng một bảng bốn mức
⚠ Mẹo ⚠ thuộc bảng bốn mức là ăn trọn cả chùm

⚠ Chọn mức nhân bản theo yêu cầu: | Yêu cầu | Chọn | |---|---| | ⚠ Rẻ nhất, dữ liệu dựng lại được | ⚠ LRS | | ⚠ Chịu mất một zone | ⚠ ZRS | | ⚠ Chịu mất cả vùng | ⚠ GRS | | ⚠ Chịu cả hai | ⚠ GZRS | | ⚠ Cần đọc ở vùng phụ | ⚠ RA-GRS hoặc RA-GZRS |

Từ khoá nhận diện:

"rẻ nhất" → ⚠ LRS "chịu mất một zone" → ⚠ ZRS "chịu mất cả vùng" → ⚠ GRS trở lên "đọc được ở vùng phụ" → ⚠ RA-

⚠ Khi nào LRS là đủ Khi nào
⚠ Dữ liệu tạm, dựng lại được từ nguồn khác
⚠ Môi trường dev và test
⚠ Dữ liệu đã có bản sao lưu ở nơi khác
⚠ Yêu cầu pháp lý buộc dữ liệu ở một nơi
⚠ Không nên dùng LRS cho ⚠ dữ liệu sản xuất không thể tái tạo
⚠ Đổi mức nhân bản sau khi tạo Đổi được không
⚠ LRS ↔ GRS: đổi trực tiếp được
⚠ Sang ZRS: cần chuyển đổi hoặc tạo mới ⚠ phức tạp hơn
⚠ Nên ⚠ cân nhắc ngay từ lúc tạo tài khoản
⚠ Nhắc lại lần cuối Nhắc lại
⚠ Nhân bản KHÔNG phải sao lưu
⚠ Sáu bản của một tệp đã xoá vẫn là sáu bản không có gì
⚠ Vẫn cần ⚠ soft delete, versioning, sao lưu độc lập

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu này có tái tạo được không | ⚠ quyết định LRS có đủ không | | Có ràng buộc pháp lý về nơi lưu không | | | Đã có soft delete và versioning chưa | |

Và cách tiết kiệm chi phí lưu trữ ít rủi ro nhất, thường bị bỏ qua: hạ mức nhân bản cho các tài khoản dev và test xuống LRS. Dữ liệu ở đó dựng lại được, và không có lý do gì trả tiền cho sáu bản sao ở hai vùng.

Câu 107 Non-relational data management
Cosmos DB measures its performance in terms of Request Units per second (RU/s). What is a Request Unit?
  1. A Reading, writing, and updating data takes 1 Request Unit each
  2. B Each read request takes 1 Request Unit
  3. C Each read request takes 1 Request Unit per partition
  4. D The amount of resources roughly required to read one 1KB document with 10 fields.
Xem giải thích

Đáp án

D — Lượng tài nguyên xấp xỉ cần để ĐỌC MỘT tài liệu 1KB có 10 trường.

Vì sao đúng

⚠ RU là đơn vị TRỪU TƯỢNG gói gọn CPU, IOPS và bộ nhớ:

⚠ Chuẩn tham chiếu
   ⚠ đọc 1 tài liệu 1KB, 10 trường
   ⚠ theo id và partition key
        ↓
⚠ = 1 RU
        ↓
⚠ Mọi thao tác khác quy đổi theo chuẩn này
Thao tác RU tương đối
⚠ Đọc theo id + partition key ⚠ 1 RU cho 1KB
⚠ GHI cùng tài liệu đó ⚠ khoảng 5 RU
⚠ Truy vấn có lọc ⚠ nhiều hơn, tuỳ chỉ mục
⚠ Truy vấn CHÉO phân vùng ⚠ tốn nhất

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

  • B (mỗi lần đọc tốn 1 RU) — ⚠ quá đơn giản: ⚠ tài liệu lớn hơn tốn nhiều RU hơn.

  • A (đọc, ghi, cập nhật mỗi cái 1 RU) — ⚠ SAI: ⚠ ghi tốn nhiều hơn đọc đáng kể.

  • C (mỗi lần đọc tốn 1 RU mỗi phân vùng) — ⚠ không phải cách tính.

Ghi nhớ

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

Câu Hỏi gì Khoá
⚠ #19520 ⚠ RU/s tối thiểu ⚠ 400
⚠ #19549 ⚠ hệ quả của cấp dư RU ⚠ vẫn trả tiền phần đã cấp
⚠ #19597 (câu này) ⚠ RU là gì ⚠ tài nguyên để đọc 1KB, 10 trường
⚠ Ba câu ⚠ định nghĩa, hạn mức, chi phí — trọn chủ đề RU

⚠ Điều làm tốn RU — bảng thực dụng: | Yếu tố | Ảnh hưởng | |---|---| | ⚠ Kích thước tài liệu | ⚠ tuyến tính | | ⚠ Ghi so với đọc | ⚠ ghi tốn gấp nhiều lần | | ⚠ Số trường được đánh chỉ mục | ⚠ tốn khi GHI | | ⚠ Truy vấn chéo phân vùng | ⚠ tốn nhất | | ⚠ Mức nhất quán mạnh | ⚠ đọc tốn gấp đôi | | ⚠ Số kết quả trả về | |

Từ khoá nhận diện:

"đơn vị tài nguyên, 1KB, 10 trường" → ⚠ định nghĩa RU "tối thiểu 400" → ⚠ hạn mức cấp phát "lỗi 429" → ⚠ vượt RU đã cấp "trả cho phần cấp phát" → ⚠ chế độ provisioned

⚠ Cách đo RU thực tế Cách
⚠ Mỗi phản hồi API trả về header x-ms-request-charge
⚠ Cho biết truy vấn đó tốn bao nhiêu RU
⚠ Đo trước khi tối ưu
⚠ Thói quen tốt ⚠ log RU của các truy vấn quan trọng
⚠ Ước lượng RU cần cấp Cách
⚠ Đo RU mỗi loại thao tác
⚠ Nhân với số thao tác mỗi giây
⚠ Cộng lại, thêm biên an toàn
⚠ Hoặc ⚠ dùng autoscale để khỏi phải ước lượng chính xác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn nào tốn RU nhất | ⚠ đọc header request-charge | | Có truy vấn chéo phân vùng nào không | | | Mức nhất quán có cao hơn mức cần thiết không | |

Và công cụ đo lường sẵn có mà ít người dùng khi tối ưu Cosmos DB: header x-ms-request-charge trong mỗi phản hồi. Nó nói chính xác từng truy vấn tốn bao nhiêu, và đó là nơi mọi việc tối ưu nên bắt đầu.

Câu 108 Analytics workload
Which type of data analytics workload is best for processing data that is large, complex and takes a significant amount of time to process?
  1. A Batch processing
  2. B Azure Stream Analytics
  3. C Azure Function Web Trigger
  4. D Real-time processing
Xem giải thích

Đáp án

A — Xử lý theo LÔ (batch processing).

Vì sao đúng

⚠ Ba đặc điểm trong đề đều là dấu hiệu của xử lý theo lô: | Đặc điểm | Kết luận | |---|---| | ⚠ Dữ liệu LỚN | ⚠ cần thông lượng, không cần độ trễ thấp | | ⚠ PHỨC TẠP | ⚠ nhiều bước biến đổi | | ⚠ Mất NHIỀU THỜI GIAN | ⚠ chấp nhận chờ |

⚠ Gom dữ liệu thành khối
        ↓
⚠ Xử lý một lần, tận dụng tối đa tài nguyên
        ↓
⚠ Kết quả có sau vài phút tới vài giờ
        ↓
⚠ Rẻ hơn nhiều so với xử lý liên tục

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

  • D (real-time) và B (Stream Analytics) — ⚠ cho dữ liệu cần kết quả trong VÀI GIÂY; ⚠ đề nói rõ ⚠ mất nhiều thời gian để xử lý.

  • C (Azure Function Web Trigger) — ⚠ là cơ chế kích hoạt hàm qua HTTP, ⚠ có giới hạn thời gian thực thi, ⚠ không hợp cho việc chạy lâu.

Ghi nhớ

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

Câu Mô tả trong đề Khoá
⚠ #19516 ⚠ dữ liệu về MỘT LẦN MỖI NGÀY ⚠ batch
⚠ #19537 ⚠ vài GIÂY một lần, nhạy thời gian ⚠ real-time
⚠ #19598 (câu này) ⚠ lớn, phức tạp, xử lý lâu ⚠ batch
⚠ Ba câu ⚠ cùng một trục, ba cách mô tả
⚠ Điểm chung của batch ⚠ không có yêu cầu về độ trễ

⚠ Nhận diện nhanh batch hay stream: | Đề nói | Kết luận | |---|---| | ⚠ "mỗi ngày", "cuối tháng", "hàng đêm" | ⚠ batch | | ⚠ "mất nhiều thời gian xử lý" | ⚠ batch | | ⚠ "khối lượng lớn, phức tạp" | ⚠ batch | | ⚠ "ngay lập tức", "vài giây" | ⚠ stream | | ⚠ "cảnh báo tức thì" | ⚠ stream | | ⚠ "cảm biến gửi liên tục" | ⚠ stream |

Từ khoá nhận diện:

"lớn, phức tạp, lâu" → ⚠ batch "tức thì, liên tục" → ⚠ stream "hàm chạy khi có HTTP request" → ⚠ cơ chế kích hoạt, không phải mô hình phân tích

⚠ Dịch vụ Azure cho batch quy mô lớn Dịch vụ
⚠ Data Factory / Synapse pipeline ⚠ điều phối
⚠ Databricks, Synapse Spark ⚠ tính toán phân tán
⚠ Azure Batch ⚠ chạy công việc tính toán quy mô lớn
⚠ HDInsight ⚠ Hadoop, Spark, Hive
⚠ Thiết kế công việc theo lô Nguyên tắc
⚠ Chia nhỏ để chạy SONG SONG
⚠ Có điểm kiểm tra để chạy tiếp khi lỗi
⚠ Chạy lại được mà không nhân đôi dữ liệu
⚠ Chạy vào giờ thấp điểm nếu chia sẻ tài nguyên
⚠ Quan trọng nhất ⚠ đừng để một lỗi ở phút thứ 55 bắt chạy lại từ đầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết quả chậm bao lâu thì vẫn dùng được | | | Công việc có chia nhỏ chạy song song được không | | | Lỗi giữa chừng có phải chạy lại từ đầu không | |

Và thiết kế quyết định một quy trình xử lý theo lô có vận hành được lâu dài hay không: khả năng chạy tiếp từ điểm dừng. Một công việc bốn tiếng mà lỗi ở phút cuối bắt làm lại từ đầu sẽ khiến cả đội sợ chạm vào nó.

Câu 109 Non-relational data
Which Azure storage solution allows you to mount the storage as a drive in Windows Servers and assign it a drive letter using the SMB protocol
  1. A Azure Blob Storage
  2. B Azure File Storage
  3. C Azure Data Lake
  4. D Azure Table Storage
Xem giải thích

Đáp án

B — Azure File Storage.

Vì sao đúng

⚠ Azure Files là dịch vụ duy nhất nói giao thức SMB:

⚠ Windows Server
   ⚠ net use Z: \\taikhoan.file.core.windows.net\share
        ↓
⚠ Ổ đĩa Z: xuất hiện như ổ mạng thường
        ↓
⚠ Ứng dụng cũ dùng đường dẫn tệp chạy được ngay
Đặc điểm Nội dung
⚠ SMB 3.0 và NFS 4.1
⚠ NHIỀU máy gắn cùng lúc
⚠ Gắn được từ Windows, Linux, macOS
⚠ Dùng được từ tại chỗ qua VPN
⚠ Xác thực bằng AD DS hoặc Entra ID

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

  • A (Blob Storage) — ⚠ truy cập qua REST API hoặc SDK; ⚠ có công cụ mount như blobfuse nhưng ⚠ không phải SMB gốc.

  • C (Data Lake) — ⚠ là Blob có namespace phân cấp, ⚠ truy cập qua ABFS.

  • D (Table Storage) — ⚠ kho khoá-giá trị, không phải hệ tệp.

Ghi nhớ

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

Câu Hỏi gì Khoá
⚠ #19105 ⚠ file server nhiều chi nhánh ⚠ File share + File Sync + GRS
⚠ #19593 ⚠ Standard và Premium file share khác gì ⚠ HDD và SSD
⚠ #19599 (câu này) ⚠ dịch vụ nào mount được bằng SMB ⚠ Azure Files
⚠ Ba câu ⚠ cùng chủ đề Azure Files

⚠ Bốn dịch vụ trong Storage Account — chọn theo cách truy cập: | Cách truy cập | Dịch vụ | |---|---| | ⚠ Mount như ổ đĩa (SMB/NFS) | ⚠ Files | | ⚠ REST API, URL | ⚠ Blob | | ⚠ Truy vấn theo khoá | ⚠ Table | | ⚠ Hàng đợi tin nhắn | ⚠ Queue |

Từ khoá nhận diện:

"mount, gán ký tự ổ đĩa, SMB" → ⚠ Azure Files "URL, tải lên tải xuống" → ⚠ Blob "phân tích dữ liệu lớn" → ⚠ Data Lake "nhiều máy cùng ghi một thư mục" → ⚠ Files

⚠ Khi nào phải dùng Files thay vì Blob Khi nào
⚠ Ứng dụng cũ chỉ biết đường dẫn tệp
⚠ Cần khoá tệp và quyền NTFS
⚠ Nhiều máy chủ chia sẻ cấu hình hoặc dữ liệu
⚠ Lift-and-shift ứng dụng lên đám mây
⚠ Ngoài ra ⚠ Blob rẻ hơn và co giãn tốt hơn
⚠ Cảnh báo về cổng 445 Cảnh báo
⚠ SMB dùng cổng 445
⚠ Nhiều nhà mạng CHẶN cổng này ra Internet
⚠ Triệu chứng: mount được ở Azure, không mount được từ nhà
⚠ Giải pháp ⚠ VPN, ExpressRoute, hoặc private endpoint
⚠ Đây là ⚠ sự cố phổ biến nhất khi mới dùng Azure Files

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cổng 445 có bị chặn không | ⚠ nguyên nhân số một | | Ứng dụng có thật sự cần SMB không | | | Xác thực bằng khoá hay bằng danh tính | |

Và nguyên nhân số một khiến việc kết nối Azure Files thất bại từ mạng ngoài, gần như không bao giờ đoán ra ngay: nhà mạng chặn cổng 445. Trong Azure thì chạy, từ văn phòng thì không, và cấu hình phía Azure hoàn toàn đúng.

Câu 110 Non-relational data management
Through what method can you enable single sign-on for Cosmos DB, so that users can use their corporate user name and password to access the contents of that database?
  1. A Enable Azure AD Authentication
  2. B Grant the user access to the Cosmos DB Reader role in RBAC
  3. C Enable Privileged Identity Management
  4. D Enable Azure AD Conditional Access
Xem giải thích

Đáp án

A — Bật xác thực bằng Azure AD (Entra ID).

Vì sao đúng

⚠ SSO nghĩa là dùng chính tài khoản công ty, và đó là việc của Entra ID:

⚠ Trước: mỗi người một khoá hoặc token riêng
        ↓ ⚠ bật Entra ID authentication
⚠ Người dùng đăng nhập bằng tài khoản công ty
        ↓
⚠ Token Entra ID được dùng để truy cập Cosmos DB
        ↓
⚠ Một danh tính, một lần đăng nhập
Lợi ích Nội dung
⚠ Không phải quản lý khoá riêng
⚠ Thu hồi truy cập bằng cách khoá tài khoản
⚠ Áp dụng được MFA và Conditional Access
⚠ Có nhật ký đăng nhập đầy đủ

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

  • B (cấp vai trò Cosmos DB Reader trong RBAC) — ⚠ là bước PHÂN QUYỀN sau khi đã xác thực; ⚠ nó không tự bật SSO.

  • C (Privileged Identity Management) — ⚠ quản lý quyền cao có thời hạn, không phải cơ chế đăng nhập.

  • D (Conditional Access) — ⚠ đặt ĐIỀU KIỆN cho việc đăng nhập, ⚠ hoạt động ⚠ trên nền Entra ID đã bật.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp với #19604 trong cùng lô — ⚠ cùng khoá Entra ID authentication, ⚠ chỉ khác dịch vụ.

Câu Dịch vụ Khoá
⚠ #19600 (câu này) ⚠ Cosmos DB ⚠ Entra ID authentication
⚠ #19604 ⚠ Azure SQL Database ⚠ Entra ID authentication
⚠ Cùng nguyên lý ⚠ thay xác thực cục bộ bằng danh tính tập trung
⚠ Không mâu thuẫn ⚠ hai dịch vụ, một giải pháp

⚠ Phân biệt bốn khái niệm danh tính: | Khái niệm | Việc | |---|---| | ⚠ Authentication | ⚠ BẠN LÀ AI | | ⚠ Authorization (RBAC) | ⚠ được làm GÌ | | ⚠ Conditional Access | ⚠ ĐIỀU KIỆN để được vào | | ⚠ PIM | ⚠ quyền cao chỉ khi cần | | ⚠ Thứ tự | ⚠ xác thực trước, phân quyền sau |

Từ khoá nhận diện:

"đăng nhập một lần, tài khoản công ty" → ⚠ Entra ID authentication "cấp vai trò" → ⚠ RBAC, bước sau "bắt MFA khi ở ngoài văn phòng" → ⚠ Conditional Access "quyền quản trị có thời hạn" → ⚠ PIM

⚠ Vì sao nên bỏ xác thực bằng khoá Lý do
⚠ Khoá không gắn với con người cụ thể
⚠ Không biết ai đã dùng
⚠ Không áp được MFA
⚠ Thu hồi phải đổi khoá cho mọi ứng dụng
⚠ Với danh tính ⚠ khoá một tài khoản là xong
⚠ Với ứng dụng thì sao Cách
⚠ Dùng MANAGED IDENTITY
⚠ Ứng dụng có danh tính riêng trong Entra ID
⚠ Không cần lưu bí mật nào
⚠ Kết hợp ⚠ người dùng đăng nhập SSO, ứng dụng dùng managed identity

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn ai dùng khoá tài khoản không | | | Ứng dụng đã dùng managed identity chưa | | | Có nhật ký ai truy cập dữ liệu không | |

Và lợi ích lớn nhất của việc chuyển sang danh tính tập trung, quan trọng hơn cả sự tiện lợi của một lần đăng nhập: khi ai đó nghỉ việc, khoá một tài khoản là cắt được mọi quyền truy cập của họ.