Explanation:

This question tests the understanding of Pricebook sharing and its specific terminology, which is distinct from standard and custom object sharing. The business requirement is for sales agents to be able to see products and prices and create opportunities.

Why A is Correct: The Organization-Wide Default (OWD) for Pricebooks has three specific settings: None, Read Only, and Use. "Public Read-Only" is the label for the Read Only setting in the user interface.
⇒ A setting of Read Only (Public Read-Only) allows all users to view pricebooks, which is necessary to see products and prices.
⇒ Crucially, this setting also allows users to use those pricebooks when creating opportunities. When adding products to an opportunity, a user must select a pricebook. The "Use" permission is implicitly granted by the "Read Only" OWD setting for this purpose.

Why B is Incorrect: "View" is not a valid OWD setting for any object in Salesforce, including Pricebooks. The standard OWD settings are Private, Public Read Only, and Public Read/Write. This option is a distractor.

Why C is Incorrect: "Use" is a valid OWD setting for Pricebooks. However, setting the OWD to Use is overly permissive. It allows users to not only see and use pricebooks but also to create, edit, and delete them. The business requirement only states that sales agents need to access the existing products and prices, not to administer or modify the pricebooks themselves. Granting "Use" access violates the principle of least privilege.

Reference:
Salesforce Help: Control Access to Price Books - "The organization-wide default sharing settings for price books determine the baseline level of access that users have to price books. You can set the baseline to None, Read Only, or Use."
⇒ "Read Only—Users can view but not edit price books. Users can also use the price books to add products to opportunities."
⇒ "Use—Users can view, edit, and use price books. Users can also create new price books."

Explanation:

The System.runAs() method in Salesforce test classes is used to test code under the record sharing context of a specific user. It's a critical tool for ensuring your application's sharing and visibility rules are enforced correctly.

Correct Option:

A. Enforcement of a user's record sharing
By default, all Apex code, including test methods, runs in system mode. In system mode, the code ignores the permissions and record sharing settings of the current user. The System.runAs() method allows a developer to temporarily change the user context for a block of code within a test method. This makes the code respect the sharing rules, such as organization-wide defaults, sharing rules, and role hierarchy, of the user specified in the runAs() method. This is essential for writing realistic and robust tests that mimic how different users will interact with data in a production environment.
Example: If you have a sharing rule that grants a "Sales" public group read-only access to all "Account" records, you can use System.runAs() with a test user from that group to verify that they can indeed read the records but cannot update them.

Incorrect Options:

B. Enforcement of a user's Field Level Security: The runAs() method does not enforce Field Level Security (FLS) or object permissions. To test for FLS, you must use other methods, like WITH SECURITY_ENFORCED in SOQL queries or stripInaccessible methods from the System or Security classes. The code inside runAs() still operates in system mode concerning FLS and object permissions.

C. Enforcement of a user's permissions: Similar to FLS, runAs() does not enforce a user's object-level or field-level permissions. Its sole purpose is to test data access based on record sharing.

Reference:
For more information, consult the official Salesforce documentation on the System.runAs() method in the Apex Developer Guide: Using the runAs Method.

Explanation:

➡️ Platform Encryption is managed using the Encryption Policy in Salesforce Setup.
➡️ The architect must update the encryption policy to include the new fields (Billing Street, Billing City, Phone).
➡️ Once enabled, all new data entered into those fields is encrypted automatically.
➡️ However, existing data already stored in Salesforce is not retroactively encrypted. To encrypt existing values, Salesforce provides a process called a backfill. You need to contact Salesforce Support to perform this operation.

Why not the other options?

A. Classic Encryption: Wrong, because Classic Encryption only works for a small set of standard fields (like password fields, credit card fields). It’s not extensible like Shield. Plus, this org already uses Shield.

B. Use Encryption Policy and wait for an email: Wrong. Just enabling encryption in the policy won’t automatically encrypt existing values. The backfill process is required.

Salesforce Reference:
Encrypt Fields with Shield Platform Encryption
“When you enable encryption for a field, new data entered is automatically encrypted. To encrypt existing data, contact Salesforce to perform a backfill.”

