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

Tìm thấy 99 câu.

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

If the initial network interface assigned to an Application Security Group (ASG) named GetCloudSkillsWeb is located in the virtual network named VNet1, then all successive network interfaces associated with GetCloudSkillsWeb must also be present in VNet1. Is this statement accurate?

  1. A

    Yes
  2. B

    No
Xem giải thích

Đáp án

A — Có, phát biểu này chính xác.

Vì sao đúng

⚠ Application Security Group bị ràng buộc vào MỘT mạng ảo: | Quy tắc | Nội dung | |---|---| | ⚠ Card mạng đầu tiên gán vào ASG quyết định VNet của ASG đó | | | ⚠ Mọi card mạng gán sau PHẢI ở cùng VNet đó | | | ⚠ Không thể trộn card mạng từ nhiều VNet trong một ASG | | | ⚠ Muốn dùng ở VNet khác | ⚠ phải tạo ASG khác |

⚠ ASG "GetCloudSkillsWeb"
   ├── ⚠ NIC 1 ở VNet1  →  ⚠ ASG gắn với VNet1
   ├── ⚠ NIC 2 ở VNet1  →  ⚠ OK
   └── ⚠ NIC 3 ở VNet2  →  ⚠ TỪ CHỐI

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

  • B (Không) — ⚠ ràng buộc này là có thật và Azure áp dụng chặt chẽ.

Ghi nhớ

⚠ ASG giải quyết bài toán gì: | Không có ASG | Có ASG | |---|---| | ⚠ Luật NSG viết theo dải IP | ⚠ luật viết theo TÊN NHÓM VAI TRÒ | | ⚠ Thêm máy phải sửa luật | ⚠ thêm máy vào nhóm là tự áp luật | | ⚠ Luật khó đọc, dễ sai | ⚠ luật đọc được như tiếng người |

⚠ Ví dụ luật NSG dùng ASG:

⚠ Cho phép: nguồn = ASG-Web  →  đích = ASG-App    cổng 8080
⚠ Cho phép: nguồn = ASG-App  →  đích = ASG-Db     cổng 1433
⚠ Chặn:     nguồn = ASG-Web  →  đích = ASG-Db
   ⚠ Không có một địa chỉ IP nào trong luật

Từ khoá nhận diện:

"nhóm card mạng theo vai trò" → ⚠ Application Security Group "nhóm dải IP của dịch vụ Azure" → ⚠ Service Tag "lọc gói theo luật" → ⚠ NSG "chặn lan ngang giữa các tầng" → ⚠ ASG kèm NSG là cách gọn nhất

⚠ Giới hạn khác của ASG Giới hạn
⚠ Chỉ dùng được trong cùng VNet ⚠ kể cả khi hai VNet đã peering
⚠ NSG dùng ASG phải cùng VNet với ASG đó
⚠ Một card mạng thuộc nhiều ASG được
⚠ Với kiến trúc nhiều VNet ⚠ phải dùng service tag hoặc dải IP, hoặc tạo ASG song song
⚠ Vì sao nên dùng ASG ngay từ đầu Lý do
⚠ Luật không vỡ khi hạ tầng thay đổi
⚠ Người mới đọc luật hiểu ngay ý đồ
⚠ Giảm sai sót khi mở rộng
⚠ Chuyển đổi sau ⚠ phải viết lại toàn bộ luật, tốn công hơn nhiều

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 thêm vào có tự được áp luật không | | | ASG và NSG có cùng VNet không | |

Và lợi ích lớn nhất của ASG không nằm ở kỹ thuật mà ở khả năng đọc hiểu: một bộ luật viết bằng tên vai trò tự giải thích ý đồ bảo mật của nó, còn một bộ luật viết bằng dải IP thì chỉ người viết ra nó mới hiểu.

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

If you have decided to safeguard your Azure Virtual Network resources with Azure Firewall, you may encounter various issues related to it. One such issue is the masking of threat intelligence alerts. To mitigate this problem, you need to consider all the possible solutions. Please select all the options that can help you solve the issue.

  1. A

    When specifying a port, use "HTTPS" as the value for the "protocol" field.
  2. B

    Set up outbound filtering for ports 80 and 443 by using application rules.
  3. C

    Switch the threat intelligence mode to "Alert and Deny."
  4. D

    Utilize authenticated SMTP relay services.
  5. E

    Utilize IPv4 addresses exclusively.
Xem giải thích

Đáp án

B và C.

  • B — Thiết lập lọc chiều ra cho cổng 80 và 443 bằng application rules.
  • C — Chuyển chế độ threat intelligence sang "Alert and Deny".

Vì sao đúng

⚠ Vì sao cảnh báo threat intelligence bị che lấp: | Nguyên nhân | Cách chữa | |---|---| | ⚠ Lưu lượng web bị bắt bởi NETWORK RULE trước | ⚠ network rule xét TRƯỚC application rule | | ⚠ Network rule khớp thì DỪNG, không xét tiếp | ⚠ nên application rule không bao giờ chạy tới | | ⚠ Threat intelligence chỉ ở chế độ Alert | ⚠ ghi nhật ký nhưng không chặn, dễ bị bỏ qua |

⚠ Thứ tự xét luật của Azure Firewall
   ⚠ 1. DNAT rules
   ⚠ 2. Network rules      ←  ⚠ khớp ở đây là DỪNG
   ⚠ 3. Application rules  ←  ⚠ không bao giờ tới

