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

Tìm thấy 99 câu.

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

Your team is currently uncertain about which Azure service to use to connect virtual networks within the same Azure region. You have provided them with the following requirements:

  • The ability to transfer data between virtual networks across Azure Active Directory tenants, Azure subscriptions, Azure regions, and deployment models.

  • The ability for resources in one virtual network to communicate with resources in a different virtual network.

  • No downtime for resources in the virtual network.

  • Low-latency, high-bandwidth connection between resources in different virtual networks.

After much brainstorming and discussion, the team has finally decided to use the virtual network peering service. The question is whether this service will meet all the requirements mentioned above.

  1. A

    Yes

  2. B

    No

Xem giải thích

Đáp án

A — Có, dịch vụ này đáp ứng đủ mọi yêu cầu.

Vì sao đúng

⚠ Đối chiếu từng yêu cầu với khả năng của VNet peering: | Yêu cầu | Peering đáp ứng | |---|---| | ⚠ Truyền dữ liệu xuyên tenant, subscription, vùng, mô hình triển khai | ⚠ ĐƯỢC — cả bốn ranh giới | | ⚠ Tài nguyên hai VNet giao tiếp với nhau | ⚠ ĐƯỢC — đây là mục đích chính | | ⚠ Không gián đoạn tài nguyên | ⚠ ĐƯỢC — tạo peering không làm dừng gì | | ⚠ Độ trễ thấp, băng thông cao | ⚠ ĐƯỢC — đi qua backbone Microsoft |

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

  • B (Không) — ⚠ peering đáp ứng được toàn bộ danh sách này.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này GẦN TRÙNG với câu #23191 ở lô trước — cùng danh sách yêu cầu, chỉ khác vài từ mở đầu.

Câu Đề bài Khoá
⚠ #23191 ⚠ "Đội của bạn khó quyết định dùng dịch vụ nào..." ⚠ A — Yes
⚠ #23229 (câu này) ⚠ "Đội của bạn đang phân vân dùng dịch vụ nào..." ⚠ A — Yes
⚠ Danh sách yêu cầu ⚠ giống hệt nhau
⚠ Chữ cái ⚠ TRÙNG nhau, cùng là A
⚠ Không mâu thuẫn ⚠ giữ nguyên cả hai khoá

⚠ Cùng với #23179 (giới hạn của peering) và #23228 (lợi ích của peering), đây là câu thứ tư về VNet peering trong hai lô gần nhau.

⚠ Peering vượt được những ranh giới nào: | Ranh giới | Được không | |---|---| | ⚠ Khác subscription | ⚠ ĐƯỢC | | ⚠ Khác tenant Entra ID | ⚠ ĐƯỢC | | ⚠ Khác vùng | ⚠ ĐƯỢC — global VNet peering | | ⚠ Khác mô hình triển khai | ⚠ ĐƯỢC — Resource Manager và Classic |

⚠ Nhưng vẫn có giới hạn cứng: | Giới hạn | Nội dung | |---|---| | ⚠ Dải IP KHÔNG được chồng lấn | ⚠ điều kiện tiên quyết | | ⚠ KHÔNG bắc cầu | ⚠ A–B và B–C không cho A tới C | | ⚠ Phải thiết lập ở CẢ HAI phía | | | ⚠ Global peering không hỗ trợ Basic SKU | |

Từ khoá nhận diện:

"nối hai VNet, độ trễ thấp, không gateway" → ⚠ VNet peering "spoke này nói với spoke kia" → ⚠ cần định tuyến qua hub "nối mạng tại chỗ vào Azure" → ⚠ VPN Gateway hoặc ExpressRoute "nhiều site, nhiều vùng, quản lý tập trung" → ⚠ Virtual WAN

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Peering đã Connected ở CẢ hai phía chưa | ⚠ một phía là trạng thái Initiated | | Kế hoạch địa chỉ IP có chồng lấn không | | | Chi phí truyền dữ liệu giữa các vùng là bao nhiêu | |

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

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

You are an Azure network administrator and you are currently configuring DNS settings within a VNet. A junior team member has approached you with a question that needs to be answered. The question is whether the statement "Azure automatically updates DNS server settings for all virtual machines and role instances within the VNet when configuring custom DNS settings" is true or false.

  1. A

    True

  2. B

    False

Xem giải thích

Đáp án

B — Sai.

Vì sao đúng

⚠ Đổi cài đặt DNS của VNet KHÔNG tự động áp lên máy đang chạy: | Bước | Nội dung | |---|---| | ⚠ Bạn đổi DNS server của VNet | ⚠ cấu hình lưu ngay | | ⚠ Máy ảo đang chạy | ⚠ VẪN dùng cấu hình DNS CŨ | | ⚠ Phải KHỞI ĐỘNG LẠI máy ảo | ⚠ hoặc gia hạn thuê DHCP | | ⚠ Máy tạo MỚI sau đó | ⚠ nhận cấu hình mới ngay |

⚠ Lý do kỹ thuật: ⚠ máy ảo nhận địa chỉ DNS server qua DHCP, và nó chỉ hỏi lại DHCP khi khởi động lại hoặc khi thời hạn thuê hết.

