EXIN DevOps Master common mistakes
EXIN DevOps Master · Understand the traps and how to avoid them.
Treating DevOps as a tooling checklist - answering 'implement CI/CD pipelines and use Docker' when asked how an organisation should start a DevOps adoption, instead of addressing culture, organisational structure, and the change approach.
Candidates study pipeline technology far more than the organisational side, and the exam's adoption questions are phrased in business language that invites a technology answer. The scenario often mentions tools, which pulls attention toward them.
What to do instead
For any adoption question, first write down the three dimensions explicitly: culture/behaviour, organisation/roles, and technology/automation. Then check your answer names at least one concrete action in each. If the question asks about starting out, lead with a small cross-functional team and an explicit improvement goal, and place tooling last.
Answering 'the DevOps team does it' or 'the platform team owns it' when a scenario asks who is responsible for a practice such as testing, security, or production support.
Real job titles in many organisations include 'DevOps engineer', so candidates map the exam's cross-functional principle onto a dedicated team. The exam deliberately tests whether you understand that DevOps is a shared responsibility across development and operations.
What to do instead
Default to 'the product team as a whole, including development and operations, with the role closest to the work taking the action'. Only assign a separate team when the question is explicitly about a platform or enabling function that supports other teams rather than owning their outcomes.
Proposing a big-bang transformation plan - reorganise all teams, replace all tooling, and roll out to the whole organisation in one phase - for a scenario asking how to make DevOps adoption succeed.
Candidates equate a thorough answer with a comprehensive one, and exam scenarios often describe large enterprises, which seems to justify a large plan. The exam rewards incremental, feedback-driven change.
What to do instead
Structure adoption answers as small, reversible steps with a feedback loop: pilot with one value stream, measure a defined outcome, learn, then expand. Explicitly mention resistance management and visible leadership support, and avoid answers with a single large cutover.
Describing the Three Ways or the DevOps principles as slogans ('flow, feedback, continual learning') without translating them into the specific practices the question asks for.
The frameworks are memorable as short lists, so candidates reproduce the list and stop, assuming naming the principle answers a question about how to apply it.
What to do instead
For each principle, memorise two or three concrete practices with an example: flow - small batch sizes, limiting work in progress, removing handoffs; feedback - automated testing, monitoring, fast incident feedback to developers; continual learning - blameless post-mortems, experimentation, shared knowledge. Answer with the practice, then name the principle it serves.
Writing a plan that lists activities in the wrong sequence - for example placing monitoring and feedback design after go-live, or defining deployment automation before agreeing on the definition of done and acceptance criteria.
Candidates recall individual DevOps practices but not their dependencies, and exam scenarios present them out of order to test sequencing.
What to do instead
Learn the lifecycle as a chain: business goal and value stream, then requirements and acceptance criteria including non-functional ones, then design, then build and test, then release and deploy, then operate and feed back. For any planning question, check that each activity has its inputs available from an earlier activity.
Ignoring non-functional requirements - performance, availability, security, recoverability, maintainability - and answering only with functional user stories when a scenario asks what to include in requirements.
Functional requirements are what candidates practise writing, and the scenario's user-facing description draws attention to features rather than qualities.
What to do instead
For every requirements question, add an explicit non-functional pass: ask what the service must guarantee, under what load, with what recovery time and recovery point, and what security constraints apply. Tie each to a measurable acceptance criterion so it can be tested and monitored in operation.
Treating requirements as frozen and fully specified up front, rejecting the idea of evolving them, when a scenario asks how to handle changing requirements during a DevOps delivery.
Many candidates' experience is plan-driven delivery, and exam questions about change can read as traps, so they choose the apparently safer 'complete the specification first' option.
What to do instead
Distinguish the goal (stable) from the solution (negotiable). Answer with short feedback cycles, a prioritised backlog, and acceptance criteria that let the team verify increments early. Note that change is absorbed by small batch size and automated verification, not by resisting change.
Describing deployment as 'developers hand the build to operations, who deploy it' or as a manual approval gate before every release, when asked to design a deployment process.
This reflects a common real-world split and sounds prudent; candidates also confuse control with manual steps. The exam tests whether you can keep control while removing handoffs.
What to do instead
Answer with automated, repeatable deployment from a single artefact built once, promoted through environments, with automated quality gates and the same deployment mechanism in every environment. Keep approvals only where a genuine risk or compliance requirement exists, and say what that requirement is.
Proposing separate development, test, and production pipelines or environment-specific builds, rather than one build promoted through environments.
Candidates reason that each environment has different needs and design accordingly, without recognising that rebuilding per environment breaks traceability and makes the tested artefact differ from what runs in production.
What to do instead
State the rule explicitly in your answer: build once, deploy the identical artefact everywhere, and vary only configuration. Mention versioning, artefact repository, and configuration management as the mechanisms that make this possible.
Answering operation and scaling questions with reactive monitoring only - alerts when something breaks - and omitting capacity planning, feedback to development, and blameless learning.
Monitoring is the most familiar operational practice, and 'scale by adding servers' feels like a complete answer to scaling. The exam expects the operational feedback loop back into development.
What to do instead
For operation answers, cover four things: observability of service level indicators against objectives, capacity and scaling approach (including when to scale up versus out), incident response with blameless post-mortems, and a defined route for operational findings to become backlog items. For scaling, state the metric you scale on and the limit you are protecting.