update-landing-zone

Type: regulative

Decision

A landing zone must be reshaped by editing its parameter file and merging a pull request, which redeploys the stack.

Why

An out-of-band edit is removed on the next deployment, because the stack deletes what the code no longer declares.

Violations

• Budget, tag, or exemption changed in the portal instead of the parameter file.
• Exemption entry naming a literal ARM assignment ID.

Anchor

no-platform-ops

Implements

• landing-zone

Steps

1. Read the rules this process is governed by, to understand the constraints on tags, budget, and exemptions.
2. Verify the landing zone exists: the bicepparam file and the lz-oasis-{appName}-{env} workflow. If either is missing this is a create-landing-zone task.
3. Collect from the user the app and environment to manage, and which concern to change: cost, tags, or exemptions.
4. Cost: edit the single budget value. The budget drives one forecasted alert, so additional thresholds are out of scope.
5. Tags: edit subscriptionLevelTags and resourceLevelTags keys and placement. Keep ownerEmail and engineerEmail as readEnvironmentVariable references, and keep ownerEmail at subscription level.
6. Exemptions: ask whether the exemption is temporary or long-lived. Temporary triggers lz-flow-create-policy-exemption with an 8-hour expiry. Long-lived adds an entry to the exemptions array referencing a policy-assignment-reference.json key.
7. Present a complete draft of the bicepparam change before implementing.
8. Open a pull request. The merge redeploys the landing zone stack with deleteAll.

Files

• landing-zones/oases-prod/
• landing-zones/oases-test/
• .github/workflows/lz-flow-create-policy-exemption.yml

Links

• create-landing-zone (depends-on) — There is no parameter file to edit until the landing zone has been provisioned.
• azure-policy-reference (governed-by)
• landing-zone-tags (governed-by)
• deployment-declarative-lifecycle (governed-by)

← Back to knowledge graph