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

Đáp án

D — Azure DNS

Vì sao đúng

Mọi mạng ảo trong Azure mặc định đã có sẵn dịch vụ phân giải tên do Azure cung cấp, truy cập qua địa chỉ nội bộ 168.63.129.16. Nhờ vậy máy ảo trong cùng VNet gọi nhau bằng tên máy mà không cần cấu hình gì và không cần dựng máy chủ DNS nào — đúng yêu cầu của đề.

Nó cũng phân giải luôn các tên miền công cộng, nên máy ảo truy cập Internet bình thường.

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

• A. Azure Private DNS — dùng khi bạn cần vùng tên miền riêng của mình (ví dụ noibo.congty.com) phân giải trong VNet, hoặc cần phân giải giữa nhiều VNet. Đây là phương án nhiễu gần nhất, nhưng nó đòi bạn tạo và liên kết vùng DNS, tức là có cấu hình — trong khi đề nói "không cần cấu hình thêm".
• B. Azure Public DNS — quản lý vùng tên miền công cộng của bạn, phục vụ người dùng Internet.
• C. "Azure DNS Private Link Service" — không phải tên dịch vụ có thật.

Đáp án

C — Dependency view (khung nhìn phụ thuộc).

Vì sao đúng

⚠ Azure Monitor Network Insights có nhiều khung nhìn, mỗi cái trả lời một câu hỏi: | Khung nhìn | Cho biết | |---|---| | ⚠ Network health and metrics | ⚠ tổng quan sức khoẻ, không cần cấu hình gì | | ⚠ Dependency view | ⚠ CẤU HÌNH và quan hệ phụ thuộc của tài nguyên | | ⚠ Connectivity | ⚠ trạng thái các phép kiểm tra kết nối | | ⚠ Traffic | ⚠ nhật ký luồng NSG và traffic analytics | | ⚠ Diagnostic Toolkit | ⚠ lối tắt tới các công cụ của Network Watcher |

⚠ Dependency view vẽ sơ đồ: ⚠ tài nguyên nối với cái gì, cấu hình ra sao, và chỉ số sức khoẻ của từng thành phần trong chuỗi đó.

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

• B (Connectivity tab) — ⚠ cho biết kết nối có thông hay không, không hiện cấu hình.

• D (Traffic tab) — ⚠ về luồng lưu lượng và nhật ký NSG.

• E (Diagnostic Toolkit) — ⚠ tập hợp công cụ chẩn đoán, không phải khung nhìn cấu hình.

• A (Alerts) — ⚠ danh sách cảnh báo.

Ghi nhớ

⚠ Bộ công cụ chẩn đoán mạng của Azure — nhớ theo việc: | Công cụ | Việc | |---|---| | ⚠ Network Insights | ⚠ tổng quan sức khoẻ và cấu hình, không cần cài gì | | ⚠ Connection Monitor | ⚠ theo dõi kết nối liên tục giữa hai điểm | | ⚠ IP flow verify | ⚠ luật NSG nào đang chặn gói này | | ⚠ Next hop | ⚠ gói tin sẽ đi đâu tiếp theo | | ⚠ Effective security rules | ⚠ tổng hợp mọi luật NSG áp lên một card mạng | | ⚠ Packet capture | ⚠ bắt gói để phân tích sâu | | ⚠ NSG flow logs | ⚠ nhật ký luồng, đầu vào cho Traffic Analytics |

Từ khoá nhận diện:

"xem cấu hình và quan hệ phụ thuộc" → ⚠ Dependency view "luật nào đang chặn" → ⚠ IP flow verify "gói đi đường nào" → ⚠ Next hop "theo dõi kết nối theo thời gian" → ⚠ Connection Monitor "bắt gói tin" → ⚠ Packet capture

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhật ký luồng NSG đã bật chưa | ⚠ không bật thì không có dữ liệu để điều tra sau này | | Có Connection Monitor cho đường kết nối quan trọng không | | | Ai trong đội biết dùng Network Watcher | |

Và lý do nên bật nhật ký luồng NSG ngay từ hôm nay: dữ liệu chỉ có từ lúc bật trở đi. Khi sự cố đã xảy ra rồi mới đi bật thì bạn đã mất đúng khoảng thời gian mình cần nhìn lại.

