ServiceNow ACL and Security Interview Questions and Answers

Access control is the round where admin and developer candidates separate. The sixteen questions below come from the RizeX Labs question bank, drawn from the ACL, Security and Access, and SecOps sections, plus the form load execution sequence question and two access control scenarios. The answers sit at the level an interviewer expects from someone who has configured security on a real instance: ACL types and notation, the order rules evaluate in, the three conditions inside every rule, the security_admin role, high security settings, and the query business rule that filters rows before a list is built.

ACL fundamentals

What is ACL?

An ACL, or Access Control List, is a rule that decides whether a user may perform an operation on an object. Most ACLs you will work with are record ACLs, stored on sys_security_acl, controlling access to tables, fields and records.

Every ACL contains three conditions, and all of them must pass before access is granted.

A rule with only a condition still works. A rule with all three filled is the strictest form, because the user needs the role, the record must match the condition, and the script must return true.

Here is a write ACL script on the comments field of incident. Only the assigned user or a member of the assignment group may add comments.

// ACL: incident.comments, operation = write
// The script must set the variable "answer" to true or false.
answer = false;

if (gs.hasRole('itil')) {
    var groupName = current.assignment_group.getDisplayValue();

    if (current.assigned_to == gs.getUserID()) {
        answer = true;
    } else if (groupName && gs.getUser().isMemberOf(groupName)) {
        answer = true;
    }
}

Two points an interviewer listens for. The script runs server side, so current is a GlideRecord and client objects such as g_form do not exist. And the script sets answer, it does not return it.

Creating an ACL is itself protected. You need the security_admin role, and holding it is not enough. It is a privilege elevation role, dormant until you raise it for the current session from the user menu, and the New button on the Access Control list stays hidden until you do. The elevation ends with the session. This behaviour comes from the high security settings under System Security, which also enforce default deny: if no ACL matches the object for the operation attempted, access is refused rather than allowed.

Types of ACLs?

ACLs are categorised two ways, and candidates usually know only the second.

By type, meaning the kind of object protected:

• Record, covering tables, fields and rows. This is the common one.
• Client callable Script Include, controlling which Script Includes a client script may call through GlideAjax.
• Processor, UI Page and REST endpoint, protecting those specific objects.

By operation, meaning the action attempted on a record ACL:

• create
• read
• write
• delete
• list_edit, for editing from a list view
• report_on, for whether the table or field can be reported on

A record ACL is named using table.field notation. incident.comments protects one field on one table. incident.* protects every field on incident. *.number protects the number field on every table. *.* is the catch-all at the bottom.

Difference between table and field ACL?

A table ACL is row level. It answers whether the user may touch the record at all, and its name is just the table, such as incident.

A field ACL is column level. It answers whether the user may see or change one field on a record they are already allowed to touch, and its name carries the field: incident.comments.

The relationship between them is where marks are won. They are an AND, not an OR.

A candidate who says "the user has the role so the field should be visible" has missed this. The role may satisfy the field rule and still fail the table rule, and then the record never loads.

What is role inheritance?

Role inheritance means a role can contain other roles, and a user granted the parent role automatically receives everything the contained roles grant. The relationship lives on sys_user_role_contains, configured from the Contains Roles related list on the role record. Grant itil and the user quietly picks up the lower level roles it contains.

The admin role sits at the top and passes almost every ACL without evaluating conditions, with one deliberate exception: rules requiring security_admin still need that elevation for the session.

Roles also reach users through groups. Assign a role to a group and every member holds it, and loses it the day they leave. That is how roles should be granted on a real project, because joiner and leaver handling becomes group membership instead of user by user edits.

Do not confuse this with table inheritance. Incident extends Task, so an ACL on task applies to incident records when no more specific rule exists. That is table hierarchy, a different mechanism.

Order of ACL evaluation?

Evaluation runs in a fixed sequence and both stages must pass.

1. Table level first. The row rule for the operation is checked. If it fails, evaluation stops and the record is not returned.
2. Field level second. For each field on the record, the matching field rule is checked.

Within each stage the platform matches rules from most specific to least specific. For a write on the comments field of incident, the search order is:

1. incident.comments
2. incident.*
3. task.comments, then task.*, walking up the table hierarchy
4. *.comments
5. *.*

