DevOps / Bamboo: Continuous Integration & Deployment Interview Questions

Bamboo is Atlassian's continuous integration and continuous delivery (CI/CD) server. It automates the process of building, testing, and deploying software every time a developer pushes code, so problems surface within minutes instead of at release time.

It ties directly into Bitbucket for source control and Jira for issue tracking, which is its main selling point over generic CI tools — a failed build or a completed deployment shows up right on the linked Jira ticket.

Worth knowing for interviews: Bamboo Server was discontinued in February 2024, so it now ships only as Bamboo Data Center. Atlassian closed new-customer sales in March 2026, and existing instances are on a sunset path toward 2029, so most Bamboo questions today are really about maintaining or migrating off existing installs.

Bamboo's job is to remove the manual steps between "code is written" and "code is running in production." It watches a repository, and whenever new commits land it automatically compiles the code, runs the test suite, packages the result, and can push that package on to a target environment.

The value is speed and consistency: every change goes through the exact same build and test steps, so a broken build is caught within minutes rather than discovered by a tester days later.

In practice this covers three purposes:

1. Continuous integration — merge and validate code frequently.
2. Continuous delivery — produce a release-ready artifact automatically.
3. Continuous deployment — push that artifact to an environment with minimal manual intervention.

Beyond basic build automation, a handful of features come up repeatedly in Bamboo interviews because they distinguish it from plain scripts or generic CI tools.

• Bamboo Specs — define plans as code (Java DSL or YAML) instead of clicking through the UI.
• Plan branches — automatic, isolated CI for feature branches.
• Deployment projects — a separate release pipeline with per-environment permissions.
• Elastic Bamboo — agents that spin up and shut down on AWS EC2 based on queue demand.
• Native Jira and Bitbucket integration, so build and deployment status appear directly on issues and pull requests.
• Parallel job execution across a pool of build agents.

None of these is unique in the CI world individually, but the tight coupling with Jira/Bitbropoint is what teams usually cite as the reason to pick Bamboo over a standalone tool.

A plan is the core build configuration in Bamboo — it's the container that says "here's a repository, here's how to build it, and here's what to do with the result."

Structurally a plan sits inside a project and is broken down into stages, which contain jobs, which contain tasks:

Project
  └── Plan
        └── Stage
              └── Job
                    └── Task

A single plan typically maps to one repository or one buildable component. For example, a "Payments API" plan would define the checkout step, a Maven build task, a unit-test task, and an artifact-packaging task, all wired to run whenever someone pushes to that repository.

A stage is a logical checkpoint inside a plan — it groups one or more jobs that should be treated as a single phase, such as "Build," "Test," or "Deploy Artifacts."

Stages always run sequentially: the next stage doesn't start until every job in the current stage has finished successfully. Jobs within the same stage, by contrast, can run in parallel if enough agents are available.

This two-level structure is what lets Bamboo express "run unit tests and lint checks at the same time, but only start the integration-test stage once both finish."

A job is a collection of tasks that Bamboo schedules and runs on a single build agent as one unit. If a stage contains three jobs, Bamboo will try to run all three at the same time, each on its own agent, as long as agents with matching capabilities are free.

Because a job is bound to one agent, everything inside it — checkout, compile, test — executes on that same machine in sequence. Splitting work into more jobs (rather than more tasks in one job) is how you get real parallelism, for example running the frontend build and backend build as separate jobs in the same stage.

A task is the smallest executable unit in Bamboo — a single step such as checking out source, running a Maven build, executing a shell script, or parsing test results. Tasks inside a job always run in order, one after another, on the same agent.

Common built-in task types include:

By default, if one task fails, the remaining tasks in that job are skipped unless the task is explicitly marked to run "even when the job fails" (used for cleanup steps).

A build agent is the worker process that actually executes a job's tasks — checking out code, compiling, running tests. The Bamboo server itself never runs build work directly; it only schedules jobs onto agents and stores the results.