⚠ Giải pháp: ⚠ đưa lưu lượng cổng 80 và 443 vào application rules thay vì network rules, ⚠ và bật Alert and Deny để threat intelligence thực sự chặn.

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

  • A (dùng "HTTPS" làm giá trị cho trường protocol khi khai cổng) — ⚠ không giải quyết vấn đề thứ tự xét luật.

  • D (dùng dịch vụ SMTP relay đã xác thực) — ⚠ liên quan tới gửi thư, không liên quan.

  • E (chỉ dùng địa chỉ IPv4) — ⚠ không ảnh hưởng tới việc cảnh báo bị che.

Ghi nhớ

⚠ Ba loại luật của Azure Firewall — thứ tự rất quan trọng: | Loại | Xét thứ | Dùng cho | |---|---|---| | ⚠ DNAT rules | ⚠ 1 | ⚠ chuyển lưu lượng từ ngoài vào | | ⚠ Network rules | ⚠ 2 | ⚠ IP, cổng, giao thức — KHÔNG biết tên miền | | ⚠ Application rules | ⚠ 3 | ⚠ FQDN, web categories |

⚠ Quy tắc nhớ: ⚠ lưu lượng web (80, 443) nên xử lý bằng APPLICATION RULE, để tận dụng lọc theo tên miền và threat intelligence.

⚠ Hai chế độ threat intelligence: | Chế độ | Hành vi | |---|---| | ⚠ Alert only | ⚠ chỉ ghi nhật ký, KHÔNG chặn | | ⚠ Alert and deny | ⚠ ghi nhật ký VÀ chặn | | ⚠ Off | ⚠ tắt hẳn | | ⚠ Triển khai an toàn | ⚠ chạy Alert trước để tìm cảnh báo giả, rồi chuyển Deny |

Từ khoá nhận diện:

"lọc theo tên miền" → ⚠ application rule "lọc theo IP và cổng" → ⚠ network rule "cảnh báo có mà không chặn" → ⚠ đang ở chế độ Alert only "luật không có tác dụng" → ⚠ kiểm tra thứ tự xét luật trước tiên

⚠ Bẫy thứ tự luật — ví dụ cụ thể Ví dụ
⚠ Network rule: cho phép mọi thứ ra cổng 443
⚠ Application rule: chỉ cho phép *.microsoft.com
⚠ Kết quả THỰC TẾ ⚠ mọi tên miền đều ra được, vì network rule khớp trước
⚠ Người viết luật tưởng ⚠ đã chặn được các trang khác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có network rule nào cho phép 80 hoặc 443 rộng rãi không | ⚠ nó vô hiệu hoá mọi application rule | | Threat intelligence đang ở chế độ nào | | | Nhật ký firewall có ai đọc không | |

Và loại lỗi cấu hình nguy hiểm nhất trong tường lửa: luật trông có vẻ chặn nhưng thực ra không bao giờ được xét tới. Nó không báo lỗi, không cảnh báo — chỉ lặng lẽ cho qua mọi thứ mà bạn tưởng đã chặn.

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

To create a security policy, you must identify the resource group containing the Front Door profile. You can use the Get-AzResourceGroup cmdlet for this purpose. Once you have identified the resource group, you must use a specific cmdlet to configure the security policy. Which of the following cmdlets would you use for this task?

  1. A

    New-AzFrontDoorWafPolicy
  2. B

    Set-AzFrontDoorWafPolicy
  3. C

    New-AzFrontDoorPolicy
  4. D

    New-AzureFrontDoorWafPolicy
Xem giải thích

Đáp án

A — New-AzFrontDoorWafPolicy.

Vì sao đúng

⚠ Ba chi tiết trong tên cmdlet đều phải đúng: | Chi tiết | Đúng | Sai | |---|---|---| | ⚠ Động từ | ⚠ New- để TẠO MỚI | ⚠ Set- là để SỬA cái đã có | | ⚠ Tiền tố | ⚠ Az | ⚠ AzureFrontDoor là mô-đun AzureRM CŨ | | ⚠ Danh từ | ⚠ FrontDoorWafPolicy | ⚠ FrontDoorPolicy thiếu chữ Waf |

⚠ $rg = Get-AzResourceGroup -Name "RG-Web"
⚠ New-AzFrontDoorWafPolicy -ResourceGroupName $rg.ResourceGroupName ...

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

  • B (Set-AzFrontDoorWafPolicy) — ⚠ có tồn tại nhưng để SỬA chính sách đã có, không tạo mới.

  • C (New-AzFrontDoorPolicy) — ⚠ thiếu chữ Waf, không phải tên cmdlet thật.

  • D (New-AzureFrontDoorWafPolicy) — ⚠ dùng tiền tố Azure của mô-đun AzureRM đã ngừng từ 2/2024.

Ghi nhớ

⚠ Đây là câu thứ tư trong lô kiểm tra quy ước PowerShell — cùng với #23198, #23203 và #23207.

Câu Quy ước
⚠ #23198 ⚠ -ResourceGroupName
⚠ #23203 ⚠ Remove- chứ không phải Delete-
⚠ #23207 ⚠ Get- và -ListAvailable
⚠ #23211 (câu này) ⚠ New- để tạo, tiền tố Az chứ không phải Azure
⚠ Bài học chung ⚠ nhớ quy ước, không cần thuộc từng lệnh

