Ngân hàng đề Microsoft Azure Networking

Câu 91 Chọn nhiều đáp án

You are designing a secure Azure architecture. Which of the following scenarios would benefit from the implementation of Azure Service Endpoints?

A
Restricting access to Azure Storage accounts only from a specific subnet within your VNet.
B
Enabling end-to-end encryption for data in transit to Azure services.
C
Applying custom routing to network traffic destined for Azure services.
D
Implementing a policy that filters outbound traffic from a subnet to an Azure service based on attributes like target service, region, etc.

Xem giải thích

Đáp án

A và D.

A — Giới hạn truy cập tài khoản Azure Storage chỉ từ một subnet cụ thể trong VNet.
D — Áp chính sách lọc lưu lượng ra từ một subnet tới một dịch vụ Azure theo các thuộc tính như dịch vụ đích, vùng...

Vì sao đúng

⚠ Service Endpoint làm hai việc chính: | Việc | Nội dung | |---|---| | ⚠ Mở rộng danh tính của VNet tới dịch vụ PaaS | ⚠ dịch vụ biết lưu lượng đến từ subnet nào | | ⚠ Cho phép dịch vụ PaaS giới hạn truy cập theo subnet | ⚠ firewall của Storage chỉ chấp nhận subnet đã khai | | ⚠ Định tuyến tối ưu qua backbone Microsoft | ⚠ không ra Internet công cộng | | ⚠ Kết hợp service tag trong NSG để lọc chiều ra | ⚠ theo dịch vụ và theo vùng |

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

B (mã hoá đầu cuối cho dữ liệu khi truyền) — ⚠ mã hoá đến từ TLS, không phải service endpoint.
C (áp định tuyến tuỳ chỉnh cho lưu lượng tới dịch vụ Azure) — ⚠ là việc của user-defined route; service endpoint tự thêm tuyến tối ưu chứ không cho bạn tuỳ chỉnh.

Ghi nhớ

⚠ Service Endpoint và Private Endpoint — bảng so sánh cần 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 theo giờ và dữ liệu | | ⚠ Từ mạng tại chỗ | ⚠ KHÔNG dùng được | ⚠ dùng được qua VPN/ExpressRoute | | ⚠ Phạm vi | ⚠ cả dịch vụ | ⚠ một tài nguyên cụ thể | | ⚠ Cần DNS riêng | ⚠ không | ⚠ CÓ, đây là chỗ hay hỏng | | ⚠ Chống rò rỉ dữ liệu | ⚠ kém hơn | ⚠ tốt hơn | | ⚠ Hướng khuyến nghị | ⚠ | ⚠ Private Endpoint |

Từ khoá nhận diện:

"chỉ subnet này truy cập được Storage" → ⚠ service endpoint kèm firewall của Storage "dịch vụ có IP riêng trong VNet" → ⚠ private endpoint "dùng được từ mạng tại chỗ" → ⚠ private endpoint "miễn phí" → ⚠ service endpoint

⚠ Điểm yếu của Service Endpoint	Điểm yếu
⚠ Vẫn dùng IP công cộng của dịch vụ
⚠ Mở cho CẢ dịch vụ, không chỉ một tài khoản	⚠ về lý thuyết vẫn tới được tài khoản Storage của người khác
⚠ Không dùng được từ mạng tại chỗ
⚠ Vì thế	⚠ với dữ liệu nhạy cảm, Private Endpoint an toàn hơn

⚠ Cấu hình đúng cần hai phía	Phía
⚠ Phía VNet	⚠ bật service endpoint cho subnet
⚠ Phía dịch vụ	⚠ cấu hình firewall chỉ cho phép subnet đó
⚠ Thiếu phía thứ hai	⚠ dịch vụ vẫn mở cho mọi nơi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Firewall của dịch vụ đã bật và 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 | ⚠ nếu có thì phải Private Endpoint | | Dữ liệu có nhạy cảm tới mức cần Private Endpoint không | |

Và hiểu nhầm phổ biến nhất về Service Endpoint: tưởng bật nó lên là dịch vụ đã được bảo vệ. Nó chỉ mở đường tối ưu và gắn danh tính subnet — phần chặn thật nằm ở firewall của chính dịch vụ, và đó là bước thứ hai rất hay bị bỏ quên.

Câu 92 Secure network connectivity to Azure resources (15–20%)

Web Application Firewall provides centralized protection for web applications against common vulnerabilities and exploits. What is an optional stage in creating a WAF policy on Azure Front Door using Azure Portal?

