I85PREP
⌘ K
OutSystems Professional DevOps Engineer study materials
OutSystems Professional DevOps Engineer study resources

OutSystems Professional DevOps Engineer practice questions

One question at a time. Build your OutSystems Professional DevOps Engineer 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 1Continuous Integration and Delivery (CI/CD) Pipelines

In an OutSystems CI/CD pipeline, which artifact does the platform generate from a completed development environment so that it can be deployed to the next stage?

  1. A signed application package (solution) built by the platform's deployment controller Correct answer.
  2. A zip archive of only the eSpace source files without compiled references
  3. A raw SQL dump of the environment's platform database
  4. A Docker image produced by the developer's local machine

Explanation

OutSystems builds a deployment package from the source environment through the platform's deployment controller, and that package carries the compiled modules plus their dependencies. The package is what the lifecycle management console uploads and deploys to the target environment, so it is the unit promoted across pipeline stages.

Question 2Continuous Integration and Delivery (CI/CD) Pipelines

Which OutSystems component is used to define the sequence of environments, the deployment steps, and the automated gates for an application's lifecycle?

  1. Service Studio's module tree
  2. The eSpace's server-side action flow
  3. The LifeTime deployment plan for the application Correct answer.
  4. The Service Center's tenant configuration

Explanation

LifeTime deployment plans define which environments an application moves through, in what order, and which steps or approvals are attached to each transition. They are the central configuration object for a CI/CD pipeline in OutSystems.

Question 3Continuous Integration and Delivery (CI/CD) Pipelines

A team wants every commit to trigger an automatic build and deployment to a quality environment. Which OutSystems capability should they configure to achieve this?

  1. Service Studio's 1-Click Publish to the quality environment
  2. Manual LifeTime deployment with an approval step
  3. Continuous integration triggers configured in the deployment plan Correct answer.
  4. Scheduled database backups of the quality environment

Explanation

OutSystems supports continuous integration by letting a deployment plan react to repository commits and start the build/deploy automatically. This removes manual initiation while still running the configured validation steps.

Question 4Continuous Integration and Delivery (CI/CD) Pipelines

What is the primary purpose of running automated tests as a quality gate in an OutSystems deployment plan?

  1. To block promotion when functional or regression tests fail Correct answer.
  2. To compile the eSpace modules before packaging
  3. To increase the size of the deployment package
  4. To replace the need for any environment configuration

Explanation

A quality gate evaluates test results and stops the promotion when the configured criteria are not met. This prevents defective builds from reaching later environments. Compilation and packaging happen as part of the build step, independently of the gate decision.

Question 5Continuous Integration and Delivery (CI/CD) Pipelines

In OutSystems lifecycle management, what distinguishes a 'tag' from a regular deployment?

  1. A tag is a named snapshot of an application version that can be deployed later Correct answer.
  2. A tag permanently deletes the previous application version
  3. A tag runs only in the development environment
  4. A tag bypasses all environment configuration

Explanation

Tagging captures a specific application version as a labeled snapshot that can be deployed to other environments on demand. It is used to mark release candidates or versions that must be reproducible later.

Question 6Continuous Integration and Delivery (CI/CD) Pipelines

Which item must be configured in LifeTime before an application can be deployed from Development to Quality?

  1. An external source control repository for each module
  2. A registered environment with a valid deployment role for the target Correct answer.
  3. A separate database server for the build step
  4. A second Service Studio license for each developer

Explanation

LifeTime deploys only to environments that are registered and reachable, and the user or service account must hold the appropriate deployment permissions. Without a registered target environment the deployment plan cannot execute.

Question 7Continuous Integration and Delivery (CI/CD) Pipelines

What role does an automated code-review or static-analysis step play in an OutSystems CI/CD pipeline?

  1. It replaces the need for a build step
  2. It automatically fixes all detected defects
  3. It detects issues such as unused references or architectural violations before deployment Correct answer.
  4. It provisions new environments dynamically

Explanation

Static analysis inspects the model for patterns like unused references, forbidden dependencies, or architecture violations and reports them early. The findings can feed a quality gate so that problems are addressed before promotion.

Question 8Continuous Integration and Delivery (CI/CD) Pipelines

