Prepare. Deploy separately. Keep release authority independent.

Path A: reviewed readiness package, platform-owned deployment

1. Submit a publication request in the hub. A maintainer reviews and authorizes the exact solution repository.
2. Work the stable parent/control issues there: roles, prerequisites, steps, evidence examples, and guide links are included.
3. Complete controls with safe evidence links; validate the original request. Checks bind to the default-branch commit and fail if it changes during validation. FAIL and UNKNOWN block readiness.
4. Use the commit-bound handoff package for named governance review and separate platform acceptance. Both decisions remain pending until humans record them.
5. The platform team independently deploys through protected release controls. Changed scope, evidence/commit, policy, or expired exceptions require fresh review.

Prepared, Reviewed, and Accepted are distinct stages, never inferred from labels. Labels are advisory, not release authorization.

A Low tier is not an exemption: it still requires every applicable baseline control and evidence review. Marking an environment prod is human context, not an automatic tier change; platform owners must still verify production identity, network, data, monitoring, rollback, and release protections.

The automation cannot prove live Azure identity, network, data handling, alert remediation, evidence quality, or deployment. Reviewers must verify those with the responsible owners. Reviewer responsibilities · Reassessment, exception, and retirement routing.

Path B: Azure deployment starter references

These examples are deliberately incomplete, non-production, and not connected to an executable deployment workflow. They are prompts for a customer platform team to design its own solution. Do not paste real tenant, subscription, client, or resource identifiers into the public example.

Identity and trust boundary

• Use a separately governed deployment identity with the smallest resource scope. Prefer workload identity federation over a stored client secret when supported by the organization.
• Constrain federation to the intended repository and protected environment/branch claims. Verify the effective subject, issuer, and audience in the actual issued token and Azure trust configuration; do not infer trust from YAML text.
• Keep the CI identity distinct from the application's runtime identity. Grant the runtime identity only required data/service permissions; store unavoidable runtime secrets in an approved vault.
• Require protected-environment review and branch policy before production credentials become available. Keep break-glass access separately governed and audited.

Service selection questions

Choose a hosting service only after documenting workload shape, network/data requirements, region, scale, supported runtime, identity features, availability objectives, and the platform team's operating model. A simple web/API workload may fit a managed web or container service; event-driven workloads may fit a serverless service. Validate current feature and regional availability with Azure documentation and the landing-zone owner before deciding.

Illustrative fragments — not deployable

# PSEUDOCODE ONLY — complete these checks in your approved platform repository.
deployment_identity:
  federation_subject: <exact-reviewed-repository-and-protected-environment-claim>
  permissions: <minimum-resource-scope-approved-by-cloud-owner>
runtime_identity:
  permissions: <separate-minimum-data-and-service-access>
production_environment:
  reviewers: <independent-authorized-team>
  bypass: <disabled-or-explicitly-governed>
rollback:
  artifact: <previous-reviewed-immutable-artifact>
  owner: <named-platform-team-alias>

# INCOMPLETE PIPELINE OUTLINE — no triggers, actions, credentials, or deploy command.
permissions:
  contents: read
  id-token: write
jobs:
  validate:
    # Build/test a reviewed commit and publish an immutable artifact.
  production:
    # Require a protected environment; re-check evidence and exact commit.
    # Authenticate using the reviewed federated identity only after approval.
    # Deploy, verify health, and execute the documented rollback if needed.

// BICEP MODULE CALL FRAGMENT — intentionally non-deployable.
// The referenced reviewed module is not included in this repository.
module workload './modules/approved-workload.bicep' = {
  name: 'workload'
  params: {
    region: '<platform-approved-region>'
    runtimeIdentityResourceId: '<separately-reviewed-runtime-identity>'
    publicIngress: false
    diagnosticsWorkspaceId: '<approved-monitoring-workspace>'
  }
}

The placeholders are not resource IDs, the module file is deliberately absent, and no deployment workflow or Bicep deployment command is supplied. A platform owner must provide a reviewed module that enforces the approved network, identity, diagnostics, retention, and cost baseline.

Prerequisites, cost, and rollback ownership

• Prerequisites: approved Azure landing zone, subscription/resource-group ownership, region/data policy, network design, identity registration/federation, security baseline, monitoring, backup and incident contacts.
• Cost: estimate hosting, compute/scale, storage, network egress, logs/retention, security features, backup/replication, and model/API consumption where applicable. Confirm billing dimensions, quotas, alert thresholds, and who responds. Budgets/alerts may notify rather than hard-stop spend; verify service-specific controls and current pricing.
• Rollback: platform owner defines the immutable previous artifact/configuration, data/schema compatibility, rollback trigger, recovery objective, verification steps, and decision authority. Practice in non-production; application/data owners assess irreversible changes.

Reference boundaries: Azure identity and deployment conversation. This repository does not create Azure resources or validate their live state.

Path C: protected release integration

Use this design when a customer release service consumes readiness evidence. Keep the release decision inside an independently protected system, not a GitHub issue label or a generated comment.

Threats and required release controls

This is a design checklist, not a supplied policy engine. Threat-model, independently review, and test any implementation, including state changes between checking and using evidence (a time-of-check/time-of-use race).