Cloud / AWS CodePipeline Interview questions

AWS CodePipeline is a fully managed continuous delivery service that models, visualizes and automates the steps needed to take code from a repository to production. You define a workflow of stages, and CodePipeline runs it every time a change is detected.

It does not build or deploy anything by itself. It orchestrates other tools such as CodeBuild, CodeDeploy, CloudFormation, ECS, Lambda or third-party services like Jenkins.

A pipeline typically looks like this: Source, Build, Test, Approval, Deploy. Each run is called an execution and its progress is visible in the console.

A pipeline is built from a small set of concepts:

• Pipeline - the whole workflow definition.
• Stage - a logical group such as Source, Build or Deploy.
• Action - a single task inside a stage, run by a provider.
• Transition - the link between two stages that can be enabled or disabled.
• Artifact - the files passed from one action to the next, stored in S3.
• Execution - one run of the pipeline for a specific revision.

Every pipeline also needs a service role and an artifact store.

A stage is a logical unit of a pipeline that groups one or more actions, for example Source, Build, Staging or Production. Stages run in the order they are defined.

A pipeline needs at least two stages, and the first stage must contain a source action. Actions inside a stage can run sequentially or in parallel depending on their runOrder.

If any action in a stage fails, the stage fails and the pipeline stops there unless you retry it.

An action is the smallest unit of work in a pipeline. It belongs to a stage and is tied to a provider that does the real work, such as CodeBuild for compiling or CodeDeploy for deploying.

Each action has a category, a provider, optional input and output artifacts, and a configuration block. Its runOrder decides whether it runs before, after or alongside other actions in the same stage.

The six action categories are Source, Build, Test, Deploy, Approval and Invoke.

The source action pulls code or artifacts and starts the pipeline. Supported providers include:

• AWS CodeCommit
• Amazon S3 (versioned bucket)
• Amazon ECR (new image push)
• GitHub, GitHub Enterprise, GitLab, Bitbucket through AWS CodeConnections

Third-party repositories use a connection resource that must be authorized once in the console before the pipeline can read from it.

Artifacts are the files that move between actions. An action can consume input artifacts and produce output artifacts, and each one is stored as a zip in the pipeline's S3 artifact bucket.

For example, the source action outputs SourceArtifact, CodeBuild takes it as input and outputs BuildArtifact, and CodeDeploy then uses that build output.

Artifact names must match exactly between the output of one action and the input of the next, otherwise the pipeline will not validate.

A pipeline execution is a single run of the pipeline that processes one set of source revisions from start to finish. It gets a unique execution ID and its own status: InProgress, Succeeded, Superseded, Stopped, Stopping or Failed.

A new execution starts on a source change, on a schedule or trigger, or manually with start-pipeline-execution.

Execution history shows which commit went through which stage, which makes it easy to trace a bad deployment back to its revision.

A transition is the connection between two stages. When a stage succeeds, the transition into the next stage is what lets the revision move forward.

You can disable a transition to hold changes before a sensitive stage such as Production, and enable it again when you are ready. While disabled, the revision waits and the pipeline shows it as pending.

This is a lightweight alternative to a manual approval when you just need to pause deployments, for example during a freeze.

A manual approval action pauses the pipeline until someone with the right IAM permission approves or rejects it. It is commonly placed before a production deploy.

You can attach an SNS topic so reviewers get an email or chat notification, plus a URL for review and comments. Approval reviewers need codepipeline:PutApprovalResult.

If nobody responds within the timeout (7 days by default), the action is treated as rejected and the pipeline fails at that point.

Deploy actions push the built output to a target. The common providers are:

• AWS CodeDeploy - EC2, on-premises servers, Lambda and ECS blue/green
• AWS CloudFormation - stack and change set operations
• Amazon ECS and ECS (Blue/Green)
• AWS Elastic Beanstalk
• Amazon S3 - static websites
• AWS Service Catalog and AWS AppConfig

Anything not covered can be handled with a Lambda invoke action or a custom action.

They are separate services that usually work together, each with a single job.

In practice CodePipeline calls CodeBuild in the Build stage and CodeDeploy in the Deploy stage, passing artifacts between them.

In the console, choose Create pipeline and follow the wizard:

1. Enter the pipeline name, pipeline type (V1 or V2) and service role.
2. Pick the source provider, repository and branch.
3. Add a build provider such as CodeBuild, or skip it.
4. Add a deploy provider or skip it.
5. Review and create. The pipeline runs immediately.

For repeatable setups use the CLI with a JSON definition, or define it in CloudFormation, CDK or Terraform.

The service role is the IAM role CodePipeline assumes to call other services for you. It needs access to the artifact bucket, and permission to start the actions you configured, such as codebuild:StartBuild or codedeploy:CreateDeployment.

