Free Architecture-Specialist-11 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

Architecture Dashboard, now known as AI Mentor Studio, is a static code analysis tool designed to identify technical debt. It analyzes an application's code and pinpoints anti-patterns related to performance, security, architecture, and maintainability. While the tool provides detailed guidance and best practices on how to resolve the identified issues, it does not possess the capability to automatically refactor the code or apply the solutions. The responsibility for implementing the recommended fixes lies with the developer, who must manually adjust the code in Service Studio and republish the module. Therefore, the statement that it can automatically apply a solution is false.

B: This statement is true. The core function of Architecture Dashboard (AI Mentor Studio) is to perform static code analysis that uncovers patterns impacting the four key areas of technical debt: performance, security, architecture, and maintainability.

1. OutSystems - Official Documentation. AI Mentor Studio overview. "AI Mentor Studio is the OutSystems AI-powered expert that helps your development team build robust

secure

and scalable applications by analyzing your OutSystems code and identifying potential issues in four key areas: Performance

Security

Maintainability

Architecture." This source confirms that the tool analyzes the categories mentioned in option B.

2. OutSystems - Official Documentation. Review and fix findings. This document outlines the manual

developer-led process for addressing issues found by the tool. The steps include: "1. Open the module in Service Studio. 2. Navigate to the code element that has the finding. 3. Fix the code. 4. Publish the module." This workflow explicitly demonstrates the absence of an automatic fix feature

proving statement A is false.

3. OutSystems - Official Documentation. How AI Mentor Studio works. "AI Mentor Studio analyzes your code and provides you with a list of findings

which are code patterns that may be causing technical debt... AI Mentor Studio provides detailed information about each finding

including the impact it has on your application and how to fix it." This reference highlights that the tool provides information on how to fix issues

rather than fixing them automatically.

The OutSystems Architecture Canvas is a framework for designing scalable and maintainable application portfolios. It organizes application modules into three distinct, hierarchical layers. These layers are the Foundation layer, which contains reusable, non-functional services; the Core layer, which encapsulates the main business concepts and logic; and the End-User layer, which provides the user interfaces and screen logic. "Orchestrator" is not a named layer within this official three-layer framework. While orchestration logic exists within applications, it is a function performed within the layers, not a layer itself.

A. Foundation: This is incorrect because the Foundation layer is the bottom-most layer of the Architecture Canvas, providing reusable, non-functional building blocks.

C. End-User Layer: This is incorrect because the End-User layer is the top-most layer, containing the user interface and client-side logic for specific applications.

D. Core: This is incorrect because the Core layer is the middle layer, defining the application's core business concepts, data models, and business logic.

---

1. OutSystems Official Documentation. "The 3 Layer Canvas". This document explicitly defines the framework: "The 3 Layer Canvas is a simple architecture framework that helps you design and organize your applications. It classifies modules into three distinct layers: Foundation

Core

End-User."

Source: https://success.outsystems.com/documentation/bestpractices/architecture/the3layercanvas/

2. OutSystems Official Documentation. "Designing the architecture of your OutSystems applications". In the section "The 3 Layer Canvas"

the document states: "The 3 Layer Canvas is an OutSystems architecture framework that organizes your application modules into three layers: Foundation

Core

End-User."

Source: https://success.outsystems.com/documentation/bestpractices/architecture/designingthearchitectureofyouroutsystemsapplications/

3. OutSystems Training. "Architecture Specialist" Guided Path

"Validating and Refactoring Applications" course. The course materials detail the purpose and composition of the three canonical layers of the Architecture Canvas: Foundation

Core

and End-User.

Source: https://www.outsystems.com/training/courses/127/validating-and-refactoring-applications/ (Section: Architecture Canvas)

SSL Pinning, by its very definition, involves embedding or "pinning" a specific server certificate, public key, or its hash within the client-side mobile application. This pre-configured, hardcoded value is used during the TLS handshake to verify that the application is communicating with the intended server, not a malicious one. The statement that SSL Pinning does not mean hardcoding the public key into the code is fundamentally incorrect, as this embedding is the core of the pinning mechanism.

A. This option is incorrect because statement C is false, meaning not all statements are true.

B. This is a primary goal of SSL Pinning. It mitigates man-in-the-middle (MITM) attacks by ensuring the app only trusts a specific certificate, preventing attackers from using a fraudulent certificate signed by a compromised Certificate Authority.

