Ngân hàng đề — Microsoft Azure Security Technology

Tìm thấy 100 câu.

Câu 61 Secure networking (20-25%)
You are designing a virtual network in Azure. For fine-grained control over traffic that flows within the subnet, you plan to use a specific Azure feature. Which of the following would you implement?
  1. A Virtual Network Peering
  2. B User-Defined Routes (UDRs)
  3. C Azure Virtual WAN
  4. D Virtual Network Gateway
  5. E

    Network Security Groups (NSGs)
Xem giải thích

Đáp án

E — Network Security Groups (NSG).

Vì sao đúng

⚠ NSG là công cụ lọc lưu lượng chi tiết ở mức subnet và card mạng: | Lọc theo | Nội dung | |---|---| | ⚠ Địa chỉ IP nguồn và đích | ⚠ hoặc service tag, hoặc ASG | | ⚠ Cổng nguồn và đích | | | ⚠ Giao thức | ⚠ TCP, UDP, ICMP, Any | | ⚠ Chiều | ⚠ vào hoặc ra | | ⚠ Hành động | ⚠ Allow hoặc Deny | | ⚠ Độ ưu tiên | ⚠ 100 tới 4096 |

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

  • B (User-Defined Routes) — ⚠ quyết định gói ĐI ĐÂU, không quyết định cho phép hay chặn.

  • A (VNet Peering) — ⚠ nối hai VNet.

  • D (Virtual Network Gateway) — ⚠ kết nối lai VPN hoặc ExpressRoute.

  • C (Virtual WAN) — ⚠ kiến trúc mạng tập trung nhiều site.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23802 ở lô trước hỏi hạn chế lưu lượng giữa hai VM theo VAI TRÒ (đáp án ASG), còn #23214 hỏi giới hạn kết nối từ web tới CSDL (đáp án NSG). ⚠ Câu này hỏi kiểm soát chi tiết trong subnet — NSG là công cụ chứa luật.

⚠ NSG và ASG dùng chung: | Thành phần | Vai trò | |---|---| | ⚠ NSG | ⚠ CHỨA luật, gắn vào subnet hoặc card mạng | | ⚠ ASG | ⚠ NHÓM card mạng theo vai trò, để luật tham chiếu bằng tên | | ⚠ Không thay thế nhau | ⚠ ASG không có luật; NSG không nhóm máy |

Từ khoá nhận diện:

"lọc lưu lượng theo IP, cổng, giao thức" → ⚠ NSG "nhóm máy theo vai trò" → ⚠ ASG "quyết định gói đi đâu" → ⚠ UDR "lọc theo tên miền" → ⚠ Azure Firewall, NSG không làm được

⚠ Sáu luật mặc định của NSG Luật
⚠ AllowVNetInBound ⚠ 65000
⚠ AllowAzureLoadBalancerInBound ⚠ 65001
⚠ DenyAllInBound ⚠ 65500
⚠ AllowVnetOutBound ⚠ 65000
⚠ AllowInternetOutBound ⚠ 65001
⚠ DenyAllOutBound ⚠ 65500
⚠ Nghĩa là ⚠ mặc định CHẶN vào từ Internet, CHO PHÉP ra Internet
⚠ Bẫy hay gặp Bẫy
⚠ Gắn NSG ở CẢ subnet và card mạng ⚠ gói phải qua CẢ HAI
⚠ Tạo NSG mà quên GẮN ⚠ nó không lọc gì cả
⚠ Chặn hết chiều ra ⚠ hỏng cập nhật và agent giám sát
⚠ Mở 3389 hoặc 22 ra Internet ⚠ dùng Bastion thay thế

Ba việc kiểm chứng: | Việc | Cách | |---|---| | NSG đã được gắn vào subnet chưa | | | Có luật nào mở cổng quản trị ra Internet không | | | Effective security rules có đúng như thiết kế không | |

Và cách gỡ lỗi NSG nhanh nhất khi kết nối không thông: IP flow verify của Network Watcher. Nó chỉ thẳng ra luật nào đang chặn, thay vì phải đọc tay hai bộ luật chồng nhau.

Câu 62 Chọn nhiều đáp án Secure networking (20-25%)

Which of the following are features or functionalities associated with Network Security Groups (NSGs) in Azure? (Select two)

  1. A Filtering traffic between virtual networks
  2. B Associating with a secured virtual hub
  3. C

    Protocol
  4. D Routing mechanisms for UDRs
Xem giải thích

Đáp án

A và C — Lọc lưu lượng giữa các mạng ảo, và Protocol (giao thức).

Vì sao đúng

