Transit CI pipelines must push NSX-T groups and firewall policy without an operator clicking hundreds of rules. Which mechanism should they use?
Select an answer to reveal the explanation.
Short Explanation
Pipelines do not click through 200 rules like a clerk stamping permits by hand. They call the NSX Policy API—or Terraform on top of it—and the groups land as code.
Full Explanation
Transit CI pipelines that must push NSX-T groups and firewall policy without an operator clicking hundreds of rules should call the NSX Policy API or an IaC provider such as Terraform against that API. Pipelines are code, not clerks stamping permits by hand: declarative or API-driven changes land groups and rules consistently. Screenshotting the NSX UI and attaching it to a change ticket fails by concept because images are not executable policy, cannot be applied by CI, and drift the moment someone clicks elsewhere. Asking each hypervisor admin to paste iptables on ESXi fails because host iptables bypasses NSX-T centralized policy, breaks consistency across the cluster, and is not the supported Distributed Firewall model. Enabling Guest Introspection as a substitute for group definitions fails because Guest Introspection supports identity and partner services; it does not define security groups or replace Policy API automation. Exam caveat: NSX-T security automation for CI is Policy API or Terraform-on-API; UI screenshots, ESXi iptables, and Guest Introspection are not policy-as-code mechanisms. Operational check: run a pipeline that creates a test group and allow rule via Policy API or Terraform, confirm realization on transport nodes, tear down in CI, forbid screenshot-only “automation,” and store API credentials and modules in the transit IaC repo with least privilege.