← Back to Learning Portal

AZ-400 Study Manual

Study book covering DevOps processes, source control, CI/CD, security, and SRE.

11. AZ-400 Study Book

Chapter 1: Processes and Communication in DevOps

DevOps is not a toolset. It is an operating model for delivering value safely and repeatedly. In AZ-400 scenarios, this appears as decisions about team flow, visibility, and coordination between development, operations, security, and reliability teams.

What matters in the exam

  • Traceability from idea to release
  • Short feedback loops
  • Role clarity and approval ownership
  • Metrics that drive decisions, not dashboards that look impressive

Practical model

Use this chain in your thinking:

Work item -> commit -> pull request -> build -> artefact -> deployment -> telemetry -> retrospective action.

If a scenario breaks this chain, you usually need better integration between Azure Boards, Repos, Pipelines, and monitoring.

Common wrong decision

Teams track activity metrics only, such as number of commits. AZ-400 usually prefers outcome metrics: deployment frequency, change failure rate, MTTR, and SLO performance.

Quick check

If a release fails, can you identify exactly which work item and commit introduced it within minutes? If not, your communication and traceability design is weak.

Chapter 2: Source Control Strategy

Source control strategy is about risk management, not just branch names. The exam tests whether your branching and PR policies support both speed and quality.

Trunk-based vs GitFlow

  • Trunk-based: best for high-frequency integration and continuous delivery.
  • GitFlow: useful where release management is heavy and cadence is lower.

In many AZ-400 questions, trunk-based with strong PR governance is the expected modern choice.

Pull request controls you should know

  • Required reviewers
  • Build validation must pass
  • Comment resolution required
  • Linked work item required
  • Protected main branch

Why this matters

Without enforced PR checks, quality depends on personal discipline. AZ-400 answers favour enforceable controls.

Exam trap

A scenario asks for speed and governance. Wrong options often remove PR gates for speed. Correct options keep automation and controls while reducing manual friction.

Chapter 3: Continuous Integration

Continuous Integration is the highest-value AZ-400 area. Focus here first.

Core CI principles

  1. 1. Build once.
  2. 2. Run tests early.
  3. 3. Enforce quality gates.
  4. 4. Publish immutable artefacts.
  5. 5. Keep pipeline logic reusable.

Pipeline design rules

  • Use YAML templates for repeated logic.
  • Parameterise service-specific differences.
  • Pin dependency versions for reproducibility.
  • Cache deterministically using lockfile signals.

Agent and pool strategy

  • Microsoft-hosted agents: fast setup and lower maintenance.
  • Self-hosted agents: needed for custom dependencies, private networking, or compliance requirements.

Typical scenario logic

If a team has 12 services with duplicated pipelines, the right move is template modularisation. If build time is too slow, parallelise independent jobs before reducing test quality.

Exam trap

Options that improve speed by skipping security scans or tests are usually wrong.

Chapter 4: Continuous Delivery and Release Strategy

CD decisions in AZ-400 are driven by risk, rollback speed, and service criticality.

Deployment strategies

  • Blue/green: fastest rollback through traffic switch.
  • Canary: gradual exposure with telemetry-based promotion.
  • Ring-based rollout: phased adoption by user cohorts.
  • Feature flags: separate release from exposure.

Promotion criteria

Promotion should depend on measurable health gates:

  • Error rate
  • Latency
  • Availability SLI
  • Business KPI where relevant

Rollback design

A robust rollback plan includes:

  • Trigger thresholds
  • Ownership
  • Execution sequence
  • Verification steps

Exam trap

"Proceed because tests passed" is not enough in production rollout scenarios. Health and SLO signals must remain stable.

Chapter 5: Security and Compliance in DevOps

Security is not an optional report at the end of the pipeline. It must be enforced in the delivery path.

DevSecOps baseline

  • Dependency scanning in CI
  • Secret scanning in CI
  • Mandatory fail thresholds for severe findings
  • Runtime secret retrieval from secure store
  • Immutable logs for approvals and policy gates

Compliance evidence chain

Good evidence is automatic, immutable, and identity-bound.

Bad evidence is manual screenshots and ad hoc sign-off emails.

Identity and access

Use least privilege identities per stage/environment. Avoid shared admin credentials.

Exam trap

A frequent wrong option is "run scan and notify team" without a gate that blocks unsafe promotion.

Chapter 6: Instrumentation Strategy

Instrumentation answers two questions:

  1. 1. Is the service healthy for users?
  2. 2. Did the latest release improve or degrade outcomes?

Telemetry essentials

  • Metrics for trend and thresholds
  • Logs for detailed diagnostics
  • Traces for distributed request paths
  • Release annotations to correlate changes with incidents

Useful release metrics

  • Deployment frequency
  • Change failure rate
  • Lead time for changes
  • MTTR

Alerting principle

Alert only when action is required. Actionless alerts create fatigue and slower response.

Chapter 7: SRE Strategy for DevOps Engineers

SRE provides the operating guardrails for release velocity.

SLI, SLO, error budget

  • SLI: measurable indicator of service behaviour
  • SLO: target for that indicator
  • Error budget: acceptable unreliability before release pace must slow

Operational loop

Detect -> triage -> mitigate -> recover -> review -> improve.

Exam trap

Treating SRE as dashboard creation only. Correct answers connect reliability policy to release decisions.

Chapter 8: Infrastructure as Code and Configuration

IaC is about consistency and repeatability. In AZ-400, this is often tested through drift and promotion decisions.

What to apply

  • Declarative templates (ARM/Bicep)
  • Reviewed changes via PR
  • Plan/what-if before apply
  • Drift detection
  • Versioned modules

Configuration management

Externalise app configuration and secrets. Keep environment-specific settings out of code.

Exam trap

Manual portal edits to fix urgent issues can solve today but create long-term drift and audit risk.

Chapter 9: How to Answer AZ-400 Scenario Questions

Use this sequence every time:

  1. 1. Extract constraints: speed, risk, compliance, reliability.
  2. 2. Remove options that are manual, untraceable, or high-blast-radius.
  3. 3. Prefer automated gates, measurable health checks, and rollback readiness.
  4. 4. Choose the option with stronger governance and operational resilience.

If two options seem correct

Pick the one that scales, is auditable, and has clearer failure handling.

Chapter 10: Final Week Readiness

You are ready to sit when:

  • You consistently score above 80% on scenario sets.
  • You can explain why wrong options are wrong.
  • You can design rollback logic for any release strategy scenario.
  • You can map incidents back to release evidence quickly.

Final focus areas:

  • Build/release pipelines (highest weight)
  • Source control governance
  • Security gate enforcement
  • Telemetry-informed release decisions

This is what gets you through AZ-400 on the first attempt with confidence.