⚠ Hai điều đúng về NSG: | Điều | Nội dung | |---|---| | ⚠ Lọc lưu lượng giữa các VNet | ⚠ khi hai VNet đã peering, NSG vẫn lọc được lưu lượng qua lại | | ⚠ Protocol là một thuộc tính của luật | ⚠ TCP, UDP, ICMP, hoặc Any |

⚠ Một luật NSG gồm những gì: | Thuộc tính | Nội dung | |---|---| | ⚠ Priority | ⚠ 100 – 4096, số nhỏ xét trước | | ⚠ Source và Destination | ⚠ IP, service tag, hoặc ASG | | ⚠ Source port và Destination port | | | ⚠ Protocol | ⚠ TCP, UDP, ICMP, Any | | ⚠ Direction | ⚠ Inbound hoặc Outbound | | ⚠ Action | ⚠ Allow hoặc Deny |

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

  • B (gắn với secured virtual hub) — ⚠ secured virtual hub là khái niệm của Virtual WAN kèm Azure Firewall; ⚠ NSG không gắn vào hub được.

  • D (cơ chế định tuyến cho UDR) — ⚠ định tuyến là việc của route table, hoàn toàn tách biệt với NSG.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23835 trong lô này hỏi công cụ nào kiểm soát lưu lượng chi tiết (đáp án NSG). ⚠ Câu này đi vào các thuộc tính của nó. Hai câu bổ sung nhau.

⚠ Điều NSG LÀM ĐƯỢC và KHÔNG LÀM ĐƯỢC: | Làm được | KHÔNG làm được | |---|---| | ⚠ Lọc theo IP, cổng, giao thức | ⚠ lọc theo tên miền (FQDN) | | ⚠ Lọc theo service tag | ⚠ phân tích nội dung HTTP | | ⚠ Lọc theo ASG | ⚠ định tuyến gói tin | | ⚠ Lọc cả hai chiều | ⚠ chống DDoS quy mô lớn | | ⚠ Áp cho lưu lượng giữa VNet đã peering | ⚠ gắn vào Virtual WAN hub |

Từ khoá nhận diện:

"IP, cổng, giao thức" → ⚠ NSG "tên miền" → ⚠ Azure Firewall "nội dung HTTP" → ⚠ WAF "gói đi đường nào" → ⚠ route table và UDR

⚠ Service tag — làm luật NSG gọn hơn Tag
⚠ Internet ⚠ mọi địa chỉ ngoài VNet và mạng đã nối
⚠ VirtualNetwork ⚠ VNet của bạn, VNet peering, mạng tại chỗ đã nối
⚠ AzureLoadBalancer ⚠ hạ tầng thăm dò sức khoẻ
⚠ Storage.EastUS, Sql.EastUS ⚠ dịch vụ theo vùng
⚠ Lợi ích ⚠ Microsoft tự cập nhật dải IP, bạn không phải duy trì
⚠ Lưu ý về NSG với VNet peering Lưu ý
⚠ Tag VirtualNetwork BAO GỒM cả VNet đã peering
⚠ Luật mặc định AllowVNetInBound cho phép lưu lượng đó
⚠ Muốn chặn giữa hai VNet peering thì phải viết luật RIÊNG
⚠ Đây là ⚠ điểm hay gây bất ngờ khi nghĩ peering là đã cách ly

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lưu lượng giữa hai VNet peering có bị kiểm soát không | ⚠ mặc định là CHO PHÉP | | Luật có dùng service tag thay vì dải IP thủ công không | | | Có luật nào cho phép rộng hơn cần thiết không | |

Và điều hay gây bất ngờ nhất về NSG và peering: tag VirtualNetwork bao gồm cả mạng đã peering. Nghĩa là hai VNet vừa peering xong đã nói chuyện được với nhau ở mọi cổng — muốn cách ly thì phải viết luật riêng.

Câu 63 Secure networking (20-25%)
You are setting up a hybrid connection between your on-premises network and Azure. You want to ensure the connection is private and doesn't go over the public Internet. Which Azure service would you implement for this?
  1. A Azure VPN Gateway
  2. B Network Watcher
  3. C ExpressRoute
  4. D Virtual Network Peering
Xem giải thích

Đáp án

C — ExpressRoute.

Vì sao đúng

⚠ ExpressRoute là kết nối RIÊNG, không đi qua Internet công cộng: | Đặc điểm | Nội dung | |---|---| | ⚠ Đấu nối qua nhà cung cấp dịch vụ | ⚠ không qua Internet | | ⚠ Băng thông tới 100 Gbps | | | ⚠ Độ trễ ổn định, dự đoán được | | | ⚠ SLA 99,95% cho circuit | | | ⚠ Nhưng KHÔNG tự mã hoá | ⚠ riêng tư ≠ được mã hoá |

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

  • A (VPN Gateway) — ⚠ có mã hoá nhưng ĐI QUA Internet công cộng; đề yêu cầu rõ không qua Internet.

  • D (VNet Peering) — ⚠ nối hai VNet TRONG Azure, không nối được mạng tại chỗ.

  • B (Network Watcher) — ⚠ bộ công cụ chẩn đoán, không tạo kết nối.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23795 ở lô trước liệt kê ba lựa chọn nối tại chỗ với Azure, còn #23251 hỏi nên chọn gì khi cần kết nối riêng có dự phòng. ⚠ Ba câu nhất quán.

