Dr. Pranay Jha

VCF Automation does not deploy anything until you give it the keys. A cloud account is exactly that: a stored credential that lets the platform read inventory from and push workloads to a vCenter or NSX. No cloud account, no infrastructure, and the most carefully designed catalog in the world has nowhere to land a machine. This Part is short on theory and long on the connections that turn an empty platform into one that can actually build something.

What a cloud account actually is

Strip away the name and a cloud account is a credential with a job. A vCenter cloud account is the credential VCF Automation uses to collect data from and deploy compute and storage to that vCenter. An NSX cloud account is the credential it uses to create and deploy network resources. A VCF cloud account brings SDDC Manager into the picture so the platform understands the wider fabric. The Infrastructure tab is where the inventory those accounts collect shows up: machines, networks, storage, and volumes, ready for templates to reference.

Why this matters beyond plumbing: the account is also a blast radius. The credential you store here can read and change real infrastructure, so it deserves the same care as any service account. Scope it to what VCF Automation actually needs, store it where secrets belong, and rotate it on a schedule. A cloud account quietly using a domain admin credential is a convenience today and an audit finding tomorrow.

Adding a vCenter cloud account

The path is Connections, then Cloud accounts, then Add cloud account, then pick the type. For vCenter you supply the server address and a credential, and the platform validates it before saving. That validation step is not a formality; it is the cheapest place to catch a typo in the hostname, a wrong password, or a firewall that quietly drops the connection. If validation fails here, nothing downstream will work, so fix it before moving on rather than saving a broken account and debugging it from a failed deployment later.

# vCenter cloud account, inputs (Connections > Cloud accounts > Add)
vcenter_cloud_account:
  name:        vc-wld-prod-01
  fqdn:        vcenter-wld-01.lab.local
  username:    svc-vcfa@vsphere.local     # scoped service account, not a person
  password:    ''
  validate:    true                       # validate BEFORE saving
# On success, the Infrastructure tab fills with machines, networks and storage.

NSX, and the 9.0 change you cannot ignore

An NSX cloud account gives VCF Automation the credentials to build network resources. When you add one, you can either enter NSX Manager credentials directly or use Create and Validate Service Credentials, which has Automation Assembler create and validate the NSX credentials for you. The second option is the one I prefer, because it produces a purpose-built credential rather than reusing an admin login you will forget to rotate.

Here is the part that bites people migrating from 8.x. VCF 9.0 removed the ability to add NSX-T cloud accounts using the manager setting, the one that leverages NSX-T Manager APIs, and removed VCF cloud accounts with an underlying NSX-T manager mode. In plain terms: manager mode is gone, and you connect NSX in Policy mode. If your old runbooks or scripts assume manager mode, they do not just need updating, they describe a path that no longer exists.

The VCF cloud account and SDDC Manager

A VCF cloud account is the one that ties deployments to the broader VCF fabric, and it has a prerequisite: SDDC Manager 4.1 or later must be configured as an Automation Assembler integration before the VCF cloud account will work. So the order is integration first, account second. Skip the integration and the VCF account has nothing to bind to. This is the account that lets the platform reason about the VCF instance rather than just a lone vCenter, which matters once you are deploying across workload domains rather than a single cluster.

Validating accounts and reading the Infrastructure tab

Adding an account is only half the job; the account has to actually collect inventory before anything can deploy onto it. The flow is the same every time: you add the account, the platform validates the credential, it runs a data collection against the target, and the results land in the Infrastructure tab as machines, networks, storage, and volumes. A template can only reference what data collection found, so an empty Infrastructure tab is not a cosmetic problem, it is a deployment that will fail to place.

When the tab comes back empty after a green validation, the cause is almost always permissions rather than a missing object. A credential that can authenticate but cannot read clusters, datastores, or port groups validates cleanly and then collects nothing, which looks like a platform fault and is really a role assignment one rung too low. Check what the service account can actually see in vCenter or NSX before you suspect anything deeper. The other usual suspects are a network path that blocks the collection traffic even though the login succeeded, and an account pointed at the wrong instance entirely, easy to do when hostnames differ by one character.

Build the habit of confirming inventory, not just validation, as the real done signal for a cloud account. Validation tells you the door opened; the populated Infrastructure tab tells you the platform walked in and took a complete picture. Until you have seen the second thing, the account is not finished, however green the first looked. That one extra glance saves the awkward later moment where a perfectly designed template cannot find a single cluster to run on.

Final Thoughts

Cloud accounts are the seam between the platform and reality, and they reward a little discipline. My recommendation: add accounts in order, vCenter then NSX then VCF, validate every one before moving on, and confirm the Infrastructure tab actually populated rather than assuming it did. Use scoped service accounts and the Create and Validate option for NSX so your credentials are purpose-built and rotatable. And internalise the 9.0 change: NSX is Policy mode now, manager mode is gone, so any design that assumes otherwise needs rewriting before it wastes your afternoon. Get the accounts right and templates have something real to deploy onto. Get them wrong and every later Part is built on a connection that does not work.

Next we turn that connected infrastructure into placement targets: cloud zones, regions, and how mappings tie templates to real capacity. For the projects that consume these accounts, see Part 8 on projects. Have you hit the NSX manager-mode removal yet? Tell me how it went in the comments.

References

• Create a vCenter Cloud Account in VCF Automation (Broadcom TechDocs)
• VCF Automation Product Support Notes (Broadcom TechDocs)
• VCF 9 VCF Automation: Create VM App Organization and Integrations (blanketvm)

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts