Salesforce Administrator Certification: 25 Free Practice Questions

The Salesforce Administrator certification stands as one of the most recognized and sought-after credentials in the customer relationship management technology space. Organizations across every industry rely on Salesforce to manage their sales pipelines, customer service operations, marketing campaigns, and business analytics, and the professionals who configure, maintain, and optimize these environments occupy roles that are consistently in high demand. Earning the Salesforce Certified Administrator credential demonstrates to employers that you possess a verified, standardized understanding of the Salesforce platform that goes beyond casual familiarity and reflects the kind of competence required to manage a production Salesforce org responsibly and effectively.

The certification examination tests candidates across a comprehensive set of domains that collectively cover the full scope of day-to-day Salesforce administration responsibilities. From managing users and security settings to configuring automation tools, building reports, and maintaining data quality, the examination evaluates both conceptual understanding and practical application in equal measure. This collection of 25 practice questions covers the most frequently tested topics from across all major examination domains, giving candidates realistic exposure to the types of questions they will encounter on the actual examination while reinforcing the conceptual understanding behind each correct answer. Working through these questions honestly — attempting each answer before reading the explanation — will reveal knowledge gaps that focused study can address before the real examination.

User Management and Access Questions

Question 1: A Salesforce Administrator needs to prevent a former employee from logging into Salesforce while preserving all records they owned. What is the correct action?

Answer: Deactivate the user account. Deleting a user is not possible in Salesforce — the platform does not allow user deletion because doing so would orphan records and break historical data integrity. Deactivating a user prevents them from logging in, frees their license for reassignment, and preserves all records they owned, which can then be transferred to other users through tools like the Mass Transfer Records utility. Freezing a user is a temporary measure that immediately prevents login without fully deactivating the account, which is useful when you need to act quickly while waiting for proper deactivation approval. However, freezing does not free up the license, so deactivation is the appropriate permanent solution for a departed employee.

Question 2: Which of the following correctly describes the relationship between Profiles and Permission Sets in Salesforce?

Answer: A Profile is assigned to every user and defines baseline permissions, while Permission Sets grant additional permissions on top of the Profile without changing it. Every Salesforce user must be assigned exactly one Profile, which establishes the default set of object permissions, field permissions, app settings, and system settings for that user. Permission Sets extend those permissions — they can grant access to objects, fields, tabs, or system features that the Profile does not include, but they cannot remove permissions that the Profile has already granted. This architecture allows administrators to create a baseline Profile with minimal permissions and then use Permission Sets to grant additional access to specific users based on their individual responsibilities, reducing the need to create large numbers of highly customized Profiles.

Question 3: An administrator wants to ensure that users in the Support team can only see records owned by members of their own team, not records owned by users in other teams. Which record access mechanism should be configured?

Answer: Role Hierarchy combined with Organization-Wide Defaults set to Private for the relevant object. Organization-Wide Defaults establish the baseline level of access that users have to records they do not own. Setting the OWD to Private means users can only see records they own by default, with no automatic visibility into records owned by others. The Role Hierarchy then opens up access upward — a manager in a role above a team member can see all records owned by users below them in the hierarchy. To restrict visibility so that Support team members see only their own team’s records, the administrator would place all Support users in the same role or in a role branch that is separate from other teams, ensuring that the hierarchy grants upward visibility within the Support branch without extending visibility across to other branches.

Security and Data Access Controls

Question 4: What is the difference between Field-Level Security and Validation Rules in Salesforce?

Answer: Field-Level Security controls whether users can see or edit a field at all, while Validation Rules enforce data quality by requiring field values to meet specific criteria before a record can be saved. Field-Level Security is configured at the Profile or Permission Set level and can make a field completely invisible to certain user groups, read-only for others, and fully editable for others still. It operates as an access control mechanism rather than a data quality mechanism. Validation Rules, by contrast, are logic conditions that run when a record is saved — if the condition evaluates to true, the save is blocked and an error message is displayed to the user. Validation Rules can reference field values, user information, record ownership, and other contextual data to enforce complex business rules that go beyond simple required-field enforcement.