⚠ Ba lựa chọn nối tại chỗ với Azure: | Lựa chọn | Qua Internet | Mã hoá | |---|---|---| | ⚠ VPN Site-to-Site | ⚠ CÓ | ⚠ CÓ — IPsec | | ⚠ ExpressRoute | ⚠ KHÔNG | ⚠ KHÔNG mặc định | | ⚠ ExpressRoute + VPN | ⚠ không | ⚠ có |

Từ khoá nhận diện:

"riêng tư, không qua Internet" → ⚠ ExpressRoute "mã hoá lưu lượng" → ⚠ VPN Gateway "vừa riêng vừa mã hoá" → ⚠ VPN chạy trên ExpressRoute "nối hai site tại chỗ với nhau" → ⚠ ExpressRoute Global Reach

⚠ Ba loại peering của ExpressRoute Loại
⚠ Private peering ⚠ tới mạng ảo của bạn, dùng IP riêng
⚠ Microsoft peering ⚠ tới Microsoft 365 và PaaS công cộng, cần IP công cộng đã đăng ký
⚠ Public peering ⚠ loại CŨ, đã bị thay thế
⚠ Ba SKU của ExpressRoute SKU
⚠ Local ⚠ chỉ tới vùng gần peering location, rẻ nhất
⚠ Standard ⚠ tới mọi vùng trong cùng khu vực địa lý
⚠ Premium ⚠ toàn cầu, nhiều tuyến và nhiều VNet hơn
⚠ Ràng buộc cần nhớ Ràng buộc
⚠ TĂNG băng thông được, không gián đoạn
⚠ GIẢM băng thông thì phải TẠO LẠI circuit
⚠ Chuyển metered sang unlimited là MỘT CHIỀU
⚠ Vì thế ⚠ bắt đầu ở mức vừa đủ rồi nâng dần

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu đi qua có yêu cầu mã hoá theo quy định không | ⚠ ExpressRoute không tự mã hoá | | Có đường dự phòng khi circuit hỏng không | | | Băng thông hiện tại có đang dùng hết không | |

Và hiểu nhầm phổ biến nhất về ExpressRoute: tưởng "kết nối riêng" đồng nghĩa với "được mã hoá". Nó riêng về đường truyền, nhưng dữ liệu vẫn đi dạng rõ nếu bạn không tự thêm lớp mã hoá.

Câu 64 Secure networking (20-25%)
When integrating Azure App Service with an Azure virtual network, which feature enables the App Service to access resources in the virtual network?
  1. A Service Endpoints
  2. B Private Link
  3. C VNet Integration
  4. D Private DNS Zone
Xem giải thích

Đáp án

C — VNet Integration (tích hợp mạng ảo).

Vì sao đúng

⚠ VNet Integration cho App Service gọi RA tài nguyên trong mạng ảo: | Chiều | Cơ chế | |---|---| | ⚠ App Service gọi RA vào VNet | ⚠ VNet Integration | | ⚠ Từ VNet gọi VÀO App Service | ⚠ Private Endpoint |

⚠ App Service  →  ⚠ VNet Integration  →  ⚠ VM, CSDL, Redis trong VNet
⚠ VNet         →  ⚠ Private Endpoint  →  ⚠ App Service

⚠ Hai cơ chế cho HAI CHIỀU khác nhau — đây là điểm hay nhầm nhất.

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

  • B (Private Link) — ⚠ cho chiều NGƯỢC LẠI: từ trong VNet truy cập App Service qua IP riêng.

  • A (Service Endpoints) — ⚠ cho tài nguyên TRONG VNet truy cập dịch vụ PaaS, không phải cho App Service gọi vào VNet.

  • D (Private DNS Zone) — ⚠ phân giải tên, là thành phần hỗ trợ chứ không tạo kết nối.

Ghi nhớ

⚠ Ba nhu cầu mạng của App Service — ba giải pháp: | Nhu cầu | Giải pháp | |---|---| | ⚠ App gọi RA tài nguyên trong VNet | ⚠ VNet Integration | | ⚠ Chỉ truy cập được app từ trong mạng | ⚠ Private Endpoint | | ⚠ Cách ly hoàn toàn, hạ tầng riêng | ⚠ App Service Environment |

Từ khoá nhận diện:

"app gọi vào VNet" → ⚠ VNet Integration "truy cập app qua IP riêng" → ⚠ Private Endpoint "hạ tầng riêng, cách ly hoàn toàn" → ⚠ ASE "tài nguyên trong VNet gọi PaaS" → ⚠ Service Endpoint hoặc Private Endpoint

⚠ Điều cần biết về VNet Integration Điều
⚠ Cần một subnet RIÊNG được uỷ quyền ⚠ delegation tới Microsoft.Web
⚠ Chỉ áp cho lưu lượng ĐI RA
⚠ Mặc định chỉ định tuyến lưu lượng RFC 1918 ⚠ địa chỉ riêng
⚠ Muốn định tuyến MỌI lưu lượng ra qua VNet ⚠ bật vnetRouteAllEnabled
⚠ Cần bậc Basic trở lên ⚠ Free và Shared không hỗ trợ
⚠ Vì sao hay bật "route all" Lý do
⚠ Để mọi lưu lượng ra đi qua Azure Firewall ở hub
⚠ Để kiểm soát và ghi nhật ký lưu lượng của app
⚠ Để app dùng NAT Gateway, có IP ra ngoài cố định
⚠ Không bật ⚠ lưu lượng ra Internet vẫn đi thẳng, không qua firewall

Ba việc kiểm chứng: | Việc | Cách | |---|---| | App có cần gọi vào VNet không | ⚠ CSDL, Redis, API nội bộ | | Có cần chặn truy cập công khai vào app không | ⚠ thì thêm private endpoint | | Lưu lượng ra Internet của app có đi qua firewall không | ⚠ kiểm tra route all |

Và cấu hình dễ bị hiểu nhầm nhất của VNet Integration: mặc định chỉ định tuyến địa chỉ riêng qua VNet. App vẫn ra Internet theo đường trực tiếp, không qua firewall của bạn — trừ khi bật thêm tuỳ chọn định tuyến toàn bộ.

Câu 65 Chọn nhiều đáp án Secure networking (20-25%)

You are tasked with securing access to an Azure SQL Managed Instance.

Which of the following can be used to secure and limit access to the instance from the internet? (Select three)

  1. A Virtual Network Service Endpoints
  2. B Azure Firewall
  3. C Private Link services
  4. D Azure Front Door
  5. E

    DMZ
  6. F

    IP whitelisting
Xem giải thích

Đáp án

A, B và C — Virtual Network Service Endpoints, Azure Firewall, và Private Link services.

Vì sao đúng

⚠ Ba biện pháp ở ba tầng khác nhau: | Biện pháp | Vai trò | |---|---| | ⚠ Service Endpoints | ⚠ giới hạn truy cập chỉ từ subnet được khai | | ⚠ Azure Firewall | ⚠ kiểm soát tập trung lưu lượng vào và ra ở biên VNet | | ⚠ Private Link | ⚠ truy cập qua IP RIÊNG, không qua endpoint công cộng |

⚠ Bản thân SQL Managed Instance đã nằm TRONG VNet — ⚠ nhưng nó có tuỳ chọn public endpoint, và ba biện pháp trên siết chặt thêm.

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

  • D (Azure Front Door) — ⚠ định tuyến và tăng tốc HTTP toàn cầu; ⚠ không dùng cho lưu lượng CSDL.

  • E (DMZ) — ⚠ là một KHÁI NIỆM kiến trúc mạng, không phải dịch vụ Azure cụ thể.

  • F (IP whitelisting) — ⚠ là một KỸ THUẬT chung; với Managed Instance, cơ chế cụ thể là NSG và firewall của public endpoint, không phải một tính năng có tên như vậy.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23807 ở lô trước hỏi cấu hình nào để Managed Instance không truy cập được từ Internet (đáp án: subnet riêng trong VNet). ⚠ Câu này liệt kê các biện pháp siết thêm. Hai câu bổ sung nhau.

⚠ SQL Managed Instance — kiến trúc mạng: | Đặc điểm | Nội dung | |---|---| | ⚠ Triển khai vào subnet RIÊNG | ⚠ được uỷ quyền tới Microsoft.Sql/managedInstances | | ⚠ Có IP RIÊNG trong subnet đó | | | ⚠ Public endpoint là TUỲ CHỌN | ⚠ mặc định tắt, và NÊN để tắt | | ⚠ NSG của subnet phải theo yêu cầu của dịch vụ | |

Từ khoá nhận diện:

"CSDL nằm trong VNet" → ⚠ SQL Managed Instance "chỉ subnet này truy cập được PaaS" → ⚠ Service Endpoint "IP riêng cho dịch vụ" → ⚠ Private Endpoint và Private Link "kiểm soát tập trung ở biên" → ⚠ Azure Firewall

