Ngân hàng đề — Microsoft Azure Networking
Tìm thấy 99 câu.
You’re hosting a two-tier application within VNet-01, which has a CIDR block of 10.0.0.0/16, and the following resource configurations:
-
The front end is situated on a VM called “VMFrontend” within a public subnet. This public subnet has an IP address range of 10.0.2.0/24. VM_Front has a private IP address of 10.0.2.5 and a public IP address of 192.168.50.2.
-
The back end is located on a second VM, “VMBackend,” within a private subnet. This private subnet has an IP address range of 10.0.3.0/24. VMBackend has a private IP address of 10.0.3.4.
-
A public load balancer is present with a private IP address of 10.0.1.6 and a public IP address of 172.16.50.35.
You’re setting up a final rule for a network security group (NSG) linked to resources in the private subnet where VMBackend is located. This final rule should deny all traffic from the public subnet. Any traffic from the public subnet that doesn’t match any of the NSG Allow rules would be handled by this rule.
Which parameters for the NSG rule would fulfill the requirements for this NSG rule?
-
A
Inbound Rule Source: 10.0.2.0/24 Source Port: 0-65535 Destination: 10.0.3.4 Destination Port: 0-65535 Protocol: ANY Priority: 4096 Action: Deny
-
B
Outbound Rule Source: 10.0.2.0/24 Source Port: 0-65535 Destination: 10.0.3.4 Destination Port: 0-65535 Protocol: ANY Priority: 20 Action: Deny
-
C
Inbound Rule Source: 10.0.0.0/16 Source Port: * Destination: 10.0.3.4 Destination Port: * Protocol: ANY Priority: 4096 Action: Deny
-
D
Outbound Rule Source: 0.0.0.0/0 Source Port: * Destination: 10.0.3.4 Destination Port: * Protocol: ANY Priority: 20 Action: Deny
Xem giải thích
Đáp án
A — Luật VÀO: Nguồn 10.0.2.0/24, cổng nguồn 0-65535, Đích 10.0.3.4, cổng đích 0-65535, Giao thức ANY, Ưu tiên 4096, Hành động Deny.
Vì sao đúng
⚠ Bốn điểm khiến phương án A là luật "cuối cùng" đúng đắn: | Điểm | Nội dung | |---|---| | ⚠ Chiều VÀO | ⚠ bảo vệ VMBackend khỏi lưu lượng tới nó | | ⚠ Nguồn là subnet public 10.0.2.0/24 | ⚠ chính xác nguồn cần chặn | | ⚠ Đích là 10.0.3.4 | ⚠ địa chỉ riêng của VMBackend | | ⚠ Ưu tiên 4096 | ⚠ số LỚN NHẤT cho luật tự tạo — xét SAU CÙNG |
⚠ Vì sao ưu tiên 4096 là đúng cho một luật "cuối cùng": ⚠ NSG xét theo ưu tiên tăng dần, ⚠ nên 4096 được xét sau mọi luật cho phép khác — đúng vai trò của một luật chặn bao quát ở cuối danh sách.
Vì sao các phương án khác sai
-
B (luật RA, ưu tiên 20) — ⚠ sai CHIỀU, và ưu tiên 20 sẽ xét TRƯỚC mọi luật cho phép, chặn luôn cả lưu lượng hợp lệ.
-
C (nguồn 10.0.0.0/16) — ⚠ quá rộng; chặn cả lưu lượng từ subnet 10.0.1.0/24 nơi có load balancer, làm hỏng cả hệ thống.
-
D (luật RA, nguồn 0.0.0.0/0, ưu tiên 20) — ⚠ sai chiều, quá rộng, và ưu tiên quá cao.
Ghi nhớ
⚠ Khoảng ưu tiên của NSG: | Khoảng | Thuộc về | |---|---| | ⚠ 100 – 4096 | ⚠ luật tự tạo — 100 xét trước nhất, 4096 sau cùng | | ⚠ 65000 – 65500 | ⚠ luật mặc định của hệ thống | | ⚠ Quy tắc | ⚠ số NHỎ xét TRƯỚC; khớp là DỪNG |
⚠ Cách đặt ưu tiên cho hợp lý: | Loại luật | Ưu tiên nên đặt | |---|---| | ⚠ Luật chặn cụ thể, khẩn cấp | ⚠ 100 – 200 | | ⚠ Luật cho phép nghiệp vụ | ⚠ 300 – 1000 | | ⚠ Luật chặn bao quát cuối cùng | ⚠ 4000 – 4096 | | ⚠ Chừa khoảng trống | ⚠ đặt cách nhau 10 hoặc 100 để còn chèn luật sau |
Từ khoá nhận diện:
"luật cuối cùng, chặn phần còn lại" → ⚠ ưu tiên gần 4096 "chặn ngay, ưu tiên cao nhất" → ⚠ ưu tiên gần 100 "bảo vệ máy khỏi lưu lượng tới nó" → ⚠ luật VÀO "chặn máy gọi ra ngoài" → ⚠ luật RA
| ⚠ Nguyên tắc viết luật NSG | Nguyên tắc |
|---|---|
| ⚠ Cụ thể trước, bao quát sau | |
| ⚠ Phạm vi hẹp nhất có thể | ⚠ đừng dùng /16 khi /24 là đủ |
| ⚠ Chừa khoảng trống giữa các ưu tiên | |
| ⚠ Đặt tên luật nói rõ mục đích | |
| ⚠ Dùng ASG thay cho dải IP khi được |
| ⚠ Sai lầm về ưu tiên hay gặp | Sai lầm |
|---|---|
| ⚠ Đặt luật deny ở ưu tiên rất cao | ⚠ chặn luôn cả lưu lượng hợp lệ phía dưới |
| ⚠ Các luật đặt sát nhau 100, 101, 102 | ⚠ hết chỗ chèn, phải đánh số lại toàn bộ |
| ⚠ Dùng dải quá rộng | ⚠ chặn nhầm thành phần khác |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật này có che khuất luật cho phép nào không | ⚠ kiểm tra thứ tự ưu tiên | | Dải nguồn có rộng hơn mức cần không | | | Effective rules có đúng như mong đợi không | ⚠ dùng công cụ, đừng đọc tay |
Và nguyên tắc sắp xếp luật NSG cho bền: luật càng cụ thể đặt càng sớm, luật càng bao quát đặt càng muộn. Đảo ngược thứ tự đó là cách nhanh nhất để một luật deny nuốt mất toàn bộ lưu lượng hợp lệ.
You started moving your current applications from on-premise servers to resources on an Azure Virtual Network. Currently, the on-premise network and Azure are linked through ExpressRoute. It is crucial to ensure that the ExpressRoute connection is always in good health. Which Network Watcher service can you use to monitor the connection?
-
A
Connection Monitor
-
B
Traffic Analytics
-
C
VPN Troubleshoot
-
D
Connection Monitor (Classic)
Xem giải thích
Đáp án
A — Connection Monitor.
Vì sao đúng
⚠ Connection Monitor theo dõi kết nối LIÊN TỤC giữa hai điểm: | Khả năng | Nội dung | |---|---| | ⚠ Kiểm tra định kỳ, không phải một lần | | | ⚠ Đo độ trễ và tỷ lệ mất gói | | | ⚠ Vẽ sơ đồ từng chặng | ⚠ thấy được nghẽn ở đâu | | ⚠ Cảnh báo khi kết nối xuống cấp | | | ⚠ Hoạt động cả tại chỗ ↔ Azure, Azure ↔ Azure, Azure ↔ Internet | | | ⚠ Hỗ trợ cả ExpressRoute lẫn VPN | |
Vì sao các phương án khác sai
-
D (Connection Monitor Classic) — ⚠ bản CŨ đã ngừng; Microsoft đã hợp nhất vào Connection Monitor hiện hành.
-
B (Traffic Analytics) — ⚠ phân tích nhật ký luồng NSG, cho biết ai nói chuyện với ai, không giám sát sức khoẻ đường kết nối.
-
C (VPN Troubleshoot) — ⚠ chẩn đoán VPN gateway MỘT LẦN theo yêu cầu, và dành cho VPN chứ không phải ExpressRoute.
Ghi nhớ
⚠ Bộ công cụ Network Watcher — nhớ theo việc: | Công cụ | Việc | |---|---| | ⚠ Connection Monitor | ⚠ giám sát kết nối LIÊN TỤC, có cảnh báo | | ⚠ Connection Troubleshoot | ⚠ kiểm tra MỘT LẦN theo yêu cầu | | ⚠ IP flow verify | ⚠ luật NSG nào chặn gói này | | ⚠ Next hop | ⚠ gói đi đâu tiếp | | ⚠ Effective security rules | ⚠ tổng hợp luật áp lên card mạng | | ⚠ Packet capture | ⚠ bắt gói phân tích sâu | | ⚠ NSG flow logs | ⚠ nhật ký luồng, phải BẬT trước | | ⚠ Traffic Analytics | ⚠ phân tích nhật ký luồng thành biểu đồ | | ⚠ Topology | ⚠ vẽ sơ đồ tài nguyên mạng |
Từ khoá nhận diện:
"giám sát liên tục, cảnh báo khi xuống cấp" → ⚠ Connection Monitor "kiểm tra một lần xem có thông không" → ⚠ Connection Troubleshoot "ai nói chuyện với ai, lưu lượng đi đâu" → ⚠ Traffic Analytics "luật nào chặn" → ⚠ IP flow verify
| ⚠ Vì sao giám sát ExpressRoute quan trọng | Lý do |
|---|---|
| ⚠ Là đường huyết mạch giữa tại chỗ và đám mây | |
| ⚠ Xuống cấp dần thường không gây lỗi rõ ràng | ⚠ chỉ là chậm hơn |
| ⚠ Cần bằng chứng khi làm việc với nhà cung cấp | |
| ⚠ Có chỉ số riêng trong Azure Monitor | ⚠ băng thông, trạng thái BGP, tính khả dụng |
| ⚠ Thực hành tốt cho kết nối lai | Thực hành |
|---|---|
| ⚠ Connection Monitor cho các đường quan trọng | |
| ⚠ Cảnh báo khi độ trễ hoặc mất gói vượt ngưỡng | |
| ⚠ Có đường dự phòng — VPN sau ExpressRoute | |
| ⚠ Kiểm thử chuyển đổi dự phòng định kỳ |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đường kết nối quan trọng có được giám sát không | | | Cảnh báo có tới đúng người trực không | | | Có số liệu nền để so sánh khi nghi ngờ xuống cấp không | |
Và giá trị lớn nhất của việc giám sát liên tục thay vì kiểm tra một lần: bạn có số liệu nền. Khi ai đó nói "hôm nay mạng chậm", chỉ dữ liệu lịch sử mới trả lời được là chậm thật hay chỉ là cảm giác.
As an Azure Engineer, your current task is to deploy six virtual machines to a vNet subnet. Each virtual machine requires both a public and a private IP address. For every virtual machine, the Network Security Group rules will be the same. Your task is to determine the minimum number of network interfaces required to accomplish this task.
-
A
3
-
B
6
-
C
12
-
D
18
Xem giải thích
Đáp án
B — 6 card mạng.
Vì sao đúng
⚠ Một card mạng mang được cả IP riêng và IP công cộng: | Thành phần | Quan hệ | |---|---| | ⚠ Mỗi card mạng | ⚠ BẮT BUỘC có ít nhất một IP riêng | | ⚠ IP công cộng | ⚠ gắn được vào cấu hình IP của chính card mạng đó | | ⚠ Vì thế mỗi máy ảo | ⚠ chỉ cần MỘT card mạng | | ⚠ Sáu máy ảo | ⚠ sáu card mạng |
⚠ VM → ⚠ NIC → ⚠ IP riêng 10.0.1.4
→ ⚠ IP công cộng 20.x.x.x
⚠ MỘT card mạng, HAI địa chỉ
Vì sao các phương án khác sai
-
C (12) — ⚠ hiểu nhầm rằng cần card mạng riêng cho IP công cộng.
-
A (3) — ⚠ một card mạng KHÔNG dùng chung cho nhiều máy ảo.
-
D (18) — ⚠ không có căn cứ nào.
Ghi nhớ
⚠ Quan hệ giữa VM, NIC và địa chỉ IP: | Quan hệ | Quy tắc | |---|---| | ⚠ VM và NIC | ⚠ một VM có ít nhất một NIC; số NIC tối đa tuỳ CỠ máy | | ⚠ NIC và VM | ⚠ một NIC chỉ gắn với MỘT VM | | ⚠ NIC và IP riêng | ⚠ một NIC có NHIỀU cấu hình IP | | ⚠ IP công cộng và cấu hình IP | ⚠ mỗi cấu hình IP gắn tối đa MỘT IP công cộng | | ⚠ NIC và subnet | ⚠ một NIC nằm trong ĐÚNG MỘT subnet |
⚠ Khi nào mới thật sự cần nhiều NIC: | Kịch bản | Lý do | |---|---| | ⚠ Thiết bị mạng ảo (NVA) | ⚠ một NIC cho mạng trong, một cho mạng ngoài | | ⚠ Tách lưu lượng quản trị và lưu lượng dữ liệu | | | ⚠ Máy phải nằm ở nhiều subnet | | | ⚠ Ứng dụng thông thường | ⚠ MỘT NIC là đủ |
Từ khoá nhận diện:
"vừa IP riêng vừa IP công cộng" → ⚠ một NIC là đủ "nằm ở hai subnet" → ⚠ cần hai NIC "nhiều IP riêng trên một máy" → ⚠ nhiều cấu hình IP trên cùng một NIC "số NIC tối đa" → ⚠ phụ thuộc CỠ máy ảo
| ⚠ Đề nhắc "luật NSG giống nhau cho mọi máy" để làm gì | Ý nghĩa |
|---|---|
| ⚠ Gợi ý gắn NSG ở SUBNET | ⚠ thay vì gắn cho từng card mạng |
| ⚠ Một NSG cho cả subnet | ⚠ ít việc quản lý hơn hẳn |
| ⚠ Thêm máy mới tự thừa hưởng luật | |
| ⚠ Đây là | ⚠ thực hành tốt khi mọi máy cùng vai trò |
| ⚠ Nhưng có nên gán IP công cộng cho cả sáu máy không | Cân nhắc |
|---|---|
| ⚠ Sáu IP công cộng là sáu bề mặt tấn công | |
| ⚠ Tốt hơn: Load Balancer cho chiều vào | |
| ⚠ NAT Gateway cho chiều ra | |
| ⚠ Đề chỉ hỏi | ⚠ số NIC tối thiểu, không hỏi thiết kế có tốt không |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy có thật sự cần IP công cộng riêng không | | | NSG nên gắn ở subnet hay card mạng | | | Cỡ máy có hỗ trợ đủ số NIC cần không | |
Và câu hỏi nên đặt ra khi thấy một thiết kế cấp IP công cộng cho từng máy: có cách nào để chỉ một điểm duy nhất phơi ra Internet không? Load Balancer cho chiều vào và NAT Gateway cho chiều ra thường thay thế được toàn bộ, với bề mặt tấn công nhỏ hơn nhiều.
You are assigned to conduct a security review on a recently launched Azure application. This application is hosted on virtual machines in a virtual network called VNetApp01. The goal is to confirm that the application can only access Azure SQL resources in the East US Azure region. Which outbound rules for the network security group (NSG) must be in place to ensure the application has the correct access? Please select three options.
-
A
The source is VirtualNetwork, the destination is 0.0.0.0/0, and the rule denies access.
-
B
A deny rule with a source of 0.0.0.0/0 and a destination of 0.0.0.0/0.
-
C
A deny rule with the VNetApp01 IP address range as the source and 168.63.129.0/24 as the destination.
-
D
An allow rule with the source IP address range of VNetApp01 and the destination as Sql.EastUS.
Xem giải thích
Đáp án
A, C và D.
- A — Nguồn VirtualNetwork, đích 0.0.0.0/0, hành động Deny.
- C — Luật Deny với nguồn là dải IP của VNetApp01, đích 168.63.129.0/24.
- D — Luật Allow với nguồn là dải IP của VNetApp01, đích là service tag
Sql.EastUS.
Vì sao đúng
⚠ Ba luật hợp thành một bộ "chỉ cho phép đúng một đích": | Luật | Vai trò | |---|---| | ⚠ D — Allow tới Sql.EastUS | ⚠ mở đúng thứ được phép, ưu tiên cao nhất | | ⚠ C — Deny tới 168.63.129.0/24 | ⚠ chặn dải hạ tầng nền tảng | | ⚠ A — Deny tới mọi nơi | ⚠ luật bao quát cuối cùng |
⚠ Thứ tự ưu tiên:
⚠ 1. Allow → Sql.EastUS (ưu tiên nhỏ nhất)
⚠ 2. Deny → 168.63.129.0/24
⚠ 3. Deny → 0.0.0.0/0 (ưu tiên lớn nhất)
⚠ Service tag Sql.EastUS là mấu chốt: ⚠ Microsoft tự duy trì danh sách dải IP của Azure SQL ở East US, ⚠ nên bạn không phải tự cập nhật hàng trăm dải địa chỉ.
Vì sao các phương án khác sai
- B (Deny với nguồn 0.0.0.0/0 và đích 0.0.0.0/0) — ⚠ nguồn quá rộng; luật chiều RA nên lấy nguồn là chính VNet hoặc
VirtualNetwork, không phải mọi nơi trên Internet.
Ghi nhớ
⚠ Service tag — công cụ không thể thiếu khi viết luật: | Service tag | Đại diện cho | |---|---| | ⚠ Internet | ⚠ mọi địa chỉ ngoài VNet và mạng tại chỗ | | ⚠ VirtualNetwork | ⚠ VNet của bạn, mạng peering, mạng tại chỗ đã nối | | ⚠ AzureLoadBalancer | ⚠ hạ tầng thăm dò sức khoẻ | | ⚠ Sql, Sql.EastUS | ⚠ Azure SQL toàn cầu, hoặc riêng một vùng | | ⚠ Storage, Storage.EastUS | | | ⚠ AzureCloud | ⚠ toàn bộ IP công cộng của Azure |
⚠ Tag có hậu tố vùng cho phép giới hạn theo địa lý — đúng yêu cầu của đề.
Từ khoá nhận diện:
"chỉ cho phép tới một dịch vụ Azure ở một vùng" → ⚠ service tag có hậu tố vùng "tự cập nhật dải IP của Azure" → ⚠ service tag "chặn phần còn lại" → ⚠ luật deny bao quát, ưu tiên lớn nhất "lọc theo tên miền" → ⚠ service tag KHÔNG làm được, cần Azure Firewall
| ⚠ Vì sao phải chặn cả 168.63.129.0/24 trong kịch bản này | Lý do |
|---|---|
| ⚠ 168.63.129.16 là kênh liên lạc với nền tảng Azure | |
| ⚠ Trong bài toán cách ly nghiêm ngặt, đây là một lối ra | |
| ⚠ Nhưng lưu ý thực tế | ⚠ chặn nó cũng làm hỏng DNS, health probe và agent |
| ⚠ Vì thế | ⚠ chỉ làm khi thật sự cần cách ly và đã tính tới hậu quả |
| ⚠ Mẫu luật "danh sách trắng" | Mẫu |
|---|---|
| ⚠ Allow những gì được phép, ưu tiên nhỏ | |
| ⚠ Deny mọi thứ còn lại, ưu tiên lớn | |
| ⚠ Không dựa vào luật mặc định cho chiều RA | ⚠ mặc định chiều ra là CHO PHÉP |
| ⚠ Đây là | ⚠ khác biệt lớn giữa chiều vào và chiều ra |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chiều RA có luật deny bao quát chưa | ⚠ mặc định là cho phép ra Internet | | Có dùng service tag thay vì dải IP thủ công không | | | Chặn 168.63.129.0/24 có làm hỏng gì không | ⚠ cân nhắc kỹ |
Và khác biệt quan trọng nhất giữa hai chiều của NSG: chiều vào mặc định CHẶN, chiều ra mặc định CHO PHÉP. Muốn kiểm soát lưu lượng ra thì phải tự viết luật deny bao quát — không có gì làm sẵn cho bạn.
You updated your company’s website after an acquisition while retaining the same FDQN. How can you ensure that old customers are directed to the new URL?
-
A
Multi-site listeners.
-
B
Basic routing.
-
C
SSL termination.
-
D
URL path-based routing.
Xem giải thích
Đáp án
B — Basic routing (định tuyến cơ bản).
Vì sao đúng
⚠ Bài toán: ⚠ giữ nguyên FQDN, nhưng đưa khách truy cập địa chỉ cũ sang địa chỉ mới.
| Tính năng | Vai trò |
|---|---|
| ⚠ Basic routing của Application Gateway | ⚠ quy tắc định tuyến đơn giản, kèm khả năng CHUYỂN HƯỚNG |
| ⚠ Redirect | ⚠ đưa yêu cầu tới URL mới, dùng 301 cho chuyển vĩnh viễn |
| ⚠ Vì FQDN không đổi | ⚠ không cần multi-site listener |
| ⚠ Vì không phân nhánh theo đường dẫn | ⚠ không cần path-based routing |
Vì sao các phương án khác sai
-
D (URL path-based routing) — ⚠ dùng khi cần gửi các ĐƯỜNG DẪN khác nhau tới các nhóm backend khác nhau; ở đây chỉ cần chuyển hướng.
-
A (multi-site listeners) — ⚠ dùng khi phục vụ NHIỀU tên miền trên một gateway; đề nói rõ giữ nguyên FQDN.
-
C (SSL termination) — ⚠ giải mã TLS tại gateway, không liên quan tới chuyển hướng URL.
Ghi nhớ
⚠ Hai kiểu quy tắc định tuyến của Application Gateway: | Kiểu | Dùng khi | |---|---| | ⚠ Basic | ⚠ mọi yêu cầu của listener đi tới CÙNG một backend, hoặc chuyển hướng | | ⚠ Path-based | ⚠ /api sang nhóm A, /images sang nhóm B |
⚠ Chọn mã chuyển hướng cho đúng: | Mã | Nghĩa | |---|---| | ⚠ 301 Moved Permanently | ⚠ chuyển VĨNH VIỄN, công cụ tìm kiếm chuyển thứ hạng | | ⚠ 302 Found | ⚠ tạm thời | | ⚠ 307 và 308 | ⚠ giữ nguyên phương thức HTTP | | ⚠ Đổi địa chỉ sau sáp nhập | ⚠ thường dùng 301 |
Từ khoá nhận diện:
"đưa khách sang URL mới" → ⚠ redirect, cấu hình trong quy tắc định tuyến "nhiều tên miền trên một gateway" → ⚠ multi-site listener "đường dẫn khác nhau tới backend khác nhau" → ⚠ path-based routing "đổi đường dẫn mà URL trên trình duyệt KHÔNG đổi" → ⚠ URL rewrite, khác redirect
| ⚠ Redirect và rewrite — khác nhau căn bản | Khác |
|---|---|
| ⚠ Redirect | ⚠ trình duyệt biết, thanh địa chỉ ĐỔI, thêm một vòng round-trip |
| ⚠ Rewrite | ⚠ xử lý ở phía máy chủ, trình duyệt KHÔNG biết |
| ⚠ Sáp nhập, đổi thương hiệu | ⚠ dùng redirect để khách thấy địa chỉ mới |
| ⚠ Giữ URL đẹp cho người dùng | ⚠ dùng rewrite |
| ⚠ Điều cần lưu ý khi chuyển đổi sau sáp nhập | Điều |
|---|---|
| ⚠ Giữ redirect ĐỦ LÂU | ⚠ ít nhất vài tháng, tốt hơn là một năm |
| ⚠ Redirect cả các đường dẫn con | ⚠ không chỉ trang chủ |
| ⚠ Cập nhật sitemap và liên kết nội bộ | |
| ⚠ 301 bị trình duyệt cache RẤT lâu | ⚠ đặt nhầm rất khó sửa |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Redirect có bảo toàn đường dẫn con không | ⚠ hay chỉ đổ hết về trang chủ | | Mã chuyển hướng là 301 hay 302 | ⚠ quyết định ảnh hưởng SEO | | Có tạo thành chuỗi chuyển hướng nhiều bước không | |
Và lỗi hay gặp nhất khi đổi tên miền: đổ toàn bộ đường dẫn cũ về trang chủ mới. Khách bấm vào một liên kết cũ cụ thể lại rơi vào trang chủ, mất luôn nội dung họ muốn xem — và công cụ tìm kiếm cũng không chuyển được thứ hạng của từng trang.
Four replicas of a multi-tier application are distributed across four resource groups with the following details:
-
Each resource group is located in a different region - East US, West US, West Central US, and South Central US.
-
Each resource group houses a replica of a three-tier application consisting of five VMs: Two front-end VMs, two mid-tier application VMs, and one back-end database VM.
You aim to set up Azure network resources to achieve the following:
-
Direct inbound requests to the application replica based on the user’s location.
-
Establish a front-end firewall for all incoming requests from the internet.
-
Enable communication between resources in different subnets while minimizing the use of public IP addresses.
-
Ensure all traffic between different application layers is encrypted.
-
Balance incoming requests from the public internet and between each tier of the application.
-
Track the performance of each VM in each application tier.
The senior solution architect on the project suggests using Azure Traffic Manager, Azure Load Balancers, and Application Gateway. The senior architect explains how these Azure resources would handle inbound and outbound traffic to meet the stated goals. However, you believe that some of his statements may be incorrect.
Considering the statements below, which ones are accurate? (Select two answers)
-
A
Incoming requests would first reach an Azure Traffic Manager configured for geographic routing, which would deploy the requests to one of four application gateways.
-
B
Traffic would need to be approved by the application gateway before continuing to a public load balancer, which routes traffic to specific front-end VMs.
-
C
Internal load balancers would load-balance traffic between resources without assigning public IP addresses.
-
D
Outgoing response traffic from the front-end VMs would return through the traffic manager before sending it to the external client.
Xem giải thích
Đáp án
A và C.
- A — Yêu cầu vào trước hết tới Azure Traffic Manager cấu hình định tuyến địa lý, rồi phân phối tới một trong bốn application gateway.
- C — Internal load balancer cân bằng tải giữa các tài nguyên mà không cần gán IP công cộng.
Vì sao đúng
⚠ Ba yêu cầu, ba lớp giải pháp: | Yêu cầu | Giải pháp | |---|---| | ⚠ Định tuyến theo VỊ TRÍ người dùng | ⚠ Traffic Manager với geographic routing | | ⚠ Tường lửa ở đầu vào cho mọi yêu cầu từ Internet | ⚠ Application Gateway kèm WAF ở từng vùng | | ⚠ Giao tiếp giữa các subnet, hạn chế phơi ra ngoài | ⚠ internal load balancer, không IP công cộng |
⚠ Người dùng
↓ ⚠ DNS
⚠ Traffic Manager (geographic)
↓
⚠ Application Gateway + WAF ×4 vùng
↓
⚠ Front-end VMs
↓ ⚠ internal load balancer
⚠ Mid-tier VMs
↓ ⚠ internal load balancer
⚠ Database VM
Vì sao các phương án khác sai
-
B (application gateway rồi mới tới public load balancer) — ⚠ thừa một lớp phơi ra Internet; sau gateway nên dùng internal load balancer.
-
D (lưu lượng trả về đi ngược qua Traffic Manager) — ⚠ SAI về nguyên lý: ⚠ Traffic Manager làm việc ở tầng DNS, KHÔNG nằm trên đường đi của gói tin. Sau khi phân giải xong, client kết nối thẳng tới endpoint.
Ghi nhớ
⚠ Traffic Manager KHÔNG phải proxy — điểm này rất hay bị hiểu sai: | Traffic Manager | Front Door | |---|---| | ⚠ Làm việc ở tầng DNS | ⚠ là proxy ngược thật sự | | ⚠ Chỉ trả về địa chỉ | ⚠ lưu lượng ĐI QUA nó | | ⚠ Không thấy lưu lượng | ⚠ thấy và can thiệp được | | ⚠ Mọi giao thức | ⚠ chỉ HTTP/HTTPS | | ⚠ Chuyển đổi phụ thuộc TTL | ⚠ chuyển đổi gần như tức thời |
Từ khoá nhận diện:
"định tuyến theo vị trí người dùng" → ⚠ Traffic Manager geographic, hoặc Front Door "WAF ở đầu vào" → ⚠ Application Gateway hoặc Front Door "cân bằng tải nội bộ, không IP công cộng" → ⚠ internal load balancer "lưu lượng trả về đi qua bộ cân bằng tải" → ⚠ KHÔNG đúng với Traffic Manager
| ⚠ Vì sao dùng internal load balancer cho tầng trong | Lý do |
|---|---|
| ⚠ Không cần IP công cộng | ⚠ giảm bề mặt tấn công |
| ⚠ Chỉ tài nguyên trong VNet gọi được | |
| ⚠ Vẫn có health probe và phân phối tải | |
| ⚠ Nguyên tắc | ⚠ chỉ lớp NGOÀI CÙNG mới nên có IP công cộng |
| ⚠ Kiến trúc đa vùng — điều cần lo thêm | Điều |
|---|---|
| ⚠ Đồng bộ dữ liệu giữa các vùng | ⚠ thường là phần khó nhất |
| ⚠ Chi phí truyền dữ liệu liên vùng | |
| ⚠ Phiên bản ứng dụng phải đồng nhất | |
| ⚠ Kiểm thử chuyển đổi định kỳ |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có lớp nào phơi IP công cộng mà không cần không | | | Dữ liệu giữa bốn vùng đồng bộ thế nào | | | Health probe có phát hiện được lỗi thật của ứng dụng không | |
Và hiểu nhầm phổ biến nhất về Traffic Manager: tưởng lưu lượng đi qua nó. Nó chỉ trả lời một câu hỏi DNS rồi rút lui — mọi byte dữ liệu sau đó đi thẳng từ client tới endpoint, không qua nó lần nào.
You must establish a Hub-and-Spoke network in the US East region between two existing virtual networks, VNet1 and VNet2. This is necessary to facilitate communication between resources in the two networks. However, you cannot use a network virtual appliance for this purpose.
To achieve this, you must deploy a new virtual network, VNet3, in the East US region. VNet3 will act as the network hub, enabling VNet1 and VNet2 to communicate with each other through virtual network gateways.
Now, the question arises: which VNet peering connections should be configured to allow gateway transit?
-
A
All peering connections between the hub and spokes.
-
B
No peering connections.
-
C
Only peering connections directed to VNet3 as the hub.
-
D
Only peering connections directed to VNet1 and VNet2 as the spokes.
Xem giải thích
Đáp án
C — Chỉ các kết nối peering hướng tới VNet3 với vai trò hub.
Vì sao đúng
⚠ "Allow gateway transit" đặt ở phía CÓ gateway — tức là hub: | Cờ | Đặt ở đâu | Nghĩa | |---|---|---| | ⚠ Allow gateway transit | ⚠ VNet3 — HUB, nơi có gateway | ⚠ cho phép spoke dùng gateway của mình | | ⚠ Use remote gateways | ⚠ VNet1 và VNet2 — SPOKE | ⚠ dùng gateway của hub |
⚠ Peering VNet3 → VNet1: ⚠ bật "Allow gateway transit"
⚠ Peering VNet1 → VNet3: ⚠ bật "Use remote gateways"
⚠ (tương tự cho VNet2)
⚠ Nói cách khác: ⚠ cờ transit nằm ở các peering hướng tới hub, đúng như phương án C.
Vì sao các phương án khác sai
-
A (mọi kết nối peering giữa hub và spoke) — ⚠ quá rộng; spoke không có gateway để chia sẻ, bật transit ở đó là vô nghĩa.
-
D (chỉ các peering hướng tới VNet1 và VNet2) — ⚠ NGƯỢC; spoke là bên dùng gateway, không phải bên chia sẻ.
-
B (không cần peering nào) — ⚠ SAI; không có peering thì không có gì kết nối.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #23233 trong lô này cũng dựng hub-and-spoke qua VNet3, nhưng hỏi về "allow forwarded traffic". ⚠ Câu này hỏi về "allow gateway transit". Hai cờ khác nhau, hai mục đích khác nhau — hai câu bổ sung nhau.
| Câu | Cờ được hỏi | Mục đích |
|---|---|---|
| ⚠ #23233 | ⚠ Allow forwarded traffic | ⚠ cho gói ĐI XUYÊN QUA hub |
| ⚠ #23245 (câu này) | ⚠ Allow gateway transit | ⚠ cho spoke DÙNG gateway của hub |
| ⚠ Trong thực tế | ⚠ thường bật cả hai |
⚠ Bốn cờ của một peering — bảng tổng hợp: | Cờ | Đặt ở đâu | |---|---| | ⚠ Allow virtual network access | ⚠ cả hai phía | | ⚠ Allow forwarded traffic | ⚠ phía nhận gói xuyên qua | | ⚠ Allow gateway transit | ⚠ phía CÓ gateway — hub | | ⚠ Use remote gateways | ⚠ phía KHÔNG có gateway — spoke |
Từ khoá nhận diện:
"spoke dùng gateway của hub" → ⚠ gateway transit ở hub, use remote gateways ở spoke "lưu lượng đi xuyên qua VNet trung gian" → ⚠ allow forwarded traffic "spoke này tới spoke kia" → ⚠ thêm UDR trỏ về thiết bị định tuyến ở hub "peering không bắc cầu" → ⚠ nguyên tắc gốc
| ⚠ Lợi ích kinh tế của gateway transit | Lợi ích |
|---|---|
| ⚠ Một gateway phục vụ mọi spoke | |
| ⚠ Gateway là tài nguyên ĐẮT | ⚠ tính tiền theo giờ, SKU cao thì rất tốn |
| ⚠ Mười spoke dùng chung một gateway | ⚠ thay vì mười gateway |
| ⚠ Đây là | ⚠ một trong những lý do chính chọn hub-and-spoke |
| ⚠ Ràng buộc của gateway transit | Ràng buộc |
|---|---|
| ⚠ Spoke KHÔNG được có gateway riêng | ⚠ nếu có thì không bật "use remote gateways" được |
| ⚠ Dải IP không chồng lấn | |
| ⚠ Phải cấu hình ở CẢ hai phía peering |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cờ transit có đặt đúng phía không | ⚠ hub chia sẻ, spoke sử dụng | | Spoke có gateway thừa nào không | ⚠ xoá đi để tiết kiệm | | Mạng tại chỗ có học được tuyến tới spoke không | |
Và cách nhớ hai cờ này cho khỏi lẫn: bên nào CÓ gateway thì "cho phép đi nhờ", bên nào KHÔNG có thì "xin đi nhờ". Đặt ngược lại là cấu hình lưu được nhưng không có tác dụng gì.
Your company has transitioned to a remote working setup and to safeguard the security of the private network hosting business-critical applications, you and your team have been instructed to use a VPN client to access the company network. In case of any issues with VPN connectivity, which tools should you use to monitor it? Please select three options.
-
A
Connection Monitor.
-
B
Network Watcher.
-
C
Network Performance Monitor.
-
D
Traffic Analytics.
Xem giải thích
Đáp án
A, B và D.
- A — Connection Monitor.
- B — Network Watcher.
- D — Traffic Analytics.
Vì sao đúng
⚠ Ba công cụ, ba góc nhìn về cùng một vấn đề: | Công cụ | Vai trò | |---|---| | ⚠ Network Watcher | ⚠ bộ công cụ TỔNG, chứa mọi thứ còn lại | | ⚠ Connection Monitor | ⚠ giám sát liên tục kết nối, đo độ trễ và mất gói | | ⚠ Traffic Analytics | ⚠ phân tích nhật ký luồng: ai kết nối, tới đâu, bị chặn ở đâu |
⚠ Với sự cố VPN, ba công cụ này trả lời ba câu hỏi khác nhau:
⚠ Network Watcher → ⚠ chẩn đoán tại chỗ: luật nào chặn, gói đi đâu
⚠ Connection Monitor → ⚠ đường kết nối có ổn định không, xuống cấp từ khi nào
⚠ Traffic Analytics → ⚠ mẫu lưu lượng bất thường, kết nối bị từ chối
Vì sao các phương án khác sai
- C (Network Performance Monitor) — ⚠ đã NGỪNG; xem ghi chú bên dưới.
Ghi nhớ
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án C — Network Performance Monitor (NPM) ⚠ đã ngừng từ 2024, được thay thế bằng Connection Monitor.
| Công cụ | Tình trạng |
|---|---|
| ⚠ Network Performance Monitor | ⚠ ĐÃ NGỪNG, chuyển sang Connection Monitor |
| ⚠ Connection Monitor (Classic) | ⚠ cũng đã ngừng, hợp nhất vào Connection Monitor |
| ⚠ Connection Monitor | ⚠ công cụ hiện hành |
| ⚠ Khoá A, B, D | ⚠ vẫn ĐÚNG và giữ nguyên — C sai cả về công năng lẫn vòng đời |
| ⚠ Trong lô này | ⚠ #23240 cũng có phương án nhiễu "Connection Monitor (Classic)" |
⚠ Bộ công cụ Network Watcher: | Công cụ | Việc | |---|---| | ⚠ Connection Monitor | ⚠ giám sát liên tục | | ⚠ Connection Troubleshoot | ⚠ kiểm tra một lần | | ⚠ IP flow verify | ⚠ luật nào chặn | | ⚠ Next hop | ⚠ gói đi đâu | | ⚠ Effective security rules | ⚠ tổng hợp luật trên NIC | | ⚠ VPN Troubleshoot | ⚠ chẩn đoán riêng cho gateway | | ⚠ Packet capture | ⚠ bắt gói | | ⚠ NSG flow logs | ⚠ nguồn dữ liệu cho Traffic Analytics |
Từ khoá nhận diện:
"giám sát liên tục có cảnh báo" → ⚠ Connection Monitor "phân tích mẫu lưu lượng" → ⚠ Traffic Analytics "chẩn đoán riêng cho VPN gateway" → ⚠ VPN Troubleshoot "Network Performance Monitor" → ⚠ đã ngừng, đừng chọn trong đề mới
| ⚠ Sự cố VPN thường gặp và nơi tìm nguyên nhân | Sự cố |
|---|---|
| ⚠ Không kết nối được | ⚠ VPN Troubleshoot, kiểm tra chứng chỉ |
| ⚠ Kết nối được nhưng không tới tài nguyên | ⚠ IP flow verify, effective rules |
| ⚠ Kết nối chập chờn | ⚠ Connection Monitor xem lịch sử |
| ⚠ Thêm VNet mới, client không tới được | ⚠ tải lại gói cấu hình client |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | NSG flow logs đã bật chưa | ⚠ Traffic Analytics cần nó mới có dữ liệu | | Có Connection Monitor cho đường VPN không | | | Còn dùng công cụ nào đã ngừng không | ⚠ NPM, Connection Monitor Classic |
Và điều kiện bắt buộc để Traffic Analytics có ích: NSG flow logs phải được bật TRƯỚC. Dữ liệu chỉ có từ lúc bật trở đi — chờ tới khi có sự cố mới đi bật thì đã mất đúng khoảng thời gian cần nhìn lại.
What steps are required to configure the gateway traffic in order to flow from the spoke to the hub and connect to remote networks?
-
A
Configure the hub and spokes to allow for all peering connections.
-
B
Do not permit any peering connections.
-
C
Enable gateway transit in the hub peering connection and configure remote gateways in each spoke peering connection.
-
D
Configure peering connections in the hub to allow gateway transit; in each spoke, use remote gateways and allow all peering connections to forward traffic.
Xem giải thích
Đáp án
D — Cấu hình các peering ở hub để cho phép gateway transit; ở mỗi spoke, dùng remote gateways và cho phép mọi peering chuyển tiếp lưu lượng.
Vì sao đúng
⚠ Để lưu lượng từ spoke đi qua gateway của hub tới mạng từ xa, cần đủ ba mảnh: | Mảnh | Đặt ở đâu | |---|---| | ⚠ Allow gateway transit | ⚠ HUB — nơi có gateway | | ⚠ Use remote gateways | ⚠ SPOKE — bên đi nhờ | | ⚠ Allow forwarded traffic | ⚠ để gói đi xuyên qua được |
⚠ Spoke → ⚠ peering (use remote gateways)
→ ⚠ Hub (allow gateway transit)
→ ⚠ VPN/ExpressRoute gateway
→ ⚠ Mạng từ xa
Vì sao các phương án khác sai
-
C (bật gateway transit ở peering của hub và cấu hình remote gateways ở mỗi peering của spoke) — ⚠ mô tả ĐÚNG hai mảnh đầu nhưng THIẾU mảnh thứ ba là cho phép chuyển tiếp lưu lượng.
-
A (cho phép mọi kết nối peering) — ⚠ quá mơ hồ, không nêu cờ nào.
-
B (không cho phép peering nào) — ⚠ thì không có gì kết nối cả.
Ghi nhớ
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án C và D khác nhau rất ít, và đây là câu thứ BA trong lô về cùng chủ đề cấu hình hub-and-spoke.
| Câu | Hỏi cờ nào | Khoá |
|---|---|---|
| ⚠ #23233 | ⚠ allow forwarded traffic | ⚠ A và B |
| ⚠ #23245 | ⚠ allow gateway transit | ⚠ C — peering hướng tới hub |
| ⚠ #23247 (câu này) | ⚠ cả BA cờ cùng lúc | ⚠ D |
| ⚠ Khác biệt C và D | ⚠ D nêu thêm "cho phép chuyển tiếp lưu lượng" | |
| ⚠ Ba câu | ⚠ nhất quán, giữ nguyên cả ba khoá |
⚠ Bảng tổng hợp bốn cờ — nên thuộc: | Cờ | Hub | Spoke | |---|---|---| | ⚠ Allow virtual network access | ⚠ bật | ⚠ bật | | ⚠ Allow forwarded traffic | ⚠ bật | ⚠ bật | | ⚠ Allow gateway transit | ⚠ BẬT | ⚠ tắt | | ⚠ Use remote gateways | ⚠ tắt | ⚠ BẬT |
Từ khoá nhận diện:
"spoke đi nhờ gateway của hub" → ⚠ transit ở hub, remote gateways ở spoke "gói đi xuyên qua VNet trung gian" → ⚠ allow forwarded traffic "spoke này tới spoke kia" → ⚠ thêm UDR trỏ về NVA hoặc firewall ở hub "spoke đã có gateway riêng" → ⚠ KHÔNG bật use remote gateways được
| ⚠ Vì sao dễ sai ở đây | Lý do |
|---|---|
| ⚠ Bốn cờ, hai phía, dễ đặt nhầm chỗ | |
| ⚠ Cấu hình sai vẫn LƯU được, không báo lỗi | |
| ⚠ Triệu chứng chỉ là "không kết nối được" | |
| ⚠ Công cụ kiểm chứng | ⚠ effective routes của card mạng trong spoke |
| ⚠ Lợi ích thu được | Lợi ích |
|---|---|
| ⚠ Một gateway phục vụ mọi spoke | ⚠ tiết kiệm đáng kể |
| ⚠ Một điểm kết nối tới mạng tại chỗ | |
| ⚠ Thêm spoke mới rất nhanh | |
| ⚠ Kiểm soát và giám sát tập trung ở hub |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bốn cờ có đặt đúng phía không | ⚠ kiểm tra từng peering | | Spoke có thấy tuyến tới mạng tại chỗ không | ⚠ xem effective routes | | Mạng tại chỗ có tuyến ngược lại tới spoke không | ⚠ định tuyến phải thông hai chiều |
Và điều hay bị quên khi dựng gateway transit: định tuyến phải thông cả HAI chiều. Spoke học được đường ra tại chỗ là chưa đủ — mạng tại chỗ cũng phải biết đường quay lại dải địa chỉ của spoke.
What should you configure to allow a virtual application in the East US to communicate with another application in the Central US? Choose two answers.
-
A
Global network peering.
-
B
Security Groups.
-
C
Service chaining.
-
D
Network Security Groups (NSGs)
Xem giải thích
Đáp án
A và D — Global network peering, và Network Security Groups.
Vì sao đúng
⚠ Hai mảnh cần có, ở hai tầng khác nhau: | Mảnh | Vai trò | |---|---| | ⚠ Global VNet peering | ⚠ dựng ĐƯỜNG ĐI giữa hai VNet ở hai vùng khác nhau | | ⚠ NSG cho phép | ⚠ mở CỬA cho lưu lượng đi qua |
⚠ Có đường mà NSG chặn thì vẫn không thông — hai thứ này phải đi cùng nhau.
⚠ VNet East US ← ⚠ global peering qua backbone Microsoft → ⚠ VNet Central US
↓ ⚠ NSG phải cho phép ở cả hai đầu
⚠ Ứng dụng nói chuyện được
Vì sao các phương án khác sai
-
B (Security Groups) — ⚠ tên mơ hồ; trong Azure, nhóm bảo mật của Entra ID dùng cho định danh, không lọc lưu lượng mạng.
-
C (Service chaining) — ⚠ kỹ thuật dùng UDR để đẩy lưu lượng qua NVA; hữu ích nhưng không cần thiết để hai ứng dụng nói chuyện với nhau.
Ghi nhớ
⚠ Hai loại peering: | Loại | Phạm vi | |---|---| | ⚠ VNet peering | ⚠ hai VNet CÙNG vùng | | ⚠ Global VNet peering | ⚠ hai VNet KHÁC vùng | | ⚠ Cả hai | ⚠ đi qua backbone Microsoft, KHÔNG qua Internet |
Từ khoá nhận diện:
"hai vùng khác nhau" → ⚠ global VNet peering "cùng vùng" → ⚠ VNet peering thường "đẩy lưu lượng qua NVA" → ⚠ service chaining bằng UDR "nhóm người dùng" → ⚠ security group của Entra ID, khác hẳn NSG
| ⚠ Điều cần lưu ý với global peering | Điều |
|---|---|
| ⚠ Chi phí cao hơn peering cùng vùng | ⚠ tính theo dữ liệu vào và ra |
| ⚠ Độ trễ phụ thuộc khoảng cách địa lý | ⚠ East US ↔ Central US vẫn có độ trễ thật |
| ⚠ KHÔNG hỗ trợ Basic SKU | ⚠ load balancer nội bộ Basic không tới được |
| ⚠ Dải IP không được chồng lấn |
| ⚠ Service chaining là gì | Nội dung |
|---|---|
| ⚠ Dùng user-defined route đẩy lưu lượng qua một NVA | |
| ⚠ Thường thấy trong hub-and-spoke | ⚠ spoke → firewall ở hub → spoke khác |
| ⚠ Cho phép kiểm tra và ghi nhật ký lưu lượng | |
| ⚠ Không bắt buộc | ⚠ chỉ khi cần kiểm soát tập trung |
| ⚠ Đừng quên NSG khi gỡ lỗi | Lý do |
|---|---|
| ⚠ Peering dựng xong vẫn có thể không thông | |
⚠ Luật mặc định cho phép lưu lượng trong VirtualNetwork |
⚠ và tag này BAO GỒM cả VNet đã peering |
| ⚠ Nhưng luật tự tạo có thể chặn | |
| ⚠ Kiểm tra bằng | ⚠ IP flow verify |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Peering đã Connected ở cả hai phía chưa | | | NSG hai đầu có cho phép không | ⚠ IP flow verify | | Chi phí truyền dữ liệu liên vùng là bao nhiêu | |
Và điều dễ quên nhất khi dựng kết nối mạng trên Azure: có đường đi không có nghĩa là có quyền đi. Peering lo phần định tuyến, NSG lo phần cho phép — thiếu một trong hai thì kết quả giống hệt nhau: không kết nối được.