✅ Final Answer: C

Explanation:

Universal Containers has set the Opportunity object’s organization-wide default (OWD) to Private, meaning records are only accessible to the record owner and users above them in the role hierarchy, unless sharing rules or other mechanisms grant additional access. They created a public group with certain sales engineers and a sharing rule to grant access to specific Opportunity records. Let’s analyze the impact of these settings and why each option is correct or incorrect, keeping it clear and detailed for someone learning Salesforce.

A. Sales engineers and their managers in the Role Hierarchy will also have access to these records.
This is correct. The sharing rule grants access to the sales engineers in the public group for the specified Opportunity records. Additionally, Salesforce’s role hierarchy automatically gives access to users above the record owner or those granted access via sharing rules. This means managers higher in the role hierarchy than the sales engineers in the public group will also have access to these Opportunities.
For example, if the sharing rule grants Read or Edit access to Opportunities for the public group, and a sales engineer in that group has a manager above them in the role hierarchy, the manager inherits that access. This is how Salesforce’s sharing model works with a Private OWD.

Why it’s the impact: The sharing rule extends access to the public group, and the role hierarchy extends it further to managers, making this the direct result of the described settings.

B. Subordinates of managers who have sales engineers in the public group will also have access to these records.
This is incorrect. In Salesforce, the role hierarchy grants access upward, not downward. Subordinates (users lower in the role hierarchy) do not automatically gain access to records that their managers can see unless explicitly granted through sharing rules, manual sharing, or other mechanisms. Since the sharing rule only applies to the public group (sales engineers), subordinates of managers not in the group won’t get access.
For example, if a manager has access because their subordinate (a sales engineer) is in the public group, the manager’s other subordinates lower in the hierarchy won’t inherit that access.

C. Other sales engineers who are in the same Role Hierarchy as the sales engineers of the public group will also have access to these records.
This is incorrect. The sharing rule grants access only to the sales engineers in the specified public group, not to all sales engineers in the same role or role hierarchy. Users in the same role or nearby roles don’t automatically share access unless they’re part of the same public group or another sharing rule applies. The role hierarchy only extends access upward to managers, not sideways to peers or others in similar roles.
For example, if Sales Engineer A is in the public group and gets access via the sharing rule, Sales Engineer B in the same role but not in the public group won’t get access.

Why Option A is the Impact?
The sharing rule gives the sales engineers in the public group access to the specified Opportunity records, despite the Private OWD. Because of Salesforce’s role hierarchy, managers above these sales engineers automatically inherit the same access (e.g., Read or Edit) to those records. This is the primary impact of the sharing settings described. Options B and C incorrectly suggest access extends to subordinates or peers, which doesn’t align with how sharing rules and the role hierarchy work.

Additional Details:
Private OWD: With Opportunities set to Private, only the record owner (e.g., the sales rep who created the Opportunity) and users above them in the role hierarchy have access by default. The sharing rule adds access for the public group.
Public Group: This is a collection of users (in this case, specific sales engineers) who can be granted access via sharing rules. It’s a flexible way to manage access for a group without relying on roles alone.
Sharing Rule: This rule likely specifies criteria (e.g., Opportunities in complex deals) and grants access (Read or Read/Write) to the public group. The role hierarchy then extends this access to managers above the group members.
Role Hierarchy: Managers higher in the hierarchy (e.g., Sales Manager over Sales Engineer) get the same or greater access to records their subordinates can see, including those shared via sharing rules.
Security Consideration: The team should ensure the sharing rule’s criteria are specific (e.g., only complex deals) to avoid over-sharing sensitive Opportunity data.

Reference:
Salesforce Help: Organization-Wide Defaults
Salesforce Help: Sharing Rules
Salesforce Help: Role Hierarchy

Explanation:

In Salesforce, when a single user owns too many records (more than ~10,000), it creates ownership skew (also called “data skew”).
When this happens, performance degrades because:
✅ Salesforce must recalculate sharing for a massive number of records every time ownership or sharing rules change.
✅ Lock contention issues can occur, especially when multiple transactions try to update records owned by the same user.
✅ Since each donations rep owns 50,000+ Accounts, this is clearly Account ownership data skew.