⚠ Danh sách siết bảo mật cho Managed Instance Mục
⚠ TẮT public endpoint ⚠ việc quan trọng nhất
⚠ NSG chặt cho subnet
⚠ Xác thực bằng Entra ID ⚠ thay vì SQL authentication
⚠ Bật TDE và Auditing
⚠ Bật Defender for SQL
⚠ Buộc TLS phiên bản tối thiểu
⚠ Vì sao public endpoint của Managed Instance là rủi ro Lý do
⚠ Nó phơi CSDL ra Internet ⚠ dù có firewall lọc IP
⚠ Dùng cổng 3342, không phải 1433 ⚠ dễ bị quên khi rà soát
⚠ Chỉ bật khi ⚠ thật sự cần và không có cách nào khác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Public endpoint của Managed Instance có đang bật không | | | Xác thực đang dùng Entra ID hay SQL authentication | | | Defender for SQL đã bật chưa | |

Và cấu hình đáng kiểm tra đầu tiên trên mọi SQL Managed Instance: public endpoint. Nó tắt theo mặc định, nhưng một khi ai đó bật lên để tiện gỡ lỗi thì rất hiếm khi được tắt lại.

Câu 66 Secure networking (20-25%)
In an Azure App Service Environment (ASE), what provides the primary layer of network defense against malicious internet traffic?
  1. A Network Watcher
  2. B Network Security Group (NSG)
  3. C Application Gateway
  4. D Traffic Manager
  5. E

    Azure Firewall
Xem giải thích

Đáp án

E — Azure Firewall.

Vì sao đúng

⚠ Trong kiến trúc App Service Environment, Azure Firewall đóng vai trò kiểm soát tập trung: | Vai trò | Nội dung | |---|---| | ⚠ Kiểm soát lưu lượng vào và ra của ASE | | | ⚠ Lọc theo FQDN cho lưu lượng đi ra | ⚠ ASE cần gọi ra một số endpoint bắt buộc của Azure | | ⚠ Threat intelligence | ⚠ chặn IP và tên miền độc hại | | ⚠ Ghi nhật ký tập trung | | | ⚠ Là điểm kiểm soát duy nhất cho cả VNet | |

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

  • C (Application Gateway) — ⚠ cân bằng tải tầng 7 và WAF, thường đứng TRƯỚC ASE cho lưu lượng vào; hữu ích nhưng không phải lớp phòng thủ mạng tổng thể.

  • A (Network Watcher) — ⚠ công cụ chẩn đoán, không chặn gì.

  • D (Traffic Manager) — ⚠ định tuyến bằng DNS, không lọc lưu lượng.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án B — Network Security Group ⚠ cũng là một lớp phòng thủ mạng rất quan trọng cho subnet của ASE, và nhiều người sẽ chọn nó.

Phương án Lập luận
⚠ B — NSG ⚠ lọc ở mức SUBNET, miễn phí, là lớp cơ bản BẮT BUỘC phải có cho ASE
⚠ E — Azure Firewall (khoá) ⚠ kiểm soát TẬP TRUNG cả vào lẫn ra, lọc FQDN, có threat intelligence
⚠ Đề nhấn ⚠ "phòng thủ trước lưu lượng Internet ĐỘC HẠI" — nghiêng về khả năng nhận diện mối đe doạ
⚠ Trong thực tế ⚠ dùng CẢ HAI: NSG phân đoạn, Firewall kiểm soát biên
⚠ Khoá ⚠ giữ nguyên E

⚠ Kiến trúc bảo mật cho ASE: | Lớp | Công cụ | |---|---| | ⚠ Vành đai | ⚠ DDoS Protection | | ⚠ Biên VNet | ⚠ Azure Firewall — kiểm soát vào và ra | | ⚠ Trước ứng dụng | ⚠ Application Gateway kèm WAF | | ⚠ Subnet | ⚠ NSG | | ⚠ Ứng dụng | ⚠ HTTPS Only, xác thực, IP restrictions |

Từ khoá nhận diện:

"kiểm soát tập trung, lọc FQDN, threat intelligence" → ⚠ Azure Firewall "lọc theo IP và cổng ở subnet" → ⚠ NSG "chống SQL injection cho web" → ⚠ WAF "chẩn đoán mạng" → ⚠ Network Watcher

⚠ Điều đặc thù của ASE Điều
⚠ ASE cần gọi ra một số endpoint BẮT BUỘC ⚠ để nhận cấu hình và báo cáo tình trạng
⚠ Chặn nhầm là ASE trở nên KHÔNG KHOẺ
⚠ Phải mở đúng danh sách FQDN mà Microsoft công bố
⚠ Đây là ⚠ lý do Azure Firewall với luật FQDN phù hợp hơn NSG thuần

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lưu lượng ra của ASE có đi qua firewall không | ⚠ kiểm tra UDR | | Các FQDN bắt buộc của ASE đã được cho phép chưa | | | ASE đang ở trạng thái khoẻ hay không | |

