Free Salesforce-Data-360-Consultant Practice Test Questions (2026)

Explanation:
The requirement is to predict a numeric dollar amount—the total future spend on bookings over the next 12 months. In Einstein Studio, this is a classic regression use case. Regression models are specifically designed to predict continuous numeric outcomes such as currency amounts, counts, or likelihood percentages .

Correct Option:

B. Regression model.
Regression models predict a number, such as a currency amount, count, or likelihood percentage. Salesforce documentation explicitly lists "Customer lifetime value of an account" and "Amount of an opportunity" as example use cases for regression models . The luxury travel company's goal of estimating total dollar spend over the next 12 months is a direct numeric prediction, making regression the correct native model type. The model is trained on historical booking data to learn patterns and produce a numeric prediction for each unified profile.

Incorrect Option:

A. Foundational model.
Foundational models (or foundation models) are large language models used for generative AI tasks like text generation, summarization, or chat completions. They are not designed for numeric regression predictions like future spend amounts .

C. Binary model.
Binary classification models predict outcomes with two possible values, such as true/false, yes/no, or won/lost. This model type cannot predict a dollar amount, which is a continuous numeric value rather than a two-option outcome .

D. Multiclass model.
Multiclass classification models predict outcomes with three to ten distinct categorical values, such as a tier or reason code. This is unsuitable for predicting a numeric dollar amount like future booking spend .

Reference:
Trailhead: Get to Know Einstein Studio; Salesforce Help: Evaluate Model Quality.

Explanation:

This question tests understanding of relationship cardinality in Salesforce Data Cloud when modeling DMOs. The scenario describes a classic parent-child relationship for car ownership.

✅ Correct Option:

C. Many-to-One (N:1)
When creating the relationship from the Vehicle DMO to the Individual DMO, the architect should select Many-to-One (N:1). This means many Vehicles can relate to one Individual (one person can own multiple cars), while one Vehicle can only relate to one Individual (one car has only one owner). This is implemented via a lookup field on the Vehicle DMO.

❌ Incorrect options:

A. One-to-One (1:1)
One-to-One would restrict each Vehicle to one Individual and each Individual to only one Vehicle. This violates the requirement that one individual can own multiple vehicles.

B. Many-to-Many (N:N)
Many-to-Many allows multiple Vehicles to relate to multiple Individuals (e.g., shared ownership). This is unnecessary and overly complex for the stated requirement of single ownership per vehicle.

D. One-to-Many (1:N)
One-to-Many from Vehicle to Individual would mean one Vehicle can link to many Individuals, which contradicts the rule that one vehicle has only one owner.

🔧 Reference:
→ Data Cloud Data Modeling – Relationships
Explains cardinality options (1:1, 1:N, N:1, N:N) when creating relationships between DMOs.

Explanation:
When creating a segment in Data 360, the Segment Builder allows you to filter your audience using three distinct types of criteria: Direct Attributes, Related Attributes, and Calculated Insights. These three options cover both the core profile data and the advanced metrics needed to define precise audiences.

Correct Option:

B. Direct attributes, related attributes, and calculated insights.
Direct attributes are fields located directly on the primary DMO (e.g., Unified Individual), such as name or age. Related attributes are fields from connected DMOs (e.g., Purchase History or Engagement data), which require traversing a relationship path and are typically placed inside containers. Calculated Insights are complex metrics (e.g., Lifetime Value or Average Order Spend) that are computed via SQL and can be used as filters to refine your segment criteria.

Incorrect Option:

A. Only direct attributes and calculated insights.
This option excludes related attributes. Related attributes (such as product purchases or email engagement) are essential for behavioral segmentation and are definitely available in the Segment Builder.

C. Direct attributes, related attributes, calculated insights, and streaming insights.
This includes "streaming insights," which are not a standard segmentation criteria option. While Data 360 has "Streaming Insights" for real-time processing and alerts, they are not typically listed as a persistent filter criteria category in the standard Segment Builder alongside the other three.

D. Only direct attributes and related attributes.
This option excludes calculated insights. Calculated Insights are a core feature used to filter on aggregated metrics like "Total Sales Amount" or "Email Views per Quarter," making them a valid and important criterion for segmentation.

Reference:
Salesforce Help: Create a Segment; Trailhead: Data 360 Insights & Use Cases; Salesforce Help: Container Paths.

Explanation:

The question tests how to control the payload of related attributes sent during activation from Salesforce Data Cloud to external targets like Marketing Cloud. It highlights a scenario where a profile segment functions correctly, but unconstrained 1-to-many relationship paths cause extraneous historical engagement records to bypass the segment’s timeline intent.

✅ Correct Option:

C. Apply a 30-day date filter on the Sales Order DMO within the activation.
When a segment is built on the Individual profile grain, its criteria only determine which customers qualify. When including related 1-to-many child attributes (like Sales Orders) in the activation payload, Data Cloud pulls all historical records for those individuals by default unless an explicit activation filter is applied to that specific related object to restrict the output.

❌ Incorrect options:

A. Filter out older orders in Marketing Cloud after activation.
Filtering data after it reaches Marketing Cloud shifts data volume and processing overhead to the downstream system instead of keeping it source-governed. This creates unnecessary processing strain, delays journeys, and creates compliance and synchronization issues by moving unnecessary historical records out of Data Cloud.

B. Apply a data space filter to exclude orders older than 30 days.
Data space filters are global boundary controls used to govern permissions and partition data visibility for entire business units or brands. They are completely static and are not intended to dynamically restrict rolling time-based transactional windows for individual marketing campaign activation payloads.

D. Build a segment using the Sales Order DMO and filter orders to the last 30 days.
Changing the segmentation entity to the Sales Order DMO shifts the entire core grain from a profile audience to a transactional audience. While it limits orders, it changes the segmentation structure entirely and fails to natively resolve the issue of constraining related payload attributes on a profile-based activation.

🔧 Reference:
→ See Considerations for Selecting Related Attributes in Data 360 Activations which explains how activation filters constrain the records exported for 1-to-many related data model objects.

Explanation:
In Data 360 activations, related attributes are accessed by traversing specific relationship paths from the segment's primary DMO (typically Unified Individual). The activation attribute picker only displays attributes that are reachable through the currently selected path. If the desired attributes exist on a different branch of the data model—a separate DMO chain not connected through the active path—they will not appear in the available attributes list .

Correct Option:

A. The desired attributes reside on different related paths.
Data 360 activations require you to navigate a single relationship path at a time from the segment entity to related DMOs. When you select attributes from a related object, you are implicitly choosing a path. Attributes on other DMOs that connect through a different relationship chain remain hidden until you explicitly navigate to that path. This is by design—the activation UI filters attributes based on the currently selected container path to avoid ambiguity .

Incorrect Option:

B. The attributes are being used in another activation.
Attributes are not locked or reserved. They can be reused across unlimited activations without restriction .

C. Activations can only include 1-to-1 attributes.
This is false. Activations support both 1-to-1 (profile) and 1-to-many (related) attributes. Related attributes are a core feature of activations .

D. The segment is not segmenting on profile data.
Segmentation can be built on various DMOs, not exclusively profile data. Even if segmenting on a non-profile DMO, related attributes would still be accessible if the proper relationship paths exist .

Reference:
Salesforce Help: Considerations for Selecting Related Attributes in Data 360 Activations; Salesforce Help: Container Paths.

Explanation:

This question tests knowledge of how Salesforce Data Cloud configurations are packaged and migrated between environments using Change Sets. The key challenge is identifying the correct metadata component type that encapsulates a data kit — including data streams and identity resolution rules — for successful deployment.

✅ D. Data Package Kit Definition
In Salesforce Data Cloud, a data kit is represented in Change Sets as a Data Package Kit Definition component type. This metadata type bundles all associated configurations — including data streams and identity resolution rulesets — into a single deployable unit. Selecting this component ensures the entire kit structure is captured and transferred intact to the target org.

❌ A. Data Stream Configuration
While Data Streams are part of the kit, selecting them individually as a standalone component type does not ensure the full kit structure is preserved. Individual data stream components lack the packaging context needed to carry associated dependencies and rules across environments reliably.

❌ B. Identity Resolution Ruleset
Identity Resolution Rulesets are a sub-component within a data kit, not a top-level deployable unit for this scenario. Selecting this alone would only migrate the ruleset logic and would not capture the associated data streams or the overarching kit configuration required for a complete transfer.

❌ C. Data 360 Metadata Definition
This is not a recognized or valid component type within Salesforce Data Cloud Change Sets. It is a fabricated option designed to mislead. No such metadata component exists in the official Data Cloud deployment framework, making it an invalid selection for any migration scenario.

🔧 Reference:
→ Data Cloud – Deploy Data Kits with Change Sets – Salesforce Help
Confirms that Data Package Kit Definition is the correct component type to select when adding data kits to outbound Change Sets for cross-org deployment.

Explanation:
Einstein Studio predictive models are operationalized in Salesforce through two standard mechanisms: prediction jobs and Flow Builder. Prediction jobs run the model against Data 360 records to generate persisted scores stored in a Data Model Object (DMO), while Flow Builder's Action element calls the model on-demand to retrieve predictions for use in business process automation . Both are the architecturally correct methods for applying AI predictions to business workflows.

Correct Option:

D. Use the predict jobs feature or call the model via Flow Builder.
Prediction jobs process source DMO records through the model and write prediction outputs to a new DMO, enabling batch or streaming scoring . Flow Builder allows consultants to add the predictive model as an Action element, mapping record fields to model inputs and using the returned prediction to drive automation such as lead scoring updates, case routing, or personalized marketing .

Incorrect Option:

A. Manually export the CSV and re-import it into Service Cloud.
This is a non-standard, manual workaround that lacks automation and real-time capability. It does not leverage Einstein Studio's integration with Salesforce business processes .