A
Create a Web Application Firewall policy.
B
To link the WAF policy with a Front Door profile.
C
Configuring the settings and rules for the WAF policy.
D
None of the above.

Xem giải thích

Đáp án

C — Cấu hình các thiết lập và luật cho chính sách WAF.

Vì sao đúng

⚠ Ba bước, hai bắt buộc một tuỳ chọn: | Bước | Bắt buộc hay tuỳ chọn | |---|---| | ⚠ Tạo chính sách WAF | ⚠ BẮT BUỘC — không có policy thì không có gì | | ⚠ Liên kết policy với Front Door profile | ⚠ BẮT BUỘC — không gắn thì policy vô tác dụng | | ⚠ Cấu hình thiết lập và luật | ⚠ TUỲ CHỌN — policy đã có managed rule set mặc định |

⚠ Vì sao tuỳ chọn: ⚠ khi tạo policy, Azure đã gán sẵn bộ luật do Microsoft quản lý dựa trên OWASP. ⚠ Chính sách hoạt động ngay mà không cần bạn thêm luật nào; ⚠ tuỳ chỉnh chỉ để phù hợp hơn với ứng dụng cụ thể.

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

A (tạo chính sách WAF) và B (liên kết với Front Door profile) — ⚠ đều BẮT BUỘC.
D (không phương án nào) — ⚠ sai vì C là bước tuỳ chọn.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23267 trong lô này liệt kê ba việc cần làm để bảo vệ ứng dụng sau Front Door. ⚠ Câu này hỏi bước nào là TUỲ CHỌN. Hai câu bổ sung nhau — cùng một quy trình, hỏi từ hai phía.

⚠ Có sẵn gì khi vừa tạo policy: | Thành phần | Trạng thái | |---|---| | ⚠ Managed rule set | ⚠ gán sẵn, dựa trên OWASP | | ⚠ Chế độ | ⚠ thường mặc định là Detection | | ⚠ Custom rules | ⚠ TRỐNG — bạn tự thêm nếu cần | | ⚠ Exclusions | ⚠ trống | | ⚠ Vì thế | ⚠ cấu hình thêm là để tinh chỉnh, không phải để hoạt động |

Từ khoá nhận diện:

"tạo policy" → ⚠ bắt buộc "gắn policy vào Front Door" → ⚠ bắt buộc "thêm custom rule, exclusion" → ⚠ tuỳ chọn "chuyển sang Prevention" → ⚠ rất nên làm, nhưng về kỹ thuật là tuỳ chọn

⚠ Nhưng "tuỳ chọn" không có nghĩa là "không nên làm"	Vì sao
⚠ Chế độ mặc định thường là Detection	⚠ không chặn gì cả
⚠ Managed rule set sinh cảnh báo giả với ứng dụng thật	⚠ cần exclusion
⚠ Không có rate limit cho endpoint đăng nhập
⚠ Kết luận	⚠ về mặt bài thi là tuỳ chọn; về mặt vận hành là gần như bắt buộc

⚠ Luật tuỳ chỉnh nên thêm đầu tiên	Luật
⚠ Rate limit cho endpoint đăng nhập	⚠ chống dò mật khẩu
⚠ Chặn theo quốc gia nếu dịch vụ chỉ phục vụ nội địa
⚠ Cho phép dải IP nội bộ đi trước
⚠ Exclusion cho tham số gây cảnh báo giả

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Policy đã gắn vào endpoint chưa | | | Đang ở chế độ Detection hay Prevention | | | Có custom rule nào chưa | |

Và điều khiến câu trả lời "tuỳ chọn" dễ gây hiểu nhầm trong thực tế: một WAF chỉ có luật mặc định và ở chế độ Detection là một WAF chưa bảo vệ gì. Nó hợp lệ về mặt cấu hình, nhưng chưa làm được việc gì.

Câu 93 Secure network connectivity to Azure resources (15–20%)

A network security group (NSG) can filter traffic from a Vnet subnet inbound and outbound. Filtering the network traffic with an NSG through the Azure portal involves many vital stages. Which of the following is not such a critical stage?

A
Creating a Resource Group
B
Creating a virtual network
C
Creating a network security group
D
Creating an Application Gateway

Xem giải thích

Đáp án

D — Tạo một Application Gateway.

Vì sao đúng

⚠ Quy trình lọc lưu lượng bằng NSG qua Portal gồm các bước: | Bước | Bắt buộc | |---|---| | ⚠ Tạo resource group | ⚠ vật chứa cho mọi tài nguyên | | ⚠ Tạo virtual network và subnet | ⚠ nơi có lưu lượng để lọc | | ⚠ Tạo network security group | ⚠ chính công cụ lọc | | ⚠ Gắn NSG vào subnet hoặc card mạng | | | ⚠ Tạo luật vào và ra | |

