Explanation

Lightning layout uses a 12-column responsive grid with a mobile-first design.
The size attribute establishes the default width for smaller devices.
Setting size="12" makes each layout item occupy the full width on mobile devices.
The medium-device-size="6" setting changes each item to half the available width at the medium breakpoint.
Therefore, two items can appear side by side on tablet and desktop screens while remaining stacked on smaller screens.

🟢 C. Set size="12" medium-device-size="6"
The size="12" setting makes each layout item span all 12 columns by default, which places items in a single column on small screens. The medium-device-size="6" setting changes each item to span six columns at the medium breakpoint. Since two six-column items fill the 12-column grid, the component displays two columns on tablet and desktop-sized screens. This combination directly provides the required responsive behavior.

🔴 A. Set size="12" tablet-device-size="6"
tablet-device-size is not a valid lightning-layout-item sizing attribute. Salesforce provides responsive attributes such as small-device-size, medium-device-size, and large-device-size. Therefore, although the intended sizing pattern resembles the requirement, this option uses an unsupported attribute and cannot provide the requested responsive layout.

🔴 B. Set size="6" small-device-size="12"
This configuration does not establish the required mobile-first behavior. The default size="6" makes the item span half the grid at smaller widths, while small-device-size="12" changes the sizing at the small breakpoint. It therefore does not correctly produce one column on mobile and two columns on medium and larger screens.

🔴 D. Set size="12" mobile-device-size="12"
mobile-device-size is not a supported lightning-layout-item attribute. The Lightning layout component uses defined breakpoint attributes such as small-device-size and medium-device-size. Additionally, setting both values to 12 would not create the required two-column layout on tablets and desktops because no six-column medium setting is provided.

Reference
⇒ Layout Item | Salesforce Developers — Confirms the supported responsive sizing attributes and explains how size and medium-device-size control layout widths across device sizes.

Explanation

This question tests understanding of how to centralize reusable business logic across different entry points. The requirement is to validate email addresses against a list of blocked domains stored in a custom object, for both Contact records (saved via standard UI/API) and Survey_Response__c records (saved via a custom Visualforce page). The optimal solution must avoid duplicating the validation logic in multiple places while still executing from both entry points.

✅ B. Implement the logic in a helper class that is called by an Apex trigger on Contact and from the custom Visualforce page controller.
A helper class centralizes the blocked-domain validation logic in one location. The Contact trigger calls the helper during before insert and before update events, ensuring validation for all Contact saves regardless of entry point. The Visualforce page controller also calls the same helper before saving Survey_Response__c records. This approach satisfies the "do not repeat logic" requirement while covering both scenarios with a single, maintainable implementation.

❌ A. Implement the logic in validation rules on the Contact and the Survey_Response__c objects.
Validation rules cannot query the blocked domains custom object to check if an email's domain exists in the list. Salesforce formula functions operate within a single record context and cannot perform the cross-object lookup required. This approach is technically impossible without a formula field that pre-aggregates the blocked domains, which adds unnecessary complexity.

❌ C. Implement the logic in an Apex trigger on Contact and also implement the logic within the custom Visualforce page controller.
This option requires writing and maintaining the same validation logic in two separate places. If the blocked domain list structure changes or the validation rules are updated, both implementations must be modified in sync. This directly violates the requirement to prevent the business logic from being repeated in more than one place.

Reference
🔗 Salesforce Developer Documentation – Triggers
→ confirms that trigger logic should be delegated to helper classes to promote reuse and separation of concerns.

Explanation

This question tests understanding of Apex code reuse principles, specifically how to centralize business logic so it can be invoked from multiple contexts, such as a trigger and a Lightning web component's Apex controller, without duplicating logic or hardcoding values.

✅ C. Create a helper class that fetches the high value opportunities.
Moving the high-value opportunity logic into a dedicated helper class allows both the trigger and an Apex controller exposed to the Lightning web component to call the same method. This centralizes the business logic in one reusable location instead of duplicating it across the trigger and any new component-facing code.

✅ D. Use custom metadata to hold the high value amount.
Storing the high-value threshold amount in a custom metadata type instead of hardcoding it keeps the qualifying criteria centralized and configurable. Both the trigger's helper class and any other consuming code reference the same custom metadata record, avoiding duplicated or inconsistent threshold values across the org.

