EXIN DevOps Foundation common mistakes
EXIN DevOps Foundation · Understand the traps and how to avoid them.
Treating DevOps as a toolchain or job title - answering that adopting CI/CD tools, or hiring a 'DevOps engineer', is what makes an organisation DevOps.
Candidates arrive from a tools-first background and the exam's vocabulary (culture, collaboration, CALMS) looks like soft filler, so they discount it and default to concrete products they know.
What to do instead
Anchor every definition in the EXIN framing: DevOps is a culture and collaboration movement aimed at breaking silos between development and operations, enabled by automation and measurement. When a question asks 'what is DevOps', reject answers that name only tools or only roles; prefer answers combining culture, collaboration and automation.
Confusing DevOps with Agile, Lean or ITIL - answering that DevOps is a rebranding of Agile, or that it replaces ITIL entirely.
The three movements share vocabulary (iterations, feedback, flow) and candidates pattern-match on shared words rather than on the distinct scope of each.
What to do instead
Memorise the distinct scopes: Agile targets the development side and customer-value delivery in short cycles; Lean targets waste elimination and flow; ITIL targets service management processes. DevOps spans the whole delivery chain from requirement to production and operations, and can coexist with ITIL (e.g. ITIL for service management, DevOps for delivery flow).
Mixing up the Three Ways - labelling feedback as 'First Way' or flow as 'Third Way' - and then answering follow-up questions from the wrong premise.
The Three Ways are abstract and the names (flow, feedback, continual learning) are not self-ordering, so candidates remember the ideas but not the sequence.
What to do instead
Fix the order with a mnemonic: 1 = Flow (left to right, from Dev to Ops, small batch sizes, limit WIP), 2 = Feedback (right to left, fast feedback from production back to development, telemetry, monitoring), 3 = Continual learning (experimentation, repetition, blaming-free culture). Map each practice to its Way before answering.
Answering that the First Way means 'automating everything' or 'moving faster', rather than optimising the flow of work left to right.
Automation and speed are the visible symptoms of DevOps, so candidates substitute the outcome for the principle.
What to do instead
State the First Way as optimising the global flow of value from development to operations and the customer, achieved by reducing batch size, limiting work in progress, and removing bottlenecks. Automation is a means to that end; if an option only mentions speed or tooling without flow, it is probably wrong.
Describing feedback (Second Way) as 'the customer giving requirements' or as 'code review', instead of amplifying feedback loops from right to left.
'Feedback' is a familiar general word, and candidates import everyday meanings rather than the DevOps-specific direction of information from operations and production back to development.
What to do instead
Define the Second Way as shortening and amplifying feedback loops from right to left - production telemetry, monitoring, incident data, user behaviour - so that development learns quickly about the consequences of its changes. Distinguish it from requirements gathering (which flows left to right) and from peer review (which is within the left side).
Treating CI as 'developers merge occasionally and run tests before release', and CD as synonymous with continuous deployment to production.
The words 'continuous' and 'delivery/deployment' are easily blurred, and many organisations use 'CD' loosely for a release pipeline.
What to do instead
Separate the terms precisely: Continuous Integration = frequently integrating work into a shared mainline with automated build and test on every change. Continuous Delivery = every change is kept in a deployable state and can be released on demand. Continuous Deployment = every passing change is automatically released to production. Delivery is a capability; deployment is a policy choice.
Answering that the exam's 'shift left' means moving testing earlier only, or confusing shift left with shift right.
Shift left is most often taught in a testing context, so candidates over-narrow it and then miss questions about security, compliance or operations involvement early in the lifecycle.
What to do instead
Define shift left as moving quality, security and operational considerations earlier into the lifecycle (requirements, design, coding), and shift right as learning from production (monitoring, chaos experiments, post-incident review). If an option mentions only 'test earlier', check whether a broader option covering security, compliance and design is available.
Choosing 'blameless post-mortem' answers that say the goal is to identify and punish the person who caused the incident, or that blame should be avoided by not recording incidents at all.
Candidates conflate 'blameless' with 'accountability-free' or with 'no documentation', because the word blame dominates attention.
What to do instead
Frame it as: record the incident fully, focus on systemic and process causes, and treat the incident as a learning opportunity (Third Way). People are still accountable for following process; the post-mortem removes fear so that information is not hidden. Reject options that suppress reporting or skip documentation.
Answering scenario questions about a stalled pipeline or a conflict between Dev and Ops by proposing a tool purchase or an org-chart change, instead of diagnosing the flow or feedback problem described.
Scenario items reward reading the described symptom; candidates skim the scenario, recognise a familiar tool name in an option, and select it without matching it to the stated problem.
What to do instead
For each scenario, first name the symptom in DevOps terms (long lead time, large batch, no production feedback, manual handoff, environment drift), then choose the option that addresses that symptom with the smallest systemic change. Prefer options that reduce batch size, add feedback, or automate a repeated manual step over options that restructure or buy.
Ignoring the people-and-culture dimension in practical questions - recommending a reorganisation, a new team name, or mandatory tooling as the fix for a siloed organisation.
Technical candidates find culture answers vague and prefer concrete structural answers, but the exam consistently tests that silos are broken by shared goals, trust and cross-functional collaboration, not by renaming teams.
What to do instead
When a scenario describes blame, fear of deployment, or Dev throwing work over the wall, select answers that create shared ownership and shared metrics (e.g. joint responsibility for availability), autonomous cross-functional teams, and safe experimentation. Treat reorganisation alone as a distractor unless it is paired with changed goals and collaboration.