Troubleshooting practice questions

A developer is troubleshooting a transaction that exceeds governor limits due to SOQL queries. Which THREE techniques help prevent hitting SOQL query limits in Apex? (Choose THREE.)

Trap 1: Executing SOQL queries inside a for loop iterating over all child…

Placing a SOQL query inside a loop causes a separate database round-trip for every single iteration, which rapidly exhausts the synchronous governor limit of 100 queries. Developers are often tempted by this pattern when attempting to retrieve child records dynamically for every parent record processed in a collection. It would only be the correct choice if querying a tiny, fixed number of records outside governor limits, or when leveraging lazy loading in specific UI extensions where query counts are strictly controlled and bounded.

Trap 2: Calling Database.query() for every single record processed in a…

Executing SOQL queries inside a loop or for every individual record triggers a distinct query against the database on each iteration, causing the transaction to rapidly exhaust the strict governor limit of 100 SOQL queries per transaction in bulk operations. This approach appears attractive when developers need to dynamically construct queries based on specific field values of individual records or implement polymorphic queries where filter criteria change per record. While `Database.query()` is the correct mechanism for constructing dynamic SOQL strings at runtime—such as building flexible search filters with variable user inputs—it must be supplied with a collection of values or a single aggregated string rather than being executed inside an iterative loop processing records.

A
Using maps and collections to store query results and perform in-memory lookups instead of querying inside loops.
Querying inside a loop easily breaches the synchronous governor limit of 100 SOQL queries per transaction. Storing query results in maps and collections allows developers to fetch all required data in a single aggregate query upfront, satisfying the core constraint of reducing query execution frequency. Subsequent lookups are then performed entirely in-memory against the collection rather than hitting the database repeatedly, drastically lowering resource consumption and preventing limits from being exceeded.
B
Writing queries that retrieve only the specific fields and records required using WHERE clauses.
Restricting retrieved data directly addresses the governor limit on total SOQL queries by fetching only necessary fields and records within a single database round-trip. Using selective `WHERE` clauses ensures that the heap size and database processing overhead remain minimal, preventing both query row limits and heap size exceptions in complex transactions. This targeted data retrieval directly satisfies the constraint of mitigating SOQL-related governor limit breaches during execution.
C
Using relationship queries (parent-to-child or child-to-parent) to retrieve related data in a single query.
Relationship queries directly address the governor limit on the total number of SOQL queries issued per transaction (the 100-query limit) by retrieving parent and child records in a single database round-trip. By joining related objects within one statement instead of executing separate queries iteratively inside a loop, developers drastically reduce the cumulative query count. This consolidation prevents the transaction from exceeding the synchronous execution threshold, making it a foundational best practice for scalable Apex code.
D
Executing SOQL queries inside a for loop iterating over all child records.
Why it fails: Placing a SOQL query inside a loop causes a separate database round-trip for every single iteration, which rapidly exhausts the synchronous governor limit of 100 queries. Developers are often tempted by this pattern when attempting to retrieve child records dynamically for every parent record processed in a collection. It would only be the correct choice if querying a tiny, fixed number of records outside governor limits, or when leveraging lazy loading in specific UI extensions where query counts are strictly controlled and bounded.
E
Calling Database.query() for every single record processed in a trigger.
Why it fails: Executing SOQL queries inside a loop or for every individual record triggers a distinct query against the database on each iteration, causing the transaction to rapidly exhaust the strict governor limit of 100 SOQL queries per transaction in bulk operations. This approach appears attractive when developers need to dynamically construct queries based on specific field values of individual records or implement polymorphic queries where filter criteria change per record. While `Database.query()` is the correct mechanism for constructing dynamic SOQL strings at runtime—such as building flexible search filters with variable user inputs—it must be supplied with a collection of values or a single aggregated string rather than being executed inside an iterative loop processing records.

Question 2hardmulti select

A developer is troubleshooting an Apex trigger recursion issue where an update operation triggers itself infinitely. Which THREE strategies can the developer use to safely prevent this recursion? Choose 3 options.

