I85PREP
⌘ K
OutSystems Architecture Specialist (O11) study materials
OutSystems Architecture Specialist (O11) study resources

OutSystems Architecture Specialist (O11) practice questions

One question at a time. Build your OutSystems Architecture Specialist (O11) 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 1OutSystems Architecture design fundamentals

In an OutSystems architecture, what is the primary purpose of a module that is classified as a Library module?

  1. To store the deployment configuration for a given environment
  2. To host end-user screens and expose them through a public URL
  3. To act as the entry point for a mobile app build
  4. To expose reusable logic and actions that other modules can consume without a user interface Correct answer.

Explanation

Library modules package reusable server-side logic, actions, and entities that other modules reference, and they contain no user interface. They are the standard mechanism for sharing behavior across an application without duplicating code. Screen-bearing modules are a different module type.

Question 2OutSystems Architecture design fundamentals

Which OutSystems module type is designed to expose screens and logic to end users and can be deployed independently?

  1. Reactive or Traditional web module Correct answer.
  2. Library module
  3. Extension module
  4. Service module

Explanation

Web and mobile application modules (Reactive or Traditional) contain screens, client actions, and are deployable units that end users interact with. Extension modules integrate external .NET code, and service modules expose APIs rather than end-user screens.

Question 3OutSystems Architecture design fundamentals

An architect needs to share a single set of reference data across several applications in the same environment. Which approach best follows OutSystems architecture guidance?

  1. Replicate the reference data in each application's own entities
  2. Hardcode the reference values inside each screen's preparation
  3. Store the data in session variables populated at login
  4. Place the shared entities in a dedicated library or core module referenced by the consuming modules Correct answer.

Explanation

Shared reference data should live in one owning module (often a core or library module) that other modules reference, keeping a single source of truth. Duplicating or hardcoding the data creates drift and maintenance cost. Session variables are per-user runtime state, not a data store.

Question 4OutSystems Architecture design fundamentals

What is the main architectural reason to separate an application into multiple modules rather than one large module?

  1. It enforces modularity, limits dependency scope, and allows independent deployment of reusable parts Correct answer.
  2. It removes the need for any testing before deployment
  3. It automatically improves database query performance
  4. It reduces the total number of entities that can be created

Explanation

Splitting into modules enforces clear boundaries and dependency direction, supports reuse, and lets teams deploy independent units. It does not remove testing needs or automatically tune queries. Module count is not limited by this design choice.

Question 5OutSystems Architecture design fundamentals

In OutSystems, which dependency direction is considered correct between a UI module and a core module that owns shared entities?

  1. The core module references the UI module
  2. The UI module references the core module Correct answer.
  3. Both modules reference each other to share entities
  4. The core module references every UI module that uses it

Explanation

Dependency should flow from consumers toward shared providers: UI modules reference core modules, not the reverse. A core module that references UI modules would create circular, tightly coupled dependencies. Bidirectional references between these layers are an anti-pattern.

Question 6OutSystems Architecture design fundamentals

A team wants to expose business logic to external systems over HTTP. Which module type should they create?

  1. A Reactive web module
  2. An extension module
  3. A service module exposing a REST API Correct answer.
  4. A library module with public actions

Explanation

Service modules are the OutSystems construct for exposing REST or SOAP APIs to external consumers. Library modules share logic internally, while Reactive web modules target end-user screens. Extension modules integrate external code rather than exposing APIs by themselves.

Question 7OutSystems Architecture design fundamentals

When designing the data layer, why is it recommended to centralize entity ownership in a small number of core modules?

  1. It provides a single owner for each entity, simplifying change management and referential integrity Correct answer.
  2. It eliminates the need for entity relationships
  3. It guarantees that no two modules ever read the same entity
  4. It forces all screens into a single module

Explanation

Clear entity ownership means one module defines and manages each entity, so changes and integrity rules are applied in one place. Other modules reference the owner rather than redefining the entity. This does not remove relationships or merge all screens into one module.