⚠ WAF của Front Door: | Thành phần | Nội dung | |---|---| | ⚠ Managed rule set | ⚠ bộ luật do Microsoft duy trì, dựa trên OWASP | | ⚠ Custom rule | ⚠ luật riêng — theo IP, quốc gia, giới hạn tần suất | | ⚠ Chế độ Detection | ⚠ chỉ ghi nhật ký | | ⚠ Chế độ Prevention | ⚠ chặn thật | | ⚠ Exclusion | ⚠ loại trừ tham số gây cảnh báo giả |

Từ khoá nhận diện:

"tạo mới" → ⚠ New- "sửa cái đã có" → ⚠ Set- "tiền tố Az" → ⚠ mô-đun hiện hành "tiền tố Azure" → ⚠ AzureRM, đã ngừng

⚠ WAF đặt ở đâu Nơi
⚠ Front Door ⚠ toàn cầu, chặn ngay tại biên — gần kẻ tấn công nhất
⚠ Application Gateway ⚠ trong một vùng
⚠ Đặt ở biên ⚠ lưu lượng độc hại không tiêu tài nguyên vùng của bạn
⚠ Cách triển khai WAF an toàn Bước
⚠ Bật chế độ Detection trước
⚠ Xem nhật ký, tìm cảnh báo giả
⚠ Thêm exclusion cho các trường hợp hợp lệ
⚠ Rồi mới chuyển sang Prevention
⚠ Bật Prevention ngay ⚠ rất dễ chặn nhầm người dùng thật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | WAF đang ở chế độ nào | ⚠ Detection mãi thì không bảo vệ gì | | Có luật nào bị tắt vì cảnh báo giả không | ⚠ xem lại định kỳ | | Có giới hạn tần suất cho endpoint đăng nhập chưa | |

Và bẫy quen thuộc khi triển khai WAF: bật Detection để "quan sát" rồi quên chuyển sang Prevention. Nhật ký đầy cảnh báo, báo cáo trông đẹp, mà không có gì thật sự bị chặn.

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

"Wheeler Car Dealership" is a company based in Sydney, Australia, that specializes in buying and selling automobiles. They have hired you as an experienced consultant to lead a team session where you will explain the Azure Firewall concept. During the session, you'll need to describe Azure Firewall clearly. Please select two statements from the following that you can use to describe Azure Firewall.

  1. A

    Azure Firewall is a fully stateful service with built-in high availability and unrestricted cloud scalability.
  2. B

    Azure Firewall utilizes the Core Rule Set (CRS) the Open Web Application Security Project (OWASP) developed.
  3. C

    Azure Firewall can identify and block traffic from or to known malicious IP addresses and domains. Additionally, it can generate alerts to notify you of such activities.
  4. D

    Azure Firewall is a security feature that safeguards against SQL injection and cross-site scripting attacks, two common web application security vulnerabilities.
Xem giải thích

Đáp án

A và C.

  • A — Azure Firewall là dịch vụ có trạng thái đầy đủ, sẵn sàng cao dựng sẵn và co giãn không giới hạn theo kiểu đám mây.
  • C — Azure Firewall nhận diện và chặn được lưu lượng tới hoặc từ các IP và tên miền độc hại đã biết, đồng thời sinh cảnh báo.

Vì sao đúng

⚠ Phát biểu A — ba đặc tính nền tảng: | Đặc tính | Nội dung | |---|---| | ⚠ Stateful | ⚠ theo dõi trạng thái kết nối; gói trả về tự được cho qua | | ⚠ Sẵn sàng cao dựng sẵn | ⚠ không phải tự dựng cụm | | ⚠ Co giãn không giới hạn | ⚠ tự mở rộng theo lưu lượng |

⚠ Phát biểu C — threat intelligence: | Chức năng | Nội dung | |---|---| | ⚠ Nguồn dữ liệu Microsoft Threat Intelligence | ⚠ cập nhật liên tục | | ⚠ Chế độ Alert only | ⚠ chỉ cảnh báo | | ⚠ Chế độ Alert and deny | ⚠ cảnh báo và chặn |

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

  • B (dùng Core Rule Set của OWASP) — ⚠ đó là WAF, không phải Azure Firewall.

  • D (bảo vệ khỏi SQL injection và cross-site scripting) — ⚠ cũng là WAF; Azure Firewall làm việc ở tầng mạng và tầng ứng dụng theo FQDN, không phân tích nội dung yêu cầu web.

Ghi nhớ

⚠ Đối chiếu: ⚠ lô này có ba câu về Azure Firewall — #23204 (chính sách tập trung), #23210 (thứ tự luật và threat intelligence), và câu này (mô tả tổng quát). ⚠ Ba câu nhất quán với nhau.

⚠ Phân biệt bốn công cụ bảo mật mạng — bảng cần thuộc: | Công cụ | Bảo vệ khỏi | Tầng | |---|---|---| | ⚠ NSG | ⚠ lưu lượng không mong muốn theo IP và cổng | ⚠ 3–4 | | ⚠ Azure Firewall | ⚠ lưu lượng độc hại theo IP, cổng, FQDN | ⚠ 3–7 | | ⚠ WAF | ⚠ SQL injection, XSS, OWASP Top 10 | ⚠ 7 | | ⚠ DDoS Protection | ⚠ tấn công lưu lượng khổng lồ | ⚠ 3–4 |

Từ khoá nhận diện:

"stateful, threat intelligence, lọc FQDN" → ⚠ Azure Firewall "OWASP Core Rule Set, SQL injection, XSS" → ⚠ WAF "miễn phí, mức subnet" → ⚠ NSG "chống lưu lượng tấn công khổng lồ" → ⚠ DDoS Protection

⚠ Stateful nghĩa là gì Nghĩa
⚠ Tường lửa NHỚ các kết nối đang mở
⚠ Cho phép gói đi ra thì gói trả về tự được cho qua
⚠ Không phải viết luật cho chiều ngược lại
⚠ Tường lửa stateless ⚠ phải khai luật cho CẢ HAI chiều, dễ sai
⚠ Bốn công cụ bổ sung cho nhau thế nào Cách
⚠ DDoS Protection ⚠ hấp thụ lưu lượng tấn công ở vành đai
⚠ Azure Firewall ⚠ kiểm soát tập trung ở biên VNet
⚠ NSG ⚠ phân đoạn bên trong, tới từng subnet
⚠ WAF ⚠ bảo vệ chính ứng dụng web
⚠ Không cái nào ⚠ thay thế được cái nào

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng web có WAF chưa | ⚠ Azure Firewall KHÔNG thay được | | Lưu lượng có thật sự đi qua firewall không | ⚠ kiểm tra định tuyến | | Threat intelligence đang ở chế độ nào | |

Và hiểu nhầm tốn kém nhất về Azure Firewall: tưởng rằng có nó là không cần WAF nữa. Hai công cụ nhìn vào hai thứ hoàn toàn khác nhau — một cái nhìn kết nối và tên miền, một cái nhìn vào nội dung của từng yêu cầu HTTP.

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

One of your friends is a system administrator at a large enterprise. The administrative staff has asked him to block all data traffic to websites from their network, except for specific domains such as www.getcloudskills.com and www.udemy.com. He has discussed this scenario with me and wants to know if he should use Network Security Groups (NSGs). Should he use them or not?

  1. A

    Yes
  2. B

    No
Xem giải thích

Đáp án

B — Không, không nên dùng NSG cho việc này.

Vì sao đúng

⚠ NSG hoạt động ở tầng 3 và 4 — nó KHÔNG hiểu tên miền: | NSG lọc theo | NSG KHÔNG lọc theo | |---|---| | ⚠ Địa chỉ IP nguồn và đích | ⚠ tên miền (FQDN) | | ⚠ Cổng | ⚠ đường dẫn URL | | ⚠ Giao thức TCP/UDP | ⚠ nội dung yêu cầu | | ⚠ Service tag | ⚠ danh mục website |

⚠ Vì sao không thể dùng IP thay thế: | Lý do | Nội dung | |---|---| | ⚠ Một tên miền có thể có NHIỀU IP | | | ⚠ IP thay đổi liên tục | ⚠ CDN, cân bằng tải toàn cầu | | ⚠ Nhiều tên miền dùng CHUNG một IP | ⚠ cho phép một IP là mở luôn cả trăm trang khác |

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

  • A (Có) — ⚠ NSG không có khả năng này; công cụ đúng là Azure Firewall với application rule theo FQDN.

Ghi nhớ

⚠ Công cụ đúng cho yêu cầu này: | Công cụ | Khả năng | |---|---| | ⚠ Azure Firewall — application rules | ⚠ cho phép hoặc chặn theo FQDN, kể cả ký tự đại diện *.udemy.com | | ⚠ Azure Firewall Premium | ⚠ thêm lọc URL và phân loại web | | ⚠ NVA của bên thứ ba | ⚠ nếu cần tính năng đặc thù |

Từ khoá nhận diện:

"chặn theo tên miền" → ⚠ Azure Firewall, KHÔNG phải NSG "chặn theo IP và cổng" → ⚠ NSG là đủ "chặn SQL injection" → ⚠ WAF "chỉ cho phép một danh sách trang web" → ⚠ application rule với FQDN

⚠ Ranh giới năng lực của từng công cụ Ranh giới
⚠ NSG ⚠ tầng 3–4, miễn phí, mức subnet và card mạng
⚠ Azure Firewall ⚠ tầng 3–7, tính phí, mức mạng ảo
⚠ WAF ⚠ tầng 7, phân tích nội dung HTTP
⚠ Chọn sai công cụ ⚠ là dựng xong mới phát hiện nó không làm được việc cần làm
⚠ Vì sao lọc theo FQDN lại khó Lý do
⚠ Firewall phải theo dõi phân giải DNS
⚠ Phải hiểu SNI trong bắt tay TLS ⚠ để biết máy khách đang gọi tên miền nào
⚠ Đây là công việc ở tầng cao hơn hẳn tầng 4
⚠ Vì thế ⚠ NSG về mặt kiến trúc không thể làm được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Yêu cầu là lọc theo IP hay theo tên miền | ⚠ quyết định chọn công cụ nào | | Nếu cần FQDN thì đã có Azure Firewall chưa | | | Lưu lượng ra Internet có đi qua firewall không | ⚠ cần user-defined route |

Và bài học rút ra khi chọn công cụ mạng trên Azure: hỏi công cụ đó nhìn thấy gì trong gói tin. NSG chỉ thấy IP và cổng, nên mọi yêu cầu nhắc tới tên miền đều nằm ngoài khả năng của nó.

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

