CQIA Practice Questions

The primary and most significant difference between a Configuration Management Database (CMDB) and an asset register lies in the CMDB's function to store and map the relationships and dependencies between its components, known as Configuration Items (CIs). While an asset register is a list focused on the financial and lifecycle aspects of assets (e.g., cost, owner, purchase date), a CMDB provides a logical model of the IT infrastructure. This relational data is essential for understanding how CIs work together to deliver services, enabling critical processes like impact analysis for changes, root cause analysis for problems, and service restoration.

A. Documentation: Both systems can store or link to relevant documentation for the items they track.

B. Software: Both an asset register (for license and cost tracking) and a CMDB (as a CI) can contain information about software.

C. The IT environment: This is too general; both tools manage components within the IT environment, but from different perspectives (financial vs. operational).

1. AXELOS. (2019). ITIL® Foundation, ITIL 4 Edition. TSO (The Stationery Office).

In Section 5.2.5, "Configuration management," the text explains that a CMDB is a database used to store configuration records throughout their lifecycle, emphasizing that it "also stores information about the relationships between CIs." This is contrasted with IT asset management, which focuses on financial value.

2. ISO/IEC 20000-1:2018, Information technology — Service management — Part 1: Service management system requirements.

Section 8.2.5, "Configuration management," mandates that an organization must identify, control, and record CIs, and specifically "define and maintain the relationships between configuration items." This highlights relationships as a core, standardized requirement of a CMDB.

3. Iden, J., & Langeland, O. (2010). Setting the Stage for a Successful ITIL Adoption. In Proceedings of the 43rd Hawaii International Conference on System Sciences. IEEE.

The paper discusses the implementation of ITIL processes and notes that the CMDB's value is derived from its ability to provide a holistic view of the IT infrastructure, which is achieved by mapping the "interdependencies between the different components" (p. 4). This academic source reinforces that relationships are the key differentiator and value proposition.

Capacity is a critical non-functional requirement that fundamentally influences a system's architecture, infrastructure, and design. According to established systems engineering and quality management principles, all requirements should be identified and analyzed as early as possible in the development lifecycle. Addressing capacity requirements during the initial planning and design phases allows for proper resource allocation, performance modeling, and architectural decisions. Deferring this consideration introduces immense risk, leading to costly rework, project delays, and potential system failure upon deployment when performance loads are applied. A proactive approach is essential for building a robust and scalable system.

A. This reactive "wait-and-see" approach is a recipe for failure, leading to costly emergency fixes and significant user dissatisfaction after implementation.

C. Identifying capacity shortfalls after development is complete necessitates major, expensive architectural changes and invalidates much of the testing already performed.

D. Discovering capacity issues just before go-live leaves no time for remediation, forcing a launch delay or guaranteeing immediate system failure.

1. Russell, J. P. (Ed.). (2020). The ASQ Certified Quality Improvement Associate Handbook (4th ed.). ASQ Quality Press. In Chapter 7, "Quality in Product and Process Design," the text emphasizes the necessity of translating customer needs into design requirements early in the process to prevent later failures. Capacity is a key technical requirement derived from customer needs (e.g., number of users, transaction volume).

2. Sommerville, I. (2011). Software Engineering (9th ed.). Pearson. In Chapter 4, "Requirements Engineering," it is stated that non-functional requirements, which include performance and capacity constraints, must be established during the requirements elicitation and analysis stage. "It is difficult to add non-functional requirements to a system late in the development process" (p. 91).

3. MIT OpenCourseWare. (2005). 6.170 Laboratory in Software Engineering, Fall 2005. Massachusetts Institute of Technology. Lecture Notes, "Lecture 2: The Software Lifecycle," emphasizes that the requirements and specification phase is the first step where both functional and non-functional properties (like performance and capacity) of the system are defined. Postponing these considerations is identified as a primary cause of project failure.