Question 8OutSystems Architecture design fundamentals

What does the OutSystems architecture canvas primarily help a team do?

  1. Visualize and reason about the modules and their dependencies in a solution Correct answer.
  2. Configure LifeTime deployment plans
  3. Generate the database schema automatically
  4. Compile the application for a target device

Explanation

The architecture canvas is a modeling aid for representing modules and the dependencies between them, helping teams validate layering and identify problematic references. It does not generate schemas, compile apps, or manage deployment plans.

Question 9OutSystems Architecture design fundamentals

An architect classifies modules into layers such as orchestration, core, and foundation. What is the key rule these layers enforce?

  1. Any layer may reference any other layer as long as it compiles
  2. Layers exist only for documentation and have no dependency rules
  3. Lower layers must reference higher layers to reuse screens
  4. Higher layers may reference lower layers, but lower layers must not reference higher layers Correct answer.

Explanation

Layering constrains dependencies so that orchestration modules may consume core and foundation modules, while lower layers stay independent of higher ones. This prevents upward and circular references that undermine reuse. Layers are meaningful dependency constraints, not just labels.

Question 10OutSystems Architecture design fundamentals

Which situation best justifies creating a separate library module instead of adding the logic directly to the application module?

  1. The logic is reusable across multiple modules or applications Correct answer.
  2. The logic needs to display a screen to the user
  3. The logic is used by only one screen and will never change
  4. The logic requires a new database table with no other consumers

Explanation

A library is justified when logic must be reused by several modules or applications, providing one maintained implementation. Logic used in a single place is simpler to keep local. Screens belong in UI modules, and a single-consumer table does not by itself call for a library.

Question 11OutSystems Architecture design fundamentals

What is the recommended way for a Reactive web app and a mobile app to share the same server-side business rules?

  1. Place the rules in a shared library or core module that both apps reference Correct answer.
  2. Copy the server actions into both modules
  3. Duplicate the rules in each app's client actions
  4. Expose the rules only through screen preparation in each app

Explanation

Shared server-side rules belong in a referenced library or core module so both front ends consume one implementation. Copying or duplicating logic creates divergence and double maintenance. Client actions also cannot hold server-only logic securely.

Question 12OutSystems Architecture design fundamentals

An architect notices that a foundation module references an orchestration module. What is the most accurate assessment?

  1. This violates layering because a lower layer should not depend on a higher layer Correct answer.
  2. This is correct because foundation modules should drive orchestration
  3. This is required to share entities between the two modules
  4. This has no architectural impact as long as it compiles

Explanation

Foundation modules are the lowest layer and must remain independent of orchestration modules; referencing upward inverts the intended dependency flow. Such references reduce reuse and risk circular dependencies. Compilation success does not make the dependency acceptable.

Question 13OutSystems Architecture design fundamentals

Which module type is appropriate when a team must incorporate a third-party .NET library into an OutSystems application?

  1. Reactive web module
  2. Library module
  3. Extension module Correct answer.
  4. Service module

Explanation

Extension modules are built to wrap external .NET assemblies and expose their functionality to OutSystems modules. Service modules expose APIs, and Reactive web modules provide user interfaces. A plain library module cannot directly host arbitrary .NET code.

Question 14OutSystems Architecture design fundamentals

A solution has a core module referenced by many application modules. A developer proposes adding application-specific screen logic into that core module. What is the best architectural response?

  1. Accept it, because the core module is already referenced widely
  2. Accept it only if the logic is placed in a client action
  3. Reject it, because application-specific logic belongs in the consuming application module to keep the core reusable Correct answer.
  4. Reject it and instead duplicate the core module per application

Explanation

A widely referenced core module should remain generic and reusable; application-specific behavior belongs in the consuming module. Adding screen-specific logic to the core couples it to one application and harms reuse. Duplicating the core module would fragment ownership instead of solving the problem.

Question 15OutSystems Architecture design fundamentals

