Ngân hàng đề Microsoft Azure Networking

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

As an Azure Administrator, you are responsible for configuring Azure DNS zones for your Microsoft Entra tenant. Your objective is to ensure that Internet and Intranet users can perform different resolutions for the same domain name. What can you use to achieve this?

A
Reverse DNS.
B
Private DNS.
C
CName.
D
Split-Horizon.

Xem giải thích

Đáp án

D — Split-Horizon DNS (còn gọi là split-brain DNS).

Vì sao đúng

⚠ Split-horizon là kỹ thuật cho CÙNG một tên miền trả về CÂU TRẢ LỜI KHÁC NHAU tuỳ người hỏi: | Người hỏi | Nhận được | |---|---| | ⚠ Người dùng từ Internet | ⚠ IP CÔNG CỘNG của dịch vụ | | ⚠ Người dùng trong mạng nội bộ | ⚠ IP RIÊNG của dịch vụ |

⚠ app.contoso.com
   ├── ⚠ hỏi từ Internet     →  ⚠ Azure Public DNS zone  →  ⚠ 20.x.x.x
   └── ⚠ hỏi từ trong VNet   →  ⚠ Azure Private DNS zone →  ⚠ 10.0.1.4

⚠ Trên Azure, cách làm là: ⚠ tạo một public DNS zone và một private DNS zone CÙNG TÊN, rồi liên kết private zone với VNet.

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

B (Private DNS) — ⚠ là một THÀNH PHẦN của giải pháp, nhưng bản thân nó chỉ phục vụ mạng nội bộ; không tạo ra hai câu trả lời khác nhau.
A (Reverse DNS) — ⚠ phân giải NGƯỢC từ IP về tên, không liên quan.
C (CNAME) — ⚠ bí danh trỏ tới tên khác, không phân biệt được người hỏi.

Ghi nhớ

⚠ Vì sao split-horizon hữu ích: | Lợi ích | Nội dung | |---|---| | ⚠ Nhân viên nội bộ đi đường RIÊNG | ⚠ nhanh hơn, không ra Internet | | ⚠ Khách bên ngoài đi đường công cộng | | | ⚠ Cùng một địa chỉ cho cả hai | ⚠ không phải nhớ hai tên | | ⚠ Ứng dụng không cần biết mình đang ở đâu | | | ⚠ Bắt buộc khi dùng Private Endpoint | ⚠ để tên dịch vụ phân giải về IP riêng |

Từ khoá nhận diện:

"cùng tên miền, hai câu trả lời khác nhau" → ⚠ split-horizon DNS "phân giải tên riêng trong VNet" → ⚠ Private DNS zone "phân giải ngược từ IP về tên" → ⚠ reverse DNS, bản ghi PTR "tại chỗ hỏi tên của Azure" → ⚠ DNS Private Resolver inbound endpoint

⚠ Cách dựng split-horizon trên Azure	Bước
⚠ Tạo Azure Public DNS zone cho tên miền	⚠ bản ghi trỏ IP công cộng
⚠ Tạo Azure Private DNS zone CÙNG TÊN	⚠ bản ghi trỏ IP riêng
⚠ Liên kết private zone với các VNet
⚠ Máy trong VNet tự dùng private zone	⚠ private zone thắng khi cùng tên

⚠ Bẫy hay gặp với split-horizon	Bẫy
⚠ Hai zone lệch nhau theo thời gian	⚠ sửa một bên quên bên kia
⚠ Chứng chỉ TLS phải hợp lệ cho CẢ hai đường
⚠ Gỡ lỗi khó hơn	⚠ phải hỏi "bạn đang ở đâu khi phân giải"
⚠ Vì thế	⚠ ghi lại rõ ràng cả hai zone trong tài liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Từ trong VNet, nslookup trả về IP nào | | | Từ ngoài Internet, cùng tên đó trả về IP nào | | | Hai zone có đồng bộ nội dung không | |

Và tác dụng phụ của split-horizon cần chuẩn bị tinh thần: gỡ lỗi khó hơn hẳn. Câu hỏi đầu tiên khi ai đó báo "không vào được" sẽ luôn phải là "bạn đang ở trong mạng hay ngoài mạng" — vì hai vị trí cho hai kết quả khác nhau.

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

You are in the process of connecting Azure VNets for three separate branch offices. Your design involves a hub-and-spoke network topology. The central hub will function as a firewall during backend communication among the different locations, and it will also serve as a central location for storing disaster recovery backups.

At this point, you are considering whether to connect your hub-and-spoke model using VNet peering connections or Azure VPN Gateways, each of which has its benefits.

Which of the following statements correctly compares VNet peering and VPN Gateways within a hub-and-spoke model? (Choose three correct answers)

A
If you use Azure VPN Gateways to implement the model, all VNets can be cross-region. If you use VNet peering connections, the VNets can be cross-regional with Global VNet Peering.
B
Whether connecting through Azure VPN Gateways or VNet peering, VNets can be in different Azure subscriptions and associated with separate Azure AD tenants.
C
If you use Azure VPN Gateways, VNets can be in different regions. If you use VNet peering connections, VNets must be in the same region.
D
If you use Azure VPN Gateways to implement the model, it enables you to create VNets in different Azure subscriptions that are linked to the same Azure tenant. On the other hand, if you go for VNet peering connections, you can create VNets in different Azure subscriptions that are associated with separate Azure AD tenants.

Xem giải thích

Đáp án

A, B và D.

A — Dùng VPN Gateway thì mọi VNet có thể ở các vùng khác nhau; dùng peering thì phải là Global VNet peering mới xuyên vùng được.
B — Dù nối bằng VPN Gateway hay peering, các VNet đều có thể ở subscription khác nhau và thuộc tenant Entra ID khác nhau.
D — Dùng VPN Gateway cho phép tạo VNet ở các subscription khác nhau cùng một tenant; peering cũng làm được điều tương tự.