Why should deployment steps in a pipeline be idempotent?

  1. So that approvals are no longer required
  2. So that rerunning a failed deployment produces the same end state without duplication Correct answer.
  3. So that each run creates a new environment
  4. So that the pipeline can skip the build step

Explanation

Idempotent steps can be retried safely, which matters when a deployment fails partway and must be rerun. The target ends in the same known state regardless of how many times the step executes.

Question 9Continuous Integration and Delivery (CI/CD) Pipelines

A deployment to Quality fails because a required site property exists in Development but is unset in Quality. Which practice best prevents this class of failure?

  1. Deploying directly to Production to skip Quality
  2. Maintaining environment-specific configuration values per environment in LifeTime Correct answer.
  3. Deleting the site property before deployment
  4. Disabling the quality gate for configuration checks

Explanation

LifeTime lets teams define environment-specific values for settings such as site properties so each environment receives the right configuration. Managing these per environment avoids missing or incorrect values during promotion.

Question 10Continuous Integration and Delivery (CI/CD) Pipelines

When promoting an application that depends on a shared module also modified in Development, what does the OutSystems deployment controller do by default?

  1. Deploys only the top-level module and ignores dependencies
  2. Requires the developer to manually recompile each dependency
  3. Blocks any deployment that includes shared modules
  4. Includes the changed dependencies in the package so the target is consistent Correct answer.

Explanation

The deployment controller resolves dependencies and includes the changed ones so the target environment receives a consistent set of modules. This prevents version mismatches between an application and the shared modules it references.

Question 11Continuous Integration and Delivery (CI/CD) Pipelines

A team wants to run automated UI tests against the Quality environment after each deployment. Which consideration is most important for reliable results?

  1. Ensuring test data and environment state are reset or seeded deterministically Correct answer.
  2. Disabling logging in the Quality environment
  3. Increasing the number of approval steps
  4. Running the tests only on the developer's laptop

Explanation

Automated tests are only trustworthy when their starting data and state are controlled, so seeding or resetting data makes runs repeatable. Without deterministic state, results vary and gates become unreliable.

Question 12Continuous Integration and Delivery (CI/CD) Pipelines

Which strategy best supports rollback if a Production deployment introduces a critical defect?

  1. Overwriting the Production database before every deployment
  2. Removing all previous application versions from LifeTime
  3. Tagging the last known good version so it can be redeployed quickly Correct answer.
  4. Disabling the deployment plan after release

Explanation

Tagging a known good version preserves a reproducible artifact that can be redeployed if a release fails. This shortens recovery time compared with rebuilding from source under pressure.

Question 13Continuous Integration and Delivery (CI/CD) Pipelines

What is the effect of configuring a manual approval step between Quality and Production in a deployment plan?

  1. The deployment skips Quality automatically
  2. The application is rebuilt from scratch after approval
  3. The deployment pauses until an authorized user approves the transition Correct answer.
  4. The deployment runs without any validation

Explanation

A manual approval step holds the promotion until a user with the right permissions authorizes it. This provides a governance checkpoint before changes reach Production.

Question 14Continuous Integration and Delivery (CI/CD) Pipelines

A pipeline must deploy the same application to two regions with different endpoint URLs. Which OutSystems mechanism is designed for this?

  1. Hardcoding the URLs in a server action
  2. Duplicating the module for each region
  3. Using environment-specific configuration values in the deployment plan Correct answer.
  4. Creating a separate application for each region

Explanation

Environment-specific configuration lets a single application package receive different values per target environment. This avoids maintaining duplicated modules or hardcoded values.

Question 15Continuous Integration and Delivery (CI/CD) Pipelines

Why is it recommended to keep the build and deployment steps in the pipeline rather than performing 1-Click Publish to shared environments?

  1. Because shared environments cannot run published applications
  2. Because 1-Click Publish deletes the module after publishing
  3. Because the pipeline enforces consistent validation, packaging, and auditability Correct answer.
  4. Because 1-Click Publish is slower than the pipeline

Explanation

Publishing directly to a shared environment bypasses the validation, gating, and traceability that the pipeline provides. The pipeline ensures every promotion follows the same controlled process and is recorded.

Question 16Continuous Integration and Delivery (CI/CD) Pipelines

