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

Câu 21 Relational DB management

You are having trouble connecting to an Azure SQL Database inside Azure from your home. Other clients are able to connect to it successfully. You have the software installed, and are able to connect to other Azure SQL Databases on your subscription. What is the most likely reason you can't connect to this particular SQL Database?

A You need to give the user specific rights to the individual DB
B You need to add your client IP address to the firewall.
C You need to connect through port 1433
D You need to grant your Azure AD user read rights to the DB

Xem giải thích

Đáp án

B — Bạn cần thêm địa chỉ IP máy khách của mình vào tường lửa.

Vì sao đúng

⚠ Đọc kỹ các manh mối trong đề, chúng loại hết các nguyên nhân khác: | Manh mối | Loại trừ | |---|---| | ⚠ Người khác kết nối được | ⚠ máy chủ vẫn chạy bình thường | | ⚠ Bạn kết nối được CSDL khác cùng subscription | ⚠ phần mềm và cổng 1433 đều ổn | | ⚠ Chỉ CSDL NÀY không vào được | ⚠ khác biệt nằm ở cấu hình của riêng nó |

⚠ Phần mềm: OK
⚠ Cổng 1433: OK (kết nối được DB khác)
⚠ Máy chủ: OK (người khác vào được)
        ↓
⚠ Còn lại: IP nhà bạn chưa nằm trong luật tường lửa
   ⚠ của máy chủ hoặc database này

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

C (cần kết nối qua cổng 1433) — ⚠ đã loại: ⚠ bạn kết nối được CSDL Azure khác, ⚠ nghĩa là cổng 1433 đang thông.
A và D (thiếu quyền trên database) — ⚠ sẽ cho lỗi ĐĂNG NHẬP hoặc lỗi quyền, ⚠ chứ không phải ⚠ không kết nối được; ⚠ và tường lửa chặn ⚠ TRƯỚC cả bước xác thực.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #19499 trong cùng lô — ⚠ #19499 hỏi thứ tự xét luật tường lửa, ⚠ câu này hỏi cách chẩn đoán khi bị chặn.

⚠ Thứ tự chẩn đoán khi không kết nối được Azure SQL: | Bước | Kiểm gì | |---|---| | ⚠ 1. Tường lửa | ⚠ IP của bạn có trong luật không | | ⚠ 2. Mạng | ⚠ cổng 1433 có bị chặn ở phía bạn không | | ⚠ 3. Xác thực | ⚠ tên đăng nhập và mật khẩu | | ⚠ 4. Phân quyền | ⚠ có quyền trên database đó không | | ⚠ Nguyên tắc | ⚠ kiểm từ NGOÀI vào TRONG |

Từ khoá nhận diện:

"cannot open server ... requested by the login" → ⚠ TƯỜNG LỬA "login failed for user" → ⚠ xác thực sai "the server principal is not able to access" → ⚠ thiếu quyền "timeout khi kết nối" → ⚠ mạng hoặc cổng bị chặn

⚠ Vì sao IP tại nhà hay gây rắc rối	Lý do
⚠ Phần lớn nhà mạng cấp IP ĐỘNG
⚠ IP đổi sau mỗi lần khởi động lại router
⚠ Luật tường lửa thêm hôm qua hôm nay hết tác dụng
⚠ Giải pháp bền hơn	⚠ VPN của công ty, Bastion, hoặc private endpoint

⚠ Cách thêm IP nhanh	Cách
⚠ Portal có nút "Add client IP"	⚠ tự nhận IP hiện tại
⚠ Hoặc thêm dải IP cố định của văn phòng
⚠ Tránh	⚠ mở dải 0.0.0.0 - 255.255.255.255 cho tiện

⚠ Thông báo lỗi tường lửa rất hữu ích	Nội dung
⚠ Azure SQL ghi RÕ địa chỉ IP bị từ chối
⚠ Chép luôn IP đó vào luật là xong
⚠ Nhiều người	⚠ đọc lướt qua thông báo rồi đi tìm nguyên nhân khác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thông báo lỗi có ghi IP nào bị từ chối không | ⚠ đọc kỹ trước tiên | | IP nhà có phải IP động không | | | Có nên dùng private endpoint thay vì mở IP không | |

Và thói quen tiết kiệm nhiều thời gian nhất khi gỡ lỗi kết nối Azure SQL: đọc hết thông báo lỗi trước khi đoán. Azure ghi thẳng địa chỉ IP đang bị từ chối trong câu thông báo, và phần lớn thời gian đó là toàn bộ câu trả lời.

Câu 22 Non-relational data management

When deploying an Azure Storage account, and you choose Zone Redundant Storage (ZRS), how many copies of your data does Azure keep?

A 3
B 3 copies in each Availability Zone
C 1
D 6

Xem giải thích

Đáp án

A — 3 bản sao.

Vì sao đúng

⚠ ZRS phân tán ba bản sao vào ba availability zone khác nhau trong CÙNG một vùng:

⚠ Vùng (region)
   ⚠ Zone 1 → bản sao 1
   ⚠ Zone 2 → bản sao 2
   ⚠ Zone 3 → bản sao 3
        ↓
⚠ Mất một zone: vẫn còn hai bản
⚠ Mất cả vùng: MẤT HẾT

Mức	Số bản sao	Vị trí
⚠ LRS	⚠ 3	⚠ cùng một trung tâm dữ liệu
⚠ ZRS	⚠ 3	⚠ ba zone khác nhau, cùng vùng
⚠ GRS	⚠ 6	⚠ 3 ở vùng chính + 3 ở vùng phụ
⚠ GZRS	⚠ 6	⚠ 3 zone ở vùng chính + 3 ở vùng phụ

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

B (3 bản trong MỖI zone) — ⚠ bẫy chính: ⚠ như vậy sẽ là 9 bản; ⚠ thực tế là ⚠ mỗi zone MỘT bản.
D (6 bản) — ⚠ đó là GRS hoặc GZRS.
C (1 bản) — ⚠ không có mức nào của Azure Storage chỉ giữ một bản.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #19105 trong cùng lô — ⚠ #19105 hỏi chọn GRS hay ZRS cho tình huống, ⚠ câu này hỏi con số cụ thể.

⚠ Bốn mức nhân bản — bảng đầy đủ: | Mức | Bản sao | Chịu được | |---|---|---| | ⚠ LRS | ⚠ 3 trong một DC | ⚠ hỏng ổ, hỏng rack | | ⚠ ZRS | ⚠ 3 qua 3 zone | ⚠ mất một zone | | ⚠ GRS | ⚠ 6 qua 2 vùng | ⚠ mất cả vùng | | ⚠ GZRS | ⚠ 6, có zone ở vùng chính | ⚠ mất zone VÀ mất vùng | | ⚠ Thêm RA- | ⚠ cho phép ĐỌC từ vùng phụ |

Từ khoá nhận diện:

"3 bản, ba zone" → ⚠ ZRS "6 bản, hai vùng" → ⚠ GRS "đọc được ở vùng phụ" → ⚠ RA-GRS, RA-GZRS "rẻ nhất" → ⚠ LRS

⚠ Availability zone là gì	Nội dung
⚠ Trung tâm dữ liệu VẬT LÝ RIÊNG trong cùng một vùng
⚠ Nguồn điện, làm mát, mạng độc lập
⚠ Cách nhau đủ xa để không cùng chịu một sự cố
⚠ Đủ gần để độ trễ giữa các zone rất thấp
⚠ Không phải vùng nào	⚠ cũng có availability zone

⚠ Chọn mức nào cho việc gì	Chọn
⚠ Dữ liệu tạm, dựng lại được	⚠ LRS
⚠ Dữ liệu sản xuất trong một vùng	⚠ ZRS
⚠ Dữ liệu quan trọng cần chống mất vùng	⚠ GRS hoặc GZRS
⚠ Cần đọc từ vùng phụ khi bình thường	⚠ RA-GZRS
⚠ Đổi mức	⚠ một số chuyển đổi làm được trực tiếp, số khác phải sao chép dữ liệu

⚠ Nhân bản KHÔNG phải sao lưu	Nhắc lại
⚠ Xoá nhầm sẽ nhân bản sang cả 6 bản
⚠ Mã hoá bởi mã độc cũng vậy
⚠ Vẫn cần	⚠ soft delete, versioning, và sao lưu riêng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vùng đang dùng có availability zone không | | | Cần chịu mất zone hay mất cả vùng | | | Đã có soft delete và versioning chưa | ⚠ nhân bản không thay được |

Và điều cần nhắc lại mỗi lần bàn về mức nhân bản lưu trữ: sáu bản sao của một tệp đã bị xoá nhầm vẫn là sáu bản sao của hư không. Nhân bản chống hỏng hóc hạ tầng; nó không chống được sai lầm của con người.

Câu 23 Non-relational deployment

What method of provisioning a non-relational database involves writing a script, which is a set of commands that you can run from any operating system prompt such as Linux, macOS or Windows?

A Visual C#
B Azure Portal
C ARM templates
D PowerShell, or CLI

Xem giải thích

Đáp án

D — PowerShell hoặc CLI.

Vì sao đúng

⚠ Đề mô tả đúng đặc điểm của công cụ dòng lệnh: viết script chạy được trên mọi hệ điều hành.

⚠ Viết script .ps1 hoặc .sh
        ↓
⚠ Chạy trên Linux, macOS, Windows
        ↓
⚠ Lặp lại được, đưa vào CI/CD

Công cụ	Đặc điểm
⚠ Azure PowerShell	⚠ cmdlet, đa nền tảng nhờ PowerShell Core
⚠ Azure CLI	⚠ lệnh `az`, đa nền tảng
⚠ Cloud Shell	⚠ chạy cả hai ngay trong trình duyệt

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