Question 5: A company requires that certain sensitive fields on the Account object be hidden from all users except those in the Finance department. What is the most appropriate Salesforce feature for achieving this requirement?

Answer: Field-Level Security configured at the Profile level, combined with a separate Profile or Permission Set for Finance users. The administrator would set the sensitive fields to Hidden for all standard Profiles used by non-Finance users, ensuring those users cannot see the field values even if they can see the Account records themselves. For Finance users, a Permission Set granting Read or Edit access to those fields can be assigned, overriding the restrictive Profile setting in the direction of greater access. It is important to remember that Permission Sets can only expand access beyond what the Profile provides — they cannot restrict it. Therefore, the Profile must establish the restrictive baseline, and the Permission Set grants the expanded Finance access on top of that baseline.

Question 6: Which sharing mechanism in Salesforce allows an administrator to grant record access to a specific user or group of users without changing the Organization-Wide Defaults or Role Hierarchy?

Answer: Manual Sharing or Sharing Rules. Sharing Rules are automated configurations that extend record access to specific public groups, roles, or territories based on record ownership or field criteria. They run automatically whenever records match the defined criteria and are appropriate for systematic access extension patterns that apply broadly across the organization. Manual Sharing allows individual users to share specific records with other users or groups on a one-off basis, which is useful for exceptional access needs that do not justify creating a permanent Sharing Rule. Both mechanisms operate above the OWD baseline, opening additional access without changing the foundational access model. Apex Managed Sharing is a third option available to developers who need programmatic control over record sharing for complex scenarios that declarative tools cannot handle.

Automation and Process Configuration

Question 7: What is the recommended Salesforce tool for automating a multi-step business process that includes record updates, email alerts, and field updates triggered by record changes?

Answer: Flow Builder. Salesforce has consolidated its automation tools around Flow Builder as the strategic platform for declarative automation, and the company has announced the retirement of Workflow Rules and Process Builder in favor of Flow. Flow Builder supports record-triggered flows that fire when records are created, updated, or deleted, and it can perform complex multi-step logic including record updates across related objects, sending email alerts, creating tasks, calling external services via HTTP actions, and branching logic based on field values. For administrators taking the current certification examination, understanding that Flow is the recommended tool for new automation and that it supersedes Workflow Rules and Process Builder is important knowledge that reflects Salesforce’s current platform direction.

Question 8: An administrator needs to automatically populate the Account Name field on a Contact record with the name of the related Account whenever the Contact is saved. Which automation tool is most appropriate for this simple field population requirement?

Answer: A Record-Triggered Flow with an Update Records element, or a Formula Field depending on whether the requirement is to store the value or calculate it dynamically. If the business requirement is to store a copy of the Account Name value in a text field on the Contact — which would be appropriate if the value needs to be reportable, searchable, or needs to persist even if the Account Name later changes — a Record-Triggered Flow that runs when the Contact record is saved and copies the related Account’s Name into the Contact field is the appropriate tool. If the requirement is simply to display the Account Name dynamically without storing a separate copy, a Formula Field on the Contact that references the related Account’s Name field is more elegant and requires no automation maintenance.

Question 9: Which of the following correctly describes the execution order when multiple automation tools are triggered by the same record save event in Salesforce?

Answer: Salesforce processes automation in a defined order during each save transaction: Validation Rules run before records are saved to the database, followed by Assignment Rules, Auto-Response Rules, Workflow Rules (before-save), Escalation Rules, and then Flows. Within the context of Record-Triggered Flows specifically, before-save flows run before the record is written to the database while after-save flows run after the record is committed. Understanding this execution order matters practically because automation tools that run earlier in the sequence can affect the record values that later tools see. A before-save Flow, for example, can modify field values on the record being saved before Validation Rules evaluate those values, which is a powerful capability for pre-populating fields to satisfy validation requirements automatically.

