Lab: Configure Multi-Tenant Project with Approval Policy and On-Demand Network

Create approval policy: Service Broker → Policies → Definitions → New Policy → Approval Policy. Name='Standard Deployment Approval'. Scope: Project='dev-team-alpha'. Decision policy: 'Any approver can approve'.

Configure conditional trigger: In the approval policy, add criteria:

Condition 1: 'When deployment request count > 2' (if requesting more than 2 VMs)
Condition 2: 'When flavor = large' (if requesting large VMs)

Approver: Select admin user. Timeout: Auto-deny after 72 hours if not actioned.

Create a second approval policy for higher-risk actions: Name='Production Change Approval'. Scope: apply when template has tag 'environment:prod'. Configure multi-level approval:

Level 1: Technical reviewer (project admin)
Level 2: Change manager (organization admin)

Both levels must approve. Timeout: 5 business days.

Test approval workflow: Login as dev-team-alpha member → Service Broker → Catalog → request 'Lab Web Server' with count=3 (triggers condition: count > 2). Verify: deployment shows 'Pending Approval'. Login as admin → Approvals → review request → Approve.

Test auto-deny: Login as member → request another deployment with count=3. Do NOT approve within 72 hours (or change timeout to 1 minute for lab testing). Verify: request auto-denied with reason 'Approval timeout exceeded'.

Configure on-demand routed network: Infrastructure → Network Profiles → edit 'Lab-Network-Profile' (from Lab 13) → Networks tab → On-Demand Networks → Add. Configure:

Type: Routed
CIDR: 172.16.0.0/16
Subnet Size: /24
Tier-1 Gateway: Select existing Tier-1 (or 'Create new' for per-deployment isolation)
Transport Zone: Overlay transport zone
IP Range: DHCP (or static with Automation-managed IPAM)

Configure on-demand isolated network: In the same network profile → On-Demand Networks → Add another:

Type: Isolated
CIDR: 10.100.0.0/16
Subnet Size: /24
No Tier-1 gateway (isolated segments have no external routing)
DNS: Internal DNS server IP

Create multi-network template using both on-demand types:

formatVersion: 1
inputs:
size:
type: string
enum: [small, medium]
default: small
resources:
web-vm:
type: Cloud.vSphere.Machine
properties:
image: ubuntu-2204
flavor: '${input.size}'
networks:

• network: '${resource["web-net"].id}'

app-vm:
type: Cloud.vSphere.Machine
properties:
image: ubuntu-2204
flavor: '${input.size}'
networks:

• network: '${resource["web-net"].id}'
• network: '${resource["db-net"].id}'

web-net:
type: Cloud.NSX.Network
properties:
networkType: routed
constraints:

• tag: 'env:lab'

db-net:
type: Cloud.NSX.Network
properties:
networkType: private
constraints:

• tag: 'env:lab'

Deploy the multi-network template. Monitor in real-time:

1. VCF Automation: Deployments → watch resource creation steps
2. NSX Manager: Segments → observe new segments appearing dynamically
3. NSX Manager: Tier-1 Gateways → observe routed segment attachment

4. vCenter: VMs created, NICs connected to correct segments

Verify network lifecycle: Delete the deployment. Monitor cleanup:

1. VCF Automation: Deployment deleted
2. vCenter: VMs removed
3. NSX Manager: Both on-demand segments deleted automatically
4. NSX Manager: Tier-1 gateway connection cleaned up

Verify: no orphaned segments remain in NSX Manager.

Configure project lease policy: VCF Automation → Administration → Projects → 'dev-team-alpha' → Provisioning tab → Lease Policy. Set: Default lease=7 days, Maximum lease=30 days, Grace period=3 days (time after expiry before destruction).

Configure lease notifications: Service Broker → Policies → Lease Expiration. Create notification policy:

1. Notify owner 3 days before expiry: 'Your deployment expires in 3 days. Renew or save your work.'
2. Notify owner 1 day before expiry: 'Final warning: deployment expires tomorrow.'
3. Notify project admin when deployment enters grace period

Test lease lifecycle: Deploy a catalog item with default 7-day lease. Check deployment details → Lease tab → verify expiry date. Test lease extension: Actions → Extend Lease → request 7 additional days. Verify total lease doesn't exceed maximum (30 days).

