AWS Developer Associate DVA-C02 Deployment and CI/CD

For the AWS Developer Associate exam and modern development teams, mastering Continuous Integration and Continuous Deployment (CI/CD) is non-negotiable. This isn't just about passing a test; it's about understanding how to automate the path from code commit to production reliably, safely, and efficiently. The DVA-C02 exam tests your ability to choose and implement the right AWS services and deployment strategies for any given scenario, making this knowledge critical for both your certification and your career.

AWS Developer Tools: The CI/CD Building Blocks

The core of AWS's native CI/CD offering is a suite of four integrated services, often called the "AWS Code" services. You must understand each service's purpose, its inputs and outputs, and how they connect to form an automated pipeline.

AWS CodeCommit is a fully-managed source control service that hosts secure Git-based repositories. It serves as the foundational trigger for your pipeline. When a developer pushes code to a designated branch (like main), this event can automatically initiate the next stages of the CI/CD process. For the exam, know that it integrates seamlessly with IAM for fine-grained access control and with AWS CodeBuild for direct cloning.

AWS CodeBuild is a fully managed build service that compiles source code, runs tests, and produces software packages ready for deployment. You don't manage servers; you define your build environment through a buildspec.yml file in your project root. This YAML file specifies phases like install, pre_build, build, and post_build. A key exam concept is understanding where CodeBuild gets its source (e.g., CodeCommit, S3) and where it places its output artifacts (almost always an S3 bucket). The build process runs in a temporary container, and you are charged for the compute time used.

AWS CodeDeploy is the service that automates application deployments to various compute services. Its primary job is to execute a deployment according to a defined strategy. You configure CodeDeploy using an appspec.yml file, which is the deployment instruction manual. It specifies where to copy files from (e.g., S3) to on the target instances (the hooks section) and defines the lifecycle event hooks for running scripts (e.g., ApplicationStop, BeforeInstall, AfterInstall). Crucially, CodeDeploy deploys to compute platforms like Amazon EC2 (including Auto Scaling Groups), AWS Lambda, and Amazon ECS—not directly to S3 or static websites.

AWS CodePipeline is the orchestration service that visually connects the other services into a complete release workflow. You define a pipeline with stages (e.g., Source, Build, Deploy) and actions within each stage (e.g., "Source: CodeCommit," "Build: CodeBuild," "Deploy: CodeDeploy"). It manages the flow of artifacts from one stage to the next and allows for manual approval actions before promotion to production. For the exam, understand that pipeline executions are triggered by changes in the source stage or can be run manually.

Deployment Strategies with CodeDeploy

Choosing the right deployment strategy is a classic DVA-C02 scenario, as it balances speed, risk, and infrastructure cost. CodeDeploy offers several key strategies for EC2/on-premises deployments.

An all-at-once deployment (also called "in-place") updates all instances in your deployment group simultaneously. This is the fastest strategy but has the highest risk, as downtime is inevitable if the application stops during deployment. It's suitable for development environments or non-critical applications.

A rolling deployment updates instances in batches. For example, you might deploy to 50% of instances first, then the remaining 50%. CodeDeploy waits for a batch to be healthy before proceeding to the next. This minimizes impact but prolongs the deployment. You can configure the batch size as a percentage or a fixed number.

A blue-green deployment is a strategy that minimizes risk and downtime. You have two identical environments: "Blue" (the current production) and "Green" (the new version). CodeDeploy deploys the new version to the idle Green environment. After thorough testing, traffic is routed from Blue to Green, often via a load balancer. If something goes wrong, you can instantly switch back to Blue. While this is highly available, it requires double the infrastructure during the cutover, increasing cost.

A canary deployment is a controlled, risk-mitigated rollout. Traffic is shifted in two increments. First, a small percentage of traffic (the "canary") is routed to the new version for a specified evaluation period. If no alarms trigger (e.g., from Amazon CloudWatch), CodeDeploy then routes the remaining traffic. If alarms do trigger, the deployment can be automatically rolled back. This is ideal for testing new features with real users in production with minimal potential impact.

Managed Deployment Services: Elastic Beanstalk and SAM

Beyond the granular control of CodeServices, AWS offers higher-level services that abstract away infrastructure management.

