ServiceNow Certified System Administrator CSA (SNOW-CSA) — Questions 451–504

Why this answer

How to eliminate wrong answers

Option B is wrong because the UI Policy explicitly hides the 'assignment_group' field when state is 'In Progress', so it does not remain visible. Option C is wrong because Client Scripts do not override UI Policies; UI Policies are designed to enforce field behavior (mandatory, visible) and take precedence over Client Scripts that might try to change those properties. Option D is wrong because there is no indication of an error; the UI Policy and Client Script can coexist without causing an error, and the UI Policy's mandatory and hide actions execute successfully.

Why this answer

How to eliminate wrong answers

Option B is wrong because the question explicitly states there is no ACL restricting the section, so an ACL cannot be the cause. Option C is wrong because mandatory fields affect submission validation, not visibility; they do not hide a section from users. Option D is wrong because if 'Visible' were set to false in the form layout, the section would be hidden from all users, including admins, which contradicts the scenario where admins can see it.

Why this answer

How to eliminate wrong answers

Option B is wrong because CI classification rules are stored in the 'cmdb_class' table, not 'cmdb_rel_ci'. Option C is wrong because the CI hierarchy tree is derived from the 'cmdb_rel_ci' table but is not stored as a separate tree structure; the hierarchy is built dynamically from the relationship records. Option D is wrong because the list of all relationship types is stored in the 'cmdb_rel_type' table, not 'cmdb_rel_ci'.

Why this answer

How to eliminate wrong answers

Option A is wrong because ServiceNow does not automatically store both values in a history field; field history is only recorded if the 'Audit' feature is enabled on the field, and even then it tracks changes over time, not both values from a single update. Option B is wrong because the database does not reject the second change; ServiceNoW's database engine (MySQL/MariaDB) processes the final value after all business rules run, and no conflict detection is triggered for sequential updates within the same transaction. Option D is wrong because the 'before' business rule runs first, but its value is overwritten by the later-executing 'after' business rule, so the 'before' value is not the final stored value.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because increasing the 'CMDB History Pruning Frequency' property only controls how often the system checks for records to prune (delete), not the archival of old records; it does not archive data and may lead to permanent deletion if combined with pruning rules. Option B is wrong because manually deleting rows from the `cmdb_ci_history` table using SQL violates ServiceNow's supported practices, bypasses the platform's audit and security controls, and can cause data integrity issues or break application logic. Option D is wrong because running a scheduled report to export and then delete records is a manual, error-prone process that does not leverage ServiceNow's native archival capabilities, risks incomplete or inconsistent data removal, and lacks the automated tracking and rollback features of the Archive Old Records functionality.

Why this answer

How to eliminate wrong answers

Option A is wrong because manually changing the class field to 'cmdb_ci' would require explicit user action and is not a typical cause for multiple CIs having the base class; the administrator is discovering the issue, not causing it. Option B is wrong because Discovery sensors classify CIs based on identification and classification rules; if a sensor fails to classify, the CI would typically remain unclassified or get a default class, not specifically 'cmdb_ci' — the base class assignment is driven by the identification rule's table mapping. Option D is wrong because retiring a CI does not reset its class; retirement only changes the 'Install Status' field to 'Retired' and does not alter the 'sys_class_name'.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because the script works in development, implying the external table exists; the production failure is likely due to permissions or context, not table existence. Option B is wrong because system logs may not capture client-side script errors; client scripts run in the browser, and errors are typically logged in the browser console, not the instance system logs. Option D is wrong because the question specifies a catalog client script, not a workflow; workflows are server-side and not directly related to client script execution.

Why this answer

How to eliminate wrong answers

Option A is wrong because a multi-select checkbox allows the user to select multiple values simultaneously, which is inappropriate for a mutually exclusive license type selection. Option B is wrong because a text field would require manual entry, introducing the risk of typos, inconsistent formatting, and invalid values that would break downstream automation or reporting. Option C is wrong because a checkbox is a binary (true/false) control and cannot represent three distinct license types.

Why this answer

How to eliminate wrong answers

