Automation, APIs, and Infrastructure as Code
This domain tests whether you can drive the platform programmatically and reproducibly: which endpoint to call, how to authenticate, and how to make automation safe to re-run.
Interfaces
- REST APIs are exposed on port 9440 by both Prism Element and Prism Central. v3 APIs use list/create/update patterns with asynchronous task UUIDs; v4 APIs on Prism Central use a different, more resource-oriented shape.
- SDKs (for example Python), PowerShell cmdlets,
ncli/acli, Ansible modules, a Terraform provider, and Calm blueprints/DSL all sit on top of those APIs. - Many objects - categories, projects, IAM - exist only on Prism Central, not on the cluster endpoint.
Automation rules
- Poll the returned task UUID; a create call returning HTTP 202 does not mean the resource exists yet.
- Paginate list calls (
length/offseton v3) rather than assuming one response holds everything. - Keep automation idempotent: look up by name or category before creating, and store Terraform state durably.
- Never hardcode credentials; use dedicated service accounts with least privilege.
Worked example
Provisioning 20 VMs: the script checks for an existing VM by name, creates it if absent, tags it with the correct category so protection and security policies attach automatically, then polls each task UUID until success before moving on. Re-running the script after a partial failure creates only the missing VMs - that property, not speed, is the point.
Traps
Calling Prism Element for a Prism Central-only object; assuming synchronous behavior; mixing v3 and v4 path conventions; leaving credentials and state files unprotected.