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

Câu 131 Relational Azure databases

Which of the following Azure data services is said to be in the IaaS model?

A SQL Managed Instances
B SQL Server in a Virtual Machine
C Azure SQL Database
D SQL Server running on premises

Xem giải thích

Đáp án

B — SQL Server chạy trên máy ảo.

Vì sao đúng

⚠ Chỉ có một lựa chọn mà bạn phải quản lý hệ điều hành trên hạ tầng Azure: | Dịch vụ | Mô hình | |---|---| | ⚠ SQL Server trên VM | ⚠ IaaS | | ⚠ SQL Managed Instance | ⚠ PaaS | | ⚠ Azure SQL Database | ⚠ PaaS | | ⚠ SQL Server tại chỗ | ⚠ KHÔNG phải dịch vụ Azure |

⚠ Câu hỏi phân biệt
   ⚠ "Bản vá Windows tháng này ai cài?"
        ↓ ⚠ BẠN
⚠ IaaS

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

A (Managed Instance) và C (Azure SQL Database) — ⚠ đều là PaaS.
D (SQL Server chạy tại chỗ) — ⚠ bẫy tinh tế: ⚠ đó ⚠ không phải dịch vụ đám mây nào cả; ⚠ đề hỏi ⚠ dịch vụ dữ liệu Azure.

Ghi nhớ

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

Câu	Hỏi gì	Khoá
⚠ #19530	⚠ Cosmos DB thuộc mô hình nào	⚠ PaaS
⚠ #19533	⚠ cái nào là IaaS	⚠ SQL Server trên VM
⚠ #19621 (câu này)	⚠ dịch vụ dữ liệu Azure nào là IaaS	⚠ SQL Server trên VM
⚠ Cùng khoá	⚠ #19533 và #19621 gần như trùng nhau
⚠ Khác biệt	⚠ câu này thêm phương án "tại chỗ" làm nhiễu

⚠ Bảng phân chia trách nhiệm — nhắc lại: | Tầng | IaaS | PaaS | SaaS | |---|---|---|---| | ⚠ Dữ liệu, danh tính | ⚠ bạn | ⚠ bạn | ⚠ bạn | | ⚠ Ứng dụng | ⚠ bạn | ⚠ bạn | ⚠ MS | | ⚠ Hệ điều hành | ⚠ bạn | ⚠ MS | ⚠ MS | | ⚠ Hạ tầng vật lý | ⚠ MS | ⚠ MS | ⚠ MS |

Từ khoá nhận diện:

"trên máy ảo, tự vá" → ⚠ IaaS "dịch vụ được quản lý" → ⚠ PaaS "tại chỗ, on-premises" → ⚠ KHÔNG phải mô hình đám mây "phần mềm dùng ngay" → ⚠ SaaS

⚠ Bốn mô hình khi tính cả tại chỗ	Mô hình
⚠ On-premises	⚠ bạn quản lý TẤT CẢ, kể cả toà nhà
⚠ IaaS	⚠ nhà cung cấp lo phần cứng
⚠ PaaS	⚠ thêm hệ điều hành và runtime
⚠ SaaS	⚠ thêm cả ứng dụng
⚠ Xu hướng	⚠ càng lên cao càng ít việc vận hành

⚠ Vì sao vẫn chọn IaaS	Lý do
⚠ Cần phiên bản cũ hoặc cấu hình đặc thù
⚠ Cần cài phần mềm bên thứ ba trên máy chủ
⚠ Ràng buộc tuân thủ đòi kiểm soát hoàn toàn
⚠ Ứng dụng kế thừa không chạy được trên PaaS
⚠ Ngoài ra	⚠ PaaS gần như luôn hợp lý hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai vá hệ điều hành | ⚠ câu hỏi phân biệt | | Có lý do bắt buộc dùng VM không | | | Đã tính chi phí vận hành chưa | |

Và câu hỏi ngắn nhất để phân loại bất kỳ dịch vụ đám mây nào vào IaaS hay PaaS: ai chịu trách nhiệm cập nhật hệ điều hành?

Câu 132 Data analytics core concepts

In what way can ETL help with data privacy and compliance?

A ETL allows you to run reports on the data before it is ingested
B ETL allows you to filter out sensitive data before it's loaded into the data store
C ETL is ideal for large volumes of data
D ETL cannot help with privacy and compliance

Xem giải thích

Đáp án

B — ETL cho phép LỌC BỎ dữ liệu nhạy cảm TRƯỚC KHI nạp vào kho dữ liệu.

Vì sao đúng

⚠ Bước biến đổi của ETL nằm TRƯỚC bước nạp, và đó là cơ hội để làm sạch:

⚠ Extract: lấy dữ liệu thô từ nguồn
        ↓
⚠ TRANSFORM ← chỗ can thiệp
   ⚠ bỏ cột nhạy cảm
   ⚠ ẩn danh hoặc giả danh
   ⚠ băm số định danh
   ⚠ gộp thành nhóm để không định danh được
        ↓
⚠ Load: dữ liệu vào kho ĐÃ SẠCH
        ↓