Option A is wrong because the workflow context variable for 'requested for' is not a standard variable; the 'Set Requested For' activity uses its own configuration, not a context variable. Option B is wrong because an unpublished workflow would prevent the catalog item from functioning entirely, not just cause a specific field to be set incorrectly. Option D is wrong because catalog item variable mappings control how variables are passed to the workflow, not the 'Requested for' field, which is a system field handled separately by the 'Set Requested For' activity.

Why this answer

How to eliminate wrong answers

Option A is wrong because `sys_journal_field` stores journal entries (like work notes or comments) attached to records, not the change log for CMDB CIs. Option B is wrong because `sys_audit` tracks changes to any table's records via audit rules, but it is a generic auditing table, not the dedicated CMDB CI history table. Option C is wrong because `cmdb_ci` is the main table that stores the current state of CIs, not the historical change log.

Why this answer

How to eliminate wrong answers

Option A is wrong because a business rule runs server-side and cannot dynamically change field properties like mandatory on the client form in real-time without a page refresh. Option B is wrong because a client script with onChange event can detect the field change but cannot directly make another field mandatory; it would require additional scripting to manipulate the UI, which is not the standard or recommended approach. Option D is wrong because a data policy enforces mandatory fields at the database level during record submission, not interactively on the form as the user changes fields.

Why this answer

How to eliminate wrong answers

Option A is wrong because setting the 'Order' field to 0 does not hide the item; it simply places it at the top of the list (lowest order value) or may cause it to appear first, not disappear. Option C is wrong because a 'Roles' restriction would prevent the item from being visible to users without that role, but the question states the item is not visible to end users at all, not that it is visible to some but not others; the 'Portal' field is a more direct cause for complete invisibility. Option D is wrong because the 'Module' field is not a standard field on a catalog item; it is used on record producers or other configurations, and the Service Catalog module is automatically associated with catalog items via the 'sc_cat_item' table, so this is not a relevant setting.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because User Criteria is used to control which users can see or access specific catalog items, knowledge articles, or records, not to enable password reset functionality. Option B is wrong because the Password Reset Plugin is a legacy feature that enables password reset via email links or the instance login page, but it does not integrate with the Service Portal's native self-service interface. Option D is wrong because ACLs (Access Control Lists) control read/write permissions on records and fields, not the ability to reset passwords through a self-service portal workflow.

Why this answer

How to eliminate wrong answers

Option B is wrong because creating a new UI Policy would be redundant and ineffective if the dictionary-level 'Visibility' field is set to 'Admin', as dictionary settings override UI Policies. Option C is wrong because adding the 'itil' role to the 'Roles' field on the dictionary entry would restrict the field to only users with that role, but the field is already missing for 'itil' users, and the current 'Roles' field is empty, so this would not solve the issue. Option D is wrong because ACLs control data access and security, not form field visibility; the field is already visible to admins, indicating no ACL issue, and the problem is a UI-level visibility setting.

Why this answer

How to eliminate wrong answers

Option B is wrong because missing data in the coalesce field would cause a different error (e.g., 'Coalesce field is empty' or a null coalesce failure), not a 'not found on target table' error. Option C is wrong because the staging table configuration (e.g., table name, columns) does not affect the coalesce field lookup; the error is specific to the transform map's mapping of the coalesce field to the target table. Option D is wrong because if the target table did not have the specified coalesce field, the error would occur at transform map creation or validation time, not during import set row processing; the error message explicitly states 'not found on target table' but the actual issue is the lack of mapping in the transform map, not the absence of the field on the table.

Why this answer

How to eliminate wrong answers

Option B is wrong because current.update() with a query still performs a database write, which will re-trigger the business rule and cause recursion; there is no built-in mechanism to suppress recursion via query parameters. Option C is wrong because checking if the risk field is already set does not prevent recursion—the business rule still calls current.update(), which will fire the rule again regardless of the field's current value. Option D is wrong because changing the business rule to run after instead of before does not solve the recursion; current.update() in an after business rule also writes to the database and re-triggers the rule, and after rules are typically used for non-field-setting actions like notifications.

Why this answer

How to eliminate wrong answers

