PDI Practice Test Questions

Explanation:

Let's analyze the scenario and the options to identify best practices for resource-intensive Apex methods, transaction control, and avoiding governor limits.

The scenario describes a method that:

Iterates over a SOQL result set (potentially large, leading to CPU or heap limits).
Performs a DML statement to save changes to the database.
The goals are transaction control and avoiding exceeding governor limits.

A. Use partial DML statements to ensure only valid data is committed.

Incorrect. "Partial DML statements" usually refers to the Database.insert(records, false) or Database.update(records, false) syntax, which allows for partial success (some records succeed, some fail). While this can be useful for data import scenarios, it's generally not a best practice for transaction control in core business logic if you want all or nothing. It doesn't inherently avoid governor limits for CPU or SOQL row limits. Full control over valid data and committing usually involves validating before DML and using try-catch blocks for error handling, or Database.setSavepoint() for full rollback.

B. Use the System.Limit class to monitor the current CPU governor limit consumption.

Correct (for avoiding exceeding limits). The System.Limits class provides methods to check the current consumption of various governor limits (e.g., getCpuTime(), getQueries(), getDmlRows()). While simply monitoring doesn't prevent exceeding limits, it's a crucial technique for proactive development and debugging. A developer would use this to identify potential bottlenecks and then refactor their code (e.g., move to Batch Apex, optimize queries/loops) before hitting the limits. It's an excellent diagnostic tool for identifying where the code might be resource-intensive.

C. Use the Database.Savepoint method to enforce database integrity.

Correct (for transaction control). Database.setSavepoint() and Database.rollback() are fundamental for transaction control. If the method performs multiple DML operations and some fail, or if certain conditions aren't met after a DML, a savepoint allows the developer to roll back all changes made since the savepoint was set, ensuring data integrity. This is a direct answer to "ensure transaction control."

D. Use the @ReadOnly annotation to bypass the number of rows returned by a SOQL.

Incorrect (and misleading).
@ReadOnly is used with Visualforce pages or Lightning components when the page/component only displays data and does not perform any DML operations. It does bypass the 50,000 row limit for SOQL queries, extending it to 1,000,000 rows.
However, the scenario explicitly states the method performs a DML statement. A method annotated with @ReadOnly (or a Visualforce page using readonly="true") cannot perform DML operations. Therefore, this option contradicts the problem statement.
It only addresses one specific governor limit (SOQL rows) and not the broader issues of CPU limits or transaction control while also performing DML.
Based on the analysis, System.Limits helps in avoiding exceeding limits by monitoring, and Database.Savepoint ensures transaction control.

Explanation:

The Developer Console is the most precise and developer-friendly tool for evaluating Apex code coverage.
Its "Overall Code Coverage" panel not only displays percentage coverage for each class but also highlights covered and uncovered lines in real time.
This immediate visibility enables developers to efficiently identify gaps in test coverage and refine their test strategies.
Compared to setup page views or general lists, this method offers granular control and deeper insight essential for test-driven development.

Explanation:

The error "Maximum trigger depth exceeded" occurs when a trigger recursively calls itself, leading to an infinite loop. This typically happens when:

The trigger performs DML operations (e.g., update, insert) on the same object it’s triggered for, causing the trigger to fire again.

A workflow field update or process builder modifies the same record, re-triggering the execution.

Why Not the Other Options?

A: User permissions do not cause recursive triggers. Permission issues would result in errors like "Insufficient privileges" or "DML not allowed."
C: Triggers are not helper classes—they are event-driven Apex code. This option is invalid.
D: Low code coverage prevents deployment but doesn’t cause runtime errors like recursion.

Explanation:

Scratch orgs are temporary, source-driven environments used for development and testing in Salesforce DX.

They are created and managed exclusively through the Salesforce Command Line Interface (CLI), which enables full DevOps automation.

Using CLI commands like sfdx force:org:create, developers can define scratch org configuration via JSON files and spin them up quickly.

Other tools like Developer Console, Workbench, or Sandbox refresh do not support creating scratch orgs.

Explanation:

Since Universal Containers already has custom JavaScript applications built on Visualforce, the quickest and most effective way to align them with Lightning Experience styling is to:

Use SLDS (Salesforce Lightning Design System):

SLDS provides ready-to-use CSS classes that match Lightning Experience’s look and feel.
Simply include the SLDS stylesheet in the Visualforce page:

< apex : page >
< ! -- -- Add SLDS stylesheet -- -- >
< apex : slds >< / apex : slds >
< !- - Your existing JavaScript / HTML content -->
< / apex : page >

Why Not the Other Options?

B: Rewriting as Lightning components – While ideal long-term, this is time-consuming and not the quickest solution.
C: enableLightning attribute – This is fictional; no such attribute exists for Visualforce.
D: Enabling "Available for Lightning Experience" – This merely makes Visualforce pages accessible in LEX but does not change their styling.

Explanation:

Before triggers fire when records are inserted, updated, or deleted, before the changes are saved to the database. Here’s why B is correct:

Data Loader/Bulk API:

When importing or updating Account records (e.g., via CSV), before triggers execute for each record in the batch.

This is standard behavior for DML operations (insert/update/delete).

Why Not the Other Options?

A: Renaming/replacing picklist values – This is a metadata change, not a DML operation. Triggers fire on record changes, not schema updates.
C: Converting Leads – While this creates Accounts, the trigger fires on the Lead conversion process, not directly on Account DML.
D: Mass Address Update tool – This tool bypasses triggers by default (uses bulk API with opt-in trigger execution).

Explanation:

To properly deploy Apex code (including triggers and Apex classes) to a Salesforce production environment, a developer must account for several key factors related to testing and code coverage.

Based on the options provided, here are the two crucial factors:

A. Apex classes must have at least 75% code coverage org-wide.
Salesforce requires that your overall Apex code coverage (including all classes and triggers) across the entire organization must be at least 75% to deploy to a production environment. This is a fundamental deployment requirement.

B. At least one line of code must be executed for the Apex trigger.
While the 75% overall coverage is necessary, for individual Apex triggers to be deployed, their associated test classes must execute at least one line of the trigger's code. This ensures that the trigger itself has been invoked and tested, even if its individual coverage doesn't reach 75% (as long as the overall org coverage does).

Let's look at why the other options are incorrect:

C. All methods in the test classes must use @isTest.
While test methods themselves should be marked as test methods (either by the class being annotated with @isTest and the method being public static void, or by the method itself being annotated with @isTest), not all methods within a test class necessarily need @isTest. Helper methods called by test methods, for example, do not need this annotation. The @isTest annotation is primarily used for the test class itself or individual test methods.

D. Test methods must be declared with the testMethod keyword.
The testMethod keyword is older, deprecated syntax. The current and recommended way to declare a test method is by using the @isTest annotation. While legacy code might still use testMethod, it's not a requirement for modern deployments and is considered outdated.

Therefore, the correct options are A and B.

Explanation:

When deploying Process Builder flows or Flows through a Change Set, Salesforce does not provide built-in UI tools to directly show their test coverage like it does for Apex classes. However, ensuring that flows are covered by Apex tests is still important — and can be done using the Tooling API and SOQL.

🔹 Why Option D is Correct:

The Tooling API provides access to metadata and test coverage data not available through the standard UI.
Developers can run SOQL queries (e.g., against FlowCoverage or ApexTestResult objects) to determine which flows have coverage.
This method gives granular and programmatic access to validate that a flow is being tested by Apex code.
It is the only reliable method to track coverage of flows during deployments.

❌ Why the Other Options Are Incorrect:

A. Use the Flow properties page:
This page does not show test coverage information. It’s mainly used for versioning and metadata.

B. Use the Code Coverage Setup page:
This page shows Apex class coverage, not flow or process builder coverage.

C. Use the Apex TestResult class:
This class provides information about Apex test execution but not specifically about Flow coverage.

Explanation:

To enforce field-level data quality and conditional logic without code, validation rules are the most efficient and declarative tool available. In this scenario, the goal is to prevent users without a specific profile from changing an Opportunity to “Closed Lost” if a required field (Lost Reason) is blank. This is precisely what validation rules are designed for.

🔹 Why Option D is Correct:

A validation rule can be configured to trigger only when:

The Opportunity Stage = "Closed Lost"
The Lost Reason is blank
The current user does not have the Sales Manager profile
It is lightweight, does not require Apex, and is easy to maintain.
You can use the formula:

AND(
ISPICKVAL(StageName, "Closed Lost"),
ISBLANK(Lost_Reason__c),
$Profile.Name <> "Sales Manager"
)

❌ Why the Other Options Are Less Efficient:

A. Record-triggered Flow:
Flows are powerful but are more complex and less performant than a validation rule for simple field checks.

B. Apex Trigger:
Overkill for this scenario. Triggers are ideal for complex logic, but not necessary for conditional checks based on user profile and field values.

C. Approval Process:
Approval processes are used to manage multi-step record approvals, not enforce conditional field-level validation.

Explanation:

When writing Apex test classes, it’s a best practice to insert test data once and reuse it across multiple test methods. The @TestSetup annotation enables developers to create common test data that runs before every test method in the class — reducing duplication and improving clarity.

🔹 Why Option C is Correct:

@TestSetup marks a method that prepares shared test data used across all @isTest methods in the class.
The method is executed once per test run, but the data it creates is isolated for each test method — ensuring test integrity.
This leads to clean, efficient, and maintainable test classes.
Perfect for inserting accounts, contacts, or custom records used in multiple tests.

❌ Why the Other Options Are Incorrect:

A. @isTest(SeeAllData=true):
This allows access to real org data — but is discouraged for proper unit testing. It doesn't set up fresh data.

B. @FreTest:
This is not a valid Apex annotation — likely a typo or fictitious choice.

D. @StartTest:
Used to reset governor limits during a test method — not for setting up data before test methods run.