Free OGEA-103 practice test: 30 questions with answers

Phase A establishes the scope, constraints and expectations and produces the Architecture Vision and Statement of Architecture Work for sponsor approval. Phases B, C and D all assume that approved scope, so starting with any of them skips the approval step.

Phase E works out how the gaps found earlier will be delivered, through projects, implementation options and transition architectures. Governance setup belongs to the Preliminary Phase, business validation to Phase A, and the finalised migration plan to Phase F.

Phase F prioritises the work packages, performs the cost-benefit analysis and risk assessment, and finalises the Implementation and Migration Plan. Phase E identifies the options without finalising the plan, Phase G oversees implementation once it starts, and Phase H handles change after the architecture is in use.

Requirements Management is a continuous process that feeds every phase, and Phase A produces the Architecture Vision with sponsor approval of the Statement of Architecture Work. Phase H runs after the architecture is in use, Phase D comes after Phase B and C, and Phase G uses architecture contracts during implementation.

An architecture contract is a joint agreement between sponsors and development partners covering deliverables, quality and fitness for purpose, so it is the instrument that formalises these obligations. The catalogue, gap matrix and capability assessment support architecture work but do not record compliance commitments.

The architecture board oversees the architecture, checks that decisions are applied consistently, monitors compliance and manages exceptions. Budgets, invoices and source code belong to project and delivery teams rather than to the board's primary role.

Compliance reviews, a chartered architecture board and documented exception handling are standard governance activities that keep architecture under control. Approving individual code commits and setting team budgets are outside the architecture governance role and would not scale across an enterprise.

Architecture governance is an ongoing, enterprise-wide practice for managing and controlling architectures, not a one-off review. The other options describe budget closure, source code records and network design, which fall outside the definition.

A matrix shows relationships between two classes of architecture entities, which suits a grid check for gaps. A catalogue lists items without showing relationships, a diagram gives a visual picture rather than a systematic cross-check, and a principle is a rule rather than an artifact.

Deliverables are formal, contractually agreed outputs, whereas artifacts are the architectural work products such as catalogues, matrices and diagrams that populate them. Reversing the two definitions or treating them as the same thing is incorrect.

An ABB captures what a capability must do in vendor-neutral terms, while an SBB is the concrete product or implementation that realises it. The other options reverse these roles or treat the two terms as synonyms, which contradicts how the content framework defines them.

The Enterprise Continuum organises reusable architecture assets from generic foundation levels through industry and organisation-specific levels. The capability model, portfolio catalogue and requirements specification are individual artifacts rather than a classification of reusable assets.

Gap analysis compares baseline and target architectures to identify missing or partial elements that need work packages. Business scenarios elicit requirements, architecture partitioning divides the architecture into segments, and interoperability requirements specify how systems must work together.

TOGAF principles are documented with a name, statement, rationale and implications so they can be applied consistently and understood by stakeholders. The other options are wrong because principles are enterprise-level rules that are reviewed and maintained, not server settings or optional advice.

Architecture patterns are reusable templates that describe a recurring problem, a proven solution and the context in which it applies. Stakeholder maps, value chains and capability maps are useful techniques but do not provide reusable solution templates.

In a TOGAF gap analysis, baseline elements with no match in the target are eliminated, and the architect must check whether that was intended or an oversight. Target elements with no baseline match are new, and elements present in both are included.

A stakeholder with high power and low interest should be kept satisfied with concise, summary-level communication. The other quadrants misstate either this stakeholder's power or their interest in technical detail.

Stakeholder concerns drive the choice of architecture views and viewpoints, so each stakeholder's needs are covered by the architecture work. The other options misuse the concern register for funding, training or exclusion, none of which is its purpose.

Each stakeholder concern is addressed by a view, and a viewpoint defines how that view is built for a particular audience. A single generic diagram, deferring the concerns, or treating them as Phase H changes would leave at least one stakeholder's concern unaddressed.

Stakeholders should be classified and their concerns recorded and mapped to views, and both activities continue through the ADM. Excluding low-power stakeholders, freezing the analysis after Phase A, or giving one budget holder sole authority are poor practices.

Phase B describes the target business architecture: the goals, organisation units, functions, processes and actors that support strategy. Data entities and interface protocols belong to Phase C, and server topology belongs to Phase D.

Phase C develops the data and application architectures, showing which data entities and application components support the business. Hardware and network choices belong to Phase D, business goals to Phase B, and schedules and budgets to Phases E and F.

Phase D describes the logical and physical platform services and the hardware, software and network components that support the applications. Capability maps and organisation units belong to Phase B, data entities to Phase C, and work packages to Phases E and F.

A logical data diagram is the Phase C artifact that shows data entities and their relationships without tying them to physical storage. The catalogue, stakeholder map and location diagram each address a different architecture concern.

Phase E identifies implementation options and decides whether an incremental approach with transition architectures is required. Phase F then sequences and costs the chosen approach, Phase G oversees delivery, and Phase H manages later changes.

Architecture contracts are joint agreements between sponsors and development partners on deliverables, quality and fitness for purpose, and they are used during Phase G. Principles, business scenarios and the Statement of Architecture Work are created earlier and do not formalise implementation obligations.

Phase H manages changes to the architecture after it is in use, through impact assessment, classification and recording of change requests. Phase G governs implementation while it is underway, and the Preliminary Phase sets up the framework rather than handling post-deployment changes.

The Architecture Vision is a high-level, aspirational view of the target that addresses stakeholder concerns and supports the decision to proceed. The Architecture Definition Document holds the detailed target architecture, while the gap analysis and migration plan come after the vision is approved.

The Architecture Vision gives a high-level view of the target state that addresses stakeholder concerns and supports approval to proceed. Detailed interface and schema specifications come in later phases, governance is a continuing practice that a vision does not replace, and cost-benefit analysis belongs to Phase F.

The Statement of Architecture Work defines the scope, approach, deliverables and schedule of the architecture project and is approved by the sponsor. The other options describe whole-agency content, later-phase transition work or solution-level building blocks rather than the agreed scope.