Free ADM-201 practice questions

When does a validation rule evaluate its formula and potentially block a record from being saved?

• AWhen the record is saved, whether the save comes from the UI, the API, or a data import, if the formula evaluates to true.check_circle Correct
• BOnly when a user edits the record manually through a Lightning record page, not during any automated process.
• CAfter the record is committed to the database, so the record saves first and the error appears on the next edit.
• DOnly during Data Loader operations, because the UI relies on required-field settings instead of validation rules.

Why A is correct: Validation rules run on every save regardless of source, and the record is blocked when the formula returns true, so this correctly states both the timing and the trigger condition.

Why B is wrong: It is tempting to think validation only guards manual edits, but rules also fire on API and automation-driven saves, so limiting them to manual edits is wrong.

Why C is wrong: This misplaces the timing: validation runs before commit and stops the save outright, rather than allowing the record to save and surfacing an error later.

Why D is wrong: Validation rules apply to UI saves as well as Data Loader, and required-field settings are a separate control, so restricting rules to Data Loader is incorrect.

What is the primary purpose of designating a custom field as an External ID when importing data with Data Loader?

• AIt encrypts the field value so the external key cannot be read by users without the View Encrypted Data permission.
• BIt forces the field to become required on every page layout so external records cannot be saved without a key.
• CIt automatically converts the field into a lookup relationship pointing back to the source object.
• DIt lets records be matched to existing Salesforce records during an upsert so external keys map to Salesforce IDs.check_circle Correct

Why A is wrong: Encryption is a separate field feature and sounds security-relevant, but marking a field as an External ID does not encrypt it; the two settings are unrelated.

Why B is wrong: Required behaviour is set on the layout or field definition, not by the External ID flag, so this confuses two independent settings even though external keys are often mandatory in practice.

Why C is wrong: External ID and relationship fields are different field types; flagging a field as an External ID never creates a lookup, so this is a plausible-sounding but incorrect mechanism.

Why D is correct: An External ID stores a unique identifier from an outside system and can be used as the match key in an upsert, letting Data Loader decide whether to insert or update each row.

In Salesforce duplicate management, what is the difference between a matching rule and a duplicate rule?

• AA matching rule permanently merges duplicates on a schedule, while a duplicate rule only reports how many duplicates exist.
• BA matching rule defines the criteria used to identify duplicate records, and a duplicate rule decides what action to take when a match is found.check_circle Correct
• CA matching rule blocks the save of any duplicate, while a duplicate rule simply logs the attempt for administrators to review later.
• DA matching rule applies only to leads, while a duplicate rule applies only to accounts and contacts across the whole org.

Why A is wrong: Neither rule auto-merges on a schedule; merging is a manual or separate job, so this misstates what both components do despite merging being a genuine duplicate-management task.

Why B is correct: The matching rule specifies which fields and logic determine a match, and the duplicate rule invokes that matching rule and sets the action, such as allow, alert, or block, so this correctly separates their roles.

Why C is wrong: Blocking or alerting is the duplicate rule's action, not the matching rule's job; the matching rule only identifies candidates, so the responsibilities are reversed here.

Why D is wrong: Both rule types work across supported objects including leads, accounts, and contacts, so tying each to a single object is an invented limitation.

At Kalgoorlie Analytics, the organisation-wide default for the Contract object is Public Read Only. The compliance team, defined as a public group, must be able to edit every Contract record regardless of owner, but no other change to the baseline is wanted. Which configuration achieves this with the least disruption?

• ACreate an owner-based sharing rule that shares Contract records owned by all internal users with the compliance public group at Read/Write access level.check_circle Correct
• BChange the Contract organisation-wide default to Public Read/Write so that everyone, including the compliance group, can edit all Contract records without further configuration.
• CCreate a criteria-based sharing rule on Contract that shares all records with the compliance public group at Read/Write access level.
• DAssign the compliance group members a permission set with the Modify All permission for the Contract object, which grants edit access to all Contract records.

Why A is correct: Correct. An owner-based sharing rule keyed on records owned by all internal users grants the compliance group Read/Write across every record while leaving the Public Read Only baseline untouched for everyone else.

Why B is wrong: Tempting because it guarantees the compliance team can edit, but it grants edit access to the entire organisation, which contradicts the requirement to change nothing else about the baseline.

Why C is wrong: Tempting because sharing rules can grant Read/Write, but a criteria-based rule keys off field values on the record; with no meaningful criterion to match every record this is the wrong sharing-rule type for an all-records share.

