CRT-450 Practice Questions

The provided trigger code is not "bulkified," meaning it cannot handle multiple records in a single transaction. The code places a SOQL query and a DML insert statement inside a for loop. When Data Loader processes 179 records, the trigger attempts to execute 179 separate SOQL queries and up to 179 DML statements. This exceeds the synchronous governor limits of 100 SOQL queries and 150 DML statements per transaction, causing a System.LimitException.

To fix this, the code must be refactored to perform all data retrieval and data modification operations outside of any loops. This involves querying for all existing opportunities in a single query before the loop and inserting all new opportunities in a single DML call after the loop.

1. Salesforce Apex Developer Guide

"Bulk Triggers": This guide explicitly states

"To write scalable triggers

you must ensure that your code is 'bulk-safe'. This means that your trigger logic should handle multiple records at once and not just a single record... A common mistake is that SOQL queries or DML statements are placed inside a for loop." This directly supports moving both the query (A) and the DML (C) outside the loop.

2. Salesforce Apex Developer Guide

"Execution Governors and Limits": This document details the specific transaction limits

including "Total number of SOQL queries issued: 100" and "Total number of DML statements issued: 150". The described failure with 179 records directly correlates to exceeding these limits.

3. Trailhead

"Apex Triggers" Module

"Bulk Apex Triggers" Unit: This educational unit provides canonical examples of how to avoid SOQL queries and DML statements inside loops. The recommended pattern is to: 1. Create a collection of IDs from the trigger context variables. 2. Perform a single SOQL query using this collection. 3. Iterate through the trigger records

process logic

and add new records to a list. 4. Perform a single DML operation on the list of new records after the loop. This reinforces the correctness of options A and C.

Communication from a parent Lightning Web Component (LWC) to a nested child LWC is accomplished through two primary mechanisms. The first is declaratively, by setting a public property on the child component. The child exposes a property using the @api decorator, which the parent can then set in its markup. The second is imperatively, where the parent component gets a reference to the child and calls a public method, also exposed via the @api decorator, passing the string value as an argument. Both are standard, documented patterns for parent-to-child data flow.

1. Salesforce Lightning Web Components Developer Guide: For passing data via public properties. The guide states

"To expose a public property

decorate a field with @api. Public properties are reactive. If the value of a reactive property changes

the component’s template rerenders."

Source: Lightning Web Components Developer Guide

"Pass Data from Parent to Child with Public Properties".

2. Salesforce Lightning Web Components Developer Guide: For invoking methods on a child. The guide explains

"To expose a public method

decorate it with @api. Public methods are part of a component's public API. To communicate down the containment hierarchy

a parent component can call a public method on a child component."

Source: Lightning Web Components Developer Guide

"Call Methods on Child Components".

3. Salesforce Lightning Web Components Developer Guide: To differentiate from child-to-parent communication. The guide specifies

"A component dispatches an event to send data to a component in its container hierarchy. The CustomEvent interface lets you create your own events." This confirms events flow upwards.

Source: Lightning Web Components Developer Guide

"Communicate with Events".

To implement a custom SOAP web service in Apex, the class must be declared with the global access modifier. Methods that are intended to be exposed to external applications via the WSDL must be declared as both global and static, and they must use the webservice keyword.

Helper methods, which are for internal use within the class and should not be exposed in the WSDL, must be defined without the webservice keyword. Option D correctly follows this structure by defining a global class, a webservice global static method for external access, and a public helper method that remains internal to the Salesforce organization.

1. Salesforce Apex Developer Guide

"Apex Web Services":

Section: Defining Apex Web Service Methods: "To expose an Apex method as a web service

the method must be global static and be part of a global class. The webservice keyword must be used for any method that should be exposed." This directly supports why Option D is correct and why options A and C are incorrect.

Section: webservice Keyword: This section details the syntax and requirements

reinforcing that a webservice method must be global and static within a global class for SOAP services. This confirms why Option B is incorrect

as it lacks the necessary keyword for exposure.

2. Trailhead by Salesforce

"Apex Integration Services" Module:

Unit: Apex Web Services: "To expose an Apex class and methods so that external applications can access your code and your application

you must use the webservice and global keywords." This module provides examples that align with the structure shown in Option D

where the class is global and the exposed method is webservice static. It clarifies that methods without the webservice keyword are not exposed.

The officially sanctioned method for displaying a Lightning Web Component (LWC) within the Salesforce Classic UI is to use the Lightning Out JavaScript library. This technology is specifically designed to surface Lightning components (both Aura and LWC) in an external container, such as a Visualforce page. The process involves referencing a Lightning dependency app from the Visualforce page and then using the $Lightning.use() and $Lightning.createComponent() JavaScript functions to dynamically create and display the component within the page. This Visualforce page can then be embedded into a standard page layout in Classic.