Đáp án

A — Có, VNet peering đáp ứng đủ mọi yêu cầu.

Vì sao đúng

⚠ Đối chiếu từng yêu cầu với khả năng của peering: | Yêu cầu | Peering đáp ứng | |---|---| | ⚠ Truyền dữ liệu giữa các tenant, subscription, vùng, mô hình triển khai | ⚠ ĐƯỢC — peering hỗ trợ cả bốn | | ⚠ Tài nguyên ở VNet này giao tiếp với VNet kia | ⚠ ĐƯỢC — đó là mục đích chính | | ⚠ Không gián đoạn tài nguyên | ⚠ ĐƯỢC — tạo peering không làm dừng gì | | ⚠ Kết nối độ trễ thấp, băng thông cao | ⚠ ĐƯỢC — đi qua backbone của Microsoft |

⚠ VNet A  ←  ⚠ backbone Microsoft  →  ⚠ VNet B
   ⚠ KHÔNG qua Internet công cộng
   ⚠ KHÔNG cần gateway
   ⚠ KHÔNG cần thiết bị trung gian

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

• B (Không) — ⚠ peering đáp ứng được toàn bộ danh sách này.

Ghi nhớ

⚠ Peering làm được nhiều hơn người ta thường nghĩ: | Vượt qua ranh giới nào | Được không | |---|---| | ⚠ Khác subscription | ⚠ ĐƯỢC | | ⚠ Khác tenant Entra ID | ⚠ ĐƯỢC | | ⚠ Khác vùng | ⚠ ĐƯỢC — global VNet peering | | ⚠ Khác mô hình triển khai | ⚠ ĐƯỢC — Resource Manager và Classic |

⚠ Nhưng peering vẫn có giới hạn cứng: | Giới hạn | Nội dung | |---|---| | ⚠ Dải IP KHÔNG được chồng lấn | ⚠ điều kiện tiên quyết | | ⚠ KHÔNG bắc cầu | ⚠ A–B và B–C không cho A nói với C | | ⚠ Phải thiết lập ở CẢ HAI phía | | | ⚠ Global peering không hỗ trợ Basic SKU | ⚠ xem #23179 cùng lô | | ⚠ Tính phí dữ liệu vào và ra | |

Từ khoá nhận diện:

"nối hai VNet, độ trễ thấp, không gateway" → ⚠ VNet peering "nối mạng tại chỗ vào Azure" → ⚠ VPN Gateway hoặc ExpressRoute "nhiều VNet, nhiều site, quản lý tập trung" → ⚠ Azure Virtual WAN "spoke này nói chuyện với spoke kia" → ⚠ cần định tuyến qua hub, peering không bắc cầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Peering đã Connected ở CẢ hai phía chưa | ⚠ một phía là trạng thái Initiated | | Có cần lưu lượng đi xuyên qua hub không | ⚠ thì phải bật allow forwarded traffic và có UDR | | Chi phí truyền dữ liệu giữa các vùng là bao nhiêu | ⚠ global peering tính phí cao hơn |

Và điều khiến peering trở thành lựa chọn mặc định để nối VNet: không cần gateway, không thêm chặng, không dừng dịch vụ. Bật lên là hai mạng nói chuyện được với nhau qua chính backbone của Microsoft.

Đáp án

A — Nó cho phép định tuyến lưu lượng tới các đích đã khai trong bảng định tuyến.

Vì sao đúng

⚠ Trong Virtual WAN, mỗi connection gắn với một route table để quyết định đi đâu: | Khái niệm | Vai trò | |---|---| | ⚠ Connection | ⚠ kết nối từ VNet, site VPN, hoặc ExpressRoute vào hub | | ⚠ Association | ⚠ connection này DÙNG bảng định tuyến nào để biết đi đâu | | ⚠ Propagation | ⚠ tuyến của connection này được GHI vào bảng nào |

⚠ Association  →  ⚠ "tôi tra đường ở bảng nào"
⚠ Propagation  →  ⚠ "ai học được đường tới tôi"

