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

Explanation:

This question tests what causes a higher identity resolution consolidation rate in Data 360. Consolidation rate rises when more source profiles are matched and merged into unified profiles. So the change that typically increases it is one that makes the ruleset match more profiles, not one that removes rules or reduces sources.

A. Modifying a ruleset that increases the number of matched profiles
✅ This is correct because adding or broadening match rules causes more source profiles to be linked into the same unified profile. That reduces the total number of unified individuals relative to source records, which increases the consolidation rate. Salesforce documents that to increase consolidation rate, you should add more match rules.

B. Removing existing identity resolution rules
❌ This usually lowers matching accuracy and reduces the number of profiles that merge together. With fewer matches, more unified individuals remain separate, so the consolidation rate tends to decrease instead of increase.

C. Reducing the number of data sources mapped to the Individual object
❌ This affects data coverage, not consolidation behavior. Fewer mapped sources may reduce the amount of data available for matching, but it does not typically raise the consolidation rate the way stronger or additional match rules do.

D. Deleting duplicate records from source data streams
❌ This removes duplicates before identity resolution can use them to consolidate profiles. Since consolidation rate measures how much source data was combined into unified profiles, deleting duplicates upstream does not cause the ruleset itself to consolidate more records.

🔧 Reference:
→ Salesforce Help — Identity Resolution Ruleset Processing Results
— confirms that adding more match rules increases consolidation rate.

Explanation:

This question tests understanding of Salesforce Data Cloud's core features for unifying customer data across multiple sources. The key requirement is matching and reconciling data about the same individual from different data sources into a single, consolidated unified profile.

✅ A. Identity Resolution
Identity Resolution is the purpose-built Data Cloud feature that matches, links, and reconciles individual records from multiple data sources into a single Unified Individual Profile. It uses configurable match rules and reconciliation rules to resolve identities across fragmented data, ensuring a complete and accurate 360-degree view of each customer.

❌ B. Data Consolidation
Data Consolidation is a general data management term referring to combining data into a central repository. It is not a specific Salesforce Data Cloud feature. It does not include the matching logic, ruleset configuration, or identity linking mechanisms required to reconcile individual-level records into unified profiles.

❌ C. Data Cleansing
Data Cleansing refers to detecting and correcting inaccurate, incomplete, or duplicate records to improve data quality. While it supports better data hygiene, it does not perform identity matching or profile unification. It addresses data accuracy, not the reconciliation of the same individual across multiple disconnected data sources.

❌ D. Harmonization
Harmonization in Data Cloud refers to mapping ingested data to a standard Data Model Object (DMO) structure for consistency. It standardizes data formats and schema alignment but does not perform individual matching or profile merging. It is a prerequisite step to Identity Resolution, not a replacement for it.

🔧 Reference:
→ About Identity Resolution – Salesforce Help
Confirms that Identity Resolution matches and reconciles records from multiple data sources into a single Unified Individual Profile using configurable match and reconciliation rules.

Explanation:

This question tests the consultant's understanding of file federation configuration in Data 360, specifically the role of the manifest file when connecting to an external data lake like Azure Blob Storage. File federation allows Data 360 to read data directly from external storage without ingesting it. The manifest file acts as a pointer or catalog that tells Data 360 which files to read and how to interpret them.

✅ Correct Option: C. It defines metadata and paths to identify specific files for the data stream and track updates.
The manifest file serves as a configuration blueprint for file federation. It contains metadata about the source files—including file paths, schemas, formats, and timestamps—allowing Data 360 to locate the correct files in Azure Blob Storage and understand their structure. Additionally, it enables incremental processing by tracking which files have already been read, so only new or updated files are processed on subsequent runs.

❌ Incorrect Option: A. It reduces the file size of the source data before Data 360 attempts to read it.
This is incorrect. The manifest file does not perform any compression or file size reduction. Data size reduction, if needed, would be handled by the source system or via separate ETL processes before files are placed in the data lake.

❌ Incorrect Option: B. It is used to manually map source fields to the Cloud Information Model.
This is incorrect. Field mapping to the Cloud Information Model is handled within the data stream configuration in Data 360, not within the manifest file. The manifest file identifies which files to read, while mapping is a separate configuration step.

❌ Incorrect Option: D. It provides the PGP public key required to decrypt the federated data files.
This is incorrect. Encryption and decryption keys, including PGP keys, are managed through separate security configurations such as key stores or credential management in Data 360. The manifest file does not handle encryption keys.

🔧 Reference:
→ Salesforce Data Cloud File Federation Documentation – Confirms that manifest files define metadata, file paths, and schemas for federated data streams, enabling incremental processing by tracking processed files.

Explanation:

The question tests the consultant's knowledge of the configurable settings within Salesforce Data Cloud Identity Resolution. Specifically, it focuses on how the system handles null or blank values across different source systems when consolidating attribute data to form a single, trusted golden record for a unified profile.

✅ Correct Option:

C. Ignores empty fields when running reconciliation rules
The Ignore Empty Value option is an attribute-level setting applied strictly within Identity Resolution reconciliation rules. When enabled, it instructs the consolidation engine to completely skip over any incoming data sources that contain blank or null values for that specific field, ensuring that an empty value does not accidentally overwrite a populated field from a lower-priority source.

❌ Incorrect options:

A. Ignores Individual object records with empty fields when running identity resolution rules
Identity resolution processes evaluate incoming data at the granular attribute layer rather than the entire record layer. This option does not skip or drop whole individual profile records from the processing pipeline just because certain optional fields happen to be empty.

B. Ignores Contact Point object records with empty fields when running identity resolution rules
Contact point records (such as phone numbers or email addresses) are processed during identity resolution to map communication channels. The configuration does not ignore entire contact point records based on blank fields; it resolves values based on specific rule setups.

D. Ignores empty fields when running match rules
Match rules are used to establish a link between separate records using techniques like exact or fuzzy matching to find duplicates. The Ignore Empty Value toggle does not control match execution behavior, as blank fields are already naturally bypassed in matching to avoid false-positive link matches.

🔧 Reference:
→ See Salesforce Help: Configure Reconciliation Rules which confirms that the Ignore Empty Values selection applies directly to attribute selection within reconciliation rules to prevent null values from overriding valid data.

Explanation:

This question tests how to validate Identity Resolution results in Salesforce Data 360 after configuring a ruleset. The goal is to confirm that records are correctly unified into a single profile and can be queried accurately.

🟢 A. Profile Explorer and Query Editor
Profile Explorer is used to visually inspect unified customer profiles and verify how source records have been stitched together after identity resolution. Query Editor allows direct querying of unified profiles and related attributes to validate correctness at a data level. Together, they provide both visual confirmation and technical verification of identity resolution outcomes.

🔴 B. Data Explorer and Actions
Data Explorer is useful for browsing datasets but not specifically for validating unified identity resolution results. Actions relate to automation or activation, not validation of profile stitching.

🔴 C. Identity Resolution and Query API
Identity Resolution is the configuration process itself, not a validation tool. Query API can retrieve data but lacks the visual inspection capabilities needed to validate unified profiles effectively.

🔴 D. Data Actions and Query API
Data Actions are used for triggering workflows or downstream processes, not validation. Query API alone is insufficient because it does not provide a UI-based view of unified profiles for verification.

🔧 Reference:
⇒ Salesforce Data Cloud Profile Explorer Overview
Explains how Profile Explorer is used to inspect unified customer profiles after identity resolution.

Explanation:

This question tests the consultant's understanding of the fundamental building blocks required when creating a calculated insight using the Visual Insights Builder in Data 360. The builder interface is designed to create SQL-based aggregations without writing code. Just like a SQL query with GROUP BY, every calculated insight requires specifying what to calculate (a measure) and how to group that calculation (a dimension) .

✅ Correct Option: C. At least one measure and one dimension
A measure is an aggregated value using functions like SUM or COUNT—for example, "Total Lifetime Loyalty Points" or "Average Order Amount." A dimension is a qualitative field used to categorize that measure, such as "Customer ID" or "Product Category" . Without both, the insight cannot define what metric to compute or how to group the results. The Visual Insights Builder enforces this requirement because an aggregate node must have both components to generate a valid SQL query with a GROUP BY clause and a selected aggregation function .

❌ Incorrect Option: A. Joining on two or more data model objects
Joins are optional, not mandatory, when creating a calculated insight. You can create a valid insight from a single Data Model Object (DMO) by selecting a measure and a dimension from that same object. Joins become necessary only when your calculation requires data spread across multiple objects .

❌ Incorrect Option: B. A SUM function
The SUM function is one of several aggregation options, but it is not a minimum requirement. Other valid aggregation functions include COUNT, AVG (average), MIN (minimum), and MAX (maximum) . The requirement is any measure (an aggregated value), not specifically a SUM.

❌ Incorrect Option: D. A WHERE clause
A WHERE clause is optional and used for filtering rows before aggregation. It is not a minimum requirement. Many calculated insights, such as "Total Sales by Customer," do not require a WHERE clause if all records should be included in the aggregation .

🔧 Reference:
→ Trailhead: Create Insights Using Data Cloud – Confirms that measures (aggregated values) and dimensions (grouping categories) are the core components of any calculated insight.

Explanation:

This question tests knowledge of the correct Salesforce Data Cloud tool for performing aggregated metric computations across historical and streaming data sources. The key requirement is summing point-based transactions from multiple sources to derive a single Lifetime Loyalty Points value usable for segmentation.

✅ B. Calculated Insight
Calculated Insights are designed to compute and persist aggregated metrics — such as summing all point-based transactions — across multiple Data Model Objects (DMOs) from different data sources. The resulting metric is stored as a DMO attribute, making Lifetime Loyalty Points directly available as a segmentation filter within Data Cloud Segment Builder.

❌ A. Streaming Transform
Streaming Transforms process and shape data in real time as it flows into Data Cloud. They handle record-level transformations on incoming events, not historical aggregations. Summing all past loyalty point transactions across a full historical ledger is beyond the scope of what Streaming Transforms are designed to perform.

