I85PREP
⌘ K
OutSystems Tech Lead study materials
OutSystems Tech Lead study resources

OutSystems Tech Lead practice questions

One question at a time. Build your OutSystems Tech Lead 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 1Architecture

In a layered OutSystems canvas, which layer is intended to hold reusable UI patterns and screen templates that multiple modules can consume?

  1. The Core layer
  2. The Library layer Correct answer.
  3. The Orchestration layer
  4. The End-User layer

Explanation

The Library layer hosts reusable UI elements such as web blocks, screen templates, and layout patterns that are shared across modules. Core modules instead concentrate on reusable business logic and data model entities, while End-User modules deliver the actual user experience.

Question 2Architecture

A team wants to expose a customer lookup to other modules. Which element should the architect place in the module's public interface so other modules can call it?

  1. A private screen action
  2. A local session variable
  3. A client action marked private
  4. A public server action Correct answer.

Explanation

Public server actions are the standard mechanism for exposing server-side logic to consuming modules through a referenced producer. Private screen actions, client actions, and session variables are scoped to the module and cannot be called externally as reusable services.

Question 3Architecture

Which statement best describes the purpose of a strong entity in an OutSystems data model?

  1. It stores only static configuration values used by site properties.
  2. It must always reference a parent entity through a mandatory foreign key.
  3. It has its own identifier and can exist independently of any other entity. Correct answer.
  4. It exists only to join two other entities in a many-to-many relationship.

Explanation

A strong entity owns its identifier and does not depend on another entity for existence. Weak entities, by contrast, derive part of their identity from a parent entity, and join entities exist to resolve many-to-many relationships.

Question 4Architecture

An architect needs to run client-side logic immediately after a screen aggregate's data has been fetched. Which event is the appropriate place?

  1. On After Fetch Correct answer.
  2. On Destroy
  3. On Render
  4. On Initialize

Explanation

On After Fetch runs when a screen aggregate finishes retrieving its data, so its results are available to the handler. It can be used to process those results for the UI. On Ready follows the initial DOM render and does not guarantee that the screen's data has arrived.

Question 5Architecture

A module needs to read records from an entity owned by another module without duplicating the table. What is the recommended OutSystems approach?

  1. Expose the entity as a site property and read it at startup.
  2. Create a local copy of the entity and synchronize it with a timer.
  3. Reference the producer module and use the exposed entity through a public reference. Correct answer.
  4. Query the other module's database table directly with a SQL element.

Explanation

Referencing the producer module gives the consumer access to the exposed entity definition, preserving a single source of truth for the data model. Copying tables, direct SQL access, or site properties all break encapsulation and create synchronization or integrity risks.

Question 6Architecture

Which OutSystems construct is designed to encapsulate a reusable unit of business logic that can be called from multiple places within the same module?

  1. A site property
  2. A web block
  3. A screen aggregate
  4. A server action Correct answer.

Explanation

Server actions encapsulate reusable server-side logic and can be called from other actions, timers, or screens within the module. Aggregates fetch data for screens, web blocks are UI components, and site properties store configuration.

Question 7Architecture

A solution must process a large batch of records nightly without blocking user requests. Which OutSystems element is the correct choice?

  1. A client action triggered on screen load
  2. A timer that runs a server action on a schedule Correct answer.
  3. A screen action invoked from a web block
  4. A site property updated by an administrator

Explanation

Timers run server-side logic on a schedule independently of user sessions, making them suitable for nightly batch processing. Client actions and screen actions depend on a user's browser session, and site properties are configuration values.

Question 8Architecture

Which statement accurately describes the role of the Orchestration layer in a well-structured OutSystems architecture?

  1. It composes and coordinates calls to services exposed by other modules to fulfill a business process. Correct answer.
  2. It stores the shared entities and business rules used by all modules.
  3. It holds reusable UI patterns consumed by End-User modules.
  4. It renders the end-user screens and handles client-side validation.

Explanation

Orchestration modules act as coordinators, invoking public services from Core and Library modules to implement a process without duplicating their logic. Shared entities and rules belong to Core, screens belong to End-User, and UI patterns belong to Library.