⚠ Application Gateway là bộ cân bằng tải tầng 7 — ⚠ hoàn toàn không liên quan tới việc lọc lưu lượng bằng NSG.

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

A (tạo resource group), B (tạo virtual network), C (tạo network security group) — ⚠ đều là bước thiết yếu.

Ghi nhớ

⚠ NSG và Application Gateway — hai tầng, hai việc: | Công cụ | Tầng | Việc | |---|---|---| | ⚠ NSG | ⚠ 3–4 | ⚠ cho phép hoặc chặn theo IP, cổng, giao thức | | ⚠ Application Gateway | ⚠ 7 | ⚠ phân phối tải, định tuyến theo URL, WAF | | ⚠ Có thể dùng cùng nhau | ⚠ nhưng không thay thế nhau |

Từ khoá nhận diện:

"lọc lưu lượng theo IP và cổng" → ⚠ NSG "phân phối tải, định tuyến theo URL" → ⚠ Application Gateway "lọc theo tên miền" → ⚠ Azure Firewall "chống SQL injection" → ⚠ WAF

⚠ Trình tự dựng một môi trường mạng cơ bản	Bước
⚠ 1. Resource group
⚠ 2. Virtual network và subnet
⚠ 3. Network security group
⚠ 4. Gắn NSG vào subnet	⚠ bước hay bị quên nhất
⚠ 5. Viết luật
⚠ 6. Triển khai máy ảo
⚠ 7. Kiểm chứng bằng IP flow verify

⚠ Bước dễ bị bỏ sót nhất	Bước
⚠ Tạo NSG xong nhưng KHÔNG GẮN vào đâu	⚠ nó không lọc gì cả
⚠ Trên Portal, tài nguyên vẫn hiện ra bình thường
⚠ Không có cảnh báo nào
⚠ Kiểm tra bằng	⚠ tab "Subnets" và "Network interfaces" của NSG

⚠ Khi nào subnet đặc biệt KHÔNG gắn NSG được hoặc không nên	Trường hợp
⚠ GatewaySubnet	⚠ không khuyến nghị gắn NSG
⚠ AzureFirewallSubnet	⚠ NSG không có tác dụng ở đây
⚠ AzureBastionSubnet	⚠ gắn được nhưng phải mở đúng bộ cổng bắt buộc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | NSG đã được gắn vào subnet hoặc NIC chưa | ⚠ tạo mà không gắn là vô ích | | Luật có đúng chiều không | | | Đã kiểm chứng bằng IP flow verify chưa | |

Và bước dễ quên nhất trong toàn bộ quy trình: gắn NSG vào subnet. Tạo xong thì nó nằm đó, hiển thị đầy đủ trong Portal, có luật đàng hoàng — nhưng không một gói tin nào đi qua nó.

Câu 94 Secure network connectivity to Azure resources (15–20%)

Application rules do not apply to inbound connections. Therefore, if you need to filter HTTP(s) traffic, you should implement a Web Application Firewall. Is this correct?

A
Yes
B
No

Xem giải thích

Đáp án

A — Đúng.

Vì sao đúng

⚠ Application rules của Azure Firewall chỉ áp cho lưu lượng ĐI RA: | Chiều | Loại luật xử lý | |---|---| | ⚠ Ra (outbound) | ⚠ network rules và application rules | | ⚠ Vào (inbound) | ⚠ DNAT rules — chuyển hướng, rồi network rules | | ⚠ Application rules cho chiều vào | ⚠ KHÔNG áp dụng |

⚠ Hệ quả: ⚠ muốn kiểm tra nội dung của lưu lượng HTTP/HTTPS đi vào ứng dụng web, ⚠ phải dùng WAF trên Application Gateway hoặc Front Door.

⚠ Lưu lượng RA   →  ⚠ Azure Firewall application rules lọc theo FQDN
⚠ Lưu lượng VÀO  →  ⚠ WAF kiểm tra nội dung HTTP

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

B (Không) — ⚠ SAI; đây là ranh giới năng lực có thật của Azure Firewall.

Ghi nhớ

