Salesforce Plat-Arch-205 Salesforce Certified Platform Sharing and Visibility Architect Exam Practice Test

Granular Locking is the platform capability associated with reducing group-membership lock contention during large changes to roles, groups, territories, and related sharing structures. A major role hierarchy realignment can cause many concurrent operations to update group membership and sharing tables. Without sufficiently granular locking, unrelated changes can be serialized behind broad locks, increasing the probability of contention and long-running maintenance operations. Granular locking narrows the scope of locks so unrelated hierarchy branches and group structures can be processed more independently where the relationships allow it. Divisions serve a different purpose: they partition data for organizational and reporting needs but do not solve group-membership locking during hierarchy maintenance. Skinny tables are database-performance optimizations and are unrelated to access recalculation. For enterprise-scale realignments, architects should also plan maintenance windows carefully and avoid overlapping major sharing, territory, role, and user-provisioning operations. Study Guide reference: Implications of Security Model Choice - enterprise-scale sharing, role hierarchy maintenance, group-membership locking, granular locking, and access-model performance.

Large changes to roles, ownership, OWD, and sharing rules can force Salesforce to recalculate very large numbers of sharing rows. In an organization with a complex hierarchy spanning many regions and countries, that recalculation can become a major operational event. Parallel sharing recalculation is the relevant capability because Salesforce can process eligible portions of the sharing recalculation workload concurrently instead of treating the entire job as one serial operation. Divisions are primarily a data-partitioning and reporting feature; they do not optimize access recalculation. Skinny tables are database-query performance structures and likewise do not address the sharing model. The architect should also recognize that Account sharing changes can cascade into related Contacts, Opportunities, and Cases through implicit sharing relationships, increasing the scale of the work. Major hierarchy and ownership reorganizations therefore require planned maintenance, monitoring of background sharing jobs, and a design that limits unnecessary complexity in the role and group model. Study Guide reference: Implications of Security Model Choice - enterprise-scale sharing, hierarchy changes, ownership realignment, parallel recalculation, and sharing performance.

Public Read-Only is the correct Lead OWD because it balances duplicate prevention with ownership-based editing. Users can see existing Lead records across the organization, which helps them identify whether a prospect already exists before creating another Lead, but they cannot edit another user ' s Lead merely because they can view it. A Private OWD would protect ownership more strictly but would undermine the duplicate-reduction objective because users might not be able to discover Leads owned elsewhere. Public Read/Write/Transfer would go too far in the opposite direction by allowing broader modification or reassignment than the requirement permits. The organization can complement the OWD with Duplicate Rules and Matching Rules for stronger prevention and warning behavior, but the OWD still establishes the right record-visibility baseline. Study Guide reference: Access to Records - Lead OWD, Public Read-Only, record ownership, duplicate prevention, and least-privilege access. The implementation should also be validated with representative users so effective permissions, sharing inheritance, and any cross-object access behave exactly as designed before production release.

View All Records is an object-specific sharing override. Granting View All on Case lets the service representative see every Case regardless of the Case OWD, but it does not automatically grant the same access to Account or other related standard objects. Each object still requires its own object permission and record-access path. This is an important distinction from normal implicit sharing: Salesforce does not treat a broad View All grant on the child object as though the user had individually received each child record through ownership or a normal share, so the expected parent access must be evaluated separately. If Contact is Controlled by Parent, Contact visibility depends on the user ' s access to the parent Account. The architect must therefore design Account access explicitly rather than assuming that universal Case visibility cascades through the customer data model. Study Guide reference: Access to Records - View All Records, object-specific sharing overrides, Account/Case relationships, Controlled by Parent, and Private OWD.

The security defect is field-level write authorization, not record-level sharing. Apex can execute with elevated behavior, so code that performs DML must explicitly respect whether the running user is allowed to update the fields being changed. The Schema Describe check represented by isUpdateable() verifies field update permission before DML and directly addresses the Read-Only Field-Level Security condition in the scenario. By contrast, the with sharing keyword controls record visibility through the sharing model; it does not itself enforce object CRUD or Field-Level Security. Moving the same logic into another with sharing class therefore would not stop a field from being updated when the user lacks field edit permission. In modern Salesforce development, user-mode database operations and Security.stripInaccessible() can provide broader and often simpler enforcement of CRUD and FLS, but the explicit isUpdateable() check remains technically valid for the option set given. The architectural rule is to evaluate object permissions, field permissions, and record sharing as separate layers. Study Guide reference: Permissions to Standard Objects, Custom Objects, and Fields - CRUD, Field-Level Security, secure Apex, Schema Describe checks, and user-mode operations.