Và lý do NSG thuần không đủ cho ASE: ASE cần gọi ra một danh sách endpoint quản lý của Azure, và danh sách đó thay đổi. Lọc theo FQDN bằng Azure Firewall bền hơn hẳn việc tự duy trì hàng chục dải IP trong NSG.

Câu 67 Secure networking (20-25%)
For end-to-end encryption in Azure App Service, which of the following configurations ensures that inbound and outbound traffic from your app is encrypted?
  1. A HTTPS Only
  2. B Managed Service Identity
  3. C IP Restrictions
  4. D Custom Domain SSL
Xem giải thích

Đáp án

A — HTTPS Only.

Vì sao đúng

⚠ Bật "HTTPS Only" buộc mọi lưu lượng đi qua TLS: | Hành vi | Nội dung | |---|---| | ⚠ Yêu cầu HTTP tự chuyển hướng sang HTTPS | ⚠ mã 301 | | ⚠ Không còn cửa nào nhận lưu lượng không mã hoá | | | ⚠ Áp cho cả tên miền mặc định lẫn tên miền tuỳ chỉnh | |

⚠ Kết hợp thêm: | Cấu hình | Nội dung | |---|---| | ⚠ Minimum TLS version 1.2 trở lên | ⚠ loại bỏ TLS 1.0 và 1.1 đã lỗi thời | | ⚠ HSTS | ⚠ buộc trình duyệt luôn dùng HTTPS | | ⚠ End-to-end TLS | ⚠ mã hoá cả chặng tới backend nếu có |

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

  • D (Custom Domain SSL) — ⚠ gắn chứng chỉ cho tên miền riêng; ⚠ cần thiết nhưng không tự buộc mọi lưu lượng dùng HTTPS.

  • B (Managed Service Identity) — ⚠ định danh cho ứng dụng, không mã hoá gì.

  • C (IP Restrictions) — ⚠ giới hạn địa chỉ truy cập, không mã hoá.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23775 ở lô trước hỏi giao thức nào mã hoá dữ liệu khi truyền tới App Service (đáp án SSL/TLS). ⚠ Câu này hỏi CẤU HÌNH nào buộc dùng nó. Hai câu bổ sung nhau.

⚠ Danh sách cấu hình bảo mật cho App Service: | Cấu hình | Nội dung | |---|---| | ⚠ HTTPS Only | ⚠ bật | | ⚠ Minimum TLS version | ⚠ 1.2 trở lên | | ⚠ Client certificate | ⚠ nếu cần xác thực hai chiều | | ⚠ Authentication (Easy Auth) | ⚠ tích hợp Entra ID | | ⚠ IP restrictions hoặc private endpoint | | | ⚠ Managed identity | ⚠ thay cho bí mật trong cấu hình | | ⚠ Key Vault references | ⚠ cho app settings nhạy cảm | | ⚠ FTP state | ⚠ tắt FTP, hoặc chỉ cho FTPS |

Từ khoá nhận diện:

"buộc mọi lưu lượng dùng HTTPS" → ⚠ HTTPS Only "gắn chứng chỉ cho tên miền riêng" → ⚠ Custom Domain SSL "giới hạn IP truy cập" → ⚠ IP Restrictions "mã hoá cả chặng tới backend" → ⚠ end-to-end TLS

⚠ Chứng chỉ cho App Service Lựa chọn
⚠ App Service Managed Certificate ⚠ MIỄN PHÍ, tự gia hạn, cho tên miền tuỳ chỉnh
⚠ App Service Certificate ⚠ mua qua Azure, lưu trong Key Vault
⚠ Chứng chỉ tự mang lên ⚠ tải lên hoặc tham chiếu Key Vault
⚠ Khuyến nghị ⚠ dùng loại tự gia hạn để tránh sự cố hết hạn
⚠ Cấu hình mặc định cần sửa Cấu hình
⚠ HTTPS Only mặc định TẮT ⚠ ở nhiều cách tạo app
⚠ Minimum TLS có thể vẫn là 1.0 ở app cũ
⚠ FTP có thể đang bật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | HTTPS Only đã bật chưa | | | TLS tối thiểu là phiên bản nào | | | Chứng chỉ còn hạn bao lâu | ⚠ hết hạn là sự cố toàn phần |

Và sự cố có thể phòng tránh dễ nhất mà vẫn xảy ra thường xuyên: chứng chỉ TLS hết hạn. Dùng chứng chỉ tự gia hạn, hoặc đặt cảnh báo trước ít nhất ba mươi ngày.

