Ngân hàng đề — Microsoft Azure Security Technology

Đáp án

B, C và E — VPN Gateway, Azure ExpressRoute, và ExpressRoute kèm VPN dự phòng.

Vì sao đúng

⚠ Ba lựa chọn nối mạng TẠI CHỖ với VNet: | Lựa chọn | Đặc điểm | |---|---| | ⚠ VPN Gateway | ⚠ đường hầm IPsec qua Internet, mã hoá sẵn, rẻ | | ⚠ ExpressRoute | ⚠ kết nối riêng, băng thông cao, độ trễ ổn định, đắt | | ⚠ ExpressRoute kèm VPN dự phòng | ⚠ kết hợp cả hai, dự phòng tự động |

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

• A (Virtual Network Peering) — ⚠ chỉ nối VNet với VNet TRONG Azure, không nối được mạng tại chỗ.

• D (Network Watcher) — ⚠ bộ công cụ CHẨN ĐOÁN mạng, không tạo kết nối.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23251 ở lô trước hỏi nên chọn gì cho kết nối riêng có dự phòng (đáp án: ExpressRoute chính, VPN S2S dự phòng). ⚠ Câu này liệt kê toàn bộ lựa chọn. Hai câu nhất quán.

⚠ Bảng chọn kết nối lai: | Nhu cầu | Chọn | |---|---| | ⚠ Rẻ, nhanh dựng, có mã hoá | ⚠ VPN Site-to-Site | | ⚠ Băng thông cao, độ trễ ổn định | ⚠ ExpressRoute | | ⚠ Quan trọng, cần dự phòng | ⚠ ExpressRoute + VPN | | ⚠ Một máy tính từ xa | ⚠ Point-to-Site | | ⚠ Nhiều site, nhiều vùng | ⚠ Virtual WAN |

Từ khoá nhận diện:

"mã hoá lưu lượng" → ⚠ VPN Gateway "kết nối riêng, không qua Internet" → ⚠ ExpressRoute "nối hai VNet trong Azure" → ⚠ peering, KHÔNG nối được tại chỗ "chẩn đoán mạng" → ⚠ Network Watcher

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có đường dự phòng khi đường chính hỏng không | | | Lần cuối kiểm thử chuyển đổi là khi nào | | | Dữ liệu đi qua có yêu cầu mã hoá theo quy định không | |

Và điều phải làm rõ ngay đầu mỗi thiết kế kết nối lai: "riêng tư" và "được mã hoá" là hai yêu cầu tách biệt. ExpressRoute cho vế đầu, VPN cho vế sau — cần cả hai thì phải chồng cả hai lên nhau.

Đáp án

C — NSG flow logs.

Vì sao đúng

⚠ NSG flow logs ghi lại từng LUỒNG lưu lượng đi qua NSG: | Ghi lại gì | Nội dung | |---|---| | ⚠ IP nguồn và đích | | | ⚠ Cổng nguồn và đích | | | ⚠ Giao thức | | | ⚠ Chiều — vào hay ra | | | ⚠ Quyết định — CHO PHÉP hay CHẶN | ⚠ phần quan trọng nhất khi điều tra | | ⚠ Số byte và số gói | ⚠ ở phiên bản 2 |

⚠ Muốn xem dưới dạng biểu đồ và phân tích thì bật thêm Traffic Analytics trên nền dữ liệu này.

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

• A (NSG diagnostics) — ⚠ công cụ kiểm tra MỘT luồng cụ thể theo yêu cầu, không ghi lại toàn bộ lưu lượng theo thời gian.

• B (User-defined routes) — ⚠ về ĐỊNH TUYẾN, không ghi nhật ký.

• D (Application Security Group) — ⚠ nhóm card mạng để viết luật gọn, không ghi nhật ký.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23260 ở lô trước hỏi thành phần nào KHÔNG thuộc Traffic Analytics (đáp án: backend pool), và nêu rõ NSG flow logs là dữ liệu thô của Traffic Analytics. ⚠ Hai câu bổ sung nhau.

⚠ Kiến trúc thu thập và phân tích:

⚠ Lưu lượng qua NSG
        ↓ ⚠ NSG flow logs (PHẢI BẬT)