Why D is wrong: Tempting because Modify All on an object does grant edit to all its records, but it also bypasses sharing entirely and is a broad object permission rather than the targeted record-sharing the requirement calls for; it cannot be assigned to a public group, only to profiles or permission sets per user.

At Fremantle Solar, most users share the Standard User profile, which grants no access to the custom Warranty Claim object. A project team of eight users, drawn from three different profiles, now needs Read and Edit access to Warranty Claim and to a single new field on it. The administrator wants a maintainable approach that does not alter what other users on those profiles can do. What should the administrator do?

• AEdit each of the three profiles to add Read and Edit object access plus field-level Edit access, since profiles are where object and field permissions are defined.
• BCreate one permission set granting Read and Edit on Warranty Claim and Edit on the new field, then assign it to the eight users regardless of their profile.check_circle Correct
• CMove all eight users onto a new shared profile that includes the Warranty Claim access, so they are managed together going forward.
• DCreate a sharing rule that shares Warranty Claim records with a public group containing the eight users at Read/Write access.

Why A is wrong: Tempting because profiles genuinely control object and field access, but editing the profiles would grant the access to every user assigned to them, not just the eight team members, violating the no-side-effects requirement.

Why B is correct: Correct. A single permission set layers the extra object and field access onto whichever profile each user already has, so only the assigned eight gain it and the underlying profiles remain unchanged.

Why C is wrong: Tempting because a dedicated profile would carry the access, but a user can hold only one profile, so reassigning them would strip whatever other settings their original three profiles provided and is far less maintainable than a permission set.

Why D is wrong: Tempting because it targets exactly eight users, but sharing rules control record-level access and cannot grant object or field-level permissions; with no object access the users still could not see the tab or the field.

At Derwent Publishing, the administrator is designing a custom Royalty Line object that must always belong to a parent Book record, inherit the parent's sharing so that anyone who can see the Book can see its royalty lines, and roll up total royalties onto the Book. Which relationship should the administrator use, and why?

• AA lookup relationship, because it links each Royalty Line to a Book and lookups automatically inherit the parent record's sharing settings for the child.
• BA hierarchical relationship, because it is the standard way to enforce a parent-child link that inherits sharing and rolls up numeric totals to the parent.
• CA master-detail relationship, because the detail record inherits the parent's sharing and record-level access, and master-detail supports roll-up summary fields on the parent.check_circle Correct
• DA lookup relationship marked as required, because making the lookup mandatory forces the child to inherit the parent's ownership and enables roll-up summary fields.

Why A is wrong: Tempting because a lookup does link the records, but a lookup child has its own sharing and org-wide default and does not inherit the parent's access, so the visibility requirement would fail.

Why B is wrong: Tempting because the name suggests parent-child structure, but hierarchical relationships exist only on the User object to reference a manager and cannot be used between custom objects or support roll-up summaries.

Why C is correct: Correct. In a master-detail relationship the detail record has no owner and inherits the master's sharing and access, and only master-detail permits roll-up summary fields, satisfying both requirements.

Why D is wrong: Tempting because a required lookup does force a parent value, but making a lookup required does not transfer ownership or sharing, and roll-up summary fields are not available on the parent of a lookup relationship.

How does deleting a parent record differ between a master-detail relationship and a lookup relationship when related child records exist?

• AIn both relationship types the child records are automatically deleted along with the parent record.
• BIn both relationship types the child records are retained and the relationship field is simply cleared.
• CIn a master-detail relationship the child (detail) records are deleted with the parent, whereas in a lookup relationship the children are retained by default.check_circle Correct
• DIn a lookup relationship the child records are deleted with the parent, whereas in a master-detail relationship they are retained.

Why A is wrong: This is tempting because both relationships link a child to a parent, but only master-detail cascades the delete. A lookup does not delete its child records by default.

Why B is wrong: This describes only the lookup behaviour. In a master-detail relationship the detail records cannot survive without their master, so they are cascade-deleted rather than retained.

Why C is correct: Master-detail is a tightly coupled relationship where the detail record cannot exist without its master, so deleting the master cascades the delete to the children, while a standard lookup leaves the child records in place.

Why D is wrong: This reverses the two behaviours. Cascade delete belongs to master-detail because of its tight coupling, not to the loosely coupled lookup relationship.

Which statement best distinguishes a standard object from a custom object in Salesforce?

