Free ODC-ARCHITECTURE-SPECIALIST Practice Test Questions and Answers (2026)

OutSystems Developer Cloud (ODC) provides a comprehensive low-code platform designed to build scalable, full-stack enterprise digital solutions. Valid use cases for ODC apps include delivering web and mobile web-based user interfaces to solve core business needs, processing high-volume data asynchronously through timers and background jobs, and serving as microservices that expose REST APIs to integrate with external systems. However, ODC apps run as cloud-native microservices hosted on AWS infrastructure. They are complete runtime applications rather than embedded code scripts or plugin extensions intended to execute within third-party Integrated Development Environments (IDEs). Therefore, functioning as an embedded script in third-party IDEs is not a valid use case.

A. To asynchronously process high-volume data: ODC apps support background processing and batch operations using timers and asynchronous processing patterns.
B. To solve a business need with a UI: Developing interactive web and mobile front-end applications with visual interfaces is a primary function of ODC.
D. As a microservice exposing APIs: ODC apps can expose public REST endpoints to act as lightweight microservices consumed by other applications.

OutSystems ODC Documentation, "Apps and Libraries in ODC", Section: "Application Use Cases and Architecture Capabilities". https://outsystems.com/help/odc/

OutSystems ODC Architecture Reference, "Designing Cloud Native Solutions with ODC".

The ODC Build Service is a core cloud-native platform service responsible for converting low-code application models created in ODC Studio into executable software artifacts. When a developer publishes or deploys an application, the Build Service compiles the underlying visual model into native .NET code and modern web front-end assets. It then packages these compiled assets along with required runtime dependencies into a standardized, immutable container image (Docker image). This generated container image is stored securely in an enterprise container registry and subsequently deployed onto Kubernetes runtime clusters across target stages (e.g., Development, Test, Production), ensuring consistent, isolated, and scalable execution across environments.

A. A raw database dump is a database backup file, not an application execution package generated by the Build Service.
B. An API gateway routes network traffic to endpoints, which is infrastructure management rather than a compiled app package.
C. A Kubernetes node is a worker machine running containers, not the application software artifact produced during compilation.
E. A virtual disk is a virtualized storage drive file, whereas ODC deploys lightweight container images onto Kubernetes.
F. A JSON spec represents metadata configuration, not the executable compiled application container image generated by the Build Service.

OutSystems Documentation, "ODC architecture", Section: Build Service and containerization. https://mfe.outsystems.com/documentation/odc/architecture/

OutSystems Documentation, "Application lifecycle in ODC", Section: Build and deployment process. https://mfe.outsystems.com/documentation/odc/lifecycle/

In application lifecycle and domain governance within OutSystems architecture, every application should ideally have a single business and technical owner (or product owner). Assigning two or more owners to a single application creates organizational ambiguity, leading to conflicting priorities, misaligned roadmaps, and unclear accountability for features and defect remediation. Ownership dilution often results in architecture rot, where competing requirements from different stakeholders lead to duplicated logic, uncoordinated deployments, and contradictory security settings. Defining a single owner ensures clear domain boundaries, streamlined approval processes, efficient backlog management, and robust lifecycle management across all environments.

A. Unified budgeting is an operational benefit or financial model, not a governance operational risk.
C. Multiple owners do not influence technical execution speed or runtime application performance.
D. UI layout complexity depends on front-end design choices, not organizational app ownership structures.
E. API response speed is determined by network efficiency and database query design, not app ownership.
F. Having multiple owners usually fragments documentation rather than making it clearer.

OutSystems Architecture Guide, "Governance and Application Ownership", Chapter 4: Architecture Governance.

OutSystems ODC Domain Architecture, "Structuring Applications and Teams".

OutSystems Developer Cloud (ODC) leverages a cloud-native microservices architecture managed by Kubernetes containers to host application runtimes. To maintain application availability and performance under fluctuating traffic conditions, ODC implements an automated scaling mechanism managed by an auto scale controller. This controller continuously monitors runtime metrics, specifically CPU utilization and memory (RAM) usage, against predefined system thresholds. When application workload surges cause CPU or memory metrics to exceed designated operational limits, the auto scale controller automatically provisions additional container replicas to distribute load effectively. Conversely, when resource usage drops below thresholds, container instances are scaled down, ensuring optimal performance, high resilience, and efficient cloud resource utilization without requiring manual intervention.

