Atlassian Bamboo Interview Questions: Plans, Jobs, Artifacts, and Deployment Releases

A Bamboo plan turns green, but staging still runs yesterday's package. Before changing a trigger or restarting an agent, ask a more precise question: which build result produced the artifact, which release selected it, and which deployment installed those bytes?

That trace grounds useful Atlassian Bamboo interview questions. Memorizing plan, job, and task definitions helps, but the stronger answer connects those objects to scheduling, artifact movement, and observable deployment results.

This guide uses official Bamboo Data Center documentation, with versions identified in the sources. Build numbers, package identifiers, and troubleshooting cases below are original practice; recommendations are preparation inferences. It does not describe Atlassian's hiring process or use candidate reports.

For a broader dependency exercise, practice Design a Dependency-Aware CI/CD Pipeline and name exactly which output each downstream step consumes.

How do plans, stages, jobs, and tasks fit together?

Official fact: A job is a build unit inside a plan. Stages organize jobs; jobs within one stage can run concurrently when enough agents are available. Tasks within a job run sequentially on the same agent. A job gathers its tasks' requirements and defines the artifacts it produces. See Bamboo's job definition.

Explain the hierarchy with an execution example. A plan for an application can contain a build stage followed by an acceptance-test stage. The build stage might have separate Linux and Windows jobs. Each job might run checkout, dependency installation, compilation, and unit tests as ordered tasks.

Preparation inference: A task boundary expresses ordering within one agent's work. A job boundary expresses a separately scheduled unit. A stage boundary can express a dependency between groups of jobs. Moving checkout and compilation into separate jobs is therefore a behavioral change, even if both scripts remain unchanged.

If acceptance tests need the compiled package, do not put the producer and consumer in sibling jobs and assume sibling listing order makes the package available. Describe the intended ordering explicitly. Also distinguish available capacity from eligible capacity: five idle agents do not help if none meets the job's requirements.

An interviewer may ask whether splitting a slow job guarantees a faster build. It does not. Parallel jobs require eligible agents; artifact transfer also adds to the critical path. Compare the critical path, queue wait, artifact transfer, and execution time before proposing more jobs.

What makes an artifact available to another job?

Official fact: Bamboo artifact definitions specify a location relative to the build directory and copy patterns relative to that location. Shared artifacts can be consumed by jobs in later stages through artifact dependencies. The Required flag can fail the build if the artifact cannot be published. Cross-plan sharing uses an Artifact downloader task. See sharing artifacts.

These settings answer different questions. Shared controls availability for consumers; Required prevents a missing expected output from being overlooked. Neither verifies that the package contains the intended commit or that a deployment script installs it correctly.

Original practice: The compile task writes dist/app.zip, while the artifact definition has Location target and Copy pattern *.zip. The compilation can succeed even though the publication rule points at the wrong directory. Correct the definition or output contract after inspecting the producing workspace and publication log.

Do not fix this by broadening the pattern to collect every ZIP under the workspace. That can include a cached dependency or an old package. Ask which single file or controlled set of files represents this build's deployable output. Verify the resulting artifact listing, not just the script's exit code.

For cross-plan downloads, inspect the source plan and branch-selection settings. The documented matching strategy can fall back to the default plan branch when no corresponding source branch exists. Inference: A branch name alone is insufficient evidence that the consumer tested the intended branch's package. Record the actual selected producer result and artifact identity.

Trace one package through a deployment release

Official fact: A deployment release is a snapshot of artifacts and associated metadata created from a single build result. Deployment projects hold releases and environments, and environment history records deployments. See understanding deployment releases and deployment projects.

Use this original trace. p41 and p42 are fictional package-identity labels, not real checksums.

Evidence point	Earlier result	Newer result	What it establishes
Producer build	APP-WEB-41, commit a1	APP-WEB-42, commit b2	Two distinct build results exist.
Published package	app.zip, identity p41	app.zip, identity p42	Same filename can refer to different content.
Acceptance test	Passed on p41	Passed on p42	Each test result needs its package identity.
Deployment release	release-41 selects build 41	release-42 selects build 42	Release names must map to producer evidence.
Staging deployment	Installed release-41	Not yet run	A new release does not install itself.
Running application	Reports commit a1	Expected future state b2	Runtime observation distinguishes installation from intention.

A green build establishes neither release selection nor installation.

The trace disproves that conclusion. Build 42 and release-42 exist, but staging's recorded deployment still selects release-41. The immediate task is to verify the intended release selection and deployment trigger or manual action, not rebuild identical source code.

If staging instead records a successful deployment of release-42 while the application reports a1, investigate a different boundary. Did the downloader retrieve p42? Did the install task target the intended host and directory? Did the process restart load that directory? Could a load balancer still serve another instance?

Preparation inference: Compare release history with the running application's version evidence. A package digest, signed manifest, or embedded commit identifier can support that comparison, depending on the team's system. Do not invent a digest when all you have is a filename.

