SALESFORCE ADMINISTRATOR MIDTERM EXAMINATION Complete Practice
Test Bank – 75 Questions & Detailed Rationales Covers Core Certification
Topics: Security, Data Model, Automation, Reports, and Lightning
Experience Practice Questions with Verified Answers & Detailed Rationales
| Comprehensive Test Bank for ADM-201 | Guaranteed Success
EXAM INSTRUCTIONS
- This midterm examination consists of 75 multiple-choice questions**.
- Each question has four or five answer choices (A–E)**.
- Select the single best answer for each question.
- Questions are based on Salesforce Spring '26 and Winter '27 releases.
- Time suggested: **90 minutes** (approximately 1.2 minutes per
question).
SECTION 1: SECURITY AND ACCESS MANAGEMENT (Questions 1–12)
Question 1
Universal Containers has implemented a hybrid sharing model where
Accounts and Contacts are Read-Only for all users except Account
Executives (AEs) who own the Accounts. Some Contacts are owned by AEs,
while other Contacts are owned by Support Representatives. The AEs have
requested the ability to edit all Contacts associated with their Accounts,
regardless of who owns the Contact. The System Administrator has already
,set the Organization-Wide Default for Contacts to Private. What additional
configuration should the Administrator implement to allow AEs to edit all
Contacts associated with their Accounts without granting excessive
permissions?**
A) Create a Sharing Rule on Contacts that grants Read/Write access to the
AE Role for all Contact records.
B) Select the "Edit All Associated Contacts" option for the AE Role in the
Role Hierarchy settings.
C) Create a Permission Set for AEs with the "Modify All Data" permission on
Contacts.
D) Set the Organization-Wide Default for Contacts to Public Read/Write and
use Field-Level Security to restrict editing.
E) Create an Apex Sharing Rule that programmatically shares Contact
records with AEs based on Account ownership.
Answer: B
**Rationale:** The "Edit All Associated Contacts" option is available in Role
Hierarchy settings. When enabled for a role, users in that role can edit all
Contacts associated with Accounts they own, regardless of who owns the
Contact. This provides the exact functionality requested without granting
excessive permissions. Option A is incorrect because Sharing Rules based
on Account ownership would require complex criteria and would not
automatically update when Account ownership changes. Option C would
grant excessive system-wide permissions. Option D would make all
Contacts visible to everyone, violating the Private OWD requirement.
,Option E is over-engineered; standard role hierarchy functionality handles
this requirement without Apex.
Question 2
Cloud Kicks has a requirement to restrict access to the "Opportunity" object
based on the user's department. Sales users should have Edit access,
Marketing users should have Read-Only access, and Finance users should
have No Access. Additionally, the System Administrator needs to ensure
that Finance users cannot even see the Opportunity tab in the Salesforce
navigation. The Administrator has created three Profiles: Sales Profile,
Marketing Profile, and Finance Profile. The Administrator has set Object
Permissions accordingly, but Finance users can still see the Opportunity
tab. What configuration step is missing?**
A) The Opportunity tab must be hidden from the Finance Profile's App
Permissions.
B) The Finance Profile must be assigned to a different App that does not
include the Opportunity object.
C) The Finance users must be deactivated and reactivated for the changes
to take effect.
D) The Opportunity object must be removed from the Finance Profile's
Page Layouts.
E) The Finance users must be assigned a Permission Set that hides the
Opportunity tab.
, Answer: A
Rationale: Setting Object Permissions to No Access prevents Finance users
from performing any operations on Opportunity records, but the
Opportunity tab might still appear in the navigation if it's included in the
App Permissions. To completely hide the tab, the Administrator must
remove it from the Finance Profile's App Permissions. Option B would work
but is less precise; users might need other objects in the same App. Option
C is incorrect because changes to Profiles are effective immediately without
deactivation. Option D is incorrect because Page Layouts control field
display, not tab visibility. Option E is incorrect because Permission Sets
grant additional permissions; they cannot restrict tab visibility.
Question 3
**Ursa Major Solar has a custom object called "Project__c" that stores
confidential project information. The Organization-Wide Default for
Project__c is set to Private. The System Administrator needs to ensure that
members of the "Project Management" Public Group can view and edit all
Project records, regardless of ownership. Additionally, users in the
"Executive" Public Group should only be able to view Project records, not
edit them. Neither group has any role hierarchy relationship. The
Administrator has created two Sharing Rules, but the Executive group is
reporting that they can edit Project records even though the rule is set to
Read-Only. What is the most likely cause of this issue?**
Test Bank – 75 Questions & Detailed Rationales Covers Core Certification
Topics: Security, Data Model, Automation, Reports, and Lightning
Experience Practice Questions with Verified Answers & Detailed Rationales
| Comprehensive Test Bank for ADM-201 | Guaranteed Success
EXAM INSTRUCTIONS
- This midterm examination consists of 75 multiple-choice questions**.
- Each question has four or five answer choices (A–E)**.
- Select the single best answer for each question.
- Questions are based on Salesforce Spring '26 and Winter '27 releases.
- Time suggested: **90 minutes** (approximately 1.2 minutes per
question).
SECTION 1: SECURITY AND ACCESS MANAGEMENT (Questions 1–12)
Question 1
Universal Containers has implemented a hybrid sharing model where
Accounts and Contacts are Read-Only for all users except Account
Executives (AEs) who own the Accounts. Some Contacts are owned by AEs,
while other Contacts are owned by Support Representatives. The AEs have
requested the ability to edit all Contacts associated with their Accounts,
regardless of who owns the Contact. The System Administrator has already
,set the Organization-Wide Default for Contacts to Private. What additional
configuration should the Administrator implement to allow AEs to edit all
Contacts associated with their Accounts without granting excessive
permissions?**
A) Create a Sharing Rule on Contacts that grants Read/Write access to the
AE Role for all Contact records.
B) Select the "Edit All Associated Contacts" option for the AE Role in the
Role Hierarchy settings.
C) Create a Permission Set for AEs with the "Modify All Data" permission on
Contacts.
D) Set the Organization-Wide Default for Contacts to Public Read/Write and
use Field-Level Security to restrict editing.
E) Create an Apex Sharing Rule that programmatically shares Contact
records with AEs based on Account ownership.
Answer: B
**Rationale:** The "Edit All Associated Contacts" option is available in Role
Hierarchy settings. When enabled for a role, users in that role can edit all
Contacts associated with Accounts they own, regardless of who owns the
Contact. This provides the exact functionality requested without granting
excessive permissions. Option A is incorrect because Sharing Rules based
on Account ownership would require complex criteria and would not
automatically update when Account ownership changes. Option C would
grant excessive system-wide permissions. Option D would make all
Contacts visible to everyone, violating the Private OWD requirement.
,Option E is over-engineered; standard role hierarchy functionality handles
this requirement without Apex.
Question 2
Cloud Kicks has a requirement to restrict access to the "Opportunity" object
based on the user's department. Sales users should have Edit access,
Marketing users should have Read-Only access, and Finance users should
have No Access. Additionally, the System Administrator needs to ensure
that Finance users cannot even see the Opportunity tab in the Salesforce
navigation. The Administrator has created three Profiles: Sales Profile,
Marketing Profile, and Finance Profile. The Administrator has set Object
Permissions accordingly, but Finance users can still see the Opportunity
tab. What configuration step is missing?**
A) The Opportunity tab must be hidden from the Finance Profile's App
Permissions.
B) The Finance Profile must be assigned to a different App that does not
include the Opportunity object.
C) The Finance users must be deactivated and reactivated for the changes
to take effect.
D) The Opportunity object must be removed from the Finance Profile's
Page Layouts.
E) The Finance users must be assigned a Permission Set that hides the
Opportunity tab.
, Answer: A
Rationale: Setting Object Permissions to No Access prevents Finance users
from performing any operations on Opportunity records, but the
Opportunity tab might still appear in the navigation if it's included in the
App Permissions. To completely hide the tab, the Administrator must
remove it from the Finance Profile's App Permissions. Option B would work
but is less precise; users might need other objects in the same App. Option
C is incorrect because changes to Profiles are effective immediately without
deactivation. Option D is incorrect because Page Layouts control field
display, not tab visibility. Option E is incorrect because Permission Sets
grant additional permissions; they cannot restrict tab visibility.
Question 3
**Ursa Major Solar has a custom object called "Project__c" that stores
confidential project information. The Organization-Wide Default for
Project__c is set to Private. The System Administrator needs to ensure that
members of the "Project Management" Public Group can view and edit all
Project records, regardless of ownership. Additionally, users in the
"Executive" Public Group should only be able to view Project records, not
edit them. Neither group has any role hierarchy relationship. The
Administrator has created two Sharing Rules, but the Executive group is
reporting that they can edit Project records even though the rule is set to
Read-Only. What is the most likely cause of this issue?**
