GISI ADO Level common mistakes
GISI ADO Level · Understand the traps and how to avoid them.
Treating DevOps as a job title or a single tool (e.g., 'DevOps is Jenkins') rather than describing it as a culture-and-practice set combining people, process, and automation to shorten lead time and increase deployment frequency.
Candidates skim the introductory domain because it feels like 'soft' material and memorize tool names instead of the CALMS-style framing and the definition of value streams and feedback loops.
What to do instead
Write a one-paragraph definition in your own words covering culture, automation, lean flow, measurement, and sharing; then for each exam scenario, ask whether the described problem is a people/process gap or a tooling gap before choosing an answer. Practice mapping each practice (CI, IaC, observability) back to the delivery outcome it improves.
Confusing continuous delivery with continuous deployment, and selecting 'continuous deployment' whenever the scenario mentions automated pipelines.
The two terms sound interchangeable and candidates memorize them as synonyms; the distinguishing criterion (whether every passing change is released to production automatically versus gated by a manual approval) is not internalized.
What to do instead
Anchor the distinction with a decision rule: continuous delivery = always releasable, deploy-on-demand with a business decision gate; continuous deployment = every green build goes to production without human approval. For each scenario, look for the phrase 'manual approval' or 'business decides when to release' to identify delivery, and 'no human intervention' to identify deployment.
Describing Git operations by outcome only ('upload the code', 'save the changes to the server') instead of naming the command and its effect on the working directory, staging area, local repository, and remote.
Candidates learn Git through a GUI or by copying commands, so they lack the three-tree mental model and cannot distinguish commit, push, fetch, pull, merge, and rebase under exam phrasing.
What to do instead
Draw the four areas (working tree, index/staging, local repo, remote) and place add, commit, push, fetch, pull, merge, and rebase on the diagram. Then answer practice items by stating which areas each command changes and in which direction data moves. Rehearse a merge conflict resolution end-to-end on the command line.
Recommending rebase on a shared, already-pushed branch, or recommending force-push to 'clean up' history on a branch other people are working on.
Candidates memorize 'rebase gives a linear history' as a blanket rule without the rewrite-history caveat, and they conflate local tidy-up with shared-branch policy.
What to do instead
State the rule explicitly: rebase rewrites commit hashes, so it is safe only on local or private branches; on shared branches use merge, and if a force-push is unavoidable use --force-with-lease and coordinate with the team. In scenario questions, check whether the branch has been pushed and whether others have based work on it before choosing rebase.
Treating a green CI build as proof the change is correct, without addressing flaky tests, missing test stages, or the difference between build, test, and pipeline stages.
Candidates equate 'pipeline passed' with 'quality assured' and overlook that a pipeline is only as trustworthy as its tests; they also confuse a CI server job with the full pipeline definition.
What to do instead
For each CI scenario, ask what the pipeline actually verifies: unit, integration, static analysis, artifact build. Learn to recognize flaky-test symptoms (intermittent failures on unchanged code) and the standard remedies: quarantine, fix root cause, retry with logging, never silently ignore. Know that CI's core promise is fast feedback on every commit to a shared trunk.
Choosing a deployment strategy by name recognition rather than by the risk and rollback characteristics the scenario describes, e.g., picking canary when the requirement is instant rollback of all traffic, or blue-green when the requirement is gradual percentage rollout.
Candidates memorize definitions of blue-green, canary, and rolling deployments but never map them to concrete requirements such as blast radius, rollback speed, infrastructure cost, and traffic-splitting granularity.
What to do instead
Build a comparison table with columns: traffic shift (all-at-once vs gradual), rollback mechanism (switch back vs redeploy), infrastructure cost (double vs incremental), and typical use case. Then for each scenario extract the stated constraint first and eliminate strategies that violate it before selecting.
Treating infrastructure as code as 'writing a script that runs commands' rather than declarative, version-controlled, idempotent configuration with state management and review.
Candidates with scripting backgrounds default to imperative thinking and miss that IaC tools converge to a declared desired state; they also underestimate state files and drift as exam topics.
What to do instead
Contrast imperative ('run these steps') with declarative ('this is the desired end state') using a concrete example. Memorize the properties: versioned in Git, peer-reviewed via pull request, idempotent re-application, plan/preview before apply, and remote shared state with locking to prevent concurrent-apply corruption. Practice explaining what happens when someone edits infrastructure by hand (drift) and how it is detected.
Confusing configuration management with provisioning, and describing idempotence as 'the script can be run twice' without explaining convergence to the declared state.
The two layers overlap in real toolchains, and candidates learn tool names (Ansible, Puppet, Chef, Terraform) without the layer each one owns or the ordering between them.
What to do instead
Separate the layers: provisioning creates infrastructure (networks, compute), configuration management installs and maintains software and system state on existing hosts. Define idempotence precisely: applying the same configuration repeatedly yields the same result and reports no changes when already converged. Learn the ordering principle: provision first, then configure, then deploy the application.
Reducing observability to 'we have dashboards and alerts', omitting the three pillars and the distinction between monitoring (known unknowns) and observability (unknown unknowns via logs, metrics, traces).
Candidates equate monitoring with a specific tool and never learn that traces and structured logs answer questions dashboards cannot; they also miss alert-fatigue and SLO/error-budget concepts.
What to do instead
Memorize the three pillars (metrics, logs, traces) and what each answers. Learn the monitoring-versus-observability distinction and the SLO/error-budget framing: an SLO is a target reliability level, and the error budget is the allowed unreliability. For alerting scenarios, prefer symptom-based alerts tied to user impact over cause-based alerts on every host metric.
Treating security as a final gate rather than shifting it left: not mentioning secrets management, least privilege, or automated scanning in the pipeline when the scenario asks how to secure a delivery process.
Candidates compartmentalize security into a separate topic and answer pipeline questions with build/test/deploy only, missing that the exam expects security controls embedded at each stage.
What to do instead
Build a stage-by-stage security checklist: pre-commit secret scanning, dependency and container image scanning in CI, IaC policy checks before apply, least-privilege pipeline credentials, and secrets stored in a managed vault rather than in code or environment files committed to Git. In any scenario asking to 'improve' a pipeline, include at least one shift-left control and one runtime control, and name the artifact each one protects.