Why can a job remain queued while agents are idle?

Official fact: A job inherits requirements from its tasks and can have additional requirements. Bamboo matches those requirements against agent capabilities. Requirement conditions include existence, equality, and regular-expression matching. The Requirements view shows matching agents. See configuring a job's requirements.

In the following original eligibility exercise, the job requires jdk=17 and docker=yes. Treat these as simplified custom keys, not built-in Bamboo key spellings.

Agent	jdk capability	docker capability	Meets both requirements?
A	11	yes	No: JDK value differs.
B	17	absent	No: Docker capability missing.
C	17	yes	Yes, subject to availability and other restrictions.

If C is offline or occupied, A and B being idle does not make the job runnable. Show how you would inspect the actual requirements, matching-agent list, agent state, and any dedicated-agent restrictions before changing capacity.

Inference: A registered capability declares eligibility; verify the executable separately when a task fails. If C accepts the job but a task cannot run Java, inspect the configured executable path and the environment used by that agent. Do not confuse “no agent can accept the job” with “an accepted task failed.”

A safe remediation must preserve the requirement's purpose. Removing the JDK condition can move a failure from the queue into the build. Adding a capability label without installing or verifying the tool can do the same. Explain which evidence would justify an agent configuration change.

What is different about build and deployment environments?

Official fact: Bamboo deployment environments contain their own details, tasks, triggers, permissions, agents, notifications, and variables. They represent destinations such as QA, staging, and production. See creating a deployment environment.

Preparation inference: Build success should establish a tested artifact. Deployment success should establish that the chosen artifact reached the intended environment and passed the deployment checks. These are related but separate contracts.

An environment can need a different set of capabilities from a compile job. A deployment task may need network access to a destination, a specific command-line tool, or an approved environment variable. Diagnose the environment's own task logs and agent selection rather than assume that an agent which built the package can deploy it.

When asked about variables, identify where a value is resolved and whether it changes artifact content or only runtime configuration. If staging and production rebuild the package with different source substitutions, “promote the same release” no longer proves identical bytes. If runtime configuration differs, record that difference independently from the package identity.

Avoid putting credentials into the artifact to simplify deployment. Explain the team's approved secret mechanism and redact sensitive values from logs. This is a preparation recommendation, not a claim that every Bamboo installation has the same credential integration.

How should you answer a failed-deployment recovery question?

First classify the failure. A queued deployment, missing artifact, failed transfer, failed install command, and failed runtime health check require different evidence. Read the first relevant failure and the steps that completed before it; the final red status does not describe all side effects.

Original practice: The deployment downloads p42, runs a database migration, installs the package, and then fails its health check. Redeploying release-41 may restore older application files, but that does not prove the database migration has been reversed. Bamboo's release identity tracks what was selected; it does not guarantee that arbitrary external operations are reversible.

Inference: Ask whether the migration is compatible with the older application and whether the deployment tasks are safe to repeat. Record the environment state before retrying. A retry that repeats an irreversible migration can change the database again even when it selects the correct release.

Describe a bounded recovery: stop further promotion, identify the installed package and completed migration, choose a compatible forward fix or tested rollback, then verify runtime behavior. Retain the failed deployment result and logs as evidence. Do not declare success because a second task run becomes green if the application version or health check still disagrees.

For an interview, make the evidence order explicit: selected release, producer build result, published artifact, downloader output, installation log, and running version. That ordering lets another engineer test your diagnosis rather than follow a list of unrelated Bamboo features.

A useful interview handoff names the smallest missing observation. If the release selects build42 but the downloader log is absent, collect that log before blaming application caching. If the package identity matches but one instance reports the older commit, inspect the rollout target set. If no deployment began, explain the trigger or approval boundary. These are competing diagnoses with different predictions, not interchangeable reasons to rerun the plan.

Practice related delivery questions

Question	What to practice
Connect Monitoring, Circuit Breakers, Rollback, and CI/CD	Connect rollout health evidence to a rollback decision.
Design Google-scale CI/CD pipeline	Reason about artifact identity and pipeline scale.
Design a CI/CD pipeline with scheduler	Separate scheduling dependencies from execution capacity.
Design a Dependency-Aware CI/CD Pipeline	Draw producer/consumer ordering before running jobs.
Demonstrate Git and build workflow	Explain the commit-to-build-result chain.

Start with Design a Dependency-Aware CI/CD Pipeline. Draw the producer, consumer, build result, release, and environment separately. Then explain which evidence would prove that the intended bytes reached the running application.

Sources and Further Reading

• Bamboo job definition, Data Center 12.1
• Sharing artifacts, Data Center 12.1
• Understanding deployment releases, Data Center 12.1
• Deployment projects, Data Center 12.0
• Configuring a job's requirements, Data Center 12.1
• Creating a deployment environment, Data Center 12.1