Explanation:

With Case and Account OWD both Private, and service reps have “View All” on Case, they automatically see all Cases. However, Contacts default OWD is often “Controlled by Parent,” meaning Contact access mirrors Account access. Since reps need account visibility to view customer data, the architect must ensure Accounts are shared (via Role Hierarchy, sharing rules, or manual shares). Once reps can see the Account, they inherit access to its Contacts.

Option A is a false alarm—Private OWD does restrict Accounts but can be mitigated. Option B misconstrues Controlled by Parent; Contacts are always tied to parent Account access. Therefore, C correctly identifies that enabling “Controlled by Parent” on Contacts unlocks the necessary Contact visibility once account access is granted.

Explanation:

To restrict a field to a single profile, the Field-Level Security settings are the most direct mechanism. You simply grant “Visible” (and “Read-Only” or “Read/Write,” as needed) to the Private Banking Rep profile and remove visibility on all other profiles.

→ Changing the field to a picklist/record type (A) is overkill and doesn’t restrict by profile.
→ Page Layout control (B) hides it on specific layouts, but a savvy user could use API or reports to access the field if FLS still allows visibility. FLS is the only way to guarantee the field is truly hidden for unauthorized users.

Explanation:

Files in a user’s private library are by definition accessible only to that user. They don’t inherit the broader record sharing model because they aren’t attached to a record; they live solely in the user’s personal Files Home. Even managers above in the Role Hierarchy (A) or users with “View All Data” (B) can’t see another user’s private library content. To share, the owner must explicitly publish or share the file with specific users or groups.

Explanation:

Site User Visibility in Sharing Settings controls whether external (community) users can see and search for each other. When it’s turned off, community users cannot find or view other external users in lookups, chatter, or user lists. Internal user visibility and profile updates (A and C) remain unaffected because Site User Visibility applies only to the portal’s external user base.

This setting is crucial for privacy in a community—especially a Partner Community—where partners should not necessarily see every other partner’s profile. Turning it off locks down that level of discovery.

Explanation:

When users can see the record header but only a few fields on detail view, it indicates Field-Level Security rather than sharing. Page Layout controls which fields appear, but FLS determines visibility at all levels—even in the API and search. If the Sales Users profile lacks “Visible” permission for certain Invoice fields, those fields never render, and the user only sees the default Name, Created Date, and Last Modified fields, which are always visible.

→ A missing sharing rule (A) wouldn’t let them see the record at all.
→ A page layout omission (C) hides fields on the layout but doesn’t explain why the admin sees more fields; admins can see everything regardless of layout if FLS permits. The differential visibility points squarely to FLS misconfiguration on the Sales Users profile.