AWS Certified Developer - Associate (DVA-C02) #9 Domain 3-1 Deployment — CI/CD
With #8 Encryption and Secrets we wrapped up security. Now comes the deployment domain, which carries 24%. DVA asks “how do you build code, where do you deploy it, and how do you update it with zero downtime?” The first post is about the division of roles among the AWS developer tools (the Code series). Their names are easy to confuse, but each one’s role is clear.
Role Division in the Code Series #
| Tool | Role | One line |
|---|---|---|
| CodeCommit | Source repository | Managed Git (a GitHub replacement) |
| CodeBuild | Build,test | Compiles and tests the source to produce an artifact |
| CodeDeploy | Deploy | Deploys the artifact to EC2/Lambda/ECS |
| CodePipeline | Orchestration | A pipeline that strings the above stages together |
| CodeArtifact | Package repository | Stores and shares npm,pip,Maven dependencies |
The core distinction: CodePipeline coordinates the flow, CodeBuild builds, and CodeDeploy deploys. “Who builds?” is CodeBuild, “who deploys?” is CodeDeploy, and “what ties the whole thing together?” is CodePipeline.
CodeBuild and buildspec.yml #
CodeBuild pulls the source into a build environment (a container), runs commands, and produces an artifact. The build definition lives in buildspec.yml at the source root.
version: 0.2
phases:
install:
commands:
- echo Installing dependencies
pre_build:
commands:
- echo Login and prep
build:
commands:
- echo Running build and tests
post_build:
commands:
- echo Packaging
artifacts:
files:
- '**/*'- The phases run in the order
install→pre_build→build→post_build. - You inject configuration via environment variables, and reference sensitive values from Parameter Store,Secrets Manager (never expose them as plaintext in build logs).
- Caching build dependencies can shorten build times.
Exam trap:
buildspec.ymlis located by default at the source root. Expect questions on the phase names and their order.
CodeDeploy and appspec #
CodeDeploy deploys the artifact to a target and controls the deployment process with lifecycle hooks. The deployment definition is appspec.yml (EC2/on-premises) or appspec.yaml (ECS/Lambda).
| Deployment target | appspec core | Representative hooks |
|---|---|---|
| EC2/on-premises | File copy locations + hook scripts | BeforeInstall, AfterInstall, ApplicationStart, ValidateService |
| Lambda | Shift traffic to the new version | BeforeAllowTraffic, AfterAllowTraffic |
| ECS | Switch to a new task set | BeforeInstall, AfterAllowTestTraffic, etc. |
Lifecycle hooks run validation scripts to judge deployment success or failure, and on failure they roll back. Deployment methods (in-place vs blue/green, canary/linear) are covered in #11.
CodePipeline #
This is the orchestrator that connects the various stages. A typical pipeline looks like this.
Source(CodeCommit/GitHub) → Build(CodeBuild) → (Test) → Deploy(CodeDeploy/CFN/ECS)- Each stage is made up of one or more actions, and artifacts are passed between stages via S3.
- You can insert a Manual Approval action between stages so a human reviews and then proceeds.
- When a source change is detected (EventBridge/webhook), the pipeline runs automatically.
The answer to “make a human approve before production deployment” is CodePipeline’s manual approval action.
CodeArtifact #
A managed repository for packages such as npm,pip,Maven,NuGet. It proxies and caches external public repositories (npmjs, etc.) and securely shares internal organizational packages. It’s the answer to “securely host and share internal dependency packages.”
Container Deployment — ECR and ECS/Fargate #
DVA also asks about container basics.
- ECR (Elastic Container Registry) — A Docker image repository. CodeBuild builds the image and pushes it to ECR.
- ECS/Fargate — Container execution. Fargate is serverless containers with no server management.
- Deployment registers a new task definition and updates the service, and blue/green switching is also possible with CodeDeploy.
Exam question patterns #
- “Which stage compiles and tests the source to create an artifact?” → CodeBuild.
- “Which stage deploys the artifact to EC2/Lambda/ECS?” → CodeDeploy.
- “Which tool automatically ties the whole flow together?” → CodePipeline.
- “A human reviews before production deployment.” → CodePipeline’s manual approval action.
- “What’s the build phase definition file?” →
buildspec.yml(source root). - “What’s the deployment hook definition file?” →
appspec. - “Host and share internal npm packages.” → CodeArtifact.
- “Use secret values safely in a build.” → Reference Parameter Store/Secrets Manager (no log exposure).
Common traps #
1) Confusing the roles of CodeBuild and CodeDeploy #
CodeBuild builds, CodeDeploy deploys. CodePipeline is the higher-level flow that connects the two.
2) Confusing buildspec and appspec #
buildspec.yml is CodeBuild’s build definition; appspec is CodeDeploy’s deployment definition.
3) Putting secrets in buildspec as plaintext #
Sensitive values among build environment variables should be referenced from a secret store.
Wrap-up #
What this post locked in:
- CodeCommit (source),CodeBuild (build),CodeDeploy (deploy),CodePipeline (orchestration),CodeArtifact (packages)
buildspec.yml(build, source root, install→pre_build→build→post_build)appspec(deploy, lifecycle hooks)- CodePipeline’s stages,actions,artifacts, gated with manual approval
- Containers are ECR + ECS/Fargate
Next — Domain 3-2 IaC and Serverless Deployment #
To automate deployment, you need to define infrastructure as code. In #10 IaC and Serverless Deployment, I’ll cover CloudFormation templates and stacks, SAM which simplifies serverless deployment, and Elastic Beanstalk’s deployment policies.