Trap 1: Call Limits.getQueries() at the start of every trigger to abort if…

Relying on `Limits.getQueries()` fails because checking governor limits merely detects resource consumption rather than halting the logical loop, meaning the transaction will still exhaust CPU time or SOQL limits before stopping. This approach is tempting because it is a standard mechanism for monitoring overall transaction health and preventing runaway code in asynchronous batch batching or scheduled processing jobs where threshold guards are used to gracefully abort prior to hitting fatal limits.

Trap 2: Wrap all DML statements in a try-catch block that catches recursion…

Apex recursion surfaces as a System.LimitException for stack depth, not a catchable recursion exception, so try-catch cannot intercept it. It is tempting because try-catch is a standard defensive pattern, but it would be correct only for handling DmlException or callout errors, not for preventing recursive trigger re-entry.

A
Call Limits.getQueries() at the start of every trigger to abort if limits are near.
Why it fails: Relying on `Limits.getQueries()` fails because checking governor limits merely detects resource consumption rather than halting the logical loop, meaning the transaction will still exhaust CPU time or SOQL limits before stopping. This approach is tempting because it is a standard mechanism for monitoring overall transaction health and preventing runaway code in asynchronous batch batching or scheduled processing jobs where threshold guards are used to gracefully abort prior to hitting fatal limits.
B
Utilize Custom Settings or Custom Metadata to provide a global toggle to turn off triggers dynamically.
Utilising Custom Settings or Custom Metadata enables developers to define a global toggle that can be evaluated at the beginning of an Apex trigger execution context. By checking this configurable boolean flag before running the trigger logic, administrators or developers can dynamically bypass the recursive execution path without needing a code deployment. This satisfies the requirement to safely prevent infinite recursion by providing an externally manageable switch to halt recurring update operations.
C
Wrap all DML statements in a try-catch block that catches recursion exceptions.
Why it fails: Apex recursion surfaces as a System.LimitException for stack depth, not a catchable recursion exception, so try-catch cannot intercept it. It is tempting because try-catch is a standard defensive pattern, but it would be correct only for handling DmlException or callout errors, not for preventing recursive trigger re-entry.
D
Compare old and new field values using Trigger.oldMap and Trigger.newMap to check if relevant fields actually changed.
Comparing field values between `Trigger.oldMap` and `Trigger.newMap` prevents infinite recursion by ensuring the trigger execution logic only proceeds when specific, relevant data has actually been modified. This satisfies the constraint of stopping self-triggering update operations by establishing a precise conditional check before invoking DML operations. If the monitored fields remain unchanged during an update, the code bypasses the recursive block altogether, effectively breaking the infinite loop without sacrificing necessary data processing.
E
Use a static boolean variable in a helper class set to false after the first execution.
A static boolean in a helper class is checked at trigger entry and flipped after the first pass, so re-entrant updates skip the trigger body. This breaks the recursive loop within the transaction while preserving the initial execution's DML.

Question 3hardmultiple choice

A developer is troubleshooting a Lightning Web Component where data returned from an Apex wire adapter needs to be mutated before being rendered. What is the correct pattern to handle this?

Trap 1: Decorate the wire property with @api mutable to allow direct writes.

Data returned from a wire adapter is immutable, and no `@api mutable` decorator exists within the Lightning Web Component framework to bypass this restriction. Developers often confuse this with the `@api` decorator, which is intended to expose public properties for parent components to pass data into a child. While `@api` facilitates data flow from a parent, it provides no mechanism to modify the read-only objects emitted by a wire service, necessitating the use of a getter or a wire function instead.

Trap 2: Use the eval() function to strip immutability constraints from the…

Using `eval()` to bypass immutability constraints fails because Lightning Web Components enforce strict read-only properties on wire service data to ensure data integrity and prevent side effects during the reactive lifecycle. While `eval()` is designed to execute arbitrary strings as JavaScript code—often utilised in legacy applications for dynamic expression evaluation or parsing complex JSON structures at runtime—it introduces severe security vulnerabilities and performance overhead. It provides no mechanism to safely clone or transform data objects to meet the requirements of a reactive component.

