Cloud CI/CD Pipeline Lab

A modern cloud deployment should not depend on an engineer manually building, testing, and deploying every change.

Welcome to Lab 24 of the CompTIA Cloud+ practical lab sequence.

In the previous labs, you progressed from:

Manual Cloud Operations
        ↓
Automation & Scripting
        ↓
Infrastructure as Code

You can now automate operational tasks and define cloud infrastructure through code.

The next challenge is delivering changes safely and consistently.

A traditional workflow might look like:

Developer
    ↓
Writes Code
    ↓
Manually Builds
    ↓
Manually Tests
    ↓
Uploads Files
    ↓
Manually Deploys
    ↓
Production

This creates opportunities for:

Human Error

Inconsistent Builds

Skipped Testing

Configuration Differences

Deployment Failures

Slow Releases

CI/CD introduces a controlled pipeline:

Code
  ↓
Version Control
  ↓
Build
  ↓
Test
  ↓
Security Validation
  ↓
Artifact
  ↓
Deployment
  ↓
Verification
  ↓
Monitoring

In this lab, you will design and build a practical cloud CI/CD workflow.

🎯 Mission Information

Item	Details
Lab	24 — Cloud CI/CD Pipeline Lab
Difficulty	Intermediate
Estimated Time	150–210 Minutes
Certification Alignment	CompTIA Cloud+
Primary Focus	CI/CD and Cloud Deployment Automation
Previous Lab	23 — Infrastructure as Code (IaC) Lab
Career Alignment	Cloud Engineer, DevOps Engineer, Cloud Administrator, Platform Engineer
Major Skills	CI/CD, Git, Build, Testing, Artifacts, Deployment, Security, Rollback
Deliverable	CI/CD Pipeline + Deployment Strategy + Pipeline Runbook

🏢 Scenario

Your organization operates a cloud-hosted application.

Developers currently deploy updates manually.

Developer Laptop
       ↓
Application Code
       ↓
Manual Build
       ↓
Manual Testing
       ↓
Manual Upload
       ↓
Cloud Server

Recently, several problems occurred:

Developer A
    ↓
Forgot Testing
    ↓
Production Failure

Another deployment:

Developer B
    ↓
Built Different Version
    ↓
Configuration Problem

Another:

Developer C
    ↓
Deployed Directly
    ↓
No Approval

Management wants a standardized process:

Developer
    ↓
Git Repository
    ↓
CI Pipeline
    ↓
Automated Testing
    ↓
Security Checks
    ↓
Approved Artifact
    ↓
CD Pipeline
    ↓
Production

Your mission is to design and implement this workflow.

🎯 Lab Objectives

By completing this lab, you should be able to:

explain CI/CD
distinguish CI from CD
understand source control workflows
understand pipeline triggers
understand pipeline stages
understand build processes
automate testing
understand artifacts
understand artifact repositories
integrate security validation
manage pipeline secrets
understand service identities
implement least privilege
understand environment promotion
understand deployment approvals
compare deployment strategies
understand rolling deployments
understand blue-green deployments
understand canary deployments
understand rollback
understand Infrastructure as Code integration
monitor pipeline executions
troubleshoot pipeline failures
build a CI/CD operational runbook

01 — Understand CI/CD

CI/CD commonly refers to:

Continuous Integration

+

Continuous Delivery / Deployment

The objective is to create a repeatable software delivery workflow.

Developer Change
      ↓
Automated Pipeline
      ↓
Validated Release

02 — Understand Continuous Integration

Continuous Integration focuses on frequently integrating code changes into a shared repository.

A typical workflow:

Developer
    ↓
Code Change
    ↓
Commit
    ↓
Repository
    ↓
Automated Build
    ↓
Automated Tests

CI helps identify problems earlier.

03 — Understand Continuous Delivery

Continuous Delivery means changes are kept in a deployable state.

Code
  ↓
Build
  ↓
Test
  ↓
Package
  ↓
Ready for Deployment
  ↓
Approval
  ↓
Production

Production deployment may still require manual approval.

04 — Understand Continuous Deployment

Continuous Deployment goes further.

Code
  ↓
Build
  ↓
Test
  ↓
Validation
  ↓
Automatic Production Deployment

If all required checks pass, the change may be deployed automatically.

05 — CI vs Continuous Delivery vs Continuous Deployment

Model	Primary Purpose
Continuous Integration	Integrate and validate changes
Continuous Delivery	Keep releases deployable
Continuous Deployment	Automatically deploy validated changes

Remember:

CI
=
Integrate + Validate

CD
=
Deliver / Deploy

06 — Understand the Complete Pipeline

A mature pipeline may contain:

SOURCE
   ↓
BUILD
   ↓
TEST
   ↓