An Azure company has hired you as an expert consultant for their Azure projects. The company wants to deploy databases and web servers to Azure and has asked for your recommendation on limiting the types of connections that can be made from the web servers to the databases. What Azure solution would you suggest?

  1. A

    Azure DDOS protection
  2. B

    Network Security Groups (NSGs)
  3. C

    Azure Front Door
  4. D

    A local network gateway
  5. E

    None of these
Xem giải thích

Đáp án

B — Network Security Groups (NSG).

Vì sao đúng

⚠ Đây đúng là việc NSG sinh ra để làm: | Yêu cầu | NSG đáp ứng | |---|---| | ⚠ Giới hạn LOẠI kết nối từ web server tới CSDL | ⚠ luật theo cổng và giao thức | | ⚠ Chỉ cho phép cổng 1433 chẳng hạn | ⚠ chặn mọi cổng khác | | ⚠ Chỉ cho phép từ subnet web | ⚠ theo nguồn | | ⚠ Miễn phí | |

⚠ Subnet Web  →  ⚠ cổng 1433  →  ⚠ Subnet Database   ⚠ CHO PHÉP
⚠ Subnet Web  →  ⚠ mọi cổng khác  →  ⚠ Subnet Database  ⚠ CHẶN
⚠ Internet    →  ⚠ Subnet Database                     ⚠ CHẶN

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

  • A (DDoS Protection) — ⚠ chống tấn công lưu lượng lớn, không lọc theo luật.

  • C (Front Door) — ⚠ định tuyến HTTP toàn cầu, không kiểm soát kết nối nội bộ.

  • D (local network gateway) — ⚠ đại diện cho mạng tại chỗ trong cấu hình VPN, không lọc gì.

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

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23213 trong lô này hỏi có nên dùng NSG để chặn theo TÊN MIỀN không (đáp án KHÔNG). ⚠ Câu này hỏi có nên dùng NSG để giới hạn kết nối theo CỔNG không (đáp án CÓ).

Câu Yêu cầu NSG dùng được
⚠ #23213 ⚠ chặn web theo tên miền ⚠ KHÔNG — cần Azure Firewall
⚠ #23214 (câu này) ⚠ giới hạn kết nối theo cổng và nguồn ⚠ CÓ
⚠ Hai câu ⚠ vẽ đúng ranh giới năng lực của NSG
⚠ Không mâu thuẫn ⚠ giữ nguyên cả hai khoá

⚠ Kiến trúc ba tầng chuẩn với NSG: | Subnet | Luật vào | |---|---| | ⚠ Web | ⚠ nhận 443 từ Internet hoặc từ Application Gateway | | ⚠ App | ⚠ chỉ nhận từ subnet Web, đúng cổng ứng dụng | | ⚠ Database | ⚠ CHỈ nhận từ subnet App, đúng cổng CSDL | | ⚠ Nguyên tắc | ⚠ mỗi tầng chỉ nói chuyện với tầng liền kề |

Từ khoá nhận diện:

"giới hạn cổng và nguồn" → ⚠ NSG "chặn theo tên miền" → ⚠ Azure Firewall "CSDL PaaS không cần IP công cộng" → ⚠ Private Endpoint "nhóm máy theo vai trò để viết luật gọn" → ⚠ Application Security Group

⚠ Với CSDL PaaS thì nên làm gì Việc
⚠ Dùng Private Endpoint ⚠ CSDL có IP riêng trong VNet
⚠ Tắt truy cập công cộng của CSDL
⚠ NSG kiểm soát ai tới được endpoint đó
⚠ Kết hợp cả ba ⚠ CSDL không còn cửa nào ra Internet

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Subnet CSDL có nhận được lưu lượng từ Internet không | ⚠ kiểm tra bằng IP flow verify | | Luật có chỉ mở đúng cổng cần không | | | Có dùng ASG để luật dễ đọc chưa | |

Và nguyên tắc thiết kế nên áp cho mọi tầng dữ liệu: CSDL chỉ nên nhận kết nối từ tầng ứng dụng, đúng một cổng, và không bao giờ từ Internet. Đây là luật NSG đơn giản nhất mà cũng có giá trị nhất trong toàn bộ kiến trúc.

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

Azure Traffic Manager provides six routing methods to meet diverse requirements and specifications. Which routing methods are suitable to ensure compliance with data sovereignty regulations?

  1. A

    Priority
  2. B

    Performance
  3. C

    Geographic
  4. D

    Multivalue
  5. E

    Clustered
Xem giải thích

Đáp án

C — Geographic (địa lý).

Vì sao đúng

⚠ Geographic routing gửi người dùng tới endpoint theo VỊ TRÍ ĐỊA LÝ mà DNS truy vấn đến từ đó: | Đặc điểm | Nội dung | |---|---| | ⚠ Ánh xạ vùng địa lý tới endpoint cụ thể | ⚠ theo quốc gia, khu vực, châu lục | | ⚠ Bảo đảm dữ liệu được xử lý ở đúng nơi cho phép | | | ⚠ Mỗi vùng địa lý chỉ gán cho MỘT endpoint trong một profile | | | ⚠ Nên có endpoint cho "World" | ⚠ bắt các vùng chưa gán |