⚠ Nhờ tách hai khái niệm này, bạn kiểm soát được chính xác ai nói chuyện được với ai — ví dụ cho spoke nói với hub nhưng không cho spoke nói với nhau.

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

• B (tự động lan truyền tuyến từ bảng này sang bảng kia) — ⚠ mô tả PROPAGATION, một khái niệm khác; association không tự lan truyền gì.

• C (xác thực người dùng) — ⚠ bảng định tuyến không làm xác thực.

• D (mã hoá lưu lượng) — ⚠ mã hoá là việc của IPsec hoặc TLS, không phải định tuyến.

Ghi nhớ

⚠ Azure Virtual WAN — mô hình mạng tập trung: | Thành phần | Vai trò | |---|---| | ⚠ Virtual WAN | ⚠ vật chứa toàn cầu cho các hub | | ⚠ Hub | ⚠ một điểm tập trung trong một vùng, Microsoft quản lý | | ⚠ Connection | ⚠ VNet, site VPN, P2S, ExpressRoute nối vào hub | | ⚠ Route table | ⚠ quyết định lưu lượng đi đâu | | ⚠ Hub-to-hub | ⚠ các hub tự nối với nhau qua backbone |

Từ khoá nhận diện:

"connection tra đường ở bảng nào" → ⚠ association "tuyến được ghi vào bảng nào" → ⚠ propagation "cách ly spoke với nhau" → ⚠ dùng route table riêng, không propagate chéo "tự dựng hub bằng peering và UDR" → ⚠ hub-and-spoke thủ công, khác Virtual WAN

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Spoke nào đang thấy được spoke nào | ⚠ xem bảng association và propagation | | Lưu lượng ra Internet có đi qua firewall ở hub không | | | Có tuyến nào chồng lấn gây định tuyến bất ngờ không | |

Và điều dễ gây nhầm nhất khi mới làm việc với Virtual WAN: association và propagation là hai chiều khác nhau của cùng một bảng. Một cái nói "tôi tra đường ở đâu", cái kia nói "ai biết đường tới tôi" — lẫn hai cái là kết nối chạy không như mong đợi mà không rõ vì sao.

Đáp án

A và C — Customer resource group và Managed resource group.

Vì sao đúng

⚠ Khi tạo một NVA trong hub Virtual WAN, Azure dựng HAI resource group: | Resource group | Ai quản lý | Chứa gì | |---|---|---| | ⚠ Customer resource group | ⚠ BẠN | ⚠ tài nguyên NVA mà bạn nhìn thấy và cấu hình | | ⚠ Managed resource group | ⚠ NHÀ CUNG CẤP NVA và Azure | ⚠ thành phần hạ tầng bên dưới, KHÔNG nên đụng vào |

⚠ Subscription của bạn
   ├── ⚠ Customer RG   →  ⚠ bạn thấy và quản lý
   └── ⚠ Managed RG    →  ⚠ khoá lại, do bên thứ ba vận hành

⚠ Managed resource group thường bị khoá để bạn không xoá nhầm thành phần mà giải pháp đang cần.

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

• B (Partner Resource Group), D (Virtual Resource Group), E (Controlled Resource Group) — ⚠ đều không phải tên Azure dùng.

Ghi nhớ

⚠ NVA — Network Virtual Appliance là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Thiết bị mạng ảo của bên thứ ba | ⚠ tường lửa, bộ định tuyến, WAN optimizer | | ⚠ Nhà cung cấp tiêu biểu | ⚠ Barracuda, Cisco, Fortinet, Check Point, Palo Alto | | ⚠ Mua qua Azure Marketplace | ⚠ tính vào hoá đơn Azure | | ⚠ Trong Virtual WAN hub | ⚠ triển khai ngay trong hub, không cần VNet riêng |

Từ khoá nhận diện:

"thiết bị mạng của bên thứ ba" → ⚠ NVA "tường lửa do Microsoft quản lý" → ⚠ Azure Firewall "lọc cơ bản theo cổng, miễn phí" → ⚠ NSG "nhóm tài nguyên bị khoá, do nhà cung cấp quản" → ⚠ managed resource group

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có ai từng sửa tay tài nguyên trong managed RG không | ⚠ rất dễ làm hỏng dịch vụ | | Chi phí NVA gồm những khoản nào | ⚠ hạ tầng Azure CỘNG giấy phép phần mềm | | Ai hỗ trợ khi NVA gặp sự cố | ⚠ nhà cung cấp, không phải Microsoft |