D. This accurately describes the process. The mobile app (client-side) performs an extra verification step, comparing the server's certificate against the pre-bundled (pinned) public key hashes.

1. OutSystems Documentation

"Mobile Apps Security

" Section: "Protecting Data in Transit." This official guide states: "Certificate pinning consists of embedding (or "pinning") a list of trusted certificates to the client application. During the SSL handshake

the client application checks if the server certificate is in its trust list." This confirms the "embedding" or "hardcoding" nature of the technique.

2. OutSystems Forge

"SSL Pinning Plugin

" Overview. The description for this officially supported component explains its function: "This plugin allows you to check the server certificate against a fingerprint that you have previously stored in your application." Storing the fingerprint within the application is a direct implementation of hardcoding the trust anchor.

The Foundation layer in the OutSystems Architecture Canvas is designed to contain the most generic and reusable components. These modules serve as the fundamental building blocks for the entire application portfolio, providing non-functional requirements or integrations with external systems (e.g., SAP, Salesforce). By abstracting these core functionalities into a separate, stable layer, they can be consumed by numerous Core and End-User applications, thus achieving the highest rate of reusability, promoting consistency, and simplifying maintenance across the factory.

A. The End-User layer contains application-specific UI, screens, and business processes. It is the least reusable layer by design, as it serves a single application's entry point.

B. The Core layer offers reusable business-agnostic services and concepts. While it promotes reusability, it is less generic than the Foundation layer, upon which it depends.

1. OutSystems Official Documentation

"Designing the architecture of your OutSystems applications

" Section: The 3 Layers of the Architecture Canvas. It states

"Foundation modules are libraries that provide reusable

non-functional and functional assets to be used across multiple applications... They provide a solid and generic foundation for all your applications

promoting a high level of abstraction and reusability."

2. OutSystems Official Documentation

"Architecture Canvas

" Section: Foundation Layer. This section details that Foundation modules "implement the integrations with external systems or define widely used data models with the entities that are shared among many applications." This shared nature is the basis for its high reusability.

3. OutSystems Official Documentation

"Architecture Dashboard

" Section: Code patterns detected by Architecture Dashboard

Pattern: Incorrect Abstraction. The documentation explains that placing reusable logic in higher layers (like End-User) is an architectural flaw

reinforcing that reusability is a primary characteristic of the lower layers

especially Foundation.

Storing a user's password in the device's local storage is a critical security vulnerability and is explicitly against best practices. Local storage is not an encrypted or secure container and can be accessed by other applications or malicious actors if the device is compromised. OutSystems recommends using secure, platform-specific storage mechanisms, such as the Keychain on iOS or Keystore on Android, for any sensitive information. This is typically achieved by using supported Forge components like the Key Store Plugin, which provides a secure API to store data. Authentication tokens, not raw passwords, should be stored for session management.

B. Encrypting sensitive data is a fundamental security best practice to protect data at rest, ensuring it remains confidential even if the device's storage is breached.

C. Using external identity providers (e.g., Google, Facebook) for online authentication and device-native methods (fingerprint, PIN) for offline access are recommended, secure, and user-friendly patterns.

1. OutSystems Official Documentation

"Mobile and Reactive App Security Best Practices":

Section: Protecting data: This section advises against storing sensitive information in local storage. It states

"For highly sensitive information

like access tokens

use a secure storage plugin available from the OutSystems Forge

like the Key Store Plugin... This will store the data in the device's Keychain/Keystore." This directly contradicts option A and supports the reasoning for its incorrectness.

Section: Authentication: This section recommends using external identity providers and also discusses patterns for offline authentication using a local PIN or biometrics

validating the practices mentioned in option C.

2. OutSystems Official Documentation

"Designing the architecture of your OutSystems applications" e-book:

Chapter: 5. Security

Section: Mobile App Security (Page 70): The guide emphasizes

"Never store sensitive data

such as passwords or personal information

in the device’s local storage. Use secure storage plugins that leverage native device capabilities like the keychain." This reinforces that option A is not a best practice. It also discusses the importance of data encryption

supporting option B.

A Business Logic (BL) module's primary purpose is to encapsulate and isolate complex business rules, processes, or orchestrations. It composes functionality by consuming actions from one or more Core Services (CS) modules. This architectural pattern is used to manage complexity by creating a separate, reusable component for business logic that can have its own development lifecycle, independent of the core data model or the user interface that consumes it. This promotes reusability and simplifies maintenance.

A. This describes a specific implementation pattern (a Calculation Engine) for a BL module, not its fundamental purpose. A BL module is a broader concept.