What is the primary benefit of defining a clear orchestration layer in an OutSystems architecture?

  1. It centralizes coordination of user flows and calls to core services while keeping core logic reusable Correct answer.
  2. It removes the requirement for library modules
  3. It stores all entities for the solution
  4. It replaces the need for a service module

Explanation

Orchestration modules coordinate screens, flows, and calls into core services, acting as the composition layer above reusable core logic. Entities are typically owned by core or foundation modules, not the orchestration layer. Orchestration complements rather than replaces services and libraries.

Question 16OutSystems Architecture design fundamentals

Which statement correctly describes the relationship between an application module and the library modules it consumes?

  1. The library modules are deployed only after the application module is deleted
  2. The application module references the library modules to use their public actions Correct answer.
  3. The library modules reference the application module to obtain its screens
  4. Both reference each other to exchange data

Explanation

Consumers reference providers: the application module references the library to consume its public actions, keeping the library independent and reusable. Libraries do not reference application screens. Mutual references create circular dependencies.

Question 17OutSystems Architecture design fundamentals

An architect must decide where to place a set of utility actions used by multiple core modules. Which placement best follows layering principles?

  1. In an extension module
  2. In the orchestration module so screens can call them directly
  3. In a foundation or shared library module that the core modules reference Correct answer.
  4. In each core module separately to avoid dependencies

Explanation

Common utilities belong in a lower-layer foundation or shared library module that core modules can reference without violating layering. Duplicating them per module causes drift, and placing them in orchestration would force core modules to depend upward. Extension modules are for external .NET code.

Question 18OutSystems Architecture design fundamentals

Which of the following best describes a service module's dependency behavior in a layered architecture?

  1. It must contain end-user screens
  2. It typically references core modules to expose their logic through APIs Correct answer.
  3. It must be referenced by core modules to function
  4. It cannot reference any other module

Explanation

Service modules commonly sit above core logic and reference core modules to expose business operations as APIs. Core modules must not reference service modules, and service modules do not contain end-user screens. They do depend on lower layers.

Question 19OutSystems Architecture design fundamentals

What risk does a circular dependency between two modules introduce in an OutSystems solution?

  1. Guaranteed improvement in runtime performance
  2. Automatic entity synchronization between the modules
  3. Tighter coupling and build or deployment problems that complicate reuse and change Correct answer.
  4. Faster deployment because both modules build together

Explanation

Circular dependencies couple modules tightly and can cause build or deployment issues while undermining reuse. They do not synchronize entities or improve performance. Breaking the cycle by extracting shared logic into a lower layer is the usual remedy.

Question 20OutSystems Architecture design fundamentals

An architect is choosing between one large application module and several modules split by responsibility. Which consideration most directly supports splitting?

  1. Splitting eliminates the need for a service module
  2. Splitting enables independent evolution and clearer ownership of each responsibility Correct answer.
  3. Splitting guarantees fewer total bugs
  4. Splitting removes the need for a data model

Explanation

Splitting by responsibility gives each module a clear owner and allows parts to evolve and deploy independently. It does not guarantee fewer bugs or remove the need for a data model. Service modules remain relevant for external API exposure.

Question 21OutSystems Architecture design fundamentals

A core module needs to notify an orchestration module when a business event occurs. Which design best respects layering?

  1. The core module exposes a public action or event that the orchestration module consumes Correct answer.
  2. The core module embeds the orchestration module's logic
  3. The core module writes directly into the orchestration module's screens
  4. The core module directly references the orchestration module and calls it

Explanation

To keep dependency direction correct, the lower-layer core module exposes public actions or events, and the higher orchestration layer consumes them. Directly referencing upward would invert layering. A core module cannot manipulate orchestration screens or embed their logic.

Question 22OutSystems Architecture design fundamentals

Which statement about library modules and service modules is accurate?

  1. A service module cannot reference other modules
  2. Both expose APIs to external systems
  3. A library shares logic internally, while a service module exposes APIs to external consumers Correct answer.
  4. A library module contains end-user screens

Explanation

