DevOps is a cultural and technical movement that breaks down the traditional wall between software developers (those who write code) and IT operations (those who run the servers and keep systems working). For the DOP-C02 exam, understanding DevOps principles is essential because every question about automation, delivery pipelines, and monitoring is built on this foundation.
Jump to a section
A simple way to picture DevOps Principles and AWS Overview
A restaurant kitchen is a high-pressure environment where small teams of specialised cooks must work together to deliver consistent, high-quality meals to customers every night. In many traditional kitchens, the head chef spends hours each morning handwriting the menu and recipe cards, and then personally hands them to each station chef. When a customer orders a steak medium-rare, the server writes the order on a paper ticket, clips it to a line, and a runner physically takes it to the grill cook. The grill cook reads the ticket, cooks the steak, plates it, and a runner delivers it. This works, but it is slow. If the menu changes, the head chef must reprint all recipe cards. If the grill cook is ill, the sous chef must cover, but she does not know the exact seasoning instructions, so the steak tastes different. If the health inspector arrives and asks for the order history of table seven, the kitchen staff must dig through a pile of paper tickets.
Now imagine a modern kitchen using a digital system. The head chef publishes the menu and all recipes to a shared tablet that every station chef can see instantly. When a server inputs an order, that order appears on a screen at every relevant station simultaneously. The system tracks which dish was ordered, who cooked it, and how long it took. The head chef can update a recipe, push that update to all tablets, and every cook follows the same instructions immediately. This is DevOps on AWS. The code repository is the shared recipe book. The continuous delivery pipeline is the automatic system that takes a recipe change and deploys it to all stations. AWS services like CodeCommit, CodeBuild, CodeDeploy, and CodePipeline form this digital kitchen infrastructure. The goal is the same: deliver consistently, adapt quickly, and know exactly what happened in the past.
DevOps is a portmanteau of 'Development' and 'Operations'. It describes a set of practices that combine software development (Dev) and IT operations (Ops) to shorten the development life cycle and deliver high-quality software continuously. The core goal is to deploy code to production more frequently, with higher reliability and faster feedback.
Before DevOps, most organisations used a model called Waterfall. In Waterfall, developers would write code for months, then 'throw it over the wall' to a separate operations team that would try to run it on production servers. This created massive friction. The developers did not understand the production environment, and the operations team did not understand the code. Releases happened every six to twelve months. If something broke, it was difficult to know which change caused the problem.
DevOps replaces this with a culture of collaboration. Developers and operations engineers work together from the start. They share tools, processes, and responsibilities. This is underpinned by three key practices:
Continuous Integration (CI): Developers frequently merge their code changes into a shared repository, often multiple times per day. Each merge triggers an automated build and a series of automated tests. This catches integration bugs early, before they reach production.
Continuous Delivery (CD): Every code change that passes all automated tests is automatically deployed to a staging environment that mimics production. From there, a manual approval or an automated gate decides when to push it to production. This means the software is always in a release-ready state.
Continuous Deployment (also CD): A stricter version of Continuous Delivery where every change that passes all tests is automatically deployed to production with no human intervention. This is the 'holy grail' for many organisations.
Amazon Web Services (AWS) provides a suite of services to implement these practices. The main services are:
AWS CodeCommit: A fully managed source control service that hosts secure Git-based repositories. It is the place where developers store their code.
AWS CodeBuild: A fully managed continuous integration service that compiles source code, runs tests, and produces software packages ready to deploy. It eliminates the need to provision, manage, and scale your own build servers.
AWS CodeDeploy: A fully managed deployment service that automates code deployments to any instance, including Amazon EC2 instances, AWS Lambda functions, and on-premises servers. It handles rolling updates, blue/green deployments, and canary releases.
AWS CodePipeline: A fully managed continuous delivery service that helps you automate your release pipelines for fast and reliable application and infrastructure updates. It orchestrates the entire workflow from source to build to deploy.
AWS CodeStar: A unified user interface that enables you to quickly develop, build, and deploy applications on AWS. It integrates with CodeCommit, CodeBuild, CodeDeploy, and CodePipeline.
DevOps also relies heavily on measuring everything. You cannot improve what you do not measure. Metrics like deployment frequency, lead time for changes, mean time to recovery, and change failure rate are used to assess pipeline health. AWS CloudWatch and AWS X-Ray help collect and visualise this data.
Infrastructure as Code (IaC) is another critical DevOps principle. This means defining your servers, networks, databases, and other infrastructure components in machine-readable configuration files. AWS CloudFormation and AWS CDK (Cloud Development Kit) allow you to treat your infrastructure like application code: version-controlled, tested, and deployed automatically.
Finally, security is integrated into DevOps, often called DevSecOps. Automated security scanning, compliance checks, and vulnerability assessments are run as part of the pipeline. AWS provides services like Amazon GuardDuty, AWS Inspector, and AWS Security Hub for this purpose.
Commit Code to Source Control
A developer writes new code and uses git to push their changes to a remote repository, such as AWS CodeCommit. This is the trigger for the entire pipeline. Without this step, no automation can start. The code is now versioned and stored securely.
Automated Build and Test (Continuous Integration)
The push to the repository automatically triggers AWS CodeBuild. CodeBuild pulls the latest code, compiles it, runs unit tests, and generates a deployable artifact (e.g., a JAR file or Docker image). If any test fails, the pipeline stops and the developer is notified immediately.
Create or Update Infrastructure (Infrastructure as Code)
Before deploying the application, the pipeline may run an AWS CloudFormation template to provision or update the target environment. This ensures the infrastructure is in the correct state before the application is deployed, preventing environment drift.
Deploy to Staging Environment (Continuous Delivery Gate)
After a successful build, the artifact is deployed to a staging environment that mirrors production. AWS CodeDeploy handles the deployment, performing a rolling update or blue/green swap. This is where integration and acceptance tests are run. A manual approval step can be placed here for compliance.
Deploy to Production (Continuous Deployment or Approved Release)
Once staging tests pass and any manual approvals are granted, the pipeline deploys the same artifact to production using CodeDeploy with the desired deployment strategy (e.g., canary, blue/green). Traffic is shifted gradually, and if monitoring detects errors, the deployment can be automatically rolled back.
Monitor and Feedback
After deployment, AWS CloudWatch and AWS X-Ray collect logs, metrics, and traces. The pipeline reports success or failure. Developers use this data to improve code quality and pipeline performance, closing the loop and starting the cycle again.
Imagine you work for a mid-sized e-commerce company called 'ShopFast'. The company has ten developers, three operations engineers, and a single production environment running on Amazon EC2 instances behind an Application Load Balancer. The old way of releasing software was painful. Once a month, a developer would manually copy a WAR file to a server, restart Apache, and hope nothing broke. Deployments were stressful, unpredictable, and often caused downtime.
Your first task is to implement a proper continuous delivery pipeline using AWS CodePipeline. Here is exactly what you would do, step by step:
Set up a Git repository in AWS CodeCommit. You migrate the existing codebase from a local server into this repository. Every developer clones this repo and starts committing their changes directly to a 'develop' branch.
Configure AWS CodeBuild to run whenever a developer pushes code to the 'develop' branch. The build specification (buildspec.yml) defines how to compile the Java code, run unit tests, and package it into a deployable artifact. If the build fails, the developer receives an email from Amazon SNS (Simple Notification Service) and must fix the code before it can proceed.
Create a staging environment that is an exact copy of production. You use AWS CloudFormation to define this environment as code. When CodeBuild succeeds, CodePipeline automatically deploys the new artifact to the staging environment using AWS CodeDeploy. CodeDeploy runs in-place deployments, meaning it updates the existing EC2 instances one at a time. This ensures zero downtime.
Add a manual approval step to the pipeline. Before the code can go to production, a senior developer or the operations lead must click 'Approve' in the CodePipeline console. This is a common control for regulatory compliance or critical systems.
After approval, CodePipeline triggers a CodeDeploy deployment to the production fleet. You configure the deployment to use a 'blue/green' strategy: a new set of EC2 instances (the 'green' environment) is launched alongside the old 'blue' environment. Traffic is shifted from blue to green using the Application Load Balancer. If something goes wrong, you can instantly switch back to the blue environment.
Now, after this pipeline is in place, your deployments happen multiple times per day. Developers get immediate feedback on their code. The operations team no longer has to perform manual, error-prone copy-paste jobs. The entire process is auditable, repeatable, and fast.
If a security vulnerability is discovered, your pipeline can be extended to include a scanning step in AWS CodeBuild using tools like Amazon ECR image scanning. If the scan fails, the pipeline stops automatically. This is how DevSecOps works in practice.
The DOP-C02 exam expects you to understand DevOps principles deeply, but it tests them through the lens of AWS services. The exam does not ask 'What is DevOps?' in a theoretical sense. Instead, it presents scenarios where you must choose the correct AWS service to implement a specific practice.
Key areas that are tested:
Understanding the difference between Continuous Integration, Continuous Delivery, and Continuous Deployment. The exam often gives a scenario and asks which practice is being described. For example, 'A company wants every code commit that passes tests to be automatically deployed to production. Which practice is this?' The correct answer is Continuous Deployment. Many candidates choose Continuous Delivery, which requires a manual approval step.
Knowing the exact capabilities of CodeCommit, CodeBuild, CodeDeploy, and CodePipeline. Which service is used for hosting Git repositories? CodeCommit. Which service compiles code? CodeBuild. Which service orchestrates the entire workflow? CodePipeline. The exam will present a scenario where you need to choose the correct combination.
Understanding deployment strategies: in-place, rolling, canary, blue/green. The exam tests which strategy minimises downtime, which is best for testing new features on a subset of users, and which AWS services support each. CodeDeploy supports all major strategies. The exam loves 'canary' deployments because they are a specific pattern for gradual rollouts.
Infrastructure as Code (IaC) with AWS CloudFormation or CDK. You need to know that CloudFormation allows you to define your entire infrastructure in a template file (JSON or YAML), and that changes are made through change sets and stack updates.
How to integrate security scanning into a pipeline. The exam may ask about using AWS Inspector, Amazon ECR scanning, or third-party tools within CodeBuild.
The role of monitoring and metrics. AWS CloudWatch is used for logging and metrics. AWS X-Ray traces requests through distributed systems. The exam tests whether you know which tool to use for which purpose.
Common traps:
Confusing CodePipeline with CodeDeploy. Remember: CodePipeline is the orchestrator that connects source, build, and deploy stages. CodeDeploy is the service that actually pushes code to instances.
Forgetting that CodeBuild can run in a custom environment using a Docker build image.
Assuming that manual approval is always required. In Continuous Deployment, there is no manual approval.
Thinking that all deployment strategies are equal. Blue/green is best for zero-downtime deployments with a quick rollback. In-place rolling updates can cause downtime if not configured carefully.
The exam also tests your ability to design a pipeline that meets specific compliance or security requirements, such as preventing deployment if automated security tests fail. Memorise the service names and their primary functions, and practise with AWS documentation examples.
DevOps is a cultural movement that brings development and operations teams together to deliver software faster and more reliably.
Continuous Integration (CI) merges code changes frequently and runs automated tests to catch errors early.
Continuous Delivery (CD) keeps every change in a release-ready state but requires a manual approval step before production deployment.
Continuous Deployment automatically deploys every change that passes all tests to production with no human intervention.
AWS CodePipeline is the central orchestration service that connects source control, build, deploy, and other stages into a single automated workflow.
Infrastructure as Code (IaC) using AWS CloudFormation or CDK lets you define, version, and deploy your cloud infrastructure just like application code.
Blue/green deployments reduce risk by running two identical environments and switching traffic gradually.
DevSecOps integrates automated security scanning and compliance checks directly into the CI/CD pipeline.
These come up on the exam all the time. Here's how to tell them apart.
Continuous Delivery
Requires a manual approval step before deployment to production.
Code is always in a release-ready state but not automatically released.
Suitable for regulated industries that need human approval gates.
Continuous Deployment
No manual approval; every change that passes tests goes straight to production.
Fully automated from code commit to production release.
Requires robust automated testing and monitoring to manage risk.
AWS CodeCommit
A source control service that hosts Git repositories.
Stores and versions your application code and configuration files.
Does not execute build or deploy actions on its own.
AWS CodePipeline
An orchestration service that automates the entire release process.
Connects source (e.g., CodeCommit) to build (CodeBuild) to deploy (CodeDeploy).
Defines the stages and transitions of your CI/CD workflow.
Blue/Green Deployment
Two full copies of production (blue and green) run simultaneously.
Traffic is switched entirely from one environment to the other.
Rollback is instant by switching traffic back to the original environment.
Canary Deployment
New version is released to a small subset of users (e.g., 5%) first.
Traffic is gradually increased over time based on monitoring data.
Rollback is slower — requires stopping the canary and shifting users back.
AWS CloudFormation
Uses declarative JSON or YAML templates to define infrastructure.
No programming language required; you write the template directly.
Template can be version-controlled and validated by CloudFormation.
AWS CDK (Cloud Development Kit)
Uses familiar programming languages (TypeScript, Python, Java, etc.) to define infrastructure.
Allows you to use loops, conditions, and abstractions common in programming.
Synthesises into CloudFormation templates behind the scenes.
Mistake
DevOps is a specific tool or software that you install.
Correct
DevOps is a cultural and philosophical approach that combines people, processes, and tools. Tools like AWS CodePipeline support DevOps, but they are not DevOps itself.
Many beginners come from a vendor background where a product claims to 'do DevOps'. This leads to the false belief that buying a tool solves the cultural challenges.
Mistake
Continuous Delivery and Continuous Deployment are the same thing.
Correct
Continuous Delivery means every change is ready to go to production but requires a manual approval step. Continuous Deployment goes further by automatically deploying every change that passes tests to production with no manual step.
The abbreviations are both 'CD', and many study materials use them interchangeably. However, the DOP-C02 exam treats them as distinct concepts with a clear difference: the manual gate.
Mistake
DevOps means developers also manage the servers, so operations teams are no longer needed.
Correct
DevOps breaks down silos, but it does not eliminate the operations role. Instead, operations engineers work closely with developers from the start. The responsibilities shift from manual server management to building automation and monitoring systems.
Job titles like 'DevOps Engineer' have led people to think you must do both development and operations simultaneously. In reality, it is about collaboration, not elimination of roles.
Mistake
You must use all AWS CodeSuite services (CodeCommit, CodeBuild, CodeDeploy, CodePipeline) together to practise DevOps on AWS.
Correct
AWS services are modular. You can use CodePipeline with a third-party source control like GitHub, CodeBuild with a third-party deployment tool, or CodeDeploy without the others. AWS encourages integration with your existing toolchain.
Vendor lock-in is a common fear. The DOP-C02 exam tests whether you know that AWS services are designed to work with external tools, not require all-native stacks.
Mistake
Infrastructure as Code (IaC) is optional for DevOps.
Correct
IaC is a foundational practice of DevOps. Without IaC, you cannot reliably reproduce environments, version control infrastructure changes, or automate deployments in a consistent way.
Beginners often think IaC is just a nice-to-have automation tip. The exam emphasises it because it enables repeatability, auditability, and speed — core DevOps goals.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
AWS CodeCommit is a fully managed Git repository service that is native to AWS. Unlike GitHub, it does not have a public community or built-in social coding features. Its advantage is tight integration with other AWS services like CodeBuild and CodePipeline.
No. AWS CodeBuild supports many languages including Java, Python, Node.js, Ruby, Go, and .NET. You define a buildspec.yml file that specifies the runtime and commands. CodeBuild runs on managed compute resources you choose.
Yes. CodePipeline can connect to GitHub, Bitbucket, or any Git repository using webhooks or the built-in GitHub integration. It is not limited to CodeCommit.
A blue/green deployment runs two identical production environments (blue and green). Traffic is directed to one environment (blue) while the other (green) is idle. When you deploy, you update the idle environment and then shift traffic to it. This enables instant rollback by switching traffic back to the original environment.
A canary deployment releases the new version to a small percentage of users (e.g., 5%) first, then gradually increases traffic if no errors occur. A rolling deployment updates instances one by one across the entire fleet. Canary is safer for risky changes because it limits blast radius.
CodeDeploy uses a 'deployment group' which is a set of EC2 instances identified by tags, Auto Scaling groups, or AWS Lambda function aliases. You define the deployment group in the CodeDeploy console or through CloudFormation, and the service determines which targets to update.
You've finished DevOps Principles and AWS Overview. Continue through the DOP-C02 study guide to build a complete picture of the exam.
Done with this chapter?