⚠ Phân vai rõ ràng giữa các công cụ: | Công cụ | Chiều | Việc | |---|---|---| | ⚠ Azure Firewall — network rules | ⚠ cả hai | ⚠ IP, cổng, giao thức | | ⚠ Azure Firewall — application rules | ⚠ CHỈ RA | ⚠ lọc theo FQDN | | ⚠ Azure Firewall — DNAT rules | ⚠ VÀO | ⚠ chuyển hướng vào tài nguyên nội bộ | | ⚠ WAF | ⚠ VÀO | ⚠ kiểm tra nội dung HTTP, chống OWASP Top 10 |

Từ khoá nhận diện:

"lọc HTTP đi vào theo nội dung" → ⚠ WAF "lọc HTTP đi ra theo tên miền" → ⚠ Azure Firewall application rules "chuyển lưu lượng từ ngoài vào máy nội bộ" → ⚠ DNAT rules "chống SQL injection, XSS" → ⚠ WAF, không phải Azure Firewall

⚠ Kiến trúc kết hợp thường gặp	Kiến trúc
⚠ Front Door hoặc Application Gateway kèm WAF ở ĐẦU VÀO
⚠ Azure Firewall ở hub kiểm soát ĐẦU RA
⚠ NSG phân đoạn bên trong
⚠ Ba lớp	⚠ mỗi lớp một chiều, một tầng, không chồng chéo

⚠ Vì sao Azure Firewall không làm được WAF	Lý do
⚠ Application rules chỉ khớp theo FQDN đích	⚠ không phân tích thân yêu cầu
⚠ Không hiểu tham số, header, body của HTTP
⚠ Với HTTPS, mặc định không giải mã	⚠ Premium mới có TLS inspection
⚠ WAF thì	⚠ sinh ra để đọc và đánh giá từng yêu cầu HTTP

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng web công khai có WAF trước mặt chưa | | | Azure Firewall có đang được kỳ vọng làm việc của WAF không | | | Lưu lượng ra có được kiểm soát theo FQDN không | |

Và cách phân vai gọn nhất giữa hai công cụ: Azure Firewall canh cửa RA, WAF canh cửa VÀO. Kỳ vọng một cái làm việc của cái kia là lỗ hổng phổ biến trong các kiến trúc trông có vẻ đầy đủ.

Câu 95 Secure network connectivity to Azure resources (15–20%)

Firewall rules are processed based on Collection Group and Collection priority. What priority level specifies the highest priority for a security rule?

A
0
B
1
C
100
D
10000
E
65000

Xem giải thích

Đáp án

C — 100.

Vì sao đúng

⚠ Ưu tiên của Azure Firewall rule collection: | Thuộc tính | Giá trị | |---|---| | ⚠ Khoảng hợp lệ | ⚠ 100 đến 65.000 | | ⚠ Số NHỎ = ưu tiên CAO | | | ⚠ Ưu tiên cao nhất | ⚠ 100 | | ⚠ Ưu tiên thấp nhất | ⚠ 65.000 |

⚠ Áp cho cả rule collection group và rule collection — cùng khoảng giá trị.

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

A (0) và B (1) — ⚠ dưới khoảng hợp lệ, Azure từ chối.
D (10000) — ⚠ hợp lệ nhưng ưu tiên THẤP hơn 100.
E (65000) — ⚠ là ưu tiên THẤP NHẤT.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23221 ở lô trước nói thứ tự BA LOẠI luật (DNAT → Network → Application) là cố định, không đổi được bằng ưu tiên. ⚠ Câu này nói về ưu tiên TRONG cùng một loại. Hai câu bổ sung nhau.

⚠ Thứ tự xét luật đầy đủ của Azure Firewall:

⚠ 1. Loại luật     →  ⚠ DNAT > Network > Application (CỐ ĐỊNH)
⚠ 2. Rule collection group theo ưu tiên (100 → 65000)
⚠ 3. Rule collection theo ưu tiên
⚠ 4. Trong một collection: theo thứ tự khai

⚠ Đừng lẫn với khoảng ưu tiên của NSG: | Dịch vụ | Khoảng ưu tiên | |---|---| | ⚠ Azure Firewall | ⚠ 100 – 65.000 | | ⚠ Network Security Group | ⚠ 100 – 4.096 cho luật tự tạo | | ⚠ NSG luật mặc định | ⚠ 65.000 – 65.500 | | ⚠ Điểm chung | ⚠ số NHỎ xét TRƯỚC ở cả hai |

Từ khoá nhận diện:

"ưu tiên cao nhất của firewall" → ⚠ 100 "ưu tiên thấp nhất của firewall" → ⚠ 65.000 "ưu tiên tự tạo của NSG" → ⚠ 100 – 4.096 "thứ tự ba loại luật" → ⚠ cố định, ưu tiên không đổi được