⚠ Đổi DNS của VNet
        ↓
⚠ Máy CŨ  →  ⚠ vẫn dùng DNS cũ tới khi khởi động lại
⚠ Máy MỚI →  ⚠ dùng DNS mới ngay

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

  • A (Đúng) — ⚠ SAI; đây là hiểu nhầm rất phổ biến và là nguyên nhân của nhiều sự cố khó lần.

Ghi nhớ

⚠ Cách buộc máy nhận cấu hình DNS mới: | Hệ điều hành | Lệnh | |---|---| | ⚠ Windows | ⚠ ipconfig /renew, hoặc khởi động lại | | ⚠ Linux | ⚠ khởi động lại dịch vụ mạng, hoặc khởi động lại máy | | ⚠ Cách chắc chắn nhất | ⚠ khởi động lại máy ảo |

⚠ Hai mức cấu hình DNS trên Azure: | Mức | Nội dung | |---|---| | ⚠ Cấp VNet | ⚠ áp cho mọi máy trong VNet đó | | ⚠ Cấp card mạng | ⚠ ghi đè cấu hình của VNet cho riêng máy đó | | ⚠ Ưu tiên | ⚠ cấu hình ở card mạng THẮNG cấu hình ở VNet |

Từ khoá nhận diện:

"đổi DNS xong máy vẫn dùng cái cũ" → ⚠ phải khởi động lại "phân giải tên riêng trong VNet" → ⚠ Private DNS zone "DNS mặc định của Azure" → ⚠ 168.63.129.16 "phân giải hai chiều với mạng tại chỗ" → ⚠ Azure DNS Private Resolver

⚠ Bẫy hay gặp khi đổi DNS tuỳ chỉnh Bẫy
⚠ Đổi xong tưởng đã xong, không khởi động lại ⚠ một nửa số máy dùng DNS cũ, một nửa dùng mới
⚠ DNS server tự dựng chết ⚠ cả VNet mất phân giải tên
⚠ Quên forward về 168.63.129.16 ⚠ DNS tự dựng không phân giải được tên nội bộ Azure
⚠ Card mạng có cấu hình riêng bị bỏ quên ⚠ nó ghi đè cấu hình VNet
⚠ Thực hành tốt với DNS tuỳ chỉnh Thực hành
⚠ Dùng ít nhất HAI DNS server ⚠ tránh điểm hỏng đơn lẻ
⚠ Forward truy vấn không xử lý được về 168.63.129.16
⚠ Cân nhắc DNS Private Resolver thay vì tự dựng ⚠ được quản lý, sẵn sàng cao sẵn có
⚠ Có kế hoạch khởi động lại máy sau khi đổi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy ảo đang thực sự dùng DNS nào | ⚠ ipconfig /all hoặc resolvectl | | Có card mạng nào có cấu hình DNS riêng không | | | DNS server tự dựng có dự phòng không | |

Và loại sự cố khó lần nhất sau khi đổi DNS: một nửa hạ tầng đã nhận cấu hình mới, nửa còn lại thì chưa. Triệu chứng là lỗi xuất hiện ngẫu nhiên tuỳ máy nào phục vụ — và cấu hình trên Portal thì trông hoàn toàn đúng.

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

Your company is planning to deploy a new application on a fleet of Azure virtual machines (VMs) in the virtual network called "vNet1". Your boss wants you to ensure that the application is scalable and robust, and has provided the following requirements:

  • Path-based loading at the global level.

  • Traffic should be load-balanced within vNet1.

  • 100% TLS/SSL offload.

  • HTTP requests must be routed within vNet1.

  • Session affinity should be supported.

To meet these requirements, what actions should you take? (Choose two answers.)

  1. A

    To improve security, you must deploy an Application Gateway in front of the virtual machines (VMs) in vNet1.

  2. B

    Enable Azure Front Door.

  3. C

    Enable Azure Firewall.


  4. D

    Enable global load balancing.


Xem giải thích

Đáp án

A và B.

  • A — Triển khai Application Gateway trước các máy ảo trong vNet1.
  • B — Bật Azure Front Door.

Vì sao đúng

⚠ Yêu cầu chia làm hai tầng, cần hai dịch vụ: | Yêu cầu | Dịch vụ đáp ứng | |---|---| | ⚠ Định tuyến theo đường dẫn ở mức TOÀN CẦU | ⚠ Front Door | | ⚠ Cân bằng tải TRONG vNet1 | ⚠ Application Gateway | | ⚠ Giảm tải TLS/SSL 100% | ⚠ cả hai đều làm được | | ⚠ Định tuyến yêu cầu HTTP trong vNet1 | ⚠ Application Gateway | | ⚠ Hỗ trợ session affinity | ⚠ Application Gateway — ghim bằng cookie |

⚠ Người dùng toàn cầu
        ↓
⚠ Front Door       →  ⚠ định tuyến theo đường dẫn ở biên, TLS offload
        ↓
⚠ Application Gateway trong vNet1  →  ⚠ định tuyến nội vùng, session affinity
        ↓