AWS Elastic Beanstalk is a Platform-as-a-Service (PaaS) that handles capacity provisioning, load balancing, scaling, and application health monitoring. You simply upload your code (e.g., a Java .war file or Node.js zip), and Beanstalk does the rest. For the DVA-C02, you must know its deployment policies. The "All at once" policy causes downtime. The "Rolling" and "Rolling with additional batch" policies update instances in batches without changing capacity. The Immutable policy is a safe, blue-green-like strategy where Beanstalk deploys a complete new set of instances in a separate Auto Scaling Group, swaps them with the old ones after passing health checks, and then terminates the old instances. This is the most reliable but slowest and most resource-intensive method.

AWS Serverless Application Model (SAM) is a framework for building and deploying serverless applications using AWS Lambda, API Gateway, and DynamoDB. You define your application in a YAML template (template.yaml), which is an extension of AWS CloudFormation. The sam deploy command (using the SAM CLI) packages your code, uploads it to S3, and deploys the application via CloudFormation. A key exam concept is understanding that SAM transforms and expands its shorthand syntax into a full, standards-compliant CloudFormation template before deployment.

Infrastructure as Code with AWS CloudFormation

AWS CloudFormation is the foundational Infrastructure as Code (IaC) service on AWS. You define your entire cloud environment—networks, servers, databases, IAM roles—in a declarative JSON or YAML template. CloudFormation then creates and configures those resources as a single unit called a stack.

For the Developer Associate exam, focus on stack management operations. You initiate a deployment with CreateStack, update resources with UpdateStack, and remove all resources cleanly with DeleteStack. Understanding change sets is critical: they allow you to preview how a proposed update will affect your running resources before executing it, helping to prevent accidental disruptions. You should also know how CloudFormation handles rollbacks on failure and the purpose of stack policies (which protect specific resources in a stack from being updated or deleted).

Common Pitfalls

Misconfiguring Artifact Locations: A frequent error is mismatching artifact input and output locations between pipeline stages. Remember: CodeBuild outputs artifacts to S3. CodeDeploy reads its application revision from S3 (when deploying to EC2). The pipeline artifact must be explicitly passed from the Build stage to the Deploy stage. If your CodeDeploy action fails with "missing artifact," check the artifact configuration in CodePipeline.

Confusing Deployment Behaviors: It's easy to mix up the behaviors of similar-sounding strategies. For example, Elastic Beanstalk's "Rolling" deployment does not add extra capacity, while "Rolling with additional batch" does. In CodeDeploy, a "rolling" deployment can leave your fleet at reduced capacity if a batch fails, whereas a "blue-green" deployment always keeps the original environment intact until the cutover. Always associate the strategy with its core trade-off: speed vs. risk vs. cost.

Overlooking IAM Permissions: The CI/CD pipeline involves multiple services interacting. CodePipeline needs permissions to invoke CodeBuild and CodeDeploy. CodeBuild needs permissions to pull from CodeCommit and write to S3. CodeDeploy needs permissions to read from S3 and to perform operations on EC2 instances or Lambda functions. Many pipeline failures stem from incomplete IAM roles and policies. In a scenario, always consider if an "Access Denied" error could be an IAM issue.

Ignoring the appspec.yml or buildspec.yml: These are not optional configuration files; they are essential execution plans. An incorrect path in the files section of appspec.yml will cause a deployment to fail because CodeDeploy can't copy the application files. A missing runtime version in the buildspec.yml will cause CodeBuild to fail. Know their structure and common sections cold.

Summary

• The AWS CI/CD pipeline is orchestrated by CodePipeline, using CodeCommit for source, CodeBuild for compilation and testing, and CodeDeploy for executing deployments to compute services.
• Choose a deployment strategy based on risk tolerance: All-at-once (fastest, most risky), Rolling (batched, minimal impact), Blue-Green (safe, requires duplicate infrastructure), or Canary (traffic-shifted, ideal for testing in production).
• Elastic Beanstalk provides managed deployment policies, with Immutable being the safest (and slowest) method, akin to blue-green.
• AWS SAM simplifies serverless deployment by extending CloudFormation, which manages infrastructure as a single, versioned stack using declarative templates.
• For the exam, pay close attention to service integration points (especially IAM roles and artifact S3 buckets) and the specific YAML configuration files (buildspec.yml, appspec.yml) that control the build and deployment behaviors.