Trap 3: Directly assign new properties to the object returned by the wire…

Wire adapter data is immutable; mutating it directly throws an error or is ignored. The tempting appeal is convenience, since plain Apex objects allow direct property assignment. The correct pattern copies the data into a separate property, typically via a getter or by spreading into a new object.

A
Decorate the wire property with @api mutable to allow direct writes.
Why it fails: Data returned from a wire adapter is immutable, and no `@api mutable` decorator exists within the Lightning Web Component framework to bypass this restriction. Developers often confuse this with the `@api` decorator, which is intended to expose public properties for parent components to pass data into a child. While `@api` facilitates data flow from a parent, it provides no mechanism to modify the read-only objects emitted by a wire service, necessitating the use of a getter or a wire function instead.
B
Use the eval() function to strip immutability constraints from the prototype chain.
Why it fails: Using `eval()` to bypass immutability constraints fails because Lightning Web Components enforce strict read-only properties on wire service data to ensure data integrity and prevent side effects during the reactive lifecycle. While `eval()` is designed to execute arbitrary strings as JavaScript code—often utilised in legacy applications for dynamic expression evaluation or parsing complex JSON structures at runtime—it introduces severe security vulnerabilities and performance overhead. It provides no mechanism to safely clone or transform data objects to meet the requirements of a reactive component.
C
Create a shallow copy or clone of the wire data object in a getter or property assignment before mutation.
Wire adapter data is read-only and frozen, so direct mutation throws in strict mode. Cloning via spread or structuredClone in a getter or property assignment produces a mutable copy, satisfying the stem's need to transform Apex-returned data before rendering without breaking reactivity.
D
Directly assign new properties to the object returned by the wire adapter property.
Why it fails: Wire adapter data is immutable; mutating it directly throws an error or is ignored. The tempting appeal is convenience, since plain Apex objects allow direct property assignment. The correct pattern copies the data into a separate property, typically via a getter or by spreading into a new object.

Question 4hardmulti select

A developer is troubleshooting a complex set of triggers and wants to restrict the amount of debug log data captured for a specific integration user. Which THREE actions can the developer take to manage debug logs effectively? (Choose three.)

Trap 1: Modify the organization-wide default debug level in Company…

Company Information houses core organisational settings, timezone values, and fiscal year configurations rather than system log parameters, rendering it technically incapable of filtering trace flags or controlling user-specific logging granularity. This option appears tempting because administrators frequently visit Company Information to manage core enterprise properties and licence allocations. It would be the correct choice if the objective required updating the organisation's primary billing address, default currency, or primary contact details rather than configuring diagnostic logging thresholds for an individual integration user.

Trap 2: Set up Apex Logging levels directly inside custom metadata types.

Custom metadata types store application configuration data and cannot dynamically intercept platform logging execution or interface with the Debug Log level architecture. Developers might find this option tempting because custom metadata types are commonly utilised to parameterise application behaviour and manage environment-specific configurations without hardcoding. In a different scenario, they would be the correct choice for storing configurable feature flags or external service endpoint URLs that need to be deployed alongside declarative packages.

