Question 1
A company has already configured an Amazon Bedrock guardrail that encodes its approved safety policy: a list of denied topics and filters for harmful content. It now wants to apply that same policy to two additional workloads that do not call an Amazon Bedrock foundation model — a support assistant running a self-managed open-weight model on Amazon EC2, and a workflow that sends user text to a third-party model endpoint. In both cases the team wants to evaluate the user's text and the generated response against the existing guardrail at inference time, before the text is used. Which approach correctly meets this requirement?
A. This is not achievable: a guardrail only takes effect when it is associated with an inference request to a foundation model hosted in Amazon Bedrock, so both workloads must first be migrated to Bedrock-hosted models.
Reflects the misconception that a guardrail is inseparable from a Bedrock model invocation. Guardrails are an independent resource that can also be invoked on their own to assess arbitrary text, so migrating the models is not a prerequisite.
B. Fine-tune the self-managed model on examples of the prohibited topics so that refusal behaviour is trained into the model weights, because a guardrail cannot evaluate text unless a Bedrock model generates it.
Substitutes model training for an inference-time safeguard and repeats the false claim that guardrails cannot evaluate text standalone. Fine-tuning changes the model's tendencies but provides no deterministic, centrally maintained filter, and it would have to be redone per model rather than reusing the approved policy.
C. Configure Amazon SageMaker Model Monitor to scan the assistant's responses on a schedule and block any response that mentions a denied topic.
Confuses scheduled monitoring with an inline content filter. Model Monitor runs scheduled jobs that compare captured data and prediction quality against a baseline and emit alerts; it does not sit in the request path and cannot block an individual response for content-policy reasons.
D. Call the ApplyGuardrail API to evaluate the input text and the generated output against the existing guardrail independently, without invoking an Amazon Bedrock foundation model, and act on the guardrail's assessment in the application.Correct answer
Correct. Amazon Bedrock Guardrails expose an API that assesses any text against a configured guardrail without a model invocation, which lets the same approved policy be reused for self-managed and third-party models while remaining maintained in one place.
Explanation
Amazon Bedrock Guardrails are a standalone resource, not merely a setting on a model call: alongside associating a guardrail with a Bedrock inference request, the service offers an API for evaluating arbitrary text against a configured guardrail without invoking any foundation model, which is exactly what lets one approved safety policy be reused for models hosted outside Amazon Bedrock. Claiming the workloads must be migrated to Bedrock-hosted models misreads guardrails as inseparable from model invocation. Fine-tuning a model to refuse topics changes only the model's learned tendencies and gives no deterministic, centrally governed filter that can be applied consistently across applications. SageMaker Model Monitor addresses a different lifecycle stage entirely — scheduled comparison of production data and prediction quality against a baseline — and is not an inline content-safety control.