Question 9Architecture

An architect is defining a REST integration to an external system. Which approach best isolates the external contract from the rest of the application?

  1. Call the external endpoint directly from every screen action that needs it.
  2. Wrap the external call in a Core module that exposes a stable public action to consumers. Correct answer.
  3. Duplicate the integration logic in each module to avoid coupling.
  4. Embed the endpoint URL in each consumer module's site property.

Explanation

Encapsulating the external integration in a Core module creates a single point of change and a stable internal contract for consumers. Direct calls and duplicated logic spread coupling, and per-module URLs create configuration drift.

Question 10Architecture

Which OutSystems element allows an architect to define a configurable value that differs per environment without redeploying code?

  1. A session variable
  2. A site property Correct answer.
  3. A local variable
  4. An input parameter

Explanation

Site properties are configuration values that can be set differently in each environment through the platform's configuration management. Local variables, session variables, and input parameters are runtime values tied to execution context, not environment configuration.

Question 11Architecture

A screen must display a list of orders filtered by the logged-in customer and support pagination. Which element most directly provides this data to the screen?

  1. A site property holding the customer identifier
  2. A screen aggregate with a filter on the customer identifier Correct answer.
  3. A client action that calls an external API
  4. A server action with a For Each loop

Explanation

A screen aggregate declaratively fetches and filters records for a screen and supports built-in pagination. A For Each loop in a server action is imperative and does not provide native screen pagination, while site properties and client actions are not the standard data-fetch mechanism here.

Question 12Architecture

Which practice best supports a modular architecture when two Core modules need to share a common entity?

  1. Copy the entity into both modules and keep them synchronized.
  2. Store the entity data in a site property shared by both modules.
  3. Extract the shared entity into a dedicated Core module that both modules reference. Correct answer.
  4. Place the entity in an End-User module and reference it from Core.

Explanation

Extracting the shared entity into a dedicated producer module preserves single ownership and avoids circular references between the two Core modules. Copying entities, referencing End-User modules from Core, or using site properties all violate layering or consistency principles.

Question 13Architecture

What is the primary benefit of using a web block instead of duplicating screen markup across multiple screens?

  1. It automatically caches data at the database level.
  2. It removes the need for input parameters between screens.
  3. It centralizes the UI definition so changes propagate to all consumers. Correct answer.
  4. It guarantees that the block's logic runs on the server only.

Explanation

A web block encapsulates a reusable UI component, so a single change updates every screen that uses it. It does not provide database caching, eliminate parameters, or force server-only execution.

Question 14Architecture

An architect must ensure that a long-running integration does not time out the user's request. Which pattern is most appropriate?

  1. Call the integration from On Render to run it in the browser.
  2. Store the request in a site property and process it on the next deployment.
  3. Offload the work to an asynchronous process and notify the user when it completes. Correct answer.
  4. Increase the screen's timeout and call the integration synchronously.

Explanation

Offloading long-running work to an asynchronous mechanism decouples it from the user request and avoids timeouts. Increasing timeouts keeps the user waiting, client-side execution cannot perform trusted server work, and site properties are not a processing queue.

Question 15Architecture

Which statement about exposing entities through a module's public interface is correct in OutSystems?

  1. Exposed entities are read-only for consumers and must be modified through public actions. Correct answer.
  2. Exposed entities can be read and written by any consumer that references the producer.
  3. Exposed entities cannot be used in aggregates by consumer modules.
  4. Exposed entities automatically replicate their data into each consumer's database.

Explanation

When an entity is exposed, consumers can read it, but writes should go through public actions so the producer retains control over business rules and validation. Data is not replicated per consumer, and consumers can use exposed entities in aggregates.

Question 16Architecture

A team wants to prevent a Core module from depending on End-User modules. Which architectural principle does this enforce?

  1. Eventual consistency across data stores
  2. Loose coupling between UI and business logic
  3. Strict layering with dependencies pointing toward lower layers Correct answer.
  4. Horizontal scaling of the application tier

