DevOps Engineering common mistakes
DevOps Engineering · Understand the traps and how to avoid them.
Treating a pipeline stage as a single opaque step and being unable to say what happens when a stage fails midway (e.g., whether artifacts from a failed build are promoted, whether downstream jobs are skipped or blocked).
Candidates memorize tool-specific YAML syntax but never model the pipeline as a dependency graph with artifact and gate semantics, so they can't reason about partial failure, retries, or promotion rules.
What to do instead
For each pipeline you build or study, draw the DAG explicitly: stages, artifacts produced/consumed, gates, and failure behavior per edge. Practice predicting outcomes of a mid-stage failure and what must be idempotent on retry.
Confusing build-once/deploy-many with rebuilding per environment, and choosing the wrong artifact promotion strategy when asked to design a release flow.
The phrase is repeated so often it gets recited without being connected to concrete mechanics like immutable image digests, environment-specific config injection, and provenance of the deployed artifact.
What to do instead
Practice explaining, in mechanism terms, how a single immutable artifact (e.g., image by digest) moves through environments with config externalized; contrast with rebuild-per-env and state the failure modes (drift, untested bits in prod).
Writing or evaluating Terraform/CloudFormation that mutates remote state or real infrastructure without planning, and being unable to explain what `plan` output implies for destructive changes.
Hands-on habits from tutorials skip the plan-review step, and candidates underestimate how state, drift, and resource replacement (force-new attributes) drive risk.
What to do instead
Always reason through plan output: which resources are create/replace/destroy, why replacement happens, and how state locking and remote backends prevent concurrent corruption. Practice reading plan diffs and predicting blast radius before apply.
Treating configuration management as imperative scripting and missing idempotency, convergence, and drift correction in answers about Ansible/Chef/Puppet.
Candidates equate 'automation' with 'running commands', so they propose shell loops instead of declarative resources and can't explain why re-running should be safe.
What to do instead
Frame every config task as desired state: resource declaration, idempotent application, and drift detection/remediation. Be ready to explain why a second run reports no changes and how ordering/handlers work.
Designing cloud architectures that ignore failure domains and cost/limits, e.g., single-AZ deployments for HA workloads or unbounded autoscaling without quotas and budget guardrails.
Study material focuses on service features, so candidates pick services by name recognition rather than by availability, scaling, and cost trade-offs.
What to do instead
For any design, state the failure domain (AZ/region), the scaling trigger and cap, and the cost/limit guardrail. Practice mapping requirements (RTO/RPO, traffic shape) to concrete multi-AZ, quota-aware choices.
Confusing container image build concerns with runtime orchestration concerns-e.g., blaming Kubernetes for problems caused by a mutable `latest` tag or a bloated, root-running image.
The container and orchestration layers are taught together, so candidates blur where a fix belongs and give answers at the wrong layer.
What to do instead
Separate the layers explicitly: image (base, layers, tags, user, healthcheck) vs. orchestration (scheduling, probes, resource requests/limits, rollout strategy). For each symptom, name the correct layer and the concrete fix there.
Answering SRE questions with tool names instead of the reasoning loop-no SLI/SLO definition, no error budget math, and alerting on causes rather than symptoms.
Candidates memorize dashboards and products but skip the measurement model, so they can't connect reliability targets to release and on-call decisions.
What to do instead
Practice defining SLIs (what you measure), SLOs (target over a window), and error budgets (allowed failure). Derive burn-rate alerts from those and explain how budget exhaustion changes release policy.
Treating security as a final gate rather than shifted-left automation-no secrets handling plan, no dependency/image scanning in the pipeline, and no policy-as-code enforcement.
Security is often studied as a separate topic, so candidates bolt it on at the end instead of embedding it as automated checks with clear pass/fail semantics.
What to do instead
Design pipelines with automated scanning, secret management (no secrets in VCS, rotation), and policy-as-code gates. Be able to explain where each check runs, what it blocks, and how false positives are triaged.
Choosing a branching model by slogan ('trunk-based is best') without matching it to release cadence, team size, and hotfix needs; and being unable to describe a concrete hotfix flow.
Branching strategies are debated ideologically, so candidates pick a label instead of reasoning about merge frequency, integration risk, and release mechanics.
What to do instead
For each model (trunk-based, GitFlow, release branches), state its assumptions and trade-offs, then walk a hotfix end-to-end: branch, fix, test, tag, deploy, back-merge. Choose based on cadence and risk, not fashion.
Writing automation scripts that ignore failure handling-no `set -e`/error checks, no idempotency, no dry-run-and being unable to debug a script that 'worked locally'.
Tutorial scripts assume happy paths; candidates don't practice error propagation, exit codes, and environment differences.
What to do instead
Write scripts with explicit error handling, exit codes, idempotent operations, and a dry-run mode. Practice tracing a failure: log the command, capture stderr, and reason about environment/quoting differences.
Describing DevOps culture as 'tools and a team rename' and answering collaboration questions with process jargon rather than concrete feedback loops, blameless postmortems, or small-batch delivery.
Culture is the softest domain and easiest to hand-wave, so answers stay abstract and miss the mechanisms that make collaboration work.
What to do instead
Ground culture answers in mechanisms: blameless postmortems with action items, small batch sizes and short feedback loops, shared ownership of production, and measurable outcomes (lead time, MTTR). Give a concrete scenario, not a slogan.