Vì sao đúng

⚠ Điểm chung của cả hai cách: | Ranh giới | Peering | VPN Gateway | |---|---|---| | ⚠ Khác subscription | ⚠ được | ⚠ được | | ⚠ Khác tenant | ⚠ được | ⚠ được | | ⚠ Khác vùng | ⚠ được — global peering | ⚠ được |

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

C (dùng VPN Gateway thì khác vùng được, dùng peering thì BẮT BUỘC cùng vùng) — ⚠ SAI; ⚠ global VNet peering nối được VNet ở các vùng khác nhau từ lâu.

Ghi nhớ

⚠ Peering và VPN Gateway — so sánh thật sự: | Tiêu chí | VNet peering | VPN Gateway | |---|---|---| | ⚠ Đường đi | ⚠ backbone Microsoft | ⚠ đường hầm IPsec | | ⚠ Băng thông | ⚠ rất cao, gần như không giới hạn | ⚠ giới hạn theo SKU | | ⚠ Độ trễ | ⚠ thấp nhất | ⚠ cao hơn — có mã hoá và giải mã | | ⚠ Mã hoá | ⚠ KHÔNG mặc định | ⚠ CÓ — IPsec | | ⚠ Chi phí | ⚠ theo dữ liệu | ⚠ theo GIỜ cộng dữ liệu — đắt hơn | | ⚠ Bắc cầu | ⚠ KHÔNG | ⚠ có, qua định tuyến | | ⚠ Thời gian dựng | ⚠ vài phút | ⚠ có thể tới 45 phút |

Từ khoá nhận diện:

"độ trễ thấp nhất, băng thông cao" → ⚠ peering "cần mã hoá giữa hai VNet" → ⚠ VPN Gateway, hoặc mã hoá ở tầng ứng dụng "khác vùng" → ⚠ global peering, KHÔNG phải chỉ VPN mới làm được "tiết kiệm chi phí" → ⚠ peering, không tính tiền theo giờ

⚠ Khi nào vẫn nên chọn VPN Gateway giữa hai VNet	Khi nào
⚠ Yêu cầu mã hoá bắt buộc theo quy định
⚠ Cần định tuyến bắc cầu bằng BGP
⚠ Đã có sẵn gateway cho kết nối tại chỗ
⚠ Còn lại	⚠ peering gần như luôn tốt hơn và rẻ hơn

⚠ Trong mô hình hub-and-spoke thực tế	Thực tế
⚠ Spoke nối hub bằng PEERING	⚠ nhanh, rẻ
⚠ Hub nối tại chỗ bằng VPN hoặc ExpressRoute
⚠ Spoke đi nhờ gateway của hub	⚠ gateway transit
⚠ Đây là	⚠ mẫu chuẩn, kết hợp ưu điểm của cả hai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có yêu cầu mã hoá giữa các VNet không | ⚠ quyết định peering hay VPN | | Có gateway nào dựng thừa không | ⚠ tính tiền theo giờ, rất tốn | | Dải IP đã lập kế hoạch chưa | |

Và lựa chọn mặc định đúng trong hầu hết trường hợp: peering giữa các VNet, gateway chỉ để nối ra ngoài Azure. Dựng VPN Gateway chỉ để nối hai VNet là trả tiền theo giờ cho thứ mà peering làm tốt hơn và gần như miễn phí.

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

A company wants to connect its on-premises data center to Azure and desires a dedicated and failover connection. They are not concerned about having a brief latency drop during the failover connection. Additionally, the company has more than 500 employees who will require access to this connection. Which type of connection would you recommend to the company?

A
A site-to-site for the primary and failover connection.
B
A site-to-Site for the primary, and a Point-to-Site for the failover connection.
C
An ExpressRoute for the primary connection, and a Site-to-Site for the failover connection.
D
A Site-to-Site for the primary, and an ExpressRoute for the failover connection.

Xem giải thích

Đáp án

C — ExpressRoute cho kết nối chính, và Site-to-Site VPN cho kết nối dự phòng.

Vì sao đúng

⚠ Đối chiếu yêu cầu: | Yêu cầu | Giải pháp | |---|---| | ⚠ Kết nối RIÊNG (dedicated) | ⚠ ExpressRoute — đúng định nghĩa | | ⚠ Có dự phòng (failover) | ⚠ VPN S2S làm đường thứ hai | | ⚠ Chấp nhận độ trễ tăng khi chuyển | ⚠ VPN qua Internet chậm hơn, nhưng đề chấp nhận | | ⚠ Hơn 500 nhân viên dùng | ⚠ cần băng thông cao và ổn định — ExpressRoute |

⚠ Bình thường:  ⚠ Trung tâm dữ liệu → ⚠ ExpressRoute → ⚠ Azure
⚠ Khi hỏng:     ⚠ Trung tâm dữ liệu → ⚠ VPN S2S     → ⚠ Azure
   ⚠ chậm hơn nhưng vẫn chạy

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

D (S2S chính, ExpressRoute dự phòng) — ⚠ NGƯỢC; để đường đắt tiền và mạnh nhất nằm không là lãng phí, và đường chính không đáp ứng được yêu cầu "dedicated".
A (S2S cho cả chính lẫn dự phòng) — ⚠ không đáp ứng yêu cầu kết nối RIÊNG.
B (S2S chính, P2S dự phòng) — ⚠ P2S dành cho từng máy tính cá nhân, không thay thế được kết nối cho cả trung tâm dữ liệu với 500 nhân viên.

Ghi nhớ