• AA standard object is provided by Salesforce out of the box, whereas a custom object is created by an administrator and its API name carries the __c suffix.check_circle Correct
• BA standard object can hold custom fields, whereas a custom object can hold only the fields Salesforce predefines for it.
• CA standard object supports page layouts and validation rules, whereas a custom object supports neither of those features.
• DA standard object stores records in the org, whereas a custom object stores its records only in an external system.

Why A is correct: Standard objects such as Account and Contact ship with the platform, while custom objects are defined in the org and are identified by the __c suffix on their API name.

Why B is wrong: This is backwards in part. Both standard and custom objects can hold administrator-created custom fields, so the ability to add fields does not distinguish them.

Why C is wrong: Custom objects fully support page layouts, validation rules, and most declarative features, so this is not a valid distinction between the two.

Why D is wrong: Custom objects store records inside Salesforce like standard objects. Records held in an external system belong to external objects, which are a separate concept.

An administrator needs a field on a parent object that automatically totals the value of a currency field across its related child records. Which relationship must connect the two objects for this to be possible?

• AA lookup relationship, because it links the two objects and lets the parent reference all of its children.
• BAn external lookup relationship, because it aggregates values from records stored in an external system.
• CA hierarchical relationship, because it rolls values up through successive levels of the same object.
• DA master-detail relationship, because a roll-up summary field can aggregate child values only from the detail side.check_circle Correct

Why A is wrong: A lookup does link the objects, but it is loosely coupled and cannot support a roll-up summary field, so it cannot aggregate the child values automatically.

Why B is wrong: External lookups link to external objects sourced outside Salesforce and do not provide roll-up summary aggregation onto a standard parent record.

Why C is wrong: A hierarchical relationship is a special lookup available only on the User object and does not provide roll-up summary aggregation of child field values.

Why D is correct: A roll-up summary field can be created only on the master side of a master-detail relationship, so this coupling is required to total, count, or find the minimum or maximum of the related detail records.

A record-triggered flow must update a field on the same record that caused it to run. Which run timing performs this update most efficiently, and why?

• AAfter-save, because only after-save flows are able to read the field values on the record that triggered the flow.
• BAfter-save, because a before-save flow is not permitted to assign values to fields on the triggering record at all.
• CBefore-save, because the change is applied in the same transaction before the record is committed, avoiding a second save operation.check_circle Correct
• DBefore-save, because a before-save flow can call Apex and email actions that write the field more quickly than a save.

Why A is wrong: Tempting because after-save flows are common, but wrong: both before-save and after-save flows can read the triggering record's field values, so this is not a reason to prefer after-save.

Why B is wrong: Tempting through confusion over before-save limits, but wrong: assigning to the triggering record's own fields is exactly what before-save flows are designed to do.

Why C is correct: Correct: a before-save flow modifies the triggering record in memory before it is written, so the same-record field update needs no extra DML and runs fastest.

Why D is wrong: Tempting because before-save is the right timing, but the reason is wrong: before-save flows cannot invoke actions such as Apex or email, which is why they are limited to fast field updates.

Which statement correctly describes a screen flow?

• AIt presents interactive screens to a user, so it must be launched from an interface such as a Lightning page, action, or button.check_circle Correct
• BIt runs entirely in the background on the server and is unable to display any screen to a user.
• CIt starts automatically when a record is created or updated, with no user present at the keyboard.
• DIt can be started only by a scheduled path that is defined inside Flow Builder for it.

Why A is correct: Correct: a screen flow contains screens the user reads and completes, so it needs a surface that a person opens, such as a Lightning page, quick action, or button.

Why B is wrong: Tempting because autolaunched flows behave this way, but wrong: describing a flow that shows no screens is the definition of an autolaunched flow, not a screen flow.

Why C is wrong: Tempting as a common trigger pattern, but wrong: automatic start on a record change describes a record-triggered flow, whereas a screen flow requires a user.

Why D is wrong: Tempting through confusion with scheduling, but wrong: a schedule launches a scheduled flow, and a screen flow cannot run on a schedule because it needs user input.

An administrator needs an automation that runs each night and processes every Opportunity that closed during that day. Which flow type fits this requirement?

• AA record-triggered flow configured to run whenever an Opportunity record is updated by a user.
• BA screen flow embedded on the Opportunity home page for an administrator to run manually.
• CAn autolaunched flow that is invoked in real time by a platform event message.
• DA scheduled flow with a defined start time and frequency that filters the records it runs against.check_circle Correct

