Salesforce Sharing and Visibility Architect Practice Test

Correct answer: C. Remove read access to the field in field-level security for the Support profile

Field-level security is the only control that removes a field everywhere. Once FLS read access is revoked, the field disappears from detail pages, list views, reports, search results, the API, and Apex queries run in user mode.

Page layouts (A) and layout-level read-only settings are presentation only — the field is still returned by the API, by reports, and by any integration using that user's credentials, which is exactly the exposure compliance is asking about. A validation rule (B) controls writes, not visibility. Restriction rules (D) filter which records a user can see; they do not operate on fields.

Exam section: Permissions to Objects & Fields  ·  Difficulty: Easy

Correct answer: A. Build one permission set with the app permissions and assign it to the affected users, ideally through a permission set group

A permission set is additive and reusable: one definition, assigned to any user on any profile. Bundling it into a permission set group lets you assign a whole job function at once and mute individual permissions later without editing the underlying sets.

Cloning profiles (C) multiplies the maintenance surface by 18 and is the classic profile-sprawl anti-pattern. Editing base profiles (D) grants the app to every user on that profile, not just the ones who need it. Modify All Data (B) is a system permission that bypasses the entire sharing model on every object — a severe over-grant for an app entitlement.

Exam section: Permissions to Objects & Fields  ·  Difficulty: Easy

Correct answer: B. Modify All object permission on Invoice

Modify All (and View All) are object-level permissions granted per object on a profile or permission set. Modify All on Invoice bypasses sharing for that object only, which matches the requirement precisely.

Modify All Data (D) and View All Data (A) are org-wide system permissions that bypass sharing on every object — far broader than requested, and they also unlock capabilities such as mass transfer and deleting records the user cannot otherwise see. A sharing rule (C) can approximate the outcome but only for records matching the criteria, and it would need maintaining as new record types appear; it also cannot cover records that fall outside the criteria.

Exam section: Permissions to Objects & Fields  ·  Difficulty: Medium

Correct answer: D. Add a muting permission set to the group that mutes Delete on Case, and assign that group to the team

Muting permission sets exist for exactly this case. A muting permission set is attached to a permission set group and subtracts specific permissions from the group's calculated result, without modifying the component permission sets that other groups may also be using.

Duplicating the group (C) or restructuring the underlying sets (A) both work mechanically but create parallel definitions that drift apart over time. A validation rule (B) cannot block a delete operation — validation rules do not run on delete.

Exam section: Permissions to Objects & Fields  ·  Difficulty: Medium

Correct answer: B. The reviewer is right; with sharing enforces record-level sharing only, so field-level security and object CRUD must be enforced separately

with sharing applies the running user's record-level sharing to SOQL and DML in that class. It does nothing about object CRUD or field-level security, which is one of the most consequential misunderstandings in Salesforce security design.

To enforce field and object permissions you must do it explicitly — run the query in user mode (WITH USER_MODE in SOQL, or AccessLevel.USER_MODE with Database.query), strip inaccessible fields with Security.stripInaccessible(), or check Schema.DescribeFieldResult.isAccessible() before returning data. without sharing (C) removes record-level enforcement and makes the problem worse.

Exam section: Permissions to Objects & Fields  ·  Difficulty: Hard

Correct answer: C. Pass the query results through Security.stripInaccessible() and return the sanitised records

Security.stripInaccessible() removes fields and relationships the running user cannot access and returns a sanitised copy of the records, so the transaction continues without an exception. It can also be used to sanitise inbound data before DML.

WITH SECURITY_ENFORCED (B) throws an exception when an inaccessible field is referenced — correct behaviour in some designs, but the opposite of what was asked. inherited sharing (D) governs record-level sharing context, not fields. FOR VIEW (A) updates the record's last-viewed timestamp and has nothing to do with security.

Exam section: Permissions to Objects & Fields  ·  Difficulty: Hard

Correct answer: D. A restriction rule on Case that filters out Litigation Hold records for the contractor permission set

