# Free Salesforce Platform Sharing and Visibility Architect Practice Questions

*Last updated September 2026 · https://www.certifyforce.com/salesforce-platform-sharing-and-visibility-architect-practice-exam/free-questions*

18 free Platform Sharing and Visibility Architect practice questions from the Certifyforce bank of 309 reviewed questions, spread across the 4 official exam sections in proportion to their weight. Each has the correct answer, an explanation, and the official documentation it was verified against.

## Permissions to Standard Objects, Custom Objects, and Fields (27%)

### Question 1

AW Computing's support operations manager needs to read every Case record to audit response quality. Case has a Private organization-wide default. The admin proposes giving the manager View All Data, but the sharing architect wants a least-privilege alternative and lists the facts that support it. Which two statements are accurate? Choose 2 answers.

- A. View All Records on Case grants read access to all cases regardless of sharing while staying limited to that one object
- B. Neither View All Data nor View All Records on Case overrides field-level security, so field permissions are still needed
- C. View All Records on Case also grants read access to every account linked to those cases without any sharing
- D. View All Data is the only way to see cases owned by users in roles above the manager in the role hierarchy
- E. View All Records on Case can also be assigned to the company's Customer Community Plus users to support case deflection

**Correct answers:** A. View All Records on Case grants read access to all cases regardless of sharing while staying limited to that one object; B. Neither View All Data nor View All Records on Case overrides field-level security, so field permissions are still needed

**Explanation:** View All Records lets users view all records of a specific object regardless of sharing, so it is the object-scoped alternative to View All Data, and Help states that neither View All Data nor View All Records overrides field-level security. View All Records for an object doesn't give access to related standard records in either direction, so linked accounts still need sharing. View All Records on Case already reaches cases owned by anyone, including users in higher roles, so View All Data isn't required for that. View All Records and View All Data can't be assigned to external users such as Customer Community Plus users.