❌ A. Call the trigger from the Lightning web component.
Triggers cannot be directly invoked from client-side code or even from Apex; they only execute automatically in response to DML operations on their associated object. This approach is not technically possible and does not solve the reuse requirement.

❌ B. Leave the business logic code inside the trigger for efficiency.
Keeping the logic solely inside the trigger means it cannot be called by the Lightning web component's Apex controller, forcing the same logic to be rewritten elsewhere. This directly contradicts the requirement to avoid repeating business logic in more than one place.

🔧 Reference
🔗 Apex Design Patterns and Best Practices – Salesforce Developer Documentation → confirms centralizing reusable business logic in helper classes avoids duplication across triggers and other invoking contexts.

Explanation

This question tests Salesforce’s declarative record-access model for users whose visibility follows a management structure. A role hierarchy provides upward access to records owned by users in lower roles. By placing support agents below support managers, agents retain access to their own and subordinate-role Cases, while managers inherit access to all Cases in the service hierarchy.

✅ Correct Option:

✅ C. Role hierarchy
The role hierarchy automatically grants users access to records owned by, or shared with, users in roles below them. Configure support managers at the top of the service role branch, with support-agent roles underneath. Managers then receive visibility into all agent-owned Cases. An agent can access Cases they own and Cases owned by users assigned to subordinate roles, but not Cases owned by roles above or parallel to them.

❌ Incorrect Options:

❌ A. Sharing sets
Sharing sets are intended primarily for external users in Experience Cloud. They grant access based on an external user’s Account or Contact association, rather than ownership relationships in an internal role hierarchy. They do not provide the required manager-to-subordinate Case visibility model.

❌ B. Apex managed sharing
Apex managed sharing can programmatically create record-sharing entries, but it is unnecessary for a standard hierarchical access requirement. The role hierarchy natively grants upward access based on ownership and role placement. Declarative configuration is simpler, easier to maintain, and aligns directly with the stated visibility requirement.

❌ D. Criteria-based sharing rules
Criteria-based sharing rules share records when field values meet defined criteria, such as Case Status, Priority, or Region. They do not dynamically grant access based on the owner’s position relative to another user in the role hierarchy. The requirement is ownership-and-role based, which the role hierarchy handles automatically.

🔧 Reference:
→ Controlling Access Using the Role Hierarchy — Salesforce Help confirms that users higher in the hierarchy automatically access records owned by, or shared with, users in lower roles.

→ Create a User Role — Salesforce Help confirms that users can view, edit, and report on records owned by or shared with users in roles below them.

Explanation

This question tests Apex transaction control when two records must be created as one logical unit. The Account should exist only if its required Contact is also created successfully. A savepoint preserves the database state before DML occurs, while a rollback reverses the Account insert if Contact insertion throws an exception.

✅ Correct Option:

✅ A. Use setSavePoint() and rollback() with a try-catch block.
Create a savepoint before inserting the Account, then insert the Account and its related Contact in a try block. If Contact creation fails, catch the DmlException and call Database.rollback(savepoint). The rollback reverses DML performed after the savepoint, including the successful Account insertion, preserving the requirement that an Account must never be created without its Contact.

❌ Incorrect Options:

❌ B. Use a Database Savepoint method with a try-catch block.
This option is incomplete because creating a savepoint alone does not reverse database changes. The developer must explicitly call Database.rollback(savepoint) after the Contact insertion fails. Option A provides both required transaction-control operations and correctly describes their use within error handling.

❌ C. Use the Database.Insert method with allOrNone set to false.
Setting allOrNone to false permits partial success in a DML operation. It could allow the Account to be inserted even if the Contact fails, directly violating the business rule. The requirement needs atomic behavior: both records succeed, or the transaction restores the prior state.

❌ D. Use the Database.Delete method if the Contact insertion fails.
Deleting the Account after a failed Contact insert is less reliable than rolling back the transaction. It requires additional DML, may introduce new errors or trigger side effects, and does not restore all transaction changes consistently. Database.rollback() is designed specifically to undo work performed after a savepoint.

🔧 Reference:
→ Transaction Control confirms that Database.setSavepoint() marks a transaction state and Database.rollback() discards DML performed afterward, restoring the database to that saved state.

→ Apex DML Operations confirms that DML exceptions can be handled with try and catch blocks.