⚠ Đây chính là công cụ để đáp ứng yêu cầu chủ quyền dữ liệu: ⚠ người dùng ở EU luôn tới endpoint EU, người dùng ở Úc luôn tới endpoint Úc.

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

  • B (Performance) — ⚠ chọn endpoint có độ TRỄ thấp nhất, có thể ở nước khác — vi phạm yêu cầu chủ quyền dữ liệu.

  • A (Priority) — ⚠ chính và dự phòng, không quan tâm vị trí.

  • D (Multivalue) — ⚠ trả về nhiều địa chỉ để client tự thử.

  • E (Clustered) — ⚠ không tồn tại.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #23201 trong lô này hỏi về trọng số tối đa của Weighted routing; câu #23218 hỏi về Priority. ⚠ Ba câu cùng kiểm tra sáu phương pháp định tuyến của Traffic Manager.

⚠ Sáu phương pháp — nhớ theo MỤC ĐÍCH: | Phương pháp | Mục đích | |---|---| | ⚠ Priority | ⚠ dự phòng — chính hỏng thì sang cái sau | | ⚠ Weighted | ⚠ chia tải theo tỷ lệ, triển khai từ từ | | ⚠ Performance | ⚠ tốc độ — độ trễ thấp nhất | | ⚠ Geographic | ⚠ TUÂN THỦ — dữ liệu ở đúng nơi | | ⚠ MultiValue | ⚠ trả nhiều địa chỉ, client tự chọn | | ⚠ Subnet | ⚠ theo dải IP nguồn — nội bộ thấy bản khác |

Từ khoá nhận diện:

"chủ quyền dữ liệu, theo quốc gia" → ⚠ Geographic "nhanh nhất cho người dùng" → ⚠ Performance "chính và dự phòng" → ⚠ Priority "chia 90/10 để thử phiên bản mới" → ⚠ Weighted

⚠ Geographic và Performance — khác biệt then chốt Khác
⚠ Geographic ⚠ BẮT BUỘC theo vị trí, kể cả khi chậm hơn
⚠ Performance ⚠ chọn nhanh nhất, có thể vượt biên giới
⚠ Yêu cầu pháp lý ⚠ luôn phải dùng Geographic
⚠ Lưu ý ⚠ Geographic dựa trên nơi TRUY VẤN DNS đến, không phải nơi người dùng thật
⚠ Giới hạn cần biết của Geographic Giới hạn
⚠ Vùng chưa gán cho endpoint nào ⚠ người dùng ở đó KHÔNG truy cập được
⚠ Vì thế nên có endpoint "World"
⚠ Vị trí suy từ trình phân giải DNS ⚠ có thể lệch nếu người dùng dùng DNS công cộng
⚠ Muốn chắc chắn hơn ⚠ kiểm tra lại ở tầng ứng dụng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mọi vùng địa lý đã được gán endpoint chưa | ⚠ thiếu là người dùng ở đó bị chặn | | Yêu cầu pháp lý cụ thể là gì | ⚠ đọc điều luật, đừng đoán | | Có kiểm tra lại vị trí ở tầng ứng dụng không | |

Và giới hạn cần nhớ khi dựa vào Geographic routing để tuân thủ: nó suy vị trí từ trình phân giải DNS, không phải từ chính người dùng. Ai dùng DNS công cộng ở nước ngoài có thể bị định tuyến sai — nên đây là lớp phòng vệ đầu tiên, không phải lớp duy nhất.

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

Please read the following statements regarding Network Address Translation (NAT):

1. NAT allows you to share a single public IPv4 address among multiple internal resources.

2. NAT enables you to assign multiple private IPv4 addresses to a single virtual machine.

3. NAT allows you to configure an external IPv4 address on each virtual machine.

4. NAT cannot be used across multiple virtual networks.

Which of the above statements are true? Please select the correct answer.

  1. A

    Only 1 and 2
  2. B

    Only 1 and 3
  3. C

    Only 3 and 4
  4. D

    Only 1 and 4
Xem giải thích

Đáp án

D — Chỉ phát biểu 1 và 4 là đúng.

Vì sao đúng

⚠ Xét từng phát biểu: | Phát biểu | Đúng sai | |---|---| | ⚠ 1. NAT cho phép nhiều tài nguyên nội bộ dùng chung MỘT IPv4 công cộng | ⚠ ĐÚNG — đó chính là định nghĩa của NAT | | ⚠ 2. NAT cho phép gán nhiều IPv4 riêng cho một máy ảo | ⚠ SAI — đó là việc của cấu hình card mạng, không phải NAT | | ⚠ 3. NAT cho phép cấu hình một IPv4 ngoài trên MỖI máy ảo | ⚠ SAI — ngược hẳn mục đích của NAT | | ⚠ 4. NAT không dùng được xuyên nhiều mạng ảo | ⚠ ĐÚNG — NAT Gateway chỉ phục vụ subnet trong CÙNG một VNet |

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

  • A (chỉ 1 và 2), B (chỉ 1 và 3), C (chỉ 3 và 4) — ⚠ đều chứa ít nhất một phát biểu sai.

Ghi nhớ

⚠ Đối chiếu: ⚠ lô này có ba câu về NAT — #23200 (16 IP, một NAT gateway mỗi subnet), câu này, và #23219. ⚠ Ba câu nhất quán và bổ sung cho nhau.

