I85PREP
⌘ K
iSAQB CPSA Foundation Level study materials
iSAQB CPSA Foundation Level study resources

iSAQB CPSA Foundation Level practice questions

One question at a time. Build your iSAQB CPSA Foundation Level understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Basics of software architecture, role and task of software architects

In iSAQB terminology, which statement best describes the relationship between a software architecture and the system it describes?

  1. The architecture is the user manual describing how end users operate the finished product.
  2. The architecture is the project plan that lists milestones and staffing for the build.
  3. The architecture is the set of design decisions and structures needed to reason about the system, not the source code itself. Correct answer.
  4. The architecture is identical to the complete source code once all modules are compiled.

Explanation

Software architecture captures the fundamental structures and the design decisions behind a system, giving a basis for reasoning about quality attributes and change. It is an abstraction over the implementation, so it is not the same as the code, the project plan, or the user documentation.

Question 2Basics of software architecture, role and task of software architects

Which pair of elements is central to the iSAQB view of architectural description?

  1. Building blocks and their relationships, together with the principles guiding them Correct answer.
  2. Sprint velocity and burndown charts
  3. Licensing costs and vendor support contracts
  4. Database normalization forms and index types

Explanation

Architecture description centers on building blocks (components, modules, subsystems), the relationships among them, and the principles and decisions that shape them. This structure is what allows stakeholders to understand and evaluate the system.

Question 3Basics of software architecture, role and task of software architects

A stakeholder asks an architect to explain why a particular technology was chosen for a subsystem. Which architect responsibility does this primarily illustrate?

  1. Estimating the marketing budget for the next release
  2. Writing unit tests for the subsystem's classes
  3. Justifying and communicating design decisions to stakeholders Correct answer.
  4. Configuring the continuous integration build server

Explanation

Architects own and must be able to explain significant design decisions, including technology choices, to the people affected by them. Communication and justification of decisions is a core part of the role, distinct from hands-on coding or operational tasks.

Question 4Basics of software architecture, role and task of software architects

Which activity belongs to the software architect's task set rather than to classic project management?

  1. Tracking the team's daily task assignments in a backlog
  2. Reporting budget consumption to the steering committee
  3. Defining the system's decomposition into subsystems and their interfaces Correct answer.
  4. Negotiating the contract with the external customer

Explanation

Decomposition into subsystems and the definition of their interfaces is a distinctly architectural task that shapes the system's structure. The other options are project-management or commercial responsibilities.

Question 5Basics of software architecture, role and task of software architects

What does the term 'architecture stakeholder' mean in the iSAQB context?

  1. Only the external auditor who certifies the release
  2. Only the architect who owns the architecture document
  3. Only the developers who write the source code
  4. Any person or group with an interest in the system and its qualities Correct answer.

Explanation

A stakeholder is anyone with a legitimate interest in the system, such as users, operators, developers, managers, or auditors. Restricting the term to a single role misses the breadth that drives architectural trade-offs.

Question 6Basics of software architecture, role and task of software architects

Which statement best captures why architecture is considered important for a long-lived system?

  1. It provides the structure that makes quality attributes and later changes manageable. Correct answer.
  2. It guarantees that no defects will ever reach production.
  3. It removes the need for requirements analysis in later iterations.
  4. It fixes the implementation so that no future change is possible.

Explanation

Architecture matters because it encodes the structures that enable or hinder quality attributes such as maintainability, performance, and modifiability over the system's life. It does not eliminate defects or requirements work, nor does it freeze change; good architecture supports evolution.

Question 7Basics of software architecture, role and task of software architects

An architect documents a design decision together with the alternatives considered and the rationale. Which benefit does this practice mainly provide?

  1. It makes the reasoning traceable for future maintainers and reviewers. Correct answer.
  2. It ensures the chosen option is always technically the best one.
  3. It replaces the need for any architecture documentation of structures.
  4. It shortens the source code by removing the need for comments.

Explanation

Recording decisions with alternatives and rationale creates traceability, so later team members can understand why the system is shaped as it is. It complements structural documentation rather than replacing it, and it does not guarantee the choice was optimal.

Question 8Basics of software architecture, role and task of software architects

Which of the following best describes the architect's responsibility toward non-functional requirements?

  1. Delegating all quality concerns to the testing team after coding is complete
  2. Treating them as optional extras that only matter for marketing
  3. Eliciting and prioritizing quality requirements and shaping the architecture to satisfy them Correct answer.
  4. Converting them into functional user stories and nothing else

