9.1 VCF Automation Architecture, Services, & Automation Use Cases

9.1 VCF Automation Architecture, Services, & Automation Use Cases

Exam Focus: For the VCP-VCF (2V0-17.25) exam, candidates must thoroughly understand the architectural fabric of VCF Automation in VMware Cloud Foundation 9.0. Mastery of the four foundational services—Cloud Assembly, Service Broker, Code Stream (Pipelines), and Aria Automation Orchestrator—is required. Candidates must know how Cloud Accounts and Cloud Zones are defined, how the placement engine resolves capability tags against hard and soft constraint tags, and how developer self-service workflows bridge declarative infrastructure-as-code templates to governed catalog deployments.

[!NOTE] VCF Automation 9.0 interface naming. The legacy Aria Automation service tiles — Cloud Assembly, Service Broker, and Orchestrator — remain functional in the backend but no longer structure the 9.0 user interface. VCF Automation 9.0 consolidates them into four menus: Consume (catalog and deployment experiences), Design (blueprints, property groups, custom resources), Content & Policies (content sources, policies, notifications), and an embedded Orchestrator tab. Read older "switch to the Cloud Assembly tile" instructions as referring to the Design menu in 9.0.

---

The VCF Automation Microservices Platform

In VMware Cloud Foundation 9.0, private cloud environments require more than virtualized compute, storage, and networking; they require an intelligent, automated consumption and orchestration plane. VCF Automation (formerly VMware Aria Automation) serves as this modern cloud management platform, delivering an infrastructure-as-code (IaC) and self-service delivery framework that abstracts full-stack SDDC resources across management and Virtual Infrastructure (VI) workload domains.

The underlying architecture of VCF Automation is structured as a resilient, multi-node appliance cluster executing containerized microservices, providing high availability, automated load balancing, and persistent state synchronization across active nodes.

Deployment Options in VCF 9.0

How VCF Automation is deployed changed with VCF 9.0, and the change is examinable:

• The VCF Installer deploys it. During a new deployment the installer can stand up a new VCF Automation instance, or leverage an existing instance already present in the fleet. Reusing an existing instance is what places a second VCF instance into the same automation and consumption plane rather than creating a parallel one.
• VCF Operations manages its lifecycle. Deployment of the Aria Suite through SDDC Manager was removed in VCF 9.0, and the VCF Installer and VCF Operations now handle it. Study material instructing an administrator to deploy or upgrade the automation stack from SDDC Manager or Aria Suite Lifecycle is describing a removed mechanism.
• Scale is a cluster decision. The platform is deployed as an appliance cluster, so the deployment choice is between a smaller footprint for non-production or evaluation use and a multi-node highly available cluster for production consumption, where node loss must not interrupt catalog requests or in-flight deployments.

Because VCF Automation is a fleet-scoped component rather than an instance-scoped one, this decision is made once for the fleet rather than repeated per VCF instance. The platform exposes four primary microservices that collectively automate the infrastructure lifecycle from initial design to end-user consumption:

1. Cloud Assembly: The infrastructure orchestration and design engine. Cloud Assembly is the primary workbench for cloud administrators and automation engineers. It provides the administrative interface to connect physical and virtual endpoints (Cloud Accounts), define resource boundaries (Cloud Zones), configure environment-agnostic abstractions (Flavor and Image Mappings), and author declarative Cloud Templates. Cloud Assembly supports both a drag-and-drop graphical canvas and a declarative YAML schema, enabling teams to model complex multi-tier virtual machines, Kubernetes clusters, software configurations, and NSX network topologies as version-controlled code.
2. Service Broker: The unified enterprise catalog and governance engine. While Cloud Assembly serves infrastructure designers, Service Broker is the consumer-facing storefront for developers, line-of-business operators, and DevOps engineers. Service Broker aggregates published Cloud Templates from Cloud Assembly and combines them with diverse multi-cloud blueprints, including VMware Aria Automation Orchestrator workflows, AWS CloudFormation templates, Azure Resource Manager (ARM) templates, Terraform configurations, and Kubernetes Helm charts. Crucially, Service Broker acts as the policy enforcement gatekeeper, applying Role-Based Access Control (RBAC), content sharing policies, approval workflows, lease timers, and Day-2 action permissions to govern catalog items.
3. Code Stream (Automation Pipelines): The continuous integration and continuous delivery (CI/CD) pipeline service. Code Stream provides a visual release automation canvas specifically optimized for infrastructure and application lifecycle management. It orchestrates multi-stage build, test, and deployment pipelines, integrating natively with Git repositories, Jenkins build servers, Docker containers, and Jira issue tracking. Cloud engineers utilize Code Stream to automate infrastructure upgrades, validate Cloud Template changes across sandbox environments, and execute canary or blue-green deployments.
4. VMware Aria Automation Orchestrator (vRO): The extensibility and workflow execution engine. Operating both as an embedded service and as an external scalable cluster, Orchestrator provides thousands of pre-configured and customizable workflows written in JavaScript, Python, NodeJS, or PowerShell. In VCF Automation, Orchestrator executes deep programmatic integrations with third-party enterprise tools, including Active Directory, ServiceNow ITSM, and Infoblox IPAM. Through the Event Broker Service (EBS), Orchestrator subscribes to lifecycle state events during virtual machine provisioning, allowing administrators to inject custom governance scripts without altering base templates.

