certslothcertsloth
← AZ-400 overview

DevOps Engineer Expert / STUDY TOOLS

AZ-400 quick review

The Expert credential also requires a qualifying prerequisite certification. Azure Administrator Associate is a current route; check Microsoft’s credential page for the applicable prerequisite rules.

Memory hook: Trace a change; build once; promote with evidence.

Reviewed 10 October 2026. Read this once, then answer the last-pass checks without looking.

Scope/version: The Expert credential also requires a qualifying prerequisite certification. Azure Administrator Associate is a current route; check Microsoft’s credential page for the applicable prerequisite rules.

Must remember by domain

Domain Rapid revision
Processes Link requirement/work item → commit/PR → build/test → artifact → release/feedback. Lead time measures delivery elapsed time; deployment frequency, change failure rate and recovery time expose flow and reliability. Wikis/Markdown/Mermaid document intent; webhooks need authenticated, validated events.
Source control Short branches reduce divergence. PR policies enforce review/build checks. Merge joins history; rebase rewrites ancestry; squash combines commits. Revert records a reversal; reset moves a ref and can discard changes. Use LFS for suitable large assets; rotate exposed secrets before history cleanup.
Packages/testing Feeds, upstream sources and views govern distribution/promotion. Lock dependencies and pin immutable artifacts/actions. Unit, integration, end-to-end and load tests answer different questions; coverage alone does not prove assertions. Publish useful test results and meaningful quality gates.
Pipelines Stages contain jobs; jobs execute on agents; steps perform work. Azure template expressions ${{ }} expand before execution; runtime $[ ] and task macro $(name) operate at different times. Azure Pipelines YAML and GitHub Actions YAML are not interchangeable. Restrict template/task versions and variable/service-connection access.
Release/IaC Build once and promote the same artifact. Rolling replaces batches; blue/green switches environments; canary exposes a small population; feature flags separate deployment from exposure. Use expand → migrate → switch → contract for database changes. Bicep declares resources; configuration management handles supported guest state.
Operations Compare run duration, queue delay, concurrency, flaky failures, retention and cost. Hosted agents reduce maintenance; persistent self-hosted runners need isolation, patching and safe cleanup. Cache is a performance aid; an artifact is a release output.
Security Workload identity federation/OIDC avoids long-lived deployment secrets. Scope repository/environment trust and target RBAC separately. Key Vault retrieval, secure files and secret variables still need restricted execution. Never provide production credentials to untrusted PR code. Scan code, dependencies, secrets, images and licenses; preserve provenance/SBOM where required.
Instrumentation Correlate logs, metrics and distributed traces with release version. Alert on user-visible SLOs; include rollback criteria and business outcome checks. KQL helps isolate time ranges, deployment cohorts and failing dependencies.

Exam traps

Approval/checks should not be bypassable by the same untrusted code author. A signature proves artifact provenance, not benign source. A slot swap cannot undo dropped columns. An emergency hotfix still needs traceable artifact identity and essential validation. A variable available at runtime may not exist during template expansion.

Last-pass self-check

1. Shared bad commit already pulled by others: safe reversal?

Usually git revert, retaining shared history.

2. A secret was removed from the current file: is exposure fixed?

No. Revoke/rotate, investigate use, then address history and artifacts.

3. Canary and A/B: same purpose?

No. Canary controls release risk; A/B compares behavior/outcomes.

4. Build separately for production after testing staging?

Prefer promoting the identical tested artifact with environment configuration.

5. What must happen before a destructive schema contraction?

Compatible clients must be switched and rollback needs resolved.

Sources

Every topic at a glance

Open any topic to revisit its essential facts, decisions and exam traps. Use the full topic for active recall and supporting references.

01 · Git, Work Tracking and Feedback

Memory hook: Trace a business change from work item to commit, test, artifact and release.

