Study guide
10.3 Continuous Delivery, Deployment Automation & GitOps
CompTIA Cloud+ Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Cloud Architecture Fundamentals
1.1 Cloud Service Models & Shared Responsibility 1.2 Cloud Deployment Models & Multi-Cloud Strategies 1.3 High Availability, Resiliency & Redundancy 1.4 Disaster Recovery & Business Continuity 1.5 Evolving Cloud Technologies: AI/ML Services, IoT & Edge Computing
2 Chapter 2: Cloud Compute & Storage Architecture
2.1 Virtualization & Hypervisor Architectures 2.2 Containerization & Microservices Architecture 2.3 Container Orchestration & Kubernetes Architecture 2.4 Cloud Storage Architectures & Performance
3 Chapter 3: Cloud Networking Architecture
3.1 Virtual Private Clouds & Subnetting Architecture 3.2 Hybrid & Multi-Cloud Connectivity 3.3 DNS, Load Balancing & Traffic Routing 3.4 Cloud Network Security Architecture
4 Chapter 4: Workload Assessment & Migration Planning
4.1 Cloud Migration Strategies (The 6/7 Rs) 4.2 Pre-Migration Workload Assessment & Sizing 4.3 Data & Database Migration Methods 4.4 Migration Execution, Cutover & Post-Migration Validation
5 Chapter 5: Infrastructure as Code & Provisioning
5.1 Infrastructure as Code Fundamentals & State Management 5.2 IaC Tooling & Template Authoring 5.3 Provisioning Automation & Image Management 5.4 Deployment Strategies & Release Patterns
6 Chapter 6: Cloud Operations & Lifecycle Management
6.1 Resource Lifecycle & Patch Management 6.2 Cloud Scaling Strategies & Elasticity 6.3 Cloud Cost Management & Optimization (FinOps) 6.4 Capacity Planning & Service Quotas
7 Chapter 7: Cloud Backup, Recovery & Business Continuity Operations
7.1 Backup Strategies, Storage Media & Retention Policies 7.2 Immutable Backups, Vault Locking & Ransomware Defense 7.3 Point-in-Time Recovery & Data Integrity Validation 7.4 High Availability Failover Drills & Chaos Engineering
8 Chapter 8: Cloud Security Controls & Identity and Access Management
8.1 Identity & Access Management, RBAC & ABAC 8.2 Identity Federation, SSO & Directory Integration 8.3 Multi-Factor Authentication, PAM & Machine Identities 8.4 Secrets Management & Cryptographic Credential Hygiene
9 Chapter 9: Data Protection, Vulnerability & Compliance
9.1 Data Encryption, Key Management & Confidential Computing 9.2 Vulnerability Management, Posture Assessment & CWPP 9.3 Container, Workload & Runtime Security 9.4 Cloud Compliance Frameworks & Governance Auditing
10 Chapter 10: DevOps Fundamentals & CI/CD Pipelines
10.1 Version Control Systems & Branching Strategies 10.2 Continuous Integration & Automated Testing Pipelines 10.3 Continuous Delivery, Deployment Automation & GitOps 10.4 Configuration Management & Systems Integration
11 Chapter 11: Cloud Observability & Monitoring
11.1 The Three Pillars of Observability: Metrics, Logs & Traces 11.2 Cloud Monitoring Architecture, Alerting & SLOs 11.3 Centralized Log Aggregation, SIEM & Log Analytics
12 Chapter 12: Troubleshooting Cloud Architecture & Deployments
12.1 Structured Cloud Troubleshooting Methodology 12.2 Troubleshooting Compute, Container & Storage Failures 12.3 Troubleshooting Provisioning, IaC & Automation Failures
13 Chapter 13: Troubleshooting Cloud Networking & Security
13.1 Troubleshooting Cloud Network Connectivity & Routing 13.2 Troubleshooting IAM, Permissions & Encryption 13.3 Troubleshooting Disaster Recovery & Performance Degradation
10.3 Continuous Delivery, Deployment Automation & GitOps
Key Takeaways Explain This Topic AI
Continuous Delivery automates software validation through staging environments up to an authorized manual approval gate for production, whereas Continuous Deployment completely automates the release all the way to production without human intervention.
Cloud deployment orchestration tools (AWS CodeDeploy, GitHub Actions, Azure Pipelines, GitLab CD) coordinate rollouts, infrastructure configuration, and lifecycle health checks.
GitOps establishes a declarative paradigm where Git is the single source of truth for desired infrastructure and application state, utilizing in-cluster controllers (ArgoCD, Flux) to continuously pull state and reconcile drift.
Pull-based GitOps architectures enhance cloud security by running agents inside the cluster network, eliminating the need to expose cluster administrative credentials to external CI/CD runner pipelines.
Progressive delivery strategies—including Feature Flags, Blue/Green deployments, and Canary analysis—minimize blast radius by combining gradual traffic shifting with automated metric health checks and instant rollback triggers.
Last updated: August 2026
Continuous Delivery, Deployment Automation & GitOps
Once software artifacts are built, verified, and published by Continuous Integration pipelines, release automation systems take over to deploy, configure, and monitor applications in runtime environments. In modern cloud engineering, release strategies have evolved from error-prone manual server deployments to fully automated Continuous Delivery (CD) , Continuous Deployment , and declarative GitOps architectures.
For the CompTIA Cloud+ (CV0-004) exam, candidates must master the distinction between Continuous Delivery and Continuous Deployment, understand cloud orchestration platforms, evaluate pull-based vs. push-based GitOps reconciliations, and implement Progressive Delivery techniques (Blue/Green, Canary, Feature Flags, and Automated Rollbacks).
1. Continuous Delivery vs. Continuous Deployment
While the acronym "CD" is often used generically, it refers to two distinct release automation models based on the presence or absence of a manual approval gate: +-----------------------------------------------------------------------------------------+
- | CONTINUOUS DELIVERY VS. CONTINUOUS DEPLOYMENT |
- | |
- | CONTINUOUS DELIVERY (Automated Staging with Manual Production Approval Gate) |
- | +-----------+ +------------+ +------------+ +==========+ +----------+ |
- | | Build App | --> | Auto Test | --> | Deploy to | --> | MANUAL | --> | Deploy to| |
- | | & Package | | & Validate | | Staging | | APPROVAL | | Prod | |
- | +-----------+ +------------+ +------------+ +==========+ +----------+ |
- | |
- | CONTINUOUS DEPLOYMENT (Fully Automated Direct to Production) |
- | +-----------+ +------------+ +------------+ +------------+ +----------+ |
- | | Build App | --> | Auto Test | --> | Deploy to | --> | Automated |-->| Deploy to| |
- | | & Package | | & Validate | | Staging | | Metric Gate| | Prod | |
- | +-----------+ +------------+ +------------+ +------------+ +----------+ |
- | (No Manual Gate) |
- +-----------------------------------------------------------------------------------------+
- Detailed Comparison
Dimension Continuous Delivery Continuous Deployment
Production Release Trigger Manual human approval (Release Manager, Product Owner) Fully automated immediately upon passing CI gates
Governance & Compliance Ideal for heavily regulated industries (SOX, HIPAA, PCI DSS, Banking) Ideal for cloud-native SaaS platforms, microservices, and DORA elite teams
Deployment Frequency Scheduled releases (daily, weekly, on-demand) Continuous (dozens or hundreds of releases per day)
Blast Radius Mitigation Human verification of staging readiness prior to release Progressive delivery (Canary / Feature Flags) and automated rollbacks
2. Cloud Deployment Automation Platforms
Enterprise cloud deployments utilize specialized deployment automation services across major cloud platforms: +-----------------------------------------------------------------------------------------+
- | CLOUD DEPLOYMENT PLATFORMS TAXONOMY |
- | |
- | Platform Architecture Model Primary Cloud Ecosystem |
- | +--------------------+--------------------------+-----------------------------------+ |
- | | AWS CodePipeline / | Native Cloud Managed | AWS (EC2, ECS, Lambda, EKS) | |
- | | AWS CodeDeploy | Orchestrator | | |
- | | | | | |
- | | Azure Pipelines | Multi-Stage YAML Cloud | Microsoft Azure, Hybrid, Multi-Cl | |
- | | | CD with Release Gates | | |
- | | | | | |
- | | GitLab CD / | Integrated Git + Matrix | Multi-Cloud, Kubernetes, IaaS | |
- | | GitHub Actions CD | Environments & Secrets | | |
- | | | | | |
- | | Jenkins | Self-Hosted Controller + | On-Premises, Legacy Hybrid | |
- | | | Distributed Build Agents | | |
- | +--------------------+--------------------------+-----------------------------------+ |
- +-----------------------------------------------------------------------------------------+
- Deployment Lifecycle Hooks (e.g., AWS CodeDeploy appspec.yml )
Deployment engines execute scripts at precise lifecycle phases to guarantee zero-downtime updates and automated health checks: version: 0.0
os: linux
files:
- source: /
- destination: /var/www/production-app
hooks:
BeforeInstall:
- location: scripts/deregister_from_load_balancer.sh
- timeout: 300
- runas: root
AfterInstall:
- location: scripts/install_dependencies.sh
- timeout: 300
- runas: root
ApplicationStart:
- location: scripts/start_application_service.sh
- timeout: 120
- runas: root
ValidateService:
- location: scripts/verify_healthcheck_endpoint.sh
- timeout: 60
- runas: root
- 3. GitOps Methodology: Declarative Infrastructure & Controllers
GitOps is an operational framework that applies DevOps best practices—such as version control, collaboration, compliance, and CI/CD—to infrastructure automation and Kubernetes application delivery. In GitOps, Git is the single source of truth for the entire system's desired state. +-----------------------------------------------------------------------------------------+
- | PUSH-BASED CD VS. PULL-BASED GITOPS |
- | |
- | PUSH-BASED CD (Traditional Pipeline) |
- | +-----------+ +---------------+ Cluster Credentials +-------------------+ |
- | | Git Repo | -------> | CI/CD Runner | ---------------------> | Kubernetes Cluster| |
- | +-----------+ | (External) | (kubectl apply) | (Inbound API Open)| |
- | +---------------+ +-------------------+ |
- | - Security Risk: External runner stores privileged cluster administrative credentials |
- | - Network Risk: Kubernetes API server must allow inbound traffic from CI runners |
- | |
- | PULL-BASED GITOPS (ArgoCD / Flux) |
- | +-----------+ +-------------------+ |
- | | Git Repo | <---------------- Pull Desired State ----------- | GitOps Controller | |
- | | (Desired | (Outbound HTTPS / Read-Only) | (ArgoCD / Flux) | |
- | | State) | | Inside Cluster | |
- | +-----------+ +---------+---------+ |
- | | |
- | Reconcile | (Apply) |
- | v |
- | [ Live Cluster State] |
- | - Zero Inbound Exposure: In-cluster operator pulls state; cluster API is private |
- | - Continuous Drift Detection & Automated Self-Healing |
- +-----------------------------------------------------------------------------------------+
- The Four Principles of OpenGitOps
Declarative Descriptions: The entire target system (infrastructure, networking, container workloads) must be described declaratively (e.g., Kubernetes YAML manifests, Helm charts, Kustomize overlays).
Versioned and Immutable Storage: The canonical desired state is stored in Git, providing complete version history, change tracking, and cryptographic auditability.
Pulled Automatically by In-Cluster Agents: Software agents running inside the target runtime continuously pull the desired state from Git.
Continuously Reconciled with Drift Detection: The GitOps controller compares the Live State against the Desired State . If an unauthorized operator manually modifies a resource via kubectl edit , the controller detects the drift and automatically self-heals the cluster back to the version declared in Git.
Leading GitOps Controllers
ArgoCD: A declarative, GitOps continuous delivery tool for Kubernetes providing an intuitive web UI, visual application dependency trees, automated rollbacks, and multi-cluster management.
Flux (FluxCD): A modular set of Kubernetes controllers (Source Controller, Kustomize Controller, Helm Controller, Notification Controller) natively integrated with the Kubernetes API.
4. Progressive Delivery: Blue/Green, Canary & Feature Flags
Progressive Delivery builds upon Continuous Delivery by combining advanced deployment strategies with fine-grained traffic routing and automated telemetry verification to minimize the blast radius of releases. +-----------------------------------------------------------------------------------------+
- | PROGRESSIVE DELIVERY STRATEGIES TAXONOMY |
- | |
- | Strategy Architecture & Traffic Flow Cost & Rollback Profile |
- | +--------------+-----------------------------------------+--------------------------+ |
- | | In-Place / | Replaces instances one-by-one in the | Lowest cost (1x infra); | |
- | | Rolling | existing pool. Mixed versions active. | Slow rollback (must | |
- | | | | re-roll previous image) | |
- | | | | | |
- | | Blue/Green | Two identical production environments. | High cost (2x infra); | |
- | | | Router flips 100% traffic from Blue | Instantaneous rollback | |
- | | | (v1) to Green (v2) simultaneously. | (flip router back) | |
- | | | | | |
- | | Canary | Routes small traffic percentage (5-10%) | Low cost (+10% infra); | |
- | | Deployment | to Canary (v2); expands gradually based | Low blast radius; | |
- | | | on real-time metric analysis. | automated rollback | |
- | +--------------+-----------------------------------------+--------------------------+ |
- +-----------------------------------------------------------------------------------------+
- Feature Flags (Feature Toggles)
Feature flagging platforms (e.g., LaunchDarkly , Unleash , AWS AppConfig ) separate software deployment from feature release:
Runtime Decoupling: Code is deployed to production in a dormant state. Product managers toggle features on for specific target audiences (e.g., 5% of beta users in a specific region) via cloud APIs without redeploying containers or modifying infrastructure.
Instant Kill Switches: If a newly activated feature causes backend database locks or unexpected errors, operators flip the flag to false in real time, instantly mitigating customer impact without initiating emergency code rollbacks.
Automated Canary Analysis & Rollback Architecture
Canary deployments integrate directly with monitoring and telemetry platforms ( Prometheus , Datadog , AWS CloudWatch ) to evaluate Service Level Indicators (SLIs): +-----------------------------------------------------------------------------------------+
- | AUTOMATED CANARY METRIC RECONCILIATION |
- | |
- | Step 1: Shift 5% Traffic to Canary Pods (v2.0) --------------------------------+ |
- | Step 2: Monitor Real-Time Metrics for 10 Minutes: | |
- | - SLI Check 1: HTTP 5xx Error Rate < 0.2% | |
- | - SLI Check 2: p99 Latency < 250ms | |
- | - SLI Check 3: Host CPU Saturation < 75% | |
- | | |
- | +--------------------------------------------------------------------------+ | |
- | | IF ALL SLIs HEALTHY: | | |
- | | Promote to 25% -> 50% -> 100% traffic. Terminate Baseline (v1.0). | | |
- | +--------------------------------------------------------------------------+ | |
- | | IF ANY SLI FAILS (e.g., 5xx Error Rate Spikes to 1.8%): | | |
- | | AUTOMATED ROLLBACK: Shift 100% traffic back to Baseline (v1.0) instantly! | | |
- | | Scale Canary to 0 pods; Send high-priority alert to PagerDuty / Slack. | | |
- | +--------------------------------------------------------------------------+ | |
- +-----------------------------------------------------------------------------------------+
- 5. CompTIA Cloud+ Exam Traps & Real-World Gotchas
Continuous Delivery vs. Continuous Deployment Distinction: A frequent CompTIA Cloud+ exam question presents a scenario where an enterprise automates all testing through staging, but requires a formal change advisory board (CAB) or manager sign-off before promoting code to production. This is Continuous Delivery . If the release proceeds automatically without human intervention, it is Continuous Deployment .
GitOps Security Posture: In traditional CI/CD, the external runner must hold high-privilege administrative credentials (such as Kubernetes cluster-admin tokens) to execute kubectl commands against the cloud cluster. In pull-based GitOps, no external credentials exist ; the controller lives inside the cluster and only requires outbound read-only access to Git.
Database Schema Migrations in Blue/Green Deployments: When executing a Blue/Green traffic switch, the database is typically shared between the Blue and Green environments. Breaking schema changes (e.g., renaming a database column) will crash the live Blue environment before the Green switch occurs. Database migrations must follow the Expand/Contract (Parallel Run) Pattern , ensuring backward compatibility across both versions.