⚠ Kho phân tích KHÔNG BAO GIỜ chứa dữ liệu nhạy cảm

Lợi ích tuân thủ	Nội dung
⚠ Giảm phạm vi dữ liệu cá nhân	⚠ data minimization
⚠ Ít người tiếp xúc dữ liệu nhạy cảm hơn
⚠ Dễ chứng minh tuân thủ khi kiểm toán
⚠ Rò rỉ kho phân tích không lộ dữ liệu cá nhân

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

D (ETL không giúp gì cho riêng tư) — ⚠ SAI: ⚠ đây là một trong những lợi ích chính.
C (ETL lý tưởng cho khối lượng lớn) — ⚠ đúng nhưng không liên quan tới quyền riêng tư.
A (chạy báo cáo trên dữ liệu trước khi nạp) — ⚠ không phải mục đích của ETL.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung một khía cạnh cho #19540 ở lô trước.

Câu	Hỏi gì	Khoá
⚠ #19540	⚠ dữ liệu đã đúng định dạng thì dùng gì	⚠ ELT
⚠ #19622 (câu này)	⚠ ETL giúp gì cho riêng tư	⚠ lọc dữ liệu nhạy cảm trước khi nạp
⚠ Bổ sung nhau	⚠ và nêu ra một lý do NÊN chọn ETL thay vì ELT
⚠ Điểm quan trọng	⚠ với dữ liệu nhạy cảm, ETL an toàn hơn ELT vì dữ liệu thô không bao giờ vào kho

⚠ ETL và ELT xét theo quyền riêng tư: | Mô hình | Rủi ro riêng tư | |---|---| | ⚠ ETL | ⚠ THẤP — làm sạch trước khi nạp | | ⚠ ELT | ⚠ CAO HƠN — dữ liệu thô nằm trong kho | | ⚠ Nếu dùng ELT với dữ liệu nhạy cảm | ⚠ phải phân quyền chặt tầng bronze | | ⚠ Cân nhắc | ⚠ theo mức nhạy cảm của dữ liệu, không chỉ theo hiệu năng |

Từ khoá nhận diện:

"lọc dữ liệu nhạy cảm trước khi nạp" → ⚠ ETL "nạp thô rồi xử lý sau" → ⚠ ELT "tìm và che thông tin cá nhân" → ⚠ PII detection "phân loại và gắn nhãn dữ liệu" → ⚠ Microsoft Purview

⚠ Kỹ thuật bảo vệ riêng tư trong ETL	Kỹ thuật
⚠ Bỏ hẳn cột không cần	⚠ đơn giản và hiệu quả nhất
⚠ Băm một chiều số định danh	⚠ vẫn nối được, không đọc được
⚠ Giả danh bằng mã thay thế
⚠ Gộp thành khoảng	⚠ tuổi thành nhóm tuổi
⚠ Thêm nhiễu cho số liệu	⚠ differential privacy
⚠ Nhớ	⚠ bỏ tên chưa chắc đã ẩn danh — vài trường kết hợp vẫn định danh được

⚠ Microsoft Purview — công cụ liên quan	Nội dung
⚠ Quét và phân loại dữ liệu tự động
⚠ Phát hiện cột chứa thông tin cá nhân
⚠ Lập bản đồ dòng chảy dữ liệu	⚠ data lineage
⚠ Giúp trả lời	⚠ "dữ liệu cá nhân của chúng ta đang nằm ở những đâu"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kho phân tích có chứa cột nhạy cảm nào không | | | Bỏ tên rồi có còn suy ra được người không | | | Ai có quyền truy cập tầng dữ liệu thô | |

Và lý do đáng cân nhắc nhất để chọn ETL thay vì ELT dù ELT đang là xu hướng: với dữ liệu nhạy cảm, thứ chưa bao giờ được nạp vào kho là thứ không bao giờ có thể rò rỉ từ đó.

Câu 133 Core data workloads

Which of the following data processing techniques would be best used for a stock market trading app that relies on real-time changes in the price of a stock?

A Stream processing
B Batch processing

Xem giải thích

Đáp án

A — Xử lý DÒNG (stream processing).

Vì sao đúng

⚠ Ứng dụng giao dịch chứng khoán phụ thuộc vào thay đổi giá THỜI GIAN THỰC:

⚠ Giá cổ phiếu thay đổi liên tục
        ↓ ⚠ dòng dữ liệu VÔ HẠN
⚠ Xử lý ngay khi từng bản ghi tới
        ↓
⚠ Cập nhật giá, kích hoạt lệnh
        ↓
⚠ Chậm một giây có thể mất tiền thật

Vì sao phải stream	Lý do
⚠ Dữ liệu chảy liên tục, không có điểm cuối
⚠ Giá trị của thông tin GIẢM RẤT NHANH theo thời gian
⚠ Quyết định phải ra trong mili giây

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

B (batch) — ⚠ hoàn toàn không phù hợp: ⚠ xử lý theo lô có độ trễ phút tới giờ; ⚠ giá cổ phiếu của một giờ trước là ⚠ vô giá trị với ứng dụng giao dịch.

Ghi nhớ

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

