Ngân hàng đề — Microsoft Azure Network Engineer

Tìm thấy 164 câu.

Câu 161
You have an on-premises datacenter in Seattle.

You have an Azure subscription that contains an Azure Network Watcher resource in the West US 2 Azure region.

You need to document network latency between the on-premises datacenter and the West US 2 region and between the on-premises datacenter and the East US 2 public Azure region. The solution must minimize administrative effort.

What should you do first?
  1. A Run the Get-AzNetworkWatcherConnectionMonitor cmdlet.
  2. B Run the Get-AzNetworkWatcherReachabilityProvidersList cmdlet.
  3. C Create a Network Watcher resource in the East US 2 region.
  4. D Create a Connection Monitor resource in the West US 2 region.
Xem giải thích

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi mô tả tình huống:
Bạn có một datacenter on-premises tại Seattle (Mỹ).
Bạn sở hữu một Azure subscription chứa Azure Network Watcher resource đã được triển khai sẵn ở vùng West US 2.
Nhiệm vụ: Document (ghi nhận) network latency (độ trễ mạng) giữa:

  • Datacenter on-premises và vùng West US 2.
  • Datacenter on-premises và vùng East US 2 public Azure region.
    Yêu cầu giải pháp minimize administrative effort (giảm thiểu công sức quản trị).
    Câu hỏi yêu cầu hành động đầu tiên (What should you do first?) để đạt được mục tiêu này.

📘 Bối cảnh kỹ thuật (dựa trên Azure Network Watcher phiên bản mới nhất 2025-2026):
Azure Network Watcher là dịch vụ giám sát mạng, hỗ trợ Connection Monitor v2 (phiên bản hiện tại, thay thế v1 từ 2021). Connection Monitor v2 cho phép đo latency, packet loss, hops từ nguồn (source) như on-premises (qua public IP, agentless) đến đích (destination) như VM/IP ở các Azure region khác nhau mà không cần Network Watcher ở mọi region. Nó sử dụng giao thức TCP/UDP/ICMP, hỗ trợ cross-region và on-premises mà chỉ cần Network Watcher ở một region duy nhất (ở đây là West US 2). Điều này giúp minimize effort vì không cần tạo thêm tài nguyên.

✅ Đáp án đúng: Create a Connection Monitor resource in the West US 2 region.

Lý do lựa chọn:
🛠️ Đây là bước đầu tiên và tối ưu vì:

  • Connection Monitor v2 (tạo trong region có Network Watcher sẵn - West US 2) hỗ trợ monitor agentless từ on-premises (Seattle public IP) đến nhiều destination như West US 2 và East US 2 (qua public endpoint hoặc VM IP).
  • Không cần tạo Network Watcher mới ở East US 2 (vì CM v2 là region-agnostic cho destination).
  • Minimize effort: Chỉ tạo 1 resource CM, cấu hình source (on-prem IP), destinations (IPs ở 2 regions), chạy test để document latency (hiển thị charts, reports).
  • Theo docs Azure 2025: CM v2 hỗ trợ up to 100 destinations từ 1 source, cross-subscription/region.

Nguồn tham khảo:

📋 Giải thích tất cả các phương án (đúng/sai)

  • Run the Get-AzNetworkWatcherConnectionMonitor cmdlet.
    ❌ Sai: Cmdlet này chỉ lấy thông tin (GET) về Connection Monitor đã tồn tại, không tạo mới hay khởi động monitoring. Bạn cần tạo CM trước để đo latency. Sử dụng nó đầu tiên sẽ lỗi vì chưa có resource.

  • Run the Get-AzNetworkWatcherReachabilityProvidersList cmdlet.
    ❌ Sai: Cmdlet này liệt kê Reachability Providers (dịch vụ bên thứ 3 như ThousandEyes), dùng cho Network Watcher Reachability Report (chỉ check reachability, không đo latency chi tiết). Không phù hợp cho on-premises latency đến 2 regions, và không minimize effort vì cần tích hợp bên thứ 3.

  • Create a Network Watcher resource in the East US 2 region.
    ❌ Sai: Không cần thiết! Network Watcher ở West US 2 đã đủ cho Connection Monitor v2 monitor cross-region (East US 2). Tạo thêm NW ở East US 2 tăng effort (chi phí, quản lý), vi phạm yêu cầu minimize administrative effort. Docs Azure xác nhận CM v2 chỉ cần NW ở source region hoặc bất kỳ, không bắt buộc per-destination.

  • Create a Connection Monitor resource in the West US 2 region.
    ✅ Đúng: Như giải thích trên, đây là bước first action lý tưởng để setup monitoring latency từ on-prem đến cả 2 regions mà không cần tài nguyên bổ sung. Hỗ trợ output reports/charts để document.