Library modules distribute reusable logic to other internal modules, whereas service modules expose REST or SOAP APIs to external consumers. Libraries do not contain end-user screens, and service modules do reference lower-layer modules to reuse logic.

Question 23OutSystems Architecture design fundamentals

An architect wants to prevent a foundation module from being polluted with UI concerns. Which practice best achieves this?

  1. Keep the foundation module free of screens and UI logic, exposing only reusable server-side actions and entities Correct answer.
  2. Allow screens in the foundation module but hide them from users
  3. Reference the orchestration module from the foundation module
  4. Move all UI logic into the foundation module for centralization

Explanation

Foundation modules should hold reusable server-side logic and entities without UI elements, preserving their reusability across applications. Adding hidden screens or UI logic couples the layer to presentation concerns. Referencing orchestration would invert the dependency direction.

Question 24OutSystems Architecture design fundamentals

What is the main reason to avoid duplicating the same entity definition in multiple modules?

  1. OutSystems forbids more than one entity per solution
  2. Duplicated entities cannot have attributes
  3. Duplicated entities always fail to compile
  4. Multiple owners of the same data cause inconsistency and complicate change management Correct answer.

Explanation

When the same entity is defined in several modules, changes and integrity rules must be applied in multiple places, leading to inconsistency. A single owning module with references from consumers keeps one source of truth. Duplication is allowed technically but architecturally harmful.

Question 25OutSystems Architecture design fundamentals

A team is building a solution with a mobile front end and a web front end that share business rules and data. Which architecture best fits OutSystems guidance?

  1. Two independent solutions with duplicated rules and data
  2. Rules duplicated in each front end with a shared database only
  3. A single module containing all mobile and web screens plus rules
  4. Front-end modules referencing shared core modules that own the rules and entities Correct answer.

Explanation

Both front ends should reference shared core modules that own business rules and entities, keeping one implementation and a single data owner. Duplicating rules or cramming all screens into one module undermines reuse and maintainability. A shared database alone does not prevent logic duplication.

Question 26OutSystems Architecture design fundamentals

In the OutSystems architecture canvas, which element directly represents a distinct end-user experience such as a Reactive Web app or a mobile app?

  1. An end-user module placed in the User layer Correct answer.
  2. A shared extension module consumed by core modules
  3. A library module in the Foundation layer
  4. A server-side service module in the Core layer

Explanation

The architecture canvas separates concerns into layers, and the User layer holds the end-user modules that deliver screens and UI flows to a specific audience. Each distinct front end is modeled as its own end-user module so it can evolve independently. Service, library, and extension modules belong to lower layers that the user modules consume.

Question 27OutSystems Architecture design fundamentals

A module exposes reusable server actions that several end-user modules call directly. Which layer of the architecture canvas does this module belong to?

  1. User
  2. Core Correct answer.
  3. Orchestration
  4. Foundation

Explanation

The Core layer contains service modules that provide reusable business capabilities to the layers above them. End-user modules in the User layer consume these services, which keeps business logic centralized. Foundation holds generic libraries, while orchestration composes core services for a specific process.

Question 28OutSystems Architecture design fundamentals

What does it mean when the architecture canvas shows a module in the Orchestration layer?

  1. It composes calls to core services to fulfill a specific application process Correct answer.
  2. It stores the physical database schema for the whole solution
  3. It wraps native code that cannot be written in OutSystems
  4. It provides generic string and date utilities to every module

Explanation

Orchestration modules sit above the Core layer and coordinate multiple core services into an application-specific process. They are allowed to depend on core and foundation modules but should not hold the reusable business rules themselves. This keeps process logic separate from shared capabilities.

Question 29OutSystems Architecture design fundamentals

Which dependency direction is allowed when following the OutSystems layered architecture?

  1. Foundation modules may reference orchestration modules
  2. User modules may reference core modules Correct answer.
  3. Orchestration modules may reference user modules
  4. Core modules may reference user modules

Explanation

