COBIT-2019 COBIT 2019 Foundation Exam Topics and Questions

COBIT 2019 opens with questions about what the framework is for and where its authority comes from. Before anything else, the exam wants to know whether you can place COBIT in the right category: a governance framework for information and technology, not a project method or a security standard. That distinction shapes every answer that follows. The three sub-topics here are tightly connected, and the place most candidates slip is on the governance-versus-management line.

How Framework Introduction is tested

At 12%, this topic contributes a meaningful share of items, and they tend to be definitional with a twist. The exam does not ask you to recite COBIT's history; it asks you to apply the definition in a scenario where two plausible answers look similar. The governance-versus-management distinction is the sharpest edge here. Items reward candidates who can sort a described activity into the right category without hesitation, because the two overlap in practice and the exam exploits that overlap. The purpose and benefits sub-topic shows up less as a recall question and more as a filter: if a scenario describes an enterprise trying to solve a specific problem, items reward recognising whether COBIT is the appropriate tool for that problem. Candidates lose marks by over-generalising COBIT's scope or by treating governance and management as interchangeable. The evolution angle is the least heavily tested, but knowing what changed from earlier versions helps you rule out answers that describe outdated concepts.

Where Framework Introduction sets the context, Principles sets the rules that any compliant governance system must follow. The exam splits these into two distinct sets, and keeping them separate is the first challenge: six principles govern the system itself, three govern the framework. Candidates who blur that boundary find themselves unable to eliminate wrong answers confidently. At 13%, this topic carries slightly more weight than the introduction, so a vague understanding of the principles will cost you.

How Principles is tested

Items in this topic tend to present a governance scenario and ask which principle is being applied or violated. The six system principles and three framework principles each have distinct roles, and the exam uses that distinction to construct distractors that sound right but belong to the wrong set. Candidates lose marks by treating all nine principles as a single undifferentiated list. The principle about stakeholder needs is tested most often in applied form: a scenario describes a governance decision and items reward recognising how stakeholder needs should shape it. The holistic approach principle shows up when a scenario describes a partial or siloed governance effort. For the framework principles, the open-and-flexible angle appears in scenarios about adopting COBIT alongside other frameworks. The third sub-topic, on how principles guide governance design, is the glue: items reward understanding that the principles are not aspirational statements but constraints that drive design choices. Memorising the names is necessary but not sufficient.

At 30%, this is the largest topic on the exam by a significant margin. Everything you learned in the first two topics feeds into this one. The governance system is not an abstract idea here; it is a specific structure made up of seven component categories, each of which can be shaped by the enterprise's own circumstances. If you underinvest in this topic, the exam will find you out across nearly a third of the paper.

– The seven component categories

The seven categories are the backbone of this topic, and the exam tests them in two ways: by asking you to identify which category a described element belongs to, and by asking how a specific category contributes to governance or management. Processes get the most attention because they are the most visible, but the exam deliberately tests the less obvious categories, such as information, culture and behaviour, and people, skills and competencies, because candidates tend to neglect them. Organisational structures matter too, particularly in scenarios about accountability and decision rights. The trap is treating components as a list to memorise rather than as a set of interacting mechanisms. Items reward candidates who can say not just what a component is but what governance function it serves in a given context. If a scenario describes a breakdown in governance, you need to identify which component category is the source of the failure, which means understanding what each one actually does rather than just what it is called.

– Interaction and customisation

The second and third sub-topics are closely linked. Components do not operate in isolation; the exam tests whether you understand how they reinforce or depend on one another. A process without the right organisational structure to own it, or without the people and skills to execute it, will not deliver its governance objective. Items in this area reward a systems view rather than a component-by-component view. The customisation angle is where design factors enter the picture for the first time. Enterprises differ in size, risk appetite, regulatory exposure, and operating model, and COBIT explicitly acknowledges that components should reflect those differences. The exam tests this by presenting an enterprise with specific characteristics and asking which component adjustments are appropriate. Candidates lose marks by applying a one-size-fits-all answer when the scenario is signalling that the enterprise context matters. Pay attention to the design factor signals embedded in scenario stems, because they are there to narrow the answer space.