SECURITY
   ↓
PACKAGE
   ↓
ARTIFACT
   ↓
DEPLOY
   ↓
VERIFY
   ↓
MONITOR

07 — Understand Source Control

The pipeline begins with:

Source Code Repository

Version control provides:

history
collaboration
traceability
branching
rollback capability
code review

08 — Create the Lab Repository

Create:

cloudplus-cicd-lab/

Example:

mkdir cloudplus-cicd-lab
cd cloudplus-cicd-lab

git init

Check:

git status

09 — Create a Simple Application

Create:

app/

Example structure:

cloudplus-cicd-lab/
│
├── app/
│   └── app.py
│
├── tests/
│
├── infrastructure/
│
├── pipeline/
│
├── README.md
│
└── .gitignore

10 — Create a Simple Python Application

Create:

def cloud_status():
    return "Cloud application healthy"


if __name__ == "__main__":
    print(cloud_status())

Run:

python app/app.py

Expected:

Cloud application healthy

11 — Understand the Build Stage

The build stage transforms source code into something deployable.

Depending on the application, this might include:

Compile

Install Dependencies

Package

Create Container Image

Generate Deployment Package

12 — Build Stage Architecture

Source Code
    ↓
Build Environment
    ↓
Dependencies
    ↓
Build
    ↓
Deployable Output

13 — Understand Reproducible Builds

A good pipeline should produce predictable results.

Avoid:

Developer Laptop A
      ↓
Build Works

Developer Laptop B
      ↓
Different Dependencies
      ↓
Build Fails

Prefer:

Controlled Build Environment
         ↓
Defined Dependencies
         ↓
Repeatable Build

14 — Define Dependencies

For Python, you might use:

requirements.txt

Other ecosystems may use their own dependency-management files.

The principle is:

Dependencies should be defined rather than remembered manually.

15 — Understand Automated Testing

After building:

Build
   ↓
Automated Tests

Tests may include:

Unit Tests

Integration Tests

Functional Tests

Security Tests

Infrastructure Tests

16 — Create a Basic Test

Create:

from app.app import cloud_status


def test_cloud_status():
    assert cloud_status() == "Cloud application healthy"

17 — Run the Test

If using pytest:

pytest

Expected:

PASS

The pipeline should stop when critical tests fail.

18 — Understand Pipeline Gates

A gate controls whether the pipeline can proceed.

Build
  ↓
Test
  ↓
PASS?
 /   \
YES   NO
 ↓     ↓
Next  Stop
Stage

19 — Why Pipeline Gates Matter

Without gates:

Failed Test
     ↓
Ignore
     ↓
Production

With gates:

Failed Test
     ↓
Pipeline Stops
     ↓
Engineer Investigates

20 — Understand Pipeline Triggers

A pipeline can begin because of:

Commit

Pull Request

Merge

Schedule

Manual Trigger

Release Tag

21 — Commit-Based Trigger

Example:

Developer
    ↓
git push
    ↓
Repository
    ↓
Pipeline Trigger

22 — Pull Request Workflow

A safer workflow:

Developer Branch
       ↓
Pull Request
       ↓
Build
       ↓
Tests
       ↓
Security Checks
       ↓
Review
       ↓
Merge

23 — Understand Branching

Example:

main
 |
 +---- feature-login
 |
 +---- feature-monitoring
 |
 +---- bugfix-network

Developers work independently and merge reviewed changes.

24 — Protect Important Branches

Production-related branches may require:

Pull Request

Review

Passing Tests

Security Checks

Approval

Avoid:

Developer
    ↓
Direct Push
    ↓
Production

where stronger controls are required.

25 — Understand Pipeline Configuration

Many CI/CD systems define pipelines as code.

Conceptually:

stages:
  - build
  - test
  - security
  - deploy

Exact syntax depends on the platform.

26 — Why Pipeline as Code Matters

Pipeline definitions can be:

Version Controlled

Reviewed

Repeated

Audited

Tested

27 — Build the CI Pipeline

Your initial pipeline should follow:

SOURCE
   ↓
BUILD
   ↓
TEST

Document each stage.

28 — Build Stage

Example concept:

build:
  steps:
    - install dependencies
    - validate application
    - package application

29 — Test Stage

Conceptually:

test:
  steps:
    - run unit tests
    - generate test results

30 — Introduce a Test Failure

Temporarily modify your test:

assert cloud_status() == "Wrong result"

Run the test.

Expected:

FAIL

31 — Observe Pipeline Behavior

The correct behavior is:

Build
   ↓
Test
   ↓
FAIL
   ↓
Pipeline Stops

Restore the correct test afterward.

32 — Understand Build Artifacts

An artifact is an output produced by the pipeline.

Examples:

Application Package

Binary

