azure-prepare

Files (1)

• SKILL.md

SKILL.md (first lines)

# Azure Prepare

Prepare subscriptions, resource groups, identity, governance, and cost controls per the Cloud Adoption Framework.
Landing zone setup is foundational; all deployments depend on this layer.

## Use This Skill When

- The user is starting a new Azure project or subscription
- Deployment keeps failing due to missing prerequisites (permissions, providers, quotas)
- The user asks for preflight checks, environment bootstrap, or landing zone design
- The user needs Azure Policy, tagging strategy, or access control baseline

## Context: Landing Zone Maturity

**Immature**: Ad hoc resource creation, no policies, inconsistent naming, mixed environments  
**Developing**: Basic resource groups, manual access control, some tagging  
**Managed**: Landing zone deployed, policies enforced, RBAC standardized, centralized logging  ← **Target**  
**Optimized**: GitOps for infrastructure, automated drift detection, cost governance, full audit trail

## Required Inputs

- **Tenant and subscription**: Tenant ID, subscription ID, billing account
- **Environment scope**: Single tenant or multi-tenant? Dev/test/prod separation?
- **Region strategy**: Primary and secondary regions, data residency constraints
- **Naming convention**: Org-env-workload-resource-seq (e.g., `contoso-prod-web-vm-01`)
- **Networking model**: Hub-spoke, vWAN, or flat? Private or public endpoints?
- **Identity model**: Entra ID only, on-premises sync, hybrid?
- **Security baseline**: Encryption, firewalls, NSGs, private link requirements
- **Team structure**: Who owns the platform? Who owns workloads?
- **Cost targets**: Monthly budget, chargeback model, reserved capacity?

## Decision Tree

```
Is this the first Azure subscription for the organization?
├─ Yes → Deploy landing zone from template (Microsoft Foundational or Enterprise)
└─ No → Align with existing landing zone patterns

Do you have on-premises infrastructure?
├─ Yes → Enable ExpressRoute, Site-to-Site VPN, DNS forwarders
└─ No → Direct internet egress acceptable

How many teams will share this subscription?
├─ Single team → Simple RBAC, one resource group per environment
└─ Multiple teams → Multiple resource groups, centralized policy, shared services

Are there compliance or regulatory requirements?
├─ Yes → Deploy Azure Policy, enable Defender, configure audit logging
└─ No → Basic security baseline sufficient
```

## Workflow

### Phase 1: Landing Zone Foundation

1. **Choose landing zone template**:
   - **Foundational** (Startups, small teams): VNet, NSG, basic RBAC
   - **Standard** (Mid-market): Hub-spoke, centralized DNS, policy enforcement
   - **Enterprise** (Large org): Management groups, policy cascade, full governance

2. **Provision landing zone**:
   ```bash
   # Use Azure landing zone Bicep templates from Microsoft
   az deployment tenant create \
     --name alz-deployment \
     --location eastus \
     --template-uri https://raw.githubusercontent.com/Azure/landing-zones-accelerator/main/templates/
   ```

3. **Validate foundational resources**:
   - Management groups created (root > platform > landing zones)
   - Subscription placed in correct management group
   - Policy definitions assigned at appropriate scope

### Phase 2: Subscription Baseline

1. **Provider registration**:
   ```bash
   # Enable required resource providers
   az provider register --namespace Microsoft.Compute
   az provider register --namespace Microsoft.Network
   az provider register --namespace Microsoft.Storage
   # (List depends on workload)
   ```

2. **Create resource groups by lifecycle**:
   - **Shared**: Logging, monitoring, networking (long-lived)
   - **Dev/Test**: Short-lived, high churn, lower security bar
   - **Production**: Long-lived, strict change controls, backup/DR

3. **Apply Azure Policy**:
   - Enforce tagging (owner, environment, cost-center)
   - Enforce encryption (storage, databases)
   - Prevent public IP creation (unless whitelisted)
   - Require network security groups

### Phase 3: Identity & Access

1. **Define role structure**:
   - **Subscription Owner** (2-3 people, max): Rare, emergency escalation only
   - **Resource Group Owners** (teams): Manage resources within group
   - **Workload Contributors** (developers): Deploy, configure; no delete
   - **Readers** (auditors, ops): View-only, troubleshooting

2. **Configure managed identities**:
   - System-assigned for single-app identities (App Service, Functions, AKS pods)
   - User-assigned for shared or multi-app identities
   - Never use connection strings in app settings

3. **Set up Key Vault**:
   ```bash
   az keyvault create --name "kv-${environment}-${org}" \
     --resource-group $RG --enable-rbac-authorization
   ```

### Phase 4: Networking

1. **Plan IP address space**:
   - Hub VNet: 10.0.0.0/8 reserved for platform services

From manu14357/zskills, MIT.

More from manu14357/zskills