Hard Difficulty Questions

Commit to a full private cloud refresh sized for current peak demand across all workloads.

Why it fails: Sizing private cloud for current peak across all workloads locks capital into capacity that variable digital channels may not need continuously, and it assumes demand will not change over the asset life. It ignores the portfolio's mixed profile and the lease deadline as a chance to rebalance. This over-provisions stable and volatile workloads alike, wasting IT resources.

Migrate all workloads to public cloud immediately to eliminate the data center lease decision.

Why it fails: Lifting every workload, including stable legacy systems, to public cloud can create re-platforming cost, latency and compliance issues that outweigh the convenience of exiting the lease. It replaces one capacity decision with a broad transformation risk and does not differentiate stable from variable demand, so it is not a resource-optimizing governance choice.

Extend the lease on a month-to-month basis and defer the capacity strategy until demand patterns become clearer.

Why it fails: Deferring the strategy treats the lease as the only deadline while ignoring that capacity decisions have long lead times and budget cycles. Month-to-month extension often carries premium pricing and leaves the enterprise without a governed plan, so it delays rather than manages the resource risk and can raise total cost.

Risk transfer by purchasing cyber insurance and removing the system from the risk register.

Why it fails: Insurance may offset financial loss but does not eliminate the operational, regulatory, or reputational consequences of a compromise. Removing the system from the risk register after transfer hides residual risk from governance oversight. Transfer is also unsuitable as the sole response because the unpatched vulnerability remains exploitable, so the exposure must stay recorded and monitored regardless of any policy.

Risk avoidance by decommissioning the system immediately and halting regulatory submissions.

Why it fails: Avoidance eliminates the activity generating the risk, but halting regulatory submissions would stop a core business process and violate compliance obligations. The system is essential, so removing it is not feasible without an approved replacement. Avoidance is therefore disproportionate and would create greater enterprise risk than the vulnerability it removes, making it an inappropriate documented response for this scenario.

Risk mitigation by applying an unsupported third-party patch to the legacy system without vendor validation.

Why it fails: Applying unauthorized patches to a validated laboratory system can invalidate regulatory compliance and introduce instability into a platform supporting submissions. This is not genuine mitigation because the fix is unverified and may itself create new failure modes. The scenario states the system cannot be patched, so this option contradicts the constraint and would be rejected by quality and regulatory functions.

Increase the frequency of IT risk assessments to quarterly.

Why it fails: More frequent assessments may improve risk identification, but they do not ensure that IT risk decisions consider the enterprise risk appetite. The gap is about alignment, not assessment cadence. Without a formal linkage to the enterprise risk appetite, even frequent assessments may continue to produce decisions that are misaligned with the board's risk tolerance.

Delegate all IT risk decisions to the enterprise risk management committee.

Why it fails: Delegating all IT risk decisions to the ERM committee may disenfranchise IT management and slow decision-making. The goal is integration, not abdication. IT management should remain accountable for IT risk within the boundaries set by the enterprise risk appetite. This action does not build the necessary alignment and could weaken IT governance.

Update the IT risk register to include all enterprise risks.

Why it fails: Expanding the IT risk register to include all enterprise risks may blur accountability and does not necessarily integrate IT risk with ERM. The core issue is alignment of IT risk decisions with the enterprise risk appetite, not the scope of the register. This action could create confusion and duplicate efforts without addressing the governance gap.

Standardize all processes across the company.

Why it fails: Uniform standardisation across every team increases the burden the firm is trying to relieve, contradicting the agile structure. The option is tempting because consistency aids auditability, but governance should scale controls to risk and team size, so the appropriate action is proportionate, tiered processes rather than company-wide uniformity.

Ignore the framework until the company grows.

Why it fails: Abandoning governance leaves risk unmanaged and unaccountable, which is not a defensible position even temporarily. The option is tempting because pausing heavy controls reduces friction, but the correct action is tailoring the framework's rigour to the firm's scale, not suspending oversight until growth justifies it.

Appoint more auditors to monitor compliance.

Why it fails: Adding auditors raises cost and oversight without removing the framework's weight, so it worsens the burden identified. The option is tempting because assurance looks like stronger governance, but the issue is framework proportionality, not detection capacity; the right action is streamlining controls to fit small agile teams.

Approve the budget as presented to ensure operational stability.

Why it fails: Approving the budget without change fails to address the strategic misalignment. The board's digital transformation mandate requires a shift in resource allocation towards innovation. Maintaining the status quo may ensure short-term stability but risks long-term competitiveness and does not fulfill governance responsibilities to align IT resources with enterprise strategy.

