Study guide
1.3 Source Control Workflows, Webhooks & Branching Models
AWS Certified DevOps Engineer – Professional Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: CI/CD Pipeline Architecture & Source Integration
1.1 Multi-Stage & Multi-Account CodePipeline Design 1.2 CodeBuild Projects, Build Environments & Pipeline Secrets 1.3 Source Control Workflows, Webhooks & Branching Models
2 Chapter 2: Automated Testing, Test Gates & Quality Verification
2.1 Automated Unit, Integration & Acceptance Testing in Pipelines 2.2 Load Testing, Performance Benchmarking & Synthetic Canaries 2.3 Security Scanning, SAST/DAST & Approval Gates
3 Chapter 3: Artifact Management & Multi-Platform Deployment Strategies
3.1 Artifact Lifecycle Management with CodeArtifact, ECR & S3 3.2 Automated Image Baking with EC2 Image Builder 3.3 In-Place, Rolling & Immutable Deployments on EC2 3.4 Blue/Green & Canary Deployments for ECS, EKS & Lambda
4 Chapter 4: CloudFormation, CDK & Reusable IaC Components
4.1 Advanced CloudFormation: Nested Stacks, Change Sets & Custom Resources 4.2 Cross-Account & Multi-Region StackSets & Drift Detection 4.3 Modern IaC: AWS CDK, SAM & Service Catalog Governance
5 Chapter 5: Multi-Account Architecture, Organizations & Control Tower
5.1 AWS Organizations Hierarchy, OUs & Account Provisioning 5.2 Service Control Policies (SCPs) & Multi-Account Guardrails 5.3 AWS Control Tower, Account Factory & Landing Zone Automation
6 Chapter 6: Systems Manager & Large-Scale Fleet Configuration
6.1 SSM Agent, Hybrid Activation & Session Manager 6.2 Systems Manager Run Command, State Manager & Associations 6.3 Patch Manager, Parameter Store vs Secrets Manager & AppConfig
7 Chapter 7: High Availability & Multi-Region Resiliency
7.1 Designing Resilient Multi-AZ & Multi-Region Architectures 7.2 Route 53 Traffic Flow, Health Checks & DNS Failover 7.3 Data Replication: Aurora Global DB, DynamoDB Global Tables & S3 CRR
8 Chapter 8: Scalability, Auto Scaling & Disaster Recovery Automation
8.1 EC2 Auto Scaling Policies, Lifecycle Hooks & Warm Pools 8.2 Container & Serverless Scalability: ECS Capacity Providers, EKS & API Gateway 8.3 Disaster Recovery Strategies: RTO, RPO & Architecture Tiers 8.4 Automated Backup & Recovery with AWS Backup & Elastic Disaster Recovery
9 Chapter 9: CloudWatch Metrics, Agent Collection & Log Aggregation
9.1 CloudWatch Metrics, Dimensions, Metric Math & High Resolution 9.2 Unified CloudWatch Agent & Custom Metric Collection 9.3 Centralized Log Aggregation, Retention & Cross-Account Subscriptions
10 Chapter 10: Log Analysis, Dashboards & Distributed Tracing with X-Ray
10.1 CloudWatch Logs Insights, Filter Syntax & Query Optimization 10.2 CloudWatch Dashboards, Composite Alarms & Anomaly Detection 10.3 Distributed Tracing with AWS X-Ray & Service Maps
11 Chapter 11: Automated Observability & Event-Driven Monitoring
11.1 Application & Infrastructure Health Checks with Route 53 & ALB 11.2 Centralized Observability with Amazon OpenSearch & Athena 11.3 Synthetic Monitoring with CloudWatch Synthetics Canaries
12 Chapter 12: Event-Driven Incident Detection & Notification Pipelines
12.1 AWS Health, CloudTrail Events & Operational Notification 12.2 EventBridge Event Routing, Patterns & Multi-Account Buses 12.3 Asynchronous Event Processing: SNS, SQS Queues & Dead-Letter Handling
13 Chapter 13: Automated Remediation & Deployment Troubleshooting
13.1 AWS Config Managed Rules & Automated Remediation with SSM 13.2 Event-Driven Infrastructure Self-Healing with Lambda & Step Functions 13.3 Troubleshooting CI/CD Pipeline & Deployment Failures 13.4 Root Cause Analysis for Auto Scaling & Container Failures
14 Chapter 14: Identity, Access Management & Secrets at Scale
14.1 IAM Policy Evaluation Logic, NotAction & Explicit Denies 14.2 IAM Permissions Boundaries & Delegated Administration 14.3 IAM Identity Center, Cross-Account Roles & STS Session Policies 14.4 Automated Secrets Management & Secret Rotation with Secrets Manager
15 Chapter 15: Security Automation, Data Protection & Compliance Auditing
15.1 Network Security Automation: Security Groups, NACLs, Network Firewall & WAF 15.2 Cryptographic Controls & Key Management with AWS KMS & ACM 15.3 Automated Threat Detection: GuardDuty, Inspector & Security Hub 15.4 Continuous Compliance Auditing & Log Integrity with CloudTrail & Config
1.3 Source Control Workflows, Webhooks & Branching Models
Key Takeaways Explain This Topic AI
AWS CodeStar Connections (now AWS CodeConnections) creates secure, OAuth-based links to external VCS providers (GitHub, GitHub Enterprise, Bitbucket, GitLab), replacing legacy personal access tokens with managed connection resources.
Amazon EventBridge rules triggered by source repository events deliver real-time, event-driven pipeline executions, superseding legacy periodic polling and eliminating API rate limit bottlenecks.
Branching strategies dictate pipeline topology: trunk-based development utilizes high-frequency automated CI/CD directly from short-lived branches into main with feature flags, whereas GitFlow demands separate pipelines across long-lived branches.
Automated pull request (PR) validation workflows use EventBridge to trigger isolated CodeBuild verification projects on PR creation or synchronization, reporting status checks back to VCS branch protection rules before merge authorization.
Mono-repository architectures prevent redundant builds by using EventBridge and AWS Lambda path evaluators to inspect Git commit file diffs, triggering only the specific CodePipeline pipelines associated with modified directories.
Last updated: September 2026
Modern Source Control Integration with AWS CodeConnections
Connecting external Version Control Systems (VCS)—such as GitHub, GitHub Enterprise Server, Bitbucket Cloud, or GitLab—to AWS CI/CD pipelines historically required personal access tokens (PATs) or static webhook secrets. Modern AWS architectures utilize AWS CodeStar Connections (now officially known as AWS CodeConnections ), which provides managed, OAuth-based integrations with external source providers.
The CodeConnections Resource Lifecycle
A CodeConnection is a regional AWS resource ( AWS::CodeStarConnections::Connection ) that acts as an authenticated bridge between AWS and your source repository provider:
Resource Provisioning : The connection is provisioned via AWS CloudFormation, the AWS CLI, or the AWS Management Console.
Initial Status ( PENDING ) : When created via CloudFormation or CLI, the connection is in a PENDING state. It cannot yet access repositories.
Interactive Handshake : An administrator must log into the AWS Management Console, navigate to the connection, and initiate the OAuth handshake. This installs the AWS GitHub App or Bitbucket App into the source control organization and authorizes repository access.
Active Status ( AVAILABLE ) : Once authorized, the status transitions to AVAILABLE , and downstream CodePipeline source actions can bind to the connection using its Amazon Resource Name (ARN). {
- "ActionTypeId": {
- "Category": "Source",
- "Owner": "AWS",
- "Provider": "CodeStarSourceConnection",
- "Version": "1"
- },
- "Name": "GitHubSource",
- "Configuration": {
"ConnectionArn": "arn:aws:codestar-connections:us-east-1:111111111111:connection/a1b2c3d4-5678-90ef-ghij-1234567890ab",
- "FullRepositoryId": "enterprise-org/payment-service",
- "BranchName": "main",
- "OutputArtifactFormat": "CODE_ZIP",
- "DetectChanges": "true"
- },
- "OutputArtifacts": [
- {
- "Name": "SourceOutput"
- }
- ],
- "RunOrder": 1
- }
- Trigger Mechanisms: Webhooks vs. EventBridge Rules
Older pipelines utilized HTTP webhooks managed directly within GitHub or Bitbucket settings. Modern AWS architectures rely on Amazon EventBridge to achieve reliable, decoupled, event-driven pipeline execution.
EventBridge Rule Pattern for CodeConnections
When code is pushed to a connected repository, CodeConnections publishes an event to the default EventBridge bus. An EventBridge rule filters these events and invokes CodePipeline as its target: {
- "source": ["aws.codestar-connections"],
- "detail-type": ["CodeConnections Source Event"],
- "detail": {
- "event": ["referenceCreated", "referenceUpdated"],
- "repositoryId": ["enterprise-org/payment-service"],
- "referenceName": ["main"],
- "referenceType": ["branch"]
- }
- }
- Advantages of EventBridge Over Direct Webhooks
Resilience : EventBridge provides built-in retries, dead-letter queues (DLQs), and event replay capabilities if downstream pipeline targets experience transient throttling.
Multiple Targets : A single Git push event can trigger multiple independent targets concurrently—such as invoking a CodePipeline deployment, triggering an auditing Lambda function, and posting an event to an Amazon SNS topic.
Fine-Grained Filtering : EventBridge event patterns filter by branch name, tag prefix, or author identity without modifying the source control repository webhook configuration.
Branching Strategies and Pipeline Topologies
How teams branch and merge code directly dictates how CI/CD pipelines should be structured across environments.
Trunk-Based Development vs. GitFlow
Attribute Trunk-Based Development (Recommended) GitFlow (Traditional)
Branch Structure Single shared branch ( main or trunk ); short-lived feature branches (< 24 hours) Multiple persistent branches ( main , develop , release/* , hotfix/* , feature/* )
Pipeline Topology Single, continuous pipeline promoting through Dev -> Staging -> Production Separate pipelines for each long-lived branch ( develop -> Dev, release -> Staging, main -> Prod)
Release Mechanism High frequency (multiple times per day) protected by Feature Flags (e.g., AWS AppConfig) Scheduled, batched releases with complex branch merging and release staging
Merge Overhead Minimal merge conflicts due to small, frequent rebases High risk of merge conflicts ("merge hell") and code drift
In high-performing DevOps teams, trunk-based development is preferred because it eliminates long-lived drift. When a developer merges into main , the primary pipeline automatically tests, packages, and deploys the change through staging to production.
Ephemeral "Pipeline-per-Branch" with AWS CDK
For teams requiring dedicated preview environments for active feature branches, organizations implement Pipeline-per-Branch automation:
A developer creates a new feature branch ( feature/user-auth ).
An EventBridge rule detects the branch creation event ( referenceCreated ).
An AWS Lambda function executes an AWS Cloud Development Kit (CDK) or CloudFormation StackSet deployment that provisions an isolated, temporary CI/CD pipeline and ephemeral ECS/Fargate environment.
When the branch is deleted ( referenceDeleted ), EventBridge triggers a teardown Lambda function that destroys the stack and associated resources.
Automated Pull Request (PR) Validation Workflows
Deploying code to production from a feature branch is dangerous, but merging unvalidated code into main compromises the mainline. Teams implement automated pull request validation gates to verify code quality before merging. [ Developer opens Pull Request ] ──> [ GitHub / Bitbucket ]
- │
- Emits PR Event
- │
- ▼
- [ Amazon EventBridge Default Bus ]
- │
- ▼
- [ Isolated AWS CodeBuild Project ]
- Runs Linters & Unit Tests
- Executes SAST Security Scanners
- │
- ▼
- [ ReportBuildStatus to VCS ]
- │
- ▼
- [ GitHub Branch Protection ]
- (Blocks merge if checks fail)
- Implementation Architecture
Event Trigger : When a pull request is opened or updated, the VCS provider emits a pull request event. CodeConnections or a GitHub Webhook forwards this to EventBridge.
Isolated Validation Project : EventBridge triggers an AWS CodeBuild project directly (bypassing CodePipeline entirely, since no deployment is occurring).
Test Execution : CodeBuild executes unit tests, linting, formatting checks, and static application security testing (SAST).
Status Reporting : The CodeBuild project is configured with reportBuildStatus: true or uses a Lambda function to invoke the GitHub Status API ( POST /repos/{owner}/{repo}/statuses/{sha} ). It reports pending , success , or failure .
VCS Branch Protection : Repository branch protection rules on main require the CodeBuild status check to pass before the merge button is enabled.
Mono-Repository Path-Filtering Architectures
Many enterprises consolidate multiple microservices, shared libraries, and infrastructure templates into a single mono-repository (mono-repo): repo-root/
- ├── services/
- │ ├── auth-service/ <-- Microservice 1
- │ ├── billing-service/ <-- Microservice 2
- │ └── notification-service/<-- Microservice 3
- └── infrastructure/ <-- Shared CloudFormation/CDK
- The Mono-Repo Challenge in CodePipeline
By default, an AWS CodePipeline source action triggers a full execution whenever any commit is pushed to the target branch. In a mono-repo with 20 services, a one-line typo fix in auth-service would trigger all 20 pipelines concurrently, causing severe resource wastage, queue contention, and deployment delays.
The EventBridge + Lambda Path Evaluator Pattern
To achieve selective, directory-based pipeline triggering, organizations implement the Path Evaluator Architecture : [ Developer pushes commit to main ]
- │
- ▼
- [ AWS CodeConnections / EventBridge ]
- │
- ▼
- [ EventBridge Rule (Push Event) ]
- │
- ▼
- [ AWS Lambda (Path Evaluator) ]
- 1. Calls VCS API (Compare Commits / git diff-tree)
- 2. Evaluates modified file paths
- 3. Determines affected services
- │
- ┌──────────┴──────────┐
- ▼ ▼
- [ StartPipeline: Auth ] [ StartPipeline: Billing ]
- (Only if /auth altered) (Only if /billing altered)
Disable Native Triggers : In CodePipeline, set DetectChanges: false on the source action, or avoid creating default EventBridge rules pointing directly to the pipelines.
Event Capture : An EventBridge rule captures all push events on the main branch and routes them to an AWS Lambda evaluator function.
Git Diff Analysis : The Lambda function receives the commit SHA and uses the GitHub/Bitbucket REST API (or clones shallow commit metadata) to run: git diff-tree -r --no-commit-id --name-only <before_sha> <after_sha>
Target Routing : Lambda maps the modified paths against a service routing table:
Changes under services/auth-service/** -> trigger CodePipeline-AuthService .
Changes under services/billing-service/** -> trigger CodePipeline-BillingService .
Pipeline Invocation : Lambda calls the CodePipeline SDK ( codepipeline.startPipelineExecution({ name: 'CodePipeline-AuthService' }) ) only for the affected microservices.
Native CodePipeline V2 Trigger Filters
AWS CodePipeline V2 supports native Trigger Filters . You can configure Git tags and file path patterns directly within the pipeline source action trigger definition: {
- "triggers": [
- {
- "providerType": "CodeStarSourceConnection",
- "gitConfiguration": {
- "sourceActionName": "Source",
- "push": [
- {
- "branches": {
- "includes": ["main"]
- },
- "filePaths": {
- "includes": ["services/auth-service/**"],
- "excludes": ["services/auth-service/docs/**", "**/*.md"]
- }
- }
- ]
- }
- }
- ]
- }
This native feature eliminates the need for a custom Lambda evaluator when using CodePipeline V2, filtering out documentation changes and targeting specific service directories natively.