A team notices that a deployment succeeds in Quality but fails in Production with a missing dependency. Which root cause is most likely?

  1. The application package was built on a developer workstation
  2. The deployment plan has too many approval steps
  3. The Production environment has a different set of published dependencies than Quality Correct answer.
  4. The quality gate was configured to run tests

Explanation

Differences in the published dependency set between environments cause a package to resolve correctly in one and fail in another. Aligning dependency versions across environments prevents this mismatch.

Question 17Continuous Integration and Delivery (CI/CD) Pipelines

Which practice most directly reduces the risk of configuration drift between Quality and Production in an OutSystems pipeline?

  1. Manually editing settings in Production after each release
  2. Allowing developers to publish directly to Production
  3. Rebuilding the application separately in each environment
  4. Promoting the same tagged package through all environments with per-environment configuration Correct answer.

Explanation

Promoting one tagged package keeps the code identical across environments while configuration supplies the environment-specific values. This eliminates code drift and makes differences explicit and controlled.

Question 18Continuous Integration and Delivery (CI/CD) Pipelines

What does the OutSystems deployment controller validate before applying a package to a target environment?

  1. That the application has no users
  2. That the database is empty
  3. That the target environment meets the package's requirements and dependencies Correct answer.
  4. That the developer has logged into Service Studio

Explanation

Before applying a package, the controller checks that the target satisfies the package's requirements and that dependencies can be resolved. Failing these checks stops the deployment with a clear error.

Question 19Continuous Integration and Delivery (CI/CD) Pipelines

A pipeline uses an automated gate that fails when code-analysis findings exceed a threshold. Which design choice makes this gate most useful?

  1. Defining severity-based thresholds and reporting findings with actionable detail Correct answer.
  2. Running the analysis only after Production deployment
  3. Setting the threshold to allow all findings
  4. Removing the gate when developers complain

Explanation

Severity-based thresholds let teams focus on the findings that matter while reporting actionable detail so developers can fix them. This balances quality enforcement with practical adoption.

Question 20Continuous Integration and Delivery (CI/CD) Pipelines

Which characteristic makes a deployment plan suitable for a hotfix path that bypasses some validation stages?

  1. A separate plan with a reduced but still controlled set of steps and approvals Correct answer.
  2. Publishing directly from a developer's environment
  3. Deleting the main deployment plan
  4. Disabling all environments in LifeTime

Explanation

A dedicated hotfix plan can shorten the path while retaining essential controls such as approval and targeted testing. This preserves governance even when speed is required.

Question 21Continuous Integration and Delivery (CI/CD) Pipelines

A team wants traceability from a Production release back to the exact source changes. Which combination best provides this in OutSystems?

  1. Storing the package on a developer's machine
  2. Relying on screenshots of Service Studio
  3. Tagging the release version and linking it to the source control commit Correct answer.
  4. Recording the deployment time only

Explanation

A tag identifies the deployed version while the linked commit identifies the source changes, together giving end-to-end traceability. Neither element alone provides the full chain from code to release.

Question 22Continuous Integration and Delivery (CI/CD) Pipelines

During a deployment, a step fails after partially applying changes. Which pipeline property most limits the impact of this failure?

  1. Increasing the number of parallel deployments
  2. Skipping the quality gate on retry
  3. Transactional or compensating behavior that restores a consistent state Correct answer.
  4. Removing logging to speed up retries

Explanation

Transactional or compensating behavior ensures a failed step does not leave the environment in a half-applied state. This makes retries safe and keeps the target consistent.

Question 23Continuous Integration and Delivery (CI/CD) Pipelines

An organization runs multiple applications that share a common library module. What is the main CI/CD risk of deploying the shared module independently of its consumers?

  1. The shared module will be automatically deleted
  2. Consumers will lose their deployment plans
  3. Consumers may be running against an incompatible version of the shared module Correct answer.
  4. The shared module cannot be tagged

Explanation

Deploying a shared module without its consumers can leave them bound to an incompatible version, causing runtime or deployment failures. Coordinating the release of the module with its consumers avoids this mismatch.

Question 24Continuous Integration and Delivery (CI/CD) Pipelines