🧩 Tóm tắt lợi ích: Giải pháp này nhanh (portal/PowerShell/CLI), chi phí thấp (~0.01$/test), và scale tốt cho hybrid cloud (on-prem + Azure multi-region). Nếu cần implement, dùng Azure Portal > Network Watcher > Connection Monitor > Create.

Câu 162
Case Study -

This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.

To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.

At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.


To start the case study -
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirements, existing environment, and problem statements. When you are ready to answer a question, click the Question button to return to the question.


Overview -

Proseware, Inc. is a financial services company that has a main office in New York City and a branch office in San Francisco.

Existing Environment. Hybrid Environment

Proseware has an on-premises Active Directory Domain Services (AD DS) forest named corp.proseware.com that syncs with a Microsoft Entra tenant named proseware.com.

Proseware has an Azure subscription that is linked to proseware.com.

Proseware has an internal certification authority (CA).

Existing Environment. Network Infrastructure

The offices contain the resources shown in the following table.



NYCNet connects to Azure by using an ExpressRoute circuit.

SFONet connects to Azure by using a Site-to-Site (S2S) VPN.

Existing Environment. Azure Resources

The Azure subscription contains the virtual networks and subnets shown in the following table.



The subscription contains four virtual machines named VM1, VM2, VM3, and VM4. VM1 and VM2 host an app named App1.

VM3 and VM4 host a web app named App2 that is accessed by using a FQDN of app2.proseware.com. Users access app2.proseware.com by using HTTP or HTTPS.

VM1, VM2, and VM4 are connected to SpokeVNet.

The subscription contains Application Gateway resources shown in the following table.



The subscription contains an Azure Front Door Standard profile named FD1. FD1 contains a single origin group that targets APPGW1 by using the default endpoint name.

HubVNet connects to NYCNet by using an ExpressRoute gateway named ERGW1.

Planned Changes and Requirements. Planned Changes

Proseware plans to implement the following changes:

•Deploy an Azure Private DNS Resolver named PRDNS1 to HubVNet and link PRDNS1 to SpokeVNet.
•Create a DNS forwarding ruleset named DNSRS1 and associate DNSRS1 with PRDNS1.
•Deploy Azure Virtual Network Manager and implement the following rules:
- Allow inbound connections on TCP port 3389 from the on-premises networks to SUBNET-JUMPHOSTS.
- Block inbound connections on TCP port 80 from the internet to SpokeVNet.
•Ensure that Azure Virtual Network Manager rules take precedence over conflicting NSG rules.
•Deploy two network virtual appliances (NVAs) named NVA1 and NVA2 to HubVNet.
•Deploy a gateway load balancer named LBGW1 to HubVNet.
•Configure LBGW1 to inspect traffic on TCP ports 443, 1433, and 1434 from LBS1 by using NVA1 and NVA2.
•Ensure that all the traffic to App2 is processed by using FD1.

Planned Changes and Requirements. Connectivity requirements

Proseware identifies the following connectivity requirements:

•Minimize the complexity of the Azure Virtual Network Manager deployment.
•Route traffic between NYCNet and SFONet via the ExpressRoute circuit and the S2S VPN.
•Ensure that remote users on Windows 11 devices can connect to HubVNet by using a Point-to-Site (P2S) VPN and their proseware.com credentials.

Planned Changes and Requirements. Security requirements

Proseware identifies the following security requirements:

•Whenever possible, use the internal CA.
•Ensure that all connections routed via APPGW1 use end-to-end encryption.
•Ensure that user connections to Azure-hosted apps use end-to-end encryption.
•Ensure that all inbound internet traffic to app2.proseware.com is routed via FD1.
•Prevent devices that connect to NYCNet from accessing Azure services that use private endpoints.
•Enable the virtual machines that connect to HubVNet and SpokeVNet to access Azure services that use private endpoints.

Planned Changes and Requirements. General requirements

Proseware identifies the following general requirements:

•Minimize the IP address space required to deploy platform-managed resources to the virtual networks.
•From SpokeVNet, resolve name resolution requests for the azure.proseware.com namespace and the corp.proseware.com namespace by using PRDNS1.
•Whenever possible, minimize administrative effort.


You need to configure APPGW1 to support end-to-end encryption. The solution must meet the security requirements.

What should you do?
  1. A From the SSL settings, upload a TLS client certificate that is issued by the internal root CA and includes the full certificate chain.
  2. B From the Backend settings, upload the internal root CA certificate.
  3. C From the SSL settings, upload a TLS client certificate that is issued by the internal root CA.
  4. D From the Backend settings, upload a wildcard TLS certificate that has a private key issued by the internal root CA.
Xem giải thích

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi thuộc phần Case Study của kỳ thi AZ-700 (Microsoft Azure Networking), tập trung vào việc cấu hình APPGW1 (Application Gateway v2 SKU) để hỗ trợ end-to-end encryption (mã hóa đầu cuối) cho các kết nối đi qua nó, đồng thời tuân thủ yêu cầu bảo mật.

Bối cảnh từ Case Study (dựa trên mô tả văn bản và 3 hình ảnh đính kèm):

  • Mạng lưới: HubVNet (10.0.0/20) peered với SpokeVNet (10.16.0/20). APPGW1 nằm trong SUBNET-APGW1 của SpokeVNet.
  • Tài nguyên Azure: VM3 và VM4 (backend pool của App2 tại app2.proseware.com) kết nối SpokeVNet. APPGW1 terminates HTTPS connections (kết thúc mã hóa HTTPS ở frontend) đến backend pool chứa VM3/VM4 (hình ảnh 3 xác nhận rõ: "Terminates HTTPS connections to a backend pool that contains VM3 and VM4").
  • Yêu cầu bảo mật chính:
    • Tất cả kết nối qua APPGW1 phải dùng end-to-end encryption (mã hóa từ client → AG → backend).
    • Ưu tiên sử dụng internal CA (Certification Authority nội bộ).
    • Kết nối đến Azure-hosted apps (như App2) cũng cần end-to-end encryption.
    • Traffic đến app2.proseware.com qua FD1, nhưng APPGW1 là origin của FD1.
  • Vấn đề hiện tại: APPGW1 chỉ terminate HTTPS ở frontend (decrypt rồi forward plain text hoặc HTTP đến backend VM3/VM4), không đảm bảo mã hóa đến backend → cần cấu hình backend HTTPS với trust CA nội bộ.
  • Mục tiêu: Cấu hình APPGW1 để backend protocol là HTTPS, verify cert của VM3/VM4 bằng root CA nội bộ, đạt end-to-end TLS mà không cần cert public.

Kiến thức cập nhật (Azure Application Gateway v2 đến 2026): Hỗ trợ HTTPS backend với trusted root certificate upload vào Backend settings để verify server cert chain (không cần private key cho root CA). Điều này giảm thiểu effort và dùng internal CA như yêu cầu.

✅ Đáp án đúng: From the Backend settings, upload the internal root CA certificate.

Lý do lựa chọn:

  • Để đạt end-to-end encryption, sau khi terminate TLS ở frontend listener (HTTPS), AG phải forward traffic đến backend qua HTTPS (backend protocol = HTTPS).
  • Backend servers (VM3/VM4) dùng cert từ internal root CA → AG cần trusted root CA certificate để verify cert chain của backend (không cần full chain hay private key).
  • Upload root CA cert vào Backend settings (của backend pool chứa VM3/VM4) kích hoạt verification tự động, đảm bảo mã hóa toàn đường đi.
  • Tuân thủ: Dùng internal CA, minimize effort (không cần cert mới), hỗ trợ WAF policy hiện có trên APPGW1.
  • Hình ảnh 3 xác nhận backend là VM3/VM4 → config đúng pool này.