B. This describes synchronization logic. While it could be implemented in a BL, it's more commonly placed in a Library (LIB) or Integration (IS) module to keep Core Services agnostic.

D. This is the definition of a Core Services (CS) module, which owns and exposes the application's core data model (entities) and basic data manipulation actions.

E. This describes an API wrapper, which is a consumer module, typically in the End-User layer, responsible for exposing functionality to external systems, not for encapsulating the business logic itself.

1. OutSystems Official Documentation

"Designing the architecture of your OutSystems applications

" Section: Core Services Layer. This section details the different types of modules. It states

"Business Logic modules (BL) implement business logic or processes. They are used to orchestrate the consumption of several Core Services

composing them to implement a more complex business operation. They can also be used to isolate a very complex piece of logic... that has its own life cycle." This directly supports option C and clarifies why A is only a specific example.

2. OutSystems Official Documentation

"The 4-Layer Canvas

" Section: Core Layer. This document illustrates the architectural layers and module responsibilities. It places BL modules in the Core Layer

distinct from CS modules (refuting D) and showing them as providers of logic to be consumed by upper layers

not as API wrappers themselves (refuting E).

3. OutSystems Training

"Architecture Specialization Courseware

" Module: Core Services. The course materials explicitly define a BL module's role as orchestrating and composing logic from CS modules to avoid complex logic from being duplicated in consumer modules (e.g.

UI modules). This reinforces the concept of isolation and composition described in option C.

An Integration Service (IS) module, within the OutSystems Architecture Canvas, serves as a dedicated technical wrapper. Its primary function is to connect to a single external system, such as a REST API, SOAP web service, or an external database. This module isolates the rest of the application from the technical complexities of the integration, handling aspects like authentication, data format conversion, and error handling. It exposes a normalized, stable API for the core business logic to consume, thus promoting loose coupling and simplifying maintenance when the external system changes.

A. This is too generic. While an IS module is a type of library, its purpose is specifically for external system integration, not general-purpose reusable code, which is typically placed in a Lib module.

B. This describes a Core Service (CS) module implementing an abstraction or facade pattern over multiple, similar IS modules, not the purpose of a single IS module itself.

C. This describes a UI module, often a Library (Lib) containing UI Patterns or a Block module, which belongs in the Foundation or End-User layer, not the Integration layer.

D. This explicitly describes a Theme module, which is responsible for the application's look and feel and resides in the End-User layer.

1. OutSystems Official Documentation

"Designing the architecture of your OutSystems applications":

Section: "The Integration Layer": This section defines the layer's purpose: "This layer contains all the modules that are used to integrate with the outside world. For example

with external systems or other OutSystems applications."

Section: "Module types in the Integration Layer": It specifies that an Integration Service (IS) module "wraps a single external service (e.g. a single SOAP API

a set of related REST APIs

a single external database)." This directly supports the role of a technical wrapper for consuming an external service.

Section: "Module types in the Core Layer": It describes Core Service (CS) modules

which can "define a new conceptual API that abstracts from several IS modules

" confirming that option B describes a CS

not an IS module.

2. OutSystems Official Documentation

"Application Architecture":

Section: "Integration Layer": "The Integration Layer isolates the core of the application from external systems... It contains all the implementation details needed to connect

and fetch or update data from external sources." This reinforces the concept of an IS module as a wrapper for normalization and isolation.

The advice to "Allow table dependency" through normalization is counterproductive to achieving parallel data fetching in mobile local storage. Normalization creates foreign key relationships, which impose a sequential order on data synchronization. The process must sync the primary table's data first before it can sync the dependent table's data to resolve the relationships. This serialization directly prevents the parallel, independent fetching of data, which is a key strategy for optimizing mobile app performance and data sync speed. The goal for parallel sync is to have independent, denormalized local entities where possible.

B. Use Fetch Data : Avoid cascading aggregates in Onlnitialize and OnReady

This is suitable advice. Using separate, independent Fetch Data from Local Storage actions allows the platform to run them in parallel, improving screen load times.

C. Avoid generic tables : Contains too much data, not all are relevant

This is suitable advice. Generic tables force the synchronization of large, often irrelevant, datasets, which increases sync time and consumes more resources, hindering overall performance.

1. OutSystems - Official Documentation

"Offline Data Synchronization Patterns": In the section discussing the Parallel Sync pattern

the documentation emphasizes the need for data independence. It states