Which approach best ensures that automated tests in the pipeline reflect the actual deployed build rather than stale artifacts?

  1. Running tests only before the build step
  2. Running tests against the environment immediately after the package is deployed Correct answer.
  3. Reusing test results from a previous release
  4. Running tests against a developer's local environment

Explanation

Testing the environment right after the package is applied ensures the tests exercise the exact build being promoted. Testing elsewhere or reusing old results risks validating something other than the deployed artifact.

Question 25Continuous Integration and Delivery (CI/CD) Pipelines

A deployment plan includes a step that runs a database migration script. Why should this step be designed to be re-runnable?

  1. Because the platform requires migrations to be written in SQL
  2. Because a retried deployment may execute the step again and must not corrupt data Correct answer.
  3. Because migrations replace the need for application packaging
  4. Because migrations must run in every environment simultaneously

Explanation

Retries after a failure can re-execute a migration step, so it must detect prior application and avoid duplicating changes. Re-runnable migrations keep the database consistent across retries.

Question 26Continuous Integration and Delivery (CI/CD) Pipelines

In an OutSystems CI/CD pipeline, which artifact is produced by the build step and then transported to the next environment?

  1. A solution package (.osp) containing the compiled application and its dependencies Correct answer.
  2. A database backup of the Development environment taken at build time
  3. A LifeTime audit log export describing the deployment history
  4. A raw source archive of the module definitions in OML text form

Explanation

The build step in an OutSystems pipeline compiles the application and produces a solution package that the deployment controller applies to the target environment. The package is the transportable unit, so the target environment does not need to recompile source. Source archives, database backups, and audit exports are not what the deployment controller applies.

Question 27Continuous Integration and Delivery (CI/CD) Pipelines

Which OutSystems component orchestrates deployment plans and moves applications between environments?

  1. LifeTime Correct answer.
  2. Integration Studio
  3. Service Center
  4. The OutSystems IDE debugger

Explanation

LifeTime is the console that manages environments, deployment plans, and application promotion across the infrastructure. Service Center is scoped to a single environment's configuration, and the debugger and Integration Studio are development tools. Deployment orchestration therefore belongs to LifeTime.

Question 28Continuous Integration and Delivery (CI/CD) Pipelines

What is the primary purpose of tagging an application version in LifeTime before promoting it?

  1. To compress the package so deployments transfer faster
  2. To lock the module so developers can no longer edit it
  3. To automatically grant end users access to the new version
  4. To create a named reference point that can be identified and redeployed later Correct answer.

Explanation

A tag records a named, immutable reference to a specific application version at a point in time. That reference supports traceability, auditing, and redeploying a known-good build if a later release fails. Tags do not compress packages, grant user access, or lock modules against editing.

Question 29Continuous Integration and Delivery (CI/CD) Pipelines

In an OutSystems pipeline, what does the deployment controller do when it applies a package to the target environment?

  1. It copies all Development data into the target database
  2. It disables the target environment until a manual approval is recorded
  3. It validates dependencies and then publishes the packaged modules in the correct order Correct answer.
  4. It recompiles the application from the Development source to match the target

Explanation

The deployment controller checks that required dependencies are satisfied and then publishes the modules in a sequence that respects their references. It applies the already-built package rather than recompiling from source, and it does not copy environment data. Manual approvals are handled by the deployment plan before the controller runs.

Question 30Continuous Integration and Delivery (CI/CD) Pipelines

Which environment is typically the first target in a standard OutSystems promotion path after Development?

  1. The LifeTime staging cache
  2. A second Development environment
  3. Production
  4. Quality Correct answer.

Explanation

The standard promotion path moves an application from Development to Quality, then to Production. Quality is the first target where the built package is validated before release. Production comes later, and a second Development environment or a LifeTime cache is not part of the promotion path.

Question 31Continuous Integration and Delivery (CI/CD) Pipelines

What does the OutSystems platform's built-in impact analysis help a CI/CD team determine before deployment?

  1. How much disk space the package will consume in Production
  2. Which developers last edited each module
  3. The expected response time of the application after release
  4. Which other applications and modules reference the modules being changed Correct answer.

Explanation

Impact analysis reports the references between modules and applications, so the team knows which consumers may be affected by a change. That information guides dependency handling and whether additional applications must be included in the deployment. Package size, edit history, and performance are separate concerns.

