Sharing-and-Visibility-Architect Practice Test Questions

Explanation:

Field Level Security (FLS) controls whether a field is visible or editable for users based on their profile or permission sets. To meet the requirement, the field must be searchable and visible to Banking Reps but not editable. Setting the Date of Birth field as Visible but Read-Only for Banking Reps allows them to search and view the field without editing capability. Meanwhile, the Customer Support Reps' profile can have the field set as Visible and Editable. Validation rules are more suited to enforcing complex logic but are not ideal for simple access control, as they cannot control searchability. Adding the field to the search layout ensures searchability but does not enforce edit permissions. Hence, adjusting FLS is the recommended, declarative, and secure approach.

Explanation:

Profiles define a user’s baseline permissions and visible apps/tabs. Cloning the existing Sales Rep profile allows you to create a customized profile where you can enable the new functionality and remove legacy app visibility or permissions. This method cleanly separates users and controls UI elements effectively. Using permission sets to add new functionality (option B or C) can grant access but cannot hide legacy features already assigned via the profile. Profiles remain the fundamental way to restrict or grant access to core app functions and visibility.

Explanation:

For sales agents needing access to products and prices with ability to create opportunities, "Public Read-Only" is the correct organization-wide default for pricebooks. This setting allows all users to view pricebooks (required for seeing products and prices) while preventing unauthorized edits, as only users with "Manage Price Books" permission can modify them. "View" (Option B) isn't a valid pricebook sharing option. "Use" (Option C) would allow editing pricebooks, which exceeds the requirement. Public Read-Only strikes the right balance - sales agents can reference pricebooks when creating opportunities without risking unauthorized changes to pricing data. This aligns with the principle of least privilege while meeting business requirements. The solution also scales well as the sales team grows and maintains data integrity by preventing accidental modifications to critical pricing information. Additional control can be layered through permission sets if specific users need edit access.

Explanation:

The runAs() system method in Apex test classes primarily verifies enforcement of a user's record sharing settings (Option A). When testing with runAs(), the system executes code with the specified user's sharing context, allowing verification of sharing rules, role hierarchy, and manual sharing. While it runs in the user's context, it doesn't fully enforce Field-Level Security (Option B) - field accessibility must be tested separately. It also doesn't verify all user permissions (Option C) as some permissions like API access aren't restricted in test context. The primary purpose of runAs() is to test record-level visibility, crucial for validating sharing models in private or controlled org-wide defaults. This enables comprehensive testing of security models without requiring actual user logins. Developers use runAs() to ensure records are properly shared or restricted according to org sharing settings, making it an essential tool for testing sharing and visibility requirements in complex implementations with multiple user types and access levels.

Explanation:

For adding new fields to Platform Shield Encryption, Option C is correct. The proper process is to use Encryption Policy to select the new fields (Billing Street, Billing City, and Phone) and then contact Salesforce to encrypt existing records, as historical data isn't automatically encrypted. Option A is incorrect because Classic Encryption is deprecated and shouldn't be mixed with Platform Encryption. Option B is incomplete because while Encryption Policy defines what to encrypt, it doesn't address existing data encryption without Salesforce assistance. Platform Encryption requires a specific implementation process: 1) Define encryption policy for new fields, 2) Deploy changes, 3) Contact Salesforce Support to encrypt existing records, as this operation requires backend processing. This approach maintains consistency with the existing encryption implementation while expanding protection to the newly identified sensitive fields. It also ensures compliance with the audit requirements by properly securing all historical data in the newly identified fields, not just future entries. The solution follows Salesforce best practices for encryption expansion projects.

Explanation:

With Opportunity OWD set to Private and a sharing rule granting access to a public group of sales engineers, Option A correctly identifies that managers in the role hierarchy will also gain access. In Salesforce's sharing model, when records are shared with users (in this case via public group membership), those users' managers in the role hierarchy automatically gain equal or greater access. This is a fundamental aspect of Salesforce's role hierarchy behavior. Option B is incorrect because subordinates don't inherit access upwards. Option C is wrong because merely being in the same role hierarchy doesn't grant access - the sharing must be explicit or through hierarchy. The scenario demonstrates how sharing rules combine with role hierarchy to determine access. Organizations must consider this behavior when designing sharing models, especially with private OWD settings. It's often desirable as it allows managerial oversight, but can lead to unintended access if not properly planned for during security design.

Explanation:

The performance degradation is caused by an account ownership data skew problem (Option A). When individual users own more than 10,000 records (in this case 50,000+ donors each), Salesforce experiences performance issues due to sharing table calculations. This is a well-documented limit in Salesforce architecture. Option B is incorrect because access being "wrong" wouldn't necessarily cause performance degradation. Option C is inaccurate because while sharing recalculations occur, they're a symptom not the root cause. The core issue is the data model assigning too many records to single users, violating Salesforce best practices for data distribution. Solutions include: implementing account teams to distribute access without transferring ownership, using territory management, or revising the assignment rules to better balance record ownership. The situation highlights the importance of considering data skew during design phases for large-volume objects, especially when implementing ownership-based sharing models. Performance can be maintained by ensuring no single user owns excessive records and that data is evenly distributed across the user base.

Explanation:

For testing Apex managed sharing implementations, Option C is correct - using runAs() to test different user contexts is essential. This allows verification that sharing works as intended for various user profiles. Option A is incorrect because "Without Sharing" would ignore sharing rules entirely, contrary to the requirement. Option B is wrong because "With Sharing" enforces record-level security, not Field-Level Security. When implementing Apex managed sharing, developers should: 1) Create sharing records programmatically based on business rules, 2) Use runAs() in test classes to verify visibility from different user perspectives, and 3) Ensure tests cover both positive and negative cases (users who should and shouldn't have access). This approach provides comprehensive testing of the complex sharing requirements while maintaining security. The solution supports the audit team's need for controlled access to private Invoice records while allowing for flexible, rule-based sharing that can evolve with the company's fraud detection processes. Proper testing with runAs() ensures the implementation meets all security requirements.

Explanation:

To grant U.S. sales managers read access to same-segment Canadian accounts, Option A is correct - creating an owner-based sharing rule is the most appropriate solution. Sharing rules can grant access based on record characteristics (like segment) to entire roles or public groups, crossing hierarchy boundaries. Option B is less ideal as permission sets don't directly grant record access and maintaining public groups of accounts is cumbersome. Option C would break the logical country-based role hierarchy unnecessarily. Owner-based sharing rules are powerful tools for granting horizontal access across role hierarchies while maintaining the vertical hierarchy structure. The rule would: 1) Identify accounts by segment field, 2) Specify sales manager roles as recipients, and 3) Grant read access. This provides clean, maintainable access that automatically adjusts as accounts change segments or managers change roles. The solution respects the existing role hierarchy while meeting the business requirement for cross-border visibility within segments. It's also scalable if additional countries or segments are added later, and performs well because sharing rules are calculated asynchronously.

Explanation:

Option A provides the optimal solution by using a Lightning Component override specifically for mobile edit actions, requiring no changes for desktop users. This approach: 1) Minimizes customization by only modifying what's necessary, 2) Promotes reusability through Lightning Components, 3) Maintains existing desktop functionality exactly as is, and 4) Provides a tailored mobile experience. Option B is overcomplicated by attempting device detection in the component itself. Option C creates UI inconsistency by adding a separate button. The override solution cleanly separates mobile and desktop experiences at the action level, following Salesforce best practices for form-factor specific customization. The Lightning Component can encapsulate all mobile-specific functionality including image capture, while desktop users continue using their familiar interface unchanged. This solution also future-proofs the implementation as Salesforce continues enhancing mobile capabilities. It respects the requirement to minimize disruption to trained service reps while adding valuable functionality for field consultants in the most maintainable way possible. The component can be reused elsewhere if similar mobile-specific functionality is needed for other objects.