How Governance System and Components is tested

With 30% of the exam drawn from this topic, you will see it represented across a wide range of item styles. Some items are identification tasks: a scenario describes a governance element and you assign it to the right component category. Others are application tasks: a scenario describes an enterprise problem and you identify which component is missing or misconfigured. The most demanding items combine both: they present a multi-component scenario and reward the candidate who can trace a governance failure back to its root component rather than its symptom. Candidates consistently lose marks on the interaction sub-topic because they answer at the level of individual components rather than at the level of the system. The customisation sub-topic is tested through scenario stems that embed design factor details, and items reward reading those details as constraints on the answer rather than background noise. Do not skim the scenario context in this topic: the enterprise-specific details are usually doing work.

This topic and the previous one together account for more than half the exam. Where topic 3 described the system's structure, this one describes what the system is trying to achieve. The five domains, the goals cascade, and the purpose of individual objectives are the three axes the exam tests across. At 23%, a weak grasp of domain scope or a fuzzy understanding of how enterprise goals translate into governance priorities will be expensive.

– The five domains and their scope

The domains divide the full set of governance and management objectives into coherent groups, and the exam tests whether you can place an objective or activity in the right domain. EDM sits at the governance layer; the other four are management domains. That split matters because items frequently present a scenario where the correct domain assignment depends on whether the activity is governance or management, a distinction first introduced in topic 1 and now applied at domain level. APO, BAI, DSS, and MEA each have a distinct operational focus, and the exam exploits the overlap between them. BAI and DSS in particular share territory around service transition and operational continuity, and distractors in this area are constructed to look plausible for both. Candidates who know the domain names but not their scope boundaries find themselves guessing between two reasonable-sounding options. The sharper your understanding of what each domain owns, the faster you can eliminate distractors.

– Goals cascade and objective-level detail

The goals cascade is one of the most tested mechanisms in the entire exam. It connects enterprise goals to alignment goals, and alignment goals to governance and management objectives. Items reward understanding the direction of that flow: enterprise priorities drive alignment goals, which in turn determine which objectives deserve the most attention. The exam tests this in both directions. Some items give you an enterprise goal and ask which alignment goal it maps to; others give you a governance problem and ask which level of the cascade it belongs to. The third sub-topic, on the purpose and components associated with individual objectives, adds another layer. Each objective has a stated purpose and a set of associated components from topic 3. Items here reward candidates who can connect an objective to its domain and to its component dependencies. Losing track of which objectives belong to which domain, or treating the goals cascade as a one-way lookup table rather than a prioritisation tool, is where marks go.

How Governance and Management Objectives is tested

At 23%, this topic produces a large volume of items, and they span a wider difficulty range than any other topic on the exam. Straightforward items ask you to assign an objective to a domain. Harder items embed the goals cascade in a multi-step scenario: an enterprise has a specific strategic priority, and you need to trace it through alignment goals to the relevant governance or management objectives. Candidates lose marks at the cascade step most often, either by skipping a level or by applying the cascade in the wrong direction. The EDM-versus-management-domain distinction is a persistent source of errors: items reward placing oversight and direction activities in EDM rather than in the management domains, even when the scenario describes something that looks operational. The objective-level detail sub-topic tends to produce items that reward knowing what a named objective is for, not just which domain it sits in. Broad familiarity with objective purposes, combined with a solid command of the cascade, is what separates passing scores from strong ones here.

After the two heaviest topics, this one is a deliberate change of scale. At 4%, Performance Management contributes a small share of items, but the concepts it covers, capability levels, maturity levels, and the CMMI-based model, appear as supporting context in scenarios drawn from other topics. Treating it as negligible because the weight is low is a mistake: a wrong answer here costs exactly as much as a wrong answer in topic 3.

How Performance Management is tested

