Development and Deployment: Pipelines, Small Batches, and Safe Releases
The Development and Deployment domain tests continuous integration, continuous delivery, automated testing, version control, deployment pipelines, and release techniques. The exam distinguishes deployment from release and expects designs that keep software deployable while limiting blast radius.
Core rules
- Keep everything in version control: code, tests, configuration, infrastructure definitions, and pipeline definitions. The mainline is the single source of truth.
- Prefer trunk-based development with short-lived branches and feature flags. Long-lived branches create integration debt and late feedback.
- Continuous integration means every change triggers build and automated tests on a shared mainline, with fast feedback. A nightly build is not CI.
- Build the artifact once and promote the same artifact through environments. Rebuilding per environment introduces untested differences.
- Use a deployment pipeline with staged quality gates: commit build, unit and contract tests, integration tests, security checks, staging verification, and production release.
- Separate deploy from release. Blue-green, canary, and feature flags reduce risk; rollback must be rehearsed. Database changes should use backward-compatible expand-contract migrations.
- Continuous delivery keeps every change deployable; continuous deployment automatically releases every change that passes the pipeline. They are not the same.
Worked example
A 60-developer e-commerce team uses three-week feature branches and rebuilds per environment. Integration failures appear late. The team moves to trunk-based development with feature flags, builds one immutable artifact, and runs a pipeline: commit build, unit and contract tests, deploy to test, integration and end-to-end tests, staging, then a 5% production canary. A failed canary triggers automatic rollback. Reasoning: smaller batches and one artifact reduce integration risk, while the canary limits blast radius. The team starts with continuous delivery before considering continuous deployment.
Traps that cost marks
- Calling a nightly build "continuous integration" or running CI only on a branch.
- Rebuilding the same commit separately for each environment.
- Relying on a manual QA gate as the only quality control.
- Keeping long-lived feature branches and merging rarely.
- Claiming continuous deployment while releasing monthly, or releasing without rollback and database compatibility plans.
Operation and Scaling: Feedback, Reliability, and Enterprise Spread
The Operation and Scaling domain tests how teams run and learn from production, and how DevOps spreads beyond a pilot. Expect questions on observability, SLOs, incident response, blameless postmortems, platform teams, and scaling mechanisms that preserve autonomy.
Core rules
- Operations is part of the feedback loop. Instrument services with logs, metrics, and traces, and monitor user-facing behavior, not only server health.
- Define SLIs and SLOs, and use error budgets to balance reliability work with change. An error budget policy makes the trade-off explicit before an incident.
- Prepare incident response: clear roles, escalation paths, runbooks, communication, and on-call rotation. During an incident, restore service first and investigate causes afterward.
- Conduct blameless postmortems that identify contributing conditions and assign owned, tracked actions. A report without follow-through is not learning.
- Scale with a platform team and a paved road: self-service, guardrails, templates, and supported tooling that reduce cognitive load without becoming a gatekeeper.
- Use communities of practice, internal open source, and federated governance to spread practices. Autonomy with alignment works better than mandated uniformity.
- Measure scaling by adoption and outcomes, not by the number of teams forced onto a tool.
Worked example
A company grows from 2 to 20 teams. Central operations becomes a ticket bottleneck. It creates a platform team that offers self-service pipelines, observability templates, and an SLO template with guardrails. Each product team owns its services and on-call; the platform team publishes a paved road and office hours. Incident reviews are blameless, and error-budget breaches trigger a reliability review. Reasoning: scaling required removing the central gate while making the right path easy. Adoption is tracked by teams using the paved road and by service reliability trends.
Traps that cost marks
- Blaming individuals after incidents, which suppresses reporting and hides systemic causes.
- Monitoring only infrastructure while ignoring user journeys and SLOs.
- Writing postmortems with no owner, deadline, or verification of actions.
- Scaling by mandate and turning the platform team into a new approval bottleneck.
- Assuming operations alone owns reliability; product teams must own their services in production.