Module 15 common mistakes
Module 15 · Understand the traps and how to avoid them.
Treating the exam as a generic IT-operations test and skipping the module's foundational vocabulary, so scenario questions using terms like policy, baseline, or lifecycle are answered from everyday intuition rather than the module's defined meaning.
Candidates assume the fundamentals domain is 'free marks' and spend their study time on configuration steps, then meet questions that hinge on precise distinctions between closely related concepts.
What to do instead
Before drilling scenarios, build a one-page glossary of the module's core terms and write each in your own words with a concrete example. Re-test yourself by explaining how two similar terms differ, not by reciting definitions.
Reading a planning scenario and immediately proposing a solution without first extracting the stated constraints (budget, timeline, existing environment, compliance requirement), leading to an answer that is technically sound but violates an explicit condition.
Exam scenarios are written to reward requirement analysis, but candidates under time pressure pattern-match to a familiar solution they have seen before.
What to do instead
Adopt a fixed routine for every scenario: underline the goal, list each constraint and stakeholder, then eliminate any option that breaks a constraint before comparing the survivors on merit.
Confusing design decisions with implementation steps, choosing an answer that describes how to configure something when the question asks what should be designed or planned.
The domains overlap heavily, and many options are plausible actions that belong to a later phase; candidates pick the most concrete-sounding option.
What to do instead
Classify each question stem by phase before looking at the options: is it asking what to decide, what to build, how to run it, or how to fix it? Then reject options from the wrong phase even if they are correct in general.
Memorising configuration values or menu paths verbatim and then failing when the question presents a slightly different environment or asks for the principle behind the setting.
Hands-on study often produces step memory rather than conceptual understanding, and exams deliberately vary the surrounding context.
What to do instead
For each configuration you practise, write down what problem it solves, what the default is, and what breaks if it is wrong. Test yourself by predicting the effect of changing the value rather than recalling where the setting lives.
Selecting the most feature-rich or restrictive configuration option by default, ignoring trade-offs such as operational overhead, performance impact, or user friction described in the scenario.
Candidates equate 'more secure' or 'more controls' with 'more correct', but implementation questions usually reward the proportionate choice.
What to do instead
For every candidate option, state one benefit and one cost. Eliminate options whose cost contradicts a stated requirement, and prefer the least complex option that fully satisfies the requirement.
Answering operational questions with one-off manual fixes instead of repeatable, documented procedures, so the chosen answer solves today's incident but not the recurring pattern the question describes.
Real-world habits favour quick remediation, and the word 'fix' in a stem pulls candidates toward immediate action rather than sustainable process.
What to do instead
When a stem mentions recurrence, multiple users, or drift, look for answers that establish a standard, automate the check, or update documentation. Reserve manual remediation answers for genuinely one-off, contained incidents.
Ignoring the maintenance half of the operations domain, such as review cadence, patch and lifecycle management, and record keeping, and losing marks on questions about keeping a working system working.
Study material and lab practice emphasise initial setup, so ongoing upkeep feels less examinable and receives little revision time.
What to do instead
Build a maintenance checklist covering scheduled review, update handling, ownership handover, and record retention, and practise mapping scenario symptoms to the missing maintenance activity.
Jumping from a monitoring alert straight to a root-cause conclusion, choosing the answer that names a likely culprit rather than the one that confirms or isolates it.
Alert fatigue and familiarity make certain causes feel obvious, and exam distractors are written to match that intuition.
What to do instead
Rank answers by diagnostic value: prefer the step that narrows the problem space or verifies the signal before any remediation. Treat any option that assumes a cause without evidence as a distractor.
Confusing monitoring with observability or with alerting alone, so questions about what to measure, how to set thresholds, and how to avoid noise are answered with 'add more alerts'.
Tool-centric study focuses on dashboards and notifications rather than on the purpose of measurement and the cost of false positives.
What to do instead
Study the measurement chain explicitly: what signal, at what granularity, with what threshold, routed to whom, and what action follows. Practise judging whether a proposed metric or alert would actually change a decision.
Treating governance as bureaucracy and choosing the fastest technical remedy in troubleshooting scenarios, missing that the correct answer requires change control, evidence capture, or escalation.
Candidates separate troubleshooting from governance in their mental model, but the exam deliberately combines them in incident and change scenarios.
What to do instead
In every troubleshooting scenario, ask two extra questions before answering: who needs to approve or be informed, and what record must exist afterwards? Eliminate options that bypass approval or leave no audit trail even when they resolve the symptom.