Data-Architect Practice Test Questions

Explanation:

Option B (✔️ Best Fit) – Service Cloud License is designed for customer support, case management, and subscription-based services, which aligns with US's requirements:
1. Track customer complaints → Cases in Service Cloud.
2. Provide fee-based support → Entitlements, Contracts, and Service Contracts.
3. Knowledge Base (white papers) → Included in Service Cloud for article management.

Why Not the Others?

Option A (❌ Too Limited) – Lightning Platform Starter lacks Cases, Knowledge, and advanced support features.
Option C (❌ Vague) – "Salesforce License" is not a specific license type (could be any SKU).
Option D (❌ Sales-Focused) – Sales Cloud is for opportunity/lead tracking, not support/case management.

Use Individual objects to maintain the preferences with relationships to Lead, Person Account, and Users.

Explanation:

Option D (✔️ Best Practice) – Salesforce Individual Object is natively designed for this exact use case:
1. Centralized Preferences: Stores communication opt-ins/opt-outs (email, SMS, etc.) in one place.
2. Standard Relationships: Automatically links to Person Accounts, Contacts, Leads, and Users (no custom setup needed).
3. GDPR/Compliance Ready: Supports privacy laws (e.g., "Do Not Call" flags).

Why Not the Others?

Option A (❌ Redundant & Fragile) – Custom fields on each object duplicate effort and risk inconsistency.
Option B (❌ Overcomplicated) – Using Cases for preferences adds unnecessary process overhead.
Option C (❌ Custom Workaround) – A custom object requires complex automation to sync with all four objects.

Add custom indexes on frequently searched account and contact objects fields

Explanation:

✅ B. Add custom indexes on frequently searched fields When working with large data volumes (millions of records), query performance becomes dependent on how well the data can be indexed and filtered.
Salesforce uses selective filters and indexed fields to improve the performance of:
1. Reports
2. List views
3. SOQL queries
Adding custom indexes to commonly filtered fields (e.g., Email, Status, CreatedDate, or Custom Category fields) significantly improves performance by avoiding full table scans.

Why Not the Others?

❌ A. Load only data the user is permitted to access
While it’s good practice to enforce data access controls, this does not directly resolve performance issues for reports and views if queries are still non-selective or unindexed.
Also, Salesforce inherently applies user sharing rules when retrieving records.

❌ C. Limit loading to 2000 records
This defeats the purpose of using Salesforce to store and manage all relevant customer data.
Artificially limiting the data set prevents complete reporting and user access.

❌ D. Create a skinny table
Skinny tables are a backend performance optimization that Salesforce Support must create.
They are helpful but are not the first step. Custom indexes should be evaluated and implemented before requesting a skinny table.
Also, skinny tables don’t support all field types and aren’t automatically updated with schema changes.

Run one report per key field, grouped by that field, to understand its data variability.

Run a report that shows the percentage of blanks for the important fields.

Explanation:

Option B (✔️ Measures Consistency) – Grouping by key fields (e.g., "Country" or "Lead Source") reveals inconsistent formats (e.g., "USA" vs. "U.S.A").
Example: A report grouped by Phone field shows variations like "(123) 456-7890" vs. "1234567890".

Option C (✔️ Measures Completeness) – A blank-field report (e.g., matrix or summary report) quantifies missing data for key fields (e.g., "30% of Contacts lack Industry").
Example: Use COUNT() and BLANKVALUE() in a report formula.

Why Not the Others?

Option A (❌ Less Actionable) – "Last updated" time doesn’t indicate if data is complete or consistent.
Option D (❌ Premature) – Default values should only be applied after assessing gaps (risks masking bad data).

Utilize an app from the AppExchange to create data -quality dashboards.

Explanation:

✅ C. Utilize an AppExchange app for data-quality dashboards
This is the best approach for monitoring data quality.
Many AppExchange apps offer:
1. Data completeness dashboards
2. Field-level data validation tracking
3. Consistency checks
4. Trend analysis over time
These tools help visualize and report on data quality issues, making them ideal for identifying and improving user-entered data through the Salesforce UI.

Why Not the Others?

❌ A. Allow users to import data using Salesforce Import tools
This doesn’t address data quality monitoring; it’s a data entry method.
It could actually increase risk of bad data if not carefully controlled.

❌ B. Utilize a 3rd-party solution for data uploads
Again, this focuses on data loading, not monitoring.
While some 3rd-party tools offer cleansing, this doesn’t directly relate to user-entered UI data monitoring.

❌ D. Use Apex to validate phone/postal code formats
Apex validation is helpful for real-time field-level enforcement, but:
It’s narrow in scope (specific fields only).
It doesn’t provide monitoring, reporting, or dashboards.
It doesn't help track broader data quality metrics.

