Ngân hàng đề Microsoft Azure Networking

Câu 1 Chọn nhiều đáp án Design, implement, and manage connectivity services (20–25%)

Virtual network peering lets you connect Azure VNets using the Azure backbone network. However, there are specific requirements and limitations associated with VNet peering. Select the appropriate requirements and limitations from the list below. (Select all that apply)

A
It is only possible to peer Vnets present in the same region using Vnet peering. Peering Vnets from different regions is not allowed.
B
In a globally peered VNet, resources in one VNet cannot communicate with the front-end IP addresses of a Basic internal load balancer.
C
The Vnets involved in peering must have non-overlapping IP address spaces.
D
You can modify a Vnet's address space by adding or deleting address ranges after it is peered with another Vnet.
E
You can use default Azure name resolution to resolve names in Vnets that are peered with each other.

Xem giải thích

Đáp án

B và C.

B — Trong VNet peering toàn cầu, tài nguyên ở một VNet KHÔNG giao tiếp được với địa chỉ IP front-end của Basic internal load balancer.
C — Các VNet tham gia peering phải có dải địa chỉ IP KHÔNG chồng lấn.

Vì sao đúng

⚠ Hai giới hạn này là điều bắt buộc phải nhớ khi thiết kế peering: | Giới hạn | Nội dung | |---|---| | ⚠ Dải IP không được chồng lấn | ⚠ Azure từ chối tạo peering nếu chồng — không có NAT ở giữa | | ⚠ Global peering không hỗ trợ Basic SKU | ⚠ Basic internal load balancer, và một số dịch vụ dùng Basic SKU |

⚠ VNet A: 10.0.0.0/16   ⚠ VNet B: 10.0.0.0/16  →  ⚠ TỪ CHỐI, chồng lấn
⚠ VNet A: 10.0.0.0/16   ⚠ VNet B: 10.1.0.0/16  →  ⚠ OK

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

A (chỉ peer được VNet trong cùng vùng) — ⚠ SAI; global VNet peering nối được VNet ở các vùng khác nhau, kể cả khác đám mây Azure trong một số trường hợp.
D (sửa được dải địa chỉ sau khi đã peering) — ⚠ có điều kiện; ngày nay Azure cho thêm hoặc bớt dải địa chỉ mà không phải xoá peering, nhưng đây không phải một "yêu cầu và giới hạn" đúng như đề liệt kê.
E (dùng phân giải tên mặc định của Azure để phân giải tên giữa các VNet đã peering) — ⚠ SAI; ⚠ DNS mặc định của Azure KHÔNG phân giải chéo giữa các VNet. Phải dùng Azure Private DNS zone liên kết với cả hai VNet, hoặc DNS server tự dựng.

Ghi nhớ

⚠ Hai loại peering: | Loại | Phạm vi | |---|---| | ⚠ VNet peering | ⚠ cùng một vùng | | ⚠ Global VNet peering | ⚠ khác vùng, vẫn đi qua backbone của Microsoft |

⚠ Đặc tính của peering: | Đặc tính | Nội dung | |---|---| | ⚠ Độ trễ thấp, băng thông cao | ⚠ đi qua backbone, KHÔNG qua Internet công cộng | | ⚠ Không cần gateway | ⚠ trừ khi dùng gateway transit | | ⚠ KHÔNG bắc cầu | ⚠ A–B và B–C KHÔNG cho A nói chuyện với C | | ⚠ Tính phí theo dữ liệu vào và ra | | | ⚠ Peering phải thiết lập ở CẢ HAI phía | ⚠ một phía thôi thì trạng thái là Initiated |

Từ khoá nhận diện:

"dải IP chồng lấn" → ⚠ peering KHÔNG tạo được "A nối B, B nối C, A có nói chuyện được với C không" → ⚠ KHÔNG, peering không bắc cầu "phân giải tên giữa các VNet" → ⚠ Private DNS zone, không phải DNS mặc định "dùng chung gateway VPN của VNet hub" → ⚠ gateway transit

⚠ Vì sao peering không bắc cầu lại quan trọng	Lý do
⚠ Kiến trúc hub-and-spoke cần định tuyến qua hub
⚠ Phải dùng user-defined route trỏ về NVA hoặc Azure Firewall ở hub
⚠ Hoặc dùng Azure Virtual WAN	⚠ quản lý định tuyến giúp bạn
⚠ Nếu quên	⚠ spoke này không tới được spoke kia dù cả hai đều peering với hub

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kế hoạch địa chỉ IP có chồng lấn ở đâu không | ⚠ lập bảng trước khi tạo VNet | | Peering đã ở trạng thái Connected ở CẢ hai phía chưa | | | Có dịch vụ nào còn dùng Basic SKU không | ⚠ Basic đã ngừng từ 9/2025 |

Và lỗi thiết kế tốn kém nhất trong mạng Azure: không lập kế hoạch dải địa chỉ IP từ đầu. Hai VNet chồng dải thì không peering được, và sửa nghĩa là dựng lại toàn bộ tài nguyên trong một trong hai mạng.

Câu 2 Design, implement, and manage connectivity services (20–25%)

What server type is required to authenticate a user who connects via a point-to-site (P2S) connection using an Active Directory Domain Server?

A
DNS server
B
Active Directory Domain Controller only
C
DIAMETER Server
D
RADIUS Server
E
None of these

Xem giải thích

Đáp án

D — Máy chủ RADIUS.

Vì sao đúng