Dynamic Forms is the most maintainable solution for an object with hundreds of fields and several distinct business processes. It allows the Lightning record page to be decomposed into individual fields and field sections, then uses visibility rules to show only the information relevant to the current Work Order or Case type. Record Type can be used as the controlling condition so one governed Lightning page supports multiple process variants without multiplying page layouts or introducing custom LWC code. A custom override with metadata would create unnecessary development and maintenance overhead for behavior the platform can provide declaratively. Separate page layouts per type can work, but with hundreds of fields they become harder to govern and often duplicate large portions of configuration. Dynamic Forms is therefore the declarative-first architecture. The architect must still enforce sensitive-data restrictions through Field-Level Security because conditional page visibility is not an authorization control. Study Guide reference: Implications of Security Model Choice - Dynamic Forms, Record Types, field sections, component visibility, large-field-count page design, and UI visibility versus FLS.

A sharing rule can extend record-level access only after the user has the fundamental object permission required to use the object. The affected users have no Read permission on Account, so membership in a public group and a sharing rule that exposes inactive Accounts cannot make those records visible. Salesforce evaluates security in layers: the license and object permissions establish whether a user can use an object at all; Field-Level Security controls individual fields; and record-level mechanisms such as OWD, role hierarchy, sharing rules, teams, and manual sharing determine which records are available. A page layout does not grant record or object access, and the position of the Account owner in the role hierarchy is irrelevant when the user ' s profile prevents Account access entirely. The administrator must first grant appropriate Account Read permission through the profile or a permission set, then allow the sharing rule to determine which Accounts the user can reach. Study Guide reference: Permissions to Standard Objects, Custom Objects, and Fields - object CRUD, profiles, permission sets, interaction between object permission and record sharing, and layered security evaluation.

An Opportunity Team is specifically designed for multiple internal users who collaborate on an individual sales deal. The owner can add specialists such as product, solution, legal, or finance participants, assign each member a team role, and grant the appropriate Read Only or Read/Write access to that Opportunity. This is more maintainable than ad hoc manual sharing because the collaboration relationship is explicitly modeled as part of the sales process. The expected Account or Opportunity ownership change is also important: Salesforce provides options to retain the team when ownership changes, allowing the collaboration structure to continue through reassignment. Manual sharing of the Account would be unnecessarily broad because the requirement is to collaborate on one Opportunity, not to expose all customer information. Opportunity Teams therefore provide the correct scope, governance, and business semantics for a private Opportunity model. Study Guide reference: Access to Records - Opportunity Teams, team access levels, ownership changes, Private OWD, and collaborative sales access.

The Partner Community role hierarchy naturally models the relationship between service agents and their dealer manager. Agents can occupy a lower partner role and the dealer manager a higher role within the same partner account, allowing record visibility to roll upward while users at the same lower level remain isolated from one another under a Private sharing model. This is more efficient than creating a separate sharing rule for every dealer-manager relationship because the management structure itself already expresses who should inherit access. A sharing group is associated with other Experience Cloud access patterns and does not replace the partner role hierarchy for this requirement. The architect should ensure that the partner roles are correctly assigned and that the underlying Case object permissions support the access the manager needs. Study Guide reference: Access to Records - Partner Community roles, external role hierarchy, Private Case sharing, manager access, and scalable Experience Cloud design.

Among the supplied choices, cloning the Sales Rep profile is the only option that can both grant the pilot functionality and remove legacy functionality for only the selected users. Salesforce permissions are additive: a normal permission set can grant more access, but it cannot negate an existing permission already supplied by the user ' s profile or another permission set. Option B would revoke legacy access from the shared Sales Rep profile and therefore affect the entire sales population, not just the pilot. Option C can add access to the new application, but a standalone permission set cannot hide functionality that the users already receive elsewhere. In a modern design, permission set groups with muting can provide a more composable persona model, but that architecture is not one of the available choices. For the stated options, the separate profile gives the pilot population an independently controlled baseline. Study Guide reference: Permissions to Standard Objects, Custom Objects, and Fields - profiles, permission sets, additive permissions, pilot access strategies, and permission-set-group concepts.

