Praxis Academy
Home › Platform Administrator II › Security and Access

Platform Administrator II practice questions: Security and Access

Security and Access is 20% of the Salesforce Certified Platform Administrator II exam. It covers advanced sharing, restriction rules, territories and session security. Try these 7 free questions, then open each answer to see why every option is right or wrong.

01

In an org where the Opportunity OWD is Private, sales reps say they can view opportunities they do not own, even though no explicit sharing rule exists. The admin confirms 'Grant Access Using Hierarchies' is turned on. What best accounts for this access?

  1. With 'Grant Access Using Hierarchies' enabled, users in roles above a record's owner automatically receive at least read access to the records owned by users beneath them.
  2. During org setup, a manual sharing rule was generated automatically that gives every internal user read access.
  3. When no sharing rule exists, Opportunity records fall back to Public Read/Write, which overrides the Private OWD.
  4. The reps' profiles include the 'View All Data' system permission, which takes precedence over the OWD.
Show answer

Answer: A

A. With 'Grant Access Using Hierarchies' enabled, users in roles above a record's owner automatically receive at least read access to the records owned by users beneath them. ✓Correct. The role hierarchy passes record visibility upward, so users in higher roles see records owned by subordinates despite the Private OWD.
B. During org setup, a manual sharing rule was generated automatically that gives every internal user read access.Incorrect. Setting up an org never creates manual sharing automatically, so this is not where the access comes from.
C. When no sharing rule exists, Opportunity records fall back to Public Read/Write, which overrides the Private OWD.Incorrect. The absence of sharing rules does not change the OWD; the Private setting remains in effect.
D. The reps' profiles include the 'View All Data' system permission, which takes precedence over the OWD.Incorrect. 'View All Data' would grant visibility, but the admin traced the access to 'Grant Access Using Hierarchies', not to a profile permission.

Why: For objects whose OWD is Private or Public Read Only, 'Grant Access Using Hierarchies' opens records up to users who sit higher in the role hierarchy than the owner. It is always on for standard objects and can be switched off only for custom objects, in which case access is limited to the owner and anyone the record is explicitly shared with.

02

An object holding sensitive financial details has a Public Read Only OWD, yet the financial data must be visible only to users in the 'Finance' role and above in the role hierarchy. Which approach correctly enforces this?

  1. Switch the object's OWD to Private and add a role-based sharing rule that shares records with the 'Finance' role and its subordinates.
  2. Leave the OWD at Public Read Only and use Field-Level Security to hide the sensitive financial fields from every profile except the Finance profile.
  3. Add a Criteria-Based Sharing Rule that gives the 'Finance' role access to records meeting a financial-sensitivity criterion.
  4. Turn on Shield Platform Encryption for the financial fields and give decryption keys only to the Finance profile.
Show answer

Answer: B

A. Switch the object's OWD to Private and add a role-based sharing rule that shares records with the 'Finance' role and its subordinates.Incorrect. Moving to Private plus a Finance sharing rule changes record access for everyone; the requirement concerns sensitive data inside records that are meant to stay broadly readable.
B. Leave the OWD at Public Read Only and use Field-Level Security to hide the sensitive financial fields from every profile except the Finance profile. ✓Correct. Record access is already open to all, so FLS is the right control: hide the sensitive fields from every profile except Finance.
C. Add a Criteria-Based Sharing Rule that gives the 'Finance' role access to records meeting a financial-sensitivity criterion.Incorrect. Sharing rules only add access; they cannot take away the read access Public Read Only already provides.
D. Turn on Shield Platform Encryption for the financial fields and give decryption keys only to the Finance profile.Incorrect. Shield Platform Encryption protects data at rest for compliance; it is not a profile-based access control, and anyone with field visibility can still read the values.

Why: Salesforce security works on two layers: record access (OWD, sharing rules, role hierarchy) and field access (Field-Level Security). When everyone can already see the records under Public Read Only, hiding specific data calls for FLS. Making the financial fields hidden for non-Finance profiles lets other users open the record without seeing those values.

03

The Contacts OWD is Private, yet users with the 'Contractor' profile can see every contact. The admin checks the sharing rules and finds none that would grant this. What is the most probable cause?

  1. A public group named 'All Contractors' was created automatically and included in a sharing rule that exposes Contacts.
  2. Because the related Account OWD is Public Read/Write, the Private Contact OWD is overridden and Contacts inherit account-level access.
  3. Contractor users hold the top role in the role hierarchy, which automatically shows them every record beneath them.
  4. The Contractor profile has the 'Read All' object permission on Contact enabled, which bypasses the OWD for that object.
