Information Systems Operations and Business Resilience practice questions

P1

A critical system outage affecting all users is a P1: ITIL severity reflects impact and urgency, and total loss of a critical service for the entire user base represents the highest impact, demanding immediate resolution.

Changes may not be properly documented

Emergency changes bypass the normal authorisation and testing path, so without post-implementation review there is no verification that the change was recorded, approved retrospectively, or tested. The primary concern is therefore incomplete documentation, leaving the audit trail unable to evidence what was changed and why.

Automated resource tagging

Automated resource tagging attaches cost-centre, owner and environment metadata to every provisioned resource, enabling chargeback, budget alerts and anomaly detection per team. This satisfies the stem's cost-overrun control need by making consumption attributable, so unowned or unexpected spend is identified before budgets are breached.

Regular detection and removal of orphaned resources

Orphaned resources — unattached disks, idle load balancers, stale snapshots — continue incurring charges while delivering no business value. Regularly detecting and removing them directly prevents the silent cost overruns the stem targets, since these resources typically escape normal ownership and review processes.

The rerun procedure specifies the correct restart point

Verifying the correct restart point ensures the rerun resumes after the last committed step, preserving payroll data integrity and avoiding duplicate postings. This directly satisfies the stem's dependency-failure constraint, since restarting from the wrong point would reprocess completed jobs or skip dependent ones.

Full backup

A full backup contains the entire database in one set, so restoration requires only that single backup. Incremental backups capture only changes since the last backup, requiring the last full plus every subsequent incremental to be applied in sequence, making restore slower.

Detect and remove orphaned resources

Orphaned resources — volumes, IP addresses, load balancers left after instances are terminated — continue incurring charges while delivering no service. Detecting and removing them directly eliminates this waste, satisfying the strategy's cost-optimisation and waste-prevention objectives.

Automate shutdown of idle resources during off-hours

Automating shutdown of idle resources during off-hours directly satisfies the cost-optimisation and waste-prevention objectives by eliminating spend on non-productive compute. Scheduled deallocation of virtual machines and similar resources removes ongoing charges for capacity that delivers no business value, a core cloud governance control auditors should recommend.

Implement resource tagging for cost allocation

Tagging attaches metadata such as owner, project and cost centre to each resource, enabling chargeback and identification of unowned spend. Without tags, costs cannot be attributed, so waste and budget overruns stay invisible — this underpins the whole optimisation strategy.

The change was implemented without CAB approval.

Classifying the upgrade as standard was invalid: it required application code modifications, so it was not a pre-approved low-risk change. Bypassing CAB review removed the assessment that would have caught integration and rollback risks, directly violating the change authorisation constraint the process exists to enforce.

Data loss exceeds the RPO.

Nightly backups give a 12-hour RPO against a 15-minute requirement, so up to 12 hours of payment transactions could be lost — far exceeding tolerance. The four-hour restore breaches the two-hour MTD, but data loss is the more critical risk.

Inaccurate cost allocation and potential budget overruns.

Untagged orphaned resources running for months escape departmental cost attribution, so spend lands in a default account and departments are never charged. This defeats the tagging control's purpose and hides waste, allowing budgets to be exceeded without detection until the next audit cycle.

Request immediate addition of resources to meet current demand.

Sustained CPU above 90% with no alerting and a six-month remediation delay leaves the critical application exposed now. Immediate resource addition addresses the current demand breach, whereas threshold alerts and plan revisions only improve future detection and planning.

Within 15 minutes

Immediate response is expected for critical incidents.

Warm site

A warm site provides pre-installed hardware and partially configured systems, enabling operations to resume within hours, and is commonly shared between organisations to reduce cost. A hot site would resume faster but costs more; a cold site lacks the equipment for rapid recovery.

Full interruption test

Actual switch-over causing disruption.

Immediately assign the incident to the appropriate support team for resolution.

Priority 1 incidents demand immediate escalation and coordinated response, so assigning the incident straight to the appropriate support team triggers the fastest restoration path. ITIL prioritisation determines the urgency of resource allocation, and P1 severity justifies bypassing routine triage queues to meet service restoration targets.

Recovery procedures are not tested against the RTO.

Daily full backups restore in six hours, exceeding the four-hour RTO, so the backup strategy itself is inadequate. Untested procedures are the likely cause: the organisation never validated restore duration against the RTO, so the shortfall went undetected until an actual disaster.

Backup tapes are stored offsite and retrieved only once per month

Monthly offsite retrieval means restoring a 4-hour RTO application could take weeks if tapes are needed, since backups sit inaccessible offsite. Daily full backups exist, but retrieval frequency, not backup frequency, breaks the recovery time objective.

4.32 minutes

Availability of 99.99% permits 0.01% downtime, equating to 4.32 minutes per 720-hour MTBF period. MTTR must not exceed this allowance, so 4.32 minutes is the maximum mean time to repair that still satisfies the stated availability requirement.

Known error database

The known error database records diagnosed root causes and associated workarounds, letting the service desk resolve recurrences rapidly without repeated investigation. It is a primary problem management output, distinct from incident records, and directly supports the stem's requirement for effective problem management.

Root cause analysis

Root cause analysis identifies the underlying fault generating recurring incidents, enabling a permanent fix rather than repeated symptomatic treatment. It is a core problem management output, satisfying the stem's requirement by producing the diagnostic knowledge that feeds the known error database.

Ensuring backup retention periods meet the recovery point objective (RPO).

Retention periods determine how far back data can be restored. Aligning retention with the RPO ensures backups exist covering the maximum tolerable data loss window, satisfying recoverability by guaranteeing a usable restore point is always available.

Regularly performing restore verification tests.

Backups are only proven recoverable when restores are actually performed and verified. Regular restore testing validates media integrity, procedure accuracy and completeness, exposing failures that untested backups conceal, which directly supports the reliability and recoverability objective.

Storing backups at an offsite location.

Offsite storage isolates backup copies from site-specific events such as fire, flood or theft that could destroy both production data and locally held backups. This preserves a recoverable copy, directly supporting reliability and recoverability for the critical database.

Including right-to-audit clauses in contracts.

Right-to-audit clauses grant the organisation contractual authority to inspect a vendor's controls, evidence and records, directly satisfying the third-party risk constraint. Without this provision, assurance relies solely on vendor self-reporting, leaving the IS auditor unable to independently verify control effectiveness or pursue remediation.

Regularly monitoring service level agreements (SLAs).

Regular SLA monitoring provides continuous assurance that vendor performance meets contracted thresholds, satisfying the need to detect service degradation before it affects business operations. It creates an auditable trail of measured outcomes, enabling the auditor to verify that third-party risk is actively managed rather than assumed at onboarding.