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

Tìm thấy 99 câu.

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

When using Azure Application Gateway Probes, which IP address is used by the Application Gateway as the source IP for health probes if you have a group of backend servers with public IP addresses?

  1. A

    Application Gateway's backend public IP address
  2. B

    Application Gateway's backend private IP address
  3. C

    Application Gateway's frontend public IP address
  4. D

    Application Gateway's frontend private IP address
Xem giải thích

Đáp án

C — Địa chỉ IP công cộng ở front-end của Application Gateway.

Vì sao đúng

⚠ Nguồn của health probe phụ thuộc backend nằm ở đâu: | Backend | IP nguồn của probe | |---|---| | ⚠ Có IP công cộng | ⚠ IP CÔNG CỘNG front-end của Application Gateway | | ⚠ Chỉ có IP riêng trong VNet | ⚠ IP riêng trong subnet của Application Gateway |

⚠ Backend công cộng  →  ⚠ probe phải đi ra Internet  →  ⚠ dùng IP công cộng front-end
⚠ Backend nội bộ     →  ⚠ probe đi trong VNet        →  ⚠ dùng IP riêng

⚠ Hệ quả thực tế: ⚠ nếu backend có tường lửa hoặc danh sách trắng, ⚠ phải cho phép IP công cộng front-end của gateway, nếu không mọi probe đều hỏng và backend bị đánh dấu là chết.

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

  • D (IP riêng front-end) — ⚠ dùng khi backend nội bộ, không tới được backend công cộng.

  • A và B (IP backend của gateway) — ⚠ Application Gateway KHÔNG có khái niệm "IP backend"; nó có IP front-end và một subnet riêng.

Ghi nhớ

⚠ Health probe của Application Gateway: | Loại | Nội dung | |---|---| | ⚠ Probe mặc định | ⚠ tự tạo, gọi đường dẫn /, chờ mã 200–399 | | ⚠ Custom probe | ⚠ tự khai đường dẫn, host, khoảng thời gian, ngưỡng, mã chấp nhận | | ⚠ Nên dùng | ⚠ custom probe trỏ tới endpoint kiểm tra sức khoẻ thật |

⚠ Các thông số của custom probe: | Thông số | Ý nghĩa | |---|---| | ⚠ Interval | ⚠ bao lâu thăm dò một lần | | ⚠ Timeout | ⚠ chờ bao lâu thì coi là hỏng | | ⚠ Unhealthy threshold | ⚠ bao nhiêu lần hỏng liên tiếp thì loại | | ⚠ Host và Path | ⚠ gọi tới đâu | | ⚠ Match conditions | ⚠ mã trạng thái và nội dung chấp nhận được |

Từ khoá nhận diện:

"backend công cộng" → ⚠ probe từ IP công cộng front-end "backend nội bộ" → ⚠ probe từ IP riêng trong subnet gateway "backend luôn bị báo unhealthy" → ⚠ kiểm tra NSG, tường lửa, và mã trả về của probe "subnet riêng cho gateway" → ⚠ Application Gateway BẮT BUỘC có subnet riêng

⚠ Nguyên nhân backend bị báo chết phổ biến Nguyên nhân
⚠ NSG chặn dải cổng 65200–65535 ⚠ Azure dùng dải này để quản lý gateway v2
⚠ Tường lửa backend chưa cho IP của gateway
⚠ Probe trỏ tới đường dẫn trả về mã 302 hay 401
⚠ Chứng chỉ TLS của backend không hợp lệ ⚠ khi dùng probe HTTPS
⚠ Host header không khớp ⚠ backend trả 404 cho host lạ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Probe đang trỏ tới đường dẫn nào và nhận mã gì | ⚠ xem backend health trong Portal | | NSG của subnet gateway có mở dải 65200–65535 không | | | Backend có lọc theo IP nguồn không | |

Và nguyên nhân số một khiến một Application Gateway mới dựng báo toàn bộ backend là "Unhealthy": probe không tới được, chứ không phải backend hỏng. Luôn kiểm tra đường đi của probe trước khi nghi ngờ ứng dụng.

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

Here are two statements about NAT (Network Address Translation):

1. A NAT gateway resource can use up to sixteen IP addresses.

2. Only one NAT gateway can be attached to a subnet.

Which of the above statement(s) is correct?

  1. A

    Only 1
  2. B

    Only 2
  3. C

    Both 1 and 2
  4. D

    None of them
Xem giải thích

Đáp án

C — Cả hai phát biểu đều đúng.

Vì sao đúng

⚠ Hai giới hạn của NAT Gateway: | Phát biểu | Đúng sai | |---|---| | ⚠ 1. Một NAT gateway dùng được tới 16 địa chỉ IP | ⚠ ĐÚNG — IP riêng lẻ hoặc qua public IP prefix | | ⚠ 2. Mỗi subnet chỉ gắn được MỘT NAT gateway | ⚠ ĐÚNG |

⚠ Bổ sung: ⚠ một NAT gateway có thể phục vụ NHIỀU subnet, nhưng quan hệ theo chiều ngược lại là một-một — ⚠ một subnet chỉ có một NAT gateway.

⚠ NAT Gateway (tối đa 16 IP công cộng)
   ├── ⚠ Subnet A
   ├── ⚠ Subnet B
   └── ⚠ Subnet C
   ⚠ Mỗi subnet chỉ trỏ về MỘT NAT gateway

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

  • A (chỉ 1 đúng), B (chỉ 2 đúng), D (không cái nào đúng) — ⚠ cả hai phát biểu đều chính xác.