The requirement cuts horizontally across a role hierarchy that is intentionally organized by country, so the solution belongs in the sharing-rule layer rather than in a redesign of the hierarchy. A sharing rule can open the relevant Accounts to sales managers in other countries without collapsing distinct regional roles. Among the supplied choices, the owner-based sharing-rule option represents the correct architectural family. If the business condition is literally based on an Account Segment field, a criteria-based sharing rule would be the more precise Salesforce mechanism because criteria-based rules select records by field values whereas owner-based rules select records by the owner ' s role or group. A permission set cannot grant access to selected Account records, and a public group contains users rather than Account records. Putting U.S. and Canadian managers in the same role would not cause peers to inherit one another ' s records and would distort the hierarchy ' s organizational meaning. Study Guide reference: Access to Records - cross-hierarchy sharing, owner-based versus criteria-based rules, roles, public groups, and record-level access.

Private is the correct organization-wide default because at least one population must be prevented from seeing a subset of Account records. Salesforce sharing is additive: once an OWD grants broad access, sharing rules cannot be used to take that access away for a particular group. Starting with Private creates the restrictive baseline needed to keep Prospect Accounts hidden from Service users. UC can then grant Read access to all Accounts for the sales population, let ownership give sales users edit access to their own Accounts, and use the role hierarchy so sales managers inherit the appropriate access to records owned by their team. Service users can receive Read access only to the non-Prospect Accounts through an appropriately designed sharing rule. Public Read/Write or Public Read/Transfer would establish an access baseline that is already broader than the requirements allow and therefore could not be corrected through ordinary sharing rules. Study Guide reference: Access to Records - OWD design, Private baseline, additive sharing, role hierarchy, criteria-based sharing, and least privilege.

Read/Write Opportunity Team access allows the team member to edit the Opportunity record, assuming the user also has the necessary object- and field-level permissions. Updating a normal Opportunity field such as Stage therefore falls within the access granted by the team membership. Ownership transfer is a separate privilege and is not automatically granted merely because a user can edit the record. Likewise, being a member of the Opportunity Team does not necessarily give the user authority to add or remove other team members; team administration is controlled by ownership and applicable administrative permissions. This distinction reflects Salesforce ' s layered security model: Opportunity Team membership supplies record access, while object permissions and ownership-related privileges govern what operations the user can perform. The owner always has the broadest control over the Opportunity and can manage collaboration more extensively than an ordinary team member. Study Guide reference: Access to Records - Opportunity Teams, Read/Write access, ownership, team administration, and collaborative sales security.

Dynamic Forms is the declarative solution for adapting record presentation without replacing the standard Salesforce page with custom Visualforce or Lightning code. It allows administrators to place fields and field sections individually on a Lightning record page and apply visibility rules based on record context or supported device conditions. That is a better fit for form-factor and alignment problems than maintaining custom view-action overrides that detect devices and route users to different layouts. The declarative approach reduces code ownership, regression risk, testing effort, and long-term maintenance while preserving the standard Salesforce record experience. Where the requirement is driven by record type, the same mechanism can show different field sections for different business processes. The architect must still remember that Dynamic Forms controls presentation rather than security: fields that are hidden by component visibility can still be available through reports, list views, APIs, or other interfaces if Field-Level Security grants access. Sensitive information therefore still requires proper FLS. Study Guide reference: Implications of Security Model Choice - Dynamic Forms, Lightning App Builder, component visibility, record types, device form factors, maintainability, and UI visibility versus security.

System.runAs() is used in Apex tests to execute a block of code in the context of a specified user so that user-dependent record-sharing behavior can be verified. It is particularly useful when the application relies on a Private OWD, role hierarchy, manual or managed shares, or classes declared with sharing. A well-designed test creates representative users, runs the relevant code under those users, and confirms that authorized users can retrieve the intended records while unauthorized users cannot. The key distinction is that runAs() is not itself a production security mechanism and does not replace explicit enforcement of CRUD or Field-Level Security. Object permissions, field permissions, and record sharing remain separate layers that the implementation must enforce appropriately. This question therefore focuses on the sharing aspect of user context rather than on field-level authorization. Study Guide reference: Access to Records - Apex sharing tests, System.runAs(), user context, record visibility, and secure testing of sharing behavior.

