A tax assessor’s SD-Access design must isolate a new third-party appraisal SaaS VRF-style tenancy from staff while still tagging fine-grained roles inside the staff network. When is a new Virtual Network (VN) warranted instead of only adding an SGT inside an existing VN?

A tax assessor isolating third-party appraisal SaaS tenancy from staff while still tagging fine-grained roles inside staff should create a new Virtual Network when macro segmentation needs a separate overlay routing domain; use SGTs for micro-segmentation inside a VN. A new VN is warranted for distinct tenancy/trust routing spaces—not for every AD group change.

Creating a new VN whenever any two users have different AD groups explodes VN count; that is what SGTs are for inside a VN.

Creating VNs only when Assurance is disabled because SGTs cannot work with Assurance is false—Assurance and SGTs coexist.

Needing a second underlay OSPF process ID for every endpoint group confuses underlay process design with overlay segmentation.

Exam caveat: decide VN vs SGT using trust-boundary and routing-table isolation requirements, not organizational chart leaf nodes.

Operational check: place appraisal tenancy in its own VN, keep staff role SGTs inside the staff VN, and verify no unintended route fusion. Update the assessor segmentation decision tree for future SaaS onboardings. 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.