Grain-elevator engineers may manage Azure only from the plant’s egress IP ranges; traffic from any other network must require MFA and a compliant device or be blocked. Which Conditional Access element expresses that network boundary for Azure portal work?

Conditional Access location conditions use named (including trusted) network locations built from public egress IP ranges. For grain-elevator engineers who may manage Azure only from the plant’s egress IPs—with other networks requiring MFA and compliant device or block—define a named location for the plant egress ranges and use it as a location condition on the Azure-management Conditional Access policy (often with separate policies or include/exclude logic for trusted vs untrusted locations).

Attaching an NSG to each engineer’s laptop NIC fails by concept: user laptops are not Azure NICs in the plant VNet in this scenario, and NSGs do not express Entra location conditions for portal access. Creating a Private Endpoint for every Azure resource fails as a substitute: Private Link changes data-plane network paths to PaaS; it does not replace Conditional Access location conditions for who may authenticate to Azure management from which networks. Placing Azure Firewall in front of Entra ID fails because Entra authentication is a Microsoft-hosted identity service; you do not front Entra with Azure Firewall inside a customer VNet to evaluate Conditional Access locations.

Exam caveat: named locations are defined with public IPs/ranges as seen by Entra, not private RFC1918 plant addresses unless correctly represented via egress. Operational check: create the named location with plant egress IPs, attach it to the CA policy, test from plant egress (allowed path) and from a home IP (MFA+compliant or block per design), and document IP change procedures when ISP ranges shift.