Explanation

Preventing lower layers from depending on higher layers enforces strict layering, keeping dependencies directed toward Core and Library. This is distinct from loose coupling, scaling, and consistency concerns, which address different quality attributes.

Question 17Architecture

Which OutSystems mechanism is best suited to expose a business capability to external systems as a documented API?

  1. A REST API exposed from a module Correct answer.
  2. A site property containing a JSON string
  3. A timer that runs every minute
  4. A screen with a public URL

Explanation

Exposing a REST API from a module publishes a documented, versioned contract for external consumers. Screens are for human users, timers are schedulers, and site properties are configuration values, none of which provide a proper API contract.

Question 18Architecture

An architect is reviewing a data model where an Order entity has a mandatory foreign key to Customer and a Customer can have many Orders. What relationship is this?

  1. One-to-one
  2. One-to-many Correct answer.
  3. Self-referencing
  4. Many-to-many

Explanation

A single Customer relating to many Orders, with each Order referencing exactly one Customer, is a one-to-many relationship. One-to-one would restrict each side to a single record, many-to-many requires a join entity, and self-referencing links an entity to itself.

Question 19Architecture

Which approach best supports testability of business logic in an OutSystems architecture?

  1. Rely on manual UI testing as the primary verification method.
  2. Place business rules in Core module actions that can be invoked independently of screens. Correct answer.
  3. Embed logic directly in screen actions to keep it close to the UI.
  4. Store rule thresholds in local variables inside each screen.

Explanation

Business rules placed in Core actions can be invoked directly by tests without rendering a screen, improving testability and reuse. Embedding logic in screens, relying on manual UI testing, or scattering thresholds in local variables all reduce testability and consistency.

Question 20Architecture

What is the recommended way to handle exceptions raised by an external integration so that users receive a meaningful message?

  1. Log the exception and return an empty record list to the caller.
  2. Let the exception propagate unhandled to the default error screen.
  3. Catch the exception in the integration action and return a structured result the caller can interpret. Correct answer.
  4. Suppress the exception with an empty Exception Handler and continue silently.

Explanation

Catching the exception at the integration boundary and returning a structured result lets callers decide how to inform users while preserving diagnostic detail. Unhandled exceptions, silent suppression, or returning misleading empty data all degrade the user experience and observability.

Question 21Architecture

An architect needs to guarantee that a set of related database writes either all succeed or all fail. Which OutSystems capability provides this?

  1. A site property toggled before and after the writes
  2. A server action wrapped in a transaction Correct answer.
  3. A client action with sequential assignments
  4. A timer scheduled to retry failed writes

Explanation

Wrapping the related writes in a server action transaction ensures atomicity, so partial failures roll back the whole set. Client actions, site property toggles, and retry timers do not provide transactional guarantees.

Question 22Architecture

Which consideration most strongly favors splitting a large monolithic module into multiple modules?

  1. Enabling independent deployment and clearer ownership boundaries Correct answer.
  2. Avoiding the use of public actions between components
  3. Reducing the number of screens in the application
  4. Eliminating the need for a data model

Explanation

Modular decomposition enables independent deployment, clearer team ownership, and reduced coupling between concerns. It does not reduce screen counts, avoid public actions, or remove the need for a data model; those are misconceptions about modularity.

Question 23Architecture

An integration must tolerate the external provider being temporarily unavailable without losing requests. Which architectural pattern is most appropriate?

  1. Disabling the integration until the provider recovers manually
  2. A durable queue with asynchronous processing and retry Correct answer.
  3. Synchronous retries inside the user's screen request
  4. Caching the provider response indefinitely in a site property

Explanation

A durable queue decouples request acceptance from provider availability and supports retries without blocking users or losing work. Synchronous retries tie up the user request, indefinite caching serves stale data, and manual disabling loses requests during the outage.

Question 24Architecture

Which statement best explains why a Core module should avoid referencing an End-User module?

  1. It would force the End-User module to run on the server only.
  2. It would create a circular dependency that the platform cannot compile.
  3. It would prevent the Core module from exposing entities.
  4. It would invert the intended layering, coupling reusable logic to a specific user experience. Correct answer.

