Parks uses vRealize Automation to stamp NSX-T security tags when a new recreation VM is provisioned. Why does that keep Distributed Firewall true?
Select an answer to reveal the explanation.
Short Explanation
The recreation VM gets its security name badge as it is born. Dynamic groups see the tag and Distributed Firewall is already waiting—no after-the-fact ticket.
Full Explanation
Parks keeps Distributed Firewall true when vRealize Automation stamps NSX-T security tags at provision time because those tags place the new recreation VM into dynamic groups that already carry Distributed Firewall policy. Treat tagging at birth as putting the correct civic park badge on the cart before it leaves the warehouse so micro-segmentation applies on first boot without a later ticket. Claiming vRealize Automation replaces NSX-T Distributed Firewall fails by concept because IaaS orchestration only applies tags and membership; enforcement remains NSX Distributed Firewall on the vNIC. Claiming tags disable Guest Introspection so Distributed Firewall is unused fails because tagging drives group membership for Distributed Firewall and does not turn Guest Introspection or DFW off. Claiming provisioning writes iptables inside the guest instead of NSX policy fails because guest iptables are not the NSX-T policy model and do not realize distributed micro-segmentation across the parks overlay. Exam caveat: provision-time NSX tagging is a policy-automation pattern that keeps DFW intent attached via dynamic groups; it does not replace DFW, disable Guest Introspection, or substitute guest firewall scripts. Operational check: provision a recreation VM through vRealize Automation, confirm the expected NSX security tags, verify dynamic group membership and Distributed Firewall hits on first traffic, and document the tag taxonomy in the parks IaaS blueprint.