Container Image

ZIP Archive

Deployment Template

33 — Artifact Workflow

Source
   ↓
Build
   ↓
Artifact
   ↓
Repository
   ↓
Deployment

34 — Why Artifacts Matter

You should ideally deploy:

Same Tested Artifact

rather than rebuilding differently for every environment.

35 — Understand Artifact Repositories

Organizations may store artifacts in:

Package Repository

Container Registry

Object Storage

Artifact Management Platform

36 — Understand Artifact Versioning

Avoid:

application-latest

as the only identifier.

Prefer traceable versions such as:

application-1.0.1

application-1.0.2

application-1.0.3

37 — Connect Artifact to Source

A release should ideally be traceable:

Artifact
   ↓
Pipeline Run
   ↓
Commit
   ↓
Developer Change

38 — Understand Security in CI/CD

A pipeline can become a powerful attack path.

Developer
   ↓
Repository
   ↓
Pipeline
   ↓
Cloud Credentials
   ↓
Production

Therefore pipeline security is critical.

39 — Add Security Validation

A pipeline may perform:

Source Code Scan

Dependency Scan

Secret Scan

IaC Scan

Container Scan

Policy Validation

40 — Build the Secure Pipeline

SOURCE
   ↓
BUILD
   ↓
TEST
   ↓
SECURITY SCAN
   ↓
PACKAGE
   ↓
DEPLOY

41 — Understand Static Analysis

Static analysis evaluates code without executing the complete application.

It may identify:

Unsafe Code Patterns

Potential Vulnerabilities

Coding Issues

42 — Understand Dependency Scanning

Applications depend on third-party packages.

Application
   ↓
Dependency A
   ↓
Dependency B

A vulnerable dependency can introduce risk.

43 — Understand Secret Scanning

Repositories should be checked for:

Passwords

API Keys

Access Tokens

Private Keys

Credentials

44 — Never Store Pipeline Secrets in Code

Poor:

password: MySecretPassword

Better:

Pipeline
   ↓
Secret Store
   ↓
Runtime Credential

45 — Understand Pipeline Secrets

Examples include:

Cloud Credentials

API Tokens

Registry Credentials

Signing Keys

Database Credentials

They require controlled storage and access.

46 — Prefer Short-Lived Credentials

Where supported:

Pipeline
   ↓
Federated / Managed Identity
   ↓
Temporary Credential
   ↓
Cloud API

is generally preferable to long-lived static credentials.

47 — Apply Least Privilege

If the pipeline only deploys:

Web Application

it should not automatically have permission to:

Delete Databases

Modify IAM Administrators

Change Billing

Delete Entire Networks

48 — Separate Pipeline Identities

Consider:

Development Pipeline Identity

Testing Pipeline Identity

Production Pipeline Identity

with appropriate permissions.

49 — Understand Supply Chain Security

CI/CD is part of the software supply chain.

Potential targets include:

Source Repository

Dependencies

Build System

Pipeline

Artifacts

Container Registry

Deployment Credentials

50 — Protect the Source Repository

Apply controls such as:

MFA

Least Privilege

Branch Protection

Code Review

Audit Logging

51 — Protect Pipeline Configuration

An attacker who modifies:

Pipeline Definition

may potentially change:

Build Behavior

Security Checks

Deployment Destination

Credential Usage

Therefore pipeline code should be reviewed.

52 — Protect Build Environments

Build environments may process:

Source Code

Dependencies

Credentials

Artifacts

Use trusted and controlled environments.

53 — Protect Artifacts

Artifacts should maintain:

Integrity

Traceability

Controlled Access

54 — Understand Artifact Integrity

Conceptually:

Source
   ↓
Build
   ↓
Artifact
   ↓
Integrity Verification
   ↓
Deployment

Checksums or signatures may be used depending on the environment.

55 — Understand Environment Promotion

A release may move through:

Development
      ↓
Testing
      ↓
Staging
      ↓
Production

56 — Why Promote the Same Artifact?

Poor:

Dev
 ↓
Build A

Test
 ↓
Build B

Production
 ↓
Build C

Better:

Build Once
    ↓
Artifact
    ↓
Dev
    ↓
Test
    ↓
Staging
    ↓
Production

57 — Environment-Specific Configuration

The application artifact may remain the same while configuration differs.

Examples:

Database Endpoint

Environment Name

Scaling Settings

Feature Configuration

58 — Keep Secrets Out of Artifacts

Do not package:

Production Password

Private Key

API Secret

inside the application artifact.

59 — Understand Deployment Approvals

Production deployment may require:

Automated Checks
      ↓
Human Approval
      ↓
Deployment

This is common when changes have significant business impact.

60 — Build an Approval Gate

Staging
   ↓
