Salesforce-Platform-Data-Architect Practice Test Questions (2026)

Use Salesforce Connect and an external object to display the order history in Salesforce

Explanation:

This question describes a scenario where a massive amount of external data (50 million customers' order history) needs to be accessed by Salesforce users in a real-time or near-real-time fashion without being physically stored in the Salesforce org. The data architect must choose a solution that provides a seamless user experience while handling the large volume of data efficiently.

✔️ B. Use Salesforce Connect and an external object to display the order history in Salesforce
This is the most effective solution. Salesforce Connect is designed specifically for this use case. It allows you to create External Objects that represent data from an external system (like the ERP). When a user views a customer's record, Salesforce Connect fetches the relevant order history on-demand using a real-time callout. This avoids duplicating 50 million customer records and their order history in Salesforce, which would be inefficient and create data sync challenges. This approach provides a seamless user experience while keeping the data where it resides.

❌ A. Use an Apex callout to populate a text area field for displaying the order history.
This is not an ideal solution. An Apex callout would require a custom-coded solution, which is more complex and less scalable than Salesforce Connect. Furthermore, populating a text area field is a poor user experience. The data would be static and not easily sortable or filterable, and it could exceed field size limits.

❌ C. Import the order history into a custom Salesforce object, update nightly
Importing 50 million records and their order history would be a massive and resource-intensive undertaking. A nightly update would mean the data is always at least one day out of date, which is not ideal for a contact center that needs real-time information. This approach is prone to data latency issues and is not scalable or efficient for such a large data set.

❌ D. Embed the ERP system in an iframe and display on a custom tab.
Embedding the ERP in an iframe provides visibility but does not integrate the data into the Salesforce platform. It creates a separate, non-native user interface experience. Users would have to navigate a different system's UI within Salesforce, which is not a "seamless user experience." It also prevents any integration of the data with native Salesforce features like reporting or automation.

Reference:
Salesforce Connect

Use Einstein Analytics for multi-org.

Explanation:

Option C (✔️ Best Choice) – Einstein Analytics (now Tableau CRM) is Salesforce’s native AI-powered analytics platform, designed to:
Aggregate data from multiple orgs (via connectors, ETL, or Salesforce Data Federation).
Provide a unified global view of Accounts, Opportunities, etc.
Leverage AI-driven insights (predictive analytics, anomaly detection, etc.).

Option A (❌ Limited) – Standard reports/dashboards cannot pull data from multiple orgs into a single view.

Option B (❌ Alternative, but not best) – While some AppExchange tools (e.g., Gizmo, CRM Analytics connectors) can help, they lack native AI integration and may require extra setup.

Option D (❌ Not scalable) – Custom Python scripts are manual, brittle, and unsupported for enterprise reporting needs.

Keep users out of public groups that can be used as the source for sharing rules.

Assign a default user as owner of account and do not assign any role to default user.

Assign “view all” permission on profile to give access to account.

Explanation:

Ownership skew occurs when a single user owns a large number of records, causing performance issues in Salesforce. For UC’s migration of 100,000 accounts, the data architect must recommend strategies to distribute ownership and manage access efficiently. This involves avoiding concentrated ownership, optimizing sharing rules, and ensuring permissions align with business needs without overloading specific users or roles, thus maintaining system performance and scalability.

Correct Options:

✅ B. Keep users out of public groups that can be used as the source for sharing rules.
Public groups used in sharing rules can lead to ownership skew if many records are assigned to users within them, causing performance bottlenecks. By limiting users in such groups, UC reduces the risk of excessive sharing calculations, ensuring smoother system performance during the migration of 100,000 accounts. This approach promotes balanced access control and scalability.

✅ C. Assign a default user as owner of account and do not assign any role to default user.
Assigning a default user (e.g., an integration user) as the owner of accounts prevents any single active user from owning too many records, reducing skew. By not assigning a role to this user, UC avoids unintended access through the role hierarchy, ensuring controlled data access and improved performance during large-scale migrations.

✅ D. Assign “view all” permission on profile to give access to account.
Granting “View All” permission on the Account object via profiles allows users to access records without relying on ownership or complex sharing rules, which can contribute to skew. This simplifies access control for UC’s large dataset, improves query performance, and reduces the risk of performance degradation caused by ownership concentration.

Incorrect Options:

❌ A. Assigned a default user as owner of accounts, and assign role in hierarchy.
While assigning a default user as owner helps, placing them in the role hierarchy can inadvertently grant access to many records through role-based sharing, exacerbating ownership skew. This could lead to performance issues, as the system processes extensive sharing calculations, making it unsuitable for UC’s large-scale migration.

❌ E. Assign a default user as owner of accounts and assigned top most role in hierarchy.
Assigning the default user to the top of the role hierarchy grants excessive access to records, increasing the risk of ownership skew and performance degradation. This approach undermines controlled data access and can overwhelm the system with unnecessary sharing calculations, making it ineffective for UC’s needs.

Reference:
Salesforce Help: Managing Ownership Skew
Salesforce Help: Sharing Rules

Use Bulk API parallel mode for data migration

Explanation:

Option A (✔️ Best Solution) – Bulk API in parallel mode processes batches concurrently, reducing lock contention and improving performance. This is ideal for large data migrations within tight windows.
Why? Parallel mode splits the workload across multiple threads, minimizing row/table locks.

Option B (❌ Slower & Riskier) – Serial mode processes records sequentially, increasing the chance of locks and exceeding the 2-hour window.

Option C (❌ Overcomplicated) – While Batch Apex can help with complex logic, it doesn’t inherently resolve locking issues and adds unnecessary steps.

Option D (❌ Irrelevant) – This setting affects record deletion behavior, not locking during bulk updates.

PK Chunking

Explanation:

When a bulk query against a large custom object like Order__c with 15 million records times out, it indicates a performance issue due to the sheer volume of data being processed in a single operation. The problem is that the query tries to fetch too many records at once, exceeding the processing time limits. The recommended solution is to break down this large query into smaller, more manageable chunks.

Correct Option:

✅ B. PK Chunking
PK Chunking is a highly effective strategy for handling large data volumes in bulk API queries. It automatically splits a large query into multiple smaller queries based on a record's primary key (e.g., the Id field). By processing the data in smaller, sequentially processed batches, it avoids the timeout issues associated with fetching a huge number of records at once. This method significantly improves the reliability and performance of bulk data extraction.

Incorrect Options:

❌ A. Tooling API
The Tooling API is designed for managing metadata and inspecting organizational structure, not for querying large volumes of data from standard or custom objects. Its primary purpose is to help developers build custom development tools, manage code, and inspect object definitions. It's not the right tool for bulk data extraction from business objects.

❌ C. Metadata API
The Metadata API is used for retrieving, deploying, creating, or updating an organization's metadata, such as object definitions, page layouts, and Apex classes. It's focused on the schema and configuration of the Salesforce instance, not on the actual record data. Therefore, it is completely irrelevant to the problem of a data query timing out.

❌ D. Streaming API
The Streaming API is used for receiving near real-time notifications about changes to Salesforce records. It's an event-driven mechanism that provides a way to get updates as they happen, using PushTopic queries or Change Data Capture. It is not designed for the large-scale extraction of existing data, which is the problem presented in the question.

Reference:
Salesforce Bulk API 2.0 and PK Chunking

Make sure the query doesn't contain NULL in any filter criteria.

Create custom indexes on the fields used in the filter criteria.

Explanation:

✅ A. NULL in filter criteria
Queries using WHERE field = NULL or WHERE field != NULL are problematic because they bypass indexes and require full table scans, especially on large datasets like 12 million records.
Such filters are not selective, which contributes to query timeouts.

✅ C. Custom indexes
Indexes improve query performance by allowing Salesforce to efficiently retrieve relevant records.
If fields used in WHERE clauses are not selectively indexed, the query can exceed governor limits or time out.
Data Architects should evaluate selectivity and whether custom indexes (skinny tables or external indexes) are needed.

Why Not the Others?

❌ B. Create a formula field instead of multiple filter criteria
Formula fields are not indexed by default, and using them in WHERE clauses can actually hurt performance.
Multiple filter criteria aren't inherently problematic—how selective the filters are matters more.

❌ D. Modify the integration users' profile to have View All Data
This has no impact on query performance.
It changes access rights, not how efficiently the query runs.

Use an AppExchange package for Data Quality to match Salesforce data against the Trusted source.

Explanation:

Option C (✔️ Best Practice) – AppExchange data quality tools (e.g., Informatica Cloud, Talend, Cloudingo, or DemandTools) are designed to:
Compare large datasets (20M+ records) efficiently.
Identify discrepancies between Salesforce and the MDM.
Automate cleansing/syncing to align Salesforce with the trusted source.
Support ongoing monitoring to prevent future drift.

Why Not the Others?

Option A (❌ Not Scalable) – Manual Excel comparison is error-prone and impossible at this scale (20M records).
Option B (❌ Resource-Intensive) – Apex batch jobs can work but require custom development and lack built-in matching logic (e.g., fuzzy matching).
Option D (❌ Risky) – Assuming auto-correction ignores data governance and risks reporting inaccuracies.

Implement a custom big object to store the data.

Explanation:

For migrating 100 million order records from a legacy ERP application into the Salesforce platform, where there are no requirements for reporting on the migrated data, the primary concern is minimizing performance degradation. Salesforce Big Objects are specifically designed to handle large volumes of data (in the millions or billions of records) without impacting the performance of the core platform. Here's a detailed breakdown of why option D is the best choice:

Why Big Objects?
Big Objects in Salesforce are optimized for storing massive datasets that do not require frequent querying or reporting. They are stored in a scalable, distributed architecture outside the standard Salesforce database, which helps prevent performance degradation on the main platform. Since UC has no reporting requirements, Big Objects are ideal because they are not meant for real-time reporting or complex queries but are excellent for archival or reference data.

Option Analysis:

A. Create a custom object to store the data.
Custom objects are stored in the standard Salesforce database, which is optimized for transactional data and real-time access. Storing 100 million records in a custom object would significantly degrade platform performance due to the limitations of standard storage (e.g., governor limits, database contention, and slower query performance). This option is not suitable for such a large dataset.

B. Use a standard big object defined by Salesforce.
Salesforce does not provide standard Big Objects for specific use cases like orders. Big Objects are typically custom-defined to meet specific business needs. While Salesforce offers some prebuilt objects (like Field History Archive), there is no standard Big Object for orders, making this option incorrect.

C. Use the standard “Order” object to store the data.
The standard Order object is designed for active transactional data and is tightly integrated with Salesforce features like reporting, workflows, and automation. Storing 100 million records in the standard Order object would severely impact performance, as it is not built for such large-scale data storage. It would also consume significant storage and processing resources, leading to slower performance across the platform.

🟢 D. Implement a custom big object to store the data.
A custom Big Object is the best choice for this scenario. It allows UC to define a schema tailored to the order data and store the 100 million records efficiently. Custom Big Objects are designed for high-scale data storage, with asynchronous querying capabilities and minimal impact on platform performance. Since no reporting is required, the limitations of Big Objects (e.g., limited support for SOQL queries and no direct reporting) are not a concern.

Additional Considerations:
➡️ Data Access and Querying: Big Objects support asynchronous SOQL queries and are not included in standard reports or dashboards, which aligns with UC’s lack of reporting requirements. For any occasional data access, UC can use asynchronous queries or integrate with external systems if needed.
➡️ Scalability: Big Objects are built to scale to billions of records, making them suitable for UC’s 100 million records and any future growth.
➡️ Performance Impact: By storing data in a custom Big Object, UC avoids overloading the standard Salesforce database, ensuring that other platform operations (e.g., user interactions, transactions) remain performant.

Implementation Notes:
➡️ UC would need to define the custom Big Object schema to match the order data structure from the legacy ERP system.
➡️ Data migration can be performed using tools like Salesforce Data Loader or Bulk API, with the data being written to the Big Object via asynchronous processes.
➡️ Permissions and access control for the Big Object can be configured to ensure secure access.

References:
Salesforce Documentation: Big Objects Overview
Salesforce Help: Big Object Considerations
Salesforce Architect Guide: Data Architecture and Management

Create a custom big object to capture the reward program data and display it on the contact record and update nightly from the point-of-scale system.

Explanation:

Option D (✔️ Best Solution) – Big Objects are designed for high-volume, low-frequency data (e.g., 100M records/month).

Pros:
1. Scalable storage: Handles billions of records without impacting Salesforce performance.
2. Queryable: Supports SOQL for summaries (e.g., "12-month trailing spend").
3. Integrated UI: Display summaries on Contact/Account pages via Lightning components.

Why Not the Others?

Option A (❌ Storage Bloat) – Standard/custom objects hit storage limits with 100M monthly records.
Option B (❌ Latency & Complexity) – External objects via Salesforce Connect introduce real-time query delays and require external infrastructure.
Option C (❌ Poor UX) – Switching systems disrupts support workflows and lacks Salesforce integration.

Skinny tables can contain frequently used fields and thereby help avoid joins.

Skinny tables are kept in sync with changes to data in the source tables.

Skinny tables do not include records that are available in the recycle bin.

Explanation:

Skinny tables are special, Salesforce-managed database tables used to optimize performance when working with large volumes of data. They reduce the number of joins, replicate important fields from standard or custom objects, and exclude recycle bin data to keep queries lean. They automatically stay in sync with source objects, so users and admins don’t manage them directly.

✅ Correct Option: A
Skinny tables minimize joins by storing frequently used fields together, making reports and queries faster. This is especially beneficial when the original object is heavily normalized.

✅ Correct Option: D
Skinny tables are automatically synchronized by Salesforce whenever changes occur in the source objects. This ensures reports and queries are always working on up-to-date data.

✅ Correct Option: E
By excluding records in the recycle bin, skinny tables avoid unnecessary bloat. This improves performance further by keeping only active, relevant records.

❌ Incorrect Option: B
Skinny tables don’t provide custom indexing on multi-select picklist fields. Indexing on such fields is not supported, and skinny tables don’t override that limitation.

❌ Incorrect Option: C
They don’t combine data across multiple objects. Each skinny table corresponds to a single object, though it may include fields from the parent in certain relationships.

🔗 Reference:
Salesforce Skinny Tables