⚠ Các máy ảo

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

  • C (Azure Firewall) — ⚠ tường lửa, không cân bằng tải và không định tuyến theo đường dẫn.

  • D (bật global load balancing) — ⚠ không phải một dịch vụ cụ thể; cân bằng tải toàn cầu chính là Front Door hoặc Traffic Manager.

Ghi nhớ

⚠ Bốn dịch vụ cân bằng tải — chọn theo hai trục: | | Trong một vùng | Toàn cầu | |---|---|---| | ⚠ Tầng 4 | ⚠ Load Balancer | ⚠ Traffic Manager (DNS) | | ⚠ Tầng 7 | ⚠ Application Gateway | ⚠ Front Door |

Từ khoá nhận diện:

"toàn cầu + theo đường dẫn" → ⚠ Front Door "trong một VNet + theo đường dẫn" → ⚠ Application Gateway "session affinity bằng cookie" → ⚠ Application Gateway hoặc Front Door "session affinity theo IP" → ⚠ Load Balancer, thô hơn

⚠ TLS offload — vì sao đáng làm Lý do
⚠ Máy chủ sau không tốn CPU giải mã
⚠ Chứng chỉ quản lý một chỗ
⚠ WAF đọc được nội dung để kiểm tra ⚠ mã hoá thì không kiểm tra được
⚠ Cần mã hoá cả chặng sau ⚠ bật end-to-end TLS, mã hoá lại từ gateway tới backend
⚠ Có cần cả hai lớp không Cân nhắc
⚠ Người dùng ở nhiều châu lục ⚠ có, Front Door đáng giá
⚠ Chỉ một vùng, người dùng nội địa ⚠ Application Gateway là đủ
⚠ Mỗi lớp thêm độ trễ và chi phí
⚠ Nguyên tắc ⚠ 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 thật sự phân tán tới đâu | ⚠ quyết định có cần Front Door không | | Ứng dụng có bắt buộc session affinity không | ⚠ hay chỉ do thiết kế cũ | | WAF nên đặt ở lớp nào | ⚠ càng ngoài càng chặn sớm |

Và cách đọc nhanh đề bài kiểu này: mỗi cụm từ trong danh sách yêu cầu thường ứng với một dịch vụ. "Toàn cầu" gọi Front Door, "trong VNet" gọi Application Gateway — hai cụm đó đã cho ra hai đáp án.

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

You're designing your company's virtual networks with a focus on cost control and high availability. Although general cost-saving policies are in place, your design must ensure resource availability in the event of a complete data center outage.

Which cost-saving policy would need to be overridden to meet this requirement?

  1. A

    Only establish peering connections between virtual networks when it is necessary.

  2. B

    Whenever possible, try to keep all resources within a single region.

  3. C

    When designing multi-regional deployments, ensuring they are independent of any specific region is important.

  4. D

    It is better to deploy resources in availability sets rather than deploying them in multiple availability zones to ensure high availability and fault tolerance of your applications.

Xem giải thích

Đáp án

A — "Chỉ tạo peering giữa các mạng ảo khi thật sự cần thiết"

Vì sao đúng

Câu hỏi tìm chính sách tiết kiệm nào phải bị bỏ qua để đạt yêu cầu chịu được sự cố mất trọn một cơ sở dữ liệu. Muốn vậy thì tài nguyên phải nằm ở nhiều vị trí, và các mạng ở những vị trí đó phải nối được với nhau — nghĩa là phải tạo peering.

Peering có tính phí theo lượng dữ liệu truyền, nên chính sách hạn chế nó là một biện pháp tiết kiệm hợp lý trong điều kiện bình thường. Nhưng khi tính sẵn sàng là ràng buộc cứng thì nó phải nhường.

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

  • B. Giữ mọi tài nguyên trong một khu vực — hợp lý về chi phí, và vẫn giữ được nếu bạn dùng nhiều availability zone trong cùng khu vực.
  • C. Thiết kế đa vùng độc lập với từng khu vực cụ thể — đây là thực hành tốt cho tính sẵn sàng, không phải chính sách cần bỏ.

Một điểm cần nói thẳng

Phương án D — "dùng availability set thay vì availability zone" — cũng mâu thuẫn với yêu cầu của đề, vì availability set chỉ bảo vệ trong một trung tâm dữ liệu, còn availability zone mới chịu được mất trọn một cơ sở. Nếu chấm theo mức độ xung đột thì D cũng là ứng viên. Điều đáng nhớ ở đây là phân biệt phạm vi bảo vệ của set và của zone, vì đó là thứ được hỏi đi hỏi lại.

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

You want to establish a Hub-and-Spoke VNet peering connection between two existing VNets (VNet1 and VNet2) in the East US region. Your objective is to allow resources in both VNets to communicate with each other without using a network virtual appliance. You have deployed VNet3 in the same region to serve as a hub between the other VNets to achieve this. You plan to use a VPN virtual network gateway to allow VNet1 and VNet2 to communicate with each other through VNet3.

Which VNet peering connections should be configured to allow all forwarded traffic? Please select two answers.

  1. A

    A connection between VNet1 and VNet3 with peering enabled and traffic forwarding enabled.

  2. B

    A peering connection between VNet2 and VNet3, with traffic forwarding enabled.

  3. C

    Peering connections should be directed only to VNet3, which serves as the hub.

  4. D

    Only peering connections that are directed to VNet1 and VNet2 are allowed as spokes.

