Question Q-8630 An ITSM implementation team is conducting User Acceptance Testing (UAT)…
3 comments · last active May 28, 2026
ServiceNow CIS-ITSM - IT Service Management Implementation - Incident Problem Change CMDB SLA Catalog
By Marcus Chen · Updated May 25, 2026
| Questions | 25 |
| Passing Score | 75% |
| Format | 100% Multiple Choice |
| Sessions Logged | 823 |
| Your progress | Log in / Register to track times taken, best score, questions mastered, and coverage on this quiz. |
| Rating |
Topics covered
Uncategorized25 questions
Discussion
Log in to post a comment, reply, or expand a question.
50k CIs = Import Set → Transform Map → cmdb_ci_* tables → IRE for dedupe. Discovery discovers live env; it won't ingest your legacy CSV history.
+2 votesIRE matching on serial/hostname/IP saved us on a migration. Know identification vs reconciliation rules.
Manual entry (opt A) at 50k records is a joke answer — exam uses it to test if you're paying attention.
500 incidents/day from one app — Intelligent Triage / ML clustering + Problem record is the right pattern. Don't mass-close as duplicates unless they're true dupes.
We used Problem linking without ML and it still worked — but exam wants the Similar Incidents / triage answer when it's offered.
Four SLA definitions: P1 response, P1 resolve, P2 response, P2 resolve — each with priority condition + business hours schedule. One mega-SLA with condition fields sounds nice but isn't the exam answer.
Schedule record Mon-Fri 8-6 then attach to each Task SLA. Pause on On Hold is standard.
Retire categories by marking sys_choice Inactive — historical incidents keep old value, dropdown stops showing it. Never delete choices in prod.
Mass update historical (opt C) breaks reporting integrity. Learned that in a CAB postmortem.
Known Error = Problem state + workaround on record + KB article. Exam answer is D (both A and B) — don't pick only one if both are listed.
Service desk finds workaround faster when KB is linked — agents search Global Search during incident.
Catalog approval over $1000 — conditional branch in the fulfillment flow/Flow Designer: if cost > 1000 → approval, else skip to fulfillment. Keeps one catalog item.
Two separate catalog items (opt A) works operationally but exam wants dynamic workflow condition on one item.
Change Collision Detection is native — flags same CI / maintenance window conflicts. Custom BR (opt C) duplicates platform capability.
CAB manually reviewing CMDB (opt D) doesn't scale — that's why collision detection exists.
Multi-region on ONE instance: regional groups, schedules, assignment rules, SLA conditions — not five instances unless legal/data residency forces it.
Domain Separation (opt D) is multi-tenant partitioning — different use case than APAC vs EMEA hours.
Major Incident Management isn't just emailing execs — you get the workbench, comms plan, stakeholder groups. Business rule alone (opt A) is a trap.
+2 votesCorrect — P1 SLA breach tells you you're late; it doesn't coordinate bridge calls and comms the way MIM does.
Standard vs Normal vs Emergency — separate workflows triggered by type/risk. Standard Change Catalog = pre-approved low risk path.
CAB skipping low risk in a meeting (opt B) is terrible governance and not how SN implements it.
Memorize: Standard = auto, Normal = CAB, Emergency = fast track + PIR.
Incident KPIs = MTTR, FCR, reopen rate, SLA %. Change metrics (opt A) and Problem backlog (opt C) are wrong process.
Easy eliminate if you know ITIL process boundaries.
Question catalog for this preview
Catalog listing of the 5 preview questions for this quiz.
Question 1
A company wants to implement a major incident process where P1 incidents automatically notify senior management and create a dedicated communication bridge. Which ServiceNow ITSM features should be configured?
Explanation
ServiceNow's Major Incident Management process (part of ITSM Pro) includes dedicated features: (1) Major Incident criteria that auto-promotes incidents to Major Incident status based on conditions; (2) Automatic creation of a communication plan with predefined stakeholder groups; (3) Major Incident workbench for coordinating response; (4) Automated notification workflows to executives and senior management; (5) Audit trail of all response activities. Simple business rule emails (option A) lack the structured coordination features. SLAs measure timelines but don't coordinate response. Emergency Change Management may be linked but isn't the primary tool for incident response coordination.
Question 2
A ServiceNow ITSM implementation needs to support a "Virtual Agent" chatbot that can help users create incidents and check the status of their requests. What configuration is required?
Explanation
ServiceNow Virtual Agent is a native platform capability (part of Now Intelligence). Configuration includes: (1) Virtual Agent Designer — create conversation Topics (intents like "Create Incident" or "Check Request Status") using NLU (Natural Language Understanding); (2) Conversation flow nodes — capture user information through dialogue; (3) Fulfillment — connect to FlowAPI, GlideRecord, or ServiceNow Spoke actions to create/query records; (4) Integration channels — deploy on Teams, Slack, web, mobile. No third-party development is needed. The Virtual Agent integrates natively with ITSM workflows and provides 24/7 self-service. Third-party chatbots (option A) require significant integration effort.
Question 3
A company is implementing the Service Portal and wants the incident creation form to automatically populate the "Affected User" field with the logged-in user's information. What is the MOST appropriate way to implement this?
Explanation
Setting a Default Value on the `caller_id` (Affected User) field in the Incident table definition is the cleanest approach. In the field's Default Value, you enter `javascript:gs.getUserID()` — this server-side script runs when a new incident record is created and automatically sets the caller to the current user's sys_id. This works across all entry points: the main UI, Service Portal, mobile app, and API calls when session context is available. A Client Script (option C) would only work in the browser UI and would need to handle the g_user object. Default values are the standard platform mechanism for auto-populating fields with user context.
Question 4
A company has implemented Knowledge Management and wants to measure the effectiveness of their knowledge base. The Knowledge Manager asks: "How many incidents were resolved using a knowledge article, and which articles are used most?" How can this be reported in ServiceNow?
Explanation
ServiceNow tracks knowledge usage through relationship records. When an agent links a KB article to an incident (via "Knowledge" related list or the Knowledge Search widget), a many-to-many relationship record is created. The `kb_knowledge_task_mtom` table tracks these links. ServiceNow also tracks article views and ratings in `kb_use` and `kb_feedback` tables. You can create reports showing: (1) Number of incidents per article (most-used articles); (2) Incidents resolved after KB article was linked (deflection rate); (3) Article usefulness ratings. The ServiceNow Knowledge Analytics dashboard provides these metrics natively. Manual work notes analysis (option C) is not scalable or reliable.
Question 5
During an ITSM implementation, the client asks whether ServiceNow supports integration with monitoring tools like Nagios or Dynatrace to automatically create incidents when alerts fire. What is the recommended integration pattern?
Explanation
ServiceNow IT Operations Management (ITOM) Event Management is designed for this integration pattern: (1) Monitoring tools (Nagios, Dynatrace, Zabbix, PagerDuty) send events to ServiceNow via REST, SNMP, or native connectors; (2) Event Management deduplicates and correlates events (preventing alert storms from creating thousands of incidents); (3) Alert rules convert significant events into Alerts; (4) Alert Action policies automatically create, update, or resolve incidents based on alert conditions; (5) CMDB CI lookup adds CI context to incidents. This reduces false-positive incidents, correlates related alerts, and provides CI-enriched context. Email-based integration (option A) lacks structured data and deduplication. Manual creation (option C) introduces lag and human error.
Anyone debate opt B vs C on CMDB baseline? I thought baseline was snapshot for comparison — re-read explanation before my exam.
Read the rationale on this one — CIS-ITSM loves 'most correct' implementation, not 'technically possible'.
Virtual Agent / Flow / CMDB questions stack up — pace yourself on timed runs.