⚠ Point-to-Site có ba cách xác thực, và cách dùng AD tại chỗ đi qua RADIUS: | Cách xác thực | Cơ chế | |---|---| | ⚠ Chứng chỉ Azure | ⚠ chứng chỉ gốc tải lên gateway, chứng chỉ con cấp cho máy khách | | ⚠ Microsoft Entra ID | ⚠ chỉ cho OpenVPN, có MFA và Conditional Access | | ⚠ RADIUS | ⚠ cầu nối tới Active Directory Domain Services tại chỗ |

⚠ Máy khách VPN
        ↓
⚠ VPN Gateway  →  ⚠ chuyển yêu cầu xác thực
        ↓
⚠ Máy chủ RADIUS (ví dụ NPS trên Windows Server)
        ↓
⚠ Active Directory Domain Controller

⚠ Gateway KHÔNG nói chuyện trực tiếp với domain controller — nó chỉ nói giao thức RADIUS.

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

B (chỉ cần domain controller) — ⚠ THIẾU; phải có RADIUS đứng giữa, thường là vai trò NPS — Network Policy Server.
A (DNS server) — ⚠ phân giải tên, không xác thực.
C (DIAMETER server) — ⚠ giao thức kế nhiệm RADIUS trong viễn thông, Azure VPN Gateway không hỗ trợ.
E (không phương án nào) — ⚠ sai vì D đúng.

Ghi nhớ

⚠ Ba giao thức đường hầm của P2S: | Giao thức | Nền tảng | Ghi chú | |---|---|---| | ⚠ OpenVPN (SSL/TLS) | ⚠ Windows, macOS, Linux, iOS, Android | ⚠ linh hoạt nhất, cần cho xác thực Entra ID | | ⚠ SSTP (SSL) | ⚠ CHỈ Windows | ⚠ qua được tường lửa vì dùng cổng 443 | | ⚠ IKEv2 (IPsec) | ⚠ Windows, macOS, Linux | ⚠ giải pháp VPN chuẩn |

Từ khoá nhận diện:

"xác thực bằng AD tại chỗ" → ⚠ RADIUS "xác thực bằng tài khoản đám mây, có MFA" → ⚠ Entra ID, bắt buộc OpenVPN "chứng chỉ gốc và chứng chỉ con" → ⚠ certificate authentication "chỉ chạy trên Windows" → ⚠ SSTP

⚠ Point-to-Site và Site-to-Site — phân biệt	Khác
⚠ P2S	⚠ MỘT máy tính nối vào VNet, cho người làm từ xa
⚠ S2S	⚠ cả MẠNG tại chỗ nối vào, cần thiết bị VPN ở đầu kia
⚠ P2S	⚠ không cần thiết bị VPN, không cần IP tĩnh công cộng
⚠ S2S	⚠ luôn bật, phù hợp cho kết nối cố định

⚠ Điều cần chuẩn bị cho P2S	Điều
⚠ GatewaySubnet trong VNet	⚠ tên phải đúng như vậy
⚠ VPN Gateway SKU hỗ trợ P2S	⚠ Basic rất hạn chế
⚠ Dải địa chỉ cho máy khách	⚠ KHÔNG được chồng với dải của VNet
⚠ Cấu hình máy khách tải từ Portal

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dải IP cấp cho máy khách có chồng với VNet không | | | Có cần MFA cho người dùng từ xa không | ⚠ nếu có thì phải Entra ID kèm OpenVPN | | Máy chủ RADIUS có sẵn sàng cao không | ⚠ nó chết là không ai đăng nhập được |

Và điểm hỏng đơn lẻ hay bị bỏ quên trong kiến trúc P2S dùng RADIUS: chính máy chủ RADIUS. Gateway có thể dư thừa hoàn hảo, nhưng nếu chỉ có một NPS thì nó hỏng là toàn bộ người dùng từ xa mất đường vào.

Câu 3 Design, implement, and manage connectivity services (20–25%)

An ExpressRoute circuit can be associated with multiple peerings or routing domains. One of these peerings has the following characteristics:

It supports any valid IP address within your WAN range.
It supports both IPv4 and IPv6 (in preview mode).
It supports MD5 hashing.

A
Private Peering
B
Public Peering
C
Microsoft Peering
D
None of the above

Xem giải thích

Đáp án

A — Private Peering (peering riêng).

Vì sao đúng

⚠ Ba loại peering của ExpressRoute: | Loại | Nối tới | Địa chỉ | |---|---|---| | ⚠ Private Peering | ⚠ mạng ảo của bạn trên Azure | ⚠ IP riêng trong dải WAN của bạn | | ⚠ Microsoft Peering | ⚠ dịch vụ công cộng của Microsoft | ⚠ IP công cộng, cần ASN và tiền tố đã đăng ký | | ⚠ Public Peering | ⚠ bản CŨ của Microsoft Peering | ⚠ không còn tạo mới |

⚠ Đặc điểm đề nêu khớp với Private Peering: | Đặc điểm | Nội dung | |---|---| | ⚠ Chấp nhận mọi IP hợp lệ trong dải WAN của bạn | ⚠ không cần IP công cộng đã đăng ký | | ⚠ Hỗ trợ IPv4 và IPv6 | | | ⚠ Hỗ trợ băm MD5 cho phiên BGP | |

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