🛠️ Giải thích tất cả các phương án (đúng/sai)

  • ❌ [SAI] From the SSL settings, upload a TLS client certificate that is issued by the internal root CA and includes the full certificate chain.

    • Phân tích sai: "SSL settings" dùng cho frontend listener (client-side TLS termination), không liên quan backend encryption. "TLS client certificate" là cho mutual TLS (mTLS) (AG làm client verify backend), nhưng yêu cầu chỉ end-to-end (server-side verify), không cần client cert. "Full certificate chain" thừa thãi cho root CA verify.

  • ✅ [ĐÚNG] From the Backend settings, upload the internal root CA certificate.

    • Phân tích đúng: Như giải thích trên. Backend settings chính xác vị trí upload root CA public cert (PEM/CRT format) để AG trust và verify backend cert từ internal CA. Đảm bảo end-to-end TLS (client→AG→VM3/VM4), dùng internal CA, không cần private key.

  • ❌ [SAI] From the SSL settings, upload a TLS client certificate that is issued by the internal root CA.

    • Phân tích sai: Tương tự phương án 1, "SSL settings" chỉ frontend, "TLS client cert" dành mTLS (AG gửi cert cho backend verify), không phải verify backend cert. Không đạt end-to-end đơn giản.

  • ❌ [SAI] From the Backend settings, upload a wildcard TLS certificate that has a private key issued by the internal root CA.

    • Phân tích sai: Backend settings dùng root CA cert (chỉ public key để verify), không phải wildcard TLS cert với private key (dành listener hoặc server-side cert). Upload private key vào AG không an toàn/an toàn và không cần (AG không impersonate backend).

📘 Tài liệu tham khảo (cập nhật 2026)

Cấu hình này minimize IP space và admin effort như general requirements! 🚀

Câu 163
You have an Azure subscription that contains a virtual machine named VM1, a virtual network interface card (NIC) named NIC1, and a Basic SKU public IP address named IP1. NIC1 is attached to VM1. IP1 is associated to NIC1.
You need to upgrade IP1 to the Standard SKU.

What should you do first?
  1. A Create a new NIC for VMI.
  2. B Disassociate IP1 from NIC1.
  3. C Detach NIC1 from VM1.
  4. D Stop vM1.
Xem giải thích

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi này thuộc lĩnh vực Microsoft Azure Networking, cụ thể là quản lý Public IP Address trong Azure Virtual Network. Tình huống: Bạn có một subscription Azure chứa:

  • VM1: Một máy ảo (Virtual Machine).
  • NIC1: Card mạng ảo (Network Interface Card) được gắn vào VM1.
  • IP1: Địa chỉ IP công khai (Public IP Address) thuộc Basic SKU, được liên kết (associated) với NIC1.

Yêu cầu nhiệm vụ: Nâng cấp IP1 từ Basic SKU lên Standard SKU.
Lưu ý quan trọng (dựa trên tài liệu Azure cập nhật đến năm 2024-2026):

  • Basic SKU là thế hệ cũ, không hỗ trợ các tính năng nâng cao như Availability Zones, DDoS Protection, hoặc Route Tables.
  • Standard SKU là thế hệ mới, hỗ trợ các tính năng bảo mật và độ tin cậy cao hơn, nhưng KHÔNG THỂ nâng cấp trực tiếp nếu IP đang được associate với tài nguyên (như NIC).
  • Quy trình nâng cấp yêu cầu dissociate IP trước, sau đó upgrade SKU, rồi associate lại. VM có thể chạy bình thường trong quá trình này (không cần stop).

