PDI Practice Test Questions

Explanation:

Given this custom exception declaration:

public class ParityException extends Exception {}

There are two valid ways to throw (fire) this exception in Apex:

✔️ B. throw new ParityException("parity does not match");

✅ Correct
You can pass a custom message to the exception constructor.
This message will be available via get Message().

✔️ D. throw new ParityException();

✅ Correct
You can throw the exception without passing any arguments.
This uses the default constructor.

❌ Incorrect Options:

A. new ParityException();
❌ Just instantiates the exception but does not throw it.

C. new ParityException('parity does not match');
❌ Similar to A — it creates the exception but does not throw it.

Explanation:

Here are the two correct use cases for executing Anonymous Apex:

Scheduling an Apex Class (B):

Anonymous Apex can schedule jobs using System.schedule().

Example:

System.schedule('Daily Update', '0 0 12 * * ?', new MyScheduledClass());

Running Batch Apex (C):

Anonymous Apex can launch batch jobs with Database.executeBatch().

Example:

Database.executeBatch(new UpdateContactsBatch(), 200);

Why Not the Others?

A. Deleting 15,000 Accounts in a single transaction:
Governor limit violation: Anonymous Apex has a 10,000-record DML limit. Use Batch Apex instead.

D. Adding unit test coverage:
Tests must be in test classes (@isTest). Anonymous Apex doesn’t count toward coverage.

Explanation:

A SOQL (Salesforce Object Query Language) query can return results in several data types, primarily collections of records (objects) or aggregate results. Here’s how the correct answers break down:

A. List

✅ True
SOQL typically returns a List of sObjects.
Example:
List accounts = [SELECT Id, Name FROM Account];

D. sObject

✅ True
You can store a single record from a SOQL query directly in an sObject variable.
Example:
Account acc = [SELECT Id, Name FROM Account LIMIT 1];

E. Double

✅ True
When using aggregate functions (like AVG() or SUM()), SOQL can return numeric values like Double.
Example:
AggregateResult[] result = [SELECT AVG(Amount) avgAmount FROM Opportunity]; Double average = (Double)result[0].get('avgAmount');

❌ Incorrect Options:

B. Long
❌ Not a return type for SOQL. While some fields might store long integers, SOQL itself doesn't return Long types directly.

C. Integer
❌ Similar to Long, SOQL does not return raw Integer values — even COUNT() typically returns Long.

Explanation:

When integrating external systems (like an order system) into Salesforce, the best way to match and identify records is by using a field that is marked as:

✅ External ID and Unique

This allows Salesforce to:

Quickly locate records based on the external Order Number
Prevent duplicate imports
Match incoming data from an external system using that field

🔍 Why use External ID + Unique for Order Number?

External ID allows external systems to reference records without using Salesforce IDs.
Unique ensures no duplicate Order Numbers exist in Salesforce.
Great for data import, integration, and record upserts.

❌ Why other options are incorrect:

A. Direct Lookup
❌ Not a valid field type in Salesforce.

C. Lookup
❌ Lookups are used to relate one object to another — they don’t ensure uniqueness or support upserts based on external data.

D. Indirect Lookup
❌ Only used in External Objects (via Salesforce Connect), not standard or custom objects directly.

Explanation:

To ensure that the TestUtils class and its methods are only usable in test context (i.e., cannot be used in production code), you must annotate the entire class with:

@IsTest

This ensures:

The class is not included in production code
Its methods can only be called from test methods
It's excluded from your organization’s Apex code size limit

🔍 Updated Code (with @IsTest):

@IsTest
public class TestUtils {

public static Account createAccount() {
Account act = new Account();
// ...set some fields on acct...
return act;
}

// ...other methods...
}

❌ Why the other options are incorrect:

A. Change public to private
❌ Makes the class inaccessible outside itself — not useful for shared test utility methods.

B. Add @IsTest above line 03
❌ You can’t annotate individual methods in this way unless they are test methods, which this is not.

D. Remove static from line 03
❌ Static is required for utility methods to be called without instantiating the class.

Explanation:

Let's analyze the code step by step to determine the value of x.

Given Code:

Boolean isOK;
integer x;
String theString = 'Hello';

if (isOK == false && theString == 'Hello') {
x = 1;
} else if (isOK == true && theString == 'Hello') {
x = 2;
} else if (isOK != null && theString == 'Hello') {
x = 3;
} else {
x = 4;
}

