10.1 Cloud Templates (Blueprints), Schema, & Infrastructure as Code

10.1 Cloud Templates (Blueprints), Schema, & Infrastructure as Code

Exam Focus: For the VCP-VCF (2V0-17.25) exam, candidates must master Cloud Templates (formerly Cloud Assembly blueprints) within VMware Cloud Foundation 9.0. You must understand the declarative YAML schema structure (formatVersion, inputs, resources, outputs), know how to distinguish cloud-agnostic from platform-specific resources, configure dynamic property expressions and conditional scaling, integrate cloud-init for guest operating system customization, and govern template lifecycles using enterprise Git version control and the Aria Automation Terraform provider.

[!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 Cloud Template Architecture & Declarative YAML Schema

In VMware Cloud Foundation 9.0, Cloud Templates serve as the foundational declarative Infrastructure as Code (IaC) definition for all automated provisioning. Authored within VCF Automation Cloud Assembly, Cloud Templates allow cloud architects and DevOps engineers to model complex multi-tier enterprise applications—encompassing compute virtual machines, storage disks, software components, and NSX software-defined networks—as human-readable, machine-executable YAML documents.

Every Cloud Template adheres to a standardized four-tier top-level schema hierarchy:

formatVersion: 1
inputs:
  # User-facing parameters prompted at request time
resources:
  # Declarative graph of infrastructure and application components
outputs:
  # Exported runtime attributes returned after deployment

1. Schema Header (formatVersion)

The schema begins with formatVersion: 1. This mandatory element informs the Cloud Assembly compiler of the underlying parser version and schema specifications utilized by the template engine.

2. User Input Definitions (inputs:)

The inputs block defines parameterized variables prompted to the consumer when requesting the template from the Service Broker catalog, REST API, or CI/CD pipeline. Inputs allow a single template to serve diverse operational tiers (e.g., development, staging, production) and sizing profiles without code duplication.

VCF Automation supports strong parameter typing and robust validation constraints:

• type: Specifies data primitive: string, integer, number, boolean, array, or object.
• title & description: Human-readable UI labels and contextual tooltips displayed in self-service request forms.
• default: Pre-populated fallback value if the user does not supply an explicit input.
• enum: A rigid set of allowable options rendered as a drop-down menu in the user interface.
• minimum & maximum: Numeric boundaries enforcing resource ceilings (e.g., limiting database memory allocation between 4 GB and 64 GB).
• pattern: Regular expressions validating string inputs (e.g., enforcing enterprise hostname conventions ^[a-z]{3}-[0-9]{3}$).
• encrypted: true: Designates sensitive data (passwords, API tokens, SSH keys). Encrypted inputs are masked with asterisks in the UI, redacted in audit logs, and stored in the internal cryptographic vault.
• readOnly: true: Displays static informational values that cannot be altered by the requester.

3. Resource Graph (resources:)

The resources block defines the operational components to be instantiated. Each resource contains a unique logical component identifier (e.g., web_tier, db_storage), a declared resource type, and specific properties dictating its operational configuration.

Crucially, resources within a template form a Directed Acyclic Graph (DAG). Cloud Assembly calculates component provisioning sequences automatically based on explicit and implicit dependencies. For example, if a virtual machine binds its network adapter to an on-demand NSX routed network, Cloud Assembly provisions the NSX Tier-1 gateway and logical segment before cloning the virtual machine in vCenter Server.

4. Deployment Outputs (outputs:)

The outputs block extracts runtime metadata generated during provisioning and returns it to the requesting consumer, upstream pipeline, or API caller. Common outputs include dynamic IP addresses assigned by IPAM, fully qualified domain names (FQDNs), load balancer virtual IP (VIP) endpoints, and generated administrative credentials.

---

Declarative Cloud Template Example: Multi-Tier Architecture

The following complete YAML document illustrates an enterprise multi-tier application template featuring user inputs, dynamic bindings, cloud-init guest customization, NSX micro-segmentation, and output declarations:

formatVersion: 1
inputs:
  environment:
    type: string
    title: Target Environment
    description: Select the target operational tier
    enum:
      - dev
      - staging
      - production
    default: dev
  clusterSize:
    type: integer
    title: Web Server Node Count
    description: Number of web instances to deploy
    minimum: 1
    maximum: 5
    default: 2
  adminPassword:
    type: string
    title: Administrator Password
    description: Secure password for guest OS local administrator
    encrypted: true

resources:
  # On-demand NSX Routed Segment
  app_network:
    type: Cloud.NSX.Network
    properties:
      networkType: Routed
      constraints:
        - tag: 'env:production:soft'

  # NSX Micro-segmentation Security Group
  web_security_group:
    type: Cloud.SecurityGroup
    properties:
      securityGroupType: Existing
      constraints:
        - tag: 'security:web-dmz'

  # Clustered Web Tier Virtual Machines
  web_vm:
    type: Cloud.Machine
    properties:
      name: '${input.environment}-web-${count.index + 1}'
      count: '${input.clusterSize}'
      image: ubuntu-22.04-lts
      flavor: '${input.environment == "production" ? "large" : "small"}'
      constraints:
        - tag: '${input.environment == "production" ? "tier:gold" : "tier:standard"}'
      networks:
        - network: '${resource.app_network.id}'
          securityGroups:
            - '${resource.web_security_group.id}'
      cloudConfig: |
        #cloud-config
        package_update: true
        packages:
          - nginx
          - curl
        runcmd:
          - echo "Deployed by VCF Automation in ${input.environment}" > /var/www/html/index.html
          - systemctl enable nginx
          - systemctl start nginx

  # Enterprise Database VM with Dedicated Storage
  db_storage:
    type: Cloud.Volume
    properties:
      capacityGb: 100
      constraints:
        - tag: 'storage:vsan-esa-raid1'

  db_vm:
    type: Cloud.vSphere.Machine
    dependsOn:
      - web_vm
    properties:
      name: '${input.environment}-db-01'
      image: rhel-9-hardened
      cpuCount: 4
      totalMemoryMB: 16384
      attachedDisks:
        - source: '${resource.db_storage.id}'
      networks:
        - network: '${resource.app_network.id}'
      customizationSpec: Linux-Enterprise-Customization

outputs:
  web_endpoints:
    type: array
    title: Web Server IP Addresses
    value: '${resource.web_vm[*].networks[0].address}'
  db_ip:
    type: string
    title: Database Private IP
    value: '${resource.db_vm.networks[0].address}'

---

Cloud-Agnostic vs. Platform-Specific Resource Types

A central design decision when authoring Cloud Templates is choosing between Cloud-Agnostic and Platform-Specific resource types. Cloud Assembly provides both models to balance multi-cloud portability against deep platform-native hypervisor control.

Cloud-Agnostic Resource Types

Cloud-agnostic resources abstract underlying hypervisor and infrastructure specifics behind standard primitives (Cloud.Machine, Cloud.Network, Cloud.Storage, Cloud.LoadBalancer).

• Mechanism: Agnostic resources rely on Flavor Mappings (mapping aliases like small, medium, large to CPU/RAM settings) and Image Mappings (mapping aliases like ubuntu-22.04 to vSphere Content Library templates or AWS AMIs). Placement is determined dynamically via capability and constraint tags.
• Advantage: Maximum portability. A single Cloud Template can be deployed without modification to an on-premises VCF Workload Domain, VMware Cloud on AWS, or native public cloud endpoints (AWS, Azure, GCP).

Platform-Specific Resource Types

Platform-specific resources (Cloud.vSphere.Machine, Cloud.vSphere.Network, Cloud.NSX.Network, Cloud.AWS.Machine) expose the granular native attributes and capabilities of a specific target cloud.

• Mechanism: In a VCF environment, using Cloud.vSphere.Machine allows architects to declare vSphere-specific configuration parameters directly in YAML: target datacenter, VM folder paths, resource pools, vCenter Customization Specifications, vSAN storage policy bindings, and exact SCSI controller types (e.g., VMware Paravirtual SCSI).
• Advantage: Unlocks hypervisor-level optimization and advanced features that cannot be generalized across heterogeneous clouds.

Resource Types Comparison Matrix

---

Expression Syntax, Bindings, & Dynamic Evaluation

Cloud Templates utilize a powerful expression engine enclosed in ${ ... } syntax. Expressions allow template properties to be resolved dynamically at request time or during provisioning runtime.

Core Expression Types

1. User Input References: Bind properties directly to user entries:

   name: '${input.vmNamePrefix}-01'
   flavor: '${input.instanceSize}'
   

2. Cross-Resource References: Bind attributes from one component to another across the dependency graph:

   network: '${resource.backend_network.id}'
   primaryDisk: '${resource.storage_vol.id}'
   

3. Environment Context Variables (env): Provide contextual metadata about the execution scope:

   • ${env.projectName}: Name of the consuming Project.
   • ${env.deploymentId}: Unique GUID assigned to the deployment.
   • ${env.requestedBy}: User principal name (UPN) of the requester.

4. Ternary Conditional Logic: Implements inline decision making (condition ? true_value : false_value):

   flavor: '${input.envTier == "prod" ? "large" : "small"}'
   cpuCount: '${input.workloadType == "analytics" ? 16 : 4}'
   

5. Conditional Resource Instantiation (count): Evaluates whether a resource should be deployed or scales the number of replicas dynamically:

   # Deploys only if user checks the enableMonitoring boolean input
   count: '${input.enableMonitoring ? 1 : 0}'
   
   # Elastic cluster deployment indexing
   count: '${input.replicaCount}'
   name: 'app-node-${count.index + 1}'
   

6. Explicit Dependency Chains (dependsOn): While Cloud Assembly automatically determines dependencies through property references, architects can force strict sequential provisioning using dependsOn. For example, ensuring a database VM completes its initialization before application servers begin booting:

   app_vm:
     type: Cloud.Machine
     dependsOn:
       - db_vm
   

---

Guest Operating System Customization: Cloud-Init & Custom Specs

Deploying a raw virtual machine template produces an unconfigured node. VCF Automation Cloud Templates support two primary methodologies for automated Day-0/Day-1 guest OS configuration:

1. Cloud-Init & Cloud-Config

cloud-init is the cross-platform industry standard for multi-cloud guest OS initialization. Integrated directly into the cloudConfig property of a Cloud.Machine or Cloud.vSphere.Machine, it executes during the first boot cycle of the virtual machine:

• Capabilities: Network configuration, creating local administrative users, injecting SSH public keys, mounting secondary vSAN disks, formatting file systems, registering with configuration management tools (Ansible, Puppet, Chef), and running bootstrap shell scripts.
• Execution Phases: Cloud-init executes in structured stages (cloud-init-local, cloud-init, cloud-config, cloud-final).

2. vCenter Customization Specifications

For environments with established vSphere operations or Windows workloads requiring domain joins, architects bind templates to existing vCenter Customization Specifications via the customizationSpec property:

• Capabilities: Generates unique Security Identifiers (SIDs) via Microsoft Sysprep, sets local administrator credentials, configures time zones and licensing keys, assigns static IP addresses, and joins Active Directory domains automatically.

---

Git Integration, Versioning, & Terraform Workflows

In an enterprise private cloud operating model, Cloud Templates must be governed under strict software engineering disciplines rather than manually edited in a web GUI.

Native Enterprise Git Integration

Cloud Assembly provides native bidirectional integration with enterprise version control systems, including GitHub, GitLab, and Bitbucket.

• Repository Synchronization: Cloud Templates are stored as YAML files within dedicated Git repositories and branches. Cloud Assembly connects via SSH keys or personal access tokens (PATs).
• Two-Way Synchronization: Developers can author templates in their preferred IDE (such as VS Code), commit changes, and trigger automated synchronization into Cloud Assembly via Git webhooks. Conversely, changes drafted within the Cloud Assembly canvas can be committed directly back to the upstream Git repository.

Semantic Versioning & Release Lifecycle

Cloud Templates follow a disciplined lifecycle progression:

1. Draft: Unreleased working version in Cloud Assembly. Can be tested by designers in sandbox environments.
2. Version Creation: When a template is validated, the architect creates a versioned snapshot (e.g., v1.0.0, v1.1.0), supplying descriptive change logs.
3. Release Tagging: An architect explicitly flags a specific version as Released. Only released versions can be imported into the Service Broker catalog for consumption by end users. If an updated template version is released, Service Broker allows administrators to update the catalog item without breaking existing active deployments.

Aria Automation Terraform Provider

Beyond native YAML authoring, platform engineering teams can consume and manage VCF Automation declaratively using HashiCorp Terraform via the official VMware Aria Automation Terraform Provider (vmware/vra / vmware/aria).

• Platform engineers declare Cloud Templates, Projects, Cloud Accounts, and Cloud Zones directly within Terraform HCL files.
• Developers can execute terraform apply against VCF Automation, leveraging VCF's multi-tenant governance, policy evaluation, and IPAM allocation while maintaining familiar developer toolchains.

---

Exam Watch: Key Scenarios and Candidate Traps

[!IMPORTANT] Input Validation and Encrypted Parameters: VCP-VCF exam questions frequently assess how to protect sensitive credentials during template requests. Always remember that marking an input with encrypted: true ensures that passwords, secret keys, or tokens are masked in the UI with asterisks, sanitized from operational logs, and stored in the encrypted platform vault. Never pass cleartext passwords through unencrypted string inputs or plain cloudConfig text without encryption.

[!TIP] Catalog Release Prerequisite: A common troubleshooting question asks why a newly created Cloud Template does not appear in the Service Broker catalog content source list. A template cannot be published to Service Broker or shared with consumer Projects until an architect explicitly creates a version snapshot and marks that version as Released.

[!WARNING] Circular Dependency Deadlocks: If web_vm declares dependsOn: [db_vm] and db_vm simultaneously references an output from web_vm (such as ${resource.web_vm.networks[0].address}), the Cloud Assembly compiler detects a circular dependency in the Directed Acyclic Graph (DAG) and fails template validation immediately before provisioning begins.

[!NOTE] Real-World Exam Scenario: An organization requires a single Cloud Template to provision a small virtual machine (2 vCPU, 4GB RAM) when requested in Development, but a large virtual machine (8 vCPU, 32GB RAM) with high-performance storage when requested in Production. The optimal design uses a single Cloud Template with an environment input and ternary expression bindings: flavor: '${input.environment == "production" ? "large" : "small"}' combined with matching capability and constraint tags.