Reports and Dashboards Fundamentals

Question 10: A sales manager wants to see a report that displays the total Opportunity amount grouped by Stage, with each Stage shown as a row and the sum of amounts shown beside each row. Which Salesforce report format should the administrator create?

Answer: A Summary Report. Salesforce offers four report formats: Tabular, Summary, Matrix, and Joined. Tabular reports display data as a simple list of rows without any grouping or subtotals, suitable for basic record lists. Summary reports add row groupings that organize records into sections with subtotals and grand totals for each group — this is exactly what the sales manager needs, with records grouped by Stage and amount totals calculated for each group. Matrix reports support both row and column groupings, enabling cross-tabulation analysis where data is summarized across two dimensions simultaneously. Joined reports combine multiple report blocks with different report types in a single view, useful for side-by-side comparisons of related but structurally different datasets. For the described requirement, Summary is the correct and most efficient format.

Question 11: What is the maximum number of components that can be displayed on a single Salesforce Dashboard?

Answer: 20 components. Salesforce Dashboards support up to 20 individual components — charts, tables, metrics, gauges, and other visual elements — on a single dashboard page. Each component is driven by a source report, and the same report can power multiple components on the same dashboard. Dashboard components refresh based on the running user’s data access permissions, which means the dashboard shows data that the running user can see in their own reports. The running user can be set to the logged-in user (dynamic dashboards) or to a specific user whose data visibility applies to all viewers of the dashboard. Dynamic dashboards are particularly important for scenarios where different users should see their own data reflected in the same dashboard layout rather than seeing a single shared data view.

Question 12: An administrator wants to create a report that shows Accounts and their related Contacts side by side, including Accounts that have no Contacts. Which report type configuration achieves this?

Answer: A custom report type based on Accounts with Contacts that is configured to include Accounts with or without related Contacts. When creating a custom report type in Salesforce, the administrator defines the primary object and any related objects, and for each relationship can specify whether to include parent records that have no related child records. Setting the Account-to-Contacts relationship to “A” records may or may not have related “B” records includes Accounts regardless of whether they have any associated Contacts, with Contact-related fields appearing blank for Accounts with no Contacts. If the relationship is set to require related records, Accounts without Contacts are excluded from the report entirely. This configuration distinction is frequently tested in the certification examination because it reflects a practical data visibility decision that administrators encounter regularly.

Object and Field Configuration

Question 13: What is the difference between a Master-Detail relationship and a Lookup relationship in Salesforce?

Answer: A Master-Detail relationship creates a tight dependency between parent and child records where the child cannot exist without the parent, while a Lookup relationship is a loose association that does not enforce this dependency. In a Master-Detail relationship, deleting the parent record automatically deletes all associated child records, the child record inherits the sharing and security settings of the parent, and roll-up summary fields can be created on the parent to aggregate values from child records. The owner field on the child record is controlled by the parent’s ownership. In a Lookup relationship, the child record exists independently of the related parent — the lookup field can be left blank, deleting the parent does not delete the child, and roll-up summary fields are not available. Lookup relationships are appropriate when two objects are related but should remain independently manageable, while Master-Detail is appropriate when child records are meaningfully subordinate to and inseparable from their parent.

Question 14: An administrator needs to create a field on the Opportunity object that automatically calculates the number of days between the Opportunity’s Close Date and today’s date. Which field type should be used?

Answer: A Formula field with a return type of Number. Formula fields calculate their values dynamically at runtime using expressions that can reference other fields on the same record, related object fields, and built-in functions. To calculate the number of days between the Close Date and today, the formula would use the TODAY() function — which returns the current date — and subtract the CloseDate field value, producing a numeric result representing the number of days. The expression would be written as TODAY() – CloseDate for a simple day difference. Formula fields do not store a value in the database — they compute the result fresh each time the record is displayed, which means they always reflect the current date. This dynamic calculation behavior is important for understanding why Formula fields are appropriate for time-relative calculations like this one, where a stored value would become stale immediately after the record was last saved.