Explanation

Quality (non-functional) requirements drive architectural decisions, so architects must elicit, clarify, and prioritize them and design structures that meet them. They cannot be deferred to testing or reduced to purely functional stories.

Question 9Basics of software architecture, role and task of software architects

A team must decide whether to split a monolithic module into two services. Which architect contribution is most appropriate at this point?

  1. Assign the decision to the newest team member without discussion.
  2. Postpone the question until after the release without recording it.
  3. Immediately write the deployment scripts for both services.
  4. Evaluate the trade-offs against quality goals and document the resulting decision. Correct answer.

Explanation

Structural decisions like splitting modules should be evaluated against the system's quality goals and recorded with their rationale. This is the architect's analytical contribution, distinct from immediately implementing deployment mechanics or deferring the choice.

Question 10Basics of software architecture, role and task of software architects

Which statement about the relationship between architecture and the development organization is most accurate?

  1. Architecture and team structure influence each other, so organizational constraints should inform decomposition. Correct answer.
  2. Architecture must always mirror the current org chart exactly, whatever the quality goals.
  3. Team structure is irrelevant to architecture and should be ignored entirely.
  4. Organizational constraints only matter after the system is decommissioned.

Explanation

Decomposition and team boundaries interact: the architecture constrains how teams can work, and existing team structures constrain feasible decompositions. Architects should therefore consider organizational context as one input among several, not ignore it or copy it blindly.

Question 11Basics of software architecture, role and task of software architects

An architect is asked to review a colleague's design. Which approach best reflects sound architectural review practice?

  1. Check the design against the stated quality goals and stakeholder concerns, and record findings. Correct answer.
  2. Focus only on code formatting and naming conventions.
  3. Rewrite the design personally without discussing it with the author.
  4. Approve the design quickly to avoid delaying the schedule.

Explanation

An architectural review assesses whether the design addresses the quality goals and stakeholder concerns, and it produces documented findings. Speed-approval, unilateral rewriting, or cosmetic focus all miss the purpose of evaluating architectural fitness.

Question 12Basics of software architecture, role and task of software architects

Which description best matches the concept of an architecture view?

  1. A screenshot of the running application's user interface
  2. A representation that highlights the structures relevant to a particular set of concerns Correct answer.
  3. A complete copy of the source repository at release time
  4. A list of every bug currently open in the tracker

Explanation

An architecture view selects and presents the structures relevant to specific concerns, such as runtime behavior or deployment, so different stakeholders can reason about the system. It is not a UI screenshot, a code snapshot, or a defect list.

Question 13Basics of software architecture, role and task of software architects

A stakeholder raises a concern about how the system behaves under peak load. Which architect action best addresses this?

  1. Identify the relevant runtime structures and evaluate them against the performance quality goal. Correct answer.
  2. Add the concern to the backlog and close the discussion.
  3. Ask the stakeholder to write the performance code themselves.
  4. Assume the concern is out of scope because it is non-functional.

Explanation

Performance under load is a quality attribute that maps to runtime structures the architect must analyze and design for. Dismissing it as out of scope or purely delegating it ignores the architect's responsibility for quality-driven design.

Question 14Basics of software architecture, role and task of software architects

What is the main purpose of documenting architectural constraints in an architecture description?

  1. To list the personal preferences of the architect for coding style
  2. To replace the requirements specification entirely
  3. To record the vacation schedule of the development team
  4. To make explicit the boundary conditions that limit design freedom and must be respected Correct answer.

Explanation

Constraints such as mandated technologies, regulations, or legacy interfaces limit the solution space, and documenting them makes these boundary conditions transparent for all involved. They are not personal style preferences, schedules, or a substitute for requirements.

Question 15Basics of software architecture, role and task of software architects

Which statement best characterizes the architect's role in an agile team?

  1. The architect has no role because agile teams do not need architecture.
  2. The architect produces one complete up-front design and then leaves the team alone.
  3. The architect collaborates continuously with the team and evolves the architecture incrementally. Correct answer.
  4. The architect only reviews code style during sprint reviews.

Explanation

In agile settings the architect stays engaged, collaborates with developers, and lets the architecture emerge and evolve through increments while safeguarding quality goals. Neither a one-shot up-front design nor the absence of architecture matches good practice.