Xem giải thích

Đáp án

A và B.

  • A — Peering giữa VNet1 và VNet3, bật peering và bật chuyển tiếp lưu lượng.
  • B — Peering giữa VNet2 và VNet3, bật chuyển tiếp lưu lượng.

Vì sao đúng

⚠ Peering KHÔNG bắc cầu — đây là điểm mấu chốt:

⚠ VNet1 ←peering→ VNet3 ←peering→ VNet2
   ⚠ VNet1 KHÔNG tự động nói chuyện được với VNet2

⚠ Để lưu lượng đi XUYÊN QUA hub, cần bật "Allow forwarded traffic" ở CẢ HAI peering: | Cờ | Nghĩa | |---|---| | ⚠ Allow forwarded traffic | ⚠ chấp nhận gói tin KHÔNG bắt nguồn từ VNet đối tác trực tiếp | | ⚠ Không bật | ⚠ VNet3 nhận gói từ VNet1 nhưng VNet2 TỪ CHỐI vì nguồn lạ |

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

  • C (chỉ hướng peering về VNet3) — ⚠ mô tả mơ hồ, không nêu cờ chuyển tiếp lưu lượng vốn là điều kiện bắt buộc.

  • D (chỉ cho phép peering hướng tới VNet1 và VNet2) — ⚠ ngược mô hình hub-and-spoke; hub là VNet3.

Ghi nhớ

⚠ Bốn cờ của một peering — nhớ theo VAI TRÒ: | 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 gói xuyên qua | ⚠ nhận gói nguồn từ VNet thứ ba | | ⚠ 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 phía kia |

⚠ Nhưng bật cờ thôi CHƯA ĐỦ để spoke nói chuyện với spoke: | Còn cần | Nội dung | |---|---| | ⚠ Thiết bị định tuyến ở hub | ⚠ NVA, Azure Firewall, hoặc VPN gateway | | ⚠ User-defined route ở các spoke | ⚠ trỏ lưu lượng về thiết bị đó | | ⚠ Trong đề này | ⚠ VPN gateway ở VNet3 đóng vai trò đó |

Từ khoá nhận diện:

"lưu lượng đi xuyên qua VNet trung gian" → ⚠ allow forwarded traffic "spoke dùng gateway của hub" → ⚠ gateway transit + use remote gateways "spoke này tới spoke kia" → ⚠ cần thiết bị định tuyến ở hub và UDR "peering không bắc cầu" → ⚠ nguyên tắc gốc phải nhớ

⚠ Vì sao mô hình hub-and-spoke phổ biến Lý do
⚠ Một điểm kiểm soát lưu lượng ⚠ firewall, giám sát, nhật ký ở hub
⚠ Dùng chung gateway, tiết kiệm
⚠ Dễ mở rộng — thêm spoke là thêm một peering
⚠ Cách ly spoke với nhau khi cần

Ba việc kiểm chứng: | Việc | Cách | |---|---| | "Allow forwarded traffic" đã bật ở đúng phía chưa | | | Có UDR trỏ lưu lượng spoke-to-spoke về hub không | | | Effective routes của card mạng có đúng thiết kế không | ⚠ Network Watcher cho xem |

Và lý do mô hình hub-and-spoke hay hỏng ở đúng bước cuối: bật cờ chuyển tiếp lưu lượng mới chỉ cho phép gói ĐI QUA, chưa dạy nó ĐI ĐƯỜNG NÀO. Thiếu user-defined route thì gói vẫn không rời khỏi spoke.

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

Your on-site network is linked to VNet 1 via a VPN gateway. VNet 1 is interconnected with VNet 2, VNet 3, and VNet 4, all of which are situated in the same region, through individual VNet peering connections. VNet 1 is a routing bridge between your on-site network and VNets 2, 3, and 4. What is the term for this type of VNet setup?

  1. A

    Hub-and-spoke network.

  2. B

    VNet-to-VNet connection.

  3. C

    Global VNet Peering.

  4. D

    Site-to-Site VPN connections.

Xem giải thích

Đáp án

A — Mạng hub-and-spoke (trung tâm và nan hoa).

Vì sao đúng

⚠ Cấu trúc mô tả trong đề đúng là hub-and-spoke: | Vai trò | VNet | |---|---| | ⚠ Hub — trung tâm | ⚠ VNet1 — có VPN gateway, làm cầu định tuyến | | ⚠ Spoke — nan hoa | ⚠ VNet2, VNet3, VNet4 — peering riêng với hub |

        ⚠ Mạng tại chỗ
              ↓ ⚠ VPN gateway
        ⚠ VNet1 (HUB)
        ↙     ↓     ↘
⚠ VNet2   ⚠ VNet3   ⚠ VNet4