Deferred Sharing Calculation is intended for major administrative changes that would otherwise cause Salesforce to repeatedly recalculate sharing while the organization is still in an intermediate state. During a large role hierarchy restructuring and mass Account ownership realignment, each individual change can affect group membership and record access. With deferred calculation enabled, administrators can suspend automatic calculation while they perform the planned restructuring and then explicitly resume and recalculate after the final model is in place. This reduces repeated work and can materially improve the operational stability of a very large reorganization. The capability must be governed carefully because access changes made while calculation is suspended are not reflected until the recalculation is completed. Skinny tables solve a different database-performance problem, and Divisions partition data but do not prevent repeated sharing recalculations. Study Guide reference: Implications of Security Model Choice - Deferred Sharing Calculation, large organizational changes, role and ownership maintenance, sharing recalculation, and operational governance.

For custom objects, a dedicated Apex Sharing Reason should be used when programmatic shares must survive a change of record owner. Apex-managed shares that use a custom sharing reason are designed to represent access granted by business logic independently of ownership. A share created with RowCause Manual is different: manual shares can be removed when ownership changes, so they are not reliable for persistent application-managed access. The with sharing keyword also does not control the persistence of share-table rows; it controls whether Apex respects the current record-sharing model when executing queries and DML. A custom sharing reason has an additional operational advantage because it gives the application a stable way to identify, update, or remove only the shares created for that business process. Study Guide reference: Access to Records - Apex-managed sharing, Apex Sharing Reasons, RowCause, ownership changes, and custom-object share lifecycle. The implementation should also be validated with representative users so effective permissions, sharing inheritance, and any cross-object access behave exactly as designed before production release.

A criteria-based Account sharing rule is appropriate because the desired access is determined by a property of the Account record: whether the record represents a retail Person Account. With Account OWD set to Private, UC can keep Business Accounts restricted and automatically grant the Retail Sales role access to all Accounts that meet the Person Account criterion. An owner-based rule on AccountContactRelation addresses a different relationship and would not provide the required Account visibility. Granting access to a Person Account record type on a profile also does not make every existing Person Account visible; record-type access controls which record types users can create or use, not which records they can see. The architect therefore needs a record-level sharing rule tied to the Account ' s Person Account characteristic. Study Guide reference: Access to Records - criteria-based sharing rules, Person Accounts, Record Types, Account OWD, and distinction between record-type availability and record visibility.

The valid runtime mechanism among the choices is declaring the Apex class with sharing so Salesforce evaluates record-level sharing when the class queries Shipment records. Because the Shipment OWD is Private, Apex that ignores sharing can expose records outside the user ' s intended visibility. The sensitive Shipment Amount introduces a second security layer: with sharing does not enforce object CRUD or Field-Level Security. The implementation must separately enforce field access, for example with user-mode operations, Security.stripInaccessible(), or valid Schema Describe checks. System.runAs() is useful for tests but does not secure production execution, and isShareable is not a valid Apex sharing keyword. The correct architecture therefore combines record-sharing enforcement with explicit CRUD/FLS enforcement instead of assuming one mechanism protects every layer. Study Guide reference: Permissions to Standard Objects, Custom Objects, and Fields - with sharing, Apex execution context, CRUD/FLS, user-mode operations, and secure Lightning/Apex architecture. The implementation should also be validated with representative users so effective permissions, sharing inheritance, and any cross-object access behave exactly as designed before production release.

The reporting permissions represented by the answer are Manage Reports in Public Folders and Edit My Reports. Under Salesforce ' s enhanced folder-sharing model, Manage Reports in Public Folders is a broad reporting permission that includes the ability to create and manage public report content and encompasses several lower-level reporting capabilities. The question is testing the permission combination required to create, organize, and share report-folder content with other coaches rather than merely run reports. Architects should still apply least privilege: if a user needs management rights only to one specific folder, granting Manager access to that folder can be safer than assigning an organization-wide reporting management permission. The key distinction is that report-folder permissions govern analytics assets, while access to the underlying business records remains controlled by the normal object, field, and record-security model. Study Guide reference: Access to Other Data - report-folder permissions, enhanced folder sharing, Manage Reports in Public Folders, Edit My Reports, and least-privilege analytics administration.