Restriction rules are the only native mechanism that subtracts record visibility. They apply a filter on top of whatever sharing has already granted, so a record excluded by the restriction rule is invisible even if a sharing rule, role hierarchy, or team would otherwise grant it.

Sharing rules (A) are purely additive — adding a narrower rule does not revoke access granted by the existing broader rules. Tightening the OWD (B) would disrupt every other user and would still be overridden by the existing sharing rules. Removing Read on Case (C) blocks all Cases, not just the flagged ones.

Exam section: Permissions to Objects & Fields  ·  Difficulty: Hard

Correct answer: A. Grant Read access but not Edit access to the field in field-level security, delivered through a permission set assigned to the analysts

Field-level security supports a read-without-edit state, and because both groups share a profile the differentiation has to come from a permission set. FLS is enforced through the UI and the API, so the analyst cannot bypass it with Data Loader or an integration.

Layout-level read-only (D) is UI-only and does not survive API access. A validation rule (B) does enforce the rule in the API but produces an error at save time instead of a read-only field, and it puts security logic in a place administrators do not think to audit. Restriction rules (C) filter records, not fields.

Exam section: Permissions to Objects & Fields  ·  Difficulty: Medium

Correct answer: B. Shield Platform Encryption protects the data at rest but does not control who can read the field; visibility still has to be enforced with field-level security

Shield Platform Encryption is an encryption-at-rest control, not an access control. Normal permission behaviour is preserved: a user who has field-level security read access on the field sees the plaintext value, encrypted or not. To limit who can read it, revoke FLS read access for everyone else.

The masking behaviour described in one option (A) belongs to classic encrypted text fields, which do require the View Encrypted Data permission — a different and much older feature that is easy to confuse with Shield. Shield does impose documented restrictions on filtering, sorting, and certain features for encrypted fields, but it does not remove the field for everyone (C), and it has no relationship to the record sharing model (D). Under Shield, masking appears only as a troubleshooting state, such as when the tenant secret has been destroyed or the encryption service is unavailable.

Exam section: Permissions to Objects & Fields  ·  Difficulty: Hard

Correct answer: C. Define a custom permission, assign it through a permission set, and use it in the button's visibility filter and in the flow's entry condition

Custom permissions exist to express application-level entitlements that do not correspond to any object or field. They can be checked declaratively in component visibility rules, validation rules, and flow decisions, and in Apex via FeatureManagement.checkPermission(). Assignment flows through permission sets, so the population is easy to change.

Hard-coded IDs (D) fail the moment someone joins or leaves. Modify All Data (A) is a drastic over-grant, and hiding a button does not stop the same user calling the flow through the API. Public groups (B) are sharing constructs and are not available as visibility filters for buttons and components.

Exam section: Permissions to Objects & Fields  ·  Difficulty: Medium

Correct answer: D. Read, Create, and Edit — object and field permissions from profiles and permission sets combine as a union

Object and field permissions are cumulative. Salesforce takes the union of the profile and every assigned permission set, so the most permissive combination applies. There is no precedence order and no conflict resolution to reason about.

This is why permission sets can only ever add access, and why muting permission sets inside a permission set group were introduced as the sanctioned way to subtract. It is also why an audit of a user's access must enumerate every assigned set rather than reading the profile alone.

Exam section: Permissions to Objects & Fields  ·  Difficulty: Easy

Correct answer: A. Modify All object permissions on only the specific objects the job touches, assigned through a dedicated permission set

Object-scoped Modify All satisfies the requirement with the smallest blast radius. If the integration is later compromised or misconfigured, the damage is bounded by the objects it was granted rather than the whole org.

Modify All Data (C) and the System Administrator profile (B) both grant org-wide bypass, including objects the job has no business touching, and the administrator profile additionally carries setup and metadata permissions. The View All Data option (D) does not meet the update requirement and mass-reassigning ownership to an integration user creates ownership skew.

Exam section: Permissions to Objects & Fields  ·  Difficulty: Medium

Correct answer: A. The field is on the list view but removed from the page layout, so field-level security still grants read access

