Certified Professional for Software Architecture – Foundation Level Free Sample Questions

The Strangler Fig pattern is the optimal choice as it allows for an incremental, risk-managed migration. It directly addresses the goals of improving time-to-market and fault isolation by creating independent services. It also respects the team's Java skills (new services can be in Java) while allowing them to learn containerization gradually. A big-bang rewrite is too risky, a lift-and-shift doesn't solve the core architectural problems, and a modular monolith improves code structure but not independent deployability or fault isolation as effectively.

Cross-cutting concerns are aspects of a system that affect multiple components. Distributed tracing, centralized logging, and security (authN/authZ) are classic examples that require a consistent, system-wide approach to be effective. Inconsistent implementation would render them useless. Business logic and database schemas are specific to the bounded context of an individual service and are not cross-cutting.

This statement is true. A core advantage of the Pipes and Filters pattern is the decoupling of individual processing steps (filters). Because each filter only depends on the input data format and produces an output in the agreed-upon format, they can be developed, deployed, and tested independently, which enhances modularity and maintainability.

The Open/Closed Principle states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. This directly addresses the requirement to add new functionality without changing the existing, core code, thus avoiding complex conditional logic. Patterns like Strategy or Decorator are common implementations of OCP.

The Dependency Inversion Principle states that high-level modules should not depend on low-level modules; both should depend on abstractions. By changing UserService (high-level) to depend on ILogger (abstraction) instead of PostgreSQL_Logger (low-level), the architect is directly applying DIP. This decouples the services from the concrete logging implementation, making the system more flexible and easier to test.

The Context View is specifically designed to show the system as a 'black box' within its environment. It focuses on defining the system's scope and its relationships with external actors and systems, making it the ideal view for providing a high-level overview to a broad audience without delving into internal implementation details.

A well-formed ADR must capture the 'why' behind a decision. This includes the 'Context' (the problem, constraints, and requirements) and the 'Consequences' (the resulting trade-offs, benefits, and drawbacks). This information is crucial for future architects and developers to understand the rationale and avoid re-litigating past decisions. Implementation code and developer names are not core components of an ADR's purpose.

Qualitative analysis, especially for a quality like modifiability, relies on structured reasoning rather than purely quantitative metrics. Quality scenarios provide concrete, hypothetical changes (e.g., 'A change to the tax calculation algorithm should be deployable within one day and affect only one component'). Analyzing the architecture's ability to handle these scenarios is a primary method for assessing modifiability. Server logs relate to performance, and support tickets relate more to usability or reliability.

Architectural goals (the 'ilities' like scalability, maintainability) focus on the long-term health and viability of the system. Project goals (time, scope, budget) are often short-term and tactical. A key responsibility of an architect is to manage the tension between these two. For instance, achieving high scalability might require more time, directly conflicting with an aggressive launch date. This necessitates trade-offs and clear communication with stakeholders.

The Pipes and Filters pattern is ideal for processing streams of data where the processing can be broken down into a series of sequential, independent steps (filters). The data flows through channels (pipes). This pattern provides excellent decoupling between the steps, meeting the architect's requirement to reorder or replace them easily. MVC is for UI, Broker is for distributed component communication, and Layered is for separation of concerns in a more general application structure.