Azure Defaults

Azure Defaults Skill

Single source of truth for all Azure infrastructure configuration used across agents. Replaces individual _shared/ file lookups with one consolidated reference.

Quick Reference (Load First)

Default Regions

Required Tags (Azure Policy Enforced)

Bicep pattern:

tags: {
  Environment: environment
  ManagedBy: 'Bicep'
  Project: projectName
  Owner: owner
}

Unique Suffix Pattern

Generate ONCE in main.bicep, pass to ALL modules:

// main.bicep
var uniqueSuffix = uniqueString(resourceGroup().id)

module keyVault 'modules/key-vault.bicep' = {
  params: { uniqueSuffix: uniqueSuffix }
}

Security Baseline

CAF Naming Conventions

Standard Abbreviations

Length-Constrained Resources

Key Vault and Storage Account have 24-char limits. Always include uniqueSuffix:

// Key Vault: kv-{8chars}-{3chars}-{6chars} = 21 chars max
var kvName = 'kv-${take(projectName, 8)}-${take(environment, 3)}-${take(uniqueSuffix, 6)}'

// Storage: st{8chars}{3chars}{6chars} = 19 chars max (no hyphens!)
var stName = 'st${take(replace(projectName, '-', ''), 8)}${take(environment, 3)}${take(uniqueSuffix, 6)}'

Naming Rules

• DO: Use lowercase with hyphens (kv-myapp-dev-abc123)
• DO: Include uniqueSuffix in globally unique names (Key Vault, Storage, SQL Server)
• DO: Use take() to truncate long names within limits
• DON'T: Use hyphens in Storage Account names (only lowercase + numbers)
• DON'T: Hardcode unique values — always derive from uniqueString(resourceGroup().id)
• DON'T: Exceed max length — Bicep won't warn, deployment will fail

Azure Verified Modules (AVM)

AVM-First Policy

1. ALWAYS check AVM availability first via mcp_bicep_list_avm_metadata
2. Use AVM module defaults for SKUs when available
3. If custom SKU needed, require live deprecation research
4. NEVER hardcode SKUs without validation
5. NEVER write raw Bicep for a resource that has an AVM module

Common AVM Modules

Finding Latest AVM Version

// Use Bicep MCP tool:
mcp_bicep_list_avm_metadata → filter by resource type → use latest version

// Or check: https://aka.ms/avm/index

AVM Usage Pattern

module keyVault 'br/public:avm/res/key-vault/vault:0.11.0' = {
  name: '${kvName}-deploy'
  params: {
    name: kvName
    location: location
    tags: tags
    enableRbacAuthorization: true
    enablePurgeProtection: true
  }
}

AVM Known Pitfalls

Region Limitations

Parameter Type Mismatches

Known issues when using AVM modules — verify before coding:

Log Analytics Workspace (operational-insights/workspace):

• dailyQuotaGb is int in AVM, not string
• DO: dailyQuotaGb: 5
• DON'T: dailyQuotaGb: '5'

Container Apps Managed Environment (app/managed-environment):

• appLogsConfiguration deprecated in newer versions
• DO: Use logsConfiguration with destination object
• DON'T: Use appLogsConfiguration.destination: 'log-analytics'

Container Apps (app/container-app):

• scaleSettings is an object, not array of rules
• DO: Check AVM schema for exact object shape
• DON'T: Assume scaleRules: [...] array format

SQL Server (sql/server):

• sku parameter is a typed object {name, tier, capacity}
• DO: Pass full SKU object matching schema
• DON'T: Pass just string 'S0'
• availabilityZone requires specific format per region

App Service (web/site):

• APPINSIGHTS_INSTRUMENTATIONKEY deprecated
• DO: Use APPLICATIONINSIGHTS_CONNECTION_STRING instead
• DON'T: Set instrumentation key directly

Key Vault (key-vault/vault):

• softDeleteRetentionInDays is immutable after creation
• DO: Set correctly on first deploy (default: 90)
• DON'T: Try to change after vault exists

Static Web App (web/static-site):

• Free SKU may not be deployable via ARM in all regions
• DO: Use Standard SKU for reliable ARM deployment
• DON'T: Assume Free tier works everywhere via Bicep

WAF Assessment Criteria

Scoring Scale

Pillar Definitions

Assessment Rules

• DO: Score each pillar 1-10 with confidence level (High/Medium/Low)
• DO: Identify specific gaps with remediation recommendations
• DO: Calculate composite WAF score as average of all pillars
• DON'T: Give perfect 10/10 scores without exceptional justification
• DON'T: Skip any pillar even if requirements seem light
• DON'T: Provide generic recommendations — be specific to the workload

Azure Pricing MCP Service Names

Exact names for the Azure Pricing MCP tool. Using wrong names returns 0 results.

• DO: Use exact names from the table above
• DON'T: Use "Azure SQL" (returns 0 results) — use "SQL Database"
• DON'T: Use "Web App" — use "Azure App Service"

Service Recommendation Matrix

Workload Patterns

Detection Signals

Map user language to workload pattern:

Business Domain Signals

Company Size Heuristics

Industry Compliance Pre-Selection

Governance Discovery

Azure Policy Discovery Workflow

Before creating implementation plans, discover active policies:

1. Query Azure Resource Graph for policy assignments
2. Check tag enforcement policies
3. Check allowed resource types
4. Check allowed locations
5. Document in 04-governance-constraints.md

ARG Query Pattern

PolicyResources
| where type == 'microsoft.authorization/policyassignments'
| where properties.enforcementMode == 'Default'
| project name, displayName=properties.displayName,
  effect=properties.parameters.effect.value,
  scope=properties.scope
| order by name asc

Common Policy Constraints

Research Workflow (All Agents)

Standard 4-Step Pattern

1. Validate Prerequisites — Confirm previous artifact exists. If missing, STOP.
2. Read Agent Context — Read previous artifact for context. Read template for H2 structure.
3. Domain-Specific Research — Query ONLY for NEW information not in artifacts.
4. Confidence Gate (80% Rule) — Proceed at 80%+ confidence. Below 80%, ASK user.

Confidence Levels

Context Reuse Rules

• DO: Read previous agent's artifact for context
• DO: Cache shared defaults (read once per session)
• DO: Query external sources only for NEW information
• DON'T: Re-query Azure docs for resources already in artifacts
• DON'T: Search workspace repeatedly (context flows via artifacts)
• DON'T: Re-validate previous agent's work (trust artifact chain)

Agent-Specific Research Focus

Service Lifecycle Validation

AVM Default Trust

When using AVM modules with default SKU parameters:

• Trust the AVM default — Microsoft maintains these
• No additional deprecation research needed for defaults
• If overriding SKU parameter, run deprecation research

Deprecation Research (For Non-AVM or Custom SKUs)

Known Deprecation Patterns

What-If Deprecation Signals

Deploy agent should scan what-if output for: deprecated|sunset|end.of.life|no.longer.supported|classic.*not.*supported|retiring

If detected, STOP and report before deployment.

Template-First Output Rules

Mandatory Compliance

Output Location

All agent outputs go to agent-output/{project}/:

Header Format

# Step {N}: {Title} - {project-name}

> Generated by {agent} agent | {YYYY-MM-DD}

Validation Checklist

Before completing any agent task, verify:

• Output file saved to agent-output/{project}/
• All required H2 headings from template are present
• H2 headings match template text exactly
• All 4 required tags included in resource definitions
• Unique suffix used for globally unique names
• Security baseline settings applied
• Region defaults correct (swedencentral, or exception documented)
• Attribution header included with agent name and date