---

Core Microservices Comparison Matrix

---

Cloud Accounts & Endpoint Discovery

To manage and provision infrastructure, VCF Automation must first establish administrative connectivity to physical and software-defined endpoints through Cloud Accounts. A Cloud Account stores the authentication credentials, endpoint URLs, and communication parameters required to interact with an underlying infrastructure provider.

In a standard VCF 9.0 private cloud deployment, administrators configure two foundational types of on-premises Cloud Accounts:

• vCenter Server Cloud Accounts: Connects VCF Automation to a target vCenter Server managing a Management Domain or VI Workload Domain. Upon connection, VCF Automation initiates an inventory discovery scan, cataloging available vSphere clusters, ESXi compute hosts, resource pools, VM folders, datastores, datastore clusters, standard/distributed port groups, and vSphere Content Libraries. Inventory synchronization occurs via periodic background polling and real-time event notifications.
• NSX Cloud Accounts: Connects to the NSX Manager cluster associated with the workload domain. An NSX Cloud Account is paired directly with its corresponding vCenter Cloud Account. This pairing enables VCF Automation to discover software-defined network fabrics, including Tier-0 and Tier-1 logical gateways, overlay transport zones, Edge clusters, distributed virtual switches, logical segments, and NSX Distributed Firewall (DFW) security groups.

Beyond private cloud infrastructure, VCF Automation supports public cloud endpoints (Amazon Web Services, Microsoft Azure, and Google Cloud Platform). This enables enterprise architects to govern hybrid cloud deployments through a single control plane while maintaining consistent security and policy baselines.

---

Cloud Zones & Provisioning Boundaries

Once Cloud Accounts synchronize infrastructure inventory, administrators carve compute resources into consumable provisioning targets known as Cloud Zones. A Cloud Zone encapsulates a specific slice of compute capacity within a Cloud Account and assigns it to an organizational boundary.

Administrators configure Cloud Zones around specific vSphere clusters or DRS resource pools. For example, in a VI Workload Domain containing three vSphere clusters, an administrator might establish two separate Cloud Zones: a "High-Performance Compute Zone" mapped to a cluster of GPU-enabled ESXi hosts, and a "General Dev/Test Zone" mapped to standard compute clusters.

Cloud Zones govern allocation behavior through several key settings:

• Placement Policy: Governs how workloads are scheduled across clusters within the zone (Default, Spread, or Binpack).
• Capability Tags: Key-value pairs assigned to the Cloud Zone to describe its operational characteristics.
• Compute Limits: Hard boundaries restricting the maximum amount of CPU, memory, and instances that can be allocated within the zone.
• Project Entitlements: Cloud Zones do not expose resources directly to end users; instead, they are allocated to specific Projects, defining which enterprise teams possess the authority to consume the underlying infrastructure.

---

Tagging Governance: Capability vs. Constraint Tags

The placement engine in VCF Automation relies on a declarative, tag-based matchmaking architecture to match application requirements to appropriate infrastructure resources. This tagging model decouples application templates from physical infrastructure names, ensuring templates remain portable across environments.

The matching mechanism functions through two reciprocal tag types:

• Capability Tags: Configured by cloud administrators directly on infrastructure resources, including Cloud Zones, compute clusters, storage profiles, and network profiles. Capability tags declare the traits and services provided by that resource (e.g., environment:production, tier:gold, storage:nvme, compliance:pci, site:us-west).
• Constraint Tags: Defined by template authors within Cloud Templates, or enforced globally by administrators at the Project level. Constraint tags express the requirements that an infrastructure resource must satisfy to host the workload (e.g., tier:gold, compliance:pci).