Question 16Basics of software architecture, role and task of software architects

An architect must communicate the architecture to both business managers and developers. Which approach is most effective?

  1. Avoid documentation and rely on verbal explanations only.
  2. Give everyone the same low-level class diagram to ensure uniformity.
  3. Use audience-appropriate views and language, keeping the underlying model consistent. Correct answer.
  4. Present only to managers and skip communication with developers.

Explanation

Different stakeholders need different views and vocabulary, but these views should remain consistent with one shared architectural model. Tailoring communication improves understanding without fragmenting the design.

Question 17Basics of software architecture, role and task of software architects

Which of the following is the clearest example of an architectural decision rather than a routine implementation detail?

  1. Adjusting the indentation of a source file
  2. Choosing the overall communication style between major subsystems Correct answer.
  3. Renaming a local variable inside a helper method
  4. Adding a log statement to a single function

Explanation

Decisions about how major subsystems communicate shape structure and quality attributes, making them architectural. Local renaming, indentation, and single-function logging are implementation details with negligible structural impact.

Question 18Basics of software architecture, role and task of software architects

What does it mean that architecture serves as a means of communication among stakeholders?

  1. It guarantees that all stakeholders will agree on every requirement.
  2. It hides design information from stakeholders to avoid conflict.
  3. It replaces the need for any meetings during the project.
  4. It provides a shared reference that lets diverse stakeholders discuss and align on the system. Correct answer.

Explanation

A documented architecture gives stakeholders a common reference point for discussion, negotiation, and alignment about the system. It supports communication but cannot guarantee agreement, replace all meetings, or justify hiding information.

Question 19Basics of software architecture, role and task of software architects

An architect notices that a proposed design meets functional requirements but makes future feature additions costly. Which quality attribute is most directly at risk?

  1. Functional correctness
  2. Data integrity
  3. Regulatory compliance
  4. Modifiability Correct answer.

Explanation

Modifiability concerns the cost and effort of changing a system, so a design that makes future features expensive directly harms it. Functional correctness may still hold, and compliance and data integrity are separate concerns not implied by the scenario.

Question 20Basics of software architecture, role and task of software architects

Two designs satisfy the same quality goals, but one concentrates many responsibilities in a single component. Why might the architect still prefer the more distributed design?

  1. Distributed designs are always cheaper to operate than monolithic ones.
  2. Separation of concerns can reduce coupling and limit the blast radius of future changes. Correct answer.
  3. The number of components is itself the primary quality goal.
  4. Concentration always improves performance regardless of context.

Explanation

Separating responsibilities tends to lower coupling and localize change, which supports modifiability and limits the impact of faults. Neither concentration nor distribution is universally better, and component count is not a goal in itself.

Question 21Basics of software architecture, role and task of software architects

A stakeholder demands a technology that conflicts with the project's stated portability goal. What is the most professional architect response?

  1. Accept the demand and quietly drop the portability goal.
  2. Silently reject the demand because architecture goals are absolute.
  3. Make the trade-off explicit, document it, and let accountable stakeholders decide with full information. Correct answer.
  4. Escalate immediately without first clarifying the conflict.

Explanation

Architects surface conflicts between stakeholder demands and quality goals, document the trade-off, and support an informed decision by the accountable parties. Silently overriding or covertly abandoning a goal hides the conflict, and escalating before clarifying it wastes the decision forum.

Question 22Basics of software architecture, role and task of software architects

Why is an architecture that is never documented still a problem even if the team currently understands it?

  1. The absence of documentation automatically violates data-protection law.
  2. An undocumented architecture cannot compile or be deployed.
  3. Undocumented knowledge is lost as the team changes, making later evolution risky and costly. Correct answer.
  4. Documentation is required only to satisfy auditors, not for engineering reasons.

Explanation

Architectural knowledge held only in people's heads erodes as team members leave or forget, raising the risk and cost of future change. Documentation supports evolution and onboarding; it is not merely an audit formality, and its absence does not prevent compilation or automatically breach law.

Question 23Basics of software architecture, role and task of software architects

An architect is choosing between two candidate architectures for a system with strict availability goals. Which reasoning is most sound?

  1. Choose the design with the most components, since more parts mean more availability.
  2. Defer the choice to the vendor with the largest market share.
  3. Compare how each design handles failures and recovery, and weigh that against cost and complexity. Correct answer.
  4. Choose the design the architect personally finds most elegant.

