Part 2 Full Quiz

B is correct. ServiceNow best practice is to ALWAYS assign roles to Groups, not directly to individual user records. Users gain roles by being members of groups. This makes role management scalable: when an employee joins a team, you add them to the relevant group and they automatically inherit the right roles. Assigning roles directly to individual users bypasses this structure, is difficult to audit, and becomes unmanageable at scale. While it is technically possible to add roles to a user directly, it is explicitly against best practice and is a trap answer on the CSA exam.

B is correct. Impersonation allows an administrator to assume the identity of another user within their current browser session. While impersonating, the admin sees exactly the same interface, menus, forms, and data that the real user would see — it is the definitive way to verify security configurations. The admin can end impersonation at any time. Elevate Privilege (A) grants the current admin additional security permissions (like security_admin) — it does not switch to another user's identity. Options C and D are not standard ServiceNow features.

B is correct. ServiceNow role inheritance works cumulatively. A user inherits all roles from every group they belong to. Additionally, roles flow through nested group hierarchies — if a user is in Group A, they also inherit roles from any groups nested inside Group A. In this scenario: from Group A directly → "itil"; from Group A's nested sub-group → "change_manager"; from Group B → "problem_manager". The user effectively has all three roles. There is no concept of a "primary group" in ServiceNow (C), and roles do not conflict with each other (D).

B is correct. The three core identity tables to memorise for the CSA exam are: sys_user (Users — individual accounts that log in), sys_user_group (Groups — collections of users), and sys_user_role (Roles — permission sets assigned to groups). These sys_ prefixed names are the actual database table names used in queries, ACLs, and scripts. "user_table", "sys_person", and "cmdb_user" are not valid ServiceNow table names for user records.

B is correct. In ServiceNow, Extending a table creates a parent-child inheritance relationship. The child table (Hardware Request) inherits all fields, business rules, and ACLs from the parent table (Task). The Task table is the core base class — Incident, Problem, Change, and many other standard tables all extend Task. "Copy table" (A) is not a supported ServiceNow mechanism. Update Sets (C) are for migrating configurations between instances, not creating tables. Schema Map (D) is a read-only visualisation tool, not a configuration mechanism.

A is correct. The sys_dictionary table is ServiceNow's schema metadata table. Every table definition and every field definition (field name, type, length, default value, mandatory flag, reference to another table, etc.) has a row in sys_dictionary. When you create a new table or add a field, a new record is written to sys_dictionary. It is the foundation of ServiceNow's metadata-driven architecture. ACLs live in sys_security_acl (C). Translations are in sys_ui_message (D). There is no "all records" lookup table as described in B.

B is correct. Every ServiceNow record has a sys_id: a 32-character hexadecimal GUID (Globally Unique Identifier) like a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4. It is unique across the entire instance and never changes once assigned. The human-readable "Number" field (INC0012345) in option A is a display field for users — it is not the true unique identifier and is only unique within a single table. sys_id is used internally for all record references and relationships. Options C and D describe non-existent formats.

B is correct. The Schema Map (accessible from any table's context menu: Configure → Schema Map) provides an interactive graphical diagram showing how tables relate to each other — including inheritance (extends relationships) and reference fields pointing to other tables. It is a read-only visualisation tool. This is the correct tool to show an auditor or architect the database structure visually. Options A (Table Map), C (Dependency Map), and D (Relationship Designer) are not standard ServiceNow tool names.

B is correct. Creating, modifying, or deleting ACLs requires the security_admin role. Even users with the standard "admin" role cannot manage ACLs without it. The security_admin role is not permanently assigned — instead, admins Elevate Privilege to it via their profile menu for the current session only. This elevation does not persist when the session ends. High Security Settings (C) is a separate system property that adds an additional security layer — it does not grant the security_admin role. The itil role (A) is for ITSM fulfillers, completely unrelated to ACL management.

B is correct. This is one of the most tested security traps in the CSA exam. Elevating to security_admin is session-only — it lasts only for the current browser session. When the admin logs out (or the session expires), the elevation is automatically revoked. The next login starts without security_admin elevation, even if the same admin logs in. This design is intentional — it forces conscious re-activation of elevated privileges, reducing the risk of accidental ACL changes. Option D is wrong: there is no time-based expiry within a session. Option A is completely wrong — there is no persistence of elevation.

B is correct. ACL evaluation follows strict AND logic: Role check AND Condition AND Script must ALL return true for access to be granted. If any single component fails, access is denied. In this scenario, even though the Role check and Condition passed, the Script returning false causes the entire ACL evaluation to fail — access is denied. Each component is a gate, not a vote. The script is authoritative, not advisory (C is wrong). No error or security violation is logged for normal ACL denial (D is wrong).

B is correct. This is a fundamental ACL trap. ServiceNow ACL evaluation is hierarchical: table-level ACL is always evaluated first. If the table-level ACL denies read access, the system stops immediately — field-level ACLs are never even checked. A field ACL can only restrict access further (not grant access if the table ACL already denies it). The key rule: a field ACL cannot grant access that the table ACL does not allow. Options A, C, and D all incorrectly suggest field ACLs can override table ACL denial.

C is correct — "export" is NOT a standard ACL operation. The five valid ACL operations in ServiceNow are: read (view records/fields), write (edit records/fields), create (create new records), delete (delete records), and execute (run scripts/client callables). "Export" is not a separate ACL operation — exporting data is controlled via other mechanisms such as roles and High Security Settings. Knowing the exact five operations is a common exam question.

B is correct. ServiceNow dot-walking syntax uses the period (.) to traverse reference fields: reference_field.target_field. The Reference field is named "project" (its column name on the Incident table), and the target field is "budget" on the Project table — so the dot-walk expression is project.budget. This syntax works in conditions, field default values, reference qualifiers, and client scripts. Bracket notation (C) and arrow notation (D) are not valid ServiceNow dot-walking syntax. Option A is just a flat field name with no traversal.

B is correct. The symptom (can see the list but cannot open individual records) points to an ACL controlling record-level read access. The user can see the list because list queries use a different access mechanism, but opening a record triggers the table or row-level ACL. Since group-mates can open records, the table isn't globally restricted (C is wrong). The most likely explanation is that a read ACL requires a specific role that this particular user is missing — perhaps their group membership wasn't saved correctly, or a role was recently added as a requirement. Option A would prevent login entirely, not just record access.