C (Microsoft Peering) — ⚠ yêu cầu IP CÔNG CỘNG đã đăng ký và số AS hợp lệ, không nhận IP riêng tuỳ ý.
B (Public Peering) — ⚠ là loại CŨ đã bị thay thế bởi Microsoft Peering; Azure không cho tạo mới từ nhiều năm nay.
D (không phương án nào) — ⚠ sai vì A đúng.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án B — Public Peering là một loại peering đã ngừng nhận cấu hình mới; Microsoft đã thay nó bằng Microsoft Peering. ⚠ Khoá đáp án A vẫn ĐÚNG và giữ nguyên — chỉ cần biết rằng B là một khái niệm lịch sử vẫn còn xuất hiện trong đề cũ.

⚠ ExpressRoute so với VPN Site-to-Site: | Tiêu chí | ExpressRoute | VPN S2S | |---|---|---| | ⚠ Đường đi | ⚠ kết nối RIÊNG, không qua Internet | ⚠ qua Internet công cộng | | ⚠ Băng thông | ⚠ tới 100 Gbps | ⚠ thường tới khoảng 10 Gbps | | ⚠ Độ trễ | ⚠ ổn định, cam kết được | ⚠ phụ thuộc Internet | | ⚠ Mã hoá | ⚠ KHÔNG tự mã hoá | ⚠ IPsec sẵn có | | ⚠ Chi phí | ⚠ cao | ⚠ thấp | | ⚠ SLA | ⚠ 99,95% cho circuit | |

Từ khoá nhận diện:

"IP riêng, nối tới VNet" → ⚠ Private Peering "IP công cộng, nối tới Microsoft 365 và dịch vụ PaaS" → ⚠ Microsoft Peering "không qua Internet, băng thông cao" → ⚠ ExpressRoute "cần mã hoá trên ExpressRoute" → ⚠ chạy VPN IPsec bên trong, hoặc MACsec ở tầng 2

⚠ Vài khái niệm ExpressRoute hay hỏi	Khái niệm
⚠ Circuit	⚠ kết nối logic qua nhà cung cấp
⚠ Peering location	⚠ nơi đấu nối vật lý, KHÁC với vùng Azure
⚠ ExpressRoute Global Reach	⚠ nối hai site tại chỗ với nhau qua backbone Microsoft
⚠ ExpressRoute Direct	⚠ đấu thẳng vào backbone, 10 hoặc 100 Gbps
⚠ FastPath	⚠ bỏ qua gateway để giảm độ trễ

⚠ Thực hành tốt cho kết nối lai	Thực hành
⚠ ExpressRoute chính, VPN S2S làm dự phòng
⚠ Hai circuit ở hai peering location khác nhau	⚠ nếu cần độ tin cậy cao nhất
⚠ Thêm mã hoá nếu dữ liệu nhạy cảm	⚠ ExpressRoute không tự mã hoá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có đường dự phòng khi circuit chính hỏng không | | | Dữ liệu đi qua có cần mã hoá không | | | Peering location có đủ gần trung tâm dữ liệu của bạn không | |

Và hiểu nhầm hay gặp nhất về ExpressRoute: tưởng rằng "kết nối riêng" đồng nghĩa với "được mã hoá". Nó riêng về mặt đường truyền, nhưng dữ liệu vẫn đi ở dạng rõ nếu bạn không tự thêm lớp mã hoá.

Câu 4 Design and implement application delivery services (20–25%)

Your boss has tasked you to configure an Azure Basic Load Balancer. You need to send the probes every 4 seconds, and a virtual machine (VM) should be marked as down or unhealthy after two consecutive probe failures.

Which setting should you choose?

A
Interval = 4
B
Interval= 2
C
Protocol = TCP
D
Hop limit = 4

Xem giải thích

Đáp án

A — Interval = 4.

Vì sao đúng

⚠ Health probe của Load Balancer có hai thông số chính: | Thông số | Ý nghĩa | |---|---| | ⚠ Interval | ⚠ bao lâu thăm dò một lần, tính bằng GIÂY | | ⚠ Unhealthy threshold | ⚠ bao nhiêu lần hỏng LIÊN TIẾP thì đánh dấu là chết |

⚠ Đề yêu cầu thăm dò mỗi 4 giây → ⚠ Interval = 4. ⚠ Đánh dấu chết sau 2 lần hỏng liên tiếp → ⚠ đó là unhealthy threshold = 2, một thông số khác.

⚠ Thời gian phát hiện máy chết ≈ Interval × Threshold
   ⚠ 4 giây × 2 lần = ⚠ khoảng 8 giây

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

B (Interval = 2) — ⚠ nhầm số 2 của ngưỡng sang thông số chu kỳ.
C (Protocol = TCP) — ⚠ là loại thăm dò, không phải chu kỳ.
D (Hop limit = 4) — ⚠ không phải thông số của health probe.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề nhắc tới Azure Basic Load Balancer, mà SKU Basic của Load Balancer đã NGỪNG từ 30/09/2025. ⚠ Khoá đáp án A vẫn ĐÚNG và giữ nguyên — cách tính Interval không đổi ở SKU Standard; chỉ cần biết rằng hệ thống mới phải dùng Standard SKU.

SKU	Tình trạng
⚠ Basic Load Balancer	⚠ ĐÃ NGỪNG từ 30/09/2025
⚠ Standard Load Balancer	⚠ SKU dùng hiện nay
⚠ Basic thiếu gì	⚠ không có Availability Zones, không có SLA, không tích hợp NSG mặc định
⚠ Trong lô 172 cũng gặp	⚠ #23179 nhắc Basic internal load balancer trong giới hạn global peering