Explanation

Referencing an End-User module from Core inverts the layering, tying reusable business logic to a specific UI and reducing reuse across channels. The platform can compile such references, and entity exposure or execution location are unrelated consequences.

Question 25Architecture

A solution requires the same business rule to be applied consistently whether data arrives through a screen, a REST API, or a timer. Where should the rule be implemented?

  1. In client-side validation on the screens only
  2. In database triggers maintained outside the platform
  3. In a shared server action in a Core module invoked by all entry points Correct answer.
  4. In each entry point separately to keep them independent

Explanation

Centralizing the rule in a shared Core server action guarantees consistent enforcement across every entry point. Duplicating it per entry point risks divergence, client-side validation can be bypassed, and external triggers fragment ownership of business logic.

Question 26Architecture

When designing the module layer diagram for a new OutSystems solution, which set of layers reflects the recommended canonical architecture?

  1. UI, Service, Repository, and Utility layers, arranged in a strict circular dependency
  2. Orchestration, End-User, Core, Foundation, and Library layers, with dependencies flowing downward Correct answer.
  3. End-User, Core, and Foundation layers only, with bidirectional dependencies allowed
  4. Presentation, Application, Domain, and Infrastructure layers, with dependencies flowing upward

Explanation

OutSystems architecture guidance defines a layered model of Orchestration, End-User, Core, Foundation, and Library modules, and dependencies must point downward so lower layers never reference higher ones. This keeps reusable logic stable and prevents cycles.

Question 27Architecture

An architect is choosing where to place a reusable email-sending capability that several Core modules will consume and that wraps a third-party provider. Which placement is most appropriate?

  1. In the Orchestration module alongside the screen flows
  2. In an End-User module exposed as a public action
  3. Inside each Core module that needs it, duplicated to avoid cross-module references
  4. In a Foundation module that the Core modules reference Correct answer.

Explanation

Foundation modules hold reusable, technology-facing capabilities such as provider wrappers, and lower layers may be referenced by higher ones. Placing the wrapper in a Foundation module keeps it single-sourced and prevents Core modules from duplicating integration logic.

Question 28Architecture

A team wants to document the intended architecture of a solution before building it, capturing modules, their responsibilities, and allowed dependencies. Which OutSystems capability supports this?

  1. Integration Studio's extension editor
  2. Service Studio's TrueChange panel
  3. The Architecture Canvas in LifeTime Correct answer.
  4. The module's public elements list

Explanation

The Architecture Canvas in LifeTime is the tool for designing and validating the module layering, including which dependencies are allowed between layers. It is used at design time to steer the solution structure rather than to compile code.

Question 29Architecture

An architect must decide how a mobile app and a web app should share the same business rules without duplicating logic. Which design satisfies the layering guidance?

  1. Place the rules in each End-User module so each app can tune them independently
  2. Place the rules in a Core module that both End-User modules reference Correct answer.
  3. Place the rules in the mobile module and expose them to the web module
  4. Place the rules in a Library module that references both End-User modules

Explanation

Business rules belong in Core modules, which End-User modules may reference, so both front ends consume one implementation. This preserves single-source logic while keeping each End-User module free to compose its own screens.

Question 30Architecture

An architect is reviewing a proposed dependency where a Core module would call a server action exposed by an Orchestration module. What is the correct assessment?

  1. Acceptable, because Orchestration modules are designed to be called by any layer
  2. Acceptable, provided the action is marked public in the Orchestration module
  3. Incorrect, because Core modules may only reference Foundation modules and never expose actions
  4. Incorrect, because dependencies must flow from higher layers to lower layers, never upward Correct answer.

Explanation

The layering rule states that dependencies point downward, so a lower-layer Core module must never depend on a higher-layer Orchestration module. Such an upward reference creates a cycle risk and makes the Core module unusable without the orchestration context.

Question 31Architecture

