CIS-ITSM Problem Management — Timed 15 Questions

Question 1

An administrator needs to configure Problem Management properties to automatically close related incidents when a Problem is closed. Where are these global properties accessed?

Accepted Answer

Problem Administration > Properties. The global properties for Problem Management, including those that control automatic closure of related incidents when a Problem is closed, are accessed via 'Problem Administration > Properties'. This module provides a centralized location for configuring Problem Management behavior.

Answer

ITSM Properties > General

Answer

Incident Management > Properties

Answer

System Properties > Problem

Question 2

During root cause analysis, a problem analyst identifies that a third-party application component is failing. The analyst wants to link an existing RFC (Request for Change) to the Problem record to track the remediation. How is this relationship established in ServiceNow?

Accepted Answer

By adding the change request in the 'Caused by change' or 'Change requests' related list on the Problem form. In ServiceNow Problem Management, the relationship between a Problem and a Change Request is established through the 'Change requests' related list (or the 'Caused by change' field when the change caused the problem). Adding the RFC to that related list creates the many-to-many link via the task_rel_change or problem_change relationship table, allowing the analyst to track remediation progress directly from the Problem record. This is the supported, out-of-the-box way to associate the two records.

Answer

By executing a background script to update the sys_audit table

Answer

By changing the task type of the problem to a change request

Answer

By modifying the Problem workflow XML to inject the change task ID

Question 3

An enterprise wants to ensure that when a Problem reaches the 'Resolved' state, any workaround discovered is automatically pushed to all active related Incidents. What is the recommended baseline feature to support this workflow?

Accepted Answer

Communicate Workaround UI Action / Business Rule logic. The baseline feature to push a workaround from a resolved Problem to related active Incidents is the 'Communicate Workaround' UI Action, which is backed by Business Rule logic. This UI Action appears on the Problem form when a workaround is added, and it triggers a business rule that updates all related active incidents with the workaround information. This is the recommended out-of-the-box approach.

Answer

Data Lookup Definitions

Answer

Scheduled Job running hourly

Answer

Inbound Action script

Question 4

An organization requires that when a Problem record moves to the 'Root Cause Analysis' state, the 'Work notes' field must become mandatory. Which ServiceNow feature should an administrator configure to achieve this without writing custom client scripts?

Accepted Answer

UI Policy. A UI Policy is the correct ServiceNow feature to make a field mandatory based on another field's value or the record's state, without writing client scripts. UI Policies run on the client side (and can be configured to run on the server) and can set fields to mandatory, read-only, or visible when conditions are met — exactly what's needed to make 'Work notes' mandatory when the Problem state is 'Root Cause Analysis'.

Answer

Data Policy

Answer

Business Rule

Answer

Client Script

Question 5

An administrator wants to customize the mandatory fields required when closing a Problem record. Where should this requirement be configured to maintain best-practice upgradeability?

Accepted Answer

Problem Administration > Properties. Problem Administration > Properties is the best-practice location for configuring mandatory fields on Problem closure because it uses system properties rather than customizing base system records. This approach preserves upgradeability by keeping customizations out of the core Task table and UI actions.

Answer

System UI > UI Actions > Close Problem

Answer

Global Client Script on the Task table

Answer

Dictionary Overrides on the State field

Question 6

A security requirement states that when a Problem record is marked with a Priority of 'Critical', only members of the assigned Problem group can view the record, overriding standard department-based ACLs. How should this be implemented?

Accepted Answer

By writing a script in a read ACL on the Problem table that checks if priority is critical and the user is in the assignment group. A read ACL with a script can evaluate both the record's priority and the user's membership in the assignment group, returning true only when priority is Critical and the user belongs to the assigned group. This overrides broader department-based ACLs because ACLs are evaluated with most-specific/deny-wins logic and scripted conditions can encode the exact business rule.

Answer

By updating the Problem Management properties file

Answer

By configuring a UI Policy to hide the entire form for non-group members

Answer

By using Data Filtration rules on the Task table

Question 7

An organization wants to categorize problems using a hierarchical tree structure (e.g., Hardware > Server > Memory). Which feature should an administrator configure to support dependent category dropdowns on the Problem form?

Accepted Answer

Dependent field attribute configured on the Dictionary entry. Dependent category dropdowns (e.g., selecting 'Hardware' filters the next field to 'Server', then 'Memory') are implemented in ServiceNow using the Dependent field attribute on the Dictionary entry. This attribute references a parent field and a dependent table, so the child field's choices are filtered based on the parent's value. It is the standard, out-of-the-box mechanism for hierarchical category selection on any form, including Problem.

Answer

Catalog Client Script

Answer

Data Lookup Matchers

Answer

Client Script with GlideRecord queries

Question 8

An organization wants to enable the 'Create Problem' button on incident forms only when the Incident Category is set to 'Network'. Where should this condition be evaluated?

Accepted Answer

In the Condition field of the 'Create Problem' UI Action record. The 'Create Problem' button is a UI Action, and UI Actions have a Condition field that controls when the button appears or is enabled. By setting the condition to evaluate the Incident's Category field (e.g., current.category == 'network'), the button will only be visible/enabled when that condition is true. This is the standard ServiceNow mechanism for conditionally displaying UI Actions, and it evaluates server-side when the form loads and on field changes if the UI Action is configured to do so.

