How to pass ServiceNow Certified System Administrator (CSA)
29 min read6 domains coveredFree practice, no sign-up
The ServiceNow Certified System Administrator (CSA) is the platform's entry credential and the prerequisite most other ServiceNow certifications assume. It tests whether you can administer a Now Platform instance: navigate it, configure it, shape lists and forms, build self-service and automation, model and secure data, and move configuration and data between instances. It is a working administrator's exam rather than a developer's exam, so the scripting it asks about is the scripting an administrator meets, and the questions reward knowing which no-code mechanism is the right one before any script is written.
It suits service desk leads, ITSM process owners, implementation consultants starting out, and anyone who has been handed an instance and told to keep it healthy. Hands-on time matters more here than on most foundational certifications. A personal developer instance is free, and the difference between candidates who have clicked through Form Design, an import set and an access control rule and candidates who have only read about them is visible in the pass rate.
The question style is scenario-first. You are given a short situation with a stated requirement, and several options that all describe real platform features. Only one produces the described outcome. The trap is almost always a feature that does something adjacent: it hides the field but only on the form, it captures the configuration but not the data, it runs but at the wrong moment in the record's lifecycle. Learning what each mechanism does not do is worth as much as learning what it does.
This guide walks the six blueprint domains in the order the platform itself makes sense in, gives you the discriminations the item writers lean on, and sets out a study plan you can run against a free instance.
CSA is a scenario exam about mechanism boundaries: the marks are in knowing which tool produces the stated outcome and which merely looks like it does.
Difficulty
Intermediate
Best for
Service desk and ITSM staff, new ServiceNow administrators and implementation consultants, and anyone who needs the prerequisite credential before the platform's specialist certifications.
Prerequisites
None formally. Several weeks of hands-on time on a free personal developer instance is the practical prerequisite, and ServiceNow's own administration training maps closely to the blueprint.
60
Questions
90 min
Time allowed
$300
Exam cost (USD)
339
Practice questions
How this exam thinks
Three habits separate a pass from a fail on the CSA, and none of them is about memorising more module paths.
First, the exam tests boundaries rather than definitions. Every question is a short scenario ending in a requirement, and the distractors are real platform features doing something almost right. A UI policy genuinely hides a field, so it will be offered when the requirement says the data must not reach the list or the export, where only an access control rule reaches. A business rule genuinely runs on save, so it will be offered when the requirement says the user must see the change before saving, where only a client-side mechanism reaches. Read the requirement first and ask what surface it touches: the form only, every read of the data, the server before the write, or the record after it. That single question resolves most of the paper.
Second, the exam wants the least powerful tool that meets the requirement. The platform has a configuration answer for almost everything, and the item writers reward reaching for it. If a field must be mandatory only on the form under a condition, the answer is a UI policy and not a client script. If a field must be mandatory on every write including an import, the answer is a data policy or a dictionary setting and not a UI policy. If a value must be prefilled for a user creating a record, the answer is a template rather than a script. When two options both work, the one with less script and less scope is the one the exam is pointing at.
Third, the exam is scored in a way that punishes guessing at the wrong moment and rewards it at the right one. The cut score is set for each exam form and is not published, and ServiceNow states plainly that it is not always seventy per cent, so there is no threshold to aim at and no useful way to budget wrong answers. Multiple-select items tell you exactly how many options to pick and carry no partial credit, which means a three-of-five item is all or nothing: pick the wrong count and you score zero even if two of your three were right. Count them deliberately. On a single-answer item there is no penalty for a wrong answer, so never leave one blank.
What each domain tests and how to study it
The CSA blueprint is split across 6 domains. Weights are the official share of the exam; see the official exam guide for the authoritative breakdown.
What you must be able to do. Describe what the Now Platform is and what a customer instance is, and know where in Next Experience Unified Navigation an administrator performs a described task.
In one sentenceThe orientation domain: one platform with one data model, a dedicated instance per customer, and the Next Experience navigation an administrator works through.
Recall check: answer these from memory first
In one sentence, say what makes a customer's ServiceNow deployment different from a typical multi-tenant application sharing one database.
Name the menus in the Next Experience unified navigation header and say what each one holds.
Say why a change to a user record shows up immediately on every incident and knowledge article that references that user.
What it tests. What the Now Platform actually is and how the applications built on it relate to it: a single cloud platform with one shared data model, on which ServiceNow applications and a customer's own applications run against the same tables, users, roles and automation. It tests the notion of a dedicated customer instance rather than a shared multi-tenant database, the roles of production, sub-production and personal developer instances, impersonation for reproducing a fault as another user, and the Next Experience Unified Navigation layout: the All, Favorites and History menus, the filter navigator, the Admin Center, user preferences and themes. Items typically describe a task and ask where it is performed, or describe an outcome and ask which platform characteristic explains it.
How to study it. Spend an evening navigating a free personal developer instance with the blueprint open beside you, and make yourself find each named area without searching for it: All, Favorites, History, the filter navigator, the Admin Center, user preferences. Then practise impersonating a user with no roles and noticing what disappears, because that habit pays off again in the access control domain. Learn the one-data-model idea properly rather than as a slogan: it explains why updating a user record changes what every referencing record displays, and why a custom application inherits roles, notifications and reporting for free. Keep the instance types straight by the question each answers: where do users work, where do you test, where do you practise without touching anyone.
Easy to confuse
An application versus a module in the Application Navigator. The application is the grouping heading and the modules are the entries beneath it, each of which opens a specific list, form or page. An item that describes an entry expanding to reveal Create New, Open and All is describing an application and its modules, not one module with tabs.
Personalising a list for yourself versus configuring it for everyone. The personalisation control on a list changes only the acting user's own view and is stored as a user preference; changing what every user sees means configuring the list layout as an administrator. The exam plants a personalisation option in scenarios whose requirement says the whole group must see the change.
The Now Platform versus a product built on it. The platform supplies the tables, forms, workflow, reporting, integration and security services; Incident Management and Service Catalog are applications that consume them. When a question asks what provides a capability rather than what uses it, the answer is the platform.
Worked example from the CSA bank
lock_openFree samplePlatform Overview and Navigationmedium
An administrator needs to see the platform as a particular user sees it, in order to confirm what that user can open, and cannot ask that user for their password. Which TWO statements describe how the platform's impersonation feature behaves? Select TWO.
AImpersonation lets an administrator work with the roles of the selected user without knowing that user's password.check_circle Correct
BImpersonation adds the selected user's roles to the administrator's own, so the session holds the sum of both role sets.
CWork carried out while impersonating is attributed to the selected user, and the platform records that an impersonation took place.check_circle Correct
DImpersonation requires the selected user to be signed out first, and their next sign in ends the administrator's impersonated session.
EImpersonation is set for the instance as a whole, so every administrator signed in at that moment sees the selected user's view.
Impersonation switches one session to another user's roles without their password, and attributes the work done to that user while recording who impersonated. Impersonation works by swapping the effective identity and role set of the current session, so every access control decision is evaluated against the selected user rather than the administrator. That is why it reproduces the user's view faithfully, and why the platform keeps a record of the impersonation to preserve accountability for anything changed during it.
Why A is correct: Correct. Impersonation switches the session to the selected user's identity and role set, which is why it is the supported way to reproduce what a user can and cannot see.
Why B is wrong: Tempting because the administrator starts the session and can end it at will, which suggests their own access is retained. It is wrong because impersonation replaces the effective roles rather than adding to them, and a combined role set would defeat the purpose of testing another user's view.
Why C is correct: Correct. Records touched during the session carry the impersonated user as the actor, and the platform keeps its own trace of the impersonation so the real administrator remains accountable.
Why D is wrong: Tempting because it sounds like a sensible safeguard against two sessions for one identity. It is wrong because impersonation is independent of whether the selected user is signed in, and their activity does not terminate the administrator's session.
Why E is wrong: Tempting because instance level configuration does change what everyone sees. It is wrong because impersonation is scoped to the single session that started it and has no effect on any other signed in user.
What you must be able to do. Choose between a plugin and a Store application for a described need, and separate a personalisation one user makes from a configuration an administrator makes for everyone.
In one sentenceGetting capability onto an instance and branding it: plugins and Store applications with their dependencies and entitlements, instance-wide branding, and the user interfaces different audiences work in.
Recall check: answer these from memory first
Give one distinction between a plugin activated from All Available Applications and an application installed from the ServiceNow Store.
Say what happens to the required plugins when you activate a plugin that depends on them, and where demo data belongs.
Name which platform interface you would put a non-technical requester in and which you would put a fulfilling agent in.
What it tests. Adding capability to an instance and shaping how it looks and feels. That means activating plugins from All Available Applications, including what loading demo data does and where it belongs, how required plugins behave when a plugin that depends on them is activated, and what happens when an administrator wants a plugin gone again. It covers installing applications from the ServiceNow Store, entitlement for paid and partner applications, and the difference between the two delivery mechanisms. It then covers branding and personalisation: logos, colours and page titles set through system properties and the Next Experience theme, instance-wide settings against per-user preferences such as time zone, and which of the platform's interfaces (Next Experience, Service Portal, Employee Center, Configurable Workspaces, mobile) fits a described audience.
How to study it. Activate a plugin on a personal developer instance and watch what the platform tells you about dependencies and demo data, because the wording of those prompts is what several items are built on. Fix in your head that plugin activation is not casually reversible on a production instance and that the correct answer to an unwanted plugin is usually to raise it with ServiceNow rather than to uninstall it yourself. For branding, learn which changes are properties an administrator sets once for everyone against which are preferences each user sets for themselves, because that split is the domain's favourite trap. For the interfaces, learn them by audience: a requester in Employee Center or Service Portal, a fulfiller in a Configurable Workspace or the classic interface, an administrator in the platform interface.
Easy to confuse
Personalising the instance versus configuring it. Personalisation is a change a user makes to their own experience, held as a user preference and visible only to them; configuration is a change an administrator makes to the instance so every user in scope sees it. If the requirement says colleagues must see it too, no personalisation control is the answer.
Activating a plugin versus installing a Store application. A plugin is platform functionality already present on the instance and switched on from All Available Applications; a Store application is distributed by ServiceNow or a partner, needs entitlement, and is installed and upgraded as its own versioned package. A request option in place of an install option means entitlement, not a missing role.
An instance-wide default versus a per-user preference. The instance default applies to everyone who has not overridden it, and a user preference overrides it for that one user only. A scenario where one person consistently sees a different time zone from everyone else is describing a preference, not a broken default.
Worked example from the CSA bank
lock_openFree sampleInstance Configurationmedium
An administrator must add a capability to an instance and is weighing two delivery mechanisms: a plugin listed in All Available Applications and an application obtained from the ServiceNow Store. Which statement describes how the two differ?
AA plugin is downloaded from an external repository each time it is switched on, whereas a Store application ships inside the base platform build and only needs activating.
BA plugin can be switched on only by ServiceNow personnel in response to a request, whereas a Store application can be installed directly by any user who holds the itil role on the instance.
CA plugin is functionality already delivered with the instance that an administrator switches on from All Available Applications, whereas a Store application is obtained from the ServiceNow Store and installed onto the instance.check_circle Correct
DA plugin can add tables, roles and business logic to the instance, whereas a Store application supplies only reports and dashboards that read tables the platform already provides.
Distinguish a plugin, which is dormant functionality delivered with the instance, from a Store application, which is obtained and installed from the ServiceNow Store. The two mechanisms differ in where the functionality comes from. A plugin is shipped with the platform in an inactive state, so activation simply enables tables, roles and logic that are already present. A Store application is published separately, so the instance must retrieve and install it before any of its artefacts exist locally.
Why A is wrong: Tempting because both mechanisms end with new functionality appearing on the instance, but the description is the wrong way round: the plugin is the part already delivered with the platform and the Store application is the part retrieved from outside the instance.
Why B is wrong: Tempting because some plugin actions do involve ServiceNow, but an administrator activates most plugins themselves, and installing a Store application is an administrative action rather than something the itil role grants.
Why C is correct: Correct because a plugin is dormant platform functionality that activation makes available, while a Store application is separately published content that must be brought onto the instance before it can be used.
Why D is wrong: Tempting because plugins do add tables and logic, but the limit placed on Store applications is invented: a Store application can also deliver tables, roles and server logic of its own.
What you must be able to do. Produce a described view or form behaviour with the right list, filter, form or template feature, and route and report on task work without writing script.
In one sentenceThe day-to-day administration domain: filters and tags, list and form anatomy, form design and views, templates and save actions, task routing, visual task boards, Platform Analytics and notifications.
Recall check: answer these from memory first
Say how you would build one list containing every Priority 1 incident plus every incident in a given state, and what makes it different from a filter with two AND conditions.
Name the four save actions on a form and say, for each, whether it creates or updates a record and where you end up.
Distinguish the three Visual Task Board types and say which one enforces a defined process.
What it tests. The largest slice of everyday administration. Building list filters with AND and OR conditions and dot-walking, reading and editing breadcrumbs, saving personal against shared filters, tagging records across tables, sorting, grouping and paging a list. The anatomy of lists and forms, and which element performs a described function, including related lists, the activity stream and UI actions. Configuring forms with Form Design and Form Layout, arranging fields into sections that render as tabs, and creating views so different audiences get different forms of the same record. Templates that prefill a new record, and the save actions with their distinct outcomes. Task management: the Task table and the tables that extend it, assignment groups and assignment rules, service level agreements. Visual Task Boards and their three types. Reports, dashboards and Platform Analytics. Email notifications and why one did or did not send.
How to study it. This domain is learned with your hands, not your eyes. Build a filter with an OR condition, save it, share it with a group and watch where it appears; then drop a single condition from the breadcrumb rather than rebuilding the filter. Dot-walk from an incident to the caller's department in a filter and again in a report, because the same skill is tested in the data schema domain. Create a view on the incident form and assign it, then use Form Design to move a field into a new section and confirm it renders as a tab. Apply a template and note exactly which fields it filled. Then work through the four save actions on a real record and write down, for each, whether the record is created or updated and whether you are still looking at it afterwards. For notifications, break one deliberately (wrong condition, no recipient) and read what the email logs tell you.
Easy to confuse
Insert and Stay versus Update. Insert and Stay copies the current record's values into a brand new record and leaves you on that new record, so you finish with two records; Update saves the changes to the record you already had and returns you to the list, leaving one record. A requirement to duplicate a record without losing your place is the tell for Insert and Stay.
A template versus a default value on the dictionary. A default value is set in the field's dictionary entry and applies to every new record on the table automatically; a template is a named set of values a user chooses to apply, so it is optional and can cover many fields at once. If the requirement is that the user picks a preset, it is a template; if every new record must start that way, it is a default value.
Personalising a form versus configuring it or creating a view. Personalize Form changes only the acting user's own layout; Form Design or Form Layout changes the form for everyone on that view, and a separate view gives one audience a different form of the same record. A scenario where technicians need a stripped-back form while agents keep the full one is a view, not a personalisation and not a second table.
Worked example from the CSA bank
lock_openFree sampleConfiguring Applications for Collaborationmedium
An administrator builds a filter on the incident list by adding, in order, Active is true, then Priority is 1, then Assignment group is Network. The filter breadcrumb displays the three conditions in that same order. The administrator then clicks the Priority is 1 segment of the breadcrumb. Which set of records does the list return afterwards?
ARecords where Active is true only, because clicking a breadcrumb segment removes that condition together with every condition added after it.
BRecords where Priority is 1 only, because clicking a breadcrumb segment isolates that single condition and discards the conditions on either side of it.
CRecords where Active is true and Priority is 1, because clicking a breadcrumb segment keeps that condition and drops the conditions added after it.check_circle Correct
DRecords matching all three conditions, because breadcrumb segments are read only labels and the filter can be shortened only from the condition builder.
Clicking a condition in a list filter breadcrumb keeps that condition and every condition to its left, and removes those added after it. The breadcrumb records the filter as an ordered chain of conditions, and each segment acts as a link back to the query state at that point. Selecting a segment rebuilds the query from the leftmost condition up to and including the one clicked, then reruns the list, which is why later conditions disappear while the clicked one survives.
Why A is wrong: Tempting because clicking a segment does discard later conditions, but the clicked condition itself is retained rather than removed, so the Priority filter still applies.
Why B is wrong: Tempting because the clicked condition survives, but conditions to the left of the clicked segment are kept, so Active is true remains in force as well.
Why C is correct: Correct: a breadcrumb segment is a live control that reruns the query at that point in the filter, retaining the clicked condition and everything to its left.
Why D is wrong: Tempting because the breadcrumb looks like a status line, but each segment is clickable and removing conditions from it is a supported way to widen a list.
What you must be able to do. Pick the right self-service building block for a described request, and control who can see or publish content using user criteria rather than roles.
In one sentenceHow work reaches the platform without a phone call: knowledge bases and their user criteria, catalog items, record producers and order guides, flows built in Workflow Studio, and Virtual Agent.
Recall check: answer these from memory first
Say what a record producer creates and what a catalog item creates, in one line each.
Explain how you would give one department read access to a knowledge base when those staff hold no extra roles.
Name the trigger types available to a flow and say which one a scheduled overnight job would use.
What it tests. The self-service front door and the automation behind it. Knowledge Management: knowledge bases and their ownership, the article lifecycle from draft through review and approval to published and retired, versioning so a published article stays readable while it is rewritten, categories, feedback and ratings, and above all user criteria governing who can read and who can contribute. Service Catalog: catalog items, record producers, order guides, categories, variables and variable sets, the request, requested item and catalog task hierarchy, and the user criteria that decide who sees an item. Workflow Studio as the home of Flow Designer: triggers, actions, conditions, approvals, subflows and spokes, testing and execution details, and when a flow is the right tool rather than a business rule. Virtual Agent: topics, the designer, prebuilt topics and live-agent handoff.
How to study it. Build one end-to-end request on a personal developer instance and follow the records it creates, because seeing a request spawn a requested item and a catalog task fixes the hierarchy permanently. Then build a record producer against a table other than the request tables and notice that it produced no requested item at all: that contrast is the domain's most tested distinction. For knowledge, create two knowledge bases, attach Can Read user criteria to one and Can Contribute to the other, and impersonate users in and out of those criteria until the behaviour is predictable. Learn that user criteria, not roles, are the platform's answer for visibility to people who hold no special roles. In Workflow Studio, build a flow with a record trigger and an approval action and read the execution details of a run, then ask yourself for each requirement in your notes whether it wants a flow, a business rule, or neither.
Easy to confuse
A record producer versus a catalog item. Both present a catalog-style form to a requester, but a catalog item drives the request, requested item and catalog task fulfilment chain, while a record producer creates a record directly on a target table you nominate. A requirement to land the submission straight onto a case or incident table with no requested item is a record producer.
User criteria versus roles for visibility. Roles grant a user permission to do things across the platform and are the wrong instrument for showing a knowledge base or catalog item to a group of ordinary staff; user criteria match users by group, department, company, location or a script and control visibility for exactly that content. A scenario stating the users hold no roles beyond the default is pointing at user criteria.
A flow versus a business rule versus a classic workflow. A flow is the current low-code automation built in Workflow Studio, with triggers, actions, approvals and spokes, and is the tool to reach for on new work; a business rule is server-side logic bound to a table event and suits a field calculation or a record-level check; classic workflow is the legacy engine that Flow Designer replaced. Multi-step fulfilment with approvals and integrations is a flow, not a business rule.
Worked example from the CSA bank
lock_openFree sampleSelf Service & Automationmedium
A knowledge base holds articles that only staff in the Finance department should be able to open, and those staff hold no roles beyond the ones every logged in user receives. Which mechanism governs who is allowed to read the articles in that knowledge base?
AA user criteria record matching the Finance department, added to the Can Read list of that knowledge basecheck_circle Correct
BA role added to the knowledge base record, granted to each Finance user through their group membership
CA read access control rule on the knowledge article table whose condition matches the department of the current user
DA category inside the knowledge base named Finance, with the articles filed under it for the department
Knowledge base read audiences are declared with user criteria on the Can Read list, not with roles, access control rules or categories. User criteria are reusable records that describe a set of users by attributes such as department, group, location or company. A knowledge base points at them from its Can Read and Can Contribute lists, and the platform evaluates the current user against those criteria when deciding whether the knowledge base and its articles are available. That is why an audience defined by department needs no new role.
Why A is correct: User criteria evaluate attributes such as department, group, location, company and role, and the Can Read list on a knowledge base is exactly where read audience is declared.
Why B is wrong: Roles are the familiar way to gate most platform features, so reaching for one is tempting, but knowledge read access is evaluated through user criteria rather than a role field on the knowledge base.
Why C is wrong: Access control rules do protect the table generally, but the per knowledge base audience for articles is decided by user criteria, so writing a rule here duplicates and fights the supported mechanism.
Why D is wrong: Categories organise articles for browsing and searching, which feels like structure equals security, but a category carries no audience and hides nothing from anyone.
What you must be able to do. Model data correctly with tables, extension and reference fields, and explain or troubleshoot exactly what a user can see using access control rules, roles and groups.
In one sentenceThe heaviest domain: the data schema and table extension, reference and choice fields and dot-walking, import sets and transform maps, the CMDB and CSDM, access control rules, and the shared responsibility model.
Recall check: answer these from memory first
Say what happens on Incident, Problem and Change Request when you add a field to the Task table, and how you would make it mandatory on one of them alone.
Recite the order in which access control rules are evaluated, and say what a user must satisfy to read one field on a record.
Explain what coalesce does on a transform map and what happens on a second import when it is not set.
What it tests. Data and security, and it carries the most weight on the paper. On data: tables, fields and records, extension from base tables such as Task and Configuration Item and what a field added to a parent means for its children, dictionary entries and dictionary overrides, field types including reference and choice, one-to-many and many-to-many relationships, the Schema Map, and dot-walking through references. Importing data: data sources, import sets and staging tables, transform maps with field maps and coalesce, transform scripts, scheduled imports, and reading the import log when rows duplicate or fail. The CMDB: configuration item classes and their hierarchy, relationships and the dependency view, identification and reconciliation, CMDB health, and how CSDM models services and applications. On security: users, groups and roles, role inheritance, access control rules on table, record and field with conditions, scripts and required roles, the order in which the platform evaluates them, the debugging tools that name the rule that denied access, Security Center, and the shared responsibility model.
How to study it. Treat this as two study blocks and give the security half at least as much time as the data half, because it produces the hardest items. For data, build a table that extends Task, add a field to the parent and confirm it appears on every child, then apply a dictionary override so one child alone is mandatory. Follow a reference field through the Schema Map and dot-walk it in a filter, a report and a transform map so the same idea lands three ways. Import a CSV twice with a coalesce field set and then without one, and read the import set rows: nothing teaches coalesce faster than watching duplicates appear. For security, learn access control evaluation as a procedure you can recite: the platform matches from the most specific object to the least specific, and a user must pass at the table level as well as the field level, so a field can be denied while the table read succeeds. Then use the security debugging output on a real denial and read which rule fired.
Easy to confuse
An access control rule versus a UI policy for hiding a field. A UI policy acts on the form in the browser and cannot touch the same data anywhere else, so the field remains in the list view, in a report and in an export; an access control rule governs every read of the data through the platform. If the requirement mentions lists, exports or reports, only an access control rule reaches it.
A role versus a group. A role is the unit of permission that access control rules and applications check for; a group is a container of users that exists to route work and to carry roles conveniently. Adding users to a group grants nothing until a role is attached to that group, which is the step the exam removes from the scenario.
Table extension versus a reference field. Extension makes the child table a specialised kind of the parent, inheriting its columns and its business logic; a reference field simply points one record at a record on another table. A new class of configuration item that needs the standard configuration item columns is an extension; recording which of several hundred existing vendor records supplied an asset is a reference field.
Worked example from the CSA bank
lock_openFree sampleDatabase Management and Platform Securityhard
A user holding the itil role opens an incident record and every field renders except a custom field named u_cost_centre, which is absent from the form, absent from the incident list view and empty in a CSV export of the same records. The read access control rule on the incident table itself evaluates to true for this user. What explains the behaviour?
AA field level read access control rule on incident.u_cost_centre requires a role the user does not hold, and both the table rule and the field rule must pass before the value is returned.check_circle Correct
BA UI policy on the Incident form hides u_cost_centre for users without a finance role, so the field is suppressed on the form and in every other view of the data.
CA before query business rule on the incident table adds a condition that strips u_cost_centre from the result set returned to users without a finance role.
DThe dictionary entry for u_cost_centre is configured as read only for the itil role, so the stored value stays hidden until the user is granted write access to the field.
Field level access control rules are evaluated in addition to the table rule, so a passing table rule alone does not reveal a field. Access control is evaluated from most specific to least specific, and a read of a field requires the field level rule and the table level rule to both grant access. Because that evaluation happens on the server for every request, a denied field disappears from forms, lists and exports alike, which is what separates it from a form only mechanism such as a UI policy.
Why A is correct: Correct: table level and field level read rules are both evaluated, so passing the table rule still leaves the field rule able to deny the single field wherever the data is requested.
Why B is wrong: Tempting because a UI policy is a common way to hide a field and does render it invisible on the form, but a UI policy acts only on the form at runtime and cannot remove a field from a list view or from an export.
Why C is wrong: Tempting because a before query business rule really does filter what a user gets back, but it filters whole records rather than individual fields, so it would hide incidents, not one column of a visible incident.
Why D is wrong: Tempting because a read only dictionary setting does restrict what a user may do with a field, but read only still displays the value; it blocks editing rather than reading.
What you must be able to do. Pick the mechanism and the timing that produce a described behaviour, and know exactly what an update set does and does not carry between instances.
In one sentenceThe mechanism-choice domain: UI policies against client scripts against data policies, business rule timing, what an update set captures, and where an administrator's scripting fits.
Recall check: answer these from memory first
Name the four business rule run points and give one requirement that fits each.
Say what an update set captures and what it does not, and what you do about the part it does not.
Given a field that must be populated on the form and also on an import, say which mechanism you use and why a UI policy will not do.
What it tests. Choosing the right mechanism and the right moment. UI policies and UI policy actions that make a field mandatory, read-only or visible when a condition is met on the form, their order and the reverse-if-false behaviour when the condition stops being true, catalog UI policies on variables, and when a data policy is the right tool because the rule must hold on an import or a web service call as well as on the form. Business rules: the four run points of before, after, async and display, what each is for, the table and condition that scope one, setting field values without script, and the order field. System update sets: the current update set, what is captured and what is not, merging and batching, exporting, retrieving, previewing and committing between instances, resolving collisions, and why work must not be left in Default. Scripting as an administrator meets it: client script types, GlideRecord basics, script includes, and the no-code options to prefer first.
How to study it. Build a small decision table and rehearse it until it is automatic, with the requirement on one side and the mechanism on the other: form-only behaviour under a condition goes to a UI policy; behaviour that must hold on every write including imports and integrations goes to a data policy; a server-side value calculated before the record is written goes to a before business rule; work that must happen after the save and must not slow the user goes to async; a value the client needs the moment the form opens without a further server call goes to a display business rule. Then verify each one on a personal developer instance rather than trusting the table. For update sets, make a change, look at it in the update set, then import three records and look again: seeing that the data is absent is what makes the rule stick. Practise setting the current update set before doing anything, because most real collisions start with work landing in Default.
Easy to confuse
A UI policy versus a client script versus a data policy. A UI policy applies mandatory, read-only and visible behaviour on the form declaratively and reverses itself when its condition stops matching; a client script runs JavaScript in the browser for anything a UI policy cannot express; a data policy enforces the same mandatory and read-only rules on every write, including imports and web service calls. If the requirement names an import or an integration, the answer is a data policy, not a UI policy.
Before versus after versus async versus display business rules. A before rule runs on the server before the record is written and is where you change field values or abort the save; an after rule runs once the write has happened and is where you act on related records; an async rule runs later on the scheduler so an expensive job does not delay the user; a display rule runs as the form is loaded and is how a server-side value reaches the client before the user does anything. Match the run point to the moment named in the requirement.
What an update set captures versus what it does not. An update set captures configuration changes such as forms, views, business rules, UI policies, client scripts and dictionary entries; it does not capture the data records those configurations act on, so users, groups, configuration items and catalog data must be moved separately, typically by an import. A migration plan that relies on the update set to carry data is the distractor.
Worked example from the CSA bank
lock_openFree sampleData Migration and Integrationmedium
An administrator must ensure that the Justification field is populated whenever a request record is saved, including when records arrive through an import set or an inbound web service call rather than through a form. Which mechanism enforces the rule in all of those cases?
AA UI policy on the table with a mandatory action on the Justification field, applied to every view of the form.
BAn onSubmit client script that cancels the save when the Justification field is empty, so no record can be written without it.
CA data policy on the table with the Justification field marked mandatory, since data policies are evaluated on the server for any insert or update.check_circle Correct
DA UI policy with the Reverse if false option cleared, so the mandatory action persists once the condition has matched.
A UI policy enforces field state only in the browser, while a data policy applies the same rule on the server for every insert or update path. UI policies and their actions are delivered to the client and evaluated against the loaded form, so nothing enforces them when a record is created by an import set, a web service or another server side process. A data policy is evaluated by the platform as part of the insert or update itself, which is why it covers every entry path. A data policy can also be converted so that it applies on the form as well.
Why A is wrong: Tempting because a UI policy is the standard no-code way to make a field mandatory, but its actions run only in the browser on a loaded form, so an import or a web service insert bypasses it entirely.
Why B is wrong: Tempting because an onSubmit script does block a form save, but like a UI policy it is client side code that never executes for an import set row or a web service insert.
Why C is correct: Correct because a data policy runs server side, so the mandatory rule holds for form saves, import set loads and web service calls alike.
Why D is wrong: Tempting because clearing Reverse if false does make an action persist, but it only changes what happens when the condition stops matching on the form and adds no server side enforcement.
A study plan that works
Get an instance and map the blueprint
Day 1
Request a free personal developer instance and sign in to it before you read anything else, because every later step assumes you can try things. Open the official blueprint, list the six domains with their weights, and mark the two that carry the most weight. Book a provisional exam date now: a fixed date turns open-ended study into a plan.
Navigate and configure the instance
Week 1
Work the first two domains together, since they are the smallest and they orient everything else. Find each named area of Next Experience Unified Navigation without searching for it, impersonate a user with no roles, activate a plugin and read what the platform says about dependencies and demo data, and brand the instance so you can feel the difference between an instance property and a user preference.
Live in lists and forms
Weeks 1-2
Build filters with OR conditions and dot-walking, save and share them, edit them from the breadcrumb, and tag records across tables. Then configure a form with Form Design, create a view for a second audience, apply a template, and try each of the four save actions on a real record and write down what each one did. Build one report and one dashboard, and break a notification deliberately so you learn where to look when one does not arrive.
Build the self-service front door
Week 2
Publish a knowledge base and gate it with Can Read and Can Contribute user criteria, then impersonate users in and out of them. Build a catalog item with variables and follow the request, requested item and catalog task records it creates, then build a record producer against a different table and notice what it did not create. Finish with a flow in Workflow Studio that carries a record trigger and an approval, and read its execution details.
Go deep on data and security
Weeks 3-4
This is the heaviest domain, so give it the most time. Extend Task with your own table, add a field to the parent, and override it on one child. Import a CSV twice with and without a coalesce field and read the import set rows. Then write access control rules on a table, a record and a field, evaluate them by impersonating, and use the security debugging output to name the rule that denied a read. Finish with a pass over the CMDB, CSDM and the shared responsibility model.
Drill the mechanism-choice decisions
Week 4
Work the migration and integration domain as a decision table and rehearse it until it is automatic: UI policy against client script against data policy, the four business rule run points, and what an update set does and does not carry. Verify each row on your instance rather than trusting the table, and move a real change between two instances through an update set at least once.
Practise on scenarios, then sit a timed mock
Week 5
Move to full practice sets and read the explanation on every question, including the ones you got right, because the distractors are real features doing something adjacent and knowing why each one fails is where the marks are. Use your per-domain accuracy to pick the two weakest domains and drill those rather than re-reading what you already know. Finish with at least one full timed mock to rehearse pacing and the flag-and-return habit.
Know when you're ready
Readiness for the CSA is a measured score on questions you have not seen before, not a feeling that the material is familiar. Those are different things, and the gap between them is where people fail this exam in particular, because the platform is pleasant to read about and the documentation is clear. Re-reading builds fluency, and fluency feels like knowledge, so confidence climbs while real recall does not move. The test is whether you can answer a fresh scenario and say out loud why each wrong option fails, not whether an explanation makes sense when you read it.
There is no published cut score to aim at, and ServiceNow states that it is not always seventy per cent, so a target percentage is the wrong instrument. Set the bar higher than any number you might guess: every domain clearing comfortably on unseen questions, across more than one session, with the two heavyweight domains of data and security clearing with real margin rather than scraping. Multiple-select items with no partial credit mean a domain that hovers around the line in practice will swing hard on exam day.
One extra readiness check for this exam that does not apply to a purely conceptual paper: if you have not personally built the thing, you do not know it. Before booking, confirm you have written an access control rule, run an import with a coalesce field, created a view, applied a template, built a flow and committed an update set on a real instance. The practice bank tells you where the gaps are, with an explanation of why the right answer is right and every wrong one is wrong on every question. Readiness scoring tells you when they are closed. Not before.
Ready to put this into practice?
Free CSA questions, every answer explained. No sign-up.
Read the last line of the scenario first. It carries the requirement, and every option has to be judged against that requirement rather than against whether it is a true statement about the platform.
Ask which surface the requirement touches: the form only, every read of the data, the server before the write, or the record after it. That one question separates UI policies, access control rules and the business rule run points faster than anything else.
Count the selections on a multiple-select item. The item states how many to pick and there is no partial credit, so picking four where three were asked scores zero however good the four were.
Prefer the least powerful tool that meets the requirement. When configuration and script both work, the exam is almost always pointing at the configuration.
Never leave a single-answer item blank. There is no penalty for a wrong answer, so flag the hard ones, cover every question first, and come back with whatever time is left.
When a scenario says the users hold no roles beyond the default, stop looking for a role. That phrase is the exam telling you the answer is user criteria or an access control condition, not a permission grant.
Frequently asked questions
What is the pass mark for the ServiceNow CSA?
There is no published pass mark. ServiceNow sets a predetermined cut score for the exam and does not publish it, and states plainly that it is not always seventy per cent. Aim to clear every domain comfortably on unseen practice questions rather than chasing a number, because there is no threshold to budget wrong answers against.
How are multiple-select questions scored?
Each item that takes more than one answer tells you exactly how many options to select, and there is no partial credit. Selecting two correct options out of three earns nothing, and selecting the wrong number of options earns nothing either, so count the selections deliberately before moving on.
How long should I study for the CSA?
Four to six weeks of focused study alongside a job is typical for someone with some IT service management background and hands-on instance time. Coming in with no platform exposure at all, plan on longer and spend the extra time building things rather than reading, because the data and security domain rewards practice more than any other.
Do I need hands-on experience, or is reading enough?
Hands-on experience is close to essential here in a way it is not on a purely conceptual certification. A free personal developer instance costs nothing, and the difference between candidates who have written an access control rule and run an import and those who have only read about them shows up directly in the scenario questions.
Which domains should I focus on?
Database Management and Platform Security is the largest domain by a clear margin and produces the hardest items, so it deserves the most time. Configuring Applications for Collaboration and Self Service and Automation are the next two, and together those three account for most of the paper. Platform Overview and Navigation is the smallest and is largely secured by using an instance for a week.
Does the CSA require scripting?
Not as a developer would understand it. You are expected to know where scripting fits for an administrator: the client script types, GlideRecord at a basic level, script includes, and above all which no-code mechanism to reach for before writing any script. Many items are won by recognising that a UI policy, a data policy or a template answers the requirement.
How is the certification maintained once I pass?
The credential is not permanent. It is maintained through annual delta exams that cover what changed in the platform, together with the yearly Certification Maintenance Program fee. Budget for both, and treat the delta exams as a small recurring commitment rather than a surprise.
Is the ServiceNow CSA worth it?
It is the platform's foundational administrator credential and the prerequisite that most other ServiceNow certifications assume, so it is the gate to the specialist tracks as well as a credential in its own right. For service desk staff, process owners and consultants moving into the ServiceNow ecosystem, it is the standard first step and it maps onto work an administrator actually does.
Examworthy is not affiliated with or endorsed by ServiceNow. This guide is original study material based on the public exam blueprint. We never reproduce live exam items. CSA and related marks belong to their respective owners.