A
Use a Debug Level configuration to define the verbosity for individual log categories.
Configuring a Debug Level directly satisfies the requirement to restrict the amount of captured log data by allowing developers to precisely control the verbosity for individual log categories, such as Database, Workflow, and Callout. By dialling down unnecessary verbosity to finer granularities like 'None' or 'Error' specifically for the integration user's trace flag, the system avoids generating excessive debug noise while still capturing essential diagnostic information for the complex triggers.
B
Adjust log levels for specific categories such as Database, Workflow, and Apex Code.
Fine-tuning log levels directly addresses the constraint to restrict the overall volume of captured data for a specific integration user. By lowering verbosity specifically for high-volume categories like Database, Workflow, and Apex Code, developers prevent unnecessary tracing operations from consuming valuable debug log storage allocations. This targeted adjustment ensures that only essential execution details are recorded during integration transactions, effectively preventing log storage limits from being exceeded during heavy API processing.
C
Configure a Trace Flag specifying the targeted user and a designated start/end time.
Setting up a Trace Flag directly satisfies the requirement to target a specific integration user while restricting data volume through explicit start and end times. By defining a precise temporal window and associating the log level specifically with that user's ID, administrators can capture necessary diagnostic data without overwhelming the debug log storage limits with excessive output from automated processes running concurrently across the wider Salesforce organisation.
D
Modify the organization-wide default debug level in Company Information.
Why it fails: Company Information houses core organisational settings, timezone values, and fiscal year configurations rather than system log parameters, rendering it technically incapable of filtering trace flags or controlling user-specific logging granularity. This option appears tempting because administrators frequently visit Company Information to manage core enterprise properties and licence allocations. It would be the correct choice if the objective required updating the organisation's primary billing address, default currency, or primary contact details rather than configuring diagnostic logging thresholds for an individual integration user.
E
Set up Apex Logging levels directly inside custom metadata types.
Why it fails: Custom metadata types store application configuration data and cannot dynamically intercept platform logging execution or interface with the Debug Log level architecture. Developers might find this option tempting because custom metadata types are commonly utilised to parameterise application behaviour and manage environment-specific configurations without hardcoding. In a different scenario, they would be the correct choice for storing configurable feature flags or external service endpoint URLs that need to be deployed alongside declarative packages.

Question 5mediummultiple choice

What is the primary purpose of the 'System.debug()' statement?

Trap 1: To display an error to the end user

`System.debug()` writes log messages to the Apex debug logs for developer diagnostics and troubleshooting, making it tempting because it is the standard method for inspecting variable states during testing. However, it fails in this scenario because it outputs exclusively to the Developer Console or execution logs rather than rendering interface elements in the browser, meaning an end user interacting with the user interface will never see the message.

Trap 2: To stop the execution of the code

Stopping Apex code execution relies on runtime exceptions or abort methods rather than logging utilities, making this choice incorrect because `System.debug()` merely writes diagnostic information to the execution log without altering control flow. Developers often find this confusing because logging statements naturally occur right before troubleshooting breakpoints, making it tempting to assume they control execution state. Such logging functions would be correct in scenarios where a developer needs to output variable values or execution paths for analysis while allowing the surrounding transaction to proceed normally to completion.

Trap 3: To log an audit trail of configuration changes

System.debug() cannot track configuration changes because it only outputs runtime execution data to the developer console or debug logs during code execution, rather than capturing administrative actions or metadata modifications. Developers often find this option tempting because it serves as a primary tool for troubleshooting and logging data within Apex code, making it intuitive to assume it monitors system events. It would be the correct choice when a developer needs to output variable values, execution paths, or diagnostic messages during the testing and debugging of custom Apex code.

A
To display an error to the end user
Why it fails: `System.debug()` writes log messages to the Apex debug logs for developer diagnostics and troubleshooting, making it tempting because it is the standard method for inspecting variable states during testing. However, it fails in this scenario because it outputs exclusively to the Developer Console or execution logs rather than rendering interface elements in the browser, meaning an end user interacting with the user interface will never see the message.
B
To stop the execution of the code
Why it fails: Stopping Apex code execution relies on runtime exceptions or abort methods rather than logging utilities, making this choice incorrect because `System.debug()` merely writes diagnostic information to the execution log without altering control flow. Developers often find this confusing because logging statements naturally occur right before troubleshooting breakpoints, making it tempting to assume they control execution state. Such logging functions would be correct in scenarios where a developer needs to output variable values or execution paths for analysis while allowing the surrounding transaction to proceed normally to completion.
C
To log an audit trail of configuration changes
Why it fails: System.debug() cannot track configuration changes because it only outputs runtime execution data to the developer console or debug logs during code execution, rather than capturing administrative actions or metadata modifications. Developers often find this option tempting because it serves as a primary tool for troubleshooting and logging data within Apex code, making it intuitive to assume it monitors system events. It would be the correct choice when a developer needs to output variable values, execution paths, or diagnostic messages during the testing and debugging of custom Apex code.
D
To write information to the debug log
Executing a `System.debug()` statement directly serialises messages into the execution context, which subsequently generates a log entry within the Salesforce debug log. This mechanism satisfies the stem's requirement to record runtime information, enabling developers to monitor variable states and control flow during Apex execution without altering the transactional database.

