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

Tìm thấy 328 câu.

Câu 31 Non-relational DB
You need a non-relational data store that supports key-value storage. This needs to be the most cost-effective way for storing data in Azure as you are expecting a large volume of data that needs to be sorted, processed and cleaned up before being migrated into another long-term data format. Which non-relational data store do you recommend?
  1. A Azure Table Storage
  2. B Cosmos DB
  3. C Azure Data Lake Storage Gen2
  4. D Azure SQL Database
Xem giải thích

Đáp án

A — Azure Table Storage.

Vì sao đúng

⚠ Đề nêu ba ràng buộc, cả ba đều dẫn về Table Storage: | Ràng buộc | Table Storage | |---|---| | ⚠ Phi quan hệ, khoá-giá trị | ⚠ đúng mô hình | | ⚠ TIẾT KIỆM CHI PHÍ NHẤT | ⚠ rẻ nhất trong nhóm | | ⚠ Dữ liệu tạm, sẽ chuyển đi sau | ⚠ không cần tính năng cao cấp |

⚠ Dữ liệu khối lượng lớn
   ⚠ chỉ để sắp xếp, xử lý, dọn dẹp
   ⚠ rồi chuyển sang định dạng dài hạn
        ↓
⚠ Không cần độ trễ cam kết
⚠ Không cần toàn cầu
        ↓
⚠ Trả tiền cho những thứ đó là lãng phí

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

  • B (Cosmos DB) — ⚠ đắt hơn nhiều: ⚠ trả cho độ trễ cam kết và nhân bản toàn cầu mà kịch bản này không dùng tới.

  • C (Data Lake Gen2) — ⚠ không phải kho khoá-giá trị; ⚠ nó cho phân tích tệp quy mô lớn.

  • D (Azure SQL Database) — ⚠ là CSDL QUAN HỆ, trái yêu cầu đề.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ cùng khoá và cùng lý do với #19502 ở lô trước.

Câu Hỏi gì Khoá
⚠ #19496 ⚠ cái nào là kho khoá-giá trị ⚠ Table Storage, Redis, Cosmos Table API
⚠ #19502 ⚠ vì sao chọn Table Storage thay Cosmos ⚠ rẻ nhất
⚠ #19521 (câu này) ⚠ chọn kho nào cho tình huống ⚠ Table Storage
⚠ Ba câu ⚠ cùng một kiến thức, ba cách hỏi
⚠ Nhận xét ⚠ bộ đề Data Fundamentals lặp rất nhiều — nắm chắc một lần ăn cả chùm

⚠ Ràng buộc trong đề quyết định đáp án: | Ràng buộc đề nêu | Kết luận | |---|---| | ⚠ "tiết kiệm chi phí nhất" | ⚠ loại mọi dịch vụ cao cấp | | ⚠ "khoá-giá trị" | ⚠ loại quan hệ và data lake | | ⚠ "dữ liệu tạm" | ⚠ không cần bền vững cao cấp | | ⚠ Cách đọc đề | ⚠ gạch chân từng ràng buộc rồi loại dần |

Từ khoá nhận diện:

"rẻ nhất, khoá-giá trị" → ⚠ Table Storage "toàn cầu, độ trễ cam kết" → ⚠ Cosmos DB "phân tích tệp lớn, Spark" → ⚠ Data Lake Gen2 "cache trong bộ nhớ" → ⚠ Redis

⚠ Dữ liệu tạm — mẫu kiến trúc thường gặp Mẫu
⚠ Nạp thô vào kho rẻ
⚠ Xử lý, làm sạch, chuẩn hoá
⚠ Ghi kết quả sang định dạng phân tích ⚠ Parquet trên Data Lake
⚠ Xoá dữ liệu thô sau thời hạn
⚠ Tiết kiệm ⚠ không giữ dữ liệu thô ở kho đắt tiền

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu này giữ tạm hay lâu dài | | | Có cần tính năng cao cấp nào thật sự không | | | Đã có kế hoạch dọn dữ liệu tạm chưa | |

Và nguyên tắc chọn dịch vụ tiết kiệm nhất, đúng với cả kỳ thi lẫn hoá đơn thật: đừng trả tiền cho năng lực mà kịch bản của bạn không dùng tới. Độ trễ cam kết và nhân bản toàn cầu là hai thứ đắt nhất và bị mua thừa nhiều nhất.

Câu 32 Power BI
You are a Power BI report designer, and in talking with the client, they are looking for a sales report that lists all of the cars sold in the past month. Each row represents one car sold, and each column contains the characteristics of the sale including the make and model, who sold it, the date sold, and the amount it sold for. The client expects there are thousands of rows per month, but they want this report anyways. Which type of report should you create for them in Power BI?
  1. A Paginated Reports
  2. B A one-page report with thousands of rows
  3. C Dashboard
  4. D Jupyter Notebook
Xem giải thích

Đáp án

A — Paginated Reports (báo cáo phân trang).

Vì sao đúng

⚠ Đề mô tả đúng kịch bản của báo cáo phân trang: | Yêu cầu | Paginated Report | |---|---| | ⚠ Liệt kê MỌI dòng, mỗi xe một dòng | ⚠ bảng dài, không tổng hợp | | ⚠ Hàng nghìn dòng | ⚠ tự chia trang | | ⚠ Định dạng chuẩn để in và xuất | ⚠ PDF, Word, Excel chuẩn từng pixel |

