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

Tìm thấy 99 câu.

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

As a consultant, you are assisting a company in building a web application that will be hosted on Microsoft Azure. The web application is a healthcare management system that processes sensitive patient data. The company intends to deploy a Web Application Firewall (WAF) to safeguard the application against common web attacks and ensure that the patient data is well-protected. In this scenario, which feature of the Web Application Firewall (WAF) would be the most crucial for the company that handles sensitive patient data and demands robust security measures?

  1. A

    Customizable rule sets
  2. B

    Autoscaling
  3. C

    Integrating with other Azure services.
  4. D

    PCI DSS compliance
Xem giải thích

Đáp án

C — Tích hợp với các dịch vụ Azure khác.

Vì sao đúng

⚠ Với dữ liệu bệnh nhân nhạy cảm, WAF một mình là không đủ: | Tích hợp với | Mang lại | |---|---| | ⚠ Azure Monitor và Log Analytics | ⚠ nhật ký đầy đủ để kiểm toán và điều tra | | ⚠ Microsoft Sentinel | ⚠ tương quan sự kiện, phát hiện tấn công phức tạp | | ⚠ Defender for Cloud | ⚠ tư thế bảo mật tổng thể | | ⚠ Key Vault | ⚠ quản lý chứng chỉ TLS | | ⚠ Azure Policy | ⚠ buộc mọi ứng dụng phải có WAF |

⚠ Với ngành y tế, khả năng CHỨNG MINH bằng nhật ký và kiểm toán quan trọng ngang với khả năng chặn — và điều đó đến từ tích hợp.

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

  • B (autoscaling) — ⚠ về hiệu năng và khả dụng, không phải bảo vệ dữ liệu nhạy cảm.

  • D (tuân thủ PCI DSS) — ⚠ PCI DSS là chuẩn cho dữ liệu THẺ THANH TOÁN; với dữ liệu y tế, chuẩn liên quan là HIPAA hoặc quy định y tế địa phương.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án A — "bộ luật tuỳ chỉnh được" ⚠ cũng rất quan trọng với một ứng dụng y tế, và nhiều người sẽ chọn nó.

Phương án Lập luận
⚠ A — bộ luật tuỳ chỉnh ⚠ cho phép chặn mẫu tấn công đặc thù của ứng dụng — RẤT hợp lý
⚠ C — tích hợp dịch vụ khác (khoá) ⚠ cho nhật ký, kiểm toán, tương quan sự kiện — cần cho tuân thủ
⚠ Đề nhấn mạnh ⚠ "biện pháp bảo mật vững chắc" cho dữ liệu nhạy cảm — nghiêng về khả năng quan sát và kiểm toán
⚠ Phương án D ⚠ nhắc SAI chuẩn — y tế dùng HIPAA, không phải PCI DSS
⚠ Kết luận ⚠ giữ nguyên khoá C, nhưng A là phương án hợp lý thứ hai

⚠ 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 |

Từ khoá nhận diện:

"dữ liệu y tế" → ⚠ HIPAA, không phải PCI DSS "dữ liệu thẻ thanh toán" → ⚠ PCI DSS "nhật ký để kiểm toán" → ⚠ tích hợp Azure Monitor và Sentinel "chặn mẫu tấn công đặc thù" → ⚠ custom rule

⚠ Bảo vệ dữ liệu nhạy cảm cần nhiều hơn WAF Cần
⚠ Mã hoá khi lưu và khi truyền
⚠ Private Endpoint cho CSDL ⚠ không phơi ra Internet
⚠ Nhật ký truy cập đầy đủ ⚠ ai xem hồ sơ nào, khi nào
⚠ Phân loại và dán nhãn dữ liệu ⚠ Microsoft Purview
⚠ Quyền tối thiểu và MFA

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhật ký WAF có được giữ đủ lâu cho kiểm toán không | | | Ứng dụng phải tuân thủ chuẩn nào cụ thể | ⚠ đọc quy định, đừng đoán | | WAF đang ở chế độ Detection hay Prevention | |

Và điều mà một hệ thống xử lý dữ liệu y tế cần không kém khả năng chặn tấn công: khả năng chứng minh chuyện gì đã xảy ra. Kiểm toán viên sẽ hỏi ai truy cập hồ sơ nào vào lúc nào — và chỉ nhật ký được tích hợp và lưu giữ đầy đủ mới trả lời được.

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

Traffic Analytics is a cloud-based solution that provides visibility into the user and application activity across cloud networks. Which of the following is/are not key components of Traffic Analytics?

  1. A

    Network Security Group (NSG)
  2. B

    NSG flow logs
  3. C

    Log Analytics
  4. D

    Network Watcher
  5. E

    Backend Pool
Xem giải thích

Đáp án

E — Backend Pool.

Vì sao đúng

⚠ Backend pool là khái niệm của bộ CÂN BẰNG TẢI, không phải của Traffic Analytics: | Thuộc về | Khái niệm | |---|---| | ⚠ Load Balancer, Application Gateway, Front Door | ⚠ backend pool — nhóm máy nhận lưu lượng | | ⚠ Traffic Analytics | ⚠ NSG, NSG flow logs, Log Analytics, Network Watcher |