Dependencies flow downward: higher layers consume lower layers, never the reverse. User modules may reference orchestration, core, and foundation modules, but lower layers must not reference upper layers. This one-way flow prevents cycles and keeps lower layers reusable.

Question 30OutSystems Architecture design fundamentals

What is the primary purpose of separating an OutSystems solution into a User layer and a Core layer?

  1. To increase the number of modules so deployment takes longer
  2. To isolate reusable business logic from the screens that present it Correct answer.
  3. To avoid using service actions between modules
  4. To force every module to own its own copy of each entity

Explanation

Separating the User and Core layers keeps business rules in reusable service modules that multiple front ends can share. User modules then focus on presentation and call core services. This separation reduces duplication and makes changes to business logic affect all consumers consistently.

Question 31OutSystems Architecture design fundamentals

An architect places a generic encryption helper that many core modules call into a Foundation library. Which statement best justifies this placement?

  1. Foundation libraries are reserved for end-user screens
  2. Foundation libraries hold cross-cutting utilities that any higher layer may consume Correct answer.
  3. Foundation libraries must contain the entity model for the whole solution
  4. Foundation libraries may only be referenced by user modules

Explanation

Foundation is the lowest layer and is intended for generic, reusable capabilities such as utility actions and integration helpers. Because it is generic, any higher layer can consume it without creating upward dependencies. Business entities and screens belong in higher layers.

Question 32OutSystems Architecture design fundamentals

Which module type should an architect choose for a reusable server-side capability that has no screens and is consumed by multiple applications?

  1. A Reactive Web app module
  2. A mobile app module
  3. A theme module
  4. A service module Correct answer.

Explanation

Service modules are headless modules that expose server actions and entities for reuse by other modules. They contain no screens and are the standard way to share business logic across applications. Reactive, mobile, and theme modules are presentation-oriented.

Question 33OutSystems Architecture design fundamentals

In the architecture canvas, what does a drawn dependency arrow between two modules represent?

  1. A shared database table used by both modules
  2. A reference where the source module consumes elements exposed by the target module Correct answer.
  3. The order in which modules are deployed to production
  4. A screen flow that navigates between the two modules

Explanation

An arrow on the canvas denotes a reference from one module to another, meaning the source consumes public elements of the target. Arrows make the dependency graph visible so architects can spot violations and cycles. Deployment order and data sharing are separate concerns.

Question 34OutSystems Architecture design fundamentals

A core service module is consumed by a web app and a mobile app. A developer wants to add a screen-specific validation message to the service. What is the best architectural response?

  1. Keep the message in each user module and leave the service UI-agnostic Correct answer.
  2. Move the service into the User layer
  3. Add the message to the service so both apps display it
  4. Duplicate the service module so each app has its own copy

Explanation

Core services should stay free of presentation concerns so every consumer can reuse them unchanged. UI text and screen-specific validation belong in the user modules that present them. Adding UI concerns to the service couples it to specific front ends and undermines reuse.

Question 35OutSystems Architecture design fundamentals

An architect is told that a Foundation library now references a Core service module. How should this be evaluated?

  1. It is required so foundation modules can reuse business logic
  2. It is a layering violation because foundation must not depend on a higher layer Correct answer.
  3. It is acceptable because foundation modules may use any layer
  4. It is acceptable only if the reference is a service action

Explanation

Foundation is the lowest layer, and dependencies must only point downward. A reference from foundation to core points upward and inverts the intended layering, which can create cycles and reduce reuse. Generic helpers must not depend on business services.

Question 36OutSystems Architecture design fundamentals

Two modules reference each other, each consuming a public action from the other. What is the most accurate architectural assessment?

  1. This is required whenever modules share entities
  2. This is allowed only between user and core modules
  3. This creates a circular dependency that complicates builds and reuse Correct answer.
  4. This is a healthy pattern that improves reuse

Explanation

Circular references mean neither module can be understood, tested, or reused independently, and they complicate dependency resolution. The standard remedy is to extract the shared element into a lower module that both can consume. Layering exists precisely to prevent such cycles.