⚠ Interactive report
   ⚠ tối ưu cho MÀN HÌNH
   ⚠ hàng nghìn dòng thì cuộn mỏi mắt

⚠ Paginated report
   ⚠ tối ưu cho TRANG GIẤY
   ⚠ tự ngắt trang, lặp tiêu đề cột

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

  • B (báo cáo một trang với hàng nghìn dòng) — ⚠ không phải loại báo cáo, ⚠ và cách trình bày đó không dùng được.

  • C (Dashboard) — ⚠ MỘT trang tổng quan, ⚠ không phải nơi liệt kê chi tiết.

  • D (Jupyter Notebook) — ⚠ công cụ phân tích cho lập trình viên, ⚠ không phải báo cáo nghiệp vụ.

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 #19491 ở lô trước — ⚠ hai câu cùng bộ khái niệm nhưng ⚠ khoá ngược nhau.

Câu Yêu cầu Khoá
⚠ #19491 ⚠ tự lọc, đổi cột sắp xếp, drill-through ⚠ Interactive Report
⚠ #19522 (câu này) ⚠ liệt kê hàng nghìn dòng, in ra ⚠ Paginated Report
⚠ KHÔNG mâu thuẫn ⚠ hai nhu cầu khác nhau
⚠ Điểm phân biệt ⚠ KHÁM PHÁ trên màn hình hay IN ra giấy

⚠ Interactive và Paginated — bảng đối chiếu: | Tiêu chí | Interactive | Paginated | |---|---|---| | ⚠ Tối ưu cho | ⚠ màn hình | ⚠ trang in | | ⚠ Số dòng | ⚠ tổng hợp, ít dòng | ⚠ hàng nghìn dòng | | ⚠ Tương tác | ⚠ cao | ⚠ thấp | | ⚠ Công cụ tạo | ⚠ Power BI Desktop | ⚠ Report Builder | | ⚠ Giấy phép | ⚠ Pro | ⚠ cần Premium hoặc PPU |

Từ khoá nhận diện:

"in ra, hoá đơn, mỗi dòng một bản ghi" → ⚠ Paginated "khám phá, lọc, drill-through" → ⚠ Interactive "một màn hình tổng quan" → ⚠ Dashboard "xuất PDF nhiều trang có tiêu đề lặp" → ⚠ Paginated

⚠ Nguồn gốc của Paginated Report Nguồn gốc
⚠ Kế thừa từ SQL Server Reporting Services (SSRS)
⚠ Dùng cùng định dạng RDL
⚠ Chuyển báo cáo SSRS cũ lên được
⚠ Vì vậy ⚠ rất mạnh về bố cục in ấn
⚠ Khi nào doanh nghiệp cần Paginated Khi nào
⚠ Hoá đơn, phiếu lương, chứng từ
⚠ Báo cáo tuân thủ nộp cơ quan quản lý
⚠ Sao kê gửi khách hàng
⚠ Đặc điểm chung ⚠ bố cục PHẢI chính xác và cố định

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết quả sẽ được xem trên màn hình hay in ra | | | Có bao nhiêu dòng dữ liệu | | | Giấy phép hiện có đủ cho Paginated không | ⚠ cần Premium hoặc PPU |

Và câu hỏi phân định hai loại báo cáo Power BI nhanh nhất: kết quả này sẽ được cuộn trên màn hình hay được in ra và ký? Bố cục cố định để in là lãnh địa riêng của báo cáo phân trang.

Câu 33 Non-relational DB
How many databases can you create in a single Cosmos DB account?
  1. A 100
  2. B 1
  3. C 10
  4. D Unlimited
Xem giải thích

Đáp án

D — Không giới hạn.

Vì sao đúng

⚠ Cosmos DB không đặt trần cứng cho số database trong một tài khoản:

⚠ Cosmos DB account
   ⚠ Database 1
      ⚠ Container A, B, C
   ⚠ Database 2
      ⚠ Container D, E
   ⚠ ... không giới hạn
Cấp Vai trò
⚠ Account ⚠ đơn vị cao nhất, chọn API và vùng ở đây
⚠ Database ⚠ nhóm logic các container
⚠ Container ⚠ nơi chứa item, đơn vị co giãn
⚠ Item ⚠ tài liệu, hàng, đỉnh — tuỳ API

⚠ Giới hạn thực tế đến từ THÔNG LƯỢNG và CHI PHÍ, ⚠ không phải từ số lượng database.

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

  • A (100), B (1), C (10) — ⚠ đều là con số bịa: ⚠ không có trần nào như vậy.

Ghi nhớ

⚠ Phân cấp Cosmos DB — điều gì đặt ở cấp nào: | Thiết lập | Cấp | |---|---| | ⚠ Chọn API | ⚠ ACCOUNT — không đổi được sau | | ⚠ Vùng và nhân bản | ⚠ account | | ⚠ Mức nhất quán mặc định | ⚠ account | | ⚠ Thông lượng dùng chung | ⚠ database (tuỳ chọn) | | ⚠ Partition key | ⚠ CONTAINER — không đổi được sau | | ⚠ Chính sách chỉ mục | ⚠ container | | ⚠ TTL | ⚠ container, ghi đè được ở từng item |

Từ khoá nhận diện:

"chọn API, chọn vùng" → ⚠ cấp account "partition key, chỉ mục, TTL" → ⚠ cấp container "thông lượng dùng chung" → ⚠ cấp database