Work with Salesforce Support to enable Skinny Tables.

Make the queries more selective using indexed fields.

Explanation:

✅ B. Enable Skinny Tables
Skinny Tables are a Salesforce-managed optimization that improves read/query performance on large objects by storing frequently queried fields in a smaller, more efficient table.
Ideal when you have objects with many fields (like Order__c with 50+ fields) but only need to query a subset.
You must request them through Salesforce Support.

✅ D. Use selective queries with indexed fields
Salesforce optimizes SOQL queries by using indexes.
Making queries selective means using WHERE clauses that filter on indexed and highly selective fields, reducing the number of records scanned.
This is especially critical as the data volume grows (with 200,000 customers and millions of order records).

Why Not the Others?

❌ A. Use SOQL queries without WHERE conditions
This is the opposite of good practice. Queries without WHERE clauses are non-selective and will result in full table scans, which can hit governor limits or cause timeouts.

❌ C. Reduce number of triggers on Order__c
While too many triggers can impact DML performance, this is not directly related to SOQL query performance.
Also, it's a development hygiene concern rather than a data access optimization.

Explanation:

Option A (✔️ Critical for Bulk Loads) – Disabling validation rules, triggers, and workflows during bulk data loads prevents:
1. Unintended automation (e.g., trigger-driven updates skewing data).
2. Validation errors blocking records (e.g., required field checks).
3. Performance bottlenecks from cascading automation.
4. How to disable: Use "Bulk API" with options to bypass triggers or deactivate automation temporarily.

Why Not the Others?

Option B (❌ Off-Topic) – Duplicate rules help prevent dupes but don’t address automation conflicts.
Option C (❌ Inefficient) – Smaller batches reduce errors but don’t solve automation interference.
Option D (❌ Risky) – Bulkifying triggers is a general best practice, but it doesn’t prevent unwanted automation during imports.

Create a custom lookup field on the standard Product to reference the parent record in the hierarchy.

Explanation:

Option B (✔️ Best Practice) – A custom lookup field on the Product2 object (e.g., Parent_Product__c) allows:
1. Hierarchical relationships (e.g., "Laptop → Battery → Charger").
2. Flexibility: Unlike master-detail, lookup relationships don’t cascade delete and allow products to exist independently.
3. Sync compatibility: Matches how most external product master systems structure hierarchies (parent-child references).

Why Not the Others?

Option A (❌ Backward Logic) – A child-reference lookup would require multiple fields (e.g., Child_Product_1__c, Child_Product_2__c), which is impractical.
Option C (❌ Overly Restrictive) – Master-detail fields enforce ownership/cascade deletion, which is unnecessary for product hierarchies.
Option D (❌ Irrelevant) – The Product Family picklist is for categorization, not hierarchical relationships.

Implement an AppExchange package.

Explanation:

✅ B. Implement an AppExchange package

To track field-level changes and support data recovery, you need a comprehensive audit and backup solution.
Several AppExchange packages (like OwnBackup, Spanning, or Odaseva) offer:
1. Automated daily backups
2. Field-level change tracking
3. Restore capabilities (record-level and field-level)
4. Audit history beyond Salesforce’s native field history limitations
This is the most scalable, automated, and reliable approach for enterprises concerned about data corruption or loss.

Why Not the Others?

❌ A. Reduce data storage by purging old data
While managing storage is important, purging data does not help with recovery or auditing.
In fact, it can make things worse if critical data is removed before being backed up.

❌ C. Review projected data storage needs
Important for long-term planning, but it doesn’t provide any recovery or auditing capability.
It’s a capacity exercise, not a backup strategy.

❌ D. Schedule a weekly export file
Native Salesforce weekly data export provides only a basic backup.
It does not track field-level changes, deletions, or provide a quick restore mechanism.
Also, weekly frequency may be insufficient for detecting or responding to daily corruption.

Salesforce does NOT allow more than four objects in a single report type.

Explanation:

Option C (✔️ True Limitation) – Salesforce report types can include a maximum of four objects (due to joins in the underlying SQL query).
Example: You could link Account → Opportunity → Order → Order Line Item, but cannot add Contact as a fifth object.

Why Not the Others?

Option A (❌ False) – Custom report types can include Opportunity data (e.g., Account + Opportunity).
Option B (❌ False) – Salesforce supports Orders (Order object) and Order Line Items (OrderItem object) (B2B/B2C).
Option D (❌ False) – Reports can combine Account and Contact data (e.g., "Accounts with Contacts" report type).