Question 15: Which of the following field types in Salesforce allows an administrator to restrict users to selecting only values from a predefined list while also allowing the field to be left blank?

Answer: A Picklist field without the Required field attribute enabled. Picklist fields present users with a dropdown menu of predefined values and prevent free-text entry, ensuring that all values in the field conform to the administrator-defined list. When the Required attribute is not enabled, users can save a record without selecting any picklist value, leaving the field blank. Multi-Select Picklist fields allow users to select multiple values from the predefined list simultaneously, which is appropriate when a record characteristic can have more than one applicable value. Record Types can further restrict picklist values by controlling which subset of global picklist values is available to users with a particular Record Type assignment, enabling different teams or business units to see only the values relevant to their context.

Data Management and Import Tools

Question 16: What is the maximum number of records that the Salesforce Data Import Wizard can import in a single operation?

Answer: 50,000 records. The Data Import Wizard is Salesforce’s point-and-click import tool accessible directly from Setup, designed for straightforward import scenarios involving standard objects like Accounts, Contacts, Leads, and Solutions, as well as custom objects. It supports up to 50,000 records per import file and walks the user through field mapping with a guided interface that is accessible to administrators without technical backgrounds. For imports exceeding 50,000 records or requiring more complex handling — such as importing multiple related objects in sequence, performing upsert operations on large datasets, or importing object types not supported by the Import Wizard — the Data Loader is the appropriate tool. Data Loader is a client application that supports up to 5 million records per operation and provides greater control over import settings, error handling, and scheduling.

Question 17: An administrator is preparing to import 10,000 Contact records that should be matched against existing records using an external ID field. The import should update existing records where matches are found and create new records where no match exists. Which operation type should be selected in Data Loader?

Answer: Upsert. The Upsert operation combines Insert and Update logic — it searches existing records for matches based on a specified ID field (either the Salesforce record ID or a designated external ID field), updates records where a match is found, and inserts new records where no match exists. This is the correct operation for the described scenario because it handles both scenarios — existing contacts being updated and new contacts being created — in a single pass through the import file. Using Insert would create duplicate records for contacts that already exist, while Update would fail or skip records for new contacts with no existing match. The external ID field used for matching must be designated as an External ID field in the object’s field configuration before it can be used as a Upsert match key in Data Loader.

Question 18: What should an administrator do before performing a mass data deletion or update operation in a Salesforce production environment?

Answer: Export a data backup using Data Export or Data Loader before performing the operation. Salesforce does not provide automatic rollback capability for mass data operations — once records are deleted or updated in bulk, restoring the previous state requires either restoring from a backup or manually correcting each affected record. The Data Export feature in Setup allows administrators to schedule or manually initiate exports of all organization data as CSV files, which serve as the recovery source if a mass operation produces unintended results. Salesforce also offers a Data Recovery service (as a paid add-on) and maintains its own backups, but relying on Salesforce for data recovery is slow and costly compared to maintaining your own current backup. Best practice is to perform mass operations first in a sandbox environment to validate the logic and confirm the expected outcome before executing against production data.

Sales Cloud and Service Cloud Features

Question 19: A company uses Salesforce Opportunities to track deals and wants to prevent sales representatives from moving an Opportunity to the Closed Won stage unless the Probability field is set to 100. Which Salesforce feature enforces this requirement?