Question 6mediummulti select

Which THREE items are included in a debug log?

Trap 1: Browser cookies.

Debug logs capture Apex execution, database operations, callouts and system events; browser cookies reside client-side and are never written to them. Cookies matter for session or web-tier troubleshooting, which is where this option would apply, not for Apex debug log analysis.

Trap 2: User password history.

Debug logs record Apex, SOQL, DML, workflow and callout activity; password history is stored in the user record and never emitted to logs. Password history is relevant to authentication policy configuration, which is where this option would be the correct consideration.

A
System.debug statements.
Debug logs capture every System.debug call, recording the statement's log level, category and message text. This is the primary mechanism developers use to trace variable values and execution flow during Apex, flow or process debugging sessions.
B
Browser cookies.
Why it fails: Debug logs capture Apex execution, database operations, callouts and system events; browser cookies reside client-side and are never written to them. Cookies matter for session or web-tier troubleshooting, which is where this option would apply, not for Apex debug log analysis.
C
User password history.
Why it fails: Debug logs record Apex, SOQL, DML, workflow and callout activity; password history is stored in the user record and never emitted to logs. Password history is relevant to authentication policy configuration, which is where this option would be the correct consideration.
D
SOQL queries.
Debug logs record each SOQL query executed, including the query string, the number of rows returned and the cumulative query count against governor limits. This lets developers identify inefficient or loop-nested queries causing limit exceptions.
E
DML operations.
DML operations appear in debug logs as executed database statements, satisfying the stem's requirement for included log content. Each insert, update, delete or upsert records the affected object and row count, letting developers trace data changes during execution. This confirms DML operations as one of the three correct items.

Question 7hardmulti select

A developer is troubleshooting lifecycle hooks and rendering behavior in a Lightning Web Component. Which THREE statements are correct regarding LWC lifecycle execution order? (Choose THREE)

Trap 1: renderedCallback() only executes once during the lifetime of the…

`renderedCallback()` executes every time the component's template is re-rendered following data changes or reactive property updates, rather than running solely upon initial insertion into the DOM. Developers frequently confuse this hook with `connectedCallback()` because both handle component initialisation tasks, making it tempting to assume `renderedCallback()` acts as a one-time setup routine. It would be the correct choice when you need to perform DOM-dependent operations, third-party library integrations, or post-render styling adjustments that must run after every single re-render cycle.

Trap 2: renderedCallback() is invoked before connectedCallback().

Lifecycle execution order dictates that `connectedCallback()` always fires prior to `renderedCallback()`, as a component must first be inserted into the DOM before its template and any child components can finish rendering. This option is tempting because developers frequently conflate DOM attachment with visual presentation, assuming that rendering templates must precede component wiring. `renderedCallback()` would correctly be used if you needed to execute post-rendering logic, such as manipulating DOM elements or integrating with third-party JavaScript libraries, after the component has successfully mounted and rendered its template.