Configure resource reclamation: VCF Automation → Administration → Reclamation. Create reclamation policy:

1. Identify idle VMs: CPU utilization < 5% for 14+ days
2. Identify oversized VMs: CPU utilization consistently < 20% with 'large' flavor
3. Action: Send notification to owner with recommendation to downsize or delete
4. If no action after 7 days: escalate to project admin

Create a governance summary report: Review across all projects:

1. Total active deployments per project
2. Resource consumption vs limits (% utilized)
3. Deployments approaching lease expiry (next 7 days)
4. Idle/oversized VMs flagged for reclamation
5. Approval requests pending

Document this as the 'Multi-Tenant Governance Dashboard' data source for VCF Operations (Lab 11-12 integration).

Document a multi-tenancy reference architecture for 10 development teams:

1. Project Structure: 10 projects (one per team), shared cloud zones with per-project resource limits
2. Template Strategy: Shared template library (org-level) + team-specific templates (project-level)
3. Network Isolation: On-demand routed networks for externally-facing workloads, isolated for internal/PCI
4. Approval Matrix: Dev environment = auto-approve, Staging = tech lead approval, Production = CAB approval
5. Lease Policy: Dev = 7 days, Staging = 30 days, Production = no expiry (managed by change request)
6. Cost Allocation: Per-project costing via VCF Operations custom groups + rate cards

Design NSX IP planning for on-demand networks at scale:

Assume: 10 teams, average 20 active deployments per team, each deployment needs 1 routed + 1 isolated subnet.

Calculation:

• Total subnets needed: 10 teams x 20 deployments x 2 networks = 400 subnets
• Each subnet is /24 (254 usable IPs)
• Routed pool: 172.16.0.0/12 (1,048,576 IPs = 4,096 /24 subnets) — sufficient
• Isolated pool: 10.0.0.0/8 (16,777,216 IPs = 65,536 /24 subnets) — sufficient

Document: CIDR allocation per team for troubleshooting (172.16.0.0/16 for team 1, 172.17.0.0/16 for team 2, etc.).

Design escalation matrix for approval bottlenecks:

1. If primary approver doesn't respond within 24 hours → notify backup approver
2. If backup approver doesn't respond within 24 hours → auto-escalate to org admin
3. If deployment is tagged 'emergency' → bypass normal approval, require post-deployment review

4. Weekly report: approval response times, auto-denied requests, emergency bypasses

Document as an operational runbook for VCF Automation governance.

VCDX Defense Preparation — document responses:

1. 'How do you design a multi-tenant VCF Automation environment for 10 development teams?'

Answer: Project-per-team model with shared cloud zones and per-project resource limits. Capability tags control placement. Naming conventions enable cost allocation. Content sharing controls template visibility. This balances isolation with infrastructure efficiency.

2. 'What's the network isolation strategy with on-demand NSX segments?'

Answer: Routed for internet-facing tiers (web), isolated for internal/sensitive tiers (database). Per-team CIDR allocation prevents IP conflicts. Tier-1 gateway per deployment provides routing isolation. NSX DFW micro-segmentation adds application-level security within segments.

3. 'How do you prevent IP exhaustion with on-demand networking?'

Answer: Pre-allocate CIDR blocks per team (/16 each from a /12 pool). Monitor subnet utilization via NSX Manager API. Alert at 80% pool utilization. Reclamation policies automatically clean up unused segments. Emergency procedure: expand pool or consolidate underutilized team allocations.

4. 'What happens when an approver is unavailable for a week?'

Answer: Escalation matrix with backup approvers. 24-hour SLA per approval level. Emergency bypass for critical deployments with post-review. Weekly governance report tracks approval response times and identifies bottleneck approvers.

5. 'How do you justify the complexity of VCF Automation to leadership?'

Answer: ROI model — compare manual provisioning (5 days average, 2 hours admin time per VM) vs self-service (15 minutes, zero admin time). At 100 VMs/month: manual = 200 admin hours, self-service = 10 hours (governance overhead). Annual savings = 2,280 admin hours. That's the productivity argument. The governance argument: automated compliance, audit trail, and cost transparency.