Items in this topic tend to be more definitional than those in the heavier topics, but they are not simple recall. The CMMI-based model shift is the most commonly tested angle: items reward knowing what changed from the earlier capability model and why the shift matters for how performance is measured. The distinction between capability levels and maturity levels is a reliable source of distractors. Both concepts exist in COBIT 2019, but they apply at different levels of the system, and items exploit the tendency to conflate them. Candidates lose marks by treating capability and maturity as synonyms or by applying the wrong concept to a described scenario. The performance management concept itself, applied to the governance system and its objectives, ties this topic back to topic 4: an objective cannot be managed without a way to measure it, and items occasionally reward making that connection explicit. At 4%, the number of items is small, but each one is winnable with precise definitions.

Topic 3 introduced the idea that components can be customised; this topic explains the mechanism for doing that. Designing a tailored governance system is an applied topic: the exam gives you an enterprise with specific characteristics and asks what a well-designed governance system for that enterprise looks like. At 7%, it sits in the middle of the weight range, and the step-by-step design approach is the part that catches candidates who studied the components but skipped the design logic.

How Designing a Tailored Governance System is tested

Items here are scenario-heavy. The exam describes an enterprise with a particular strategy, risk profile, or operating environment and asks which design factors are most relevant, or how those factors should affect objective prioritisation. The step-by-step approach sub-topic is tested by presenting a design decision at a specific stage and asking what should happen next, or what input is needed before that step can proceed. Candidates lose marks by applying generic COBIT guidance when the scenario has already signalled a specific enterprise context. The design factor sub-topic and the prioritisation sub-topic are closely connected: items reward understanding that design factors are not just background information but active inputs that change which objectives a given enterprise should weight most heavily. The trap is treating design as a one-time activity rather than an iterative process that responds to changing enterprise circumstances. Items that describe a change in enterprise strategy or risk appetite are testing whether you understand that the governance design should respond to that change.

At 3%, this is the lightest topic on the exam, and it is also the most self-contained. The business case topic is not about financial modelling; it is about understanding why a governance initiative needs formal justification and how that justification supports change. The three sub-topics cover purpose, content, and the link to change enablement, and the exam tests all three, even if the item count is small.

How Business Case is tested

Items in this topic tend to be direct: a scenario describes a governance initiative and asks what the business case should accomplish, or what element is missing from a described business case. The purpose sub-topic is the most straightforward: items reward understanding that a business case exists to justify the initiative and secure commitment, not to document the technical design. The key elements sub-topic produces items where a described business case is incomplete, and candidates must identify what is absent. Candidates lose marks by over-specifying what belongs in a business case or by confusing it with a project plan. The change enablement angle is the most nuanced: items reward recognising that a business case is not just a financial document but a tool for managing stakeholder expectations and enabling the organisational change that governance implementation requires. That connection to change enablement links this topic directly to topic 8, and items occasionally test whether you can make that link. With only a handful of items expected, precision on each concept matters more than breadth.

Implementation closes the exam with an applied, process-oriented topic. The seven-phase lifecycle, the change enablement approach, and the continual improvement cycle are the three structures you need to know, and the exam tests all three in scenario form. At 8%, this topic carries more weight than the previous two combined, and candidates who treated it as an afterthought in their preparation tend to find it the least forgiving topic to recover from under time pressure.

How Implementation is tested

The seven-phase lifecycle is the most directly tested structure: items describe a governance initiative at a specific stage and reward identifying the correct phase, or the correct next action within that phase. Candidates lose marks by confusing the sequence of phases or by treating the lifecycle as linear when the exam signals a need to revisit an earlier phase. The change enablement sub-topic is tested in scenarios where a governance initiative is failing to gain traction: items reward recognising that the problem is organisational resistance rather than a technical gap, and that the response belongs to change enablement rather than to the lifecycle itself. The continual improvement sub-topic produces items about sustaining governance effectiveness after initial implementation. These items reward understanding that implementation does not end at go-live: the governance system needs ongoing assessment and adjustment. The connection between continual improvement and the performance management concepts from topic 5 is a live one, and items occasionally reward candidates who can draw that link without being prompted.