Explanation

Availability is achieved through explicit failure handling and recovery mechanisms, so the architect should compare candidate designs on those mechanisms while weighing cost and complexity. Component count, personal taste, or vendor size are not sound bases for the decision.

Question 24Basics of software architecture, role and task of software architects

Which statement about architecture and requirements is most consistent with iSAQB thinking?

  1. Architecture is independent of requirements and can be designed in isolation.
  2. Requirements are irrelevant once the first architecture draft exists.
  3. Architecture both derives from requirements and helps refine and negotiate them. Correct answer.
  4. Requirements must be fully frozen before any architectural thinking begins.

Explanation

Architecture is driven by requirements, especially quality requirements, but the design process also uncovers ambiguities and trade-offs that feed back into refining and negotiating requirements. Treating requirements as frozen, irrelevant, or separable from architecture misrepresents this interplay.

Question 25Basics of software architecture, role and task of software architects

What distinguishes an architect's responsibility for interfaces from a developer's responsibility for method signatures?

  1. Architects define interfaces between major building blocks, shaping contracts across subsystems and teams. Correct answer.
  2. Architects only name interfaces and leave all semantics to chance.
  3. Architects have no interface responsibility at all.
  4. Architects define every private method signature in each class.

Explanation

Architectural interface responsibility concerns the contracts between major building blocks and the teams that own them, which strongly influences integration and quality. Private method signatures are implementation-level, and merely naming interfaces without semantics is insufficient.

Question 26Basics of software architecture, role and task of software architects

In iSAQB terminology, which pair correctly distinguishes the architect's structural responsibility from the developer's coding responsibility?

  1. The architect writes the most complex classes, while developers write the simpler classes and tests.
  2. The architect approves every pull request, while developers decide the module boundaries themselves.
  3. The architect owns the build pipeline configuration, while developers own all source files including interfaces.
  4. The architect defines cross-component interfaces and their quality-relevant contracts, while developers implement the internal logic behind those interfaces. Correct answer.

Explanation

Architecture work assigns responsibility at the level of components, interfaces and their contracts, including quality attributes such as performance or security expectations at the boundary. Developers then realize the internal design and code behind those interfaces. The division is about abstraction level and scope of impact, not about who writes more or harder code.

Question 27Basics of software architecture, role and task of software architects

A candidate for an architecture role is described as needing to balance conflicting stakeholder interests. Which architect task does this description most directly reflect?

  1. Writing end-user documentation for the released product.
  2. Selecting the IDE and code formatting rules for the team.
  3. Optimizing the algorithm complexity of the core domain classes.
  4. Mediating between stakeholders and negotiating trade-offs among competing quality goals. Correct answer.

Explanation

Architects work at the intersection of technical and business concerns, so they must elicit stakeholder concerns and negotiate trade-offs when goals conflict, for example availability versus cost. This mediation is a defining part of the role, distinct from detailed coding or tooling decisions. Resolving conflicts transparently is what makes architecture decisions durable.

Question 28Basics of software architecture, role and task of software architects

Which statement best describes the relationship between architecture and the software development process used by a team?

  1. Architecture is only relevant for plan-driven processes and has no role in iterative or agile processes.
  2. Architecture must be produced in a single up-front phase before any process can begin.
  3. Architecture work is compatible with iterative processes, where it is typically evolved incrementally rather than fixed once at the start. Correct answer.
  4. Architecture and process are independent, so the choice of process never influences how architecture is created or evolved.

Explanation

iSAQB treats architecture as an ongoing activity that can be performed iteratively, with decisions taken when they are needed and revisited as knowledge grows. A big up-front phase is one option, not a requirement, and architecture does not disappear in agile settings. The process shapes how much architecture is done when, but both coexist.

Question 29Basics of software architecture, role and task of software architects

Which of the following is the best example of an architecture task rather than a project-management task?

  1. Deciding the deployment topology and the runtime distribution of components across nodes. Correct answer.
  2. Scheduling the release date with the product owner.
  3. Assigning developers to work items in the backlog.
  4. Estimating the team's velocity for the next sprint.

Explanation

Deployment topology and the distribution of components across runtime nodes are structural, quality-relevant decisions that belong to architecture. They determine properties such as scalability, fault tolerance and operational cost. The other options concern planning, staffing and scheduling, which are project-management responsibilities.