If a field is genuinely hidden by field-level security it cannot appear in a list view, a report, or the API. The symptom described — visible in a list view but not on the detail page — is the signature of a field removed from the page layout while FLS read access remains.

This is the practical reason architects treat page layouts as a usability tool and FLS as the security control. Neither of the list-view explanations (C) (D) is correct, because list views do not bypass FLS, and View All Data (B) affects record access, not field access.

Exam section: Permissions to Objects & Fields  ·  Difficulty: Medium

Correct answer: D. Standard controllers enforce sharing, object, and field permissions; custom controllers run in system context unless the developer enforces them

Pages built on a standard controller enforce sharing, CRUD, and field-level security for you. A custom controller runs in system context by default: the developer must declare with sharing for record access and enforce CRUD and FLS explicitly.

Some Visualforce components do respect FLS when bound to an sObject field, but relying on component behaviour is fragile and does not cover data the controller has already queried and exposed. The dependable pattern is to enforce access in the controller — user-mode queries and stripInaccessible — rather than trusting the view layer.

Exam section: Permissions to Objects & Fields  ·  Difficulty: Hard

Correct answer: C. Opportunity OWD Private, role hierarchy for managers, and View All on Opportunity for the deal desk

Start restrictive and open up. A Private OWD gives reps their own records; the role hierarchy automatically rolls that access up to their managers; and a small, stable population needing org-wide visibility is best served by the Modify All / View All object permission rather than by a sharing rule.

Two of the options (A) (B) start permissive and try to claw access back, which sharing rules cannot do and which leaves the data exposed if the restriction is misconfigured. The per-rep option (D) would need one rule per rep — unmaintainable, and it does not scale within the documented sharing rule limits.

Exam section: Access to Records  ·  Difficulty: Easy

Correct answer: B. Deselect Grant Access Using Hierarchies on the Compliance Case object definition

Grant Access Using Hierarchies can be deselected on custom objects, which stops the role hierarchy from rolling record access upward for that object only. It cannot be deselected for standard objects, which is a limitation worth remembering when a similar requirement lands on Case or Opportunity.

Removing the role hierarchy (A) would break access everywhere else. Controlled by Parent (C) makes a child object's access follow its parent — the default for detail records in a master-detail relationship, and for standard objects such as Contact — which is a different question from hierarchy inheritance. A restriction rule (D) could theoretically filter managers out, but it is a heavier and less obvious control than the setting designed for this purpose.

Exam section: Access to Records  ·  Difficulty: Medium

Correct answer: A. A criteria-based sharing rule on the Risk Tier field

Criteria-based sharing rules evaluate field values on the record and re-evaluate automatically when the record is created or edited, which is exactly the stated requirement: the trigger is Risk Tier, not ownership.

Ownership-based rules (D) key off who owns the record, which the requirement explicitly rules out. Manual shares (B) do not scale and disappear when ownership changes. Apex managed sharing (C) would work but is unjustified custom code when a declarative rule covers the requirement — and criteria-based rules carry documented per-object limits that should be checked before committing to a design that needs many of them.

Exam section: Access to Records  ·  Difficulty: Easy

Correct answer: D. Explain that sharing rules only grant access, and identify what is currently granting it so the correct control can be applied

Sharing rules are additive only — there is no access level of None and no exclusion semantics. The productive response is to trace the actual grant: OWD, role hierarchy, an existing sharing rule, team membership, a manual share, or a View All permission each require a different remedy.

If the access must genuinely be subtracted while other grants remain in place, a restriction rule is the mechanism designed for it. Setting the OWD to Private (B) may or may not help — it does nothing if the access is coming from a sharing rule or a View All permission, which is why diagnosis comes before configuration.

Exam section: Access to Records  ·  Difficulty: Medium

Correct answer: C. It is removed, because manual shares are deleted when record ownership changes

Manual shares carry the row cause Manual and are deleted when the record's owner changes. Salesforce discards them on the reasoning that the new owner has not endorsed those grants.

