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

Tìm thấy 99 câu.

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

Virtual Network NAT (Network Address Translation) enables virtual networks to have outbound-only Internet connectivity. Select all applicable statements about NAT.

  1. A

    NAT is compatible with standard SKU public IP and public IP prefixes but not with load balancer resources.

  2. B

    NAT can support both IPv4 and IPv6 addresses regardless of which one you are using.

  3. C

    NAT is capable of supporting only IPv4 protocol and not IPv6.

  4. D

    A network address translation (NAT) can cover several virtual networks at once.

  5. E

    Network Address Translation (NAT) cannot extend across multiple virtual networks.

Xem giải thích

Đáp án

C và E.

  • C — NAT chỉ hỗ trợ giao thức IPv4, không hỗ trợ IPv6.
  • E — NAT không mở rộng xuyên nhiều mạng ảo.

Vì sao đúng

⚠ Hai giới hạn cứng của Virtual Network NAT: | Giới hạn | Nội dung | |---|---| | ⚠ Chỉ IPv4 | ⚠ IPv6 không được hỗ trợ | | ⚠ Chỉ trong MỘT mạng ảo | ⚠ phục vụ nhiều subnet, nhưng phải cùng VNet |

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

  • A (tương thích với IP công cộng và prefix Standard nhưng KHÔNG với load balancer) — ⚠ SAI; NAT Gateway dùng chung được với Load Balancer trong cùng mạng ảo.

  • B (hỗ trợ cả IPv4 và IPv6) — ⚠ SAI; chỉ IPv4.

  • D (một NAT bao phủ được nhiều mạng ảo) — ⚠ SAI, và mâu thuẫn trực tiếp với phương án E.

Ghi nhớ

⚠ Đối chiếu: ⚠ đây là câu thứ BA về NAT trong lô này.

Câu Kiểm tra điều gì Khoá
⚠ #23200 ⚠ 16 IP, một NAT gateway mỗi subnet ⚠ cả hai đúng
⚠ #23216 ⚠ dùng chung IP công cộng, không xuyên VNet ⚠ phát biểu 1 và 4
⚠ #23219 (câu này) ⚠ chỉ IPv4, không xuyên VNet ⚠ C và E
⚠ Ba câu ⚠ hoàn toàn nhất quán, giữ nguyên cả ba khoá

⚠ Bảng tổng hợp mọi giới hạn của NAT Gateway: | Thuộc tính | Giá trị | |---|---| | ⚠ Số IP công cộng tối đa | ⚠ 16 | | ⚠ Cổng SNAT mỗi IP | ⚠ 64.512 | | ⚠ NAT gateway mỗi subnet | ⚠ 1 | | ⚠ Subnet mỗi NAT gateway | ⚠ nhiều, cùng VNet | | ⚠ Xuyên VNet | ⚠ KHÔNG | | ⚠ Giao thức | ⚠ chỉ IPv4 | | ⚠ Chiều | ⚠ chỉ RA | | ⚠ Zone | ⚠ gán vào một zone, hoặc regional |

Từ khoá nhận diện:

"chỉ đi ra, dùng chung IP" → ⚠ NAT Gateway "IPv6" → ⚠ NAT Gateway KHÔNG hỗ trợ "nhiều VNet" → ⚠ mỗi VNet phải có NAT gateway riêng "cho phép đi vào" → ⚠ Load Balancer hoặc Application Gateway

⚠ NAT Gateway và Load Balancer dùng chung Cách
⚠ Load Balancer lo lưu lượng ĐI VÀO
⚠ NAT Gateway lo lưu lượng ĐI RA
⚠ Hai vai trò khác nhau, không xung đột
⚠ Nếu subnet có NAT Gateway ⚠ nó thắng SNAT của Load Balancer cho chiều ra
⚠ Vì sao NAT Gateway đáng dùng hơn SNAT của Load Balancer Lý do
⚠ Nhiều cổng SNAT hơn hẳn ⚠ hết cạn cổng
⚠ Cấp cổng theo nhu cầu, không chia cứng
⚠ Thời gian chờ nhàn rỗi cấu hình được
⚠ Không cần cấu hình định tuyến

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có VNet nào chưa có NAT Gateway riêng không | | | Kết nối ra ngoài có lỗi ngẫu nhiên không | ⚠ dấu hiệu cạn cổng SNAT | | Có dùng IPv6 ở đâu không | ⚠ NAT Gateway không phục vụ được |

Và cách tóm gọn Virtual Network NAT trong một câu: một chiều, một mạng ảo, một họ giao thức. Chỉ đi ra, chỉ trong một VNet, và chỉ IPv4 — ba giới hạn này quyết định gần như mọi quyết định thiết kế quanh nó.

