Salesforce-Platform-Developer-II Practice Test Questions

Explanation:

Universal Containers has set the organization-wide defaults (OWD) for the custom Candidate object to Private, meaning only the record owner and users with higher access (e.g., via roles, sharing rules, or manual sharing) can view the records. A lookup field on the Candidate object links to an Employee (assumed to be a User record) as an Interviewer. The requirement is to automatically grant Read access to the Candidate record when the Interviewer lookup field is set to a specific user. Let’s evaluate the options:

Option A: The record can be shared using an Apex class. While Apex can be used to create sharing records (e.g., via the CandidateShare object for a custom object), this approach requires custom code to detect when the Interviewer lookup field is updated and programmatically insert a sharing record. This is not an automatic, declarative solution and involves manual development, testing, and maintenance. It is less efficient than using built-in Salesforce features like sharing rules.

Option B: The record can be shared using a permission set. Permission sets grant additional permissions to users, such as object-level access (e.g., Read, Create) or field-level access. However, permission sets do not dynamically share individual records based on field values (e.g., the Interviewer lookup). They provide broad access to all records of an object for users assigned the permission set, which does not meet the requirement of automatically sharing a specific Candidate record with the Interviewer user.

Option C: The record can be shared using a sharing rule. Sharing rules are a declarative way to extend access to records based on criteria or ownership. A criteria-based sharing rule can be created for the Candidate object to grant Read access to users specified in the Interviewer lookup field. For example, the rule can be configured to share the record with the user whose ID matches the Interviewer field value whenever it is populated. This automates the sharing process without requiring code, making it the most appropriate solution given the Private OWD and the need for dynamic access.

Option D: The record cannot be shared with the current setup. This is incorrect because Salesforce provides mechanisms like sharing rules to extend access beyond the Private OWD. The lookup field to the Interviewer (User) allows for criteria-based sharing, enabling automatic Read access when the field is set.

Why Option C is Best:
With OWD set to Private, sharing rules are the standard Salesforce feature to automatically grant access to records based on field values or other criteria. A criteria-based sharing rule can evaluate the Interviewer lookup field and share the Candidate record with that user, ensuring Read access is granted dynamically. This aligns with Salesforce’s security model and avoids the complexity of custom Apex code.

Implementation Notes:
Create a criteria-based sharing rule on the Candidate object.
Set the criteria to match records where the Interviewer field is not null.
Grant Read access to the users specified in the Interviewer field.
Ensure the rule is active and tested to confirm access is applied correctly.

References:
1. Salesforce Documentation - Sharing Rules:
Explains how to use criteria-based sharing rules to extend access based on field values.

2. Salesforce Documentation - Organization-Wide Defaults:
Details how OWD interacts with sharing rules to control record access.

3. Salesforce Platform Developer II Study Guide:
Covers security and sharing models, including the use of sharing rules for dynamic access control.

Explanation:

📌 Scenario Summary:
The Visualforce page worked in a developer sandbox but is causing view state errors in production.
This points to issues with too much data being stored in the view state, which exceeds Salesforce’s view state size limit (170 KB).

✅ Why Option C Is Correct:
"Ensure variables are marked as transient."
In Visualforce controllers, non-transient instance variables are automatically included in the view state, even if they are large or not needed after the initial page load.
By using the transient keyword, the developer can prevent temporary or large variables from being serialized into the view state.

💡 Example:
public class MyController {
public String name; // Stored in view state
transient public List accList; // NOT stored in view state
}

This reduces the view state size and prevents view state errors.

❌ Why the Other Options Are Incorrect:

A. Ensure queries do not exceed governor limits
Important for Apex performance, but unrelated to view state issues.
View state errors are about data size, not SOQL execution limits.

B. Ensure properties are marked as private
Private vs. public properties affect accessibility but not view state inclusion.
Even private properties can be included in view state if they are non-transient.

D. Ensure profiles have access to the Visualforce page
This would result in authorization errors, not view state errors.
Completely unrelated to the error described.

📚 Reference:
Salesforce Developer - Introducing Visualforce
Using Transient Keyword

Explanation:

📌 Requirement Recap:
Phones (small devices): display items in one column → full width (12 units)
Tablets, desktops, and larger devices: display items in two columns → each item takes half width (6 units)

✅ Why Option B is Correct:
lightning-layout-item size="6" small-device-size="12"
small-device-size="12" ensures that on phones, the item takes the full width (i.e., 1 item per row).
size="6" is used for medium and large screens, which means two items per row.
This matches the requirement exactly.

❌ Why Other Options Are Incorrect:

A. small-device-size="12" only:
Only covers phones, no layout defined for desktops or tablets → won't achieve two-column layout on larger screens ❌

C. size="12" medium-device-size="6":
Full width on large, half width on medium → contradicts the requirement (desktop should also be 2 columns) ❌

D. medium-device-size="6" only:
No layout for small devices → phones may default to unpredictable layout ❌

📚 Reference:
Salesforce Lightning Layout Docs
size → default for medium+ devices
small-device-size, medium-device-size, large-device-size → override for specific screen sizes

Explanation:

The developer has built an Aura component for guests to self-register at a front desk kiosk and now needs to create a utility tray component to alert users (e.g., front desk staff) whenever a guest arrives. This requires communication between components, likely across different parts of the application, to notify users of the guest registration event. Let’s evaluate the options:

Option A: DML Operation A Data Manipulation Language (DML) operation (e.g., insert, update) is used to modify data in Salesforce, such as saving a guest’s registration details. While DML might be part of the self-registration process, it is not a mechanism for alerting or notifying users via a utility tray component. This option is incorrect for the purpose of event notification.

Option B: Changelog A changelog typically refers to tracking changes to records (e.g., via Field History Tracking or a custom solution), but it is not designed for real-time notifications or communication between components. It serves as a historical record rather than an active alerting mechanism, making this option unsuitable.

Option C: Application Event In the Aura framework, an application event is used to communicate between components across the entire application, regardless of their position in the component hierarchy. When a guest self-registers, the registration component can fire an application event to signal the arrival. The utility tray component, designed to alert users, can be configured to handle this event and display the alert. This is the appropriate choice for broadcasting the guest arrival notification to all relevant parts of the application, including the utility tray.

Option D: Component Event A component event is used for communication between components that have a parent-child relationship within the same hierarchy. Since the utility tray (likely a global component) and the self-registration component (likely a specific page component) may not be directly related in the component tree, a component event is not suitable. Application events are better suited for cross-application notifications.

Why Option C is Best:
The requirement involves alerting users via a utility tray component whenever a guest arrives, which implies a need for a global notification mechanism. An application event allows the self-registration component to broadcast the guest arrival event, and the utility tray component can listen for and respond to this event by displaying an alert. This aligns with Aura’s event-driven architecture for inter-component communication across the application.

Implementation Notes:
Define an application event (e.g., guestArrivalEvent) in the Aura framework.
Fire the event from the self-registration component when a guest registers.
Register the utility tray component to handle the event and trigger the alert (e.g., show a toast or update the UI).

References:
1. Salesforce Documentation - Application Events in Aura:
Application Events
Explains how application events enable communication across the application.

2. Salesforce Documentation - Component Events in Aura:
Component Events
Contrasts component events with application events, highlighting their use cases.

Explanation:

📌 Scenario Summary:

Trigger Point: When Account records are saved
Requirement: Send each Account to an external RESTful web service
Constraint: Web service only accepts one record per call
Consideration: Must perform a callout (HTTP request) from Apex

✅ Why Option D is Correct:

"Create a future method."
Future methods are designed for asynchronous processing and are one of the few ways you can make callouts from triggers.
Since callouts cannot be performed directly inside a trigger, you must defer them using @future(callout=true).
Because the external system can only accept one record at a time, you can invoke the future method once per record.

💡 Example:

public class AccountCalloutService {
@future(callout=true)
public static void sendToBackup(String accountId) {
Account acc = [SELECT Id, Name FROM Account WHERE Id = :accountId];
HttpRequest req = new HttpRequest();
req.setEndpoint('https://externalapi.com/backup');
req.setMethod('POST');
req.setBody(JSON.serialize(acc));
// add headers, auth, etc.
Http http = new Http();
HttpResponse res = http.send(req);
}
}