⚠ Đặc điểm nhận diện: ⚠ mọi spoke chỉ peering với hub, không peering với nhau, và mọi lưu lượng liên spoke hoặc ra tại chỗ đều đi qua hub.

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

  • B (VNet-to-VNet connection) — ⚠ là cách nối hai VNet bằng VPN gateway, không mô tả cấu trúc tổng thể.

  • C (Global VNet Peering) — ⚠ peering giữa các vùng KHÁC nhau; đề nói rõ mọi VNet ở cùng một vùng.

  • D (Site-to-Site VPN) — ⚠ chỉ là kết nối từ tại chỗ vào VNet1, một phần của bức tranh chứ không phải tên cấu trúc.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23233 trong lô này hỏi cách cấu hình hub-and-spoke (bật allow forwarded traffic ở cả hai peering). ⚠ Câu này hỏi TÊN GỌI của cấu trúc. Hai câu bổ sung nhau.

⚠ Lợi ích của hub-and-spoke: | Lợi ích | Nội dung | |---|---| | ⚠ Dùng chung gateway | ⚠ không phải dựng gateway cho từng spoke — tiết kiệm lớn | | ⚠ Một điểm kiểm soát | ⚠ firewall, giám sát, nhật ký đặt ở hub | | ⚠ Cách ly giữa các spoke | ⚠ mặc định spoke không thấy nhau | | ⚠ Dễ mở rộng | ⚠ thêm spoke là thêm một peering | | ⚠ Tách trách nhiệm | ⚠ đội mạng quản hub, đội ứng dụng quản spoke |

⚠ Đặt gì ở hub: | Thành phần | Vai trò | |---|---| | ⚠ VPN hoặc ExpressRoute gateway | ⚠ kết nối tại chỗ | | ⚠ Azure Firewall hoặc NVA | ⚠ kiểm soát lưu lượng tập trung | | ⚠ Azure Bastion | ⚠ quản trị máy ảo ở mọi spoke | | ⚠ DNS server hoặc Private DNS Resolver | | | ⚠ Dịch vụ dùng chung | |

Từ khoá nhận diện:

"một VNet trung tâm, nhiều VNet nhánh" → ⚠ hub-and-spoke "cùng vùng" → ⚠ VNet peering thường "khác vùng" → ⚠ global VNet peering "Microsoft quản lý hub giúp" → ⚠ Azure Virtual WAN

⚠ Tự dựng hub-and-spoke và Virtual WAN Chọn
⚠ Tự dựng ⚠ toàn quyền, tự viết UDR, phù hợp quy mô vừa
⚠ Virtual WAN ⚠ Microsoft quản lý định tuyến, phù hợp nhiều site và nhiều vùng
⚠ Điểm chung ⚠ cùng một ý tưởng kiến trúc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Spoke có peering trực tiếp với nhau không | ⚠ nếu có thì đã lệch khỏi mô hình | | Lưu lượng liên spoke có đi qua hub thật không | ⚠ kiểm tra UDR | | Firewall ở hub có nằm trên đường đi không | |

Và lý do hub-and-spoke là mẫu kiến trúc mạng phổ biến nhất trên Azure: nó đặt mọi thứ cần kiểm soát vào đúng một chỗ. Thêm một spoke thứ mười không làm phức tạp thêm phần kiểm soát ở hub.

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

Due to the pandemic, you and your colleagues have been asked to work from home. In order to establish a secure connection between your home computers and the company's Azure Virtual Network, what are the three necessary steps that you need to configure?

  1. A

    To establish a connection between your home computer and the Azure Virtual Network, you need to create a point-to-site VPN.

  2. B

    To secure your home computer's connection to a server, you need to create a client certificate and export it.

  3. C

    To ensure online privacy and security, it is recommended to install a VPN client on your home computer.

  4. D

    To ensure the best quality and lowest latency between your home computer and a server, configure Azure Express Route.

Xem giải thích

Đáp án

A, B và C.

  • A — Tạo VPN point-to-site để nối máy tính ở nhà vào mạng ảo Azure.
  • B — Tạo chứng chỉ máy khách và xuất nó ra.
  • C — Cài phần mềm VPN client lên máy tính ở nhà.

Vì sao đúng

⚠ Ba bước dựng P2S VPN với xác thực bằng chứng chỉ: | Bước | Nội dung | |---|---| | ⚠ 1. Cấu hình P2S trên VPN Gateway | ⚠ khai dải địa chỉ cho máy khách, giao thức, cách xác thực | | ⚠ 2. Tạo và xuất chứng chỉ | ⚠ chứng chỉ GỐC tải lên gateway, chứng chỉ CON cài lên máy khách | | ⚠ 3. Cài gói cấu hình VPN client | ⚠ tải từ Portal, cài lên máy |

⚠ Gateway: tải lên chứng chỉ GỐC (chỉ phần công khai)
        ↓
⚠ Máy khách: cài chứng chỉ CON (có khoá riêng)
        ↓
⚠ Máy khách: cài gói cấu hình VPN
        ↓
⚠ Kết nối

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

  • D (cấu hình ExpressRoute cho độ trễ thấp nhất) — ⚠ KHÔNG phù hợp: ⚠ ExpressRoute là kết nối RIÊNG cấp doanh nghiệp, cần hợp đồng với nhà cung cấp và đấu nối vật lý; ⚠ không phải giải pháp cho máy tính cá nhân ở nhà, và rất tốn kém.

Ghi nhớ