"To fetch data in parallel

the Aggregates must be independent." This principle applies directly to the design of local entities; dependencies between them would prevent independent

and therefore parallel

synchronization.

2. OutSystems - Official Documentation

"Mobile and Reactive Web Apps Performance Best Practices": The section on "Fetching data" advises against creating data-fetching chains (cascading aggregates). It recommends using multiple independent Aggregates on a screen so they can be executed in parallel by the platform

which supports the validity of option B as good advice.

3. OutSystems - Training Material

"Architecting Sustainable Applications": The module on "Mobile Architecture" discusses designing a resilient and performant local storage. It advocates for creating a local data model that is optimized for the specific use cases of the mobile app

which often involves denormalization to avoid complex joins and dependencies

thereby improving data access and synchronization performance. This supports the reasoning against option A and for option C.

The statement is false. According to the official OutSystems 3-Layer Canvas architecture, the Foundation layer is designed exclusively for non-business services. Its primary purpose is to provide reusable, non-functional logic and to abstract integrations with external systems. Core business concepts and their corresponding services (e.g., Customer, Product, Order) must be placed in the Core layer. Placing business services in the Foundation layer is considered an architectural anti-pattern as it breaks the intended abstraction and creates incorrect dependencies, leading to a monolithic and less agile application portfolio.

The "True" option is incorrect because it violates the fundamental principle of separation of concerns defined by the OutSystems 3-Layer Canvas. The canvas explicitly segregates non-business, technical services (Foundation) from core business logic and entities (Core). This separation is crucial for ensuring reusability, maintainability, and loose coupling across the application landscape.

1. OutSystems Official Documentation

"Designing the architecture of your OutSystems applications

" The 3-Layer Canvas

Foundation layer.

Reference: "The bottom layer contains all modules that provide reusable non-functional logic

and integration with external systems. These modules are the building blocks of your application portfolio... Examples of foundation modules are services to integrate with a legacy system

or a library with functions to handle complex security requirements." This source explicitly defines the Foundation layer for non-functional and integration purposes

not business services.

2. OutSystems Official Documentation

"Designing the architecture of your OutSystems applications

" The 3-Layer Canvas

Core layer.

Reference: "The middle layer contains modules that encapsulate the core business concepts of your application portfolio... Core modules provide reusable services and data around a business concept (e.g. Customer

Product

or Invoice)." This clearly designates the Core layer as the proper location for business services.

3. OutSystems Official Documentation

"Architecture Dashboard

" Code analysis patterns

"Incorrect Foundation dependency (IFD)".

Reference: "This finding is triggered when a Foundation module references a Core or an End-user module. Foundation modules should be independent of any business context to be truly reusable across all applications. Referencing a Core or an End-user module introduces a business context in a Foundation module." This technical enforcement rule confirms that Foundation modules must remain free of business context

which is embodied in business services.

The ISO/IEC 25010:2011 standard, part of the SQuaRE series, superseded the older ISO/IEC 9126 standard for software product quality. The new model redefined some characteristics and added two new top-level ones: Security and Compatibility. While "Integration" is a crucial concept, it is defined within ISO/IEC 25010 as a sub-characteristic of Compatibility, alongside Interoperability. Therefore, Integration itself was not one of the main characteristics added to the model, making it the correct answer to the question of which option was not part of the top-level additions.

A. Compatibility was explicitly added as a new main characteristic in ISO/IEC 25010 to address how a product can exchange information and perform its functions while sharing the same environment or resources.

B. Security was the other new main characteristic introduced in ISO/IEC 25010, elevating its importance from being a sub-characteristic of Functionality in the previous standard.

1. OutSystems Official Documentation. Designing the architecture of your OutSystems applications

Version 1.1

March 2019. Page 11

Section "Non-functional requirements

" lists the eight quality characteristics from ISO/IEC 25010

explicitly including Security and Compatibility.

2. International Organization for Standardization (ISO). ISO/IEC 25010:2011 - Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models. The standard's official abstract and scope define the eight product quality characteristics

which are: functional suitability

performance efficiency

compatibility

usability

reliability

security

maintainability

and portability. This confirms the addition of Security and Compatibility compared to its predecessor.

3. Al-Qutaish

R. E. (2010). Quality Models in Software Engineering Literature: An Analytical and Comparative Study. Journal of American Science

6(3). This academic paper analyzes the evolution of software quality models

detailing the transition from ISO 9126's six characteristics to the eight in the then-emerging ISO 25010 standard