Question 32Continuous Integration and Delivery (CI/CD) Pipelines

Why should the OutSystems pipeline build the package from a committed, version-controlled codebase rather than from uncommitted local changes?

  1. Because LifeTime rejects packages that contain local edits
  2. Because uncommitted changes cannot be compiled by the platform
  3. Because version control automatically runs the automated tests
  4. Because the build must be reproducible and traceable to a known commit Correct answer.

Explanation

Building from a known commit makes each build reproducible and lets the team trace a release back to the exact source state. Uncommitted local edits make the build non-reproducible and impossible to audit. The platform can compile such edits, and version control does not itself execute tests or trigger LifeTime rejection.

Question 33Continuous Integration and Delivery (CI/CD) Pipelines

Which item is required for a pipeline to authenticate against an OutSystems environment and invoke deployment operations programmatically?

  1. An anonymous public endpoint on the deployment controller
  2. A valid platform service account with the appropriate permissions and an API credential Correct answer.
  3. A developer's personal IDE session token
  4. A database administrator login for the target environment

Explanation

Programmatic deployment uses a service account with the right permissions and an API credential so the pipeline can authenticate to LifeTime and the environments. A database administrator login, an IDE session token, or an anonymous endpoint does not provide the required authorized API access.

Question 34Continuous Integration and Delivery (CI/CD) Pipelines

A pipeline must fail fast when a build produces compilation errors. Where should that check be placed?

  1. Immediately after the build step, before any deployment stage runs Correct answer.
  2. Only in the final manual approval step
  3. Inside the automated UI test suite that runs against Production
  4. After the Production deployment so the release is confirmed first

Explanation

Placing the compilation check right after the build stops the pipeline before any environment is touched, which saves time and avoids deploying a broken package. Later stages such as UI tests or approvals should not be the first line of defense against a build failure. Failing fast keeps defective artifacts out of Quality and Production.

Question 35Continuous Integration and Delivery (CI/CD) Pipelines

A team wants each commit to trigger a pipeline run that builds and deploys to Quality automatically. Which configuration supports this requirement?

  1. A repository webhook or trigger that starts the pipeline on each push Correct answer.
  2. An email notification sent to the release manager on each commit
  3. A scheduled nightly deployment plan that runs regardless of commits
  4. A manual button in Service Center that a developer presses after each commit

Explanation

Continuous integration requires an automated trigger tied to source changes, typically a webhook from the repository that starts the pipeline on each push. Scheduled runs, manual buttons, and email notifications do not provide per-commit automation. The trigger is what connects a commit event to the pipeline execution.

Question 36Continuous Integration and Delivery (CI/CD) Pipelines

What is the main benefit of running automated unit and integration tests in the Quality stage rather than only in Development?

  1. Tests eliminate the need for any manual approval before Production
  2. Tests validate the deployed package in an environment that resembles Production Correct answer.
  3. Tests run faster because Quality has more compute capacity
  4. Tests remove the requirement to tag application versions

Explanation

Running tests against the deployed package in Quality verifies behavior in an environment configured like Production, catching environment-specific issues. Speed and capacity are not the goal, and tests complement rather than replace approvals or version tagging. The value lies in validating the actual deployed artifact in a realistic setting.

Question 37Continuous Integration and Delivery (CI/CD) Pipelines

A pipeline deploys an application that consumes a shared module also changed in the same release. What should the pipeline ensure?

  1. The shared module and its consumers are deployed together in a dependency-respecting order Correct answer.
  2. The shared module is deployed only after all consumers are already running
  3. Each consumer is deployed to a different environment to isolate risk
  4. The shared module is excluded from the package to reduce its size

Explanation

When a shared module changes, its consumers must be deployed in the same release in an order that satisfies their references. Deploying consumers first or excluding the shared module would leave references broken or stale. The deployment controller uses dependency information to sequence the modules correctly.

Question 38Continuous Integration and Delivery (CI/CD) Pipelines

What is the effect of storing environment-specific values such as endpoint URLs in LifeTime environment settings instead of hardcoding them in modules?

  1. The values become immutable and cannot be changed after deployment
  2. The same package can be promoted across environments without rebuilding Correct answer.
  3. The application no longer needs to be compiled before deployment
  4. The deployment controller skips validation of those modules