Câu 68 Secure networking (20-25%)

Which of the following Azure services provides both a global acceleration Content Delivery Network (CDN) and Web Application Firewall (WAF) capabilities?

  1. A

    Azure Front Door
  2. B

    Azure Application Gateway
  3. C

    Azure DDoS Protection Standard
  4. D

    Azure Traffic Manager
Xem giải thích

Đáp án

A — Azure Front Door.

Vì sao đúng

⚠ Front Door gộp ba vai trò trong một dịch vụ: | Vai trò | Nội dung | |---|---| | ⚠ CDN — tăng tốc toàn cầu | ⚠ cache nội dung tĩnh ở biên | | ⚠ WAF | ⚠ chặn tấn công web ngay tại biên | | ⚠ Cân bằng tải toàn cầu | ⚠ định tuyến tới backend gần và khoẻ nhất |

⚠ Chạy ở tầng 7 và ở BIÊN mạng toàn cầu của Microsoft — hơn 190 điểm hiện diện.

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

  • B (Application Gateway) — ⚠ có WAF nhưng KHÔNG có CDN, và chỉ phục vụ trong MỘT vùng.

  • D (Traffic Manager) — ⚠ định tuyến bằng DNS, không có cache, không có WAF, lưu lượng không đi qua nó.

  • C (DDoS Protection Standard) — ⚠ chống tấn công lưu lượng, không phải CDN cũng không phải WAF.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23256 ở lô trước hỏi mô tả nào đúng về Front Door, còn #23809 liệt kê dịch vụ cho DDoS, TLS termination và định tuyến URL. ⚠ Ba câu nhất quán về vai trò của Front Door.

⚠ 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 | CDN | WAF | |---|---|---|---|---| | ⚠ Load Balancer | ⚠ vùng | ⚠ 4 | ⚠ không | ⚠ không | | ⚠ Application Gateway | ⚠ vùng | ⚠ 7 | ⚠ không | ⚠ CÓ | | ⚠ Traffic Manager | ⚠ toàn cầu | ⚠ DNS | ⚠ không | ⚠ không | | ⚠ Front Door | ⚠ toàn cầu | ⚠ 7 | ⚠ CÓ | ⚠ CÓ |

Từ khoá nhận diện:

"CDN và WAF trong một" → ⚠ Front Door "WAF trong một vùng" → ⚠ Application Gateway "định tuyến toàn cầu bằng DNS" → ⚠ Traffic Manager "chống lưu lượng tấn công lớn" → ⚠ DDoS Protection

⚠ Vì sao đặt WAF ở biên có lợi Lý do
⚠ Chặ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 ở quy mô toàn cầu
⚠ Kết hợp sẵn với DDoS Protection của nền tảng
⚠ Hai bậc của Front Door Bậc
⚠ Standard ⚠ CDN, cân bằng tải, WAF cơ bản
⚠ Premium ⚠ thêm managed rule set nâng cao, bot protection, Private Link tới origin
⚠ Private Link tới origin ⚠ backend không cần phơi ra Internet chút nào

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 | ⚠ quyết định Front Door có đáng không | | Backend có bị truy cập trực tiếp, bỏ qua Front Door không | ⚠ chặn bằng service tag hoặc Private Link | | WAF đang ở chế độ Detection hay Prevention | |

Và lỗ hổng hay bị bỏ sót khi dựng Front Door: backend vẫn nhận được lưu lượng trực tiếp. Kẻ tấn công tìm ra địa chỉ gốc là đi vòng qua toàn bộ WAF và cache — nên phải chặn để backend chỉ chấp nhận lưu lượng đến từ Front Door.

Câu 69 Secure compute, storage, and databases (20-25%)

What is/are the factual assertions when setting up an Azure file share for a corporate team?

  1. A

    Automatic encryption by default
  2. B

    Azure Files cannot authenticate to on-premises Active Directory Domain Services.
  3. C

    Azure Files can use RBAC for share-level or directory/file permissions.
  4. D

    All file shares must be in the same region
Xem giải thích

Đáp án

C — Azure Files dùng được RBAC cho quyền ở mức share hoặc mức thư mục và tệp

Vì sao đúng

Azure Files có hai tầng phân quyền hoạt động cùng nhau, và đây là điều đáng nhớ nhất:

  • Mức share — dùng vai Azure RBAC (Storage File Data SMB Share Reader, Contributor, Elevated Contributor) để quyết định ai gắn được share.
  • Mức thư mục và tệp — dùng danh sách kiểm soát truy cập NTFS quen thuộc, nên quyền chi tiết giữ nguyên như trên máy chủ tệp Windows.