📘 Tài liệu tham khảo:

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Disassociate IP1 from NIC1.
🛠️ Lý do: Theo quy trình chính thức của Azure (cập nhật mới nhất 2024+), bước đầu tiên và bắt buộc để nâng cấp Public IP từ Basic sang Standard là ngắt liên kết (disassociate) IP khỏi NIC hoặc tài nguyên đang gắn. Nếu không làm bước này, Azure sẽ báo lỗi vì Standard SKU không tương thích với các ràng buộc của Basic (như không hỗ trợ associate trực tiếp). Sau khi dissociate, bạn có thể thực hiện upgrade SKU qua Portal/CLI/PowerShell, rồi associate lại mà KHÔNG CẦN dừng VM. Điều này đảm bảo tính linh hoạt và giảm downtime.

🔍 Giải thích tất cả các phương án (đúng/sai)

Dưới đây là phân tích từng lựa chọn một cách chi tiết, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên quy trình Azure Networking chính xác:

  • "Create a new NIC for VMI." ❌ Sai.
    🧩 Phương án này không cần thiết và không phải bước đầu tiên. Tạo NIC mới (cho VM1, có lẽ lỗi chính tả "VMI") sẽ làm phức tạp hóa cấu hình, tăng chi phí và không giải quyết vấn đề SKU của IP1. Azure cho phép upgrade IP mà không cần thay NIC; chỉ cần dissociate IP khỏi NIC hiện tại là đủ.

  • "Disassociate IP1 from NIC1." ✅ Đúng.
    🛠️ Như đã giải thích ở trên, đây là bước đầu tiên bắt buộc theo docs Microsoft. Dissociate IP sẽ giải phóng ràng buộc Basic SKU, cho phép upgrade lên Standard mà không ảnh hưởng đến VM/NIC đang chạy.

  • "Detach NIC1 from VM1." ❌ Sai.
    🧩 Detach NIC khỏi VM sẽ gây gián đoạn kết nối mạng của VM1 (VM mất mạng hoàn toàn), và đây KHÔNG PHẢI yêu cầu cho việc upgrade IP. Azure không đòi hỏi detach NIC; chỉ cần dissociate IP từ NIC là VM vẫn hoạt động bình thường với private IP.

  • "Stop vM1." ❌ Sai.
    🧩 Dừng VM1 (stop/deallocate) là không cần thiết và gây downtime không đáng có. Theo best practices Azure 2024+, việc upgrade IP SKU có thể thực hiện trong khi VM đang chạy, miễn là dissociate IP trước. Stop VM chỉ áp dụng cho một số thay đổi khác như resize VM hoặc thay đổi size.

💡 Lời khuyên từ Azure Network Engineer: Để thực hiện thực tế, dùng Azure CLI:
az network public-ip update --resource-group <RG> --name IP1 --sku Standard (sau khi dissociate). Kiểm tra luôn Availability Zone nếu cần cho Standard SKU! 🚀

Câu 164
You have an Azure subscription that contains the resources shown in the following table.



You test DDoSplan1 by running a simulation that targets IP1.

You need to review the DDoS Protection mitigation reports.

What should you use?
  1. A DDos protection plan in the Azure portal
  2. B Log Analytics
  3. C Microsoft Defender for Cloud
  4. D Azure Monitor Network Insights
Xem giải thích

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

📖 Nội dung câu hỏi:
Câu hỏi thuộc kỳ thi chứng chỉ AZ-700: Designing and Implementing Microsoft Azure Networking Solutions (phiên bản cập nhật mới nhất đến năm 2026). Nội dung mô tả một subscription Azure chứa các tài nguyên như sau:

  • DDoSplan1: Một Azure DDoS Protection plan (kế hoạch bảo vệ DDoS cấp Standard) được kích hoạt (enabled) cho VNet1.
  • VNet1: Một Virtual Network chứa một Virtual Machine (VM1).
  • IP1: Một Public IP address được liên kết (associated) với VM1.

