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

Đáp án

B — Azure Advisor.

Vì sao đúng

⚠ Advisor quét tài nguyên thật của bạn rồi đưa khuyến nghị theo năm trụ cột: | Trụ cột | Ví dụ khuyến nghị | |---|---| | ⚠ Cost — chi phí | ⚠ VM dùng dưới công suất, nên mua reservation | | ⚠ Security — bảo mật | ⚠ cổng quản trị mở, thiếu MFA | | ⚠ Reliability — độ tin cậy | ⚠ chưa có Availability Set hay backup | | ⚠ Operational excellence | ⚠ thiếu thẻ, thiếu cảnh báo | | ⚠ Performance — hiệu năng | ⚠ thiếu chỉ mục, SKU quá nhỏ |

⚠ Khuyến nghị dựa trên telemetry của CHÍNH tài nguyên bạn đang chạy, không phải lời khuyên chung chung.

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

• A (Azure Service Health) — ⚠ báo sự cố và bảo trì ảnh hưởng tới bạn, không đưa khuyến nghị tối ưu.

• C (Azure Mobile App) — ⚠ là một cách XEM lại thông tin, không tự sinh khuyến nghị.

• D (Azure Firewall) — ⚠ dịch vụ tường lửa, không liên quan.

Ghi nhớ

⚠ Phần bảo mật của Advisor lấy từ Microsoft Defender for Cloud — hai công cụ nối với nhau.

Từ khoá nhận diện:

"khuyến nghị tối ưu chi phí, bảo mật, hiệu năng" → ⚠ Advisor "secure score" → ⚠ Defender for Cloud "sự cố nền tảng ảnh hưởng tới tôi" → ⚠ Service Health "ước tính chi phí TRƯỚC khi triển khai" → ⚠ Pricing Calculator

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lần cuối mở Advisor là khi nào | | | Có khuyến nghị bảo mật mức cao nào chưa xử lý không | | | Khuyến nghị bị bỏ qua có được ghi lý do không | |

Và giá trị thật của Advisor nằm ở chỗ nó dựa trên dữ liệu thật của hệ thống bạn. Đó là danh sách việc cần làm đã được xếp sẵn theo mức tác động — thứ mà một buổi rà soát thủ công phải mất nhiều ngày mới dựng được.

Đáp án

A — Azure Firewall.

Vì sao đúng

⚠ Azure Firewall có tính năng threat intelligence: | Tính năng | Nội dung | |---|---| | ⚠ Threat intelligence–based filtering | ⚠ tự cảnh báo hoặc CHẶN lưu lượng tới và từ IP, tên miền độc hại đã biết | | ⚠ Nguồn dữ liệu | ⚠ Microsoft Threat Intelligence, cập nhật liên tục | | ⚠ Hai chế độ | ⚠ Alert only, hoặc Alert and deny |

⚠ Các khả năng khác của Azure Firewall: | Khả năng | Nội dung | |---|---| | ⚠ Luật theo FQDN | ⚠ cho phép ra *.microsoft.com | | ⚠ Luật mạng và luật ứng dụng | | | ⚠ SNAT và DNAT | | | ⚠ Nhật ký tập trung | ⚠ gửi sang Log Analytics | | ⚠ Trạng thái đầy đủ, sẵn sàng cao sẵn có | |

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

• D (Network Security Group) — ⚠ chỉ lọc theo IP, cổng, giao thức; KHÔNG biết IP nào là độc hại, phải tự khai từng dải.

• C (Load Balancer) — ⚠ phân phối lưu lượng, không lọc mối đe doạ.

• B (Microsoft Entra ID) — ⚠ định danh, không lọc lưu lượng mạng.

Ghi nhớ

⚠ Azure Firewall và NSG — chọn cái nào: | Tiêu chí | NSG | Azure Firewall | |---|---|---| | ⚠ Giá | ⚠ miễn phí | ⚠ tính theo giờ và theo dữ liệu | | ⚠ Phạm vi | ⚠ subnet và card mạng | ⚠ biên của mạng ảo | | ⚠ Lọc theo tên miền | ⚠ không | ⚠ có | | ⚠ Threat intelligence | ⚠ không | ⚠ có | | ⚠ Nhật ký tập trung | ⚠ hạn chế | ⚠ đầy đủ | | ⚠ Thực tế | ⚠ dùng CẢ HAI, không thay thế nhau |