Ghi nhớ

⚠ NAT Gateway giải quyết bài toán gì: | Vấn đề | NAT Gateway | |---|---| | ⚠ Máy cần ra Internet mà không muốn có IP công cộng | ⚠ giải quyết | | ⚠ Cạn cổng SNAT khi nhiều máy dùng chung ít IP | ⚠ giải quyết — mỗi IP cho 64.512 cổng | | ⚠ Muốn IP ra ngoài ổn định để đưa vào danh sách trắng | ⚠ giải quyết | | ⚠ Cho phép Internet đi VÀO | ⚠ KHÔNG — NAT Gateway chỉ một chiều RA |

⚠ Vì sao 16 IP là con số đáng nhớ: | Phép tính | Kết quả | |---|---| | ⚠ Mỗi IP công cộng | ⚠ 64.512 cổng SNAT | | ⚠ 16 IP | ⚠ hơn một triệu cổng | | ⚠ Đủ cho | ⚠ hầu như mọi khối lượng công việc |

Từ khoá nhận diện:

"ra Internet không cần IP công cộng trên máy" → ⚠ NAT Gateway "kết nối ra ngoài thất bại ngẫu nhiên" → ⚠ nghi cạn cổng SNAT "cho Internet đi vào" → ⚠ Load Balancer hoặc Application Gateway, KHÔNG phải NAT Gateway "IP ra ngoài phải cố định" → ⚠ NAT Gateway với IP tĩnh

⚠ Thứ tự ưu tiên khi máy ra Internet Thứ tự
⚠ 1. NAT Gateway ⚠ nếu subnet có gắn, luôn được ưu tiên
⚠ 2. IP công cộng gán trực tiếp trên máy
⚠ 3. SNAT của Load Balancer
⚠ Nghĩa là ⚠ gắn NAT Gateway sẽ THAY ĐỔI IP ra ngoài của máy
⚠ Cạn cổng SNAT — triệu chứng và cách chữa Nội dung
⚠ Triệu chứng: kết nối ra ngoài lỗi ngẫu nhiên, timeout
⚠ Rất khó chẩn đoán ⚠ trông như lỗi mạng vu vơ
⚠ Cách chữa: NAT Gateway
⚠ Hoặc: dùng connection pooling, giảm số kết nối mới

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Subnet đã có NAT Gateway chưa | | | Bên thứ ba có lọc theo IP của bạn không | ⚠ gắn NAT Gateway sẽ đổi IP đó | | Có máy nào còn IP công cộng không cần thiết không | |

Và tác dụng phụ dễ gây sự cố nhất khi mới gắn NAT Gateway: IP ra ngoài của toàn bộ subnet thay đổi. Nếu đối tác đang lọc theo IP cũ, kết nối sẽ đứt ngay lập tức — phải báo trước và cập nhật danh sách trắng.

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

When distributing traffic across a set of endpoints using the Weighted Routing method, you may want to prioritize a certain resource. In this case, what weight value should be assigned to this particular resource? Please choose the most appropriate answer.

  1. A

    0
  2. B

    1
  3. C

    10
  4. D

    100
  5. E

    1000
Xem giải thích

Đáp án

E — 1000.

Vì sao đúng

⚠ Weighted routing của Traffic Manager: | Thông số | Giá trị | |---|---| | ⚠ Khoảng trọng số hợp lệ | ⚠ 1 tới 1000 | | ⚠ Trọng số càng cao | ⚠ càng nhận nhiều lưu lượng | | ⚠ Muốn ưu tiên tối đa | ⚠ đặt 1000 | | ⚠ Trọng số 0 | ⚠ KHÔNG hợp lệ |

⚠ Cách chia lưu lượng:

⚠ Endpoint A: trọng số 1000
⚠ Endpoint B: trọng số 100
        ↓
⚠ A nhận khoảng 1000/1100 ≈ 91% lưu lượng
⚠ B nhận khoảng 100/1100 ≈ 9%

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

  • A (0) — ⚠ ngoài khoảng hợp lệ.

  • B (1), C (10), D (100) — ⚠ đều hợp lệ nhưng KHÔNG phải mức cao nhất; đề hỏi giá trị để ưu tiên tài nguyên đó, tức là mức tối đa.

Ghi nhớ

⚠ Sáu phương pháp định tuyến của Traffic Manager: | Phương pháp | Dùng khi | |---|---| | ⚠ Priority | ⚠ một endpoint chính, phần còn lại dự phòng | | ⚠ Weighted | ⚠ chia theo tỷ lệ, hoặc triển khai từ từ | | ⚠ Performance | ⚠ gửi tới endpoint có độ trễ thấp nhất | | ⚠ Geographic | ⚠ theo vị trí địa lý — cho tuân thủ dữ liệu | | ⚠ MultiValue | ⚠ trả về nhiều địa chỉ để client tự thử | | ⚠ Subnet | ⚠ theo dải IP nguồn — ví dụ nhân viên nội bộ thấy bản khác |

⚠ Weighted routing dùng để làm gì trong thực tế: | Kịch bản | Cách đặt | |---|---| | ⚠ Triển khai từ từ phiên bản mới | ⚠ bản mới trọng số 1, bản cũ 1000, rồi tăng dần | | ⚠ Chia tải giữa hai vùng theo công suất | ⚠ vùng lớn hơn nhận trọng số cao hơn | | ⚠ Rút một endpoint ra dần | ⚠ giảm trọng số về mức thấp nhất rồi tắt |