1. Lightning Web Components Developer Guide: The section "Use Lightning Web Components in Visualforce Pages" details the process. It explicitly states

"To use a Lightning web component in a Visualforce page

embed it in a Lightning Aura component. Then

use Lightning Out to surface the Aura component in Visualforce." This confirms that Lightning Out is the core technology (supporting B) and that an Aura wrapper is a necessary step (making D a partial but less complete answer).

Source: Salesforce

Lightning Web Components Developer Guide

"Use Lightning Web Components in Visualforce Pages".

2. Lightning Aura Components Developer Guide: The "Communicate with a Visualforce Page" section describes the use of $Lightning.createComponent(). It states

"Dynamically create a component on a page by calling $Lightning.createComponent() after the Lightning Out app has loaded." This highlights the central role of the Lightning Out JavaScript library.

Source: Salesforce

Lightning Aura Components Developer Guide

"Lightning Out Dependencies"

"Communicate with a Visualforce Page".

3. Visualforce Developer Guide: The documentation on tag confirms its purpose: "Use this component to include Lightning Components for Visualforce in a Visualforce page." This tag is the entry point for using the Lightning Out library within Visualforce.

Source: Salesforce

Visualforce Developer Guide

"Component Reference"

.

The most appropriate and direct method to handle exceptions gracefully in Apex is by using a try/catch block. Placing the DML statement (insert accts;) inside a try block allows the program to attempt the operation. If a DmlException occurs—as it will in this scenario due to the missing required Name field—the catch block will execute. This prevents the program from terminating abruptly and allows the developer to implement logic to log the error, display a user-friendly message, or attempt a recovery action, thus ensuring the exception is handled gracefully.

1. Salesforce Apex Developer Guide

"Exception Handling": The guide explicitly states

"To handle exceptions

use the try-catch-finally construct... The try statement identifies a block of code in which an exception can occur. The catch statement identifies a block of code that can handle a particular type of exception." This directly supports using try/catch as the correct handling mechanism.

2. Salesforce Apex Developer Guide

"DML Statements": This section details how DML statements like insert operate. It explains that if an error occurs in any record during a bulk operation

a DmlException is thrown

and the entire operation is rolled back by default. This confirms the cause of the problem in the scenario.

3. Trailhead

"Apex Exception Handling" Module

"Handle Exceptions in Apex" Unit: This official Salesforce training material teaches that "A try-catch block is the most common way to handle exceptions... When your code throws an exception

you can write code to gracefully recover from it." This reinforces that try/catch is the standard and expected solution.

The Apex syntax sObject variable = [SOQLquery]; is specifically designed to assign a single record to an sObject variable. If the SOQL query returns more than one record, the Apex runtime environment throws a System.QueryException with the error message "List has more than 1 row for assignment". If this exception is not handled within a try-catch block, it is considered an unhandled exception, which immediately terminates the transaction and prevents further code execution.

1. Salesforce Apex Developer Guide

"SOQL and SOSL Queries": The guide explains that assigning a query result to a single sObject variable is only valid if the query returns exactly one record. It states

"If the query returns no records

a System.QueryException is thrown... Likewise

if the query returns more than one record

a System.QueryException is thrown."

Reference: Salesforce Apex Developer Guide

Chapter 3: "Database & DML"

Section: "Writing SOQL Queries".

2. Salesforce Apex Developer Guide

"Exception Class and Built-In Exceptions": This section documents the System.QueryException. It is described as an exception that is thrown for errors that occur during SOQL or SOSL query execution

including when a query that is expected to return a single row returns multiple rows.

Reference: Salesforce Apex Developer Guide

Appendix: "Apex Language Reference"

Section: "Exception Class and Built-In Exceptions".

The Apex code executes two distinct DML (Data Manipulation Language) operations within a single transaction.

1. The first insert accts; statement successfully inserts 150 Account records into the database. This operation completes without error.

2. The second insert accts2; statement attempts to insert 100 new Account records. However, the names of these records (e.g., 'Account 0', 'Account 1') duplicate those created in the first step. This will cause a DmlException, assuming a standard duplicate rule or unique index is in place on the Account Name.

3. The try...catch block successfully catches this DmlException. Because the exception is caught, it does not propagate and does not cause the entire transaction to roll back.

Therefore, the results of the first successful DML operation are committed, while the second DML operation fails and its changes are discarded. The net result is 150 inserted records.

1. Salesforce Apex Developer Guide

"Transaction Control": This guide explains that while a transaction is a single unit

try...catch blocks can be used to handle exceptions from DML operations to prevent the entire transaction from being rolled back. The failure of one DML statement within a try block does not roll back a preceding