⚠ TTL — tính năng đáng nhớ Nội dung
⚠ Tự XOÁ item sau N giây
⚠ Đặt ở container, ghi đè ở từng item
⚠ Việc xoá tiêu tốn RU dư thừa, không tính thêm tiền
⚠ Hữu ích cho ⚠ dữ liệu phiên, log, cache, dữ liệu tạm
⚠ Thay thế ⚠ các job dọn dẹp định kỳ tự viết
⚠ Chính sách chỉ mục — nơi tiết kiệm RU Nội dung
⚠ Mặc định đánh chỉ mục MỌI trường
⚠ Tốn RU ở mỗi lần GHI
⚠ Loại trừ trường không bao giờ lọc theo
⚠ Với khối lượng ghi lớn ⚠ tiết kiệm đáng kể
⚠ Quyết định không sửa được Quyết định
⚠ API của account
⚠ Partition key của container
⚠ Muốn đổi ⚠ phải tạo mới và di chuyển dữ liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | API và partition key đã cân nhắc kỹ chưa | ⚠ không sửa được | | Có trường nào không cần chỉ mục không | | | Dữ liệu tạm đã bật TTL chưa | |

Và tính năng của Cosmos DB tiết kiệm được nhiều công sức vận hành nhất mà ít người bật ngay từ đầu: TTL tự động xoá. Nó thay thế hẳn những job dọn dẹp định kỳ vốn hay hỏng và hay bị quên.

Câu 34 Non-relational data management
When it comes to data security, what is the principle of least privilege?
  1. A Users are only granted permissions for the specific task that they are trying to do, at the moment they are trying to do it.
  2. B Users access rights should be reviewed regularly, every month or every quarter, to ensure that they still require access to the resources they have access to.
  3. C Users only have the permissions they need to complete their job, and no more.
  4. D Administrative users should be forced to use MFA when logging in.
Xem giải thích

Đáp án

C — Người dùng CHỈ có những quyền cần thiết để hoàn thành công việc của họ, và không hơn.

Vì sao đúng

⚠ Đó chính là định nghĩa chuẩn của principle of least privilege:

⚠ Câu hỏi khi cấp quyền
   ⚠ "Người này CẦN gì để làm việc?"
   ⚠ KHÔNG phải "cấp cho rộng cho tiện"
        ↓
⚠ Cấp đúng mức, không hơn
        ↓
⚠ Tài khoản bị chiếm → thiệt hại giới hạn
Lợi ích Nội dung
⚠ Giảm thiệt hại khi tài khoản bị chiếm
⚠ Giảm sai sót do thao tác nhầm
⚠ Dễ kiểm toán và tuân thủ

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

  • A (chỉ được cấp quyền cho tác vụ cụ thể, ngay lúc cần) — ⚠ là mô tả của JIT: ⚠ một ⚠ cách thực hiện đặc quyền tối thiểu trên trục thời gian, ⚠ không phải định nghĩa của nguyên tắc.

  • B (rà soát quyền định kỳ hằng tháng, hằng quý) — ⚠ là Access Reviews, ⚠ biện pháp ⚠ duy trì nguyên tắc.

  • D (buộc quản trị viên dùng MFA) — ⚠ thuộc XÁC THỰC MẠNH, ⚠ không liên quan tới phạm vi quyền.

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 #19515 trong cùng lô, ⚠ và cần đọc kỹ để không nhầm.

Câu Hỏi gì Khoá Vì sao
⚠ #19515 ⚠ VÍ DỤ của đặc quyền tối thiểu ⚠ JIT ⚠ JIT là cách hiện thực
⚠ #19524 (câu này) ⚠ ĐỊNH NGHĨA của nguyên tắc ⚠ chỉ có quyền cần thiết ⚠ định nghĩa gốc
⚠ Bẫy ⚠ phương án A ở đây chính là JIT — khoá của câu kia
⚠ KHÔNG mâu thuẫn ⚠ một hỏi ví dụ, một hỏi định nghĩa
⚠ Bài học đọc đề ⚠ phân biệt "là gì" với "ví dụ nào"

⚠ Bốn khái niệm bảo mật dễ lẫn: | Khái niệm | Nội dung | |---|---| | ⚠ Least privilege | ⚠ quyền HẸP nhất đủ dùng | | ⚠ JIT | ⚠ quyền chỉ tồn tại KHI CẦN | | ⚠ Zero trust | ⚠ không tin mặc định, xác minh mọi lần | | ⚠ Defense in depth | ⚠ nhiều lớp phòng thủ chồng lên nhau |

Từ khoá nhận diện:

"chỉ quyền cần thiết, không hơn" → ⚠ least privilege "chỉ khi cần, có thời hạn" → ⚠ JIT "xác minh mọi lần, không tin mạng nội bộ" → ⚠ zero trust "nhiều lớp bảo vệ" → ⚠ defense in depth