Why A is wrong: Tempting because Opportunities do change, but wrong: a record-triggered flow reacts to each individual save, not to a nightly batch run over a set of records at a fixed time.

Why B is wrong: Tempting as a way to process records, but wrong: a screen flow needs a user to launch and step through it, so it cannot run unattended on a nightly timetable.

Why C is wrong: Tempting because autolaunched flows run without a user, but wrong: this fires on an event message rather than on a nightly clock, so it does not meet the scheduled batch requirement.

Why D is correct: Correct: a scheduled flow runs on a set schedule and can be given entry conditions so it processes only the records that match, such as Opportunities closed that day.

What must be true about a product before it can be given a price in a custom price book and sold on an opportunity?

• AThe product must first have a standard price recorded in the Standard Price Book before it can be given a list price in any custom price book.check_circle Correct
• BThe product must be defined as a master-detail child of the price book so that deleting the price book also deletes the product.
• CThe product must be assigned to a forecast category so that the revenue it generates rolls up into the pipeline correctly.
• DThe product must be owned by the same user who owns the opportunity on which it will eventually be sold.

Why A is correct: Correct: a product needs an active standard price before a custom price book entry can be created, so the Standard Price Book underpins every custom price book.

Why B is wrong: Tempting because master-detail governs many parent-child links, but products relate to price books through price book entries, not a master-detail relationship.

Why C is wrong: Forecast categories apply to opportunity stages, not to products, so this is an unrelated requirement invented for the product record.

Why D is wrong: Product and price book setup is org-wide reference data; record ownership of the opportunity has no bearing on whether a product can be priced.

Each opportunity stage in Salesforce can be associated with a forecast category such as Pipeline, Best Case, Commit, or Closed. Which statement correctly describes how forecast categories behave?

• AForecast categories are set independently on every opportunity and are not influenced by the stage the record is currently in.
• BEach opportunity stage maps to several forecast categories at once, and the user selects which one should apply.
• CForecast categories replace opportunity stages entirely, so an organisation configures one mechanism or the other but not both together.
• DEach opportunity stage is mapped to a single forecast category, so moving an opportunity to a new stage can update its forecast category automatically.check_circle Correct

Why A is wrong: Tempting because the Forecast Category field can be edited on a record, but the field is driven by a stage-to-category mapping by default, so the stage does influence it.

Why B is wrong: This confuses a one-to-one mapping with a one-to-many one; a stage is mapped to exactly one forecast category, not a menu of several.

Why C is wrong: Tempting as both summarise pipeline, but stages and forecast categories work together; the stage drives the category rather than replacing it.

Why D is correct: Correct: stage configuration includes the forecast category, so advancing the stage updates the category and rolls the amount into the matching forecast bucket.

An administrator enables a sales path (Path) on the Opportunity object. What does the sales path actually provide to users working an opportunity?

• AIt creates a second, independent set of stages that runs in parallel with the standard opportunity stage picklist.
• BIt presents the existing stage picklist as a guided sequence, with key fields and guidance for success configurable per stage, without adding new stage values.check_circle Correct
• CIt converts each opportunity stage into its own record type, each with a distinct page layout assigned to it.
• DIt replaces the opportunity Amount with a weighted amount calculated from each stage's probability percentage.

Why A is wrong: Tempting because the path looks like stages, but it is built on the existing stage picklist rather than introducing a separate parallel set of stages.

Why B is correct: Correct: a path sits on top of the stage picklist and surfaces the key fields and guidance for success for each stage, helping reps without changing the stages themselves.

Why C is wrong: This confuses paths with record types; a path guides users through stages but does not generate record types or reassign page layouts.

Why D is wrong: Weighted pipeline is a reporting concept; a path offers guidance and key fields and does not overwrite the Amount field with a probability calculation.

A company wants to accept customer emails as cases without installing any agent software behind its firewall, accepting the trade-off of a smaller limit on attachment and message size. Which capability meets this requirement?

• AOn-Demand Email-to-Case, which processes inbound email in the cloud with no locally installed agent, subject to lower size limits.check_circle Correct
• BWeb-to-Case, because it forwards every inbound customer email through the website form engine before a case is created.
• CThe standard Email-to-Case agent, because it must be installed locally to receive any inbound email that becomes a case.
• DAuto-response rules, which convert each acknowledgement email that Salesforce sends back to the customer into a new case.

Why A is correct: On-Demand Email-to-Case runs entirely in Salesforce with no agent behind the firewall and trades that convenience for smaller message and attachment size limits, matching the requirement exactly.