Each agent advertises a set of capabilities (installed JDKs, executables, environment variables), and Bamboo only assigns a job to an agent whose capabilities satisfy that job's requirements. This is how the same server can support projects that need completely different toolchains, for example one job requiring Node 18 and another requiring .NET.

Bamboo distinguishes agents mainly by where they run and how they scale.

Most real deployments run zero or one local agent and scale out with remote agents (including Elastic Bamboo agents on EC2 for bursty workloads).

A project is purely an organizational folder that groups related plans together — it has no build logic of its own. Teams typically create one project per product, per service, or per team, and then put every plan for that product inside it.

Grouping matters mainly for permissions and navigation: you can grant a team admin rights over an entire project instead of configuring access plan by plan, and the project dashboard gives a single view of every plan's status.

A deployment project is a separate pipeline, distinct from a build plan, whose job is to take an already-built artifact and push it to one or more target environments such as Dev, Staging, or Production.

It's linked to a build plan as its artifact source, but it keeps its own history, its own permissions, and its own environment-specific tasks. That separation matters because who is allowed to build code and who is allowed to release to production are usually different sets of people, and Bamboo models that directly through separate deployment permissions per environment.

An environment is a named target inside a deployment project — typically something like Dev, QA, Staging, or Production. Each environment has its own sequence of deployment tasks (copy artifact, run install script, restart service) and its own permission list controlling who can trigger a release to it.

Because permissions are per-environment, it's common to let any developer deploy to Dev freely while restricting Production deploys to a release manager or requiring a manual approval step before that environment's tasks run.

Plan branches let Bamboo automatically create a lightweight copy of a plan's build configuration for every branch in the linked repository, so a feature branch gets its own isolated CI runs without anyone hand-configuring a new plan.

Key behavior interviewers look for:

• Branches can be detected automatically (based on a naming pattern or VCS trigger) or created manually.
• Each branch plan inherits the parent plan's stages/jobs/tasks by default, though individual settings can be overridden per branch.
• Branch plans can be configured to clean up automatically once the branch is merged or deleted, avoiding clutter.

This is what makes pull-request-driven workflows practical: every PR branch gets build and test feedback before it's merged, with no manual plan creation.

A trigger is the mechanism that decides when a plan should start running. Bamboo supports several trigger types, and picking the right one is a common interview point.

In modern setups, webhook-based repository triggers are preferred over polling because they avoid unnecessary load and give near real-time build starts.

Bamboo connects directly to the major version control systems used in enterprise environments, most commonly through Bitbucket Server/Data Center but also via direct repository connections:

• Git (including Bitbucket, GitHub, and generic Git remotes) — the most common choice today.
• Mercurial
• Subversion (SVN)
• Perforce
• CVS — legacy support, rarely used in new setups.

For interview purposes, the practical answer is: any team already on Bitbucket gets the deepest integration (pull request builds, commit-linked issues), while other VCS types work through a generic repository connection with fewer built-in extras.

Bamboo Specs let you define a plan's entire configuration — stages, jobs, tasks, triggers, permissions — as code, written in a Java DSL or YAML, and stored alongside the application in the same repository instead of being clicked together in the Bamboo UI.

The purpose is to bring the same discipline used for application code to build configuration: it can be code-reviewed in a pull request, versioned, rolled back, and reused across similar plans, instead of living as an undocumented set of UI settings that only one admin remembers how to change.

version: 2
plan:
  project-key: PAY
  key: PAYAPI
  name: Payments API
stages:
  - Build:
      jobs:
        - Compile and Test

An artifact is any file (or set of files) that a job produces and marks for reuse — a compiled JAR, a Docker image tag file, a test report, or an installer package. Once defined, Bamboo stores that file so it can be downloaded, inspected, or passed forward to later stages or to a deployment project.

Artifacts are what actually connects a build plan to a deployment project: the deployment project doesn't rebuild the code, it takes the artifact the plan already produced and ships that exact, already-tested file to an environment.

Creating a plan is a short, fixed sequence in the Bamboo UI:

1. Select an existing project, or create a new one to hold the plan.
2. Click "Create plan," give it a name and a plan key.
3. Link a repository (Bitbucket, Git, or another supported VCS).
4. Add stages, then jobs within each stage, then tasks within each job (checkout, build, test, package).
5. Configure a trigger, typically a repository push trigger.
6. Enable the plan and run it manually the first time to confirm the configuration works.

The same result can be achieved without touching the UI at all by committing a Bamboo Specs file to the repository, which Bamboo picks up and turns into a plan automatically — the preferred approach once a team has more than a handful of plans to maintain.

The short answer: Specs turn build configuration into a reviewable artifact instead of a set of clicks only one person remembers. A few concrete reasons teams switch:

• Version control — the plan definition lives in the same repo as the code, so a change to the pipeline goes through the same pull-request review as any other change.
• Reproducibility — spinning up an identical plan in a new project key or environment is a copy-paste of the Specs file, not a manual re-click of dozens of settings.
• Drift prevention — UI-configured plans tend to diverge silently over time as different admins tweak settings; Specs make every change explicit and diffable.
• Bulk changes — updating twenty similar plans (e.g. bumping a shared Docker tag) is a scripted edit instead of twenty manual UI sessions.

Plan plan = new Plan(project, "Payments API", "PAYAPI")
    .stages(new Stage("Build")
        .jobs(new Job("Compile", "JOB1")
            .tasks(new MavenTask().goal("clean install"))));

The UI still has a place for quick, throwaway experimentation, but production plans in mature teams are almost always Specs-driven.

Both are CI/CD servers that run pipelines against agents, but they diverge in licensing model, ecosystem, and how tightly they integrate with a broader toolchain.

The practical decision usually comes down to whether a team is already invested in the Atlassian ecosystem (favors Bamboo) or wants maximum flexibility and community plugins at no license cost (favors Jenkins). Given Atlassian closed new Bamboo sales in March 2026, new projects increasingly default to Jenkins, Bitbucket Pipelines, or another actively-growing CI tool.

Both come from Atlassian and both can build code pushed to Bitbucket, but they're built on very different operating models.

In short, Bamboo suits teams that need on-premises control, heavier governance, or already run Bitbucket Server/Data Center; Pipelines suits Bitbucket Cloud teams that want a zero-maintenance, YAML-only pipeline.

Once an application link connects a Bamboo instance to a Jira instance, build and deployment activity becomes visible directly inside Jira issues, without anyone manually cross-referencing systems.

• Commits that reference a Jira issue key (e.g. PROJ-123) automatically show up on that issue's development panel.
• Build status (passed/failed) and deployment status per environment appear on the same panel, so a reviewer can see "this fix built successfully and is deployed to Staging" without leaving Jira.
• Jira Software's release/versions view can pull deployment data from Bamboo to show what's actually live in each environment.
• Bamboo plans can be triggered based on Jira workflow transitions in more advanced setups (e.g. moving an issue to "Ready for QA").

This traceability — issue to commit to build to deployment — is the main reason teams already using Jira and Bitbucket historically chose Bamboo over a disconnected CI tool.

A local agent runs inside the Bamboo server process itself, which means every build it executes competes with the server for CPU, memory, and disk I/O — and a runaway build can degrade the whole Bamboo UI for every user.

Remote agents avoid that entirely by running on separate hardware, giving three concrete advantages:

1. Isolation — a heavy or misbehaving build can't starve the server.
2. Horizontal scale — adding capacity means adding more remote agents, not upgrading the server box.
3. Heterogeneous tooling — different remote agents can carry different capabilities (Node vs .NET vs mobile SDKs) so one server can support very different projects.

For anything beyond a small evaluation instance, remote agents are the recommended and expected production setup; local agents are really only meant for testing Bamboo itself.

Within a single stage, every job is eligible to run at the same time, as long as there's an agent available whose capabilities satisfy that job's requirements. Bamboo's scheduler simply dispatches each pending job to the first free, matching agent — it doesn't force sequential execution unless the stage structure says so.

Two things gate real parallelism in practice:

• Agent count — three jobs in a stage still run one after another if only one agent is free.
• Stage boundaries — the next stage always waits for every job in the current stage to finish, so parallelism only exists inside a stage, not across stages.

This is why teams splitting a long test suite into three jobs (e.g. unit, integration, contract tests) see real wall-clock savings only if at least three agents with the right capabilities are actually available at once.

The deciding factor is how much the build configuration differs. If a feature branch should be built, tested, and packaged using essentially the same steps as the main branch — same tasks, same agents, maybe a different deploy target — plan branches are the right fit, because Bamboo reuses the parent configuration automatically and cleans branch plans up when the branch is merged or deleted.

A separate plan makes more sense when the pipelines are genuinely different products or processes: for example, a mobile app and its backend API living in different repositories, or a release pipeline that runs on a completely different schedule and toolchain than day-to-day feature CI. Forcing unrelated pipelines into one plan's branches just to avoid creating a second plan usually creates more configuration complexity than it saves.

The failure cascades in a predictable order. First, the job containing the failed task stops — any remaining tasks in that job are skipped unless individually flagged to "always execute" (typically used for cleanup or notification steps). Second, the whole job is marked failed, which in turn marks the stage as failed. Third, by default, Bamboo does not proceed to the next stage.

Other jobs running in parallel within the same failed stage are allowed to finish on their own rather than being killed immediately, so you still get their results. An admin can override the default behavior with "Force execution of dependent stages," which lets later stages run even after a failure — useful for stages that just publish diagnostic reports rather than build on the previous stage's output.

A single run of a plan follows a fixed path from trigger to result, moving stage by stage and, within each stage, job by job in parallel.

The key mechanics to call out in an interview: stages are strict sequential gates, jobs inside a stage parallelize across agents, and a failure at any stage halts the default flow rather than letting later stages run against a broken build.

Slow builds usually come from one of a few repeatable causes, and the fixes map directly to them:

1. Not enough parallelism — split a monolithic job into multiple jobs (e.g. separate unit tests from integration tests) so they run concurrently across agents instead of one long sequential job.
2. Dependency re-download every run — cache Maven/npm/Gradle dependency directories on the agent instead of fetching them fresh each time.
3. Agent contention — if jobs are queueing, add more remote agents or use Elastic Bamboo to scale agent count with demand rather than running everything through a handful of static agents.
4. Oversized checkout — use shallow clones for plans that don't need full repository history.
5. Wrong capability matching — overly broad requirements can send jobs to agents that then have to install missing tools first; keep capability declarations tight and accurate.

The queue/timeline view in Bamboo is the first place to look — it shows whether time is lost waiting for an agent versus time spent actually executing tasks, which tells you whether to fix capacity or fix the pipeline itself.

An agent showing offline in the Bamboo admin console is a connectivity or process problem, and the checks go roughly in this order:

1. Confirm the agent process/service is actually running on the host; restart it if it has crashed.
2. Check network connectivity from the agent to the Bamboo server's configured URL/port — firewalls and VPN changes are common culprits.
3. Check the agent's local log file for authentication or version-mismatch errors (agent and server Java/Bamboo versions should be compatible).
4. Verify disk space on the agent host; a full disk can silently prevent the agent process from writing its working directory.
5. Confirm the agent hasn't been disabled or left "unapproved" in the server's agent list — new or reconnected agents sometimes need manual re-approval.

If the agent reconnects but jobs still don't get scheduled to it, the next check is whether its capabilities still match what jobs require — a capability that silently disappeared (e.g. a JDK path that moved) will leave the agent online but never selected.

Capabilities are how Bamboo prevents a job from landing on an agent that simply can't run it. Each agent advertises what it has installed — a JDK version, an executable path, a custom environment variable — and each job declares requirements describing what it needs. The scheduler only assigns a job to agents whose capabilities satisfy every one of that job's requirements.