This is the practical reason architects avoid manual sharing for anything that must persist. If a share needs to survive ownership changes, use Apex managed sharing with a custom sharing reason on a custom object, or an equivalent declarative rule keyed to record data rather than to a one-off decision.

Exam section: Access to Records  ·  Difficulty: Medium

Correct answer: B. An Apex managed share using a custom Apex sharing reason defined on the object

Apex managed sharing means inserting rows into the object's __Share table with a RowCause set to a custom Apex sharing reason defined on the custom object. Shares with a custom row cause are preserved across ownership changes and can be recalculated in bulk by an Apex sharing recalculation class.

A share row written from Apex with RowCause = Manual (A) behaves like any manual share and is deleted on owner change. The trigger option (D) would work in a narrow sense but re-creates a platform feature in fragile custom code. Note that custom Apex sharing reasons are available for custom objects only.

Exam section: Access to Records  ·  Difficulty: Hard

Correct answer: D. ParentId, UserOrGroupId, AccessLevel, and RowCause

Every share row identifies the record being shared (ParentId), the beneficiary — a user, public group, role group, or territory group (UserOrGroupId), the level of access granted (AccessLevel, typically Read or Edit), and why the share exists (RowCause).

Standard objects use named share tables such as AccountShare and OpportunityShare with the same shape, but several fields are renamed: the record reference takes the object name (AccountId) and so does the access level (AccountAccessLevel). AccountShare additionally carries per-child access columns such as CaseAccessLevel, ContactAccessLevel, and OpportunityAccessLevel. The RowCause is what drives whether a share survives an ownership change.

Exam section: Access to Records  ·  Difficulty: Medium

Correct answer: C. Account teams, with team members added per account by the owner

Account teams are designed for per-record, owner-managed collaboration: the owner adds named users to an individual account with a defined access level for Account, and optionally for related Cases, Contacts, and Opportunities.

A criteria-based rule (B) grants the same population to every matching record and cannot vary by account. An ownership-based rule (D) has the same problem. Manipulating the role hierarchy (A) to solve a per-record access need is a serious anti-pattern — it inflates hierarchy depth, affects reporting and forecasting, and grants far more than intended.

Exam section: Access to Records  ·  Difficulty: Medium

Correct answer: A. Default opportunity teams defined on each user's record

Each user can define a default opportunity team that is added automatically to opportunities they own. It is maintained per user, which suits an arrangement where a rep works with a consistent supporting cast.

A criteria-based rule (B) would grant the same group on every matching opportunity rather than the owner's own supporting users. A trigger (C) achieves it with unnecessary code. Territory management (D) shares based on territory assignment rules, not on the owner's personal working group.

Exam section: Access to Records  ·  Difficulty: Medium

Correct answer: B. Case teams, with predefined team roles that agents apply per case

Case teams let an agent add named users or contacts to an individual case with a defined role and access level, which matches a per-case, agent-driven decision. Predefined case teams can be applied in one step to reduce clicks.

A criteria-based sharing rule (C) is a reasonable alternative if the escalation population is the same every time — the requirement here is that it varies. Opening the OWD (D) grants everyone access to every case. Role hierarchy changes (A) grant far more than the requirement and distort reporting.

Exam section: Access to Records  ·  Difficulty: Medium

Correct answer: D. Read access to the parent Account, granted implicitly by the platform

This is implicit parent sharing. When a user gains access to a child record — Case, Contact, or Opportunity — the platform grants read-only access to the parent Account so the record is usable in context. It is generated by the platform and does not appear as a sharing rule.

Crucially, the implicit grant is read-only, which rules out (A), and covers only the parent Account and not its other children, which rules out (B). Implicit sharing rows also account for a large share of the sharing table volume in big orgs, which matters when estimating recalculation cost.

Exam section: Access to Records  ·  Difficulty: Hard

Correct answer: A. The role of the account owner, specifically the Opportunity Access setting on that role