Why not the other options?

B. The donations reps’ access is wrong: Incorrect. Access model may affect usability but doesn’t directly cause system performance degradation at this scale.

C. Salesforce sharing recalculation kicked off: Partially true — recalculations do happen, but the root cause here is ownership data skew. That’s the recognized exam answer.

Salesforce Reference:
Make SOQL query selective
“When a large number of records are associated to a single owner or a single parent, performance issues such as record locking or sharing recalculations may occur. This is referred to as ownership skew or data skew.”

✅ Final Answer: A. There is an Account ownership data skew problem.

Explanation:

Universal Containers (UC) has a team that needs access to Invoice records (a custom object with a Private organization-wide default, or OWD). The OWD being Private means only the record owner and users above them in the role hierarchy have access, unless additional sharing rules or mechanisms like Apex managed sharing are used. The architect recommends Apex managed sharing to handle complex access rules for the fraud analysis team. Let’s evaluate each option to find the best recommendation for a developer implementing this solution, keeping it clear and detailed for someone learning Salesforce.

A. Use "Without Sharing" keyword to make sure record visibility will be considered.
This is incorrect. The without sharing keyword in Apex means the code runs in system mode, ignoring the user’s sharing rules and role hierarchy. This would allow the code to access all Invoice records, regardless of the Private OWD or other sharing settings, which could lead to over-sharing sensitive data.
In this case, UC needs to enforce complex sharing rules for the fraud analysis team, so Apex managed sharing should respect user permissions and only grant access to specific records as defined. Using without sharing would bypass these controls, making it the opposite of what’s needed.
For example, if the Apex code creates share records to give the fraud team access to certain Invoices, without sharing might expose records the team shouldn’t see, violating the Private OWD.

B. Use "With Sharing" keyword to enforce Field-Level Security.
This is incorrect. The with sharing keyword in Apex ensures the code respects the user’s sharing rules and role hierarchy, meaning it only accesses records the running user is allowed to see based on the OWD, sharing rules, or manual sharing. However, it does not enforce Field-Level Security (FLS). FLS is controlled separately using methods like Schema.sObjectType.

Explanation:

This question tests the understanding of cross-hierarchy sharing. The Role Hierarchy grants access downwards (managers see their subordinates' records), but it does not grant access across parallel branches of the hierarchy. A U.S. Sales Manager and a Canadian Sales Manager are in sibling roles; neither is above the other, so the hierarchy provides no access between them.

Why A is Correct: A sharing rule is the standard, declarative tool designed specifically for this purpose.
→ An owner-based sharing rule can be configured to share records owned by members of one role (e.g., the "Canadian Sales Manager" role) to another role or group (e.g., the "US Sales Manager" role).
→ The rule can be further refined with criteria (e.g., Segment = 'Enterprise') to ensure it only shares the specific accounts required by the business case. This meets the requirement precisely and efficiently.

Why B is Incorrect: This approach misunderstands how sharing works. You cannot grant access to a collection of records (the public group of accounts) via a permission set. Permission sets grant permissions to users (e.g., object permissions, field permissions, system permissions). They cannot be used to grant record-level access to a specific set of records. Record access is controlled through the sharing model (sharing rules, teams, manual share, etc.).

Why C is Incorrect: Flattening the role hierarchy by putting all managers in the same role is a poor architectural solution.
→ It destroys the logical organization of the hierarchy based on countries.
→ It would over-share dramatically. A U.S. Sales Manager would get access to all accounts owned by all Canadian sales users (reps and managers), not just the managers' accounts of the same segment. This violates data security and the principle of least privilege.
→ It is not a scalable solution; adding a new country would require constantly re-architecting the role hierarchy.

Reference:
Salesforce Help: Sharing Rules - "Use sharing rules to extend sharing access to users in public groups, roles, or territories. Sharing rules give additional users access to records they don’t own or can’t see normally."
Platform Sharing and Visibility Architect Exam Guide: This scenario directly addresses the objective "Given a scenario, design a sharing strategy that uses sharing rules." It highlights a classic limitation of the role hierarchy (no lateral sharing) and the use of sharing rules to solve it.

Explanation:

Summary:
To allow field consultants to capture images on their mobile devices while keeping the standard "Edit" page for desktop users, the architect should recommend using a Lightning Component to override the "Edit" action for the mobile form factor only. This approach minimizes customization and avoids disrupting the existing user experience for customer service representatives.

Correct Option:

A. Use Lightning Component as an override for "Edit" action on mobile view allowing image capture feature. No Change required for desktop users.
Salesforce Lightning Experience allows for different overrides for actions based on the form factor—specifically, a desktop view and a mobile view. By creating a custom Lightning Component that handles image capture and then setting it as an override for the mobile "Edit" action on the Case object, the architect can achieve the requirement without any changes to the desktop experience. The customer service representatives will continue to see and use the standard "Edit" page they are accustomed to. This method is the most direct and efficient way to meet the business and technical constraints of the problem.

Incorrect Options:

B. Use Lightning Component as an override for "Edit" action on lightning experience allowing image capture feature. Detect the form factor of the device and redirect the user to the default not-overridden view.
Reasoning: This approach is unnecessarily complex. Overriding the "Edit" action for the entire Lightning Experience and then trying to redirect desktop users back to the standard page introduces unnecessary code and potential points of failure. The platform already provides a simpler, built-in solution for handling form factor-specific overrides, making this approach less efficient and more difficult to maintain.

C. Create a separate button “Edit in Mobile”, which opens a custom lightning component that will allow field consultants to add an image. No change required for desktop users.
Reasoning: While this option would work, it is not the most user-friendly or elegant solution. It introduces a new button for a standard action ("Edit"), which can confuse users and lead to inconsistent user interface behavior. The goal is to provide a seamless experience, and overriding the existing "Edit" action is a cleaner solution that leverages the platform's native capabilities without adding clutter to the page layout.

Explanation:

When Universal Containers plans to reorganize roles and reassign a large number of account owners, it can trigger massive sharing recalculations which can negatively impact system performance. To manage this efficiently, Deferred Sharing Recalculation is the right solution. It allows administrators to temporarily suspend automatic recalculations of record sharing when changes are made in roles, territories, or ownership. After completing all changes, the recalculations can then be run in bulk, reducing the performance impact and avoiding timeouts or incomplete recalculations. Options like Divisions and Skinny Tables are not relevant in this context—Divisions are used for reporting segmentation and Skinny Tables improve query performance but don’t help with sharing recalculations. Hence, Deferred Sharing Recalculation ensures scalability and performance during such organizational changes.

Explanation:

Salesforce Content Deliveries allow users to share files externally with password protection, meeting the CISO’s security requirement. Option A (AppExchange) is unnecessary since native functionality exists. Option C (Experience Cloud) requires customer logins, which may not be as seamless as password-protected links. Thus, B is the most straightforward and secure solution.

Explanation:

The Delivery object is set to Private, so sharing rules are required to make records visible across users. Since each customer is assigned to a distributor, the records can be filtered based on a distributor field. Sharing to the Distributor role in the Role Hierarchy ensures that all users under that role (and its subordinates) will gain access. Option B (Public Group) could work but lacks hierarchical propagation. Option C (Sharing Set) applies only to Experience Cloud users—not internal users. Therefore, using criteria-based sharing with Role Hierarchy is the most efficient and scalable way to meet the requirement.

Explanation:

When a record is manually shared, Salesforce creates a new entry in the AccountShare table with the RowCause as Manual. Since John initially had Read-Only access (from OWD), Paul’s manual sharing grants him additional rights, and this is done through a new sharing record—not by updating an existing one. The Access Level reflects the shared access — in this case, Read/Write. Option A is incorrect because existing OWD-based access isn't updated; it's extended via a separate sharing record. Option C incorrectly states "Owner" as RowCause, which only applies to ownership-based access. Therefore, the correct mechanism is a new AccountShare record with RowCause “Manual” and the correct access level.