Answer: A Validation Rule on the Opportunity object. The validation rule would use a formula condition that evaluates to true (triggering the error) when the Stage is being set to Closed Won and the Probability field is not equal to 100. The formula would be written as AND(ISPICKVAL(StageName, “Closed Won”), Probability <> 100), and the associated error message would explain the requirement to the user. An alternative approach using a Flow with a decision element could also enforce this logic, but Validation Rules are the standard declarative tool for this type of field value dependency requirement. It is worth noting that Validation Rules run regardless of whether the record is being saved through the user interface, through automation, or through API calls, making them a robust enforcement mechanism that cannot be bypassed by non-UI operations.

Question 20: What is the purpose of Salesforce Queues and which objects support them?

Answer: Queues are holding areas where records can be assigned when no specific individual user ownership is appropriate, allowing groups of users to share ownership of and responsibility for a set of records until someone accepts or is assigned individual ownership. Queues are commonly used in service environments where incoming Cases are routed to a Support Queue and agents claim cases from the queue based on availability and expertise. Standard Salesforce objects that support Queues include Cases, Leads, Orders, Service Contracts, Knowledge Articles, and custom objects with the Queue feature enabled. To assign a record to a Queue, the record’s Owner field is set to the Queue rather than an individual user. Queue members — users or public groups assigned to the Queue — can then view all records in the Queue through a Queue list view and accept ownership of individual records when they are ready to work on them.

Question 21: An administrator needs to automatically assign incoming Cases to specific support agents based on the Case’s origin and product category. Which Salesforce feature handles this requirement?

Answer: Case Assignment Rules. Assignment Rules allow administrators to define ordered criteria — evaluated from top to bottom until the first matching condition is found — that automatically set the Owner field of incoming records to a specified user or queue. For Cases, the assignment rule can reference any Case field, including Origin and product-related fields, to route records to the appropriate agent or team queue. Each rule entry specifies the criteria that must be true and the user or queue to assign the record to when those criteria are met. Assignment Rules run automatically when new records are created through the web-to-case form or email-to-case process, and can also be triggered manually by checking the Assign using active assignment rule checkbox when creating or editing a case in the user interface.

AppExchange and Platform Fundamentals

Question 22: What is Salesforce AppExchange and what types of solutions does it offer?

Answer: Salesforce AppExchange is Salesforce’s online marketplace where independent software vendors, consulting partners, and Salesforce itself publish pre-built applications, components, and consulting services that extend Salesforce functionality. Solutions on AppExchange fall into several categories: managed packages (fully developed applications that install into a Salesforce org and add new functionality), unmanaged packages (open-source collections of components that can be installed and modified freely), Lightning components (individual UI components that can be added to Salesforce pages), and flow templates (pre-built automation flows that can be installed and customized). Many AppExchange solutions are free, while others require paid subscriptions. Before installing any AppExchange package into a production org, best practice is to install and test it in a sandbox environment first, as packages can introduce new custom objects, fields, and automation that interact with existing configuration in unexpected ways.

Question 23: Which Salesforce environment type is a full copy of the production org including all data, configuration, and customization, used primarily for performance testing and final user acceptance testing?

Answer: Full Sandbox. Salesforce offers four sandbox types that differ in how much data and metadata they copy from production. Developer sandboxes copy all metadata (configuration and customization) but no production data, and have a 200 MB storage limit — appropriate for development and unit testing. Developer Pro sandboxes also copy all metadata with no production data but provide 1 GB of storage, suitable for more complex development work. Partial Copy sandboxes copy all metadata and a subset of production data defined by a sandbox template, providing a representative sample of real data for more realistic testing. Full sandboxes copy all metadata and all production data, creating an exact replica of the production environment — they are used for final performance testing, load testing, and user acceptance testing where realistic data volumes and configurations are essential. Full sandboxes take the longest to create and refresh, and have the most limited refresh frequency (every 29 days).

Lightning Experience and UI Configuration

Question 24: An administrator wants to customize the fields displayed on an Opportunity record page for users with the Sales Representative profile, showing different fields than those seen by users with the Sales Manager profile. Which Salesforce feature enables this profile-specific page layout assignment?