Người dùng đã chạy một simulation DDoS (mô phỏng tấn công DDoS) nhắm vào IP1 bằng DDoSplan1. Nhiệm vụ là xem xét (review) các báo cáo giảm thiểu (mitigation reports) của DDoS Protection.
✅ Mục tiêu chính: Xác định công cụ chính xác để truy cập báo cáo chi tiết về các hành động giảm thiểu tấn công DDoS sau simulation. Đây là tính năng cốt lõi của Azure DDoS Protection Standard, cung cấp báo cáo thời gian thực và lịch sử về các cuộc tấn công được phát hiện và giảm thiểu.

🖼️ Phân tích hình ảnh đính kèm:
Hình ảnh là một bảng tóm tắt tài nguyên:
| Tên | Loại | Mô tả |
|----------|-------------------------------|------------------------|
| DDoSplan1| Azure DDoS Protection plan | Enabled for VNet1 |
| VNet1 | Virtual network | Contains VM1 |
| IP1 | Public IP address | Associated to VM1 |

🛠️ Ý nghĩa:

  • DDoSplan1 bảo vệ toàn bộ VNet1 (bao gồm IP1 công khai của VM1).
  • Simulation tấn công IP1 sẽ kích hoạt mitigation qua DDoSplan1, và báo cáo sẽ hiển thị telemetry như lưu lượng tấn công, hành động giảm thiểu (scrubbing, rate limiting), thời gian phát hiện/phục hồi.

✅ Đáp án đúng:
DDoS protection plan in the Azure portal

Lý do chọn (🧠 Giải thích chi tiết):
Trong Azure DDoS Protection Standard (cập nhật 2026), các mitigation reports được truy cập trực tiếp từ Azure portal tại trang DDoS protection plan (DDoSplan1).

  • Sau simulation, bạn vào Azure portal > DDoS protection plans > DDoSplan1 > Metrics/Reports để xem:
    • Báo cáo tấn công (Attack analytics): Lưu lượng under attack, mitigation flow.
    • Báo cáo mitigation: Chi tiết IP bị tấn công (IP1), loại tấn công, thời gian mitigation.
  • Đây là cách chuẩn và nhanh nhất, hỗ trợ export PDF/CSV. Không cần cấu hình thêm Log Analytics hay công cụ khác.
    📘 Tài liệu tham khảo: Azure Docs - View and configure DDoS protection telemetry (cập nhật 2025-2026).

❌ Giải thích tất cả các phương án (đúng/sai):

  • ✅ DDos protection plan in the Azure portal
    Phương án đúng tuyệt đối 🏆. Như giải thích trên, đây là vị trí chính thức lưu trữ và hiển thị mitigation reports sau simulation. Hỗ trợ xem realtime dashboard với graph về SYN flood, UDP, etc., phù hợp cho IP1 trong VNet1 được bảo vệ bởi DDoSplan1.

  • ❌ Log Analytics
    Phương án sai. Log Analytics dùng để query logs DDoS (diagnostic logs từ DDoS protection), nhưng không phải nơi chính để xem mitigation reports. Reports là UI-based trong portal, không phải log query. Bạn cần enable diagnostic settings riêng để gửi logs sang Log Analytics, nhưng simulation reports không tự động ở đây.

  • ❌ Microsoft Defender for Cloud
    Phương án sai. Microsoft Defender for Cloud (trước là Security Center) cung cấp security recommendations và alerts cho DDoS (qua integration), nhưng không có mitigation reports chi tiết. Nó chỉ overview threats, không drill-down vào DDoSplan1 reports như attack vectors trên IP1.

  • ❌ Azure Monitor Network Insights
    Phương án sai. Azure Monitor Network Insights dùng cho topology visualization và traffic insights (NSG flows, etc.), nhưng không hỗ trợ DDoS mitigation reports. Nó không tích hợp trực tiếp DDoS telemetry từ protection plan.

🛡️ Kết luận & Lời khuyên thực tế:
Câu hỏi kiểm tra kiến thức sâu về Azure DDoS Protection Standard vs các công cụ monitoring khác. Trong thực tế, luôn kiểm tra portal DDoS plan đầu tiên sau simulation để troubleshoot. Nếu cần automate, dùng Azure Monitor alerts hoặc API.
🔗 Nguồn bổ sung: Azure DDoS Protection Overview (2026 updates bao gồm AI-based detection enhancements).