Và nguyên tắc chung với mọi managed resource group: đừng đụng vào. Nó nằm trong subscription của bạn nên trông có vẻ thuộc quyền bạn, nhưng sửa tay bên trong là cách nhanh nhất để làm hỏng một dịch vụ mà bạn không tự sửa lại được.

Đáp án

D — Bất kỳ giao thức nào ở trên.

Vì sao đúng

⚠ Point-to-Site VPN của Azure hỗ trợ cả ba giao thức: | Giao thức | Nền tảng | Đặc điểm | |---|---|---| | ⚠ OpenVPN (SSL/TLS) | ⚠ Windows, macOS, Linux, iOS, Android | ⚠ linh hoạt nhất, BẮT BUỘC nếu xác thực bằng Entra ID | | ⚠ SSTP (SSL) | ⚠ CHỈ Windows | ⚠ dùng cổng 443 nên qua được hầu hết tường lửa | | ⚠ IKEv2 (IPsec) | ⚠ Windows, macOS, Linux | ⚠ chuẩn VPN truyền thống |

⚠ Bật được nhiều giao thức cùng lúc trên một gateway, để máy khách trên các nền tảng khác nhau đều nối được.

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

• A, B, C — ⚠ mỗi phương án chỉ nêu MỘT giao thức, trong khi cả ba đều được hỗ trợ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23180 trong lô này hỏi máy chủ nào cần cho P2S xác thực qua AD (đáp án RADIUS). ⚠ Câu này hỏi về GIAO THỨC đường hầm. Hai câu bổ sung nhau — xác thực và đường hầm là hai chuyện khác nhau.

⚠ Ba cách xác thực P2S — và giao thức tương ứng: | Xác thực | Giao thức hỗ trợ | |---|---| | ⚠ Chứng chỉ Azure | ⚠ cả ba | | ⚠ RADIUS (tới AD tại chỗ) | ⚠ cả ba | | ⚠ Microsoft Entra ID | ⚠ CHỈ OpenVPN |

Từ khoá nhận diện:

"muốn dùng MFA và Conditional Access cho VPN" → ⚠ Entra ID, bắt buộc OpenVPN "máy khách chỉ có Windows" → ⚠ SSTP dùng được "cần qua tường lửa chặn hết trừ 443" → ⚠ SSTP hoặc OpenVPN "xác thực bằng AD tại chỗ" → ⚠ RADIUS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dải IP máy khách có chồng với mạng nào không | ⚠ nguyên nhân lỗi phổ biến nhất | | Có cần MFA cho người dùng từ xa không | ⚠ nếu có thì phải Entra ID kèm OpenVPN | | SKU gateway có đủ số kết nối đồng thời không | |

Và ràng buộc nên nhớ khi thiết kế VPN cho người làm từ xa: muốn có MFA thì phải dùng xác thực Entra ID, mà xác thực Entra ID chỉ chạy trên OpenVPN. Chọn giao thức và chọn cách xác thực là hai quyết định ràng buộc lẫn nhau.

Đáp án

E — Tất cả những công cụ trên.

Vì sao đúng

⚠ Nâng băng thông một ExpressRoute circuit làm được bằng mọi công cụ quản lý Azure: | Công cụ | Được không | |---|---| | ⚠ Azure Portal | ⚠ được | | ⚠ REST API | ⚠ được | | ⚠ PowerShell | ⚠ được | | ⚠ Azure CLI | ⚠ được |

⚠ Đây là nguyên tắc chung của Azure: ⚠ hầu như mọi thao tác quản lý đều đi qua Azure Resource Manager, nên Portal, CLI, PowerShell và REST API chỉ là các mặt tiền khác nhau của cùng một API.

⚠ Portal  ⚠ CLI  ⚠ PowerShell  ⚠ SDK  ⚠ ARM template
        ↘   ↓   ↓   ↙
      ⚠ Azure Resource Manager
              ↓
        ⚠ Tài nguyên

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

