PDI Practice Test Questions

Explanation:

- Dynamic Forms allow different fields to be displayed based on the user's job role, ensuring a personalized experience.
- Custom Permissions help restrict access to the functionality, ensuring only a small group of users can use the form.
- Lightning Web Components (LWC) provide flexibility in designing the form and handling dynamic field visibility based on user roles.

Why Not the Other Options?

- B (Dynamic Action on Account Record Page): Dynamic Actions control button visibility but do not manage field visibility within a form.
- D (Dynamic Action on Page Layouts): Page Layouts are static and do not provide dynamic field visibility based on user roles.
Would you like a guide on implementing Dynamic Forms and LWC for this use case? 😊

Explanation: Why Option C is Correct:

global class WebServiceClass → ✔️ Makes the class available outside the namespace (required for web services)
private Boolean helperMethod() → ✔️ Internal helper method, hidden from external callers
webservice static String updateRecords() → ✔️ Properly declared public web method for SOAP access

❌ Why Other Options Are Incorrect:

A: Uses global String updateRecords() without static or webservice → ❌ Invalid for SOAP web service.

B: Uses webservice class → ❌ Invalid syntax, webservice is not a valid modifier for a class.
D: Same issue as B → webservice class is invalid.

Explanation:

- Validation Rules enforce business logic by ensuring data integrity before records are saved. They allow declarative enforcement of conditions without requiring code.
- Record-Triggered Flows automate business processes by executing logic when records are created, updated, or deleted. They provide a powerful declarative way to implement complex workflows without Apex.

❌ Why the other options are incorrect:
B. Remote Actions

❌ Imperative Apex code used for invoking controller methods from Visualforce
Not declarative

D. Batch Jobs

❌ Built using Apex code
Used for processing large volumes of data asynchronously
Not a declarative solution

Key Takeaways:

✅ Validation Rules (A) + Record-Triggered Flows (C) = 100% declarative business logic.
🚫 Remote Actions (B) and Batch Jobs (D) require code.

Explanation:

- StandardSetController is specifically designed for handling large datasets efficiently in Visualforce pages.
- It provides built-in pagination, reducing the amount of data stored in the view state and improving page performance.
- Since customers rent over 10,000 containers, loading all records at once would exceed the 170KB view state limit. Pagination ensures only a subset of records is loaded at a time.

✔️ Why D. StandardSetController is the best solution:

✅ Built-in support for pagination in Visualforce pages
✅ Handles view state efficiently
✅ Requires no custom code for managing offset, limits, or record counts
✅ Works well with Visualforce apex:pageBlockTable or apex:repeat

Key Takeaways:

✅ StandardSetController (D) is the Salesforce-recommended solution for large datasets.
🚫 Avoid manual offset (B/C) or transient hacks (A).

Explanation:

- Salesforce CLI (SFDX CLI) is the best tool for automating tests in a CI/CD pipeline.
- It allows developers to run Apex tests using commands like:

sfdx force:apex:test:run -u sandboxAlias
- This ensures automated testing is integrated into the development workflow, reducing deployment failures.

❌ Why the other options are incorrect:
A. Force.com Toolkit

❌ Outdated and not suitable for modern CI/CD.
Not actively maintained or recommended by Salesforce.

C. Visual Studio Code

❌ It's an IDE, not a CI tool.
Used for local development but not for automating test execution.
D. Developer Console
❌ Only useful for manual testing and debugging.
Cannot be used in a CI pipeline or for automated deployments.

Key Takeaways:
✅ Salesforce CLI (B) is the only tool designed for automated testing in CI.
🚫 Avoid legacy (A) or manual (D) tools.

Explanation:

- Record-Triggered Flow (Fast Field Updates): This is the best declarative option for updating the Timezone field when the Postal Code changes. Since it runs before-save, it ensures efficient updates without requiring additional DML operations.
- Account Trigger: If more complex logic is needed (such as querying the PostalCodeToTimezone__c object dynamically), an Apex trigger provides flexibility for handling the update programmatically.

✔️ B. Fast Field Updates Record-Triggered Flow
✅ Declarative (no code)
✅ Can trigger on field change (Postal Code)
✅ Use Get Records to fetch timezone from PostalCodeToTimezone__c
✅ Use Update Records to update Timezone
✅ Fast Field Updates (before-save) improve performance by avoiding DML

✔️ D. Account Trigger

✅ Use Apex code to write custom logic
✅ Good choice if business logic is complex or performance needs are high
✅ Offers maximum flexibility, especially if future logic requires more branching or external calls

