ca-fdops common mistakes
ca-fdops · Understand the traps and how to avoid them.
Treating DevOps as a job title or a specific toolchain ("we do DevOps because we use Jenkins and Docker") rather than as a set of cultural and organizational principles, so scenario questions about collaboration, shared ownership, and blameless culture get answered with tool-selection logic.
Candidates study the tooling first because it is concrete and testable, and they absorb the marketing shorthand that equates DevOps with CI/CD pipelines. The exam, however, tests whether you can distinguish the CALMS-style principles and feedback loops from the implementations that serve them.
What to do instead
For every scenario, first name the underlying principle at stake (shared ownership, fast feedback, small batch size, blameless learning) and only then choose the practice or tool that realizes it. Practice writing one-sentence justifications that lead with the principle.
Choosing the most technically sophisticated answer to a culture or incident scenario instead of the one that preserves psychological safety and learning, for example recommending individual blame or performance penalties after a production outage.
Engineers are trained to optimize for technical correctness and root-cause elimination, so punitive or hero-driven options read as 'rigorous.' The exam consistently rewards blameless postmortems, systemic fixes, and organizational learning.
What to do instead
Memorize the blameless-postmortem pattern: focus on systemic and process causes, avoid naming individuals as causes, and produce actionable prevention items. When two answers are technically plausible, pick the one that increases transparency and shared accountability.
Describing a Git branching or merge strategy in vague terms ("use feature branches and merge when ready") without specifying how conflicts are resolved, how history is kept reviewable, and how the mainline stays releasable.
Candidates know the commands but not the collaboration contract behind them, so they answer at the level of 'create a branch' rather than addressing review gates, rebase-versus-merge implications, and protected-branch rules that keep integration continuous.
What to do instead
Be able to contrast trunk-based development, short-lived feature branches, and GitFlow on concrete dimensions: branch lifetime, merge frequency, conflict surface, and release cadence. State explicitly which workflow keeps main always deployable and why.
Confusing commit, push, pull, fetch, and merge, or assuming a push automatically updates teammates' working copies, leading to wrong answers about how changes propagate and how conflicts arise in collaborative workflows.
Daily use blurs the distributed model: many candidates operate only through a hosting UI and never form a precise mental model of local versus remote refs, so they misattribute when synchronization actually happens.
What to do instead
Draw the three-tier model (working tree, local repository, remote) and place each command on it. Verify by explaining why a fetch followed by a merge differs from a pull, and why a push can be rejected as non-fast-forward.
Designing a CI pipeline that runs only on a developer's machine or only after merge, and that lacks fast feedback, deterministic builds, or artifact promotion, while claiming it satisfies continuous integration.
Candidates conflate 'we have a build script' with CI. The exam tests whether integration happens frequently on a shared, authoritative system with automated verification and reproducible outputs.
What to do instead
Check any proposed pipeline against the CI definition: every commit triggers automated build and tests on a clean shared runner, failures block integration, and a versioned immutable artifact is produced for downstream stages. Be ready to explain build reproducibility and caching pitfalls.
Collapsing continuous delivery and continuous deployment into one concept, then answering release-management questions as though every passing build must automatically reach production.
The terms sound interchangeable and many organizations use 'CD' loosely. The exam distinguishes deployable-at-any-time (delivery) from automatic-every-commit-to-production (deployment), plus the role of manual approval gates and feature flags.
What to do instead
Anchor the distinction: continuous delivery guarantees every green build is releasable on demand; continuous deployment removes the human gate. For each scenario, identify whether the requirement is 'always releasable' or 'automatically released' before selecting an answer.
Treating infrastructure as code as imperative scripting only, or writing declarative configuration that is not idempotent, not version-controlled, and not reviewed, so state drift and unreviewed manual changes go unrecognized as failures.
Many candidates' first exposure is ad-hoc shell provisioning, and the exam's scenarios about drift, plan-and-apply, and reproducible environments punish answers that ignore desired-state reconciliation and peer review of infrastructure changes.
What to do instead
For every IaC scenario, state the desired end state, how the tool detects and reconciles drift, where state is stored and locked, and how changes flow through version control and review. Contrast imperative scripts with declarative, idempotent management explicitly.
Answering container and orchestration questions by describing a single container's behavior on one host, missing scheduling, self-healing, service discovery, and the distinction between image and running container, or confusing configuration with secrets baked into images.
Local Docker experience dominates candidates' mental models, so cluster-level concerns like reconciliation loops, readiness versus liveness probes, and stateless design are underweighted.
What to do instead
Frame orchestration answers around the controller pattern: desired replica count, rescheduling on failure, probes gating traffic, and externalized configuration and secrets. Always separate build-time image contents from runtime configuration.
Choosing monitoring over observability, or answering incident-response questions with only dashboards and alerts while omitting logs, traces, SLIs/SLOs, error budgets, and a defined escalation and rollback path.
Candidates default to the tooling they have seen (a metrics dashboard) and under-specify the signal types and the decision framework that turn signals into action during an incident.
What to do instead
For observability scenarios, name the three signal types (metrics, logs, traces) and tie alerting to user-facing SLIs and SLOs rather than raw resource thresholds. For incident scenarios, include detection, triage, mitigation or rollback, communication, and blameless follow-up.
Treating security as a final gate owned by a separate team, or hardcoding credentials and secrets in pipeline files and images, instead of shifting checks left into the pipeline and managing secrets through a dedicated store.
Security is often learned as a pre-release audit step, and quick-start examples embed credentials directly, so insecure patterns feel normal. The exam rewards automated scanning in CI, least privilege, and secrets management as a continuous practice.
What to do instead
Build a checklist for every pipeline you describe: dependency and static scanning in CI, secrets pulled at runtime from a managed store, least-privilege identities for runners and workloads, and security review as an automated, continuous gate rather than a phase.