Option A is wrong because SSO Configuration is used for single sign-on authentication via external identity providers (e.g., SAML, OAuth), not for enabling users to reset their own passwords within ServiceNow. Option C is wrong because LDAP Integration synchronizes user accounts and attributes from an external directory (e.g., Active Directory) but does not provide a built-in mechanism for users to reset passwords through the ServiceNow portal; password reset would still require external directory tools or additional configuration. Option D is wrong because Virtual Agent is a chatbot for conversational self-service, but it does not natively handle password reset functionality unless specifically configured with flows or integrations; the core feature for password reset is the dedicated Password Reset module.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because an ACL defined on a different table that extends 'incident' would still apply to the 'incident' table via inheritance, and if it grants write access, it would not prevent updates. Option C is wrong because a read ACL that denies read access would prevent users from viewing records, but it does not directly block write operations; write operations are controlled by separate write ACLs, and the administrator confirmed no other write ACLs exist. Option D is wrong because the 'High Security' setting in application properties affects table-level security by requiring the 'admin' role for all operations, but it does not selectively block updates for the 'itil' role; it would block all access unless the user has the 'admin' role.

Why this answer

How to eliminate wrong answers

Option B is wrong because the 'Prevent duplicates' flag is a UI-level setting that prevents manual creation of duplicate CIs in the CMDB interface, but it does not control duplicate creation from automated discovery sources. Option C is wrong because reconciliation rules handle conflict resolution (e.g., which source's attribute values to trust) after identification has already matched CIs; they do not prevent the initial creation of duplicate CIs. Option D is wrong because read-only mode prevents all CI creation and modification, so no duplicates would be created at all; the administrator would see errors or no changes, not duplicates.

Why this answer

How to eliminate wrong answers

Option A is wrong because if the field is already mandatory by dictionary, the UI Policy's mandatory setting would be redundant but not prevented; the field would still be mandatory. Option B is wrong because UI Policy order determines execution sequence among multiple policies, but a policy with a false condition will not apply its actions regardless of order. Option D is wrong because 'Run on load' only means the policy runs when the form loads, but if the condition is false at load time, the mandatory action still won't be applied; the issue is the condition, not the trigger timing.

Why this answer

How to eliminate wrong answers

Option A is wrong because a CMS banner is designed for content management system pages, not for platform form views like the incident module, and would require additional configuration to appear on forms. Option C is wrong because a UI Script that runs on load adds unnecessary complexity and maintenance overhead for a simple static message, and it requires scripting knowledge. Option D is wrong because a UI Policy with an 'always true' condition is overkill for a static message; UI Policies are intended for dynamic field behavior and conditions, and using one for a static message introduces unnecessary processing and maintenance.

Why this answer

How to eliminate wrong answers

Option A is wrong because the 'Run As' property affects the security context under which the workflow runs, but if approval records are already created and conditions are met, the issue is not about permissions to execute actions—it's about the workflow logic not advancing. Option B is wrong because if the workflow were not published, it would not run at all, and no approval records would be created; the administrator has verified that approval records exist, so the workflow must be published and active. Option C is wrong because approval rules define who approves and under what conditions, not the order of workflow state transitions; the order of approval rules does not cause a request to remain in 'Pending' if the approval records are already created.

Why this answer

How to eliminate wrong answers

Option A is wrong because Jane Smith is not mentioned as a member of the IT Managers group, and the approval is still pending, not approved. Option C is wrong because John Doe is not referenced in the exhibit or the approval configuration; the approval is assigned to a group, not an individual. Option D is wrong because there is no indication of rejection by Bob Lee; the flow is still waiting for approval.

Why this answer

How to eliminate wrong answers

Option A is wrong because designing custom forms is the purpose of the Form Designer (or UI Builder), not Flow Designer; Flow Designer focuses on workflow logic, not form layout. Option B is wrong because configuring reports and dashboards is handled by the Reports module and Performance Analytics, not by Flow Designer, which is strictly for automation flows. Option D is wrong because managing user roles is done through the User Administration or Role Management modules, whereas Flow Designer has no role in role-based access control.

Why this answer

How to eliminate wrong answers

Option A is wrong because scheduling a report to run at night affects when the data is refreshed, not the visibility of the report in the navigation menu. Option B is wrong because the question states the report was shared with the IT team, implying they have the necessary roles; the issue is specifically about the report not appearing in the navigation menu, which is controlled by the 'Public' flag, not roles. Option D is wrong because an unsupported chart type would cause an error when viewing the report, not prevent it from appearing in the navigation menu.

Why this answer

How to eliminate wrong answers

Option A is wrong because g_form.setDisplay() is a valid method for showing or hiding a variable, and if used correctly with the right parameters (e.g., g_form.setDisplay('variable_name', true)), it would work; the issue here is that the script does not run at all, not that the method is misused. Option C is wrong because if the condition were written with g_form.getValue for the wrong variable, the script would still execute but evaluate incorrectly; the symptom of the variable not appearing at all indicates the script is not firing, not a logic error in the condition. Option D is wrong because the question states the script runs on 'onChange' of the first variable, so it is not set to 'onLoad'; if it were onLoad, it would run when the form loads, not on a field change, but the problem description confirms the intended event is onChange.

Why this answer

How to eliminate wrong answers

Option A is wrong because the UI Policy does not include any action to hide the cost_center variable; it only sets mandatory to false. Option B is wrong because the policy sets mandatory to false, not true, so the variable does not become mandatory. Option D is wrong because the policy does not change the read-only property of the cost_center variable; it only affects its mandatory state.

Why this answer

How to eliminate wrong answers

Option A is wrong because a task record is not created unless the transform map explicitly targets the Task table or uses a condition to change the target table; the mapping shows 'incident' as the target table. Option B is wrong because 'short_desc' is a valid source field name, and the target field 'short_description' is correct for the Incident table; the import will not fail due to an incorrect field name. Option D is wrong because if coalesce is enabled and a matching incident record exists, the transform engine will update that record rather than create a new one; a new incident is only created if no match is found.

Why this answer

How to eliminate wrong answers

Option A is wrong because the 'approval_admin' role does not exist in ServiceNow; there is no built-in role that universally overrides approval constraints. Option B is wrong because 'Delegate to group' in an approval activity sends the approval to a group, but the group manager is not automatically granted approval authority—the group manager only manages group membership, not approvals. Option D is wrong because approval delegation enables a user to delegate their own approvals to another user, but it does not allow a non-manager to approve requests that require manager approval; the approval group membership alone does not bypass the manager approval requirement unless the catalog item's approval rule is set to use that group.

Why this answer

How to eliminate wrong answers

Option B is wrong because a line chart with trend over time shows how a metric changes across a time series, not a single average value; it would display fluctuations in resolution time per period rather than the overall average. Option C is wrong because a bar chart with count of incidents shows the number of incidents, not the average resolution time; it answers 'how many' not 'how long'. Option D is wrong because a scorecard with gauge typically displays a single metric against a target (e.g., current SLA compliance percentage), not the average of a calculated field like resolved time.

Why these pairings

Why this answer

How to eliminate wrong answers

Option A is wrong because Jane Smith has not been recorded as approving the request; the exhibit shows no approval action has occurred. Option B is wrong because 'Any one approves' does not require a specific approver like John Doe; it waits for any member of the group. Option D is wrong because Bob Lee has not rejected the request; no rejection action is indicated in the exhibit.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because enabling only the system property does not specify who the delegate is; the delegate must also be configured on the user record. Option B is wrong because the 'Delegate' related list is not available on approval rules; delegation is configured on the user record, not on the rule itself. Option C is wrong because configuring the delegate on the user record alone, without setting the 'Approval Delegation' property to true, will not activate the delegation functionality.

Why this order

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because modifying the form view to remove the button would permanently hide it for all users, including administrators, which does not meet the requirement of allowing it for administrators. Option C is wrong because a Business Rule runs server-side and cannot directly hide a UI element on the form; it would require additional client-side scripting or a UI Policy to achieve the visibility change. Option D is wrong because an ACL controls data access and record-level operations (like delete), not the visibility of UI elements on the form; an ACL would prevent the delete action but would not hide the button itself.

Why this answer

Why this order

Why this answer

How to eliminate wrong answers

Option B is wrong because the rule does not check any timestamps or prevent updates; it only updates the parent's timestamp after a child update. Option C is wrong because the rule does not write to a custom table or use any logging mechanism like 'gs.log' or 'GlideRecord.insert' to a separate table. Option D is wrong because the rule does not perform any delete operations; it only updates a timestamp field on the parent, and there is no cascading delete logic.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because managing user roles and permissions for the CMDB is handled through the Role Administration module and Access Controls (ACLs), not the CMDB Health Dashboard. Option C is wrong because visualizing relationships between CIs is the purpose of the Service Graph Connector or the CI Relationship Map, not the Health Dashboard. Option D is wrong because configuring discovery schedules and probes is done within the Discovery module, specifically in the Discovery Schedules and Probe configurations, not the CMDB Health Dashboard.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because the task creation activity does not have a default to assign to the requester; the assignment behavior depends on the activity's configuration, such as the 'Assignment group' or 'Assigned to' fields, which are not set to the requester by default. Option C is wrong because a 'Set Values' activity after approval would not fix the issue; the assignment must be configured within the 'Create Task' activity itself or via a script that explicitly sets the task's assignment fields. Option D is wrong because the approval activity approves by the manager but does not reassign the request; it only changes the state of the approval record, not the `assigned_to` field of the request or task.

Why this answer

How to eliminate wrong answers

Option A is wrong because it omits the priority<=3 condition; the script explicitly includes 'priority<=3' in the encoded query, so incidents with priority 4 or 5 would be excluded even if state=3 and assigned_to is not null. Option C is wrong because it ignores both the state=3 and assigned_toISNOTEMPTY conditions; the query requires all three filters, not just priority<=3. Option D is wrong because the query is not empty—it applies three specific conditions, so not all incidents are returned.

Why this answer

How to eliminate wrong answers

Option A is wrong because modifying the import set table to store employee numbers as strings with leading zeros does not fix the coalesce matching issue; the coalesce compares against the target table field, which still lacks leading zeros, so duplicates would persist. Option C is wrong because changing the coalesce field to a different unique field like email address is a workaround that avoids the root cause and may introduce new matching problems if email is not consistently unique or present. Option D is wrong because a before business rule on the Employee table runs after the record is already created or updated, so it cannot prevent the duplicate creation caused by the coalesce failing to match during the import.

Why this answer

How to eliminate wrong answers

Option B is wrong because if the admin_group did not exist, the script would likely throw an error or return true (depending on implementation), but the question states the user is denied access, so the group must exist. Option C is wrong because the ACL does not require both the role and group membership; the script overrides the role check entirely, so the condition only checks group membership, not the role. Option D is wrong because gs.getUserID() == 'admin' is not shown in the exhibit; the script uses gs.getUser().isMemberOf('admin_group'), not a user ID comparison.

Why these pairings

Why this answer

How to eliminate wrong answers

Option A is wrong because the 'Can read' role on the 'Request' table controls whether a user can view existing request records, not whether they can see catalog items in the service catalog; catalog item visibility is governed by user criteria and roles on the item itself, not table-level read permissions. Option C is wrong because custom URLs or encoding issues would affect the entire portal or category display, not selectively hide specific items from users who meet the criteria, and the administrator already verified the portal's 'Catalog Categories' and 'Homepage' configuration are correct. Option D is wrong because fulfillment groups determine who can fulfill a request, not who can see or submit the catalog item; visibility is controlled by user criteria and roles, not fulfillment group membership.

Why this answer

How to eliminate wrong answers

Option B is wrong because clearing the browser cache would not resolve a role-based visibility issue; it only addresses client-side caching problems. Option C is wrong because deactivating and reactivating the module does not change role assignments; it would only affect the module's active state, not its role requirements. Option D is wrong because assigning the 'admin' role is an overprivileged workaround that bypasses proper role-based access control and is not a recommended troubleshooting step.