Explanation

Environment settings externalize values that differ per environment, so a single built package can be promoted unchanged through Quality and Production. Compilation is still required, values remain editable by administrators, and validation still applies. This separation is a core technique for avoiding configuration drift.

Question 39Continuous Integration and Delivery (CI/CD) Pipelines

A pipeline step runs a smoke test after deployment and fails if the application's health endpoint does not respond. What does this gate protect against?

  1. Developers committing code without a code review
  2. Promoting a release that deployed but is not actually functional Correct answer.
  3. Packages that are too large for the deployment controller
  4. Unauthorized users accessing the LifeTime console

Explanation

A post-deployment smoke test confirms the deployed application is reachable and functional before promotion continues. It catches deployments that technically succeeded but left the application unusable. Code review, package size, and console access are unrelated concerns handled elsewhere.

Question 40Continuous Integration and Delivery (CI/CD) Pipelines

Which practice best keeps the pipeline definition itself under control as the team grows?

  1. Letting each developer maintain a personal copy of the pipeline script
  2. Storing the pipeline configuration in version control and reviewing changes to it Correct answer.
  3. Recreating the pipeline from scratch for every release
  4. Editing the pipeline directly in the CI server UI without review

Explanation

Treating pipeline configuration as code places it under version control and peer review, so changes are auditable and reproducible. Personal copies, unreviewed UI edits, and frequent recreation introduce inconsistency and drift. Reviewed, versioned configuration is what keeps the pipeline reliable as more people contribute.

Question 41Continuous Integration and Delivery (CI/CD) Pipelines

A deployment to Quality succeeds, but the automated tests then fail because a required timer or scheduled job did not run. Which pipeline improvement addresses this class of issue?

  1. Deploying directly to Production to avoid the Quality stage
  2. Removing the automated tests so the pipeline can proceed
  3. Increasing the timeout of the manual approval step
  4. Adding a step that seeds or triggers required background jobs before running tests Correct answer.

Explanation

Tests that depend on timers or scheduled jobs need those jobs to be in a known state, so the pipeline should seed or trigger them before testing. Removing tests or skipping Quality hides the defect rather than fixing it. Adjusting an approval timeout or bypassing Quality does not make the background jobs run.

Question 42Continuous Integration and Delivery (CI/CD) Pipelines

What is the recommended way to handle database schema changes as part of an OutSystems deployment pipeline?

  1. Include them as managed entities deployed with the package and, where needed, run idempotent migration scripts Correct answer.
  2. Store schema changes in a separate repository that the pipeline never deploys
  3. Skip schema changes in Quality and apply them only in Production
  4. Apply them manually after deployment by a database administrator

Explanation

OutSystems entity model changes are deployed with the package, and any additional data migration should run as an idempotent script in the pipeline. Manual post-deployment changes, skipping Quality, or keeping changes outside the pipeline all risk drift and inconsistency. Keeping schema evolution inside the pipeline preserves reproducibility.

Question 43Continuous Integration and Delivery (CI/CD) Pipelines

A team wants the pipeline to notify the on-call engineer when a Production deployment fails. Which design is most appropriate?

  1. A comment added to the source commit by the developer after noticing the failure
  2. A dashboard that is refreshed once per week
  3. A notification step in the pipeline that fires on failure and includes the failing stage and logs Correct answer.
  4. A daily report emailed to the whole company summarizing all deployments

Explanation

Failure notifications should be immediate, targeted at the responsible on-call engineer, and include diagnostic context such as the failing stage and logs. Broad daily reports, manual commit comments, and weekly dashboards are too slow or too diffuse to support rapid response. The pipeline itself is the right place to trigger the alert.

Question 44Continuous Integration and Delivery (CI/CD) Pipelines

An organization wants to run parallel pipeline runs for different feature branches without them interfering. Which practice supports this?

  1. Sharing a single Quality environment for all branches simultaneously
  2. Deploying every branch directly to Production for validation
  3. Disabling the build step for feature branches
  4. Using isolated build workspaces and separate Quality slots or environments per run Correct answer.