Câu	Mô tả	Khoá
⚠ #19516	⚠ 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	⚠ lớn, phức tạp, lâu	⚠ batch
⚠ #19608	⚠ tệp hàng triệu dòng	⚠ batch
⚠ #19623 (câu này)	⚠ giá cổ phiếu thời gian thực	⚠ stream
⚠ Năm câu	⚠ cùng một trục, và luôn có một chi tiết quyết định

⚠ Chi tiết quyết định trong đề: | Chi tiết | Kết luận | |---|---| | ⚠ "thời gian thực" | ⚠ stream | | ⚠ "một tệp" | ⚠ batch | | ⚠ "mỗi ngày" | ⚠ batch | | ⚠ "cảm biến gửi liên tục" | ⚠ stream | | ⚠ "mất nhiều thời gian xử lý" | ⚠ batch |

Từ khoá nhận diện:

"thời gian thực, ngay lập tức" → ⚠ stream "tệp, khối dữ liệu có sẵn" → ⚠ batch "giá cổ phiếu, giao dịch" → ⚠ stream "báo cáo cuối ngày" → ⚠ batch

⚠ Kiến trúc xử lý dòng cho tài chính	Tầng
⚠ Event Hubs	⚠ nhận dòng giá với thông lượng cao
⚠ Stream Analytics hoặc Databricks	⚠ tính toán trên cửa sổ thời gian
⚠ Cosmos DB hoặc Redis	⚠ lưu trạng thái mới nhất
⚠ SignalR	⚠ đẩy tới trình duyệt người dùng
⚠ Yêu cầu	⚠ độ trễ đầu cuối tính bằng mili giây

⚠ Thách thức riêng của xử lý dòng	Thách thức
⚠ Sự kiện đến MUỘN hoặc SAI THỨ TỰ
⚠ Phải chọn giữa chờ đủ và trả kết quả sớm
⚠ Xử lý trùng lặp	⚠ exactly-once rất khó
⚠ Khôi phục trạng thái khi job khởi động lại
⚠ Đó là lý do	⚠ stream phức tạp hơn batch đáng kể

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thông tin mất giá trị sau bao lâu | ⚠ câu hỏi quyết định | | Có xử lý được sự kiện đến muộn không | | | Trạng thái có khôi phục được khi job restart không | |

Và câu hỏi duy nhất cần trả lời để chọn giữa hai mô hình xử lý, đúng cho cả năm câu hỏi trong chùm này: thông tin này mất giá trị sau bao lâu? Sau vài giây thì phải dùng dòng; sau vài giờ thì lô rẻ hơn nhiều.

Câu 134 Power BI

What is one reason why someone would design a report as a paginated report?

A It needs to be a visual summary of the data, including charts and graphs
B It needs to be printed or shared.
C It will be consumed entirely online
D Generating the report will likely go into the 100,000s of pages.

Xem giải thích

Đáp án

B — Vì nó cần được IN RA hoặc chia sẻ.

Vì sao đúng

⚠ Paginated report sinh ra cho bố cục cố định, chuẩn từng pixel: | Đặc điểm | Nội dung | |---|---| | ⚠ Tự ngắt trang | | | ⚠ Lặp tiêu đề cột ở mỗi trang | | | ⚠ Đầu trang, chân trang, số trang | | | ⚠ Xuất PDF, Word, Excel chuẩn | | | ⚠ Bố cục KHÔNG đổi theo màn hình | |

⚠ Hoá đơn, phiếu lương, sao kê
        ↓
⚠ Bố cục phải CHÍNH XÁC
⚠ In ra phải đúng như thiết kế
        ↓
⚠ Paginated report

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

C (sẽ được xem hoàn toàn trực tuyến) — ⚠ đó là lý do chọn INTERACTIVE report.
A (cần là bản tóm tắt trực quan có biểu đồ) — ⚠ đó là dashboard hoặc interactive report.
D (báo cáo có thể lên tới hàng trăm nghìn trang) — ⚠ bẫy đáng chú ý: ⚠ paginated report ⚠ có giới hạn số trang thực tế; ⚠ hàng trăm nghìn trang là dấu hiệu thiết kế sai, ⚠ nên chia nhỏ hoặc xuất dữ liệu thô.

Ghi nhớ

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

Câu	Hỏi gì	Khoá
⚠ #19522	⚠ hàng nghìn dòng, mỗi xe một dòng	⚠ Paginated
⚠ #19567	⚠ tính năng của Interactive report	⚠ báo cáo web tuỳ biến
⚠ #19624 (câu này)	⚠ vì sao thiết kế paginated report	⚠ cần in và chia sẻ
⚠ Ba câu	⚠ cùng bảng ba loại nội dung Power BI
⚠ Phương án D	⚠ nhắc nhở: paginated không phải để in hàng trăm nghìn trang

⚠ Ba loại nội dung — bảng chốt: | Loại | Tối ưu cho | |---|---| | ⚠ Interactive report | ⚠ khám phá trên màn hình | | ⚠ Paginated report | ⚠ in ra giấy, bố cục cố định | | ⚠ Dashboard | ⚠ tổng quan một trang |

