A summer tourism site for a lakeside town needs inexpensive elastic capacity for only three peak months. Which cloud model best fits that use case?
Select an answer to reveal the explanation.
Short Explanation
Three hot months of visitors, then quiet—that is a public-cloud sweet spot. Pay for the surge, shed it when the lake freezes over. Building a private cloud for a seasonal brochure site is usually overkill.
Full Explanation
Public cloud fits inexpensive elastic capacity for an internet-facing tourism site that only needs three peak months. The town can scale out for summer demand and reduce capacity afterward without building a private cloud estate or keeping peak hardware idle all winter. Variable, time-bounded citizen websites are a textbook public-cloud use case.
Mandating private cloud because seasonal websites supposedly legally require exclusive on-premises hardware invents a universal legal rule that is not the fundamentals answer. Requiring hybrid because any tourism mention must keep servers in city hall confuses branding with architecture. Claiming colocation only can serve internet-facing sites while denying elastic public capacity contradicts how public cloud commonly hosts websites.
Exam caveat: data classification, accessibility, and records rules still apply on public cloud; “best fit for elasticity” does not mean “no controls required.” Operational check: estimate peak versus off-season capacity, confirm the site can scale down after tourist season, and compare that OpEx pattern to buying private hardware sized for August all year. Public cloud also reduces the need to staff seasonal hardware lifecycle work for a brochure-style site; the town still must configure TLS, content ownership, and access to the publishing tools, but it avoids buying winter-idle servers sized only for July traffic.