Explanation

Parallel runs need isolation so that one branch's build and deployment does not corrupt another's. Isolated workspaces and separate Quality slots or environments provide that separation. Sharing one Quality environment, skipping builds, or deploying branches to Production introduces interference and risk.

Question 45Continuous Integration and Delivery (CI/CD) Pipelines

A pipeline deployment to Production is blocked because a module was changed in Development after the package was built. What does this situation most likely indicate?

  1. The application has no automated tests configured
  2. The package was built from a commit that no longer matches the current Development state Correct answer.
  3. The deployment controller is misconfigured to reject all packages
  4. The Production environment has insufficient disk space

Explanation

A mismatch between the built package and the current Development state signals that source changed after the build, breaking traceability. The correct response is to rebuild from the intended commit rather than to force the stale package through. Disk space, controller misconfiguration, and missing tests are unrelated to this mismatch.

Question 46Continuous Integration and Delivery (CI/CD) Pipelines

A pipeline supports both a standard release path and an emergency hotfix path. Which design keeps the hotfix path safe while still being faster?

  1. Skipping all automated tests on the hotfix path to save time
  2. Removing version tagging so the hotfix cannot be traced
  3. Deploying the hotfix directly to Production without building a package
  4. Retaining automated build and smoke tests but allowing a reduced approval chain Correct answer.

Explanation

A safe hotfix path keeps the automated checks that catch defects, such as build and smoke tests, while compressing the human approval chain. Dropping all tests, removing tags, or deploying without a package sacrifices traceability and quality for speed. The goal is to shorten the path without removing essential safeguards.

Question 47Continuous Integration and Delivery (CI/CD) Pipelines

A shared library module is consumed by five applications. The team wants to release a breaking change to that library. Which pipeline approach minimizes disruption?

  1. Deploy the library change to Production first and update consumers later
  2. Bypass Quality for the library because it contains no user interface
  3. Version and test the library change against all consumers in Quality, then coordinate a staged rollout Correct answer.
  4. Deploy only one consumer and assume the others are unaffected

Explanation

A breaking change to a widely consumed library requires validating it against every consumer and coordinating the rollout so no application is left referencing an incompatible version. Deploying the library first, testing a single consumer, or skipping Quality would expose consumers to breakage. Staged, validated rollout limits the blast radius.

Question 48Continuous Integration and Delivery (CI/CD) Pipelines

A pipeline must guarantee that a failed Production deployment can be reversed quickly. Which combination best supports this?

  1. Deleting old packages immediately after each release to save space
  2. Tagging the last known-good version and keeping the previous package available for redeployment Correct answer.
  3. Disabling the deployment controller's validation to speed up rollback
  4. Relying on developers to remember the previous configuration

Explanation

Fast rollback depends on having a tagged, known-good version and its package available to redeploy. Relying on memory, deleting old packages, or disabling validation undermines the ability to restore service safely. Retaining tagged packages is what makes reversal quick and reliable.

Question 49Continuous Integration and Delivery (CI/CD) Pipelines

A team observes that automated tests pass in Quality but the same tests fail after the Production deployment. Which factor most likely explains the difference?

  1. Production has different environment settings, data, or integrations than Quality Correct answer.
  2. Quality runs a newer version of the OutSystems platform
  3. The tests are written in the wrong programming language
  4. The pipeline runs tests only in Production by design

Explanation

Differences in environment settings, data, or external integrations between Quality and Production commonly cause tests to behave differently after promotion. Platform version differences are possible but less likely and would be a configuration issue to verify. The core lesson is to align environment configuration so tests reflect Production conditions.

Question 50Continuous Integration and Delivery (CI/CD) Pipelines

A pipeline deploys several applications that share a common module. Which sequencing strategy does the OutSystems deployment controller apply?

  1. Alphabetical order by application name
  2. Dependency order, deploying referenced modules before their consumers Correct answer.
  3. Reverse dependency order, deploying consumers before referenced modules
  4. Random order to distribute load across the environment

Explanation

The deployment controller resolves the reference graph and publishes referenced modules before the applications that consume them. Alphabetical, random, or reverse ordering would break references or force unnecessary recompilation. Dependency ordering is what keeps a multi-application deployment consistent.