⚠ Mẫu kết nối lai chuẩn của doanh nghiệp: | Thành phần | Vai trò | |---|---| | ⚠ ExpressRoute | ⚠ đường chính — băng thông cao, độ trễ ổn định, có SLA | | ⚠ VPN S2S | ⚠ đường dự phòng — rẻ, tự động chuyển khi đường chính hỏng | | ⚠ BGP | ⚠ để chuyển đổi tự động, không phải can thiệp tay |

⚠ So sánh ba kiểu kết nối: | Kiểu | Cho ai | Mã hoá | Băng thông | |---|---|---|---| | ⚠ Point-to-Site | ⚠ một máy tính | ⚠ có | ⚠ thấp | | ⚠ Site-to-Site | ⚠ cả một mạng | ⚠ có | ⚠ trung bình | | ⚠ ExpressRoute | ⚠ cả một mạng | ⚠ KHÔNG mặc định | ⚠ rất cao |

Từ khoá nhận diện:

"kết nối riêng, dedicated" → ⚠ ExpressRoute "dự phòng rẻ tiền" → ⚠ VPN S2S "một máy tính từ xa" → ⚠ Point-to-Site "chấp nhận chậm hơn khi chuyển đổi" → ⚠ dấu hiệu chấp nhận VPN làm dự phòng

⚠ Vì sao ExpressRoute cần đường dự phòng	Lý do
⚠ Đấu nối vật lý có thể đứt	⚠ cáp, thiết bị nhà cung cấp
⚠ SLA 99,95% vẫn có thời gian chết
⚠ Bảo trì của nhà cung cấp
⚠ Hai mức dự phòng	⚠ VPN làm dự phòng, hoặc circuit thứ hai ở peering location khác

⚠ Điều cần lo khi dựng dự phòng	Điều
⚠ BGP phải cấu hình đúng để chuyển tự động
⚠ Đặt độ ưu tiên tuyến cho đúng	⚠ ExpressRoute ưu tiên hơn VPN
⚠ Kiểm thử chuyển đổi định kỳ	⚠ chưa thử là chưa có dự phòng
⚠ Băng thông VPN có đủ cho tải tối thiểu không

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đường dự phòng lần cuối được kiểm thử khi nào | | | BGP có tự chuyển tuyến khi đường chính hỏng không | | | Băng thông VPN có gánh được tải thiết yếu không | |

Và điều duy nhất chứng minh một kết nối dự phòng thật sự tồn tại: đã từng chạy thử. Cấu hình hai đường trên giấy tờ rất dễ; biết chắc rằng đường thứ hai gánh được tải mới là phần việc thật.

