A county tags new tax-system VMs with app=tax and env=prod and wants those VMs to inherit distributed firewall policy when they are cloned. What should the administrator build?
Select an answer to reveal the explanation.
Short Explanation
Tags are name badges the group engine already knows how to read. Badge a new tax VM and it walks into the policy—no clipboard of UUIDs.
Full Explanation
County tax-system VMs tagged app=tax and env=prod should inherit distributed firewall via NSX security groups whose membership criteria match those tags. Tag-based groups automatically include newly cloned and tagged tax VMs without rewriting static inventories after every clone.
A static inventory of tax VM BIOS UUIDs pasted into each DFW rule does not scale with cloning. A Carbon Black sensor group named tax-prod is not a valid NSX applied-to membership model for tag inheritance. One gateway firewall rule per tax VM IP rewritten after every clone is operationally brittle and wrong for east-west micro-segmentation at scale.
Exam caveat: tag criteria groups are the durable pattern for clone-heavy civic apps.
Operational check: create groups matching app=tax and env=prod, clone a VM with those tags, confirm membership, validate DFW inheritance, and ban UUID paste lists from the tax build standard.
Tag-based tax groups make cloning cheap for the county. Enforce tags in the provisioning pipeline, alert on tax VMs missing env=prod, and demonstrate to auditors that a fresh clone inherits DFW without a UUID spreadsheet update. Keep tag-membership proof from a freshly cloned tax VM with the provisioning change record so the next on-call engineer can demonstrate DFW inheritance without rediscovering UUID spreadsheets under pressure.