Answer

In the Data Policy configuration

Answer

In a Client Script using g_form.setDisabled()

Answer

In a UI Policy applied to the Incident form

Question 9

An administrator needs to modify the default list layout for the Problem module so that all users see the 'Known Error' column by default. Where should this be configured?

Accepted Answer

Configure List Layout while logged in with no user preference overriding (Default view). The default list layout for any table in ServiceNow is controlled by the List Layout configuration accessed via the form context menu (Configure > List Layout) while viewing the table with no personal view override active. Saving this layout applies it as the system default for all users who have not personalized their own view. This is the standard mechanism for setting columns visible to everyone out of the box.

Answer

System UI > Views > Problem Default View

Answer

User Preferences table (sys_user_preference)

Answer

Navigation Pane Module Editor

Question 10

An ITIL process owner wants to ensure that when a Problem record is set to 'Resolved', the 'Root cause' field is mandatory. Which out-of-the-box or configurable feature should be verified or adjusted?

Accepted Answer

Problem Properties (com.snc.problem.mandatory_on_resolve). The Problem Properties module contains the system property com.snc.problem.mandatory_on_resolve, which controls whether the 'Root cause' field (and other fields like 'Fix notes') are mandatory when a Problem is set to Resolved. An administrator should verify or adjust this property to enforce the requirement. This is the out-of-the-box configuration point for making root cause mandatory on resolution.

Answer

Incident Management Properties

Answer

Change Management Properties

Answer

System Properties > UI Defaults

Question 11

A user with the 'itil' role tries to view a Problem record but receives an error stating 'Record not found' or is blocked by an ACL. What is the most likely cause?

Accepted Answer

The user lacks the 'problem' role required to read or write Problem records. In ServiceNow, access to Problem records is governed by ACLs that typically require the 'problem' role (or a role containing it, like 'problem_admin' or 'itil' combined with problem-specific roles depending on configuration). The 'itil' role grants broad read access to incident, problem, and change in many base systems, but if the ACLs have been customized or the user lacks the specific problem role, they will get 'Record not found' or be blocked. The most likely cause is a missing problem role.

Answer

The problem record was archived into an update set

Answer

The Incident Management plugin is inactive

Answer

The user's browser cache needs to be cleared

Question 12

An ITIL process architect wants to ensure that all Problem records include a mandatory 'Category' and 'Subcategory'. Where can this be enforced without writing custom validation scripts?

Accepted Answer

Dictionary entry configuration by setting Mandatory to true. The Dictionary entry configuration allows administrators to set a field as mandatory at the database schema level. By navigating to the Problem table's dictionary and setting the 'Mandatory' attribute to true for the 'Category' and 'Subcategory' fields, the system enforces that these fields must be populated before a record can be saved. This is a declarative, no-code approach that applies consistently across all forms and UI interactions, including API inserts, without requiring custom scripts.

Answer

Global System Properties file

Answer

Module Editor argument field

Answer

UI Action condition builder

Question 13

Which TWO fields are standard baseline fields on a Problem record in ServiceNow? (Choose two.)

Accepted Answer

Short description. Option A (Short description) is correct because it is a standard baseline field inherited from the Task table that every Problem record carries to give a brief summary of the issue. Option B (Root cause) is correct because the Problem table includes a dedicated Root cause field used to document the underlying cause of the problem after investigation. The remaining options do not belong: Patient diagnosis, Classroom ID, and Flight number are not baseline Problem fields and instead resemble custom or industry-specific fields (healthcare, education, and travel) that would only exist if added by a customer.

Answer

Patient diagnosis

Answer

Classroom ID

Answer

Flight number

Question 14

Which TWO roles are commonly associated with viewing or managing Problem records in ServiceNow? (Choose two.)

Accepted Answer

problem. Option D, the 'problem' role, is correct because it is the baseline ServiceNow role granted to ITIL users who need to create, view, and work on Problem records as part of the problem management process. Option E, the 'problem_admin' role, is correct because it is the elevated administrative role that provides full control over Problem records, including configuration and management of the Problem module. The other options do not belong: 'shipment_receiver' (A) and 'hotel_booking_user' (B) are unrelated line-of-business or custom roles, and 'financial_analyst' (C) is a finance-oriented role with no inherent access to Problem management.

Answer

shipment_receiver

Answer

hotel_booking_user

Answer

financial_analyst

Question 15

Which THREE states are part of the baseline ServiceNow Problem lifecycle model? (Choose three.)

Accepted Answer

Assess. The baseline ServiceNow Problem lifecycle model follows the states New, Assess, Root Cause Analysis, Fix in Progress, Resolved, and Closed, so option C (Assess) is correct because it is the state where the problem is evaluated and prioritized after creation. Option D (Fix In Progress) is correct because it is the state in which a known fix or workaround is being implemented for the problem. Option E (Root Cause Analysis) is correct because it is the dedicated state where the problem task team investigates and identifies the underlying root cause. Option A (Pending Customer Approval) is not part of the Problem lifecycle; that state belongs to Change Management approval workflows, not Problem. Option B (Archived Live) is not a Problem state either; archiving is handled by the separate Archived/Retired record state used for inactive records, not a lifecycle state in the Problem model.

Answer

Pending Customer Approval

Answer

Archived Live