⚠ Bốn thành phần thật sự của Traffic Analytics: | Thành phần | Vai trò | |---|---| | ⚠ Network Security Group | ⚠ nơi lưu lượng đi qua và được ghi nhận | | ⚠ NSG flow logs | ⚠ DỮ LIỆU THÔ — phải bật mới có | | ⚠ Log Analytics workspace | ⚠ nơi lưu và truy vấn | | ⚠ Network Watcher | ⚠ dịch vụ chứa Traffic Analytics |

⚠ Lưu lượng qua NSG
        ↓ ⚠ NSG flow logs (phải BẬT)
⚠ Storage Account
        ↓ ⚠ Traffic Analytics xử lý
⚠ Log Analytics workspace
        ↓
⚠ Biểu đồ và truy vấn KQL

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

  • A, B, C, D — ⚠ đều là thành phần thật của Traffic Analytics.

Ghi nhớ

⚠ Traffic Analytics trả lời được câu hỏi gì: | Câu hỏi | Nội dung | |---|---| | ⚠ Ai đang nói chuyện với ai | ⚠ giữa các máy, subnet, VNet | | ⚠ Lưu lượng đi tới đâu trên Internet | ⚠ quốc gia, dịch vụ | | ⚠ Kết nối nào bị CHẶN | ⚠ rất hữu ích để tìm luật NSG sai | | ⚠ Máy nào tạo nhiều lưu lượng nhất | | | ⚠ Có kết nối tới IP độc hại không | |

Từ khoá nhận diện:

"ai nói chuyện với ai, lưu lượng đi đâu" → ⚠ Traffic Analytics "nhóm máy nhận lưu lượng từ bộ cân bằng tải" → ⚠ backend pool "giám sát kết nối liên tục" → ⚠ Connection Monitor "luật nào chặn gói này" → ⚠ IP flow verify

⚠ Điều kiện tiên quyết Điều kiện
⚠ NSG flow logs PHẢI được bật ⚠ mặc định TẮT
⚠ Cần một Storage Account ⚠ lưu nhật ký thô
⚠ Cần Log Analytics workspace
⚠ Dữ liệu chỉ có từ lúc bật ⚠ không dựng lại được quá khứ
⚠ Cân nhắc chi phí Cân nhắc
⚠ Nhật ký luồng sinh dữ liệu rất lớn
⚠ Tính tiền theo GB nhập vào Log Analytics
⚠ Chọn khoảng xử lý 10 phút hoặc 1 giờ ⚠ 1 giờ rẻ hơn nhiều
⚠ Bật có chọn lọc cho subnet quan trọng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | NSG flow logs đã bật cho subnet nào | | | Chi phí nhập log hằng tháng là bao nhiêu | | | Có ai thực sự xem báo cáo Traffic Analytics không | |

Và điều nên làm ngay hôm nay dù chưa có sự cố nào: bật NSG flow logs cho các subnet quan trọng. Dữ liệu chỉ có từ lúc bật, và khi cần điều tra thì đã quá muộn để quay ngược thời gian.

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

You are setting up an Azure solution that includes Azure app services and on-prem hosted web apps. These web apps are accessible through the internet using their FQDN. You have chosen Azure Traffic as the load balancing option for this solution, and you have created an Azure Traffic Manager profile named 'MyNewProfile'. Can you please advise which endpoint types you need to configure to add your on-prem web app to the 'MyNewProfile' traffic manager profile?

  1. A

    Azure Endpoints
  2. B

    Nested Endpoints
  3. C

    External Endpoints
  4. D

    Staggered Endpoints
  5. E

    None of the above
Xem giải thích

Đáp án

C — External Endpoints (endpoint bên ngoài).

Vì sao đúng

⚠ Traffic Manager có ba loại endpoint: | Loại | Dùng cho | |---|---| | ⚠ Azure endpoints | ⚠ tài nguyên Azure — App Service, Public IP, Cloud Service | | ⚠ External endpoints | ⚠ dịch vụ NGOÀI Azure — khai bằng FQDN hoặc IP | | ⚠ Nested endpoints | ⚠ một profile Traffic Manager KHÁC |

⚠ Ứng dụng web tại chỗ nằm ngoài Azure → ⚠ phải là external endpoint, khai bằng FQDN của nó.

⚠ MyNewProfile
   ├── ⚠ Azure endpoint    →  ⚠ App Service trên Azure
   └── ⚠ External endpoint →  ⚠ webapp.congty.com (tại chỗ)

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

  • A (Azure endpoints) — ⚠ chỉ dành cho tài nguyên TRONG Azure.

  • B (Nested endpoints) — ⚠ để lồng một profile Traffic Manager khác, không phải để thêm dịch vụ tại chỗ.

  • D (Staggered endpoints) — ⚠ không tồn tại.

  • E (không cái nào) — ⚠ sai vì C đúng.

Ghi nhớ

⚠ Vì sao Traffic Manager làm được điều này: | Lý do | Nội dung | |---|---| | ⚠ Nó làm việc ở tầng DNS | ⚠ chỉ trả về địa chỉ, không cần lưu lượng đi qua | | ⚠ Không cần backend nằm trong Azure | | | ⚠ Thăm dò sức khoẻ qua HTTP/HTTPS/TCP công khai | | | ⚠ Nhờ vậy | ⚠ rất hợp cho kịch bản LAI hoặc chuyển đổi dần lên đám mây |

