Capacity Planning

Trick 1 Both Failure Modes Are Real — Outages and Waste Are Both Wrong Answers

Students often think of capacity planning as "make sure there's enough." The exam tests the other side too: overcapacity is also a failure. When a question describes low CPU utilization, idle servers, or resources nobody is using, the problem is overcapacity — financial waste. Capacity planning must balance both directions.

Pattern Recognition

Question says: slow response times, timeouts, service degradation, outage during high demand

→ Undercapacity — demand exceeded supply

Question says: low utilization (5–10%), idle resources, money being wasted, servers "doing nothing"

→ Overcapacity — supply exceeds demand; right-sizing or decommissioning needed

The goal is neither full utilization at all times (which means you're always near the edge) nor massive unused headroom. The goal is appropriate headroom — enough buffer without waste.

Trick 2 Vertical = One Bigger Box (with a Ceiling). Horizontal = More Boxes (no ceiling).

The exam will describe a scaling action and ask you to name it, or describe a need and ask which approach fits. The key discriminators are: architectural change required, ceiling, and redundancy.

Pattern Recognition

"Added more RAM to the existing server" / "upgraded to a 32-core instance"

→ Vertical scaling (scale up)

"Added three more web servers behind the load balancer"

→ Horizontal scaling (scale out)

Question asks: "which scaling method has no practical ceiling?"

→ Horizontal — you can keep adding servers

Question asks: "which scaling method maintains a single point of failure?"

→ Vertical — one bigger server is still one server

Workload is stateful / legacy / cannot run as multiple instances

→ Vertical scaling is the pragmatic first choice

Memory anchor: Vertical = one server gets a promotion. Horizontal = hire more people. A promoted employee is still one person who can quit (fail). More staff means losing one person doesn't stop the work.

Trick 3 Cloud = Fast + Operational Expense. Physical = Slow + Capital Expense.

Whenever a question involves the speed of capacity changes or the financial model of infrastructure, the answer hinges on this distinction. Physical infrastructure is CapEx (large upfront purchase) and takes weeks/months. Cloud is OpEx (pay-per-use) and takes minutes.

Pattern Recognition

"Provision additional capacity within minutes" / "no hardware to purchase"

→ Cloud infrastructure

"Weeks to months for delivery and installation" / "capital expenditure"

→ Physical on-premises infrastructure

"Pay only for what you use" / "billed by the hour"

→ Cloud infrastructure (OpEx model)

"Hardware exists regardless of utilization" / "consumes power even when idle"

→ Physical infrastructure (fixed cost regardless of utilization)

The financial distinction matters: CapEx = you own it, you pay for it even if it sits idle. OpEx = you rent it, you only pay while you use it.

Trick 4 Elasticity Is the Answer to "Provision for Peak vs. Normal" — Not a Compromise Between Them

When the exam presents the dilemma of "provision for peak demand (expensive, wastes money at normal times) vs. provision for normal demand (risks outages during peaks)," the answer is elasticity — it eliminates the dilemma entirely by matching supply to actual demand in real time.

Pattern Recognition

"Automatically scales resources up when demand is high and back down when it drops"

→ Elasticity / auto-scaling

"Avoids paying for idle capacity during normal periods while still handling peak demand"

→ Elasticity — resolves the fixed-capacity dilemma

"Define minimum instances, maximum instances, and scaling trigger rules"

→ Cloud auto-scaling group configuration (implementing elasticity)

Elasticity is not about finding a middle number between peak and normal. It is about dynamically matching the number to whatever demand actually is, at any moment.

Trick 5 People Is the Hardest and Slowest Dimension — The Exam Tests This Directly

The three capacity dimensions (people, technology, infrastructure) are not equal. Technology and cloud infrastructure can be scaled in minutes to hours. People — hiring, onboarding, training — takes weeks to months. When a question describes a capacity problem where time-to-scale is the critical constraint, people is almost always the bottleneck.

Pattern Recognition

"Service requires human staff" + "needs to scale quickly" = impossible to do fast

→ People capacity — inherently slow to scale; requires advance planning

"Seasonal demand spike known months in advance" + "human-staffed service"

→ Must hire and train before the season begins, not during it

"More flexibility than pure full-time headcount" strategies for people scaling

→ Contract staffing, cross-training, outsourcing, remote work arrangements

Technology and cloud scale in minutes. People scale in months. The slowest dimension determines the minimum planning horizon.

Practice Scenarios — Apply the Tricks

Scenario A: A company's cloud database instances have been running at 8% CPU utilization for six months. A capacity review flags this situation. What should the capacity team do, and what problem does this represent?

Scenario B: A hospital's IT team discovers that their single patient portal database server has reached its maximum RAM configuration (512 GB) and query response times are still degrading as the patient population grows. What are their scaling options and what is the limitation of the current approach?

Scenario C: A news website normally handles 50,000 visitors per hour. When a major breaking story is published, traffic can spike to 800,000 visitors per hour within minutes — unpredictably. They want to ensure service quality during spikes without paying for 16× normal capacity all the time. What capacity approach should they implement?

Capacity Planning — Exam Tricks