Each role carries Contact Access, Opportunity Access, and Case Access settings that determine what the account owner can do with child records owned by other users. If Opportunity Access is set to No Access on that role, the account owner sees nothing, and no amount of Opportunity sharing rule tuning will explain the symptom.

This implicit child sharing is one of the most commonly missed behaviours on the exam and in practice, because the setting lives on the role rather than on the object. Grant Access Using Hierarchies (B) cannot be disabled for Opportunity anyway, and View All (C) would be a blunt over-grant even if it resolved the symptom.

Exam section: Access to Records  ·  Difficulty: Hard

Correct answer: C. Create a public group containing the roles, the territory, and the individual users, and share to that group

Public groups are containers that can hold users, roles, roles and subordinates, territories, and other public groups. Sharing to one well-named group keeps the rule count down and turns future membership changes into a group edit rather than a sharing rule change.

Four rules (B) multiply the maintenance burden and consume the object's sharing rule allocation. Queues (D) are for work distribution and record ownership, not for expressing a sharing audience. Restructuring roles to fit a sharing need (A) distorts the hierarchy and affects forecasting and reporting.

Exam section: Access to Records  ·  Difficulty: Easy

Correct answer: B. Access to the cases owned by the queue, because queue membership grants access to records the queue owns

A queue is a special kind of public group that can own records. Members of the queue get access to the records the queue owns, which is what lets them view the backlog and accept work from it.

No additional sharing rule is required for members to see records the queue owns, so no extra rule (D) is needed. Note the distinction that trips people up: queue membership gives access to records the queue owns; it does not give access to records owned by other members.

Exam section: Access to Records  ·  Difficulty: Easy

Correct answer: D. Sharing sets, which grant access based on the relationship between the community user's Account or Contact and the record

Customer Community is a high-volume license type: those users have no roles and cannot be used in sharing rules. Sharing sets exist for exactly this population — they grant access by matching a field on the record to the user's related Account or Contact.

Sharing rules (C) and role-based hierarchy designs (A) are not available for high-volume external users. Opening the external OWD (B) would expose every customer's records to every other customer, which is precisely the outcome the sharing set is designed to avoid.

Exam section: Access to Records  ·  Difficulty: Hard

Correct answer: C. A share group associated with the sharing set, containing the internal support users

High-volume community users sit outside the role hierarchy, so records they own do not roll up to anyone. A share group, defined on the sharing set, grants named internal users or groups access to records owned by that high-volume population.

An ownership-based sharing rule (D) requires the owner to have a role, which high-volume users do not. Hierarchy settings (A) cannot help for owners outside the hierarchy. View All on Case (B) would work but grants access to every case in the org, when the requirement is scoped to community-owned records.

Exam section: Access to Records  ·  Difficulty: Hard

Correct answer: B. Partner Community or Customer Community Plus, both of which support external roles and sharing rules

Partner Community and Customer Community Plus are role-based external licenses: each external account gets an account role hierarchy, records roll up within the partner account, and the users can be referenced in sharing rules and public groups.

Customer Community (A) is the high-volume license with no roles and no sharing rule participation — it cannot satisfy the hierarchy requirement. Salesforce Platform (C) is an internal license. Chatter External (D) provides no CRM record access at all. Confirm object entitlements per license against the current Salesforce license comparison before committing.

Exam section: Access to Records  ·  Difficulty: Medium

Correct answer: A. Keep the guest user's org-wide default at Private and create a guest user sharing rule granting read access to the listings

Under the secure guest user access model, the guest user's org-wide default is forced to Private and cannot be raised. Access is granted through guest user sharing rules, which grant Read only and are the sanctioned mechanism for exposing public data.

Guest users also cannot own records and cannot be added to public groups, queues, teams, or ordinary sharing rules, which rules out (D) and (B). Granting View All (C) to an unauthenticated profile is a serious over-grant and defeats the point of the model. Guest user sharing rules count against the object's criteria-based sharing rule allocation.

Exam section: Access to Records  ·  Difficulty: Hard

Correct answer: C. The access levels configured on the territory model for accounts, opportunities, cases, and contacts

