2027: 100 Practice Questions with Verified Answers
& Detailed Rationales | Complete Test Bank for ADM-
201 | Guaranteed Success
EXAM INSTRUCTIONS
- This examination consists of 100 multiple-choice question
- 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: 120 minutes (approximately 1.2 minutes per question).
SECTION 1: SECURITY AND ACCESS (Questions 1–15)
Question 1
Ursa Major Solar has implemented a private sharing model for Opportunities.
The Sales Director needs all Sales Managers (who are above the Sales
Representatives in the role hierarchy) to have read/write access to all
Opportunities owned by their subordinates. However, the Sales Director also
wants to ensure that Sales Managers in one region cannot access
Opportunities belonging to Sales Managers in a different region. The
organization uses a role hierarchy with separate branches for each region.
What should the System Administrator configure to meet these requirements
while maintaining the private sharing model?**
,A) Set the Organization-Wide Default for Opportunities to Public Read/Write
and use Role Hierarchy to restrict access.
B) Configure a Sharing Rule based on Role Hierarchy that grants Read/Write
access to parent roles.
C) Create a Permission Set with "View All Data" and "Modify All Data" for
Sales Managers.
D) Set the Organization-Wide Default for Opportunities to Private and
configure Grant Access Using Hierarchies to allow parent roles access.
E) Create Apex Sharing Rules that programmatically share Opportunities
based on region criteria.
Answer: D
**Rationale:** When Organization-Wide Defaults (OWD) are set to Private for
Opportunities, the "Grant Access Using Hierarchies" option, when enabled,
allows users higher in the role hierarchy (Sales Managers) to access records
owned by users below them (Sales Representatives). This is the standard
Salesforce behavior that respects the hierarchical structure. Option A would
make all Opportunities visible to everyone, violating the private model.
Option B is incorrect because Sharing Rules based on Role Hierarchy are
typically used to share with groups below or across roles, but the hierarchy
already grants access upward. Option C would grant excessive system-wide
access. Option E is over-engineered and unnecessary when standard hierarchy
sharing works. The key is that the hierarchy grants upward visibility
automatically, and different regional branches remain separate because the
hierarchy only grants access within the same branch.
,### Question 2
At Universal Containers, a Delegated Administrator has been assigned to
manage users in the Eastern Region. This Delegated Administrator can create,
edit, and deactivate users within their assigned role and subordinate roles.
However, the Delegated Administrator reports that they are unable to edit
the "Created Date" field on Account records, even for Accounts owned by
users in their region. The System Administrator has verified that the
Delegated Administrator's profile has Read/Write permissions on the Account
object. What is the most likely reason the Delegated Administrator cannot
edit the Created Date field?**
A) The Delegated Administrator's profile does not have the "Modify All Data"
permission.
B) The Created Date field is a System Audit field that is read-only for all users,
including Delegated Administrators.
C) The Delegated Administrator's role does not have permission to edit
Accounts in that region.
D) The Organization-Wide Default for Accounts is set to Private, and the
Delegated Administrator does not own the Accounts.
E) The Delegated Administrator's Permission Sets override the profile
permissions and restrict editing of system fields.
Answer: B
Rationale The "Created Date" field is a standard system audit field in
Salesforce. System audit fields (Created By, Created Date, Last Modified By,
Last Modified Date) are automatically populated by Salesforce and are read-
only for all users, regardless of their profile or permission set settings. This is a
fundamental platform limitation that cannot be overridden by Delegated
Administrator permissions, "Modify All Data," or any other configuration.
, Option A is incorrect because even "Modify All Data" does not allow editing of
system audit fields. Option C is irrelevant because the field itself is read-only.
Option D is incorrect because field-level editability is separate from record
visibility. Option E is incorrect because Permission Sets cannot grant access to
edit system audit fields.
Question 3
**Cloud Kicks has implemented a complex security model where different
departments require varying levels of access to the same objects. The Sales
team needs Edit access to Opportunity fields, while the Support team needs
Read-Only access. Additionally, within the Sales team, Junior Sales
Representatives should not be able to edit the "Discount Percentage" field,
while Senior Sales Representatives can. The System Administrator has created
two Profiles (Sales Profile and Support Profile) and two Permission Sets
(Junior Permissions and Senior Permissions). Where should field-level security
be configured to restrict the "Discount Percentage" field from Junior Sales
Representatives while allowing Senior Sales Representatives to edit it?**
A) On the Page Layout, set the "Discount Percentage" field as read-only for
Junior Sales Representatives.
B) On the Profile, set the "Discount Percentage" field as read-only for the
Sales Profile, then use a Permission Set to grant edit access to Senior Sales
Representatives.
C) On the Permission Set, set the "Discount Percentage" field as read-only for
Junior Sales Representatives.
D) On the Field-Level Security settings for the "Discount Percentage" field,
make it read-only for the Junior Permission Set.
E) Use Validation Rules to prevent Junior Sales Representatives from saving
changes to the "Discount Percentage" field.