Most CodePipeline questions on the AWS Certified DevOps Engineer - Professional exam used to be about structure: stages, actions, artifacts, runOrder, transitions and cross-account roles. Those still appear, and our SDLC automation guide covers them. But since the V2 pipeline type arrived, CodePipeline has gained a second layer of behaviour that the exam increasingly tests under release safety: execution modes that decide whether two commits run in parallel or queue, Git triggers that filter on branches, tags and file paths, variables you pass at run time, stage-level conditions that block, skip, fail or roll back a stage, one-shot automatic retry, and a Commands action that runs shell commands without a CodeBuild project.
This guide is a practitioner’s walk through that layer, written for the DOP-C02 exam and verified against the current CodePipeline documentation. It assumes you already know what a stage and an action are and focuses on what V2 adds, where each feature is allowed, and the restrictions that turn into exam distractors.
V1 vs V2: What You Actually Get
A V2 pipeline has the same JSON structure as a V1 pipeline plus extra parameters for triggers, variables and stage lifecycle. Everything V1 can do, V2 can do. The reverse is not true.
| Capability | V1 | V2 |
|---|---|---|
| Stages, actions, artifacts, action-level output variables | Yes | Yes |
| SUPERSEDED execution mode | Yes | Yes |
| QUEUED and PARALLEL execution modes | No | Yes |
| Pipeline-level variables | No | Yes |
| Triggers filtered on Git tags, branches, file paths, pull requests | No | Yes |
| Source revision overrides at start | No | Yes |
| Stage conditions (beforeEntry, onSuccess, onFailure) | No | Yes |
| Entry conditions with the Skip result | No | Yes |
| Stage rollback (manual and automatic) | No | Yes |
| Automatic retry on stage failure | No | Yes |
| Commands action | No | Yes |
Pricing differs too, and the exam likes cost questions:
| Type | Price | Free tier | Notes |
|---|---|---|---|
| V1 | USD 1.00 per active pipeline per month | 1 active pipeline | A pipeline is active if it is older than 30 days and ran at least once that month; no proration |
| V2 | USD 0.002 per action execution minute | 100 minutes per month across all V2 pipelines | Partial minutes round up; manual approval and custom actions are not charged |
A rarely used V1 pipeline that runs one short execution a month costs a dollar. The same pipeline as V2 would cost a few cents. A pipeline with long-running CodeBuild or CodeDeploy actions running dozens of times a day can cost more as V2. The pipeline type is set with the pipelineType field (V1 or V2) in create-pipeline or update-pipeline, and the console offers the switch under pipeline settings.
Exam framing: if a scenario needs any of the V2-only rows above, the answer must include upgrading to V2. If a scenario is purely about a simple pipeline that runs rarely and cost is the concern, V1 at a flat dollar may be the trap answer while V2 at fractions of a cent is correct, or vice versa for a busy pipeline with long actions.
Execution Modes: How Concurrent Executions Behave
Every pipeline execution is a set of source changes moving through the stages. The execution mode decides what happens when a second execution starts before the first finishes.
SUPERSEDED (default, V1 and V2)
Three rules govern this mode:
- A stage is locked while it processes an execution. Only one execution can be in a stage at a time.
- Later executions wait in front of a locked stage. When the stage finishes or fails, the lock releases.
- A newer waiting execution supersedes an older waiting one. If executions 2 and 3 are both waiting for the Deploy stage, execution 3 overtakes and execution 2 never continues.
Superseding only happens between stages. An execution that is already inside a stage is never interrupted. The practical effect is that in a busy pipeline, intermediate commits can be skipped over and only the latest change reaches production. That is usually what you want for a trunk-based main branch.
QUEUED (V2 only)
Stages still lock, but waiting executions form a FIFO queue at each stage entry instead of superseding each other. Every execution eventually runs through every stage in the order it arrived. Use this when every commit must be deployed, for example when each release produces an artifact that must exist, or when integration tests need to run for every change.
PARALLEL (V2 only)
Executions run simultaneously and independently. There are no stage locks and no queues. The console has no single pipeline-state view in this mode; you look at each execution on its own visualization tab. The documented use case is a development environment where each feature branch deploys to its own, unshared target.
PARALLEL has hard restrictions that the exam can test:
- Stage rollback is not available, and an
onFailurecondition with aROLLBACKresult cannot be added to a PARALLEL pipeline. - A CodeCommit or S3 source always clones HEAD at the time the source action starts, regardless of which commit triggered the execution, so two rapid pushes can produce two executions of the same revision. Connection-based sources (GitHub, GitLab, Bitbucket) use the specific commit that triggered them.
- Quotas: 50 concurrent pipeline executions per pipeline in QUEUED or PARALLEL mode, and 5 concurrent action executions per PARALLEL execution.
Switching modes
Changing the executionMode field with update-pipeline has side effects. Moving between SUPERSEDED and QUEUED (either direction) cancels active executions after their in-progress actions complete and cancels pending ones. Moving from SUPERSEDED or QUEUED to PARALLEL does the same and the pipeline-state page becomes empty. Executions that were started in PARALLEL keep running independently when you switch away. Remember also that any update-pipeline call stops the execution currently in flight; you restart it manually.
| Mode | Stage lock | Waiting executions | Rollback allowed | Pipeline type |
|---|---|---|---|---|
| SUPERSEDED | Yes | Newest overtakes older | Yes (V2) | V1, V2 |
| QUEUED | Yes | FIFO per stage | Yes | V2 |
| PARALLEL | No | None, all run | No | V2 |
Triggers and Filters: Starting Pipelines on Git Events
Triggers are configured on source actions that use CodeConnections (CodeStarSourceConnection): GitHub, GitHub Enterprise Server, GitLab.com, GitLab self-managed and Bitbucket Cloud. CodeCommit, S3 and ECR sources do not use triggers; they start pipelines through EventBridge rules, which our EventBridge guide for DOP-C02 covers.
There are three trigger configurations for a connection source:
| Configuration | What starts the pipeline | DetectChanges in the action |
|---|---|---|
| Add a trigger, no filter | Any push to the single branch in the action’s BranchName | true |
| Add a trigger, specify filter | Only events that match the push or pull-request filters | false |
| Do not detect changes | Nothing; manual or API start only | false |
With a filter, the pipeline fetches the exact commit that caused the event, and BranchName in the action configuration only matters for manual starts, where it is the default branch used.
Push filters
A push filter can match on branches, Git tags and file paths, each with includes and excludes lists of glob patterns. Valid combinations are tags alone, branches alone, or branches plus file paths. For a push, the branch evaluated is the one being pushed to.
Pull request filters
A pull request filter matches on events (OPEN, UPDATED, CLOSED) plus branches and optionally file paths. The branch evaluated is the destination branch of the pull request, but the execution builds the commit from the source branch being merged in. Provider behaviour differs for CLOSED: on GitHub, GitHub Enterprise Server and GitLab, both merging and manually closing a pull request produce the event, while on Bitbucket only a merge does.
How the filters combine
- Multiple filter types in one trigger (two push filters, or a push and a pull request filter) are ORed: any match starts the pipeline.
- Multiple filters inside one type (branches and file paths) are ANDed: all must match.
- Within a filter, excludes take precedence over includes. The same pattern in both means exclude.
- When a commit changes several files, each file is evaluated independently; if any one file passes, the pipeline starts.
"triggers": [
{
"providerType": "CodeStarSourceConnection",
"gitConfiguration": {
"sourceActionName": "Source",
"push": [
{ "tags": { "includes": ["release-*"] } },
{
"branches": { "includes": ["main"], "excludes": ["feature*"] },
"filePaths": { "includes": ["services/api/**"], "excludes": ["**/README.md"] }
}
],
"pullRequest": [
{
"events": ["OPEN", "UPDATED"],
"branches": { "includes": ["main"] }
}
]
}
}
]That configuration starts the pipeline for any release-* tag, for pushes to main that touch the API service (but not only a README), and when a pull request into main is opened or updated.
Limits and gotchas
- One trigger per source action, up to 50 triggers per pipeline across push and pull request configurations.
- Up to 3 filters per push or pull request type, and up to 8 include and 8 exclude patterns per filter, each at most 255 characters.
- A branch-plus-file-path filter will not fire on the first push of a brand-new branch, because there is no file diff to evaluate yet.
- Merging a pull request can start two executions if a push filter on the destination branch and a pull request
CLOSEDfilter both match. - Glob syntax:
*matches within a path segment,**crosses directories,?matches one character,{a,b}groups alternatives.
Tag-based triggers are the exam’s favourite: the team wants production deployed only when a release tag is pushed is answered by a V2 pipeline with a push trigger filtered on tags, not by an EventBridge rule or a Lambda webhook.
Pipeline-Level Variables and Source Overrides
V1 pipelines only have action output variables (#{SourceVariables.CommitId}) and the reserved #{codepipeline.PipelineExecutionId}. V2 adds pipeline-level variables declared in the pipeline structure and referenced with the variables namespace:
"variables": [
{ "name": "TargetEnv", "defaultValue": "staging", "description": "Deployment environment" },
{ "name": "ImageTag", "description": "Container tag to deploy" }
]aws codepipeline start-pipeline-execution --name ServicePipeline \
--variables name=TargetEnv,value=prod name=ImageTag,value=2026.10.21Rules worth memorising:
- A variable without a
defaultValueis required; starting the pipeline without overriding it fails validation. - Reference syntax is
#{variables.TargetEnv}in any action configuration field (1,000-character field limit still applies). - Pipeline-level variables cannot be used in Source actions.
- Up to 50 variables per pipeline, values up to 1,000 characters, descriptions up to 200.
- If an action already uses
variablesas its namespace, rename it; namespaces must be unique.
The use case the exam describes is one pipeline, many environments or versions, chosen at start time, without duplicating the pipeline. Previously that required separate pipelines or a parameterised CodeBuild hack.
Source revision overrides are the second V2-only start-time feature. start-pipeline-execution --source-revisions lets you pin a specific COMMIT_ID (CodeCommit or connection sources), IMAGE_DIGEST (ECR) or S3_OBJECT_VERSION_ID / S3_OBJECT_KEY (S3; the key override needs AllowOverrideForS3ObjectKey set to true on the action). This is how you redeploy exactly commit abc123 to production without pushing anything.
Source actions also expose extra output variables under their namespace depending on how the execution started: TagName only for tag triggers, PullRequestId, PullRequestTitle, SourceBranchName and DestinationBranchName only for pull request triggers, and BranchName for pushes and tags.
Stage Conditions: Gates Before, After Success and After Failure
Stage conditions are the heart of V2 release safety. Each stage can carry up to three condition blocks. Each block contains conditions, each condition contains an ordered rule set, and all rules in a condition must pass for the condition to pass. When a condition fails, its configured result is applied.
| Block | When it is evaluated | Allowed results | Typical use |
|---|---|---|---|
beforeEntry | Before the stage starts | FAIL, SKIP | Block production entry while a CloudWatch alarm is in ALARM; skip a stage unless a variable matches |
onSuccess | After all actions succeed | FAIL, ROLLBACK | Bake time: watch an alarm for N minutes after deploy and roll back if it fires; enforce a deployment window |
onFailure | When the stage fails | ROLLBACK, RETRY (and the default FAIL) | Roll back automatically, or retry once |
The rule providers
| Rule | Checks | Key parameters |
|---|---|---|
CloudWatchAlarm | The state of a CloudWatch alarm | AlarmName, AlarmStates, WaitTime in minutes: if the alarm is in ALARM at first check, CodePipeline waits this long; if it is OK, the rule passes immediately |
LambdaInvoke | A Lambda function you write reports success or failure | FunctionName, UserParameters, TimeoutInMinutes, optional role ARN, input artifacts |
DeploymentWindow | Whether the current time is inside a cron-defined window | Cron (six required fields plus optional year, with ?, L, W and # support) and TimeZone (America/New_York, UTC+05:30 or an abbreviation) |
VariableCheck | A pipeline or action variable against a value | Variable, Value, Operator: EQ, NE, CONTAINS, MATCHES (Java regex) |
CodeBuild | Whether a CodeBuild project build succeeds | ProjectName, PrimarySource, EnvironmentVariables |
Commands | Whether inline shell commands succeed on managed compute | commands, input artifacts; same 55-minute limit as the Commands action |
Example: a production stage that refuses to start while the error-rate alarm is firing, and rolls back if the alarm fires within 60 minutes of a successful deploy:
{
"name": "Prod",
"actions": [ "...deploy actions..." ],
"beforeEntry": {
"conditions": [{
"result": "FAIL",
"rules": [{
"name": "ProdHealthy",
"ruleTypeId": { "category": "Rule", "owner": "AWS", "provider": "CloudWatchAlarm", "version": "1" },
"configuration": { "AlarmName": "prod-5xx-rate", "WaitTime": "5" },
"region": "us-east-1"
}]
}]
},
"onSuccess": {
"conditions": [{
"result": "ROLLBACK",
"rules": [{
"name": "BakeTime",
"ruleTypeId": { "category": "Rule", "owner": "AWS", "provider": "CloudWatchAlarm", "version": "1" },
"configuration": { "AlarmName": "prod-5xx-rate", "WaitTime": "60" },
"region": "us-east-1"
}]
}]
}
}Restrictions that become exam traps
SKIPonly works with theLambdaInvokeandVariableCheckrules, and a condition with aSKIPresult cannot be overridden at run time. A skipped stage shows statusSkippedand its actions show Didn’t Run; you cannot manually retry or roll back to a skipped stage.- Every other condition can be overridden when a pipeline execution is running (the console shows an Override button and the rule status becomes Abandoned). An overridden
beforeEntry FAILlets the stage proceed; an overriddenonFailure ROLLBACKleaves the stage failed. - You cannot combine automatic stage retry with
onFailureconditions on the same stage. Retry and rollback-on-failure are alternatives, not a chain. - A
ROLLBACKresult only works if a previous successful execution exists in the current pipeline structure version; editing the pipeline resets that history. ROLLBACKresults are not allowed in PARALLEL mode.- The
CloudWatchAlarmrule andDeploymentWindowrule need no code;LambdaInvokeneeds a function that calls back with success or failure, similar to a Lambda invoke action.
Stage conditions replace a lot of older glue. Where you once wrote a Lambda invoke action that polled an alarm, or a manual approval that a human clicked only during office hours, a CloudWatchAlarm or DeploymentWindow rule does it natively. Approvals and the older patterns are in the CI/CD guide; the monitoring side of composite alarms is in the DevOps monitoring guide.
Automatic and Manual Retry
Any pipeline, V1 or V2, supports manual retry of a failed stage through the console or retry-stage-execution with --retry-mode FAILED_ACTIONS (rerun only failed actions; in-progress ones continue) or ALL_ACTIONS (rerun the stage from its first action; no actions may be in progress). A retry overwrites output artifacts of previously successful actions in that execution. You cannot retry if the pipeline structure changed after the failure, if another retry is in progress, or if a newer execution has already superseded the failed one.
Automatic retry is V2 only. It is configured as an onFailure result of RETRY with a retryConfiguration:
"onFailure": {
"result": "RETRY",
"retryConfiguration": { "retryMode": "FAILED_ACTIONS" }
}Two facts the exam checks: it makes exactly one retry attempt, and it can be configured on any stage including Source. If the retry also fails, the stage fails normally. If you need more than one attempt or conditional logic, the answer is not automatic retry; it is a LambdaInvoke rule, a Step Functions action, or fixing the flaky action.
Stage Rollback
A rollback is a new pipeline execution of type rollback that re-runs the stage with the source revisions and variables of a previous successful execution in that stage. It is not an undo; it is a redeploy of a known-good input. It can be triggered manually with rollback-stage --target-pipeline-execution-id or automatically through an onFailure or onSuccess condition with the ROLLBACK result.
Documented restrictions:
- You cannot roll back a Source stage.
- The target execution must have been started in the current pipeline structure version.
- You cannot roll back to an execution that was itself a rollback.
- Rollback is unavailable in PARALLEL mode.
- CodePipeline uses the target execution’s variables and artifacts, so pipeline-level variable overrides from the failed run are not carried into the rollback.
Rollback at the pipeline level is orthogonal to rollback inside a deploy action. CodeDeploy can roll back a deployment group on alarm or failure, CloudFormation rolls back a failed stack update, and ECS has its own circuit breaker; those happen inside one action. A CodePipeline stage rollback re-runs the whole stage with the previous inputs and therefore works for any action type, including S3 and Lambda deployments that have no native rollback. The deployment-level mechanisms are compared in our deployment strategies guide.
The Commands Action
The Commands action (Compute / AWS / Commands / 1) runs shell commands on CodePipeline-managed CodeBuild compute without creating a CodeBuild project. It is V2 only.
name: SmokeTest
actionTypeId:
category: Compute
owner: AWS
provider: Commands
version: '1'
runOrder: 2
configuration:
EnvironmentType: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
commands:
- 'echo Testing #{codepipeline.PipelineExecutionId} against #{variables.TargetEnv}'
- 'curl -sf https://$API_HOST/healthz'
- 'export BUILD_STAMP=$(date +%s)'
inputArtifacts:
- name: BuildArtifact
outputArtifacts:
- name: TestReport
files:
- 'reports/**/*'
outputVariables:
- BUILD_STAMP
environmentVariables:
- name: API_HOST
value: 'api.staging.example.com'
type: PLAINTEXT
- name: API_TOKEN
value: 'staging/api-token'
type: SECRETS_MANAGER
namespace: SmokeVarsWhat to know about it:
- Compute and billing. It uses CodeBuild under the hood, incurs separate CodeBuild charges, counts against the account’s concurrent build quota, and times out at 55 minutes. Defaults are
LINUX_CONTAINERwithBUILD_GENERAL1_SMALL;WINDOWS_SERVER_2022_CONTAINERis available with medium or large compute. OptionalVpcId,SubnetsandSecurityGroupIdsgive it VPC access. - Commands are single-line strings. Multi-line YAML blocks are rejected.
- Artifacts. 1 to 10 input artifacts, 0 or 1 output artifact declared with
filespatterns using CodeBuild’s buildspec file syntax. - Output variables are environment variables you export, listed under
outputVariablesand consumed downstream through the action’snamespace. - Secrets. The
SECRETS_MANAGERenvironment variable type is supported only by the Commands action; the value is the secret name, and values are redacted in logs. The pipeline service role needssecretsmanager:GetSecretValueon that secret. - Logs and IAM. Logs go to the log group
/aws/codepipeline/PIPELINE_NAME. The pipeline service role needslogs:CreateLogGroup,logs:CreateLogStreamandlogs:PutLogEventson that group, and console users need log-read permission to view them inline. - Cross-account is supported via
actionRoleArn, and the action runs with the pipeline service role, so scope that role down.
When should you still use a CodeBuild action? When you need a buildspec with phases, local or S3 caching, batch builds, test report groups, custom images, GPU or ARM fleets, or reserved capacity. The Commands action is for short glue: smoke tests, packaging tweaks, calling an API, computing a variable. The exam distinguishes simplest way to run a few commands in a pipeline (Commands action) from build with caching and reports (CodeBuild action). Package management for those builds is covered in our CodeArtifact guide.
Scenario Drill
| Scenario | Answer | Why |
|---|---|---|
Deploy to production only when a Git tag matching v* is pushed to GitHub | V2 pipeline, CodeConnections source, push trigger with a tags include filter | Tag filtering is a V2 trigger feature; EventBridge does not see GitHub tags |
Monorepo: only start the pipeline when files under services/api/ change on main | Push trigger with branches include main AND filePaths include services/api/** | Filters within one type are ANDed |
| Every commit must be deployed in order, none skipped | executionMode: QUEUED | SUPERSEDED skips intermediate executions; PARALLEL has no ordering |
| Dozens of feature branches each deploy to their own ephemeral environment | executionMode: PARALLEL with a branch-filtered push trigger | Independent executions; accept no rollback |
| Block production deploys while the error-rate alarm is in ALARM | beforeEntry condition, CloudWatchAlarm rule, result FAIL | Entry gate; can be overridden by an operator |
| Roll back automatically if the alarm fires within 30 minutes after a successful deploy | onSuccess condition, CloudWatchAlarm rule with WaitTime 30, result ROLLBACK | Bake-time pattern |
| Only allow deployments Monday to Friday 09:00 to 17:00 local time | DeploymentWindow rule with Cron and TimeZone | Native rule; no Lambda or approval needed |
Skip the integration-test stage when the commit message contains [skip-tests] | beforeEntry with SKIP and a VariableCheck rule on #{SourceVariables.CommitMessage} with CONTAINS | Only VariableCheck and LambdaInvoke support SKIP |
| A flaky deploy action fails occasionally; retry it once without a human | onFailure result RETRY, retryMode: FAILED_ACTIONS | One automatic attempt; cannot be combined with onFailure rollback conditions |
| Redeploy the exact commit that is running in staging to production without a new push | start-pipeline-execution --source-revisions with COMMIT_ID | Source revision override, V2 only |
| Same pipeline deploys to dev, test or prod chosen at start time | Pipeline-level variable TargetEnv referenced as #{variables.TargetEnv} | Required variable with no default forces the operator to choose |
| Run three shell commands between build and deploy with no CodeBuild project | Commands action | V2 only; separate CodeBuild charges |
| Roll back a stage that is in PARALLEL mode | Not possible; switch to QUEUED or SUPERSEDED | Documented restriction |
| Low-traffic pipeline runs once a month; minimise cost | V2 (a few cents) over V1 (USD 1 per active pipeline) | V2 bills per action minute |
Common Mistakes
- Expecting QUEUED or PARALLEL on a V1 pipeline. Both require V2; the console labels them Pipeline type V2 required.
- Assuming SUPERSEDED runs every commit. Waiting executions are overtaken; only the newest waiting execution continues.
- Using a trigger filter and still expecting
BranchNameto control automatic starts. With a filter,DetectChangesisfalseandBranchNameonly applies to manual starts. - Putting branch and file-path filters in separate push filter objects when you meant AND. Separate filter objects are ORed; put both inside one object to AND them.
- Configuring both automatic retry and an
onFailurerollback on one stage. Not allowed. - Trying to override a
SKIPentry condition. OnlyFAILandROLLBACKresults can be overridden. - Rolling back after editing the pipeline. Rollback targets must come from the current structure version.
- Rolling back the Source stage. Not supported; roll back the deploy stage.
- Treating the Commands action as free. It is billed as CodeBuild compute and counts toward CodeBuild concurrency.
- Forgetting that
update-pipelinestops the in-flight execution. Changing the execution mode or adding a condition halts whatever is running.
Practice Release-Safety Scenarios Under Exam Conditions
DOP-C02 questions in this area are long: a paragraph of context, four plausible pipeline designs, and one word (every commit, tag, only during business hours, without a CodeBuild project) that decides the answer. The way to get fast at them is repetition against realistic distractors, which is what Sailor.sh’s AWS Certified DevOps Engineer - Professional (DOP-C02) Mock Exam Bundle is built for: eight full-length exams with explanations that spell out why the V1 answer, the PARALLEL answer or the Lambda-glue answer is wrong. If you are planning your study order, the DOP-C02 study plan places SDLC automation first because Domain 1 carries the largest weight; cross-account and cross-Region pipeline design, which pairs naturally with this article, is in our multi-account CI/CD guide.
Frequently Asked Questions
What is the difference between CodePipeline V1 and V2 pipeline types?
V2 has the same structure as V1 plus pipeline-level variables, Git triggers with branch, tag, file-path and pull-request filters, QUEUED and PARALLEL execution modes, source revision overrides, stage conditions, automatic retry, stage rollback and the Commands action. V1 is billed at one dollar per active pipeline per month; V2 is billed per action execution minute with 100 free minutes a month.
What happens to waiting executions in SUPERSEDED mode?
Stages lock while processing one execution. Executions waiting in front of a locked stage are overtaken by newer ones; only the most recent waiting execution enters when the stage unlocks, and superseded executions do not continue. Switch to QUEUED to process every execution in order.
Can I roll back a stage in a PARALLEL mode pipeline?
No. Stage rollback is not available in PARALLEL mode, and onFailure or onSuccess conditions with a ROLLBACK result cannot be added to a PARALLEL pipeline.
How do I start a CodePipeline only when a Git tag is pushed?
Use a V2 pipeline with a CodeConnections source (GitHub, GitLab or Bitbucket) and add a push trigger with a tags include filter such as release-*. Tag filtering is not available for CodeCommit, S3 or ECR sources, which rely on EventBridge.
Which rules can be used with the Skip result in an entry condition?
Only LambdaInvoke and VariableCheck. A SKIP condition cannot be overridden at run time, and a skipped stage cannot be retried or used as a rollback target.
How many times does automatic retry run?
Once. Configure onFailure with result RETRY and a retryMode of FAILED_ACTIONS or ALL_ACTIONS. It can be set on any stage, including Source, but cannot be combined with onFailure conditions on the same stage.
Is the Commands action free?
No. It runs on CodePipeline-managed CodeBuild compute and incurs separate CodeBuild charges, counts toward the CodeBuild concurrent build quota, and has a 55-minute timeout. It is only available on V2 pipelines.
Can pipeline-level variables be used in the Source action?
No. Pipeline-level variables (#{variables.name}) can be referenced in any action except Source actions. To change what the source fetches, use a source revision override at start time instead.
Conclusion
The V2 pipeline type turns CodePipeline from an orchestrator into a release-safety system. Execution modes decide whether commits supersede, queue or run in parallel. Triggers filter Git events by branch, tag, file path and pull request, with OR between filter types, AND within a type, and excludes winning. Pipeline-level variables and source revision overrides parameterise a single pipeline at start time. Stage conditions gate entry, watch for bake-time alarms, enforce deployment windows and check variables, with FAIL, SKIP, ROLLBACK and RETRY results that each carry restrictions the exam will test. The Commands action removes the need for a CodeBuild project for short glue steps. Learn which features are V2-only, which are blocked in PARALLEL mode, and which results cannot be combined or overridden, and the long scenario questions in Domain 1 become pattern matching rather than guesswork.