Trigger:

trigger AccountTrigger on Account (after insert, after update) {
for (Account acc : Trigger.new) {
AccountCalloutService.sendToBackup(acc.Id);
}
}

❌ Why Other Options Are Incorrect:

A. Implement the Queueable interface
Queueable Apex can perform callouts, but you cannot enqueue one job per record from a trigger without hitting limits.
Not suitable for 1-record-per-call from within a trigger, unless you batch them — which contradicts the 1-per-call requirement.

B. Implement platform events
Platform events are good for asynchronous integration, but they are not designed for immediate HTTP callouts and would require a separate subscriber system.

C. Expose an Apex class as a web service
This makes your org receivable (you host the endpoint), but in this case, you need to send data externally, not receive it.

📚 References:
Apex Developer Guide – Future Methods
Making Callouts from Triggers Best Practices

Explanation:

The 'Attempt to dereference a null object' error occurs in Apex when trying to access a property or method of a null object (e.g., calling a method on a Contact variable that hasn’t been initialized). In a Visualforce controller, this typically happens when a Contact property is accessed (e.g., in a page binding) before it is instantiated.

Option A: Declare a static final Contact at the top of the controller. Declaring a static final Contact creates a single, immutable instance shared across all users, which is not suitable for a Visualforce page where each user’s context may require a unique Contact instance. This does not address the null dereference issue dynamically.

Option B: Use a condition in the getter to return a new Contact if it is null. Implementing a getter method that checks if the Contact is null and initializes a new Contact instance if so prevents the dereference error. This ensures the object is always valid when accessed by the Visualforce page. For example, the getter can return a new Contact() if the current value is null, providing a safe default.

Option C: Change the setter’s signature to return a Contact. A setter’s purpose is to assign a value to a property and typically does not return a value (it returns void in Apex). Changing its signature to return a Contact is invalid syntax and does not resolve the null dereference issue.

Option D: Change the getter's signature to be static Contact. Making the getter static makes it class-level rather than instance-level, which is inappropriate for a Visualforce controller where the getter should operate on the current instance’s state. This does not fix the null issue and could break page bindings.

Why Option B is Best:
A conditional getter ensures the Contact is never null when accessed, avoiding the error. This is a common pattern in Visualforce controllers to handle uninitialized objects safely.

References:
Visualforce Developer Guide: Properties and Getters

Explanation:

The company has multiple Salesforce orgs with some different and some common objects, and a Java application needs to create, retrieve, and update common object records across all orgs. The integration method must be flexible and org-agnostic.

Option A: SOAP API with the Partner WSDL The Partner WSDL is a loosely typed, generic WSDL that works across different Salesforce orgs, regardless of their specific object schemas. It allows the Java application to dynamically discover and interact with common objects (e.g., Account, Contact) using standard SOAP API calls. This is ideal for a single application interacting with multiple orgs with varying configurations.

Option B: Apex REST Web Service Apex REST Web Services are custom RESTful services defined in Apex, specific to a single org’s implementation. This requires each org to expose compatible endpoints, which is impractical for multiple orgs with different schemas and would require significant customization per org.

Option C: SOAP API with the Enterprise WSDL The Enterprise WSDL is strongly typed and generated based on a specific org’s schema, including its custom objects and fields. It is not portable across orgs with different configurations, making it unsuitable for a single application to handle multiple orgs.

Option D: Metadata API The Metadata API is used to manage metadata (e.g., custom objects, fields) rather than runtime data operations like create, retrieve, and update. It is not designed for record-level interactions.

Why Option A is Best:
The Partner WSDL provides a flexible, org-agnostic interface, allowing the Java application to adapt to the common objects across different orgs without requiring org-specific customization.

References:
Salesforce Developer Guide: Partner WSDL

Explanation:

The Visualforce page correctly assigns Account ownership to a queue upon save, but the test class’s assertion fails. This suggests a discrepancy between the expected and actual state during testing.

