A tool-library kiosk must finish a waiver summary before the borrower loses a place in line. Overnight handbook rewrites can wait several minutes. Which application constraint should pick the model and hosting style?
Select an answer to reveal the explanation.
Short Explanation
Think of a kiosk waiver that has to finish before the borrower loses their place. That latency SLA picks the model. Overnight handbook rewrites can take the slow path.
Full Explanation
The tool-library kiosk must finish a waiver summary before the borrower loses a place in line, while overnight handbook rewrites can tolerate several minutes. Those are different latency envelopes, so the application constraint that should pick the model and hosting style is the kiosk latency SLA. Interactive borrower flow needs a fast path; batch overnight work can use a slower, possibly cheaper path without harming the line.
Always picking the slowest path even for the kiosk line fails because it ignores the interactive SLA and will drop borrowers from the queue. Claiming latency never differs between a live kiosk and an overnight rewrite fails because online and batch workloads have different acceptable delays by design. Ignoring the line and picking by which model name sounds newer fails because novelty is not a latency requirement and does not protect place-in-line experience.
Exam caveat: the same organization often runs both interactive and batch GenAI jobs; model and hosting choices should follow the latency class of each job, not a single default. Operational check: publish a kiosk p95 latency budget for waiver summaries, measure candidates against that budget under queue load, and route overnight handbook rewrites to a separate slower queue or model tier.