Question 30Basics of software architecture, role and task of software architects

An architect joins a project where the team already has a working system but no written architecture. Which first step best fits the architect's role?

  1. Replace the team's conventions with the architect's personal coding standards.
  2. Ask the team to stop feature work until a complete architecture document exists.
  3. Immediately rewrite the system according to a preferred reference architecture.
  4. Reconstruct the existing architecture from code, deployment artifacts and team interviews, then document it and its known risks. Correct answer.

Explanation

When a system already exists, the architect must first understand the as-is structure and its quality-relevant properties before proposing changes. Reconstructing the architecture from artifacts and stakeholder input makes implicit decisions explicit and reveals risks. Only then can targeted improvements be planned and justified.

Question 31Basics of software architecture, role and task of software architects

A product owner asks the architect to guarantee that the system will handle ten times the current load. What is the most appropriate architect response?

  1. Refuse the request because scalability cannot be addressed architecturally.
  2. Promise the guarantee verbally so the product owner can proceed with marketing.
  3. Clarify the load scenario and quality goals, then evaluate candidate designs against measurable criteria such as response time and cost. Correct answer.
  4. Delegate the question entirely to the operations team without further analysis.

Explanation

Quality goals must be made concrete and measurable before a design can be judged against them, and scalability claims require analysis of scenarios and trade-offs. The architect translates a vague demand into testable quality requirements and evaluates options. Guarantees without evidence would be unfounded.

Question 32Basics of software architecture, role and task of software architects

During a design discussion, a developer proposes putting business rules directly into the UI layer because it is faster to implement. Which architect contribution is most appropriate?

  1. Reject the idea without discussion because layering is always mandatory.
  2. Accept the proposal silently because implementation speed is the only relevant criterion.
  3. Explain the quality consequences, such as testability and portability, and propose a structure that isolates the rules. Correct answer.
  4. Escalate to management to have the developer removed from the project.

Explanation

The architect's contribution is to make the structural consequences of a choice visible, linking it to quality attributes such as testability, maintainability and portability. Proposing an isolating structure gives the team a concrete alternative rather than a bare prohibition. This keeps the discussion evidence-based and preserves team ownership.

Question 33Basics of software architecture, role and task of software architects

An architect must justify a decision to use asynchronous messaging between two components. Which argument is most consistent with architecture reasoning?

  1. Asynchronous messaging is newer than synchronous calls, so it should be preferred.
  2. The decision removes the need for any interface documentation between the components.
  3. The decision guarantees that no messages will ever be lost.
  4. The decision improves decoupling and resilience under partial failure, at the cost of increased complexity in consistency and error handling. Correct answer.

Explanation

Architecture reasoning weighs benefits against costs for explicit quality goals. Asynchronous messaging can improve decoupling and resilience but introduces complexity around consistency, ordering and error handling, which must be acknowledged. A balanced trade-off statement is what makes the decision defensible.

Question 34Basics of software architecture, role and task of software architects

What is the primary reason an architect should identify stakeholders early in a project?

  1. To ensure their concerns and quality expectations are elicited and reflected in the architecture. Correct answer.
  2. To limit the number of people who can influence the design.
  3. To assign blame if the project later fails.
  4. To decide which stakeholders will be excluded from reviews.

Explanation

Stakeholders hold the concerns that architecture must satisfy, such as security, operability or regulatory compliance. Identifying them early lets the architect elicit these concerns and incorporate them into quality goals and design decisions. Stakeholder analysis is about coverage of concerns, not about restricting participation.

Question 35Basics of software architecture, role and task of software architects

A team asks whether the architect should decide the internal structure of a single class. Which answer best reflects the division of responsibilities?

  1. No, because internal class structure is a local design decision that developers can own within the architectural constraints. Correct answer.
  2. Yes, because class structure always determines system-wide quality attributes.
  3. Yes, because architects must approve every design detail to keep the system consistent.
  4. No, because architects are not allowed to read source code.

Explanation

Architecture sets boundaries and constraints, while local design inside a component is delegated to developers. This delegation keeps the architect's attention on system-wide concerns and respects developer expertise. Architects may still review code, but they do not need to dictate every internal detail.

Question 36Basics of software architecture, role and task of software architects