Validation
   ↓
PASS
   ↓
Approval
   ↓
Production

61 — Understand Separation of Duties

Example:

Developer
   ↓
Writes Code

Reviewer
   ↓
Approves Change

Operations
   ↓
Approves Production Deployment

62 — Understand Deployment Strategies

Major strategies include:

Recreate

Rolling

Blue-Green

Canary

63 — Recreate Deployment

Version 1
   ↓
STOP
   ↓
Version 2
   ↓
START

Simple, but it may create downtime.

64 — Rolling Deployment

V1   V1   V1   V1

↓ Replace Gradually ↓

V2   V1   V1   V1

V2   V2   V1   V1

V2   V2   V2   V1

V2   V2   V2   V2

Benefits may include reduced downtime.

65 — Rolling Deployment Risk

During deployment:

Version 1
+
Version 2

may operate simultaneously.

The application must support this where required.

66 — Blue-Green Deployment

Maintain two environments:

BLUE
Version 1
Production Traffic

GREEN
Version 2
New Release

After validation:

Traffic
   ↓
GREEN

67 — Blue-Green Architecture

                 Users
                   |
                   v
             Load Balancer
                   |
             Traffic Switch
              /          \
             v            v
          BLUE          GREEN
           V1             V2

68 — Blue-Green Advantage

Rollback may be faster:

GREEN Fails
    ↓
Traffic
    ↓
BLUE

provided the previous environment remains compatible and available.

69 — Canary Deployment

Deploy the new version to a small percentage of users.

Users
  |
  +---- 95% → Version 1
  |
  +---- 5%  → Version 2

Observe the new version before increasing traffic.

70 — Canary Progression

5%
 ↓
10%
 ↓
25%
 ↓
50%
 ↓
100%

only if validation remains successful.

71 — Monitor Canary Health

Track:

Error Rate

Latency

Availability

Application Logs

Resource Usage

Business Metrics

72 — Compare Deployment Strategies

Strategy	Downtime	Rollback	Complexity
Recreate	Possible	Moderate	Low
Rolling	Low	Moderate	Medium
Blue-Green	Low	Fast	Higher
Canary	Low	Controlled	Higher

73 — Understand Rollback

A pipeline needs a defined response to failed deployment.

Deploy V2
   ↓
Validation
   ↓
FAIL
   ↓
Rollback
   ↓
V1

74 — Define Rollback Conditions

Examples:

Health Check Failure

Error Rate Increase

Application Unavailable

Critical Test Failure

Performance Degradation

75 — Rollback Is More Than Application Code

Consider:

Application

Infrastructure

Database Schema

Configuration

Data

A previous application version may not work with a new database schema.

76 — Understand Forward Fix

Sometimes rollback is unsafe or impossible.

Another option:

Failure
   ↓
Fix
   ↓
New Version
   ↓
Deploy

This is a:

Forward fix.

77 — Build the Deployment Decision

Deployment Failure
       ↓
Can Safely Roll Back?
      /            \
    YES             NO
     ↓               ↓
Rollback         Forward Fix

78 — Understand Database Changes

Database changes require special care.

Application V1
      ↓
Database Schema V1

New deployment:

Application V2
      ↓
Database Schema V2

Rollback could fail if schema changes are incompatible.

79 — Use Backward-Compatible Changes

Where possible, design changes that allow:

V1
+
V2

to work during transition.

This is especially useful for rolling and canary deployments.

80 — Integrate Infrastructure as Code

From Lab 23:

Infrastructure Code
      ↓
Validation
      ↓
Plan
      ↓
Deployment

This can become part of the pipeline.

81 — IaC CI/CD Workflow

Git Commit
    ↓
IaC Validation
    ↓
Security Scan
    ↓
Plan
    ↓
Review
    ↓
Approval
    ↓
Apply

82 — Separate Application and Infrastructure Changes

Your repository might contain:

cloudplus-cicd-lab/
│
├── app/
├── tests/
├── infrastructure/
├── pipeline/
└── README.md

83 — Validate IaC Automatically

Pipeline stage:

Infrastructure
      ↓
Format Check
      ↓
Validate
      ↓
Security Scan
      ↓
Plan

84 — Do Not Automatically Apply Destructive IaC Changes

If the plan contains:

DELETE DATABASE

the pipeline should not blindly proceed.

Require appropriate review.

85 — Understand Pipeline Variables

Pipeline variables may contain:

Environment Name

Region

Artifact Version

Deployment Target

86 — Separate Variables from Secrets

VARIABLE

REGION=region-a

versus:

SECRET

DATABASE_PASSWORD=*****

Secrets require stronger controls.

87 — Understand Environment Variables

Applications may receive runtime configuration through environment variables.

Example:

APP_ENV=production

