Quartz 5

Lab: AZ-400 end-to-end delivery challenge

Properties1
tagslab, az-400, integrated, devops, delivery

3 min read

Lab: AZ-400 end-to-end delivery challenge

Outcome

Take one safe training change from a tracked work item through pull request, validated pipeline, immutable artifact, governed deployment, security gate, and production-style telemetry. This is the course synthesis challenge.

Before you begin

Use a personal GitHub/Azure DevOps training project and an Azure training subscription only if you are authorized and have a cost limit. Use a sample application and fake/test secrets only. Read the cleanup section before creating resources.

Scenario

The product team wants a new feature released progressively. The platform team requires traceability, protected default branch, YAML CI, reproducible artifacts, least-privilege Azure deployment, a production approval, security scanning, and a measurable feedback signal.

Do

  1. Create an issue/work item with acceptance criteria, rollout metric, rollback trigger, and a reference ID.
  2. Create a short-lived branch, implement a small safe feature behind a feature flag, and open a pull request that links the work item.
  3. Build CI in either GitHub Actions or Azure Pipelines: lint/unit test, a structured test result, security/dependency check, immutable versioned artifact, and pull-request trigger.
  4. Protect the default branch with required review and required checks. Deliberately fail one safe test/scanner fixture and show that merge is blocked.
  5. Define training infrastructure as code. Add a preview/what-if stage and deploy through a scoped, preferably federated identity—not a stored subscription Owner credential.
  6. Deploy the artifact to a protected training environment. Require an approval/check, record the artifact version and deployment evidence, and use an idempotent deployment path.
  7. Emit one feature-use event and a health/availability signal. Create an alert/action group and a dashboard/query that compares the flagged cohort or deployment version with expected behavior.
  8. Update the work item and release note with the deployed version, environment, evidence, and rollout decision.

Verify

Produce an evidence chain that another person can follow without oral context:

  1. Work item → branch/PR → code review/checks.
  2. Pipeline run → test/security evidence → immutable artifact version.
  3. IaC preview → deployment identity/scope → environment approval.
  4. Deployment version → telemetry/alert → follow-up work or rollout decision.

Break and fix

  1. Introduce a safe test or scanner finding; prove branch protection blocks merge, then remediate it.
  2. Attempt deployment with the environment approval ungranted; record the pause/rejection, then complete authorized approval.
  3. Toggle the feature flag or use a controlled failing route. Verify the telemetry/alert signal and document whether you roll forward, roll back, or stop exposure.
  4. Re-run the deployment. Prove that it converges without unintended duplicate resources or release drift.

Clean up

Disable or delete the training feature flag, alert/action group, environment, service connections/role assignments, training IaC resources, artifacts, repositories, and test identities when they are no longer needed. Confirm no production access or billable resource remains.

Reflection

Explain the difference among a branch-protection check, a security gate, an environment approval, a service-connection role assignment, a feature flag, and an alert. Each is a control at a different point in the delivery system.

Sources and re-audit

Re-audit when branch protection, pipeline identity federation, deployment environments, feature flags, or telemetry alerting changes.

Processes and communications · CI · Release strategy · Security · Feedback · All labs

Graph View

Backlinks