Từ khoá nhận diện:

"chặn IP và tên miền độc hại đã biết" → ⚠ Azure Firewall "lọc cơ bản theo cổng, miễn phí" → ⚠ NSG "chặn SQL injection, XSS" → ⚠ WAF "chống lưu lượng tấn công khổng lồ" → ⚠ DDoS Protection "phát hiện và điều tra sự cố an ninh" → ⚠ Microsoft Sentinel

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Threat intelligence đang ở chế độ Alert hay Deny | ⚠ chỉ Alert thì không chặn gì | | Lưu lượng ra Internet có thực sự đi qua firewall không | ⚠ kiểm tra bảng định tuyến | | Nhật ký firewall có được gửi đi và có ai đọc không | |

Và bẫy kiến trúc hay gặp nhất khi triển khai Azure Firewall: quên cấu hình định tuyến. Firewall dựng xong, tính tiền đầy đủ, nhưng lưu lượng vẫn ra Internet theo đường mặc định và không đi qua nó lần nào.

Đáp án

A — Privileged Identity Management (PIM).

Vì sao đúng

⚠ PIM quản lý quyền quản trị theo kiểu tạm thời, có kiểm soát: | Tính năng | Nội dung | |---|---| | ⚠ Quyền chỉ được KÍCH HOẠT khi cần | ⚠ just-in-time, không giữ thường trực | | ⚠ Buộc MFA khi kích hoạt vai trò | ⚠ chỉ áp cho người có vai quản trị | | ⚠ Có thời hạn | ⚠ hết giờ thì quyền tự thu hồi | | ⚠ Cần lý do, có thể cần người duyệt | | | ⚠ Ghi nhật ký và cảnh báo mọi lần kích hoạt | | | ⚠ Đánh giá quyền định kỳ | ⚠ access review |

⚠ Người dùng thường  →  ⚠ đăng nhập bình thường
⚠ Quản trị viên      →  ⚠ muốn dùng quyền  →  ⚠ kích hoạt vai trò
                                              ⚠ MFA + lý do + có hạn

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

• D (Advanced Threat Protection) — ⚠ phát hiện mối đe doạ, không quản lý quyền.

• C (Entra ID B2B) — ⚠ mời cộng tác viên bên ngoài, không liên quan.

• B (Azure Firewall) — ⚠ lọc lưu lượng mạng.

Ghi nhớ

⚠ Trong thực tế, việc "buộc MFA cho nhóm này mà không cho nhóm kia" thường làm bằng Conditional Access — nhưng phương án đó không có trong đề, và PIM cũng thực sự buộc MFA cho vai quản trị khi kích hoạt.

Từ khoá nhận diện:

"quyền quản trị tạm thời, kích hoạt khi cần" → ⚠ PIM "điều kiện đăng nhập theo nhóm hoặc vị trí" → ⚠ Conditional Access "phát hiện tài khoản bị lộ" → ⚠ Identity Protection "mời người ngoài tổ chức" → ⚠ B2B

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bao nhiêu tài khoản giữ quyền Global Admin thường trực | ⚠ nên rất ít | | Vai quản trị có bị buộc MFA khi kích hoạt không | | | Đã có quy trình đánh giá quyền định kỳ chưa | |

Và thay đổi tư duy quan trọng nhất mà PIM mang lại: có quyền không còn là một trạng thái, mà là một hành động có ghi nhận. Mỗi lần dùng quyền quản trị đều để lại dấu vết và có lý do đi kèm.

Đáp án

A — ĐÚNG.

Vì sao đúng

⚠ Đó là đặc trưng cốt lõi của đám mây công cộng — tự phục vụ: | Đặc trưng | Nội dung | |---|---| | ⚠ Tự phục vụ theo yêu cầu | ⚠ không cần thương lượng hợp đồng trước | | ⚠ Đăng ký trực tuyến | ⚠ thẻ tín dụng là đủ | | ⚠ Dùng được ngay | ⚠ vài phút, không chờ mua sắm phần cứng | | ⚠ Trả theo mức dùng | | | ⚠ Hạ tầng dùng chung | ⚠ multi-tenant, cách ly logic |