⚠ Cách đặt ưu tiên cho dễ bảo trì	Cách
⚠ Chừa khoảng trống lớn	⚠ 100, 200, 300 thay vì 100, 101, 102
⚠ Nhóm theo mục đích	⚠ 100–999 luật chặn khẩn cấp, 1000–4999 luật nghiệp vụ
⚠ Luật bao quát để ưu tiên lớn nhất
⚠ Đặt sát nhau	⚠ hết chỗ chèn, phải đánh số lại toàn bộ

⚠ Kế thừa policy ảnh hưởng thế nào	Ảnh hưởng
⚠ Rule collection group của policy CHA xét TRƯỚC policy con
⚠ Dù ưu tiên của con có nhỏ hơn
⚠ Vì thế	⚠ đội bảo mật đặt luật bắt buộc ở policy gốc là hiệu quả

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Các ưu tiên có chừa khoảng trống không | | | Có luật nào bị luật ưu tiên cao hơn che khuất không | | | Policy cha có luật nào đang ghi đè policy con không | |

Và điều dễ gây nhầm nhất giữa Azure Firewall và NSG: hai dịch vụ dùng hai khoảng ưu tiên khác nhau. Cả hai đều "số nhỏ xét trước", nhưng trần của NSG là 4.096 còn của Firewall là 65.000.

Câu 96 Design, implement, and manage connectivity services (20-25%)

You work as a network engineer and need to configure communication between the company's Amsterdam and California offices. Which of the following configurations would you use?

A
Connect GlobalReach to local service providers in Amsterdam and California.
B
Connect each location to a private VPN with GlobalReach and use local service providers for P2S access.
C
Connect the Amsterdam and California branches using Global Reach’s ExpressRoute and MS global network with local service providers in each location.
D
None of these

Xem giải thích

Đáp án

C — Nối chi nhánh Amsterdam và California bằng ExpressRoute Global Reach cùng mạng toàn cầu của Microsoft, với nhà cung cấp dịch vụ tại mỗi địa phương.

Vì sao đúng

⚠ ExpressRoute Global Reach nối hai SITE TẠI CHỖ với nhau qua backbone Microsoft: | Đặc điểm | Nội dung | |---|---| | ⚠ Mỗi site có một ExpressRoute circuit riêng | ⚠ qua nhà cung cấp địa phương | | ⚠ Global Reach nối hai circuit đó lại | | | ⚠ Lưu lượng đi qua mạng toàn cầu của Microsoft | ⚠ KHÔNG qua Internet công cộng | | ⚠ Thay thế đường WAN riêng đắt tiền | |

⚠ Amsterdam  →  ⚠ ExpressRoute circuit
                        ↓ ⚠ Global Reach qua backbone Microsoft
⚠ California →  ⚠ ExpressRoute circuit

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

A (nối GlobalReach với nhà cung cấp địa phương) — ⚠ mô tả thiếu; Global Reach nối hai circuit đã có, không phải nối thẳng với nhà cung cấp.
B (VPN riêng kèm GlobalReach và P2S) — ⚠ trộn lẫn các khái niệm; P2S dành cho máy tính cá nhân, không nối hai chi nhánh.
D (không phương án nào) — ⚠ sai vì C đúng.

Ghi nhớ

⚠ Ba cách nối hai chi nhánh ở hai châu lục: | Cách | Đặc điểm | |---|---| | ⚠ ExpressRoute Global Reach | ⚠ backbone Microsoft, độ trễ ổn định, đắt | | ⚠ VPN site-to-site qua Azure | ⚠ rẻ hơn, qua Internet, độ trễ biến động | | ⚠ Azure Virtual WAN | ⚠ quản lý tập trung, nhiều site, hub-to-hub tự nối |

Từ khoá nhận diện:

"nối hai site tại chỗ qua backbone Microsoft" → ⚠ Global Reach "nối site tại chỗ vào Azure" → ⚠ ExpressRoute hoặc VPN S2S "nhiều site, nhiều vùng, quản lý tập trung" → ⚠ Virtual WAN "một máy tính từ xa" → ⚠ Point-to-Site

⚠ Vì sao Global Reach hấp dẫn	Lý do
⚠ Tận dụng backbone toàn cầu của Microsoft	⚠ thay vì thuê đường WAN riêng
⚠ Độ trễ ổn định và dự đoán được
⚠ Không qua Internet công cộng
⚠ Đã có ExpressRoute rồi thì thêm Global Reach khá đơn giản

