support@Free-Braindumps.com
Register Login
Cisco
CompTIA
ISC
EC-Council
EXIN
Fortinet
ITIL
Juniper
Microsoft
VMware
Avaya
SAP
Google
NVIDIA
Salesforce
Amazon
Palo Alto Networks
ISC2
Splunk
ServiceNow
All Vendors
  1. Home
  2. Exams
  3. ServiceNow
  4. CIS-ITSM

ServiceNow CIS-ITSM Exam Prep
Certified Implementation Specialist - IT Service Management (Page 13 )

Updated On: 30-Aug-2026
Page 6 of 32
PDF with 248 Questions

How are Releases related to Projects?

  1. Project tasks and Release tasks are interchangeable
  2. Projects can be part of one or more releases
  3. Project features are components of a release
  4. Projects need to be completed before releases can be defined
  5. Projects are used to do root cause analysis for releases

Answer(s): B

Explanation:

The most accurate answer is B. Projects can be part of one or more releases. Here's a detailed justification:
Releases in ServiceNow ITSM represent the deployment of changes to IT services. These changes can stem from various sources, including projects. A large project might necessitate multiple releases to deliver its features incrementally or manage risk. Projects frequently bundle multiple changes into a single, coordinated deployment (release).
Option A is incorrect because project tasks and release tasks serve different purposes and have distinct workflows. Project tasks focus on delivering project deliverables, while release tasks focus on deploying changes into the production environment.
Option C isn't entirely accurate because project features could be a component within a release, but release features are not always project driven. For example, a release could include fixes that were not initiated via a project.
Option D is misleading.
While project deliverables might trigger a release, releases can also occur independently of projects for routine maintenance, patches, or urgent fixes. Projects are not prerequisites for releases to be defined or initiated.
Option E is incorrect because root cause analysis is usually associated with incident or problem management, not directly with projects. Root cause analysis may sometimes trigger a project, but projects aren't primarily for root cause analysis.
Therefore, releases are used to deploy the deliverables and features developed during projects, making option B the most accurate choice. One project may have multiple releases and one release may deploy multiple projects.
For further reading, consider exploring these resources:
ServiceNow Official Documentation: Search within the ServiceNow documentation portal for "Release Management" and "Project Management." ITIL 4 Foundation Publications: Consult the ITIL 4 framework for best practices on Release Management.



What baseline Change Flows support the baseline Normal Change model?

  1. Change - Normal - Assess, Change - Normal - Authorize, Change - Normal - Implement Change -Implementation tasks
  2. Change - Normal - New, Change - Normal - Review, Change - Normal - Close, Change - Implementation tasks
  3. Change - Normal - New, Change - Normal - Assess, Change - Normal - Implement, Change - Implementation tasks
  4. Change - Normal - Assess, Change - Normal - Authorize, Change - Normal - Close, Change - Implementation tasks

Answer(s): A

Explanation:

The correct answer is A, outlining the Change Flows that support the baseline Normal Change model in ServiceNow ITSM: Change - Normal - Assess, Change - Normal - Authorize, Change - Normal - Implement, and Change - Implementation tasks. This reflects the standard progression of a Normal Change within the ServiceNow platform.
A Normal Change typically requires a detailed assessment to understand the potential impact, risk, and resources required. This assessment phase is explicitly supported by the "Change - Normal - Assess" workflow. After the assessment, authorization is crucial. This phase ensures that appropriate stakeholders review and approve the change before it is implemented. The "Change - Normal - Authorize" workflow caters to this authorization process, typically involving CAB (Change Advisory Board) approval. Following authorization, the implementation phase brings the change into effect. The "Change - Normal - Implement" workflow guides the execution of the change. Finally, the "Change - Implementation tasks" flow manages the individual tasks involved in the implementation, allowing for granular tracking and control.
Options B, C, and D are incorrect as they either include phases that are not sequentially accurate or miss key phases in the standard Normal Change process. For example, "Change - Normal - Review" and "Change -Normal - Close" are related to change management, but do not directly drive the baseline Normal Change model progression as represented by the default workflows. The New workflow is a starting point, but the core is the Assessment, Authorization and Implementation. The Close workflow is part of the change record lifecycle after it goes into production. Therefore, only option A contains the complete set of baseline Change Flows that actively support the Normal Change model from assessment to implementation.
For deeper understanding, refer to the ServiceNow documentation on Change Management: https://docs.servicenow.com/bundle/vancouver-it-service-management/page/product/change-management/concept/c_ChangeManagement.html and specifically the details on Normal Changes https://docs.servicenow.com/bundle/vancouver-it-service-management/page/product/change-management/concept/change-management-process.html .



