Explanation:
In Data Cloud, Party Identification objects are used to store alternate identifiers for individuals, such as Loyalty IDs, external system IDs, or membership numbers. Identity Resolution can perform exact match rules using these identifiers to unify profiles, even when the primary unique ID of the customer differs. This approach allows organizations to merge data across multiple systems while keeping the primary Individual object distinct.

Correct Option:

A — Party Identification object
The Party Identification object is designed to hold secondary identifiers for a customer, such as loyalty numbers, external CRM IDs, or other unique codes. By configuring Identity Resolution to use exact match rules on this object, the system can unify multiple records associated with the same individual, even when the primary customer ID differs across systems. This ensures accurate, unified profiles.

Incorrect Options:

B — Loyalty Identification object
There is no dedicated Loyalty Identification object in standard Data Cloud. Loyalty IDs are stored in Party Identification objects, so selecting this option is incorrect.

C — Individual object
The Individual object represents the primary profile of a customer. While it stores main identity attributes, it is not used for alternate ID matching in Identity Resolution. Exact match rules on secondary identifiers must reference Party Identification objects.

D — Contact Identification object
There is no standard Contact Identification object in Data Cloud. Using this would not allow Identity Resolution to match on secondary identifiers like Loyalty IDs.

Reference:
Salesforce Data Cloud: Party Identification and Identity Resolution

Explanation:
The Ignore Empty Value setting in identity resolution determines how the system treats fields that contain no value when evaluating reconciliation rules. Reconciliation rules decide whether multiple matched records should be merged into a single unified individual. By ignoring empty values, the system avoids unintentionally overwriting good data with blank values and ensures reconciliation relies only on meaningful, populated information.

Correct Option

B. Ignores empty fields when running reconciliation rules
This option is correct because the Ignore Empty Value setting applies specifically to reconciliation rules, not match rules. When enabled, empty fields will not be considered during reconciliation, ensuring that blank values do not override populated fields during the merging process. This helps maintain high-quality unified profiles and prevents data loss during identity resolution.

Incorrect Options

A. Ignores empty fields when running any custom match rules
This is incorrect because the Ignore Empty Value option does not affect match rules—whether standard or custom. Match rules evaluate how similar two records are, and empty values may still be part of the matching logic depending on configuration. The setting only applies after matching, during reconciliation.

C. Ignores Individual object records with empty fields when running identity resolution rules
This is incorrect because the feature does not exclude entire Individual object records. Identity resolution will still process records even if they contain empty fields. The setting strictly determines whether empty field values participate in reconciliation decisions.

D. Ignores empty fields when running the standard match rules
This is incorrect because the Ignore Empty Value option does not affect match rules of any type—standard or custom. Match rules still evaluate fields as configured, regardless of empty values. Ignore Empty Value only influences reconciliation behavior.

Reference:
Salesforce Data Cloud — Identity Resolution Reconciliation Rules & Ignore Empty Values Documentation

Explanation:
When using the Marketing Cloud Connector to ingest customer data into Salesforce Data Cloud, data deletion requests (e.g., right to be forgotten under GDPR/CCPA) must be managed at the source to ensure comprehensive compliance. Data Cloud does not natively support direct deletions for ingested data from connectors; instead, deletions are handled in the originating system (Marketing Cloud). This propagates deletions to Data Cloud via the connector's synchronization, preventing data resurrection on subsequent syncs and maintaining a single point of control for privacy requests.

Correct Option:

C. In Marketing Cloud settings:
Marketing Cloud provides dedicated privacy management tools, including the "Contact Deletion" feature under Setup > Privacy Management, where users can submit bulk or individual right-to-be-forgotten requests. For connector-ingested data, deleting contacts in Marketing Cloud triggers automatic removal from Data Cloud during the next sync cycle (typically hourly or as configured). This ensures end-to-end compliance without manual intervention in Data Cloud, as the connector respects source deletions to avoid re-ingestion of deleted records.

Incorrect Options:

A. In Data Cloud settings:
Data Cloud's global settings (e.g., under Setup > Data Cloud Settings) handle ingestion configurations, permissions, and general compliance toggles but do not process individual deletion requests. Bulk operations like DMO deletions are possible for managed data, but for connector sources like Marketing Cloud, changes must originate there to sync properly.

B. On the individual data profile in Data Cloud:
Individual profiles in Data Cloud allow viewing unified data and basic actions like exporting, but no "delete" or "forget" button exists for privacy requests. Attempting manual edits or suppressions here would be overwritten by connector syncs, making it ineffective and non-compliant for source-managed data.

D. through Consent API:
The Consent API manages opt-in/opt-out preferences and granular consent revocation, but it does not handle full data deletion or right-to-be-forgotten requests. It's designed for ongoing consent signals, not erasure, and would not trigger removal from Marketing Cloud or synced Data Cloud profiles.

Reference:
Salesforce Help: “Delete Contacts in Marketing Cloud for Data Cloud Compliance” – Explains source-system deletion propagation via connectors.

Explanation:
The client's primary concern is avoiding the risk of unifying distinct profiles that might accidentally share common PII (e.g., two people named "John Smith" with the same email domain). Identity Resolution needs a unique, non-transferable identifier to guarantee that only records belonging to the same individual are merged.

Correct Option:

A. Party Identification on Patient ID
Uniqueness Guarantee: A Patient ID (or Medical Record Number) is an internal, system-generated, and guaranteed unique identifier assigned to an individual by the healthcare provider. This ensures there is zero risk of false positives (unifying two different people).

Highest Accuracy: Using Party Identification based on this unique ID means profiles will only unify if they share the exact same Patient ID, providing the highest level of trust and accuracy for sensitive healthcare data.

Mitigates PII Risk: Since this ID is not commonly shared or transferable like a name or email, it completely mitigates the risk of unifying separate individuals who happen to have similar non-unique PII.

Incorrect Option:

B. Exact Last Name and Email
This is highly susceptible to false positives. Two different individuals (e.g., a husband and wife, or people with common last names) could easily share the same last name and be associated with the same household or family email, leading to an incorrect merge and data privacy risk.

C. Email Address and Phone
This combination still carries a high risk of false positives, especially in family or shared device scenarios where multiple individuals might use the same phone number or a shared family email address, thus violating the client's requirement to avoid unifying distinct profiles.

D. Fuzzy First Name, Exact Last Name, and Email
The use of Fuzzy First Name (which allows for minor variations like "Jon" and "John") increases the risk of matching records that belong to different people but happen to have similar names and the same email address. This directly contradicts the client's desire to minimize the risk of unification.

Reference:
Salesforce Data Cloud Documentation on Identity Resolution Matching Rules: Look for best practices on creating matching rules, specifically emphasizing the use of unique identifiers (Party IDs) for the most accurate and risk-averse matching in regulated industries like healthcare.

Explanation:

When activation updates are delayed despite a 12-hour publish schedule, the consultant should verify the dependency chain of data processing. Here’s why:

Calculated Insights Before Segment Refresh (Correct - B)

Issue: If insights (e.g., lifetime value scores) run after segments refresh, the segment won’t include the latest insights.
Fix: Ensure insights are scheduled before segment refreshes so segments use up-to-date metrics.

Segment Refresh After Data Ingestion (Correct - C)

Issue: If segments refresh before new data is fully ingested, they’ll use stale data.
Fix: Align segment refreshes with the data ingestion schedule (e.g., refresh segments 1 hour after ingestion completes).

Why Not the Other Options?

A. Data transformations after insights → Transformations should happen before insights (to clean raw data), not after.
D. Insights after segments → This would worsen delays by making insights dependent on segments (backward logic).

Key Takeaway:

1. Proper sequencing (ingestion → transformations → insights → segments → activation) is critical for timely updates.
2. Delays often stem from incorrect scheduling dependencies.

Reference:

Data Cloud Processing Order Documentation
Exam Objective: Data Pipeline and Activation Timing.