DevOps Automation and Tooling
Domain 3 - DevOps Automation and Tooling
This domain tests whether you can design an automated path from commit to production and avoid tooling that automates waste. Expect questions about deployment pipelines, continuous integration, infrastructure as code, test automation, and secure configuration.
Automation scope
Automate repetitive, error-prone, and high-friction steps first: build, test, provisioning, deployment, and verification. Do not automate a step that should be eliminated; map the value stream before choosing tools. Tools must integrate so a change produces one traceable pipeline result.
Pipeline and integration rules
- Model the deployment pipeline as the automated form of the value stream: build, test, package, provision, deploy, verify.
- Build once, deploy many. Store versioned artifacts and promote the same artifact through environments.
- Use trunk-based development with short-lived branches and merge at least daily; run automated tests on every change.
- Test in layers: unit, integration, contract, acceptance, performance, and security; keep the suite fast enough for feedback.
- Treat infrastructure as code: idempotent, version-controlled, reviewed, and tested. Prefer immutable images and environment parity to configuration drift.
- Manage secrets outside code and inject them at runtime.
Worked example
A team builds manually on developer laptops, deploys to a shared server, and suffers environment drift. Design: commit triggers CI, which compiles and runs unit and contract tests, then stores an artifact. A pipeline provisions an ephemeral environment from code, deploys the artifact, runs acceptance tests, and promotes to production behind a feature flag. Reasoning: the pipeline removes handoffs and makes the environment reproducible; the same artifact prevents works-on-my-machine failures; the flag separates deploy from release.
Traps that cost marks
- Automating a manual process without removing unnecessary approval queues.
- Calling a build server CI when there is no automated test or daily merge.
- Using configuration scripts that are not idempotent.
- Hard-coding secrets or environment-specific values in artifacts.
- Buying a toolchain before defining the value stream and feedback needs.
- Treating infrastructure as code as a one-time script rather than a maintained product.