Escalate the decision to the board of directors for a final ruling on the budget.

Why it fails: Escalation may be necessary in some cases, but the IT steering committee is the appropriate governance body to first address resource allocation misalignment. The committee should provide a recommendation or a revised plan to the board. Escalating without analysis abdicates the committee's responsibility to oversee IT resources and provide strategic guidance.

Reject the budget and demand an immediate increase in the strategic allocation to 50%.

Why it fails: While the intent is correct, demanding an immediate and drastic reallocation without a transition plan is impractical and could destabilize critical operations. A sudden shift may starve essential maintenance, leading to system failures. Effective governance requires a balanced, phased approach that considers operational risks and the organization's capacity to absorb change.

The size of the IT office building.

Why it fails: Physical office size has no bearing on how often the board needs risk information; reporting frequency should track risk profile, appetite thresholds and change velocity. It is tempting because facility factors do appear in some operational risk assessments, but they inform risk content, not board reporting cadence.

The number of years the board members have served.

Why it fails: Board tenure does not determine how frequently risk information must reach the board; cadence should follow risk materiality, appetite breaches and the rate of change in the risk landscape. It is tempting because tenure affects board dynamics and familiarity, yet it does not alter the underlying need for timely risk visibility.

The color of the risk report cover page.

Why it fails: Cover page colour is presentational and has no relationship to the timeliness of risk information reaching the board; frequency should reflect risk severity, appetite thresholds and emerging exposures. It is tempting because report design does affect readability, but formatting choices never determine reporting cadence.

Reducing the number of project stakeholders.

Why it fails: Reducing stakeholders is an organisational change with no bearing on identifying, tracking or realising benefits; the lifecycle requires engaging stakeholders to define and measure value. It is tempting because stakeholder management is a governance concern, and it would be relevant if the question asked how to simplify project governance structures.

Updating the project's source code documentation.

Why it fails: Source code documentation is a software engineering deliverable, not a benefits management activity; the benefits lifecycle covers identifying, analysing, planning, realising and reviewing benefits. It is tempting because documentation supports governance, and it would fit if the question concerned configuration or change management rather than benefits realisation.

Engage a staffing agency to provide contract specialists who can step in if any of the current specialists leave

Why it fails: Contract specialists can provide surge capacity but rarely possess the deep institutional knowledge of a bespoke legacy interface, and they introduce their own onboarding lead time and dependency. This option substitutes one external dependency for an internal one without capturing the knowledge in documentation or transferring it to permanent staff, leaving the governance risk structurally unchanged.

Approve a retention bonus program to keep the specialists employed for as long as possible

Why it fails: Retention bonuses delay but do not resolve the underlying knowledge concentration risk. The specialists will eventually leave, and the governance gap remains. This option treats a symptom while leaving the enterprise exposed to sudden departure, illness, or resignation. It also consumes budget without building the durable capability that governance objectives require for sustaining critical clinical services.

Initiate a project to replace the legacy interface with a modern platform, eliminating the need for the specialists' skills

Why it fails: Replacement may be the right long-term direction, but it is a multi-year effort that leaves the knowledge concentration risk unmitigated in the interim. If a specialist departs during the replacement project, the migration itself could stall. Governance requires addressing the immediate continuity risk before or alongside the strategic replacement, not deferring it to a future project outcome.

Decommission it immediately to save money.

Why it fails: Immediate decommissioning removes a system the department still depends on, disrupting critical operations before any transition exists. It is tempting as a cost-saving action, yet decommissioning is correct only after migration or replacement has been completed and validated.

Force the department to find their own funding.

Why it fails: Forcing the department to self-fund bypasses governance and leaves the critical service without assured support. It is tempting as a way to respect the funding decision, but the committee should instead assess risk and plan an orderly transition or replacement.

Ignore the committee's decision and keep paying.

Why it fails: Ignoring the committee's decision undermines governance authority and leaves the funding conflict unresolved. It is tempting to preserve continuity, but the correct response is to escalate the risk and agree a managed transition, not to continue unauthorised spending.

To ensure the project follows the vendor's best practices.

Why it fails: Vendor best practices govern implementation quality, not whether the organisation will realise the intended benefits; benefit-realisation risk concerns adoption, capability and outcome dependency. Following vendor guidance is tempting during solution design, where it genuinely reduces delivery risk, but it does not address whether benefits are achievable.

To ensure the technical project has no bugs.

Why it fails: Bug-free delivery is a technical quality objective handled through testing and assurance; benefit-realisation risk addresses whether outcomes deliver value once the project is live. Eliminating defects is tempting because it feels like project success, but it is the correct focus for quality assurance planning, not feasibility benefit analysis.