⚠ Ba loại health probe: | Loại | Cách kiểm tra | |---|---| | ⚠ TCP | ⚠ bắt tay ba bước tới cổng chỉ định | | ⚠ HTTP | ⚠ gọi một đường dẫn, chờ mã 200 | | ⚠ HTTPS | ⚠ như HTTP nhưng có TLS | | ⚠ Nên dùng | ⚠ HTTP tới endpoint kiểm tra sức khoẻ thật của ứng dụng |

Từ khoá nhận diện:

"bao lâu thăm dò một lần" → ⚠ Interval "bao nhiêu lần hỏng thì loại" → ⚠ unhealthy threshold "thăm dò tới đường dẫn nào" → ⚠ probe path, chỉ có ở HTTP/HTTPS "phát hiện nhanh hơn" → ⚠ giảm interval, nhưng tăng tải lên máy

⚠ Đặt probe cho đúng	Nguyên tắc
⚠ Probe tới endpoint NHẸ, chuyên để kiểm tra sức khoẻ
⚠ Endpoint đó nên kiểm tra cả phụ thuộc quan trọng	⚠ ví dụ CSDL
⚠ Đừng probe trang chủ nặng	⚠ tốn tài nguyên vô ích
⚠ Đừng đặt interval quá ngắn	⚠ probe cũng là tải

⚠ Hậu quả khi probe sai	Hậu quả
⚠ Probe quá dễ dãi	⚠ máy hỏng vẫn nhận lưu lượng, người dùng gặp lỗi
⚠ Probe quá nghiêm	⚠ máy tốt bị loại oan, giảm công suất
⚠ Cả hai	⚠ đều biểu hiện thành lỗi ngắt quãng rất khó lần

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Probe đang trỏ tới endpoint nào | | | Endpoint đó có kiểm tra phụ thuộc quan trọng không | | | Còn tài nguyên nào dùng Basic SKU không | ⚠ đã ngừng, cần chuyển sang Standard |

Và thứ quyết định chất lượng của một bộ cân bằng tải không phải thuật toán phân phối, mà là health probe. Probe sai thì lưu lượng vẫn được gửi tới máy đã chết, và triệu chứng là lỗi ngắt quãng — kiểu lỗi tốn thời gian gỡ nhất.

Câu 5 Design and implement application delivery services (20–25%)

You are a network engineer and want to set unique monitoring settings for various endpoints in Azure Traffic Manager. Is it possible? (Select the best option)

A
No
B
No, it needs to use multiple instances of Traffic Manager.
C
Yes, automatically, the system provides different monitoring settings for different endpoints.
D
Yes, choose the monitoring protocol as TCP.
E
Yes, you need to use nested Traffic Manager profiles.

Xem giải thích

Đáp án

E — Có, bạn cần dùng profile Traffic Manager LỒNG NHAU (nested profiles).

Vì sao đúng

⚠ Cấu hình giám sát của Traffic Manager đặt ở cấp PROFILE, không đặt cho từng endpoint: | Thiết lập ở cấp profile | Nội dung | |---|---| | ⚠ Giao thức | ⚠ HTTP, HTTPS, TCP | | ⚠ Cổng | | | ⚠ Đường dẫn | ⚠ ví dụ /health | | ⚠ Khoảng thăm dò và số lần cho phép hỏng | |

⚠ Muốn endpoint A và endpoint B có cấu hình giám sát khác nhau:

⚠ Profile cha
   ├── ⚠ Endpoint thường
   └── ⚠ Profile con (nested)  →  ⚠ cấu hình giám sát RIÊNG
                                   └── ⚠ các endpoint của nó

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

A (Không) và B (Không, phải dùng nhiều instance) — ⚠ làm được, và nested profile chính là cơ chế chính thức.
C (Có, hệ thống tự động cho cấu hình khác nhau) — ⚠ SAI; không có gì tự động cả.
D (Có, chọn giao thức giám sát là TCP) — ⚠ đổi giao thức vẫn là đổi cho CẢ profile, không tách riêng từng endpoint.

Ghi nhớ

⚠ Traffic Manager là bộ cân bằng tải ở tầng DNS: | Đặc điểm | Nội dung | |---|---| | ⚠ Hoạt động bằng DNS | ⚠ trả về địa chỉ của endpoint phù hợp | | ⚠ KHÔNG nhìn thấy lưu lượng | ⚠ client kết nối THẲNG tới endpoint | | ⚠ Phạm vi toàn cầu | | | ⚠ Nối được cả endpoint ngoài Azure | | | ⚠ Hệ quả | ⚠ chuyển đổi dự phòng phụ thuộc TTL của DNS, không tức thời |

⚠ Sáu phương pháp định tuyến: | Phương pháp | Nội dung | |---|---| | ⚠ Priority | ⚠ chính và dự phòng | | ⚠ Weighted | ⚠ chia theo tỷ lệ | | ⚠ Performance | ⚠ endpoint có độ trễ thấp nhất | | ⚠ Geographic | ⚠ theo vị trí địa lý của người dùng | | ⚠ MultiValue | ⚠ trả về nhiều địa chỉ cùng lúc | | ⚠ Subnet | ⚠ theo dải IP của người dùng |

Từ khoá nhận diện:

"cấu hình giám sát riêng cho từng endpoint" → ⚠ nested profile "định tuyến toàn cầu bằng DNS" → ⚠ Traffic Manager "toàn cầu, tầng 7, có cache và WAF" → ⚠ Front Door "trong một vùng, tầng 7" → ⚠ Application Gateway

