Free Salesforce Data 360 Consultant Practice Test Questions

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 understanding of how the Salesforce CRM Connector behaves during batch data ingestion into Data Cloud. It focuses on schema change handling, manual refresh capabilities, deletion thresholds, and synchronization interval configurations — all critical behaviors for managing CRM data pipelines reliably.

✅ A. When a column is added or removed, the CRM Connector performs a full refresh.
When a schema change occurs — such as adding or removing a column — the CRM Connector automatically triggers a full refresh to ensure data integrity and alignment with the updated structure. This behavior prevents mismatched mappings and ensures the Data Cloud Data Model Object accurately reflects the modified CRM schema.

❌ B. CRM data cannot be manually refreshed and must wait for the next scheduled synchronization.
This is incorrect. Salesforce Data Cloud allows administrators to manually trigger a CRM Connector refresh at any time directly from the Data Stream settings. Manual refresh capability is a supported feature, giving teams flexibility to pull updated CRM data outside of the scheduled synchronization window when needed.

❌ C. The CRM Connector performs an incremental refresh when 600,000 or more deletion records are detected.
This is incorrect. When 600,000 or more deletion records are detected, the CRM Connector performs a full refresh, not an incremental one. The high volume of deletions triggers a complete data reload to ensure accuracy and consistency, as incremental processing at that scale risks data integrity issues.

❌ D. The CRM Connector's synchronization times can be customized to up to 15-minute intervals.
This is incorrect. The CRM Connector in Data Cloud supports synchronization on an hourly basis, not 15-minute intervals. The 15-minute latency option applies to other Data Cloud features like Calculated Insights. CRM Connector scheduling does not support sub-hourly customization intervals.

🔧 Reference:
→ Salesforce CRM Connector Behavior – Salesforce Help
Confirms full refresh behavior upon schema changes, deletion record thresholds, and supported synchronization intervals for the CRM Connector in Data Cloud.

Explanation:

This question tests understanding of Salesforce Data Cloud's data storage architecture, specifically which object type holds raw, unprocessed source data prior to any mapping or transformation. The key requirement is preserving an exact historical record of the original transmission from the mobile application source system.

✅ D. Data Lake Object
A Data Lake Object (DLO) is the container in Salesforce Data Cloud that stores raw, unmodified source data exactly as it arrives from the source system — before any mapping, transformation, or harmonization occurs. It acts as the foundational ingestion layer, preserving the original transmission record and serving as the source from which Data Model Objects are later mapped.

❌ A. Calculated Insight Object
Calculated Insight Objects store pre-computed, aggregated metrics derived from processed Data Model Objects. They represent the output of analytical computations, not raw source data. They are the furthest point from ingestion in the Data Cloud pipeline and have no role in storing unmodified source transmissions.

❌ B. Data Model Object
A Data Model Object (DMO) is created after raw data has been mapped and harmonized from the Data Lake Object. It represents structured, standardized data aligned to the Data Cloud data model. Since it exists post-transformation, it does not preserve the original unmodified source data as required by this scenario.

❌ C. Party Identification Object
The Party Identification Object is a specific standard DMO used within Identity Resolution to store identifiers — such as email or phone — associated with individuals. It is a specialized mapped object within the data model layer, not a raw ingestion container, and plays no role in preserving unmodified source transmission records.

🔧 Reference:
→ Data Objects in Data 360 – Salesforce Help
Confirms that Data Lake Objects serve as the raw ingestion containers in Data Cloud, storing source data exactly as received before any mapping or transformation is applied.

Explanation:

This question evaluates how Salesforce Data 360 handles record uniqueness during data ingestion. Every ingested dataset requires a reliable primary key so records can be uniquely identified, updated, synchronized, and deduplicated correctly. When a source system lacks a naturally unique field, the consultant must design an alternative identifier strategy that guarantees uniqueness across all records.

🟢 D. Create a composite key by combining two or more source fields through a formula field.
Creating a composite key is the recommended solution when no single field uniquely identifies records in the source data. By combining multiple attributes—such as customer ID, transaction timestamp, store number, or order reference—into a formula field, the consultant can generate a stable and unique identifier for every record. This ensures Data 360 can accurately track updates, prevent duplicate ingestion issues, maintain synchronization integrity, and support downstream identity resolution and analytics processes.

🔴 A. Use the default primary key recommended by Data 360.
Data 360 does not automatically create a universally reliable primary key for datasets that lack uniqueness. Relying on a default recommendation can result in duplicate records, synchronization problems, and inconsistent record identification during ingestion and updates.

🔴 B. Remove duplicates from the data source and then select a primary key.
Eliminating duplicates improves data quality but does not solve the core issue of missing unique identifiers. Future incoming records could still create conflicts if no stable primary key exists to uniquely distinguish each record over time.

🔴 C. Select a field as a primary key and then add a key qualifier.
A key qualifier is used to distinguish similar identifiers across multiple data sources, but it does not make a non-unique field inherently unique within the same dataset. The primary key itself must still uniquely identify each record.

🔧 Reference:
⇒ Salesforce Data Cloud Primary Keys and Record Identification
Explains the importance of unique primary keys in Data Cloud and how composite keys can be used when source systems lack a single unique identifier.