Scenario practice questions

What is the recommended approach to manage 'Skinny Tables' in an environment with Large Data Volumes?

Trap 1: Enable skinny tables for every object with more than 1 million…

Enabling skinny tables for all large objects is excessive and unnecessary. They introduce complexity and maintenance overhead. They should be used selectively for objects where query performance remains unacceptable after traditional indexing and database optimization strategies have already been exhausted, rather than as a default standard.

Trap 2: Manually update skinny tables using DML statements in Apex.

Skinny tables are read-only to users and developers; they are synchronized automatically by the Salesforce platform when the base table is updated. Manually attempting to modify or insert into a skinny table is not possible and demonstrates a misunderstanding of how the platform maintains data consistency.

Trap 3: Always include every field of the object in the skinny table.

Including every field defeats the purpose of a skinny table, which is to minimize the row width and increase the number of rows that fit into a data block. A properly designed skinny table should only include the fields necessary for the specific performance-sensitive queries that require optimization.

A
Enable skinny tables for every object with more than 1 million records.
Why it fails: Enabling skinny tables for all large objects is excessive and unnecessary. They introduce complexity and maintenance overhead. They should be used selectively for objects where query performance remains unacceptable after traditional indexing and database optimization strategies have already been exhausted, rather than as a default standard.
B
Request them only for high-read-volume objects where performance is critical.
Skinny tables are designed to solve specific performance issues by reducing join complexity. Because they are maintained by Salesforce Support, they add administrative overhead. They are best reserved for core objects where read performance is the primary bottleneck and standard indexing cannot provide the necessary speed.
C
Manually update skinny tables using DML statements in Apex.
Why it fails: Skinny tables are read-only to users and developers; they are synchronized automatically by the Salesforce platform when the base table is updated. Manually attempting to modify or insert into a skinny table is not possible and demonstrates a misunderstanding of how the platform maintains data consistency.
D
Always include every field of the object in the skinny table.
Why it fails: Including every field defeats the purpose of a skinny table, which is to minimize the row width and increase the number of rows that fit into a data block. A properly designed skinny table should only include the fields necessary for the specific performance-sensitive queries that require optimization.

Question 2mediummultiple choice

Northern Trail Outfitters uses Salesforce as its system of entry for customer records, but the ERP remains the system of record for billing addresses. A data architect must design the MDM integration so that when a billing address changes in the ERP, Salesforce is updated, but address edits made in Salesforce do not flow back to the ERP. Which MDM pattern should the architect implement?

Trap 1: Federated access using Salesforce Connect to display the ERP…

Federation is a valid MDM pattern, but it makes the address available only through live callouts rather than storing it in Salesforce. Reporting, offline use, and automation on the address field would break, and the requirement states that Salesforce should be updated when the ERP changes, implying a persisted replicated value rather than a virtual external object reference.

Trap 2: Bi-directional synchronization with last-write-wins conflict…

Last-write-wins would allow a Salesforce address edit to overwrite the ERP value whenever the Salesforce record has the later timestamp, directly violating the requirement that Salesforce must not push address changes back. It also introduces nondeterministic outcomes when clocks or time zones differ between systems, so it fails the scenario on both the direction and the conflict-resolution requirements.

Trap 3: Bi-directional synchronization with a survivorship rule that always…

A survivorship rule that always prefers the ERP value still requires a write path from Salesforce to the ERP, because bi-directional synchronization means both systems publish changes. The Salesforce edit would be transmitted and then discarded or overwritten, creating unnecessary traffic and audit noise, and it does not satisfy the explicit requirement that Salesforce edits must not flow back.

A
Federated access using Salesforce Connect to display the ERP address in real time without persisting it in Salesforce.
Why it fails: Federation is a valid MDM pattern, but it makes the address available only through live callouts rather than storing it in Salesforce. Reporting, offline use, and automation on the address field would break, and the requirement states that Salesforce should be updated when the ERP changes, implying a persisted replicated value rather than a virtual external object reference.
B
Bi-directional synchronization with last-write-wins conflict resolution based on the most recent ModifiedDate.
Why it fails: Last-write-wins would allow a Salesforce address edit to overwrite the ERP value whenever the Salesforce record has the later timestamp, directly violating the requirement that Salesforce must not push address changes back. It also introduces nondeterministic outcomes when clocks or time zones differ between systems, so it fails the scenario on both the direction and the conflict-resolution requirements.
C
One-way synchronization from the ERP to Salesforce, with Salesforce address fields made read-only for users.
This implements a system-of-record pattern where the ERP owns the billing address attribute and Salesforce is a downstream consumer. Making the fields read-only prevents Salesforce-originated edits from ever being treated as authoritative, and the unidirectional integration guarantees no write-back path exists, which is exactly the governance the architect was asked to enforce.
D
Bi-directional synchronization with a survivorship rule that always prefers the ERP value for the address field.
Why it fails: A survivorship rule that always prefers the ERP value still requires a write path from Salesforce to the ERP, because bi-directional synchronization means both systems publish changes. The Salesforce edit would be transmitted and then discarded or overwritten, creating unnecessary traffic and audit noise, and it does not satisfy the explicit requirement that Salesforce edits must not flow back.