⚠ Kịch bản dùng external endpoint: | Kịch bản | Nội dung | |---|---| | ⚠ Chuyển dần từ tại chỗ lên Azure | ⚠ weighted routing, tăng dần tỷ lệ về Azure | | ⚠ Tại chỗ làm chính, Azure làm dự phòng | ⚠ priority routing | | ⚠ Đa đám mây | ⚠ endpoint ở nhà cung cấp khác | | ⚠ Giữ hệ thống cũ trong lúc thử nghiệm bản mới | |

Từ khoá nhận diện:

"dịch vụ ngoài Azure" → ⚠ external endpoint "tài nguyên Azure" → ⚠ Azure endpoint "lồng profile khác" → ⚠ nested endpoint "cân bằng tải cho backend ngoài Azure" → ⚠ Traffic Manager hoặc Front Door đều làm được

⚠ Điều kiện cho endpoint tại chỗ Điều kiện
⚠ Phải truy cập được từ Internet công cộng ⚠ để Traffic Manager thăm dò sức khoẻ
⚠ Có FQDN phân giải được
⚠ Endpoint kiểm tra sức khoẻ trả về mã 200
⚠ Nếu chặn probe ⚠ endpoint bị coi là chết và không nhận lưu lượng
⚠ Nhớ giới hạn của cân bằng tải bằng DNS Giới hạn
⚠ Client cache kết quả cho tới khi TTL hết
⚠ Chuyển đổi dự phòng KHÔNG tức thời
⚠ Tỷ lệ chia lưu lượng chỉ đúng theo thống kê
⚠ Cần chuyển đổi nhanh hơn ⚠ dùng Front Door, là proxy ngược thật sự

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Endpoint tại chỗ có cho phép probe từ Internet không | | | TTL đang đặt bao nhiêu | | | Trạng thái sức khoẻ của từng endpoint là gì | ⚠ xem trong Portal |

Và lý do Traffic Manager vẫn hữu ích dù đã có Front Door: nó không đòi backend phải là HTTP và không đòi backend nằm trong Azure. Với một quá trình chuyển đổi dần từ trung tâm dữ liệu lên đám mây, đó đúng là thứ cần.

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

Your IT consultancy has recently partnered with two other firms in various parts of the country. Each of your three offices has resources deployed on the Microsoft Azure cloud. While you intend to eventually consolidate your separate offices into a single Microsoft Entra tenant, you wish to connect several Virtual Networks (VNets) across your separate subscriptions while your current, distinct Microsoft Entra tenants are still operational. What is the simplest Azure solution to achieve this?

  1. A

    Create a VNet peering connection.
  2. B

    Create Virtual Network Gateways.
  3. C

    Create a DNS zone with a split-horizon view.
  4. D

    Create a VNet-to-VNet VPN.
Xem giải thích

Đáp án

A — Tạo kết nối VNet peering.

Vì sao đúng

⚠ Peering nối được VNet xuyên mọi ranh giới, và là cách đơn giản nhất: | Ranh giới | Peering vượt được | |---|---| | ⚠ Khác subscription | ⚠ ĐƯỢC | | ⚠ Khác tenant Entra ID | ⚠ ĐƯỢC | | ⚠ Khác vùng | ⚠ ĐƯỢC — global peering |

⚠ Vì sao "đơn giản nhất": | Lý do | Nội dung | |---|---| | ⚠ Không cần gateway | ⚠ tiết kiệm và nhanh | | ⚠ Dựng trong vài phút | ⚠ gateway mất tới 45 phút | | ⚠ Không tính tiền theo giờ | ⚠ chỉ theo dữ liệu | | ⚠ Độ trễ thấp nhất | | | ⚠ Không gián đoạn tài nguyên | |

⚠ Với peering xuyên tenant, cần cấp quyền RBAC cho phía bên kia — dùng vai Network Contributor trên VNet, hoặc quyền Microsoft.Network/virtualNetworks/peer/action.

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

  • B (tạo Virtual Network Gateway) và D (VNet-to-VNet VPN) — ⚠ làm được nhưng PHỨC TẠP và ĐẮT hơn hẳn: tính tiền theo giờ, độ trễ cao hơn, dựng lâu hơn.

  • C (DNS zone split-horizon) — ⚠ giải bài toán PHÂN GIẢI TÊN, không tạo kết nối mạng.

Ghi nhớ

⚠ Đối chiếu: ⚠ lô này có ba câu về peering — #23229 (peering đáp ứng danh sách yêu cầu), #23250 (so sánh peering với VPN gateway), và câu này. ⚠ Ba câu nhất quán: peering vượt được mọi ranh giới và rẻ hơn gateway.

⚠ Yêu cầu quyền cho peering xuyên tenant: | Bên | Cần | |---|---| | ⚠ Mỗi bên phải cấp quyền cho bên kia | ⚠ thường mời làm khách B2B | | ⚠ Vai trò tối thiểu | ⚠ Network Contributor trên VNet | | ⚠ Peering phải thiết lập ở CẢ HAI phía | ⚠ một phía là trạng thái Initiated |

