Explanation:
When using the Consent API to honor a Right to Be Forgotten request in Data 360, the request must be submitted against a specific Individual profile. The Consent API identifies the target profile by the Individual ID, and the deletion cascades to records in Data Model Objects and Data Lake Objects that have a defined relationship to that Individual ID. This is a fundamental consideration the consultant must communicate to set correct expectations about how the deletion mechanism operates.

Correct Option:

C. Data Deletion requests are submitted for Individual profiles.
The Consent API uses the shouldforget action with mode=cdp to target a Data 360 profile. The ids parameter must contain an ID that is mapped to the Individual.Individual Id field. This means the deletion request is scoped to a specific individual record, and the system then traverses relationships to identify and remove related records across DMOs and DLOs.

Incorrect Option:

A. Data Deletion requests are processed within 1 hour.
This is not a guaranteed processing window. The Consent API operations are asynchronous, and Salesforce documentation states that deletion of Data 360 records "may take some time" after the request is submitted. Setting a strict 1-hour expectation is inaccurate.

B. Data Deletion requests submitted to Data 360 are passed to all connected Salesforce clouds.
Data 360 deletion requests are scoped to Data 360's own storage layers (DLOs and DMOs). The platform does not propagate deletion commands back to source systems like Sales Cloud or Service Cloud. Source system deletions must be managed independently.

D. Data Deletion automatically happens for related records.
While the Consent API does cascade deletion to records that have a defined relationship with the Individual ID, this is not an "automatic" blanket operation. It requires the Individual ID to be properly mapped and relationships to be defined in the data model. Data in unrelated DMOs is not affected.

Reference:
Salesforce Help: Consent API Actions; Salesforce Help: Right to Be Forgotten with Privacy Requests.

Explanation:
In Salesforce Data 360, a Data Space is a logical partition that organizes and secures data, metadata, and processes by categories such as brand, region, or department . When a workspace is created, it is bound to the specific Data Space selected at initialization. Data Model Objects (DMOs) are scoped to the Data Space where they reside. If the consultant selected the wrong Data Space, the target DMO will not appear in the query environment because it is outside the workspace's logical scope .

Correct Option:

C. Create a new workspace and select the data space the DMO belongs to.
The workspace context is immutable after creation—you cannot change the Data Space associated with an existing workspace . The standard and most efficient resolution is to create a new workspace that is initialized with the correct Data Space where the DMO is located. This ensures the query session has the appropriate metadata visibility and permissions to access the required DMO.

Incorrect Option:

A. Add the data space to the existing workspace.
Workspaces in Data 360 are bound to a single Data Space at creation and do not support adding additional Data Spaces afterward. This is not a supported configuration change .

B. Add the DMO to the data space they selected when creating the workspace.
Moving a DMO to a different Data Space is a significant administrative action that impacts data governance, security, and downstream processes. It is not a standard solution for a simple workspace selection error .

D. Reference the data space name and DMO in the query within the existing workspace.
Query syntax cannot override the Data Space scoping rules. If the workspace is not bound to the Data Space containing the DMO, the DMO is not visible regardless of how it is referenced in the query .

Reference:
Trailhead: Data Spaces in Data 360; Salesforce Help: Data Spaces Overview.

Explanation:

This question is testing the most efficient way to surface engagement history from Data 360 on a Salesforce Lead record. The right approach is to use the native related list enrichment feature, because it can display Data 360 engagement data directly on the record page without copying records into custom Salesforce objects.

A. Embed a filtered report chart on the record page that queries the Data 360 objects directly
❌ This is not the best fit because a report chart is a reporting view, not a native record-level engagement timeline. It also adds more complexity and does not provide the direct chronological related-list experience sales reps need.

B. Drag the native Data 360 Related List Enrichment onto the Lead Lightning page and configure the relevant Engagement data model objects (DMOs)
✅ This is correct because Data 360 Related List Enrichment is designed to show Data 360 data directly on Salesforce record pages. It lets you configure the relevant engagement DMOs so sales reps can see Web Page Views and Email Clicks in context on the Lead record, which is efficient and avoids data duplication.