Must remember

  • Choose trunk-based development, short feature branches or release branches according to release needs and team discipline. Long-lived branches increase divergence. Pull-request policies can require review, build validation, resolved conversations and protected merge rules.
  • A merge preserves branch integration history; rebase rewrites commit ancestry; squash produces a combined change. revert records an inverse commit; reset moves a local reference and can discard work depending on mode. Prefer shared-history-safe recovery when others already depend on commits.
  • Tags identify releases but can be moved unless protected. Git LFS stores large assets outside ordinary Git objects; repository scaling tools such as Scalar address large-repo workflows. Avoid committing generated archives, secrets or dependency caches by default.
  • Removing a secret from the latest file does not remove it from history or revoke it. Rotate/revoke first, then perform coordinated history cleanup where needed and inspect downstream artifacts/caches.
  • Azure Boards/GitHub Issues and Projects organise work; link changes to bugs, tests and deployments. Wikis, Markdown, Mermaid, API documentation and generated release notes improve review and handover. Webhooks/Teams integrations need scoped credentials, validated events and noise control.
  • Track lead time, cycle time, deployment frequency, failure rate and recovery time. Distinguish work-in-progress bottlenecks from individual output metrics. Feedback should lead to a testable improvement, not just a larger dashboard.

Choose under exam pressure

Requirement Choice and reason
Undo a published change without rewriting shared history Revert with a reviewed corrective commit.
Prevent unreviewed production changes Protected branch/PR rules and deployment controls.
Large binary assets repeatedly bloat clones Evaluate Git LFS and appropriate artifact storage.

Traps

  • A tag is not immutable unless protected.
  • Deleting a file does not revoke a leaked credential.
  • High deployment frequency alone does not prove reliability.

Practise this topic

02 · YAML Pipelines, Packages and Test Gates

Memory hook: An artifact should carry its identity and evidence from build to deployment.

Must remember

  • Azure Pipelines and GitHub Actions use different YAML schemas. Triggers, conditions, jobs, stages and dependencies determine execution. Distinguish compile/template-time expressions from runtime variables in Azure Pipelines; quoting a value does not necessarily make a secret safe.
  • In Azure Pipelines, ${{ }} expressions expand during template/plan construction and can use parameters; $[ ] expressions evaluate at runtime in their supported contexts; $(name) macro syntax resolves task variable values. A value first created by a running step cannot retroactively change an already-expanded template. Check expression phase and available context when a condition or variable is unexpectedly empty.
  • Hosted agents simplify maintenance; self-hosted agents need patching, tools, licences, network access and isolation. Never run untrusted code on a privileged persistent runner that holds production credentials. Parallelism reduces time only when dependencies, capacity and cost allow it.
  • Reuse templates/actions with version pinning and review. Variable groups centralise configuration; environment checks/approvals gate deployments. Service connections authorise target operations; a pipeline's existence does not grant access to every subscription.
  • Azure Artifacts/GitHub Packages provide package feeds. Upstream sources, views and permissions affect provenance and promotion. SemVer communicates compatibility; CalVer communicates release time. Lock dependencies and record immutable package/artifact versions.
  • Unit tests isolate logic; integration tests validate real contracts; end-to-end tests check useful outcomes; load tests assess capacity. Coverage measures execution, not assertion quality. Publish results and fail on meaningful quality/security gates rather than merely collecting reports.
  • Monitor duration, failures, flaky tests, queue delay, cache effectiveness and cost. Retain artifacts long enough for rollback/audit, with lifecycle policies for unused outputs. Migrate classic pipelines to YAML by preserving triggers, credentials, approvals and retention semantics, not only copying task names.

Choose under exam pressure

Requirement Choice and reason
Need reliable repeatable dependency installation Pinned versions/lockfiles and trusted package feeds.
Only production needs manual approval An environment approval/check at the deployment boundary.
Pipeline is slow but workers are idle Inspect dependency ordering and queue/serial bottlenecks.