Từ khoá nhận diện:

"in ra, chia sẻ bản cứng, PDF" → ⚠ Paginated "xem trực tuyến, tương tác" → ⚠ Interactive "tóm tắt trực quan một trang" → ⚠ Dashboard "hoá đơn, phiếu lương" → ⚠ Paginated

⚠ Khi nào KHÔNG nên dùng paginated report	Khi nào
⚠ Cần xuất hàng trăm nghìn dòng dữ liệu thô	⚠ nên xuất trực tiếp từ CSDL
⚠ Người dùng chỉ xem trên màn hình
⚠ Cần lọc và khám phá
⚠ Paginated mạnh ở	⚠ bố cục chính xác, không phải khối lượng

⚠ Yêu cầu giấy phép — điều hay vướng	Yêu cầu
⚠ Paginated report cần Premium capacity hoặc PPU
⚠ Interactive report chỉ cần Pro
⚠ Lập kế hoạch	⚠ kiểm tra 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 | |---|---| | Kết quả sẽ được in hay xem trên màn hình | | | Có bao nhiêu trang thực tế | ⚠ quá nhiều thì xem lại thiết kế | | Giấy phép hiện có đủ chưa | |

Và điều phương án nhiễu trong câu này vô tình dạy được: một báo cáo dài hàng trăm nghìn trang không phải là báo cáo nữa. Đó là một lần xuất dữ liệu, và nên làm bằng công cụ xuất dữ liệu.

Câu 135 Relational data workloads

What data structure represents "entities" in a relational database?

A Indexes
B Databases
C Tables
D Rows

Xem giải thích

Đáp án

C — Bảng (Tables).

Vì sao đúng

⚠ Trong mô hình quan hệ, mỗi THỰC THỂ tương ứng một BẢNG:

⚠ Thực thể "Khách hàng" → bảng KhachHang
⚠ Thực thể "Đơn hàng"   → bảng DonHang
⚠ Thực thể "Sản phẩm"   → bảng SanPham
        ↓
⚠ Mỗi DÒNG = một thể hiện cụ thể của thực thể
⚠ Mỗi CỘT = một thuộc tính của thực thể

Khái niệm mô hình hoá	Ánh xạ vào CSDL
⚠ Entity (thực thể)	⚠ table
⚠ Attribute (thuộc tính)	⚠ column
⚠ Instance (thể hiện)	⚠ row
⚠ Relationship (quan hệ)	⚠ khoá ngoại

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

D (Rows) — ⚠ dòng là một THỂ HIỆN cụ thể, ⚠ không phải bản thân thực thể; ⚠ "khách hàng Nguyễn Văn A" là một dòng, ⚠ còn "Khách hàng" là thực thể.
B (Databases) — ⚠ chứa NHIỀU thực thể.
A (Indexes) — ⚠ cấu trúc phụ trợ tăng tốc, không biểu diễn thực thể.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #19565 ở lô trước — ⚠ #19565 hỏi bảng là gì, ⚠ câu này hỏi bảng biểu diễn khái niệm nào.

⚠ Mô hình hoá dữ liệu — ba bước: | Bước | Nội dung | |---|---| | ⚠ Mô hình KHÁI NIỆM | ⚠ thực thể và quan hệ, không quan tâm công nghệ | | ⚠ Mô hình LOGIC | ⚠ bảng, cột, khoá, chuẩn hoá | | ⚠ Mô hình VẬT LÝ | ⚠ kiểu dữ liệu, chỉ mục, phân vùng | | ⚠ Thường bỏ qua bước đầu | ⚠ và đó là lý do lược đồ về sau khó sửa |

Từ khoá nhận diện:

"thực thể" → ⚠ bảng "thuộc tính" → ⚠ cột "một bản ghi cụ thể" → ⚠ dòng "quan hệ giữa thực thể" → ⚠ khoá ngoại

⚠ Ba loại quan hệ	Loại
⚠ Một - một	⚠ hiếm, thường gộp vào một bảng
⚠ Một - nhiều	⚠ phổ biến nhất, khoá ngoại ở bên "nhiều"
⚠ Nhiều - nhiều	⚠ cần BẢNG TRUNG GIAN
⚠ Ví dụ nhiều-nhiều	⚠ sinh viên và môn học → bảng đăng ký

⚠ Sơ đồ ERD — công cụ mô hình hoá	Nội dung
⚠ Vẽ thực thể, thuộc tính, quan hệ
⚠ Thống nhất với bên nghiệp vụ TRƯỚC khi viết mã
⚠ Rẻ hơn nhiều so với sửa lược đồ khi đã có dữ liệu
⚠ Thực tế	⚠ nửa giờ vẽ sơ đồ tiết kiệm được hàng tuần sửa chữa

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi bảng có tương ứng một thực thể rõ ràng không | | | Quan hệ nhiều-nhiều đã có bảng trung gian chưa | | | Bên nghiệp vụ đã xác nhận mô hình chưa | |