Problem Management's core function is to investigate, diagnose, and resolve the root causes of incidents to prevent their recurrence. This creates a direct and frequent operational relationship with Incident Management (which reports the issues), Change Management (which implements the fixes), and Availability Management (which tracks the impact of problems on service uptime). In contrast, the interface with IT Financial Management is much less frequent. It is typically engaged only when a proposed solution to a problem requires significant, unbudgeted expenditure, making the interaction strategic or project-based rather than a regular, operational one.

B. Change Management: This is incorrect because the resolution of a problem's root cause almost always requires a formal Request for Change (RFC) to implement a permanent fix, making this a very common interface.

C. Incident Management: This is incorrect because Problem Management is fundamentally dependent on Incident Management to provide data and trigger investigations into recurring or major incidents.

D. Availability Management: This is incorrect because eliminating the root causes of incidents is a primary activity for improving service availability, necessitating a close and regular working relationship.

1. University of New Hampshire, Enterprise Technology & Services. (n.d.). ITIL V3 Problem Management. In Service Management. Retrieved from https://www.unh.edu/it/service-management/itil-v3-problem-management.

Reference Detail: The "Relationships with Other Processes" section explicitly states, "Problem Management works closely with Incident Management and Change Management..." It details how incident records are a key input and Requests for Change (RFCs) are a key output, confirming the frequent interface. The document does not list Financial Management as a primary related process.

2. Iden, J., & Langeland, O. (2010). Setting the Stage for a Successful ITIL Adoption. Information Systems Management, 27(2), 103–112. https://doi.org/10.1080/10580531003708378

Reference Detail: Page 106, Table 1, describes the core ITIL processes. It highlights the tight integration between Incident, Problem, and Change Management as foundational for service operation and transition, noting that "Problem Management analyzes incident records to find the underlying causes" and its resolution often "results in a Request for Change."

3. University of Washington, UW-IT. (n.d.). Problem Management. In ITIL Service Management. Retrieved from https://itconnect.uw.edu/work/itil-service-management/problem-management/.

Reference Detail: The process overview and diagrams show direct inputs from Incident Management and direct outputs to Change Management. The process goals are directly aligned with Availability Management ("...minimize the adverse impact of Incidents and Problems on the business..."). The interface with Financial Management is not depicted as a regular part of the operational workflow.

The fundamental purpose of Configuration Management (CM) is to establish and maintain control over a product's attributes throughout its lifecycle. A Configuration Item (CI) is an entity within the system that is designated for separate configuration control. The decision on the lowest level of CI to record is primarily driven by the need to manage changes independently. If a component is expected to be designed, procured, tested, repaired, or replaced as a distinct unit, it must be identified as a CI. This allows for precise tracking and control of its specific version and any modifications, ensuring the integrity of the overall system is maintained when individual parts are altered.

A. The reliability of the CIs: Reliability is an important characteristic of a component, but it does not determine its status as a CI. Both highly reliable and unreliable parts may be designated as CIs if they require independent change control.

C. The suitability of the available software to hold the information: The capabilities of a CM tool are a constraint, not the primary driver for CI selection. Engineering and management requirements should dictate what needs to be controlled, and the tools should be selected to support those needs.

D. The availability of spares for CIs: Spares management is a logistical function. While many CIs are also spare parts, the decision to designate an item as a CI is based on the need for formal change control, not simply its status as a spare.

1. ANSI/EIA-649-B, Configuration Management Standard. (2011). SAE International.

Section 5.2, "Configuration Identification": This section details the process of selecting CIs. It states, "CIs are selected for management visibility and control... Criteria for CI selection include, but are not limited to... [items that] will be separately designed, developed, procured, produced, tested, delivered, installed, operated, maintained, repaired, or retired." This directly supports the principle that the level of independent change, maintenance, and repair dictates CI selection.

2. Tahan, M., & Rausand, M. (2012). Configuration Management: Theory and Application for Engineers, Managers, and Students. John Wiley & Sons.

