Data-Architect Practice Exam Questions Spring 2025 Page 10

Two million Opportunities need to be loaded in different batches into Salesforce using the Bulk API in parallel mode. What should an Architect consider when loading the Opportunity records?

A.

Use the Name field values to sort batches.

B.

Order batches by Auto-number field.

C.

Create indexes on Opportunity object text fields.

D.

Group batches by the AccountId field.

D.

Group batches by the AccountId field.

Explanation:

✅ D. Group batches by the AccountId field.
When using Bulk API in parallel mode, contention on parent records (like AccountId) can cause locking issues and errors. Grouping batches by AccountId ensures that records with the same parent do not get processed in parallel, thereby reducing lock contention and improving performance.

❌ A. Use the Name field – Sorting by Name has no performance impact for bulk processing.
❌ B. Order by Auto-number field – Similar to Name, Auto-number ordering won’t reduce locking or improve performance.
❌ C. Index text fields – Indexing helps in querying, not in bulk loading.

Northern Trail Outfitters (NTO) wants to capture a list of customers that have bought a particular product. The solution architect has recommended to create a custom object for product, and to create a lookup relationship between its customers and its products. Products will be modeled as a custom object (NTO_ Product__ c) and customers are modeled as person accounts. Every NTO product may have millions of customers looking up a
single product, resulting in a lookup skew. What should a data architect suggest to mitigate Issues related to lookup skew?

A.

Create multiple similar products and distribute the skew across those products.

B.

Change the lookup relationship to master-detail relationship.

C.

Create a custom object to maintain the relationship between products and customers.

D.

Select Clear the value of this field option while configuring the lookup relationship.

C.

Create a custom object to maintain the relationship between products and customers.

Explanation:

✅ Correct Answer: C. Create a custom object to maintain the relationship between products and customers.
Modeling the many-to-many relationship with a junction object (like ProductCustomer__c) breaks the direct lookup from millions of customers to one product, effectively eliminating lookup skew.

❌ A. Multiple product records – Splitting a product into duplicates just to avoid skew creates data integrity issues.

❌ B. Master-detail – Master-detail still enforces ownership, potentially leading to the same skew issue.

❌ D. “Clear the value” option – Only applies when deleting the referenced record, not for preventing skew.

Universal Containers (UC) has lead assignment rules to assign leads to owners. Leads not routed by assignment rules are assigned to a dummy user. Sales rep are complaining of high load times and issues with accessing leads assigned to the dummy user. What should a data architect recommend to solve these performance issues?

A.

Assign dummy user last role in role hierarchy

B.

Create multiple dummy user and assign leads to them

C.

Assign dummy user to highest role in role hierarchy

D.

Periodically delete leads to reduce number of leads

B.

Create multiple dummy user and assign leads to them

Explanation:

✅ Correct Answer: B. Create multiple dummy users and assign leads to them.
When too many records are owned by a single user, performance degradation (called ownership skew) can occur. Distributing leads across multiple dummy users spreads the load and improves performance.

❌ A. Lowest role – Doesn’t help with ownership-based sharing calculations.

❌ C. Highest role – Could increase visibility and sharing recalculations, worsening the issue.

❌ D. Deleting leads – Doesn’t solve root cause and may lose valuable data.

Northern Trail Outfitters (NTO) wants to start a loyalty program to reward repeat customers. The program will track every item a customer has bought and grants them points for discounts. The following conditions will exist upon implementation:
Data will be used to drive marketing and product development initiatives.
NTO estimates that the program will generate 100 million rows of date monthly.
NTO will use Salesforce's Einstein Analytics and Discovery to leverage their data and make business and marketing decisions. What should the Data Architect do to store, collect, and use the reward program data?

A.

Create a custom big object in Salesforce which will be used to capture the Reward Program data for consumption by Einstein.

B.

Have Einstein connect to the point of sales system to capture the Reward Program data.

C.

Create a big object in Einstein Analytics to capture the Loyalty Program data.

D.

Create a custom object in Salesforce that will be used to capture the Reward Program data.

A.

Create a custom big object in Salesforce which will be used to capture the Reward Program data for consumption by Einstein.

Explanation:

✅ A. Create a custom big object in Salesforce
Big Objects are the best choice for storing high-volume, immutable data like reward transactions. They're optimized for storage and can be queried via SOQL (with indexed fields), and are compatible with Einstein Analytics.

❌ B. Connect Einstein directly – Not scalable or reliable for data storage and historical queries.

❌ C. Big Objects don’t exist in Einstein Analytics – They exist in the core platform, not Einstein.

❌ D. Custom object – Not scalable for 100M+ rows/month and hits storage limits.

Universal Containers (UC) is a business that works directly with individual consumers (B2C). They are moving from a current home-grown CRM system to Salesforce. UC has about one million consumer records. What should the architect recommend for optimal use of Salesforce functionality and also to avoid data loading issues?

A.

Create a Custom Object Individual Consumer c to load all individual consumers.

B.

Load all individual consumers as Account records and avoid using the Contact object.

C.

Load one Account record and one Contact record for each individual consumer.

D.

Create one Account and load individual consumers as Contacts linked to that one Account.

C.

Load one Account record and one Contact record for each individual consumer.

Explanation:

Person Accounts (Account + Contact merged):
1. Optimize B2C modeling with dedicated layouts.
2. Avoid "Contact sprawl" (Option D’s single Account with 1M Contacts creates roll-up skew).
3. Enable standard features (e.g., Opportunities).

Rejected options:

A: Custom objects lose native CRM functions.
B/D: Bloat Accounts or create hierarchy issues.

Universal Containers (UC) uses Salesforce for tracking opportunities (Opportunity). UC uses an internal ERP system for tracking deliveries and invoicing. The ERP system supports SOAP API and OData for bi-directional integration between Salesforce and the ERP system. UC has about one million opportunities. For each opportunity, UC sends 12 invoices, one per month. UC sales reps have requirements to view current invoice status and invoice amount from the opportunity page. When creating an object to model invoices, what should the architect recommend, considering performance and data storage space?

A.

Use Streaming API to get the current status from the ERP and display on the Opportunity page.

B.

Create an external object Invoice _x with a Lookup relationship with Opportunity.

C.

Create a custom object Invoice _c with a master -detail relationship with Opportunity.

D.

Create a custom object Invoice _c with a Lookup relationship with Opportunity.

B.

Create an external object Invoice _x with a Lookup relationship with Opportunity.

Explanation:

✅ B. Create an external object Invoice__x with a Lookup relationship to Opportunity External Objects (via Salesforce Connect) let you access invoice data in real-time from ERP without consuming storage. With 12 invoices per opportunity, storing all in Salesforce (12 million+ records) would be inefficient.

❌ A. Streaming API – Good for real-time updates but doesn’t store or display data.

❌ C & D. Custom object – Would consume a lot of storage and create maintenance overhead.

UC is rolling out Sales App globally to bring sales teams together on one platform. UC expects millions of opportunities and accounts to be creates and is concerned about the performance of the application. Which 3 recommendations should the data architect make to avoid the data skew? Choose 3 answers.

A.

Use picklist fields rather than lookup to custom object.

B.

Limit assigning one user 10000 records ownership.

C.

Assign 10000 opportunities to one account.

D.

Limit associating 10000 opportunities to one account.

E.

Limit associating 10000 records looking up to same records.

B.

Limit assigning one user 10000 records ownership.

D.

Limit associating 10000 opportunities to one account.

E.

Limit associating 10000 records looking up to same records.

Explanation:

✅ B. Limit assigning one user 10,000 records – Reduces ownership skew, avoiding performance hits.

✅ D. Limit associating 10,000 opportunities to one account – Reduces parent-child skew which can cause locking.

✅ E. Limit associating 10,000 records to same record – General guideline to prevent lookup skew.

❌ A. Use picklist over lookup – Doesn’t solve skew-related problems.

❌ C. 10,000 opps to one account – This is actually what causes skew, not avoids it.

Universal Containers (UC) provides shipping services to its customers. They use Opportunities to track customer shipments. At any given time, shipping status can be one of the 10 values. UC has 200,000 Opportunity records. When creating a new field to track shipping status on opportunity, what should the architect do to improve data quality and avoid data skew?

A.

Create a picklist field, values sorted alphabetically.

B.

Create a Master -Detail to custom object ShippingStatus c.

C.

Create a Lookup to custom object ShippingStatus c.

D.

Create a text field and make it an external ID.

A.

Create a picklist field, values sorted alphabetically.

Explanation:

✅ A. Create a picklist field, values sorted alphabetically
Picklists are simple, enforce data consistency, and avoid skew issues. Shipping status is best represented with a controlled picklist, ensuring data quality.

❌ B & C. Related object – Overengineering for a simple status field; could cause skew if many records point to the same object.

❌ D. Text with external ID – Doesn’t enforce controlled values; poor for data quality.

A Customer is migrating 10 million order and 30 million order lines into Salesforce using Bulk API. The Engineer is experiencing time-out errors or long delays querying parents order IDs in Salesforce before importing related order line items. What is the recommended solution?

A.

Query only indexed ID field values on the imported order to import related order lines.

B.

Leverage an External ID from source system orders to import related order lines.

C.

Leverage Batch Apex to update order ID on related order lines after import.

D.

Leverage a sequence of numbers on the imported orders to import related order lines.

B.

Leverage an External ID from source system orders to import related order lines.

Explanation:

✅ B. Leverage an External ID from source system orders
Using External IDs allows you to associate child records (order lines) with parent records (orders) without querying Salesforce for internal IDs, reducing API load and timeouts.

❌ A. Indexed ID field – Still requires querying Salesforce, which is slow at scale.

❌ C. Batch Apex – Adds unnecessary complexity and async delays.

❌ D. Sequence numbers – Doesn’t support reliable relationships unless tied to external IDs.

Universal Containers has more than 10 million records in the Order_c object. The query has timed out when running a bulk query. What should be considered to resolve query timeout?

A.

Tooling API

B.

PK Chunking

C.

Metadata API

D.

Streaming API

B.

PK Chunking

Explanation:

✅ B. PK Chunking
PK Chunking is a feature of the Bulk API that breaks up large data sets into manageable chunks based on primary keys. It improves performance and avoids timeouts for large exports.

❌ A. Tooling API – Used for metadata, not querying data records.

❌ C. Metadata API – Used for deploying metadata, not data extraction.

❌ D. Streaming API – Meant for event notifications, not bulk data access.

Data-Architect Practice Test Questions