To reduce the number of stakeholders involved.

Why it fails: Stakeholder count is not a risk to realization.

Require the board of directors to approve every IT change

Why it fails: Board approval of every IT change adds an escalation layer above existing decision rights, lengthening cycle time rather than shortening it. It tempts because boards legitimately own risk appetite and major investment approval, so escalating to them appears to strengthen governance when responsiveness is the actual concern.

Remove all governance oversight requirements to speed up decisions

Why it fails: Removing governance oversight eliminates the decision rights, risk guardrails and accountability that direct IT investment, producing uncontrolled change rather than faster governed decisions. It tempts because oversight is often blamed for delay, yet the stem requires faster decision-making within governance, not its abolition.

Stop all development until the governance process is redesigned

Why it fails: Halting development freezes delivery entirely and addresses no decision-rights or escalation defect, so responsiveness worsens. It tempts because pausing work to redesign governance sounds disciplined, yet the stem demands faster decisions during market change, which a development freeze directly contradicts.

Accept the risk because the project is strategically important.

Why it fails: Accepting a moderate breach risk contradicts the stated low appetite, so governance must direct treatment rather than tolerate it. Acceptance suits risks already inside appetite. Strategic importance does not override a board-set appetite; the correct action escalates for mitigation, transfer or rejection.

Lower the 'low' appetite threshold to 'moderate'.

Why it fails: Altering the appetite threshold to legitimise the project inverts governance: appetite is set by leadership and drives decisions, not the reverse. Thresholds change through formal risk-appetite review, not per-project convenience. Lowering appetite is correct only when strategy genuinely shifts, not to accommodate one initiative.

Document the risk in the risk register and ignore it for now.

Why it fails: Recording and deferring leaves a moderate breach risk unaddressed against a low appetite, breaching governance obligations. The register tracks risks; it does not authorise inaction. Documentation alone suits risks already within appetite or formally accepted after treatment decisions.

The slower speed of provisioning resources

Why it fails: Provisioning speed is an operational performance metric, not a governance challenge for resource optimisation; multi-cloud governance must reconcile inconsistent tagging, quotas and utilisation visibility across providers. It is tempting because slow provisioning frustrates teams, but automation, not governance, addresses it.

The difficulty of finding cloud architects

Why it fails: Architect scarcity is a staffing and skills concern, not a resource-optimisation governance issue; multi-cloud resource optimisation centres on allocating, tracking and right-sizing workloads across providers. It is tempting because multi-cloud environments do demand scarce expertise, but that affects delivery capability rather than governance of resource usage.

The increased cost of data egress fees between clouds

Why it fails: Egress fees are a cost-management concern, not the governance challenge of optimising resource allocation across providers. It is tempting because multi-cloud billing is genuinely complex, but the question asks about resource optimisation — matching workloads to the right provider capacity — not transfer pricing.

The board should take over all local IT decisions.

Why it fails: Boards set direction, risk appetite and assurance; assuming local IT decisions removes the delegated authority decentralisation depends on. It tempts because boards own governance accountability, but that means oversight of decision rights, not exercising them directly.

The governance framework is no longer required.

Why it fails: Decentralisation redistributes decision rights to business units; it does not remove the need for governance, which must instead be redefined with federated policies, escalation paths and oversight. The option is tempting because decentralised structures do grant local autonomy, but that autonomy still operates within an enterprise governance framework.

Decentralization makes IT governance impossible.

Why it fails: Decentralisation redistributes decision rights to business units while enterprise governance retains policy, risk and performance oversight. It tempts because federated structures genuinely complicate consistency, yet governance adapts through frameworks and assurance rather than becoming unworkable.

In the software coding standards.

Why it fails: Coding standards govern source quality, not whether the redesigned business process is adopted, so they cannot cause unrealised benefits here. It is tempting because standards are a genuine benefits-management concern when poor code quality undermines a delivered system, but this scenario's failure sits in process change, not software construction.

In the technical design phase.

Why it fails: The technical design phase covers system architecture and build, not the business process change needed to realise benefits. The failure lies in benefits management planning, which should have scheduled the process update. It is tempting because the outdated manual process touches the delivered system's operation.

In the project budget management.

Why it fails: Budget management tracks spend against forecast; it does not govern whether the re-engineered manual process is implemented, so it cannot explain the shortfall. It is tempting because cost control is a legitimate benefits-management activity when overspend erodes the business case, but here the system was delivered and the process was not.

Adopt the framework of the company with more employees.

