PDII Practice Test Questions

Explanation:

Lightning Web Components (LWC) and Aura components cannot execute SOQL directly. To perform a complex SOQL query, especially one involving joins between objects (like parent-to-child or child-to-parent queries), you need to use Apex.

Why Apex with @AuraEnabled is correct:

You define an Apex method that performs the SOQL query.
Annotate the method with @AuraEnabled so it can be invoked from a Lightning component.
The component then calls this method imperatively or via wire, depending on the use case.

Explanation:

Universal Containers has:

A private sharing model for Convention_Attendee__c, meaning users do not have access to records they don’t own unless explicitly shared.
A custom lookup field (Event_Reviewer__c), and reviewers must get Read/Write access to the records they’re assigned.

Why Apex Managed Sharing via an After Insert trigger is the best solution:

Private sharing model means access must be explicitly granted.
The Event_Reviewer__c field is a dynamic user, so criteria-based sharing rules won’t work unless you hardcode criteria or share with a group (which doesn’t satisfy individual dynamic access).
Apex Managed Sharing gives fine-grained control to programmatically share records with specific users.
The sharing logic needs to happen after the record exists (i.e., in an After Insert trigger), because sharing rules require a record ID.

Explanation:

Why This Is the Best Approach?

User Experience (UX) Requirement
If the LWC appears unresponsive, users need visible feedback when errors occur.
Simply wrapping code in try-catch (Option A) or using Database methods (Option B) does not display errors to users.

Implementation Steps

HTML: Add an error message container (e.g., < lightning - messages > or a custom < div >).
JavaScript: Catch errors and update the UI.

Explanation:

When an Apex transaction is rolled back to a previously set savepoint, only the database state is reverted to that savepoint—the changes that have occurred in the database since that point are undone. However, static variables reside in memory and are not part of the database state. As a result, their values are not reverted when the transaction is rolled back. This means any changes made to static variables persist even after a rollback, which can be important to remember when designing transactional logic in Apex.

Let's briefly examine the other options:

A. "You can roll back to any savepoint variable created in any order." This is incorrect because once you roll back to an earlier savepoint, any savepoints created after that point become invalid and cannot be referenced or rolled back to.
C. "Reference to savepoints can cross trigger invocations." While triggers in the same transaction share the transaction context, savepoints are scoped to the transaction in which they’re created; they do not persist beyond that, and their references cannot be reused arbitrarily across different transaction contexts.
D. "Savepoints are not limited by DML statement governor limits." This statement is inaccurate; although Salesforce does impose various governor limits, the concept of savepoints is tied to the transaction control mechanism in Salesforce and is not directly limited by the DML governor limits.

Explanation:

The Candidate object has OWD (Organization-Wide Default) set to Private, which means users only see records they own or that are explicitly shared with them.

In this scenario:

There is a lookup field to a User (Interviewer).
When this field is set, the Interviewer should be given Read access to the Candidate record.
Since the sharing is based on a dynamic field value (Interviewer), and not on a role, group, or criteria that is static, the correct solution is:

Apex Managed Sharing using an Apex class.
This allows:

Programmatically sharing the record with the user in the Interviewer field.
Setting the access level (Read in this case).
Automatically triggering sharing logic when the Interviewer is assigned.

Explanation:

In a Visualforce test class, the best practice for initializing a page is to use the Test.setCurrentPage() method, passing in a reference to the Visualforce page (i.e., Page.MyTestPage). This sets the current page context for the test, allowing controller code (even custom controllers or controller extensions) to properly reference page attributes, parameters, and state. This approach is standard and ensures that any page-level logic in your Visualforce page is properly simulated during test execution.

Explanation:

Validation rules (Option A) cannot reference data in other objects, such as the custom object storing the blocked domains, so they are unsuitable for this requirement. Instead, centralizing your validation logic in a helper class allows you to query the custom object for blocked domains and verify that the entered email domain is not on the list. This approach promotes code reuse and ensures consistency:

The helper class can be invoked from an Apex trigger on Contact, ensuring that any email entered via the standard Contact UI is validated.
The Visualforce page controller for the Survey_Response__c object can call the same helper class, maintaining consistent logic and avoiding code duplication.
This design adheres to best practices by separating business logic from presentation, improving maintainability, and ensuring that both data entry points (Contacts and Survey_Response__c) have the same validation behavior.

Explanation:

The error "Maximum view state size limit exceeded" occurs when too much data is stored in the Visualforce view state, which includes:

Controller state
Component tree
Field values
Large collections (like record lists)
If a Visualforce page queries and displays too many records at once, the view state becomes too large, leading to this error and performance issues.

Why StandardSetController or SOQL LIMIT is the right solution:

The StandardSetController is built for efficient pagination, and it minimizes the amount of data stored in the view state by loading only a pageful of records at a time.
Using a LIMIT clause in your SOQL reduces the number of returned records and therefore the size of the data bound to the page.

Reference: StandardSetController Docs

Explanation:

When you need to store secret data that must vary by user or profile, Salesforce’s Hierarchy Custom Settings are a common solution. Hierarchy Custom Settings allow you to set default values at the org level and then override them at the profile or user level. This built‑in hierarchy mechanism is ideal when you want to control which users or profiles see which secret values. It also provides ease of maintenance by allowing administrators to update these settings through the Setup interface.

Custom Metadata (Option D) is designed for configuration data that’s typically the same across all users and isn’t subject to record-level (i.e., user or profile–based) access control. The other options (system.Cookie class and static resources) aren’t appropriate for storing secret data with such granular access controls.

Explanation:

In this scenario, the system of record is an external PIM (Product Information Management) system, and Salesforce must:

Accept create/update requests for Product2 records.
Automatically create or update PricebookEntry records.
Use a custom setting to determine which Pricebook2 to use.

Because Salesforce must receive incoming requests from the external system, and the process involves custom business logic (e.g., using a custom setting), the optimal approach is to:

Expose a Custom Apex REST API endpoint using @RestResource
This allows you to:

Define a custom REST interface (e.g., /services/apexrest/products/)
Accept payloads from the external system (e.g., in JSON format)

Perform complex logic like:

Upserting Product2 records
Querying the custom setting for the appropriate Pricebook2
Upserting PricebookEntry records with custom logic
Return success/failure responses