ServiceNow Certified System Administrator (CSA) practice questions

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.

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.

Eight new starters must gain the access that approving change requests requires. An administrator creates a group named Change Approvers, adds the eight users as members, and finds their access is unchanged because the group carries no roles. Which action grants the access and keeps future starters working with the least ongoing maintenance?

• AGrant the role directly on each of the eight user records, so the assignment is explicit on the user and visible to anyone auditing that individual account.
• BAdd the role that carries the change approval access to the Change Approvers group record, so every current member and every future member inherits it through group membership.check_circle Correct
• CCreate an access control rule on the change request table that names the Change Approvers group in place of a role, so the group itself becomes the security check.
• DSet Change Approvers as the parent of a group that already holds the role, so the members of the new group pick up the roles held by the child group beneath it.

Why A is wrong: Tempting because direct role assignment does work and is easy to audit, but it must be repeated for every joiner and unpicked for every leaver, which is exactly the maintenance the group is there to remove.

Why B is correct: Correct: a role granted to a group is inherited by all of its members, and membership changes apply the role automatically without any further role administration.

Why C is wrong: Tempting because the group is the object the administrator has just built, but access control rules are satisfied by roles and conditions; a group is a container for members and roles, not a value the required roles list accepts.

Why D is wrong: Tempting because nested groups genuinely do pass roles down a hierarchy, but inheritance runs from parent to child, so members of a parent group gain nothing from the roles held by a child group.

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.

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.