⚠ Storage Account
        ↓ ⚠ Traffic Analytics xử lý
⚠ Log Analytics workspace
        ↓
⚠ Biểu đồ, truy vấn KQL, cảnh báo

Từ khoá nhận diện:

"ghi lại luồng lưu lượng theo thời gian" → ⚠ NSG flow logs "kiểm tra một luồng cụ thể ngay bây giờ" → ⚠ IP flow verify hoặc NSG diagnostics "phân tích và trực quan hoá" → ⚠ Traffic Analytics "tổng hợp luật đang áp lên NIC" → ⚠ effective security rules

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Flow logs đã bật cho NSG quan trọng chưa | | | Thời gian giữ có đủ cho điều tra không | | | Chi phí nhập log hằng tháng là bao nhiêu | |

Và điều nên làm trước khi cần tới nó: bật nhật ký luồng ngay hôm nay. Dữ liệu chỉ tồn tại từ lúc bật, nên khi có sự cố mới đi bật thì đúng khoảng thời gian bạn cần nhìn lại đã vĩnh viễn không còn.

Đáp án

B — Virtual Network Service Endpoints.

Vì sao đúng

⚠ Service Endpoint mở rộng "danh tính" của subnet tới dịch vụ PaaS: | Cơ chế | Nội dung | |---|---| | ⚠ Bật service endpoint cho subnet | ⚠ lưu lượng mang theo danh tính subnet | | ⚠ Cấu hình firewall của Storage | ⚠ chỉ chấp nhận subnet đó | | ⚠ Lưu lượng đi qua backbone Microsoft | ⚠ không ra Internet công cộng | | ⚠ MIỄN PHÍ | |

⚠ Phải làm ĐỦ HAI phía — bật endpoint ở subnet, và khai subnet đó trong firewall của Storage. Thiếu phía thứ hai thì dịch vụ vẫn mở cho mọi nơi.

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

• A (Private Link services) — ⚠ là mặt NHÀ CUNG CẤP của Private Link, dùng khi bạn phơi dịch vụ CỦA MÌNH; ở đây bạn là bên tiêu thụ.

• C (Azure Functions) và D (SQL Managed Instance) — ⚠ không liên quan tới kiểm soát truy cập Storage.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này GẦN TRÙNG với câu #23805 trong CÙNG lô.

⚠ Service Endpoint và Private Endpoint — bảng phải thuộc: | Tiêu chí | Service Endpoint | Private Endpoint | |---|---|---| | ⚠ Địa chỉ dịch vụ | ⚠ IP CÔNG CỘNG | ⚠ IP RIÊNG trong VNet | | ⚠ Chi phí | ⚠ miễn phí | ⚠ tính tiền | | ⚠ Từ mạng tại chỗ | ⚠ KHÔNG dùng được | ⚠ dùng được | | ⚠ Cần DNS riêng | ⚠ không | ⚠ CÓ | | ⚠ Phạm vi | ⚠ cả dịch vụ | ⚠ một tài nguyên cụ thể |

Từ khoá nhận diện:

"chỉ subnet này truy cập được" → ⚠ Service Endpoint "dịch vụ có IP riêng trong VNet" → ⚠ Private Endpoint "phơi dịch vụ của mình cho khách" → ⚠ Private Link Service "truy cập từ mạng tại chỗ" → ⚠ Private Endpoint

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Firewall của Storage đã khai đúng subnet chưa | ⚠ bật endpoint thôi chưa đủ | | Có cần truy cập từ mạng tại chỗ không | | | Dữ liệu nhạy cảm tới mức cần Private Endpoint chưa | |

Và bước hay bị bỏ sót nhất khi dùng Service Endpoint: cấu hình firewall ở phía dịch vụ. Bật endpoint chỉ mở đường tối ưu — phần chặn thật nằm ở tường lửa của chính Storage.

Đáp án

B và C — Private Link và Private Endpoints.

Vì sao đúng

⚠ Private Link là công nghệ, Private Endpoint là hiện thân của nó trong VNet của bạn: | Thành phần | Vai trò | |---|---| | ⚠ Azure Private Link | ⚠ công nghệ nền, đưa dịch vụ PaaS vào mạng riêng | | ⚠ Private Endpoint | ⚠ card mạng mang IP RIÊNG trong subnet của bạn, trỏ tới dịch vụ đó |