B: Scheduled nightly builds govern application deployment pipelines, not real-time container horizontal scaling based on runtime demand. C: Monthly patch updates maintain platform security and maintenance, which operate independently of dynamic runtime auto-scaling triggers. D: Manual Kubernetes restarts are administrative interventions for recovery, not automated scaling triggers driven by performance metrics. E: GitHub webhooks trigger continuous integration or deployment workflows, not infrastructure runtime auto-scaling based on load. F: Developer refresh actions update user interface views in the portal but do not trigger cluster auto-scaling controllers.

OutSystems ODC Documentation: "ODC Architecture Overview" – Application Runtime and Container Auto-scaling mechanisms.

OutSystems ODC Documentation: "OutSystems Developer Cloud infrastructure" – Scalability, elasticity, and resource utilization monitoring.

In OutSystems platform architecture, executing database queries using custom SQL actions or advanced database extensions creates database statement handles and places query result sets into server memory. When developers fail to explicitly invoke statement closure operations (such as calling CloseStatement) within custom logic, the platform retains the underlying query result dataset in server memory to allow continued data iteration. To prevent indefinite memory leaks and resource exhaustion, OutSystems runtime implements an automatic background cleanup and garbage collection mechanism. This mechanism automatically releases unclosed query statements and frees the associated memory buffers after a default retention threshold of approximately 5 minutes, ensuring platform stability while mitigating temporary unclosed resource overhead.

Option A: Query results are reclaimed significantly sooner than 24 hours to prevent memory exhaustion on runtime servers.
Option B: Memory is not held until application closure; automated background cleanup reclaims unclosed resources after approximately 5 minutes.
Option C: 30 seconds is the default query execution timeout for requests, not the memory retention duration for unclosed statement results.
Option E: 1 hour is longer than the automatic memory cleanup threshold applied to unclosed query execution datasets.
Option F: Statements are not retained indefinitely because garbage collection and platform cleanup automatically reclaim memory after approximately 5 minutes.

OutSystems Platform Documentation: "SQL Tool / ExecuteQuery API Reference", Section: Memory Management and Statement Closure.

OutSystems Best Practices: "Managing Database Connections and Custom SQL Execution in OutSystems".

In OutSystems Developer Cloud (ODC), security and governance are governed by centralized access management built directly into ODC Portal. Viewing application logs, system trace events, deployment history, and audit data is strictly protected using Role-Based Access Control (RBAC). Platform administrators assign specific organization roles and permission sets to users, explicitly granting or restricting privileges such as viewing logs or monitoring environments. Without the appropriate role-based log viewing permissions assigned in ODC Portal, users cannot access telemetry data or trace information. This ensures compliance with organizational data security policies, prevents unauthorized exposure of sensitive operational logs, and provides granular visibility control across development, staging, and production application environments.

Option A: Log access in ODC is governed by user role permissions rather than time-based access expiration mechanisms.
Option C: Non-developer roles (such as site reliability engineers or auditors) can view logs if granted appropriate role-based permissions in ODC Portal.
Option D: Third-party API integration can export logs, but individual user view access within ODC is regulated by role-based permissions.
Option E: Access to logs is controlled via role permissions in ODC Portal rather than exposing logs purely based on user IP addresses.
Option F: Log access is restricted to authorized individuals according to assigned roles, rather than being openly shared across all platform users.

OutSystems Documentation: "ODC Portal User Management and User Roles", Section: Permissions for Log and Monitoring Access.

OutSystems Security & Compliance Guide: "Role-Based Access Control (RBAC) in ODC Portal".

In OutSystems Developer Cloud (ODC), database High Availability (HA) is achieved through a multi-zone, fault-tolerant database architecture utilizing synchronous replication between a primary database instance and a warm standby instance. During an unexpected infrastructure failure, hardware degradation, or zone outage affecting the primary database, the cloud infrastructure automatically detects the failure and initiates a database failover. The standby database instance is automatically promoted to become the new primary instance without requiring manual developer intervention, manual data synchronization, or database deletion. Endpoint routing is updated seamlessly to point application traffic to the new primary instance, minimizing downtime and guaranteeing high availability and business continuity for runtime applications.

A: The system switches automatically to the synchronous standby database instance, not running directly from a restored backup. B: Applications do not need to restart entirely; database connections reconnect transparently to the newly promoted primary database. C: Failover is completely automated by cloud infrastructure and does not require manual developer notification or manual switching. D: Synchronous database replication keeps the standby instance updated in real-time, eliminating the need for manual data synchronization. E: Kubernetes manages application container pods, not database lifecycle deletion during multi-AZ database failover events.

