The municipality wants GBP group membership informed by its existing identity and access management (IAM) results rather than only static switch port maps. What conceptual integration is appropriate?
Select an answer to reveal the explanation.
Short Explanation
IAM already knows the employee; GBP needs the network badge. Hooking auth results into group assignment keeps the fabric honest without stuffing passwords into EVPN routes.
Full Explanation
When the municipality wants GBP group membership informed by its existing identity and access management (IAM) results rather than only static switch port maps, the appropriate conceptual integration is to use identity or authentication outcomes to inform GBP group mapping at a concept level. Policy then tracks who or what connected—employee laptop, kiosk, or badge-authenticated device—instead of assuming a wall jack permanently equals a department. Replacing IAM with underlay static routes that encode usernames in next-hop metrics is not a workable identity model and confuses routing metrics with group classification. Disabling authentication so every endpoint shares one fabric-wide group collapses microsegmentation and defeats the IAM-driven goal. Storing IAM passwords in EVPN Type-2 routes for leaf validation is insecure nonsense and not how GBP integrates with identity systems. Exam caveat: describe IAM-informed GBP mapping conceptually without inventing credential-in-BGP mechanisms or vendor SKUs. Operational check: authenticate two civic test identities into different GBP groups via the city’s identity workflow, confirm leaf group membership follows the IAM result rather than the physical port alone, and verify inter-group policy tracks the identity change when the same port is reused.