Từ khoá nhận diện:

"ưu tiên tối đa trong weighted" → ⚠ 1000 "chính và dự phòng" → ⚠ Priority "gần người dùng nhất" → ⚠ Performance "theo quốc gia, cho tuân thủ" → ⚠ Geographic

⚠ Lưu ý khi dùng weighted Lưu ý
⚠ Phân phối là XẤP XỈ, không chính xác tuyệt đối ⚠ vì DNS có cache
⚠ Endpoint không khoẻ bị loại khỏi vòng chia
⚠ Tỷ lệ tính trên tổng trọng số của endpoint ĐANG KHOẺ
⚠ Hệ quả ⚠ một endpoint chết thì lưu lượng dồn sang các endpoint còn lại theo tỷ lệ cũ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổng trọng số và tỷ lệ mong muốn có khớp không | | | TTL của DNS đặt bao nhiêu | ⚠ ảnh hưởng tốc độ tỷ lệ thật hội tụ | | Endpoint còn lại có gánh nổi khi một cái chết không | |

Và điều cần chấp nhận với mọi cách chia tải bằng DNS: tỷ lệ thực tế luôn lệch so với con số bạn đặt. Cache của trình phân giải và của client khiến phân phối chỉ đúng theo thống kê dài hạn, không đúng theo từng phút.

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

Which virtual public IP address facilitates a communication channel to Azure platform resources?

  1. A

    168.63.129
  2. B

    168.63.129.16
  3. C

    164.63.129.16
  4. D

    168.0.0.16
  5. E

    255.0.0.0
Xem giải thích

Đáp án

B — 168.63.129.16.

Vì sao đúng

⚠ 168.63.129.16 là địa chỉ IP ảo cố định của nền tảng Azure, giống nhau ở mọi vùng và mọi mạng ảo: | Chức năng | Nội dung | |---|---| | ⚠ DNS do Azure cung cấp | ⚠ phân giải tên trong VNet | | ⚠ Liên lạc với agent trên máy ảo | ⚠ kiểm tra sức khoẻ, tải cấu hình | | ⚠ Health probe của Load Balancer | ⚠ probe đi từ địa chỉ này | | ⚠ DHCP và cấp thuê địa chỉ | | | ⚠ Kích hoạt giấy phép Windows | ⚠ KMS đi qua kênh này |

⚠ Đây là địa chỉ ảo, không định tuyến ra ngoài — chỉ truy cập được từ bên trong mạng ảo.

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

  • A (168.63.129) — ⚠ thiếu một octet, không phải địa chỉ IPv4 hợp lệ.

  • C (164.63.129.16) — ⚠ sai octet đầu.

  • D (168.0.0.16) và E (255.0.0.0) — ⚠ không phải địa chỉ nền tảng của Azure; 255.0.0.0 là một mặt nạ mạng.

Ghi nhớ

⚠ Vì sao địa chỉ này quan trọng khi gỡ lỗi: | Nếu chặn 168.63.129.16 | Hậu quả | |---|---| | ⚠ Health probe không tới được | ⚠ máy bị đánh dấu chết, bị loại khỏi vòng phục vụ | | ⚠ DNS trong VNet ngừng hoạt động | ⚠ máy không phân giải được tên | | ⚠ Agent không báo cáo được | ⚠ extension và giám sát hỏng | | ⚠ Windows không kích hoạt được giấy phép | | | ⚠ Kết luận | ⚠ ĐỪNG BAO GIỜ chặn địa chỉ này trong NSG hay tường lửa trên máy |

Từ khoá nhận diện:

"168.63.129.16" → ⚠ IP ảo nền tảng Azure, DNS và probe "169.254.169.254" → ⚠ Instance Metadata Service, thông tin về chính máy ảo "probe đến từ đâu" → ⚠ service tag AzureLoadBalancer, tương ứng 168.63.129.16 "phân giải tên giữa các VNet peering" → ⚠ DNS mặc định KHÔNG làm được, cần Private DNS zone

⚠ Hai địa chỉ đặc biệt hay bị lẫn Địa chỉ
⚠ 168.63.129.16 ⚠ kênh liên lạc với nền tảng — DNS, probe, agent
⚠ 169.254.169.254 ⚠ Instance Metadata Service — hỏi thông tin về chính máy này
⚠ IMDS trả về ⚠ cỡ máy, vùng, thẻ, và token của managed identity
⚠ Vì thế ⚠ IMDS là mục tiêu tấn công SSRF, cần bảo vệ ở tầng ứng dụng
⚠ Lựa chọn DNS trong VNet Lựa chọn
⚠ DNS mặc định của Azure ⚠ 168.63.129.16, tự động, không cấu hình gì
⚠ Azure Private DNS zone ⚠ tên riêng, phân giải được giữa các VNet đã liên kết
⚠ DNS server tự dựng ⚠ toàn quyền, nhưng tự lo sẵn sàng cao
⚠ Azure DNS Private Resolver ⚠ cầu nối phân giải giữa tại chỗ và Azure