Và bước rẻ nhất nhưng bị bỏ qua nhiều nhất trong thiết kế cơ sở dữ liệu: vẽ sơ đồ thực thể và thống nhất với bên nghiệp vụ trước khi tạo bảng đầu tiên. Sửa một sơ đồ mất nửa giờ; sửa một lược đồ đã có mười triệu dòng thì không.

Câu 136 Non-relational deployment

Which of the following metrics affect how much an Azure Table Storage account costs?

A Consumed storage only
B Region, geo-replication, consumed storage
C Tier - Standard or Premium
D Per transaction - reads and writes

Xem giải thích

Đáp án

B — Vùng, nhân bản địa lý (geo-replication) và dung lượng đã dùng.

Vì sao đúng

⚠ Table Storage tính tiền theo mô hình của Storage Account: | Yếu tố | Nội dung | |---|---| | ⚠ Vùng | ⚠ giá khác nhau giữa các vùng | | ⚠ Mức nhân bản | ⚠ LRS rẻ nhất, GRS/GZRS đắt hơn | | ⚠ Dung lượng ĐÃ DÙNG | ⚠ trả theo GB thực tế | | ⚠ Số giao dịch | ⚠ cũng có tính, nhưng rất rẻ |

⚠ Khác Cosmos DB
   ⚠ Cosmos: trả cho THÔNG LƯỢNG CẤP PHÁT
   ⚠ Table Storage: trả cho DUNG LƯỢNG DÙNG
        ↓
⚠ Đó là lý do Table Storage rẻ hơn nhiều

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

A (chỉ dung lượng đã dùng) — ⚠ thiếu yếu tố vùng và nhân bản.
D (theo từng giao dịch) — ⚠ có tính giao dịch nhưng KHÔNG phải yếu tố chính; ⚠ và phương án này bỏ qua dung lượng.
C (theo bậc Standard hay Premium) — ⚠ Table Storage không có mô hình bậc như vậy; ⚠ đó là cách tính của Redis hoặc File Share.

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

Câu	Dịch vụ	Khoá
⚠ #19603	⚠ Cosmos DB	⚠ thông lượng, vùng, zone, dung lượng
⚠ #19626 (câu này)	⚠ Table Storage	⚠ vùng, geo-replication, dung lượng
⚠ Khác biệt then chốt	⚠ Cosmos có THÔNG LƯỢNG CẤP PHÁT, Table Storage KHÔNG
⚠ Đó chính là	⚠ lý do chênh lệch giá giữa hai dịch vụ

⚠ Ba mô hình tính tiền trên Azure — nhận diện: | Mô hình | Dịch vụ | |---|---| | ⚠ Theo tài nguyên CẤP PHÁT | ⚠ Cosmos provisioned, VM, App Service Plan, Redis | | ⚠ Theo lượng DÙNG THẬT | ⚠ Storage, Functions Consumption, serverless | | ⚠ Theo BẬC cố định | ⚠ Redis tier, File Share tier | | ⚠ Câu hỏi | ⚠ không dùng thì có mất tiền không |

Từ khoá nhận diện:

"dung lượng đã dùng" → ⚠ Storage, tính theo thực tế "thông lượng cấp phát" → ⚠ Cosmos provisioned "bậc Basic/Standard/Premium" → ⚠ Redis, File Share "số lần thực thi" → ⚠ Functions Consumption

⚠ Vì sao geo-replication làm tăng giá	Lý do
⚠ Dữ liệu được lưu ở HAI vùng
⚠ Trả cho dung lượng ở cả hai
⚠ Cộng phí băng thông nhân bản
⚠ Với dữ liệu lớn	⚠ chênh lệch đáng kể — nên cân nhắc theo yêu cầu thật

⚠ Giao dịch của Table Storage	Chi phí
⚠ Tính theo mỗi 10.000 giao dịch
⚠ Rất rẻ so với dung lượng
⚠ Nhưng với hàng tỉ thao tác thì cộng lại đáng kể
⚠ Tối ưu	⚠ gộp thao tác thành batch trong cùng phân vùng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cần nhân bản địa lý thật không | ⚠ khoản tăng giá rõ nhất | | Số giao dịch mỗi tháng là bao nhiêu | | | Dữ liệu cũ có được dọn không | |

Và điều giải thích gọn nhất vì sao Table Storage rẻ hơn Cosmos DB nhiều lần: một bên trả tiền cho dung lượng đã dùng, một bên trả tiền cho năng lực đã đặt trước.

Câu 137 Core data workloads

Which of the following terms means "processing data as it arrives"?

A Buffering
B Batching
C Templating
D Streaming

Xem giải thích

Đáp án

D — Streaming (xử lý dòng).

Vì sao đúng

⚠ Streaming đúng nghĩa là xử lý từng bản ghi NGAY KHI nó tới:

⚠ Sự kiện tới
        ↓ ⚠ xử lý NGAY
⚠ Kết quả ra
        ↓
⚠ Không chờ gom đủ khối
⚠ Không có điểm kết thúc

Streaming	Batching
⚠ Xử lý khi tới	⚠ gom rồi xử lý
⚠ Độ trễ mili giây tới giây	⚠ phút tới giờ
⚠ Dữ liệu vô hạn	⚠ dữ liệu hữu hạn

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