• A, B, C, D — ⚠ mỗi phương án chỉ nêu MỘT công cụ, trong khi cả bốn đều làm được.

Ghi nhớ

⚠ Ràng buộc quan trọng về băng thông ExpressRoute: | Thao tác | Được không | |---|---| | ⚠ TĂNG băng thông | ⚠ ĐƯỢC, không gián đoạn, nếu cổng vật lý còn dư | | ⚠ GIẢM băng thông | ⚠ KHÔNG — phải xoá circuit và tạo lại |

⚠ Vì thế nên bắt đầu ở mức thấp rồi nâng dần, chứ đừng mua dư ngay từ đầu.

Từ khoá nhận diện:

"tăng băng thông circuit" → ⚠ được, không gián đoạn "giảm băng thông circuit" → ⚠ phải tạo lại circuit "đổi SKU từ Standard sang Premium" → ⚠ được "đổi mô hình tính tiền metered sang unlimited" → ⚠ được, nhưng KHÔNG đảo ngược được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Băng thông hiện tại có đang dùng hết không | ⚠ xem chỉ số trong Azure Monitor | | Cổng vật lý ở nhà cung cấp còn dư không | ⚠ giới hạn thật nằm ở đó | | Mô hình tính tiền có phù hợp mức dùng không | |

Và điều cần cân nhắc trước khi chọn băng thông ban đầu cho ExpressRoute: nâng lên thì dễ, hạ xuống thì phải làm lại từ đầu. Bắt đầu ở mức vừa đủ rồi nâng dần luôn là lựa chọn an toàn hơn về tài chính.

Đáp án

E — AllowAllInbound.

Vì sao đúng

⚠ Mỗi NSG do người dùng tạo đều có SÁU luật mặc định, không xoá được: | Chiều | Luật mặc định | Ưu tiên | |---|---|---| | ⚠ Vào | ⚠ AllowVNetInBound | ⚠ 65000 | | ⚠ Vào | ⚠ AllowAzureLoadBalancerInBound | ⚠ 65001 | | ⚠ Vào | ⚠ DenyAllInBound | ⚠ 65500 | | ⚠ Ra | ⚠ AllowVnetOutBound | ⚠ 65000 | | ⚠ Ra | ⚠ AllowInternetOutBound | ⚠ 65001 | | ⚠ Ra | ⚠ DenyAllOutBound | ⚠ 65500 |

⚠ KHÔNG có luật nào tên AllowAllInbound — và cũng không thể có, vì mặc định của Azure là chặn mọi lưu lượng vào từ ngoài VNet.

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

• A, B, C, D — ⚠ đều là luật mặc định thật, nằm trong bảng trên.

Ghi nhớ

⚠ Ý nghĩa của bộ luật mặc định: | Kết quả | Nội dung | |---|---| | ⚠ Trong cùng VNet nói chuyện được với nhau | ⚠ AllowVNetInBound | | ⚠ Load Balancer thăm dò được sức khoẻ | ⚠ AllowAzureLoadBalancerInBound | | ⚠ Internet KHÔNG vào được | ⚠ DenyAllInBound | | ⚠ Máy ra được Internet | ⚠ AllowInternetOutBound | | ⚠ Nghĩa là | ⚠ mặc định đã khá an toàn ở chiều vào, khá thoáng ở chiều ra |

⚠ Cách NSG xét luật:

⚠ Xếp theo ƯU TIÊN, số nhỏ xét trước
        ↓
⚠ Khớp luật nào thì DỪNG, không xét tiếp
        ↓
⚠ Không khớp gì  →  ⚠ rơi vào luật mặc định

⚠ Ưu tiên hợp lệ cho luật tự tạo: 100 tới 4096 — luôn nhỏ hơn 65000 nên luôn được xét trước luật mặc định.

Từ khoá nhận diện:

"luật mặc định" → ⚠ sáu luật, ưu tiên 65000–65500, không xoá được "ghi đè luật mặc định" → ⚠ tạo luật với ưu tiên nhỏ hơn "tổng hợp luật đang áp lên một card mạng" → ⚠ effective security rules "luật nào đang chặn gói này" → ⚠ IP flow verify

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có luật nào cho phép Internet vào không | ⚠ rà lại từng cái | | Luật chiều ra có chặn nhầm dịch vụ nền tảng không | | | Máy nào đang chịu NSG ở cả hai cấp | |