Question 37OutSystems Architecture design fundamentals

A team wants to reuse the same server-side validation across two applications without exposing it to external systems. Which module choice fits best?

  1. A service module referenced by both applications Correct answer.
  2. An extension module containing the validation
  3. A theme module shared by both applications
  4. A separate copy of the validation in each application module

Explanation

A service module exposes reusable server actions that multiple application modules can reference. Placing validation there keeps a single source of truth and avoids duplication. Extension modules wrap native code, and themes carry styling.

Question 38OutSystems Architecture design fundamentals

An architect must decide where a set of reusable data-transformation actions belongs when they are used by several core service modules. Which placement best respects the canvas?

  1. In an orchestration module above the core modules
  2. In a foundation library consumed by the core modules Correct answer.
  3. In a user module that calls the core modules
  4. In each core module that needs them

Explanation

Generic transformation helpers used by multiple core modules belong in a foundation library, which any higher layer may consume. This keeps the helpers in one place and preserves downward-only dependencies. Placing them higher would force core modules to depend upward.

Question 39OutSystems Architecture design fundamentals

A solution has grown to many modules with tangled references. Which action most directly improves its architectural clarity?

  1. Group modules by layer and enforce downward-only references Correct answer.
  2. Merge all modules into one large module
  3. Add more orchestration modules to call every other module
  4. Remove all service actions between modules

Explanation

Organizing modules by the canvas layers and enforcing one-way references makes the dependency graph understandable and maintainable. It exposes violations and cycles that can then be corrected. Merging everything or removing service actions does not address the underlying structure.

Question 40OutSystems Architecture design fundamentals

When should an architect introduce an orchestration module rather than adding logic to an existing core service?

  1. When the logic coordinates several core services for one application's process Correct answer.
  2. When the logic only formats dates and strings
  3. When the logic must be reused unchanged by every application
  4. When the logic is a generic utility used by every layer

Explanation

Orchestration modules exist to compose calls to multiple core services into a process specific to an application. Reusable business capability stays in core, and generic utilities stay in foundation. This keeps process-specific coordination out of shared services.

Question 41OutSystems Architecture design fundamentals

A core module needs to inform a specific application when a business event happens, without depending on that application. Which design best respects the layering?

  1. The core module exposes the event through a public action the application calls Correct answer.
  2. The core module references the application module and calls its action
  3. The core module is merged into the application module
  4. The core module writes directly into the application's screens

Explanation

Lower layers should expose capabilities that higher layers consume, never call upward. Exposing a public action or event lets the application pull the information while core stays independent. Referencing or merging into the application would invert the dependency.

Question 42OutSystems Architecture design fundamentals

Which statement accurately distinguishes a library module from a service module in OutSystems?

  1. A library module is deployed only to mobile devices, while a service module is deployed to the server
  2. A library module contains screens, while a service module contains only styling
  3. A library module always owns the solution's entity model, while a service module never owns entities
  4. A library module exposes actions for reuse and typically owns no business entities, while a service module exposes business capabilities and may own entities Correct answer.

Explanation

Library modules are reusable collections of actions and are generally generic, while service modules expose business capabilities and commonly own the entities for their domain. Both are server-side and headless. Screens and styling belong to user and theme modules.

Question 43OutSystems Architecture design fundamentals

An architect wants to keep a foundation library free of UI concerns. Which practice best achieves this?

  1. Let the library own the application's theme and styling
  2. Place all screen logic in the library so user modules stay thin
  3. Allow the library to reference user modules for shared screens
  4. Restrict the library to actions and data structures with no screen or theme references Correct answer.

Explanation

A foundation library should contain only generic, non-visual elements such as actions and structures. Keeping screens, themes, and UI references out of it preserves its reusability across every layer. Referencing user modules or owning themes would introduce presentation coupling.

Question 44OutSystems Architecture design fundamentals

Why is duplicating the same entity definition across several modules considered an architectural problem?

  1. It prevents the modules from being deployed
  2. It increases the number of service actions available
  3. It automatically creates circular dependencies
  4. It creates multiple sources of truth that can drift and complicate data integrity Correct answer.