Question 3hardmultiple choice

A global retailer is consolidating customer master data from Salesforce, a legacy loyalty system, and an e-commerce platform. The data architect must design a matching strategy that minimizes false positives while still identifying the same customer across sources where names are spelled differently and addresses vary. Which matching approach should the architect recommend?

Trap 1: Exact matching on the combination of first name, last name, and…

Requiring exact agreement on three fields is brittle: nicknames, middle names, and address changes cause misses, and common names in dense areas can still collide. It does not handle the stated variation in names and addresses, so it produces both false negatives and potential false positives. This deterministic composite key is too rigid for cross-source customer matching.

Trap 2: Fuzzy matching on the full name field alone using a Levenshtein…

Name-only fuzzy matching ignores other attributes and can merge different people with similar names, especially in large populations. It also fails when names are recorded in different orders or scripts. Without additional attributes or a threshold strategy across fields, false positives rise. This does not meet the requirement to minimize false positives while handling address variation.

Trap 3: Deterministic matching on exact email address only, treating any…

Exact email matching is deterministic and low risk for false positives, but it fails when customers use different emails across channels or when email is missing, producing many false negatives. The requirement is to match across sources where names and addresses vary, so a single exact key cannot achieve the needed recall. This approach would leave duplicates unmerged and is not appropriate.

A
Exact matching on the combination of first name, last name, and postal code.
Why it fails: Requiring exact agreement on three fields is brittle: nicknames, middle names, and address changes cause misses, and common names in dense areas can still collide. It does not handle the stated variation in names and addresses, so it produces both false negatives and potential false positives. This deterministic composite key is too rigid for cross-source customer matching.
B
Fuzzy matching on the full name field alone using a Levenshtein distance threshold.
Why it fails: Name-only fuzzy matching ignores other attributes and can merge different people with similar names, especially in large populations. It also fails when names are recorded in different orders or scripts. Without additional attributes or a threshold strategy across fields, false positives rise. This does not meet the requirement to minimize false positives while handling address variation.
C
Deterministic matching on exact email address only, treating any non-match as a distinct customer.
Why it fails: Exact email matching is deterministic and low risk for false positives, but it fails when customers use different emails across channels or when email is missing, producing many false negatives. The requirement is to match across sources where names and addresses vary, so a single exact key cannot achieve the needed recall. This approach would leave duplicates unmerged and is not appropriate.
D
Probabilistic matching with a configured match threshold and score bands, supplemented by deterministic rules for high-confidence identifiers like loyalty number.
Probabilistic matching compares multiple attributes with weights and tolerates variation in names and addresses, while a threshold controls false positives. Adding deterministic rules for unique identifiers such as loyalty number captures exact matches with certainty. This hybrid approach balances precision and recall, directly addressing the need to minimize false positives while still matching records across sources with inconsistent spelling and addresses.

Question 4hardmulti select

An architect is choosing between storing a new data domain in a custom object versus using Big Objects in Salesforce. The dataset is expected to reach billions of records with append-only writes and infrequent, key-based reads. Which two characteristics make Big Objects the appropriate choice for this scenario? (Choose two.)

Trap 1: Big Objects support full DML operations including update and delete…

Big Objects are optimized for write-once, read-many access and do not support the full range of interactive DML you get with custom objects. Updates and deletes are limited and generally performed through asynchronous processes rather than the UI, so this statement misrepresents how Big Objects behave.

Trap 2: Big Objects replicate data across every Salesforce instance for…

Big Objects are not replicated across all instances, and they are not fully available in standard reporting the way custom objects are. Reporting on Big Objects typically requires asynchronous query tools and specific access patterns, so this claim about real-time cross-instance reporting is inaccurate.