Why it fails: Employee count does not determine governance fit; the merged entity's strategy, risk profile and regulatory obligations do. It is tempting as a quick, objective tiebreaker, but it would be correct only if the larger company's framework already satisfied the combined entity's requirements.

Keep both frameworks as they are.

Why it fails: Retaining both frameworks leaves duplicated, conflicting governance processes after the merger, so no single authority or decision path exists. It is tempting to minimise disruption, but it would be correct only where the entities remain legally and operationally separate.

Abandon both frameworks and start from scratch.

Why it fails: Discarding both frameworks loses established controls and compliance evidence, creating a governance gap during integration. It is tempting when both frameworks appear incompatible, but it would be correct only for a genuinely new entity with no inherited obligations or existing controls worth preserving.

Updating the incident management policy to mandate shorter SLA targets.

Why it fails: Shorter SLA targets accelerate individual ticket resolution but do not establish the risk criteria, aggregation or reporting that reveal a pattern of minor incidents becoming enterprise risk. SLA tightening suits chronic backlog or slow-resolution problems.

Increasing the budget for incident response staff.

Why it fails: Additional response staff address capacity, not the governance gap: without policy defining risk thresholds and escalation, recurring minor incidents still accumulate unmonitored. Budget increases suit resourcing shortfalls, whereas the stem asks for a governance action.

Requiring all incidents to be reported directly to the board of directors.

Why it fails: Reporting every minor incident to the board floods directors with operational noise, delaying escalation of genuine enterprise risks and bypassing the IT service management escalation path. Board reporting suits material incidents or aggregated risk trends. The stem requires governance oversight of recurring minor incidents, which is achieved through management reporting thresholds and trend analysis, not direct board notification.

The initial cost of implementing the system

Why it fails: Sunk implementation cost is irrelevant to forward-looking optimisation; retirement decisions hinge on ongoing support, licensing and integration burden. It is tempting because original spend feels significant, but that cost is unrecoverable, so this factor would matter only for historical cost accounting, not for planning resource reallocation.

The amount of documentation available for the system

Why it fails: Documentation volume does not determine resource optimisation; the critical factor is identifying which system capabilities are still consumed, so effort maps to actual business dependency. Documentation supports knowledge transfer and audit evidence during decommissioning, making it valuable once retirement scope is fixed — but it cannot reveal redundant capacity or duplicated function across the portfolio.

The age of the hardware

Why it fails: Hardware age says nothing about business value, dependency or migration effort, so it cannot drive optimisation decisions. It is tempting because older assets intuitively appear ready for retirement, but age is the right criterion only when the question concerns physical refresh cycles rather than resource optimisation across a portfolio.

Hiring a dedicated resource governance manager

Why it fails: Hiring a dedicated manager creates a single point of accountability without the decision rights, stakeholder engagement and enforcement mechanisms that make governance work. It is tempting because assigning an owner appears decisive, but the critical action is defining clear roles, responsibilities and escalation paths across the organisation.

Automating all policy enforcement mechanisms

Why it fails: Automation enforces policy consistently but cannot define ownership, scope or exception handling, which determine whether a resource governance policy succeeds. It is tempting because automation scales enforcement across many resources; it would be correct once the policy's decision rights and controls are already agreed and stable.

Creating a 500-page policy document covering every scenario

Why it fails: A 500-page document covering every scenario becomes unusable and unenforceable; governance succeeds through concise, actionable policies with clear ownership and decision rights. It is tempting because exhaustive coverage feels thorough and defensible, but the critical action is establishing accountability and enforcement mechanisms that stakeholders actually follow.

Increased revenue from new digital sales channels.

Why it fails: New digital sales revenue is a direct, quantifiable financial return attributable to the initiative, so it is a tangible direct benefit rather than an indirect one. It is tempting because revenue growth feels like a downstream effect, but indirect benefits are non-financial enablement outcomes such as improved morale, information quality or stakeholder satisfaction.

Decrease in server hardware acquisition costs.

Why it fails: Hardware acquisition cost reduction is a direct, measurable saving tied to the infrastructure investment, not an indirect benefit. It is tempting because procurement savings appear consequential, yet indirect benefits stem from business outcomes the technology enables, such as enhanced decision-making, regulatory compliance or user satisfaction, which resist direct financial attribution.

Reduction in annual software maintenance costs.

Why it fails: Software maintenance savings are a direct, quantifiable cost reduction attributable to the IT investment itself, so they count as a tangible direct benefit. It is tempting because recurring licence and support fees feel like downstream effects, but indirect benefits are those arising from business enablement, such as improved staff productivity or customer satisfaction, rather than the cost line itself.