⚠ Truyền thống: ⚠ duyệt ngân sách → ⚠ mua máy → ⚠ chờ giao → ⚠ lắp đặt  = ⚠ hàng tháng
⚠ Đám mây:      ⚠ đăng ký → ⚠ tạo tài nguyên                              = ⚠ vài phút

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

• B (SAI) — ⚠ không đúng; Azure công cộng cho phép ai cũng đăng ký, thậm chí có tài khoản miễn phí kèm 200 USD tín dụng.

⚠ Ngoại lệ hợp lý: ⚠ Azure Government và Azure China có yêu cầu đủ điều kiện, nhưng đó là các đám mây tách biệt, không phải Azure công cộng mà đề nói tới.

Ghi nhớ

⚠ Năm đặc trưng của điện toán đám mây: | Đặc trưng | Nội dung | |---|---| | ⚠ Tự phục vụ theo yêu cầu | ⚠ tự tạo tài nguyên, không cần con người duyệt | | ⚠ Truy cập rộng qua mạng | ⚠ từ mọi nơi, mọi thiết bị | | ⚠ Gộp tài nguyên | ⚠ hạ tầng dùng chung nhiều khách hàng | | ⚠ Co giãn nhanh | ⚠ thêm bớt trong vài phút | | ⚠ Đo lường được | ⚠ tính tiền theo mức dùng thật |

Từ khoá nhận diện:

"ai cũng đăng ký được, dùng ngay" → ⚠ public cloud "chỉ tổ chức đủ điều kiện" → ⚠ Azure Government hoặc Azure China "hạ tầng riêng cho một tổ chức" → ⚠ private cloud "kết hợp tại chỗ và đám mây" → ⚠ hybrid

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức có bao nhiêu subscription và ai sở hữu | | | Có subscription nào ngoài tenant chính không | | | Đã có chính sách giới hạn vùng và SKU chưa | |

Và mặt sau của sự tiện lợi này: thứ khiến đám mây dễ bắt đầu cũng khiến nó dễ mất kiểm soát. Bất kỳ ai có thẻ đều mở được một subscription mới, nên quản trị tập trung phải được dựng sớm, chứ không phải sau khi đã có ba mươi tài khoản rải rác.

Đáp án

A — Azure AI Services (trước là Cognitive Services).

Vì sao đúng

⚠ Azure AI Services là TẬP HỢP các API AI dựng sẵn: | Nhóm | Việc | |---|---| | ⚠ Speech | ⚠ nhận diện giọng nói, đọc văn bản thành tiếng | | ⚠ Vision | ⚠ gắn thẻ ảnh, OCR, phát hiện đối tượng | | ⚠ Language | ⚠ phân tích cảm xúc, trích thực thể, hỏi đáp | | ⚠ Translator | ⚠ dịch văn bản và tài liệu | | ⚠ Document Intelligence | ⚠ bóc dữ liệu từ biểu mẫu | | ⚠ Azure OpenAI | ⚠ mô hình sinh, hỗ trợ chatbot |

⚠ Gọi bằng REST API hoặc SDK — không cần biết học máy.

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

• B (Azure AI Language services, trước là LUIS) — ⚠ chỉ là MỘT nhóm trong bộ đó, không phải cả tập hợp.

• D (Azure Machine Learning Studio) — ⚠ nền tảng để TỰ HUẤN LUYỆN mô hình, không phải API dựng sẵn.

• C (Azure Batch) — ⚠ chạy tính toán theo lô, không phải AI.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #22091 ở lô trước hỏi Azure AI Services làm được gì (đáp án: tất cả các việc liệt kê); câu này hỏi tên gọi của bộ API đó. ⚠ Hai câu bổ sung nhau.

⚠ Ba mức tiếp cận AI trên Azure — chọn theo năng lực và nhu cầu: | Mức | Dịch vụ | Dành cho | |---|---|---| | ⚠ Dùng API sẵn | ⚠ Azure AI Services | ⚠ lập trình viên, không cần biết ML | | ⚠ Kéo thả và tự động | ⚠ Azure ML designer, AutoML | ⚠ người phân tích dữ liệu | | ⚠ Viết mã huấn luyện | ⚠ Azure Machine Learning | ⚠ nhà khoa học dữ liệu |

Từ khoá nhận diện:

"API sẵn có, gọi là dùng" → ⚠ Azure AI Services "tự huấn luyện mô hình của mình" → ⚠ Azure Machine Learning "xây ứng dụng AI sinh, quản lý mô hình" → ⚠ Azure AI Foundry "tìm kiếm thông minh trên dữ liệu của mình" → ⚠ Azure AI Search

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có API sẵn nào giải được bài toán này chưa | ⚠ kiểm tra trước khi huấn luyện mô hình | | Dữ liệu gửi lên có nhạy cảm không | | | Kết quả AI có được con người xem lại trước khi ra quyết định không | |

Và nguyên tắc thực tế nhất khi bắt đầu với AI trên Azure: thử API dựng sẵn trước. Tự huấn luyện mô hình chỉ đáng làm khi API sẵn có đã được chứng minh là không đủ cho bài toán cụ thể của bạn.

Đáp án

D — Cho phép người dùng truy cập desktop và ứng dụng ảo hoá từ bất cứ đâu

Vì sao đúng

Azure Virtual Desktop cung cấp desktop và ứng dụng chạy trên đám mây, truy cập được từ máy tính, máy tính bảng hay trình duyệt. Giá trị thực tế nằm ở chỗ dữ liệu và ứng dụng ở lại trên đám mây, không nằm trên thiết bị đầu cuối — nên máy cá nhân bị mất cũng không mất dữ liệu công ty.

Nó cũng là cách nhanh nhất để cấp môi trường làm việc chuẩn cho nhân viên mới hoặc nhà thầu.

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

• A. Dịch vụ cơ sở dữ liệu được quản lý — mô tả Azure SQL hoặc Cosmos DB.
• B. Tự động triển khai và quản lý ứng dụng container — mô tả AKS.
• C. Nền tảng không máy chủ chạy ứng dụng theo sự kiện — mô tả Azure Functions.

Đáp án

A — ĐÚNG.

Vì sao đúng

⚠ Tenant là thể hiện Entra ID riêng của một tổ chức: | Đặc điểm | Nội dung | |---|---| | ⚠ Tự động tạo | ⚠ khi tổ chức đăng ký một dịch vụ đám mây Microsoft | | ⚠ Riêng và tách biệt | ⚠ dữ liệu định danh không lẫn với tổ chức khác | | ⚠ Đại diện cho một tổ chức | ⚠ thường gắn với tên miền, ví dụ contoso.onmicrosoft.com | | ⚠ Chứa người dùng, nhóm, ứng dụng đã đăng ký | |

⚠ Tenant (Entra ID)
   ├── ⚠ Subscription 1
   │      └── ⚠ Resource Group  →  ⚠ Resource
   └── ⚠ Subscription 2
   ⚠ MỘT tenant có NHIỀU subscription
   ⚠ MỘT subscription chỉ tin cậy MỘT tenant

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

• B (SAI) — ⚠ không đúng; đây đúng là định nghĩa Microsoft dùng.

Ghi nhớ

⚠ Bốn khái niệm hay bị nhầm lẫn nhất: | Khái niệm | Là gì | |---|---| | ⚠ Tenant | ⚠ tổ chức, thể hiện Entra ID | | ⚠ Subscription | ⚠ ranh giới thanh toán và cách ly tài nguyên | | ⚠ Management Group | ⚠ nhóm nhiều subscription để áp chính sách chung | | ⚠ Resource Group | ⚠ nhóm tài nguyên cùng vòng đời |

Từ khoá nhận diện:

"thể hiện Entra ID của tổ chức" → ⚠ tenant "ranh giới hoá đơn và hạn mức" → ⚠ subscription "áp chính sách cho nhiều subscription" → ⚠ management group "xoá cả nhóm cùng lúc" → ⚠ resource group

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức đang có mấy tenant | ⚠ nhiều hơn một thì phải có lý do rõ ràng | | Mỗi subscription thuộc tenant nào | | | Có subscription nào của nhân viên tự mở không | ⚠ shadow IT |

Và điều cần cân nhắc kỹ trước khi chuyển một subscription sang tenant khác: toàn bộ gán quyền RBAC sẽ bị xoá sạch. Tài nguyên vẫn còn nguyên, nhưng không ai truy cập được cho tới khi gán lại quyền từ đầu.

Đáp án