Show answer

Answer: D

A. A public group named 'All Contractors' was created automatically and included in a sharing rule that exposes Contacts.Incorrect. Salesforce never creates public groups or sharing rules for profiles on its own, and the admin's review found no such rule.
B. Because the related Account OWD is Public Read/Write, the Private Contact OWD is overridden and Contacts inherit account-level access.Incorrect. A Private Contact OWD is independent of the Account OWD; inheritance happens only when Contact is set to 'Controlled by Parent', which is a different setting.
C. Contractor users hold the top role in the role hierarchy, which automatically shows them every record beneath them.Incorrect. Nothing suggests Contractor users hold a high role, and hierarchy access would cover only records owned by users in lower roles.
D. The Contractor profile has the 'Read All' object permission on Contact enabled, which bypasses the OWD for that object. ✓Correct. An object-level 'View All' style permission on Contact for the Contractor profile would give access to every contact regardless of OWD or sharing, which matches what the admin sees.

Why: An object permission such as 'View All' on a profile or permission set ignores OWD and sharing for that object and gives read access to every record. When a Private OWD does not match what users actually see, the profile's object settings are the first thing to check. Such permissions should be tightly governed because they sidestep the sharing model.

04

An admin builds a Login Flow that runs when users sign in from outside the corporate network, including a Screen Flow step that gathers extra verification details. Afterward, some users get around it by connecting through the API. Why does this happen?

  1. API access needs its own Login Flow, which must be set up specifically for API users in the API-only Login Flow settings.
  2. The Login Flow was not saved properly; Login Flow changes need a page cache clear before they apply to API users.
  3. Login Flows apply only to UI logins; API access skips them by design because API sessions cannot run interactive, screen-based verification steps.
  4. The users who skip the flow are using a Connected App with the 'Bypass Login Flow' permission enabled, which must be turned off.
Show answer

Answer: C

A. API access needs its own Login Flow, which must be set up specifically for API users in the API-only Login Flow settings.Incorrect. No 'API-only Login Flow settings' exist; Login Flows are UI-only by design.
B. The Login Flow was not saved properly; Login Flow changes need a page cache clear before they apply to API users.Incorrect. The behavior is intentional for API sessions, not a save or cache problem.
C. Login Flows apply only to UI logins; API access skips them by design because API sessions cannot run interactive, screen-based verification steps. ✓Correct. SOAP/REST calls using OAuth tokens never hit the Login Flow because API sessions cannot render screens, a design trait admins must plan around.
D. The users who skip the flow are using a Connected App with the 'Bypass Login Flow' permission enabled, which must be turned off.Incorrect. Connected App settings can influence sessions, but the root cause is the platform design, not a 'Bypass Login Flow' permission.

Why: Login Flows run only for interactive, browser-based logins. API clients authenticate with OAuth tokens or username-password API calls and cannot display screens, so they never pass through a Login Flow. To control API access, admins rely on IP restrictions, Connected App OAuth policies and other API-specific controls.

05

In an org with 5,000 users in several countries, an admin reviewing profiles notices that many users hold the 'Manage Users' permission without needing it. What risk does that create?

  1. Users with 'Manage Users' can create, edit, deactivate and delete user records, reset passwords and change role and profile assignments, which could let them give themselves or others elevated access.
  2. Users with 'Manage Users' can see all org data regardless of OWD or sharing rules, because the permission implicitly includes 'View All Data.'
  3. Users with 'Manage Users' can change Governor Limits and Apex execution settings, which creates a development risk.
  4. Users with 'Manage Users' can delete every record in the org, because the permission includes 'Modify All Data.'
Show answer

Answer: A