C. Create a custom object in Salesforce, use Flow to sync Data 360 Engagement records back to CRM, and add a standard related list
❌ This works, but it is not efficient. It creates extra storage, Flow maintenance, and synchronization overhead, when the native related list enrichment already solves the use case directly.

D. Use Dynamic Forms to conditionally show fields from the Data 360 Individual object based on the Lead's status
❌ Dynamic Forms control field visibility, not a chronological activity feed. They cannot present a list of engagement events like page views and email clicks in the way the question requires.

🔧 Reference:
→ Salesforce Help — Create a Related List Enrichment
— confirms the native Data Cloud Related List feature for adding related data to Lead, Contact, or Account pages.

→ Salesforce Help — Create a Direct-DMO Related List Enrichment
— confirms that related list enrichment can display DMO records on Salesforce object pages.

Explanation:
When activating data to a Cloud File Storage target, Data 360 provides a "Preferred Attribute Name" field specifically for customizing output field labels without altering the underlying data model. This feature allows consultants to alias attribute names to match the target system's naming convention while keeping the source DMO fields intact. It is the standard, non-destructive approach for target-specific renaming .

Correct Option:

A. Set preferred attribute names when configuring activation.
During activation setup, each selected attribute includes a field where you can override the default DMO field name with a preferred alias. This alias appears in the exported file header sent to Cloud File Storage (e.g., S3, GCS, Azure). This approach is scoped only to that specific activation target, ensuring other segments, insights, and activations are unaffected .

Incorrect Option:

B. Update attribute names in the data stream configuration.
Changes here affect the Data Lake Object (DLO) level, which is too early in the pipeline. This impacts all downstream uses and lacks the target-specific flexibility required for a single activation target's naming convention .

D. Update field names in the data model object.
Renaming DMO fields is a structural change that affects every segment, insight, and activation using that object. It creates unintended side effects across the entire Data 360 instance and is not recommended for target-specific naming needs .

C. Use a formula field to update the field name in an activation.
Formula fields are designed for data value transformations (e.g., concatenating strings, calculating values), not for renaming output headers in an activation workflow. They modify field values, not field labels .

Reference:
Salesforce Help: Cloud File Storage Activation Targets; Salesforce Help: Create an Activation; Data Cloud Consultant Exam Guide.

Explanation:
Suggested Values in Data 360 has a hard limit on how many distinct values it can display. When an attribute has more than 1,000 distinct values, the system only shows the 1,000 most frequently occurring values in alphabetical order. Since Secondary Product Code contains 5,000 distinct values, the consultant must anticipate that marketers will only see a subset of the available values, which could lead to incomplete filtering results or confusion if users expect to find every possible code in the dropdown.

Correct Option:

A. The feature only displays the first 1,000 distinct values, which may lead to incomplete results for the user.
This is the documented behavior of Suggested Values in Data 360. When an attribute exceeds 1,000 distinct values, the system retains and displays only the 1,000 most frequently occurring values. For Secondary Product Code with 5,000 distinct values, 4,000 codes will not appear in the suggested list. Marketers can still manually type values that are not displayed, but they may not know those values exist, creating a risk of incomplete segment filters.

Incorrect Option:

B. Suggested values will fail to load if the attribute contains more than 500 unique entries.
There is no 500-entry failure threshold. The limit is 1,000 values displayed, not a failure point. The system continues to function with high-cardinality attributes by capping the displayed set.

C. The system requires a custom streaming data transform to refresh values for high-cardinality attributes.
Value Suggestions are a built-in DMO-level feature enabled from the DMO record page. No custom streaming transform is required to refresh or populate values for high-cardinality attributes.

D. Value suggestions are only available for attributes that have been mapped to the Engagement category.
Value suggestions are available for Text-type fields on DMOs regardless of category, with specific relationship constraints for the "Other" category. There is no Engagement-only restriction.

Reference:
Salesforce Help: Use Suggested Values in Segmentation.