Question Q-8800 Which of the following are valid **states** for an Incident…
2 comments · last active May 25, 2026
ServiceNow IT Service Management Modules
By Marcus Chen · Updated May 25, 2026
| Questions | 22 |
| Passing Score | 75% |
| Format | 59% Multiple Choice |
| Sessions Logged | 729 |
| Your progress | Log in / Register to track times taken, best score, questions mastered, and coverage on this quiz. |
| Rating |
Topics covered
Uncategorized22 questions
Discussion
Log in to post a comment, reply, or expand a question.
CMDB needs Discovery/MID/import — not magic real-time self-populate. False.
Accuracy = quality of discovery feeding it.
Knowledge Management: KB articles linked from incidents for faster resolution / deflection.
Known error articles differ from generic how-to — tied to problem records.
Matching: incident→incident table, problem→problem, change→change_request, request→sc_request.
All extend task — common fields inherited.
Unplanned disruption = Incident Management. Change is planned; request is catalog fulfillment.
Problem is root cause investigation, not the live outage ticket.
Valid change types: Standard, Normal, Emergency — not Advisory or Scheduled as SN types.
Multi-select: pick three real ones only.
Standard change does NOT need full CAB each time — pre-approved template. Statement is False.
Normal still goes through CAB; that's the trick.
Normal change = full CAB path. Standard is pre-approved low risk — don't swap them.
Emergency = expedited/ECAB when service restoration can't wait.
Resolve incidents first, then Problem → Known Error → Change for permanent fix. Jumping straight to change (opt A) skips RCA.
Same failing switch 3x = problem candidate, not three unrelated incidents forever.
Problem record = root cause + workaround + path to permanent fix → Known Error in KEDB.
Not the same as resolving the user's active outage — that's incident.
Catalog request creates sc_request + sc_req_item (RITM) per item — fill-in blank favorite.
Child tasks under RITM for multi-step fulfillment.
SLA can pause on state; multiple SLAs per record (response + resolve). Breach doesn't auto-close incident.
+2 votesPriority-only condition (opt D) is false — conditions can use any fields.
Question catalog for this preview
Catalog listing of the 5 preview questions for this quiz.
Question 1
Which of the following are valid **states** for an Incident record in ServiceNow's default ITSM configuration? *(Select THREE)*
Explanation
Default ServiceNow Incident states include: New, In Progress, On Hold, Resolved, and Closed. "Submitted" is a state used in Service Catalog (sc_request), not incidents. "Archived" is not a standard incident state (though records can be archived by the system after aging). Administrators can customize state values using the choice list.
Question 2
In ServiceNow Change Management, the three mandatory stages that a Normal Change must pass through are: [[blank1]], [[blank2]], and [[blank3]].
Explanation
Normal Changes in ServiceNow follow a structured lifecycle. After submission, the change goes through: (1) Assessment/Review — risk, impact, and planning evaluation; (2) Approval — reviewed and approved by the CAB; and (3) Implementation — the actual change is made during the approved change window. A Post-Implementation Review (PIR) follows implementation.
Question 3
In ServiceNow Change Management, what is a **Normal Change**?
Explanation
Normal Changes are non-emergency changes that require full review, risk assessment, and approval through the Change Advisory Board (CAB). They follow the complete change lifecycle: request → assessment → approval → implementation → review. Standard Changes (pre-approved) and Emergency Changes (expedited process) are the other two major types in ServiceNow Change Management.
Question 4
In ServiceNow, a [[blank1]] is a record type that extends the Task table and is used to track fulfillment of a catalog item request, including tasks assigned to fulfillment groups.
Explanation
When a user submits a Service Catalog request, ServiceNow creates a Request [sc_request] record and one or more Requested Items [sc_req_item] records (RITMs) beneath it. Each RITM represents one catalog item, and it can have child Task records for multi-step fulfillment. Understanding the Request → RITM → Task hierarchy is fundamental to ServiceNow catalog administration.
Question 5
What is the function of **Work Notes** vs. **Additional Comments** on a ServiceNow incident record?
Explanation
Work Notes are internal journal entries visible only to agents and groups with appropriate access. Additional Comments (also called Customer-Visible Comments) are visible to the requesting user, often generating email notifications to the customer. This distinction is critical for proper communication hygiene—agents must not accidentally put internal diagnostic details in customer-visible comments.
Priority matrix: impact × urgency on incident. P1 = critical business impact.
Don't confuse with change risk — different field set.