Chapter 4, "Configuration Identification," Section 4.3, "Selection of Configuration Items": The text explains that a key criterion for selecting a CI is that it is a "replaceable unit." It elaborates that the "level of decomposition depends on the complexity of the product and the level at which parts are expected to be replaced during the operational and support phase." (p. 63). This aligns directly with the chosen answer.

3. Blanchard, B. S. (2004). System Engineering Management (3rd ed.). John Wiley & Sons.

Chapter 11, "Configuration Management": This chapter discusses that CIs are selected based on the need for formal control. It notes that CIs are typically items "subject to replacement" and that the breakdown into CIs should reflect the "logistics support structure," which is based on which components will be independently replaced or repaired. (pp. 268-270).

The primary function of a Service Desk is to act as the single point of contact for users to report service disruptions. This process is known as Incident Management. A key performance indicator (KPI) for the Service Desk is tracking the volume and severity of these disruptions. The number of high-priority incidents is a critical metric used for resource allocation, escalation, and reporting on the immediate health of IT services. It directly measures the immediate workload and impact handled by the Service Desk.

B. The support team which resolves the greatest number of problems: This is a metric for Problem Management, a separate process focused on root cause analysis, not the front-line Service Desk function.

C. The number of problems solved in a day: This metric also relates to Problem Management. The Service Desk's focus is on restoring service (resolving incidents), not necessarily identifying and solving underlying problems.

D. The mean time between failure: This is a reliability metric used in Availability or Capacity Management to measure the uptime of a component or service, not a direct operational metric for the Service Desk.