Ba việc kiểm chứng: | Việc | Cách | |---|---| | NSG có luật nào chặn 168.63.129.16 không | ⚠ kiểm tra ngay nếu probe hỏng bất thường | | Tường lửa trên chính máy ảo có chặn nó không | ⚠ hay bị quên | | VNet đang dùng DNS nào | ⚠ mặc định hay tự khai |

Và một trong những nguyên nhân "khó tin" nhất khiến máy ảo Azure hoạt động sai: ai đó chặn 168.63.129.16 trong tường lửa của hệ điều hành. Máy vẫn chạy, vẫn ping được, nhưng probe hỏng, DNS hỏng, và extension ngừng báo cáo — ba triệu chứng trông chẳng liên quan gì đến nhau.

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

You have been tasked with managing Private Endpoint connections for customer-owned services. Which cmdlet in PowerShell would you use to remove a Private Endpoint Connection?

  1. A

    Deny-AzPrivateEndpointConnection
  2. B

    Delete-AzPrivateEndpointConnection
  3. C

    Remove-AzPrivateEndpointConnection
  4. D

    Remove- AZPrivateConnection
  5. E

    Delete- AZPrivateConnection
Xem giải thích

Đáp án

C — Remove-AzPrivateEndpointConnection.

Vì sao đúng

⚠ PowerShell dùng động từ chuẩn — và động từ để xoá là Remove: | Động từ đúng | Động từ SAI | |---|---| | ⚠ Remove- | ⚠ Delete- — không phải động từ chuẩn của PowerShell | | ⚠ Get- | | | ⚠ New- | | | ⚠ Set- | | | ⚠ Approve- và Deny- | ⚠ có thật với private endpoint connection, nhưng để DUYỆT hoặc TỪ CHỐI |

⚠ Get-AzPrivateEndpointConnection      →  ⚠ xem danh sách
⚠ Approve-AzPrivateEndpointConnection  →  ⚠ duyệt yêu cầu kết nối
⚠ Deny-AzPrivateEndpointConnection     →  ⚠ từ chối
⚠ Remove-AzPrivateEndpointConnection   →  ⚠ XOÁ

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

  • A (Deny-AzPrivateEndpointConnection) — ⚠ có tồn tại nhưng để TỪ CHỐI, không xoá.

  • B (Delete-AzPrivateEndpointConnection) — ⚠ Delete không phải động từ chuẩn; PowerShell dùng Remove.

  • D và E — ⚠ sai cả tên lệnh lẫn khoảng trắng thừa.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23198 trong lô này cũng kiểm tra quy ước đặt tên PowerShell (-ResourceGroupName chứ không phải -ResourceGroup). ⚠ Cùng một kiểu câu hỏi: nhớ QUY ƯỚC thì loại được hầu hết phương án nhiễu.

⚠ Private Link và Private Endpoint là gì: | Khái niệm | Nội dung | |---|---| | ⚠ Private Endpoint | ⚠ một card mạng trong VNet của bạn, mang IP RIÊNG, trỏ tới một dịch vụ PaaS | | ⚠ Private Link Service | ⚠ dịch vụ CỦA BẠN được phơi ra cho khách hàng qua private endpoint | | ⚠ Kết quả | ⚠ lưu lượng tới Storage, SQL, Key Vault... KHÔNG đi qua Internet |

⚠ Không có private endpoint:
   ⚠ VM  →  ⚠ Internet  →  ⚠ endpoint công cộng của Storage
⚠ Có private endpoint:
   ⚠ VM  →  ⚠ IP riêng trong VNet  →  ⚠ Storage

Từ khoá nhận diện:

"IP riêng trong VNet cho dịch vụ PaaS" → ⚠ Private Endpoint "phơi dịch vụ của mình cho khách hàng qua IP riêng" → ⚠ Private Link Service "đi ra Internet nhưng qua backbone Microsoft" → ⚠ Service Endpoint, KHÁC private endpoint "xoá" → ⚠ Remove-, không phải Delete-

⚠ Service Endpoint và Private Endpoint — khác nhau Khác
⚠ Service Endpoint ⚠ vẫn dùng IP CÔNG CỘNG của dịch vụ, chỉ định tuyến qua backbone
⚠ Private Endpoint ⚠ dịch vụ có IP RIÊNG trong VNet của bạn
⚠ Private Endpoint ⚠ dùng được từ mạng tại chỗ qua VPN hoặc ExpressRoute
⚠ Service Endpoint ⚠ KHÔNG dùng được từ tại chỗ
⚠ Hướng khuyến nghị hiện nay ⚠ Private Endpoint
⚠ Điều cần lo khi dùng Private Endpoint Điều
⚠ DNS phải trỏ đúng ⚠ cần Azure Private DNS zone, đây là chỗ hay hỏng nhất
⚠ Mỗi private endpoint tính tiền theo giờ và theo dữ liệu
⚠ Nên tắt truy cập công cộng của dịch vụ ⚠ nếu không thì vẫn còn cửa cũ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | DNS có phân giải tên dịch vụ về IP riêng không | ⚠ nslookup từ trong VNet | | Truy cập công cộng của dịch vụ đã tắt chưa | | | Private DNS zone đã liên kết với đúng VNet chưa | |

Và nguyên nhân số một khiến Private Endpoint "dựng xong mà vẫn đi ra Internet": DNS chưa được cấu hình. Endpoint có IP riêng, nhưng nếu tên miền vẫn phân giải ra địa chỉ công cộng thì lưu lượng vẫn đi đường cũ.

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