Why B is wrong: Web-to-Case handles website form submissions, not inbound email, so it does not turn emails into cases and does not fit the requirement at all.

Why C is wrong: This is tempting, but the standard agent is the option the company is trying to avoid, since it requires software behind the firewall; it does not satisfy the stated constraint.

Why D is wrong: Auto-response rules only send acknowledgement emails to customers; they do not ingest inbound email or create cases, so they cannot deliver this capability.

An administrator is comparing Web-to-Case and Email-to-Case as channels for capturing customer cases. Which statement correctly describes how these two features differ?

• AWeb-to-Case creates cases from messages sent to a routing address, while Email-to-Case captures cases from a form hosted on the company website.
• BBoth features require the customer to hold a Salesforce user licence before a case can be created from their submission.
• CBoth features route submissions only to a single named user and cannot direct new cases into a queue for a support team.
• DWeb-to-Case captures cases from an HTML form on a public website, while Email-to-Case creates cases from messages sent to configured support email addresses.check_circle Correct

Why A is wrong: This reverses the two features. Web-to-Case uses a website form and Email-to-Case uses routing addresses, so the mapping described here is backwards and wrong.

Why B is wrong: This is tempting because internal case creation needs a user, but both channels exist precisely to capture cases from external customers who have no Salesforce licence, so this is false.

Why C is wrong: This sounds plausible if you forget assignment rules, but cases from either channel can be routed to a queue through case assignment rules, so the claim is incorrect.

Why D is correct: This is the correct distinction: Web-to-Case turns website form submissions into cases, and Email-to-Case converts inbound emails to designated support addresses into cases.

In case management, what is the primary purpose of assigning new cases to a queue rather than directly to an individual user?

• AA queue automatically closes each case after a fixed number of days so that the backlog can never grow beyond a set size.
• BA queue holds cases as a shared backlog that any of its members can view and take ownership of when they are ready to work them.check_circle Correct
• CA queue grants every member permanent edit access to all case fields regardless of the object's field-level security settings.
• DA queue permanently reassigns each case to the most recently active member so that no case is ever left unowned.

Why A is wrong: This is tempting because it sounds like workload control, but queues never close cases on a timer; case closure is a manual or automated status change unrelated to the queue itself.

Why B is correct: This is the core role of a queue: it owns records temporarily so that any member can monitor the shared list and accept ownership, which is ideal for distributing case workload across a team.

Why C is wrong: This confuses record routing with field access; queue membership affects record ownership and visibility, not field-level security, which is still governed by profiles and permission sets.

Why D is wrong: This sounds like load balancing, but a queue does not push cases to individuals; members pull cases by accepting ownership, and cases remain queue-owned until then.

In Salesforce activity management, what is the key distinction between a task and an event?

• AA task can be logged against a record, whereas an event can only exist on a user's personal calendar and cannot relate to any record.
• BA task is a to-do item with a due date and a status, whereas an event is a scheduled activity that occupies a block of time with a start and an end.check_circle Correct
• CA task appears on the activity timeline, whereas an event appears only in reports and is never shown on a record's timeline.
• DA task can be assigned to another user, whereas an event is always owned by the person who created it and cannot be reassigned.

Why A is wrong: This is tempting because events are calendar items, but it is wrong: events can be related to records through the Name and Related To fields just as tasks can.

Why B is correct: Correct: tasks track work to be completed and carry a status such as Not Started or Completed, while events are calendared items with a specific start and end time.

Why C is wrong: This is tempting because timelines emphasise tasks, but it is wrong: both open events and open tasks appear on the activity timeline of a related record.

Why D is wrong: This is tempting because tasks are often reassigned, but it is wrong: events also have an owner and assigned user and can be reassigned like other activities.

On a standard Lightning record page, what does the activity timeline primarily display?

• AA list of every field change made to the record, ordered by the time each change was saved.
• BThe Chatter posts and comments made about the record, grouped by the user who posted them.
• CUpcoming and past activities such as tasks, events, calls, and emails logged against the record, ordered by date.check_circle Correct
• DThe list of reports and dashboards that reference the record's object across the org.

Why A is wrong: This describes field history tracking, not the activity timeline, so it is a tempting but incorrect confusion of two separate features.

Why B is wrong: Chatter posts appear in the Chatter feed component, which is distinct from the activity timeline, so this mixes up two related but separate collaboration surfaces.

Why C is correct: Correct: the activity timeline consolidates open and completed activities for the record, including tasks, events, logged calls, and emails, in date order.