⚠ Không có Private Endpoint:
   ⚠ VM  →  ⚠ IP công cộng của Storage
⚠ Có Private Endpoint:
   ⚠ VM  →  ⚠ 10.0.1.5 (IP riêng)  →  ⚠ Storage

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

• A (Service Endpoints) — ⚠ vẫn dùng IP CÔNG CỘNG của dịch vụ, chỉ đổi đường đi; đề yêu cầu rõ qua IP riêng.

• D (Azure Functions) — ⚠ dịch vụ điện toán, không liên quan.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này GẦN TRÙNG với câu #23806 trong CÙNG lô — cùng hỏi cách truy cập PaaS qua kết nối riêng, cùng khoá Private Endpoints và Private Link.

⚠ Ba khái niệm trong họ Private Link: | Khái niệm | Ai dùng | |---|---| | ⚠ Private Endpoint | ⚠ bên TIÊU THỤ — bạn truy cập dịch vụ PaaS | | ⚠ Private Link Service | ⚠ bên CUNG CẤP — bạn phơi dịch vụ của mình | | ⚠ Private Link | ⚠ tên chung của cả công nghệ |

Từ khoá nhận diện:

"IP riêng trong VNet cho dịch vụ PaaS" → ⚠ Private Endpoint "vẫn IP công cộng, chỉ đổi đường" → ⚠ Service Endpoint "phơi dịch vụ của mình" → ⚠ Private Link Service "tên miền phải phân giải về IP riêng" → ⚠ Private DNS zone

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Từ trong VNet, tên dịch vụ phân giải ra IP nào | ⚠ nslookup | | Truy cập công cộng của dịch vụ đã tắt chưa | | | Private DNS zone đã liên kết đúng VNet chưa | |

Và mắt xích quyết định của mọi kiến trúc Private Endpoint: DNS. Endpoint dựng đúng nhưng tên miền vẫn phân giải ra địa chỉ công cộng thì lưu lượng vẫn đi đường cũ — và không có cảnh báo nào cho bạn biết điều đó.

Đáp án

D — App Service Environment (ASE).

Vì sao đúng

⚠ ASE là App Service chạy TRÊN HẠ TẦNG RIÊNG, đặt bên trong VNet của bạn: | Đặc điểm | Nội dung | |---|---| | ⚠ Đơn nhiệm — single tenant | ⚠ không chia sẻ hạ tầng với khách hàng khác | | ⚠ Triển khai TRONG VNet của bạn | ⚠ có địa chỉ IP trong subnet của bạn | | ⚠ Kiểm soát mạng đầy đủ | ⚠ NSG, UDR, buộc lưu lượng qua firewall | | ⚠ Quy mô lớn | ⚠ nhiều instance hơn App Service thường | | ⚠ Hỗ trợ yêu cầu tuân thủ nghiêm ngặt | ⚠ PCI DSS, FedRAMP |

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

• B (Service Endpoints) — ⚠ kiểm soát truy cập TỚI dịch vụ PaaS, không tạo môi trường cách ly cho ứng dụng.

• A (SQL Managed Instance) — ⚠ là CSDL, không phải nơi chạy ứng dụng.

• C (Container Instances) — ⚠ chạy container đơn lẻ, không có mức cách ly mạng của ASE.

Ghi nhớ

⚠ Ba mức cách ly cho ứng dụng web trên Azure: | Mức | Dịch vụ | |---|---| | ⚠ Dùng chung | ⚠ App Service bậc Basic, Standard, Premium — hạ tầng chia sẻ | | ⚠ Cách ly mạng một phần | ⚠ App Service kèm VNet integration và private endpoint | | ⚠ Cách ly hoàn toàn | ⚠ App Service Environment — hạ tầng riêng trong VNet |

Từ khoá nhận diện:

"môi trường cách ly, hạ tầng riêng" → ⚠ ASE "ứng dụng gọi được tài nguyên trong VNet" → ⚠ VNet integration, rẻ hơn nhiều "tuân thủ nghiêm ngặt, đơn nhiệm" → ⚠ ASE "container chạy riêng" → ⚠ Container Apps environment hoặc AKS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Yêu cầu cách ly đến từ quy định hay từ cảm giác | ⚠ ASE rất đắt | | VNet integration kèm private endpoint đã đủ chưa | | | Subnet dành cho ASE có đủ lớn không | |