A
The constructor() is invoked before the component is inserted into the DOM.
The `constructor()` hook executes as the very first step in the component lifecycle, running entirely in memory prior to the component being inserted into the DOM. This satisfies the strict initialization constraint regarding DOM insertion order, ensuring that reactive properties and base state variables are properly instantiated before template evaluation and rendering occur in the browser.
B
renderedCallback() only executes once during the lifetime of the component.
Why it fails: `renderedCallback()` executes every time the component's template is re-rendered following data changes or reactive property updates, rather than running solely upon initial insertion into the DOM. Developers frequently confuse this hook with `connectedCallback()` because both handle component initialisation tasks, making it tempting to assume `renderedCallback()` acts as a one-time setup routine. It would be the correct choice when you need to perform DOM-dependent operations, third-party library integrations, or post-render styling adjustments that must run after every single re-render cycle.
C
connectedCallback() is invoked when the component is inserted into the DOM.
The `connectedCallback()` lifecycle hook executes precisely when a component is inserted into the DOM, satisfying the requirement to track component instantiation and template rendering order. During this phase, the component instance has been created in memory and its element is successfully appended to the document tree, enabling developers to perform initialisation tasks such as fetching data, adding event listeners, or interacting with parent elements that are now accessible in the DOM hierarchy.
D
disconnectedCallback() is invoked when the component is removed from the DOM.
The `disconnectedCallback()` lifecycle hook executes precisely when a Lightning Web Component instance is removed from the DOM, such as when toggled off via a conditional directive in a parent template. This satisfies the requirement to trace the correct teardown behavior within the component's execution lifecycle. Developers rely on this hook to perform essential cleanup tasks, such as removing event listeners or clearing timers, preventing memory leaks when the DOM element is unmounted.
E
renderedCallback() is invoked before connectedCallback().
Why it fails: Lifecycle execution order dictates that `connectedCallback()` always fires prior to `renderedCallback()`, as a component must first be inserted into the DOM before its template and any child components can finish rendering. This option is tempting because developers frequently conflate DOM attachment with visual presentation, assuming that rendering templates must precede component wiring. `renderedCallback()` would correctly be used if you needed to execute post-rendering logic, such as manipulating DOM elements or integrating with third-party JavaScript libraries, after the component has successfully mounted and rendered its template.

Question 8mediummulti select

Which TWO tools are effective for monitoring asynchronous Apex jobs?

Trap 1: Setup > Security

Setup > Security deals exclusively with platform access controls, user authentication, profile permissions, and sharing rules, making it entirely irrelevant for tracking the execution status or queue progress of asynchronous code. It appears plausible because administrators frequently navigate through the global Setup menu to configure platform monitoring tools, and security settings are routinely audited alongside system performance reviews. However, monitoring batch jobs, future methods, or queueable processes requires accessing the dedicated Apex Flex Queue or Apex Jobs page, where runtime states and error logs are recorded.

Trap 2: Setup > Debug Logs

Debug logs are tempting because developers frequently rely on them to trace execution paths and inspect governor limits during transaction failures. However, they fail for monitoring asynchronous jobs at scale because logs must be enabled per user or trace flag, capture a limited volume of log data, and are designed for real-time transactional debugging rather than tracking the status, batch counts, and queue metrics of hundreds of scheduled, batch, or queueable executions, for which the Apex Flex Queue and Apex Jobs pages are required.

Trap 3: Setup > Flows

Flows in Salesforce are designed to automate business processes and guide users through data collection via screens, meaning they lack any capability to track or query platform-level execution logs for background threads like batch classes or future methods. This option is tempting because developers frequently use Flows to orchestrate asynchronous actions such as scheduled paths or autolaunched triggers, making it a familiar administrative area for managing backend processes, yet they provide zero visibility into the actual queue status or error logs of standard asynchronous Apex jobs.