Key Observations:

isOK is uninitialized:

In Apex, uninitialized Boolean variables default to null (not false).
theString is initialized:
theString == 'Hello' evaluates to true.

Evaluation of Conditions:

First if (isOK == false && theString == 'Hello'):

isOK is null → isOK == false evaluates to false.
Result: Skipped.

Second else if (isOK == true && theString == 'Hello'):

isOK is null → isOK == true evaluates to false.

Result: Skipped.

Third else if (isOK != null && theString == 'Hello'):

isOK is null → isOK != null evaluates to false.
Result: Skipped.

Final else:

All conditions failed → x = 4.

Why Not the Others?

A. 3: Incorrect because isOK is null (fails isOK != null).
B. 1: Incorrect because isOK is not false (it’s null).
D. 2: Incorrect because isOK is not true (it’s null).

Explanation:

In Apex (like in Java), when a class wants to use an interface, it must implement that interface using the implements keyword.

So if you have an interface:

public interface Laptop {
void start();
}

Then a class using it should be written like:

public class SilverLaptop implements Laptop {
public void start() {
// Implementation here
}
}

❌ Why the other options are incorrect:

A. @Extends(class='Laptop')
❌ Not valid Apex syntax — Apex doesn't use annotations like this to extend or implement interfaces.

B. public class SilverLaptop extends Laptop
❌ extends is used to inherit from a class, not to implement an interface.

C. @Interface (class='Laptop')
❌ Not a valid Apex syntax — @Interface is not an Apex annotation.

Explanation:

In the Aura component framework, JavaScript functions can be defined in several resources to handle logic, events, and UI behavior. The three resources that support JavaScript functions are:

A. Renderer

✅ Contains JavaScript logic to override or extend default rendering behavior.
Methods like render(), rerender(), afterRender() are defined here.

C. Helper

✅ Holds reusable logic that can be called from the controller or renderer.
Ideal for separating logic from UI-handling code.

D. Controller

✅ Contains event-handling JavaScript methods (like doInit, handleClick, etc.).
Responds to component events, actions, and UI changes.

❌ Incorrect Answers:

B. Style
❌ Holds CSS, not JavaScript.

E. Design
❌ Used to define design-time attributes for App Builder, not logic or JS.

Explanation:

Correct Syntax for PDF Rendering:

Visualforce uses the renderAs attribute to specify PDF output:

< apex := " " page=" " renderas=" pdf ">
< !- - PDF content here - - >


This is the standard and documented way to generate PDFs in Visualforce.

Why Not the Others?

A. : Invalid (no contentType attribute in Visualforce).
B. : Invalid (same as A).
D. : Incorrect format (renderAs takes simple values like "pdf", not MIME types).

Explanation:

When dealing with a junction object, sharing can be a bit tricky because the junction object's sharing behavior depends on its master-detail relationships.

Here's a breakdown of how sharing typically works with junction objects:

Junction Object Sharing: The sharing of a junction object record (like Case_Defect__c) is often controlled by the sharing settings of its master records. If the junction object has two master-detail relationships, its sharing settings usually inherit from one of the master records. If both are master-detail, the sharing settings of the junction object are driven by the more restrictive of the two parent objects (or explicitly configured).

Access to Junction Records: To gain access to a specific Case_Defect__c record, a user generally needs read/write access to both of its parent master records (Case and Defect__c). If a user can see one parent but not the other, they typically won't be able to see the junction record.

Let's evaluate the options:

A. Share the Case_Defect_c record.

While you can share the junction object record directly if it's in a lookup relationship, or if sharing settings allow, in a master-detail relationship scenario (which is typical for junction objects), its sharing is often derived from the parents. Directly sharing the junction object might not be sufficient if the user doesn't have access to the associated master records.

B. Share the parent Case record.

This is necessary, but not sufficient on its own. If the user only has access to the Case but not the Defect__c record, they won't see the junction object.

C. Share the parent Defect_c record.

This is also necessary, but not sufficient on its own. If the user only has access to the Defect__c but not the Case record, they won't see the junction object.

D. Share the parent Case and Defect_c records.

This is the most robust and generally correct approach. For a user to access a specific junction object record (Case_Defect__c), they must have access to both of the parent records it links (Case and Defect__c). Salesforce's security model ensures that if a user cannot see one of the master records, they cannot see the detail (junction) record linked to it. By sharing both parent records, you ensure the user has the foundational access required for the junction object.