Salesforce-Platform-Developer-II Practice Test Questions

✅ Explanation:

The question is asking for a way to store configuration variables (for styling or behavior control in LWC) that are:
➝ Testable in Production and all Sandboxes
➝ Consistent across environments
➝ Deployable using change sets or metadata tools
The best option that meets all of these requirements is Custom Metadata.

🔍 Why Custom Metadata is the Right Choice
➝ Testable: Custom metadata can be queried in Apex and used in tests without requiring dynamic creation of records.
➝ Deployable: Can be packaged and moved between sandboxes and production via change sets, metadata API, or unlocked packages.
➝ Accessible in Apex, LWC (via Apex), and flows.
➝ Does not count against data storage limits.
➝ Ideal for storing configuration that controls logic or styling.

Example Use Case:
Store a flag like isDarkModeEnabled = true, or a color value buttonColor = "#FF0000" in custom metadata, and access it in LWC through an Apex method.

❌ Why Other Options Are Incorrect

A. Custom Setting
➥ Limited support in new Salesforce development (legacy).
➥ Hierarchy custom settings can be user/profile-specific, but not deployable with data via change sets easily.
➥ Not recommended for org-wide config that needs to be versioned and deployed between environments.

B. Custom Object
➥ Meant for business data, not configuration.
➥ Requires data creation in every environment manually or via scripts.
➥ Not ideal for testing or consistent deployment of config settings.

C. Custom Variable
➥ Not a real Salesforce feature. There is no such concept as "Custom Variable" in Salesforce metadata.

📚 Reference Documentation
➜ Custom Metadata Types Overview
➜ Custom Metadata vs. Custom Settings
➜ Deploying Custom Metadata

✅ Explanation:

The error message:
➥ "You have uncommitted work pending. Please commit or rollback before calling out"
...indicates that a DML operation (like insert/update) was performed before an HTTP callout, which is not allowed in synchronous Apex.

🧠 Why This Happens:
Apex enforces a "DML before callout" restriction in synchronous transactions.

In your code:
➥ You perform insert operations for reqs and reqLines.
➥ Then you make a callout using CalloutUtil.makeRestCallout(...).
➥ This causes the runtime to throw the error because uncommitted DML has occurred before the callout.

✅ How @future Helps
By marking the callout method as @future(callout=true), you:
➥ Move the callout logic to an asynchronous context.
➥ Avoid the DML-before-callout restriction.
➥ Allow the synchronous part to finish (i.e., insert the records), and then the callout is made separately after the transaction completes.

❌ Why the Other Options Are Incorrect

A. Change to @InvocableMethod
➥ @InvocableMethod is used for Flow and Process Builder integration.
➥ It does not solve the DML-before-callout error.
➥ Also, @InvocableMethod does not inherently run asynchronously or allow callouts unless combined with future or Queueable context.

B. Remove Database.setSavepoint() and rollback()
➥ These lines handle transaction rollback and are not related to the DML-callout restriction.
➥ Removing them won't fix the error — you'd still be making a callout after a DML operation.

📘 Reference Documentation
Apex Callouts Best Practices
@future Annotation
DML and Callout Order

✅ Explanation:

📘 Scenario Summary:
➝ A Lightning Web Component (LWC) is calling an Apex method imperatively from JavaScript.
➝ The Apex method returns a list of wrapper objects, which include Account and a custom matchProbability field.
➝ For the LWC to call this Apex method and process the returned data, specific annotations are required.

🔍 Line-by-Line Breakdown:

✅ A. Add @AuraEnabled to line 09.
➝ The AccountWrapper is returned to LWC.
➝ For LWC to deserialize and use the properties of this wrapper class (account, matchProbability), each property must be annotated with @AuraEnabled.
➝ Required for serialization over the wire between Apex and LWC.

✅ B. Add @AuraEnabled to line 03.
➝ The method search() must be @AuraEnabled to be accessible by LWC.
➝ Since this method is being called imperatively, @AuraEnabled is sufficient (you only need @AuraEnabled(cacheable=true) for wired methods).
➝ It also needs to be public static, which it already is.

❌ C. Add @AuraEnabled to lines 11 and 12.
➝ This is partially correct in idea, but line 09 is the start of the AccountWrapper class, which is where you’d annotate the properties inside the class, not specifically lines 11 and 12.
➝ Option A already covers this accurately.

❌ D. Add @AuraEnabled to line 01.
➝ @AuraEnabled is not valid on classes.
➝ It is only applied to:
➥ Methods you want to expose to Lightning components
➥ Properties inside wrapper classes returned to Lightning

📚 References:
Lightning Web Components and Apex
@AuraEnabled Annotation

✅ Explanation:

Salesforce provides a standard platform event called BatchApexErrorEvent that is automatically published by the platform whenever an unhandled exception occurs in a Batch Apex job (in the start, execute, or finish methods).

This event can be consumed by:
➝ External systems via CometD (Streaming API)
➝ Internal automation via Platform Event-triggered Flows or Apex Triggers

🔍 Why Option B is Correct
➝ No custom publishing logic is needed.
➝ The platform takes care of publishing the BatchApexErrorEvent.
➝ Your external system simply needs to subscribe to this event using the Streaming API or Change Data Capture/CometD mechanism.
➝ This approach is reliable, scalable, and aligns with Salesforce event-driven architecture.

❌ Why the Other Options Are Incorrect

A. Publish the error event using EventBus.publish()
➝ Incorrect because you don’t need to manually publish the error.
➝ Salesforce handles it automatically via the BatchApexErrorEvent.

C. Publish the error event using addError
➝ addError() is used to prevent DML from proceeding and is meant for user feedback or validation, not for error notification or event publishing.

D. Publish the error event with a Flow
➝ Flows can publish custom platform events, but BatchApexErrorEvent is standard and auto-published.
➝ Using Flows to publish custom error events adds unnecessary complexity and still wouldn't catch unhandled Batch Apex errors as reliably.

📚 References:
🧩 BatchApexErrorEvent – Salesforce Developer Guide
🧩 Event Monitoring for Batch Apex
🧩 Streaming API and CometD

✅ Explanation:

Event Monitoring is a Salesforce feature that allows developers and admins to track and analyze user activity, including login history, via log files. These logs include valuable information such as:

➥ Login Time
➥ User ID
➥ IP Address
➥ Login Status
➥ Login Type (UI, API, etc.)

This data is not real-time (which aligns with the question requirement) and is available through:

➟ Event Log Files (ELFs), accessible via:
➥ REST API
➥ Event Log File Browser App (in AppExchange)
➥ Shield Event Monitoring (for more advanced visibility, if licensed)

❌ Why Other Options Are Incorrect

A. Calendar Events
➟ Related to user-created appointments and tasks, not login or security tracking.
➟ Does not provide login data or system activity logs.

B. Asynchronous Data Capture Events
➟ This option doesn't exist in Salesforce as a specific named feature.
➟ Might be confused with Change Data Capture, which tracks data changes, not user logins.

D. Developer Log (Debug Log)
➟ Shows logs for code execution (Apex, triggers, etc.) for specific users.
➟ Only logs activity when explicitly enabled.
➟ Does not passively track logins or provide consistent historical login data.

📚 Reference Documentation:
1. Salesforce Event Monitoring Overview
2. Event Log File Browser (AppExchange Tool)
3. Login History in Salesforce

✅ Explanation:

This automation needs to occur after a Case is updated, specifically when its Status = 'Could not fix' and the Case is closed. Based on these conditions, let’s break down why an after update trigger is the right choice.

🔍 Why after update is correct:
➡️ You’re creating a new related record (Engineering_Review__c) based on the values of the Case, Contact, and associated Products.
➡️ Accessing related objects (like Case.Contact or Case.Products) is more reliable in an after trigger, because the parent Case record has already been committed to the database.
➡️ You cannot safely perform DML operations (like insert) on unrelated records inside a before trigger without risk of partial commits or recursion issues.

❌ Why Other Options Are Incorrect:

B. An after upsert trigger
➜ There's no such thing as a trigger type named after upsert.
➜ Triggers respond to insert, update, delete, etc., not upsert directly.
➜ Upsert is a DML operation, but you'd still write before insert, after update, etc.

C. A before update trigger
➜ You should not perform DML operations (like creating/inserting new records) in a before trigger for unrelated objects.
➜ before triggers are intended for modifying the same records being saved — not for creating new ones.

D. A before upsert trigger
➜ Again, no such trigger exists.
➜ And performing inserts in a before context is not recommended for this use case.

✅ Use Case Best Practice Summary:
➜ Use an after update trigger when creating related records after the main record (here, Case) has been successfully updated.
Check the status condition inside the trigger:
➜ Only create Engineering_Review__c when Status == 'Could not fix' and it's a transition from some other status (to avoid duplicates).
➜ Always bulkify the logic to handle multiple Cases.

📚 Reference:
➜ Salesforce Apex Triggers – Developer Guide
➜ Trigger Context and Best Practices

✅ Explanation:

✅ B.
➞ Can initiate an Ajax request by setting action and reRender attributes.
➞ When used with reRender, it triggers a partial page update for specified components.

✅ D.
➞ Manages the status (like a spinner or loading message) during an Ajax call.
➞ Works with components like and .
➞ Doesn't initiate the Ajax request directly but supports and enhances the Ajax behavior.

