Explanation:

Salesforce Prompt Builder maintains version history for prompt templates. When a prompt template is deployed (for example, from a sandbox to production), the deployment includes all versions of that prompt template that exist in the source org—not just the currently active or latest version.

This preserves the template's version history in the target org, allowing administrators to review or activate different versions after deployment if needed.

Why the Other Options Are Incorrect

A. ❌ Deploying a template requires all previous versions to be manually activated before deployment can succeed.
This is incorrect.
There is no requirement to activate every previous version before deployment.
Activation status does not determine whether deployment succeeds.

B. ❌ Deploying a template automatically removes all prior versions and replaces them with the deployed version in production.
This is incorrect.
Deployment does not delete the existing version history and replace it with a single version.
Prompt template deployments are designed to preserve version history rather than overwrite it.

Reference
Salesforce Prompt Builder documentation on prompt template versioning and deployment.
Salesforce Agentforce Specialist (AI-201) Exam Guide – Prompt Builder and prompt template lifecycle.

Exam Tip

Remember how Prompt Builder handles versioning:

✅ Deployment includes all prompt template versions from the source org.
❌ You do not need to activate every version before deployment.
❌ Deployment does not replace the entire history with only the latest version.

Exam clue: If the question mentions sandbox, production deployment, and multiple saved versions, the expected answer is that all versions are included in the deployment.

Explanation:

Option B is the best and most deterministic solution. In Agentforce, you achieve reliable, enforceable control using variables combined with available when filter conditions on actions.

Store the verification status (e.g., is_verified boolean) in a custom variable (set by the verification action).
Apply an available when condition (e.g., @variables.is_verified == True) to the account lookup action.

When the condition evaluates to false, the platform completely hides/removes the action from the tool list presented to the LLM/reasoning engine. This is a hard, platform-level gate — not something the model can reason around, bypass, or hallucinate past.

This is the standard pattern for security-sensitive flows (e.g., verification before accessing account data, refunds, etc.).

Why not the others?

A: Einstein Trust Layer Prompt Defense policies are useful for data masking, PII protection, toxicity, etc., but they operate at the prompt/response level and do not deterministically control action availability in the reasoning process.

C: Natural language instructions in the subagent are probabilistic. The LLM might ignore, misinterpret, or creatively bypass them under certain prompts. This is not deterministic for critical security rules.

Key References:
Agent Script documentation: available when clauses provide conditional action availability that is evaluated before the prompt reaches the LLM, making behavior deterministic.
Variables act as structured short-term memory and enable guard clauses/filters for security and sequencing.

Explanation:

Agentforce Agent Script supports hybrid reasoning, which allows developers to mix flexible, declarative instructions (interpreted by the LLM for natural conversation) with procedural instructions (prefixed by ->) that enforce deterministic execution order. This ensures that critical steps — such as identity verification — are always executed before sensitive actions like account access, while still allowing the agent to respond naturally to customer inquiries.

Option A is incorrect because hybrid reasoning does not involve multiple LLMs; it’s about combining declarative and procedural instructions within a single script.

Option B is incorrect because hybrid reasoning is not tied to Canvas vs. Script View editors; it’s about instruction types, not UI editors.

Option C is correct because it captures the essence of hybrid reasoning: blending declarative flexibility with procedural guarantees.

Reference:
Salesforce Documentation: Agentforce Agent Script Hybrid Reasoning
Trailhead Module: Agentforce Script Basics
Salesforce Developer Guide: Instruction Patterns in Agentforce

Explanation:

Why C is correct:
Salesforce provides a centralized, administrative control point for managing which LLMs (Large Language Models) are available for use across the organization. This is done through the Model Provider settings in Einstein Setup.

In Einstein Setup, administrators can enable or disable specific model providers (e.g., OpenAI, Azure OpenAI, Anthropic, Google Vertex AI, or Salesforce-hosted models like Einstein GPT) and individually select which specific models (e.g., GPT-4, Claude 3, etc.) are active.

When a model provider or a specific model is disabled at this administrative level, it becomes unavailable to all users, agents, and prompt templates across the entire organization. Developers simply cannot select or route prompts to disabled models.

This is a governance control that operates at the platform level, ensuring that only approved and vetted models are used enterprise-wide—exactly what Universal Containers needs for compliance and audit purposes.

Why A is incorrect:
Attribute-Based Access Control (ABAC) is used to control access to records and data based on user attributes (e.g., department, role, or custom permissions). It is not designed to block prompts from routing to specific LLMs. The Einstein Trust Layer handles data privacy, masking, and audit, but ABAC does not govern which models are available at the provider level.

Why B is incorrect:
Writing a system instruction (e.g., "Never use external models for reasoning") is a natural language guideline for the LLM's behavior. It is a soft control that the LLM can misinterpret, ignore, or be jailbroken to bypass. It does not actually prevent developers from selecting unapproved models in Prompt Builder or Agent Builder. System instructions guide the agent's responses but do not enforce governance restrictions on model selection.

References:
Salesforce Official Documentation: "Manage Large Language Models in Einstein Setup" – explicitly states that administrators control which LLMs are available across the organization by enabling/disabling model providers and specific models in Einstein Setup.

Trailhead Module: "Einstein Trust Layer and Governance" > Unit: "Control Access to LLMs" – explains that the Model Provider section is the primary governance mechanism for restricting model usage, while system instructions and ABAC serve different purposes.

Agentforce Exam Guide (AI-201): Under "Governance and Compliance" – emphasizes understanding the administrative controls for LLM access, distinguishing between platform-level enablement (Model Provider) and behavioral guidelines (system instructions).

Explanation:

Prompt Builder offers two primary supported methods for a business stakeholder to bring Data Cloud data into a prompt template for grounding:

Data Cloud related lists — When a Data Cloud object is related to the primary object used in the prompt template (e.g., related to a Case, Account, or Contact record), you can pull in fields via related list merge fields directly in the template.

Prompt-initiated Flows — A Flow can be invoked from within the prompt template to query Data Cloud (e.g., using a Data Cloud query or DMO lookup within the flow), and the retrieved data is passed back into the prompt as grounding context.

These two methods represent the standard, supported approaches for a business stakeholder (a less technical persona) working within Prompt Builder to access Data Cloud data without needing deep technical setup like retrievers or vector search indexes (which are more relevant to unstructured/semantic search scenarios, typically handled by more technical roles like Agentforce Specialists).

Why the other options are incorrect:

A: While Flex templates can reference DMOs directly, this is a more advanced/technical capability typically used by an Agentforce Specialist or technical builder setting up structured grounding — not necessarily the primary method being described for a general business stakeholder. Including it here makes the option overly broad relative to what the question is testing (the standard, stakeholder-accessible methods).

C: External APIs are not the mechanism for accessing Data Cloud data within Prompt Builder — Data Cloud data is natively accessible within the Salesforce/Data Cloud ecosystem via related lists, DMOs, and flows. There's no need (or supported pattern) to import Data Cloud data via external APIs for this purpose.

Reference:
Salesforce Prompt Builder documentation — "Ground Prompts with Data Cloud" (related lists and flow-based grounding for Data Cloud objects).