Fragen für Practice Manager ITITL zweiter Versuch

123

0.0 (0)

Pablo Garcia

Étudier

Pablo Garcia

À propos de ce fichier

Diese Lernkarten behandeln fortgeschrittene Themen der IT-Service-Management-Praktiken auf Universitätsniveau, mit Fokus auf Service-Request-Management, Incident-Management, Problem-Management und Monitoring. Sie decken Schlüsselkonzepte wie die Unterschiede zwischen Service-Request- und Incident-Management, die Bedeutung von Empathie im Service Desk, sowie die Rolle von Monitoring und Event Management bei der frühzeitigen Erkennung von Vorfällen ab. Praktiker im IT-Service-Management profitieren von diesen Karteikarten, da sie ihnen helfen, die Effizienz und Qualität ihrer Dienstleistungen zu verbessern, indem sie standardisierte Modelle und bewährte Verfahren anwenden.

Cartes-fiches

123

Utilisateurs

Langue

Allemand

Catégorie

Informatique

Niveau

Université

Créé / Mis à jour

05.09.2025 / 08.09.2025

Fichiers de cartes similaires

Cartes-fiches

Primary purpose of Incident Management?

To eliminate all root causes permanently

Minimize negative impact by restoring normal service operation quickly

To negotiate SLAs with customers

To prioritize projects over operations

To approve all infrastructure changes

If users perceive abnormal service but no SLA breach exists, what should be done?

Wait until an SLA breach occurs

Escalate directly to change enablement

Close as “request for information”

Log as a problem only

An SLA is breached but no users reported an issue. Correct action?

Do nothing until users complain

Open a service request

Only notify supplier management

Classify as known error immediately

A CI underperforms versus technical spec but SLA not yet impacted. What next?

Treat as a routine change

Ignore since SLA is fine

Log as a service request

Immediately initiate a major incident bridge

Which best characterizes a major incident?

High business impact and/or high complexity requiring special handling

Any ticket escalated to L3

Any P3 incident lasting over 2 hours

Only incidents affecting external customers

Only incidents detected by monitoring

Swarming is most appropriate when the incident is…

Clear and well-known with a standard model

Complex or of unknown nature, needing rapid joint diagnosis

Already resolved by self-healing

A routine service request

An SLA review item

A workaround in Incident Management primarily aims to…

Reduce or eliminate business impact without necessarily fixing the fault

Provide a permanent fix to the root cause

Bypass Problem Management entirely

Update SLAs with higher targets

Replace the need for incident models

Which is a Practice Success Factor (PSF) in Incident Management?

Detecting incidents early

Approving budget requests

Defining service portfolios

Contracting suppliers

Authorizing changes

Main practice enabling early incident detection?

Monitoring and Event Management

Service Level Management

Information Security Management

Deployment Management

Release Management

In the Cynefin framing of incidents, clear situations are best handled by…

Predefined procedures and incident models, often automated

Free-form experiments without constraints

Budget re-planning workshops

Only supplier-driven actions

Immediate problem closure

When is prioritization needed for incidents within teams?

Only when there is a resource conflict

Always, even if resources are idle

Never, prioritization is anti-Lean

Only for user-reported incidents

Only for events auto-registered

Where should incidents await assignment in a team’s work system?

In a single backlog together with other tasks

In separate backlogs per priority

Only in the service desk queue

In email threads

In ad-hoc spreadsheets per engineer

Which activity comes first in the incident handling and resolution process?

Incident detection

Incident diagnosis

Incident closure

Periodic review

Change enablement

A key metric for “detecting incidents early” is…

Time between occurrence and detection

Number of RFCs approved

Defect density in new code

Supplier invoice accuracy

MTBF of new hardware only

LACMT “T” competency refers to which capability for an incident-related role?

Technical expert (subject-matter expertise)

Team budgeting oversight

Talent acquisition

Target setting for sales

Third-party contracting authority

Which information item is MOST critical to capture at incident registration?

The annual depreciation value of the CI

Symptoms, affected service/CI, observed time, last known good

The project code of the reporter

Supplier DUNS number

Hardware purchase order number

A recommended automation design principle for Incident Management tools is to…

Design for the end-to-end value stream, not a single practice

Use one identical workflow for all incident sources

Ignore reporting until maturity stage 4

Forbid cross-team collaboration

Avoid integrating knowledge capability

How should third parties be reflected in incident handling?

In incident models with clear integration and collaboration rules

Excluded to keep accountability internal

Given unilateral authority to close all incidents

Engaged only after SLA breach

Handled solely via supplier invoices

Main purpose of the Service Desk practice in MSF context?

Single point of contact capturing demand for incidents and requests

Approving changes on behalf of CAB

Owning the CMDB schema

Owning product roadmaps

Issuing financial invoices to customers

A key benefit of Service Desk for service consumers is…

Clear, convenient interfaces that reduce miscommunication

Guaranteed 24/7 on-site support