⚠ Ba cách xác thực P2S: | Cách | Đặc điểm | |---|---| | ⚠ Chứng chỉ Azure | ⚠ đơn giản, tự quản chứng chỉ | | ⚠ Microsoft Entra ID | ⚠ có MFA và Conditional Access, CHỈ dùng được với OpenVPN | | ⚠ RADIUS | ⚠ nối tới Active Directory tại chỗ |

⚠ Ba giao thức đường hầm: | Giao thức | Nền tảng | |---|---| | ⚠ OpenVPN | ⚠ Windows, macOS, Linux, iOS, Android | | ⚠ SSTP | ⚠ CHỈ Windows | | ⚠ IKEv2 | ⚠ Windows, macOS, Linux |

Từ khoá nhận diện:

"máy cá nhân nối vào VNet" → ⚠ Point-to-Site "cả mạng văn phòng nối vào" → ⚠ Site-to-Site "kết nối riêng băng thông cao" → ⚠ ExpressRoute, cho doanh nghiệp "muốn MFA cho người dùng VPN" → ⚠ Entra ID, bắt buộc OpenVPN

⚠ Điều cần chuẩn bị trước Điều
⚠ GatewaySubnet trong VNet ⚠ tên phải đúng như vậy
⚠ SKU gateway hỗ trợ P2S ⚠ Basic rất hạn chế
⚠ Dải địa chỉ cấp cho máy khách ⚠ KHÔNG chồng với VNet hay mạng nhà
⚠ Số kết nối đồng thời tuỳ SKU
⚠ Bẫy hay gặp khi làm việc từ xa Bẫy
⚠ Dải IP mạng gia đình trùng dải VNet ⚠ rất hay gặp với 192.168.1.0/24
⚠ Chứng chỉ hết hạn ⚠ phải gia hạn và phát lại
⚠ Thêm VNet mới sau khi phát gói cấu hình ⚠ phải tải lại gói
⚠ Không thu hồi được chứng chỉ của người nghỉ việc ⚠ cần dùng danh sách thu hồi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dải IP nhà người dùng có trùng VNet không | | | Có quy trình thu hồi chứng chỉ khi nhân viên nghỉ không | | | Có cần MFA cho VPN không | ⚠ nếu có thì phải Entra ID kèm OpenVPN |

Và điểm yếu bảo mật thường bị bỏ qua của P2S dùng chứng chỉ: thu hồi quyền truy cập. Khác với tài khoản Entra ID tắt một cái là xong, chứng chỉ đã phát ra phải được đưa vào danh sách thu hồi thì mới hết hiệu lực.

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

You’re diagnosing an issue with a Network Security Group. Which Azure PowerShell command from the options given will yield all the rules that are implemented on a Network Interface Card (NIC)?

  1. A

    Get-AzEffectiveNetworkSecurityGroup

  2. B

    Get-AzNsg

  3. C

    Get-AzNicNetworkSecurityGroup

  4. D

    Get-AzEffectiveNicNsg

Xem giải thích

Đáp án

A — Get-AzEffectiveNetworkSecurityGroup.

Vì sao đúng

⚠ "Effective" nghĩa là TỔNG HỢP mọi luật đang thực sự áp lên card mạng: | Nguồn luật được gộp | Nội dung | |---|---| | ⚠ NSG gắn ở SUBNET | | | ⚠ NSG gắn ở CARD MẠNG | | | ⚠ Luật mặc định | ⚠ sáu luật hệ thống | | ⚠ Luật từ Azure Firewall Policy nếu có | |

⚠ Đây là công cụ đúng khi gỡ lỗi, vì gói tin phải đi qua CẢ HAI tầng NSG, và đọc thủ công hai bộ luật rất dễ sai.