⚠ Tổng hợp mọi giới hạn của NAT Gateway: | Giới hạn | Nội dung | |---|---| | ⚠ Tối đa 16 địa chỉ IP công cộng | ⚠ hoặc qua public IP prefix | | ⚠ Mỗi subnet gắn ĐÚNG MỘT NAT gateway | | | ⚠ Một NAT gateway phục vụ NHIỀU subnet | ⚠ nhưng phải cùng VNet | | ⚠ KHÔNG xuyên nhiều VNet | | | ⚠ CHỈ hỗ trợ IPv4 | ⚠ không hỗ trợ IPv6 | | ⚠ CHỈ chiều RA | ⚠ không cho Internet đi vào | | ⚠ Gắn với MỘT availability zone hoặc regional | |

Từ khoá nhận diện:

"nhiều máy dùng chung IP công cộng ra ngoài" → ⚠ NAT "cho Internet đi vào" → ⚠ Load Balancer, KHÔNG phải NAT "IPv6" → ⚠ NAT Gateway KHÔNG hỗ trợ "nhiều VNet dùng chung một NAT gateway" → ⚠ KHÔNG được, mỗi VNet cần riêng

⚠ Vì sao NAT Gateway đáng dùng Lý do
⚠ Máy không cần IP công cộng ⚠ giảm bề mặt tấn công
⚠ Mỗi IP cho 64.512 cổng SNAT ⚠ hết cạn cổng
⚠ IP ra ngoài ổn định ⚠ đối tác đưa vào danh sách trắng được
⚠ Không cần cấu hình định tuyến ⚠ gắn vào subnet là xong
⚠ Thứ tự ưu tiên khi máy ra Internet Thứ tự
⚠ 1. NAT Gateway của subnet ⚠ luôn thắng nếu có
⚠ 2. IP công cộng gán trên máy
⚠ 3. SNAT của Load Balancer
⚠ Hệ quả ⚠ gắn NAT Gateway sẽ ĐỔI IP ra ngoài của toàn subnet

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có hệ thống nào lọc theo IP ra ngoài của bạn không | ⚠ báo trước khi gắn NAT Gateway | | Mỗi VNet đã có NAT Gateway riêng chưa | ⚠ không dùng chung được | | Có dùng IPv6 không | ⚠ NAT Gateway không hỗ trợ |

Và điều rút gọn dễ nhớ nhất về NAT Gateway: nhiều trong một, một chiều, một mạng ảo. Nhiều máy dùng chung ít IP, chỉ đi ra không đi vào, và không vượt được ranh giới VNet.

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

When configuring a load balancing rule, you want to make sure that requests from the same client IP address and protocol are always handled by the same virtual machine (VM). Which option should you choose for the Session persistence setting?

  1. A

    Client IP
  2. B

    Client IP and Protocol
  3. C

    HostName
  4. D

    HostAddress
  5. E

    None
Xem giải thích

Đáp án

B — Client IP and Protocol (địa chỉ IP máy khách và giao thức).

Vì sao đúng

⚠ Azure Load Balancer có ba mức session persistence: | Chế độ | Dựa trên | Tên kỹ thuật | |---|---|---| | ⚠ None | ⚠ IP nguồn, cổng nguồn, IP đích, cổng đích, giao thức | ⚠ five-tuple — mặc định | | ⚠ Client IP | ⚠ IP nguồn, IP đích | ⚠ two-tuple | | ⚠ Client IP and Protocol | ⚠ IP nguồn, IP đích, GIAO THỨC | ⚠ three-tuple |

⚠ Đề yêu cầu cùng IP máy khách VÀ cùng giao thức thì tới cùng một máy → ⚠ đúng định nghĩa của three-tuple.

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

  • A (Client IP) — ⚠ chỉ two-tuple, không xét giao thức như đề yêu cầu.

  • C (HostName) và D (HostAddress) — ⚠ không phải tuỳ chọn của Load Balancer.

  • E (None) — ⚠ mặc định, phân phối theo five-tuple, không ghim phiên chút nào.

Ghi nhớ

⚠ Vì sao mặc định là five-tuple: | Lý do | Nội dung | |---|---| | ⚠ Phân phối đều nhất | ⚠ mỗi kết nối mới có thể tới máy khác | | ⚠ Tận dụng hết công suất | | | ⚠ Nhược điểm | ⚠ ứng dụng giữ trạng thái trên máy sẽ hỏng |

⚠ Cái giá của session persistence: | Cái giá | Nội dung | |---|---| | ⚠ Phân phối KHÔNG còn đều | ⚠ một IP lớn có thể dồn tải vào một máy | | ⚠ Máy chết là mất phiên của mọi người ghim vào nó | | | ⚠ Người dùng sau NAT chung một IP đều tới cùng một máy | ⚠ cả văn phòng dồn vào một chỗ | | ⚠ Vì thế | ⚠ chỉ dùng khi ứng dụng thật sự cần |

Từ khoá nhận diện:

"cùng IP và giao thức tới cùng máy" → ⚠ Client IP and Protocol "cùng IP tới cùng máy" → ⚠ Client IP "phân phối đều nhất" → ⚠ None, five-tuple "ghim phiên bằng cookie" → ⚠ Application Gateway, tầng 7