B. Use the Identity Resolution tool to merge predictions with Individual records.
Identity Resolution is designed for deduplication and creating unified customer profiles, not for executing predictive models or applying their outputs to business logic .

C. Embed the Einstein Studio URL into a Lightning component.

Embedding a URL only provides a link to the studio interface; it does not integrate prediction data into Salesforce records or automated workflows .

Reference:
Salesforce Developers Blog: Using AI Model Output in Data Cloud with Prediction Jobs; Salesforce Help: Use Predictions from Einstein Studio Models; Salesforce Help: Get Predictions in Flows.

Explanation:

This question tests understanding of logical data isolation in Salesforce Data 360. The requirement is governance-level separation between business units while still operating under the same home org. The solution must isolate both data and metadata, not just access or UI-level visibility.

🟢 C. Use separate data spaces for each business unit
Data Spaces in Data 360 are designed specifically for logical separation of data, metadata, and configurations within a single org. Each business unit can operate in its own isolated environment while sharing the same underlying Data 360 instance. This ensures compliance, governance boundaries, and independent data management without requiring separate orgs.

🔴 A. Use separate companion connections within the same data space
Companion connections are used for connecting external systems or data sources, not for isolating business units. They do not provide logical separation of data or metadata within Data 360.

🔴 B. Use different permission sets within the same data space
Permission sets control user access and visibility but do not separate data or metadata. All business units would still share the same underlying data space, which fails governance isolation requirements.

🔴 D. Use separate objects per business unit with record-type filtering
Using separate objects or record types only provides logical segmentation at the data model level, not true isolation. It introduces complexity and does not enforce strict separation of metadata, configurations, or governance boundaries.

🔧 Reference:
⇒ Salesforce Data Cloud Data Spaces Overview
Explains how Data Spaces provide logical separation of data, metadata, and configurations for multi-business-unit scenarios.

Explanation:
When data from multiple sources shares the same customer identifier, Data 360 can misinterpret related records because it cannot distinguish which source system a record originated from. Fully Qualified Keys (FQKs) solve this by combining the source key with a key qualifier (such as the source system name), creating a unique identifier that preserves source lineage. This ensures engagement records are correctly associated with the profile from the same source system, preventing data misattribution during harmonization and queries.

Correct Option:

D. Fully Qualified Keys.
FQKs append a source-specific qualifier to primary and foreign key fields in Data Lake Objects (DLOs), creating a composite unique identifier. When multiple DLOs map to the same DMO field (e.g., Individual ID), FQKs allow Data 360 to distinguish records by their source origin. This prevents the platform from incorrectly assuming that identical raw ID values from different systems represent the same entity, thereby ensuring engagement records join to the correct source profile.

Incorrect Option:

A. Profile Unification Rules.
This is a general term for the identity resolution process that matches and merges records into unified profiles. It does not address the specific problem of distinguishing source-specific records during key mapping and joins.

B. Identity Resolution Reconciliation Rules.
These rules determine which attribute values (e.g., most frequent, most recent) appear on the unified profile after matching. They do not manage key uniqueness or prevent source-based key collisions.

C. Identity Resolution Match Rules.
Match rules define which fields are compared to identify records belonging to the same person. While essential for profile unification, they operate at a different stage and do not resolve the fundamental issue of identical raw IDs from different sources being mapped to the same DMO field.

Reference:
Salesforce Help: Best Practices for Fully Qualified Keys; Trailhead: Learn About Fully Qualified Keys.

Explanation:

The question tests the consultant's ability to implement governance, efficiency, and maintenance best practices within the Data Cloud segmentation canvas. It addresses a scenario where common exclusion filters must be standardized across multiple distinct brand segments and updated centrally every month to prevent operational duplication.

✅ Correct Option:

C. Create a reusable container block with common criteria.
Creating a reusable container block allows a consultant to define specific exclusion rules once and insert that single block across multiple target segments. When exclusion criteria change on a monthly basis, modifying the core reusable container instantly propagates those updates across every brand segment utilizing it, minimizing configuration effort and ensuring architectural consistency.

❌ Incorrect options:

A. Create a segment and copy it for each brand.
Copying a standalone segment for each brand team creates completely independent copies of the filtering criteria. This approach eliminates centralized control, forcing the consultant to manually find, open, and update every single brand's copied segment individually every month, which is error-prone and highly inefficient.

B. Create, publish, and deploy a data kit.
Data kits are specialized package containers designed to transfer metadata structures, schemas, and mappings across completely separate Salesforce orgs or sandbox environments. They are not intended for managing rolling, monthly operational data filter logic or segment criteria modifications within a single live production environment.

D. Create a nested segment.
A nested segment allows you to reuse an entire existing segment's output as an eligibility filter inside another segment. While useful, nesting focuses on compiling whole population subsets rather than establishing a modular, easily managed exclusion rule-set component block explicitly designed for cross-team structural reuse.

🔧 Reference:
→ See Salesforce Help: Segment Your Data with Attributes which details how to build and maintain reusable container blocks for unified segmentation criteria.