Hard vs. Soft Constraint Resolution

Constraint tags can be designated as either hard or soft:

• Hard Constraints ([tag_key:tag_value] or [tag_key:tag_value:hard]): Absolute, mandatory requirements. During placement evaluation, the provisioning engine searches for infrastructure resources possessing matching capability tags. If no resource satisfies all hard constraints, the provisioning request fails immediately with an allocation error.
• Soft Constraints ([tag_key:tag_value:soft]): Preferred requirements. The placement engine attempts to satisfy soft constraints by prioritizing resources with matching capability tags. However, if no matching resources have available capacity, the placement engine falls back to provisioning the workload onto an otherwise eligible resource that lacks the tag, preventing deployment failure.

Administrators can also define negative constraints (e.g., !environment:dev) to explicitly prevent workloads from landing on designated infrastructure pools.

Tag Matching Matrix

---

The Self-Service Private Cloud Consumption Lifecycle

The ultimate goal of VCF Automation is enabling friction-free developer self-service while enforcing strict IT governance. The complete end-to-end consumption lifecycle follows a structured five-stage workflow:

1. Infrastructure Configuration: Cloud administrators connect Cloud Accounts (vCenter and NSX), create Cloud Zones, define Flavor Mappings (standardizing CPU and memory sizes such as small, medium, large), configure Image Mappings (mapping OS aliases like ubuntu-22.04 to vSphere Content Library templates), and assign capability tags.
2. Template Design & Versioning: Cloud architects author declarative Cloud Templates in Cloud Assembly. Templates define compute nodes, storage attachments, software initialization scripts (cloud-init), and NSX network connections. When validated, the architect creates a released version of the template.
3. Catalog Publishing & Policy Attachment: In Service Broker, administrators import the released template and add it to the service catalog. They define Content Sharing Policies to entitle specific consumer Projects to request the item. Concurrently, administrators attach Approval Policies (e.g., triggering manager review if a deployment exceeds 16 vCPUs) and Lease Policies (enforcing a 30-day expiration timer on test workloads).
4. Self-Service Request & Automated Provisioning: A developer logs into the Service Broker portal (or triggers deployment via REST API, CLI, or Terraform). The system evaluates project quotas and approval criteria. Upon approval, Cloud Assembly takes ownership of the deployment: it resolves constraint tags against capability tags, selects the target Cloud Zone and compute cluster, allocates IP addresses, instructs NSX to provision network segments, and signals vCenter Server to clone virtual machines from the designated Content Library.
5. Day-2 Management & Decommissioning: Once deployed, consumers manage workloads through Day-2 operational actions (power cycling, creating snapshots, resizing vCPU/RAM, or attaching disks) permitted by their project role. When the project completes or the lease expires, VCF Automation gracefully tears down the deployment, reclaims compute resources, releases allocated IP addresses back to IPAM, and cleans up dynamic NSX segments.

---

Exam Watch: Key Scenarios and Candidate Traps

[!IMPORTANT] The Hard vs. Soft Constraint Trap: VCP-VCF exam questions frequently present scenarios where all compute clusters matching a hard constraint tag have run out of resources. If a question states that a template specifies tier:gold:hard and all Gold clusters are at 100% capacity, do not select answers suggesting the system will provision to a Silver cluster or prompt the user to choose another host. The provisioning engine terminates immediately with an allocation error. Only soft constraints (tier:gold:soft) allow automatic fallback.

[!TIP] Service Broker vs. Cloud Assembly Separation of Duties: Remember the clear operational boundary: Cloud Assembly is where templates are authored, endpoints are registered, and cloud abstractions are built. Service Broker is where templates are published, catalog items are consumed, approval policies are evaluated, and lease durations are enforced. A user requesting a machine from a catalog interacts exclusively with Service Broker.

[!WARNING] Unlinked NSX Cloud Accounts: If an NSX Cloud Account is created in Cloud Assembly but not explicitly associated with a vCenter Server Cloud Account, VCF Automation cannot discover the relationship between vSphere clusters and NSX transport nodes. Any Cloud Template requesting on-demand routed or isolated NSX segments on that vCenter will fail during network allocation.

[!NOTE] Real-World Exam Scenario: An organization requires virtual machines deployed by developers to be registered in ServiceNow CMDB and assigned an IP address from an Infoblox appliance before the VM powers on. The recommended architecture is creating an Event Broker Service (EBS) blocking subscription in VCF Automation that triggers an Aria Automation Orchestrator (vRO) workflow during the compute allocation and network provisioning phases.