IBM Cloud Professional SRE common mistakes
IBM Cloud Professional SRE · Understand the traps and how to avoid them.
Treating SLOs as a dashboard decoration: quoting availability targets from memory (for example 'three nines') without connecting them to an error budget, a measurement window, or a consequence for release velocity when the budget is exhausted.
Candidates memorise the definition of an SLO but never practise the arithmetic of error budgets (budget = 1 - SLO, expressed in allowed bad minutes over a 28- or 30-day window) or the policy that follows exhaustion. Exam items often give a window, an SLO, and observed downtime and expect a judgement about whether the budget is spent and what action follows.
What to do instead
Before the exam, work three or four numeric scenarios by hand: convert an SLO into allowed downtime for a 28-day window, subtract observed incidents, state the remaining budget as a percentage, and state the freeze-or-ship decision. Practise writing the one-sentence policy that links budget exhaustion to a release freeze, and check that every answer you choose references measurement, not intention.
Confusing SLI, SLO, and SLA, and answering questions about internal reliability targets with contractual language about credits and penalties.
The three acronyms sit next to each other in every study guide, so candidates learn them as a trio of definitions rather than as three different instruments with different audiences: SLI is the measurement, SLO is the internal target, SLA is the external contract with financial consequences. Items that describe a customer credit or a support escalation get answered as if they were about internal alerting thresholds.
What to do instead
Build a three-column table (who is the audience, what is the consequence of missing it, what is the typical numeric relationship) and place each practice question into a column before reading the options. Remember that an SLO is normally stricter than the SLA so that the internal team has warning time; if an option implies the SLO is looser than the SLA, it is usually wrong.
Choosing alerting strategies that page humans for every threshold breach, and failing to distinguish symptom-based alerting from cause-based alerting or to reason about alert fatigue and toil.
Candidates default to 'alert on CPU above 80%' because it is the pattern they have seen in tutorials. Exam scenarios describe noisy paging and ask what to change; the correct answer usually moves the page to a user-visible symptom (latency, error rate, saturation of the request path) and demotes resource metrics to tickets or dashboards. Candidates also under-recognise toil as a measurable, automatable category of work rather than just 'boring tasks'.
What to do instead
Memorise the rule that pages must be actionable, urgent, and tied to user impact, and practise rewriting cause-based alerts into symptom-based ones. For toil questions, apply the criteria (manual, repetitive, automatable, tactical, no enduring value, scales with service growth) and prefer answers that quantify and reduce toil over answers that add more on-call staff.
Describing observability as 'logs, metrics, and traces' and stopping there, without being able to say which signal answers which question or how correlation identifiers tie them together.
The three-pillar slogan is easy to memorise and appears in every summary, so candidates never learn the operational distinctions: metrics for aggregate trends and alerting, traces for request-level latency breakdown across services, logs for discrete events and detail. Scenario questions about finding which downstream dependency caused a slow checkout are answered with 'check the logs' rather than 'follow the trace and its span timings'.
What to do instead
For each signal, write down the question it answers best, its cost profile, and its cardinality risk. Practise the correlation story end to end: an alert fires on an error-rate metric, you pivot to traces filtered by that time window, you identify the slow span, and you use the trace identifier to pull matching logs. Also learn why high-cardinality labels such as user ID or request ID belong in traces and logs, not in metric labels.
Treating incident response as improvisation: skipping explicit severity classification, role assignment (incident commander versus communications lead versus subject-matter experts), and the structured timeline that feeds the post-incident review.
Candidates read incident write-ups as narratives and remember the technical root cause, not the process scaffolding. Exam items ask who should be doing what during a live incident, or what belongs in a blameless post-incident review, and candidates pick technically plausible but process-wrong answers such as 'the most senior engineer leads every incident' or 'the review should identify who made the mistake'.
What to do instead
Learn the role split as a checklist: who coordinates, who communicates, who investigates, and who decides to mitigate versus diagnose. Practise separating mitigation (restore service, often by rollback or failover) from root-cause analysis (later, in the review). For review questions, prefer answers that produce action items with owners and dates, focus on systemic causes, and explicitly exclude individual blame.
Answering automation questions with 'automate everything' rather than reasoning about idempotency, blast radius, and the pipeline gates that make automation safe.
Candidates associate automation with maturity and therefore pick the most automated option regardless of risk. Real exam scenarios test whether you understand that a non-idempotent script retried by a pipeline can double-apply a change, that a broad automation run can widen a failure, and that approval gates and canary stages exist to bound damage rather than to slow teams down.
What to do instead
For every automation question, ask three questions before choosing: is the operation idempotent, what is the worst case if it runs twice or runs on the wrong target, and where is the human or automated gate. Prefer answers that add health checks, staged rollout, and rollback over answers that add more automation scope. Learn to recognise the difference between declarative desired-state tooling and imperative scripts, and why the former is preferred for repeatability.
Confusing infrastructure as code concepts: mistaking state for configuration, assuming a plan is a guarantee, or failing to distinguish immutable redeployment from in-place mutation of running resources.
Candidates learn IaC vocabulary from tool documentation and blur the boundaries. Questions about drift, about why a plan shows unexpected changes, or about why a redeploy is preferred to patching a live server require knowing that state records what was last applied, that drift arises from out-of-band changes, and that immutable replacement removes configuration drift as a class of failure.
What to do instead
Write a short explanation, in your own words, of the lifecycle: author configuration, store and lock state, plan, review the diff, apply, and detect drift. Practise identifying when a plan can be stale (state changed since plan, or external changes occurred) and when replacement is safer than in-place update. For pipeline questions, prefer answers that run plan on pull request and apply after review, with state locking to prevent concurrent applies.
Treating IBM Cloud resource hierarchy as flat: picking answers that ignore the account, resource group, region, and access-group structure, or assuming a resource can move freely between regions and groups.
Candidates study individual services (Kubernetes, VPC, object storage) and never build a mental model of how resources are organised and scoped. Exam items about where to place resources for cost attribution, isolation, or access control, or about why a resource is not visible to a teammate, hinge on the hierarchy rather than on the service itself.
What to do instead
Draw the hierarchy once: account contains resource groups, resources are created in a resource group and a region (and often a zone), and access is granted through IAM policies scoped to account, resource group, or individual resource. Practise mapping requirements onto that structure: separate resource groups per environment for isolation and cost visibility, region chosen for latency and data residency, zones chosen for high availability. When an option implies cross-region or cross-group movement of an existing resource, treat it with suspicion.
Answering high-availability and disaster-recovery questions with a single word ('replicate') instead of matching RTO and RPO requirements to a specific strategy and its cost and complexity trade-offs.
Candidates know the acronyms RTO and RPO but do not practise converting a business requirement into an architecture. Items that state a recovery objective and ask for the appropriate pattern are answered with the most resilient-sounding option, ignoring that multi-zone within a region and multi-region active-active solve different problems at very different cost and consistency trade-offs.
What to do instead
Build a ladder of strategies (backup and restore, pilot light, warm standby, active-active) with typical RTO and RPO ranges, relative cost, and the failure each one covers. Then practise reading a requirement and stating the cheapest strategy that meets it, plus the failure domain it does not cover. Remember that high availability is about surviving component and zone failure inside a region, while disaster recovery is about losing a region or a critical dependency.
Treating security and compliance as a checklist of services rather than as controls mapped to data sensitivity, identity scope, and audit evidence; answering governance questions with 'encrypt it' or 'enable logging' without saying who can access the key, what is logged, and who reviews it.
Candidates memorise service names (key management, audit logging, secrets management) but not the control objectives behind them. Scenario items ask how to protect data at rest so that an operator cannot read it, how to prove who changed a configuration, or how to apply least privilege across a team, and the generic answer sounds right but fails the specific requirement.
What to do instead
For each control area, write the objective in one line and the evidence it produces: encryption with customer-managed keys and separated key administration for data-at-rest protection; audit trails of administrative actions with retention and review for accountability; scoped IAM policies and service IDs rather than shared credentials for least privilege; secrets in a managed store with rotation rather than in configuration. When answering, check that your choice names the actor, the permission boundary, and the record produced, not just the service.