⚠ Nested profile còn dùng để làm gì	Việc
⚠ Kết hợp nhiều phương pháp định tuyến	⚠ ví dụ Performance ở cha, Weighted ở con
⚠ Đặt ngưỡng sức khoẻ tối thiểu cho một nhóm endpoint
⚠ Vượt giới hạn số endpoint của một profile
⚠ Cấu hình giám sát riêng theo nhóm

⚠ Traffic Manager và Front Door — chọn cái nào	Chọn
⚠ Traffic Manager	⚠ DNS, mọi giao thức, kể cả endpoint ngoài Azure
⚠ Front Door	⚠ HTTP/HTTPS, có cache, WAF, dừng TLS ở biên
⚠ Chuyển đổi dự phòng	⚠ Front Door nhanh hơn vì không phụ thuộc TTL DNS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | TTL của bản ghi DNS đang đặt bao nhiêu | ⚠ quyết định tốc độ chuyển đổi dự phòng | | Endpoint có endpoint kiểm tra sức khoẻ riêng không | | | Lưu lượng có phải HTTP không | ⚠ nếu có thì Front Door thường phù hợp hơn |

Và giới hạn cốt lõi của mọi giải pháp cân bằng tải bằng DNS: client vẫn nhớ kết quả phân giải cũ cho tới khi TTL hết hạn. Endpoint đã chết vẫn có người gõ vào trong vài phút sau khi Traffic Manager đã chuyển hướng.

Câu 6 Design and implement application delivery services (20–25%)

As an Azure network engineer, your responsibility is to configure caching in Azure Front Door for an organization that offers online services to its customers. You are required to establish a cache expiration policy that ensures timely content updates for customers while minimizing the risk of serving stale content. In this scenario, what would be a key factor to consider when setting up cache expiration policies in Azure Front Door?

A
The size of the content being cached
B
The location of the origin server
C
The expected frequency of content updates
D
The number of end users accessing the content

Xem giải thích

Đáp án

C — Tần suất dự kiến của việc cập nhật nội dung.

Vì sao đúng

⚠ Thời gian sống của bộ nhớ đệm là một ĐÁNH ĐỔI: | TTL | Được | Mất | |---|---|---| | ⚠ Dài | ⚠ ít gọi về origin, nhanh, rẻ | ⚠ rủi ro phục vụ nội dung CŨ | | ⚠ Ngắn | ⚠ nội dung luôn mới | ⚠ tải về origin cao, chậm hơn |

⚠ Nội dung đổi bao lâu một lần chính là yếu tố quyết định TTL: | Loại nội dung | TTL hợp lý | |---|---| | ⚠ Tệp tĩnh có mã băm trong tên | ⚠ rất dài, hàng năm | | ⚠ Ảnh, CSS, JS thông thường | ⚠ hàng giờ tới hàng ngày | | ⚠ Trang danh mục sản phẩm | ⚠ vài phút | | ⚠ Dữ liệu cá nhân hoá | ⚠ KHÔNG cache |

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

A (kích thước nội dung) — ⚠ ảnh hưởng tới chi phí lưu và băng thông, không quyết định thời điểm nội dung trở nên cũ.
B (vị trí máy chủ gốc) — ⚠ ảnh hưởng độ trễ khi cache trượt, không quyết định TTL.
D (số người dùng truy cập) — ⚠ ảnh hưởng tỷ lệ trúng cache, không quyết định nội dung cũ hay mới.

Ghi nhớ

⚠ Cách kiểm soát cache của Front Door: | Cơ chế | Nội dung | |---|---| | ⚠ Header Cache-Control từ origin | ⚠ nguồn sự thật mặc định | | ⚠ Rules Engine | ⚠ ghi đè TTL theo đường dẫn, phần mở rộng, điều kiện | | ⚠ Query string caching | ⚠ bỏ qua, hoặc cache riêng theo chuỗi truy vấn | | ⚠ Purge | ⚠ xoá cache thủ công khi vừa xuất bản nội dung mới | | ⚠ Cache compression | ⚠ nén nội dung ở biên |

Từ khoá nhận diện:

"bao lâu nội dung đổi một lần" → ⚠ yếu tố quyết định TTL "vừa xuất bản, muốn thấy ngay" → ⚠ purge cache "nội dung không bao giờ đổi" → ⚠ đặt TTL rất dài, dùng tên tệp có mã băm "nội dung riêng cho từng người" → ⚠ KHÔNG được cache

⚠ Kỹ thuật vừa cache lâu vừa cập nhật ngay	Kỹ thuật
⚠ Cache busting	⚠ nhúng mã băm vào tên tệp — `app.a1b2c3.js`
⚠ Tệp mới có tên mới	⚠ cache cũ trở nên vô hại
⚠ Không cần purge, không cần TTL ngắn
⚠ Đây là	⚠ thực hành chuẩn cho tài nguyên tĩnh của web hiện đại

⚠ Rủi ro thật khi cache sai	Rủi ro
⚠ Người dùng thấy giá cũ, tin cũ
⚠ Cache nhầm nội dung cá nhân hoá	⚠ NGHIÊM TRỌNG — người này thấy dữ liệu người kia
⚠ Cache nhầm phản hồi lỗi	⚠ lỗi tạm thời thành lỗi kéo dài
⚠ Vì thế	⚠ nội dung có xác thực phải đánh dấu không cache rõ ràng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Origin có gửi Cache-Control rõ ràng không | ⚠ đừng phó mặc cho mặc định | | Có nội dung cá nhân hoá nào đang bị cache không | ⚠ kiểm tra kỹ nhất chỗ này | | Quy trình xuất bản có bước purge chưa | |