B (Batching) — ⚠ NGƯỢC: ⚠ gom dữ liệu lại rồi mới xử lý.
A (Buffering) — ⚠ là kỹ thuật ĐỆM tạm trong bộ nhớ, ⚠ một chi tiết kỹ thuật chứ không phải mô hình xử lý.
C (Templating) — ⚠ không liên quan tới xử lý dữ liệu.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ cùng chùm với #19623 và #19629 trong cùng lô — ⚠ ba câu về stream trong một lô.

Câu	Hỏi gì	Khoá
⚠ #19623	⚠ ứng dụng chứng khoán thời gian thực	⚠ stream
⚠ #19627 (câu này)	⚠ thuật ngữ "xử lý khi dữ liệu tới"	⚠ streaming
⚠ #19629	⚠ dòng không có đầu cuối	⚠ real-time
⚠ Ba câu	⚠ cùng một khái niệm, ba cách hỏi trong MỘT lô
⚠ Nhận xét	⚠ bộ đề Data Fundamentals lặp rất dày ở chủ đề này

⚠ Thuật ngữ xử lý dữ liệu — bảng chốt: | Thuật ngữ | Nghĩa | |---|---| | ⚠ Streaming | ⚠ xử lý khi dữ liệu tới | | ⚠ Batching | ⚠ gom thành khối rồi xử lý | | ⚠ Micro-batching | ⚠ lô rất nhỏ, độ trễ vài giây | | ⚠ Buffering | ⚠ đệm tạm trước khi xử lý | | ⚠ Windowing | ⚠ cắt dòng thành cửa sổ thời gian |

Từ khoá nhận diện:

"xử lý khi tới, liên tục" → ⚠ streaming "gom rồi xử lý" → ⚠ batching "cắt thành cửa sổ thời gian" → ⚠ windowing "đệm tạm" → ⚠ buffering, chi tiết kỹ thuật

⚠ Vì sao streaming cần windowing	Lý do
⚠ Dòng dữ liệu VÔ HẠN
⚠ Không thể tính "tổng doanh thu" của thứ vô hạn
⚠ Phải cắt thành cửa sổ: mỗi 5 phút, mỗi giờ
⚠ Bốn loại cửa sổ	⚠ tumbling, hopping, sliding, session

⚠ Micro-batching — ranh giới thực dụng	Nội dung
⚠ Spark Structured Streaming xử lý dòng bằng lô rất nhỏ
⚠ Độ trễ vài giây thay vì vài mili giây
⚠ Đơn giản hơn và ổn định hơn stream thuần
⚠ Đủ dùng cho	⚠ phần lớn nhu cầu "gần thời gian thực"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ trễ chấp nhận được là bao nhiêu | ⚠ mili giây hay vài giây | | Có cần tổng hợp theo cửa sổ không | | | Micro-batching có đủ không | ⚠ thường là đủ, và đơn giản hơn |

Và điều thực dụng đáng nhớ khi ai đó yêu cầu "xử lý thời gian thực": hỏi xem vài giây có chấp nhận được không. Nếu có, micro-batching giải quyết bài toán với độ phức tạp thấp hơn hẳn.

Câu 138 SQL Server on VM

With SQL Server in a Virtual Machine, can you select the specific version of SQL Server you need or does it only run the latest version?

A You can choose from any number of still-supported SQL Server versions
B Running SQL Server in the cloud means you have to accept whatever version they are running

Xem giải thích

Đáp án

A — Bạn có thể chọn bất kỳ phiên bản SQL Server nào còn được hỗ trợ.

Vì sao đúng

⚠ Đó chính là ưu điểm lớn nhất của mô hình IaaS: | Bạn kiểm soát | Nội dung | |---|---| | ⚠ Phiên bản SQL Server | ⚠ 2016, 2017, 2019, 2022... | | ⚠ Edition | ⚠ Developer, Standard, Enterprise | | ⚠ Hệ điều hành | ⚠ Windows hoặc Linux | | ⚠ Thời điểm nâng cấp | ⚠ bạn quyết định | | ⚠ Cấu hình cấp instance | |

⚠ Azure Marketplace
   ⚠ có sẵn ảnh cho nhiều phiên bản
        ↓
⚠ Hoặc tự cài lên VM trống
        ↓
⚠ Hoặc mang giấy phép sẵn có
   ⚠ Azure Hybrid Benefit

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

B (phải chấp nhận phiên bản mà họ đang chạy) — ⚠ SAI với IaaS: ⚠ đó là đặc điểm của ⚠ PaaS, ⚠ nơi Microsoft quản lý phiên bản engine.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #19532 và #19621 về SQL Server trên VM.

Câu	Hỏi gì	Khoá
⚠ #19532	⚠ không đổi một dòng mã	⚠ SQL Server trên VM
⚠ #19621	⚠ dịch vụ nào là IaaS	⚠ SQL Server trên VM
⚠ #19628 (câu này)	⚠ chọn được phiên bản không	⚠ chọn được
⚠ Ba câu	⚠ cùng làm rõ giá trị của mô hình IaaS