Which of the following Change Task Types are available by default? (Choose three.)

  1. Planning
  2. Testing
  3. Review
  4. Deployment
  5. Verification

Answer(s): A,B,C

Explanation:

The correct answer identifying the default Change Task Types in ServiceNow ITSM is A. Planning, B. Testing, and C. Review.
ServiceNow's IT Service Management (ITSM) module provides a structured framework for managing IT services, including change management. Change tasks are granular activities performed as part of a larger change request. The default Change Task Types are pre-configured within the platform to support common stages of a change.
Planning: This task type focuses on defining the scope, resources, schedule, and potential impact of the change. It ensures that the change is well-defined before implementation. Testing: This task type ensures that the change is thoroughly tested in a controlled environment to identify and resolve any issues before deployment. Review: This task type focuses on evaluating the change request, the testing results and the impact of the change and providing feedback.
While Deployment and Verification are important aspects of change management, they are typically implemented as distinct steps in the overall change workflow rather than specific, pre-defined Change Task Types. Deployment would often be a phase triggered after a specific change task. Verification would be similar to the overall outcome of the change request.
While these two are part of the overall process, the out of box offerings for change task types are Planning, Testing and Review.
In summary, the default Change Task Types—Planning, Testing, and Review—provide a basic structure for organizing and executing tasks within a change request in ServiceNow ITSM.
For more information, you can refer to the ServiceNow documentation on Change Management. These documents often include details about Change Task Types and how they fit into the overall Change Management process. Explore the ServiceNow documentation portal for official guides. Specifically, search for "ServiceNow Change Management" and "Change Task Management."



What is the Business Rule that triggers automatic group assignment on Incident, Problem or Change requests?

  1. Populate Assignment Group based on CI/SO
  2. Auto-populate ITSM Assignment Groups
  3. ITSM Assignment Lookup Rule
  4. Automatic Assignment for ITSM

Answer(s): A

Explanation:

The provided answer, "Populate Assignment Group based on CI/SOB," is the most likely correct answer for automatic group assignment in ServiceNow's ITSM module via Business Rules. Let's dissect why:
Option A makes the most logical sense because a common implementation pattern for ITSM involves automatically assigning incidents, problems, or changes to the appropriate group based on the Configuration
Item (CI) and, often, the service offering or business service (SOB) associated with that CI. This is based on the idea that specific teams are responsible for maintaining or supporting particular systems or services. The Business Rule uses information from the CI and SOB fields on the record to determine the correct assignment group.
The logic often embedded within the Business Rule would query a table (custom or OOB) that maps CIs and/or services to assignment groups.
When a new Incident (or Problem or Change) is created, this rule runs, looks at the CI and service, finds the corresponding assignment group in the mapping table, and populates the assignment group field.
Option B, "Auto-populate ITSM Assignment Groups," is too vague.
While it describes the goal, it doesn't specify how it's achieved. Options C and D are more specific. However, "ITSM Assignment Lookup Rule" is likely a specific type of script include or extension of the functionality described in Option A, not the core Business Rule itself. "Automatic Assignment for ITSM" is similarly too general.
Therefore, the correct and detailed answer is "Populate Assignment Group based on CI/SOB" as the most fitting Business Rule to trigger automatic group assignment.
For further research, consider looking at the following:
ServiceNow documentation on Business Rules: https://developer.servicenow.com/devportal/$knowledge_base.do#!/article/KB0538057 ServiceNow documentation on CI relationship and automatic assignment: Search ServiceNow Docs for "Assignment Rules based on CI" or "Service-Aware Assignment"



In the CAB workbench, what are some ways the CAB manager can identify the Change requests to be added to a particular meeting agenda? (Choose two.)

  1. Change requests meeting different conditions, like Risk level or Type
  2. Change requests planned within a certain date range
  3. Use any of the options on the Agenda Criteria Tab
  4. Change requests for a certain Change Flow Definition

Answer(s): A,B

Explanation:

