What Is Pipeline artifact in DevOps?
On This Page
Quick Definition
A pipeline artifact is a packaged output, like a compiled program or a Docker image, created automatically during the software build process. These artifacts are saved so that later stages in the pipeline, such as testing or deployment, can use them without rebuilding. Artifacts ensure consistency because the same exact files move through every step.
Commonly Confused With
Build cache stores dependencies (like npm packages or Maven .jar files) to speed up future builds, but it is not preserved across pipeline stages by default. Artifacts store the output of a build (e.g., the final compiled code) and are designed to be passed to subsequent stages. Cache is temporary and rebuildable; artifacts are permanent outputs.
Using cache for 'node_modules' speeds up 'npm install'; using artifacts for the 'dist' folder passes the built site to the test stage.
Pipeline variables are key-value pairs of text strings that can be used to pass configuration data like file names or paths between stages. They cannot hold binary files. Artifacts hold files, not text. Variables are often used in conjunction with artifacts to reference their paths.
A variable 'BUILD_VERSION' might store '1.2.3', while the artifact would be the file 'app-1.2.3.jar'. The variable tells the deployment stage which artifact to use.
A container image is a type of pipeline artifact that includes an entire runtime environment. While both are outputs of a build, container images are stored in a registry and referenced by tag. Other artifacts like a single jar file or zip archive are simpler and may not require a container runtime.
A Docker image built in a pipeline is pushed to Docker Hub as an artifact. A compiled Java .war file is also an artifact but stored in a different repository type.
Must Know for Exams
Pipeline artifacts appear in several popular IT certification exams, particularly those focused on DevOps, continuous delivery, and cloud platforms. For the AWS Certified DevOps Engineer – Professional exam (DOP-C02), candidates must understand how CodePipeline passes artifacts between stages using Amazon S3 as a repository. Exam questions often ask about artifact store locations, encryption settings, and cross-account artifact sharing. For the Azure DevOps Solutions expert exam (AZ-400), artifacts are central to release pipelines. Questions may cover artifact versioning, retention policies, and integration with Azure Artifacts or Universal Packages. For the Google Cloud Professional DevOps Engineer exam, artifact concepts appear in the context of Cloud Build and Artifact Registry, including vulnerability scanning and promotion strategies. In the GitLab Certified DevOps Professional exam, candidates need to know how to define artifacts in .gitlab-ci.yml, set expiration periods, and use dependencies between jobs. In the Jenkins Certified Engineer exam, questions focus on archiving artifacts, fingerprinting, and accessing artifacts from upstream builds.
Exam question types include scenario-based questions where you must choose the correct artifact configuration to ensure a downstream job receives the right files. For example, a question might describe a pipeline with separate build and test jobs and ask which keyword in GitLab CI allows the test job to access files from the build job. The answer would be 'dependencies' along with 'artifacts' paths. Other questions test troubleshooting skills: why a downstream job fails to find a file. Candidates must check artifact path patterns, retention policies, and stage dependencies. Some questions focus on artifact security, such as using signed artifacts or scanning before promotion. Performance-based questions in cloud exams may require you to configure an artifact store in a CI/CD tool or set up artifact sharing between environments. Overall, artifacts are a high-value topic because they bridge build and deployment phases, a common exam emphasis.
Simple Meaning
Think of a pipeline artifact like a cake that comes out of an oven after following a recipe. In a software development pipeline, the recipe is the build script, the ingredients are the source code, and the cake is the artifact. Once the cake is baked, you don't go back and mix the ingredients again every time you want a slice.
Instead, you keep the cake on the counter and take pieces from it for frosting, decorating, and serving. In IT, the artifact is the compiled application or package that results from a build stage. It could be a .
jar file, a .exe file, a container image, or even a collection of configuration files. This artifact is stored in a repository or on the build server for later use. When the pipeline moves to testing or deployment, it pulls that exact artifact instead of rebuilding from scratch.
This prevents errors from different source code versions and saves time. For example, a team writing a web app runs a build that produces a Java JAR file. That JAR is stored as an artifact.
Later, the testing stage runs automated tests using that JAR, and if tests pass, the deployment stage copies the same JAR to a production server. The artifact acts as a single source of truth for that specific version of the software. Without artifacts, each stage would need to compile code again, risking inconsistencies and wasted compute resources.
Full Technical Definition
In CI/CD pipelines, a pipeline artifact is any persistent output produced by a pipeline stage, typically stored in a versioned artifact repository for traceability and reuse. Common artifact types include compiled binaries, library dependencies, container images, deployable packages like WAR or JAR files, Docker images, Terraform plan files, and test result reports. Modern pipelines, such as those in Jenkins, GitLab CI, Azure DevOps, or GitHub Actions, define artifacts explicitly in pipeline configuration files. For example, in a Jenkinsfile, the 'archiveArtifacts' step saves specified files to the Jenkins master. In GitLab CI, the 'artifacts' keyword in .gitlab-ci.yml lists paths to preserve after a job completes, and these artifacts can be passed to downstream jobs within the same pipeline. In Azure DevOps, the 'PublishBuildArtifacts' task stores files in a drop folder accessible by subsequent stages.
Artifact management follows a few key technical principles. First, artifacts are immutable once created: any change to the source code should produce a new artifact with a unique version or hash. Second, artifacts are stored in a central repository such as Nexus, Artifactory, or container registries like Docker Hub or AWS ECR. These repositories provide access controls, versioning, and metadata tags. Third, artifacts are often signed or checksummed to verify integrity. In practice, a developer commits code to a repository trigger, the pipeline runs a build step that compiles code and runs tests, then publishes the artifact. The artifact's location, including the repository URL and version, is passed to subsequent stages via environment variables or pipeline parameters.
Security considerations include scanning artifacts for vulnerabilities using tools like Trivy or Snyk before promotion to production. Artifacts may also be stored with retention policies to avoid storage bloat. For exam purposes, understanding artifact lifecycle stages, build, publish, store, retrieve, and promote, is critical. Many DevOps exam questions test knowledge of how artifacts differ from build logs or cached dependencies. Candidates should know that artifacts are intentionally preserved outputs, not intermediate temporary files.
Real-Life Example
Imagine you are baking cookies for a large family gathering. You follow a recipe, mix flour, sugar, eggs, and chocolate chips, then bake a batch. The baked cookies are your artifact.
You put them in a sealed container. Later, your cousin wants to add frosting, and your aunt wants to package them as gift boxes. They both take cookies from the same container, not from the raw dough.
Nobody re-bakes the cookies from scratch each time. This is exactly how pipeline artifacts work. In a software pipeline, the "baking" is the build stage, and the cookies are the compiled application.
The container is the artifact repository. The frosting and gift boxing are later pipeline stages like quality testing and deployment. By reusing the same artifact, everyone works with the same final product, avoiding mistakes.
If your cousin accidentally used undercooked dough, the frosting might melt. Similarly, if a test stage used a different build than the deploy stage, integration issues could occur. Artifacts eliminate that risk.
Why This Term Matters
Pipeline artifacts matter because they directly enable continuous delivery and deployment. Without artifacts, every pipeline stage would need to rebuild code, introducing variation and wasting compute resources. In a typical IT organization, build times can be minutes or even hours for large applications. Rebuilding for each stage multiplies that time and increases the chance of failure from transient environment issues. Artifacts provide a single, verifiable package that flows from development to production. This ensures that the exact same binary tested in staging is the one deployed to production. This concept is foundational to DevOps practices like immutable infrastructure and blue-green deployments.
From a security standpoint, artifacts can be scanned once and promoted only if they pass security gates. This prevents vulnerable code from reaching production. Artifacts also enable rollback: if a deployment fails, the previous artifact version can be redeployed immediately. In regulated industries, artifacts provide an audit trail because each artifact has a unique ID, timestamp, and pipeline run that created it. For IT professionals, understanding artifact management is critical for roles like DevOps engineer, build/release engineer, and cloud architect. In practice, misconfigured artifact paths or permissions can cause pipeline failures that take hours to debug. Therefore, knowing how to define, publish, and retrieve artifacts in tools like Jenkins, GitLab, or Azure DevOps is a core skill.
How It Appears in Exam Questions
Pipeline artifact questions often present a scenario with a multi-stage CI/CD pipeline and ask about file sharing between stages. Typical question patterns include:
1. Scenario type: A team has a Jenkins pipeline with a build stage that compiles a Java application into a WAR file. The test stage needs to run unit tests on that WAR. What must the build stage do to make the file available? The correct answer is to use 'archiveArtifacts' or 'stash' steps to preserve the WAR file, then 'unstash' or retrieve it in the test stage. Distractors might suggest using shared workspace or copying to a network drive, which are less reliable.
2. Configuration type: In a GitLab CI pipeline, what is the correct syntax to pass a compiled binary from the 'compile' job to the 'test' job? Candidates must know the 'artifacts' keyword with 'paths' and 'dependencies' in the .gitlab-ci.yml file. Example choices include using 'cache' versus 'artifacts'. The trap is that 'cache' is for dependencies, not outputs.
3. Troubleshooting type: A pipeline fails because the deployment stage cannot find the artifact. The build stage completed successfully, but the artifact path is incorrect. The question asks what to check. Options include artifact retention policies, path patterns with wildcards, and stage order. The correct answer often involves verifying that the artifact path matches the exact file structure and that the artifact is not expired.
4. Security type: An organization requires all artifacts to be scanned for vulnerabilities before deployment. Which step should be added? The answer is to add a scanning stage that downloads the artifact, runs a tool like Snyk, and only promotes if the scan passes. Questions may also ask about artifact encryption at rest in S3 or Azure Blob Storage.
5. Multi-pipeline type: A team uses Azure DevOps with multiple pipelines for microservices. How can one pipeline reference an artifact from another pipeline? The answer is to use Pipeline Artifacts and multi-stage pipelines triggers or to publish to a feed. Understanding the differences between Build Artifacts and Pipeline Artifacts in Azure is important.
Candidates should expect at least one or two dedicated questions on artifacts in DevOps-focused exams, plus integrated questions in broader topics. Performance labs may require configuring artifact publishing in a sample pipeline.
Study AZ-400
Test your understanding with exam-style practice questions.
Example Scenario
A small team is building a Node.js web application. Their CI/CD pipeline has three stages: Build, Test, and Deploy. In the Build stage, the pipeline runs 'npm install' and 'npm run build', which generates a 'dist' folder containing the minified JavaScript and CSS files. The pipeline configuration saves this 'dist' folder as an artifact. In the Test stage, the pipeline retrieves the artifact and runs automated end-to-end tests using Cypress against the files in 'dist'. Because the Test stage uses the exact same artifact, it validates the same code that will be deployed. If the tests pass, the Deploy stage retrieves the artifact again and uploads its contents to an AWS S3 bucket configured for static website hosting. The artifact includes all frontend assets. Without artifacts, the Deploy stage would need to run 'npm run build' again, which could produce a different set of files if any dependency versions changed or environment variables differed. By using artifacts, the team ensures that the exact build tested is the one deployed, reducing risk. In this scenario, the pipeline configuration could be a simple .gitlab-ci.yml:
build: script: - npm install - npm run build artifacts: paths: - dist/
test: script: - npm install - npx cypress run dependencies: - build
deploy: script: - aws s3 sync dist/ s3://my-bucket/ dependencies: - build
If one of the students mistakenly omitted the 'dependencies' keyword in the test job, the test job would not receive the artifact, and Cypress would have nothing to test. The pipeline would fail. This simple scenario illustrates how artifact configuration is essential for multi-stage pipelines.
Common Mistakes
Using 'cache' instead of 'artifacts' to pass files between pipeline stages
Cache is designed to speed up dependency installation by reusing downloaded packages, not to preserve build outputs for later stages. Artifacts are the correct mechanism for passing files between jobs.
Always use the 'artifacts' keyword (or equivalent in your CI/CD tool) to pass build outputs, and reserve 'cache' for dependency directories like node_modules or .m2.
Assuming artifact paths are relative to the repository root, not the job's working directory
Most CI/CD systems define artifact paths relative to the job's working directory. If the build generates files in a subfolder and the artifact path incorrectly starts with '../' or an absolute path, the files won't be archived or the archive will include unintended files.
Always verify the working directory of the job and list artifact paths relative to that directory. Use glob patterns carefully and test in a sample pipeline.
Forgetting to set artifact expiration and causing storage overflow
Without a retention policy, old artifacts accumulate, consuming disk space and increasing costs. Over many builds, this can fill the artifact storage and cause pipeline failures due to insufficient space.
Always set a reasonable 'expire_in' value (e.g., 30 days) for artifacts in pipeline configuration. In production, set retention policies in the artifact repository separately.
Expecting artifacts to be automatically available in downstream jobs when using 'needs' without 'dependencies'
In tools like GitLab CI, using 'needs' reduces pipeline execution time by starting jobs earlier, but artifacts are not automatically passed unless 'dependencies' is explicitly set. This can lead to 'file not found' errors.
When using 'needs', always add 'dependencies:' listing the jobs whose artifacts you need. Alternatively, use 'stage' ordering to ensure artifacts are available implicitly.
Exam Trap — Don't Get Fooled
{"trap":"Confusing artifacts with build logs or environment variables. An exam question might ask how to make a compiled binary available to a later stage, and one distractor says 'use the variables keyword' or 'store in environment variables'.","why_learners_choose_it":"Learners remember that environment variables pass data between stages, but they forget that binary files cannot be stored in environment variables.
The trap works because both artifacts and variables are passed, but variables only support text.","how_to_avoid_it":"Remember that environment variables pass small text values (like file paths or version numbers), but actual files must be passed as artifacts. If the question mentions a binary, compiled code, or large file set, the answer must involve artifacts or a repository."
Step-by-Step Breakdown
Define artifact paths in pipeline configuration
In your CI/CD configuration file (e.g., .gitlab-ci.yml, Jenkinsfile, azure-pipelines.yml), you specify which files and folders are considered artifacts. This is done using an 'artifacts' block with 'paths' parameter. This step tells the system what to preserve after the job finishes. Incorrect paths cause missing artifacts later.
Run the build job that produces the artifact
The pipeline executes the build job, which compiles code, runs scripts, and generates output files. These files are written to the working directory or a specified output folder. The build job must succeed for artifacts to be retained. If the job fails, artifacts may not be created or may be discarded depending on configuration.
Artifacts are uploaded to persistent storage
After the build job completes successfully, the CI/CD system compresses and uploads the specified files to a central storage location, often a cloud bucket or the CI server's file system. This ensures artifacts survive even if the build node is recycled. Metadata like job ID and pipeline run number is attached.
Downstream jobs retrieve artifacts
When a later job (e.g., test or deploy) starts, it downloads the artifact from storage into its working directory. This is automatic if dependencies are configured. The artifact's content is exactly as it was produced in the build job. The retrieval is done over HTTPS or internal network, and integrity may be verified using checksums.
Artifacts are used for testing or deployment
The downstream job uses the artifact files directly, for example, running unit tests against the compiled binary or copying the files to a server. Because the artifact is immutable, the same files are used across all stages unless explicitly transformed into a new artifact by a subsequent job.
Artifacts are retained or expired per policy
Artifacts stay in storage according to the retention policy set in the pipeline or globally. They may be kept for a number of days or a number of runs. After expiration, they are automatically deleted to free space. Some artifacts worth keeping (like release builds) are moved to long-term artifact repositories with indefinite retention.
Practical Mini-Lesson
In practice, pipeline artifacts are a cornerstone of reliable software delivery. To use artifacts effectively, IT professionals must understand how their chosen CI/CD tool implements artifact storage and retrieval. In Jenkins, the 'archiveArtifacts' step stores files on the Jenkins master, and 'copyArtifacts' plugin can fetch from upstream jobs.
However, storing too many artifacts on the master can cause disk space issues, so many teams use external storage like Amazon S3 or Artifactory with the Jenkins Artifact Manager or custom scripts. In GitLab CI, artifacts are stored on the GitLab server and can be downloaded via the web interface, but for large artifacts, the 'dependencies' keyword should be used carefully to avoid transferring unnecessary files. In Azure DevOps, there is a distinction between 'Build Artifacts' (published using the 'PublishBuildArtifacts' task) and 'Pipeline Artifacts' (used in multi-stage pipelines).
Pipeline Artifacts are faster and support larger files, but Build Artifacts integrate with classic releases. In GitHub Actions, artifacts are defined with the 'actions/upload-artifact' and 'actions/download-artifact' actions, and they are stored on GitHub's infrastructure for up to 90 days. A common issue is artifact download speed: large artifacts can slow down pipelines, so teams should optimize what they include.
For example, only include the compiled application and its runtime dependencies, not the entire source code or intermediate build files. Another practical consideration is artifact versioning. Artifacts should be versioned with the same semantic version as the release to enable traceability.
Security scanning tools often integrate with artifact repositories to scan before deployment. Finally, professionals should know how to debug artifact issues: check the pipeline logs for upload and download steps, verify the artifact path patterns, and ensure the downstream job has the correct dependencies configured. A quick command-line test on the build agent can confirm the file exists at the expected path.
Memory Tip
Artifact = 'Archive The File I Created', remember to archive the output files you create during the build so later stages can use them.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
Related Glossary Terms
A 2-in-1 laptop is a portable computer that can switch between a traditional laptop form and a tablet form, usually by detaching or rotating the keyboard.
The 24-pin motherboard connector is the main power cable that connects the computer's power supply unit (PSU) to the motherboard, supplying electricity to the motherboard and its components.
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
A 3D printer is a device that creates physical objects by depositing layers of material based on a digital model.
5G is the fifth generation of cellular network technology, designed to deliver faster speeds, lower latency, and support for many more connected devices than previous generations.
The 8-pin CPU connector is a power cable from the power supply that delivers dedicated electricity to the processor on a computer's motherboard.
802.1Q is the networking standard that allows multiple virtual LANs (VLANs) to share a single physical network link by tagging Ethernet frames with VLAN identification information.
802.1X is a network access control standard that authenticates devices before they are allowed to connect to a wired or wireless network.
Frequently Asked Questions
What is the difference between an artifact and a build output?
A build output is any file produced during compilation, but not all outputs are preserved. An artifact is a deliberately saved build output that is versioned and passed to later stages. Temporary files like object .o files are usually not artifacts.
Can artifacts be deleted after the pipeline finishes?
Yes, artifacts have retention policies. They are automatically deleted after a configurable number of days or pipeline runs. For long-term storage, move important artifacts to a dedicated repository like Artifactory or Nexus.
How do I pass artifacts between stages in Azure DevOps?
Use the 'Publish Pipeline Artifact' task in the first stage and the 'Download Pipeline Artifact' task in subsequent stages. You can also use the 'dependencies' syntax in YAML pipeline definitions.
Is a Docker image considered a pipeline artifact?
Yes, a Docker image is a type of artifact. It is built in a pipeline stage and stored in a container registry. It is then pulled by later stages for testing or deployment. Many DevOps tools treat container images as specialized artifacts.
What happens if an artifact is too large?
Large artifacts can slow down pipeline execution and consume storage. Many CI/CD tools have file size limits. Split large artifacts into multiple smaller ones or use an external artifact repository with optimized transfer.
Do artifacts count towards storage quotas in GitLab or GitHub?
Yes, artifact storage counts toward the total storage quota in GitLab (free tier limited) and GitHub Actions (2 GB free). Exceeding quotas can cause pipelines to fail or incur extra costs.
Summary
Pipeline artifacts are the built outputs of a CI/CD pipeline stage, such as compiled binaries, packages, container images, or test reports. Their purpose is to provide a consistent, immutable set of files that flow through subsequent stages like testing, staging, and production. By storing artifacts in a central repository, teams avoid rebuilding code for each stage, reduce errors, and enable traceability.
For IT certification learners, understanding artifact configuration, lifecycle, and common pitfalls is essential for DevOps exams like AWS DevOps Engineer, Azure DevOps Solutions, and GitLab Certified Professional. Exam questions often test how to define artifact paths, pass artifacts between stages, and troubleshoot missing files. Practical implementation requires knowledge of specific syntax and retention policies in tools like Jenkins, GitLab, Azure DevOps, and GitHub Actions.
By mastering pipeline artifacts, you strengthen your ability to build reliable, efficient software delivery pipelines.