When managing your task, it's important to centrally create, enforce, and log policies for applications and network connectivity across virtual networks and subscriptions. Which service would be best suited for this purpose?

  1. A

    Azure Front Door
  2. B

    Azure Firewall
  3. C

    Azure Private Link
  4. D

    Azure DNS
  5. E

    Azure DDoS Protection
Xem giải thích

Đáp án

B — Azure Firewall.

Vì sao đúng

⚠ Azure Firewall là dịch vụ tường lửa TẬP TRUNG do Microsoft quản lý: | Khả năng | Nội dung | |---|---| | ⚠ Tạo và áp chính sách tập trung | ⚠ Firewall Policy dùng chung cho nhiều firewall | | ⚠ Áp qua nhiều VNet và subscription | ⚠ đặt ở hub, spoke định tuyến về | | ⚠ Ghi nhật ký đầy đủ | ⚠ gửi sang Log Analytics, Storage hoặc Event Hub | | ⚠ Luật ứng dụng theo FQDN | ⚠ cho phép ra *.microsoft.com | | ⚠ Luật mạng theo IP, cổng, giao thức | | | ⚠ Threat intelligence | ⚠ chặn IP và tên miền độc hại đã biết | | ⚠ Sẵn sàng cao và tự co giãn sẵn có | |

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

  • A (Front Door) — ⚠ định tuyến và tăng tốc HTTP toàn cầu, không phải nơi áp chính sách mạng tập trung.

  • C (Private Link) — ⚠ đưa dịch vụ PaaS vào IP riêng, không có khái niệm chính sách và nhật ký kiểu tường lửa.

  • D (Azure DNS) — ⚠ phân giải tên.

  • E (DDoS Protection) — ⚠ chống tấn công lưu lượng, không lọc theo luật.

Ghi nhớ

⚠ Firewall Policy — thứ làm nên tính "tập trung": | Đặc điểm | Nội dung | |---|---| | ⚠ Là tài nguyên RIÊNG, tách khỏi firewall | | | ⚠ Một policy áp cho NHIỀU firewall | ⚠ ở nhiều vùng, nhiều subscription | | ⚠ Kế thừa | ⚠ policy con thừa hưởng policy cha | | ⚠ Rule collection group | ⚠ gom luật theo nhóm, có ưu tiên | | ⚠ Mô hình thường dùng | ⚠ policy gốc do đội bảo mật quản, policy con do đội ứng dụng |

⚠ Ba loại luật của Azure Firewall — xét theo thứ tự: | Loại | Xét thứ | Nội dung | |---|---|---| | ⚠ DNAT rules | ⚠ 1 | ⚠ chuyển lưu lượng vào từ ngoài | | ⚠ Network rules | ⚠ 2 | ⚠ theo IP, cổng, giao thức | | ⚠ Application rules | ⚠ 3 | ⚠ theo FQDN và giao thức web |

Từ khoá nhận diện:

"chính sách tập trung, nhiều VNet và subscription, có nhật ký" → ⚠ Azure Firewall "lọc cơ bản theo cổng, miễn phí, mức subnet" → ⚠ NSG "chặn SQL injection và XSS" → ⚠ WAF "quản trị mạng cho nhiều site và nhiều vùng" → ⚠ Virtual WAN, có Secured Virtual Hub

⚠ Ba bậc Azure Firewall Bậc
⚠ Basic ⚠ doanh nghiệp nhỏ, thông lượng thấp
⚠ Standard ⚠ threat intelligence, lọc FQDN
⚠ Premium ⚠ thêm kiểm tra TLS, IDPS, lọc URL, phân loại web
⚠ Điều kiện để firewall thực sự hoạt động Điều kiện
⚠ Định tuyến phải đi qua nó ⚠ user-defined route trỏ về IP riêng của firewall
⚠ Subnet tên AzureFirewallSubnet ⚠ tên bắt buộc
⚠ Nhật ký phải được bật và có người đọc
⚠ Thiếu định tuyến ⚠ firewall vẫn tính tiền mà không lọc gói nào

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lưu lượng ra Internet có thật sự đi qua firewall không | ⚠ kiểm tra bảng định tuyến, đừng giả định | | Threat intelligence đang ở chế độ Alert hay Deny | | | Nhật ký có ai xem không | |

Và bẫy triển khai tốn kém nhất với Azure Firewall: dựng xong nhưng quên user-defined route. Nó chạy, nó tính tiền theo giờ, nhưng không một gói tin nào đi qua — và bạn chỉ phát hiện ra khi mở nhật ký thấy trống trơn.

Câu 27 Chọn nhiều đáp án Design and implement core networking infrastructure (20-25%)

The Domain Name System (DNS) resolves service names to IP addresses. Which record types can't Azure Private DNS use?

  1. A

    CNAME
  2. B

    A
  3. C

    AA
  4. D

    AAA
  5. E

    TXT
Xem giải thích

Đáp án

C và D — "AA" và "AAA".

Vì sao đúng

⚠ Lý do đơn giản: hai loại bản ghi này KHÔNG TỒN TẠI trong DNS. | Tên trong đề | Thực tế | |---|---| | ⚠ "AA" | ⚠ KHÔNG có loại bản ghi nào tên như vậy | | ⚠ "AAA" | ⚠ cũng KHÔNG có — loại thật là AAAA, bốn chữ A |