A. Users with 'Manage Users' can create, edit, deactivate and delete user records, reset passwords and change role and profile assignments, which could let them give themselves or others elevated access. ✓Correct. Because the permission controls user setup, role and profile assignment and permission sets, misuse could escalate privileges or create unauthorized accounts.
B. Users with 'Manage Users' can see all org data regardless of OWD or sharing rules, because the permission implicitly includes 'View All Data.'Incorrect. 'Manage Users' covers user configuration, not access to object data.
C. Users with 'Manage Users' can change Governor Limits and Apex execution settings, which creates a development risk.Incorrect. Governor Limits are platform-enforced and cannot be changed by any admin permission, including 'Manage Users'.
D. Users with 'Manage Users' can delete every record in the org, because the permission includes 'Modify All Data.'Incorrect. 'Modify All Data' is a separate permission; 'Manage Users' does not include it.

Why: 'Manage Users' is a powerful system permission: holders can create and edit users, reset passwords, deactivate accounts, and assign roles, profiles and permission sets, effectively deciding who can access what. Handing it out broadly invites privilege escalation, so it should be limited to designated administrators.

06

An employee is about to leave the company. The admin must block that person's access to Salesforce while keeping all of their records and data available for reassignment. What should the admin do?

  1. Delete the employee's Salesforce user record to end access and release all associated licenses immediately.
  2. Deactivate the user record in Salesforce, which immediately prevents login while preserving all records owned by the user and freeing the license for reallocation.
  3. Strip the employee of every permission set and the profile, leaving the account active but without access to any Salesforce features.
  4. Freeze the user account for now instead of deactivating it, giving time to reassign data before access is ended permanently.
Show answer

Answer: B

A. Delete the employee's Salesforce user record to end access and release all associated licenses immediately.Incorrect. User records cannot be deleted in Salesforce; deactivation is the supported process.
B. Deactivate the user record in Salesforce, which immediately prevents login while preserving all records owned by the user and freeing the license for reallocation. ✓Correct. Deactivating blocks login right away, keeps everything the user owned, and frees the license; records can be reassigned with Mass Transfer Records.
C. Strip the employee of every permission set and the profile, leaving the account active but without access to any Salesforce features.Incorrect. Profile is a required field on the user record, and leaving the account active still leaves a possible way in.
D. Freeze the user account for now instead of deactivating it, giving time to reassign data before access is ended permanently.Incorrect. Freezing blocks login only temporarily and keeps the license in use; for someone leaving, deactivation is the proper permanent step.

Why: Deactivation is the standard offboarding step: login stops at once, all records, history and data the user owned remain, and the license becomes available for someone else. Those records can then be moved with Mass Transfer Records in Setup. Users cannot be deleted, only deactivated.

07

Cases have a Private OWD. A group of external partners using an Experience Cloud site must be able to view Cases linked to their own Account. Which sharing mechanism is most appropriate for giving these partners access to related Cases?

  1. Build a Criteria-Based Sharing Rule that shares Cases with the partner community profile whenever the Case Account matches the partner's Account.
  2. Configure a Sharing Set for the Experience Cloud site that grants Case access to external users based on the Account field on the Case matching the partner user's Account.
  3. Put all partner users in a public group and create an owner-based sharing rule that shares every Case owned by accounts in the partner community.
  4. Change the Case OWD to Public Read Only so every user, partners included, can view all Cases in the org.
Show answer

Answer: B

A. Build a Criteria-Based Sharing Rule that shares Cases with the partner community profile whenever the Case Account matches the partner's Account.Incorrect. Criteria-based rules cannot compare a Case field to each partner's own Account, so they cannot scope access dynamically per partner.
B. Configure a Sharing Set for the Experience Cloud site that grants Case access to external users based on the Account field on the Case matching the partner user's Account. ✓Correct. A Sharing Set matches the Case's Account lookup to the external user's Account, so each partner sees only Cases for its own Account.
C. Put all partner users in a public group and create an owner-based sharing rule that shares every Case owned by accounts in the partner community.Incorrect. Owner-based rules share by record owner, not by a related Account field, so they cannot limit each partner to its own Cases.
D. Change the Case OWD to Public Read Only so every user, partners included, can view all Cases in the org.Incorrect. A Public Read Only OWD would expose every Case to every partner, a serious privacy breach.

Why: Sharing Sets are an Experience Cloud feature that gives external users access to records when a lookup on the record, such as Account on Case, matches the external user's own Account or Contact. They scope access per account dynamically and are the standard approach for this kind of portal sharing.

Find out if you're ready to pass

Take the free Platform Administrator II diagnostic: 20 questions, no account needed. Then unlock all 180 questions, full practice exams and the study guide.

Start the free diagnosticSee plans

Other sections of this exam