Specific beats wildcard. Once a matching rule exists at a level of specificity, that rule decides, and the broader wildcard below it is not what grants access. This is why adding a permissive *.* rule does not rescue a user failing a rule on incident.comments.

Where two rules match at the same specificity for the same operation, satisfying one clears that level. Across levels the logic is still AND, so clearing the field level achieves nothing if the table level refused.

If no rule matches at all, high security settings deny the operation. Silence is not permission.

What the interviewer is actually checking

• Whether you can name the three parts of an ACL and say what happens when one is left blank.
• Whether you read table.field notation well enough to predict which rule fires.
• Whether you know table and field rules are an AND, and can describe the half-open record that results when only the field rule fails.
• Whether you know that writing ACLs needs security_admin switched on for the session, not merely granted.
• Whether you treat a missing rule as a deny.

ACLs in the execution sequence and in real scenarios

What is the sequence of execution between ACL, business rules, client script and UI policies while a form loads?

Most candidates can name the four objects and cannot say when each one runs. Our trainer's line on this is that candidates know syntax but not execution: when it runs, where it runs, what data it can reach. Client side versus server side is the ServiceNow version of that gap.

Server side runs first. The browser gets involved only at the end.

1. Query business rule. Runs as the record is fetched and can add conditions that remove rows before anything else sees them.
2. Read ACLs. Table level first, then field level, deciding which record and which fields are returned.
3. Display business rule. Runs after the read and before the form is sent, typically to populate g_scratchpad.
4. Form renders in the browser.
5. onLoad client scripts. Now g_form exists.
6. UI policies apply, after the onLoad client scripts, which is why a UI policy can override what a client script just set.

The point to land: a field hidden by a read ACL never reaches the browser, while a field hidden by a UI policy is already in the page and recoverable by anyone who looks. Security is server side. Presentation is client side.

Explain access control behaviour with multiple roles?

When a user holds more than one role, access is additive. Roles never cancel each other out.

• Inside a single ACL, the Requires role list is an OR. Holding any one role on that list satisfies the role condition, and the user must still clear the condition and the script.
• Across ACLs at the same specificity, passing one of them is enough.

So adding a role can only widen access or leave it unchanged. It can never remove access. If a user with four roles is refused, the cause is not a conflict between roles. Either no matching rule at that level accepts any of them, or a condition or script inside the rule returns false for that particular record.

That distinction is the debugging answer, and debugging is where candidates fall over. "This user cannot see the Comments field, what do you check" beats "what is an ACL" every time. The method: impersonate the user, switch on Security Debug from the settings menu, reload the record, and read which rule evaluated and which condition failed.

How to show inactive incidents only to admins?

Use a before query business rule on the incident table, not a client script and not a saved list filter.

(function executeRule(current, previous /*null when async*/) {

    // Skip for admins and for non-interactive sessions such as
    // integrations, scheduled jobs and background scripts.
    if (gs.hasRole('admin') || !gs.isInteractive()) {
        return;
    }

    current.addQuery('active', true);

})(current, previous);

Set it to run before, with the Query checkbox ticked, on the Incident table, with no condition.

Why a query rule and not an ACL. The query rule adds its condition to the database query itself, so inactive records are never fetched. A read ACL runs per row after the query returns, strips the rows the user fails, and shows the message about rows removed by security constraints. The query rule is cheaper and quieter.

Two points worth adding. It applies to lists, reports and any GlideRecord query in a user session, so the filtering stays consistent everywhere, while gs.isInteractive() keeps integrations and scheduled jobs working on the full data set. And a query rule is a filter, not a permission, so a user who knows a sys_id could still reach the record directly. Where the data is genuinely sensitive, pair it with a read ACL.

What the interviewer is actually checking

• Whether you separate server-side enforcement from client-side presentation.
• Whether you know roles add up, and can locate the real cause of a refusal.
• Whether you reach for a query business rule for row filtering instead of a client script.
• Whether you can describe a debugging method rather than a definition.

Security and access

What is impersonation in ServiceNow?

Impersonation lets an administrator run a session as another user and see the instance exactly as that user sees it. You start it from the user menu, pick the user, and the session switches until you end it.