⚠ Điều kiện và lưu ý	Điều
⚠ Mỗi site phải có circuit ExpressRoute riêng
⚠ Không phải mọi peering location đều hỗ trợ	⚠ kiểm tra trước
⚠ Tính phí riêng cho Global Reach	⚠ theo dữ liệu vào và ra
⚠ KHÔNG tự mã hoá	⚠ như mọi kết nối ExpressRoute

⚠ Ba dịch vụ ExpressRoute hay bị lẫn	Dịch vụ
⚠ Global Reach	⚠ nối hai site TẠI CHỖ với nhau
⚠ ExpressRoute Direct	⚠ đấu thẳng vào backbone, 10 hoặc 100 Gbps
⚠ FastPath	⚠ bỏ qua gateway để giảm độ trễ vào VNet

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hai peering location có hỗ trợ Global Reach không | | | Dữ liệu đi giữa hai site có cần mã hoá không | ⚠ Global Reach không tự mã hoá | | Chi phí có rẻ hơn đường WAN hiện tại không | |

Và cách hiểu Global Reach cho gọn: nó biến mạng toàn cầu của Microsoft thành đường WAN riêng của bạn. Hai chi nhánh nói chuyện với nhau qua hạ tầng mà Microsoft đã dựng sẵn, thay vì thuê một đường truyền xuyên đại dương.

Câu 97 Design and implement core networking infrastructure (20-25%)

A subnet can be associated with zero or more route tables. Which PowerShell cmdlet associates a route table with a subnet?

A
Set-AzRouteTable
B
Set-AzVirtualNetworkSubnetConfig
C
New-AzRouteConfig
D
Get-AzRouteConfig
E
Set-AzRouteConfig

Xem giải thích

Đáp án

B — Set-AzVirtualNetworkSubnetConfig.

Vì sao đúng

⚠ Việc gắn route table là một thay đổi trên SUBNET, không phải trên route table: | Cmdlet | Việc | |---|---| | ⚠ New-AzRouteConfig | ⚠ tạo một TUYẾN | | ⚠ New-AzRouteTable | ⚠ tạo BẢNG định tuyến | | ⚠ Set-AzVirtualNetworkSubnetConfig | ⚠ GẮN bảng vào subnet | | ⚠ Set-AzVirtualNetwork | ⚠ lưu thay đổi xuống Azure |