⚠ Ba nguyên tắc của Zero Trust Nguyên tắc
⚠ Xác minh tường minh ⚠ luôn xác thực và cấp quyền dựa trên mọi tín hiệu
⚠ Dùng đặc quyền tối thiểu ⚠ JIT và JEA
⚠ Giả định đã bị xâm nhập ⚠ phân đoạn, mã hoá, giám sát
⚠ Least privilege ⚠ là MỘT trong ba trụ của zero trust
⚠ Áp dụng vào Azure Cách
⚠ Dùng vai trò dựng sẵn hẹp nhất ⚠ Reader thay vì Contributor
⚠ Gán ở phạm vi hẹp nhất ⚠ resource group thay vì subscription
⚠ Dùng PIM cho vai trò quản trị
⚠ Rà soát định kỳ bằng Access Reviews

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có ai đang giữ Owner mà chỉ cần Reader không | | | Quyền gán ở phạm vi nào | | | Có rà soát định kỳ không | |

Và cách phân biệt hai câu hỏi rất giống nhau trong cùng một đề thi: "nguyên tắc này là gì" hỏi định nghĩa, "ví dụ nào của nguyên tắc" hỏi cách hiện thực. Cùng một bộ phương án có thể có hai đáp án khác nhau tuỳ vào chữ đầu tiên của câu hỏi.

Câu 35 Relational data
What is the difference between a clustered and unclustered index in SQL Server?
  1. A A clustered index sort and store the data rows based on their key values. Nonclustered indexes have a structure separate from the data rows.
  2. B There is no performance cost to inserting data into a table with a clustered index, while inserting data into a table with an nonclustered index is an expensive operation.
  3. C A clustered index uses a single column as a key, while a nonclustered index uses multiple columns.
  4. D A nonclustered index sort and store the data rows based on their key values. Clustered indexes have a structure separate from the data rows.
Xem giải thích

Đáp án

A — Chỉ mục CLUSTERED sắp xếp và LƯU chính các dòng dữ liệu theo giá trị khoá; chỉ mục NONCLUSTERED có cấu trúc TÁCH RIÊNG khỏi dòng dữ liệu.

Vì sao đúng

⚠ Khác biệt nằm ở chỗ dữ liệu THẬT nằm ở đâu:

⚠ CLUSTERED
   ⚠ Chính bảng ĐƯỢC SẮP XẾP theo khoá
   ⚠ Lá của cây B chứa DÒNG DỮ LIỆU
        ↓
⚠ Mỗi bảng CHỈ CÓ MỘT

⚠ NONCLUSTERED
   ⚠ Cấu trúc RIÊNG, chứa khoá + con trỏ
   ⚠ Trỏ về dòng dữ liệu thật
        ↓
⚠ Mỗi bảng có NHIỀU
Đặc điểm Clustered Nonclustered
⚠ Số lượng tối đa ⚠ 1 ⚠ nhiều (999)
⚠ Lá chứa ⚠ dữ liệu thật ⚠ con trỏ
⚠ Bảng không có ⚠ gọi là heap

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

  • D — ⚠ đảo ngược hai vế; ⚠ bẫy đối xứng.

  • B (chèn dữ liệu vào bảng có clustered index không tốn chi phí) — ⚠ SAI: ⚠ mọi chỉ mục đều làm chậm việc GHI.

  • C (clustered dùng một cột, nonclustered dùng nhiều cột) — ⚠ SAI: ⚠ cả hai đều ⚠ ghép nhiều cột được.

Ghi nhớ

⚠ Đánh đổi cơ bản của chỉ mục: | Ảnh hưởng | Nội dung | |---|---| | ⚠ ĐỌC nhanh hơn | ⚠ tìm theo khoá thay vì quét bảng | | ⚠ GHI chậm hơn | ⚠ mỗi INSERT/UPDATE phải cập nhật chỉ mục | | ⚠ Tốn dung lượng | | | ⚠ Vì vậy | ⚠ đừng đánh chỉ mục mọi cột |

Từ khoá nhận diện:

"sắp xếp chính dòng dữ liệu" → ⚠ clustered "cấu trúc riêng, có con trỏ" → ⚠ nonclustered "bảng không có clustered index" → ⚠ heap "chỉ mục chứa luôn cột cần lấy" → ⚠ covering index

⚠ Chọn khoá cho clustered index Nguyên tắc
⚠ Hẹp (ít byte) ⚠ vì mọi nonclustered đều tham chiếu tới nó
⚠ Duy nhất
⚠ TĂNG DẦN ⚠ tránh chia trang khi chèn
⚠ Ít thay đổi
⚠ Thường là ⚠ cột identity hoặc khoá chính
⚠ Covering index — kỹ thuật đáng biết Nội dung
⚠ Chỉ mục chứa đủ MỌI cột truy vấn cần ⚠ dùng INCLUDE
⚠ Không phải quay về bảng để lấy thêm
⚠ Kết quả ⚠ truy vấn nhanh hơn nhiều
⚠ Đổi lại ⚠ chỉ mục to hơn, ghi chậm hơn
⚠ Phân mảnh chỉ mục Nội dung
⚠ Sau nhiều lần ghi, chỉ mục bị phân mảnh
⚠ Cần REORGANIZE hoặc REBUILD
⚠ Azure SQL ⚠ có tự động điều chỉnh, tự tạo và bỏ chỉ mục

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng có clustered index chưa | ⚠ heap thường không tốt cho bảng lớn | | Có chỉ mục nào không bao giờ được dùng không | ⚠ chỉ tốn chi phí ghi | | Truy vấn chậm có thiếu chỉ mục không | |

Và cái giá của chỉ mục mà người ta hay quên khi thêm mãi để chữa truy vấn chậm: mỗi chỉ mục làm mọi thao tác ghi chậm thêm một chút. Một bảng mười chỉ mục đọc rất nhanh và ghi rất chật vật.