LOG_LEVEL=info

Avoid exposing sensitive values through logs.

88 — Understand Pipeline Logging

Pipeline logs help answer:

What Ran?

When?

Who Triggered It?

Which Commit?

Which Tests Passed?

Which Stage Failed?

What Was Deployed?

89 — Do Not Log Secrets

Poor:

Connecting with password:
SuperSecret123

Logs may be retained and accessible to many users.

90 — Monitor Pipeline Health

Useful metrics include:

Pipeline Success Rate

Failure Rate

Build Duration

Test Duration

Deployment Frequency

Deployment Failures

91 — Monitor Deployment Health

After deployment:

Pipeline
   ↓
Production
   ↓
Monitoring

Check:

Availability

Latency

Error Rate

Resource Utilization

Logs

Health Checks

92 — Build Post-Deployment Validation

Deploy
   ↓
Health Check
   ↓
Application Test
   ↓
Metrics Review
   ↓
PASS?
 /   \
YES   NO
 ↓     ↓
Done  Rollback / Investigate

93 — Create a Smoke Test

A smoke test quickly validates critical functionality.

Examples:

Application Responds

Login Endpoint Works

Database Connection Works

Health Endpoint Returns Success

94 — Understand Deployment Verification

Never assume:

Pipeline Green
=
Application Healthy

The pipeline must validate the deployed workload.

95 — Build the Full Pipeline

                    Developer
                        |
                        v
                  Git Repository
                        |
                        v
                   Pull Request
                        |
              +---------+---------+
              |                   |
              v                   v
            Build               Review
              |
              v
             Test
              |
              v
        Security Scan
              |
              v
           Artifact
              |
              v
         Development
              |
              v
            Testing
              |
              v
            Staging
              |
              v
           Approval
              |
              v
          Production
              |
              v
           Validate
              |
              v
           Monitor

96 — Introduce a Build Failure

Create an intentional syntax error in the disposable lab application.

Expected:

Build
  ↓
FAIL
  ↓
Pipeline Stops

Restore the application afterward.

97 — Introduce a Test Failure

Modify a test so it fails.

Expected:

Build
  ↓
PASS
  ↓
Test
  ↓
FAIL
  ↓
Deployment Blocked

98 — Introduce a Security Failure

In a disposable local exercise, create an obvious placeholder pattern for your security-checking process.

For example:

EXAMPLE_SECRET_DO_NOT_USE

Verify that your security stage identifies the test condition if configured to do so.

Remove the test value afterward.

99 — Test Deployment Failure

Simulate:

Deployment
   ↓
Application Health Check
   ↓
FAIL

Document what should happen next.

100 — Test Rollback

Verify:

Failed Release
      ↓
Previous Known-Good Version
      ↓
Application Healthy

Do this only in a disposable lab environment.

101 — Test Approval Controls

Attempt:

Staging
   ↓
Production

without required approval.

Expected:

BLOCKED

102 — Test Unauthorized Pipeline Access

Verify that an unauthorized account cannot:

Modify Pipeline

Approve Production

Access Secrets

Deploy Production

103 — Test Secret Protection

Check:

Repository

Pipeline Configuration

Logs

Artifacts

Ensure sensitive values are not exposed.

104 — Test Artifact Traceability

Select a deployed artifact.

Determine:

Artifact Version

Commit

Pipeline Run

Build Time

Deployment Environment

105 — Test Environment Promotion

Verify that:

Same Artifact

moves through:

Development
      ↓
Testing
      ↓
Staging
      ↓
Production

106 — Test Monitoring

After deployment, intentionally create a safe application error in the disposable environment.

Verify:

Error
   ↓
Logs
   ↓
Monitoring
   ↓
Alert / Detection

107 — Troubleshooting — Pipeline Does Not Start

Check:

Trigger

Branch

Pipeline Configuration

Repository Permissions

Pipeline Service

108 — Troubleshooting — Build Fails

Check:

Dependencies

Runtime Version

Build Commands

Configuration

Build Logs

109 — Troubleshooting — Tests Pass Locally but Fail in CI

Investigate:

Environment Differences

Dependency Versions

Environment Variables

Operating System

External Dependencies

Test Data

110 — Troubleshooting — Pipeline Cannot Access Cloud

Check:

Pipeline Identity

Authentication

Authorization

Network Connectivity

Cloud Account

Token Expiration

111 — Troubleshooting — Deployment Permission Denied

Think:

Authentication
   ↓
Successful

Authorization
   ↓
Insufficient

Review the deployment identity’s permissions.

112 — Troubleshooting — Artifact Missing

Check:

Build Stage

Artifact Path

Upload Step

Artifact Repository

Version

113 — Troubleshooting — Wrong Version Deployed