It is separate from the roles used by CodeBuild or CodeDeploy, which do the actual work with their own permissions.

Most permission errors in a new pipeline come from this role missing an action or a resource ARN.

CodePipeline has two pricing models depending on the pipeline type:

You also pay separately for the services it calls, like CodeBuild minutes, S3 storage for artifacts and KMS requests. Check the current pricing page for exact rates and free tier limits.

V2 is the newer pipeline type and adds features V1 lacks, plus a different billing model.

New pipelines should generally use V2 unless you have a strong reason to stay on V1.

AWS CodeConnections (formerly CodeStar Connections) lets AWS services access third-party repositories like GitHub, GitLab and Bitbucket. You create a connection resource, then authorize it once through the provider's app installation.

Pipelines reference the connection ARN in the source action. A connection stays in the PENDING state until someone completes the handshake, and a pipeline using a pending connection cannot fetch code.

It replaces the older GitHub OAuth token (version 1) source action, which is no longer recommended.

Variables are values a pipeline can read at runtime. There are two groups:

• Action output variables - values produced by actions, like #{SourceVariables.CommitId}.
• Pipeline-level variables (V2) - values set at start time, referenced as #{variables.env}.

Built-ins such as #{codepipeline.PipelineExecutionId} are always available. Variables can feed action configuration, for example passing a commit ID to CodeBuild as an environment variable.

From the console, open the pipeline and choose Release change. From the CLI:

aws codepipeline start-pipeline-execution --name my-pipeline

This runs the latest revision from the source. With V2 you can also pass variables using --variables, or a specific source revision with --source-revisions.

To follow progress, use aws codepipeline get-pipeline-state --name my-pipeline.

It depends on the provider. CodeCommit, S3 and ECR sources use Amazon EventBridge rules: an event fires when a branch is updated, an object is put or an image is pushed, and the rule starts the pipeline.

Third-party repositories use CodeConnections, which handle the webhook events for you. The older method, polling (PollForSourceChanges), checks periodically and is discouraged because it is slower.

For S3, CloudTrail data events must be enabled for the bucket so EventBridge can see object writes.

Actions run on separate compute, so they cannot pass files directly. CodePipeline uploads each action's output to an S3 artifact bucket, and the next action downloads it as input.

The bucket also keeps revision data for retries. Objects are encrypted with the default S3 key, or with a customer-managed KMS key if you configure one, which is required for cross-account access.

A pipeline with actions in several regions needs one artifact bucket per region.

You add a Build (or Test) action with the provider AWS CodeBuild and point it at a build project. CodePipeline passes the input artifact, CodeBuild runs the commands in buildspec.yml and then returns the files listed under artifacts as the output artifact.

version: 0.2
phases:
  build:
    commands:
      - mvn -q package
artifacts:
  files:
    - target/app.jar

A failing command makes the build fail, which fails the action and stops the stage.

Add a Deploy action with the provider AWS CloudFormation and choose an action mode:

• CREATE_UPDATE - create or update a stack directly.
• CHANGE_SET_REPLACE then CHANGE_SET_EXECUTE - create a change set, review it, then apply.
• REPLACE_ON_FAILURE - recreate the stack if it failed.
• DELETE_ONLY - remove a stack.

The template comes from an input artifact. The action also needs a CloudFormation role that can create the resources in the template.

Add an Approval action, choose Manual approval and select an SNS topic. When the pipeline reaches it, CodePipeline publishes a message to the topic with a review link.

1. Create an SNS topic and subscribe reviewers by email or chat.
2. Allow the pipeline service role to sns:Publish.
3. Give reviewers codepipeline:PutApprovalResult.
4. Optionally add a review URL and comments.

Reviewers then open the console and choose Approve or Reject.

When an action fails, the stage is marked Failed and the pipeline stops progressing. The revision stays at that stage, and nothing later runs.

You can choose Retry stage to rerun either all actions or only the failed actions in that stage, without repeating earlier stages. In V2 you can also configure a stage on-failure condition to retry automatically or roll back.

If the fix is in code, a new commit starts a fresh execution instead.

Give the actions the same runOrder value. Actions with the same number run at the same time; higher numbers wait until all lower numbers finish.

"actions": [
  { "name": "UnitTests",  "runOrder": 1 },
  { "name": "LintCheck",  "runOrder": 1 },
  { "name": "Package",    "runOrder": 2 }
]

Here the tests and lint run together, then Package starts once both succeed.

These V2 modes decide what happens when a new change arrives while a run is in progress.

Use QUEUED when every commit must be deployed in order, and SUPERSEDED when only the latest commit matters.

Use output variables with a namespace. Give the producing action a namespace, then reference its variables in a later action with #{namespace.variableName}.

