DATA-ARCHITECT Practice Questions

The three characteristics of a Skinny table that help improve report and query performance are:

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. These characteristics are beneficial because they reduce the query

complexity and execution time, and improve the data accuracy and freshness. For example, skinny

tables can contain frequently used fields from multiple objects, such as Account and Contact, and

thereby help avoid joins that can slow down queries4. Skinny tables are updated automatically when

the source tables are modified, so they always reflect the latest data5. Skinny tables do not include

records that are available in the recycle bin, so they only contain active records that are relevant for

reports and queries.

According to this article, the Apex Connector Framework enables developers to create custom

adapters for Salesforce Connect to access data from external systems that are not OData enabled.

This can meet UC’s requirements of exposing shipment details to the custom application and

accessing the data in real time.

According to the official Salesforce guide1, assigning leads to a single dummy user can cause

performance issues and data skew, especially if the dummy user owns more than 10,000 records.

Data skew occurs when a single user or a small number of users own a disproportionately large

number of records, which can affect query performance and sharing calculations. Option B is the

correct answer because it suggests creating multiple dummy users and assigning leads to them,

which can distribute the load and reduce data skew. Option A is incorrect because assigning the

dummy user to the last role in the role hierarchy does not affect the performance or data skew

issues. Option C is incorrect because assigning the dummy user to the highest role in the role

hierarchy can worsen the performance and data skew issues, as it will grant access to more users and

records. Option D is incorrect because periodically deleting leads can cause data loss and does not

address the root cause of the problem.

Using hard delete in Bulk API, identifying records that have not been modified or used in last 3 years,

and archiving the records in EDW before deleting from Salesforce are all good recommendations to

reduce the number of records from the org1. Using hard delete in batch Apex or Rest API may not be

as efficient or scalable as Bulk API

Enabling granular locking (option B) is the best option to prevent the error, as it allows finer control

over how records are locked during automated or manual processes, and reduces the chances of lock

contention or deadlock. Reducing number of users updated concurrently (option A) is not a good

option, as it may limit the productivity and efficiency of the system admins, and it does not address

the root cause of the error. Analyzing Splunk query to spot offending records (option C) is also not a

good option, as it may require more time and effort, and it does not provide a permanent solution

for the error. Increasing CPU for the Salesforce org (option D) is also not a good option, as it may

introduce additional cost and complexity, and it does not solve the root cause of the error.

Enabling granular locking allows concurrent sharing rule calculations and group membership updates

to run without locking each other1. This can help resolve the group membership locking issues that

UC is experiencing.

Lightning Platform Plus is the license type that best fits UC’s requirements, as it allows up to 50

custom objects and 40,000 API calls per user per 24-hour period4. Service Cloud does not provide

enough custom objects or API calls. Lightning Platform Start only allows up to 10 custom objects and

5,000 API calls per user per 24-hour period. Lightning External Apps Start is for external users and

does not provide enough API calls.

Using a validation rule is the best way to ensure that all customers provide either a phone number or

an email address when registering for an account, as it allows defining a formula that evaluates

whether a record meets certain criteria. Using required fields may not work if both phone number

and email address are required. Using an Apex class or a Process Builder may be more complex or

cumbersome than using a validation rule.

Async SOQL with a custom object (option B) and Einstein Analytics (option D) are the two native

tools that can be used to report on big object data. Async SOQL allows querying big object data and

storing the results in a custom object, which can then be used for reporting. Einstein Analytics can

connect to big object data sources and provide advanced analytics and visualization

features. Standard reports and dashboards (option A) and standard SOQL queries (option C) cannot

be used to report on big object data, as they do not support big object fields

Having each system pull the record changes from Salesforce using change data capture (option D) is

the correct solution for ensuring all systems using customer data are kept up to date, as it allows the

systems to subscribe to real-time events from Salesforce and receive notifications when customer

records are created, updated, deleted, or undeleted. Sending customer data nightly to the system of

truth in a scheduled batch job (option A) or sending customer record changes from Salesforce to each

system in a nightly batch job (option B) are not good solutions, as they may cause data latency and

inconsistency, and they do not provide real-time updates. Sending customer record changes from

Salesforce to the system of truth in real time (option C) is also not a good solution, as it does not

address how the other systems will receive the updates from the system of truth.