deny-by-default — Every resource type is denied until the platform has security controls and observability wired. Approval is the platform's commitment, not a task left to the application team.
landing-zone-self-service — Self-service, self-contained landing zones. The application team owns it end-to-end — what they build and how they run it is their call.
no-human-touch — Configuration has one source of truth: the repo. Every change flows through a branch, a PR, and a pipeline. Nothing is set manually.
zero-cost-on-idle — Platform-managed infrastructure carries no flat fees. Every service the platform provisions scales to zero when idle — fixed monthly costs are eliminated by design.
Decisions
application-teams-own-the-cost — Each application has its own billing scope; every subscription it provisions bills to it exclusively.
azure-policy-allowed-resources — Every resource is denied by default. It appears on the allowed list only after the platform has approved it.
azure-policy-custom-definition — When no built-in policy provides the required Deny or DeployIfNotExists effect, a custom definition is authored to close the gap.
azure-policy-reference — Policy exemptions source assignment IDs from the generated reference file.
branch-gated-environment-promotion — Every platform production deployment passes through a test environment first. This is enforced by branch protection rules and workflow structure.
config-lives-in-the-repo — Configuration has one committed source of truth — a single JSON file in the repo. Values are propagated to GitHub variables and Bicep parameters at deployment time. Nothing is set manually in the UI or injected out of band.
declarative-resource-lifecycle — What's in the code is what exists in Azure — Azure Deployment Stacks delete anything removed from the template on the next deployment.
deny-security-controls — Azure Policy enforces hard denies on public network access, local authentication, minimum TLS, and cross-tenant replication, on every resource type that supports them.
deployment-logic-reusable-workflow — Deployment logic is written once in reusable workflows — each environment only controls when to run it.
end-to-end-deployment — Each platform concern (policy, access control, management groups) owns its Bicep and workflows end-to-end.
initial-setup — The platform has a one-time manual setup process to configure the Azure management group hierarchy and billing, Entra ID authentication, and the GitHub organization.
ipam — When a new landing zone is requested, the GitHub workflow queries Azure Resource Graph and finds the next free VNet address space. The address space is written to a landing zone parameter file.
job-function-scoped-roles — Roles are scoped to a job function. A role describes what a person does (e.g., app engineer), not what resources they touch.
landing-zone-action-group — Platform-managed notifications are scoped to the action group and target the landing zone's engineers.
landing-zone-allowed-public-ip — The platform provides an approved public IP address, so getting-started deployment pipelines can enable/disable network access to Azure resources.
landing-zone-application-profile — Registering an Application Profile is how an application joins the platform and gains the ability to provision its own landing zones.
landing-zone-automation — Each landing zone has automation runtime running inside its own subscription — job definitions and images are centrally managed by the platform, but execution happens locally.
landing-zone-diagnostic-settings — Every whitelisted resource type has diagnostic settings deployed automatically via DeployIfNotExists policy. Telemetry flows to the landing zone's Log Analytics workspace with no team action required.
landing-zone-getting-started — The template provides a minimal example to manage resources in Azure using the same principles as the platform itself.
landing-zone-github-runners — The platform provisions a delegated subnet for GitHub-hosted runners within the landing zone VNet.
landing-zone-identity — Each landing zone has a single managed identity that serves all its capabilities — GitHub workflows, automation jobs, and Entra ID queries.
landing-zone-lifecycle — Landing zone provisioning draws from a subscription bank, returning the subscription to it when the landing zone is sunset.
landing-zone-monitoring — The platform configures a Log Analytics workspace per landing zone, with retention set to stay within the free SKU.
landing-zone-repo — Each application gets a GitHub repository that serves as the control and deployment plane for all its landing zones
landing-zone-resource-group — Platform-managed landing zone resources live in a single resource group, protected by an Azure Deployment Stack.
landing-zone-tags — The platform configures tags to identify application engineers and owners.
landing-zone-template — Landing zones are stamped from a single shared template, but each is managed through its own dedicated parameter file and workflow.
landing-zone-vnet — Each landing zone gets an isolated VNet, with no connectivity to other landing zones or on-premises networks.
platform-exemptions-automation — The platform uses GitHub Container Registry as the shared image source for all automation jobs across all landing zones.
platform-identity-azure — Entra ID app registration serves as the platform identity, used to provision and configure both the platform and its landing zones.
platform-identity-github — All platform and landing zone workflows authenticate to GitHub using a single, shared GitHub App identity.
platform-identity-graph — Landing zone-managed identities receive Microsoft Graph permissions, allowing them to query Entra ID objects.
platform-test-environment — Every platform change is validated in a test environment before it reaches production.
self-service-policy-exemptions — Application teams can request a temporary or long-lived exemption from a specific Azure Policy assignment via a self-service workflow.
single-region — All landing zones deploy to a single region — the platform guarantees service parity by eliminating regional variation.