Investigate:

Artifact Tag

Pipeline Variables

Deployment Configuration

Repository Commit

Environment Promotion

114 — Troubleshooting — Secret Appears in Logs

Treat this as possible credential exposure.

Stop Exposure
     ↓
Protect Logs
     ↓
Rotate Credential
     ↓
Investigate Access
     ↓
Correct Pipeline

Follow organizational security procedures.

115 — Troubleshooting — Production Deployment Fails

Review:

Pipeline Logs

Application Logs

Infrastructure Logs

Health Checks

Monitoring

Recent Changes

Then determine:

Rollback

or:

Forward Fix

116 — Troubleshooting — Rollback Fails

Investigate:

Database Compatibility

Configuration Changes

Infrastructure Changes

Missing Previous Artifact

Dependencies

117 — Troubleshooting — Pipeline Suddenly Becomes Slow

Review:

Build Duration

Dependency Downloads

Test Duration

Runner Capacity

Network Performance

External Services

118 — Troubleshooting — Security Scan Produces Findings

Do not automatically ignore them.

Determine:

Finding
   ↓
Severity
   ↓
Validity
   ↓
Risk
   ↓
Remediation / Exception

119 — Build Pipeline Governance

Define:

Pipeline Owner

Repository Owner

Production Approver

Security Reviewer

Artifact Retention

Secret Management

Change Control

120 — Define Pipeline Access

Apply:

Least Privilege

Role-Based Access

MFA

Separation of Duties

121 — Define Production Controls

Example:

[ ] Protected production branch
[ ] Required code review
[ ] Automated tests required
[ ] Security checks required
[ ] Deployment approval required
[ ] Dedicated production identity
[ ] Rollback available
[ ] Deployment monitoring enabled

122 — Define Artifact Controls

Verify:

[ ] Artifact versioned
[ ] Artifact traceable to commit
[ ] Access restricted
[ ] Integrity protected
[ ] Retention defined
[ ] Production artifact identifiable

123 — Define Secret Controls

Verify:

[ ] Secrets not stored in repository
[ ] Secrets not embedded in artifacts
[ ] Secrets masked in logs
[ ] Access restricted
[ ] Rotation process defined
[ ] Short-lived credentials preferred

124 — Define Pipeline Security Controls

Verify:

[ ] Repository protected
[ ] Pipeline code reviewed
[ ] Dependencies scanned
[ ] Secrets scanned
[ ] IaC scanned
[ ] Build environment protected
[ ] Artifacts protected
[ ] Deployment identity restricted
[ ] Production approvals enabled
[ ] Audit logs retained

125 — Define Pipeline Reliability Controls

Verify:

[ ] Build repeatable
[ ] Tests automated
[ ] Failed tests block deployment
[ ] Deployment validated
[ ] Rollback tested
[ ] Pipeline failures alerted
[ ] Artifacts versioned
[ ] Deployment state observable

126 — Build the CI/CD Findings Register

Finding	Risk	Recommendation	Priority
Manual Deployment	Human Error	Implement CI/CD	High
No Automated Tests	Defects Reach Production	Add Test Stage	High
Secrets in Repository	Credential Exposure	Use Secret Management	Critical
Pipeline Uses Admin Rights	Excessive Privilege	Apply Least Privilege	Critical
Direct Production Push	Unreviewed Changes	Protect Branch	High
No Security Scanning	Vulnerability Risk	Add Security Gates	High
Artifact Not Versioned	Poor Traceability	Version Artifacts	Medium
No Approval Gate	Unauthorized Deployment	Add Production Approval	High
No Rollback	Extended Outage	Define Rollback	High
No Deployment Monitoring	Delayed Detection	Add Post-Deployment Monitoring	High

127 — Build the CI/CD Runbook

Use:

Runbook:
Cloud CI/CD Pipeline

Application:

Repository:

Pipeline Platform:

Pipeline Owner:

Cloud Environment:

Source Branch:

Trigger:

Build Stage:

Test Stage:

Security Stage:

Artifact:

Artifact Repository:

Development Deployment:

Testing Deployment:

Staging Deployment:

Production Approval:

Production Deployment:

Deployment Strategy:

Deployment Identity:

Required Permissions:

Secrets:

Post-Deployment Validation:

Monitoring:

Rollback:

Failure Handling:

Escalation:

Audit Logging:

128 — Create the Final Lab Report

Use:

Lab:
Cloud CI/CD Pipeline Lab

Application:

Repository:

Pipeline Platform:

Cloud Platform:

Build Environment:

Pipeline Trigger:

Build Result:

Automated Tests:

Security Checks:

Artifact:

Artifact Version:

Artifact Repository:

Development Deployment:

Testing Deployment:

Staging Deployment:

Production Deployment:

Deployment Strategy:

Approval Controls:

Pipeline Identity:

Permissions:

Secret Management:

IaC Integration:

Post-Deployment Validation:

Monitoring:

Rollback Test:

Failure Tests:

Findings:

Recommendations:

Lessons Learned:

🧪 Final Validation Checklist

Validation	Status
CI/CD understood
Continuous Integration understood
Continuous Delivery understood
Continuous Deployment understood
Repository created
Application created
Source control configured
Build stage understood
Automated test created
Test failure validated
Pipeline triggers understood
Pull request workflow understood
Branch protection understood
Pipeline as Code understood
Artifact created
Artifact versioning understood
Artifact traceability understood
Security validation understood
Dependency scanning understood
Secret scanning understood
Pipeline secrets protected
Least privilege reviewed
Pipeline identities understood
Supply chain security understood
Environment promotion understood
Approval gate understood
Deployment strategies compared
Rolling deployment understood
Blue-green deployment understood
Canary deployment understood
Rollback understood
Database rollback considerations understood
IaC integrated into pipeline
Pipeline logging understood
Pipeline monitoring understood
Post-deployment validation understood
Failure scenarios tested
Pipeline governance reviewed
CI/CD runbook created
Findings documented

🎯 Certification Connection

A Cloud+ scenario may say:

Developers manually deploy application changes and production frequently receives untested releases.

Think:

CI/CD pipeline with automated testing and deployment gates.

Another:

A deployment pipeline has permanent administrator credentials.

Think:

Credential-management and least-privilege failure.

Another:

A new application version should initially receive only 5% of production traffic.

Think:

Canary deployment.

Another:

The organization wants the new environment fully deployed before switching production traffic.

Think:

Blue-green deployment.

Another:

Application instances should be updated gradually while keeping the service available.

Think:

Rolling deployment.

Another:

A critical automated test fails.

Think:

Stop the pipeline and block deployment.

Another:

Production receives a different build than the version tested in staging.

Think:

Artifact consistency and environment-promotion problem.

Another:

An application deployment succeeds but monitoring shows a significant increase in errors.

Think:

Post-deployment validation and rollback/forward-fix decision.

🎤 Interview Questions

Practice without notes.

1. What is CI/CD?

2. What is Continuous Integration?

3. Continuous Delivery vs Continuous Deployment?

4. What is a pipeline?

5. What is a pipeline trigger?

6. Why is version control important?

7. What is an automated build?

8. Why automate testing?

9. What is a pipeline gate?

10. What is a build artifact?

11. Why version artifacts?

12. Why promote the same artifact?

13. How should pipeline secrets be managed?

14. Why should pipeline identities use least privilege?

15. What is branch protection?

16. What is rolling deployment?

17. What is blue-green deployment?

18. What is canary deployment?

19. What is rollback?

20. When might a forward fix be preferable?

21. Why are database changes difficult to roll back?

22. How can IaC integrate with CI/CD?

23. Why monitor pipelines?

24. Why perform post-deployment validation?

25. How would you secure a cloud CI/CD pipeline?

🚨 Scenario Interview Question 1

Developers can push directly to the production branch.

Improve:

Protected Branch
      ↓
Pull Request
      ↓
Tests
      ↓
Security Checks
      ↓
Review
      ↓
Merge

🚨 Scenario Interview Question 2

The pipeline contains a plaintext cloud administrator password.

Think:

Credential exposure.

Use an approved secrets-management or workload-identity mechanism.

🚨 Scenario Interview Question 3

Version 2 should be tested against a small percentage of real production traffic.

Use:

Canary deployment.

🚨 Scenario Interview Question 4

The company wants near-instant rollback by switching traffic to the previous environment.

Use:

Blue-green deployment.

🚨 Scenario Interview Question 5

A pipeline deploys successfully but the application health check fails.

Think:

Deployment
   ↓
Verification
   ↓
Failure
   ↓
Rollback / Forward Fix

🚨 Scenario Interview Question 6

The same application is rebuilt separately for testing and production.

Risk:

Tested Build
≠
Production Build

Prefer:

Build Once
    ↓
Versioned Artifact
    ↓
Promote

🚨 Scenario Interview Question 7

The CI/CD service can create and delete every resource in the cloud account.

Think:

Excessive permissions.

Apply least privilege to the pipeline identity.

🚨 Scenario Interview Question 8

An engineer modifies the pipeline to skip security scanning.

Controls should include:

Pipeline as Code
      ↓
Code Review
      ↓
Protected Branch
      ↓
Audit Logging

🚨 Scenario Interview Question 9

Production fails after a database schema migration, and the old application cannot use the new schema.

This demonstrates why rollback planning must consider:

Application
+
Database
+
Data Compatibility