Câu 36 Non-relational DB
What type of non-relational data revolves around storing and retriving large binary files or blobs, such as images, videos, text files and audio files?
  1. A Object data
  2. B Key-value data
  3. C Graph data
  4. D Document data
Xem giải thích

Đáp án

A — Dữ liệu ĐỐI TƯỢNG (object data).

Vì sao đúng

⚠ Lưu trữ đối tượng sinh ra cho các khối nhị phân lớn:

⚠ Ảnh, video, âm thanh, tệp văn bản
        ↓
⚠ Lưu như một ĐỐI TƯỢNG
   ⚠ nội dung nhị phân + metadata + định danh
        ↓
⚠ Azure Blob Storage
Đặc điểm Nội dung
⚠ Không có schema
⚠ Truy cập bằng tên/URL
⚠ Không truy vấn được nội dung bên trong
⚠ Co giãn gần như vô hạn
⚠ Chi phí thấp mỗi GB

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

  • B (khoá-giá trị) — ⚠ lưu giá trị NHỎ theo khoá: ⚠ Table Storage, Redis.

  • D (tài liệu) — ⚠ JSON có cấu trúc, truy vấn theo trường được.

  • C (đồ thị) — ⚠ đỉnh và cạnh, cho dữ liệu quan hệ nhiều tầng.

Ghi nhớ

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

Câu Hỏi gì Khoá
⚠ #19507 ⚠ cái nào là dữ liệu phi cấu trúc ⚠ nội dung blob
⚠ #19508 ⚠ Table Storage thuộc loại nào ⚠ khoá-giá trị
⚠ #19526 (câu này) ⚠ tệp nhị phân lớn thuộc loại nào ⚠ đối tượng
⚠ Ba câu ⚠ hoàn chỉnh bảng năm mô hình phi quan hệ

⚠ Năm mô hình phi quan hệ — bảng đầy đủ: | Mô hình | Dữ liệu | Dịch vụ | |---|---|---| | ⚠ Đối tượng | ⚠ tệp nhị phân lớn | ⚠ Blob Storage | | ⚠ Khoá-giá trị | ⚠ giá trị nhỏ theo khoá | ⚠ Table, Redis | | ⚠ Tài liệu | ⚠ JSON có cấu trúc | ⚠ Cosmos NoSQL | | ⚠ Cột rộng | ⚠ nhiều cột thưa | ⚠ Cassandra API | | ⚠ Đồ thị | ⚠ quan hệ | ⚠ Gremlin API |

Từ khoá nhận diện:

"ảnh, video, tệp lớn" → ⚠ object / blob "tra theo khoá, giá trị nhỏ" → ⚠ key-value "JSON, truy vấn theo trường" → ⚠ document "mạng lưới quan hệ" → ⚠ graph

⚠ Metadata của blob — tính năng hay bị bỏ qua Nội dung
⚠ Gắn cặp khoá-giá trị vào từng blob
⚠ Blob index tags cho phép TÌM theo thẻ
⚠ Không phải quét toàn bộ container
⚠ Hữu ích cho ⚠ phân loại và lifecycle theo thẻ
⚠ Vì sao không lưu tệp lớn trong CSDL Lý do
⚠ Làm phình cơ sở dữ liệu và bản sao lưu
⚠ Đắt hơn nhiều so với blob
⚠ Chậm khi sao lưu và khôi phục
⚠ Mẫu chuẩn ⚠ lưu tệp ở blob, lưu ĐƯỜNG DẪN trong CSDL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cần truy vấn nội dung bên trong không | ⚠ nếu có thì không phải object store | | Có tệp lớn nào đang nằm trong CSDL không | | | Đã dùng index tags để phân loại chưa | |

Và mẫu thiết kế đúng đắn nhất khi hệ thống có tệp đính kèm, đơn giản đến mức hay bị bỏ qua: tệp nằm ở blob, cơ sở dữ liệu chỉ giữ đường dẫn. Nhồi tệp vào cột nhị phân làm mọi thao tác sao lưu và khôi phục nặng nề gấp bội.

Câu 37 Non-relational DB
With a relational data store, when data transaction volumes get too high and database performance suffers, which of the following is a common yet difficult method of distributing those data transactions over multiple servers?
  1. A SQL Server Stretch DB
  2. B SQL Database autoscale
  3. C Server scale-up
  4. D Manual sharding
Xem giải thích

Đáp án

D — Phân mảnh THỦ CÔNG (manual sharding).

Vì sao đúng

⚠ Sharding là cách chia dữ liệu ra nhiều máy chủ, và với CSDL quan hệ nó rất khó:

⚠ Một máy chủ quá tải
        ↓ ⚠ sharding
⚠ Khách A-H  → Server 1
⚠ Khách I-P  → Server 2
⚠ Khách Q-Z  → Server 3
        ↓