Từ khoá nhận diện:

"nối VNet, đơn giản nhất" → ⚠ peering "cần mã hoá giữa hai VNet" → ⚠ VPN gateway "phân giải tên khác nhau cho trong và ngoài" → ⚠ split-horizon DNS "nối mạng tại chỗ" → ⚠ VPN hoặc ExpressRoute

⚠ Điều kiện tiên quyết duy nhất Điều kiện
⚠ Dải IP KHÔNG được chồng lấn
⚠ Ba văn phòng nên thống nhất kế hoạch địa chỉ TRƯỚC
⚠ Nếu đã chồng ⚠ phải đánh lại địa chỉ một bên — rất tốn công
⚠ Khi hợp nhất về một tenant sau này Điều
⚠ Peering vẫn hoạt động bình thường
⚠ Nhưng chuyển subscription sang tenant khác thì MẤT hết RBAC
⚠ Phải gán lại quyền sau khi chuyển
⚠ Lên kế hoạch trước ⚠ ghi lại toàn bộ gán quyền hiện có

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ba văn phòng có dải IP chồng nhau không | ⚠ kiểm tra trước tiên | | Quyền peering đã cấp cho phía bên kia chưa | | | Peering đã Connected ở cả hai phía chưa | |

Và việc nên làm ngay khi ba tổ chức bắt đầu hợp tác trên Azure: thống nhất kế hoạch dải địa chỉ IP. Đây là thứ duy nhất có thể chặn peering, và cũng là thứ tốn công nhất để sửa về sau.

Câu 85 Chọn nhiều đáp án Secure network connectivity to Azure resources (15-20%)

You're configuring network security for a set of Azure virtual machines. Which tasks would you perform using Azure Network Security Groups (NSG) and Application Security Groups (ASG)?

  1. A

    Create granular traffic filtering rules for a subnet.
  2. B

    Associate a specific VM's NIC with a security categorization.
  3. C

    Establish site-to-site VPN connectivity.
  4. D

    Group multiple VMs based on their application layer function for simplified NSG rule management.
Xem giải thích

Đáp án

A, B và D.

  • A — Tạo luật lọc lưu lượng chi tiết cho một subnet.
  • B — Gắn card mạng của một máy ảo cụ thể vào một phân loại bảo mật.
  • D — Nhóm nhiều máy ảo theo chức năng ở tầng ứng dụng để đơn giản hoá việc quản lý luật NSG.

Vì sao đúng

⚠ NSG và ASG chia việc rõ ràng: | Công cụ | Việc | |---|---| | ⚠ NSG | ⚠ chứa LUẬT lọc, gắn ở subnet hoặc card mạng | | ⚠ ASG | ⚠ NHÓM các card mạng theo vai trò, để luật viết theo tên nhóm |

⚠ ASG-Web, ASG-App, ASG-Db  →  ⚠ nhóm card mạng theo vai trò
        ↓
⚠ Luật NSG: nguồn = ASG-Web, đích = ASG-App, cổng 8080, Allow
   ⚠ Không có một địa chỉ IP nào trong luật

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

  • C (thiết lập kết nối VPN site-to-site) — ⚠ là việc của VPN Gateway, hoàn toàn không liên quan tới NSG hay ASG.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23209 ở lô trước nói mọi card mạng trong một ASG phải cùng MỘT mạng ảo. ⚠ Câu này hỏi ASG và NSG làm được những việc gì. Hai câu bổ sung nhau.

⚠ Vì sao ASG làm luật dễ đọc hơn hẳn: | Không có ASG | Có ASG | |---|---| | ⚠ Nguồn: 10.0.1.0/24 | ⚠ Nguồn: ASG-Web | | ⚠ Đích: 10.0.2.0/24 | ⚠ Đích: ASG-App | | ⚠ Thêm máy phải sửa luật | ⚠ thêm máy vào nhóm là xong | | ⚠ Người mới đọc không hiểu ý đồ | ⚠ luật tự giải thích |

Từ khoá nhận diện:

"luật lọc lưu lượng" → ⚠ NSG "nhóm card mạng theo vai trò" → ⚠ ASG "nhóm dải IP của dịch vụ Azure" → ⚠ service tag "kết nối VPN" → ⚠ VPN Gateway, không phải NSG

⚠ Giới hạn của ASG Giới hạn
⚠ Mọi card mạng trong ASG phải cùng MỘT VNet
⚠ NSG dùng ASG phải cùng VNet với ASG ⚠ kể cả khi hai VNet đã peering
⚠ Một card mạng thuộc nhiều ASG được
⚠ Kiến trúc nhiều VNet ⚠ phải dùng service tag hoặc dải IP
⚠ Thiết kế ba tầng bằng ASG Thiết kế
⚠ ASG-Web ⚠ nhận 443 từ Internet hoặc Application Gateway
⚠ ASG-App ⚠ chỉ nhận từ ASG-Web, đúng cổng ứng dụng
⚠ ASG-Db ⚠ chỉ nhận từ ASG-App, đúng cổng CSDL
⚠ Kết quả ⚠ bộ luật đọc được như tiếng người, chặn được lan ngang

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật NSG đang viết theo IP hay theo ASG | | | Máy mới có tự được áp luật khi vào nhóm không | | | Có luật nào cho phép rộng hơn cần thiết không | |