Enterprise Territory Management shares records through territory assignment, and the access levels are configured on the territory type or model — separately for Accounts and for the child Opportunities, Cases, and Contacts. Territory groups appear as the beneficiary on the resulting share rows.

Territory sharing operates in addition to the role hierarchy, which rules out (B), and works with a restrictive OWD, which rules out (D) — in fact a restrictive OWD is what makes territory sharing meaningful. Territory shares are not implemented as criteria-based sharing rules (A).

Exam section: Access to Records  ·  Difficulty: Medium

Correct answer: A. Reports return only records the running user can access through the sharing model, and the director lacks record access

Folder access controls who can open a report; the sharing model controls which rows it returns. Two users with identical folder access will see different data if their record access differs, which is the intended behaviour.

The report scope option (B) is worth checking as a second-order cause — the report scope filter does change the row set — but the scope is a property of the report definition and would affect both users identically unless one of them has saved a personal variant. Folder access levels (D) and subscriptions (C) do not filter rows.

Exam section: Access to Other Data  ·  Difficulty: Medium

Correct answer: B. A dashboard configured to run as a specified user who has the required record access

A dashboard with a running user renders its components using that user's access, regardless of who is viewing. The viewer sees the aggregate figures without gaining any access to the underlying records.

This is powerful and correspondingly risky: it is a sanctioned way to expose aggregate data past the sharing model, so the running user should be a purpose-built, tightly governed account and the dashboard folder access should be treated as the real security boundary. A dynamic dashboard running as the logged-in user (A) shows each executive only their own access — the opposite of the requirement. The View All option (C) grants exactly the record access the requirement forbids.

Exam section: Access to Other Data  ·  Difficulty: Hard

Correct answer: D. The ContentDocumentLink record's ShareType, set to Viewer

Salesforce Files are shared through ContentDocumentLink records. ShareType determines the permission granted — Viewer, Collaborator, or Inferred (where access is derived from the linked record) — and Visibility controls whether the link is exposed to internal users, all users, or only shared users.

Files therefore have their own sharing surface that sits alongside the record sharing model, which is a common gap in security reviews: a file can be shared more widely than the record it was uploaded against. Sharing rules (B) do not apply to ContentDocument, and the record OWD (C) governs the Opportunity, not the file.

Exam section: Access to Other Data  ·  Difficulty: Hard

Correct answer: C. Data categories with category group visibility configured per profile or permission set

Knowledge visibility is driven by data categories. Articles are categorised, and each profile or permission set is given visibility over specific categories within a category group, so the same article type can serve internal and external audiences with different category assignments.

Channel settings (Internal App, Customer, Partner, Public Knowledge Base) provide a second, coarser layer of control over where an article is published. Record types (B) do not control visibility. Sharing rules (D) do not apply to Knowledge in this way, and hiding the body field (A) would leave the article discoverable with its title and metadata.

Exam section: Access to Other Data  ·  Difficulty: Medium

Correct answer: B. Big Objects have no record-level sharing; access is controlled through object and field permissions only

Big Objects deliberately omit the sharing model. There are no organization-wide defaults, sharing rules, manual shares, or share tables — a user who has object and field permissions can query the data, and one who does not cannot.

For an architect this means any per-record confidentiality requirement has to be met a different way: partition the data into separate Big Objects with different permission sets, filter access in a controlled Apex or Flow layer that users invoke instead of querying directly, or exclude sensitive attributes from the archive altogether.

Exam section: Access to Other Data  ·  Difficulty: Hard

Correct answer: A. List views are shared by selecting visibility for specific groups or roles when the list view is created or edited

A list view's visibility is set on the view itself: visible only to the creator, visible to all users, or visible to a chosen set of groups and roles. It is a separate control from record access.

It is worth being explicit with stakeholders that list view visibility is a convenience control, not a security control. Restricting the view does not restrict the data — a user who can see the records can build an equivalent view or query the same records through the API.

Exam section: Access to Other Data  ·  Difficulty: Easy