C (ARM template) — ⚠ bẫy gần đúng: ⚠ cũng tự động hoá được, ⚠ nhưng là ⚠ tệp JSON KHAI BÁO, ⚠ không phải "script chạy từ dấu nhắc hệ điều hành".
B (Azure Portal) — ⚠ giao diện đồ hoạ, thao tác tay.
A (Visual C#) — ⚠ ngôn ngữ lập trình; ⚠ gọi SDK được nhưng không phải cách cấp phát tiêu biểu.

Ghi nhớ

⚠ Bốn cách cấp phát tài nguyên Azure — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | ⚠ Portal | ⚠ trực quan, hợp học và thử | | ⚠ PowerShell / CLI | ⚠ script MỆNH LỆNH, tự động hoá | | ⚠ ARM template / Bicep | ⚠ KHAI BÁO, hạ tầng dạng mã | | ⚠ SDK | ⚠ nhúng trong ứng dụng |

Từ khoá nhận diện:

"script chạy từ dòng lệnh" → ⚠ PowerShell / CLI "tệp JSON mô tả trạng thái mong muốn" → ⚠ ARM template "cú pháp gọn hơn ARM" → ⚠ Bicep "bấm chuột tạo tài nguyên" → ⚠ Portal

⚠ Mệnh lệnh và khai báo — khác biệt cốt lõi	Khác biệt
⚠ Mệnh lệnh: mô tả CÁC BƯỚC phải làm	⚠ CLI, PowerShell
⚠ Khai báo: mô tả KẾT QUẢ 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ả	⚠ idempotent
⚠ Script mệnh lệnh	⚠ chạy hai lần có thể tạo trùng hoặc lỗi

⚠ Khi nào dùng cái nào	Khi nào
⚠ Thao tác một lần, khám phá	⚠ Portal hoặc CLI
⚠ Triển khai lặp lại nhiều môi trường	⚠ Bicep hoặc ARM
⚠ Tác vụ vận hành hằng ngày	⚠ CLI trong script
⚠ Thực tế	⚠ hầu hết tổ chức dùng kết hợp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thao tác này sẽ lặp lại bao nhiêu lần | ⚠ quyết định có nên viết mã không | | Có cần chạy trên nhiều hệ điều hành không | | | Script chạy hai lần có an toàn không | |

Và tính chất tách bạch hai nhóm công cụ này rõ nhất, đáng nhớ hơn cả tên gọi: chạy lại một template khai báo là an toàn, chạy lại một script mệnh lệnh thì chưa chắc.

Câu 24 Data processing

Which of the following activities would be considered part of Azure Data Factory's Control Flow?

A Data Flow
B If Condition
C MapReduce
D Copy Data

Xem giải thích

Đáp án

B — If Condition (hoạt động điều kiện).

Vì sao đúng

⚠ Data Factory tách rõ hai khái niệm: | Khái niệm | Nội dung | |---|---| | ⚠ Control Flow | ⚠ ĐIỀU PHỐI: thứ tự, rẽ nhánh, vòng lặp, tham số | | ⚠ Data Flow | ⚠ BIẾN ĐỔI dữ liệu thật sự |

⚠ Control Flow
   ⚠ If Condition
   ⚠ ForEach
   ⚠ Until
   ⚠ Switch
   ⚠ Execute Pipeline
   ⚠ Wait, Web, Lookup
        ↓
⚠ Quyết định LÀM GÌ và THEO THỨ TỰ NÀO

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

A (Data Flow) — ⚠ là hoạt động BIẾN ĐỔI, không phải điều phối.
D (Copy Data) — ⚠ là hoạt động DI CHUYỂN dữ liệu, thuộc nhóm data movement.
C (MapReduce) — ⚠ mô hình xử lý của Hadoop, ⚠ không phải hoạt động control flow của ADF.

Ghi nhớ

⚠ Ba nhóm hoạt động trong Data Factory: | Nhóm | Hoạt động | |---|---| | ⚠ Data movement | ⚠ Copy Data | | ⚠ Data transformation | ⚠ Data Flow, Databricks, HDInsight, Stored Procedure | | ⚠ Control flow | ⚠ If, ForEach, Until, Switch, Wait, Lookup, Execute Pipeline |

Từ khoá nhận diện:

"rẽ nhánh, lặp, điều kiện" → ⚠ control flow "chuyển dữ liệu từ A sang B" → ⚠ Copy activity "biến đổi, làm sạch, join" → ⚠ Mapping Data Flow "lịch chạy, kích hoạt" → ⚠ trigger

⚠ Thành phần chính của Data Factory	Thành phần
⚠ Pipeline	⚠ nhóm hoạt động chạy cùng nhau
⚠ Activity	⚠ một bước công việc
⚠ Dataset	⚠ mô tả cấu trúc dữ liệu
⚠ Linked service	⚠ chuỗi kết nối tới nguồn
⚠ Integration runtime	⚠ hạ tầng tính toán thực thi
⚠ Trigger	⚠ theo lịch, theo cửa sổ, theo sự kiện

⚠ Ba loại Integration Runtime	Loại
⚠ Azure IR	⚠ dịch vụ đám mây, không cần cài gì
⚠ Self-hosted IR	⚠ cài trên máy tại chỗ để tới nguồn nội bộ
⚠ Azure-SSIS IR	⚠ chạy gói SSIS cũ
⚠ Nguồn tại chỗ	⚠ BẮT BUỘC self-hosted IR

⚠ Mapping Data Flow chạy trên gì	Nội dung
⚠ Chạy trên cụm Spark do Azure quản lý
⚠ Bạn không cần viết mã Spark
⚠ Có thời gian khởi động cụm	⚠ vài phút mỗi lần
⚠ Giảm bằng	⚠ time to live cho cụm khi chạy nhiều luồng liên tiếp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hoạt động này điều phối hay biến đổi | | | Nguồn dữ liệu ở đám mây hay tại chỗ | ⚠ quyết định loại IR | | Có nhiều data flow chạy liên tiếp không | ⚠ bật TTL để đỡ khởi động lại cụm |

Và ranh giới cần nắm chắc để trả lời cả nhóm câu hỏi về Data Factory: control flow quyết định thứ tự và điều kiện, data flow mới thật sự chạm vào dữ liệu.

Câu 25 Non-relational data management

Which of the following techniques is an example of Least Privileged Access?

A Just-In-Time (JIT) access
B Enable auditing and logging.
C Have users regularly review their own access using Access Reviews.
D Have managers reguarly review their employees' access using Access Reviews.

Xem giải thích

Đáp án

A — Truy cập Just-In-Time (JIT).

Vì sao đúng

⚠ JIT là hiện thân trực tiếp của đặc quyền tối thiểu trên trục THỜI GIAN:

⚠ Không có JIT
   ⚠ Quyền quản trị: có VĨNH VIỄN
        ↓ ⚠ 99% thời gian không dùng tới
⚠ Có JIT
   ⚠ Bình thường: KHÔNG có quyền
   ⚠ Cần dùng: xin kích hoạt, có thời hạn
   ⚠ Hết hạn: tự thu hồi

JIT giảm điều gì	Nội dung
⚠ Cửa sổ thời gian có thể bị lợi dụng
⚠ Rủi ro khi tài khoản bị chiếm
⚠ Quyền tồn đọng của người đã đổi việc

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

C và D (Access Reviews) — ⚠ là RÀ SOÁT ĐỊNH KỲ: ⚠ hỗ trợ đặc quyền tối thiểu nhưng ⚠ không phải bản thân kỹ thuật đó; ⚠ chúng phát hiện quyền thừa ⚠ sau khi đã cấp.
B (bật kiểm toán và ghi log) — ⚠ là PHÁT HIỆN, không phải giới hạn quyền.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ gần trùng #19524 trong cùng lô và ⚠ đáng chú ý về mặt logic.

Câu	Hỏi gì	Khoá
⚠ #19515 (câu này)	⚠ VÍ DỤ của đặc quyền tối thiểu	⚠ JIT
⚠ #19524	⚠ ĐỊNH NGHĨA đặc quyền tối thiểu	⚠ chỉ có quyền cần cho công việc
⚠ Lưu ý	⚠ phương án A của #19524 chính là mô tả JIT, nhưng ở đó nó KHÔNG phải khoá
⚠ Vì sao không mâu thuẫn	⚠ một câu hỏi ví dụ, một câu hỏi định nghĩa
⚠ Bài học	⚠ JIT là một CÁCH THỰC HIỆN đặc quyền tối thiểu, không phải định nghĩa của nó

⚠ Ba trục của đặc quyền tối thiểu: | Trục | Câu hỏi | |---|---| | ⚠ AI được cấp | ⚠ chỉ người thật sự cần | | ⚠ Được làm GÌ | ⚠ vai trò hẹp nhất đủ dùng | | ⚠ Trong BAO LÂU | ⚠ JIT, có thời hạn |

Từ khoá nhận diện:

"chỉ khi cần, hết hạn tự thu hồi" → ⚠ JIT / PIM "rà soát định kỳ" → ⚠ Access Reviews "ghi lại ai làm gì" → ⚠ auditing "vai trò hẹp nhất" → ⚠ RBAC

⚠ Vì sao quyền vĩnh viễn nguy hiểm	Lý do
⚠ Kẻ chiếm được tài khoản có quyền NGAY
⚠ Người đổi vị trí vẫn giữ quyền cũ	⚠ tích luỹ quyền
⚠ Không ai nhớ đã cấp cho ai từ bao giờ
⚠ JIT đổi	⚠ mặc định từ "có quyền" sang "xin quyền"

⚠ Kết hợp các biện pháp	Kết hợp
⚠ RBAC: giới hạn phạm vi
⚠ PIM/JIT: giới hạn thời gian
⚠ Access Reviews: dọn quyền thừa
⚠ Audit log: phát hiện lạm dụng
⚠ Không cái nào	⚠ thay thế được cái nào

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn bao nhiêu quyền quản trị vĩnh viễn | | | Thời hạn kích hoạt JIT đặt bao lâu | | | Ai duyệt yêu cầu kích hoạt | |

Và cách nói ngắn nhất về sự khác biệt giữa hai nhóm biện pháp: JIT ngăn quyền tồn tại khi không cần, Access Reviews dọn những quyền đã lỡ tồn tại quá lâu.

Câu 26 Analytics workload

Which type of data analytics workload is best for processing data that arrives from an external source once per day?

A Stream processing
B Real-time processing
C Batch processing
D Queue messaging

Xem giải thích

Đáp án

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

Vì sao đúng

⚠ "Một lần mỗi ngày" là dấu hiệu kinh điển của xử lý theo lô:

⚠ Dữ liệu tích luỹ cả ngày
        ↓ ⚠ tới giờ hẹn
⚠ Xử lý CẢ KHỐI một lần
        ↓
⚠ Kết quả sẵn sàng cho báo cáo hôm sau

Đặc điểm xử lý theo lô	Nội dung
⚠ Độ trễ cao	⚠ chấp nhận được
⚠ Thông lượng lớn
⚠ Chi phí thấp hơn	⚠ chỉ chạy khi cần
⚠ Dễ xử lý lại khi lỗi

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

A (stream processing) và B (real-time) — ⚠ dành cho dữ liệu chảy LIÊN TỤC, ⚠ cần kết quả trong vài giây; ⚠ dùng cho dữ liệu về mỗi ngày một lần là ⚠ thừa và tốn kém.
D (queue messaging) — ⚠ là cơ chế TRUYỀN TIN giữa các thành phần, ⚠ không phải mô hình phân tích dữ liệu.

Ghi nhớ

⚠ Batch và Stream — bảng đối chiếu: | Tiêu chí | Batch | Stream | |---|---|---| | ⚠ Dữ liệu | ⚠ hữu hạn, có ranh giới | ⚠ vô hạn, chảy liên tục | | ⚠ Độ trễ | ⚠ phút tới giờ | ⚠ mili giây tới giây | | ⚠ Chi phí | ⚠ thấp hơn | ⚠ cao hơn, chạy liên tục | | ⚠ Ví dụ | ⚠ báo cáo cuối ngày, tổng hợp lương | ⚠ cảm biến IoT, phát hiện gian lận |

Từ khoá nhận diện:

"mỗi ngày một lần, hằng đêm, cuối tháng" → ⚠ batch "ngay lập tức, thời gian thực, cảnh báo tức thì" → ⚠ stream "dữ liệu cảm biến chảy liên tục" → ⚠ stream "bảng lương, hoá đơn cuối kỳ" → ⚠ batch

⚠ Dịch vụ Azure cho từng loại	Dịch vụ
⚠ Batch	⚠ Data Factory, Synapse pipeline, Databricks
⚠ Stream	⚠ Stream Analytics, Event Hubs, Functions
⚠ Nhập dữ liệu dòng	⚠ Event Hubs, IoT Hub
⚠ Hàng đợi tin nhắn	⚠ Service Bus, Queue Storage

⚠ Kiến trúc Lambda — kết hợp cả hai	Nội dung
⚠ Nhánh nóng: stream cho kết quả gần đúng ngay
⚠ Nhánh lạnh: batch cho kết quả chính xác sau
⚠ Kết hợp hai kết quả khi hiển thị
⚠ Vì sao cần	⚠ stream nhanh nhưng khó bảo đảm chính xác tuyệt đối

⚠ Chọn theo câu hỏi nghiệp vụ	Câu hỏi
⚠ Biết muộn 12 tiếng có sao không	⚠ không sao thì dùng batch
⚠ Chậm một phút có mất tiền không	⚠ có thì phải stream
⚠ Sai lầm thường gặp	⚠ chọn thời gian thực vì nghe hiện đại, rồi trả tiền cho thứ không ai cần

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âu hỏi quyết định | | Dữ liệu về theo đợt hay chảy liên tục | | | Chi phí chạy liên tục có đáng không | |

Và câu hỏi duy nhất cần trả lời để chọn giữa hai mô hình, quan trọng hơn mọi so sánh kỹ thuật: kết quả đến muộn bao lâu thì vẫn còn giá trị?

Câu 27 Data processing

Which Azure data service is best used for moving data from one source to another destination, with the ability to transform the data (process it) along the way?

A Azure Machine Learning
B Azure SQL Database
C Azure Data Migration
D Azure Data Factory

Xem giải thích

Đáp án

D — Azure Data Factory.

Vì sao đúng

⚠ Đề mô tả đúng định nghĩa của một dịch vụ ETL/ELT: | Yêu cầu | Data Factory | |---|---| | ⚠ Chuyển dữ liệu từ nguồn sang đích | ⚠ Copy activity, 100+ connector | | ⚠ Biến đổi dọc đường | ⚠ Mapping Data Flow | | ⚠ Lặp lại theo lịch | ⚠ trigger |

⚠ Nguồn (SQL, blob, API, SaaS)
        ↓ ⚠ Copy
⚠ Vùng dàn dựng
        ↓ ⚠ Data Flow
⚠ Làm sạch, join, tổng hợp
        ↓
⚠ Đích (kho dữ liệu, Data Lake)

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

C (Azure Data Migration) — ⚠ bẫy gần đúng nhất: ⚠ DMS ⚠ di chuyển MỘT LẦN khi chuyển đổi hệ thống; ⚠ nó ⚠ không biến đổi dữ liệu và không dùng cho luồng chạy định kỳ.
B (Azure SQL Database) — ⚠ là nơi LƯU dữ liệu, không phải công cụ điều phối.
A (Azure Machine Learning) — ⚠ huấn luyện mô hình.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #19514 trong cùng lô — ⚠ #19514 hỏi chi tiết control flow bên trong ADF, ⚠ câu này hỏi ADF dùng để làm gì.

⚠ ETL và ELT — phân biệt: | Mô hình | Thứ tự | |---|---| | ⚠ ETL | ⚠ trích → BIẾN ĐỔI → nạp | | ⚠ ELT | ⚠ trích → nạp → BIẾN ĐỔI tại đích | | ⚠ ELT phổ biến hơn với đám mây | ⚠ vì kho đích đủ mạnh để tự biến đổi | | ⚠ ADF hỗ trợ | ⚠ cả hai |

Từ khoá nhận diện:

"chuyển và biến đổi dữ liệu định kỳ" → ⚠ Data Factory "chuyển CSDL một lần khi di trú" → ⚠ Database Migration Service "biến đổi bằng Spark có mã" → ⚠ Databricks hoặc Synapse Spark "tất cả trong một: pipeline + kho + Spark" → ⚠ Synapse Analytics hoặc Fabric

⚠ Data Factory và Synapse pipeline	Quan hệ
⚠ Gần như cùng công nghệ
⚠ Synapse gộp pipeline vào một không gian làm việc chung
⚠ Kèm kho dữ liệu, Spark, Data Explorer
⚠ Chọn ADF khi	⚠ chỉ cần điều phối
⚠ Chọn Synapse khi	⚠ muốn cả phân tích trong một nơi

⚠ Điều cần cấu hình cho luồng chạy thật	Điều
⚠ Cơ chế thử lại khi hoạt động thất bại
⚠ Cảnh báo khi pipeline lỗi	⚠ hay bị quên
⚠ Nạp TĂNG DẦN thay vì nạp lại toàn bộ
⚠ Tham số hoá để tái dùng pipeline
⚠ Không có cảnh báo	⚠ dữ liệu ngừng cập nhật mà không ai biết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chuyển một lần hay chạy định kỳ | ⚠ DMS hay ADF | | Đã có cảnh báo khi pipeline lỗi chưa | | | Có nạp tăng dần được không | |

Và cấu hình bị bỏ sót nhiều nhất trong một luồng dữ liệu vừa dựng xong: cảnh báo khi pipeline thất bại. Không có nó, cách phát hiện sự cố thường là một người dùng hỏi vì sao báo cáo vẫn hiển thị số của tuần trước.

Câu 28 Data Warehouse

What type of file system does Azure Data Lake Storage Gen2 use?

A EXT3
B Hadoop Distributed File System (HDFS)
C NTFS
D FAT32

Xem giải thích

Đáp án

B — Hệ tệp phân tán Hadoop (HDFS).

Vì sao đúng

⚠ Data Lake Storage Gen2 = Blob Storage + namespace phân cấp + giao diện tương thích HDFS:

⚠ Blob Storage
        ↓ ⚠ bật hierarchical namespace
⚠ Data Lake Storage Gen2
        ↓
⚠ Có THƯ MỤC thật
⚠ Đổi tên thư mục là thao tác NGUYÊN TỬ
⚠ Phân quyền POSIX (ACL)
⚠ Driver ABFS cho Spark, Hadoop, Databricks

Vì sao quan trọng	Nội dung
⚠ Công cụ phân tích nói "ngôn ngữ" HDFS
⚠ Spark và Hadoop dùng được trực tiếp
⚠ Không phải sao chép dữ liệu đi nơi khác

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

C (NTFS) — ⚠ hệ tệp của Windows, dùng cho đĩa cục bộ.
A (EXT3) — ⚠ hệ tệp Linux.
D (FAT32) — ⚠ hệ tệp cũ cho thiết bị di động, giới hạn tệp 4GB.

⚠ Cả ba đều là hệ tệp của MỘT máy, ⚠ không phải hệ tệp phân tán cho dữ liệu lớn.

Ghi nhớ

⚠ Data Lake Gen2 — điểm khác Blob thường: | Điểm | Blob thường | Data Lake Gen2 | |---|---|---| | ⚠ Cấu trúc | ⚠ phẳng, thư mục là ẢO | ⚠ phân cấp THẬT | | ⚠ Đổi tên thư mục | ⚠ phải sao chép từng blob | ⚠ NGUYÊN TỬ, tức thì | | ⚠ Phân quyền | ⚠ RBAC ở mức container | ⚠ + ACL POSIX tới từng tệp | | ⚠ Giao diện | ⚠ REST blob | ⚠ + ABFS tương thích HDFS |

Từ khoá nhận diện:

"HDFS, phân tích dữ liệu lớn" → ⚠ Data Lake Gen2 "lưu ảnh, video, sao lưu" → ⚠ Blob thường "namespace phân cấp" → ⚠ Data Lake Gen2 "chia sẻ SMB" → ⚠ Azure Files

⚠ Bật namespace phân cấp — lưu ý	Lưu ý
⚠ Chỉ bật được LÚC TẠO tài khoản
⚠ Không bật được sau
⚠ Muốn có phải tạo tài khoản mới và sao chép dữ liệu
⚠ Vì vậy	⚠ quyết định ngay từ đầu nếu có ý định phân tích

⚠ Vì sao đổi tên thư mục quan trọng với ETL	Lý do
⚠ Luồng dữ liệu hay ghi vào thư mục tạm rồi đổi tên
⚠ Đổi tên nguyên tử = công bố kết quả tức thì
⚠ Trên blob phẳng, việc này là sao chép hàng nghìn tệp
⚠ Ảnh hưởng	⚠ hiệu năng và tính đúng đắn của luồng dữ liệu

⚠ Tổ chức thư mục trong data lake	Cách
⚠ Phân vùng theo NGÀY	⚠ /nam=2026/thang=09/ngay=03/
⚠ Giúp công cụ chỉ đọc phần cần	⚠ partition pruning
⚠ Chia tầng: raw, curated, presentation	⚠ kiến trúc medallion
⚠ Tệp nhỏ quá nhiều	⚠ làm chậm mọi thứ — nên gộp lại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Namespace phân cấp đã bật chưa | ⚠ không sửa được sau | | Dữ liệu có phân vùng theo ngày không | | | Có quá nhiều tệp nhỏ không | |

Và vấn đề hiệu năng phổ biến nhất trong một data lake sau vài tháng vận hành: hàng triệu tệp nhỏ. Mỗi tệp là một lần mở và đóng, và chi phí đó nhanh chóng lớn hơn chính việc đọc dữ liệu.

Câu 29 Non-relational data management

Which of the following is a valid IP address range using the CIDR address method?

A 110.0.0.0/8
B 110.0.0.0-110.0.0.255
C 110.0.0.*
D 110.0.0.0-255

Xem giải thích

Đáp án

A — 110.0.0.0/8

Vì sao đúng

⚠ CIDR viết theo dạng ĐỊA CHỈ / SỐ BIT tiền tố:

⚠ 110.0.0.0/8
   ⚠ 8 bit đầu = phần MẠNG cố định
   ⚠ 24 bit còn lại = phần HOST
        ↓
⚠ Dải: 110.0.0.0 → 110.255.255.255
⚠ Số địa chỉ: 2^24 ≈ 16,7 triệu

Tiền tố	Số địa chỉ
⚠ /8	⚠ 16.777.216
⚠ /16	⚠ 65.536
⚠ /24	⚠ 256
⚠ /29	⚠ 8 — nhỏ nhất Azure cho phép cho subnet

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

B (110.0.0.0-110.0.0.255) — ⚠ là dải viết bằng GẠCH NGANG, ⚠ đúng về ý nghĩa nhưng ⚠ không phải ký hiệu CIDR.
C (110.0.0.*) — ⚠ ký hiệu ký tự đại diện, không phải CIDR.
D (110.0.0.0-255) — ⚠ cú pháp không hợp lệ ở bất kỳ chuẩn nào.

Ghi nhớ

⚠ CIDR trong Azure — con số phải nhớ: | Điểm | Nội dung | |---|---| | ⚠ Azure giữ 5 địa chỉ mỗi subnet | ⚠ network, 3 địa chỉ Azure, broadcast | | ⚠ Subnet /24 → 251 địa chỉ dùng được | ⚠ không phải 254 | | ⚠ Subnet nhỏ nhất | ⚠ /29 → 3 địa chỉ dùng được | | ⚠ Subnet lớn nhất | ⚠ /2 | | ⚠ VNet phổ biến | ⚠ /16, chia thành các subnet /24 |

Từ khoá nhận diện:

"x.x.x.x/n" → ⚠ CIDR "tiền tố càng NHỎ, dải càng LỚN" → ⚠ /8 lớn hơn /24 nhiều "dải riêng tư" → ⚠ 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

⚠ Vì sao Azure giữ 5 địa chỉ	Nội dung
⚠ .0 địa chỉ mạng
⚠ .1 cổng mặc định của Azure
⚠ .2 và .3 cho DNS của Azure
⚠ Địa chỉ cuối là broadcast
⚠ Hậu quả	⚠ tính nhầm khi thiết kế subnet nhỏ

⚠ Lỗi thiết kế mạng hay gặp	Lỗi
⚠ Dải VNet CHỒNG LẤN nhau	⚠ không peering được
⚠ Chồng lấn với mạng tại chỗ	⚠ không dựng VPN được
⚠ Subnet quá nhỏ, hết địa chỉ khi mở rộng
⚠ Không chừa chỗ cho subnet dịch vụ	⚠ Bastion, Firewall, Gateway đều cần subnet riêng
⚠ Không đổi được	⚠ thu hẹp dải VNet đang dùng rất phiền

⚠ Subnet đặc biệt Azure yêu cầu	Subnet
⚠ GatewaySubnet	⚠ tên CỐ ĐỊNH, cho VPN/ExpressRoute
⚠ AzureFirewallSubnet	⚠ tối thiểu /26
⚠ AzureBastionSubnet	⚠ tối thiểu /26
⚠ Sai tên	⚠ dịch vụ không triển khai được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dải có chồng lấn với mạng nào không | ⚠ kiểm trước khi tạo VNet | | Đã chừa chỗ cho subnet dịch vụ chưa | | | Subnet có đủ địa chỉ khi mở rộng không | |

Và quyết định mạng khó sửa nhất sau khi đã triển khai, đáng dành thời gian nhất lúc thiết kế: chọn dải địa chỉ cho VNet. Trùng dải với một mạng khác là mất luôn khả năng kết nối hai bên với nhau.

Câu 30 Non-relational deployment

What is the minimum number of Request Units per second (RU/s) that you can allocate to a Cosmos DB database or container?

A 0 RU/s
B 100 RU/s
C 400 RU/s
D 1000 RU/s

Xem giải thích

Đáp án

C — 400 RU/s.

Vì sao đúng

⚠ 400 RU/s là mức cấp phát tối thiểu cho một container hoặc database ở chế độ provisioned: | Chế độ | Mức tối thiểu | |---|---| | ⚠ Provisioned thủ công | ⚠ 400 RU/s | | ⚠ Autoscale | ⚠ tối đa 1.000, tự co xuống 100 | | ⚠ Serverless | ⚠ không cấp phát, trả theo lượt dùng | | ⚠ Free tier | ⚠ 1.000 RU/s đầu miễn phí |

⚠ RU = đơn vị đo TÀI NGUYÊN cho một thao tác
   ⚠ đọc 1 tài liệu 1KB ≈ 1 RU
   ⚠ ghi tốn nhiều RU hơn đọc
   ⚠ truy vấn phức tạp tốn nhiều hơn nữa
        ↓
⚠ Vượt RU/s đã cấp → bị điều tiết (lỗi 429)

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

B (100 RU/s) — ⚠ là mức sàn của AUTOSCALE, ⚠ không phải mức cấp phát tối thiểu thủ công.
A (0 RU/s) — ⚠ chỉ đúng với serverless, ⚠ nơi không có khái niệm cấp phát.
D (1.000 RU/s) — ⚠ là hạn mức của gói miễn phí, không phải mức tối thiểu.

Ghi nhớ

⚠ Ba chế độ thông lượng Cosmos DB: | Chế độ | Dùng khi | |---|---| | ⚠ Provisioned thủ công | ⚠ tải ổn định, dự đoán được | | ⚠ Autoscale | ⚠ tải thất thường, co giãn 10%–100% | | ⚠ Serverless | ⚠ tải thấp, thưa, môi trường dev |

Từ khoá nhận diện:

"tối thiểu cấp phát" → ⚠ 400 RU/s "lỗi 429, too many requests" → ⚠ vượt RU, cần tăng hoặc tối ưu "tải thất thường" → ⚠ autoscale "dev/test, dùng rất ít" → ⚠ serverless

⚠ Điều làm tốn RU	Điều
⚠ Truy vấn CHÉO PHÂN VÙNG	⚠ tốn nhất
⚠ Tài liệu lớn
⚠ Đánh chỉ mục mọi trường	⚠ mặc định, tốn RU khi GHI
⚠ Mức nhất quán mạnh
⚠ Tối ưu đầu tiên	⚠ partition key khớp truy vấn hay dùng

⚠ Xử lý lỗi 429	Cách
⚠ SDK tự thử lại theo header retry-after
⚠ Tăng RU nếu xảy ra thường xuyên
⚠ Hoặc tối ưu truy vấn và chỉ mục
⚠ Đừng	⚠ cứ tăng RU mà không tìm nguyên nhân

⚠ Chia RU giữa database và container	Cách
⚠ Cấp ở mức DATABASE: các container DÙNG CHUNG	⚠ rẻ khi có nhiều container nhỏ
⚠ Cấp ở mức CONTAINER: riêng biệt, đảm bảo hơn
⚠ Chung có rủi ro	⚠ một container nuốt hết RU của cả nhóm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có container nào cấp phát dư không | ⚠ nhất là môi trường dev | | Truy vấn có chéo phân vùng không | | | Đang gặp bao nhiêu lỗi 429 mỗi ngày | |

Và cách kiểm soát chi phí Cosmos DB hiệu quả nhất, trước cả việc chỉnh mức RU: xem lại partition key. Truy vấn chéo phân vùng tiêu tốn RU gấp nhiều lần, và không mức cấp phát nào đủ để bù cho một thiết kế khoá sai.

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ớ