⚠ Azure Private DNS hỗ trợ các loại bản ghi sau: | Loại | Dùng để | |---|---| | ⚠ A | ⚠ tên trỏ tới địa chỉ IPv4 | | ⚠ AAAA | ⚠ tên trỏ tới địa chỉ IPv6 | | ⚠ CNAME | ⚠ bí danh trỏ tới tên khác | | ⚠ MX | ⚠ máy chủ thư | | ⚠ PTR | ⚠ phân giải ngược, IP về tên | | ⚠ SOA | ⚠ thông tin về vùng, tạo tự động | | ⚠ SRV | ⚠ dịch vụ và cổng | | ⚠ TXT | ⚠ văn bản tự do — SPF, DKIM, xác minh sở hữu |

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

  • A (CNAME), B (A), E (TXT) — ⚠ đều là loại bản ghi THẬT và Azure Private DNS hỗ trợ đầy đủ.

Ghi nhớ

⚠ Mẹo phân biệt A và AAAA: | Loại | Số chữ A | Địa chỉ | |---|---|---| | ⚠ A | ⚠ một | ⚠ IPv4 — 32 bit | | ⚠ AAAA | ⚠ bốn | ⚠ IPv6 — 128 bit, gấp BỐN lần | | ⚠ Mẹo nhớ | ⚠ số chữ A tương ứng bội số độ dài địa chỉ |

⚠ Azure Private DNS zone dùng để làm gì: | Việc | Nội dung | |---|---| | ⚠ Phân giải tên riêng trong VNet | ⚠ không lộ ra Internet | | ⚠ Phân giải chéo giữa các VNet đã liên kết | ⚠ thứ mà DNS mặc định KHÔNG làm được | | ⚠ Tự động đăng ký bản ghi cho máy ảo | ⚠ bật auto-registration trên virtual network link | | ⚠ Bắt buộc cho Private Endpoint | ⚠ để tên dịch vụ phân giải về IP riêng |

Từ khoá nhận diện:

"IPv4" → ⚠ bản ghi A "IPv6" → ⚠ bản ghi AAAA "bí danh trỏ tới tên khác" → ⚠ CNAME "xác minh sở hữu tên miền, SPF" → ⚠ TXT "phân giải tên trong VNet không lộ ra ngoài" → ⚠ Private DNS zone

⚠ Private DNS zone và Public DNS zone Khác
⚠ Azure DNS (public) ⚠ lưu trữ tên miền công khai, ai cũng phân giải được
⚠ Azure Private DNS ⚠ chỉ phân giải được từ VNet đã liên kết
⚠ Liên kết ⚠ virtual network link, có tuỳ chọn tự đăng ký bản ghi
⚠ Giới hạn cần biết Giới hạn
⚠ CNAME không đặt được ở đỉnh vùng ⚠ giới hạn của chính chuẩn DNS
⚠ Một VNet liên kết được với nhiều zone
⚠ Auto-registration chỉ bật cho MỘT zone mỗi VNet

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Private DNS zone đã liên kết đúng VNet chưa | ⚠ thiếu liên kết là không phân giải được | | Private endpoint có zone tương ứng chưa | ⚠ mỗi dịch vụ có tên zone riêng | | Máy ảo đang dùng DNS nào | ⚠ mặc định của Azure hay DNS tự khai |

Và lý do Private DNS zone là mắt xích hay hỏng nhất trong kiến trúc Private Endpoint: endpoint dựng đúng, nhưng nếu tên miền vẫn phân giải ra IP công cộng thì lưu lượng vẫn đi đường cũ — và mọi thứ trông như vẫn hoạt động bình thường.

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

There are two types of virtual WANs: Basic and Standard. Basic virtual WAN supports different configurations. Choose the available configurations for Basic virtual WAN from the given options.

  1. A

    User VPN (P2S)
  2. B

    ExpressRoute
  3. C

    Azure Firewall
  4. D

    Site-to-site VPN
  5. E

    All the Above
Xem giải thích

Đáp án

D — Site-to-site VPN.

Vì sao đúng

⚠ Virtual WAN có hai bậc, khác nhau rất nhiều: | Khả năng | Basic | Standard | |---|---|---| | ⚠ Site-to-site VPN | ⚠ CÓ | ⚠ có | | ⚠ User VPN (P2S) | ⚠ không | ⚠ có | | ⚠ ExpressRoute | ⚠ không | ⚠ có | | ⚠ Azure Firewall trong hub | ⚠ không | ⚠ có — Secured Virtual Hub | | ⚠ Hub-to-hub và VNet-to-VNet qua hub | ⚠ không | ⚠ có | | ⚠ Định tuyến tuỳ chỉnh | ⚠ không | ⚠ có |

⚠ Basic chỉ có đúng một khả năng: ⚠ nối site tại chỗ vào Azure bằng VPN site-to-site.

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

  • A (User VPN P2S), B (ExpressRoute), C (Azure Firewall) — ⚠ đều CHỈ có ở bậc Standard.

  • E (tất cả) — ⚠ sai vì Basic không hỗ trợ ba cái kia.

Ghi nhớ

⚠ Nâng cấp một chiều: | Thao tác | Được không | |---|---| | ⚠ Basic → Standard | ⚠ ĐƯỢC | | ⚠ Standard → Basic | ⚠ KHÔNG | | ⚠ Vì thế | ⚠ bắt đầu ở Basic nếu chỉ cần S2S, nâng khi cần thêm |