Và lỗi cache nguy hiểm nhất không phải là nội dung cũ, mà là cache nhầm nội dung riêng của một người rồi phục vụ cho người khác. Mọi phản hồi phía sau xác thực đều phải được đánh dấu không cache một cách tường minh.

Câu 7 Design and implement application delivery services (20–25%)

As an Azure consultant, you have been tasked with providing a proposal to a company that wishes to move its on-premises web application to the cloud. The application has a complex URL structure with various parameters used for different functionalities. The company is concerned about handling the URLs during the migration and wants to ensure that users can access the application using the old URLs for some time after the migration. Which type of URL redirect would you suggest using in Azure Front Door to ensure that the target resource has been assigned a new permanent URI, and any future references to this resource will use one of the enclosed URIs?

A
302 (Found)
B
303 (see other)
C
307 (Temporary Redirect)
D
301 (Moved permanently)

Xem giải thích

Đáp án

D — 301 (Moved Permanently).

Vì sao đúng

⚠ 301 nghĩa là tài nguyên đã chuyển VĨNH VIỄN sang URI mới: | Hệ quả của 301 | Nội dung | |---|---| | ⚠ Trình duyệt GHI NHỚ và tự chuyển hướng lần sau | ⚠ không hỏi lại máy chủ | | ⚠ Công cụ tìm kiếm CHUYỂN thứ hạng sang URL mới | ⚠ giữ được giá trị SEO | | ⚠ Mọi tham chiếu tương lai nên dùng URI mới | | | ⚠ Đúng với yêu cầu đề bài | ⚠ URL cũ vẫn dùng được một thời gian sau khi chuyển |

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

⚠ Ba phương án còn lại đều là chuyển hướng TẠM THỜI: | Mã | Nghĩa | |---|---| | ⚠ A — 302 Found | ⚠ tạm thời, trình duyệt vẫn hỏi lại URL cũ lần sau | | ⚠ B — 303 See Other | ⚠ tạm thời, ép đổi sang phương thức GET | | ⚠ C — 307 Temporary Redirect | ⚠ tạm thời, GIỮ NGUYÊN phương thức HTTP |

⚠ Dùng 302 cho một lần chuyển vĩnh viễn sẽ khiến công cụ tìm kiếm giữ URL cũ và không chuyển thứ hạng.

Ghi nhớ

⚠ Bảng mã chuyển hướng — nhớ theo cặp: | Mã | Vĩnh viễn hay tạm | Phương thức | |---|---|---| | ⚠ 301 | ⚠ vĩnh viễn | ⚠ có thể đổi sang GET | | ⚠ 308 | ⚠ vĩnh viễn | ⚠ GIỮ NGUYÊN | | ⚠ 302 | ⚠ tạm thời | ⚠ có thể đổi sang GET | | ⚠ 307 | ⚠ tạm thời | ⚠ GIỮ NGUYÊN | | ⚠ Mẹo | ⚠ 30x có số 7 và 8 là loại GIỮ NGUYÊN phương thức |

⚠ Khả năng chuyển hướng của Azure Front Door: | Đổi được gì | Ví dụ | |---|---| | ⚠ Giao thức | ⚠ HTTP sang HTTPS | | ⚠ Tên miền | ⚠ cũ sang mới | | ⚠ Đường dẫn | | | ⚠ Chuỗi truy vấn | | | ⚠ Mảnh neo | ⚠ fragment |

Từ khoá nhận diện:

"chuyển vĩnh viễn, giữ SEO" → ⚠ 301 "tạm thời, sẽ quay lại URL cũ" → ⚠ 302 hoặc 307 "giữ nguyên phương thức POST" → ⚠ 307 hoặc 308 "viết lại đường dẫn mà KHÔNG đổi URL trên trình duyệt" → ⚠ URL rewrite, khác hẳn redirect

⚠ Redirect và rewrite — khác nhau căn bản	Khác
⚠ Redirect	⚠ trình duyệt NHÌN THẤY, thanh địa chỉ ĐỔI, thêm một vòng round-trip
⚠ Rewrite	⚠ xảy ra ở phía máy chủ, trình duyệt KHÔNG biết
⚠ Muốn giữ URL đẹp cho người dùng	⚠ dùng rewrite
⚠ Muốn chuyển hẳn sang địa chỉ mới	⚠ dùng redirect

⚠ Rủi ro của 301	Rủi ro
⚠ Trình duyệt CACHE rất lâu	⚠ đặt nhầm là người dùng kẹt ở URL sai
⚠ Khó rút lại	⚠ phải chờ cache của từng trình duyệt hết hạn
⚠ Vì thế	⚠ khi còn chưa chắc, dùng 302 trước

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chuyển hướng này là vĩnh viễn hay tạm thời | ⚠ chọn sai mã là rất khó sửa | | Có tạo thành chuỗi chuyển hướng nhiều bước không | ⚠ mỗi bước thêm một vòng round-trip | | POST có cần giữ nguyên phương thức không | ⚠ nếu có thì phải 307 hoặc 308 |

Và lý do nên thận trọng với 301: trình duyệt ghi nhớ nó rất lâu, đôi khi cho tới khi người dùng xoá dữ liệu duyệt web. Đặt nhầm một 301 lên trang chủ là một sự cố rất khó chữa từ phía máy chủ.