**Sources:** [“View All” and “Modify All” Permissions Overview](https://help.salesforce.com/s/articleView?id=platform.users_profiles_view_all_mod_all.htm&language=en_US&type=5), [Object Permissions](https://help.salesforce.com/s/articleView?id=platform.users_profiles_object_perms.htm&language=en_US&type=5)

### Question 2

AW Computing (Enterprise Edition) adds a custom hierarchical field, HR Business Partner, on the User object. Every employee must be able to see who their HR business partner is, but only members of the HR Operations team may change the field on any user record. What should the Salesforce admin configure?

- A. Select the field's Restricted Field checkbox, so only users with the Manage Internal Users permission can edit it
- B. Use field-level security: Read on the field for employees, plus Edit through a permission set for HR Operations
- C. Remove the field from the user page layout for everyone except HR Operations, so other employees can't change it
- D. Mark the field Required on the User page layout, so that only HR Operations is shown the field as an editable input

**Correct answer:** B. Use field-level security: Read on the field for employees, plus Edit through a permission set for HR Operations

**Explanation:** Help's Object Relationships Overview says that for hierarchical fields the Restricted Field checkbox, which limits editing to users with Manage Internal Users, is offered in Personal, Contact Manager, Group and Professional Editions, and that in Enterprise and higher editions you use field-level security instead. Read for all employees with Edit granted to HR Operations through a permission set meets the requirement. Removing the field from layouts hides it from employees who must see it and doesn't secure other channels. Field Permissions says page layout and field-level security combine with the most restrictive setting winning, and a layout's Required setting doesn't decide who may edit.

**Sources:** [Object Relationships Overview](https://help.salesforce.com/s/articleView?id=platform.overview_of_custom_object_relationships.htm&language=en_US&type=5), [Field Permissions](https://help.salesforce.com/s/articleView?id=platform.users_profiles_field_perms.htm&language=en_US&type=5)

### Question 3

Ursa Major Solar's interns open records of the custom Site Survey object from two Lightning apps, Field Ops and Sales, and each app has its own Site Survey record page. To stop interns from being offered the Clone action, the admin upgraded the Highlights Panel on the Field Ops record page to dynamic actions and added a filter that hides Clone for the Intern profile. Interns no longer see Clone in Field Ops but still see it in the Sales app. What is the cause?

- A. Dynamic action filters on a custom object apply in only one Lightning app until Dynamic Actions on Mobile is enabled
- B. A profile filter on a dynamic action is evaluated only for users whose default app is the app that owns the record page
- C. The Clone action can't be hidden with dynamic actions, so the Field Ops result is cached and will revert for interns
- D. Enabling dynamic actions applies only to the record page being edited, so the Sales page still shows page layout actions

**Correct answer:** D. Enabling dynamic actions applies only to the record page being edited, so the Sales page still shows page layout actions

**Explanation:** Create Dynamic Actions in Lightning App Builder states that when you enable Dynamic Actions, it applies only to the record page you're currently working on, and users of that page see the actions configured in Lightning App Builder instead of the page layout's actions, so the Sales record page still uses the Site Survey page layout actions. The mobile setting controls dynamic actions for standard objects on mobile and has nothing to do with desktop apps. Visibility filters don't depend on a user's default app. Clone is being hidden successfully in Field Ops, which shows that the action can be filtered. Hiding an action is a UI choice; if interns must never copy records, their object permissions should also be reviewed.

**Sources:** [Create Dynamic Actions in Lightning App Builder](https://help.salesforce.com/s/articleView?id=sf.lightning_app_builder_create_dynamic_action.htm&language=en_US&type=5)

### Question 4

Universal Containers plans to move its Apex classes from API version 60.0 to API version 67.0, introduced in the Summer '26 release. Many classes run SOQL and DML with no access mode, some queries use WITH SECURITY_ENFORCED, and a nightly integration class, declared without sharing, must keep reading and updating every record. Which two changes should the technical architect plan before raising the versions? Choose 2 answers.

- A. Replace WITH SECURITY_ENFORCED with WITH USER_MODE, because the release notes say the clause is removed as of API version 67.0.
- B. Remove every with sharing keyword, because Salesforce deprecated the sharing keywords in API version 67.0 in favor of access modes.
- C. Set WITH SYSTEM_MODE and as system explicitly in the integration class, because operations without a mode run in user mode at 67.0.
- D. Replace each Security.stripInaccessible call with WITH USER_MODE, because stripInaccessible isn't supported at API version 67.0 or later.
- E. Wrap the integration's DML in System.runAs with an admin user, so the class keeps full record access at API version 67.0.

**Correct answers:** A. Replace WITH SECURITY_ENFORCED with WITH USER_MODE, because the release notes say the clause is removed as of API version 67.0.; C. Set WITH SYSTEM_MODE and as system explicitly in the integration class, because operations without a mode run in user mode at 67.0.

**Explanation:** The Summer '26 release note (versioned change for API version 67.0 and later; earlier API versions keep system mode) says that from API version 67.0, Apex database operations run in user mode by default and that the WITH SECURITY_ENFORCED clause is removed as of API version 67.0, so queries should use WITH USER_MODE instead. The LWC guide page "Secure Apex Classes" confirms that API version 66.0 and earlier run in system mode by default. Code that needs full access, such as the integration, must set system mode explicitly, and Salesforce recommends setting an access mode on every operation. The sharing keywords aren't deprecated: the LWC guide still tells you to declare without sharing to bypass sharing and recommends keywords on every class, and the release note says the class sharing declaration governs system-mode operations, so removing them would change behavior. stripInaccessible remains a supported way to enforce FLS. System.runAs can be used only in test methods, so it can't elevate production integration code.

**Sources:** [Database Operations Run in User Mode by Default, Not System Mode (Summer '26 release notes)](https://help.salesforce.com/s/articleView?id=release-notes.rn_apex_default_user_mode.htm&release=262&type=5), [Enforce User Mode for Database Operations](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_enforce_usermode.htm), [Secure Apex Classes (Lightning Web Components Developer Guide)](https://developer.salesforce.com/docs/platform/lwc/guide/apex-security.html), [Enforce Security with the stripInaccessible Method](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_with_security_stripInaccessible.htm), [Using the runAs Method](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_tools_runas.htm)

### Question 5

Ursa Major Solar stores utility permit numbers in a Classic Encryption custom text field on the custom Installation object. Installers who work for partner companies log in to an Experience Cloud site with Partner Community licences. The admin gave them Read on the field and a permission set with View Encrypted Data, yet the installers still can't see the permit number at all. What is the cause?

- A. View Encrypted Data takes effect only after the installers log out and back in, so their existing site sessions still show the field as hidden
- B. Classic encrypted fields need a page layout assignment for each Experience Cloud site, and the partner layout doesn't include the field yet
- C. Experience Cloud sites show encrypted values only to users who also have Manage Encryption Keys, which partner licences can't receive
- D. Classic encrypted text fields aren't available to partner and customer portal licence types, even when those users have View Encrypted Data

**Correct answer:** D. Classic encrypted text fields aren't available to partner and customer portal licence types, even when those users have View Encrypted Data

**Explanation:** Help lists licence types (Partner, PowerPartner, CspLitePortal, CustomerSuccess and PowerCustomerSuccess) for which encrypted text fields aren't available, even if the users have View Encrypted Data, so partner site users can't see the field. A new session doesn't change that licence restriction. A page layout controls where a visible field appears, but it can't override the licence limitation. Manage Encryption Keys is a Shield Platform Encryption key management permission and has nothing to do with reading Classic encrypted values.

**Sources:** [Classic Encryption for Custom Fields](https://help.salesforce.com/s/articleView?id=sf.fields_about_encrypted_fields.htm&language=en_US&type=5)

## Access to Records (39%)

### Question 6

Cloud Kicks is building two custom objects: Athlete Sponsorship and Sponsorship Payment. Every payment belongs to exactly one sponsorship, payments should be deleted with their sponsorship, and anyone who can see a sponsorship must see its payments without any separate sharing to maintain. Which relationship should the architect recommend?

- A. A lookup from Sponsorship Payment to Athlete Sponsorship with a Private default and an ownership-based sharing rule for payments.
- B. A lookup from Athlete Sponsorship to Sponsorship Payment, so each sponsorship stores the most recent payment in a related field.
- C. A master-detail relationship with Sponsorship Payment as the detail, so its access is controlled by the parent sponsorship.
- D. A hierarchical relationship between the two objects, so access to a sponsorship rolls down to the payment records under it.

**Correct answer:** C. A master-detail relationship with Sponsorship Payment as the detail, so its access is controlled by the parent sponsorship.

**Explanation:** In a master-detail relationship the detail inherits security from the master (its default is Controlled by Parent), and deleting the master deletes its details, which meets both requirements with nothing extra to maintain. A lookup gives the payment its own default and sharing, so the team would keep a sharing rule aligned with sponsorship access. A lookup in the other direction stores one payment on the sponsorship and doesn't model one-to-many or control payment access. Hierarchical relationships exist only on the User object.

**Sources:** [Object Relationships Overview](https://help.salesforce.com/s/articleView?id=platform.overview_of_custom_object_relationships.htm&language=en_US&type=5), [Custom Object Security](https://help.salesforce.com/s/articleView?id=platform.dev_security.htm&language=en_US&type=5), [Sharing a Record Using Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_bulk_sharing_creating_with_apex.htm)

### Question 7

Ursa Major Solar is redesigning its role hierarchy before a large expansion. The technical architect is asked to list recommendations that follow Salesforce guidance for a role hierarchy that performs well and is easy to maintain. Which three recommendations should the architect make? Choose 3 answers.

- A. Consolidate job titles that need the same record access into a single role instead of creating a separate role for each title
- B. Keep the number of levels low, following the architect best practice of about 10 levels of branches or fewer, and remove roles that aren't needed
- C. Delete sharing rules that only grant access which the role hierarchy already provides to users above the record owners
- D. Use the reporting structure that each department's dashboards need to decide how many levels the role hierarchy has
- E. Schedule role hierarchy changes during business hours so managers can confirm their access straight after each change

**Correct answers:** A. Consolidate job titles that need the same record access into a single role instead of creating a separate role for each title; B. Keep the number of levels low, following the architect best practice of about 10 levels of branches or fewer, and remove roles that aren't needed; C. Delete sharing rules that only grant access which the role hierarchy already provides to users above the record owners

**Explanation:** Salesforce advises consolidating titles whose access is the same into single roles, minimizing the number of levels (the architect page gives about 10 levels of branches as a best practice, not a hard limit) and deleting sharing rules that grant access already given by the role hierarchy. The role guidelines say not to use reporting requirements to determine the hierarchy levels you need. They also say to avoid changing the role hierarchy during business hours to prevent disruptions, because changes trigger sharing recalculation.

**Sources:** [Guidelines for Success with Roles](https://help.salesforce.com/s/articleView?id=platform.setup_roles_guidelines.htm&language=en_US&type=5), [Platform Sharing Architecture](https://architect.salesforce.com/docs/architect/fundamentals/guide/platform-sharing-architecture)

### Question 8

Refer to the code below from Ursa Major Solar, where both classes are saved at API version 60.0:
```apex
public with sharing class PermitService {
    public class Finder {
        public Integer countPermits() {
            return [SELECT COUNT() FROM Permit__c];
        }
    }
}

public without sharing class PermitAudit {
    public static Integer run() {
        return new PermitService.Finder().countPermits();
    }
}
```
The org has 2,000 Permit__c records, and the running user's sharing lets them see 300. A compliance job calls `PermitAudit.run()` as that user. What does it return?

- A. 300, because an inner class inherits the with sharing declaration of the class that contains it.
- B. 2,000, because the inner class doesn't inherit its container's sharing and runs in its caller's mode.
- C. 300, because any query on a custom object enforces the running user's sharing unless it is anonymous.
- D. It fails to compile, because a class with no sharing keyword can't be called from a without sharing class.

**Correct answer:** B. 2,000, because the inner class doesn't inherit its container's sharing and runs in its caller's mode.

**Explanation:** Inner classes don't inherit the sharing setting of their container class, and a class with no sharing declaration runs with the sharing rules already in effect, so Finder runs in the without sharing mode of PermitAudit and counts all 2,000 records. The claim that the inner class inherits with sharing from PermitService is the misconception the documentation warns about. At API version 60.0, Apex runs in system context by default, so custom object queries don't enforce sharing on their own. Omitting a sharing keyword is legal; it is insecure by default, not a compile error.

**Sources:** [Use the with sharing, without sharing, and inherited sharing Keywords](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_keywords_sharing.htm), [Enforce Sharing Rules](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_security_sharing_rules.htm)

### Question 9

In a current Cumulus Financial org, the All Advisors public group has grown to 14,000 users and is the target of several sharing rules. When admins add or remove advisors on the group's Edit page, the page is slow and some existing members have disappeared from the group. Which two approaches should the architect recommend for changing this group's membership? Choose 2 answers.

- A. Update membership through the GroupMember API, for example from the HR integration, rather than on the group's Edit page.
- B. Adjust membership through the public group's access summary or through user access policies instead of the Edit page.
- C. Ask Salesforce Customer Support to raise the public group member limit to 20,000 so the Edit page can save larger groups.
- D. Deselect Grant Access Using Hierarchies on the group, which raises the number of members the Edit page can safely handle.
- E. Recreate All Advisors as a personal group owned by the admin, because personal groups don't have the Edit page limitation.

**Correct answers:** A. Update membership through the GroupMember API, for example from the HR integration, rather than on the group's Edit page.; B. Adjust membership through the public group's access summary or through user access policies instead of the Edit page.

**Explanation:** Salesforce warns that groups with more than 10,000 members can suffer performance issues or lose members when membership is updated on the Edit or Create page, and recommends adjusting membership through the GroupMember API, the public group's access summary or user access policies (Support can also enable a modified Group Setup interface). There is no member limit for Support to raise; the issue is the Edit page itself. Grant Access Using Hierarchies affects who inherits access, not how many members the page handles. Personal groups are only for their owner's manual sharing in Salesforce Classic and can't be the target of sharing rules.

**Sources:** [Public Group Considerations](https://help.salesforce.com/s/articleView?id=platform.user_groups_considerations.htm&language=en_US&type=5), [Create and Edit Public Groups](https://help.salesforce.com/s/articleView?id=platform.creating_and_editing_groups.htm&language=en_US&type=5)

### Question 10

Universal Containers keeps its custom Supplier Audit object at a Private organization-wide default and hasn't enabled the Keep manual shares when transferring records setting. Each auditor manually shares their audits with the quality reviewer named on the audit's Review Team picklist. Last week, sales operations transferred 300 audits from a departed auditor to a new one, and the quality reviewers lost access to all of them. What should the sharing architect recommend so that reviewer access no longer depends on who owns each audit?

- A. Have the reviewers wait for sharing recalculation to finish, because the transferred audits regain their manual shares once it completes.
- B. Replace the manual shares with criteria-based sharing rules on the Review Team field, because an owner change removes manual shares.
- C. Give each reviewer View All Records on Supplier Audit so that they keep access when the audits they review change owner.
- D. Place the new auditor in a role below the departed auditor's role so that the earlier manual shares carry over to the new owner.

**Correct answer:** B. Replace the manual shares with criteria-based sharing rules on the Review Team field, because an owner change removes manual shares.

**Explanation:** By default, Salesforce deletes a record's manual shares when its owner changes, which is why the transfer removed reviewer access. Criteria-based sharing rules on the Review Team field share audits with the right reviewer groups regardless of owner, so future transfers don't break access. Sharing recalculation doesn't recreate deleted manual shares. View All Records would let every reviewer read every audit, which is far broader than the per-team requirement. Role placement doesn't move manual shares to a new owner, because the shares were deleted at transfer.

**Sources:** [Manual Sharing](https://help.salesforce.com/s/articleView?id=platform.granting_access_to_records.htm&language=en_US&type=5), [Sharing Considerations](https://help.salesforce.com/s/articleView?id=platform.security_sharing_considerations.htm&language=en_US&type=5), [Sharing Rule Considerations](https://help.salesforce.com/s/articleView?id=platform.security_sharing_rule_considerations.htm&language=en_US&type=5)

### Question 11

AW Computing's org was created in 2023 and has an internal Account default of Public Read Only. The admin has just launched an Experience Cloud partner site and never touched the external defaults. Partner users with Partner Community licenses can see their own distributor account, but none of the other accounts that every internal user can read. A partner manager calls this a bug. What should the architect explain?

- A. In orgs created after Spring '20, the external default starts as Private for objects not set to Controlled by Parent, so partners need sharing to see more
- B. Partner users always inherit the internal Account default, so a Public Read Only internal default should already let them read every account in the org
- C. The external Account default starts at Public Read Only, but partner users can't see other accounts until the admin runs a sharing recalculation
- D. Partner users can never read accounts beyond their own account through any default, because external defaults don't exist for the Account object

**Correct answer:** A. In orgs created after Spring '20, the external default starts as Private for objects not set to Controlled by Parent, so partners need sharing to see more

**Explanation:** Help's default access table shows that in orgs created after Spring '20 the default external authenticated access is Private for all objects unless the internal default is Controlled by Parent, so partners see only their own account plus what sharing grants, which is working as designed. External defaults are a separate setting, so partners don't inherit the internal Public Read Only level. The external default doesn't start at Public Read Only in a new org, so no recalculation would reveal more accounts. Account is one of the objects that supports an external default, which could be raised to Public Read Only if that were wanted.

**Sources:** [Default Organization-Wide Access Levels](https://help.salesforce.com/s/articleView?id=platform.security_sharing_owd_default_settings.htm&language=en_US&type=5), [External Organization-Wide Defaults Overview](https://help.salesforce.com/s/articleView?id=platform.security_owd_external.htm&language=en_US&type=5)

### Question 12

Cumulus Financial is launching a member service site for about 3 million retail banking members. Each member must see the Service_Request__c records they create and read the cases on their own household account. Members don't need reports, dashboards or a role-based hierarchy inside their household. Which license and sharing approach should the architect recommend?

- A. Customer Community Plus licenses with account roles, plus sharing rules that share requests with each member's account role.
- B. Partner Community licenses, so that each member gets the partner role hierarchy that rolls up to the account owner.
- C. Customer Community licenses with a sharing set that maps the user's Contact.Account to each record's account lookup.
- D. Customer Community licenses with owner-based sharing rules that share each member's records with their household.

**Correct answer:** C. Customer Community licenses with a sharing set that maps the user's Contact.Account to each record's account lookup.

**Explanation:** Customer Community is the high-volume license, with no roles, recommended for very large user counts, and a sharing set grants these users access to records whose account or contact lookup matches the user's account or contact. Customer Community Plus adds roles and standard sharing that the members don't need, and each account role counts toward portal role limits. Partner Community is meant for business-to-business sales scenarios and can't be used with person accounts. High-volume users can't be included in owner-based sharing rules, so that design can't be built.

**Sources:** [Experience Cloud User Licenses](https://help.salesforce.com/s/articleView?id=platform.users_license_types_communities.htm&language=en_US&type=5), [Create a Sharing Set for Experience Cloud Site Users](https://help.salesforce.com/s/articleView?id=platform.networks_setting_light_users.htm&language=en_US&type=5)

## Access to Other Data (16%)

### Question 13

A Cloud Kicks merchandiser posted a confidential launch-pricing file to a public Chatter group's feed. The compliance officer says the file must no longer be visible across the company, but the merchandiser and two named colleagues, who already have the file shared with them individually as viewers, must keep access. Which two statements should the admin use to explain and fix the situation? Choose 2 answers.

- A. Posting the file to a public group shared it with the company, and Chatter users get Viewer access by default
- B. The file owner or a collaborator can change the company's access to No Access, which ends that company share
- C. Only users with View All Data can see files posted to public groups, so the file is already limited to admins
- D. Deleting the public group is the only way to remove a file share that was created by posting to a group feed
- E. Users who saw the file through the group became collaborators and must be removed one by one from the file

**Correct answers:** A. Posting the file to a public group shared it with the company, and Chatter users get Viewer access by default; B. The file owner or a collaborator can change the company's access to No Access, which ends that company share

**Explanation:** A file is shared with the company when it is posted to a feed all users can see or to a public group, and all Chatter users in the company get Viewer permission by default. File owners and collaborators can change company access to No Access, after which the file is no longer shared with the company or with public groups, while individual shares remain, which is why the two colleagues keep their access. Files posted to public groups are not limited to View All Data users. Deleting the group isn't required because changing the company access removes the share. Group members get Viewer access by default, not Collaborator, so there is no list of collaborators to remove.

**Sources:** [Change File Access in Lightning Experience](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.collab_files_change_access.htm), [Chatter Groups](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=experience.collab_group_about.htm)

### Question 14

Northern Trail Outfitters uses a Salesforce CRM Content library for product sheets. Product marketers must publish new content, upload new versions, tag and archive content, but must not add or remove library members or rename the library. Which library permission should the admin give the marketers?

- A. Viewer, which includes the View Comments and Add Comments library privileges
- B. Author, which includes Add Content, Archive Content, Tag Content and related privileges
- C. Library Administrator, which includes the Manage Library privilege for the library
- D. A custom permission with only the Deliver Content and Feature Content privileges

**Correct answer:** B. Author, which includes Add Content, Archive Content, Tag Content and related privileges

**Explanation:** The Author library permission includes Add Content, Add Content on Behalf of Others, Archive Content, Add Comment and Tag Content, which covers publishing, versioning, tagging and archiving. Viewer includes only View Comments and Add Comments, so it can't publish content. Library Administrator includes Manage Library, which is required to edit a library's name and add or remove members, so it gives more than allowed. Deliver Content and Feature Content don't include publishing new content.

**Sources:** [Create and Edit Library Permissions](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.content_workspace_perm_add.htm)

### Question 15

Cumulus Financial shares a quarterly results file with an external auditor through a file link. The auditor replies that the link lets her view and download the file, but she needs to upload a corrected version. What should the admin explain?

- A. The auditor needs the Create Public Links permission on her own account before she can upload a version
- B. The file owner must set the link to Collaborator in the sharing dialog so that link recipients can edit
- C. Content deliveries are required, because public links are read-only only when they have a password set
- D. File link recipients can only view and download files and can't be collaborators, so she can't upload

**Correct answer:** D. File link recipients can only view and download files and can't be collaborators, so she can't upload

**Explanation:** Help states that file link recipients can only view and download files and can't be collaborators, so a link will never let the auditor upload a new version. Create Public Links lets an internal user create links; it is not something a link recipient needs. There is no Collaborator setting for link recipients in the sharing dialog. Content deliveries add options such as passwords, expiration and view tracking, but they still send a link to view the file, not a way to edit it.

**Sources:** [Change File Access in Lightning Experience](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.collab_files_change_access.htm), [Enable Content Deliveries and Public Links](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=admin_files_libraries_content_deliveries_public_links.htm)

## Implications of Security Model Choice (18%)

### Question 16

Get Cloudy Consulting runs a partner site where resellers use Partner Community licenses. Forty internal solution engineers, who already have Salesforce licenses, must work in the same site to answer reseller questions and see the deal records that internal sharing already gives them. A project manager proposes buying 40 Partner Community licenses for the engineers. What should the security architect recommend?

- A. Buy Partner Community Login licenses instead of member-based ones, because these internal users will visit the site only now and then
- B. Keep the engineers on their Salesforce licenses and add them to the site, since external licenses are only for external users
- C. Assign Partner Community licenses as permission set licenses on top of the engineers' current Salesforce user licenses
- D. Create a Partner Community user for each engineer under a company partner account so the engineers are in partner roles

**Correct answer:** B. Keep the engineers on their Salesforce licenses and add them to the site, since external licenses are only for external users

**Explanation:** Help explains that internal users can also access Experience Cloud sites with their internal licenses, and that Experience Cloud licenses are only for external users and must not be assigned to employees or contractors. The engineers' existing access then follows the internal sharing model. Login-based Partner Community licenses are still external licenses, so they don't fix the problem. Each user has only one user license, so a Partner Community license can't be layered on a Salesforce license, and creating partner users for employees misuses external licenses.

**Sources:** [When to Use an Internal or External License](https://help.salesforce.com/s/articleView?id=platform.users_internal_external_license_types.htm&language=en_US&type=5), [User Licenses](https://help.salesforce.com/s/articleView?id=platform.users_understanding_license_types.htm&language=en_US&type=5)

### Question 17

Cloud Kicks is training its support leads to test the sharing model by checking why a user can see a given case. In Lightning Experience, the leads have the permissions they need, but the Sharing Hierarchy option doesn't appear on case records. What should the admin do?

- A. Add the Sharing Hierarchy action to the case page layout, because the option appears only when it's on the layout.
- B. Switch the leads to Salesforce Classic, because the Sharing Hierarchy page is available only in the Classic interface.
- C. Change the Case org-wide default to Private, because the Sharing Hierarchy appears only on objects with a Private default.
- D. Give the leads Modify All Data, because only users with that permission can open the Sharing Hierarchy on a record.

**Correct answer:** A. Add the Sharing Hierarchy action to the case page layout, because the option appears only when it's on the layout.

**Explanation:** Help says that if you don't see the Sharing Hierarchy option and you have the right permissions, you should make sure it's added to the page layout. Sharing Hierarchy is the Lightning Experience feature, opened from the record's action menu; in Classic you click Sharing and then Expand List instead. The org-wide default doesn't decide whether the action appears; it only affects which users the list shows. The leads already have the permissions they need, and Modify All Data would give them far more access than testing requires.

**Sources:** [Viewing Which Users Have Access to Your Records in Lightning Experience](https://help.salesforce.com/s/articleView?id=platform.viewing_which_users_have_access_lex.htm&language=en_US&type=5), [Troubleshoot Object and Record Access Issues](https://help.salesforce.com/s/articleView?id=platform.admin_insufficient_privileges_map.htm&language=en_US&type=5)

### Question 18

Ursa Major Solar will load about 30 million Meter_Reading__c records, and each reading belongs to one custom Solar_Site__c record. Readings must be visible to exactly the users who can see their site. The architect is comparing two designs for the sharing load: making Meter_Reading__c the detail in a master-detail relationship to Solar_Site__c, or keeping a lookup with its own Private default and sharing rules that mirror site access. Which statement about the master-detail design is accurate?

- A. Each reading gives its viewers implicit Read on the parent site, so the platform keeps a parent implicit share for every reading viewer
- B. Each reading gets Meter_Reading__Share rows copied from its site's shares, so the share table grows with the number of readings
- C. The readings keep their own Private default, so sharing rules on the readings are still needed to mirror each site's access
- D. Detail records have no share object, so readings add no share rows; access comes from the site's sharing and the relationship setting

**Correct answer:** D. Detail records have no share object, so readings add no share rows; access comes from the site's sharing and the relationship setting

**Explanation:** The Apex Developer Guide says objects on the detail side of a master-detail relationship don't have an associated sharing object; the detail record's access is determined by the master's sharing object and the relationship's sharing setting, so 30 million readings add no share rows of their own. Salesforce's sharing architecture guide states that implicit sharing doesn't apply to custom objects; parent implicit sharing covers accounts with child contacts, opportunities, cases and orders, so a custom detail doesn't create implicit shares on its master. Without a share object there are no copied reading share rows. A detail object's default is Controlled by Parent, so it has no separate Private default to open with sharing rules.

**Sources:** [Sharing a Record Using Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_bulk_sharing_creating_with_apex.htm), [Platform Sharing Architecture](https://architect.salesforce.com/docs/architect/fundamentals/guide/platform-sharing-architecture), [Considerations for Object Relationships](https://help.salesforce.com/s/articleView?id=platform.relationships_considerations.htm&language=en_US&type=5)

## Related pages

- [Salesforce Platform Sharing and Visibility Architect practice exam](https://www.certifyforce.com/salesforce-platform-sharing-and-visibility-architect-practice-exam)
- [Practice exam packs](https://www.certifyforce.com/practice-exams)
- [Official Platform Sharing and Visibility Architect exam guide](https://help.salesforce.com/s/articleView?id=005298977&language=en_US&type=1)