Explanation

When the same entity is defined in several modules, each copy can evolve differently, producing inconsistent data and integrity problems. Centralizing ownership in one module and referencing it keeps a single source of truth. Deployment and action counts are unrelated to this issue.

Question 45OutSystems Architecture design fundamentals

An architect is comparing a single large application module against several modules split by responsibility. Which consideration most favors the split design?

  1. Fewer modules always means faster runtime performance
  2. Splitting guarantees there will be no references between modules
  3. Smaller focused modules enable independent change, testing, and reuse Correct answer.
  4. A single module removes the need for a service layer

Explanation

Splitting by responsibility yields modules that can be changed, tested, and reused independently, which reduces the blast radius of changes. A single large module couples unrelated concerns and is harder to maintain. Splitting does not eliminate references, and runtime performance is not the deciding factor.

Question 46OutSystems Architecture design fundamentals

A team must integrate a third-party .NET library that cannot be reimplemented in OutSystems. Where should this integration live in the canvas?

  1. In an extension module at the lowest layer, consumed by higher modules Correct answer.
  2. In an orchestration module so it can coordinate processes
  3. In a theme module shared across applications
  4. In a user module so screens can call it directly

Explanation

Native code integration is placed in an extension module, which sits at the lowest layer and is consumed by higher modules. This isolates the native dependency and keeps it reusable. User, orchestration, and theme modules are not appropriate hosts for native wrappers.

Question 47OutSystems Architecture design fundamentals

An architect finds that a core service module references a user module to read the current user's locale. What is the best correction?

  1. Move the core service into the user module permanently
  2. Have the core service reference the theme module instead
  3. Keep the reference because locale is a user concern
  4. Pass the locale into the service as a parameter from the calling user module Correct answer.

Explanation

Core modules must not depend on user modules, so the caller should supply contextual values such as locale as input parameters. This keeps the service independent and reusable across front ends. Moving the service upward or swapping the reference does not fix the inversion.

Question 48OutSystems Architecture design fundamentals

A team wants one shared set of business rules consumed by both a Reactive Web app and a mobile app, with each front end keeping its own screens. Which structure best fits the canvas?

  1. Separate user modules per front end, both referencing a shared core service module Correct answer.
  2. Two core service modules, one per front end, each with its own copy of the rules
  3. One user module containing both web and mobile screens plus the rules
  4. A single orchestration module containing the screens and the rules

Explanation

Each front end should be its own user module so its screens evolve independently, while shared business rules live in a core service both consume. This yields one source of truth for the rules and clean downward references. Combining screens or duplicating rules undermines the layering.

Question 49OutSystems Architecture design fundamentals

A foundation library is referenced by many core modules, and the team proposes adding a reference from the foundation library back to one core module for a convenience action. What is the best assessment?

  1. It introduces an upward dependency and risks a cycle, so the action should be moved down or the call inverted Correct answer.
  2. It is fine as long as the referenced action is public
  3. It is required so the foundation library can stay generic
  4. It is acceptable because only one core module is involved

Explanation

Any reference from foundation to core points upward, regardless of how many modules are involved, and can create cycles across the dependency graph. The shared logic should move into foundation or the caller should pass what is needed. Visibility of the action does not change the direction problem.

Question 50OutSystems Architecture design fundamentals

An architect reviews a solution where orchestration modules call each other in a chain, and one of them is also referenced by a core module. Which issue is most significant?

  1. The chain is fine because orchestration modules may reference any layer
  2. The chain improves reuse because orchestration is shared
  3. The core-to-orchestration reference inverts layering and the orchestration chain increases coupling Correct answer.
  4. The core module should reference the orchestration module more often

Explanation

Core must never reference orchestration, since that is an upward dependency and may create cycles. Chaining orchestration modules also increases coupling and makes the process harder to reason about. Orchestration is not intended as a shared, widely referenced layer.