Two Core modules both need the same set of reference entities describing product categories. Which approach best preserves the architecture?

  1. Create a Foundation module that owns the entities and have both Core modules reference it Correct answer.
  2. Let the first Core module own the entities and have the second reference that Core module
  3. Move the entities into an End-User module and reference it from both Core modules
  4. Duplicate the entities in both Core modules and synchronize them with a timer

Explanation

Shared reference data belongs in a lower layer that both consumers can reference without creating peer coupling. A Foundation module owning the entities keeps the dependency direction downward and gives a single source of truth.

Question 32Architecture

An architect is evaluating whether to expose a Core module's entities directly to End-User screens or to wrap access in server actions. Which consideration most strongly supports wrapping access in actions?

  1. Entities exposed publicly are automatically read-only, so actions are needed for writes
  2. Wrapping access lets the Core module enforce validation and change its data model without breaking consumers Correct answer.
  3. Exposed entities cannot be used in aggregates, so actions are the only way to read data
  4. Server actions execute faster than aggregates because they bypass the database

Explanation

Encapsulating data access behind server actions gives the Core module control over validation and lets the underlying data model evolve without forcing consumer changes. Direct entity exposure spreads knowledge of the schema across the solution.

Question 33Architecture

A solution must call an external payment provider whose API contract may change. Which design best isolates the impact of that contract change?

  1. Generate the provider's entities directly into each End-User module
  2. Wrap the provider in a Foundation module that exposes a stable internal action contract Correct answer.
  3. Embed the provider's endpoint URLs in the Orchestration module's screen logic
  4. Reference the provider's REST endpoints directly from every screen that takes a payment

Explanation

An anti-corruption wrapper in a Foundation module exposes a stable internal contract, so a provider change is absorbed in one place. Consumers then depend on the internal action rather than the external payload shape.

Question 34Architecture

An architect is deciding how to model a Customer that has many Orders where Orders are only meaningful within a Customer context. Which data-model decision best reflects the domain?

  1. Create Order as a standalone entity with no reference to Customer
  2. Model Order as an entity in the End-User module and reference Customer from it
  3. Model Order as a child entity of Customer using a composite aggregate, and expose it through the Customer's public interface Correct answer.
  4. Store Order rows in a Structure shared between Core and End-User modules

Explanation

When a child has no independent lifecycle, modeling it as a child entity of the aggregate root keeps invariants enforced by the owning entity. Exposing it through the parent's interface preserves encapsulation of the aggregate.

Question 35Architecture

A Core module needs to notify interested parties when an order is approved, but it must not depend on the modules that will react. Which mechanism fits best?

  1. A direct server action call from the Core module to each interested End-User module
  2. A public event raised by the Core module that consumers subscribe to Correct answer.
  3. A timer in the Core module that inspects consumer tables directly
  4. A shared session variable that consumers poll on each screen load

Explanation

Public events let a lower-layer module announce a fact without knowing its consumers, so subscribers depend on the publisher rather than the reverse. This keeps the dependency direction correct while allowing extensibility.

Question 36Architecture

An architect is reviewing a solution where an End-User module directly references entities from another End-User module. What is the primary architectural concern?

  1. End-User modules cannot reference entities at all, so the build will fail
  2. The reference prevents the module from using web blocks
  3. Peer references between End-User modules create coupling and can produce circular dependencies Correct answer.
  4. Referencing entities always forces the module into the Foundation layer

Explanation

End-User modules are top-layer composition units, and referencing one from another creates peer coupling that can become circular as features grow. Shared logic or data should be pushed down into Core or Foundation instead.

Question 37Architecture

A team plans to expose several Core capabilities as a documented API for partners. Which OutSystems approach best fits this requirement?

  1. Grant partners access to the Orchestration module's public actions
  2. Publish the Core module's screens as the partner interface
  3. Expose the Core module's entities directly and let partners query the database
  4. Create a Service module that exposes REST APIs and delegates to Core server actions Correct answer.

Explanation

A dedicated Service module owns the external API contract and delegates to Core logic, keeping the external interface separate from internal modules. This isolates versioning and authentication concerns from the domain layer.