An architect is preparing to present the architecture to a group of operations engineers. Which preparation is most appropriate?

  1. Avoid discussing constraints so the presentation stays positive.
  2. Present only the class diagrams, since they contain the most detail.
  3. Focus on the deployment view, runtime behavior, monitoring and failure handling relevant to operations. Correct answer.
  4. Use the same slide deck that was prepared for the sales team to save time.

Explanation

Communication should be tailored to the audience's concerns. Operations engineers care about deployment, runtime behavior, monitoring and failure handling, which the deployment and runtime views address. Reusing a deck aimed at another audience would miss those concerns.

Question 37Basics of software architecture, role and task of software architects

Why does iSAQB emphasize architecture knowledge exchange and continuing education for architects?

  1. Because only architects with formal degrees can make valid design decisions.
  2. Because architecture is a static body of knowledge that does not change over time.
  3. Because architecture certification replaces the need for practical project experience.
  4. Because technology, methods and quality expectations evolve, so architects must keep their knowledge and judgment current. Correct answer.

Explanation

Architecture practice is shaped by changing technologies, methods and business expectations, so architects need ongoing learning and exchange with peers. Shared terminology and training improve communication within teams and across projects. Certification documents baseline knowledge but does not substitute for experience.

Question 38Basics of software architecture, role and task of software architects

A legacy system must keep running while a new system is built alongside it, with a gradual migration of users. Which architect responsibility does this scenario most clearly illustrate?

  1. Ensuring the migration path, coexistence of old and new components, and data consistency are designed as part of the target architecture. Correct answer.
  2. Negotiating the salaries of the new development team.
  3. Choosing the programming language for the new system's utility scripts.
  4. Writing the user-acceptance test cases for the new features.

Explanation

Migration architecture must address coexistence, intermediate states, data synchronization and cutover, because these determine risk and quality during the transition. This is a structural concern spanning both systems, not a local implementation detail. Ignoring it typically causes the migration to fail despite a sound target design.

Question 39Basics of software architecture, role and task of software architects

An architect documents a design using a context diagram, a building-block view and a runtime view. What is the main justification for using several such views?

  1. Using several views reduces the total documentation effort compared with one view.
  2. Each view addresses different stakeholder concerns, and together they make the architecture understandable from several perspectives. Correct answer.
  3. Multiple views are required because a single view cannot be understood by any stakeholder.
  4. Views exist to satisfy documentation templates, regardless of the questions they answer.

Explanation

Architecture descriptions use views because different stakeholders ask different questions: context, static structure and runtime behavior cannot be shown well in one diagram. Each view highlights specific aspects while abstracting others, and their combination conveys the whole. The choice of views should follow the concerns to be addressed, not a template.

Question 40Basics of software architecture, role and task of software architects

Two architects disagree about whether a shared database between two services is acceptable. Which approach best reflects professional architecture practice?

  1. Let the more senior architect decide without discussion to save time.
  2. Adopt the option that requires the fewest changes to existing code.
  3. Avoid the topic by letting each team choose independently without coordination.
  4. Make the coupling and consistency consequences explicit, relate them to the system's quality goals, and record the resulting decision with its rationale. Correct answer.

Explanation

Professional practice resolves design disputes by making consequences explicit and tying them to agreed quality goals, then documenting the decision and its rationale for later review. This produces a traceable, revisitable decision rather than an arbitrary outcome. Coupling and data consistency are the key trade-offs in a shared-database question.

Question 41Description and communication of software architectures

Which view in the iSAQB architecture description approach addresses how the system is structured into modules and what responsibilities each module carries?

  1. The runtime view
  2. The deployment view
  3. The context view
  4. The building-block view Correct answer.

Explanation

The building-block view describes the static decomposition of the system into modules, subsystems and components together with their responsibilities and interfaces. The runtime view covers behaviour and interactions, the deployment view covers mapping to infrastructure, and the context view delimits the system from its environment.

Question 42Description and communication of software architectures

A team must explain to non-technical stakeholders why a new payment service cannot simply be embedded into the existing monolith. Which communication artefact is most appropriate?

  1. A context diagram showing the system boundary, external partners and the direction of data flow Correct answer.
  2. A sequence diagram of every internal method call
  3. A detailed class diagram of the payment domain model
  4. A database schema with all foreign key constraints

Explanation

Stakeholders outside engineering need a reduced abstraction that shows the boundary of the system and its external relationships, which is exactly what a context diagram provides. Class diagrams, full sequence diagrams and schemas are implementation-level artefacts that overload non-technical audiences with detail they cannot act on.