Traps

  • Code coverage does not prove behaviour is correct.
  • An unpinned reusable action can change without your source changing.
  • A cache is an optimisation, not a trusted release artifact.

Practise this topic

03 · Progressive Delivery and Database Changes

Memory hook: Control exposure separately from deployment, and make rollback compatible with state.

Must remember

  • Rolling replaces instances in batches; blue/green maintains separate environments; canary exposes a small share first; rings expand by user/cohort; A/B testing compares behaviour. Choose with capacity, state, risk and rollback constraints.
  • Feature flags, including App Configuration feature-management capabilities, can decouple code deployment from feature exposure. Flags need owners, defaults, audit and retirement; they should not become permanent undocumented branches.
  • App Service slots provide eligible staging/swap behaviour; mark sticky settings and validate warmup. Container deployments need probes, compatible image versions and traffic policy. A green startup probe is not proof the business workflow works.
  • Database changes should support old/new code during the transition. Expand schema, migrate/backfill data, switch clients and contract only after rollback needs expire. A destructive column drop cannot be undone by redeploying the previous container.
  • IaC provisions infrastructure; configuration management maintains supported machine/application settings. ARM/Bicep, Machine Configuration, Automation State Configuration and Deployment Environments have different scope/ownership. Review dependencies and desired-state drift.
  • Hotfix paths should retain review, artifact identity, tests and audit while shortening unnecessary waiting. Define error-rate/latency/business-health gates and rollback actions. Capture incident feedback in tests/runbooks after recovery.

Choose under exam pressure

Requirement Choice and reason
Release code but enable it for only one cohort Feature flag/ring exposure.
Need rapid traffic rollback with spare capacity Blue/green or eligible slot swap.
Old and new app versions overlap Backward-compatible database migration sequencing.

Traps

  • A feature flag does not automatically secure the hidden endpoint.
  • Rollback of binaries does not reverse data mutation.
  • A canary without representative traffic is weak validation.

Practise this topic

04 · Pipeline Identity and Supply-Chain Security

Memory hook: A pipeline is a privileged workload; give it a narrow identity and inspect what it consumes.

Must remember

  • Prefer workload identity federation/OIDC or managed identities for supported secretless authentication. Entra service principals, GitHub Apps, GITHUB_TOKEN, PATs and Azure DevOps service connections have different scopes and lifecycles. Restrict audiences, repositories/branches/environments and role assignments.
  • Use Key Vault for supported secrets/keys/certificates and controlled runtime retrieval. Secure files/secret variables still need restricted access; masking is not a complete defence against transformed or intentionally exfiltrated values. Never expose secrets to untrusted PR code.
  • GitHub/Azure DevOps organisations, projects, teams and repositories have their own roles/access levels. Azure RBAC is a separate target permission system. Review outside collaborators, stakeholder access, token expiry and who can edit a privileged pipeline.
  • Scan code, dependencies, secrets, licences and container images. CodeQL/static analysis, Dependabot and GitHub Advanced Security capabilities detect different risks. Defender for Cloud DevOps security connects supported posture evidence; a finding needs triage and remediation ownership.
  • Pin third-party actions/tasks/dependencies, verify provenance and maintain a software inventory/SBOM where required. Use trusted feeds and least-privilege package publication. A build from compromised source can produce a correctly signed malicious artifact.
  • Protect approvals, branch policies and service-connection use from the same untrusted author controlling the build. Log administrative changes, rotate exposed credentials and retain evidence. Separate security policy from application-controlled YAML when the platform supports it.

Choose under exam pressure

Requirement Choice and reason
Avoid storing a deployment secret Supported OIDC/workload identity federation with constrained trust.
Detect a vulnerable transitive dependency Dependency scanning and update review.
Control which pipeline can use production credentials Service-connection/environment permissions and protected configuration.