⚠ Kiểm soát phiên bản — điểm khác biệt IaaS và PaaS: | Tiêu chí | VM (IaaS) | Azure SQL (PaaS) | |---|---|---| | ⚠ Chọn phiên bản | ⚠ CÓ | ⚠ KHÔNG — luôn mới nhất | | ⚠ Chọn thời điểm vá | ⚠ CÓ | ⚠ KHÔNG | | ⚠ Ai chịu trách nhiệm vá | ⚠ BẠN | ⚠ Microsoft | | ⚠ Đánh đổi | ⚠ kiểm soát nhiều hơn = việc nhiều hơn |

Từ khoá nhận diện:

"chọn phiên bản, chọn thời điểm nâng cấp" → ⚠ IaaS "luôn là bản mới nhất" → ⚠ PaaS "mang giấy phép sẵn có" → ⚠ Azure Hybrid Benefit "tương thích tuyệt đối" → ⚠ VM

⚠ Vì sao có người cần phiên bản cũ	Lý do
⚠ Ứng dụng của nhà cung cấp chỉ chứng nhận tới phiên bản đó
⚠ Tính năng bị bỏ ở phiên bản mới
⚠ Chưa kịp kiểm thử nâng cấp
⚠ Compatibility level của database
⚠ Lưu ý	⚠ phiên bản HẾT hỗ trợ thì không nên dùng vì lý do bảo mật

⚠ Azure Hybrid Benefit — tiết kiệm đáng kể	Nội dung
⚠ Dùng giấy phép SQL Server đã mua
⚠ Chỉ trả phần hạ tầng
⚠ Áp dụng cho cả VM và Managed Instance
⚠ Điều kiện	⚠ giấy phép phải có Software Assurance

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phiên bản đang dùng còn được hỗ trợ không | | | Có giấy phép sẵn để dùng Hybrid Benefit không | | | Ai chịu trách nhiệm vá lỗi | |

Và ranh giới cần nhớ khi tận dụng quyền chọn phiên bản của mô hình IaaS: chọn được phiên bản cũ không có nghĩa là nên chọn phiên bản đã hết hỗ trợ. Không còn bản vá bảo mật là một rủi ro khác hẳn.

Câu 139 Analytics workload

Which type of data analytics workload is best for processing data that arrives in a stream, without a start or an end?

A Batch processing
B Real-time processing
C ETL pipeline

Xem giải thích

Đáp án

B — Xử lý thời gian thực (real-time processing).

Vì sao đúng

⚠ "Không có điểm bắt đầu và kết thúc" là định nghĩa của dữ liệu dòng:

⚠ Dữ liệu HỮU HẠN (bounded)
   ⚠ tệp, bảng, kết quả truy vấn
        ↓ ⚠ batch

⚠ Dữ liệu VÔ HẠN (unbounded)
   ⚠ cảm biến, log, giao dịch, click
        ↓ ⚠ stream / real-time

Đặc điểm dòng vô hạn	Nội dung
⚠ Không biết khi nào kết thúc
⚠ Không thể chờ có đủ dữ liệu
⚠ Phải cắt theo CỬA SỔ thời gian để tổng hợp
⚠ Xử lý liên tục, không có "chạy xong"

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

A (batch) — ⚠ đòi dữ liệu có RANH GIỚI; ⚠ dòng vô hạn thì không bao giờ "gom đủ".
C (ETL pipeline) — ⚠ là QUY TRÌNH nạp dữ liệu, ⚠ không phải mô hình xử lý; ⚠ và ETL truyền thống chạy theo lô.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ ba về stream trong CÙNG MỘT LÔ.

Câu	Mô tả	Khoá
⚠ #19623	⚠ ứng dụng chứng khoán thời gian thực	⚠ stream
⚠ #19627	⚠ thuật ngữ "xử lý khi tới"	⚠ streaming
⚠ #19629 (câu này)	⚠ dòng không đầu không cuối	⚠ real-time
⚠ Ba câu trong một lô	⚠ cộng với #19516, #19537, #19598, #19608 là BẢY câu qua ba lô
⚠ Kết luận	⚠ đây là chủ đề bị lặp nhiều nhất của Data Fundamentals

⚠ Bounded và Unbounded — khái niệm gốc: | Loại | Đặc điểm | Xử lý | |---|---|---| | ⚠ Bounded | ⚠ có đầu có cuối | ⚠ batch | | ⚠ Unbounded | ⚠ chảy mãi | ⚠ stream | | ⚠ Mọi câu hỏi trong chùm này | ⚠ rút gọn về một câu: dữ liệu có kết thúc không |

Từ khoá nhận diện:

"không có đầu cuối, liên tục" → ⚠ stream "tệp, bảng, khối" → ⚠ batch "ETL pipeline" → ⚠ quy trình, không phải mô hình xử lý "cảm biến, log, click" → ⚠ stream

