10.3 Governance Policies: Approvals, Leases, Resource Quotas, & Day-2 Actions

10.3 Governance Policies: Approvals, Leases, Resource Quotas, & Day-2 Actions

Exam Focus: For the VCP-VCF (2V0-17.25) exam, enterprise governance and lifecycle policy enforcement form a vital administrative domain. Candidates must master how Service Broker enforces Approval Policies (including criteria triggers, multi-level approval matrices, and timeout behaviors), Lease Policies (enforcing automated resource reclamation and extension boundaries), Resource Quotas (at both Project and Cloud Zone scopes), and Day-2 Action Policies (governing operational permissions on provisioned workloads).

---

The Service Broker Policy Engine & Governance Framework

A primary value proposition of VMware Cloud Foundation 9.0 is enabling self-service velocity while maintaining rigorous enterprise IT governance. If developers can provision compute and storage resources on demand without administrative friction, an enterprise faces severe risks of resource exhaustion, unexpected infrastructure sprawl, unbudgeted expenditure, and compliance violations.

VCF Automation resolves this tension through the Service Broker Policy Engine. The policy engine provides a centralized, declarative governance framework that evaluates every catalog request and Day-2 operational action against enterprise rules before infrastructure changes occur.

Policy Scope & Hierarchy

Policies within Service Broker can be established at two distinct administrative scopes:

• Organization Scope: Policies defined at the Organization level apply universally across all Projects, users, and deployments within that organization. Organization-level policies cannot be overridden or bypassed by individual project administrators, ensuring non-negotiable enterprise compliance baselines.
• Project Scope: Policies configured at the Project level apply exclusively to deployments owned by members of that specific project. This enables departmental customization (e.g., granting developers 14-day leases while allowing production operations 365-day leases).

When multiple policies apply to the same request, Service Broker resolves enforcement based on explicit Policy Priority (numeric ranking where 1 is highest priority) or evaluates the most restrictive condition (e.g., selecting the shortest lease duration or the lowest resource cap).

---

Approval Policies: Criteria, Workflows, & Decision Handling

Approval Policies act as automated gating mechanisms. When a consumer submits a catalog request or initiates a Day-2 modification, Service Broker intercepts the request, evaluates whether any approval criteria are met, and halts provisioning until designated approvers review and authorize the transaction.

User Catalog Request ──> [Criteria Match Check] ──> Match Found?
                             │                           │
                             ├── No ──> Provision Immediately
                             │
                             └── Yes ──> [Halt Request & Dispatch Alert]
                                              │
                         ┌────────────────────┴────────────────────┐
                         ▼                                         ▼
                  [Manual Approval]                         [Timeout Expired]
                  • Approve ──> Provision                   • Auto-Reject (Default)
                  • Reject  ──> Terminate                   • Auto-Approve (Optional)

Approval Trigger Criteria

Service Broker supports granular conditional triggers, ensuring approvals are only mandated for high-impact or non-standard deployments:

• Resource Sizing Thresholds: Trigger approvals based on resource magnitude (e.g., total deployment vCPUs > 8, total memory > 32 GB, or total attached storage > 500 GB).
• Financial Cost Estimates: Interfacing directly with VCF Operations cost engines, policies can trigger approvals if estimated monthly deployment costs exceed a defined threshold (e.g., estimatedCost > 500.00 USD).
• Target Cloud Zones & Capability Tags: Mandate manager sign-off only when workloads target high-cost or regulated infrastructure (e.g., cloudZone: PCI-Production or tag: tier:gold).
• Flavor & Image Mappings: Trigger approvals if specific non-standard OS images or extra-large flavor sizes are requested.
• Day-2 Operational Actions: Intercept high-risk lifecycle actions (such as virtual machine resizing, attaching extra disks, or restoring snapshots).

Approver Definitions & Hierarchies

Administrators configure who possesses the authority to grant approvals:

• Named Users & Identity Directory Groups: Route requests to designated individuals (e.g., IT Operations Leads) or Active Directory security groups.
• Manager Approval: Service Broker integrates with corporate identity directories (via Workspace ONE Access or VCF Identity Broker). By inspecting user directory schemas, the system automatically routes the approval request to the requester's direct manager without requiring hardcoded user mappings.
• Multi-Level Sequential Approvals: For high-value requests, administrators construct multi-tier approval chains. For example, Level 1 requires technical approval from the Project Administrator; upon Level 1 sign-off, the request escalates to Level 2 for financial sign-off from the Department Director.

Approval Expiration & Timeout Behaviors

If an approver fails to respond within a configured expiration window (e.g., 72 hours), Service Broker enforces a deterministic timeout action:

• Reject (Default & Recommended): The request expires and is cancelled. This prevents unapproved workloads from deploying due to administrative absence.
• Approve: The request is automatically approved and forwarded to the provisioning engine upon timeout.

---

Lease & Expiration Policies: Automated Resource Reclamation

"Virtual machine sprawl"—where temporary development and testing workloads remain running indefinitely after projects end—is a primary driver of infrastructure waste. Lease Policies (also called Expiration Policies) enforce automated lifecycles for all provisioned deployments.

Core Lease Configuration Elements