Answer: Page Layouts combined with Record Type assignments to Profiles. Page Layouts define which fields, related lists, and components appear on a record detail and edit page. Record Types allow administrators to associate different Page Layouts with different user Profiles — when a user views a record, Salesforce determines which Page Layout to display based on the record’s Record Type and the viewing user’s Profile. To show different fields to Sales Representatives versus Sales Managers, the administrator would create two Page Layouts with different field configurations and assign each to the appropriate Profile through the Record Type’s Page Layout Assignment settings. If only one Record Type is needed, multiple Page Layouts can still be assigned to different Profiles through the standard Page Layout Assignment settings on the object.

Question 25: What is the difference between a Salesforce Lightning App and a Lightning App Page?

Answer: A Lightning App is a navigation container that groups related items — tabs, objects, and utilities — into a cohesive workspace that users navigate to from the App Launcher, while a Lightning App Page is a customizable page within Salesforce that displays content through a flexible component-based layout. Lightning Apps define what navigation tabs are visible to users when they are working within that app, what utility bar components are available, and which user Profiles have access to the app. They essentially define the workspace context and navigation structure. Lightning App Pages, by contrast, are individual pages — Home pages, Record pages, or standalone App Pages — that are built using Lightning App Builder by dragging and dropping standard and custom components into a flexible multi-column layout. A Lightning App Page can be assigned to specific apps and profiles so that different user groups see different page configurations for the same object, which complements the App-level navigation control that Lightning Apps provide.

Conclusion

Working through these 25 practice questions represents a valuable component of Salesforce Administrator certification preparation, but it is important to understand where practice questions fit within a comprehensive study strategy. Practice questions serve their greatest purpose as diagnostic tools — they reveal which topics you understand solidly and which areas require additional focused study, and they familiarize you with the style of reasoning that Salesforce examination questions demand. A candidate who works through practice questions, carefully reviews the explanations for both correct and incorrect answers, and then returns to the official Salesforce study materials to deepen their understanding of weak areas will extract far more value from practice testing than one who simply accumulates question attempts without analytical reflection.

The official Salesforce Administrator certification examination covers a defined set of domains with published percentage weights, and candidates who align their preparation time proportionally to these weights ensure that they are investing their study energy where the examination rewards it most. The Salesforce Help documentation, Trailhead modules and trails specifically designed for the Administrator credential, and the official Exam Guide published by Salesforce together constitute the primary study resources that should anchor preparation. Trailhead’s Prepare for Your Salesforce Administrator Credential trail is particularly valuable because it is maintained by Salesforce itself, ensuring that the content reflects the current examination version and platform capabilities rather than outdated information from previous exam releases.

Hands-on practice in a real Salesforce environment is equally important as conceptual study, and Salesforce makes this accessible through free Developer Edition orgs that any candidate can create at developer.salesforce.com. Working through the administrative tasks described in examination topics — creating custom objects and fields, configuring sharing settings, building reports and dashboards, setting up automation with Flow Builder, importing data with the Import Wizard — in a real org environment builds the practical familiarity that makes examination scenario questions significantly more approachable. When you have personally navigated to the Sharing Settings page and configured an Organization-Wide Default, or built a record-triggered Flow that sends an email alert, the examination questions about those topics cease to be abstract and become recognizable descriptions of things you have actually done.

The Salesforce Administrator credential is genuinely achievable for any professional who approaches the preparation process with consistency, intellectual curiosity, and honest self-assessment of where their knowledge gaps lie. The platform rewards practitioners who understand not just what each feature does but why it was designed that way and when it is the appropriate solution to a given business requirement. Candidates who develop this contextual understanding — not just memorizing feature names and button locations but genuinely grasping the administrative logic that connects platform capabilities to business needs — consistently perform better on the examination and more importantly become better administrators in their actual roles. The certification validates that foundation, and the career opportunities it opens are a natural consequence of the genuine competence it represents.

• Category: Others