Và lợi ích thật của ASG không nằm ở kỹ thuật mà ở khả năng bảo trì: bộ luật viết bằng tên vai trò vẫn còn đúng sau khi hạ tầng thay đổi, trong khi bộ luật viết bằng dải IP thì cứ mỗi lần mở rộng lại phải rà lại từ đầu.

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

You are working on deploying an Azure Firewall in a high-availability architecture that requires the ability to scale based on changing workloads while also having threat intelligence-based filtering. Which Azure Firewall SKU should you select?

  1. A

    Azure Firewall Basic
  2. B

    Azure Firewall Standard
  3. C

    Azure Firewall Premium
  4. D

    Azure Firewall Manager
Xem giải thích

Đáp án

C — Azure Firewall Premium.

Vì sao đúng

⚠ Ba SKU của Azure Firewall: | SKU | Khả năng | |---|---| | ⚠ Basic | ⚠ doanh nghiệp nhỏ, thông lượng thấp, KHÔNG tự co giãn linh hoạt | | ⚠ Standard | ⚠ threat intelligence, lọc FQDN, tự co giãn | | ⚠ Premium | ⚠ mọi thứ của Standard, CỘNG thêm IDPS, kiểm tra TLS, lọc URL, phân loại web |

⚠ Premium là bậc cao nhất, đáp ứng cả hai yêu cầu nêu trong đề và còn hơn thế.

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

  • A (Basic) — ⚠ không đáp ứng được yêu cầu co giãn và threat intelligence đầy đủ.

  • D (Azure Firewall Manager) — ⚠ KHÔNG phải một SKU; đó là dịch vụ quản lý tập trung nhiều firewall.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ hai yêu cầu đề nêu ra — ⚠ tự co giãn theo tải và ⚠ lọc dựa trên threat intelligence — ⚠ bậc STANDARD đã đáp ứng đủ cả hai.

SKU Tự co giãn Threat intelligence Đủ yêu cầu đề nêu
⚠ Basic ⚠ hạn chế ⚠ có, hạn chế ⚠ không
⚠ Standard ⚠ CÓ ⚠ CÓ ⚠ ĐỦ
⚠ Premium ⚠ có ⚠ có ⚠ đủ, và thừa
⚠ Vì sao khoá là Premium ⚠ đề nhấn "kiến trúc sẵn sàng cao" và "biện pháp mạnh nhất"
⚠ Ghi chú thực tế ⚠ nếu chỉ cần đúng hai yêu cầu đó thì Standard rẻ hơn đáng kể
⚠ Khoá ⚠ giữ nguyên C — Premium là tập cha, không sai

⚠ Premium thêm gì so với Standard: | Tính năng | Nội dung | |---|---| | ⚠ TLS inspection | ⚠ giải mã, kiểm tra, mã hoá lại lưu lượng HTTPS | | ⚠ IDPS | ⚠ phát hiện và ngăn chặn xâm nhập, hơn 67.000 chữ ký | | ⚠ URL filtering | ⚠ lọc theo đường dẫn đầy đủ, không chỉ tên miền | | ⚠ Web categories | ⚠ chặn theo nhóm nội dung |

Từ khoá nhận diện:

"kiểm tra nội dung HTTPS" → ⚠ Premium, cần TLS inspection "phát hiện xâm nhập, IDPS" → ⚠ Premium "lọc theo FQDN, threat intelligence" → ⚠ Standard là đủ "quản lý nhiều firewall tập trung" → ⚠ Firewall Manager, KHÔNG phải SKU

⚠ Cái giá của TLS inspection Cái giá
⚠ Cần chứng chỉ CA trung gian trong Key Vault
⚠ Máy khách phải TIN chứng chỉ đó
⚠ Tốn tài nguyên tính toán
⚠ Vấn đề pháp lý và quyền riêng tư ⚠ đọc được nội dung của người dùng
⚠ Vì thế ⚠ chỉ bật khi thật sự cần và đã được phê duyệt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thật sự cần TLS inspection và IDPS không | ⚠ quyết định Standard hay Premium | | Chênh lệch chi phí hai bậc là bao nhiêu | | | Lưu lượng có thật sự đi qua firewall không | ⚠ kiểm tra UDR |

Và câu hỏi nên đặt trước khi chọn Premium: bạn có định bật TLS inspection không? Nếu không, phần lớn giá trị tăng thêm của Premium sẽ không được dùng tới, và Standard là lựa chọn kinh tế hơn nhiều.

Câu 87 Chọn nhiều đáp án Secure network connectivity to Azure resources (15-20%)

Your organization wants to centralize the management of multiple Azure Firewalls across different regions. Additionally, there is a need to deploy an Azure Firewall inside a Virtual WAN hub for traffic inspection. Which of the following actions should you take to meet these requirements?

  1. A

    Implement Azure Firewall Manager policies.
  2. B

    Deploy Azure Firewall in a Virtual Network.
  3. C

    Configure Azure Firewall with Premium SKU.
  4. D

    Create a secure hub by deploying an Azure Firewall inside an Azure Virtual WAN hub.
Xem giải thích

Đáp án