# CodeBuild environment variable set from a source action
CommitId = #{SourceVariables.CommitId}

CodeBuild can export its own variables via exported-variables in buildspec.yml, which later actions can read. Variables are for small strings; use artifacts for files.

The standard Amazon ECS deploy action performs a rolling update. It reads an imagedefinitions.json file from the build artifact, which maps a container name to a new image URI, then updates the service with a new task definition revision.

[{"name": "web", "imageUri": "123456789012.dkr.ecr.us-east-1.amazonaws.com/web:1.4.2"}]

For blue/green, use the ECS (Blue/Green) action with CodeDeploy, which needs appspec.yaml and a task definition instead.

There are three common routes. The simplest is a CloudFormation deploy action using a SAM or CDK template, where CodeBuild first runs sam package to upload code to S3.

A second option is CodeDeploy with a Lambda deployment group, which shifts alias traffic gradually (canary or linear) and can roll back on a CloudWatch alarm.

Third, an Invoke action can call a custom Lambda that updates function code directly, though that gives you no built-in traffic shifting.

CodePipeline emits state-change events to Amazon EventBridge for pipelines, stages and actions, such as CodePipeline Pipeline Execution State Change.

You can create a rule that matches FAILED and sends it to SNS, Lambda or a chat channel. Notification rules through AWS Chatbot offer a simpler path for Slack or Teams.

CloudTrail records API calls such as UpdatePipeline for auditing, and the console shows execution history.

Never hard-code secrets in the pipeline definition or the repository. Store them in AWS Secrets Manager or Systems Manager Parameter Store and read them at build time.

In CodeBuild you can map them as environment variables of type SECRETS_MANAGER or PARAMETER_STORE. The build role needs read permission on just those secrets.

Also enable KMS encryption on the artifact bucket and avoid printing secret values to build logs.

Add an Invoke action with the AWS Lambda provider and set the function name. CodePipeline passes a job event containing artifact locations and user parameters.

The function must report back by calling PutJobSuccessResult or PutJobFailureResult with the job ID, otherwise the action waits until it times out.

codepipeline.put_job_success_result(jobId=event["CodePipeline.job"]["id"])

Use V2 triggers. In the pipeline definition, add a trigger on the source action with filters for pushes or pull requests.