Correct answer: D. Whether Chatter feed tracking and the user's Chatter permissions and feed visibility settings are correctly configured, since record feed access follows record access but requires Chatter enablement

Feed items on a record follow the record's access — a user who can see the record can see its record feed — but only if the user is Chatter-enabled and feed tracking is configured. The described asymmetry between two users with identical record access points at user-level Chatter enablement rather than at sharing.

Following a record (B) affects what appears in the user's personal feed, not what is visible on the record itself. Raising the OWD (C) is unnecessary and unrelated. Note that posts made in a private Chatter group are governed by group membership, not by record sharing — a distinction worth confirming when the symptom involves group posts rather than record feeds.

Exam section: Access to Other Data  ·  Difficulty: Medium

Correct answer: A. Neither participates in record sharing; access depends on whether the type is public or protected and on the user's permissions, so neither should be used to store secrets

Custom settings and custom metadata types are configuration containers, not records in the sharing model. Public custom settings and custom metadata are readable by any user with the relevant access, including from Apex running in user mode, so they are unsuitable for secrets.

Hierarchy custom settings do support user- and profile-level values, but that is a data layering feature, not an access control — the values remain readable. For credentials and keys, use Named Credentials and External Credentials, or protected custom metadata accessed only from managed code, and verify the current guidance in the Salesforce security documentation.

Exam section: Access to Other Data  ·  Difficulty: Hard

Correct answer: B. Ownership skew; move the owning user out of the role hierarchy or distribute ownership across many users

Ownership skew is a large number of records owned by a single user. Because the role hierarchy grants access upward, every operation that changes that user's role or the hierarchy above them forces recalculation across all of those records.

The two accepted remedies are to distribute ownership across many users, or — where a single technical owner is genuinely required — to place that user outside the role hierarchy so there is no upward path to recalculate. Account data skew (A) is the related but distinct problem of too many children under one parent record.

Exam section: Implications of Security Model Choice  ·  Difficulty: Hard

Correct answer: D. Request deferred sharing calculation, load with automation minimised, then resume and recalculate sharing once

Deferred sharing calculation — enabled by Salesforce Support — suspends group membership and sharing rule recalculation during a large maintenance window, so the platform performs one recalculation at the end rather than continuously during the load.

Raising the OWD (C) changes who can see the data during the window and triggers a full recalculation both on the way up and on the way back down. Deleting and re-creating sharing rules (A) causes the same double recalculation and risks losing configuration. Random batch ordering (B) is the opposite of the guidance: batches should be sorted by parent Id to avoid lock contention.

Exam section: Implications of Security Model Choice  ·  Difficulty: Hard

Correct answer: C. Deep hierarchies increase sharing recalculation cost and complexity, and layers that exist only to grant record access are usually better expressed as public groups and sharing rules

A role hierarchy is a record-access mechanism, and every additional level multiplies the share rows the platform maintains and recalculates. Levels introduced purely to model an org chart — rather than to express a genuine record-access requirement — are cost without benefit.

The usual guidance is to keep the hierarchy as flat as the access requirements allow, model true reporting relationships elsewhere, and use public groups with sharing rules for cross-cutting access needs. Salesforce does document a maximum hierarchy depth, which should be checked against current limits, but the practical constraint is performance well before the documented ceiling.

Exam section: Implications of Security Model Choice  ·  Difficulty: Medium

Correct answer: D. Which standard objects those users need, since the Salesforce Platform license does not include Opportunity, Case, Lead, Campaign, or Forecast objects

License type constrains which standard objects a user can access at all, independent of profiles, permission sets, and sharing. The Salesforce Platform license covers custom objects along with Accounts, Contacts, Reports, Dashboards, and Documents, but excludes core CRM objects such as Opportunity, Case, Lead, Campaign, and Forecast.

No amount of sharing configuration overcomes a license restriction, which is why license analysis belongs at the start of a security design rather than at the end. Platform users do participate in the role hierarchy, public groups, and record ownership, so the other three statements (A) (B) (C) are all true and therefore not the concern. Always validate the current entitlements against the Salesforce license comparison before committing.

