A building permits desk onboards wired PCs into SD-Access so each authenticates into the correct virtual network based on identity and port assignment. What is the essential onboarding outcome?
Select an answer to reveal the explanation.
Short Explanation
Wired onboarding is the fabric’s greeter: who are you, which badge group, which VN lobby do you belong in? Identity plus port/pool policy drops the PC onto the right overlay segment. It’s not “give everyone the underlay loopback and hope.”
Full Explanation
At a building-permits desk, wired PCs onboard into SD-Access through identity- and pool-driven policy that places each endpoint into the intended virtual network/segment with the correct fabric policy. Authentication/authorization results, IP pools, and port assignments align so staff PCs land in the right overlay without manual per-MAC VLAN rituals.
Endpoints receiving only underlay loopback addresses and never joining an overlay VN describe infrastructure nodes, not user host onboarding.
All wired hosts statically mapping to the same anycast RP regardless of identity confuses multicast RP design with fabric host segmentation.
Border handoff type chosen per mouse click by each end user at login is not how fabric onboarding or border modes work.
Exam caveat: failed auth often falls back to a guest/critical VLAN or AuthZ profile—know the configured failure path so “wrong VN” is diagnosed as policy, not underlay loss.
Operational check: authenticate a test permits PC, confirm SGT/VN assignment and DHCP from the intended pool, and verify reachability only to allowed services. Capture AAA and pool bindings in the department onboarding standard. In municipal operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the platform code and policy revisions used by the civic network team.