A — Bạn được hoàn lại một phần nhỏ phí hằng tháng.

Vì sao đúng

⚠ Vi phạm SLA được bù bằng TÍN DỤNG DỊCH VỤ, theo bậc: | Mức khả dụng thực tế | Tín dụng hoàn | |---|---| | ⚠ Dưới 99,99% (với SLA 99,99%) | ⚠ 10% | | ⚠ Dưới 99% | ⚠ 25% | | ⚠ Dưới 95% | ⚠ 100% | | ⚠ Con số cụ thể | ⚠ khác nhau tuỳ dịch vụ |

⚠ Ba điều quan trọng: | Điều | Nội dung | |---|---| | ⚠ Là TÍN DỤNG, không phải tiền mặt | ⚠ trừ vào hoá đơn kỳ sau | | ⚠ Bạn phải TỰ YÊU CẦU | ⚠ Azure không tự hoàn | | ⚠ Có thời hạn nộp yêu cầu | ⚠ thường trong vài tháng |

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

• C (dịch vụ sẽ miễn phí tháng đó) — ⚠ chỉ đúng ở mức vi phạm NẶNG NHẤT, không phải mọi vi phạm.

• B (không thể xảy ra, Azure luôn đạt SLA) — ⚠ SAI; sự cố có xảy ra, và SLA tồn tại chính vì điều đó.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #22076 ở lô trước nói SLA khác nhau tuỳ dịch vụ; câu này nói điều gì xảy ra khi vi phạm. ⚠ Hai câu bổ sung nhau.

⚠ SLA KHÔNG phải là gì: | Hiểu nhầm | Thực tế | |---|---| | ⚠ "Bồi thường thiệt hại kinh doanh" | ⚠ KHÔNG — chỉ tín dụng dịch vụ | | ⚠ "Tự động hoàn tiền" | ⚠ KHÔNG — phải tự yêu cầu | | ⚠ "Đảm bảo ứng dụng của tôi luôn chạy" | ⚠ KHÔNG — chỉ cam kết về hạ tầng Azure | | ⚠ "Áp cho mọi dịch vụ" | ⚠ KHÔNG — Preview và bậc Free không có SLA |

Từ khoá nhận diện:

"vi phạm SLA" → ⚠ tín dụng dịch vụ, phải tự yêu cầu "dịch vụ Preview" → ⚠ không có SLA "SLA tổng hợp của nhiều thành phần" → ⚠ NHÂN các SLA lại, thấp hơn thành phần yếu nhất "muốn SLA cao hơn" → ⚠ triển khai dư thừa, đa vùng sẵn sàng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã tính SLA tổng hợp của cả chuỗi phụ thuộc chưa | | | Có ai theo dõi Service Health để biết khi nào được yêu cầu tín dụng không | | | Thiệt hại thật khi ngừng một giờ là bao nhiêu | ⚠ so với tín dụng nhận được |

Và cách hiểu đúng nhất về SLA: nó nói cho bạn biết cần thiết kế dư thừa đến mức nào, chứ không đền bù cho bạn khi có sự cố. Tín dụng nhận được gần như không bao giờ tương xứng với thiệt hại kinh doanh.

Đáp án

D — Windows và Linux.

Vì sao đúng

⚠ Azure Virtual Machines hỗ trợ hai họ hệ điều hành: | Họ | Ví dụ bản phân phối | |---|---| | ⚠ Windows | ⚠ Windows Server 2016–2025, Windows 10 và 11 cho môi trường ảo hoá | | ⚠ Linux | ⚠ Ubuntu, RHEL, SUSE, Debian, CentOS Stream, Oracle Linux, Rocky, Alma |

⚠ macOS KHÔNG chạy được như một máy ảo Azure thông thường — Apple ràng buộc macOS phải chạy trên phần cứng Apple, nên các nhà cung cấp đám mây phải dùng máy Mac vật lý cho thuê chứ không phải máy ảo.

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

• A (chỉ Windows) và B (chỉ Linux) — ⚠ thiếu một nửa; Linux chiếm phần lớn workload trên Azure.

• C (chỉ macOS) và E (cả ba) — ⚠ SAI vì có macOS.

Ghi nhớ