Exam section: Implications of Security Model Choice  ·  Difficulty: Medium

Correct answer: A. High-volume community license types have no roles and cannot be used in sharing rules, so sharing sets are required; role-based external licenses would work but at a very different cost and scale profile

The design conflates two different external license models. High-volume licenses such as Customer Community are built for exactly this scale but deliberately omit roles and sharing rule participation — access comes from sharing sets and share groups instead. Role-based licenses do support sharing rules, but an external role hierarchy at 90,000 users is a very different cost and performance proposition.

The architectural point is that external user scale and external sharing mechanism are a single joint decision, not two independent ones. Choosing the license first and discovering the sharing constraint later is a common and expensive sequencing mistake.

Exam section: Implications of Security Model Choice  ·  Difficulty: Hard

Correct answer: B. Build a test matrix of representative personas and expected record access, verify it with Apex tests using System.runAs and by querying UserRecordAccess, and confirm the results with business users in a full-copy sandbox

A sharing model is verified by evidence, not by inspection. A persona matrix states the expected outcome per role and record type; System.runAs exercises it in automated tests; the UserRecordAccess object answers whether a specific user can read, edit, or delete a specific record and why; and a full-copy sandbox exposes the volume and data-shape problems a developer org will not.

Administrator testing (A) proves nothing, because administrators bypass sharing. Reviewing configuration (C) confirms intent, not behaviour — it cannot catch interactions between implicit sharing, teams, and territory rules. Report counts (D) are a useful smoke test but do not isolate the cause of a discrepancy.

Exam section: Implications of Security Model Choice  ·  Difficulty: Medium

Correct answer: C. The record's Sharing and Sharing Hierarchy views, together with a query on the object's share table

The record's Sharing action lists who has access and at what level, and the Sharing Hierarchy view shows the access users derive through the role hierarchy. Querying OpportunityShare for the record completes the picture, because each row carries a RowCause that names the granting mechanism — Owner, Rule, Team, Territory, Manual, or an implicit cause.

UserRecordAccess complements this by answering the question from the user's side. The Setup Audit Trail (D) records configuration changes, Field Accessibility (A) diagnoses field visibility, and Health Check (B) scores security settings against a baseline — none of them explains a specific record grant.

Exam section: Implications of Security Model Choice  ·  Difficulty: Medium

Correct answer: C. Look for a way to collapse the conditions into fewer rules — for example a formula or classification field that maps many conditions onto a small set of values shared to public groups — and use Apex managed sharing only if the requirement genuinely cannot be normalised

Ninety conditions almost always means the requirement has not been normalised. Deriving a small classification field from the underlying conditions and sharing each classification value to a public group collapses the rule count dramatically, keeps it inside the documented per-object allocation for criteria-based rules, and makes the model comprehensible to whoever maintains it next.

Apex managed sharing remains the legitimate fallback when the logic genuinely cannot be expressed declaratively — but it brings recalculation classes, test coverage, and a long-term maintenance obligation, so it should follow a normalisation attempt rather than precede it. The Public Read Only option (D) inverts the model dangerously, and the ninety-groups option (A) does not reduce the underlying rule count.

Exam section: Implications of Security Model Choice  ·  Difficulty: Hard

Correct answer: D. The change triggers a large asynchronous sharing recalculation, so it should be scheduled in a maintenance window, tested in a full-copy sandbox, and paired with the sharing rules that restore legitimate access

Tightening an organization-wide default invalidates the sharing tables for the object and triggers recalculation proportional to data volume — potentially many hours in a large org, during which access is inconsistent.

The safe sequence is to model the change in a full-copy sandbox to measure duration and catch access regressions, prepare the sharing rules, teams, and permission sets that restore legitimate access before the cutover, execute in a maintenance window, and verify with the persona test matrix afterwards. The change is reversible (A), but reversing it triggers the same recalculation again.

Exam section: Implications of Security Model Choice  ·  Difficulty: Medium