A và D.

  • A — Triển khai các chính sách của Azure Firewall Manager.
  • D — Tạo secure hub bằng cách triển khai Azure Firewall bên trong một Azure Virtual WAN hub.

Vì sao đúng

⚠ Hai yêu cầu, hai giải pháp: | Yêu cầu | Giải pháp | |---|---| | ⚠ Quản lý TẬP TRUNG nhiều firewall ở nhiều vùng | ⚠ Firewall Manager với Firewall Policy dùng chung | | ⚠ Firewall bên trong Virtual WAN hub để kiểm tra lưu lượng | ⚠ Secured Virtual Hub |

⚠ Firewall Manager quản lý hai kiểu hub: | Kiểu | Nội dung | |---|---| | ⚠ Secured Virtual Hub | ⚠ Virtual WAN hub CÓ Azure Firewall bên trong | | ⚠ Hub Virtual Network | ⚠ VNet tự dựng làm hub, có firewall |

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

  • B (triển khai Azure Firewall trong một Virtual Network) — ⚠ giải quyết được vế thứ hai theo kiểu tự dựng, nhưng đề nói rõ bên trong Virtual WAN hub.

  • C (dùng SKU Premium) — ⚠ về TÍNH NĂNG của firewall, không liên quan tới quản lý tập trung.

Ghi nhớ

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

Từ khoá nhận diện:

"quản lý tập trung nhiều firewall" → ⚠ Firewall Manager và Firewall Policy "firewall trong Virtual WAN hub" → ⚠ Secured Virtual Hub "tính năng nâng cao của firewall" → ⚠ SKU Premium "chính sách kế thừa từ cấp trên" → ⚠ Firewall Policy có cha con

⚠ Firewall Manager làm gì Việc
⚠ Quản lý chính sách tập trung
⚠ Triển khai firewall vào Virtual WAN hub hoặc VNet hub
⚠ Quản lý cả DDoS Protection plan
⚠ Tích hợp giải pháp bảo mật của bên thứ ba
⚠ Lưu ý ⚠ KHÔNG phải một SKU, mà là lớp quản lý
⚠ Secured Virtual Hub mang lại gì Lợi ích
⚠ Không phải tự dựng VNet hub
⚠ Định tuyến do Microsoft quản lý
⚠ Lưu lượng giữa các spoke tự đi qua firewall ⚠ không phải viết UDR thủ công
⚠ Đây là ⚠ khác biệt lớn nhất so với hub tự dựng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Các firewall có dùng chung một policy không | ⚠ hay mỗi cái một bộ luật riêng | | Lưu lượng spoke-to-spoke có đi qua firewall không | | | Có chính sách gốc do đội bảo mật quản không | |

Và lợi ích lớn nhất của Secured Virtual Hub so với hub tự dựng: không phải viết và bảo trì user-defined route. Định tuyến để mọi lưu lượng đi qua firewall là phần dễ sai nhất khi tự dựng, và ở đây Microsoft làm sẵn.

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

You are tasked with deploying a Web Application Firewall (WAF) to protect a web application hosted on Azure. The application experiences sudden traffic spikes and needs protection from known threats and custom rule sets that cater to the application's unique requirements. Which Azure service should you primarily utilize?

  1. A

    Azure Application Gateway with WAF
  2. B

    Azure Front Door with WAF
  3. C

    Azure Network Security Group
  4. D

    Azure Firewall
Xem giải thích

Đáp án

A — Azure Application Gateway kèm WAF.

Vì sao đúng

⚠ Đối chiếu ba yêu cầu: | Yêu cầu | Application Gateway WAF | |---|---| | ⚠ Bảo vệ ứng dụng web trên Azure | ⚠ đúng vai trò | | ⚠ Chịu được tải tăng đột biến | ⚠ WAF_v2 TỰ CO GIÃN | | ⚠ Bộ luật tuỳ chỉnh riêng cho ứng dụng | ⚠ custom rules, xét TRƯỚC managed rules | | ⚠ Chống mối đe doạ đã biết | ⚠ managed rule set dựa trên OWASP |

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

  • B (Front Door kèm WAF) — ⚠ cũng có WAF và cũng co giãn, nhưng là dịch vụ TOÀN CẦU ở biên; đề nói ứng dụng hosted trên Azure không nhấn mạnh phân phối toàn cầu, nên lớp trong vùng là lựa chọn trực tiếp hơn.

  • C (Network Security Group) — ⚠ lọc ở tầng 3–4, KHÔNG phân tích được nội dung HTTP.

  • D (Azure Firewall) — ⚠ lọc theo IP, cổng, FQDN, KHÔNG chống được SQL injection hay XSS.

Ghi nhớ

⚠ WAF đặt được ở ba nơi: | Nơi | Phạm vi | |---|---| | ⚠ Application Gateway | ⚠ trong một vùng | | ⚠ Azure Front Door | ⚠ toàn cầu, tại biên | | ⚠ Azure CDN | ⚠ tại biên |

⚠ Chọn WAF ở đâu: | Tình huống | Chọn | |---|---| | ⚠ Ứng dụng trong một vùng | ⚠ Application Gateway | | ⚠ Người dùng nhiều châu lục | ⚠ Front Door | | ⚠ Muốn chặn càng sớm càng tốt | ⚠ Front Door — chặn ngay tại biên | | ⚠ Cần định tuyến chi tiết trong VNet | ⚠ Application Gateway |

