CDOS common mistakes
CDOS · Understand the traps and how to avoid them.
Treating CI as a build server that only compiles code, so pipeline questions about gates, artifacts, and environment promotion get answered with 'run the build again' instead of describing stage sequencing and artifact immutability.
Candidates carry over experience from single-job build systems and have never designed a multi-stage pipeline with promotion criteria, so they collapse build, test, and deploy into one mental step.
What to do instead
Practice sketching a three-stage pipeline on paper: build once, publish an immutable versioned artifact, then promote that same artifact through test and prod with quality gates between stages. For each stage write the trigger, the gate, and the artifact identity so you can answer sequencing questions precisely.
Confusing continuous delivery with continuous deployment, asserting that a CD pipeline must automatically push every passing change to production.
The two terms share the abbreviation CD and marketing material often blurs them, so candidates pick the more aggressive definition without checking the release-on-demand criterion.
What to do instead
Memorize the distinction: continuous delivery keeps every change releasable with a manual approval to deploy; continuous deployment removes that approval. When a question mentions approval gates or business sign-off, that is delivery, not deployment.
Answering infrastructure-as-code questions by describing manual console changes with the code committed afterwards, rather than describing declarative desired state reconciled by a tool.
Many candidates learned cloud by clicking through consoles and treat IaC as documentation of what they did, missing the reconciliation loop and drift detection that define the practice.
What to do instead
Frame every IaC answer around desired state, plan or dry-run preview, apply, and drift detection. Practice explaining what happens when someone edits a resource by hand: the next plan should show drift and the apply should revert it unless the code is changed.
Describing containers as lightweight virtual machines and attributing hardware-level isolation to them, then answering security and orchestration questions on that false premise.
The VM analogy is the easiest way to first understand images and is rarely corrected, so it silently propagates into isolation, kernel sharing, and privilege questions.
What to do instead
State clearly that containers share the host kernel and isolate via namespaces and cgroups, while VMs virtualize hardware. Then reason from that: a container escape is more severe, privileged containers weaken isolation, and image contents must be trusted because the kernel is shared.
Treating Kubernetes pod failure questions as 'restart the pod' without distinguishing CrashLoopBackOff, ImagePullBackOff, Pending, and readiness-probe failures.
Candidates memorize a handful of kubectl commands but not the state machine behind pod status, so they apply one remedy to every symptom.
What to do instead
Build a symptom-to-cause table: CrashLoopBackOff means the process exits repeatedly, so read logs and check exit codes; ImagePullBackOff means registry or credential problems; Pending means scheduling or resource constraints; readiness failures mean the probe or app startup is wrong. Answer with the diagnostic step before the remedy.
Choosing trunk-based development for every scenario and dismissing long-lived branches, or the reverse, without weighing release cadence, team size, and test automation maturity.
Candidates latch onto one workflow they have used and treat branching strategy as a matter of taste rather than a trade-off tied to integration frequency and merge risk.
What to do instead
Prepare a decision rule: short-lived branches and trunk-based flow suit frequent integration with strong automated tests; release branches suit versioned products with multiple supported versions; GitFlow suits infrequent, scheduled releases. In answers, name the constraint that drives the choice.
Answering incident questions by jumping straight to remediation steps and skipping detection, triage, communication, and blameless postmortem.
Engineers are rewarded for fixing things fast, so the response reflex dominates and the lifecycle around an incident is treated as paperwork rather than part of the answer.
What to do instead
Structure incident answers along the full lifecycle: detect and alert, assess severity and assemble responders, mitigate before root-causing, communicate status to stakeholders, then run a blameless postmortem with tracked action items. Mention mitigation-before-diagnosis explicitly, since it is a frequent scoring point.
Treating DevSecOps as a final security review before release instead of embedding checks such as dependency scanning, secret detection, and IaC policy validation into the pipeline.
Security is often a separate team's gate in candidates' organizations, so shift-left is a slogan they can recite but not place concretely in a pipeline.
What to do instead
Map each control to a pipeline stage: secret scanning and linting at commit, dependency and container image scanning at build, IaC policy checks at plan, and runtime or compliance checks post-deploy. Being able to say where a control runs, and whether it blocks or warns, answers most of these questions.
Describing monitoring as dashboards and CPU graphs while omitting logs, traces, and service-level objectives when asked about observability.
Candidates equate observability with the monitoring tool they know best and have not internalized the three pillars or the difference between known-unknown and unknown-unknown debugging.
What to do instead
Answer with the three pillars plus their purpose: metrics for aggregate trends and alerting, logs for discrete events, traces for request flow across services. Tie alerts to SLOs and error budgets rather than raw thresholds, and explain that high-cardinality tracing is what lets you debug novel failures.
Assuming cloud managed services remove operational responsibility, so questions about patching, backup, or identity get answered with 'the provider handles it'.
The shared responsibility model is understood only vaguely, and managed-service marketing encourages the belief that operations disappear entirely.
What to do instead
Learn the split by layer: the provider secures physical infrastructure, hypervisor, and the managed service's control plane; you remain responsible for identity and access configuration, data classification, encryption choices, network policy, and client-side patching. Answer by naming which side owns the specific control in the question.