Traps

  • Log masking is not secret isolation.
  • A signature proves provenance under a key, not benign behaviour.
  • A pipeline editor may effectively control its deployed identity unless boundaries prevent it.

Practise this topic

05 · ARM Templates and Bicep

Memory hook: Declare the desired resources, inspect the proposed change and preserve clear ownership.

Must remember

  • ARM templates are declarative JSON; Bicep offers a concise language that compiles to ARM deployments. Parameters supply inputs, variables simplify expressions, resources declare objects, modules group reusable declarations and outputs expose selected results.
  • A resource reference can establish an implicit dependency; explicit dependsOn is for dependencies not already expressed. Deployment ordering does not prove application readiness. Existing-resource declarations reference objects without necessarily taking over their full lifecycle.
  • Use parameter files and secure parameters for sensitive inputs, but remember that secrets can still leak through outputs, logs or resource properties. Prefer managed identities and Key Vault references where supported.
  • what-if previews supported changes; template validation checks syntax/configuration within its scope. Neither proves a deployment will have quota, permissions or a functioning application. Check incremental versus deletion behaviour and use deployment stacks or supported lifecycle controls deliberately.
  • Exported templates are a starting point, not always a complete reusable description of every deployed feature. Bicep decompilation may need repair/refactoring. Review API versions, unique names, dependencies, region support and hard-coded IDs.
  • Deploy at the scope the resource type supports: resource group, subscription, management group or tenant. The deployer needs the required resource/deployment permissions; a reusable module does not grant them. Inspect deployment operations for the first relevant failure before retrying.

Choose under exam pressure

Requirement Choice and reason
Reusable network deployment across environments Bicep module with validated parameters.
See what an update may change ARM/Bicep what-if plus review.
Secret needed at runtime Managed identity and a supported secret-reference pattern.

Traps

  • An exported template can omit unsupported state.
  • A successful what-if is not a guarantee of apply success.
  • A secret marked secure can still be leaked by unsafe output use.

Practise this topic

06 · Azure Monitor, Logs and Alerts

Memory hook: Metrics quantify, logs explain, traces connect and alerts start a response.

Must remember

  • Azure Monitor combines metrics and logs; Log Analytics workspaces hold queryable log data. Activity Log records management-plane events; resource/application logs require relevant collection configuration. Diagnostic settings route supported categories to selected destinations.
  • Azure Monitor Agent uses data collection rules for supported guest telemetry. VM, Storage and Network Insights provide focused views; Application Insights adds application performance and tracing with suitable instrumentation. Guest memory/disk metrics are not automatically identical to platform metrics.
  • KQL pipelines transform tables: where filters, project selects columns, summarize aggregates, bin() groups time intervals, and joins combine data. Example: Heartbeat | summarize LastSeen=max(TimeGenerated) by Computer finds each computer's latest recorded heartbeat; absence can mean collection failure, not only host failure.
  • Alert rules define signal, scope, evaluation and condition. Action groups define notifications/actions. Alert processing rules modify processing such as suppression under selected conditions; they do not change the source telemetry. Use dynamic thresholds where appropriate and test missing-data behaviour.
  • Network Watcher and Connection Monitor help inspect path and connectivity. Logs, effective routes/rules and an application test answer different questions. Narrow time windows and correlation IDs reduce noise; retention and ingestion volume affect cost.
  • Monitor the collection pipeline itself. Permissions, network access, workspace configuration and data collection rules can break visibility. Avoid logging secrets and unnecessary personal data, and define retention according to operational/evidence requirements.

Choose under exam pressure

Requirement Choice and reason
Who changed an Azure resource? Activity Log and relevant audit evidence.
Notify an operations group on a metric breach Alert rule linked to an action group.
Investigate recurring connection failures Connection Monitor plus route, rule and application evidence.

Traps

  • No logs can mean no collection.
  • Action groups do not define the alert threshold.
  • Average response time can conceal severe tail latency.

Practise this topic

Search across every published topic.