Data Ingestion And Modeling practice questions

AWS S3 does not support date formatting natively, so all dates must be transformed using a formula in Data Cloud after the stream is active.

Why it fails: Data Cloud supports standard ISO date formats directly from S3 without requiring post-ingestion formulas.

The Cloud Information Model restricts S3 date fields to string data types until harmonization is completed.

Why it fails: The CIM supports proper Date and DateTime data types.

Data Cloud automatically infers all S3 data types as Text upon initial ingestion, and field types must be manually adjusted in the Data Stream detail page.

Why it fails: Data Cloud attempts type inference based on sample records, but text representation in S3 often requires manual adjustment if formatting is non-standard.

Standard DMOs do not support custom DSO fields unless wrapped in a Profile DMO extension.

Why it fails: Standard DMOs can map custom DSO fields to standard or custom attributes.

The data stream must be deleted and recreated for Identity Resolution to recognize new mapping paths.

Why it fails: Deleting data streams is never required for updating mappings.

Harmonization requires an intermediate Master Data Model object before matching can take place.

Why it fails: Harmonization maps DSOs directly to DMOs.

They require Apex code to establish relationships between each other.

Why it fails: Relationships between DMOs are configured visually in the Data Model UI, not via Apex.

They store raw, unformatted data directly from the source system without modification.

Why it fails: Raw, unformatted data is stored in Data Source Objects (DSOs), not DMOs.

Data Cloud does not support record deletion; deleted records remain permanently in DSOs.

Why it fails: Salesforce CRM streams do propagate deletions into Data Cloud, so claiming deletion is unsupported misstates the connector's behaviour. It tempts consultants who have seen orphaned records after a failed or paused stream and concluded the platform cannot delete. The actual mechanism is the source-deletion sync built into the CRM connector.

Deletes require an external Ingestion API call with a delete flag set to true.

Why it fails: Ingestion API delete flags apply to custom Ingestion API streams, not the native Salesforce CRM connector, which handles deletions itself. It tempts consultants who have used the Ingestion API for other sources and assume every stream needs an explicit delete signal. No external call is required for CRM deletes.

Deletes must be handled manually by running a weekly SQL purge script.

Why it fails: Manual SQL purges are not how CRM deletions reach Data Cloud; the connector propagates them automatically during stream runs. It tempts teams accustomed to warehouse ETL, where scheduled purge jobs are the norm. The correct answer describes the built-in source-deletion handling rather than an external script.

Delete source records directly from the external connected system.

Why it fails: Data Cloud mapping is a read-only integration process relative to the source system.

Modify the underlying primary key structure of standard CIM DMOs.

Why it fails: Standard CIM DMO primary key structures are locked and cannot be modified.

Apex Trigger Objects

Why it fails: Apex triggers are programmatic automation logic that runs on record events, not a data model object type in Data Cloud. It tempts because Apex is central to Salesforce platform development, and triggers do act on data objects there — but Data Cloud's model comprises DMO, DLO and CIO types, not trigger constructs.

Visualforce Page Objects

Why it fails: Visualforce pages are a UI rendering technology for Salesforce applications, not a Data Cloud data model object type. It tempts because Visualforce is a familiar Salesforce metadata component, but Data Cloud's architecture defines DMOs, DLOs and CIOs; presentation-layer artefacts play no part in that model.

Ingest raw CSV files directly into custom DMOs without creating DSOs.

Why it fails: Batch data streams always ingest into DSOs first, never directly into DMOs.

Ensure every custom DMO has at least 50 primary key fields.

Why it fails: DMOs have a single composite or singular primary key.

Prefix all custom DMO names with 'Apex_' to ensure system compatibility.

Why it fails: Custom objects use standard publisher prefixes (e.g., '__c'), not 'Apex_'.

Disable Identity Resolution during peak hours to free up processing capacity.

Why it fails: Identity Resolution runs asynchronously on already-ingested data, so disabling it cannot relieve Ingestion API throttling; the 429s originate at the ingestion endpoint. It is tempting because Identity Resolution is processing-intensive, and pausing it would be valid when the constraint is batch or streaming processing capacity, not API request volume.

Switch the streaming endpoint to a batch CSV upload via Amazon S3.

Why it fails: Batch CSV upload via Amazon S3 replaces real-time streaming with scheduled bulk ingestion, so web events lose the immediacy the Ingestion API provides and 429 throttling is not addressed. It tempts for high-volume historical loads, where latency is irrelevant and throughput matters instead.

Increase the batch size limit in Salesforce CRM Setup under API limits.

Why it fails: That setting governs Salesforce CRM's own API request allocations, not Data Cloud's Ingestion API connector limits, so raising it leaves the 429 throttling unchanged. It is tempting because both surfaces expose API limits, and adjusting CRM limits would be correct when the throttled calls are standard Salesforce REST or Bulk API requests.

Guaranteed zero latency for batch data streams

Why it fails: Starter bundles deliver prebuilt data streams, DMOs and dashboards, not latency guarantees; batch ingestion inherently has scheduling delay. Zero latency is tempting because streaming ingestion exists, but that is a separate streaming capability, not a starter bundle feature.