Trap 3: Big Objects allow roll-up summary fields and validation rules on…

Big Objects do not support roll-up summary fields, and they support only limited validation and automation compared with custom objects. Architects expecting standard declarative features such as roll-ups or rich validation will be disappointed, so this is not a reason to select Big Objects for the described dataset.

A
Big Objects support full DML operations including update and delete through the standard user interface.
Why it fails: Big Objects are optimized for write-once, read-many access and do not support the full range of interactive DML you get with custom objects. Updates and deletes are limited and generally performed through asynchronous processes rather than the UI, so this statement misrepresents how Big Objects behave.
B
Big Objects replicate data across every Salesforce instance for real-time reporting in standard reports.
Why it fails: Big Objects are not replicated across all instances, and they are not fully available in standard reporting the way custom objects are. Reporting on Big Objects typically requires asynchronous query tools and specific access patterns, so this claim about real-time cross-instance reporting is inaccurate.
C
Big Objects allow roll-up summary fields and validation rules on the object.
Why it fails: Big Objects do not support roll-up summary fields, and they support only limited validation and automation compared with custom objects. Architects expecting standard declarative features such as roll-ups or rich validation will be disappointed, so this is not a reason to select Big Objects for the described dataset.
D
Big Objects provide an indexed, query-optimized access path for retrieving records by defined key fields.
Big Objects use an index defined by the architect over selected fields, enabling efficient retrieval by those keys even at massive scale. This matches the scenario's infrequent, key-based read pattern and is a defining advantage over custom objects, which do not scale to billions of rows with predictable query performance.
E
Big Objects are designed to store and query massive volumes of data on the Salesforce platform.
Big Objects are purpose-built for very large datasets, scaling to billions of records that exceed the practical limits of standard and custom objects. That scalability is the core reason this append-heavy, high-volume domain fits Big Objects rather than a custom object, which would hit storage and performance ceilings.

Question 5easymultiple choice

A data architect needs to ensure that when a user updates a field on a custom object, a related record on another object is automatically updated to reflect the change. The architect wants to avoid writing code. Which declarative feature should be used?

Trap 1: Workflow Rule with a Field Update

Workflow rules can perform field updates on the same object or on related records via a cross-object field update. However, cross-object field updates in workflow rules only work on master-detail relationships, not lookup relationships. If the related object is linked via lookup, this feature cannot update it. Additionally, workflow rules are being retired in favor of Flow, but for this scenario, the limitation on relationship type makes it less appropriate.

Trap 2: Process Builder with an Update Records action

Process Builder can update records on related objects through the Update Records action, but it is also being retired and has limitations. It can handle lookup relationships, but it may not be the most current or recommended declarative tool. Given Salesforce's direction, Flow is the preferred no-code solution for this requirement.

Trap 3: Apex Trigger with a future method

An Apex Trigger with a future method would require writing code, which the architect explicitly wants to avoid. While Apex is powerful and can handle complex logic, it is not declarative. This option fails the no-code requirement. Additionally, future methods have governor limits and are asynchronous, which may introduce delays not suitable for immediate updates.

A
Workflow Rule with a Field Update
Why it fails: Workflow rules can perform field updates on the same object or on related records via a cross-object field update. However, cross-object field updates in workflow rules only work on master-detail relationships, not lookup relationships. If the related object is linked via lookup, this feature cannot update it. Additionally, workflow rules are being retired in favor of Flow, but for this scenario, the limitation on relationship type makes it less appropriate.
B
Record-Triggered Flow with an Update Records element
Record-Triggered Flows are the modern declarative automation tool in Salesforce. They can be triggered when a record is created or updated, and they can update related records regardless of whether the relationship is master-detail or lookup. This meets the requirement without code. Flows are more powerful and flexible than Workflow Rules or Process Builder, and they are the recommended approach for new automation.
C
Process Builder with an Update Records action
Why it fails: Process Builder can update records on related objects through the Update Records action, but it is also being retired and has limitations. It can handle lookup relationships, but it may not be the most current or recommended declarative tool. Given Salesforce's direction, Flow is the preferred no-code solution for this requirement.
D
Apex Trigger with a future method
Why it fails: An Apex Trigger with a future method would require writing code, which the architect explicitly wants to avoid. While Apex is powerful and can handle complex logic, it is not declarative. This option fails the no-code requirement. Additionally, future methods have governor limits and are asynchronous, which may introduce delays not suitable for immediate updates.