❌ Incorrect Options:
A. Approval Process
❌ Used to manage record approvals, not to trigger field updates based on data changes
C. Quick Actions

❌ Used for UI-based manual actions, not automatic data-driven updates
Key Takeaways:

✅ Record-Triggered Flow (B) = Best for declarative, low-maintenance updates.
✅ Account Trigger (D) = Best for complex logic or bulk operations.
🚫 Avoid Approval Process (A) or Quick Actions (C)—they don’t fit the use case.

Explanations:

A. Debug log levels are cumulative...

❌ Incorrect.
Log levels are NOT cumulative in Salesforce.
For example, selecting FINE logs only FINE-level events (not DEBUG, INFO, etc.).
Key Point: Each level must be explicitly set in the TraceFlag settings.

B. The maximum size of a debug log is 5 MB.

✅ Correct.
Salesforce enforces a 5 MB limit per debug log. If exceeded, the log is truncated.
Tip: Use selective logging (e.g., filters for classes/triggers) to stay within limits.

C. Only the 20 most recent debug logs for a user are kept.

✅ Correct.
Salesforce retains only the last 20 debug logs per user. Older logs are automatically deleted.
Note: Logs can be downloaded or deleted manually to free space.

D. Debug logs can be set for specific users, classes, and triggers.

✅ Correct.
Debug logs are configurable via TraceFlags, which can target:
Specific users (e.g., your own user for testing).
Specific Apex classes or triggers (to narrow down debugging).
How to Set: Setup → Debug Logs → Add Trace Flags.

E. System debug logs are retained for 24 hours.

❌ Incorrect.
Debug logs are retained indefinitely (until the 20-log limit is reached).
Exception: Org-wide monitoring logs (not user debug logs) may have retention policies.

Explanation:

Lightning Web Components (LWCs) can access a variety of Salesforce-managed resources. Here's a breakdown of what's correct:

✔️ A. SVG resources
✅ True
LWCs can use custom SVGs (either inline or from static resources).
You can embed them in templates or use them as part of component branding.

✔️ C. Content asset files
✅ True
Content assets (uploaded via Salesforce CMS or Files) can be referenced in LWCs using ContentAsset or by constructing public URLs.

✔️ D. Static resources
✅ True
You can import static resources (like images, CSS, JS, or fonts) using:
import myResource from '@salesforce/resourceUrl/resourceName';

❌ Incorrect Options:

B. Third-party web components
❌ False
LWC doesn’t natively support importing external web components unless wrapped manually in LWC or exposed via static resources — and they must follow strict security policies.

E. All external libraries
❌ False
You can use some external libraries by loading them via static resources, but not all are supported due to Locker Service/security restrictions.
External libraries must be manually loaded using loadScript() or loadStyle().

Explanation:
To enforce field-level security (FLS) automatically when building forms in a Lightning Web Component (LWC), the developer should use:

inside a

Why this is important:

lightning-input-field automatically respects FLS:

If a user doesn't have read access, the field is hidden
If a user has read-only access, the field is disabled
If a user has read/write access, the field is editable

This ensures that only the appropriate fields are shown or editable based on user permissions, without writing custom logic.

❌ Why the other options are incorrect:

A. force-input-field
❌ Not a valid LWC component — likely a confusion with older Aura naming

B. ui-input-field
❌ Part of the Aura UI namespace, deprecated and not available in LWC

C. aura-input-field
❌ Also Aura framework-specific, not usable in Lightning Web Components

Explanation:

The provided Apex code performs a SOQL query inside a for loop, which is a well-known anti-pattern in Salesforce development due to its governor limits.

In this code:

for (Id leadId : leadIds) {
result.add([SELECT FIELDS(ALL) FROM Lead WHERE Id = :leadId]);
}

A SOQL query is executed once for each lead ID.

If leadIds contains more than 100 items, it exceeds the governor limit of 100 SOQL queries per transaction, causing a runtime exception.

🔧 Best Practice Fix:

Use bulk querying instead of querying inside the loop:

public static List obtainAllFields(Set leadIds) {
return [SELECT FIELDS(ALL) FROM Lead WHERE Id IN :leadIds];
}

This executes just one query, no matter how many IDs are passed in.

❌ Why other options are incorrect:

A. Avoid executing queries without a limit clause
Not necessary when querying by specific IDs — the ID filter already limits the result.

B. Avoid returning an empty List of records
Returning an empty list is safe and standard if no records match — not a best practice violation.

C. Avoid using variables as query filters
Using variables (e.g., :leadIds) is best practice for dynamic and safe queries — this option is incorrect.