Automatic custom Apex code generation for complex business logic

Why it fails: Starter bundles deliver prebuilt data models, connectors and calculated insights; they generate no Apex, which belongs to Salesforce platform development rather than Data Cloud provisioning. It tempts because Data Cloud does surface business logic through calculated insights, and Apex generation would be the right answer for a code-centric CRM requirement.

Store all attributes as text strings to prevent data type conversion errors.

Why it fails: Text-only storage inflates storage and blocks numeric range, date and boolean filtering that segmentation logic depends on, forcing costly casting at query time. Typed attributes are the point of a DMO. Text is tempting because it avoids ingestion-time conversion failures, which suits unstructured or genuinely free-text source fields.

Write custom Apex triggers on the DMOs to optimize database indexing.

Why it fails: Data Cloud DMOs are metadata-driven; Apex triggers cannot be written against them, and indexing is handled by the platform's own optimisation. Apex triggers belong to core Salesforce objects, where custom business logic on record changes is genuinely required.

Bypass the Cloud Information Model entirely by using raw DSOs for segmentation.

Why it fails: Segmentation requires the Cloud Information Model's standard DMO schema so the platform can resolve identities and relationships; raw DSOs lack that harmonised structure and cannot drive segmentation. Raw DSOs suit ingestion and transformation staging before mapping to CIM-based DMOs.

Analyzing Salesforce CRM Apex Debug logs.

Why it fails: Apex debug logs record Salesforce CRM transaction execution, not Data Cloud ingestion activity, so they contain no stream health or connector error detail. They are tempting because debug logs are the standard troubleshooting tool elsewhere on the platform, and would be correct when diagnosing custom Apex triggers, flows or governor-limit failures in the CRM org itself.

Running a SOQL query in Developer Console to query DSO tables.

Why it fails: SOQL queries DSO (Data Space Object) tables to read ingested records, but exposes no stream status, latency or error metadata, so it cannot monitor ingestion health. It is tempting because querying DSOs verifies whether data landed, and would be correct for validating record contents after ingestion rather than troubleshooting the stream itself.

Tableau workbook connection strings.

Why it fails: Tableau strings are unrelated to ingestion schemas.

Apex class definitions for data transformation.

Why it fails: Apex is not supported in batch data stream schemas.

Marketing Cloud Journey Builder canvas IDs.

Why it fails: Journey IDs are irrelevant to S3 batch streams.

Use a Calculated Insight to unnest the array after ingestion.

Why it fails: Calculated Insights run against already-modelled data, so they cannot reshape a nested array during ingestion; the stream's hierarchical flattening must map the array before load. Insights suit post-load aggregation and metric derivation, not schema transformation, so the nested items would never become queryable rows.

Reject the file, because Data Cloud only accepts flat CSV structures.

Why it fails: Data Cloud ingests JSON and supports nested structures through related DMOs, so rejecting the file abandons a supported requirement. Rejecting malformed or unsupported payloads is correct for genuinely invalid input, but this nested transaction array is exactly what relationship-based stream configuration handles.

Flatten the entire JSON into a single flat string field within a single DMO.

Why it fails: Flattening everything into one string field destroys the parent-child relationship between customer and transaction items, preventing the separate DMO mapping the array requires. Flattening suits simple single-object payloads, but nested arrays need their own related DMO linked by a primary key.

Salesforce Marketing Cloud Business Unit ID

Why it fails: A Marketing Cloud Business Unit ID governs subscriber and journey segmentation, not S3 file retrieval. It tempts because Data Cloud ingests Marketing Cloud data, but that uses Marketing Cloud Connect or ingestion API connectors, not the external cloud storage batch stream configuration requiring bucket, role, and file details.

Pre-built Tableau dashboard ID

Why it fails: A Tableau dashboard ID is a visualisation artefact, not an S3 ingestion parameter; the stream requires a connected source, target object, and field mapping. It tempts because Data Cloud surfaces Tableau assets in CRM Analytics contexts, but dashboards consume modelled data rather than defining batch storage ingestion.

Use an auto-generated sequential row number as the primary key to guarantee uniqueness across billions of rows.

Why it fails: A sequential surrogate key provides uniqueness but destroys join efficiency: matching billions of transactions to Individuals would require an additional lookup on the customer identifier, which is not the key. This adds cost without supporting the required segmentation joins.

Store the customer identifier and transaction date concatenated into a single composite text field to reduce the number of attributes.

Why it fails: Concatenating values into one text field prevents the platform from filtering on date ranges and from joining on a clean customer key. Segmentation filters and relationships would require parsing logic, dramatically degrading performance and maintainability at this data volume.

Model each transaction as a separate custom DMO so that segmentation queries scan smaller objects.

Why it fails: Splitting transactions across many DMOs multiplies object count and complicates joins to the Individual DMO. Segmentation would need to union results across objects, increasing query complexity and latency rather than reducing scan cost in any meaningful way.

Ingest the Contact object as-is and use a Data Transform to run a SQL query that filters records containing the desired picklist value.