⚠ Ứng dụng phải TỰ biết đi tới server nào
Vì sao khó Lý do
⚠ Ứng dụng phải tự định tuyến
⚠ Truy vấn CHÉO shard rất phức tạp
⚠ Giao dịch qua nhiều shard gần như không làm được
⚠ Cân bằng lại shard khi lệch tải rất khó
⚠ Vì vậy đề nói ⚠ "phổ biến nhưng KHÓ"

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

  • C (mở rộng theo chiều DỌC — scale-up) — ⚠ bẫy hợp lý: ⚠ nâng cấu hình máy đúng là cách thường làm, ⚠ nhưng ⚠ KHÔNG phân tán giao dịch qua nhiều máy chủ như đề yêu cầu; ⚠ và nó có trần.

  • B (SQL Database autoscale) — ⚠ cũng là mở rộng dọc, chỉ tự động hơn.

  • A (SQL Server Stretch DB) — ⚠ chuyển dữ liệu LẠNH sang Azure để tiết kiệm, ⚠ không phải phân tán tải giao dịch.

Ghi nhớ

⚠ Scale-up và scale-out — phân biệt cốt lõi: | Cách | Nội dung | |---|---| | ⚠ Scale UP (dọc) | ⚠ máy MẠNH hơn — đơn giản, có TRẦN | | ⚠ Scale OUT (ngang) | ⚠ NHIỀU máy hơn — không trần, phức tạp | | ⚠ CSDL quan hệ | ⚠ dễ scale up, khó scale out | | ⚠ CSDL NoSQL | ⚠ thiết kế sẵn để scale out |

Từ khoá nhận diện:

"chia dữ liệu qua nhiều máy chủ" → ⚠ sharding / scale out "nâng cấu hình máy" → ⚠ scale up "chuyển dữ liệu lạnh lên đám mây" → ⚠ Stretch Database "tự phân vùng, không cần lo" → ⚠ Cosmos DB

⚠ Cosmos DB làm gì khác Khác
⚠ TỰ phân vùng theo partition key
⚠ Ứng dụng không cần biết dữ liệu ở đâu
⚠ Tự cân bằng lại khi phân vùng lớn lên
⚠ Đó là ⚠ lý do NoSQL thắng ở quy mô rất lớn
⚠ Đổi lại ⚠ mất giao dịch chéo phân vùng và truy vấn phức tạp
⚠ Trước khi nghĩ tới sharding, hãy thử Thử
⚠ Tối ưu truy vấn và chỉ mục ⚠ thường đủ
⚠ Thêm bản sao CHỈ ĐỌC cho báo cáo
⚠ Cache tầng ứng dụng bằng Redis
⚠ Nâng bậc dịch vụ
⚠ Sharding ⚠ là phương án cuối, chi phí kỹ thuật rất lớn
⚠ Elastic Database tools Nội dung
⚠ Azure SQL có bộ công cụ hỗ trợ sharding
⚠ Shard map manager định tuyến giúp
⚠ Elastic query truy vấn chéo shard
⚠ Vẫn ⚠ phức tạp hơn nhiều so với một CSDL duy nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã tối ưu truy vấn và chỉ mục chưa | ⚠ làm trước tiên | | Đã thử bản sao chỉ đọc và cache chưa | | | Có thật sự cần chia dữ liệu không | |

Và thứ tự đúng khi cơ sở dữ liệu quan hệ bắt đầu quá tải, đi ngược lại là rất tốn kém: tối ưu trước, nâng cấp sau, chia tách sau cùng. Sharding giải quyết được vấn đề quy mô nhưng tạo ra một loạt vấn đề mới suốt vòng đời hệ thống.

Câu 38 Data Warehouse
You have 10 TB of log files stored in an Azure Data Lake Storage Gen2, and would like to save some money on storage. These files are historical, and you don't expect to be needing to access them any more. Because of company policy, you still need to keep them around for 3 more months in case they are needed. What actions can you take to reduce the cost, in the fewest possible steps?
  1. A Set the default access tier on the account to Cool tier
  2. B Implement lifecycle management policies on the Azure Data Lake storage to move files to cool or archive storage tier
  3. C Use Azure Data Factory to move the data from high cost Data Lake storage to lower cost standard Blob Storage
  4. D Implement a compression algorithm (like ZIP) to reduce the size of the files
Xem giải thích

Đáp án

B — Triển khai chính sách LIFECYCLE MANAGEMENT trên Data Lake để chuyển tệp sang tầng Cool hoặc Archive.

Vì sao đúng

⚠ Đề nêu ba manh mối, chúng khớp chính xác với lifecycle policy: | Manh mối | Kết luận | |---|---| | ⚠ Tệp lịch sử, không cần truy cập nữa | ⚠ hợp Archive | | ⚠ Vẫn phải giữ thêm 3 tháng | ⚠ không xoá được | | ⚠ Muốn giảm chi phí lưu trữ | ⚠ hạ tầng lưu trữ |

⚠ Luật lifecycle
   ⚠ blob cũ hơn N ngày → Cool
   ⚠ blob cũ hơn M ngày → Archive
   ⚠ blob cũ hơn K ngày → xoá
        ↓
⚠ Chạy tự động, không cần ai nhớ

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

  • A (đặt tầng mặc định của tài khoản là Cool) — ⚠ chỉ áp cho blob MỚI, ⚠ không chuyển 10TB đang có; ⚠ và Archive rẻ hơn Cool nhiều cho dữ liệu không cần đọc.

  • C (dùng Data Factory chuyển sang Blob Storage thường) — ⚠ vô nghĩa: ⚠ Data Lake Gen2 ⚠ chính là Blob Storage; ⚠ giá lưu trữ như nhau.

  • D (nén ZIP) — ⚠ có giảm dung lượng nhưng ⚠ không phải cách chuẩn, ⚠ và làm dữ liệu khó truy cập khi cần.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ áp dụng kiến thức của #19509 và #19498 ở lô trước vào một tình huống cụ thể.