OutSystems ODC Documentation: "ODC database architecture and reliability" – High Availability (HA) and automatic failover concepts.

OutSystems ODC Documentation: "Data architecture in ODC" – Multi-AZ deployments, fault tolerance, and replication strategies.

In OutSystems Developer Cloud (ODC), applications are strictly isolated execution units to ensure modularity and independent lifecycle management. Direct cross-application dependencies or direct sharing of UI components between applications are not permitted. To share UI elements—such as custom Blocks, UI patterns, themes, images, or client-side logic—developers must place these elements inside a Library and set their visibility to public. Once the Library is released, any Application within the ODC tenant can consume these public UI elements by adding a dependency to the published Library version, enabling consistent branding and component reusability across the entire enterprise portfolio.

A: APIs (REST/ODATA) are strictly for exchanging data and remote logic, and cannot render or deliver reusable UI elements like Blocks. B: Manual duplication creates maintenance overhead and technical debt, contradicting the ODC architectural principle of centralized component reusability via Libraries. C: UI elements can indeed be shared across applications, provided they are packaged and published within shared public Libraries.

OutSystems ODC Documentation, "Reuse UI across apps", Section: "Sharing UI components using Libraries", https://success.outsystems.com/documentation/outsystems_developer_cloud/building_apps/user_interface/

OutSystems ODC Architecture, "ODC Architecture Canvas", Section: "Libraries as UI and Logic providers", https://success.outsystems.com/documentation/outsystems_developer_cloud/architecture/

In OutSystems Developer Cloud (ODC), Libraries are stateless assets designed specifically for code reusability across multiple applications within an organization's portfolio. They allow developers to package and distribute reusable UI elements, client actions, server actions, logic, and integration connectors without maintaining state or persistent database entities. By encapsulating common utility functions, design system assets, and integration patterns, Libraries enable consistent functionality across apps while promoting independent deployment lifecycles. When an app consumes a library, it receives a versioned dependency that ensures stability. Using libraries to share code prevents code duplication, simplifies maintenance across enterprise portfolios, and enforces architectural compliance across distributed application development teams within ODC.

A. Hosting large media files: Hosting large media files is handled via dedicated cloud storage, Content Delivery Networks (CDNs), or external blob storage, not ODC Libraries.
B. Managing user sessions: User session management is handled by the ODC platform's built-in authentication runtime and identity provider mechanisms, not reusable libraries.
D. Building UI only: Libraries support both UI patterns (like design systems) and logic (client/server actions, integrations), so they are not restricted to UI only.
E. Running external APIs: External APIs run on third-party servers; ODC Libraries can contain logic or integrations to consume APIs, but do not host external APIs.
F. Managing payment flows: Managing complex payment business flows is handled in core domain applications rather than stateless shared library assets.

OutSystems Documentation: "Libraries in ODC", Section: What is a Library. https://success.outsystems.com/documentation/outsystems_developer_cloud/building_apps/libraries/

OutSystems Architecture Guide: "Reusability and Dependency Management in ODC Applications".

In OutSystems Developer Cloud (ODC), apps represent independent, loosely coupled lifecycle units. As a key architectural rule, Server Actions inside an App cannot be directly set to Public for consumption by other Apps. To share business logic residing inside an App without moving it into a reusable Library, you must expose it as a Service Action. Service Actions act as public interfaces wrapped in REST-based endpoints, enabling asynchronous or synchronous communication across App boundaries while maintaining weak dependencies. This design ensures that the producer App can be updated and deployed independently without breaking or forcing an immediate re-compilation of the consumer Apps.

A. Uploading to Forge shares public components community-wide rather than privately exposing internal App logic.
C. "Global" is not a valid scope setting or feature in OutSystems ODC for sharing logic across applications.
D. Modules are not manually shared in ODC, as architecture is organized at the App and Library level.
E. Duplicating logic in a library creates code redundancy and maintenance overhead instead of exposing existing logic.
F. Static methods are programming language constructs not utilized as sharing mechanisms in OutSystems ODC.

OutSystems ODC Documentation, "Expose functionality using Service Actions", Section: Service Actions in ODC.

OutSystems Architecture Canvas in ODC, "Validating Dependencies and Lifecycle Management", Section 3.2.