Why it fails: A Data Transform can filter or shape rows but does not split a multi-value field into separate records for each selection. Filtering only reduces which records pass through; it does not create one row per picklist value, so the Contact Point Email DMO would still lack individual value-level rows.

Create a Formula Field in Data Cloud that concatenates the picklist values and map it to a custom DMO attribute.

Why it fails: Formula fields in Data Cloud operate on already-ingested data and cannot explode a multi-value source field into separate rows. Concatenating values into one attribute still leaves a single record holding all selections, so downstream segmentation cannot isolate one value per row in the Contact Point Email DMO.

Enable the multi-value picklist as a comma-separated string and store it in a single text field on the Individual DMO.

Why it fails: Storing the selections as one comma-separated string keeps all values in a single field, so a segmentation filter on one value cannot match a row cleanly. This approach also prevents the platform from creating one record per value, which the scenario explicitly requires for row-level filtering in the Contact Point Email DMO.

Create a custom DMO instead of using Sales Order, because standard DMOs cannot store currency codes alongside amounts.

Why it fails: Standard DMOs in Data Cloud do include currency-aware fields, so replacing Sales Order with a custom DMO is unnecessary and adds maintenance overhead. A custom DMO would also lose the benefit of standard relationships and prebuilt metrics, while the real requirement is simply to map the timestamp, amount, and currency code to the appropriate standard fields.

Convert the timestamp to a date-only string and map the amount as a text field, then create a custom attribute for currency.

Why it fails: Storing the amount as text prevents numeric aggregation and comparison in segmentation and analytics. Converting the timestamp to date-only also loses time precision that the source provides. The correct approach is to preserve the native timestamp and numeric types so the Sales Order DMO can perform currency-aware calculations and time-based filtering accurately.

Map the timestamp directly to the Sales Order date field and map the decimal amount to the amount field while ignoring the currency code.

Why it fails: Ignoring the currency code leaves the amount without context, so aggregation and reporting across multiple currencies become ambiguous. The timestamp format is compatible, but dropping the currency code means the Sales Order DMO cannot distinguish USD from EUR amounts, which breaks downstream currency-aware calculations and segmentation based on monetary thresholds.

Configure a Salesforce Data Cloud storage provider to persist the raw JSON payload before transformation.

Why it fails: Storage providers are used for file-based batch ingestion from cloud storage, not for API-based streams. An API connector retrieves and processes JSON directly through the ingestion framework, so provisioning a separate storage provider adds unnecessary configuration and does not contribute to authenticating or parsing the paginated API responses.

Enable Change Data Capture on the external system so only modified JSON records are transmitted.

Why it fails: Change Data Capture is a Salesforce platform feature for tracking changes on Salesforce objects and is not applicable to an external API that does not expose CDC. The external system controls its own change tracking, and Data Cloud ingestion relies on the API's pagination and filtering rather than CDC to retrieve records.

Manually upload a CSV export of the API response to seed the data stream before scheduling it.

Why it fails: A manual CSV upload creates a separate file-based ingestion path and does not configure the API connector. It would also produce a one-time load rather than an ongoing API-based stream, so it fails to satisfy the requirement of ingesting the paginated JSON responses directly from the external system on a schedule.

By modifying the JSON configuration file of the connector bundle

Why it fails: Connector bundles are managed metadata; editing their JSON is unsupported and does not expose per-stream field selection. It tempts because connector configuration sounds like where sources are defined, and hand-editing JSON would be the route for unsupported custom connector behaviour, not standard field selection.

In Setup under Object Manager

Why it fails: Object Manager defines metadata and field-level security, not which fields a Data Cloud data stream ingests. It tempts because that is where admins normally inspect Account fields, but field selection for a stream happens during data stream configuration in Data Cloud itself.

In the Data Model Object mapping canvas

Why it fails: The mapping canvas aligns source fields to Data Model Object fields after ingestion, so it cannot add fields the stream never extracted. It is tempting because mapping is where field-level work visibly happens, and it would be correct when reconciling ingested data to a DMO schema.

Batch Data Stream scheduled every hour

Why it fails: An hourly batch schedule introduces up to sixty minutes of latency and processes data in bulk windows, which contradicts the stem's low-latency, constantly updating clickstream requirement. Batch Data Streams suit periodic bulk loads where freshness tolerances are measured in hours. Real-time clickstream ingestion requires the Streaming Ingestion API.

Salesforce CRM Connector with changed data capture enabled

Why it fails: The CRM connector with change data capture replicates Salesforce CRM records, not external clickstream events, so it cannot ingest the web or app telemetry the stem describes. It is tempting because CDC delivers near-real-time updates, but only for CRM objects. Clickstream requires the Streaming Ingestion API or a web/mobile SDK connector.

Manual CSV file upload via the Data Cloud UI

Why it fails: Manual CSV upload is a one-off, human-triggered load with no streaming capability, so it cannot sustain constantly updating, high-volume clickstream data or meet low-latency requirements. It suits ad-hoc backfills or small reference datasets. Continuous ingestion needs the Streaming Ingestion API or a streaming connector instead.