🚨 Scenario Interview Question 10

A pipeline passes every stage but nobody knows which commit produced the running production version.

Improve:

Artifact and deployment traceability.

🧠 CI/CD Interview Framework

Remember:

CODE
  ↓
COMMIT
  ↓
REVIEW
  ↓
BUILD
  ↓
TEST
  ↓
SECURITY
  ↓
PACKAGE
  ↓
ARTIFACT
  ↓
PROMOTE
  ↓
APPROVE
  ↓
DEPLOY
  ↓
VERIFY
  ↓
MONITOR
  ↓
ROLLBACK

💬 Interview Tip

Avoid:

“CI/CD automatically deploys applications.”

A stronger answer is:

“I would design the CI/CD workflow so every change is traceable from source control through build, automated testing, security validation, artifact creation, environment promotion, and deployment. I would protect production branches, use dedicated least-privilege pipeline identities, keep secrets outside source code, version artifacts, introduce appropriate approval gates, choose a deployment strategy based on availability requirements, perform post-deployment health validation, monitor the release, and maintain a tested rollback or forward-fix procedure.”

That demonstrates Cloud Engineer and DevOps operational thinking.

📁 Portfolio Deliverables

Keep sanitized versions of:

1. CI/CD Pipeline Definition

Show:

Build

Test

Security

Package

Deploy

2. Application Repository

Include:

app/

tests/

infrastructure/

pipeline/

README.md

3. Pipeline Architecture Diagram

Show:

Developer
   ↓
Repository
   ↓
CI/CD
   ↓
Artifact
   ↓
Cloud

4. Pipeline Security Review

Document:

Repository Security

Secrets

Identity

Permissions

Artifacts

Approvals

Logging

5. Deployment Strategy

Document whether you selected:

Rolling

Blue-Green

Canary

and explain why.

6. Rollback Plan

Include:

Failure Criteria

Previous Version

Application Recovery

Infrastructure Recovery

Database Considerations

Validation

7. CI/CD Runbook

Document the complete operational workflow.

📝 Resume Examples

Instead of:

Worked with CI/CD.

Use:

Built cloud CI/CD workflows integrating source control, automated builds, testing, security validation, versioned artifacts, environment promotion, deployment approvals, and post-deployment verification.

Or:

Implemented secure CI/CD practices using protected source-control workflows, least-privilege deployment identities, centralized secrets management, automated security gates, artifact traceability, and monitored production deployments.

Or:

Designed cloud application delivery workflows supporting rolling, blue-green, and canary deployment strategies with automated health validation and rollback procedures.

⭐ Job-Readiness Check

You should now be able to:

explain CI/CD
distinguish CI, Continuous Delivery, and Continuous Deployment
understand source control workflows
explain pipeline triggers
build basic pipeline stages
automate testing
understand pipeline gates
explain artifacts
version artifacts
understand artifact repositories
integrate security validation
protect pipeline secrets
apply least privilege
understand pipeline identities
explain supply chain security
promote releases across environments
use deployment approvals
compare deployment strategies
explain rolling deployments
explain blue-green deployments
explain canary deployments
design rollback procedures
understand forward fixes
account for database changes
integrate IaC with CI/CD
understand pipeline logging
monitor deployments
perform post-deployment validation
troubleshoot pipeline failures
build CI/CD runbooks

🏆 Mission Complete

You have progressed from:

Developer
   ↓
Manual Build
   ↓
Manual Testing
   ↓
Manual Deployment

to:

Code
  ↓
Version Control
  ↓
Automated Build
  ↓
Automated Testing
  ↓
Security Validation
  ↓
Versioned Artifact
  ↓
Controlled Deployment
  ↓
Verification
  ↓
Monitoring

You now understand an important cloud engineering principle:

A successful CI/CD pipeline is not simply a deployment script. It is a controlled software-delivery system that makes changes repeatable, testable, traceable, secure, and recoverable.

🚀 What’s Next?

You have now built the core operational chain:

Cloud Operations
       ↓
Automation
       ↓
Infrastructure as Code
       ↓
CI/CD

The next step is to bring these capabilities together in a practical troubleshooting exercise.

You will investigate cloud problems across:

compute
networking
storage
identity
application connectivity
monitoring
logging
resource utilization
deployment failures
configuration issues
service dependencies
root-cause analysis
remediation
validation
incident documentation

You will work through problems systematically:

SYMPTOM
   ↓
SCOPE
   ↓
EVIDENCE
   ↓
HYPOTHESIS
   ↓
TEST
   ↓
ROOT CAUSE
   ↓
REMEDIATE
   ↓
VALIDATE
   ↓
DOCUMENT

➡️ Next: Lab 25 — Cloud Troubleshooting Lab