Câu Hỏi gì Khoá
⚠ #19498 / #19509 ⚠ đặc điểm của tầng lưu trữ ⚠ đánh đổi lưu / truy cập
⚠ #19528 (câu này) ⚠ làm gì để giảm chi phí 10TB log cũ ⚠ lifecycle policy
⚠ Cùng nguyên lý ⚠ một hỏi lý thuyết, một hỏi hành động

⚠ Lifecycle policy — cấu trúc một luật: | Thành phần | Nội dung | |---|---| | ⚠ Điều kiện | ⚠ số ngày kể từ khi tạo, sửa, hoặc truy cập lần cuối | | ⚠ Hành động | ⚠ chuyển tầng, hoặc xoá | | ⚠ Bộ lọc | ⚠ theo tiền tố đường dẫn, theo index tag | | ⚠ Áp cho | ⚠ blob hiện tại, phiên bản cũ, snapshot | | ⚠ Chạy | ⚠ tự động mỗi ngày một lần |

Từ khoá nhận diện:

"tự chuyển tầng theo tuổi" → ⚠ lifecycle management "dữ liệu cũ giữ để tuân thủ" → ⚠ Archive "phải xoá sau N năm" → ⚠ lifecycle với hành động xoá "không được xoá trước hạn" → ⚠ immutable / WORM

⚠ Cân nhắc khi dùng Archive Cân nhắc
⚠ Phải RÃ ĐÔNG mới đọc được ⚠ vài giờ
⚠ Thời gian tối thiểu 180 ngày
⚠ Đề nói giữ 3 THÁNG = 90 ngày ⚠ rút ra trước 180 ngày sẽ bị phạt
⚠ Vì vậy trong tình huống này ⚠ Cool có thể hợp lý hơn Archive
⚠ Đề chấp nhận cả hai ⚠ khoá nói "cool HOẶC archive"
⚠ Ước tính tiết kiệm Ước tính
⚠ 10TB ở Hot so với Cool: giảm đáng kể mỗi tháng
⚠ Archive giảm nhiều hơn nữa
⚠ Nhưng phải cộng phí truy cập nếu cần đọc
⚠ Với log không đọc ⚠ tầng lạnh gần như thuần tiết kiệm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thời gian giữ có vượt thời gian tối thiểu của tầng không | ⚠ tránh phí rút sớm | | Có chắc sẽ không cần đọc gấp không | | | Đã có luật xoá sau thời hạn chưa | |

Và chi tiết trong đề này đáng cân nhắc kỹ hơn vẻ ngoài của nó: giữ 3 tháng ngắn hơn thời gian tối thiểu 180 ngày của Archive. Chuyển xuống Archive rồi xoá sau 90 ngày sẽ phát sinh phí rút sớm, và Cool là lựa chọn an toàn hơn.

Câu 39 SQL Language
Data Definition Language (DDL) primarily does what?
  1. A Determine which users and logins can access data and perform operations.
  2. B Define data structures
  3. C Affect the information stored in the database
  4. D Provide ways to create backups and restore from backups.
Xem giải thích

Đáp án

B — Định nghĩa CẤU TRÚC dữ liệu.

Vì sao đúng

⚠ DDL = Data DEFINITION Language, đúng như tên gọi: | Câu lệnh DDL | Việc | |---|---| | ⚠ CREATE | ⚠ tạo bảng, view, chỉ mục, schema | | ⚠ ALTER | ⚠ sửa cấu trúc | | ⚠ DROP | ⚠ xoá đối tượng | | ⚠ TRUNCATE | ⚠ xoá sạch dữ liệu, giữ cấu trúc |

⚠ DDL nói về CÁI BÌNH
⚠ DML nói về NƯỚC trong bình
⚠ DCL nói về AI được chạm vào

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

  • C (ảnh hưởng tới thông tin lưu trong CSDL) — ⚠ đó là DML.

  • A (quyết định ai truy cập được và làm gì) — ⚠ đó là DCL: ⚠ GRANT, REVOKE, DENY.

  • D (tạo bản sao lưu và khôi phục) — ⚠ là lệnh quản trị: ⚠ BACKUP, RESTORE — ⚠ không thuộc bốn nhóm ngôn ngữ chuẩn.

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 #19493 ở lô trước và ⚠ #19535 trong cùng lô này.

Câu Hỏi gì Khoá
⚠ #19493 ⚠ SELECT thuộc nhóm nào ⚠ DML
⚠ #19529 (câu này) ⚠ DDL làm gì ⚠ định nghĩa cấu trúc
⚠ #19535 ⚠ ví dụ nào là DML ⚠ SELECT, INSERT, UPDATE
⚠ Ba câu ⚠ cùng một bảng kiến thức, hỏi ba chiều
⚠ Mẹo ⚠ thuộc bảng bốn nhóm là ăn trọn cả chùm

⚠ Bốn nhóm câu lệnh SQL — bảng đầy đủ: | Nhóm | Tên đầy đủ | Câu lệnh | |---|---|---| | ⚠ DDL | ⚠ Definition | ⚠ CREATE, ALTER, DROP, TRUNCATE | | ⚠ DML | ⚠ Manipulation | ⚠ SELECT, INSERT, UPDATE, DELETE | | ⚠ DCL | ⚠ Control | ⚠ GRANT, REVOKE, DENY | | ⚠ TCL | ⚠ Transaction | ⚠ COMMIT, ROLLBACK, SAVE |