Account Teams are designed to model collaboration around an Account while allowing different access levels to the Account and its related Opportunities and Cases. UC can give the sales associate Read access to the Account, Read access to related Cases, and no general Opportunity access through the team configuration. If the associate later needs access to a particular Opportunity, that record can be opened separately through an Opportunity Team or another appropriate sharing mechanism. Introducing separate Case Teams or sharing rules would duplicate functionality that the Account Team already provides for this collaboration model. The design also preserves the Private OWD, because access is granted only to the users explicitly added to the team. Object permissions still apply independently, so the sales associate must have the required object-level Read permission before the team access can be effective. Study Guide reference: Access to Records - Account Teams, related Opportunity and Case access, team roles, Private OWD, and least-privilege collaboration.

Partner Community is the appropriate external license model because the distributors participate in a B2B sales process and require Opportunity visibility. Partner-oriented licenses support the external role hierarchy and the sales-object collaboration model needed for channel users such as distributors and resellers. Customer Community is primarily aimed at high-volume customer self-service and does not provide the same Opportunity-oriented partner model. Customer Community Plus adds more advanced sharing than basic Customer Community, but it is not the primary licensing model for external channel sales collaboration. At the scale described, the architect must also design the partner role hierarchy and external sharing model carefully so that one distributor cannot see another distributor ' s records and so that role/group proliferation does not create unnecessary sharing complexity. The license defines the ceiling of what the external user can do; UC must still configure object permissions and record-level sharing to expose only the Opportunities relevant to each distributor. Study Guide reference: Access to Records - Experience Cloud licensing, Partner Community, Opportunity access, partner roles, external sales collaboration, and scalable partner sharing.

Salesforce Content Deliveries are designed to distribute files externally through generated links and include an option to require a password before the recipient can access the content. That directly satisfies the CISO ' s requirement without adding a third-party product or building an Experience Cloud site solely for file delivery. A content delivery can provide a controlled external URL while the password is communicated separately to the customer. Administrators can also establish organization-level policies for content-delivery password behavior so the security requirement is applied consistently. An Experience Cloud site would introduce identity, licensing, and site-management overhead that is unnecessary when the business simply needs to send a protected file link. The architect should still consider the sensitivity of the content, expiration requirements, and broader information-governance policy when deciding whether content delivery is appropriate for a particular file. Study Guide reference: Access to Other Data - Salesforce Files, Content Deliveries, external file access, password protection, and secure content distribution.

Because the Account page layout did not change, the next control to inspect is Field-Level Security and effective field accessibility. Salesforce can hide a field from a user even when that field remains present on the assigned page layout. The Field Accessibility view in Object Manager provides a consolidated way to determine whether a field is visible, read-only, or hidden for the relevant profile and configuration. This is a better diagnostic than logging in and checking several records because the symptom is field-level, not record-specific. A Who Sees What analysis focuses on record visibility and therefore does not explain why one field disappeared while the user can still open the Account. The administrator should verify the affected field ' s FLS for the user ' s profile and any relevant permission-set assignments, then confirm that the page layout and record type do not impose additional presentation restrictions. Field-Level Security is the enforceable security boundary; page layout placement alone is not. Study Guide reference: Permissions to Standard Objects, Custom Objects, and Fields - Field-Level Security, field accessibility, profiles, permission sets, and page layouts.

The requirement is an authorization requirement, not merely a page-design preference. Removing the Work Order Edit object permission from the Sales Representative permission model prevents those users from updating Work Orders regardless of which UI, API, automation entry point, or page layout they use. Page layouts can make fields appear read-only, but they are presentation controls and should not be relied on as the security boundary. A sharing rule is also the wrong tool because sharing rules add record-level access; they do not reduce the CRUD capabilities a user already has. In a modern Salesforce permission architecture, the organization should remove Edit from the relevant profile or baseline permission set and verify that no other assigned permission set or permission set group grants it back, because permissions are additive. The page can still be configured to present an appropriate read-only experience, but enforcement belongs at the object-permission layer. Study Guide reference: Permissions to Standard Objects, Custom Objects, and Fields - object CRUD, profiles, permission sets, page-layout limitations, and least-privilege authorization.