⚠ Cách tốt hơn thay vì ghim phiên Cách
⚠ Lưu phiên ở nơi DÙNG CHUNG ⚠ Azure Cache for Redis, hoặc CSDL
⚠ Dùng token không trạng thái ⚠ JWT
⚠ Ứng dụng không giữ trạng thái trên máy
⚠ Khi đó ⚠ máy nào phục vụ cũng được, co giãn tự do
⚠ Ghim phiên ở tầng 4 và tầng 7 Khác
⚠ Load Balancer (tầng 4) ⚠ ghim theo IP — thô, dễ lệch tải
⚠ Application Gateway (tầng 7) ⚠ ghim bằng COOKIE — chính xác theo từng trình duyệt
⚠ Người dùng sau NAT chung ⚠ cookie phân biệt được, IP thì không

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng có thật sự cần ghim phiên không | ⚠ hay chỉ là do thiết kế cũ | | Phiên có lưu ở nơi dùng chung được không | | | Tải có bị lệch giữa các máy không | ⚠ dấu hiệu của ghim phiên theo IP |

Và cách nghĩ đúng về session persistence: nó là một cái nạng cho ứng dụng giữ trạng thái, không phải một tính năng đáng theo đuổi. Sửa được ứng dụng để không giữ trạng thái thì mọi vấn đề về ghim phiên biến mất.

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

You have multiple instances of Azure App Service that are located in various Azure Regions. All of these instances host the same web app. Your task is to configure Azure Traffic Manager in a way that ensures there is a primary service instance/endpoint for all traffic. Additionally, you must ensure that backup endpoints/instances are available in case the primary or backup instances become unavailable. Which routing method would you use to achieve this?

  1. A

    Weighted
  2. B

    Geographic
  3. C

    Priority
  4. D

    Subnet
Xem giải thích

Đáp án

C — Priority (ưu tiên).

Vì sao đúng

⚠ Priority routing đúng nghĩa "chính và dự phòng": | Cách hoạt động | Nội dung | |---|---| | ⚠ Mỗi endpoint có một số ưu tiên | ⚠ 1 tới 1000, số NHỎ ưu tiên CAO hơn | | ⚠ Toàn bộ lưu lượng tới endpoint ưu tiên cao nhất đang khoẻ | | | ⚠ Endpoint đó chết | ⚠ chuyển sang endpoint ưu tiên kế tiếp | | ⚠ Endpoint đó khoẻ lại | ⚠ lưu lượng tự quay về |

⚠ Endpoint A — ưu tiên 1  →  ⚠ nhận 100% lưu lượng
⚠ Endpoint B — ưu tiên 2  →  ⚠ chờ sẵn
⚠ Endpoint C — ưu tiên 3  →  ⚠ chờ sẵn
        ↓ ⚠ A chết
⚠ Toàn bộ lưu lượng sang B

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

  • A (Weighted) — ⚠ chia lưu lượng theo tỷ lệ cho TẤT CẢ endpoint cùng lúc, không có khái niệm chính và dự phòng.

  • B (Geographic) — ⚠ định tuyến theo vị trí địa lý.

  • D (Subnet) — ⚠ theo dải IP nguồn của người dùng.

Ghi nhớ

⚠ Đối chiếu: ⚠ lô này có ba câu về định tuyến Traffic Manager.

Câu Phương pháp Mục đích
⚠ #23201 ⚠ Weighted ⚠ chia tải theo tỷ lệ, trọng số tối đa 1000
⚠ #23215 ⚠ Geographic ⚠ tuân thủ chủ quyền dữ liệu
⚠ #23218 (câu này) ⚠ Priority ⚠ chính và dự phòng
⚠ Ba câu ⚠ nhất quán, cùng vẽ nên bộ sáu phương pháp

⚠ Điều cần lưu ý khi dùng Priority cho DR: | Điều | Nội dung | |---|---| | ⚠ Chuyển đổi phụ thuộc TTL của DNS | ⚠ không tức thời | | ⚠ TTL mặc định 60 giây | ⚠ giảm được nhưng tăng tải truy vấn | | ⚠ Client có thể cache lâu hơn TTL | ⚠ một số trình duyệt cứng đầu | | ⚠ Endpoint dự phòng phải LUÔN sẵn sàng | ⚠ và được kiểm thử định kỳ |

Từ khoá nhận diện:

"chính và dự phòng" → ⚠ Priority "chia theo tỷ lệ" → ⚠ Weighted "theo quốc gia" → ⚠ Geographic "gần nhất, nhanh nhất" → ⚠ Performance

⚠ Traffic Manager và Front Door cho kịch bản DR So sánh
⚠ Traffic Manager ⚠ DNS, chuyển đổi mất thời gian bằng TTL
⚠ Front Door ⚠ proxy ngược, chuyển đổi gần như tức thời
⚠ Traffic Manager ⚠ dùng được cho MỌI giao thức
⚠ Front Door ⚠ chỉ HTTP/HTTPS
⚠ Sai lầm phổ biến với endpoint dự phòng Sai lầm
⚠ Dựng xong rồi không bao giờ kiểm thử
⚠ Phiên bản ứng dụng ở đó lỗi thời
⚠ Cấu hình và bí mật không được đồng bộ
⚠ Đến lúc cần ⚠ chuyển sang thì phát hiện nó không chạy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Endpoint dự phòng lần cuối được kiểm thử khi nào | | | TTL đang đặt bao nhiêu giây | | | Health probe có phát hiện được lỗi thật của ứng dụng không | ⚠ hay chỉ kiểm tra máy còn sống |

Và điều quyết định một kế hoạch chuyển đổi dự phòng có dùng được hay không: đã từng chạy thử nó chưa. Cấu hình Priority trong Traffic Manager mất năm phút; kiểm chứng rằng endpoint dự phòng thật sự phục vụ được mới là phần việc thật.