IBM DevOps and Software Engineering common mistakes
IBM DevOps and Software Engineering · Understand the traps and how to avoid them.
Describing DevOps as a single job title or as 'just automation tooling' when asked what DevOps is, rather than as a culture-plus-practices-plus-tooling combination aimed at shortening feedback loops and increasing delivery frequency and reliability.
Candidates memorize a tool list (Git, Jenkins, Docker) from the CI/CD domain and reuse it to answer definitional questions; the exam often tests the cultural/process framing (collaboration, shared ownership, blameless postmortems, small batch sizes) separately from tooling.
What to do instead
Prepare a one-sentence definition that names culture, automation, lean/measurement, and sharing (CALMS-style framing) plus the outcome it targets; when a question asks 'which practice best reflects DevOps', eliminate options that only describe a tool installation with no feedback-loop or collaboration effect.
Conflating continuous delivery with continuous deployment, and answering that a continuous delivery pipeline must automatically push every green build to production.
The terms differ by one word and marketing material uses them interchangeably; candidates memorize 'automation all the way to production' without noting that continuous delivery stops at a deployable artifact with a manual approval gate.
What to do instead
Anchor the distinction in the pipeline diagram: CI produces a tested build; continuous delivery keeps every build releasable and gates the production release on a human decision; continuous deployment removes that gate. On scenario questions, look for the words 'approval', 'on demand', or 'every commit' to disambiguate.
Treating a user story as complete once the code is merged, ignoring the Definition of Done and the sprint-review acceptance step, and selecting 'done' for items that have no tests or no product-owner acceptance.
Day-to-day engineering habits equate merge with done; exam items that test Scrum empiricism expect the team's agreed Definition of Done to govern, and candidates under-weight the transparency/inspection/adaptation reasoning behind it.
What to do instead
For any 'is this increment done' item, check the story against the team's Definition of Done (tested, integrated, documented, accepted) rather than against 'code written'. Memorize that undone work is not counted in velocity and returns to the product backlog.
Assigning the Scrum Master the authority to commit the team to scope, or describing the Product Owner as the person who estimates and assigns tasks, when answering role-responsibility questions.
Real organizations blur these roles, and candidates answer from their own workplace rather than from the Scrum Guide's accountability split; the exam tests the canonical boundaries.
What to do instead
Build a three-column role table: Product Owner owns value and backlog ordering; Scrum Master owns process, impediment removal, and coaching (servant-leadership, not people management); Developers own estimation and how work is done. Answer role items by asking 'who owns the what/value vs. the how vs. the process'.
Confusing git merge with git rebase and predicting the wrong history outcome, or claiming rebase is unsafe on shared branches for the wrong reason.
Both integrate changes and both can produce a linear-looking result; candidates remember 'rebase is dangerous' without the mechanism (rewritten commit hashes) that makes it dangerous only on shared history.
What to do instead
Memorize the mechanism: merge creates a new merge commit preserving both parents; rebase replays commits onto a new base, producing new SHAs, so it rewrites history. Use rebase for local cleanup before pushing, merge for integrating into shared branches. Verify by asking 'does this change commit identity?'
Explaining a container as a lightweight virtual machine, or saying containers provide the same isolation boundary as a hypervisor because they 'package the OS'.
The 'lightweight VM' analogy is everywhere in introductory material; candidates repeat it without noting that containers share the host kernel and rely on Linux namespaces and cgroups, which is exactly what exam items probe.
What to do instead
State the mechanism explicitly: containers are isolated processes on a shared kernel using namespaces (visibility) and cgroups (resource limits); VMs virtualize hardware and each carry a full guest OS. Then answer isolation and startup-time questions from that mechanism rather than from the analogy.
Treating a Kubernetes Pod as the durable unit to scale and manage, and describing a Deployment as creating Pods directly rather than through a ReplicaSet.
Pods are the first object taught and the one candidates see in kubectl output, so the ownership chain (Deployment to ReplicaSet to Pod) and the Pod's ephemeral, non-stable-identity nature get flattened.
What to do instead
Draw the ownership hierarchy once and reuse it: Deployment manages ReplicaSets, ReplicaSets maintain Pod count, Pods are disposable and get new IPs. For stable identity and ordered scaling, reach for StatefulSet; for node-level agents, DaemonSet; for one-off runs, Job/CronJob.
Choosing a ClusterIP Service when the requirement is external access, or picking LoadBalancer/NodePort without checking what the cloud or cluster actually provides.
Service types are memorized as a list without their exposure semantics, and candidates skip the 'who needs to reach this and from where' step that the scenario is really testing.
What to do instead
Map requirement to type before reading options: internal-only traffic uses ClusterIP; HTTP routing with host/path rules uses Ingress; direct node-port exposure is NodePort; cloud-provisioned external IP is LoadBalancer. Also remember Services select Pods by label, so a selector mismatch is a common root cause in troubleshooting items.
Answering application modernization questions by defaulting to a full rewrite, instead of matching a disposition (rehost, replatform, refactor, retire, retain, repurchase) to the stated constraint such as cost, timeline, or regulatory lock-in.
Candidates equate 'modernize' with 'refactor to microservices'; the exam often rewards the least invasive option that meets the stated business goal, and the scenario usually contains the constraint that rules out a rewrite.
What to do instead
Read the scenario for the binding constraint first (time, budget, compliance, traffic profile), then select the smallest disposition that satisfies it; justify by naming the trade-off. Reserve refactor/re-architect for cases where scaling, release cadence, or coupling is explicitly the problem.
Describing a sprint burndown chart and a release burndown chart as interchangeable, or interpreting a flat burndown as a team problem rather than as scope change or incomplete work.
Both chart remaining work over time, so candidates ignore the axis difference (sprint vs. release) and the fact that scope added mid-sprint makes the line flat or rising for legitimate reasons.
What to do instead
Fix the axes in memory: sprint burndown tracks remaining task hours within one sprint and resets each sprint; release burndown tracks remaining story points across sprints. When a chart looks wrong, first ask whether scope changed or work was added, then whether the team is blocked, before concluding velocity dropped.