Select Two (Multi-Select) Questions

Install the Marketing Cloud package in the CRM

Why it fails: This is not required for CRM-to-Data Cloud ingestion.

Configure a private cloud gateway

Why it fails: This is not a standard requirement for Salesforce CRM connectors.

Create a sandbox for the Data Cloud environment

Why it fails: While best practice, it is not a mandatory configuration step.

Enabling Salesforce CRM Change Data Capture on AWS RDS

Why it fails: Change Data Capture is a Salesforce CRM feature that tracks record changes within Salesforce objects; it cannot capture changes occurring in an AWS RDS database. It is tempting because CDC is a recognised ingestion pattern, but it would be correct only when replicating changes from Salesforce CRM itself, not from external AWS sources.

Installing Marketing Cloud Connect on an AWS EC2 instance

Why it fails: Marketing Cloud Connect links Salesforce Marketing Cloud to a Salesforce org for journey and subscriber integration; installing it on EC2 does not ingest AWS data into Data Cloud. It is tempting because it is a genuine integration package, but it would be correct only for Marketing Cloud-to-CRM connectivity, not external AWS ingestion.

Establishing a direct SQL Server replication tunnel

Why it fails: Data Cloud ingests through connectors, MuleSoft, ingestion APIs and zero-copy federation; a direct SQL Server replication tunnel is not a supported ingestion path and bypasses governance. It is tempting because database replication is a familiar ETL technique, but it would only suit replicating between SQL Server instances, not bringing AWS data into Data Cloud.

Create manual database constraints in the underlying Data Lake Object storage.

Why it fails: Identity Resolution matches and reconciles source profiles through match rules and reconciliation rules configured in Data Cloud; it does not create database constraints in the Data Lake Object storage layer. Manual constraints are tempting because Data Cloud stores data in Data Lake Objects, but those govern storage structure, not profile unification logic.

Execute a batch SOQL query via Data Loader to export merged profiles.

Why it fails: Identity Resolution runs as a batch process within Data Cloud, producing unified profiles in the Unified Profile object; exporting merged profiles via Data Loader is an output activity, not a configuration step. Data Loader is tempting for bulk data movement, but it neither defines match rules nor reconciles records.

Write a custom Apex trigger to merge duplicate contact records in Sales Cloud.

Why it fails: Identity Resolution runs inside Data Cloud using match and reconciliation rulesets; Apex triggers operate on Sales Cloud records and cannot unify Data Cloud profiles. It is tempting because deduplication sounds similar, and would be correct for merging duplicate CRM records within Sales Cloud itself.

A custom on-premise relational database via direct ODBC driver installation.

Why it fails: Direct ODBC installation to an on-premise database requires custom middleware or an agent, so it is not a native direct integration; Data Cloud ingests on-premise relational data through supported connectors or MuleSoft. It is tempting because ODBC is a standard database interface, but native ingestion covers cloud sources and packaged connectors instead.

A legacy local file server accessed via FTP without intermediate cloud storage.

Why it fails: FTP file servers lack a native Data Cloud connector; ingestion requires staging files in supported cloud storage first. It tempts because batch file ingestion is a genuine Data Cloud capability, so on-premises sources would be correct only when routed through an intermediary such as Amazon S3 or SharePoint.

Standard CIM DMO relationships cannot be modified or extended.

Why it fails: Custom relationships can be added to standard DMOs.

Relationships require Apex code to enforce referential integrity.

Why it fails: Relationships are managed visually in the UI without Apex code.

Relationships are automatically created by Identity Resolution without user configuration.

Why it fails: Identity resolution creates unified links, but structural relationships between DMOs must be modeled explicitly.

Check the core CRM Apex code coverage for all triggers in the organization.

Why it fails: Apex code coverage has no impact on Data Cloud CRM data streams.

Verify that all Data Model Objects have been converted to custom Salesforce objects in Object Manager.

Why it fails: Data Model Objects are native to Data Cloud and are not converted to core CRM custom objects.

Calculated Insight SQL Formula

Why it fails: A calculated insight SQL formula derives metrics from existing data; it produces no identifying value for comparing records. It is tempting because it is defined per data model, but match rules instead evaluate identity attributes such as email address, phone number or loyalty identifier to reconcile profiles.

Data Stream Ingestion Schedule

Why it fails: An ingestion schedule governs when data streams load, describing pipeline timing rather than any customer characteristic, so it cannot link records. It is tempting because it is configured alongside data streams, but match rules instead compare identifying values such as email, phone or name and address.

Activation Target URL

Why it fails: An activation target URL is a downstream destination for segmented audiences, not a customer attribute, so it cannot match identities. It is tempting because it appears in activation configuration, but match rules instead evaluate stable personal identifiers such as email address, phone number or loyalty ID.

Streaming segments are restricted to a maximum refresh frequency of once every 24 hours.

Why it fails: Streaming segments refresh near-continuously as new data arrives, not once every 24 hours; that cadence describes batch segments. The 24-hour figure is tempting because it reflects a real batch refresh limit, but applying it to streaming inverts the actual behaviour and fails the scenario.

Streaming segments can only be published to Marketing Cloud Engagement and no other targets.

Why it fails: Streaming segments can activate to multiple targets, including Data Cloud and other connected platforms, not Marketing Cloud Engagement alone. Restricting to one destination is tempting because Marketing Cloud Engagement is a common activation target, but it is not an actual limitation of streaming segments.

An active Einstein Studio predictive scoring model.

Why it fails: Batch segment activation reads unified profile and segment data; an Einstein Studio scoring model supplies predictions, not the activation payload. It is tempting because predictive scores enrich segments, yet scoring models are correct when the requirement is appending propensity values rather than publishing a segment to a batch destination.

A real-time Data Action Target configured with a webhook URL.

Why it fails: A Data Action Target pushes real-time events to a webhook, whereas batch activation writes segment members to a file or destination on a schedule. It is tempting because both deliver segment data outward, yet Data Action Targets are correct for streaming, event-triggered activation rather than scheduled batch publishing.

Switch all reconciliation rules from Source Sequence to Longest String.

Why it fails: Longest String selects the longest value per field, which does not address duplicate profiles arising from weak match rules or missing normalisation; it may even merge or retain inconsistent values. Source Sequence is correct when a defined source priority must determine the winning attribute value.

Delete all data spaces and restart the entire Salesforce CRM instance.

Why it fails: Deleting data spaces and restarting the CRM destroys the ingested data and configuration that troubleshooting requires, and cannot reduce inflated counts caused by reconciliation or matching rules. It is tempting as a reset when a sandbox is corrupted, but production identity resolution demands diagnostic analysis, not teardown.

Use streaming segments exclusively for all segments regardless of size.

Why it fails: Streaming segments are not appropriate or supported for all data volumes and complex calculations.

Include all available profile attributes in the segment output to maximize downstream usability.

Why it fails: Including unused attributes wastes processing resources and slows down segment evaluation.

Schedule all segments to run simultaneously at midnight to align with data refreshes.

Why it fails: Staggering segment schedules prevents resource contention and concurrency limits.

Cross-database SQL join queries

Why it fails: Segment Builder offers point-and-click filtering, set operations and related-attribute selection; arbitrary cross-database SQL joins are not exposed there. It tempts because Data Cloud does support SQL-based joins in Data Model/query tooling, but that capability sits outside the Segment Builder canvas.

Triggering real-time email sends

Why it fails: Segment Builder defines audience membership and can activate segments to destinations; it does not itself trigger real-time email sends. It tempts because Data Cloud supports real-time activation and Flow-triggered messaging, but those sends are configured in activation or automation tooling, not the segment canvas.

Automatically deletes duplicate records in the external source system.

Why it fails: Mapping DSOs to CIM DMOs harmonises field semantics and enables identity resolution within Data 360; it never writes back to delete records in the external source system. It is tempting because deduplication is a genuine Data 360 capability, but that occurs during ingestion and unification, not through CIM mapping itself.

Replaces the need for batch data stream scheduling.

Why it fails: CIM mapping aligns DSO fields to standard DMO schemas for interoperability; batch data stream scheduling remains a separate configuration governing when ingestion runs. It is tempting because standardised models reduce per-source transformation effort, yet scheduling cadence is unaffected — mapping changes semantics, not orchestration timing.

Eliminates the need to configure primary keys on custom DMOs.

Why it fails: Primary keys on custom DMOs are still defined during DMO creation; mapping a DSO to a CIM DMO does not remove that configuration step. It is tempting because CIM DMOs ship with predefined keys, but that benefit applies only when using the standard DMO itself, not custom ones.

Map Salesforce Core Case assignment rules to the webhook payload.

Why it fails: Case assignment rules are Salesforce Core automation logic and have no bearing on how a Data Action Target authenticates or formats an outbound webhook call. Tempting because mapping fields feels like payload configuration, and it would be right when syncing Core records into Data 360 rather than invoking an external REST endpoint.

Upload a Parquet encryption key for AWS S3 bucket storage.

Why it fails: A Parquet encryption key applies to AWS S3 storage at rest, which is irrelevant to a REST API webhook that transmits JSON over HTTPS. Tempting because encryption keys are a security feature, and it would be correct when securing Data 360 data lake exports stored in S3 rather than an outbound webhook target.

Set the Data Stream ingestion batch refresh interval to 24 hours.

Why it fails: Batch refresh interval governs Data Stream ingestion scheduling, not webhook authentication or payload delivery, so it does nothing for the REST API target. It is tempting because refresh settings appear in Data 360 configuration, and it would be correct when tuning ingestion latency for a Data Stream rather than securing an outbound webhook.

Core Salesforce CRM records are automatically overwritten and modified.

Why it fails: Identity resolution builds unified profiles from matched source data without overwriting core Salesforce CRM records; those objects remain untouched unless separately configured. It is tempting because unified profiles resemble master records, but Data 360's unification operates on ingested data streams, not by writing back to CRM objects automatically.

Source records are permanently deleted from the source data streams.

Why it fails: Identity resolution links matched source records into a unified profile while retaining the originals in their source data streams; nothing is deleted. It is tempting because deduplication in other systems often removes duplicates, but Data 360 preserves source records so they remain available for reconciliation, lineage and downstream activation.

All segments in Data Cloud are forced to refresh simultaneously every 60 seconds.

Why it fails: Each segment carries its own schedule, so refresh cadence varies per segment rather than being globally forced. It is tempting because near-real-time streaming segments do refresh on very short intervals, so a 60-second cadence would be correct for those specific streaming use cases, not for every segment in the org.

Segment publishing schedules are managed exclusively via external REST API calls.

Why it fails: Schedules are configured in the Data Cloud user interface, with API access available but not exclusive. It is tempting because programmatic scheduling suits automated pipelines, so REST API management would be the correct approach when schedules must be driven by external orchestration rather than by consultants in the UI.

Segment schedules are permanently locked and cannot be modified after initial creation.

Why it fails: Schedules remain editable after creation, so a permanent lock contradicts how Data Cloud stores them. It is tempting because some publishing configurations do require re-creation once dependencies change, so immutability would be the correct property for those locked artefacts, not for the schedule itself.

Tableau Desktop Workbook files

Why it fails: Tableau connects via data connectors for reporting, not as an activation target.

Personalized Email Client plugins

Why it fails: Email client plugins are not supported activation targets.

Salesforce Core Custom Report Types

Why it fails: Report types are not activation targets.

Using an append-only publishing policy instead of a full refresh

Why it fails: Append-only publishing writes only changed records, so it reduces volume and generally speeds activation rather than slowing it. It is tempting because full refresh rewrites the entire dataset, and append-only would be the correct policy when the destination supports incremental upserts and change tracking is reliable.

Having the Data Stream ingestion batch size set to maximum

Why it fails: A maximum ingestion batch size reduces per-batch overhead and typically improves throughput, so it does not degrade publishing performance. It is tempting because oversized batches can strain memory, and tuning batch size would be correct when diagnosing ingestion-side latency rather than activation publishing jobs.

Apex trigger validation scripts for custom match scoring

Why it fails: Identity Resolution rulesets are configured declaratively through match rules, reconciliation rules and match rule sets; Apex cannot supply custom match scoring. It is tempting because Apex extends many Salesforce features, but Data Cloud matching uses its own fuzzy algorithms and rule configuration, not programmatic triggers.

Core Salesforce duplicate management rules from CRM Setup

Why it fails: Identity Resolution rulesets in Data Cloud are built from match rules, reconciliation rules and match rule sets; CRM duplicate management rules are a separate Salesforce feature and cannot be imported. It is tempting because both reconcile duplicates, but CRM rules operate on Salesforce records, not on Data Cloud unified profiles.

Manually configure HTML email templates in Marketing Cloud Engagement.

Why it fails: HTML email template configuration sits in Marketing Cloud Engagement's content tooling, not in Data Cloud ingestion and modelling design, so it answers a different role's duties. It is tempting because both products share the Salesforce platform and consultants often hold both certifications, making cross-product tasks look plausible.

Write Apex triggers to manage database indexing on external ERP systems.

Why it fails: Apex triggers cannot execute against external ERP databases; they run only in the Salesforce platform, so they cannot manage indexing on a third-party system. It is tempting because Apex is the standard Salesforce customisation tool, and it would be correct for automating index-related logic on Salesforce objects instead.