Từ khoá nhận diện:

"SQL injection, XSS, OWASP" → ⚠ WAF "lọc IP và cổng" → ⚠ NSG "lọc theo FQDN, threat intelligence" → ⚠ Azure Firewall "toàn cầu, tại biên" → ⚠ Front Door

⚠ WAF_v1 và WAF_v2 Khác
⚠ v1 ⚠ cỡ cố định, không tự co giãn — đã ngừng
⚠ v2 ⚠ TỰ CO GIÃN, hiệu năng cao hơn, hỗ trợ Availability Zones
⚠ Đề nhắc tải đột biến ⚠ chính là lý do phải dùng v2
⚠ Hai lớp luật của WAF Lớp
⚠ Managed rule set ⚠ Microsoft duy trì, cập nhật liên tục
⚠ Custom rules ⚠ của bạn, xét TRƯỚC, gồm match rule và rate limit rule
⚠ Exclusion ⚠ loại trừ tham số gây cảnh báo giả

Ba việc kiểm chứng: | Việc | Cách | |---|---| | WAF đang ở chế độ Detection hay Prevention | ⚠ Detection mãi thì không bảo vệ gì | | Có luật giới hạn tần suất cho endpoint đăng nhập chưa | | | SKU có phải v2 để tự co giãn không | |

Và trình tự triển khai WAF an toàn cho ứng dụng đang chạy: Detection trước, đọc nhật ký tìm cảnh báo giả, thêm exclusion, rồi mới chuyển Prevention. Bật Prevention ngay là cách nhanh nhất để chặn nhầm chính người dùng của mình.

Câu 89 Chọn nhiều đáp án Secure network connectivity to Azure resources (15-20%)

Your company has a web application hosted behind Azure Front Door. You've been tasked to enhance the security by applying Web Application Firewall (WAF) protections. Which of the following actions are essential to ensure the application is protected against common web threats while having flexibility in rule configuration?

  1. A

    Configure WAF on Azure Front Door in prevention mode.
  2. B

    Implement a WAF policy specific to Azure Front Door.
  3. C

    Associate the WAF policy with Azure Front Door.
  4. D

    Enable Azure Network Security Group on Azure Front Door.
Xem giải thích

Đáp án

A, B và C.

  • A — Cấu hình WAF trên Azure Front Door ở chế độ prevention.
  • B — Tạo một chính sách WAF dành riêng cho Azure Front Door.
  • C — Gắn chính sách WAF đó với Azure Front Door.

Vì sao đúng

⚠ Ba bước bắt buộc, thiếu bước nào cũng không bảo vệ được: | Bước | Nội dung | |---|---| | ⚠ B — Tạo chính sách | ⚠ policy phải là loại dành cho Front Door, không dùng chung với Application Gateway | | ⚠ C — Gắn chính sách | ⚠ gắn vào endpoint hoặc domain của Front Door | | ⚠ A — Đặt chế độ Prevention | ⚠ để thật sự CHẶN, không chỉ ghi nhật ký |

⚠ Tạo policy  →  ⚠ Gắn vào Front Door  →  ⚠ Chuyển sang Prevention
   ⚠ Thiếu bước cuối = ⚠ có nhật ký mà không chặn gì

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

  • D (bật Network Security Group trên Azure Front Door) — ⚠ KHÔNG áp dụng được; Front Door là dịch vụ toàn cầu ở biên, không nằm trong VNet của bạn nên không gắn NSG được.

Ghi nhớ

⚠ Chính sách WAF của Front Door và của Application Gateway là HAI LOẠI KHÁC NHAU: | Loại policy | Dùng cho | |---|---| | ⚠ WAF policy cho Front Door | ⚠ chỉ gắn được với Front Door | | ⚠ WAF policy cho Application Gateway | ⚠ chỉ gắn được với Application Gateway | | ⚠ Không dùng chéo được | ⚠ đây là điểm hay bị nhầm |

⚠ Hai chế độ WAF: | Chế độ | Hành vi | |---|---| | ⚠ Detection | ⚠ chỉ GHI NHẬT KÝ, cho qua | | ⚠ Prevention | ⚠ CHẶN thật | | ⚠ Triển khai an toàn | ⚠ Detection trước, sửa cảnh báo giả, rồi Prevention | | ⚠ Bẫy phổ biến | ⚠ để Detection mãi rồi quên |

Từ khoá nhận diện:

"chặn thật" → ⚠ Prevention mode "chỉ quan sát" → ⚠ Detection mode "chính sách riêng cho Front Door" → ⚠ WAF policy loại Front Door "NSG cho Front Door" → ⚠ KHÔNG áp dụng được