⚠ Azure Virtual WAN giải quyết bài toán gì: | Bài toán | Nội dung | |---|---| | ⚠ Nhiều chi nhánh, nhiều vùng, nhiều VNet | ⚠ quản lý bằng tay rất rối | | ⚠ Virtual WAN gom lại thành mô hình hub tập trung | | | ⚠ Microsoft quản lý định tuyến giữa các hub | | | ⚠ Mở rộng bằng cách thêm connection, không phải thêm peering thủ công | |

Từ khoá nhận diện:

"chỉ cần nối site vào Azure" → ⚠ Virtual WAN Basic là đủ "cần P2S, ExpressRoute, hoặc firewall trong hub" → ⚠ Standard "firewall ngay trong hub Virtual WAN" → ⚠ Secured Virtual Hub "vài VNet đơn giản trong một vùng" → ⚠ peering thủ công có khi đủ, không cần Virtual WAN

⚠ Virtual WAN và hub-and-spoke tự dựng Chọn
⚠ Virtual WAN ⚠ nhiều site, nhiều vùng, muốn ít việc vận hành
⚠ Tự dựng ⚠ cần kiểm soát chi tiết từng tuyến, hoặc quy mô nhỏ
⚠ Virtual WAN cũng có chi phí ⚠ hub và các đơn vị co giãn tính tiền riêng
⚠ Thành phần của Virtual WAN Thành phần
⚠ Virtual WAN ⚠ vật chứa toàn cầu
⚠ Hub ⚠ một điểm tập trung trong một vùng
⚠ Connection ⚠ VNet, site VPN, P2S, ExpressRoute nối vào
⚠ Route table ⚠ quyết định định tuyến — xem #23192 cùng lô

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thật sự cần Virtual WAN không | ⚠ vài VNet thì peering rẻ hơn nhiều | | Bậc hiện tại có đủ cho kế hoạch sắp tới không | ⚠ hạ bậc không được | | Chi phí hub và đơn vị co giãn là bao nhiêu | |

Và cân nhắc thực tế trước khi chọn Virtual WAN: nó đáng giá khi bạn có nhiều site và nhiều vùng. Với hai ba VNet trong một vùng, peering thủ công vừa đơn giản hơn vừa rẻ hơn đáng kể.

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

You mentioned that you're facing issues while working on Azure PowerShell due to some failing values. One of your friends suggested installing the latest version to avoid such problems. Which of the following cmdlets would you use to find out the Azure PowerShell versions installed on your computer?

  1. A

    Get-Module -ListAvailable Az
  2. B

    Get-Module -AzList
  3. C

    Retrieve-Module -ListAvailable Az
  4. D

    Retrieve- Module -AzList
Xem giải thích

Đáp án

A — Get-Module -ListAvailable Az.

Vì sao đúng

⚠ Cấu trúc lệnh: | Thành phần | Vai trò | |---|---| | ⚠ Get-Module | ⚠ cmdlet chuẩn của PowerShell để xem mô-đun | | ⚠ -ListAvailable | ⚠ liệt kê mọi mô-đun ĐÃ CÀI, kể cả chưa nạp vào phiên hiện tại | | ⚠ Az | ⚠ tên mô-đun Azure PowerShell |

⚠ Không có -ListAvailable thì chỉ thấy mô-đun đang được NẠP trong phiên hiện tại — thường là danh sách trống nếu chưa gọi lệnh Az nào.

⚠ Get-Module -ListAvailable Az     →  ⚠ mọi phiên bản đã cài
⚠ Get-InstalledModule -Name Az     →  ⚠ phiên bản cài qua PowerShellGet
⚠ Update-Module -Name Az           →  ⚠ cập nhật lên bản mới

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

  • B (Get-Module -AzList) — ⚠ -AzList không phải tham số của Get-Module.

  • C và D (Retrieve-Module) — ⚠ Retrieve KHÔNG phải động từ chuẩn của PowerShell; động từ để đọc luôn là Get.

Ghi nhớ

⚠ Đây là câu thứ ba trong lô kiểm tra quy ước PowerShell — cùng với #23198 (-ResourceGroupName) và #23203 (Remove- chứ không phải Delete-).

Câu Quy ước bị kiểm tra
⚠ #23198 ⚠ tên tham số -ResourceGroupName
⚠ #23203 ⚠ động từ Remove-
⚠ #23207 (câu này) ⚠ động từ Get-, tham số -ListAvailable
⚠ Kết luận ⚠ nhớ QUY ƯỚC loại được hầu hết phương án nhiễu, không cần nhớ từng lệnh

⚠ Động từ chuẩn của PowerShell: | Động từ | Việc | |---|---| | ⚠ Get- | ⚠ đọc, liệt kê | | ⚠ New- | ⚠ tạo mới | | ⚠ Set- | ⚠ sửa | | ⚠ Remove- | ⚠ xoá | | ⚠ Add-, Update-, Test-, Start-, Stop- | | | ⚠ Không tồn tại | ⚠ Retrieve-, Delete-, Create-, Fetch- |

Từ khoá nhận diện:

"xem đã cài phiên bản nào" → ⚠ Get-Module -ListAvailable "cập nhật mô-đun" → ⚠ Update-Module "đăng nhập Azure" → ⚠ Connect-AzAccount "xem đang ở subscription nào" → ⚠ Get-AzContext