⚠ Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName "vm1-nic" `
       -ResourceGroupName "RG-Mang"

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

  • B (Get-AzNsg) — ⚠ không tồn tại; cmdlet đúng để lấy một NSG là Get-AzNetworkSecurityGroup, và nó chỉ trả về luật đã khai của MỘT NSG, không tổng hợp.

  • C (Get-AzNicNetworkSecurityGroup) và D (Get-AzEffectiveNicNsg) — ⚠ đều không tồn tại.

Ghi nhớ

⚠ Bộ công cụ chẩn đoán NSG: | Công cụ | Việc | |---|---| | ⚠ Effective security rules | ⚠ xem TOÀN BỘ luật đang áp lên một card mạng | | ⚠ IP flow verify | ⚠ luật NÀO đang chặn gói cụ thể này | | ⚠ Next hop | ⚠ gói sẽ đi đâu tiếp | | ⚠ NSG flow logs | ⚠ nhật ký luồng, phải BẬT trước mới có | | ⚠ Connection troubleshoot | ⚠ kiểm tra kết nối giữa hai điểm |

Từ khoá nhận diện:

"tổng hợp mọi luật áp lên NIC" → ⚠ effective security rules "luật nào chặn gói này" → ⚠ IP flow verify "xem luật đã khai của một NSG" → ⚠ Get-AzNetworkSecurityGroup "gói đi đường nào" → ⚠ Next hop

⚠ Vì sao cần công cụ "effective" Lý do
⚠ NSG gắn được ở CẢ subnet và card mạng
⚠ Gói vào phải qua NSG subnet RỒI NSG card mạng
⚠ Gói ra thì ngược lại ⚠ card mạng trước, subnet sau
⚠ Đọc thủ công hai bộ luật ⚠ rất dễ bỏ sót, nhất là khi có nhiều luật
⚠ Quy tắc gỡ lỗi kết nối trên Azure Bước
⚠ 1. Service Health ⚠ có phải lỗi nền tảng không
⚠ 2. Effective security rules ⚠ luật nào đang áp
⚠ 3. IP flow verify ⚠ luật nào chặn cụ thể
⚠ 4. Next hop ⚠ định tuyến có đúng không
⚠ 5. Packet capture ⚠ bước cuối, tốn công nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Card mạng đang chịu bao nhiêu NSG | ⚠ subnet, card mạng, hoặc cả hai | | Luật nào có ưu tiên cao nhất đang khớp | | | Có luật nào bị luật khác che khuất không | |

Và lý do gỡ lỗi NSG thủ công hay sai: luật có ưu tiên cao khớp trước là dừng luôn. Một luật đúng đắn ở dưới có thể không bao giờ được xét tới — và chỉ công cụ effective rules mới cho thấy điều đó rõ ràng.

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

You have a resource group in Azure that comprises Vnet-01 and Subnet-01. Subnet-01 has a routing table and a network security group (NSG-01). ARM VM1 is present in Subnet-01 with a private IP address. You must allow VM-Database01 to connect to an on-premises static IP address for software updates without revealing the ARM VM1 IP address. You also want to block all inbound traffic except for software updates. What are the two steps you can take to achieve this?

  1. A

    Create a private load balancer that is linked to the ARM virtual machine.

  2. B

    Create a NAT gateway associated with Subnet-01.

  3. C

    Modify NSG-01 to permit outbound traffic to and from the IP address 216.3.128.12 via port 443. Do not include any additional rules that allow traffic.

  4. D

    Allow outbound traffic to 216.3.128.12 on port 443 for NSG-01, no other rules are allowed.

Xem giải thích

Đáp án

B và D.

  • B — Tạo NAT gateway gắn với Subnet-01.
  • D — Cho phép lưu lượng RA tới 216.3.128.12 cổng 443 trong NSG-01, không thêm luật nào khác.

Vì sao đúng

⚠ Hai yêu cầu, hai giải pháp: | Yêu cầu | Giải pháp | |---|---| | ⚠ Kết nối ra ngoài mà KHÔNG lộ IP của máy ảo | ⚠ NAT Gateway — máy dùng IP của gateway, không dùng IP riêng của mình | | ⚠ Chặn mọi lưu lượng VÀO trừ cập nhật phần mềm | ⚠ NSG chỉ có luật RA; luật mặc định DenyAllInBound lo phần còn lại |

⚠ Máy ảo (chỉ có IP riêng)
        ↓ ⚠ NAT Gateway
⚠ Ra Internet bằng IP của NAT Gateway
   ⚠ Máy chủ đích thấy IP của gateway, KHÔNG thấy IP máy ảo
⚠ Chiều vào: ⚠ DenyAllInBound mặc định đã chặn sẵn

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

  • A (tạo load balancer nội bộ gắn với máy ảo) — ⚠ để phân phối lưu lượng VÀO, không giải quyết việc ẩn IP khi đi ra.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án C và phương án D gần như trùng nhau, chỉ khác một cụm từ.

Phương án Nội dung Đúng sai
⚠ C ⚠ cho phép lưu lượng "TỚI VÀ TỪ" 216.3.128.12 cổng 443 ⚠ SAI — "và từ" nghĩa là mở cả chiều VÀO, mâu thuẫn với yêu cầu chặn hết inbound
⚠ D ⚠ cho phép lưu lượng RA tới 216.3.128.12 cổng 443 ⚠ ĐÚNG — chỉ một chiều
⚠ Khác biệt ⚠ nằm ở đúng ba chữ "và từ"
⚠ Bài học ⚠ đọc kỹ CHIỀU của luật, đây là chỗ bẫy phổ biến nhất

⚠ Luật mặc định của NSG đã lo phần chặn: | Luật | Ưu tiên | |---|---| | ⚠ AllowVNetInBound | ⚠ 65000 | | ⚠ AllowAzureLoadBalancerInBound | ⚠ 65001 | | ⚠ DenyAllInBound | ⚠ 65500 — chặn mọi thứ từ Internet | | ⚠ Nghĩa là | ⚠ KHÔNG cần thêm luật deny nào cho chiều vào |

Từ khoá nhận diện:

"ra ngoài mà không lộ IP máy" → ⚠ NAT Gateway "chặn mọi inbound" → ⚠ luật mặc định đã làm sẵn "phân phối lưu lượng vào" → ⚠ Load Balancer "IP ra ngoài phải cố định" → ⚠ NAT Gateway với IP tĩnh

⚠ NAT Gateway mang lại gì ở đây Lợi ích
⚠ Máy không cần IP công cộng ⚠ giảm bề mặt tấn công
⚠ IP ra ngoài ổn định ⚠ đối tác đưa vào danh sách trắng được
⚠ 64.512 cổng SNAT mỗi IP ⚠ không lo cạn cổng
⚠ Không cần cấu hình định tuyến ⚠ gắn vào subnet là xong

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật NSG có mở nhầm chiều vào không | ⚠ đọc kỹ trường Direction | | Máy còn IP công cộng nào không | ⚠ gỡ nếu không cần | | Máy chủ cập nhật có lọc theo IP của bạn không | ⚠ gắn NAT Gateway sẽ đổi IP đó |

Và điểm cần đọc kỹ nhất trong mọi luật NSG: chiều của luật. Cùng một địa chỉ và cổng, "cho phép ra" và "cho phép ra và vào" là hai tư thế bảo mật hoàn toàn khác nhau.

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

As an Azure Network Engineer, you have been tasked with designing the network configuration for a web application that comprises three tiers for daily business-critical operations - a SQL Database, a JavaScript Frontend, and a processing middle tier. The web application also needs to interact with the following on-premise resources - a Windows File server, a SQL server, and a Windows Domain Controller.

Your task is to determine the number of subnets required to host the VMs for the web application.

  1. A

    1

  2. B

    2

  3. C

    3

  4. D

    6

Xem giải thích

Đáp án

C — 3 subnet.

Vì sao đúng

⚠ Ứng dụng web ba tầng thì mỗi tầng một subnet: | Tầng | Subnet | Nội dung | |---|---|---| | ⚠ Frontend JavaScript | ⚠ Subnet 1 | ⚠ nhận lưu lượng từ ngoài | | ⚠ Middle tier xử lý | ⚠ Subnet 2 | ⚠ chỉ nhận từ frontend | | ⚠ SQL Database | ⚠ Subnet 3 | ⚠ chỉ nhận từ middle tier |

⚠ Ba tài nguyên tại chỗ — file server, SQL server, domain controller — KHÔNG cần subnet trên Azure; chúng nằm ở mạng tại chỗ và được kết nối qua VPN hoặc ExpressRoute.

⚠ Internet → ⚠ Subnet Frontend → ⚠ Subnet Middle → ⚠ Subnet Database
                                        ↓ ⚠ qua VPN gateway
                                 ⚠ Tài nguyên tại chỗ

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

  • D (6) — ⚠ đếm nhầm cả ba tài nguyên TẠI CHỖ thành subnet Azure.

  • B (2) — ⚠ gộp hai tầng lại, mất một ranh giới bảo mật.

  • A (1) — ⚠ tất cả chung một subnet, không phân đoạn được gì.

Ghi nhớ

⚠ Vì sao mỗi tầng một subnet: | Lý do | Nội dung | |---|---| | ⚠ NSG riêng cho từng tầng | ⚠ luật khác nhau cho vai trò khác nhau | | ⚠ Chặn lan ngang | ⚠ chiếm được frontend không tới thẳng được CSDL | | ⚠ Bảng định tuyến riêng | ⚠ UDR khác nhau nếu cần | | ⚠ Dễ đọc, dễ kiểm toán | |

⚠ Lập kế hoạch subnet — điều cần nhớ: | Điều | Nội dung | |---|---| | ⚠ Azure giữ 5 địa chỉ mỗi subnet | ⚠ một /24 chỉ còn 251 địa chỉ dùng được | | ⚠ Subnet nhỏ nhất là /29 | ⚠ chỉ còn 3 địa chỉ dùng được | | ⚠ Một số dịch vụ đòi subnet RIÊNG | ⚠ GatewaySubnet, AzureFirewallSubnet, AzureBastionSubnet | | ⚠ Tên subnet của dịch vụ là BẮT BUỘC | ⚠ viết sai là không dùng được | | ⚠ Chừa chỗ để mở rộng | ⚠ đổi dải subnet sau rất phiền |

Từ khoá nhận diện:

"ứng dụng ba tầng" → ⚠ ba subnet "tài nguyên tại chỗ" → ⚠ KHÔNG tính vào subnet Azure "gateway VPN" → ⚠ cần GatewaySubnet riêng, tên chính xác "nhóm máy theo vai trò để viết luật" → ⚠ Application Security Group

⚠ Năm địa chỉ Azure giữ lại mỗi subnet Địa chỉ
⚠ x.x.x.0 ⚠ địa chỉ mạng
⚠ x.x.x.1 ⚠ cổng mặc định
⚠ x.x.x.2 và x.x.x.3 ⚠ ánh xạ DNS của Azure
⚠ x.x.x.255 ⚠ broadcast
⚠ Vì thế ⚠ luôn trừ 5 khi tính số máy chứa được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi tầng có subnet riêng chưa | | | Có chừa chỗ cho subnet dịch vụ chưa | ⚠ Gateway, Firewall, Bastion | | Dải địa chỉ có đủ để mở rộng không | |

Và quyết định khó sửa nhất khi bắt đầu một mạng ảo: kế hoạch địa chỉ IP. Chia quá chật thì hết chỗ, chồng lấn với mạng khác thì không peering được — và cả hai đều phải dựng lại tài nguyên mới sửa được.