Practical AZ-400 preparation should make DevOps decisions visible. The current Microsoft blueprint emphasizes build and release pipelines, but the role still connects source control, collaboration, security, infrastructure as code, deployment, observability, and feedback. A useful lab therefore produces evidence that a change can move from reviewed source to a healthy production state\u2014and can recover when something goes wrong.<\/p>\n
Use the Microsoft AZ-400 exam<\/a> as the target, but build your practice around systems rather than portal steps. Every exercise below should answer four questions: what requirement are you solving, what control enforces it, what evidence proves the result, and what recovery path exists if the change fails?<\/p>\n Create a small production repository and define the branch model, review requirements, protected paths, validation checks, and emergency-change process. Include one high-risk file such as deployment configuration or security policy and decide whether code owners, additional approval, or specialized validation should protect it.<\/p>\n Then test the policy. Attempt a direct change that should be blocked, submit a compliant pull request, and verify the audit trail. The goal is not to maximize controls; it is to make each rule traceable to a risk such as unreviewed production changes, lost accountability, or accidental bypass.<\/p>\n Start from reviewed source, restore dependencies, build the application, run tests, perform quality and security checks, and publish a versioned artifact. Record which commit produced the artifact and which checks were required before publication.<\/p>\n Break one dependency or test and confirm that the artifact is not promoted. Then fix the issue and rerun. This makes CI a quality boundary rather than a YAML exercise.<\/p>\n Build once, then promote the same tested artifact through development, test, and production. Keep environment-specific configuration outside the artifact so the binary or package being validated is the one that reaches production.<\/p>\n Add approvals or checks only where the risk justifies them. Introduce a failed production health check and decide whether to halt, roll back, or fix forward. The decision should follow recoverability and user impact, not a universal rule.<\/p>\n Create a deployment identity with intentionally broad access, prove what it can reach, and then reduce it to the minimum durable scope. Replace hard-coded credentials with a supported secret store, managed identity, workload identity federation, or scoped service connection where appropriate.<\/p>\n Test rotation or revocation and preserve evidence showing which principal performed the deployment. Security is stronger when the pipeline can operate without long-lived credentials that are difficult to track or revoke.<\/p>\n Implement or model the same deployment in both platforms. Compare runner or agent trust, environment protection, reusable definitions, artifact handling, identity, approvals, integration, and audit evidence. Do not decide that one platform is universally better.<\/p>\n The current AZ-400 role expects familiarity with both GitHub and Azure DevOps. The useful skill is recognizing which control or operating model satisfies the scenario. The AZ-400 source-control guide<\/a> can support that comparison.<\/p>\n Version an infrastructure definition beside the delivery workflow, validate it before deployment, and apply it to a small environment. Then change one resource manually outside the normal path.<\/p>\n Compare actual state with the versioned definition and decide how drift should be detected, approved, reconciled, or reversed. This exercise shows why infrastructure as code is an operating control: it makes intended state reviewable and reproducible.<\/p>\n Collect signals for pipeline failure rate, duration, deployment success, application health, latency, errors, and important infrastructure metrics. Deploy a deliberately faulty version and identify which signal detects the problem first.<\/p>\n Then follow the evidence to a decision. Monitoring is not complete because a dashboard exists; it is useful when a signal leads to remediation, rollback, capacity action, or investigation.<\/p>\n Break one dependency, revoke one deployment permission, introduce an unhealthy release, or create infrastructure drift. Diagnose the problem from logs, metrics, pipeline state, and configuration before changing anything.<\/p>\nExercise 1: design a repository and pull-request policy<\/h2>\n
Exercise 2: build a traceable continuous-integration pipeline<\/h2>\n
Exercise 3: promote one artifact through environments<\/h2>\n
Exercise 4: secure identities, secrets, and permissions<\/h2>\n
Exercise 5: compare GitHub Actions and Azure Pipelines<\/h2>\n
Exercise 6: deliver infrastructure as code and detect drift<\/h2>\n
Exercise 7: instrument the delivery system and workload<\/h2>\n
Exercise 8: create a controlled failure and recovery drill<\/h2>\n