Question 43Description and communication of software architectures

In the iSAQB terminology, what distinguishes an architecture view from an architecture perspective?

  1. A view is a concrete representation of the system for specific concerns, while a perspective is a cross-cutting quality lens applied across views Correct answer.
  2. A view is mandatory in every architecture document, while a perspective is optional decoration
  3. A view is written for managers, while a perspective is written for developers
  4. A view documents only runtime behaviour, while a perspective documents only static structure

Explanation

Views partition the description by structural or behavioural concern such as building blocks, runtime and deployment. Perspectives such as security, performance or maintainability cut across those views and are applied to them, so the two concepts are orthogonal rather than hierarchical.

Question 44Description and communication of software architectures

Which statement best describes the purpose of an Architecture Decision Record (ADR) in architecture communication?

  1. It captures a decision, the context that made it necessary, the alternatives considered and the consequences Correct answer.
  2. It records the meeting minutes of the architecture review board
  3. It lists every source file that belongs to a component
  4. It specifies the coding style rules for the development team

Explanation

An ADR preserves the reasoning behind an architecturally significant decision so that later readers understand why a design looks the way it does. Recording context, options and consequences is what makes the decision traceable and revisable when circumstances change.

Question 45Description and communication of software architectures

Which diagram type is best suited to show the dynamic interaction of several components over time, including the order of messages?

  1. A sequence diagram Correct answer.
  2. A deployment diagram
  3. A class diagram
  4. A context diagram

Explanation

A sequence diagram has a time axis and lifelines for participants, so it can express the ordering of messages between components. Context, deployment and class diagrams are static and cannot express message ordering.

Question 46Description and communication of software architectures

An architect writes a document that references a diagram stored only on a personal laptop. Which quality principle of architecture documentation is violated?

  1. Accessibility and traceability of the documented artefacts Correct answer.
  2. Conformance to the reference architecture
  3. Completeness of the runtime view
  4. Consistency of the modelling notation

Explanation

Architecture documentation must be discoverable and traceable for all intended readers, which requires artefacts to live in a shared, versioned location. A diagram held on a private device cannot be reviewed, referenced or maintained by the team.

Question 47Description and communication of software architectures

Which of the following best characterises the role of architecture communication towards the customer?

  1. Withholding quality risks until the implementation is complete
  2. Presenting the complete source-code structure for approval
  3. Explaining the solution structure and its quality trade-offs in terms the customer can relate to business goals Correct answer.
  4. Transferring all design decisions to the customer for voting

Explanation

Customer-facing architecture communication translates technical structure and trade-offs into business-relevant terms so the customer can validate that the solution meets their goals. It is not a code review, a democratic decision process, or a delay tactic for risks.

Question 48Description and communication of software architectures

Which element belongs in the context view of a system according to common architecture description practice?

  1. Internal classes of the persistence layer
  2. The sprint backlog of the delivery team
  3. The heap-size settings of the application server
  4. External systems and actors that exchange information with the system under consideration Correct answer.

Explanation

The context view delimits the system under consideration and identifies the external actors, systems and interfaces it interacts with. Internal classes, runtime tuning parameters and project planning artefacts belong to other views or to project management.

Question 49Description and communication of software architectures

You must convey the static module structure of a large system to developers who will implement against it. Which combination of content is most appropriate?

  1. A list of all open bug tickets with priorities
  2. Building blocks with their responsibilities and the interfaces they provide and require Correct answer.
  3. The release calendar for the next four quarters
  4. A capacity plan for the production database

Explanation

Developers need the decomposition into building blocks, the responsibility of each block and the provided and required interfaces, because that is what they implement against. Tickets, capacity plans and release calendars are project artefacts, not architecture description.

Question 50Description and communication of software architectures

A colleague argues that one single diagram should serve developers, operators and management at once. What is the strongest architectural counter-argument?

  1. Developers cannot read diagrams that contain more than five boxes
  2. Operators and management legally require identical documentation
  3. A single diagram is always cheaper to maintain and therefore preferable
  4. Different stakeholders have different concerns and levels of abstraction, so one diagram either overloads or underinforms most of them Correct answer.

Explanation

Architecture communication must be tailored to stakeholder concerns and their ability to absorb detail, which is why multiple views and abstraction levels exist. A single diagram cannot simultaneously satisfy implementation needs and management-level abstraction without becoming either overloaded or too vague.