✅ E.
➞ Adds Ajax behavior to non-Ajax components (like , , etc.).
➞ Fires Ajax events like onchange, onclick, etc., and can reRender specific parts of the page.

❌ A. (misspelled in the option)
➞ This would normally be a correct answer, but it appears to be a misspelled or invalid option ().
➞ If it were , then yes, it supports Ajax via reRender.

❌ C.
➞ Required as a container for input components and command buttons but does not initiate Ajax behavior.
➞ It simply enables interaction between components but does not trigger partial page updates by itself.

📚 References:
➩ Visualforce Developer Guide – Ajax Components
➩ Understanding
➩ Visualforce

✅ Explanation:

The correct choice is Option B.

➤ Salesforce Lightning Web Components allow you to control on which device form factors a component is exposed by using the element in your component’s metadata. By specifying only the “Large” form factor, you ensure that the component appears on record pages when viewed in a desktop (or large-screen) context, but is hidden when the same page is accessed from a phone or tablet. This mechanism is declarative and built into the Lightning framework, so it doesn’t require any additional Apex or JavaScript logic to enforce the restriction.

➤ either of the other options meets this requirement: the tag (Option A) is solely for design-time property exposure in the App Builder; the tag (Option C) relates to component internals and layout arrangement, not availability; and with a “formFactor” name (Option D) isn’t a recognized metadata instruction for controlling form factors.

➤ By leveraging the supported form factors feature, you maintain clean separation of concerns—your component’s rendering logic remains focused on business requirements, while the metadata governs where it can be placed.

Reference:
– Salesforce Lightning Web Components Metadata Configuration, Supported Form Factors

✅ Explanation:

The code snippet shows a Lightning Web Component (LWC) using a template for: each> directive to iterate over a orders.data collection, rendering an component for each order item. The orderId is bound to order.Id. The question implies that the component needs to communicate some information or action (e.g., a selection or change) to another part of the application, likely a parent component or another handler.

In LWC, communication between components can occur in several ways:
➜ Component Events: These are custom events fired from a child component to its parent component. This is the most common and recommended approach for parent-child communication in LWC.
➜ Application Events: These are global events that can be handled by any component, but they are less common and generally discouraged in favor of component events or the pub/sub model.
➜ Standard DOM Events: These are native browser events (e.g., click, change) and are not typically used for custom component communication in LWC.
➜ Custom Events: In LWC, custom events are created and dispatched using the CustomEvent API, which is the mechanism for firing component events.

Given that the component is likely a child component within the component, the most appropriate way to communicate (e.g., to notify the parent of an action like order selection) is by firing a custom event from the child to the parent. This aligns with LWC’s event-driven architecture, where child components use dispatchEvent with a CustomEvent to send data upward.

Correct Answer:
D. Create and dispatch a custom event.

Steps to Implement:
In the component, create a custom event using this.dispatchEvent(new CustomEvent('eventname', { detail: data }));, where data could include orderId or other relevant information. In the parent component, handle the event using the on syntax in the template (e.g., ), and define the handleNotify method to process the event data.

Reference:
Communicate with Events
Lightning Web Components Basics

✅ Explanation:

To meet the requirement of normalizing addresses on both Contact and Account whenever they're saved, Option A is the most modular, maintainable, and scalable approach.

✅ Why A is correct:
➝ Having triggers on both objects ensures that address normalization logic is run independently whenever either object is inserted or updated.
➝ By delegating the logic to a shared helper class, the code becomes reusable, DRY (Don’t Repeat Yourself), and easier to test.
➝ This structure keeps the trigger lightweight and avoids logic duplication.

🔁 This follows the Trigger → Handler → Helper design pattern, which is a Salesforce best practice.

❌ Why B is incorrect:
➝ An Apex trigger on Account that calls the Contact trigger is not supported or reliable. Triggers don’t call each other explicitly.
➝ Cross-object triggering in this way would require an update to the Contact, which could lead to recursive triggers and governor limit issues.

❌ Why C is incorrect:
➝ Although it works, placing normalization logic directly inside the triggers makes the code hard to maintain, difficult to test, and not reusable.
➝ This approach violates the Single Responsibility Principle and does not align with enterprise coding standards.

❌ Why D is incorrect:
➝ Similar to B, calling one trigger from another object’s trigger is not a valid or reliable pattern.
➝ Account and Contact are separate sObjects, and their triggers don’t naturally invoke one another.
➝ It would require updates that could lead to performance problems, complex debugging, or infinite loops.

📚 Reference:
➝ Apex Trigger Best Practices – Salesforce Developer Guide

🧠 Key Takeaway:
Use triggers on both objects and delegate logic to a shared Apex helper class to ensure clean, maintainable, and scalable code.