⚠ Mô-đun Az và AzureRM Lịch sử
⚠ AzureRM ⚠ mô-đun CŨ, đã ngừng hỗ trợ từ 2/2024
⚠ Az ⚠ mô-đun hiện hành, đa nền tảng
⚠ Không nên cài cả hai ⚠ cùng máy dễ xung đột
⚠ Có công cụ chuyển đổi ⚠ Set-AzContext và bí danh giúp chuyển kịch bản cũ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy đang có mấy phiên bản Az | ⚠ nhiều phiên bản dễ gây hành vi lạ | | Có còn AzureRM cũ trên máy không | ⚠ nên gỡ | | Kịch bản tự động có ghim phiên bản mô-đun không | ⚠ để bản mới không làm vỡ pipeline |

Và nguyên nhân âm thầm gây ra những lỗi PowerShell "không hiểu nổi": nhiều phiên bản mô-đun cùng tồn tại trên một máy. Lệnh chạy đúng hôm nay, sai ngày mai, chỉ vì phiên bản được nạp khác nhau.

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

Various services are available for connecting Azure resources, including connections from on-premises networks to Azure resources and between branches in Azure. These services include ExpressRoute, Virtual Network (VNet), VPN Gateway, Virtual Network NAT Gateway, Virtual WAN, Azure DNS, Azure Bastion, and Azure Peering service. To ensure traffic between an on-premises site and the Azure virtual network is encrypted, which tool should you use?

  1. A

    ExpressRoute
  2. B

    VPN Gateway
  3. C

    Azure Bastion
  4. D

    Azure Peering Service
Xem giải thích

Đáp án

B — VPN Gateway.

Vì sao đúng

⚠ VPN Gateway dựng đường hầm IPsec/IKE có MÃ HOÁ giữa mạng tại chỗ và VNet: | Đặc điểm | Nội dung | |---|---| | ⚠ Mã hoá sẵn có | ⚠ IPsec, không phải cấu hình thêm | | ⚠ Đi qua Internet công cộng | ⚠ nên mã hoá là bắt buộc | | ⚠ Site-to-site cho cả mạng | | | ⚠ Point-to-site cho từng máy | |

⚠ Mạng tại chỗ  ←  ⚠ đường hầm IPsec đã mã hoá  →  ⚠ Azure VNet

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

  • A (ExpressRoute) — ⚠ là kết nối RIÊNG, không qua Internet, NHƯNG KHÔNG tự mã hoá. ⚠ Muốn mã hoá trên ExpressRoute phải thêm lớp riêng — VPN IPsec chạy bên trong, hoặc MACsec ở tầng 2 với ExpressRoute Direct.

  • C (Azure Bastion) — ⚠ để truy cập RDP/SSH vào máy ảo qua trình duyệt, không nối hai mạng.

  • D (Azure Peering Service) — ⚠ tối ưu đường đi tới dịch vụ SaaS của Microsoft qua nhà mạng, không phải kết nối mã hoá vào VNet.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23181 trong lô này về các loại peering của ExpressRoute cũng nhắc tới điểm này. ⚠ ExpressRoute riêng tư nhưng KHÔNG mã hoá — đây là hiểu nhầm phổ biến nhất về nó.

⚠ Bốn cách nối tại chỗ với Azure: | Cách | Mã hoá | Đường đi | |---|---|---| | ⚠ VPN Site-to-Site | ⚠ CÓ — IPsec | ⚠ Internet | | ⚠ VPN Point-to-Site | ⚠ CÓ | ⚠ Internet | | ⚠ ExpressRoute | ⚠ KHÔNG mặc định | ⚠ kết nối riêng | | ⚠ ExpressRoute + VPN | ⚠ CÓ | ⚠ kết nối riêng, thêm lớp mã hoá |

Từ khoá nhận diện:

"mã hoá lưu lượng" → ⚠ VPN Gateway "không qua Internet, băng thông cao" → ⚠ ExpressRoute "vừa riêng vừa mã hoá" → ⚠ VPN chạy trên ExpressRoute "quản trị máy ảo qua trình duyệt" → ⚠ Bastion

⚠ SKU VPN Gateway SKU
⚠ Basic ⚠ rất hạn chế, không dùng cho sản xuất
⚠ VpnGw1 tới VpnGw5 ⚠ băng thông và số đường hầm tăng dần
⚠ Bản AZ ⚠ hỗ trợ Availability Zones
⚠ Hai chế độ ⚠ Route-based (phổ biến) và Policy-based (cũ, hạn chế)
⚠ Thiết kế kết nối lai đáng tin cậy Thiết kế
⚠ ExpressRoute làm chính ⚠ băng thông cao, độ trễ ổn định
⚠ VPN S2S làm dự phòng ⚠ rẻ, tự động chuyển khi ExpressRoute hỏng
⚠ Gateway active-active ⚠ hai instance, không có điểm hỏng đơn lẻ
⚠ Dải IP hai bên KHÔNG chồng lấn ⚠ điều kiện tiên quyết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu đi qua có yêu cầu mã hoá theo quy định không | | | Gateway có ở chế độ active-active không | | | Có đường dự phòng khi đường chính hỏng không | |

Và điều cần làm rõ ngay từ đầu khi thiết kế kết nối lai: "riêng tư" và "được mã hoá" là hai yêu cầu khác nhau. ExpressRoute cho vế đầu, VPN cho vế sau — cần cả hai thì phải chồng cả hai lên nhau.