Và câu hỏi nên đặt trước khi chọn ASE: App Service Premium kèm VNet integration và private endpoint đã đáp ứng được chưa? Với đa số trường hợp, câu trả lời là có — và chênh lệch chi phí là rất lớn.

Đáp án

D — Managed Identities.

Vì sao đúng

⚠ Managed Identity cho phép ứng dụng xác thực mà KHÔNG có bí mật nào: | Bước | Nội dung | |---|---| | ⚠ Bật managed identity cho tài nguyên | ⚠ App Service, VM, Function... | | ⚠ Gán quyền RBAC trên Storage | ⚠ ví dụ Storage Blob Data Reader | | ⚠ Ứng dụng gọi Azure SDK | ⚠ DefaultAzureCredential tự lấy token | | ⚠ KHÔNG có chuỗi kết nối hay khoá nào trong mã | |

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

• C (Service Principals) — ⚠ cũng là định danh cho ứng dụng, NHƯNG cần client secret hoặc chứng chỉ — ⚠ tức là vẫn có bí mật phải quản. ⚠ Managed identity chính là service principal được Azure tự quản khoá.

• A (Security Principals) — ⚠ thuật ngữ CHUNG cho mọi thực thể được cấp quyền: người dùng, nhóm, service principal, managed identity.

• B (OAuth permission grants) — ⚠ bản ghi quyền đã được đồng ý, không phải cơ chế xác thực.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23793 trong lô này hỏi công dụng chính của Managed Identity. ⚠ Câu này là một tình huống áp dụng cụ thể. Hai câu nhất quán.

⚠ Managed Identity và Service Principal — quan hệ: | Khái niệm | Nội dung | |---|---| | ⚠ Service principal | ⚠ định danh của ứng dụng trong tenant | | ⚠ Managed identity | ⚠ một service principal mà AZURE TỰ QUẢN vòng đời và khoá | | ⚠ Khác biệt then chốt | ⚠ service principal thường thì BẠN quản secret; managed identity thì không có secret |

Từ khoá nhận diện:

"không nhúng thông tin đăng nhập" → ⚠ managed identity "ứng dụng chạy NGOÀI Azure gọi API Azure" → ⚠ service principal kèm chứng chỉ "cất bí mật của bên thứ ba" → ⚠ Key Vault "cấp quyền tạm cho một tệp blob" → ⚠ SAS token

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn chuỗi kết nối Storage nào trong mã không | ⚠ quét cả lịch sử Git | | Shared key access của Storage đã tắt chưa | | | Managed identity có được cấp đúng vai trò DỮ LIỆU không | ⚠ Contributor thường là chưa đủ |

Và điểm hay gây bối rối khi mới chuyển sang managed identity: vai trò Contributor ở mức tài nguyên không cho phép đọc dữ liệu trong blob. Phải gán thêm một vai trò thuộc nhóm "Storage Blob Data ..." thì mới truy cập được nội dung.

Đáp án

A, B và C — Service Principals, Permission scopes, và OAuth permission grants.

Vì sao đúng

⚠ Ba thành phần quyết định ứng dụng truy cập được gì: | Thành phần | Vai trò | |---|---| | ⚠ Service Principal | ⚠ định danh của ứng dụng TRONG tenant này — nơi gán quyền | | ⚠ Permission scopes | ⚠ ứng dụng XIN những quyền nào | | ⚠ OAuth permission grants | ⚠ bản ghi những quyền đã ĐƯỢC ĐỒNG Ý |

⚠ App Registration  →  ⚠ định nghĩa ứng dụng (toàn cầu)
        ↓
⚠ Service Principal →  ⚠ hiện thân trong tenant, nơi gán quyền
        ↓
⚠ Permission scopes →  ⚠ xin quyền gì
        ↓
⚠ Consent           →  ⚠ OAuth permission grant được tạo

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

• D (Microsoft Entra Application Proxy) — ⚠ phơi ứng dụng web TẠI CHỖ ra Internet qua Entra ID; là kịch bản truy cập từ xa, không liên quan tới việc giới hạn quyền của ứng dụng.

