Free Salesforce Plat-Arch-205 Practice Exam with Questions & Answers | Set: 2

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.

A file uploaded to Files Home is private by default until it is explicitly shared. Current Salesforce behavior allows the file owner and users with the powerful View All Data permission to access such private files. The ordinary role hierarchy does not automatically expose a private Salesforce File merely because another user is the owner ' s manager. Files have their own visibility and sharing model and should be evaluated separately from standard business-object sharing. View All Data is a very broad administrative permission and should not be granted merely to solve a file-sharing requirement; this question describes its effect, not a least-privilege recommendation. When collaboration is needed, the appropriate design is to share the file through the supported Salesforce Files mechanisms with the intended people, records, groups, or libraries. Study Guide reference: Access to Other Data - Salesforce Files, Files Home, private files, View All Data, file-sharing semantics, and least privilege.

This is an ownership data skew problem. Salesforce sharing performance degrades when a single user or queue owns an excessively large number of records of the same object because ownership is deeply involved in sharing calculations, role changes, group membership evaluation, transfers, and other access operations. A common design guideline is to avoid concentrating more than roughly ten thousand records of one object under a single owner when possible. Here, each donations representative owns more than fifty thousand donor Accounts, well beyond that threshold, and the organization has more than twenty million members overall. The problem is therefore structural, not simply a one-time recalculation event or an incorrect permission assignment. The architect should distribute ownership more evenly and, where concentration cannot be avoided, keep heavily skewed owners out of unnecessary roles and groups to reduce sharing complexity. Study Guide reference: Implications of Security Model Choice - ownership data skew, enterprise-scale sharing, Account ownership, role/group participation, and sharing performance.

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.

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.

When a sharing rule grants Opportunity access to members of a public group, the effective audience can also include managers above those group members through the role hierarchy. Salesforce can propagate access upward according to the group ' s Grant Access Using Hierarchies behavior and the object ' s normal hierarchy semantics. That is why the sales engineers in the public group and their managers can have access to the shared Opportunities. The reverse is not true: subordinates of a manager do not inherit records merely because the manager or another subordinate has access, and peer users in comparable roles do not automatically receive one another ' s shared records. Architects must account for this upward propagation when designing public groups for sensitive records because the effective audience may be broader than the explicit list of group members. Study Guide reference: Access to Records - Public Groups, sharing rules, Grant Access Using Hierarchies, upward access inheritance, and Private Opportunity OWD.

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.

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 requirement is limited to one object and requires universal visibility without edit access, so the least-privilege solution is a permission set that grants View All Records for Opportunity. View All Records bypasses record-sharing restrictions for that object only. View All Data is much broader because it bypasses sharing across essentially all objects, which would conflict with UC ' s privacy principle and expose more information than the reporting team needs. A permission set is preferable to changing a broad profile when only a few users require the elevation because it can be assigned and removed independently. View All Records does not itself grant edit permission; object CRUD and Field-Level Security still control what users can change and which fields they can access. This preserves the rest of the security model while ensuring the reporting team can see every Opportunity. Study Guide reference: Permissions to Standard Objects, Custom Objects, and Fields - View All Records, View All Data, permission sets, sharing overrides, and least privilege.

A Default Account Team is designed for sales representatives who repeatedly collaborate with the same internal specialists on customer Accounts. The representative can define recurring team members such as legal, engineering, or finance and specify the access each team member receives to the Account and, where applicable, related Opportunities and Cases. The default team can then be applied automatically to new or transferred Accounts or added to existing Accounts, eliminating the repetitive manual-sharing work described in the scenario. A criteria-based sharing rule is better suited to record access determined by stable record attributes and a fixed audience; it does not model a recurring collaboration team tied to a particular salesperson. View All Data would be dramatically overprivileged because it bypasses record-level controls across the organization. Default Account Teams therefore improve productivity while preserving least privilege and making the collaboration relationship explicit. Study Guide reference: Access to Records - Default Account Teams, team roles, related-record access, collaboration, and least-privilege sharing.