Và điều nên nhớ khi thiết kế luật NSG: mặc định của Azure đã chặn mọi thứ vào từ Internet. Mỗi luật bạn thêm ở chiều vào là một lần nới lỏng — nên câu hỏi luôn phải là "cái này có thật sự cần mở không".

Đáp án

C — Cho phép lưu lượng vào từ AzureBastionSubnet tới mọi địa chỉ đích

Vì sao đúng

Khi dùng Azure Bastion, kết nối RDP hay SSH không đến từ Internet mà đến từ chính subnet của Bastion nằm trong VNet của bạn. Vì vậy luật NSG chỉ cần mở cho nguồn là AzureBastionSubnet, và máy ảo không cần địa chỉ IP công khai nào.

Đây là điểm mạnh của Bastion: cổng 3389 và 22 không bao giờ phơi ra Internet, nên chúng không nằm trong tầm quét tự động.

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

• A. Mở cổng 3389 từ mọi nguồn và B. Mở cổng 22 từ mọi nguồn — phơi cổng quản trị ra toàn bộ Internet, đúng thứ Bastion sinh ra để tránh.
• D. Mở cổng 22 từ IP công khai của VPN gateway — mô hình dùng VPN, không phải Bastion; và khi đã có Bastion thì không cần đường này.

Đáp án

B — Get-AzExpressRouteCircuit -ResourceGroupName.

Vì sao đúng

⚠ Quy ước đặt tên tham số của Azure PowerShell rất nhất quán: | Tham số | Dùng cho | |---|---| | ⚠ -ResourceGroupName | ⚠ TÊN của resource group — dạng chuẩn | | ⚠ -Name | ⚠ tên của chính tài nguyên | | ⚠ -SubscriptionId | ⚠ subscription | | ⚠ Không có tham số nào tên | ⚠ -ResourceGroup |

⚠ Get-AzExpressRouteCircuit -ResourceGroupName "RG-Mang"
⚠ Get-AzExpressRouteCircuit -ResourceGroupName "RG-Mang" -Name "Circuit-HN"

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

• A (-ResourceGroup) — ⚠ sai tên tham số; PowerShell sẽ báo lỗi.

• C (Get-AzAllExpressRouteCircuit) — ⚠ cmdlet không tồn tại; bỏ -ResourceGroupName thì Get-AzExpressRouteCircuit đã liệt kê toàn bộ subscription.

• D (Get-AzExpressRouteCircuitStats) — ⚠ có tồn tại nhưng trả về THỐNG KÊ lưu lượng, không liệt kê circuit.

Ghi nhớ

⚠ Quy ước động từ của Azure PowerShell: | Động từ | Việc | |---|---| | ⚠ Get- | ⚠ đọc, liệt kê | | ⚠ New- | ⚠ tạo mới | | ⚠ Set- | ⚠ sửa | | ⚠ Remove- | ⚠ xoá | | ⚠ Add- | ⚠ thêm vào một tài nguyên đã có | | ⚠ Mọi cmdlet Azure | ⚠ có tiền tố Az sau động từ |

Từ khoá nhận diện:

Verb-AzNoun → ⚠ Azure PowerShell az <nhóm> <lệnh> → ⚠ Azure CLI Remove- → ⚠ PowerShell xoá, KHÔNG phải Delete- -ResourceGroupName → ⚠ KHÔNG phải -ResourceGroup

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang ở subscription nào | ⚠ Get-AzContext | | Cmdlet có tồn tại không | ⚠ Get-Command thay vì đoán | | Kịch bản có khai rõ subscription không | ⚠ đừng dựa vào mặc định |

Và cách tránh gần như mọi câu hỏi kiểu này trong phòng thi: nhớ quy ước thay vì nhớ từng lệnh. Động từ chuẩn của PowerShell, tiền tố Az, và tham số -ResourceGroupName — ba điều đó loại được phần lớn phương án nhiễu.