Question 38Architecture

An architect must decide how to version a public REST API consumed by partners while internal Core logic continues to evolve. Which design is most sound?

  1. Change the Core action signatures in place and require partners to redeploy on each release
  2. Maintain versioned API contracts in the Service module and map each version to current Core actions Correct answer.
  3. Let partners call Core server actions directly so no versioning layer is needed
  4. Expose the Core entities and rely on schema changes being backward compatible

Explanation

Versioned contracts in the Service module decouple the external promise from internal refactoring, so Core logic can evolve while older partner versions keep working. The mapping layer absorbs the difference between contract versions.

Question 39Architecture

An architect is assessing a solution where the Orchestration module contains business validation rules that are also needed by a REST API exposed from a Service module. What is the most appropriate remediation?

  1. Move the REST API into the Orchestration module so the rules stay in one place
  2. Have the Service module call the Orchestration module's screen actions to reuse the rules
  3. Copy the validation rules into the Service module so each entry point owns its own copy
  4. Extract the validation into a Core server action that both the Orchestration module and the Service module call Correct answer.

Explanation

Business validation belongs in Core so every entry point, whether screen or API, applies the same rule. Extracting it into a Core action removes duplication and keeps the dependency direction downward for both consumers.

Question 40Architecture

A solution is growing and an architect is deciding whether to split a large Core module. Which signal most strongly indicates that a split is warranted?

  1. The module is referenced by more than one End-User module
  2. The module exposes more than one public server action
  3. The module contains many entities and actions that change together for a single business capability
  4. The module has grown to include several unrelated business capabilities with distinct change cadences and teams Correct answer.

Explanation

Module boundaries should follow business capabilities and change cadence, so a module mixing unrelated capabilities owned by different teams is a strong split signal. Size alone, or the number of public actions, is not decisive.

Question 41Delivery and project leadership

In an OutSystems delivery project, which artifact should the Tech Lead establish first to govern code review and deployment gates across the team?

  1. A list of every screen the client might request later
  2. A spreadsheet of developer salaries and utilization
  3. A marketing plan for the OutSystems Center of Excellence
  4. A written architecture and coding-standards baseline agreed with the team Correct answer.

Explanation

A Tech Lead first fixes the technical baseline-architecture decisions, naming, module boundaries and coding standards-because review checkpoints and deployment gates are judged against it. Without that agreed reference, reviewers apply personal preferences and quality becomes inconsistent. The other artifacts do not govern technical quality in the delivery lifecycle.

Question 42Delivery and project leadership

A team is building a large OutSystems application with several squads. Which strategy best limits merge conflicts and cross-team coupling?

  1. Ban the use of reusable components until the final sprint
  2. Split functionality into separate modules per squad with explicit, versioned dependencies Correct answer.
  3. Require all squads to deploy simultaneously to a single environment
  4. Have every squad commit to one shared module to maximize reuse

Explanation

Partitioning the application into modules owned by individual squads, with explicit and versioned dependencies between them, reduces concurrent edits to shared assets and makes integration points visible. One shared module concentrates conflicts, and banning reuse or forcing simultaneous deploys increases risk rather than reducing coupling.

Question 43Delivery and project leadership

During sprint planning, the Tech Lead must estimate an OutSystems feature that integrates with an external REST API whose contract is not yet finalized. What is the most defensible approach?

  1. Estimate as if the API contract were already stable and ignore the risk
  2. Estimate the known work and add an explicit spike or risk buffer for the unsettled contract Correct answer.
  3. Assign the story to the most junior developer to absorb uncertainty
  4. Refuse to estimate until the external provider publishes final documentation

Explanation

When a dependency contract is unsettled, the honest estimate covers the work you can define plus an explicit spike or buffer for the unknown. That makes the uncertainty visible to the client and the team instead of hiding it. Refusing to estimate blocks planning, and ignoring the risk produces a false commitment.

Question 44Delivery and project leadership

