A tourism app must survive traffic spikes without waiting a week for hardware purchasing. Which cloud benefit is primarily under test?
Select an answer to reveal the explanation.
Short Explanation
Festival weekend hits and the tourism site needs muscle now, not after a purchase order ages in someone’s inbox. Cloud scalability is the express lane—capacity shows up when the crowd does.
Full Explanation
Surviving traffic spikes without waiting a week for hardware purchasing points primarily to rapid elasticity and scalability: in the cloud you can add capacity quickly instead of enduring CapEx procurement delay. Festival-driven tourism traffic needs that express lane for capacity when the crowd arrives this weekend, not after a purchase order clears next month.
Mandatory CapEx delays that force a week-long wait before any capacity change describe the problem, not the cloud benefit. Deleting the app during festivals avoids the scaling decision rather than solving demand. Claiming cloud scalability requires mailing physical servers to each tourist overnight misunderstands elastic cloud capacity.
Exam caveat: elasticity stresses speed of change; scalability stresses ability to grow (and often shrink) to match demand. Exam language may use either or both—anchor on capacity when the crowd arrives, without long hardware lead time, and do not invent a requirement to ship metal overnight.
Operational check: time how long it takes to add instances to the tourism web tier in a drill (minutes) versus the last on-premises server purchase cycle (days or weeks), and present that delta to leadership as evidence of the elasticity and scalability benefit before peak season.