A startup wants to deploy a Foundry-hosted model for a customer-facing app with unpredictable traffic, ranging from a few requests per hour to sudden spikes during marketing campaigns, and wants to avoid paying for idle infrastructure between spikes. Which deployment option best fits this pattern?
Select an answer to reveal the explanation.
Short Explanation
The traffic pattern here is a handful of quiet hours followed by unpredictable bursts, which is exactly the situation pay-as-you-go, usage-based billing was built for: you are charged for what actually gets used, not for capacity sitting around waiting for a spike that might not come for hours. Reserving a fixed chunk of compute sized for the busiest campaign moment and leaving it running around the clock means paying peak prices during every quiet hour too. Turning the whole thing off overnight does not help if a spike happens to land outside business hours, which marketing campaigns are not obligated to respect. And locking in the cheapest, smallest compute tier no matter what is a recipe for the app slowing down or failing at the exact moment a campaign sends a rush of new traffic. Usage-based billing is the option that naturally follows the traffic wherever it goes.
Full Explanation
The correct answer is C. A serverless API deployment bills based on actual token usage rather than requiring a reserved block of compute, which matches a workload that swings from a handful of requests per hour to sudden campaign-driven spikes without the team paying for capacity that sits idle most of the time. Option A is incorrect because sizing managed compute for peak traffic and running it continuously means paying for that peak-level capacity even during the many quiet hours, which is the opposite of the cost efficiency the startup wants. Option B is incorrect because manually shutting the deployment down every night does not solve unpredictable within-day spikes, and marketing campaigns are not guaranteed to align with business hours, so real traffic could arrive while the service is off. Option D is incorrect because a fixed low compute tier will not handle sudden spikes in demand and risks slow responses or failures during exactly the moments, campaign launches, when reliable performance matters most. Serverless billing tied to actual usage is the option that scales automatically with the unpredictable pattern described.