⚠ Vì sao WAF ở Front Door lại hay Lý do
⚠ Chặn ngay tại BIÊN, gần kẻ tấn công nhất
⚠ Lưu lượng độc hại không tiêu tài nguyên vùng của bạn
⚠ Chặn được ở quy mô toàn cầu
⚠ Kết hợp cả DDoS Protection ở nền tảng
⚠ Có nên đặt WAF ở CẢ hai lớp không Cân nhắc
⚠ Front Door WAF ⚠ lọc thô ở biên, chặn phần lớn
⚠ Application Gateway WAF ⚠ lọc chi tiết theo ứng dụng trong vùng
⚠ Đặt cả hai ⚠ phòng thủ nhiều lớp, nhưng tăng chi phí và độ phức tạp
⚠ Đa số trường hợp ⚠ một lớp là đủ, chọn theo phạm vi người dùng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách đã gắn vào endpoint chưa | ⚠ tạo policy mà không gắn thì vô tác dụng | | Đang ở chế độ nào | | | Có luật nào bị tắt vì cảnh báo giả không | ⚠ xem lại định kỳ |

Và ba cách phổ biến khiến một WAF tồn tại mà không bảo vệ gì: chính sách chưa được gắn, đang ở chế độ Detection, hoặc luật quan trọng đã bị tắt vì cảnh báo giả. Cả ba đều trông hoàn toàn bình thường trên giao diện.

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

You're setting up an ExpressRoute circuit and need to enable connectivity to both Microsoft Azure services and Microsoft 365. Which peering configuration(s) should you select?

  1. A

    Private peering only.
  2. B

    Microsoft peering only.
  3. C

    Both private peering and Microsoft peering.
  4. D

    None of the above.
Xem giải thích

Đáp án

C — Cả private peering và Microsoft peering.

Vì sao đúng

⚠ Hai loại peering phục vụ hai nhóm đích khác nhau: | Peering | Tới đâu | Địa chỉ | |---|---|---| | ⚠ Private peering | ⚠ mạng ảo của bạn trên Azure | ⚠ IP riêng | | ⚠ Microsoft peering | ⚠ dịch vụ công cộng của Microsoft — Microsoft 365, Dynamics 365, PaaS công cộng | ⚠ IP công cộng |

⚠ ExpressRoute circuit
   ├── ⚠ Private peering    →  ⚠ VNet của bạn (máy ảo, private endpoint)
   └── ⚠ Microsoft peering  →  ⚠ Microsoft 365, Azure PaaS công cộng

⚠ Đề yêu cầu CẢ HAI — dịch vụ Azure trong VNet và Microsoft 365 — nên phải cấu hình cả hai peering trên cùng một circuit.

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

  • A (chỉ private peering) — ⚠ không tới được Microsoft 365.

  • B (chỉ Microsoft peering) — ⚠ không tới được mạng ảo của bạn.

  • D (không phương án nào) — ⚠ sai vì C đúng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23181 ở lô trước hỏi loại peering nào chấp nhận mọi IP trong dải WAN (đáp án Private Peering). ⚠ Câu này hỏi khi cần cả hai nhóm đích. Hai câu bổ sung nhau.

⚠ Yêu cầu của Microsoft peering — nghiêm ngặt hơn nhiều: | Yêu cầu | Nội dung | |---|---| | ⚠ IP công cộng đã ĐĂNG KÝ | ⚠ thuộc sở hữu của bạn hoặc nhà cung cấp | | ⚠ Số AS hợp lệ | | | ⚠ Đăng ký định tuyến hợp lệ | ⚠ Microsoft xác minh quyền sở hữu tiền tố | | ⚠ Bộ lọc tuyến | ⚠ route filter chọn dịch vụ nào được quảng bá | | ⚠ Private peering | ⚠ chỉ cần IP riêng bất kỳ trong dải WAN của bạn |

Từ khoá nhận diện:

"tới máy ảo trong VNet" → ⚠ private peering "tới Microsoft 365 hoặc dịch vụ PaaS công cộng" → ⚠ Microsoft peering "public peering" → ⚠ loại CŨ đã bị thay thế "chọn dịch vụ nào được quảng bá" → ⚠ route filter

⚠ Có nên dùng ExpressRoute cho Microsoft 365 không Cân nhắc
⚠ Microsoft KHUYẾN NGHỊ đi Internet cho Microsoft 365 ⚠ thiết kế của M365 tối ưu cho Internet
⚠ ExpressRoute cho M365 chỉ hợp một số ít trường hợp ⚠ yêu cầu pháp lý đặc thù
⚠ Đưa lưu lượng M365 qua ExpressRoute có thể LÀM CHẬM
⚠ Vì thế ⚠ cân nhắc kỹ trước khi bật Microsoft peering cho M365
⚠ Ba loại peering của ExpressRoute Loại
⚠ Private peering ⚠ VNet, dùng phổ biến nhất
⚠ Microsoft peering ⚠ dịch vụ công cộng của Microsoft
⚠ Public peering ⚠ CŨ, đã bị Microsoft peering thay thế

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thật sự cần Microsoft 365 đi qua ExpressRoute không | ⚠ đọc khuyến nghị của Microsoft trước | | Có IP công cộng đã đăng ký và số AS chưa | | | Route filter đã chọn đúng dịch vụ chưa | |

Và lời khuyên chính thức của Microsoft mà nhiều tổ chức bỏ qua: đưa lưu lượng Microsoft 365 qua ExpressRoute thường làm trải nghiệm TỆ HƠN, vì M365 được thiết kế để tận dụng đường Internet gần nhất. Chỉ bật Microsoft peering khi có lý do pháp lý rõ ràng.