A
Setup > Security
Why it fails: Setup > Security deals exclusively with platform access controls, user authentication, profile permissions, and sharing rules, making it entirely irrelevant for tracking the execution status or queue progress of asynchronous code. It appears plausible because administrators frequently navigate through the global Setup menu to configure platform monitoring tools, and security settings are routinely audited alongside system performance reviews. However, monitoring batch jobs, future methods, or queueable processes requires accessing the dedicated Apex Flex Queue or Apex Jobs page, where runtime states and error logs are recorded.
B
Setup > Debug Logs
Why it fails: Debug logs are tempting because developers frequently rely on them to trace execution paths and inspect governor limits during transaction failures. However, they fail for monitoring asynchronous jobs at scale because logs must be enabled per user or trace flag, capture a limited volume of log data, and are designed for real-time transactional debugging rather than tracking the status, batch counts, and queue metrics of hundreds of scheduled, batch, or queueable executions, for which the Apex Flex Queue and Apex Jobs pages are required.
C
Setup > Apex Jobs
The Apex Jobs page in the Salesforce Setup menu provides a centralised queue interface that directly satisfies the requirement to monitor asynchronous Apex jobs. Administrators and developers can use this native tool to view the real-time status, execution time, method names, and error details of scheduled jobs, batch apex, future methods, and queueable apex. It tracks job lifecycles through states like Queued, Processing, Completed, and Failed, enabling rapid troubleshooting and operational oversight without requiring custom code or external logging infrastructure.
D
Querying the AsyncApexJob object
Querying the `AsyncApexJob` standard object via SOQL provides programmatic visibility into batch jobs, future methods, and queueable tasks, satisfying the requirement to monitor asynchronous Apex jobs. Developers can filter system data by status, job type, and error counts to track execution progress and handle exceptions efficiently without relying solely on manual UI navigation.
E
Setup > Flows
Why it fails: Flows in Salesforce are designed to automate business processes and guide users through data collection via screens, meaning they lack any capability to track or query platform-level execution logs for background threads like batch classes or future methods. This option is tempting because developers frequently use Flows to orchestrate asynchronous actions such as scheduled paths or autolaunched triggers, making it a familiar administrative area for managing backend processes, yet they provide zero visibility into the actual queue status or error logs of standard asynchronous Apex jobs.

Question 9hardmultiple choice

A developer is troubleshooting an issue where a Lightning Web Component is not picking up changes to the internal fields of an object property. What is the cause of this behavior in LWC reactivity?

Trap 1: Reactive properties must be declared as constants using const…

Declaring a property with `const` prevents reassignment of the variable reference, but it does not alter how the Lightning Web Component reactivity engine tracks nested object mutations. Developers often confuse variable immutability with reactive tracking, assuming that `const` ensures deep reactivity or guards against data corruption. Using `const` is the standard practice in JavaScript for defining local variables and component methods that will not be reassigned, ensuring code predictability without affecting whether deep object property changes trigger a re-render.

Trap 2: The component must be wrapped in an Aura container to enable deep…

Wrapping a Lightning Web Component in an Aura container does not alter the fundamental mutation tracking rules of the LWC framework, which only observes shallow property reassignments by default. This approach is tempting because Aura components traditionally rely on framework-managed data wrappers for change detection, leading developers to assume Aura can force reactivity downwards. However, it would only be the correct choice when integrating legacy Aura components into an existing workspace or leveraging Aura-specific event communication channels, rather than resolving modern data-binding issues within native component properties.

Trap 3: LWC does not support objects as reactive properties under any…

Objects are fully supported as reactive properties in Lightning Web Components, enabling developers to pass structured data sets into components. This option is tempting because developers often assume that simply declaring an object as `@track` or standard reactive properties makes all nested property modifications automatically traceable by the framework. It would be the correct choice if the component required only a complete replacement of the object reference itself rather than deep reactivity, because surface-level reassignment successfully triggers a re-render when the entire object reference changes.

A
Reactive properties must be declared as constants using const instead of let.
Why it fails: Declaring a property with `const` prevents reassignment of the variable reference, but it does not alter how the Lightning Web Component reactivity engine tracks nested object mutations. Developers often confuse variable immutability with reactive tracking, assuming that `const` ensures deep reactivity or guards against data corruption. Using `const` is the standard practice in JavaScript for defining local variables and component methods that will not be reassigned, ensuring code predictability without affecting whether deep object property changes trigger a re-render.
B
LWC reactivity is shallow, so nested object property mutations require creating a new object reference or using @track.
LWC's reactive engine tracks assignments to fields, not deep mutations, so changing a nested property leaves the original reference intact and no rerender triggers. Satisfying the stem's constraint, you must reassign a new object reference (or decorate the field with @track) for internal field changes to propagate.
C
The component must be wrapped in an Aura container to enable deep object tracking.
Why it fails: Wrapping a Lightning Web Component in an Aura container does not alter the fundamental mutation tracking rules of the LWC framework, which only observes shallow property reassignments by default. This approach is tempting because Aura components traditionally rely on framework-managed data wrappers for change detection, leading developers to assume Aura can force reactivity downwards. However, it would only be the correct choice when integrating legacy Aura components into an existing workspace or leveraging Aura-specific event communication channels, rather than resolving modern data-binding issues within native component properties.
D
LWC does not support objects as reactive properties under any circumstances.
Why it fails: Objects are fully supported as reactive properties in Lightning Web Components, enabling developers to pass structured data sets into components. This option is tempting because developers often assume that simply declaring an object as `@track` or standard reactive properties makes all nested property modifications automatically traceable by the framework. It would be the correct choice if the component required only a complete replacement of the object reference itself rather than deep reactivity, because surface-level reassignment successfully triggers a re-render when the entire object reference changes.