Without this matching, a job needing Node 20 could land on an agent that only has Node 14, failing at the first script step with a confusing environment error rather than a clear scheduling message. Capability matching also lets one Bamboo instance safely serve very different projects — mobile builds routed to macOS agents, .NET builds routed to Windows agents, everything else to generic Linux agents — without anyone manually deciding where each job runs.

A deployment starts only after a build plan has already produced a usable artifact; the deployment project then takes over from there.

Two details matter for interviews: a release is a specific, immutable artifact version, and each environment keeps its own independent deployment history — Staging failing doesn't affect Production's last known state, and promoting to Production means running that same tested artifact through the Production environment's own tasks, not rebuilding it.

A job defines an artifact by pointing to files it produces (e.g. target/*.jar), and marking that definition as shared makes it available to every later stage in the plan automatically. Bamboo copies the file(s) to its artifact storage after the producing job finishes, and any job in a subsequent stage that needs them has them downloaded onto its agent before its own tasks start.

This matters because different stages often run on different agents — without shared artifacts, a "Package" stage's output wouldn't exist on the agent running the later "Deploy" stage. It also avoids rebuilding the same code twice: the test and package stages consume the exact binary the build stage produced, rather than each stage recompiling independently.

Both start the same way — a job declares which files it produces — but the scope of where those files travel differs.

The practical rule: mark an artifact shared only if a later stage genuinely consumes it, since every shared artifact adds storage and transfer cost to the plan.

Docker builds in Bamboo generally follow one of two patterns. The simpler one is a Script task on a remote agent that has Docker installed, running the standard build and push commands directly:

docker build -t registry.example.com/payments-api:${bamboo.buildNumber} .
docker push registry.example.com/payments-api:${bamboo.buildNumber}

For this to work, the agent needs a Docker capability declared so the scheduler only routes the job there, and registry credentials stored as Bamboo variables (masked as passwords) rather than hard-coded in the script.

The other pattern runs the job's tasks inside a Docker container as the build environment itself, which keeps the toolchain isolated per plan rather than installed permanently on the agent host — useful when different plans need conflicting versions of the same tool.

Permissions are layered, from broad to narrow, and each layer can be assigned to individual users or groups:

• Project level — who can view or administer everything under a project.
• Plan level — who can view build results, edit plan configuration, or trigger builds for a specific plan.
• Deployment project level — who can view or edit the deployment pipeline itself.
• Environment level — who can actually trigger a deployment to that specific environment.

Environment-level permission is the one that matters most operationally: it's normal to let most developers deploy freely to Dev while restricting the Production environment to a small release-management group, all within the same deployment project, without touching plan-level permissions at all.

Neither wins outright — the right choice depends on team size and how long the plan will live.

Specs wins for anything long-lived or shared across a team: it's reviewable in a pull request, diffable, and reusable across similar plans, which matters once you have more than a handful of pipelines or more than one person touching them. It also avoids the classic failure mode of UI-only setups, where a plan quietly drifts because a change was made by one admin and never documented.

UI configuration wins for quick, one-off experimentation — testing whether a new task type works, or spinning up a throwaway plan to debug an agent issue — where writing and committing a Specs file is more overhead than the task deserves.

In practice, most teams start in the UI to learn how a plan should look, then "export" that shape into Specs once it's stable enough to be worth versioning.

Rather than having Bamboo repeatedly poll the repository for changes, Bitbucket can push a webhook notification to Bamboo the moment a commit lands, and Bamboo starts the build immediately.

1. In the plan's trigger configuration, add a "Repository triggered" (webhook-based) trigger and select the linked repository.
2. If the repository is Bitbucket Server/Data Center linked via an application link, Bamboo can register the webhook automatically; for other Git hosts it's added manually.
3. For a manual setup, Bitbucket's repository settings get a webhook pointed at the Bamboo endpoint, for example:

POST https://bamboo.example.com/rest/api/latest/queue/PROJ-PLAN
Content-Type: application/json

Once configured, a push shows up as a queued build within seconds instead of waiting for the next polling interval, which is the main reason webhook triggers have largely replaced polling triggers in current setups.

Agents don't wait for the server to push work to them blindly — the relationship is closer to agents checking in and the server assigning work from a queue.

The connection is typically a persistent, authenticated channel over HTTPS. If it drops, the agent shows as offline and any job it was mid-way through is marked as failed/interrupted rather than silently left in limbo, since the server has no way to confirm the work actually completed.

Notifications are configured per plan (and can also be set as personal watches by individual users) under the plan's Notifications settings, where you pick an event and a delivery method.

• Events commonly configured: build failed, build first successful after a failure, build still failing (repeat failures), and deployment status changes.
• Delivery methods: email is built in; Slack or Microsoft Teams notifications are typically wired through an incoming webhook configured as a notification recipient; legacy setups sometimes still use HipChat.

A common pattern is to notify broadly (e.g. a team channel) only on failure or first-success-after-failure, rather than on every single passing build, to avoid alert fatigue while still surfacing anything that actually needs attention.

They sit at different points in the pipeline and serve different purposes.

A useful mental model: the plan answers "does this code work?" and the deployment project answers "is this already-verified code running where it needs to be?" — conflating the two into one plan removes the ability to gate production releases separately from everyday builds.

When a job is ready to run but no matching agent is free, it sits in the build queue rather than failing outright. Bamboo works through the queue roughly in order, dispatching each queued job to the first available agent whose capabilities satisfy that job's requirements.

A few factors affect how long something waits:

• Plan priority — plans can be weighted so more important pipelines get agents first when there's contention.
• Capability scarcity — a job needing a rare capability (a specific OS or license-bound tool) waits for one of the few agents that has it, even if generic agents are idle.
• Elastic capacity — if Elastic Bamboo is enabled, a growing queue can trigger new EC2 agents to spin up automatically, shortening the wait without manual intervention.

The Build Queue admin page shows exactly what's waiting and why, which is the first place to look when builds feel slow to start rather than slow to run.

Elastic Bamboo provisions remote agents as EC2 instances on demand — spinning them up when the build queue grows and terminating them once idle — so it fits situations where load is bursty rather than constant.

It makes sense when:

• Build volume spikes at predictable times (end of sprint, pre-release crunch) but is otherwise light, so paying for fixed always-on agents would waste capacity most of the week.
• The team already runs Bamboo on or near AWS and has an AWS account to authenticate against (via access key or an EC2 instance profile).
• Different jobs occasionally need a fresh, disposable environment rather than a long-lived agent that could accumulate state between builds.

It's a weaker fit when the version control system sits behind a strict internal firewall, since elastic agents on EC2 need network access to it — that's a security trade-off worth reading Atlassian's Elastic Bamboo security guidance on before enabling it.

Sensitive values like API keys or database passwords need to stay out of plain build logs and out of the plan configuration text itself. Bamboo's approach:

• Define the value as a plan or global variable and set its type to Password, which masks it in logs and the UI as soon as it's referenced.
• Reference it in scripts as ${bamboo.password.MY_SECRET} rather than hard-coding the literal value anywhere in the task configuration.
• Scope variables as narrowly as possible — a plan-level variable rather than a global one when only one plan needs it — and restrict edit permission on the plan so not everyone can view or change it.
• For Specs-defined plans, avoid committing the actual secret value to the repository; store it in Bamboo's variable store and reference it by name in the Specs code instead.

The masking is a log-display safeguard, not encryption at rest by itself, so pairing it with tight edit/view permissions on the variable is what actually limits who can retrieve the raw value.

Capabilities describe what an agent has; requirements describe what a job needs. Neither is useful alone — capabilities with nothing checking them would just be unused metadata, and requirements with no capability data to match against would have nothing to validate against.

Used together, they let Bamboo's scheduler make a correctness guarantee before a job ever starts: it will only place a job on an agent proven to satisfy every declared requirement, instead of discovering a missing tool mid-build through a cryptic "command not found" error. This is also what lets a single Bamboo instance safely serve heterogeneous projects — a mobile job routed only to macOS agents, a .NET job routed only to Windows agents — without any manual assignment, purely from the requirement/capability match.

For a reactor-style multi-module Maven project, the simplest approach is a single Maven task pointed at the root POM, letting Maven's own reactor handle module ordering:

mvn clean install -pl module-a,module-b -am

For faster feedback on larger projects, teams often split modules into separate jobs within the same stage instead — one job per module — so independent modules build in parallel across agents, with a shared artifact (or a local Maven repository cache) carrying compiled dependencies between them. This requires care around module build order, since a module job that depends on another module's output needs that artifact shared to it before its own Maven task runs.

Either way, a JUnit Parser task afterward aggregates test results across all modules into one build summary, rather than leaving results scattered per module.

A Specs YAML file goes through a detect-validate-apply cycle rather than being executed directly like a script.

A minimal example:

version: 2
plan:
  project-key: PAY
  key: PAYAPI
stages:
  - Build:
      jobs:
        - Compile:
            tasks:
              - checkout
              - maven: 'clean install'

Because this is a publish-and-validate step rather than a build step itself, a broken Specs file fails fast with a clear parsing error in Bamboo's UI, before any agent ever picks up work — it never silently produces a half-configured plan.

Test reporting relies on a parser task — most commonly JUnit Parser, but NUnit, TestNG, and other formats are supported too — added after the actual test-running task in a job. The parser reads the XML output the test framework already produces and turns it into structured Bamboo data rather than leaving it as raw log text.

Once parsed, Bamboo:

• Shows a pass/fail/skipped count summary directly on the build results page.
• Tracks trends over time, so a build's test count can be compared against the previous build to catch a test suite quietly shrinking.
• Flags newly failing tests distinctly from tests that were already failing, which helps triage what a specific commit actually broke.
• Can quarantine consistently flaky tests in some configurations so they don't mask genuine regressions.

The important detail for interviews: Bamboo doesn't run or interpret the tests itself — the build tool (Maven, Gradle, npm) runs them, and Bamboo's role is purely to parse and surface the resulting report.

Stages are designed as sequential checkpoints where each one is assumed to build on the verified state left by the previous one — artifacts, environment setup, whatever the prior stage produced. Re-running an already-successful stage would mean redoing work whose output hasn't changed and risks producing a subtly different result the second time (a flaky test passing differently, a dependency version drifting), which would undermine the point of treating that stage as "done."

Instead, Bamboo offers "Rerun failed jobs," which restarts only the jobs that actually failed within the failed stage, reusing the artifacts and state from every stage that already passed. A full "Run" restarts the entire plan from stage one, which is the intended path when you specifically want a clean, from-scratch verification rather than a spot-fix rerun.

A migration is mostly a mapping exercise between two similar concepts expressed differently, plus a re-plumbing of credentials and triggers.

1. Map structure — Jenkinsfile stage blocks map to Bamboo stages; parallel Jenkins branches map to parallel jobs within a stage; individual sh/bat steps map to Script tasks.
2. Rebuild plugin functionality — a Jenkins plugin step (e.g. a specific deployment plugin) usually has no direct Bamboo equivalent, so it's replaced with an equivalent Script task or, where available, a matching Bamboo task type.
3. Move credentials — Jenkins credentials become Bamboo Password-type variables, referenced the Bamboo way rather than via Jenkins' credential-binding syntax.
4. Reconfigure triggers — Jenkins webhook/SCM triggers are replaced with Bamboo repository triggers pointed at the same repository.
5. Express the result as Specs — writing the new pipeline as Bamboo Specs (rather than clicking it together) keeps it reviewable, similar in spirit to how the Jenkinsfile itself was versioned.
6. Run both in parallel briefly — validate the Bamboo plan produces identical build/test outcomes before retiring the Jenkins job, using plan branches to test without touching the main pipeline.

These are two historical deployment editions, and the distinction matters mainly because only one of them still exists as a real option today.

The practical takeaway for anyone interviewing on Bamboo today: virtually every current installation is Data Center, and any "Bamboo Server" reference in older documentation or job postings describes a discontinued edition rather than something you'd deploy new.