Question 6mediummultiple choice

A company maintains a custom object Asset__c with 5 million records. They need to archive records older than 7 years to a Big Object for compliance. After archiving, the records must be queryable via SOQL for audits, but not editable. Which approach should an architect recommend?

Trap 1: Create a Big Object with the same fields as Asset__c, use a batch…

Big Objects cannot be queried with standard SOQL; they require Async SOQL or a custom index-based query. A Visualforce page using SOQL will fail. While copying to a Big Object and deleting from Asset__c is a valid archival pattern, the query method is incorrect. This option would not provide the required audit access.

Trap 2: Create a custom object Asset_Archive__c to store old records, and…

A custom object has the same storage and performance characteristics as Asset__c, so moving records to another custom object does not solve the large data volume problem. It also does not provide the scalability of a Big Object. While standard reports can query custom objects, the archive would still contribute to storage and could degrade performance as it grows. This is not a true archival solution.

Trap 3: Use Salesforce Connect to create an external object that points to…

Salesforce Connect external objects can query external data in real time, but they require an external data source and do not store data in Salesforce. This approach does not archive data within Salesforce and may have performance and licensing implications. The requirement is to archive records to a Big Object for compliance, not to federate to an external system. This option does not meet the stated archival requirement.

A
Create a Big Object with the same fields, use a batch Apex job to copy old records, and then delete them from Asset__c. Provide audit access via a Lightning component that uses Async SOQL to query the Big Object.
Big Objects are designed for large-scale archival and are queried using Async SOQL, which runs asynchronously and can handle massive datasets. Copying old records to a Big Object and deleting them from Asset__c reduces the size of the transactional object, improving performance. Async SOQL is the correct mechanism for querying Big Objects and can be invoked from a Lightning component, satisfying the audit requirement.
B
Create a Big Object with the same fields as Asset__c, use a batch Apex job to copy old records, and then delete them from Asset__c. Provide audit access via a Visualforce page that queries the Big Object using SOQL.
Why it fails: Big Objects cannot be queried with standard SOQL; they require Async SOQL or a custom index-based query. A Visualforce page using SOQL will fail. While copying to a Big Object and deleting from Asset__c is a valid archival pattern, the query method is incorrect. This option would not provide the required audit access.
C
Create a custom object Asset_Archive__c to store old records, and use a batch Apex job to move them. Provide audit access via standard reports and list views.
Why it fails: A custom object has the same storage and performance characteristics as Asset__c, so moving records to another custom object does not solve the large data volume problem. It also does not provide the scalability of a Big Object. While standard reports can query custom objects, the archive would still contribute to storage and could degrade performance as it grows. This is not a true archival solution.
D
Use Salesforce Connect to create an external object that points to an external database containing the archived records, and provide audit access via external object list views.
Why it fails: Salesforce Connect external objects can query external data in real time, but they require an external data source and do not store data in Salesforce. This approach does not archive data within Salesforce and may have performance and licensing implications. The requirement is to archive records to a Big Object for compliance, not to federate to an external system. This option does not meet the stated archival requirement.

Question 7mediummultiple choice

A Salesforce org has a custom object Invoicec with a Lookup relationship to Account. The business now requires that every Invoicec record must always have a valid Account, and deleting an Account must also delete its related invoices. The architect decides to change the relationship type to Master-Detail. Which statement describes a valid consequence of this change?

Trap 1: Invoice__c keeps its own sharing rules, and the Account lookup…

In a master-detail relationship, the child record's sharing is determined by the parent, so Invoice__c would not keep independent sharing rules. Additionally, the parent field is required by the platform, not by a manual field setting. This option misstates both sharing behavior and field requirement, making it incorrect for the described conversion.

Trap 2: The Account field remains a lookup, but Salesforce automatically…

A standard lookup relationship does not automatically block deletion of the parent record; without a custom restriction, deleting the Account would simply clear the lookup on child invoices. The scenario describes converting to master-detail specifically to get cascade delete, not to prevent parent deletion. This option describes behavior that belongs to a lookup with a deletion constraint, not to master-detail.

Trap 3: The Invoice__c object inherits the Account's sharing model, but the…

