PDI Practice Test Questions

Explanation:

The Visualforce page is using a standard controller for the Account object:


However, you need to:

Perform complex validation logic involving multiple objects
Redirect the user to a different Visualforce page upon success
A controller extension is the correct approach because it allows you to:

Extend the standard controller
Add custom Apex logic
Still leverage the standard controller’s built-in actions (like save()), while overriding or supplementing them

✔️ Why Controller Extension is best:

Access to the standard controller’s context (Account record)
Ability to add custom logic before or after the save()
Supports redirecting to other pages via Page Reference

❌ Why the other options are incorrect:

A. Custom controller
❌ Would replace the standard controller entirely
You'd need to re-implement all standard logic, including save() — more work than needed

C. Validation rule
❌ Limited to single-object field validation
Can’t handle multi-object logic or perform redirects

D. Apex trigger
❌ Triggers are backend-only logic
Cannot redirect or provide user-facing feedback
Not intended for complex UI control or flow logic

Explanation:

The @RestResource annotation is used to expose an Apex class as a RESTful web service in Salesforce.
It allows you to define a custom REST endpoint
You can handle HTTP methods like GET, POST, PUT, and DELETE
You specify the URL path using urlMapping

🔍 Example:

@RestResource(urlMapping='/myService/*')
global with sharing class MyRestService {
@HttpGet
global static String doGet() {
return 'Hello from REST!';
}
}

❌ Why the other options are incorrect:

A. @AuraEnabled(cacheable=true)
❌ Used to expose methods to Lightning components (LWC, Aura), not RESTful services

B. @RemoteAction
❌ Used to expose Apex methods to Visualforce + JavaScript remoting, not REST

D. @HttpInvocable
❌ Not a valid Apex annotation (possibly confused with @InvocableMethod, which is used for Flows)

Explanation:

The Limits Apex class provides methods to monitor and retrieve the governor limits that apply to the current execution context in Salesforce.
It helps developers write efficient code by allowing them to check how many resources (like DML statements, SOQL queries, etc.) have been used or are remaining.

🔍 Example methods from Limits class:

Limits.getDmlStatements() → Returns the number of DML statements used so far.
Limits.getLimitDmlStatements() → Returns the maximum allowed DML statements (usually 150).
Limits.getQueries() → Number of SOQL queries used.
Limits.getLimitQueries() → SOQL query limit.

❌ Incorrect Options:

A. Exception
Used for handling runtime errors, not governor limits.

B. Messaging
Used for email services, like sending emails, not monitoring system limits.

C. OrgLimits
Deals with org-wide limits (e.g., total API calls per org), not per-transaction governor limits.

Explanation:

To automatically deploy code to a sandbox using a script, the development team needs tools that support automation and scripting. The correct tools are:

✔️ A. VS Code (Visual Studio Code)

✅ Used with the Salesforce Extension Pack
Allows running SFDX CLI commands directly from the terminal
Supports automated development workflows when combined with scripts

✔️ B. SFDX CLI (Salesforce CLI)

✅ The core tool for automated deployments in Salesforce
Enables scripting of deployments with commands like:

sfdx force:source:deploy -u SandboxAlias

Works seamlessly in CI/CD pipelines

❌ Incorrect Answers:

C. Change Sets
❌ Manual deployment tool
Not scriptable or automatable
Requires point-and-click actions in the UI

D. Developer Console
❌ Used for manual development and debugging
Cannot deploy code or run deployment scripts

Explanation:

In the Aura component framework, when an application event is fired, it goes through two main phases in the event propagation lifecycle:

✔️ C. Default Phase
This is the first phase.
Components that register for the event using handler="APPLICATION" can handle the event.
This phase is where default handlers respond to the event.

✔️ D. Bubble Phase
This is the second phase.
The event bubbles up the component hierarchy.
Components can handle or stop propagation during this phase.

❌ Incorrect Options:

A. Emit
❌ Not a valid phase in Aura’s event framework.
"Emit" is terminology often used in JavaScript event systems, not Aura.

B. Control
❌ Control phase is specific to component events, not application events.
Application events only go through Default and Bubble phases.

Explanation:

To ensure that an Apex class works according to the requirements, the best and most reliable approach is to:

✅ Write a test class that includes unit tests for each piece of functionality.

This approach allows the developer to:

Automatically verify that the code behaves as expected
Catch any regressions or logic errors
Achieve code coverage requirements for deployment
Simulate different input and edge cases using System.assert() statements

❌ Why the other options are not sufficient:

B. Include a savepoint and Database.rollback
❌ Useful for managing data changes during testing, but does not validate business logic on its own.

C. Include a try/catch block to the Apex class
❌ Helps with error handling, but does not confirm correctness or validate logic per requirements.

D. Run the code in an Execute Anonymous block in the Developer Console
❌ Useful for manual testing, but:
Not repeatable or automated
Not a good long-term validation strategy
Does not support System.assert() validation

Explanation:

To embed a Flow (like accountOnboarding) in an Aura component, the correct tag to use is:


This component is part of the Lightning Base Components and is specifically designed to embed Flow Builder flows in Aura components.

🔍 Example Usage in Aura:

< aura : component > < br > < lightning : flow aura : id = "flow " > < / lightning : flow >


You can then start the flow using JavaScript in the controller:

var flow = component.find("flow");
flow.startFlow("accountOnboarding");

❌ Incorrect Options:

A. lightning-flow
❌ Incorrect syntax — this is used in LWC, not Aura.

B/D. aura:flow / Aura:flow
❌ These are invalid component names — no such tag exists.

Explanation:

Given the base class:

public virtual class Payment {
public virtual void makePayment(Decimal amount) {
// implementation
}
}

The class Payment is a virtual class, which means it can be extended.
The method makePayment is also marked as virtual, meaning it can be overridden in a subclass.
To override a method, use the **override** keyword in the subclass.

🔍 Why Option A is correct:
CreditcardPayment extends Payment → ✅ Correct way to inherit a class.
public override void makePayment(...) → ✅ Correct way to override a virtual method.

❌ Why other options are incorrect:

B. implements Payment
❌ Invalid: Payment is a class, not an interface — you can't use implements with a class.
C. public virtual void makePayment(...) in subclass
❌ Invalid: You must use override, not virtual, when overriding a method.

D. implements Payment with override
❌ Invalid: Again, implements is only for interfaces, not classes.

Explanation:

Ursa Major Solar needs to keep the TotalJobs__c field on Account up to date with the number of ServiceJob__c records related via an optional Lookup field (Partner_Service_Provider__c).
Because this is an optional lookup, not a master-detail relationship, you cannot use a roll-up summary field. Instead, you need to calculate and update the total using automation.

✔️ Why B. Record-Triggered Flow is the best option:

✅ Declarative, no code required
✅ Supports logic based on lookup relationships
✅ Can handle create, update, and delete events
✅ Easily maintainable and more efficient than Apex for simple logic
✅ Most efficient non-code approach that satisfies the requirement

❌ Why other options are not ideal:

A. Change TotalJob__c to a roll-up summary field
❌ Not possible: roll-up summary fields only work with master-detail relationships, and Partner_Service_Provider__c is a lookup.

C. Create an Apex trigger on ServiceJob__c
❌ Functional, but unnecessary unless the logic is complex.
More maintenance-heavy and requires unit tests.

D. Create a schedule-triggered flow on ServiceJob__c
❌ Not efficient for real-time updates.
Delays data consistency and is resource-intensive.

Explanation:

Option C: String.escapeSingleQuotes()

String query = 'SELECT Id FROM Account WHERE Name LIKE \'%' + String.escapeSingleQuotes(name) + '%\'';
List results = Database.query(query);

Why Safe?

String.escapeSingleQuotes() sanitizes the input by escaping single quotes (' → \').
Prevents attackers from breaking the query with malicious input (e.g., name = "test' OR Name != ''").

Option D: Bind Variable

String query = '%' + name + '%';
List results = [SELECT Id FROM Account WHERE Name LIKE :query];

Why Safe?
Bind variables (:query) are automatically escaped by Salesforce.
No string concatenation = no injection risk.

Why Not the Others?

Option A: Unsafe Concatenation

String query = 'SELECT Id FROM Account WHERE Name LIKE \'%' + name + '%\'';

Risk: Direct concatenation allows SOQL injection (e.g., if name = "test' OR Name != ''").

Option B: noQuotes() (Invalid Method)
String query = 'SELECT Id FROM Account WHERE Name LIKE \'%' + name.noQuotes() + '%\'';

Risk: noQuotes() doesn’t exist in Apex. Even if it did, it wouldn’t escape quotes.