Nhờ hai tầng này, chuyển file server tại chỗ lên Azure Files mà không phải thiết kế lại mô hình quyền.

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

  • B. Azure Files không xác thực được với Active Directory tại chỗ — sai: nó hỗ trợ đúng điều đó, và đây là tính năng quan trọng nhất cho môi trường lai.
  • D. Mọi file share phải nằm cùng một khu vực — không có ràng buộc nào như vậy.
  • A. Tự động mã hoá theo mặc định — điều này đúng, nhưng nó là đặc điểm chung của Azure Storage chứ không phải khẳng định riêng về việc thiết lập file share.
Câu 70 Chọn nhiều đáp án Secure compute, storage, and databases (20-25%)

While configuring security for your Azure Kubernetes Service (AKS), which of the following measures would you undertake to ensure network isolation and security monitoring for the containers? (Select two)

  1. A Use Azure Network Policies
  2. B Enable Azure Monitor and Azure Security Center integration
  3. C Configure Azure Disk Encryption for AKS nodes
  4. D Configure API Management for AKS
Xem giải thích

Đáp án

A và B — Dùng Azure Network Policies, và bật tích hợp Azure Monitor cùng Defender for Cloud.

Vì sao đúng

⚠ Hai yêu cầu của đề, hai giải pháp: | Yêu cầu | Giải pháp | |---|---| | ⚠ Cách ly MẠNG cho container | ⚠ Network Policy — kiểm soát pod nào nói chuyện được với pod nào | | ⚠ GIÁM SÁT bảo mật | ⚠ Azure Monitor cho chỉ số và nhật ký, Defender for Cloud cho mối đe doạ |

⚠ Network Policy làm gì: | Khả năng | Nội dung | |---|---| | ⚠ Mặc định Kubernetes: MỌI pod nói chuyện được với MỌI pod | ⚠ rất mở | | ⚠ Network policy giới hạn theo nhãn, namespace, cổng | | | ⚠ Hai lựa chọn triển khai | ⚠ Azure Network Policy Manager, hoặc Calico | | ⚠ Phải bật LÚC TẠO cụm | ⚠ với một số cấu hình |

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

  • C (Azure Disk Encryption cho node AKS) — ⚠ mã hoá đĩa, không liên quan tới cách ly mạng hay giám sát; ⚠ hơn nữa đĩa node đã được mã hoá sẵn bằng Azure Storage encryption.

  • D (API Management cho AKS) — ⚠ cổng quản lý API, hữu ích cho việc phơi API nhưng không phải cách ly mạng nội bộ cụm.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23811 ở lô trước hỏi cấu hình bảo mật và giám sát cho AKS (đáp án: Defender, Monitor, Azure Policy). ⚠ Câu này nhấn vào CÁCH LY MẠNG nên chọn Network Policy. Hai câu bổ sung nhau, giữ nguyên cả hai khoá.

⚠ Vì sao network policy quan trọng với container: | Vấn đề | Nội dung | |---|---| | ⚠ Mặc định Kubernetes là mạng phẳng | ⚠ mọi pod tới được mọi pod | | ⚠ Một container bị chiếm là tới được cả cụm | | | ⚠ Network policy chặn lan ngang | ⚠ giống vai trò của NSG với máy ảo | | ⚠ Nguyên tắc | ⚠ deny mặc định, rồi mở đúng luồng cần |

Từ khoá nhận diện:

"pod nào nói chuyện với pod nào" → ⚠ Network Policy "phát hiện đe doạ trong cụm" → ⚠ Defender for Containers "chỉ số và nhật ký cụm" → ⚠ Container Insights "buộc pod tuân chuẩn" → ⚠ Azure Policy for AKS

⚠ Hai lựa chọn network policy trên AKS Lựa chọn
⚠ Azure Network Policy Manager ⚠ của Microsoft, tích hợp sẵn
⚠ Calico ⚠ mã nguồn mở, nhiều tính năng hơn — global policy, network sets
⚠ Mới hơn ⚠ Cilium qua Azure CNI powered by Cilium
⚠ Danh sách bảo mật AKS Mục
⚠ Private cluster
⚠ Entra ID kèm Azure RBAC, TẮT tài khoản cục bộ
⚠ Network policy
⚠ Workload Identity
⚠ Bí mật trong Key Vault qua CSI Driver
⚠ Quét lỗ hổng ảnh
⚠ Cập nhật node định kỳ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Network policy đã bật cho cụm chưa | ⚠ một số cấu hình phải bật lúc tạo cụm | | Có policy mặc định deny chưa | | | Container Insights có đang thu thập dữ liệu không | |

Và điều cần biết trước khi dựng cụm AKS: network policy phải quyết định ngay từ lúc tạo. Bật sau thường không được, mà tạo lại cụm sản xuất là một việc lớn — nên đây là quyết định phải cân nhắc từ đầu.