⚠ $vnet = Get-AzVirtualNetwork -Name "VNet1" -ResourceGroupName "RG"
⚠ Set-AzVirtualNetworkSubnetConfig -VirtualNetwork $vnet `
       -Name "Subnet1" -AddressPrefix "10.0.1.0/24" -RouteTable $rt
⚠ Set-AzVirtualNetwork -VirtualNetwork $vnet    # ⚠ BẮT BUỘC để lưu

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

A (Set-AzRouteTable) — ⚠ lưu thay đổi vào chính route table, không gắn nó vào subnet.
C (New-AzRouteConfig) — ⚠ tạo một tuyến.
D (Get-AzRouteConfig) — ⚠ đọc một tuyến.
E (Set-AzRouteConfig) — ⚠ sửa một tuyến trong bảng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23227 ở lô trước hỏi cmdlet tạo một TUYẾN mới (New-AzRouteConfig). ⚠ Câu này hỏi cmdlet GẮN bảng vào subnet. Hai câu là hai bước khác nhau của cùng một quy trình.

⚠ Quy trình đầy đủ để định tuyến qua một thiết bị ảo: | Bước | Cmdlet | |---|---| | ⚠ 1. Tạo tuyến | ⚠ New-AzRouteConfig | | ⚠ 2. Tạo bảng chứa tuyến | ⚠ New-AzRouteTable | | ⚠ 3. Gắn bảng vào subnet | ⚠ Set-AzVirtualNetworkSubnetConfig | | ⚠ 4. LƯU thay đổi | ⚠ Set-AzVirtualNetwork | | ⚠ 5. Bật IP forwarding trên NVA | ⚠ nếu next hop là thiết bị ảo |

⚠ Bước 4 là chỗ hay quên nhất — trong Azure PowerShell, nhiều thao tác trên VNet chỉ sửa đối tượng trong bộ nhớ; phải gọi Set-AzVirtualNetwork mới thực sự áp lên Azure.

Từ khoá nhận diện:

"gắn bảng vào subnet" → ⚠ Set-AzVirtualNetworkSubnetConfig "tạo một tuyến" → ⚠ New-AzRouteConfig "lưu thay đổi VNet" → ⚠ Set-AzVirtualNetwork "cùng việc bằng CLI" → ⚠ az network vnet subnet update --route-table

⚠ Một subnet gắn được bao nhiêu route table	Số
⚠ Tối đa MỘT	⚠ không phải nhiều
⚠ Một route table gắn được cho NHIỀU subnet
⚠ Đề nói "zero or more"	⚠ ý là có thể không có bảng nào, hoặc có một

⚠ Sau khi gắn cần kiểm tra gì	Kiểm tra
⚠ Effective routes của card mạng	⚠ Network Watcher cho xem trực tiếp
⚠ IP forwarding trên NVA đã bật chưa
⚠ NSG có chặn lưu lượng qua NVA không

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã gọi Set-AzVirtualNetwork để lưu chưa | ⚠ quên là thay đổi biến mất | | Effective routes có phản ánh tuyến mới không | | | NVA đã bật IP forwarding chưa | |

Và cái bẫy đặc trưng của Azure PowerShell khi làm việc với mạng: sửa xong mà không lưu. Lệnh chạy không báo lỗi, đối tượng trong bộ nhớ đã đúng, nhưng Azure thì chưa biết gì — cho tới khi bạn gọi Set-AzVirtualNetwork.

Câu 98 Design and implement core networking infrastructure (20-25%)

Is it possible to automatically create DNS records for all VMS deployed in a VNet while linking a private DNS Zone and a virtual network?

A
Yes
B
No

Xem giải thích

Đáp án

A — Có.

Vì sao đúng

⚠ Khi liên kết một Private DNS zone với VNet, có tuỳ chọn "Enable auto registration": | Bật auto-registration | Nội dung | |---|---| | ⚠ Máy ảo mới tạo | ⚠ tự có bản ghi A trong zone | | ⚠ Máy ảo bị xoá | ⚠ bản ghi tự bị gỡ | | ⚠ IP đổi | ⚠ bản ghi tự cập nhật | | ⚠ Không phải quản lý bản ghi bằng tay | |

⚠ Private DNS zone "noibo.contoso.com"
        ↓ ⚠ virtual network link, bật auto-registration
⚠ VNet1
   ├── ⚠ vm-web01  →  ⚠ tự có vm-web01.noibo.contoso.com
   └── ⚠ vm-db01   →  ⚠ tự có vm-db01.noibo.contoso.com

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

B (Không) — ⚠ SAI; đây là tính năng có sẵn và rất tiện.

Ghi nhớ

⚠ Giới hạn quan trọng của auto-registration: | Giới hạn | Nội dung | |---|---| | ⚠ Một VNet chỉ bật auto-registration cho MỘT zone | ⚠ liên kết thêm zone khác thì phải để tắt | | ⚠ Chỉ đăng ký MÁY ẢO | ⚠ không đăng ký private endpoint hay tài nguyên PaaS | | ⚠ Chỉ dùng card mạng CHÍNH của máy | | | ⚠ Bản ghi tạo trong zone, không phải trong VNet | |

Từ khoá nhận diện:

"tự tạo bản ghi DNS cho máy ảo" → ⚠ auto-registration trên virtual network link "phân giải tên riêng trong VNet" → ⚠ Private DNS zone "tên cho private endpoint" → ⚠ zone privatelink.*, KHÔNG auto-register "phân giải hai chiều với tại chỗ" → ⚠ DNS Private Resolver

⚠ Vì sao chỉ một zone được auto-register	Lý do
⚠ Một máy chỉ có MỘT tên miền chính
⚠ Nếu nhiều zone cùng đăng ký thì trùng lặp và mâu thuẫn
⚠ Thực tế	⚠ *một zone cho tên máy, các zone `privatelink.` để tắt auto-register**

⚠ Private DNS zone dùng cho hai việc	Việc
⚠ Đặt tên cho máy ảo nội bộ	⚠ bật auto-registration
⚠ Phân giải tên cho Private Endpoint	⚠ zone `privatelink.blob.core.windows.net`, bản ghi tạo theo endpoint
⚠ Hai mục đích khác nhau	⚠ dùng hai zone khác nhau

⚠ Điều cần lưu ý khi vận hành	Điều
⚠ Zone liên kết với NHIỀU VNet được	⚠ các VNet đó phân giải chéo được tên của nhau
⚠ Nhưng chỉ MỘT VNet auto-register vào một zone
⚠ Đây là cách giải bài toán peering không phân giải tên chéo

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Zone đã liên kết với đúng các VNet chưa | | | Auto-registration bật ở VNet nào | | | Có zone privatelink.* nào bật nhầm auto-register không | |

Và cách Private DNS zone giải quyết một hạn chế lớn của peering: DNS mặc định của Azure không phân giải tên chéo giữa các VNet đã peering. Liên kết cùng một Private DNS zone với cả hai VNet là cách gọn nhất để lấp khoảng trống đó.

Câu 99 Design and implement core networking infrastructure (20-25%)

One of your friends is having trouble connecting to a specific virtual machine in their Azure virtual network. They have approached you for help, and you want to diagnose the issue. What would be your initial step to start the diagnosis?

A
For each resource, set up a static IP address.
B
Configure each resource to have a dynamic IP address.
C
To control the traffic flow, you can use forced tunneling.
D
To see the active network interface card routes, you can view the effective routes for each NIC.

Xem giải thích

Đáp án

D — Xem effective routes của từng card mạng để thấy các tuyến đang có hiệu lực.

Vì sao đúng

⚠ Effective routes cho biết gói tin THỰC SỰ sẽ đi đâu: | Nguồn tuyến được tổng hợp | Nội dung | |---|---| | ⚠ Tuyến hệ thống mặc định | | | ⚠ User-defined route | | | ⚠ Tuyến học được qua BGP | ⚠ từ VPN hoặc ExpressRoute | | ⚠ Tuyến từ VNet peering | |

⚠ Đây là bước chẩn đoán hợp lý đầu tiên vì nó trả lời câu hỏi gốc: ⚠ gói tin có biết đường tới đích không.

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

A (đặt IP tĩnh cho mọi tài nguyên) và B (đặt IP động cho mọi tài nguyên) — ⚠ là THAY ĐỔI cấu hình, không phải chẩn đoán; và đổi IP có thể làm hỏng thêm.
C (dùng forced tunneling để kiểm soát luồng) — ⚠ là một thay đổi kiến trúc lớn, hoàn toàn không phù hợp làm bước chẩn đoán đầu tiên.

Ghi nhớ

⚠ Nguyên tắc chẩn đoán: QUAN SÁT trước, THAY ĐỔI sau. | Bước | Việc | |---|---| | ⚠ 1. Service Health | ⚠ có phải lỗi nền tảng không | | ⚠ 2. Resource Health của máy | ⚠ máy có khoẻ không | | ⚠ 3. Effective routes | ⚠ gói có biết đường đi không | | ⚠ 4. Effective security rules | ⚠ luật nào đang áp | | ⚠ 5. IP flow verify | ⚠ luật nào chặn cụ thể | | ⚠ 6. Packet capture | ⚠ bước cuối, tốn công nhất |

Từ khoá nhận diện:

"gói tin đi đường nào" → ⚠ effective routes, hoặc Next hop "luật nào chặn" → ⚠ IP flow verify "tổng hợp luật trên NIC" → ⚠ effective security rules "giám sát liên tục" → ⚠ Connection Monitor

⚠ Hai nguyên nhân lớn nhất khiến không kết nối được	Nguyên nhân
⚠ Định tuyến sai	⚠ gói không biết đường, hoặc đi nhầm chỗ
⚠ Luật chặn	⚠ NSG hoặc firewall
⚠ Effective routes và effective rules	⚠ giải quyết đúng hai nguyên nhân đó

⚠ Thứ tự ưu tiên tuyến trên Azure	Thứ tự
⚠ 1. User-defined route
⚠ 2. Tuyến BGP
⚠ 3. Tuyến hệ thống
⚠ Trong cùng nhóm	⚠ tiền tố CỤ THỂ hơn thắng — longest prefix match

⚠ Tuyến "next hop = None" nghĩa là gì	Nghĩa
⚠ Gói tin bị BỎ
⚠ Thường do UDR cố ý chặn
⚠ Hoặc do tuyến hệ thống cho dải không định tuyến được
⚠ Thấy nó trong effective routes	⚠ là đã tìm ra nguyên nhân

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Effective routes có tuyến tới đích không | | | Next hop của tuyến đó là gì | ⚠ None nghĩa là bị bỏ | | Nếu định tuyến đúng thì kiểm tra tiếp NSG | |

Và nguyên tắc chẩn đoán nên áp cho mọi sự cố mạng: đừng đổi gì trước khi hiểu chuyện gì đang xảy ra. Đổi IP, bật forced tunneling, gỡ NSG — mỗi thay đổi mù quáng đều tạo thêm một biến số và làm bài toán khó hơn.

Ngân hàng đề — Microsoft Azure Networking

Đá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ớ