Câu 8 Chọn nhiều đáp án Design and implement application delivery services (20–25%)

Azure Application Gateway and Azure Front Door are two different load-balancing solutions. Which of the following statements rightly differentiates Azure Application Gateway and Front Door? (Choose all that are applicable)

A
Azure Application Gateway is a layer 7 load balancer, while Azure Front Door is a layer 3 load balancer.
B
Azure Application Gateway is a layer 7 load balancer, whereas Azure Front Door is a layer 7 load balancer.
C
Azure Front Door is a global service, whereas the Azure Application Gateway is a regional service.
D
Azure Front Door is a regional service, while Azure Application Gateway is global.
E
Front Door can be used for load balancing between your various scale units, stamp units, and clusters across regions. The Application Gateway can be used for load balancing between your Virtual Machines and containers within the scale unit.

Xem giải thích

Đáp án

C và E.

C — Azure Front Door là dịch vụ TOÀN CẦU, còn Application Gateway là dịch vụ theo VÙNG.
E — Front Door dùng để cân bằng tải giữa các scale unit, stamp unit và cụm ở NHIỀU VÙNG; Application Gateway dùng để cân bằng tải giữa các máy ảo, container trong MỘT mạng ảo.

Vì sao đúng

⚠ Khác biệt cốt lõi nằm ở PHẠM VI, không nằm ở tầng: | Tiêu chí | Application Gateway | Front Door | |---|---|---| | ⚠ Phạm vi | ⚠ một VÙNG | ⚠ TOÀN CẦU, chạy ở biên | | ⚠ Tầng | ⚠ 7 | ⚠ 7 | | ⚠ Backend | ⚠ trong hoặc gần một VNet | ⚠ bất kỳ đâu, kể cả ngoài Azure | | ⚠ Cache | ⚠ không | ⚠ CÓ, tích hợp CDN | | ⚠ WAF | ⚠ có | ⚠ có, chặn ngay tại biên |

⚠ Người dùng toàn cầu
        ↓
⚠ Front Door (biên, gần người dùng nhất)
        ↓
⚠ Application Gateway ở từng vùng
        ↓
⚠ Máy ảo, App Service, container

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

A (App Gateway tầng 7, Front Door tầng 3) — ⚠ SAI; Front Door là tầng 7.
D (Front Door theo vùng, App Gateway toàn cầu) — ⚠ NGƯỢC hoàn toàn.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án B — "App Gateway là bộ cân bằng tải tầng 7, còn Front Door cũng là tầng 7" — ⚠ về SỰ THẬT là ĐÚNG: cả hai đều hoạt động ở tầng 7.

Phương án	Đúng về sự thật	Có phân biệt hai dịch vụ
⚠ B	⚠ CÓ — cả hai đều tầng 7	⚠ KHÔNG — nói cả hai giống nhau
⚠ C	⚠ có	⚠ CÓ — toàn cầu và theo vùng
⚠ E	⚠ có	⚠ CÓ — phạm vi cân bằng tải khác nhau
⚠ Đề hỏi rõ	⚠ "phát biểu nào PHÂN BIỆT đúng hai dịch vụ"
⚠ Kết luận	⚠ loại B là hợp lý, giữ nguyên khoá C và E

⚠ Bốn dịch vụ cân bằng tải — bảng chọn: | Dịch vụ | Phạm vi | Tầng | |---|---|---| | ⚠ Load Balancer | ⚠ vùng | ⚠ 4 | | ⚠ Application Gateway | ⚠ vùng | ⚠ 7 | | ⚠ Traffic Manager | ⚠ toàn cầu | ⚠ DNS | | ⚠ Front Door | ⚠ toàn cầu | ⚠ 7 |

Từ khoá nhận diện:

"toàn cầu, tầng 7, có cache" → ⚠ Front Door "trong một vùng, tầng 7, định tuyến theo URL" → ⚠ Application Gateway "toàn cầu bằng DNS, mọi giao thức" → ⚠ Traffic Manager "tầng 4, độ trễ thấp nhất" → ⚠ Load Balancer

⚠ Mẫu kiến trúc thường gặp	Mẫu
⚠ Front Door ở ngoài cùng	⚠ định tuyến toàn cầu, WAF, cache
⚠ Application Gateway ở từng vùng	⚠ định tuyến theo đường dẫn trong vùng
⚠ Load Balancer phía sau	⚠ cho lưu lượng không phải HTTP
⚠ Không phải lúc nào cũng cần cả ba	⚠ chỉ thêm lớp khi có lý do rõ ràng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người dùng có ở nhiều châu lục không | ⚠ nếu không thì Front Door có thể thừa | | Có cần cache ở biên không | | | WAF nên đặt ở lớp nào | ⚠ càng ngoài càng chặn sớm |

Và điểm dễ nhầm nhất giữa hai dịch vụ: cả hai đều là tầng 7 và đều có WAF. Thứ phân biệt chúng là phạm vi địa lý — một cái ở biên toàn cầu, một cái trong một vùng.