successful DML statement.

2. Salesforce Apex Developer Guide

"Exception Handling"

section "Using try-catch-finally Statements": This section explicitly states

"If an exception is not caught

it causes the transaction to be rolled back." The code in the question demonstrates the opposite: the exception is caught

thereby preventing the rollback of the initial 150 records.

3. Salesforce Apex Developer Guide

"Database & DML"

section "Processing Records with DML": This section details how DML statements like insert operate. The failure of the second insert is a runtime DML exception

which is handled by the catch block as described in the exception handling documentation.

Apex triggers are designed to execute in response to Data Manipulation Language (DML) operations such as insert, update, or upsert. Importing data using the Data Loader, whether with the SOAP API or the Bulk API, directly performs these DML operations on records. By default, these operations invoke the standard Salesforce order of execution, which includes firing any before triggers on the target object (in this case, Accounts) for each batch of records processed. This is a fundamental and expected behavior of data loading via the API.

1. Apex Developer Guide

"Triggers": "A trigger is Apex code that executes before or after specific data manipulation language (DML) events occur

such as before object records are inserted into the database

or after records have been deleted." This establishes that DML operations

like those performed by Data Loader (Option C)

are the direct cause of triggers firing.

2. Apex Developer Guide

"Triggers and Order of Execution": This guide details the sequence of events during a save operation initiated by any means (including an API call from Data Loader)

confirming that before triggers are executed early in the process.

3. Bulk API 2.0 and Bulk API Developer Guide

"Introduction to Bulk API 2.0": The guide explains that the Bulk API is used to "query

queryAll

insert

update

upsert

or delete a large number of records." These are all DML operations that invoke the standard execution order

including triggers.

4. Salesforce Help

"Mass Update Addresses": "The Mass Update Addresses tool doesn't trigger workflow rules

validation rules

or Apex triggers." This directly invalidates Option B.

5. Salesforce Help

"Considerations for Converting Leads": "When you convert a lead... Apex triggers are fired." This confirms the action in Option D does fire triggers

but as explained

Option C is the more direct and fundamental answer.

The business requirement is for multiple Account records to share a single Global Address record. This describes a many-to-one relationship, where Account is the "many" side and Global Address is the "one" side. To model this, the relationship field must be created on the "many" object (Account) and point to the "one" object (Global Address). A lookup relationship is the correct choice as it creates this association. A master-detail relationship is not possible because a standard object (Account) cannot be on the detail side of a relationship with a custom object (Global Address).

1. Salesforce Help

Object Relationships Overview: This document explains that to create a one-to-many relationship

you create a lookup or master-detail field on the object that is intended to be the "many" side. In this scenario

Account is the "many" side.

2. Salesforce Help

Create a Lookup Relationship: "You can use lookup fields to create one-to-many relationships... For example

you can create a one-to-many relationship between the account and case objects by creating a lookup field on the case object that looks up to the account object." This confirms the field placement on the "many" side (Account in our case).

3. Salesforce Help

Considerations for Relationships: Under the "Master-Detail Relationship" section

the documentation explicitly states: "You can create master-detail relationships between custom objects or between a custom object and a standard object. However

the standard object cannot be on the detail side of a relationship with a custom object." This rule directly invalidates option D.

4. Salesforce Developer Documentation

Relationships Among Objects: "In a one-to-many relationship

a single object is the “one” side

and many other objects are the “many” side... You can create this relationship by adding a lookup or master-detail relationship field to the objects on the “many” side." This reinforces that the field must be on the Account object.

The most optimal and robust method to ensure a field is always populated is by marking it as "Required" on the field's definition. This declarative setting enforces the rule at the data model level, guaranteeing that no record can be created or updated without a value in this field, regardless of the entry point (e.g., user interface, API, Data Loader). This approach is superior to UI-level requirements or programmatic solutions for universal data integrity.

1. Salesforce Help

"Custom Field Attributes": This document details the properties of custom fields. For the "Required" attribute

it states

"Always requires a value in this field in all records... Universally required fields are automatically added to all page layouts." This confirms that making a field required at the definition level provides universal enforcement.

2. Salesforce Help

"Considerations for Page Layouts and Field-Level Security": This source differentiates between UI-level and data-level requirements. It clarifies

"If you make a field required on a page layout

it’s only required when users edit records with that page layout." This directly explains why option C is insufficient for the stated requirement.

3. Trailhead

"Data Modeling" Module

"Customize a Salesforce Object" Unit: This educational module explains that setting the "Required" property during field creation enforces data integrity across the entire application. It states

"To make sure users always fill in a field

you can make it required... This means a user can’t save a record without filling in that field." This supports the choice of option D as the standard

optimal method.