Capacity, Performance, and Troubleshooting
What the exam tests
This domain tests whether you can plan capacity, find bottlenecks, and troubleshoot with evidence. Expect quotas, instance profiles, autoscaling, load testing, percentile latency, resource saturation, database connections, zone-failure headroom, and IBM Cloud support evidence.
Core rules
- Establish a baseline before changing anything. Use p95 and p99 latency, not only averages, and correlate with traffic, errors, and saturation.
- Capacity planning includes quotas and limits per region and resource. A design that cannot scale because of a quota is not resilient.
- Scale the constrained tier. Application replicas do not help if the database connection pool is exhausted; adding replicas can make it worse.
- Plan headroom for a zone failure. If three zones normally carry one-third each, the remaining two must absorb the load after one fails.
- Use load testing to validate limits and autoscaling behavior. Test realistic connection reuse, payloads, and dependency latency.
- Troubleshoot by time correlation: recent changes, deploy IDs, metrics, logs, traces, and VPC flow logs. Eliminate layers systematically.
- When opening an IBM Cloud support case, include resource IDs, timestamps, regions, symptoms, and recent changes.
Worked example. A service's p95 latency rises from 200 ms to 900 ms at 70% CPU, and database connections are at 95% of the maximum. The team first adds application replicas, but latency worsens because each replica opens more connections. The correct fix is to add connection pooling, scale the database or add a read replica for read traffic, then scale application replicas. Reasoning: the real constraint is database connections, not application CPU. Scaling the wrong tier amplifies contention.
Traps that cost marks
Scaling only on CPU; ignoring service quotas; using averages that hide tail latency; load testing without realistic dependencies; forgetting zone-failure headroom; blaming the network without flow logs or packet evidence; changing multiple variables during troubleshooting.
Key points
- Baseline first; use p95 and p99 latency.
- Find and scale the actual constrained tier.
- Check quotas before declaring a design scalable.
- Plan capacity so remaining zones can absorb a zone failure.
- Correlate changes, metrics, logs, traces, and flow logs during troubleshooting.