Từ khoá nhận diện:

"tạo, sửa, xoá BẢNG" → ⚠ DDL "đọc, thêm, sửa, xoá DỮ LIỆU" → ⚠ DML "cấp quyền, thu quyền" → ⚠ DCL "chốt hoặc huỷ giao dịch" → ⚠ TCL

⚠ DDL trên bảng lớn — lưu ý thực tế Lưu ý
⚠ ALTER TABLE có thể KHOÁ bảng
⚠ Thêm cột NOT NULL không có DEFAULT rất tốn
⚠ Nên làm ngoài giờ cao điểm
⚠ Azure SQL ⚠ một số thao tác làm được trực tuyến
⚠ TRUNCATE và DROP Phân biệt
⚠ TRUNCATE: xoá DỮ LIỆU, giữ bảng
⚠ DROP: xoá cả BẢNG
⚠ Cả hai đều là DDL
⚠ Rollback ⚠ được nếu nằm trong giao dịch

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lệnh này đụng cấu trúc hay dữ liệu | | | Thay đổi cấu trúc có khoá bảng không | | | Có nằm trong giao dịch để rollback được không | |

Và cách nhớ bốn nhóm câu lệnh SQL bền nhất, không cần học thuộc danh sách: đọc chính tên viết tắt — Definition là cấu trúc, Manipulation là dữ liệu, Control là quyền, Transaction là giao dịch.

Câu 40 Non-relational DB
What type of cloud service is Cosmos DB?
  1. A Infrstructure-as-a-Service (IaaS)
  2. B Platform-as-a-Service (PaaS)
  3. C Software-as-a-Service (SaaS)
Xem giải thích

Đáp án

B — Platform-as-a-Service (PaaS).

Vì sao đúng

⚠ Cosmos DB là dịch vụ CSDL được quản lý hoàn toàn: | Microsoft lo | Bạn lo | |---|---| | ⚠ Phần cứng, hệ điều hành | ⚠ thiết kế dữ liệu | | ⚠ Vá lỗi, nâng cấp | ⚠ partition key | | ⚠ Sao lưu tự động | ⚠ truy vấn và chỉ mục | | ⚠ Nhân bản, sẵn sàng cao | ⚠ phân quyền | | ⚠ Co giãn hạ tầng | ⚠ chi phí RU |

⚠ IaaS: bạn quản lý MÁY
⚠ PaaS: bạn quản lý ỨNG DỤNG và DỮ LIỆU
⚠ SaaS: bạn chỉ DÙNG

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

  • A (IaaS) — ⚠ là khi bạn tự cài CSDL trên máy ảo: ⚠ ví dụ SQL Server trong VM.

  • C (SaaS) — ⚠ là phần mềm dùng ngay cho người cuối: ⚠ Microsoft 365, Dynamics.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp với #19533 trong cùng lô — ⚠ câu kia hỏi cái nào là IaaS, khoá là SQL Server trong VM.

⚠ Ba mô hình dịch vụ — bảng phải thuộc: | Mô hình | Bạn quản lý | Ví dụ Azure | |---|---|---| | ⚠ IaaS | ⚠ hệ điều hành trở lên | ⚠ VM, SQL Server trong VM | | ⚠ PaaS | ⚠ ứng dụng và dữ liệu | ⚠ App Service, Azure SQL, Cosmos DB | | ⚠ SaaS | ⚠ chỉ dữ liệu và người dùng | ⚠ Microsoft 365 |

Từ khoá nhận diện:

"máy ảo, tự cài, tự vá" → ⚠ IaaS "dịch vụ được quản lý, chỉ lo ứng dụng" → ⚠ PaaS "phần mềm dùng ngay" → ⚠ SaaS "serverless" → ⚠ một nhánh của PaaS

⚠ Vị trí của các dịch vụ CSDL Azure Vị trí
⚠ SQL Server trong VM ⚠ IaaS
⚠ SQL Managed Instance ⚠ PaaS
⚠ Azure SQL Database ⚠ PaaS
⚠ Cosmos DB ⚠ PaaS
⚠ Azure Database for MySQL/PostgreSQL ⚠ PaaS
⚠ Càng lên PaaS ⚠ càng ít việc vận hành, càng ít quyền tuỳ chỉnh
⚠ Đánh đổi IaaS và PaaS Đánh đổi
⚠ IaaS: toàn quyền, tương thích tối đa ⚠ bạn tự vá và tự sao lưu
⚠ PaaS: ít việc, tự động hoá cao ⚠ một số tính năng không có
⚠ Chọn IaaS khi ⚠ cần tính năng PaaS không hỗ trợ
⚠ Mặc định nên ⚠ ưu tiên PaaS, chỉ xuống IaaS khi buộc phải

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai chịu trách nhiệm vá lỗi hệ điều hành | ⚠ câu hỏi phân biệt IaaS và PaaS | | Có tính năng nào PaaS không hỗ trợ không | | | Sao lưu là tự động hay phải tự lo | |

Và câu hỏi phân biệt IaaS với PaaS nhanh nhất trong phòng thi: ai chịu trách nhiệm vá lỗi hệ điều hành? Nếu câu trả lời là bạn, đó là IaaS.