Câu 9 Design and implement private access to Azure services (5–10%

You want to ensure that an Azure Storage account is only accessible from a specific Azure virtual network without exposing the storage account to the public internet.

Which Azure feature should you use to accomplish this?

A
ExpressRoute Peering
B
ExpressRoute Private Link
C
Azure Service Endpoint
D
Azure Private Link Service
E
Network Security groups

Xem giải thích

Đáp án

D — Azure Private Link

Vì sao đúng

Private Link tạo một giao diện mạng có địa chỉ IP riêng ngay bên trong mạng ảo của bạn, trỏ tới tài khoản lưu trữ. Nhờ vậy máy trong VNet gọi tài khoản đó bằng địa chỉ nội bộ, và bạn tắt hẳn truy cập công khai — dịch vụ không còn tiếp cận được từ Internet dù ai đó biết tên nó.

Đây là mức cô lập chặt nhất mà Azure cung cấp cho dịch vụ PaaS.

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

C. Service Endpoint — đây là phương án nhiễu gần nhất và nó cũng giới hạn truy cập theo VNet, nhưng khác ở một điểm quan trọng: tài khoản lưu trữ vẫn giữ điểm cuối công khai, chỉ là tường lửa của nó chặn mọi nguồn ngoài VNet đã khai. Đề nói rõ "không phơi ra Internet công cộng", nên Private Link mới đạt.
E. Network Security Group — lọc lưu lượng bên trong VNet, không kiểm soát được dịch vụ PaaS nằm ngoài VNet.
A và B. ExpressRoute — dùng để nối mạng tại chỗ với Azure, sai bài toán.

Câu 10 Design and implement core networking infrastructure (20–25%)

You are the owner of an application and must use dynamic IP addresses for specific resources on your virtual network (VNet). What SKU should you use?

A
Standard SKU
B
Basic SKU
C
Hybrid SKU
D
Complied SKU

Xem giải thích

Đáp án

B — Basic SKU.

Vì sao đúng

⚠ Hai SKU của địa chỉ IP công cộng khác nhau ở cách CẤP PHÁT: | SKU | Cấp phát | |---|---| | ⚠ Basic | ⚠ hỗ trợ ĐỘNG (dynamic) và tĩnh | | ⚠ Standard | ⚠ CHỈ tĩnh (static) |

⚠ IP động nghĩa là: ⚠ địa chỉ được cấp khi tài nguyên khởi động và có thể đổi khi tài nguyên dừng rồi bật lại. ⚠ Chỉ Basic SKU cho phép điều này.

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

A (Standard SKU) — ⚠ chỉ hỗ trợ IP TĨNH, không đáp ứng yêu cầu địa chỉ động.
C (Hybrid SKU) và D (Complied SKU) — ⚠ không tồn tại.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ Basic SKU của địa chỉ IP công cộng đã NGỪNG từ 30/09/2025, cùng đợt với Basic Load Balancer. ⚠ Khoá đáp án B vẫn ĐÚNG và giữ nguyên — về mặt kỹ thuật chỉ Basic mới hỗ trợ cấp phát động. ⚠ Nhưng hệ thống mới KHÔNG tạo được Basic nữa, nên trong thực tế hôm nay câu trả lời là "dùng Standard với IP tĩnh".

SKU	Tình trạng
⚠ Basic Public IP	⚠ ĐÃ NGỪNG từ 30/09/2025
⚠ Basic Load Balancer	⚠ ĐÃ NGỪNG cùng đợt
⚠ Standard	⚠ SKU dùng hiện nay
⚠ Trong lô này	⚠ #23182 cũng nhắc tới Basic Load Balancer

⚠ Vì sao Standard chỉ cho IP tĩnh: | Lý do | Nội dung | |---|---| | ⚠ Hỗ trợ Availability Zones | ⚠ zone-redundant hoặc gán vào một zone | | ⚠ Có SLA | | | ⚠ Mặc định đóng, phải mở bằng NSG | ⚠ an toàn hơn Basic vốn mặc định mở | | ⚠ Địa chỉ ổn định giúp bản ghi DNS và danh sách trắng không vỡ | |

Từ khoá nhận diện:

"IP động" → ⚠ Basic SKU, đã ngừng "IP tĩnh, có SLA, hỗ trợ zone" → ⚠ Standard SKU "nhiều IP công cộng gom lại" → ⚠ Public IP Prefix "máy không cần IP công cộng mà vẫn ra Internet" → ⚠ NAT Gateway

⚠ Ba cách để máy ảo ra Internet	Cách
⚠ IP công cộng gán trực tiếp	⚠ đơn giản nhất, kém an toàn nhất
⚠ Qua Load Balancer	⚠ dùng SNAT của bộ cân bằng tải
⚠ NAT Gateway	⚠ khuyến nghị — không cần IP công cộng trên máy, không cạn cổng SNAT

⚠ Cạn cổng SNAT — vấn đề hay gặp	Vấn đề
⚠ Nhiều máy dùng chung ít IP công cộng	⚠ hết cổng khả dụng
⚠ Triệu chứng: kết nối ra ngoài thất bại ngẫu nhiên
⚠ Rất khó chẩn đoán	⚠ trông như lỗi mạng ngẫu nhiên
⚠ Cách chữa	⚠ NAT Gateway, cấp nhiều cổng hơn hẳn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn tài nguyên nào dùng Basic SKU không | ⚠ đã ngừng, phải chuyển sang Standard | | Có máy nào có IP công cộng mà không cần không | | | Lưu lượng ra ngoài có đi qua NAT Gateway chưa | |

Và bài học rút ra từ đợt ngừng Basic SKU: kiểm tra định kỳ xem hạ tầng còn dùng SKU nào sắp hết vòng đời. Azure báo trước 12 tháng qua Service Health advisories, nhưng chỉ khi bạn có cảnh báo và có người đọc.

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

Đáp án

Vì sao đúng

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

Ghi nhớ