Automatic root cause removal

Faster software development velocity

Elimination of all escalations

Which set belongs to “convenient channel” characteristics at the Service Desk?

Accessibility, Assurance, Availability, Context, Familiarity, Integration, Usability

Affordability, Accountability, Auditability

Accuracy, Allocability, Achievability

Automation, Authorization, Authentication

Alignment, Agility, Adaptability

Omnichannel versus multichannel in Service Desk implies…

Seamless context transfer when switching channels

Using a single channel only

More channels without integration

Blocking self-service and chat

Replacing phone support with email only

“Service empathy” for desk agents primarily means…

Understanding users’ feelings/needs while maintaining professional boundaries

Sharing the same emotions as the user

Outsourcing emotional support to bots

Ignoring emotion to preserve objectivity

Delegating empathy to problem managers

A PSF of the Service Desk practice is to enable…

Effective, efficient, convenient communications with users

Vendor selection for hardware

Annual portfolio reprioritization

Project steering committee decisions

Legal counsel reviews of contracts

A remedy for user-to-technology communication challenges is to…

Use familiar channels and ensure high-quality knowledge and data

Disable chat and portals

Remove self-service entirely

Prohibit contextual intelligence

Ignore ML data quality

Core purpose of Monitoring & Event Management (MEM)?

Support normal operation by observing, analyzing, and responding to events

Define supplier SLAs and OLAs

Approve major changes

Perform all incident communications

Own the service catalogue

Why is event correlation important in MEM?

It reduces noise and links related signals to detect meaningful conditions

It increases the number of alerts for visibility

It replaces the need for monitoring tools

It guarantees root cause analysis

It removes the need for thresholds

A recommended stance on SLAs for event types is to…

Avoid writing SLAs per event type; focus on overall service performance

Set unique SLAs for each event signature

Guarantee zero false positives in SLAs

Ignore service performance outcomes

Tie SLAs to log ingestion volumes

When designing monitoring, balancing granularity primarily helps to…

Avoid missing signals (too coarse) and noise/cost (too fine)

Increase storage consumption

Guarantee zero downtime

Eliminate the need for correlation

Replace incident models

Primary purpose of Problem Management in MSF?

Reduce likelihood and impact of incidents by managing causes, workarounds, known errors

Handle all user communications

Approve all releases

Own the request catalogue

Monitor events in real time

A “known error” is best described as…

A problem with analyzed root cause and/or confirmed workaround

Any incident older than 7 days

A standard change template

A resolved incident stored for audit

Any request linked to a CMDB CI

When can a workaround reasonably become a long-term solution in MSF context?

When permanent fix is not viable or cost-effective; problem remains a known error

Always, to speed closure metrics

Never; workarounds are forbidden

Only for supplier-related faults with no documentation

Only if incident SLA was met

Purpose of Service Request Management (SRM)?

Handle predefined, user-initiated requests effectively and in a user-friendly manner

Resolve unplanned service disruptions

Perform supplier scoring

Define strategic portfolio

Authorize financial spend

A service request model should include primarily…

Reusable steps, data, approvals, and automation for a request type

Root cause analysis methods

Major incident communications

Supplier penalty clauses

Release rollback plans

Why does MSF emphasize value streams over isolated practices for incident resolution?

Real workflows span multiple practices; integration reduces delays and handoffs

It eliminates the need for any single practice

It focuses only on project work

It replaces the need for service desk

It avoids documenting processes

Encouraging documentation and reuse of solutions in Incident Management mainly reflects which guidance?

Gather and reuse data; demonstrate value via reporting

Ignore history; favor ad-hoc fixes

Automate only at maturity level 4

Treat each incident as unique

Prioritize documentation over restoration time

Which statement correctly contrasts Incident Management and SRM?

Incidents restore normal operation after unplanned disruption; SRM fulfils predefined user requests

Both focus on new service design

SRM handles root cause analysis

Incident Management publishes the request catalogue

SRM manages major incidents

An advantage of automated early incident detection is that it often…

Improves data quality and enables self-healing before users notice

Eliminates the need for classification

Guarantees zero incidents

Removes the need for SLAs

Avoids communication with users entirely

Design guidance for handling user- vs event-initiated incidents in tooling is to…

Allow different workflows and business rules for each source

Force a single universal workflow for simplicity

Disable event ingestion until maturity

Route all events to Service Request Management

Bypass Service Desk for user-initiated incidents

In MSF, effective incident communications primarily aim to…

Reduce duplicate work and optimize IM and Service Desk resources

Replace the need for dashboards

Avoid updating stakeholders during resolution

Satisfy audit only

Delay user updates until closure

Étudier

Fragen für Practice Manager ITITL zweiter Versuch

Créer ou copier des fichiers d'apprentissage

Cartes-fiches

Veuillez vous connecter

Google

Apple ID

Microsoft

Switch edu-ID

Edulog

Google

Apple ID

Microsoft

Switch edu-ID

Edulog