1. University Courseware: University of Wisconsin-Madison, IT Service Management. "Incident Management Key Performance Indicators (KPIs)." The document lists "Number of Incidents (by priority, category, etc.)" as a fundamental KPI for the Incident Management process, which is owned and executed by the Service Desk. (Available through DoIT, University of Wisconsin-Madison's public documentation on ITSM).

2. Academic Publication: Marrone, M., & Kolbe, L. M. (2011). "Uncovering ITIL claims: IT executives’ perception on benefits and performance." Journal of Strategic Information Systems, 20(3), 300-312. This article discusses ITIL processes and their perceived benefits. It implicitly supports the distinction that the Service Desk handles incidents (Table 2, p. 304), while Problem Management focuses on root causes, making incident-based metrics (like volume by priority) central to the Service Desk. DOI: https://doi.org/10.1016/j.jsis.2011.06.004

3. Academic Publication: Idrees, N., & Xu, L. (2012). "A Framework for Measuring the Performance of IT Service Management." Proceedings of the World Congress on Engineering 2012 Vol II. This paper outlines various metrics for ITSM processes. In Section IV, Table I, under "Incident Management," it lists "Number of incidents per period" and "Number of incidents per priority" as key metrics, reinforcing that these are central to the function most associated with the Service Desk. (Available via IAENG, WCE 2012 proceedings).

Statement 1 is true because functional escalation is a fundamental component of the Incident Management process. It ensures that an incident is passed to a team with the appropriate technical skills when the initial support level cannot resolve it, thereby facilitating a timely restoration of service. Statement 3 is also true as a primary function of the Service Desk is to act as the single point of contact for users. This includes fulfilling routine, pre-approved Service Requests like password resets or software access, which are distinct from incidents. Statement 2 is false because the Service Desk handles various types of user interactions, including service requests and general inquiries, not just incidents (unplanned service interruptions).

B. All three of them: This is incorrect because statement 2 is false. Not all contacts with a Service Desk are classified as incidents.

C. Only 1: This is incorrect because statement 3 is also a true and standard practice in service management.

D. 1 and 2: This is incorrect because statement 2 is false; conflating all user contacts as incidents is a procedural error.

1. AXELOS. (2019). ITIL® Foundation: ITIL 4 Edition. TSO (The Stationery Office).

Section 5.2.5, Incident Management: This section details the purpose of incident management, which includes resolving incidents efficiently. It implicitly and explicitly covers the need for escalation paths (both functional and hierarchical) to route incidents to the correct resolution group.

Section 5.2.14, Service Desk: This practice is described as the entry point and single point of contact for the service provider with all of its users. It clarifies that the service desk handles both incidents and service requests.

Section 5.2.16, Service Request Management: This section defines service requests and notes that simpler requests are often fulfilled by the service desk team directly.

2. University of Washington. (n.d.). ITIL Key Concepts: Incident vs. Service Request. UW-IT, IT Connect. Retrieved from https://itconnect.uw.edu/work/services-and-processes/itil/itil-key-concepts-incident-vs-service-request/

This university documentation clearly distinguishes between an incident ("something is broken") and a service request ("a request for something new or different"). It supports the reasoning that not all calls are incidents (refuting statement 2) and that service requests are a distinct category of work handled by IT support (supporting statement 3).

3. Iden, J., & Langeland, L. (2010). Setting the stage for a successful ITIL adoption. International Journal of Information Management, 30(1), 69-77. https://doi.org/10.1016/j.ijinfomgt.2009.09.001

This academic paper discusses the implementation of ITIL processes. It reinforces the distinct nature and purpose of Incident Management and Request Fulfillment, highlighting that a Service Desk is structured to handle both types of user interactions, which aligns with the correct answer.

The primary responsibility for maintaining the accuracy and integrity of the Configuration Management Database (CMDB) and its Configuration Items (CIs) lies with the Configuration Management process, not Release Management. While the Release Management process provides crucial updates to the CMDB during the deployment of new software, the overall ownership and accountability for the CMDB's accuracy rests with Configuration Management. Release Management is a consumer and contributor of CMDB data, but not its ultimate custodian.

A. Release Management is directly responsible for the physical control of software assets, typically managed within a Definitive Media Library (DML) or equivalent secure repository.

C. Release Management provides essential expertise and practical input to help formulate and define the organization's overarching software release policies and strategies.

D. A core function of Release Management is the controlled and authorized distribution and deployment of software from a controlled environment to the live production systems.

1. Iden, J., & Langeland, A. (2010). "Setting the Stage for a Successful ITIL Implementation." Information Systems Management, 27(2), 154-162. This article describes the distinct ITIL processes, clarifying that Configuration Management's role is to "maintain a logical model of the IT infrastructure" (p. 157), which includes ensuring the accuracy of CIs in the CMDB, while Release Management focuses on the build and deployment lifecycle.

DOI: https://doi.org/10.1080/10580531003708363

2. University of Washington, IT Connect Courseware. "Change and Release Management." This course material distinguishes between the processes, stating that Configuration Management "maintains the definitive record of all configuration items (CIs)," implying responsibility for accuracy. In contrast, Release Management is defined by its role in planning and deploying changes.

Reference: UW IT Connect, "Key Concepts of Change Management," Section on related processes.

3. Brewster, E., Griffiths, R., & Lawes, A. (2010). IT Service Management: A Guide for ITIL V3 Foundation Exam Candidates. The British Computer Society. In Chapter 6, "Service Transition," the text explicitly states that the objective of Service Asset and Configuration Management is to "ensure that assets under the control of the IT organization are identified, controlled and properly cared for throughout their lifecycle... by maintaining an accurate and complete Configuration Management System" (Section 6.3). Release and Deployment Management's objectives are focused on the deployment itself (Section 6.4).

A Configuration Item (CI) is a fundamental component of a system that is managed under configuration control. A hardware CI represents a specific, tangible asset like a server, router, or workstation. Its attributes are properties that uniquely describe and manage that single item throughout its lifecycle. Attributes such as a supplier's part number, the item's cost, and the manufacturer's serial number are essential for identification, financial accounting, and tracking a specific instance. "The number of items held" is not an attribute of an individual CI; it is an inventory management metric that quantifies the stock level of a particular type of item, rather than describing a characteristic of a single, unique component.

A. A supplier's part number: This is a key identifier for a specific model or type of hardware, crucial for procurement and management.

B. The cost of the item: This is a critical financial attribute used for asset management, budgeting, and calculating total cost of ownership.

C. A manufacturer's serial number: This is a unique identifier for a specific physical instance of a hardware item, which is fundamental to tracking and control.

1. IEEE Std 828-2012, "IEEE Standard for Configuration Management in Systems and Software Engineering." Section 5.2.2.2, "Configuration identification," outlines the information required to identify CIs. It states, "Information about the CI shall be recorded so that the CI can be uniquely identified," which directly supports the use of unique identifiers like serial numbers and part numbers as attributes. The standard focuses on the attributes of individual items under control, not aggregate inventory counts.

2. Garschhammer, M., et al. (2001). "A Conceptual Model for Configuration Management Databases." In Integrated Network Management VII. Integrated Management in a Virtual World. IFIP/IEEE. This publication discusses the data models for Configuration Management Databases (CMDBs). The models show that a CI instance has attributes like serialNumber and modelNumber, and can have associated financial data. The model distinguishes between a CI instance and a CI type (or model), with inventory levels being a property of the type, not the individual instance. (See Section 3, "The Core Information Model"). DOI: https://doi.org/10.1007/3-540-45461-313

3. University of Toronto, CSC444/2107: Software Engineering, "Lecture 10: Configuration Management." Course materials on configuration management consistently define a CI as a single, identifiable unit. The attributes recorded in a CMDB describe that unit's specific state, identity, and relationships. Inventory data, such as quantity on hand, is treated as a separate concern of asset or stock management, not as an intrinsic attribute of a single CI.

The "Requirements and Strategy" phase of the Business Continuity Life-cycle is foundational. It begins with a Business Impact Analysis (BIA) to identify critical business processes and the impact of their disruption, thereby defining the requirements for recovery. Concurrently, a Risk Assessment identifies threats and vulnerabilities. The outputs of both the BIA and Risk Assessment are then used to formulate and select an appropriate Business Continuity Strategy. This strategy outlines the approach the organization will take to ensure resilience and recovery, directly addressing the identified requirements and risks. This sequence forms the core of the analysis and strategic planning stage in any recognized business continuity management framework.

A. Initial testing, Education and Awareness, and Assurance are activities that occur later in the life-cycle, primarily within the implementation, embedding, and validation/review phases, not the initial requirements phase.

B. Education and Awareness is part of embedding the BCM culture, while Review and Audit are components of the performance evaluation and continual improvement phase, which follows implementation.

C. Implementation Planning and Risk Reduction Measures are part of the subsequent design and implementation phases. They are actions taken after the core strategy has been determined.

1. ISO 22301:2019, Security and resilience — Business continuity management systems — Requirements.

Section 8.2.2, "Business impact analysis and risk assessment," mandates these activities to understand the organization's priorities and risks.

Section 8.3, "Business continuity strategy and solutions," requires the selection of strategies based on the outputs from Section 8.2.2. These sections collectively represent the requirements and strategy determination phase.

2. Business Continuity Institute (BCI), "Good Practice Guidelines (GPG), 2018 Edition."

Professional Practice 3 (PP3), "Analysis," details the process of conducting a Business Impact Analysis (BIA) and a risk assessment to determine continuity requirements.

Professional Practice 4 (PP4), "Design," describes how to use the outputs from the Analysis phase to identify and select appropriate strategies to meet the identified requirements.

3. Herbane, B. (2010). The evolution of business continuity management: A historical review of practices and drivers. Business History, 52(6), 978-1002.

This academic review discusses the evolution of BCM, consistently identifying BIA and risk assessment as the analytical foundation (requirements) upon which continuity strategies are built (p. 985). DOI: https://doi.org/10.1080/00076791.2010.511185