Câu 74 Chọn nhiều đáp án Design and implement private access to Azure services (5-10%

You're setting up Azure Private Link for your application. Which actions will ensure secure access and seamless integration with DNS?

A Create a Private Endpoint
B Implement Azure Front Door
C Integrate the Private Endpoint with Azure DNS
D Set up Network Security Groups (NSG)

Xem giải thích

Đáp án

A và C.

A — Tạo một Private Endpoint.
C — Tích hợp Private Endpoint với Azure DNS.

Vì sao đúng

⚠ Private Link cần đủ HAI mảnh mới hoạt động đúng: | Mảnh | Vai trò | |---|---| | ⚠ Private Endpoint | ⚠ cấp một IP RIÊNG trong VNet cho dịch vụ PaaS | | ⚠ Tích hợp DNS | ⚠ để TÊN dịch vụ phân giải về IP riêng đó |

⚠ Thiếu mảnh thứ hai là lỗi phổ biến nhất:

⚠ Có endpoint, không có DNS
   ⚠ ứng dụng gọi tên  →  ⚠ phân giải ra IP CÔNG CỘNG  →  ⚠ đi đường cũ
   ⚠ Endpoint dựng xong nhưng KHÔNG ai dùng tới

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

B (Azure Front Door) — ⚠ định tuyến HTTP toàn cầu ở biên, không liên quan tới truy cập riêng tư vào PaaS.
D (Network Security Group) — ⚠ hữu ích để kiểm soát ai tới được endpoint, nhưng không phải điều kiện để Private Link hoạt động.

Ghi nhớ

⚠ Cách DNS làm việc với Private Endpoint: | Bước | Nội dung | |---|---| | ⚠ Tạo Private DNS zone đúng tên | ⚠ ví dụ privatelink.blob.core.windows.net | | ⚠ Liên kết zone với VNet | | | ⚠ Bản ghi A trỏ tên về IP riêng | ⚠ thường tạo tự động khi bật DNS integration | | ⚠ Máy trong VNet phân giải ra IP riêng | | | ⚠ Máy ngoài vẫn phân giải ra IP công cộng | ⚠ đây chính là split-horizon |

Từ khoá nhận diện:

"dịch vụ PaaS có IP riêng trong VNet" → ⚠ Private Endpoint "tên phân giải về IP riêng" → ⚠ Private DNS zone "vẫn dùng IP công cộng nhưng đi qua backbone" → ⚠ Service Endpoint, KHÁC hẳn "phơi dịch vụ của mình cho khách hàng" → ⚠ Private Link Service

⚠ Service Endpoint và Private Endpoint	Khác
⚠ Service Endpoint	⚠ vẫn dùng IP CÔNG CỘNG của dịch vụ, chỉ đổi đường đi
⚠ Private Endpoint	⚠ dịch vụ có IP RIÊNG trong VNet của bạn
⚠ Service Endpoint	⚠ KHÔNG dùng được từ mạng tại chỗ
⚠ Private Endpoint	⚠ dùng được từ tại chỗ qua VPN hoặc ExpressRoute
⚠ Service Endpoint	⚠ miễn phí
⚠ Private Endpoint	⚠ tính tiền theo giờ và theo dữ liệu
⚠ Hướng khuyến nghị	⚠ Private Endpoint

⚠ Việc nên làm kèm theo	Việc
⚠ TẮT truy cập công cộng của dịch vụ	⚠ nếu không thì cửa cũ vẫn mở
⚠ Kiểm chứng bằng `nslookup` từ trong VNet
⚠ Đảm bảo mạng tại chỗ cũng phân giải đúng	⚠ cần DNS forwarder hoặc Private Resolver

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Từ trong VNet, tên dịch vụ phân giải ra IP nào | ⚠ kiểm chứng nhanh nhất | | Truy cập công cộng đã tắt chưa | | | Private DNS zone đã liên kết đúng VNet chưa | |

Và mắt xích quyết định của mọi kiến trúc Private Link vẫn là DNS. Endpoint có IP riêng, quyền cấu hình đúng, nhưng chừng nào tên miền còn phân giải ra địa chỉ công cộng thì gói tin vẫn đi đường cũ — và không có cảnh báo nào cho bạn biết.

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

While creating the virtual network gateway for a VPN configuration, you need to specify a VPN type. Which of the following are valid VPN types that you can choose? (Select all applicable options)

A
PolicyBased
B
IntervalBased
C
RouteBased
D
LinkBased
E
StatusBased

Xem giải thích

Đáp án

A và C — PolicyBased và RouteBased.

Vì sao đúng

⚠ Azure VPN Gateway có đúng HAI kiểu: | Kiểu | Cách chọn đường hầm | |---|---| | ⚠ PolicyBased | ⚠ theo CHÍNH SÁCH — dựa trên tổ hợp dải địa chỉ nguồn và đích | | ⚠ RouteBased | ⚠ theo BẢNG ĐỊNH TUYẾN — dùng giao diện đường hầm ảo |

⚠ So sánh: | Tiêu chí | PolicyBased | RouteBased | |---|---|---| | ⚠ Số đường hầm | ⚠ CHỈ MỘT | ⚠ nhiều | | ⚠ Point-to-Site | ⚠ KHÔNG hỗ trợ | ⚠ hỗ trợ | | ⚠ VNet-to-VNet | ⚠ KHÔNG | ⚠ có | | ⚠ Cùng tồn tại với ExpressRoute | ⚠ KHÔNG | ⚠ có | | ⚠ BGP | ⚠ KHÔNG | ⚠ có | | ⚠ SKU hỗ trợ | ⚠ chỉ Basic | ⚠ mọi SKU | | ⚠ Khuyến nghị | ⚠ chỉ khi thiết bị cũ bắt buộc | ⚠ MẶC ĐỊNH cho mọi triển khai mới |

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

B (IntervalBased), D (LinkBased), E (StatusBased) — ⚠ đều là tên bịa, không tồn tại trong Azure.

Ghi nhớ

⚠ Khi nào buộc phải dùng PolicyBased: | Trường hợp | Nội dung | |---|---| | ⚠ Thiết bị VPN tại chỗ chỉ hỗ trợ IKEv1 kiểu policy-based | ⚠ thường là thiết bị đời cũ | | ⚠ Không có nhu cầu P2S hay nhiều đường hầm | | | ⚠ Ngoài ra | ⚠ RouteBased luôn là lựa chọn tốt hơn |

Từ khoá nhận diện:

"nhiều đường hầm, có P2S, có BGP" → ⚠ RouteBased "chỉ một đường hầm, thiết bị cũ" → ⚠ PolicyBased "IKEv1" → ⚠ thường gắn với PolicyBased "IKEv2" → ⚠ RouteBased

⚠ Ràng buộc quan trọng	Ràng buộc
⚠ KHÔNG đổi kiểu VPN sau khi tạo gateway	⚠ phải xoá và tạo lại
⚠ Tạo gateway mất tới 45 phút
⚠ Xoá và tạo lại nghĩa là GIÁN ĐOẠN
⚠ Vì thế	⚠ chọn đúng ngay từ đầu, và mặc định nên chọn RouteBased

⚠ Vì sao RouteBased linh hoạt hơn	Lý do
⚠ Dùng giao diện đường hầm ảo	⚠ định tuyến quyết định gói nào vào hầm nào
⚠ Thêm kết nối mới không phải sửa chính sách
⚠ Hỗ trợ active-active	⚠ hai instance gateway, không có điểm hỏng đơn lẻ
⚠ Hỗ trợ BGP	⚠ tuyến tự lan truyền và tự chuyển đổi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gateway hiện tại là kiểu gì | ⚠ đổi được thì phải tạo lại | | Thiết bị tại chỗ hỗ trợ IKEv2 không | | | Có cần P2S trong tương lai không | ⚠ nếu có thì bắt buộc RouteBased |

Và quyết định khó lùi nhất khi dựng VPN Gateway: chọn kiểu VPN. Nó không đổi được sau khi tạo, mà tạo lại thì mất tới 45 phút gián đoạn — nên với triển khai mới, RouteBased gần như luôn là câu trả lời đúng.

Câu 76

You have been hired as an expert advisor by a well-known Azure company to help with their Azure projects. After analyzing their work, you have noticed that the team is not using Microsoft Sentinel effectively. You have decided to brief them on the importance of Microsoft Sentinel. In order to do so, you need to come up with a clear description of Microsoft Sentinel. Which of the following statements would be the best option for defining or describing Microsoft Sentinel?

A
This feature assists you in monitoring diagnostic information related to WAF alerts and logs.
B
It assists you in proactively preventing, identifying, and addressing potential security risks.
C
This function is accountable for converting a service name into an IP address, also known as resolving or translating the service name.
D
It is a DNS-based traffic load balancing solution that enables optimal distribution of traffic to services across global Azure regions, offering high responsiveness and availability. However, it may not be the most suitable tool for the intended purpose.
E
It is a solution for security information and event management that is cloud-native and scalable and can automate security orchestration responses.

Xem giải thích

Đáp án

E — Là giải pháp quản lý thông tin và sự kiện an ninh, gốc đám mây, có khả năng mở rộng và tự động hoá điều phối phản ứng an ninh.

Vì sao đúng

⚠ Microsoft Sentinel là SIEM cộng SOAR: | Viết tắt | Nghĩa | Sentinel làm gì | |---|---|---| | ⚠ SIEM | ⚠ Security Information and Event Management | ⚠ thu thập, tương quan, phát hiện | | ⚠ SOAR | ⚠ Security Orchestration, Automation and Response | ⚠ tự động phản ứng bằng playbook |

⚠ Bốn giai đoạn Sentinel phục vụ: | Giai đoạn | Nội dung | |---|---| | ⚠ Collect | ⚠ thu dữ liệu từ người dùng, thiết bị, ứng dụng, hạ tầng — cả trong lẫn ngoài Azure | | ⚠ Detect | ⚠ phát hiện mối đe doạ bằng phân tích và học máy | | ⚠ Investigate | ⚠ điều tra, dựng dòng thời gian sự cố | | ⚠ Respond | ⚠ phản ứng tự động bằng playbook chạy trên Logic Apps |

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

B (giúp chủ động ngăn chặn, nhận diện và xử lý rủi ro bảo mật) — ⚠ mô tả gần với Microsoft Defender for Cloud, thiên về tư thế bảo mật của tài nguyên.
A (theo dõi nhật ký và cảnh báo WAF) — ⚠ là một nguồn dữ liệu ĐƯA VÀO Sentinel, không phải định nghĩa của nó.
C (chuyển tên dịch vụ thành địa chỉ IP) — ⚠ là DNS.
D (cân bằng tải dựa trên DNS trên toàn cầu) — ⚠ là Traffic Manager.

Ghi nhớ

⚠ Sentinel và Defender for Cloud — phân biệt: | Công cụ | Trả lời câu hỏi | |---|---| | ⚠ Defender for Cloud | ⚠ cấu hình của tôi có an toàn không — tư thế bảo mật, secure score | | ⚠ Microsoft Sentinel | ⚠ có ai đang tấn công tôi không — phát hiện và điều tra sự cố | | ⚠ Quan hệ | ⚠ Defender là một NGUỒN dữ liệu cho Sentinel | | ⚠ Dùng chung | ⚠ cả hai đều dựa trên Log Analytics workspace |

Từ khoá nhận diện:

"SIEM, SOAR, điều tra sự cố an ninh" → ⚠ Microsoft Sentinel "secure score, khuyến nghị bảo mật" → ⚠ Defender for Cloud "gom nhật ký và chỉ số, truy vấn KQL" → ⚠ Azure Monitor và Log Analytics "khuyến nghị tối ưu chi phí và hiệu năng" → ⚠ Azure Advisor

⚠ Thành phần chính của Sentinel	Thành phần
⚠ Data connectors	⚠ hơn 100 nguồn dựng sẵn, cả sản phẩm ngoài Microsoft
⚠ Analytics rules	⚠ luật phát hiện, tạo ra incident
⚠ Workbooks	⚠ bảng điều khiển trực quan
⚠ Playbooks	⚠ tự động phản ứng, chạy trên Logic Apps
⚠ Hunting queries	⚠ chủ động săn tìm dấu hiệu bất thường
⚠ Notebooks	⚠ điều tra sâu bằng Jupyter
⚠ UEBA	⚠ phân tích hành vi người dùng và thực thể

⚠ Điều cần cân nhắc về chi phí	Điều
⚠ Tính theo GB dữ liệu nhập vào
⚠ Nhập bừa mọi nguồn là hoá đơn rất lớn
⚠ Nên chọn lọc nguồn theo giá trị phát hiện
⚠ Có bậc commitment tier để giảm giá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nguồn dữ liệu nào thực sự tạo ra phát hiện có ích | ⚠ bỏ nguồn chỉ tốn tiền | | Có playbook tự động cho sự cố thường gặp chưa | | | Ai đọc và xử lý incident hằng ngày | ⚠ SIEM không có người trực là vô dụng |

Và điều quyết định một hệ thống SIEM có giá trị hay không, không phải số nguồn dữ liệu nó nhập vào, mà là có người thật sự xử lý các cảnh báo nó sinh ra. Không có quy trình trực thì Sentinel chỉ là một hoá đơn hằng tháng.

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

As the system administrator, you are responsible for creating and configuring the IPsec/lKE policy for a site-to-site VPN connection. You will need to follow the steps outlined below (not necessarily in the correct sequence) to develop and update the policy:

a. Create a local network gateway for the cross-premises connection.

b. Create a virtual network and a VPN gateway.

c. Create an IPsec/lKE policy by selecting appropriate algorithms and parameters.

d. Set up an IPSec connection using the IPsec/lKE policy.

e. Add, update, or remove an IPsec/lKE policy for an existing connection.

Place the above steps in the correct sequence.

A
b-a-c-d-e
B
a-b-c-d-e
C
a-b-d-c-e
D
a-c-d-e-b
E
b-a-d-c-e

Xem giải thích

Đáp án

A — b-a-c-d-e.

Vì sao đúng

⚠ Trình tự hợp lý theo quan hệ phụ thuộc: | Thứ tự | Bước | Vì sao ở vị trí này | |---|---|---| | ⚠ 1 | ⚠ b. Tạo mạng ảo và VPN gateway | ⚠ nền tảng, mọi thứ khác dựa vào nó | | ⚠ 2 | ⚠ a. Tạo local network gateway | ⚠ đại diện cho mạng tại chỗ ở phía Azure | | ⚠ 3 | ⚠ c. Tạo chính sách IPsec/IKE | ⚠ chọn thuật toán và tham số | | ⚠ 4 | ⚠ d. Tạo kết nối IPsec dùng chính sách đó | ⚠ nối hai gateway lại, áp chính sách | | ⚠ 5 | ⚠ e. Thêm, sửa, hoặc gỡ chính sách cho kết nối đã có | ⚠ việc VẬN HÀNH về sau |

⚠ VNet + VPN Gateway   →  ⚠ có đầu Azure
        ↓
⚠ Local Network Gateway →  ⚠ có đầu tại chỗ
        ↓
⚠ Chính sách IPsec/IKE  →  ⚠ có quy tắc mã hoá
        ↓
⚠ Connection            →  ⚠ nối hai đầu, áp chính sách
        ↓
⚠ Bảo trì về sau

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

B, C, D (bắt đầu bằng a) — ⚠ tạo local network gateway trước khi có VNet là ngược; ⚠ ở Azure, mạng ảo và gateway là nền tảng phải có trước.
E (b-a-d-c-e) — ⚠ tạo kết nối TRƯỚC khi có chính sách; không áp được chính sách vào một kết nối chưa được định nghĩa quy tắc.

Ghi nhớ

⚠ Ba thành phần của một kết nối Site-to-Site: | Thành phần | Đại diện cho | |---|---| | ⚠ Virtual Network Gateway | ⚠ đầu AZURE của đường hầm | | ⚠ Local Network Gateway | ⚠ đầu TẠI CHỖ — khai IP công cộng và dải địa chỉ của mạng đó | | ⚠ Connection | ⚠ nối hai gateway, mang khoá chia sẻ trước và chính sách |

⚠ Điểm hay nhầm: ⚠ "local network gateway" không phải là thiết bị; ⚠ nó chỉ là một đối tượng trong Azure mô tả mạng tại chỗ.

⚠ Chính sách IPsec/IKE gồm những gì: | Thành phần | Ví dụ | |---|---| | ⚠ Thuật toán mã hoá IKE | ⚠ AES256 | | ⚠ Thuật toán toàn vẹn IKE | ⚠ SHA384 | | ⚠ Nhóm DH | ⚠ DHGroup24 | | ⚠ Thuật toán mã hoá IPsec | ⚠ GCMAES256 | | ⚠ Nhóm PFS | ⚠ PFS24 | | ⚠ Thời gian sống SA | ⚠ theo giây và theo KB |

Từ khoá nhận diện:

"đại diện cho mạng tại chỗ" → ⚠ local network gateway "đầu Azure của đường hầm" → ⚠ virtual network gateway "khoá chia sẻ trước" → ⚠ thuộc về connection "thuật toán mã hoá" → ⚠ IPsec/IKE policy

⚠ Vì sao đôi khi phải khai chính sách tuỳ chỉnh	Lý do
⚠ Thiết bị tại chỗ chỉ hỗ trợ một bộ thuật toán nhất định
⚠ Quy định nội bộ yêu cầu thuật toán mạnh hơn
⚠ Mặc định của Azure chấp nhận nhiều tổ hợp	⚠ thường là đủ
⚠ Điều BẮT BUỘC	⚠ hai đầu phải khớp nhau CHÍNH XÁC

⚠ Lỗi hay gặp khi dựng S2S	Lỗi
⚠ Chính sách hai đầu không khớp	⚠ đường hầm không lên, thông báo rất chung chung
⚠ Khoá chia sẻ trước khác nhau
⚠ Dải địa chỉ khai sai trong local network gateway
⚠ Dải IP hai bên chồng lấn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách hai đầu có khớp từng tham số không | ⚠ nguyên nhân số một khiến hầm không lên | | Dải địa chỉ trong local network gateway có đúng không | | | Dải IP hai bên có chồng lấn không | |

Và nguyên nhân phổ biến nhất khiến một đường hầm Site-to-Site không lên được: hai đầu không thống nhất chính sách IPsec/IKE. Thông báo lỗi thường chỉ nói "không kết nối được", nên việc đầu tiên nên làm là đối chiếu từng tham số của hai bên.

Câu 78 Design and implement application delivery services (20-25%)

As a team leader, you address your team about load balancing and various Azure load-balancing services. Which of the following statements would you use to describe the Azure Front Door load balancing service? Please choose the option that best suits the context.

A
A DNS-based traffic load balancing service that optimally distributes traffic to services across Azure global regions, offering high responsiveness and availability.
B
A load balancing option is available as a service with an application delivery controller (ADC), supporting various Layer 7 load balancing capabilities.
C
A Layer 4 load balancing service for all TCP and UDP protocols that is high-performance, ultra-low-latency, and handles inbound and outbound traffic.
D
An application delivery network that provides global load balancing and site acceleration services for web applications, using layer seven capabilities.

Xem giải thích

Đáp án

D — Một mạng phân phối ứng dụng, cung cấp cân bằng tải toàn cầu và tăng tốc trang web cho ứng dụng web, dùng khả năng tầng bảy.

Vì sao đúng

⚠ Front Door gộp ba vai trò: | Vai trò | Nội dung | |---|---| | ⚠ Cân bằng tải toàn cầu | ⚠ định tuyến tới backend gần và khoẻ nhất | | ⚠ Tăng tốc trang web | ⚠ cache ở biên, kết nối tối ưu tới origin | | ⚠ Bảo vệ tầng 7 | ⚠ WAF chặn ngay tại biên |

⚠ Hoạt động ở tầng 7 — đọc được HTTP, định tuyến theo đường dẫn, dừng TLS, viết lại URL.

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

⚠ Ba phương án còn lại mô tả ĐÚNG nhưng cho DỊCH VỤ KHÁC: | Phương án | Thực ra là | |---|---| | ⚠ A — cân bằng tải dựa trên DNS, phân phối toàn cầu | ⚠ Traffic Manager | | ⚠ B — ADC hỗ trợ nhiều khả năng cân bằng tải tầng 7 | ⚠ Application Gateway | | ⚠ C — tầng 4, mọi giao thức TCP và UDP, độ trễ cực thấp | ⚠ Azure Load Balancer |

Ghi nhớ

⚠ Bốn dịch vụ cân bằng tải — bảng phải thuộc: | Dịch vụ | Phạm vi | Tầng | Đặc trưng | |---|---|---|---| | ⚠ Load Balancer | ⚠ vùng | ⚠ 4 | ⚠ độ trễ thấp nhất, mọi giao thức | | ⚠ Application Gateway | ⚠ vùng | ⚠ 7 | ⚠ ADC, WAF, định tuyến theo URL | | ⚠ Traffic Manager | ⚠ toàn cầu | ⚠ DNS | ⚠ mọi giao thức, không nằm trên đường đi | | ⚠ Front Door | ⚠ toàn cầu | ⚠ 7 | ⚠ CDN, WAF, proxy ngược thật sự |

Từ khoá nhận diện:

"toàn cầu, tầng 7, tăng tốc, có cache" → ⚠ Front Door "dựa trên DNS, toàn cầu" → ⚠ Traffic Manager "ADC, tầng 7, trong một vùng" → ⚠ Application Gateway "tầng 4, TCP và UDP, độ trễ cực thấp" → ⚠ Load Balancer

⚠ Front Door và Traffic Manager — khác biệt then chốt	Khác
⚠ Traffic Manager	⚠ chỉ trả lời DNS rồi rút lui, lưu lượng KHÔNG đi qua
⚠ Front Door	⚠ là proxy ngược, mọi byte ĐI QUA nó
⚠ Chuyển đổi dự phòng	⚠ Front Door gần như tức thời, Traffic Manager phụ thuộc TTL
⚠ Giao thức	⚠ Traffic Manager mọi loại, Front Door chỉ HTTP/HTTPS

⚠ Front Door mang lại gì thêm	Thêm
⚠ Cache nội dung tĩnh ở biên
⚠ Dừng TLS gần người dùng	⚠ giảm độ trễ bắt tay
⚠ WAF chặn tấn công trước khi vào vùng của bạn
⚠ Nén, viết lại URL, chuyển hướng
⚠ Kết nối tối ưu tới origin qua backbone

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người dùng có phân tán nhiều châu lục không | ⚠ nếu không thì Front Door có thể thừa | | Lưu lượng có phải HTTP không | ⚠ nếu không thì phải Traffic Manager | | Có cần cache ở biên không | |

Và cách phân biệt bốn dịch vụ này cho khỏi lẫn: hỏi hai câu — toàn cầu hay một vùng, và tầng 4 hay tầng 7. Hai câu đó cho ra đúng một ô trong bảng bốn ô.

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

You want your customers to use Microsoft’s backbone to connect from their virtual network to the services in your virtual network. Which Azure service supports this?

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

Xem giải thích

Đáp án

D — Azure Private Link Service.

Vì sao đúng

⚠ Private Link Service là mặt "NHÀ CUNG CẤP" của Private Link: | Vai trò | Dịch vụ | |---|---| | ⚠ Bạn là người CUNG CẤP dịch vụ | ⚠ tạo Private Link Service | | ⚠ Khách hàng là người TIÊU THỤ | ⚠ tạo Private Endpoint trỏ tới |

⚠ VNet của khách hàng
   ⚠ Private Endpoint (IP riêng của họ)
        ↓ ⚠ backbone Microsoft
   ⚠ Private Link Service
   ⚠ Standard Load Balancer
   ⚠ Dịch vụ của BẠN

⚠ Điều kiện để tạo Private Link Service: | Điều kiện | Nội dung | |---|---| | ⚠ Dịch vụ đứng sau Standard Load Balancer | ⚠ bắt buộc | | ⚠ Có subnet cho NAT của dịch vụ | | | ⚠ Bạn DUYỆT hoặc TỪ CHỐI từng yêu cầu kết nối | |

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

C (Service Endpoint) — ⚠ dành cho dịch vụ PaaS của MICROSOFT, không phơi được dịch vụ riêng của bạn.
A (ExpressRoute Peering) và B (ExpressRoute Private Link) — ⚠ về kết nối tại chỗ với Azure, không phải giữa hai VNet của hai tổ chức.
E (Network Security Groups) — ⚠ lọc lưu lượng, không tạo kênh kết nối.

Ghi nhớ

⚠ Hai mặt của Private Link: | Mặt | Tài nguyên | Ai tạo | |---|---|---| | ⚠ Tiêu thụ | ⚠ Private Endpoint | ⚠ khách hàng | | ⚠ Cung cấp | ⚠ Private Link Service | ⚠ nhà cung cấp dịch vụ |

⚠ Vì sao mô hình này hấp dẫn: | Lợi ích | Nội dung | |---|---| | ⚠ Không cần peering giữa hai VNet | ⚠ không lo dải IP chồng lấn | | ⚠ Không lộ dịch vụ ra Internet | | | ⚠ Lưu lượng đi qua backbone Microsoft | | | ⚠ Nhà cung cấp KIỂM SOÁT ai được kết nối | ⚠ duyệt từng yêu cầu | | ⚠ Khách hàng thấy dịch vụ như một IP riêng trong mạng mình | |

Từ khoá nhận diện:

"phơi dịch vụ CỦA MÌNH qua IP riêng" → ⚠ Private Link Service "truy cập dịch vụ PaaS qua IP riêng" → ⚠ Private Endpoint "vẫn IP công cộng nhưng đi qua backbone" → ⚠ Service Endpoint "nối hai VNet trực tiếp" → ⚠ peering, nhưng cần dải IP không chồng

⚠ Vì sao Private Link tốt hơn peering trong kịch bản này	Lý do
⚠ Không lo dải IP của khách hàng chồng với của bạn
⚠ Khách hàng chỉ thấy ĐÚNG dịch vụ đó	⚠ không thấy toàn bộ VNet của bạn
⚠ Không phải quản lý hàng chục peering
⚠ Đây là	⚠ mô hình chuẩn cho SaaS trên Azure

⚠ Vòng đời một kết nối	Trạng thái
⚠ Pending	⚠ khách yêu cầu, chờ bạn duyệt
⚠ Approved	⚠ đã duyệt, hoạt động
⚠ Rejected	⚠ từ chối
⚠ Disconnected	⚠ bạn đã ngắt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có yêu cầu nào đang Pending không | ⚠ khách đang chờ mà không ai biết | | Dịch vụ có đứng sau Standard Load Balancer không | ⚠ điều kiện bắt buộc | | Có quy trình duyệt rõ ràng chưa | |

Và lý do Private Link Service là mô hình chuẩn để cung cấp dịch vụ trên Azure: khách hàng truy cập được mà không cần biết gì về mạng của bạn, và bạn không cần biết gì về mạng của họ. Không có peering, không có dải IP phải thoả thuận.

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

Azure Private Endpoint serves as a network interface that enables you to connect to a service powered by Azure Private Link in a private and secure way. As the Private Link resource owner, what actions can you perform over a private endpoint connection?

A
Reviewing all private endpoint connection details.
B
Approving a private endpoint connection.
C
Rejecting a private endpoint connection.
D
Deleting a private endpoint connection from any state.
E
All the above

Xem giải thích

Đáp án

E — Tất cả các hành động trên.

Vì sao đúng

⚠ Chủ sở hữu tài nguyên Private Link kiểm soát toàn bộ vòng đời kết nối: | Hành động | Nội dung | |---|---| | ⚠ Xem chi tiết mọi kết nối | ⚠ ai yêu cầu, từ subscription nào, trạng thái ra sao | | ⚠ Duyệt | ⚠ Approve — kết nối bắt đầu hoạt động | | ⚠ Từ chối | ⚠ Reject | | ⚠ Xoá từ BẤT KỲ trạng thái nào | ⚠ Pending, Approved, hay Rejected đều xoá được |

⚠ Khách hàng tạo Private Endpoint
        ↓ ⚠ yêu cầu tới bạn
⚠ Trạng thái Pending
        ↓ ⚠ bạn quyết định
⚠ Approved  hoặc  ⚠ Rejected
        ↓ ⚠ bất cứ lúc nào
⚠ Bạn xoá được kết nối

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

A, B, C, D — ⚠ mỗi phương án chỉ nêu MỘT hành động, trong khi chủ sở hữu làm được cả bốn.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23257 trong lô này hỏi dịch vụ nào cho phép khách hàng nối vào dịch vụ của bạn qua backbone (Private Link Service). ⚠ Câu này đi vào QUYỀN KIỂM SOÁT của chủ dịch vụ. Hai câu bổ sung nhau.

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

⚠ Hai chế độ duyệt: | Chế độ | Nội dung | |---|---| | ⚠ Tự động duyệt | ⚠ khi người tạo endpoint có quyền RBAC trên tài nguyên | | ⚠ Duyệt thủ công | ⚠ người ngoài yêu cầu, chủ dịch vụ quyết định | | ⚠ Với Private Link Service | ⚠ có danh sách subscription được tự động duyệt |

Từ khoá nhận diện:

"duyệt hoặc từ chối kết nối" → ⚠ quyền của chủ Private Link resource "xem trạng thái các kết nối" → ⚠ Get-AzPrivateLinkService "duyệt" → ⚠ Approve-AzPrivateEndpointConnection "xoá" → ⚠ Remove-AzPrivateEndpointConnection

⚠ Vì sao mô hình duyệt này quan trọng	Lý do
⚠ Bất kỳ ai biết Resource ID đều YÊU CẦU được
⚠ Nhưng không kết nối được cho tới khi bạn duyệt
⚠ Bạn ngắt được bất cứ lúc nào	⚠ khách hàng ngừng hợp đồng chẳng hạn
⚠ Đây là	⚠ lớp kiểm soát truy cập ở tầng mạng, độc lập với RBAC

⚠ Việc vận hành cần chú ý	Việc
⚠ Yêu cầu Pending KHÔNG có cảnh báo mặc định	⚠ phải tự dựng cảnh báo hoặc kiểm tra định kỳ
⚠ Kết nối cũ của khách đã ngừng dùng nên ngắt
⚠ Ghi lại lý do khi từ chối

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có yêu cầu nào đang Pending không | | | Có kết nối nào nên ngắt không | | | Ai chịu trách nhiệm duyệt | |

Và điểm dễ bỏ sót nhất khi vận hành Private Link Service: yêu cầu ở trạng thái Pending sẽ nằm im vô thời hạn. Khách hàng tưởng bạn đang xử lý, còn bạn thì không biết có ai đang chờ — trừ khi có cảnh báo hoặc quy trình kiểm tra định kỳ.

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

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