⚠ Dịch vụ Azure cho dòng vô hạn	Dịch vụ
⚠ Event Hubs	⚠ nhận dòng thông lượng cao
⚠ IoT Hub	⚠ thiết bị IoT, giao tiếp hai chiều
⚠ Stream Analytics	⚠ truy vấn SQL trên dòng
⚠ Databricks Structured Streaming	⚠ linh hoạt hơn, cần code
⚠ Functions với Event Hub trigger	⚠ xử lý từng sự kiện

⚠ Vấn đề riêng của dòng vô hạn	Vấn đề
⚠ Trạng thái phải giữ ở đâu khi job restart
⚠ Checkpoint để không xử lý lại từ đầu
⚠ Sự kiện đến muộn xử lý thế nào
⚠ Backpressure khi nguồn nhanh hơn xử lý
⚠ Đó là lý do	⚠ stream phức tạp hơn batch đáng kể

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu có điểm kết thúc không | ⚠ câu hỏi phân định duy nhất | | Có checkpoint để khôi phục không | | | Xử lý sự kiện đến muộn thế nào | |

Và câu hỏi rút gọn được toàn bộ chùm bảy câu về batch và stream trong ba lô liền: dữ liệu của bạn có bao giờ kết thúc không?

Câu 140 Non-relational deployment

What method of provisioning a non-relational database involves first defining the database in a JSON file, which can then be checked into a code repository for source control, sometimes also referred to as Infrastructure as Code?

A ARM templates
B PowerShell Scripts
C Azure Portal
D CLI Bash Shell

Xem giải thích

Đáp án

A — ARM template.

Vì sao đúng

⚠ Đề mô tả chính xác đặc điểm của ARM template: | Đặc điểm đề nêu | ARM template | |---|---| | ⚠ Định nghĩa trong tệp JSON | ⚠ đúng định dạng | | ⚠ Đưa vào kho mã nguồn | ⚠ quản lý phiên bản như mã | | ⚠ Infrastructure as Code | ⚠ đúng thuật ngữ |

⚠ {
⚠   "$schema": "...",
⚠   "resources": [{
⚠     "type": "Microsoft.DocumentDB/databaseAccounts",
⚠     "name": "[parameters('accountName')]",
⚠     ...
⚠   }]
⚠ }
        ↓
⚠ git commit → review → triển khai tự động

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

B (PowerShell script) và D (CLI Bash) — ⚠ là script MỆNH LỆNH: ⚠ mô tả các BƯỚC, không phải trạng thái mong muốn; ⚠ đưa vào Git được nhưng không phải "định nghĩa bằng JSON".
C (Azure Portal) — ⚠ thao tác tay, không có tệp nào để lưu.

Ghi nhớ

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

Câu	Mô tả trong đề	Khoá
⚠ #19513	⚠ viết SCRIPT chạy từ dòng lệnh mọi hệ điều hành	⚠ PowerShell / CLI
⚠ #19630 (câu này)	⚠ định nghĩa bằng JSON, đưa vào quản lý mã	⚠ ARM template
⚠ Cặp đối xứng	⚠ cùng bộ phương án, hoán đổi khoá
⚠ Điểm phân định	⚠ SCRIPT (mệnh lệnh) hay TỆP KHAI BÁO

⚠ Mệnh lệnh và khai báo — nhắc lại: | Loại | Mô tả gì | Công cụ | |---|---|---| | ⚠ Mệnh lệnh | ⚠ CÁC BƯỚC phải làm | ⚠ CLI, PowerShell | | ⚠ Khai báo | ⚠ TRẠNG THÁI mong muốn | ⚠ ARM, Bicep, Terraform | | ⚠ Khai báo | ⚠ chạy lại nhiều lần vẫn cho cùng kết quả |

Từ khoá nhận diện:

"tệp JSON, Infrastructure as Code" → ⚠ ARM template "script chạy từ dòng lệnh" → ⚠ CLI, PowerShell "cú pháp gọn hơn ARM" → ⚠ Bicep "bấm chuột" → ⚠ Portal

⚠ Bicep — bản kế nhiệm của ARM JSON	Nội dung
⚠ Cú pháp gọn hơn nhiều
⚠ Biên dịch RA chính ARM JSON
⚠ Có kiểm tra kiểu và gợi ý trong trình soạn thảo
⚠ Không cần state file như Terraform
⚠ Khuyến nghị hiện nay	⚠ dùng Bicep cho dự án mới trên Azure

⚠ Lợi ích của Infrastructure as Code	Lợi ích
⚠ Dựng lại môi trường giống hệt
⚠ Review thay đổi hạ tầng như review mã
⚠ Lịch sử ai đổi gì, khi nào
⚠ Dev, test, prod dùng chung một template khác tham số
⚠ Khôi phục thảm hoạ nhanh
⚠ Giá trị lớn nhất	⚠ hết cảnh "môi trường test khác prod mà không ai biết khác chỗ nào"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hạ tầng có được mô tả bằng mã không | | | Dev và prod có dùng chung template không | | | Đã chạy what-if trước khi triển khai chưa | |

Và giá trị của Infrastructure as Code chỉ thật sự cảm nhận được vào một thời điểm: khi cần dựng lại toàn bộ môi trường và bạn biết chắc nó sẽ giống hệt cái 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ớ