Question 10mediummultiple choice

What is the purpose of the 'Debug Log' Filter in the Developer Console?

Trap 1: To export logs.

Exporting debug logs for local analysis or archival purposes is handled via the "File" menu or API-based retrieval tools such as Salesforce CLI, rather than the Debug Log Filter panel. This option appears plausible because the term "filter" might suggest preparing a dataset for extraction or download. However, the filter panel is strictly designed to narrow down the real-time execution trace categories and log levels displayed within the Developer Console UI, making it tempting for users seeking to manage data volume before downloading when they actually need a file export mechanism instead.

Trap 2: To run tests.

Running tests in the Developer Console is handled via the separate Tests tab rather than the Debug Log filter panel. This choice is tempting because developers frequently generate and review logs immediately after executing unit tests to troubleshoot failures. However, the log filter is solely designed to restrict which trace flags and log levels are captured for specific users, classes, or triggers, whereas the Apex Test Execution panel manages the actual compilation, running, and validation of test suites.

Trap 3: To delete old logs.

Managing storage limits for debug logs requires clearing out obsolete records, which can be tempting to associate with filtering tools. However, filtering logs only controls which runtime events are captured and displayed in the Developer Console user interface based on user IDs, database triggers, or system levels; it does not purge stored records from the database. To remove historical logs and free up the 250 MB org allocation, developers must instead use the "Clear" button in the Developer Console or delete log records via the Setup menu.

A
To export logs.
Why it fails: Exporting debug logs for local analysis or archival purposes is handled via the "File" menu or API-based retrieval tools such as Salesforce CLI, rather than the Debug Log Filter panel. This option appears plausible because the term "filter" might suggest preparing a dataset for extraction or download. However, the filter panel is strictly designed to narrow down the real-time execution trace categories and log levels displayed within the Developer Console UI, making it tempting for users seeking to manage data volume before downloading when they actually need a file export mechanism instead.
B
To run tests.
Why it fails: Running tests in the Developer Console is handled via the separate Tests tab rather than the Debug Log filter panel. This choice is tempting because developers frequently generate and review logs immediately after executing unit tests to troubleshoot failures. However, the log filter is solely designed to restrict which trace flags and log levels are captured for specific users, classes, or triggers, whereas the Apex Test Execution panel manages the actual compilation, running, and validation of test suites.
C
To limit the types of events displayed.
Filtering debug logs in the Developer Console directly satisfies the requirement to limit the types of events displayed by applying specific logging levels to individual categories, such as Database, Workflow, and Callout. By adjusting these filters, developers can isolate extraneous trace flags and reduce noise within the log panel. This mechanism constrains the verbosity of system events captured during execution, ensuring that only relevant diagnostic data for targeted components is evaluated during troubleshooting.
D
To delete old logs.
Why it fails: Managing storage limits for debug logs requires clearing out obsolete records, which can be tempting to associate with filtering tools. However, filtering logs only controls which runtime events are captured and displayed in the Developer Console user interface based on user IDs, database triggers, or system levels; it does not purge stored records from the database. To remove historical logs and free up the 250 MB org allocation, developers must instead use the "Clear" button in the Developer Console or delete log records via the Setup menu.