• Branches - include or exclude patterns like release/*.
• Tags - start only on tags like v*.
• File paths - run only when files under services/api/** change.

This is useful in monorepos, where you do not want every commit to start every pipeline.

CodePipeline is a managed AWS service focused on orchestration, while Jenkins is a self-hosted automation server you install and maintain.

Jenkins can also be a build provider inside CodePipeline, so the two can coexist.

Pick CodePipeline when your delivery is AWS-centric: deploying via CloudFormation, CodeDeploy or ECS, needing IAM roles instead of stored keys, and cross-account promotion with AWS-native audit trails.

Pick GitHub Actions when your code and workflow live in GitHub, you want a large marketplace of ready actions and prefer YAML next to the code.

Many teams mix them: GitHub Actions runs tests and CodePipeline handles controlled deployments.

You can describe a pipeline with CloudFormation (AWS::CodePipeline::Pipeline), AWS CDK, Terraform or a JSON file used with the CLI.

aws codepipeline get-pipeline --name my-pipeline > pipeline.json
aws codepipeline update-pipeline --cli-input-json file://pipeline.json

Keeping the definition in version control makes changes reviewable and lets you recreate the pipeline in another account or region. With CDK you can use the higher-level CDK Pipelines construct.

A common pattern is one tooling account that owns the pipeline and deploys into dev, test and prod accounts.

1. Create a customer-managed KMS key in the tooling account and use it to encrypt the artifact bucket.
2. Allow the target account to use that key and to read the bucket via resource policies.
3. Create a deployment role in each target account that trusts the pipeline role.
4. Set the roleArn on each cross-account action so CodePipeline assumes it.

CodeCommit or ECR sources can also live in a separate account, using a role with access to them.

A pipeline lives in one region, but individual actions can run in other regions using the region field on the action.

The pipeline uses artifactStores (plural) with one S3 bucket per region instead of a single artifactStore. CodePipeline copies artifacts to the bucket in the target region before the action runs.

Each region's bucket needs the right permissions, and a KMS key for that region if you use encryption.

By default, artifacts are encrypted with the AWS managed key aws/s3. Its key policy cannot be edited, so it cannot be shared with another account.

A customer-managed key has a key policy you control. You grant the target account's deployment role kms:Decrypt and related actions, so it can read the artifacts.

Without it, the deploy action in the other account fails with an AccessDenied error when trying to download the artifact.

A run moves through a fixed sequence:

flowchart LR
  A["Change detected"] --> B["Source action"]
  B --> C["Artifact saved to S3"]
  C --> D["Build action"]
  D --> E["Test action"]
  E --> F{Approval?}
  F -->|Approved| G["Deploy action"]
  F -->|Rejected| H["Execution failed"]

The source action fetches the revision and stores it as an artifact. Each later action downloads its input, does its job through its provider, and uploads output. If an action fails or an approval is rejected, the execution stops at that stage.

Blue/green in CodePipeline is done by CodeDeploy, which the pipeline triggers in the Deploy stage.

• ECS - the ECS (Blue/Green) action shifts an ALB listener from the old task set to a new one.
• EC2 - CodeDeploy provisions a replacement Auto Scaling group and reroutes the load balancer.
• Lambda - CodeDeploy moves alias traffic gradually.

You can add pre- and post-traffic hooks and a CloudWatch alarm so a failure rolls traffic back to the original version. The old environment is kept briefly before termination.

Start by finding which role is failing. The console error usually says whether it is the pipeline service role, the CodeBuild role or the deployment role.

1. Read the failed action's details and CloudTrail event for the denied API call.
2. Check the role's policy for that action and resource ARN.
3. For artifacts, verify S3 and KMS permissions on both sides.
4. Check the trust policy if it is a cross-account role assumption.

The IAM policy simulator helps confirm a fix before rerunning the failed action.

Check these causes in order:

• The connection is still PENDING or was revoked in the provider.
• The EventBridge rule for a CodeCommit source is missing or disabled.
• A V2 trigger filter excludes the branch or file path you changed.
• For S3, versioning or CloudTrail data events are off.
• The commit went to a different branch than the one configured.

Manually run start-pipeline-execution to confirm the pipeline itself works, which separates a trigger problem from a stage problem.

V2 pipelines let you attach conditions to a stage at three points: beforeEntry, onSuccess and onFailure.

Each condition holds rules such as a CloudWatch alarm check, a Lambda invoke, a variable check or a deployment window. If a beforeEntry rule fails, the pipeline can fail, skip or wait, and an onFailure condition can automatically retry the stage or roll back to the last successful execution.

This lets you gate deployments on alarms or time windows without adding a separate approval step.

Focus on the slowest stages first, usually Build and Test.

• Run independent tests and scans in parallel using the same runOrder.
• Enable CodeBuild caching for dependencies and Docker layers.
• Use a larger CodeBuild compute type if builds are CPU bound.
• Trim artifacts so less data is uploaded and downloaded.
• Use trigger filters to skip runs for unrelated changes.

Measure first: the execution history shows per-action durations, so you optimize the real bottleneck.

Use a custom action when no built-in provider fits, for example an in-house test tool.

1. Create the action type with create-custom-action-type, defining category, provider and version.
2. Add the action to a pipeline stage.
3. Run a job worker that calls PollForJobs to find work.
4. Acknowledge with AcknowledgeJob, do the work, then call PutJobSuccessResult or PutJobFailureResult.

The worker can run anywhere with network access to CodePipeline, such as an EC2 instance.

It depends on the execution mode. In the default SUPERSEDED mode, the first run continues, but when the second run reaches a stage that is locked, it waits there. If a third arrives, it supersedes the waiting second one, so the middle commit is never deployed.

In QUEUED mode both are processed in order. In PARALLEL mode both run at once as independent executions.

Choose based on whether every commit must ship or only the newest.

CDK Pipelines is a construct that builds a CodePipeline for deploying CDK apps. It adds a UpdatePipeline (self-mutation) stage right after the build.

That stage runs cdk deploy on the pipeline's own stack. If you changed the pipeline definition in code, such as adding a stage, it updates itself and then restarts the run with the new structure.

You only need to deploy the pipeline manually once. After that, pushing code changes both the app and the pipeline.

Use IAM to separate duties. Give developers codepipeline:StartPipelineExecution and read access, but only release managers codepipeline:PutApprovalResult.

Restrict changes with permissions on UpdatePipeline, and scope policies by pipeline ARN or tags. For cross-account controls, use SCPs at the organization level.

CloudTrail logs every approval and update with the caller identity, giving you an audit trail. You can also send events to EventBridge for alerts.

Build the artifact once, then promote the same artifact through environments so what you test is exactly what you ship.

flowchart LR
  S[Source] --> B["Build once"]
  B --> D["Deploy Dev"]
  D --> T["Deploy Test + integration tests"]
  T --> A{Manual approval}
  A --> P["Deploy Prod"]

Use separate accounts per environment with cross-account roles, environment-specific config via variables or Parameter Store, and an approval before prod. Add alarm-based rollback on the prod deploy.