Option A: The test class does not retrieve the updated value from the database. In Apex tests, changes made during execution (e.g., ownership assignment) are not automatically reflected in memory unless explicitly queried from the database. The test class must use a SOQL query (e.g., [SELECT OwnerId FROM Account WHERE Id = :accountId]) after the save to retrieve the updated ownership and assert against it. Without this, the test may check the in-memory state, which retains the original owner.

Option B: The test class does not use the Bulk API for loading test data. The Bulk API is for large data loads outside of test execution and is unrelated to validating ownership changes in a test class. This option is irrelevant.

Option C: The test class does not use the seeAllData=true annotation. seeAllData=true allows access to org data but is not required for testing ownership changes, which can be validated with test data created in the test class. This is not the cause of the assertion failure.

Option D: The test class does not implement the Queueable interface. The Queueable interface is for asynchronous processing and is not relevant to a synchronous ownership assignment via a Visualforce page. This option is incorrect.

Why Option A is Best:
Failing to requery the database after the save means the test checks an outdated in-memory state, causing the assertion to fail. A SOQL query ensures the test reflects the actual database state.

References:
Salesforce Developer Guide: Testing Apex

Explanation:

The company needs to delete nearly a million records daily after seven years, requiring a scalable, governor-limit-aware solution.

Option A: Schedule an @future process to query records older than seven years, and then recursively invoke itself in 1,000 record batches to delete them. Future methods have governor limits (e.g., 50 callouts per transaction) and cannot handle recursive invocation effectively for large datasets. This approach is not scalable for nearly a million records daily.

Option B: Use aggregate functions to query for records older than seven years, and then delete the aggregateResults objects. Aggregate functions (e.g., COUNT) return summarized data, not the records themselves, and cannot be deleted directly. This option is invalid.

Option C: Schedule a batch Apex process to run every day that queries and deletes records older than seven years. Batch Apex (Database.Batchable) is designed for processing large datasets by breaking them into batches (default 200 records, adjustable up to 2,000). Scheduling it daily with a query for records older than seven years ensures efficient deletion of nearly a million records within governor limits.

Option D: Perform a SOSL statement to find records older than 7 years, and then delete the entire result set. SOSL is for text-based searches across multiple objects and is not suitable for querying by date fields (e.g., created date). It also lacks the batching capability needed for large deletions.

Why Option C is Best:
Batch Apex handles large-scale deletions efficiently with its batch processing, making it ideal for deleting nearly a million records daily while respecting governor limits.

References:
Salesforce Developer Guide: Batch Apex

Explanation:

The Catalog object has a master-detail relationship with Catalog Item, and a change in Catalog’s CurrencyIsoCode should update the CurrencyIsoCode of up to 100,000 related Catalog Items.

Option A: A Database.Schedulable and Database.Batchable class that queries the Catalog Item object and updates the Catalog Items if the Catalog CurrencyIsoCode is different A Batch Apex class with Database.Batchable can process the 100,000 Catalog Items in batches, updating their CurrencyIsoCode based on the parent Catalog’s value. Scheduling it with Database.Schedulable allows it to run after detecting a Catalog change (e.g., via a trigger). This handles the large volume efficiently.

Option B: An after insert trigger on Catalog that updates the Catalog Items if the Catalog CurrencyIsoCode is different An after insert trigger on Catalog fires only on new records, not updates, and cannot handle 100,000 records in a single transaction due to governor limits (e.g., 10,000 DML rows). This is insufficient.

Option C: An after insert trigger on Catalog Item that updates the Catalog Items if the Catalog’s CurrencyIsoCode is different This trigger fires on Catalog Item inserts, not Catalog updates, and cannot propagate changes upward to update other Catalog Items. It’s the wrong direction and context.

Option D: A Database.Schedulable and Database.Batchable class that queries the Catalog object and updates the Catalog Items if the Catalog CurrencyIsoCode is different Querying the Catalog object alone misses the need to process all related Catalog Items. The batch should query Catalog Items and filter by the parent Catalog’s CurrencyIsoCode.

Why Option A is Best:
Batch Apex with scheduling handles the large volume of Catalog Items (up to 100,000) efficiently, updating their CurrencyIsoCode based on the Catalog’s value after a change.

References:
Salesforce Developer Guide: Batch Apex