The provided answer, AB, is the most appropriate choice for identifying Change Requests to add to a CAB meeting agenda within the ServiceNow ITSM CAB Workbench.
Option A is correct because CAB managers often need to prioritize Change Requests based on their potential impact and urgency. Filtering by Risk level (e.g., High, Moderate, Low) allows focusing on Changes that pose the greatest threat to service stability. Similarly, filtering by Type (e.g., Standard, Normal, Emergency) helps categorize Changes for focused discussion, as emergency changes often require more scrutiny.
Option B is correct because Change Requests planned within a specific date range are naturally relevant for discussion in a CAB meeting occurring during or shortly before that period. This ensures timely review and approval of Changes that are about to be implemented, providing an opportunity to identify and address any potential conflicts or dependencies. Prioritizing based on the start or end dates allows the CAB to proactively assess and mitigate risks related to upcoming changes.
Option C, "Use any of the options on the Agenda Criteria Tab," while generally true, is too broad and doesn't specify which capabilities are most essential for Change selection. The criteria tab undoubtedly offers options, but A and B are demonstrably relevant.
Option D is incorrect. Change Flow Definition dictates the lifecycle of a Change, defining the stages a Change Request goes through (e.g., submission, approval, implementation, closure).
While knowing the Change Flow is helpful, it isn't a primary criterion for deciding whether a Change Request should be added to a particular CAB meeting agenda. The status of the Change (e.g., in review, scheduled) may be more relevant.
Therefore, filtering based on risk level/type and planned date ranges are direct methods for identifying and prioritizing the most critical Change Requests for CAB review and approval. This ensures the CAB meeting is productive and focused on Changes that require the most attention.
Relevant links for further reading:
ServiceNow CAB Workbench Documentation: (search ServiceNow documentation portal for "CAB Workbench") ITIL 4 Change Enablement: https://www.axelos.com/ (Search for ITIL 4 Change Management documentation)



A change user complains that with the new Preapproved tab, they have to search through many options to find the Reboot Windows Server change. Since they use this change several times per day, it is inconvenient.
What should you suggest to make it easier for the change user?

  1. Use the Pin feature
  2. Make a Favorite
  3. Use the keyword search
  4. Drag the change tile to the Navigation pane

Answer(s): A

Explanation:

The question focuses on optimizing the user experience within the ServiceNow ITSM platform, specifically related to pre-approved change templates. The user wants faster access to a frequently used "Reboot Windows Server" change template within the Preapproved tab.
Option A, using the "Pin" feature, is the most efficient solution. ServiceNow's Pin feature allows users to prioritize and keep frequently used items easily accessible within a section. By pinning the "Reboot Windows Server" change template, it will consistently appear at the top or in a designated area of the Preapproved tab, eliminating the need for scrolling or searching. This direct access saves the user valuable time and effort each time they initiate this specific change.
Option B, creating a "Favorite," while helpful, may not be ideal within the context of the Preapproved tab. Favorites are typically accessed from a separate section in the navigation, requiring an extra click or two compared to the immediate visibility provided by pinning.
Option C, using the keyword search, defeats the purpose of streamlining access.
While search is functional, it still requires typing and cognitive effort, which the user is trying to avoid.
Option D, dragging the change tile to the Navigation pane, is not a standard or configurable feature within ServiceNow's Preapproved Change Management.
Therefore, pinning the change template provides the most direct and efficient solution to the user's problem, ensuring quick and easy access to the frequently used "Reboot Windows Server" change. The Pin feature, being readily available within the user interface and requiring minimal configuration, makes it the superior choice. The other options may have their uses in different contexts, but they don't directly address the need for rapid and consistent access to a specific item within the Preapproved tab.
While official ServiceNow documentation explicitly detailing the "Pin" feature within Preapproved Changes may be limited (as feature implementations can change), the general concept of pinning/favoriting in UI/UX design for quicker access to frequently used items is a standard best practice and aligns with ServiceNow's aim for improved usability.



Roles control which users can perform which actions on a change record.
What are actions, which cannot be performed by anyone, even an administrator? (Choose two.)

  1. Update Change Type on an existing change record
  2. Delete a Change record
  3. Delete a Standard Change Template
  4. Delete CAB Definition

Answer(s): A,C

Explanation:

The correct answer is A and C because certain system-level configurations and historical data manipulations are restricted even to administrators in ServiceNow to maintain data integrity and auditability.