Câu 42 Design and implement private access to Azure services (5-10%

You have been tasked with managing Private Endpoint connections for customer-owned services. To retrieve Private Endpoint connections along with their statuses, which PowerShell command would you use?

  1. A

    Get-AzurePrivateLinkService

  2. B

    Get-AzPrivateLinkService

  3. C

    Get- AZPrivateLinkState

  4. D

    Approve-AzPrivateEndpointConnection

  5. E

    az network private-link-service connection reject

Xem giải thích

Đáp án

B — Get-AzPrivateLinkService.

Vì sao đúng

⚠ Ba chi tiết đều phải đúng: | Chi tiết | Đúng | |---|---| | ⚠ Động từ | ⚠ Get- để đọc và liệt kê | | ⚠ Tiền tố | ⚠ Az — mô-đun hiện hành | | ⚠ Danh từ | ⚠ PrivateLinkService |

⚠ Lệnh trả về các Private Link Service cùng danh sách private endpoint connection và TRẠNG THÁI của từng cái — Pending, Approved, Rejected, hoặc Disconnected.

⚠ Get-AzPrivateLinkService -ResourceGroupName "RG-Mang"
⚠   → xem PrivateEndpointConnections và ConnectionState của từng cái

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

  • A (Get-AzurePrivateLinkService) — ⚠ tiền tố Azure thuộc mô-đun AzureRM đã ngừng từ 2/2024.

  • C (Get- AZPrivateLinkState) — ⚠ sai tên, và có khoảng trắng thừa sau dấu gạch nối.

  • D (Approve-AzPrivateEndpointConnection) — ⚠ có thật nhưng để DUYỆT, không phải để đọc danh sách.

  • E (az network private-link-service connection reject) — ⚠ là lệnh Azure CLI để TỪ CHỐI, không phải PowerShell và không phải để đọc.

Ghi nhớ

⚠ Đối chiếu: ⚠ đây là câu PowerShell thứ NĂM trong lô — cùng với #23198, #23203, #23207 và #23211.

Câu Quy ước
⚠ #23198 ⚠ -ResourceGroupName
⚠ #23203 ⚠ Remove- để xoá
⚠ #23207 ⚠ Get- và -ListAvailable
⚠ #23211 ⚠ New- để tạo, tiền tố Az
⚠ #23220 (câu này) ⚠ Get- để đọc, tiền tố Az
⚠ Kết luận ⚠ lô này kiểm tra quy ước PowerShell rất dày — thuộc quy ước là đủ

⚠ Vòng đời một private endpoint connection: | Trạng thái | Nghĩa | |---|---| | ⚠ Pending | ⚠ khách hàng đã yêu cầu, chủ dịch vụ chưa duyệt | | ⚠ Approved | ⚠ đã duyệt, kết nối hoạt động | | ⚠ Rejected | ⚠ bị từ chối | | ⚠ Disconnected | ⚠ chủ dịch vụ đã ngắt |

⚠ Cmdlet tương ứng: | Cmdlet | Việc | |---|---| | ⚠ Get-AzPrivateLinkService | ⚠ xem dịch vụ và các kết nối | | ⚠ Get-AzPrivateEndpointConnection | ⚠ xem riêng các kết nối | | ⚠ Approve-AzPrivateEndpointConnection | ⚠ duyệt | | ⚠ Deny-AzPrivateEndpointConnection | ⚠ từ chối | | ⚠ Remove-AzPrivateEndpointConnection | ⚠ xoá |

Từ khoá nhận diện:

"xem, liệt kê" → ⚠ Get- "duyệt yêu cầu kết nối" → ⚠ Approve- "xoá" → ⚠ Remove- "tiền tố Azure" → ⚠ mô-đun cũ đã ngừng

⚠ Private Link Service dùng khi nào Khi nào
⚠ Bạn là NHÀ CUNG CẤP dịch vụ ⚠ muốn khách hàng truy cập qua IP riêng
⚠ Dịch vụ đứng sau Standard Load Balancer ⚠ điều kiện bắt buộc
⚠ Khách hàng tạo private endpoint trỏ tới
⚠ Bạn duyệt hoặc từ chối từng yêu cầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có yêu cầu kết nối nào đang Pending không | ⚠ khách hàng đang chờ | | Có kết nối nào nên ngắt không | ⚠ khách hàng đã ngừng dùng dịch vụ | | Quy trình duyệt có ai chịu trách nhiệm không | |

Và điều dễ bị bỏ quên khi vận hành Private Link Service: yêu cầu kết nối ở trạng thái Pending sẽ nằm im mãi. Không có cảnh báo mặc định nào, nên phải có người chủ động kiểm tra hoặc phải tự dựng cảnh báo cho việc đó.

Câu 43 Secure network connectivity to Azure resources (15-20%)

Clarify the order in which rules/operations are executed in Azure Firewall, regardless of their collection priority, collection group, and policy inheritance. What is the correct sequence of application, network, and DNAT rules?

  1. A

    Application Rules > Network Rules > DNAT Rules

  2. B

    Application Rules > DNAT Rules > Network Rules

  3. C

    DNAT Rules > Application Rules > Network Rules

  4. D

    DNAT Rules > Network Rules > Application Rules

  5. E

    Network Rules > Application Rules > DNAT Rules

Xem giải thích

Đáp án

D — DNAT Rules > Network Rules > Application Rules.

Vì sao đúng

⚠ Azure Firewall luôn xét theo đúng thứ tự này, bất kể ưu tiên của collection hay policy: | Thứ tự | Loại luật | Việc | |---|---|---| | ⚠ 1 | ⚠ DNAT rules | ⚠ chuyển lưu lượng từ ngoài vào tài nguyên nội bộ | | ⚠ 2 | ⚠ Network rules | ⚠ lọc theo IP, cổng, giao thức | | ⚠ 3 | ⚠ Application rules | ⚠ lọc theo FQDN và danh mục web |

⚠ Gói tin tới
     ↓
⚠ 1. DNAT rules        →  ⚠ khớp thì chuyển hướng và dừng
     ↓
⚠ 2. Network rules     →  ⚠ khớp thì CHO PHÉP hoặc CHẶN, và DỪNG
     ↓
⚠ 3. Application rules →  ⚠ chỉ tới đây nếu network rules KHÔNG khớp

⚠ Hệ quả quan trọng nhất: ⚠ một network rule cho phép cổng 443 rộng rãi sẽ khiến mọi application rule lọc theo FQDN trở nên vô nghĩa.

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

  • A, B, C, E — ⚠ đều sai thứ tự; DNAT luôn đầu tiên, application rules luôn cuối cùng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23210 trong lô này hỏi cách khắc phục việc cảnh báo threat intelligence bị che lấp — ⚠ nguyên nhân gốc chính là thứ tự luật này. ⚠ Hai câu bổ sung nhau, giữ nguyên cả hai khoá.

⚠ Mẹo nhớ thứ tự: | Mẹo | Nội dung | |---|---| | ⚠ Từ THÔ tới TINH | ⚠ DNAT là chuyển hướng, network là IP/cổng, application là tên miền | | ⚠ Từ tầng THẤP tới tầng CAO | ⚠ tầng 3 → tầng 4 → tầng 7 | | ⚠ Luật càng cụ thể càng xét sau | |

⚠ Bẫy cấu hình điển hình: | Cấu hình | Kết quả thực tế | |---|---| | ⚠ Network rule: cho phép mọi đích cổng 443 | | | ⚠ Application rule: chỉ cho phép *.microsoft.com | | | ⚠ Người viết tưởng | ⚠ đã chặn được các trang khác | | ⚠ Thực tế | ⚠ mọi trang HTTPS đều ra được | | ⚠ Cách chữa | ⚠ BỎ network rule cho 443, để application rule xử lý |

Từ khoá nhận diện:

"lọc theo tên miền" → ⚠ application rule, phải để network rule không bắt trước "lọc theo IP và cổng" → ⚠ network rule "chuyển lưu lượng từ ngoài vào" → ⚠ DNAT rule "luật không có tác dụng" → ⚠ kiểm tra thứ tự xét luật trước tiên

⚠ Trong một loại luật thì xét thế nào Cách
⚠ Rule collection group theo ưu tiên
⚠ Rồi rule collection theo ưu tiên
⚠ Trong một collection, luật xét theo thứ tự khai
⚠ Nhưng ⚠ thứ tự BA LOẠI luôn cố định, ưu tiên không đổi được điều đó

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có network rule nào bắt cổng 80 hoặc 443 rộng rãi không | ⚠ nó vô hiệu hoá application rules | | Nhật ký cho thấy luật nào đang khớp | ⚠ đọc Azure Firewall logs | | Threat intelligence đang ở chế độ nào | |

Và điều làm loại lỗi này khó phát hiện: cấu hình trông hoàn toàn hợp lý khi đọc. Application rule có đó, viết đúng, nhưng không bao giờ được xét tới — và không có cảnh báo nào cho bạn biết điều đó.

Câu 44 Secure network connectivity to Azure resources (15-20%)

A custom Web Application Firewall (WAF) rule contains a priority number, match conditions, rule type, and an action. What kinds of custom rules can you create while creating a WAF policy?

  1. A

    Rate limit rules and Match rules

  2. B

    Match rules and priority rules

  3. C

    Match rules and String rules

  4. D

    Rate limit rules and Last limit rules

  5. E

    Rate limit rules and priority rules

Xem giải thích

Đáp án

A — Rate limit rules và Match rules.

Vì sao đúng

⚠ WAF của Azure có hai loại luật tuỳ chỉnh: | Loại | Việc | |---|---| | ⚠ Match rule | ⚠ khớp điều kiện rồi cho phép, chặn, hoặc ghi nhật ký | | ⚠ Rate limit rule | ⚠ đếm số yêu cầu trong một cửa sổ thời gian, vượt ngưỡng thì chặn |

⚠ Cấu trúc một luật tuỳ chỉnh: | Thành phần | Nội dung | |---|---| | ⚠ Priority | ⚠ số nhỏ xét trước | | ⚠ Match conditions | ⚠ IP, quốc gia, header, chuỗi truy vấn, phương thức, body | | ⚠ Rule type | ⚠ Match hoặc RateLimit | | ⚠ Action | ⚠ Allow, Block, Log, hoặc Redirect |

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

  • B, E (priority rules) — ⚠ priority là một THUỘC TÍNH của luật, không phải một loại luật.

  • C (String rules) và D (Last limit rules) — ⚠ không tồn tại.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23211 trong lô này hỏi cmdlet tạo chính sách WAF cho Front Door. ⚠ Câu này đi vào nội dung của chính sách đó. Hai câu bổ sung nhau.

⚠ Hai lớp luật của WAF: | Lớp | Nội dung | |---|---| | ⚠ Managed rule set | ⚠ Microsoft duy trì, dựa trên OWASP Core Rule Set | | ⚠ Custom rules | ⚠ của bạn, xét TRƯỚC managed rules |

⚠ Custom rules luôn được xét trước — nên dùng chúng để tạo ngoại lệ hoặc chặn sớm.

⚠ Rate limit dùng để làm gì: | Kịch bản | Cách đặt | |---|---| | ⚠ Chống dò mật khẩu | ⚠ giới hạn số yêu cầu tới /login mỗi IP | | ⚠ Chống cào dữ liệu | ⚠ giới hạn tới endpoint danh mục | | ⚠ Chống DDoS tầng 7 | ⚠ hạn chế lưu lượng bất thường | | ⚠ Bảo vệ API tốn kém | |

Từ khoá nhận diện:

"đếm số yêu cầu trong khoảng thời gian" → ⚠ rate limit rule "khớp điều kiện rồi hành động" → ⚠ match rule "bộ luật OWASP có sẵn" → ⚠ managed rule set "bỏ qua tham số gây cảnh báo giả" → ⚠ exclusion

⚠ Bốn hành động của một luật WAF Hành động
⚠ Allow ⚠ cho qua, KHÔNG xét luật sau
⚠ Block ⚠ chặn
⚠ Log ⚠ chỉ ghi nhật ký, vẫn xét tiếp
⚠ Redirect ⚠ chuyển hướng đi nơi khác
⚠ Triển khai WAF an toàn Bước
⚠ Bật Detection trước
⚠ Đọc nhật ký, tìm cảnh báo giả
⚠ Thêm exclusion cho trường hợp hợp lệ
⚠ Rồi mới chuyển sang Prevention
⚠ Với rate limit ⚠ đo lưu lượng thật trước khi đặt ngưỡng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Endpoint đăng nhập đã có rate limit chưa | | | Ngưỡng có dựa trên số liệu thật không | ⚠ đặt bừa là chặn nhầm người dùng | | WAF đang ở chế độ Detection hay Prevention | |

Và luật WAF tuỳ chỉnh đáng thêm nhất cho gần như mọi ứng dụng: giới hạn tần suất cho endpoint đăng nhập. Nó chặn được dò mật khẩu bằng một cấu hình duy nhất, không cần đụng tới mã ứng dụng.

Câu 45 Design, implement, and manage connectivity services (20-25%)

You have an Azure subscription named "Subscription2" which includes two Azure virtual networks (VNets) named VNet2 and VNet3. VNet2 has a VPN gateway named "VGW1I" and it uses static routing. There is a site-to-site (S2S) VPN connectivity established between VNet2 and your on-premises network. You have also configured a point-to-site (P2S) VPN connectivity to VNet2 on a computer system named "Client2" running Windows 11. Additionally, you have configured VNet peering between VNet2 and VNet3.

During verification, you noticed that you can connect to VNet3 from the on-premises network but not from Client2. You need to resolve this issue and make sure that Client2 can connect to VNet3.

What steps would you take to address this problem?

  1. A

    Select the option "Allow gateway transit" on VNet3.

  2. B

    Select the option "Allow gateway transit" for VNet2.

  3. C

    On VGW1 enable BGP.

  4. D

    On Client2, download and re-install the VPN client configuration package.

Xem giải thích

Đáp án

D — Trên Client2, tải về và cài lại gói cấu hình VPN client.

Vì sao đúng

⚠ Gói cấu hình VPN client chứa DANH SÁCH TUYẾN mà máy khách sẽ học được: | Nội dung gói cấu hình | Nội dung | |---|---| | ⚠ Địa chỉ gateway | | | ⚠ Chứng chỉ và thiết lập xác thực | | | ⚠ DANH SÁCH TUYẾN tới các mạng đích | ⚠ đây là phần quan trọng ở đây |

⚠ Vấn đề: ⚠ peering giữa VNet2 và VNet3 được tạo SAU KHI Client2 tải gói cấu hình. ⚠ Gói cũ không có tuyến tới VNet3, nên máy khách không biết đường đi.

⚠ Mạng tại chỗ → ⚠ VNet3   ⚠ ĐƯỢC — gateway biết tuyến qua peering
⚠ Client2      → ⚠ VNet3   ⚠ KHÔNG — gói cấu hình cũ thiếu tuyến
        ↓
⚠ Tải lại gói cấu hình  →  ⚠ máy khách học được tuyến mới

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

  • B ("Allow gateway transit" trên VNet2) — ⚠ cần thiết cho peering để VNet3 dùng gateway của VNet2, nhưng ở đây kết nối từ tại chỗ tới VNet3 đã hoạt động, chứng tỏ transit đã được cấu hình đúng.

  • A ("Allow gateway transit" trên VNet3) — ⚠ sai chiều; VNet3 là bên dùng gateway, nên nó cần "Use remote gateways".

  • C (bật BGP trên VGW1) — ⚠ gateway đang dùng định tuyến TĨNH; bật BGP là thay đổi lớn và không giải quyết vấn đề tuyến của máy khách.

Ghi nhớ

⚠ Bốn cờ của một VNet peering — nhớ theo chiều: | Cờ | Đặt ở đâu | Nghĩa | |---|---|---| | ⚠ Allow virtual network access | ⚠ cả hai | ⚠ cho lưu lượng qua lại | | ⚠ Allow forwarded traffic | ⚠ bên nhận | ⚠ nhận gói không bắt nguồn từ VNet kia | | ⚠ Allow gateway transit | ⚠ bên CÓ gateway | ⚠ chia sẻ gateway của mình | | ⚠ Use remote gateways | ⚠ bên KHÔNG có gateway | ⚠ dùng gateway của phía bên kia |

Từ khoá nhận diện:

"máy khách P2S không tới được VNet mới" → ⚠ tải lại gói cấu hình VPN client "spoke dùng gateway của hub" → ⚠ gateway transit + use remote gateways "tuyến tự lan truyền" → ⚠ cần BGP "peering không bắc cầu" → ⚠ A–B và B–C không cho A tới C

⚠ Khi nào PHẢI tải lại gói cấu hình client Khi nào
⚠ Thêm peering mới cho VNet
⚠ Đổi dải địa chỉ của VNet
⚠ Đổi loại xác thực hoặc giao thức đường hầm
⚠ Đổi dải địa chỉ cấp cho client
⚠ Với BGP ⚠ tuyến tự cập nhật, đỡ phải tải lại — đó là ưu thế của BGP
⚠ Vì sao lỗi này khó đoán Lý do
⚠ Từ tại chỗ thì thông, từ client thì không ⚠ hai đường học tuyến khác nhau
⚠ Không có thông báo lỗi rõ ràng ⚠ chỉ là không tới được
⚠ Cấu hình phía Azure trông hoàn toàn đúng
⚠ Manh mối ⚠ thay đổi nào xảy ra SAU khi client tải gói cấu hình

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Client tải gói cấu hình từ khi nào | ⚠ so với thời điểm tạo peering | | Bảng định tuyến trên máy client có tuyến tới VNet3 không | ⚠ route print trên Windows | | Có nên bật BGP để đỡ phải tải lại không | |

Và quy trình nên đưa vào tài liệu vận hành: mỗi lần thay đổi cấu trúc mạng, thông báo cho người dùng VPN tải lại gói cấu hình. Không có bước này thì mỗi lần thêm VNet lại phát sinh một loạt báo lỗi khó hiểu.

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

Azure Virtual WAN is a comprehensive networking solution that integrates various networking, routing, and security features, providing a unified operational interface. Please choose the statements below that accurately describe Azure Virtual WAN.

  1. A

    Every network connection has an association with a particular route table.

  2. B

    Multiple route tables can be linked to a single connection.

  3. C

    Multiple connections can be linked to a single route table.

  4. D

    It is not possible to associate two connections with the same route table.

  5. E

    To establish a connection, two route tables must be linked together.

Xem giải thích

Đáp án

A và C.

  • A — Mỗi kết nối mạng có liên kết với MỘT bảng định tuyến cụ thể.
  • C — NHIỀU kết nối có thể liên kết tới CÙNG một bảng định tuyến.

Vì sao đúng

⚠ Quan hệ giữa connection và route table là NHIỀU–MỘT: | Chiều | Quan hệ | |---|---| | ⚠ Một connection | ⚠ liên kết với ĐÚNG MỘT route table | | ⚠ Một route table | ⚠ phục vụ NHIỀU connection |

⚠ Route Table "Default"
   ├── ⚠ Connection VNet-A
   ├── ⚠ Connection VNet-B
   └── ⚠ Connection Site-VPN-1
⚠ Route Table "Isolated"
   └── ⚠ Connection VNet-C  →  ⚠ tách biệt với nhóm trên

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

  • B (nhiều route table gắn cho một connection) — ⚠ SAI; mỗi connection chỉ có một association.

  • D (không thể gắn hai connection vào cùng một route table) — ⚠ SAI, và mâu thuẫn trực tiếp với C.

  • E (phải liên kết hai route table với nhau mới tạo được connection) — ⚠ không có yêu cầu nào như vậy.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23192 trong lô này hỏi vì sao phải gắn connection với route table. ⚠ Câu này hỏi về QUAN HỆ SỐ LƯỢNG giữa chúng. Hai câu bổ sung nhau.

⚠ Hai khái niệm định tuyến của Virtual WAN — đừng lẫn: | Khái niệm | Câu hỏi nó trả lời | |---|---| | ⚠ Association | ⚠ connection này TRA ĐƯỜNG ở bảng nào — một bảng duy nhất | | ⚠ Propagation | ⚠ tuyến của connection này được GHI vào những bảng nào — có thể nhiều |

⚠ Chính sự bất đối xứng này tạo ra khả năng phân đoạn: ⚠ một spoke có thể tra đường ở bảng chung nhưng không lan truyền tuyến của mình sang bảng khác.

Từ khoá nhận diện:

"connection tra đường ở bảng nào" → ⚠ association, một-một "tuyến ghi vào bảng nào" → ⚠ propagation, một-nhiều "cách ly spoke với nhau" → ⚠ bảng riêng, không propagate chéo "mọi lưu lượng qua firewall ở hub" → ⚠ Secured Virtual Hub, propagate tuyến mặc định

⚠ Mẫu phân đoạn thường gặp Mẫu
⚠ Bảng Default ⚠ cho các spoke thông thường, thấy nhau
⚠ Bảng riêng cho nhóm nhạy cảm ⚠ chỉ thấy hub, không thấy spoke khác
⚠ Bảng None ⚠ không lan truyền tuyến của mình đi đâu cả
⚠ Kết hợp với NSG ⚠ hai lớp phân đoạn ở hai tầng khác nhau
⚠ Vì sao đây là điểm hay sai nhất trong Virtual WAN Lý do
⚠ Cấu hình trông đúng nhưng kết nối không như mong đợi
⚠ Không có thông báo lỗi ⚠ chỉ là gói tin không tới nơi
⚠ Phải đọc CẢ association lẫn propagation mới hiểu
⚠ Công cụ hỗ trợ ⚠ xem effective routes của từng connection

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi connection đang associate với bảng nào | | | Tuyến của nó propagate sang những bảng nào | | | Effective routes có đúng như thiết kế không | ⚠ kiểm tra, đừng suy luận |

Và cách gỡ rối nhanh nhất khi lưu lượng trong Virtual WAN đi sai đường: xem effective routes của connection đó. Nó cho biết chính xác bảng định tuyến đang nói gì, thay vì phải suy diễn từ hai lớp cấu hình association và propagation.

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

As an Azure administrator, your responsibility involves setting up Azure Private DNS Resolver within your organization's virtual network (VNet). The VNet is configured with an IP address range of 10.0.0.0/16, and there's an Azure DNS zone named getcloudskills.com designated for private DNS resolution. What is one necessary action you must take when configuring Azure Private DNS Resolver in this particular situation?

  1. A

    Establish a private endpoint for Azure DNS within the VNet where the resources requiring DNS query resolution are located.

  2. B

    Establish an Azure DNS zone within the same VNet as the resources needing DNS query resolution.

  3. C

    Assign a public IP address to the virtual machine requiring DNS query resolution.

  4. D

    Adjust the DNS server settings on the virtual machine to utilize the IP address of Azure DNS.

Xem giải thích

Đáp án

A — Tạo một private endpoint cho Azure DNS trong chính mạng ảo chứa tài nguyên cần phân giải truy vấn DNS.

Vì sao đúng

⚠ Nguyên tắc của phân giải tên riêng tư: | Yêu cầu | Nội dung | |---|---| | ⚠ Truy vấn DNS phải đi qua đường RIÊNG | ⚠ không ra Internet công cộng | | ⚠ Endpoint riêng đặt trong chính VNet có tài nguyên | ⚠ để tài nguyên tới được bằng IP riêng | | ⚠ Vùng DNS riêng liên kết với VNet đó | |

⚠ Máy ảo trong VNet
        ↓ ⚠ truy vấn DNS
⚠ Endpoint riêng trong CÙNG VNet
        ↓
⚠ Vùng DNS riêng getcloudskills.com
        ↓
⚠ Trả về IP RIÊNG

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

  • B (tạo vùng DNS trong cùng VNet) — ⚠ vùng DNS riêng là tài nguyên TOÀN CẦU, không "nằm trong" một VNet; nó LIÊN KẾT với VNet.

  • C (gán IP công cộng cho máy ảo) — ⚠ đi ngược mục đích; phân giải riêng tư là để không cần ra Internet.

  • D (đổi DNS server trên máy ảo trỏ tới IP của Azure DNS) — ⚠ không đủ; nếu chưa có endpoint riêng và liên kết vùng thì truy vấn vẫn không tới được vùng riêng.

Ghi nhớ

⚠ Ba lựa chọn phân giải tên trong VNet: | Lựa chọn | Khi nào | |---|---| | ⚠ DNS mặc định của Azure (168.63.129.16) | ⚠ chỉ phân giải trong CÙNG một VNet | | ⚠ Azure Private DNS zone | ⚠ tên riêng, phân giải được ở mọi VNet đã liên kết | | ⚠ Azure DNS Private Resolver | ⚠ cầu nối phân giải HAI CHIỀU giữa tại chỗ và Azure |

⚠ Azure DNS Private Resolver giải quyết bài toán gì: | Bài toán | Nội dung | |---|---| | ⚠ Máy tại chỗ cần phân giải tên riêng của Azure | ⚠ inbound endpoint | | ⚠ Máy Azure cần phân giải tên của mạng tại chỗ | ⚠ outbound endpoint và forwarding ruleset | | ⚠ Trước khi có nó | ⚠ phải tự dựng máy ảo làm DNS forwarder | | ⚠ Nay | ⚠ dịch vụ được quản lý, sẵn sàng cao sẵn có |

Từ khoá nhận diện:

"phân giải tên riêng trong VNet" → ⚠ Private DNS zone "tại chỗ hỏi tên của Azure" → ⚠ DNS Private Resolver inbound endpoint "Azure hỏi tên của tại chỗ" → ⚠ outbound endpoint và forwarding rule "phân giải chéo giữa các VNet peering" → ⚠ DNS mặc định KHÔNG làm được

⚠ Điều kiện để Private Endpoint hoạt động đúng Điều kiện
⚠ Có Private DNS zone đúng tên ⚠ ví dụ privatelink.blob.core.windows.net
⚠ Zone đã liên kết với VNet của tài nguyên
⚠ Bản ghi A trỏ tên về IP riêng ⚠ thường tạo tự động
⚠ Thiếu một bước ⚠ tên vẫn phân giải ra IP công cộng, lưu lượng đi đường cũ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Từ trong VNet, nslookup trả về IP riêng hay công cộng | ⚠ kiểm chứng nhanh nhất | | Private DNS zone đã liên kết đúng VNet chưa | | | Máy ảo đang dùng DNS server nào | |

Và mắt xích yếu nhất trong mọi kiến trúc Private Endpoint vẫn là DNS. Endpoint dựng đúng, NSG đúng, quyền đúng — nhưng nếu tên miền vẫn phân giải ra địa chỉ công cộng thì mọi công sức đó không đổi được đường đi của gói tin.

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

Utilizing PowerShell, you are required to fetch an already existing workspace titled "Workspace" within a resource group named "Workspace." Which cmdlet from the options provided would you employ for this task?

  1. A

    Get-AzNetworkSecurityGroup

  2. B

    Get-AzOperationallnsightsWorkspace

  3. C

    Retrieve-AzOperationallnsightsWorkspace

  4. D

    Get-AzWorkspace

  5. E

    New-AzOperationallnsightsWorkspace

Xem giải thích

Đáp án

B — Get-AzOperationalInsightsWorkspace.

Vì sao đúng

⚠ Tên cmdlet phản ánh tên nội bộ của dịch vụ: | Thành phần | Nội dung | |---|---| | ⚠ Get- | ⚠ động từ để đọc | | ⚠ Az | ⚠ mô-đun hiện hành | | ⚠ OperationalInsights | ⚠ TÊN NỘI BỘ của Log Analytics | | ⚠ Workspace | ⚠ đối tượng cần lấy |

⚠ Get-AzOperationalInsightsWorkspace -ResourceGroupName "Workspace" -Name "Workspace"

⚠ Ghi nhớ quan trọng: ⚠ Log Analytics vẫn mang tên OperationalInsights trong nhà cung cấp tài nguyên Microsoft.OperationalInsights — ⚠ tên hiển thị đổi, tên API thì không.

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

  • D (Get-AzWorkspace) — ⚠ không tồn tại; quá chung chung.

  • C (Retrieve-AzOperationalInsightsWorkspace) — ⚠ Retrieve KHÔNG phải động từ chuẩn của PowerShell.

  • E (New-AzOperationalInsightsWorkspace) — ⚠ có thật nhưng để TẠO MỚI, đề yêu cầu lấy cái đã có.

  • A (Get-AzNetworkSecurityGroup) — ⚠ lấy NSG, không liên quan.

Ghi nhớ

⚠ Đối chiếu: ⚠ đây là câu PowerShell thứ SÁU trong lô — cùng với #23198, #23203, #23207, #23211, #23220. ⚠ Lô 172 kiểm tra quy ước PowerShell rất dày.

Câu Quy ước
⚠ #23198 ⚠ -ResourceGroupName
⚠ #23203 ⚠ Remove- để xoá
⚠ #23207 ⚠ Get- và -ListAvailable
⚠ #23211 ⚠ New- để tạo
⚠ #23220 ⚠ Get-, tiền tố Az
⚠ #23226 (câu này) ⚠ Get-, và tên nội bộ OperationalInsights

⚠ Vài tên nội bộ khác biệt với tên hiển thị: | Tên hiển thị | Tên trong API và cmdlet | |---|---| | ⚠ Log Analytics | ⚠ OperationalInsights | | ⚠ Microsoft Entra ID | ⚠ AzureAD, và Microsoft.AAD ở một số chỗ | | ⚠ Microsoft Defender for Cloud | ⚠ Security | | ⚠ Azure Monitor | ⚠ Insights | | ⚠ Vì thế | ⚠ đổi tên thương mại KHÔNG kéo theo đổi tên API |

Từ khoá nhận diện:

"Log Analytics workspace" → ⚠ OperationalInsights "đọc, lấy" → ⚠ Get- "tạo mới" → ⚠ New- "Retrieve-, Delete-, Create-" → ⚠ KHÔNG phải động từ chuẩn

⚠ Log Analytics workspace dùng để làm gì Việc
⚠ Nơi lưu nhật ký của Azure Monitor
⚠ Truy vấn bằng KQL
⚠ Đích của diagnostic settings
⚠ Nền của Microsoft Sentinel
⚠ Chi phí ⚠ tính theo GB nhập vào và thời gian giữ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức có bao nhiêu workspace | ⚠ quá nhiều thì khó truy vấn chéo | | Thời gian giữ dữ liệu đặt bao lâu | ⚠ ảnh hưởng trực tiếp tới chi phí | | Có nguồn nào đang nhập log không cần thiết không | |

Và mẹo tiết kiệm nhiều công sức nhất khi làm việc với Azure PowerShell: dùng Get-Command và tab completion thay vì đoán tên cmdlet. Tên nội bộ của dịch vụ thường không giống tên thương mại, và đoán gần như luôn sai.

Câu 49

Which PowerShell command should be used to create a new route for traffic destined for an Azure Storage IP prefix towards a virtual appliance?

  1. A

    New-AzRouteTable

  2. B

    Get-AzRouteTable

  3. C

    Set-AzRouteTable

  4. D

    New-AzRouteConfig

  5. E

    az network route-table route create

Xem giải thích

Đáp án

D — New-AzRouteConfig.

Vì sao đúng

⚠ Phân biệt hai cấp đối tượng: | Đối tượng | Cmdlet | Vai trò | |---|---|---| | ⚠ Route table | ⚠ New-AzRouteTable | ⚠ cái BẢNG chứa nhiều tuyến | | ⚠ Route (một tuyến) | ⚠ New-AzRouteConfig | ⚠ một DÒNG trong bảng đó |

⚠ Đề hỏi tạo MỘT TUYẾN mới cho lưu lượng tới dải IP của Azure Storage đi về thiết bị ảo → ⚠ đó là một route, không phải một route table.

⚠ $route = New-AzRouteConfig -Name "ToStorage" `
       -AddressPrefix "20.150.0.0/16" `
       -NextHopType VirtualAppliance `
       -NextHopIpAddress "10.0.1.4"
⚠ New-AzRouteTable -Name "RT-Hub" -ResourceGroupName "RG" -Location "eastasia" -Route $route

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

  • A (New-AzRouteTable) — ⚠ tạo cả BẢNG, không phải một tuyến.

  • B (Get-AzRouteTable) — ⚠ đọc bảng đã có.

  • C (Set-AzRouteTable) — ⚠ lưu thay đổi vào bảng đã có; thường dùng SAU khi đã thêm route.

  • E (az network route-table route create) — ⚠ là Azure CLI, đề hỏi PowerShell.

Ghi nhớ

⚠ Năm loại next hop của một tuyến: | Loại | Nội dung | |---|---| | ⚠ VirtualAppliance | ⚠ gửi tới IP của NVA hoặc Azure Firewall | | ⚠ VirtualNetworkGateway | ⚠ gửi tới VPN hoặc ExpressRoute gateway | | ⚠ VnetLocal | ⚠ trong chính mạng ảo | | ⚠ Internet | ⚠ ra Internet | | ⚠ None | ⚠ BỎ gói tin — dùng để chặn hoàn toàn một dải |

⚠ Thứ tự ưu tiên định tuyến của Azure: | Thứ tự | Nguồn tuyến | |---|---| | ⚠ 1 | ⚠ User-defined route — UDR của bạn | | ⚠ 2 | ⚠ Tuyến BGP học được | | ⚠ 3 | ⚠ Tuyến hệ thống mặc định | | ⚠ Trong cùng một nhóm | ⚠ tiền tố CỤ THỂ hơn thắng — longest prefix match |

Từ khoá nhận diện:

"tạo một tuyến" → ⚠ New-AzRouteConfig "tạo bảng định tuyến" → ⚠ New-AzRouteTable "buộc lưu lượng qua firewall" → ⚠ UDR với next hop VirtualAppliance "chặn hẳn một dải" → ⚠ next hop None

⚠ Điều kiện để NVA nhận và chuyển tiếp gói Điều kiện
⚠ Bật IP forwarding trên card mạng của NVA ⚠ bước hay bị quên nhất
⚠ NSG cho phép lưu lượng đi qua
⚠ Bảng định tuyến phải gắn vào SUBNET ⚠ tạo bảng thôi chưa đủ
⚠ Thiếu một bước ⚠ gói tin bị bỏ, không có thông báo lỗi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng định tuyến đã gắn vào subnet chưa | | | NVA đã bật IP forwarding chưa | | | Effective routes của card mạng có đúng như thiết kế không | ⚠ Network Watcher cho xem trực tiếp |

Và ba bước phải làm đủ khi định tuyến qua một thiết bị ảo: tạo tuyến, gắn bảng vào subnet, bật IP forwarding trên NVA. Thiếu bước nào cũng dẫn tới cùng một triệu chứng — gói tin biến mất mà không có lỗi nào được ghi lại.

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

You can seamlessly connect two or more Virtual Networks in Azure using Virtual network peering. Select all applicable benefits:

  1. A

    A fast and efficient connection with minimal delays between different virtual network resources.

  2. B

    A high-bandwidth, high-latency connection that exists between the resources in different virtual networks

  3. C

    There may be significant downtime to resources in virtual networks during or after peering development.

  4. D

    The ability to peer virtual networks created through the Azure Resource Manager.

  5. E

    The ability of resources in one virtual network to communicate with resources in another virtual network.

Xem giải thích

Đáp án

A, D và E.

  • A — Kết nối nhanh và hiệu quả, độ trễ tối thiểu giữa các tài nguyên ở những mạng ảo khác nhau.
  • D — Peering được các mạng ảo tạo qua Azure Resource Manager.
  • E — Tài nguyên ở mạng ảo này giao tiếp được với tài nguyên ở mạng ảo khác.

Vì sao đúng

⚠ Ba lợi ích cốt lõi của VNet peering: | Lợi ích | Nội dung | |---|---| | ⚠ Độ trễ thấp, băng thông cao | ⚠ đi qua backbone của Microsoft, KHÔNG qua Internet | | ⚠ Giao tiếp trực tiếp giữa tài nguyên | ⚠ như thể cùng một mạng | | ⚠ Hỗ trợ Resource Manager | ⚠ và cả peering giữa Resource Manager với Classic |

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

  • B (băng thông cao, ĐỘ TRỄ CAO) — ⚠ SAI ở vế sau; peering cho độ trễ THẤP.

  • C (có thể có thời gian ngừng đáng kể trong hoặc sau khi tạo peering) — ⚠ SAI; ⚠ tạo peering KHÔNG gây gián đoạn cho tài nguyên đang chạy.

Ghi nhớ

⚠ Đối chiếu: ⚠ lô này có ba câu về VNet peering.

Câu Hỏi gì Khoá
⚠ #23179 ⚠ yêu cầu và GIỚI HẠN của peering ⚠ B và C
⚠ #23191 ⚠ peering có đáp ứng danh sách yêu cầu không ⚠ Yes
⚠ #23228 (câu này) ⚠ LỢI ÍCH của peering ⚠ A, D, E
⚠ Ba câu ⚠ nhất quán — vẽ đủ cả mặt mạnh lẫn giới hạn

⚠ Bảng tổng hợp: peering làm được gì và không làm được gì: | Làm được | KHÔNG làm được | |---|---| | ⚠ Nối VNet khác vùng | ⚠ nối VNet có dải IP chồng lấn | | ⚠ Nối VNet khác subscription | ⚠ bắc cầu — A–B, B–C không cho A tới C | | ⚠ Nối VNet khác tenant | ⚠ phân giải tên chéo bằng DNS mặc định | | ⚠ Không cần gateway | ⚠ global peering không hỗ trợ Basic SKU | | ⚠ Không gián đoạn khi tạo | |

Từ khoá nhận diện:

"độ trễ thấp, băng thông cao, không gián đoạn" → ⚠ lợi ích của peering "dải IP chồng lấn" → ⚠ giới hạn — không peering được "spoke này tới spoke kia" → ⚠ cần định tuyến qua hub "phân giải tên giữa các VNet" → ⚠ cần Private DNS zone

⚠ Chi phí của peering Chi phí
⚠ Tính theo dữ liệu VÀO và RA ⚠ cả hai chiều đều tính
⚠ Global peering đắt hơn peering cùng vùng
⚠ Không tính phí giờ như gateway
⚠ Với lưu lượng lớn giữa các vùng ⚠ nên đưa vào tính toán chi phí từ đầu

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

Và lý do peering là công cụ mặc định để nối mạng ảo trên Azure: bật lên là xong, không gateway, không chặng trung gian, không gián đoạn dịch vụ. Điều kiện duy nhất — và cũng là điều phải lo từ trước — là kế hoạch địa chỉ IP không được chồng lấn.