❌ C. Batch Transform
Batch Transforms are used to reshape, filter, or enrich data during ingestion on a scheduled basis. They operate at the record or row level and do not perform cross-source aggregations like summing transactions. They prepare data for use but cannot produce a persisted, segmentable aggregated metric like Lifetime Loyalty Points.

❌ D. Secondary Index
A Secondary Index improves query performance by creating additional lookup paths on Data Model Object fields. It is purely a performance optimization tool and has no capability to compute, aggregate, or store calculated values. It does not process transactions or generate any derived metrics for segmentation purposes.

🔧 Reference:
→ Calculated Insights in Salesforce Data Cloud – Salesforce Help
Confirms that Calculated Insights aggregate and persist metrics across multiple DMOs, making computed values like Lifetime Loyalty Points available directly for segmentation in Data Cloud.

Explanation:

This question tests where contact point-level filtering belongs in Data 360. The goal is to narrow the contact points that are sent from already-qualified Unified Individuals, so the filtering should happen at the activation stage, not during segmentation or ingestion.

A. Apply contact point filtering during the creation of the segment
❌ Segment creation defines who is in the audience, but contact point filtering is not applied there. The segment should first identify the right Unified Individuals, and then the activation should decide which contact points to use.

B. Apply contact point filtering when creating an activation
✅ This is correct because Salesforce supports filtering and sorting contact points during activation. That lets you choose the right contact point for the right channel, while also honoring preferences and avoiding unnecessary downstream processing.

C. Apply contact point filtering leveraging a calculated insight
❌ Calculated Insights are used for metrics and aggregates, not for selecting or excluding contact points in activation. They are the wrong layer for contact point-level delivery control.

D. Apply contact point filtering on data ingestion
❌ Ingestion is about bringing data into Data 360, not deciding which contact points should be activated for a segment. Filtering at ingestion would not serve the audience-targeting requirement described here.

🔧 Reference:
→ Salesforce Help — Add Filters to Contact Points in Activation
— confirms contact point filtering is applied during activation.

Explanation:

This question focuses on identifying a realistic early-stage business outcome for Data 360 adoption. Early success should prioritize quick, visible business value rather than complex enterprise-scale architecture or advanced real-time systems. The goal is adoption momentum through immediate operational impact.

🟢 D. Improving customer service resolution times by giving support agents a 360-degree view
This is the most effective quick-win use case because it directly leverages unified customer profiles in Data 360. Support agents can access complete customer context in one place, reducing resolution time and improving service quality. It is easy to implement compared to enterprise-wide data governance or predictive streaming systems, making it ideal for early adoption success.

🔴 A. Consolidating all partner and supply chain data into a single master management hub
This is a large-scale transformation initiative requiring extensive integration and governance. It is not suitable as a quick win due to high complexity and long implementation cycles.

🔴 B. Implementing a global data lineage system to calculate data quality scores and create audit reports for compliance teams across all business units
This focuses on compliance and governance rather than immediate business value. It requires mature data infrastructure and does not deliver fast user-facing benefits.

🔴 C. Building a predictive platform to update dynamic segments every 30 seconds
This is an advanced real-time analytics scenario requiring streaming architecture and high maturity. It is not practical for early-stage adoption of Data 360.

🔧 Reference:
⇒ Salesforce Data Cloud Use Cases
Explains how Data Cloud is commonly used to improve customer service through unified customer profiles and faster issue resolution.

Explanation:

This question evaluates a key limitation of Calculated Insights in Salesforce Data Cloud when used for reporting. It tests the consultant’s awareness of data freshness and the batch nature of Calculated Insights compared to real-time or streaming capabilities.

✅ Correct Option:

A. The data reflects the state of the last time the insight was batch processed.
Calculated Insights in Data Cloud are processed in batches according to a defined schedule. When reporting on them, the data shown always reflects the results from the most recent batch execution, not live or real-time data. This is a critical limitation a Data 360 Consultant must keep in mind, especially when building dashboards or reports for executives who expect current information.

❌ Incorrect options:

B. Calculated insights can only be reported on if they contain fewer than 2,000 total rows.
This statement is incorrect. There is no such row limit restriction of 2,000 for reporting on Calculated Insights in Data Cloud. Reports can be built on larger datasets depending on overall platform limits.

C. Insights are only available in reports if they have been "Activated" to a Marketing Cloud engagement.
This is not true. Activation is only required when using insights for Marketing Cloud journeys or campaigns. Calculated Insights can be directly used in Salesforce reports and dashboards without any activation to Marketing Cloud.

D. Calculated insights are only updated once every 24 hours.
This is inaccurate. The refresh frequency for Calculated Insights is configurable by the consultant. Common options include every 6 hours, 12 hours, or 24 hours, and they can also be run manually.

🔧 Reference:
→ Trailhead - Schedule a Calculated Insight in Data 360
Explains batch processing, scheduling, and data freshness behavior of Calculated Insights.