A: Update Change Type on an existing change record: This operation is heavily restricted because changing the Change Type after the record is created can significantly impact the entire change management process. The Change Type dictates the workflow, risk assessment, and approval processes that a change request must follow. Altering it mid-stream would undermine these pre-established processes, potentially leading to inconsistencies, bypassed approvals, and inaccurate reporting. In practical terms, you can't simply switch a "Normal" change to an "Emergency" change after it's been implemented without creating chaos. ServiceNow's design enforces this to uphold the intended governance and control.
C: Delete a Standard Change Template: Standard Change Templates represent pre-approved, low-risk changes with defined workflows and procedures. These templates are critical for standardization and efficiency in change management. Allowing unrestricted deletion of these templates would create a significant risk of process inconsistencies, errors, and the potential for unauthorized changes to be implemented under the guise of a now-deleted standard change. The system protects these critical configurations to maintain the integrity and consistency of the change management process.
While an administrator can deactivate or modify a standard change template, complete deletion is generally prevented to preserve the audit trail and prevent accidental or malicious removal.
Why B and D are not correct:
B: Delete a Change record: While not ideal, administrators, with appropriate roles (e.g., change_manager ,
change_admin ) can delete change records under specific circumstances. The ability might be restricted based on auditing requirements or company policy via script or security constraints. D. Delete CAB Definition: CAB (Change Advisory Board) Definitions can be deleted, typically by administrators who manage the Change Management application. It's a configuration setting, and deleting it may be a necessary administrative task to adjust the change process.
Therefore, actions related to fundamentally altering the type of a change record or removing pre-defined templates that ensure standardized change processes are protected to ensure best practices, security, and auditing standards within ServiceNow.
Supporting Documentation:
ServiceNow Product Documentation: https://docs.servicenow.com/ (Search for "Change Management Roles", "Standard Change Templates", and "Change Process") This is the direct source of truth for ServiceNow's functionality and configuration.
While there is no single page detailing the impossibility of these actions, the design of the platform and the role hierarchy implicitly demonstrate that these actions are not intended to be directly performed through simple administrative privileges. The documentation for change_manager and change_admin role defines the capabilities that these users can do, which is related to closing or cancelling but not deleting or changing change type.



In the baseline Change - Normal model how can Change Tasks be added? (Choose two.)

  1. Automatically via the Change - Implementation subflow
  2. Manually by the user during New, Assess, and Authorized states
  3. Automatically depending on the category selected on the Change Request
  4. Manually by the user during all states, except Closed or Canceled

Answer(s): A,D

Explanation:

The correct answer is AD because Change Tasks in the baseline Change - Normal model can be added both automatically and manually, under specific conditions.
Option A is correct because the Change - Implementation subflow, associated with the Change - Normal model, can be configured to automatically create Change Tasks based on pre-defined conditions or activities within the workflow. This automation streamlines the implementation process by ensuring necessary tasks are created without manual intervention. This relates to the cloud computing concept of automation, reducing manual effort and improving efficiency in service management.
Option D is also correct because users can manually add Change Tasks during most states of the Change Request lifecycle, except when the Change Request is in the Closed or Canceled states. This allows for flexibility in managing the change, addressing unexpected issues, or adding tasks that were not initially planned. This embodies the principle of flexibility and control in cloud-based ITSM systems, enabling users to adapt to changing circumstances. Manual creation can happen directly on the Change Request.
Option B is incorrect because while users can manually add Change Tasks during the New, Assess, and Authorized states, their ability to do so is not limited to these states. They can do it in other active states like Implement.
Option C is incorrect as the category of the Change Request, while used for categorization and routing, doesn't automatically trigger the creation of change tasks directly in the baseline model, unless custom workflows are created for this purpose. The baseline workflow primarily uses the Change - Implementation Subflow (A) for automated Change Task generation.
In summary, the baseline Change - Normal model supports both automated and manual addition of Change Tasks, providing a balance between efficiency and control over the change management process.
References:
ServiceNow Documentation: https://docs.servicenow.com/ (Search for "Change Management" and "Change Task")


Reference:

References:
ServiceNow Documentation: https://docs.servicenow.com/ (Search for "Change Management" and "Change Task")



  PDF
Viewing page 13 of 32
Viewing questions 97 - 104 out of 248 questions


Post your Comments and Discuss ServiceNow CIS-ITSM exam prep with other Community members:

AI Tutor AI Tutor 👋 I’m here to help!

© 2026 Free-Braindumps.com - A Community of Learners.

Free-Braindumps.com is owned by Xùnliàn Limited, a company registered at 15 Wang Chiu Rd, Kowloon Bay, Hong Kong.

The resources, practice tests, and study guides on Free-Braindumps.com are strictly for educational and research purposes. We are an independent community platform and are not affiliated with, endorsed by, or sponsored by any official certification vendors, including Microsoft, Cisco, Amazon, CompTIA, or others. All certification names, trademarks, and logos are the property of their respective owners. Our content is user-contributed or independently developed to assist with exam preparation and skill assessment; we do not host or provide access to proprietary, confidential, or live exam questions.