Master-detail relationships do not leave the parent field optional; the field becomes required by the platform as soon as the relationship type is changed. Sharing inheritance is a real side effect of master-detail, but the statement is wrong because it claims the field stays optional. The scenario requires mandatory parent references, so this option would not meet the requirement.

A
Invoice__c keeps its own sharing rules, and the Account lookup field must be manually marked as required in the field definition.
Why it fails: In a master-detail relationship, the child record's sharing is determined by the parent, so Invoice__c would not keep independent sharing rules. Additionally, the parent field is required by the platform, not by a manual field setting. This option misstates both sharing behavior and field requirement, making it incorrect for the described conversion.
B
The Account field remains a lookup, but Salesforce automatically prevents deletion of an Account that has related Invoice__c records.
Why it fails: A standard lookup relationship does not automatically block deletion of the parent record; without a custom restriction, deleting the Account would simply clear the lookup on child invoices. The scenario describes converting to master-detail specifically to get cascade delete, not to prevent parent deletion. This option describes behavior that belongs to a lookup with a deletion constraint, not to master-detail.
C
The Invoice__c object inherits the Account's sharing model, but the Account lookup field remains optional until a validation rule is created.
Why it fails: Master-detail relationships do not leave the parent field optional; the field becomes required by the platform as soon as the relationship type is changed. Sharing inheritance is a real side effect of master-detail, but the statement is wrong because it claims the field stays optional. The scenario requires mandatory parent references, so this option would not meet the requirement.
D
The Account field on Invoice__c automatically becomes required, and the Invoice__c records are deleted when their parent Account is deleted.
Converting a lookup to master-detail makes the parent reference mandatory and enforces cascade delete from the master record. In this scenario, every invoice must have an account, and deleting the account removes its invoices, which is exactly the requested behavior. This is the core difference between the two relationship types and directly satisfies both business requirements without additional configuration.

Question 8hardmultiple choice

A data architect is designing a solution for a custom object Orderc that will contain 30 million records. Users need to frequently query orders by Customerc (a lookup to Account) and Order_Datec. The architect plans to create a composite custom index on Customerc and Order_Date__c. Which consideration is most critical for the index to be used by the query optimizer?

Trap 1: The composite index must include at least three fields to be…

Composite indexes can consist of two fields and still be effective. The number of fields is not the primary factor; rather, the leading field's selectivity and the overall filter conditions determine index usage. Requiring three fields is not a Salesforce requirement and does not guarantee better performance.

Trap 2: The composite index must be created on fields that are not already…

Salesforce automatically indexes certain fields like Id, Name, and lookup fields. However, if a field is already indexed, you cannot create a custom index on it alone, but you can include it in a composite index. The critical factor is not whether fields are already indexed, but the selectivity of the leading field.

Trap 3: The fields in the composite index must be in the same order as they…

The order of fields in a composite index does not need to match the order in the WHERE clause. The optimizer can use the index as long as the leading field in the index is included in the filter. However, the leading field must be selective for the index to be used, which is a more critical consideration.

A
The composite index must include at least three fields to be effective for large data volumes.
Why it fails: Composite indexes can consist of two fields and still be effective. The number of fields is not the primary factor; rather, the leading field's selectivity and the overall filter conditions determine index usage. Requiring three fields is not a Salesforce requirement and does not guarantee better performance.
B
The composite index must be created on fields that are not already indexed by default.
Why it fails: Salesforce automatically indexes certain fields like Id, Name, and lookup fields. However, if a field is already indexed, you cannot create a custom index on it alone, but you can include it in a composite index. The critical factor is not whether fields are already indexed, but the selectivity of the leading field.
C
The fields in the composite index must be in the same order as they appear in the SOQL WHERE clause.
Why it fails: The order of fields in a composite index does not need to match the order in the WHERE clause. The optimizer can use the index as long as the leading field in the index is included in the filter. However, the leading field must be selective for the index to be used, which is a more critical consideration.
D
The leading field in the composite index must be highly selective for the queries being executed.
For a composite index to be used, the leading field must be selective. In this scenario, Customer__c is likely to be selective if queries filter by a specific customer. If the leading field is not selective, the optimizer may ignore the index entirely. Thus, ensuring the leading field's selectivity is critical.

Question 9hardmultiple choice

Refer to the exhibit. An architect is reviewing an error log from a high-volume data load. Which pattern should be implemented to resolve this limit violation?

Exhibit

System.LimitException: Too many DML statements: 151; Trigger on Account: execution of AfterUpdate