It is the correct way to test ACLs, because the target user's roles apply rather than yours. While impersonating you lose your own admin rights, and any session privilege from security_admin is dropped. Impersonation sessions are recorded in the system logs, so the activity traces back to the real administrator.

What is domain separation?

Domain separation splits data and process configuration into logical groupings called domains, arranged in a hierarchy with the global domain at the top. Users in one domain see only their own domain's records, and configuration such as workflows and business rules can differ per domain.

The typical use case is a managed service provider running several customers on one instance. Two levels exist: data separation, which controls record visibility, and process separation, which allows different behaviour per domain.

Say clearly that domain separation sits alongside ACLs rather than replacing them. ACLs still evaluate on top of the domain filter.

What is user criteria?

User criteria are reusable records defining a set of users, built from any combination of users, groups, roles, companies, departments or locations, or from a script for anything more complex.

They control visibility in the Service Catalog and in Knowledge Management, not on ordinary tables. A catalog item or category carries Available For and Not Available For lists, and knowledge articles use Can Read and Cannot Read. Not Available For wins where both apply.

Draw the line for the interviewer: user criteria decide who sees an item in the catalog or an article in a knowledge base, while ACLs decide who can read and write records on a table. Neither one covers the other.

What the interviewer is actually checking

• Whether you test access by impersonating rather than by reasoning about it.
• Whether you know impersonation drops your own privileges and is logged.
• Whether you can place domain separation, user criteria and ACLs on the correct layer.

SecOps

What is SecOps?

Security Operations is the ServiceNow application family that brings security work onto the same platform as IT service management. It connects detection tooling to structured response workflow and uses the CMDB to tell you what a given alert is sitting on. The main applications are Security Incident Response, Vulnerability Response, Threat Intelligence and Configuration Compliance.

The value argument is that CMDB link. A vulnerability on a server means little until you know the server supports a revenue-critical service, and that relationship already exists in the CMDB.

What are security incidents?

A security incident is a record of a suspected or confirmed security event needing investigation and response. It lives on its own table rather than the ITSM incident table. Phishing reports, malware detections and unauthorised access attempts all become security incident records.

They are created from SIEM integrations, from alert ingestion, from a reported phishing mailbox, or manually by an analyst. They carry their own fields for risk score, severity, category and affected configuration items, and they route to the security team rather than the service desk.

What is vulnerability response?

Vulnerability Response ingests vulnerability data from third-party scanners such as Qualys, Tenable and Rapid7, and turns it into work the organisation can action.

1. The scanner reports a vulnerability against a host.
2. The platform matches that host to a configuration item in the CMDB.
3. It creates a Vulnerable Item, the pairing of one vulnerability with one CI.
4. Related vulnerable items are collected into Vulnerability Groups, so remediation is planned once rather than a thousand times.
5. Remediation goes out as a change request or a remediation task to the owning group.

Prioritisation uses CMDB context, so a vulnerability on a CI supporting a critical business service rises above the same vulnerability on a test box.

What is threat intelligence?

Threat Intelligence supplies external context to a security incident. It brings in indicators of compromise, also called observables, from threat feeds and lookup sources. IP addresses, file hashes, domains and URLs are the usual ones.

When an analyst works a security incident, the observables on that record are enriched against those sources, and the analyst gets an evidence-backed answer on whether an indicator is known-bad instead of a personal opinion.

Security incident lifecycle?

The lifecycle follows the NIST response model, and the state field walks through it in order.

Do not simply recite the seven stages. Attach one concrete action to each, because a memorised definition collapses the moment the interviewer asks for a real project example.

What the interviewer is actually checking

• Whether you know security incidents live on their own table, not on the ITSM incident table.
• Whether you can explain why the CMDB link makes prioritisation possible.
• Whether you follow the vulnerability to CI to vulnerable item to group chain.
• Whether you can attach a real action to each lifecycle stage.

Before you sit the interview

Security questions reward demonstration over recall. Open a developer instance, create a field ACL on a table you understand, impersonate a user without the role, turn on Security Debug and watch which rule fails and why. Then build the query business rule from the inactive incidents scenario and confirm it filters lists, reports and background queries the same way. Do that twice and your answers stop sounding memorised.

For structured practice on these topics, with instance access and mock interview rounds, see the ServiceNow training programme at RizeX Labs.