⚠ Điều cần nhớ về máy ảo Azure: | Điều | Nội dung | |---|---| | ⚠ Ảnh lấy từ Azure Marketplace | ⚠ hoặc ảnh tuỳ chỉnh của bạn | | ⚠ Có thể mang ảnh riêng lên | ⚠ VHD tự chuẩn bị | | ⚠ Giấy phép Windows tính trong giá VM | ⚠ trừ khi dùng Hybrid Benefit | | ⚠ Linux thường rẻ hơn | ⚠ không tính phí giấy phép, trừ bản trả phí như RHEL |

Từ khoá nhận diện:

"VM Azure chạy hệ điều hành nào" → ⚠ Windows và Linux "đã có giấy phép Windows Server tại chỗ" → ⚠ Azure Hybrid Benefit, tiết kiệm đáng kể "chạy macOS để build ứng dụng iOS" → ⚠ cần dịch vụ Mac chuyên biệt, không phải VM Azure "chạy container thay vì VM" → ⚠ Container Instances, Container Apps, AKS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy Windows có bật Hybrid Benefit chưa | ⚠ nếu đã có giấy phép | | Có máy nào chạy ngoài giờ mà không cần không | | | Bản vá hệ điều hành đang do ai quản | |

Và khoản tiết kiệm hay bị bỏ quên nhất với máy ảo Windows: Azure Hybrid Benefit. Nếu tổ chức đã có giấy phép Windows Server kèm Software Assurance, bật cờ này giảm đáng kể chi phí mà không phải đổi gì trong hệ thống.

Đáp án

A — Application Gateway hiểu giao thức HTTP, đọc được URL và ra quyết định dựa trên URL.

Vì sao đúng

⚠ Khác biệt gốc nằm ở TẦNG hoạt động: | Dịch vụ | Tầng | Nhìn thấy gì | |---|---|---| | ⚠ Load Balancer | ⚠ 4 — TCP/UDP | ⚠ chỉ IP và cổng | | ⚠ Application Gateway | ⚠ 7 — HTTP/HTTPS | ⚠ URL, header, cookie, hostname |

⚠ Nhờ đọc được HTTP, Application Gateway làm được: | Khả năng | Nội dung | |---|---| | ⚠ Định tuyến theo đường dẫn | ⚠ /api sang nhóm A, /images sang nhóm B | | ⚠ Định tuyến theo tên miền | ⚠ nhiều site trên một gateway | | ⚠ Dừng và giải mã TLS | ⚠ SSL termination, giảm tải cho máy sau | | ⚠ Ghim phiên bằng cookie | | | ⚠ Chuyển hướng và viết lại header | | | ⚠ Web Application Firewall | ⚠ tuỳ chọn |

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

• B (Application Gateway co giãn được nhiều thể hiện) — ⚠ ĐÚNG nhưng KHÔNG phải điểm khác biệt; Load Balancer cũng là dịch vụ phân tán, sẵn sàng cao.

• C (là sản phẩm cấp doanh nghiệp, không nên dùng Load Balancer trong sản xuất) — ⚠ SAI; Load Balancer được dùng rộng rãi trong sản xuất và là lựa chọn đúng cho lưu lượng không phải HTTP.

Ghi nhớ

⚠ Đối chiếu: ⚠ lô trước có #22117 (dịch vụ nào phân phối lưu lượng) và #22119 (Application Gateway có WAF mà Load Balancer không có). ⚠ Câu này bổ sung nguyên nhân kỹ thuật: vì nó hoạt động ở tầng 7.

Từ khoá nhận diện:

"định tuyến theo URL, có WAF" → ⚠ Application Gateway "TCP/UDP, độ trễ thấp, không phải HTTP" → ⚠ Load Balancer "toàn cầu, tầng 7, có cache" → ⚠ Front Door "định tuyến toàn cầu bằng DNS" → ⚠ Traffic Manager

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lưu lượng có phải HTTP không | ⚠ không phải thì Load Balancer là đúng | | Có cần định tuyến theo đường dẫn không | | | Có cần WAF không | ⚠ nếu có thì buộc phải tầng 7 |

Và nguyên tắc chọn gọn nhất: dùng công cụ ở tầng thấp nhất mà vẫn đủ việc. Tầng 7 mạnh hơn nhưng chậm hơn và đắt hơn, nên chỉ dùng khi thật sự cần đọc nội dung HTTP.