A 311 platform must keep answering residents while the primary foundation-model configuration undergoes a maintenance window. Which deployment strategy best preserves continuity?
Select an answer to reveal the explanation.
Short Explanation
You can keep residents getting answers by switching to a preapproved fallback while the primary configuration is maintained. Think of it as a bypass that keeps 311 running until you restore the primary.
Full Explanation
Hot-swapping traffic to a preapproved fallback foundation-model configuration during primary maintenance, then restoring the primary, preserves continuity: residents can keep getting 311 answers while operators change configurations under change control. Validate the fallback in advance for tone, Guardrails, knowledge grounding, and IAM so the swap is a controlled traffic shift, not a live experiment. Taking the chatbot offline leaves residents without automated answers despite a planned change that a fallback could mitigate. Deleting the primary configuration to force a hard error turns a maintenance window into an outage; fail-fast behavior can help contain a bad deployment, but it is not a continuity strategy when a validated alternate exists. Showing a static maintenance notice and answering queued questions only after restoration delays every resident response until the window ends, when a validated fallback could keep answering throughout. Exam caveat: fallback quality may be lower, such as with a smaller model or older prompt pack. Tell operations about that tradeoff, keep Guardrails enabled, and set restoration criteria so the temporary path does not become the accidental permanent primary. Practical check: document primary and fallback Bedrock or equivalent configurations, rehearse traffic shifts in staging with production-like prompts, monitor errors, latency, and deflection during the window, and verify primary restoration with smoke tests before closing the change ticket.