Trap 1: Increase the batch size in the data loader settings.

Increasing batch size actually exacerbates DML limit issues by creating more records per execution context. If the code is not optimized to handle bulk operations, a larger batch size will cause the transaction to hit governor limits faster, leading to systemic failures rather than resolving the existing logic flaw.

Trap 2: Convert the trigger to an asynchronous future method.

While future methods run in a separate context, they have their own limits and are not the correct way to handle trigger logic. Using them for this purpose is considered an anti-pattern, as it introduces complexity and may hit other limits like asynchronous apex queue depth or concurrency.

Trap 3: Increase the Apex CPU time limit in the Setup menu.

Governor limits such as DML statement counts cannot be increased via configuration changes in the Setup menu. These are hard limits imposed by the platform to protect multi-tenant performance. The only solution is to refactor the code to adhere to the platform's architectural standards for scalable data management.

A
Increase the batch size in the data loader settings.
Why it fails: Increasing batch size actually exacerbates DML limit issues by creating more records per execution context. If the code is not optimized to handle bulk operations, a larger batch size will cause the transaction to hit governor limits faster, leading to systemic failures rather than resolving the existing logic flaw.
B
Implement the Bulk DML Pattern using collections.
Moving DML operations outside of loops is the fundamental requirement for Salesforce Apex development. By collecting records in a List and performing a single DML call, you stay within the 150 limit per transaction. This is a critical architectural pattern for ensuring scalable code during heavy data ingestion processes.
C
Convert the trigger to an asynchronous future method.
Why it fails: While future methods run in a separate context, they have their own limits and are not the correct way to handle trigger logic. Using them for this purpose is considered an anti-pattern, as it introduces complexity and may hit other limits like asynchronous apex queue depth or concurrency.
D
Increase the Apex CPU time limit in the Setup menu.
Why it fails: Governor limits such as DML statement counts cannot be increased via configuration changes in the Setup menu. These are hard limits imposed by the platform to protect multi-tenant performance. The only solution is to refactor the code to adhere to the platform's architectural standards for scalable data management.

Question 10mediummultiple choice

Universal Containers has 50 million records in a custom object. A report summarizing these records times out. Which strategy is most effective for improving report performance?

Trap 1: Increase the report timeout limit in Setup.

Salesforce does not provide a configurable setting to increase report timeout limits for end users. The system imposes hard limits on report execution duration to maintain multi-tenant stability, meaning increasing thresholds is not a viable architectural solution for handling large data volume reporting challenges.

Trap 2: Implement a custom lightning web component for reporting.

Custom Lightning Web Components still rely on underlying SOQL queries. If the query scans 50 million records, it will hit governor limits or experience significant latency regardless of the UI component, failing to address the fundamental performance bottleneck inherent in querying massive data volumes directly.

Trap 3: Add more indexes to the custom object fields.

Adding indexes helps retrieve specific records faster via indexed fields but does not assist in aggregating or summarizing 50 million records. The reporting engine must still perform a full table scan or gather data across the massive dataset to compute the final summary results.

A
Increase the report timeout limit in Setup.
Why it fails: Salesforce does not provide a configurable setting to increase report timeout limits for end users. The system imposes hard limits on report execution duration to maintain multi-tenant stability, meaning increasing thresholds is not a viable architectural solution for handling large data volume reporting challenges.
B
Implement a custom lightning web component for reporting.
Why it fails: Custom Lightning Web Components still rely on underlying SOQL queries. If the query scans 50 million records, it will hit governor limits or experience significant latency regardless of the UI component, failing to address the fundamental performance bottleneck inherent in querying massive data volumes directly.
C
Create a summary object to store pre-aggregated data.
Pre-aggregation shifts the computational load from read-time to write-time. By calculating metrics asynchronously and storing them in a summary object, the report engine only processes a small number of aggregate records rather than scanning the entire base table, significantly reducing execution time and resource consumption.
D
Add more indexes to the custom object fields.
Why it fails: Adding indexes helps retrieve specific records faster via indexed fields but does not assist in aggregating or summarizing 50 million records. The reporting engine must still perform a full table scan or gather data across the massive dataset to compute the final summary results.

Question 11mediummultiple choice

Universal Containers wants to ensure data quality by preventing the creation of duplicate Leads from various sources. The architect recommends matching rules and duplicate rules. Which action should the architect take to ensure that users are alerted to potential duplicates during manual entry while blocking automated integrations?