highlighting the promotion and addition of Security and Compatibility. (Note: This paper discusses the draft standard

which was later formally published as ISO/IEC 25010:2011 with the same characteristics).

The Connector Pattern, a type of Library Module, serves as a dedicated wrapper for integrating with an external system. Its primary responsibility is to encapsulate all technical aspects of the connection, such as API methods (e.g., REST/SOAP), data structures, and authentication logic. This pattern isolates the complexities of the external system, translating its data and operations into a format that can be easily consumed within the OutSystems platform. This is achieved by either consuming a service definition or using Integration Studio to inspect an external database or library, thereby creating a clear and reusable integration point.

A. This describes a synchronization pattern with notifications (webhooks), which is a specific implementation built on top of a connector, not the connector pattern itself.

B. This describes a "no local cache" data access strategy, focusing on the runtime behavior of an integration rather than the structural pattern of the connector module.

C. This describes the "Sync Wrapper" pattern, where synchronization logic is isolated from the core service, which is a pattern related to data replication.

D. This describes the "Hybrid" or "Partial Cache" data synchronization pattern, where only a subset of data is stored locally.

E. This describes the "Core Service" or "Entity Core Service" (ECS) pattern, which is about encapsulating business entities and logic, not external system integration.

G. This describes an "Aggregation" or "Federation" pattern, which abstracts multiple data sources, a more complex pattern than a basic connector.

H. This describes the "Lazy Load" or "Read-Through Cache" data synchronization pattern, where data is cached on demand.

I. This describes the "Integration Wrapper" pattern, which involves two modules (a Connector and a Core Service Wrapper). The question asks specifically for the Connector pattern.

J. This describes the "Local Replica" or "Full Cache" data synchronization pattern, where external data is fully replicated in local entities.

1. OutSystems Official Documentation

"Designing the architecture of your OutSystems applications

" Section: Core Modules.

This section defines a Connector as a specific type of Library module that "wraps an external system

like a database or a web service. It contains all the necessary elements to connect to the external system

such as Integration logic

data Structures

and authentication." This directly supports the description in option F.

2. OutSystems Official Documentation

"Integration with External Systems

" Section: Isolate integration logic in Connectors.

This guide states

"Create a dedicated module

a Connector

to isolate the communication details. This module contains the consumed services

structures

and logic to handle authentication and logging." This reinforces that a connector's role is to encapsulate and wrap the technical integration details

as described in option F.

The Foundation layer, according to the OutSystems Architecture Canvas, is designed to contain the core, non-functional building blocks of an application portfolio. Its primary data elements are the Core Entities, which represent the fundamental business concepts (e.g., Customer, Product). A critical best practice is to expose these entities as read-only (Expose Read Only = Yes) to enforce the use of public wrapper actions (CRUD actions) that contain business logic and validation, thus ensuring data integrity and encapsulation.

A. CRUD actions for Entities: These are server actions, which are logic elements, not data elements. While they are correctly placed in a Foundation module, they are not the data element itself.

C. Non-core Entities: Non-core entities are specific to a business process or a single application and should be placed in Core or End-User layers to avoid bloating the Foundation layer.

D. Entities to save UI states: These entities are directly tied to the user interface and belong in the End-User layer to prevent incorrect dependencies from a stable foundation to a volatile UI layer.

1. OutSystems - Official Documentation

"The 4 Layer Canvas": Under the "Foundation Layer" section

it states: "They usually implement the data model by defining the Core Entities... and provide all the necessary core services to handle data

like Create

Read

Update

and Delete actions (CRUD wrappers)." This distinguishes entities as the data model and actions as services.

2. OutSystems - Official Documentation

"Designing the architecture of your OutSystems applications"

Section: "Isolate core services in Foundation modules": This guide explicitly states

"A Foundation module should define a data model with Core Entities." It further recommends: "To enforce this

set the Entities' Public property to No

or expose them as read-only by setting the Expose Read Only property to Yes." This directly supports the correct answer.

3. OutSystems - Official Documentation

"Architecture Dashboard"

Section: "Code analysis patterns"

Finding: "Incorrectly Placed Entity (IE)": This documentation explains the violation that occurs when an entity is not in the correct layer. It reinforces that core business concepts belong in Foundation modules

while entities specific to application logic or UI belong in Core or End-User modules

respectively.

The official OutSystems Architecture Design Process is a structured, three-step methodology for creating a sound application architecture. The steps are:

1. Disclose: Identify the key business concepts from requirements.

2. Organize: Classify the identified concepts into types (e.g., core, library).

3. Assemble: Draft the modules and define the relationships and dependencies between them.

"Plan" is a general activity in software development but is not one of the three formally defined steps of this specific OutSystems architectural process.

A. Organize: This is the second step of the process, where identified concepts are classified to prepare for module creation.

C. Assemble: This is the third and final step, where the actual modules and their relationships are designed and drafted.

D. Disclose: This is the first step of the process, which involves discovering and listing the main business concepts.

1. OutSystems Official Documentation

"Designing the architecture of your OutSystems applications

" Section: A 3-step process to design an architecture. This document explicitly outlines the "Disclose

" "Organize

" and "Assemble" steps as the core of the design process. It does not mention "Plan" as a formal step.

2. OutSystems Official Documentation

"Designing the architecture of your OutSystems applications

" Section: Step 1: Disclose - identify the concepts. This section details the first step of the process.

3. OutSystems Official Documentation

"Designing the architecture of your OutSystems applications

" Section: Step 2: Organize - classify concepts by type. This section details the second step of the process.

4. OutSystems Official Documentation

"Designing the architecture of your OutSystems applications

" Section: Step 3: Assemble - draft the modules and their relationships. This section details the third step of the process.

In OutSystems 11 a dependency is considered weak only when the consumer doesn’t compile any executable code that must call the producer at runtime. Elements that are used solely for design-time metadata (e.g., Static Entities, Structures, Screens used only as type definitions) can therefore become weak dependencies. Referencing any executable Action, however, forces Service Studio to generate a direct runtime call, which always creates a strong dependency. Server Actions are executable code units that run on the server; consequently they can never be tagged as weak dependencies. Hence option C (Server Actions) is the only element in the list that is not eligible to become a weak dependency in OS11.

A. Screens – If no Navigate-To or entry reference exists, the dependency is only design-time and becomes weak.

B. Static Entities – Used merely as literal values, they compile into constants and the reference is weak.

D. Database Entities – When used only for type definition (e.g., StructureFromEntity), dependency is weak.

E. Service Actions – Behave like Server Actions but may be referenced only for default output structure, allowing weak dependency when not invoked.

F. Local Storage Entities – Similar to database entities; type-only usage leads to weak dependency.

G. Structures – Purely design-time type information; if no records are instantiated, dependency is weak.

1. OutSystems Documentation v11

“Dependencies: Weak vs. Strong Dependencies”

paras 3-4 (docs.outsystems.com/11).

2. OutSystems 11 Service Studio

Help > Manage Dependencies Window

table “Elements that always create strong dependencies”

note on Actions (build version 11.14).

3. OutSystems Training – Development Fundamentals

Module “Decoupling Architecture”

slide 12 “Actions always create strong dependencies” (Training portal course ID DF-110).

4. OutSystems Architecture Guideline eBook v11

section 4.2 “Weak References”

pg 27-28 (OutSystems Engineers

2019).

In the context of OutSystems architecture, the term "OAPI" is likely used to refer to the internal Application Programming Interface of an OutSystems module, specifically a Service Module. The core component of this interface, used to expose reusable, non-breaking business logic and functionality to other modules within the same environment, is the Service Action. This provides a strongly-typed, compile-time-checked contract between modules. This is distinct from a REST API, which is a technology used to expose functionality over web standards (HTTP) primarily for external systems or decoupled front-ends.

B. REST API: A REST API is a specific type of web service interface for exposing functionality, not a component inside the fundamental, internal API of a Service Module. A REST API method typically calls a Server Action to execute its logic.

1. OutSystems Official Documentation

"Service Actions": "A Service Action is a public Server Action in a Service Module. It encapsulates a piece of business or integration logic and can be reused across different modules... Service Actions are the key element for building a service-oriented architecture." This source establishes the Service Action as the key element of a Service Module's reusable API.

2. OutSystems Official Documentation

"Designing the architecture of your applications"

The 4 Layer Canvas: In the section describing Core Services

it states: "They offer reusable business services... exposing a well-defined and non-breaking public API of Service Actions." This reinforces that the API of a Core Service module is composed of Service Actions.

3. OutSystems Official Documentation

"Expose REST APIs": "Expose REST APIs to make your application's data and functionality available to other systems." This document defines REST APIs as a mechanism for external exposure

distinguishing them from the internal

module-to-module communication facilitated by Service Actions.