Update Landing Zone

Type: operation

Intent

The application team reshapes their landing zone on demand — within the boundaries the parameter file defines.

Design Decisions

Steps

  1. Read all design decisions in decisions[] to understand the constraints on tags, budget, and exemptions before proposing any change.
  2. Verify the landing zone exists: the bicepparam file at landing-zones/oases-{env}/oases-{appName}-{env}.bicepparam and the workflow at .github/workflows/lz-oasis-{appName}-{env}.yml — do not proceed if either is missing, this is a create-landing-zone task.
  3. Collect from the user the app/env to manage and which concern to change: cost, tags, or exemptions.
  4. Cost: edit the single `budget` value only. Do not add actual-spend or additional thresholds — the budget drives a single Forecasted alert.
  5. Tags: edit `subscriptionLevelTags` / `resourceLevelTags` keys and placement only. Keep ownerEmail and engineerEmail as readEnvironmentVariable references, never hardcoded values (landing-zone-tags, landing-zone-platform-members); keep ownerEmail at subscription level, never resource level.
  6. Exemptions: ask the user whether the exemption is temporary or long-lived. Temporary -> trigger lz-flow-create-policy-exemption (8-hour expiry, break-glass, no PR record). Long-lived -> add an entry to the `exemptions` array referencing a policy-assignment-reference.json key, never a hardcoded ARM assignment id (self-service-policy-exemptions, azure-policy-reference). defenderRecommendationExemptions and diagSettingsExemption remain platform-managed booleans.
  7. Present a complete draft of the bicepparam change before implementing.
  8. For declarative changes (cost, tags, long-lived exemptions) open a PR; the merge triggers lz-oasis-{appName}-{env}.yml, redeploying the landing zone stack with deleteAll. No portal or out-of-band edits (end-to-end-deployment).

Files

Violations

← Back to operations