Visit here for our full ServiceNow CIS-ITSM exam dumps and practice test questions.
Question 1: In the baseline installation of ServiceNow ITSM, if a parent Incident is closed and marked as ‘Resolved’, what is the default behavior for any child Incidents related to that parent?
A) They remain open until manually closed.
B) They are automatically resolved with the same resolution as the parent.
C) They are automatically cancelled.
D) They are reassigned to the parent’s assignment group.
Answer: A) They remain open until manually closed.
Explanation: In ServiceNow’s Incident Management application, incidents can be linked in a parent-child relationship, allowing a single overarching incident to track multiple related issues. By default, when a parent incident is resolved or closed, the child incidents are not automatically closed. This behavior exists to ensure that each incident is addressed individually, preserving the integrity of incident tracking and reporting. Automatically closing child incidents could result in unresolved issues being marked as complete, which can compromise service quality, reporting accuracy, and SLA compliance.
Organizations that require automation for closing child incidents can configure custom business rules or workflows to propagate the parent’s closure status to child incidents. However, implementing such automation requires careful consideration, as it could conflict with the need for proper resolution, verification, or communication with end users. Baseline behavior—manual closure of child incidents—is considered best practice because it ensures that each incident receives the necessary attention and verification before resolution. It also allows incident managers to prioritize, assign, and document resolutions accurately, supporting clear audit trails and process compliance. Overall, ServiceNow’s default approach encourages thorough problem resolution while giving flexibility for organizations to tailor automation based on their operational needs.
Question 2: Which table holds the records for the “Known Error” stage in the Problem Management application?
A) problem
B) problem_task
C) known_error
D) problem_known_error
Answer: C) known_error
Explanation: In ServiceNow, the Known Error table, named known_error, is a dedicated table designed to manage issues where the root cause has been identified but a permanent solution may not yet be available. Known errors typically arise during the Problem Management process when an underlying issue is understood, and a temporary workaround can be provided to reduce impact on users. By maintaining a separate table for known errors, organizations can clearly distinguish between active problems still under investigation and issues with known causes that can be mitigated using workarounds.
Each Known Error record is linked to a Problem record through a reference field, ensuring traceability between the problem investigation and its corresponding known error. This relationship allows IT teams to track which problems have been analyzed, which have workarounds in place, and which are awaiting a permanent resolution. Storing known errors separately also facilitates reporting, trend analysis, and the creation of knowledge articles that can be shared with support teams or end users.
Following this best practice ensures that Problem Management processes are structured, auditable, and aligned with ITIL guidelines. It helps reduce incident volume by providing support staff with actionable workarounds while maintaining focus on resolving the root cause. By managing known errors distinctly, organizations improve service quality, minimize downtime, and ensure that temporary solutions are properly documented and leveraged effectively.
Question 3: During a normal Change in ServiceNow, which of the following is not a default state in the Change Request lifecycle?
A) Assess
B) Authorise
C) Scheduled
D) Post‑Implementation Review
Answer: D) Post‑Implementation Review
Explanation:
The project management lifecycle typically involves several key stages — Assess, Authorise, Schedule, and Post-Implementation Review — each playing a vital role in ensuring the success, accountability, and sustainability of any project or system implementation. The Assess phase is the foundation of the process, where the project’s need, feasibility, and potential benefits are critically evaluated. During this stage, data is gathered to analyze the current situation, identify problems or opportunities, and determine whether the proposed solution aligns with organizational goals. It involves risk assessment, cost-benefit analysis, and stakeholder consultation to ensure that the project is both viable and valuable. Once the assessment provides enough evidence to justify moving forward, the next step is Authorise, where formal approval is granted by the management or governing body.
This stage ensures that the project has a clear mandate, allocated resources, and defined responsibilities. Authorisation confirms that decision-makers are aware of the project’s scope, budget, risks, and expected outcomes before giving the official go-ahead. After authorisation, the project enters the Scheduled phase, where a detailed plan is created, outlining timelines, milestones, and resource allocation. This phase focuses on organizing activities, sequencing tasks, and ensuring that all necessary resources — such as personnel, technology, and finances — are available at the right time. Scheduling also includes establishing performance metrics and monitoring systems to track progress and manage deviations from the plan. Once the project is executed and completed, it proceeds to the Post-Implementation Review, which serves as a final evaluation of the entire process.
This review measures the project’s success against the original objectives defined in the assessment stage and verifies whether the approved resources were effectively utilized. It examines system performance, user satisfaction, and return on investment, while also identifying lessons learned and areas for improvement. The Post-Implementation Review ensures accountability, captures best practices, and supports continuous improvement for future projects. Together, these four stages — Assess, Authorise, Schedule, and Post-Implementation Review — create a structured and transparent framework that guides projects from conception to completion, ensuring that organizational goals are met efficiently, resources are used responsibly, and long-term value is achieved.
Question 4: Which of the following roles is required for a user to publish Knowledge articles to a public knowledge base in ServiceNow?
- A) knowledge_user
B) kb_writer
C) knowledge_manager
D) kb_admin
Answer: C) knowledge_manager
Explanation: In a knowledge management system, the roles of Knowledge_User, KB_Writer, Knowledge_Manager, and KB_Admin are essential for creating, maintaining, and utilizing organizational knowledge effectively. The Knowledge_User is the primary consumer of information within the knowledge base (KB). This role involves accessing, searching, and applying knowledge articles to resolve issues, improve decision-making, and enhance productivity. Knowledge users depend on the accuracy, relevance, and clarity of content, and they often provide feedback to help improve the knowledge base. Their interaction with the KB ensures that the system remains dynamic and user-centered, as their experiences highlight gaps or outdated information. The KB_Writer, on the other hand, is responsible for creating, editing, and updating knowledge articles. This role requires strong communication skills, subject matter expertise, and an understanding of organizational processes. KB Writers ensure that information is accurate, standardized, and easy to understand, often following predefined templates or guidelines.
They play a crucial role in translating technical or complex information into accessible knowledge resources for end users. The Knowledge_Manager oversees the entire knowledge management process, ensuring that content creation, review, and distribution align with organizational goals and best practices. This role involves establishing policies for content governance, quality assurance, and lifecycle management. Knowledge Managers also monitor performance metrics such as article usage, feedback ratings, and resolution times to assess the effectiveness of the knowledge base. They work closely with writers, users, and administrators to ensure that knowledge flows efficiently across departments, minimizing duplication and maintaining consistency. Finally, the KB_Admin (Knowledge Base Administrator) is responsible for the technical configuration, security, and overall maintenance of the knowledge management platform.
This includes managing user roles and permissions, controlling access levels, ensuring data integrity, and performing system updates or integrations with other tools like CRM or ITSM platforms. KB Admins also handle the backend structure, taxonomy, and metadata that help organize information logically for quick retrieval. While the Knowledge_User represents the demand side of the knowledge ecosystem, the KB_Writer, Knowledge_Manager, and KB_Admin collectively represent the supply and governance sides. Together, they form a continuous cycle: users consume and provide feedback; writers update and improve content; managers oversee quality and relevance; and admins maintain the technical backbone that supports it all. Each role contributes to the effectiveness of knowledge management by ensuring that accurate, useful, and timely information is always available. When these roles function in harmony, organizations can foster a culture of continuous learning, collaboration, and innovation, ultimately improving efficiency and customer satisfaction. Therefore, the integration of Knowledge_User, KB_Writer, Knowledge_Manager, and KB_Admin roles is fundamental to the success of any knowledge management system, ensuring that organizational knowledge is properly created, curated, and utilized for maximum value.
Question 5: In the Service Catalog / Request Fulfilment domain, what is the recommended way to capture user‑specific inputs before creating a request item (RITM)?
- A) Use a Catalog Task script to prompt the user.
- B) Use a Record Producer to collect user inputs, then generate a Request Item.
- C) Directly create variables on the RITM form.
- D) Use UI Action on the Order form for user input.
Answer: B) Use a Record Producer to collect user inputs, then generate a Request Item.
Explanation: In the context of ServiceNow and IT Service Management (ITSM) processes, the options A) Use a Catalog Task script to prompt the user, B) Use a Record Producer to collect user inputs, then generate a Request Item, C) Directly create variables on the RITM form, and D) Use UI Action on the Order form for user input represent different methods of collecting and managing user input during service request creation and fulfillment. Option A, “Use a Catalog Task script to prompt the user,” involves writing scripts within catalog tasks to dynamically interact with users during the fulfillment process. This approach is used when additional information is needed after the initial request has been submitted. For instance, a catalog task script can generate notifications or forms prompting users for missing details.
However, this method is less efficient for structured data collection since it occurs after the initial submission and may delay fulfillment. Option B, “Use a Record Producer to collect user inputs, then generate a Request Item,” is one of the most efficient and standardized methods in ServiceNow. A Record Producer is a type of catalog item used to create task-based records, such as incident or change requests, from the Service Catalog. It allows the system administrator to design a user-friendly form that captures specific data from the requester and automatically creates a corresponding Request Item (RITM) record. Record Producers use variables to capture input, and scripts can map those variables to fields in the generated record. This method simplifies the user experience, enforces data consistency, and supports automation within workflows. Option C, “Directly create variables on the RITM form,” refers to adding variables directly on the Request Item form to collect information during or after the request process. While this approach can be useful for simple setups or quick configurations, it lacks scalability and flexibility.
Directly adding variables to the RITM form may lead to cluttered interfaces and inconsistent data structures, especially when multiple catalog items require similar inputs. It’s also less user-friendly since end users typically interact with catalog items rather than RITM forms directly. Option D, “Use UI Action on the Order form for user input,” involves creating custom UI Actions (like buttons or links) on the order form that trigger specific scripts or dialogs for user input. This approach is highly customizable and is often used for complex or conditional workflows where user confirmation or additional data is required before proceeding. However, it requires more scripting expertise and administrative oversight to maintain. Among these four methods, using a Record Producer (Option B) is generally considered the best practice for collecting user inputs in a structured, maintainable, and scalable way within ServiceNow. It provides a clear, guided experience for users while ensuring that the system automatically generates the appropriate Request Items with accurate data. Together, these options illustrate the flexibility of ServiceNow’s catalog and form design capabilities, allowing developers and administrators to choose the most effective method based on user experience, process complexity, and data management requirements.
Question 6: Which of the following is a best practice for implementing the Configuration Management Database (CMDB) so that it supports Incident and Change processes effectively?
A) Populate all CI records manually by copying spreadsheets.
B) Use inbound integrations and discovery to feed accurate CI data, and implement reconciliation rules.
C) Allow all users to freely create new CI records from incidents.
D) Only track CIs that have had incidents historically.
Answer: B) Use inbound integrations and discovery to feed accurate CI data, and implement reconciliation rules.
Explanation: In the management of Configuration Items (CIs) within a Configuration Management Database (CMDB), the options A) Populate all CI records manually by copying spreadsheets, B) Use inbound integrations and discovery to feed accurate CI data, and implement reconciliation rules, C) Allow all users to freely create new CI records from incidents, and D) Only track CIs that have had incidents historically represent different approaches to building and maintaining CI data integrity. Option A, which suggests manually populating all CI records by copying spreadsheets, is a traditional and labor-intensive approach. While it can be useful during initial CMDB setup or for small organizations with limited IT infrastructure, it is prone to human errors, duplication, and data inconsistencies. Manual population lacks automation, making it difficult to maintain up-to-date records as IT environments evolve.
This method often leads to data becoming outdated quickly, resulting in unreliable CMDB information that can hinder decision-making and service management processes. Option B, which recommends using inbound integrations and discovery to feed accurate CI data and implementing reconciliation rules, is widely regarded as the best practice for CMDB management. Inbound integrations connect the CMDB with external systems such as asset management tools, cloud platforms, or monitoring systems to automatically import configuration data. Discovery tools like ServiceNow Discovery or third-party solutions actively scan the network to identify devices, applications, and relationships between them. Together, these automated processes ensure that CI records are accurate, current, and reflective of the actual IT environment. Reconciliation rules play a crucial role by preventing data duplication and ensuring that updates from various sources merge correctly, maintaining the CMDB’s integrity.
This approach enables organizations to achieve a “single source of truth” for IT assets, improves service impact analysis, and supports efficient change management. Option C, allowing all users to freely create new CI records from incidents, may seem flexible, but it introduces significant risks. Without proper governance or approval controls, this approach leads to uncontrolled CI creation, inconsistent data, and an inflated CMDB filled with inaccurate or redundant records. Such unregulated practices compromise the CMDB’s reliability and increase administrative overhead, as administrators must later clean and validate the data. Effective CMDB management requires role-based access controls to ensure only authorized personnel, such as configuration managers or automation systems, can create or modify CI records. Option D, which proposes tracking only CIs that have had incidents historically, offers a limited and reactive approach. While it may reduce data volume, it undermines the purpose of the CMDB by excluding critical components that have not yet experienced incidents but are still essential to the infrastructure.
This approach restricts proactive management, impact analysis, and change planning. A well-managed CMDB should include all relevant configuration items that support business services, regardless of whether they have encountered issues. Among these four options, Option B—using inbound integrations, discovery, and reconciliation—is the most effective and sustainable strategy. It automates data collection, ensures accuracy, and maintains consistency, enabling organizations to manage their IT ecosystem proactively, minimize risks, and make data-driven decisions that enhance overall service delivery and operational efficiency.
Question 7: In ServiceNow Incident Management, which table holds the Incident records, and what role is required to update incident fields via API if you want to limit access?
A) Table: task_incident; Role required: itil
B) Table: incident; Role required: itil_user
C) Table: incident; Role required: ITIL
D) Table: task; Role required: itil_admin
Answer: C) Table: incident; Role required: ITIL
Explanation: In the ServiceNow platform, which is widely used for IT Service Management (ITSM), the understanding of tables and roles is crucial to ensure proper access control, data organization, and workflow functionality. The options A) Table: task_incident; Role required: itil, B) Table: incident; Role required: itil_user, C) Table: incident; Role required: ITIL, and D) Table: task; Role required: itil_admin represent different combinations of database tables and user permissions that define how incidents and tasks are managed within the system. Option A, Table: task_incident; Role required: itil, refers to a sub-table structure where “task_incident” extends from the base “task” table, but is not the correct or standard table name in ServiceNow. The proper table used for incident management is simply “incident,” which itself extends from the “task” table. However, the role ITIL is the standard ServiceNow role assigned to IT service management professionals, such as support agents and technicians.
Users with the ITIL role can view, create, update, and resolve incidents, as well as access problem, change, and request records depending on configuration. Option B, Table: incident; Role required: itil_user, describes a scenario that seems logical in name but does not align with standard ServiceNow role naming conventions. While some organizations may create a custom role named itil_user to provide limited access to ITSM functionalities, it is not a default role. Typically, such a role would grant read-only or restricted access to the incident table, allowing users to view incidents but not modify or close them. This approach can be used to provide visibility without full edit permissions, supporting segregation of duties. Option C, Table: incident; Role required: ITIL, represents the correct and standard configuration in most ServiceNow instances, though the role name is case-sensitive—itil (all lowercase) is the valid default system role. The incident table is a core table that inherits from the task table, meaning it includes all task-related fields (such as assignment group, state, priority, and description) along with additional fields specific to incidents (like caller, category, and impact). The ITIL role is required to perform typical ITSM actions such as logging, updating, and resolving incidents, making this option the most accurate representation of standard ServiceNow practice.
Option D, Table: task; Role required: itil_admin, refers to the base task table that underlies several key tables like incident, problem, change, and request. The itil_admin role is a higher-level role that grants administrative privileges beyond the standard itil role. Users with itil_admin can modify configurations, manage records across all task-based tables, and often have access to system properties or workflows. This role is generally reserved for senior administrators or platform owners who manage system configuration and data integrity. Among these options, Option C (Table: incident; Role required: itil) is the correct and most widely accepted configuration in ServiceNow. It reflects the platform’s design principle, where incident is the main operational table for incident management, and ITIL is the fundamental role enabling IT service agents to perform their daily functions. Understanding this relationship between tables and roles ensures proper access control, supports compliance, and maintains system integrity across the ServiceNow environment.
Question 8: A customer has a requirement to duplicate an existing Change Request behavior so that when copying a change request, the “Work Notes” list on the original is also copied. According to best practice in ServiceNow, how should this be implemented?
A) Modify the Copy Change UI Action to include the Work Notes field.
B) Add the Work Notes field to the “List of attributes (comma‑separated) that will be copied from the originating change” system property.
C) Override the dictionary attribute of the Work Notes field to “Include in Record Copy = true”.
D) Create a Business Rule on the change_request table to copy Work Notes manually.
Answer: B) Add the Work Notes field to the “List of attributes (comma‑separated) that will be copied from the originating change” system property.
Explanation: In ServiceNow change management, when creating a copy of an existing change request, it is often necessary to determine which fields should be duplicated in the new record. The options A) Modify the Copy Change UI Action to include the Work Notes field, B) Add the Work Notes field to the “List of attributes (comma-separated) that will be copied from the originating change” system property, C) Override the dictionary attribute of the Work Notes field to “Include in Record Copy = true”, and D) Create a Business Rule on the change_request table to copy Work Notes manually represent different approaches to achieving this functionality. Option A, Modify the Copy Change UI Action to include the Work Notes field, involves directly editing the “Copy Change” UI Action script. The Copy Change function uses a UI Action to create a new change record by duplicating selected fields from the original. By customizing this script, administrators can add logic to include additional fields such as Work Notes.
However, this method is not recommended as a best practice because modifying out-of-the-box (OOB) UI Actions can complicate future upgrades, create maintenance issues, and increase the risk of breaking core functionality. Customizing OOB features should always be avoided unless no alternative solution exists. Option B, Add the Work Notes field to the “List of attributes (comma-separated) that will be copied from the originating change” system property, is the correct and most maintainable approach. ServiceNow provides a system property, usually named something like glide.ui.copy.change.attributes, that defines which fields are automatically copied when a user selects “Copy Change.” Administrators can add or remove field names in this property, and when the copy action runs, only those listed attributes are duplicated to the new record. By adding work_notes to this property, the system will automatically include the Work Notes field in the duplication process without modifying scripts or core logic. This approach is upgrade-safe, easy to maintain, and aligns with ServiceNow best practices. Option C, Override the dictionary attribute of the Work Notes field to “Include in Record Copy = true”, attempts to manipulate field-level dictionary attributes. The “Include in Record Copy” setting, when enabled, allows a field’s data to be included when a record is duplicated.
However, Work Notes in ServiceNow are not a simple field but a journal field, which stores data in a related table (sys_journal_field). This means enabling “Include in Record Copy” will not copy historical journal entries, as the data resides in a separate table. Therefore, this approach does not effectively duplicate Work Notes between change records. Option D, Create a Business Rule on the change_request table to copy Work Notes manually, involves writing a script that runs after a record is inserted to query the sys_journal_field table for Work Notes associated with the original change and manually insert them into the new one. While technically possible, this method is complex, requires custom scripting, and introduces performance overhead. It also risks violating audit and compliance rules since Work Notes are intended to be historical records rather than cloned data. Among these four options, Option B is the most effective and recommended solution because it leverages existing platform configuration, maintains system integrity, and minimizes maintenance complexity. By simply updating the system property, administrators can ensure Work Notes—or any other permitted field—are copied consistently during the “Copy Change” action, ensuring both efficiency and compliance with ServiceNow best practices.
Question 9: For the Known Error record in ServiceNow, which of the following fields can be used to route Incidents related to a particular CI to the correct support group?
A) Assignment_Group field on the CI record
B) Support_Group field on the CI class
C) Managed_By field on the CI record
D) Support_Group field on the Incident table
Answer: C) Managed_By field on the CI record
Explanation: In ServiceNow CMDB best practice, the Managed_By field on the CI record can be used to determine who manages that CI and thus route related Incidents appropriately. While Assignment_Group or Support_Group may also be used in some designs, the Managed_By field is the default baseline field that may be leveraged for routing logic. This supports linking configuration items to responsible teams.
Question 10: Which of the following statements about Knowledge article versioning is true in ServiceNow?
A) Every time an article is viewed, a new version is created.
B) Only when an article is edited and published does a new version record appear.
C) Versioning is not supported in baseline; you must implement custom version logic.
D) Version numbers are reset when the article is moved to another knowledge base.
Answer: B) Only when an article is edited and published does a new version record appear.
Explanation: In ServiceNow’s Knowledge Management module, version control plays a crucial role in maintaining the accuracy, consistency, and integrity of knowledge articles over time. The options A) Every time an article is viewed, a new version is created, B) Only when an article is edited and published does a new version record appear, C) Versioning is not supported in baseline; you must implement custom version logic, and D) Version numbers are reset when the article is moved to another knowledge base describe different possible interpretations of how versioning functions, but only one accurately reflects the platform’s baseline behavior. Option A, Every time an article is viewed, a new version is created, is incorrect because viewing an article in ServiceNow does not alter its data or create a new record. The system simply tracks view counts or feedback ratings, but does not generate new versions during access.
Version creation is an administrative or authoring action, not a user interaction, ensuring that content remains stable and unchanged during normal usage. If a new version were created upon every view, it would cause unnecessary duplication, data overload, and confusion in managing article histories. Option B: Only when an article is edited and published does a new version record appear, accurately describing the baseline versioning behavior in ServiceNow. When a knowledge article is edited and then republished (after approval, if workflows are in place), the system automatically creates a new version record. Each version maintains its own version number (e.g., 1.0, 2.0, 3.0) while retaining links to the same article ID, allowing users to track the evolution of content over time. The new version overwrites the previous one as the “published” version, but older versions remain accessible for auditing or rollback purposes, depending on configuration. This process ensures that changes to critical information—such as troubleshooting steps, policies, or procedures—are properly tracked, approved, and documented, maintaining accuracy and compliance.
Option C: Versioning is not supported in baseline; you must implement custom version logic, which is incorrect because version control is a built-in feature of the ServiceNow Knowledge Management application. Out-of-the-box, the platform supports version tracking, draft creation, approvals, and publishing workflows without requiring customization. While organizations can enhance versioning with additional logic, such as automatic archiving or conditional publishing rules, the baseline system already includes robust version management. Option D: Version numbers are reset when the article is moved to another knowledge base, which is also inaccurate. Moving an article to another knowledge base—while possible for reclassification or ownership changes—does not reset its version history. The article retains its version number and metadata, ensuring that version tracking remains consistent across knowledge bases. Resetting versions upon transfer would undermine content integrity and disrupt audit trails.
Among these options, Option B is the correct and most accurate explanation of how ServiceNow handles knowledge article versioning. This approach aligns with best practices in knowledge management by ensuring that new versions are created only when actual content updates occur, preserving historical versions for reference and governance. Versioning upon edit and publish supports content lifecycle management, enabling authors to continuously refine knowledge while maintaining control over what end users see. In summary, ServiceNow’s knowledge versioning mechanism ensures stability, accountability, and traceability by automatically creating new versions only after edits and publication, making it a reliable and compliant method for managing evolving organizational knowledge.
Question 11: A Service Catalog item has variables “Department” (choice list), “Role” (choice list), and “Approver” (reference field). The customer wants the “Approver” to be pre‑populated based on the combination of Department and Role. What is the best ServiceNow approach?
A) Use a Catalog Client Script to change of Department and Role to query and set the Approver variable.
B) Create a Business Rule on the variables table to pre‐populate Approver.
C) Use a Catalog UI Policy to set the Approver variable default.
D) Hard‑code the Approver in the Catalog Item default value.
Answer: A) Use a Catalog Client Script on the change of Department and Role to query and set the Approver variable.
Explanation: The most maintainable and upgradable approach is to use a Catalog Client Script triggered when either of the selection variables changes. The script can query a configuration table (for example, a custom lookup table mapping Department+Role → Approver) and then set the value of the Approver variable dynamically. Using UI Policy alone does not support lookup logic; business rules on the variables table are discouraged because variables are not direct records, and hard‑coding is inflexible and non‑scalable.
Question 12: In Change Management within ServiceNow, risk and impact calculation can be automated using the “Change Risk and Change Impact” plugins. Which two are correct regarding how risk conditions function?
A) Risk conditions allow the system to set the highest risk value when conditions are matched.
B) Risk conditions must be evaluated manually by the change approver.
C) Impact conditions work in a similar condition‑matching approach to risk conditions.
D) Risk conditions can override the default risk value regardless of other criteria.
E) Risk conditions only apply to Emergency Changes.
Answer: A) Risk conditions allow the system to set the highest risk value when conditions are matched.
C) Impact conditions work in a similar condition‑matching approach to risk conditions.
Explanation: The Change Risk / Impact Assessment functionality in ServiceNow provides configurable condition (rule) sets that evaluate change request fields and assign a risk and/or impact score accordingly. When multiple conditions apply, the system takes the highest (worst) value by default. Impact assessment uses a parallel set of conditions. Manual evaluation is optional but not required. The conditions apply to all change types (not only emergency). Best practice is to configure these conditions rather than manually risk assignment to drive consistency.
Question 13: What is the effect of setting the dictionary attribute “Extensible = true” on a table in ServiceNow?
A) It allows the table to be extended in future releases with no upgrade issues.
B) It allows other tables to extend from this table.
C) It allows inbound web services on the table.
D) It enables the table to have change tracking.
Answer: B) It allows other tables to extend from this table.
Explanation: The Extensible dictionary attribute (when set to true) indicates that the table is a base table from which other tables may derive (extend). It is used in ServiceNow to create hierarchies and reuse columns/processes in subclasses. It does not govern inbound web services, change tracking, or inherently future-release issues (though good design supports future upgrades). Understanding table architecture is critical in implementing Applications and ensuring upgradability.
Question 14: During the implementation of CMDB, you discover that multiple automated feeds import duplicate CI records for the same physical server. Which of the following best practice solutions should you apply?
A) Allow the duplicates, and periodically delete the older ones manually.
B) Use an Identification Rule to merge duplicates based on Serial Number.
C) Disable one of the feeds.
D) Create a Business Rule to delete duplicates on insert.
Answer: B) Use an Identification Rule to merge duplicates based on Serial Number.
Explanation: Best practice for CMDB is to use Identification Rules (and Reconciliation Rules) to ensure uniqueness and avoid duplicate records. These can be set up based on key identifiers such as Serial Number, Asset Tag, or Unique ID for a device. Manual deletion or disabling feeds may circumvent the problem temporarily, but do not resolve the architecture. Business Rules for deletion are custom and can complicate upgrades. Using built‑in reconciliation features maintains data quality and scale.
Question 15: In the baseline ServiceNow Incident application, which of the following fields must be fulfilled before a record moves from the New state to the Work In Progress state?
A) Assignment Group
B) Assigned To
C) Category
D) All of the above
Answer: A) Assignment Group
Explanation: In the baseline Incident workflow, when an Incident is created in the New state, moving it to Work In Progress typically requires that the Assignment Group be set. The Assigned To may optionally be filled depending on business rules, but the essential baseline requirement is the Assignment Group. The category is often optional (depending on configuration) and may be filled later. Review documentation and your instance configuration to validate.
Question 16: When implementing the Service Catalog, why is it recommended to use Service Offerings linked to Business Services rather than simply showing all catalog items under a “Technology” category?
A) Service Offerings enforce SLA metrics automatically.
B) Service Offerings align catalog items to business‑defined services, improving visibility and cost allocation.
C) Technology category items cannot be tracked in CMDB.
D) Service Offerings prevent users from ordering items outside their department.
Answer: B) Service Offerings align catalog items to business‑defined services, improving visibility and cost allocation.
Explanation: ServiceNow best practice suggests organizing requestable items under Service Offerings that reflect what the business consumes – not just technology categories. This helps IT quantify cost, service levels, business impact, and consumption of services. It also supports reporting, charge‑back, and ensures the catalog design maps to business value rather than purely technical constructs. While SLA enforcement and departmental limitations may be benefits, the primary reason is aligning with business services.
Question 17: In Problem Management, a workaround has been identified and applied, but the root cause has not yet been found. According to baseline states in ServiceNow, what is the correct state to set for the Problem?
A) New
B) In Progress
C) Known Error
D) Resolved
Answer: C) Known Error
Explanation: When a workaround is available but a permanent fix (root cause and change) is not yet implemented, the Problem should be moved to the Known Error state. This indicates that the problem has been identified sufficiently to apply a workaround, and the issue is recorded in the Known Error table. Once the root cause is addressed and the fix applied, the Problem can then be resolved and closed. This aligns with the best practice lifecycle in Problem Management.
Question 18: A customer wants to measure the success of their Incident Management process in ServiceNow. Which two KPIs would be most appropriate? (Select two)
A) Mean time to resolve Incident.
B) Number of knowledge articles created.
C) Percentage of Incidents reopened within 30 days.
D) Number of Change Requests implemented.
Answer: A) Mean time to resolve Incident.
C) Percentage of Incidents reopened within 30 days.
Explanation: For Incident Management specifically, relevant KPIs include mean time to resolve (MTTR) and quality indicators such as % of incidents reopened (which may suggest inadequate resolution). While the number of knowledge articles may relate to Knowledge Management, and the number of Change Requests implementation relates to Change Management, they are less direct for measuring Incident process success. Good implementation practice includes identifying a small set of meaningful metrics tied to business value.
Question 19: In ServiceNow, the “Assignment” field on a CI record is visible to certain roles. If you want to ensure that only users in the “Asset Manager” role can modify the Assignment field for CIs classified as “Servers”, what is the recommended solution?
A) Set field-level ACL on the Assignment field for the CI table specifying the Asset Manager role and a condition on CI class = Server.
B) Hide the field via UI Policy unless the user has the Asset Manager role.
C) Use a Business Rule to prevent update if role is not Asset Manager and CI class = Server.
D) Extend the CI table for Servers and remove the Assignment field from the extension.
Answer: A) Set field‑level ACL on the Assignment field for the CI table specifying the Asset Manager role and a condition on CI class = Server.
Explanation: The recommended and standard way in ServiceNow to restrict who can update a given field under specific conditions is to use Access Control (ACL) rules at the field level. You can define an ACL on the Assignment field with the condition “CI class = Server” and grant only the asset_manager role. UI Policies and Business Rules are less secure (they enforce on UI rather than backend), and removing the field via table extension is not maintainable or flexible.
Question 20: Which of the following is a correct description of how the Knowledge Use table works in ServiceNow?
A) It logs each time an article is published.
B) It logs each time a user views or uses a knowledge article.
C) It logs each time an article is edited.
D) It logs each time a user downvotes an article.
Answer: B) It logs each time a user views or uses a knowledge article.
Explanation: The kb_use (Knowledge Use) table in ServiceNow records usage data for knowledge articles — it captures when articles are viewed or attached to tasks/incidents and by whom. This data helps measure article effectiveness (e.g., number of uses, ratings, etc.). It does not log publishing events, edits, or vote actions (those are tracked in different tables). Knowing the architecture of the Knowledge application is part of the exam blueprint.