Why D is wrong: The timeline never lists reports or dashboards, so although analytics feel related to a record, this option describes something the timeline does not do.

An administrator wants to extend Salesforce by installing a pre-built application built by a third-party partner. Where should the administrator look for such a package?

• AOn the AppExchange, the Salesforce marketplace where partners publish managed packages and apps for installation.check_circle Correct
• BIn Setup under Schema Builder, which lists installable applications alongside the org's object model.
• CIn the Data Import Wizard, which packages third-party applications together with their sample data for loading.
• DIn the App Launcher, which downloads new applications from external vendors on demand.

Why A is correct: Correct: the AppExchange is the marketplace for finding and installing partner-built apps, components, and managed packages into an org.

Why B is wrong: Schema Builder visualises objects and relationships and does not distribute installable apps, so it is a plausible-sounding but incorrect location.

Why C is wrong: The Data Import Wizard loads records into existing objects and has nothing to do with installing applications, making this a tempting mix-up of two Setup tools.

Why D is wrong: The App Launcher only opens apps already available in the org; it does not source or install new third-party packages, so this confuses navigation with distribution.

Which statement about how an Agentforce agent respects Salesforce security when it executes an action is true?

• AThe agent runs its actions as a defined agent user and is constrained by that user's profile and permission set access.check_circle Correct
• BThe agent bypasses object and field-level security because it is an internal platform process rather than a user.
• CThe agent inherits the profile of whichever end user is chatting, changing its access on every conversation.
• DThe agent enforces organisation-wide defaults only and disregards field-level security entirely when it reads data.

Why A is correct: Correct. Agent actions execute in the context of an assigned user, so object, field, and record access follow that user's profile and permission sets, and the agent cannot surface data the user could not see.

Why B is wrong: Agents do not bypass the security model. This tempts candidates who assume automation ignores permissions, but agent actions are bound to a user's access.

Why C is wrong: The agent operates under its own configured agent user, not the chatting user's profile. The option is plausible because access does matter, but the running context is fixed to the agent user.

Why D is wrong: Field-level security still applies to agent actions, so ignoring it is incorrect. Naming org-wide defaults makes this sound informed while omitting the layers that also apply.

When a user sends a request to an Agentforce agent, how does the agent decide which set of actions to consider for that request?

• AIt applies the first matching assignment rule entry and uses the actions linked to that rule.
• BIt evaluates the requester's place in the role hierarchy and considers only actions owned above that user.
• CIt runs every action defined in the agent in sequence and keeps whichever result the user accepts.
• DIt uses the reasoning engine to classify the request against the topic descriptions and selects the matching topic.check_circle Correct

Why A is wrong: Assignment rules route records such as cases and leads; they play no part in an agent's reasoning. The first-matching-entry wording is a real concept borrowed from the wrong feature.

Why B is wrong: The role hierarchy governs record sharing, not action selection. It is tempting because hierarchy drives visibility elsewhere, but it does not choose which topic an agent uses.

Why C is wrong: Agents do not brute-force every action; that would be inefficient and unsafe. The idea is plausible to someone unaware of topic classification but misrepresents how reasoning works.

Why D is correct: Correct. The Atlas Reasoning Engine interprets the request, matches it to a topic using the topics' classification descriptions, then works from that topic's available actions.

In the Agentforce architecture, which component masks sensitive data and screens generated responses for toxicity before they reach the user?

• AThe reasoning engine, which interprets each request and matches it to the most relevant configured topic.
• BThe Einstein Trust Layer, which masks sensitive data and evaluates responses for toxicity as part of its safeguards.check_circle Correct
• CData Cloud, which unifies records from many systems so the agent can be grounded in trusted context.
• DAgent Builder, which is the tool an administrator uses to define the agent's topics, actions, and instructions.

Why A is wrong: The reasoning engine handles request interpretation and topic selection, not data masking or safety screening. It is a genuine component, which makes it a plausible but incorrect pick.

Why B is correct: Correct. The Einstein Trust Layer provides the security and safety controls, including data masking and toxicity detection, that protect data and users as the agent generates responses.

Why C is wrong: Data Cloud provides grounding data; it does not perform toxicity checks or mask outputs. Its role in grounding makes it tempting to over-attribute safety duties to it.

Why D is wrong: Agent Builder is the design-time configuration tool, not a run-time safety control. It is plausible because admins spend time there, but it does not mask data or check for toxicity.