IBM Cloud Associate SRE common mistakes
IBM Cloud Associate SRE · Understand the traps and how to avoid them.
Calculates an availability SLO by averaging the uptime percentages of every individual microservice instead of measuring success and latency on the user-facing request path.
Candidates memorize the SLI/SLO/SLA definitions but miss the SRE principle that SLOs attach to user journeys; averaging components hides correlated failures and makes the composite number look better than the customer experience.
What to do instead
Practice deriving SLIs from edge request success rate and latency, define one SLO per critical user journey, and explain how a dependency failure consumes the same error budget as an edge failure.
Selects IBM Cloud Activity Tracker to graph CPU, memory, or request-latency metrics, or expects Activity Tracker itself to evaluate threshold conditions and page an on-call engineer.
The names of the observability services sound interchangeable, so candidates map "activity" to operational metrics and "monitoring" to audit logs without learning each service's data type and purpose.
What to do instead
Memorize the split: Activity Tracker records account-level audit events, IBM Cloud Monitoring stores and alerts on time-series metrics, and IBM Cloud Logs handles log search and retention; then match each scenario to the correct data source before choosing an alerting tool.
In an incident scenario, chooses to identify the root cause before restoring service, and describes a blameless postmortem as one that has no follow-up actions or accountability.
Candidates conflate root-cause analysis with mitigation, and they hear "blameless" as "no consequences" rather than "focus on system conditions instead of individual fault."
What to do instead
Apply the order mitigate, stabilize, then investigate; assign an incident commander and scribe early, and write postmortems with a timeline, contributing factors, and owned, dated action items that are tracked to closure.
Designs a delivery pipeline that deploys a release to every production instance only after the full test suite passes, with no canary stage and no automated rollback tied to a reliability signal.
Candidates treat CI/CD as a build-and-test gate and overlook progressive delivery, so they miss how deployment strategy itself limits blast radius and shortens recovery time.
What to do instead
Add canary or blue-green stages, immutable versioned artifacts, health and SLO-based promotion gates, and an automated rollback path; be able to explain which failure signals should stop a rollout.
Assumes an IBM Cloud VPC is account-global and that worker nodes in a single Kubernetes cluster can be spread across resource groups and regions by default.
Candidates flatten the account, resource group, region, and zone hierarchy into one mental model, then apply the wrong scope when reasoning about placement, quotas, and failure domains.
What to do instead
Map the hierarchy explicitly: the account contains resource groups, resource groups contain service instances, VPCs and clusters are regional, and multi-zone placement is not the same as multi-region placement; practice locating a resource by region, resource group, and service type.
Chooses a VPC network ACL when the requirement is stateful, instance-level allow or deny rules for one virtual server, or exposes a load balancer backend on a public subnet when private connectivity is sufficient.
Security groups and network ACLs are both described as firewalls, so candidates miss that security groups are stateful and attach to network interfaces while ACLs are stateless and operate at the subnet boundary.
What to do instead
Compare the constructs by scope and statefulness: use security groups for stateful instance-level control, ACLs for stateless subnet-level guardrails, public gateways or floating IPs only for required outbound or inbound public access, and private subnets for backends behind a load balancer.
Grants an application an account owner API key, or assumes that adding a service ID to an access group automatically gives it permissions, instead of attaching a scoped IAM policy.
Candidates confuse access-group membership with authorization and reach for the broadest credential when a scenario mentions a service that must call another service.
What to do instead
State the chain clearly: identities such as service IDs receive access only through IAM policies, and access groups are containers for identities plus policies; use least-privilege scoped policies, separate service credentials from human credentials, and rotate or bind API keys deliberately.
Responds to a latency spike by immediately increasing worker count without checking VPC quotas, pod resource requests and limits, node taints, or whether the bottleneck is a downstream dependency.
Candidates treat autoscaling as instantaneous and capacity as purely a cluster-size problem, so they skip the evidence-gathering step and recommend scaling for symptoms that scaling cannot fix.
What to do instead
Walk through capacity troubleshooting in order: confirm the symptom with metrics, check quotas and available capacity, verify pod scheduling constraints and resource requests, identify the saturated layer, then choose horizontal pod autoscaling, cluster autoscaling, or a downstream fix with a stated validation signal.
States that IBM Cloud automatically encrypts all customer data at rest and in transit at every layer, so the customer has no encryption-key or compliance responsibilities.
The shared-responsibility model is often reduced to a slogan, and candidates do not distinguish provider-managed encryption from customer-managed keys and service-specific configuration obligations.
What to do instead
Separate provider controls from customer controls: know where customer-managed keys such as Key Protect or Hyper Protect Crypto Services apply, which services require explicit encryption configuration, and how compliance evidence and audit logging remain customer responsibilities even when the platform supplies defaults.
Treats longer log retention and more dashboards as the fix for poor observability, and proposes alerting on every CPU or memory threshold rather than on user-visible symptoms and error-budget burn.
Candidates equate observability with data volume and equate alerting with cause metrics, so they miss that logs, metrics, and traces answer different questions and that cause-based paging produces noisy, low-signal alerts.
What to do instead
Design around the three pillars: metrics for aggregation and alerting, traces for request-path attribution, logs for event detail; alert primarily on symptom signals such as error rate and latency against SLOs, use multi-window burn-rate conditions for paging, and keep cause metrics for dashboards and diagnosis.