Which metric most directly indicates whether an OutSystems delivery team's technical debt is being controlled sprint over sprint?

  1. Number of screens delivered per developer
  2. Count of OutSystems certifications held by the team
  3. Average number of meetings attended per squad
  4. Trend of open code-analysis findings and remediation items closed per sprint Correct answer.

Explanation

Technical debt is tracked through the balance of outstanding quality findings-code analysis warnings, known defects, refactoring backlog-against the remediation work closed each sprint. Screen counts, meeting attendance and certifications describe output or activity, not the accumulation or repayment of debt.

Question 45Delivery and project leadership

A client asks the Tech Lead to skip the architecture review to hit a demo date. What response best protects delivery quality while keeping the relationship constructive?

  1. Agree to a time-boxed, focused review of only the highest-risk decisions before the demo Correct answer.
  2. Escalate to the client's CEO before replying to the request
  3. Cancel the demo and move the date without discussion
  4. Skip the review entirely and document the decision after go-live

Explanation

A time-boxed review limited to the highest-risk architectural decisions preserves the essential safeguard while respecting the demo deadline. This is a negotiated compromise rather than an all-or-nothing stance. Skipping review or unilaterally moving the date damages either quality or trust.

Question 46Delivery and project leadership

Which responsibility belongs specifically to the OutSystems Tech Lead rather than to the project manager?

  1. Owning the technical design decisions and enforcing platform best practices Correct answer.
  2. Approving the client's annual budget
  3. Managing the client's HR onboarding
  4. Negotiating contract payment terms

Explanation

The Tech Lead owns technical direction: architecture, platform best practices, code quality and technical risk. Budget approval, contract terms and HR onboarding are commercial or administrative responsibilities outside the technical leadership role.

Question 47Delivery and project leadership

An OutSystems team repeatedly deploys to production with manual, undocumented steps. What should the Tech Lead introduce first?

  1. A rule that only the Tech Lead may deploy
  2. A documented, repeatable deployment checklist aligned with the platform's lifecycle tooling Correct answer.
  3. A request to migrate the application to a different low-code platform
  4. A freeze on all production releases for six months

Explanation

The first step is to make the deployment process explicit and repeatable, using a documented checklist aligned with the platform's lifecycle and deployment tooling. That creates a baseline others can follow and audit. Freezing releases or concentrating deployment in one person addresses symptoms without building capability.

Question 48Delivery and project leadership

When onboarding a new developer to an OutSystems squad, which action gives the fastest path to productive, standards-compliant contributions?

  1. Let them explore the codebase alone for two weeks without guidance
  2. Give them only the user manual and no code access
  3. Assign them the most complex integration story immediately
  4. Pair them with a senior developer on a small, well-scoped story with review feedback Correct answer.

Explanation

Pairing on a small, well-scoped story with structured review feedback exposes the newcomer to real conventions and platform patterns while keeping risk low. Throwing someone into the hardest story or leaving them isolated produces rework and slow ramp-up.

Question 49Delivery and project leadership

A squad's OutSystems code review process has become a rubber stamp. Which change most effectively restores its value?

  1. Require a minimum number of comments per review to prove effort
  2. Introduce a focused checklist covering naming, error handling, security and platform patterns Correct answer.
  3. Remove reviews and rely on testing only
  4. Move reviews to a monthly batch after all code is merged

Explanation

A focused checklist gives reviewers concrete criteria tied to platform standards, which restores substantive scrutiny. Comment quotas encourage noise, batch reviews arrive too late to prevent problems, and removing reviews discards a key quality control.

Question 50Delivery and project leadership

Which approach best manages technical risk when a delivery depends on a third-party OutSystems Forge component with limited maintenance?

  1. Ignore its maintenance status because Forge components are always supported
  2. Adopt it everywhere immediately to save development time
  3. Fork or wrap it, assess its support status, and isolate the dependency behind an abstraction Correct answer.
  4. Copy its source into every module independently

Explanation

Third-party components with uncertain maintenance should be assessed for support status and isolated behind an abstraction so they can be replaced or patched without rippling through the codebase. Blind adoption or scattered copies multiply risk and make future replacement expensive.