1. Total Lease Duration: Specifies the standard operational lifespan granted to a deployment upon initial provisioning (e.g., 30 days).
2. Maximum Lease Duration: Establishes the absolute ceiling for a deployment, preventing infinite renewals. Even with extensions, a workload cannot exceed this duration.
3. Grace Period: The buffer period (e.g., 3 days) between lease expiration and permanent resource destruction. When a lease reaches 0 days, the platform initiates a graceful guest OS shutdown and powers off the virtual machines. The resources remain in this stopped state throughout the grace period, giving application owners a final opportunity to request an emergency renewal if the workload is still required.
4. Notification Warnings: Automated warning emails dispatched to deployment owners at configured intervals prior to expiration (e.g., 7 days and 1 day before lease expiration).

Automated Resource Reclamation

When the grace period expires without renewal, Service Broker triggers an automated end-of-life teardown:

• Virtual machines and attached storage disks are permanently deleted from vCenter Server and vSAN datastores.
• Dynamic NSX logical segments, Tier-1 routers, and security tags are torn down.
• IP address allocations and DNS records are returned to IPAM and DNS servers.
• Compute and memory headroom is reclaimed into the Project quota pool immediately.

Lease Extension Requests

Consumers can submit a "Change Lease" Day-2 action from the Service Broker deployment interface. Administrators can govern extensions by attaching an Approval Policy to the Change Lease action, requiring management sign-off if a user requests an extension exceeding standard parameters.

---

Resource Quotas & Allocation Ceilings

To prevent resource exhaustion, budget overruns, and noisy-neighbor contention across shared physical infrastructure, VCF Automation enforces Resource Quotas.

Resource Quotas differ fundamentally from hypervisor-level reservations and limits. While vSphere DRS resource pools govern memory and CPU scheduling shares on physical ESXi hosts, VCF Automation Quotas represent administrative capacity ceilings evaluated at request time.

Quota Scopes & Enforcement Metrics

Administrators configure quotas across two operational dimensions:

• Project Quotas: Constrain total aggregate consumption across all deployments owned by members of that Project, regardless of where the workloads land.
• Cloud Zone Quotas: Constrain consumption allocated by a specific Project within a specific Cloud Zone.

Quotas enforce hard ceilings across four core metrics:

1. Total Virtual Machine Instances: Maximum concurrent VMs permitted (e.g., 100 instances).
2. Total vCPUs: Maximum aggregate virtual processing cores (e.g., 400 vCPUs).
3. Total Memory (GB): Maximum aggregate RAM allocation (e.g., 1,600 GB).
4. Total Storage Capacity (GB): Maximum aggregate disk storage consumed across all datastores (e.g., 20,000 GB).

Quota Evaluation Pipeline

When a user clicks "Submit" on a catalog item, Service Broker performs an instant mathematical evaluation before invoking the Cloud Assembly placement engine. The system calculates the projected resource footprint of the requested template and adds it to the Project's current utilization. If any metric exceeds the quota ceiling, the request fails immediately with a clear explanatory error (e.g., Request rejected: Project 'Dev-Team' exceeds memory quota limit of 1600 GB).

---

Day-2 Action Policies: Operational Guardrails

Once workloads are provisioned, consumers require administrative autonomy to operate their environments. However, unrestricted operational freedom introduces operational risk. A developer mistakenly power-cycling a production database or creating unmanaged VM snapshots can cause severe outages and storage exhaustion.

Day-2 Action Policies establish fine-grained Role-Based Access Control (RBAC) over the post-deployment operations available to users.

Standard Day-2 Operations Governed by Policy

Custom Day-2 Actions

Beyond native hypervisor operations, administrators can create Custom Resource Actions. By binding an Aria Automation Orchestrator workflow or ABX action to a specific resource type, administrators expose custom self-service operational tasks directly within the Service Broker deployment interface. Examples include:

• "Execute On-Demand Security Vulnerability Scan"
• "Backup Database to S3 / MinIO Object Storage"
• "Rotate Operating System Root Password"
• "Install Splunk Forwarder Logging Agent"

---

Policy Comparison Matrix

---

Exam Watch: Key Scenarios and Candidate Traps

[!IMPORTANT] Quota Evaluation Timing: VCP-VCF exam questions frequently assess when resource quotas are evaluated. Quotas are evaluated at request submission time in Service Broker, before any placement matchmaking or hypervisor API calls occur. If an incoming request causes a Project to exceed its aggregate vCPU, RAM, or storage limits, Service Broker rejects the request immediately without consulting vCenter Server or NSX.

[!TIP] Organization vs. Project Policy Precedence: If an Organization-level policy defines a maximum lease duration of 60 days, and a Project Administrator configures a Project-level policy specifying a 90-day lease, the Organization-level policy prevails. Project-level policies can be more restrictive than Organization policies, but they can never grant permissions or durations that violate an overarching Organization boundary.

[!WARNING] Snapshot Sprawl & Day-2 Policy Guardrails: Creating hypervisor snapshots without lifecycle limits degrades vSAN storage performance and consumes massive datastore capacity. In VCF Automation, administrators must enforce Day-2 Action Policies that limit the maximum number of snapshots per VM (e.g., max 1 or 2) and specify mandatory expiration timers to ensure snapshots are automatically committed and deleted.

[!NOTE] Real-World Exam Scenario: A software engineering department requires automated self-service access to deploy test environments. To control infrastructure spend, IT leadership mandates that: (1) Any VM with more than 8 vCPUs requires team lead approval; (2) All test environments must automatically power off after 14 days and be deleted after a 3-day grace period; and (3) Developers must never be allowed to manually delete production-tagged deployments. The solution requires configuring an Approval Policy, a Lease Policy, and a Day-2 Action Policy in Service Broker.