Trap 1: Enable 'Block' for both user-facing and integration-based duplicate…

Blocking both channels prevents users from manually entering valid but potentially matching leads, which negatively impacts productivity and prevents legitimate data entry. The business requirement explicitly asks for alerts in the UI, which this configuration would fail to provide by forcing a hard block on every creation attempt.

Trap 2: Apply 'Report' to the record creation rule and ignore the API…

The 'Report' setting only generates a duplicate record event for tracking; it does not block the creation of duplicates from integrations. Simply ignoring API settings leaves the system vulnerable to junk data, failing the specific requirement to prevent duplicates from automated sources through a hard block mechanism.

Trap 3: Use a third-party AppExchange solution exclusively for integration…

While third-party solutions provide advanced matching logic, native Salesforce duplicate rules are capable of handling these requirements natively without additional costs or dependencies. Relying on an external tool for standard duplicate management increases architectural complexity and maintenance overhead without providing a tangible benefit for these specific business needs.

A
Enable 'Block' for both user-facing and integration-based duplicate rules.
Why it fails: Blocking both channels prevents users from manually entering valid but potentially matching leads, which negatively impacts productivity and prevents legitimate data entry. The business requirement explicitly asks for alerts in the UI, which this configuration would fail to provide by forcing a hard block on every creation attempt.
B
Apply 'Report' to the record creation rule and ignore the API settings.
Why it fails: The 'Report' setting only generates a duplicate record event for tracking; it does not block the creation of duplicates from integrations. Simply ignoring API settings leaves the system vulnerable to junk data, failing the specific requirement to prevent duplicates from automated sources through a hard block mechanism.
C
Set 'Report' for record creation and 'Block' for API insertion.
This configuration directly maps to the requirements. The 'Report' action allows users to proceed after an alert, facilitating manual data entry, while the 'Block' action on the API ensures that automated integration processes cannot bypass duplicate prevention, effectively maintaining high data quality across all system interaction types.
D
Use a third-party AppExchange solution exclusively for integration rules.
Why it fails: While third-party solutions provide advanced matching logic, native Salesforce duplicate rules are capable of handling these requirements natively without additional costs or dependencies. Relying on an external tool for standard duplicate management increases architectural complexity and maintenance overhead without providing a tangible benefit for these specific business needs.

Question 12mediummultiple choice

When designing a custom Data Model, when should an architect choose a 'Lookup' relationship over a 'Master-Detail' relationship?

Trap 1: When the child records must inherit the parent's security.

Master-Detail relationships force child records to inherit the security (sharing) settings of the parent. If this is a requirement, then a Master-Detail relationship is the correct choice, not a lookup relationship. Lookups allow for independent security models, which is the opposite of this requirement.

Trap 2: When the child must be deleted when the parent is deleted.

Cascading delete is a feature of the Master-Detail relationship. If this behavior is required, then Master-Detail is mandatory. Choosing a lookup relationship in this case would require custom automation to handle the deletion, which is less efficient and more prone to error than the native feature.

Trap 3: When you need to create a Roll-up Summary field.

Roll-up Summary fields are only available on the parent of a Master-Detail relationship. They cannot be created on a Lookup relationship. If the business requires a count or sum of child records, the architect must use a Master-Detail relationship, as lookups do not support this functionality natively.

A
When the child records must inherit the parent's security.
Why it fails: Master-Detail relationships force child records to inherit the security (sharing) settings of the parent. If this is a requirement, then a Master-Detail relationship is the correct choice, not a lookup relationship. Lookups allow for independent security models, which is the opposite of this requirement.
B
When the child record must have its own sharing settings.
Lookup relationships are independent, allowing for granular sharing controls on both the parent and the child. If the business requirement demands that the child object has its own unique security rules separate from the parent, then a lookup relationship is the architecturally correct choice.
C
When the child must be deleted when the parent is deleted.
Why it fails: Cascading delete is a feature of the Master-Detail relationship. If this behavior is required, then Master-Detail is mandatory. Choosing a lookup relationship in this case would require custom automation to handle the deletion, which is less efficient and more prone to error than the native feature.
D
When you need to create a Roll-up Summary field.
Why it fails: Roll-up Summary fields are only available on the parent of a Master-Detail relationship. They cannot be created on a Lookup relationship. If the business requires a count or sum of child records, the architect must use a Master-Detail relationship, as lookups do not support this functionality natively.