Ghi nhớ

⚠ Application Registration và Service Principal — quan hệ: | Khái niệm | Nội dung | |---|---| | ⚠ Application object | ⚠ định nghĩa GỐC, chỉ tồn tại ở tenant chủ | | ⚠ Service principal | ⚠ HIỆN THÂN trong từng tenant dùng ứng dụng đó | | ⚠ Ví dụ | ⚠ một ứng dụng SaaS có MỘT app object, và một service principal ở MỖI tenant khách hàng | | ⚠ Gán quyền RBAC | ⚠ gán cho SERVICE PRINCIPAL, không phải app object |

⚠ Hai loại quyền: | Loại | Nội dung | |---|---| | ⚠ Delegated permissions | ⚠ ứng dụng hành động THAY MẶT người dùng đang đăng nhập | | ⚠ Application permissions | ⚠ ứng dụng hành động TỰ THÂN, không có người dùng | | ⚠ Delegated | ⚠ quyền hiệu dụng = giao của quyền ứng dụng và quyền người dùng | | ⚠ Application | ⚠ quyền đầy đủ, luôn cần ADMIN CONSENT |

Từ khoá nhận diện:

"định danh ứng dụng trong tenant" → ⚠ service principal "quyền ứng dụng xin" → ⚠ permission scope "quyền đã được đồng ý" → ⚠ OAuth permission grant "phơi ứng dụng tại chỗ ra Internet" → ⚠ Application Proxy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người dùng có tự đồng ý cho ứng dụng được không | ⚠ nên tắt hoặc giới hạn | | Ứng dụng nào đang giữ quyền application rộng | | | Có service principal nào lâu không dùng không | |

Và một hướng tấn công thường bị đánh giá thấp: illicit consent grant — kẻ tấn công dụ người dùng đồng ý cho một ứng dụng độc hại. Không cần mật khẩu, không cần vượt MFA, mà vẫn đọc được hộp thư của nạn nhân. Tắt quyền tự đồng ý của người dùng là biện pháp trực tiếp nhất.

Đáp án

D — Application Security Groups (ASG).

Vì sao đúng

⚠ Đề nhấn mạnh hạn chế lưu lượng theo VAI TRÒ của máy trong ứng dụng — đó chính là bài toán ASG sinh ra để giải: | Không có ASG | Có ASG | |---|---| | ⚠ Luật viết theo dải IP | ⚠ luật viết theo TÊN VAI TRÒ | | ⚠ Thêm máy phải sửa luật | ⚠ thêm máy vào nhóm là xong | | ⚠ Luật khó đọc | ⚠ luật tự giải thích ý đồ |

⚠ Luật NSG: nguồn = ASG-Web, đích = ASG-App, cổng 8080, Allow
   ⚠ Không có một địa chỉ IP nào trong luật

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

• C (Network Security Groups) — ⚠ là nơi CHỨA luật và cũng lọc được, nhưng đề nhấn "dựa trên VAI TRÒ" — ⚠ đó là điểm mạnh riêng của ASG; ⚠ thực tế hai thứ dùng CÙNG nhau: ASG nhóm máy, NSG chứa luật tham chiếu nhóm đó.

• A (VNet Peering) — ⚠ nối hai VNet, không lọc lưu lượng.

• B (User-defined routes) — ⚠ quyết định gói đi đâu, không quyết định cho phép hay chặn.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23263 ở lô trước hỏi việc nào làm được bằng NSG và ASG (đáp án gồm cả hai). ⚠ Câu này nhấn riêng vào yếu tố VAI TRÒ nên chọn ASG. Hai câu bổ sung nhau, giữ nguyên cả hai khoá.

⚠ ASG và NSG dùng chung thế nào: | Bước | Nội dung | |---|---| | ⚠ Tạo ASG theo vai trò | ⚠ ASG-Web, ASG-App, ASG-Db | | ⚠ Gắn card mạng vào ASG tương ứng | | | ⚠ Viết luật NSG tham chiếu tên ASG | | | ⚠ Máy mới vào nhóm là tự áp luật | |

Từ khoá nhận diện:

"theo vai trò của máy trong ứng dụng" → ⚠ ASG "luật lọc theo IP và cổng" → ⚠ NSG "nhóm dải IP của dịch vụ Azure" → ⚠ service tag "quyết định gói đi đâu" → ⚠ UDR

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật NSG đang viết theo IP hay theo ASG | | | Máy mới thêm có tự được áp luật không | | | Có tầng nào nhận được lưu lượng từ tầng không liền kề không | |

Và giá trị bền nhất của ASG nằm ở chỗ bảo trì: bộ luật viết bằng tên vai trò vẫn đúng sau khi hạ tầng mở rộng, còn bộ luật viết bằng dải IP thì mỗi lần thêm máy lại phải rà lại từ đầu.

Đáp án

A, B và C — Azure Virtual WAN, Global Virtual Network Peering, và ExpressRoute với Global Reach.

Vì sao đúng

⚠ Ba cách nối hai vùng Azure với nhau qua BACKBONE Microsoft: | Cách | Nội dung | |---|---| | ⚠ Global VNet Peering | ⚠ nối trực tiếp hai VNet khác vùng, độ trễ thấp nhất | | ⚠ Azure Virtual WAN | ⚠ hub ở mỗi vùng, các hub tự nối với nhau qua backbone | | ⚠ ExpressRoute Global Reach | ⚠ nối hai site TẠI CHỖ, cũng qua backbone Microsoft |

⚠ Điểm chung: ⚠ cả ba đều đi qua mạng riêng của Microsoft, không qua Internet công cộng.

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

• D (Site-to-Site VPN) — ⚠ đi qua INTERNET CÔNG CỘNG; ⚠ tuy có mã hoá nhưng độ trễ biến động và không đáp ứng yêu cầu "riêng tư, độ trễ thấp" theo nghĩa của đề.

Ghi nhớ

⚠ So sánh ba cách: | Cách | Nối gì | Độ phức tạp | |---|---|---| | ⚠ Global VNet Peering | ⚠ VNet ↔ VNet | ⚠ đơn giản nhất | | ⚠ Virtual WAN | ⚠ nhiều VNet và nhiều site | ⚠ quản lý tập trung | | ⚠ ExpressRoute Global Reach | ⚠ site tại chỗ ↔ site tại chỗ | ⚠ cần circuit ở mỗi nơi |

Từ khoá nhận diện:

"hai VNet khác vùng" → ⚠ global VNet peering "nhiều site nhiều vùng, quản lý tập trung" → ⚠ Virtual WAN "hai chi nhánh tại chỗ nói chuyện với nhau" → ⚠ ExpressRoute Global Reach "qua Internet, có mã hoá" → ⚠ VPN Site-to-Site

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí truyền dữ liệu liên vùng ước tính bao nhiêu | | | Có thật sự cần đồng bộ nhiều dữ liệu giữa hai vùng không | | | Dải IP hai vùng có chồng lấn không | |

Và khoản chi phí hay bị đánh giá thấp trong kiến trúc đa vùng: tiền truyền dữ liệu giữa các vùng. Hạ tầng thì rõ ràng và dự đoán được, còn lưu lượng đồng bộ dữ liệu thì tăng âm thầm theo quy mô hệ thống.

Đáp án

C — Virtual network flow logs

Vì sao đúng

Flow log ghi lại từng luồng lưu lượng IP đi qua mạng ảo, kèm thông tin quan trọng nhất: địa chỉ nguồn và đích, cổng, giao thức, số byte, và luồng đó được ACCEPT hay bị REJECT.

Đây chính là dữ liệu cần khi phân tích lưu lượng vào ra liên quan tới NSG — nó cho biết luật nào đang chặn cái gì, dựa trên lưu lượng đã thực sự xảy ra.

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

• A. Network Watcher — là bộ công cụ chứa flow log cùng nhiều công cụ khác; câu hỏi hỏi đích danh nguồn dữ liệu, nên trả lời bằng cả bộ công cụ là quá rộng.
• D. Azure Monitor Metrics — lưu chuỗi số theo thời gian như băng thông tổng, không chứa được chi tiết từng luồng.
• B. Nhật ký VPN Gateway — chỉ ghi lưu lượng đi qua cổng VPN, không phải lưu lượng giữa các máy ảo trong VNet.