Free Practice Questions for Salesforce Plat-Arch-205 Exam

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.

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.

The decisive requirement is that temporary deal access must expire automatically at a known future date. Salesforce sharing mechanisms such as manual or Apex-created shares can grant the temporary access, but a standard share entry does not carry an automatic expiration date. A Scheduled Apex job can therefore implement the lifecycle requirement by running after the specified fiscal-year date and removing only the temporary shares that were created for this collaboration program. Apex sharing by itself describes how access could be granted but not how it expires, while a sharing rule is population-based and is poorly suited to temporary per-deal collaboration with individual expiration. A production design should mark the temporary grants in a reliable way so the scheduled process removes only those shares and leaves ownership, hierarchy, teams, and unrelated sharing intact. Study Guide reference: Access to Records - temporary record sharing, Apex/manual shares, scheduled revocation, share lifecycle, and least-privilege collaboration.

Field-Level Security is the appropriate control because the requirement concerns whether a user may see a sensitive field anywhere in Salesforce, not merely whether the field appears on one page layout. If the VIP Flag is hidden through FLS for non-authorized users, Salesforce can suppress that field across record pages, reports, list views, search results, APIs, and other interfaces according to the user ' s effective permissions. Removing the field from a page layout is only a presentation change and is not a reliable security boundary; a user who retains FLS could still reach the value through another surface. Record types likewise select business processes and page layouts but do not provide authoritative field confidentiality. The architect should therefore grant field visibility only to the Private Banking population, preferably through the organization ' s chosen profile/permission-set strategy, and keep the field hidden from everyone else. This follows the principle that sensitive information must be protected at the data-access layer rather than by cosmetic UI configuration. Study Guide reference: Permissions to Standard Objects, Custom Objects, and Fields - Field-Level Security, page layouts, record types, profiles, permission sets, and protection of sensitive fields.

Apex-managed sharing gives the development team substantial control over who receives record access, so it must be tested from the perspective of different users. System.runAs() is the appropriate test technique among the choices because it allows the test to execute sharing-sensitive behavior under representative user contexts and verify both positive and negative access outcomes. The test suite should include users who are supposed to receive access and users who must remain restricted, then confirm that the managed share entries produce exactly the intended visibility. A keyword such as without sharing would weaken record enforcement rather than validate it, and with sharing does not enforce Field-Level Security. In production code, record sharing, object CRUD, and FLS still have to be handled as separate concerns; runAs() simply provides a reliable way to exercise user-context behavior in tests. Study Guide reference: Access to Records - Apex-managed sharing, System.runAs(), Private OWD, user-context testing, and validation of least-privilege access.

The requirement follows a direct manager-to-subordinate relationship, so the role hierarchy is the native record-access mechanism. By placing the operations users below the operations manager and enabling Grant Access Using Hierarchies for the custom Scheduled Course object, Salesforce can automatically provide the manager access to records owned by those subordinate users. The manager must also have the necessary object-level Edit permission because hierarchy access cannot create object capability that the user lacks. A public group alone does not share records; it is simply a reusable collection that must be referenced by another sharing mechanism. An ownership-based sharing rule could create access, but it would duplicate a relationship already expressed by the hierarchy and add unnecessary maintenance across hundreds of regions. Study Guide reference: Access to Records - Role Hierarchy, Grant Access Using Hierarchies, custom-object sharing, manager access, and object permissions. 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.

Super User access is designed for selected external partner managers who need visibility across records associated with other users at the same partner account. Granting that elevated access to the individual partner manager is more scalable than creating and maintaining separate ownership-based sharing rules for every distributor. The requirement is deliberately limited to certain managers, so the organization can keep the external sharing model private between distributors while giving designated managers broader visibility within their own distributor organization. Sharing Sets are best suited to deterministic Account/Contact relationship mappings and do not replace the manager-level elevation represented by the Super User model. Because Super User access is powerful, it should be assigned only to users who genuinely need it and should be reviewed as part of the external-access governance process. Study Guide reference: Access to Records - Partner Community, Super User access, partner manager visibility, same-account external sharing, distributor isolation, and scalable Experience Cloud access.

The relevant Experience Cloud capability is Super User access, which gives selected external users broader visibility to records belonging to other users associated with the same external account. For Customer Community Plus, the modern terminology commonly used is Portal Super User; the answer choice uses the broader or legacy Partner Super User wording, but it represents the same architectural concept being tested. Delegated external-user administration focuses on managing external users rather than granting broad same-account Case visibility, and a generic community-administration permission is not the record-sharing mechanism required. Super User access should be assigned only to carefully selected agents because it materially expands what they can see within the distributor account. The organization ' s external OWD can remain restrictive between distributors while the elevated user receives the intended same-account visibility. Study Guide reference: Access to Records - Customer Community Plus, Super User access, same-account Case visibility, external-user administration, and Experience Cloud least privilege.