Name the desired outcome
Availability concerns whether a service can be used when needed. Scalability concerns adjusting resources to demand. Reliability includes recovering from failure and continuing the required function. Predictability concerns reasoning about likely performance or cost under stated assumptions. These concepts can support one another, but a change that addresses one does not establish all the others. For example, a larger virtual machine may handle more processing without removing a shared dependency, and a cost forecast does not test restoration.
Capacity and failure are different dimensions
Vertical scaling changes an individual resource’s capabilities, such as CPU or memory. Horizontal scaling changes resource count: adding is scale-out and removing is scale-in. Neither direction, by itself, states where copies are placed or which dependencies they share. For availability reasoning, trace the named failure through each path serving the application. For reliability reasoning, ask what recovery behavior has actually been exercised. Avoid converting an infrastructure option or a service-specific SLA into an unconditional promise about the whole application.
Worked example
A fictional ticketing application has two active processors, both using the same explicitly supplied component Z. In the simplified exercise, a Z outage stops both processors; requests can otherwise reach either one. Adding memory to each processor can improve capacity but leaves the common failure path. Adding a third Z-dependent processor has the same limitation. If the requirement is to retain one running path when Z alone fails, a path with a dependency explicitly independent of Z addresses that requirement. The conclusion is about the supplied dependency model, not a guarantee that every Azure service or placement automatically behaves this way.
Prediction needs its own evidence
A separate question asks how much capacity a workload needs for a response-time target. Repeatable load observations and clearly stated capacity assumptions make that investigation meaningful. Cost prediction needs usage quantities, relevant rate assumptions and the boundaries of what is included. A tested recovery copy, an administrative-role audit and a residency inventory can all be valuable, yet none substitutes for those direct observations. Predictions remain conditional: changed workload, resource behavior or prices can invalidate earlier assumptions. Record what was measured and what was merely assumed.
Transfer check
A fictional photo-processing service keeps each worker’s CPU and memory constant but removes three workers when queued demand falls. Which scaling direction is described, and does it prove recovery from a regional outage? Check basis: reducing worker count is horizontal scale-in. It says nothing by itself about regional failure or restoration. State the variable that changed and the different evidence a recovery claim would need. Then attempt the linked independent cases; do not use this teaching example as a substitute for reading each task’s failure or workload condition.
Try it, then explain it.
Complete a short set without looking at the example. After each answer, explain which evidence or rule supports your decision and why the alternatives do not fit.
Sources & authorship
Original OpenExam explanations and examples. References support the concepts; they are not the source of copied questions. Independent educator review is pending.
Describe the benefits of high availability and scalability in the cloudDescribe the benefits of reliability and predictability in the cloud