Developer Tools
Source control, build, test, and deployment services for shipping code on AWS.
AWS CLI
Unified command-line tool for controlling and scripting every AWS service from a terminal.
- One `aws` binary for every service, same shape every time: `aws <service> <operation> --flags` — it calls the same public APIs the Console does
- `aws configure` writes keys to `~/.aws/credentials` and Region + output format to `~/.aws/config`; `--profile <name>` switches accounts
- Defaults to JSON output; `--output table|text|yaml` and `--query` (JMESPath) trim the wall of output before it hits your screen
- Reality check: v1 entered maintenance mode 5 Aug 2026 and reaches end-of-support 15 Jul 2027 — assume v2 in anything current
Exam triggers
Phrases and scenarios that point here.
- "Automate", "script", "repeatable", "scheduled", "without using the console" → CLI
- "Programmatic access" or "access key ID and secret access key" → CLI or SDK, never Console sign-in
- Run AWS commands with nothing installed and no keys stored locally → CloudShell (CLI v2 pre-installed and pre-authenticated in the browser)
- An option offers long-lived access keys sitting on a laptop or in a script → wrong answer; IAM roles for EC2 and CI, IAM Identity Center for humans
Not this service
- Application code that calls AWS → the language SDK (boto3, AWS SDK for JavaScript), not shelling out to `aws`
- Repeatable, versioned infrastructure with drift detection → CloudFormation, not a folder of shell scripts
Use cases
- Cleaning up after yourself — a loop over `aws ec2 terminate-instances` kills a forgotten dev fleet in one command instead of forty Console clicks
- Bulk work the Console has no button for — `aws s3 sync` moving 50,000 objects, or tagging every untagged EBS volume in an account
- CI/CD steps that run with no human present — a build job assumes a role, then `aws ecr get-login-password` and `aws ecs update-service`
- Fast audits — `aws iam list-users --output table` answers "who has access?" before the Console page finishes loading
- Multi-account work — named profiles let one terminal jump between dev, staging, and prod with `--profile prod` instead of logging out and back in
Commonly confused with
Verified against AWS documentation · 2026-09-09
AWS CodeBuild
Fully managed build service that compiles code, runs tests, and produces deploy-ready artifacts — no build servers to manage.
- Serverless CI: you don't provision, patch, or scale build servers — builds run in fresh, ephemeral containers that are thrown away after every run
- buildspec.yml defines the build — phases (install, pre_build, build, post_build), commands, environment variables, and artifact output, living in the repo root
- Sources: GitHub, GitHub Enterprise, Bitbucket, CodeCommit, or S3; artifacts typically land in S3 or ECR (Docker images)
- Scales automatically and runs builds concurrently — no build queue when traffic spikes, unlike a single Jenkins box
- Can run inside your VPC to reach private resources (internal RDS for integration tests, private package repos)
Exam triggers
Phrases and scenarios that point here.
- "Compile", "run unit tests", "produce build artifacts", "no servers to manage for CI"
- Jenkins maintenance pain / build server patching → replace with CodeBuild
- Build stage inside a CodePipeline pipeline → the build action is CodeBuild
- Build needs access to resources in a private subnet → CodeBuild with VPC configuration
- Build Docker images and push to ECR → CodeBuild with privileged mode
Not this service
- Orchestrating the whole release flow (source → build → deploy stages) → CodePipeline
- Deploying artifacts to EC2, Lambda, or ECS → CodeDeploy
- Full platform that builds AND runs the app for you → Elastic Beanstalk
Use cases
- Replacing a self-managed Jenkins server — the classic 'our build box died on release day' problem disappears because every build gets a fresh managed environment
- Building and pushing Docker images to ECR as part of a container deployment pipeline
- Running the test suite on every pull request via webhook, so broken code is caught before merge instead of after deploy
- Integration tests against a private database — CodeBuild joins the VPC, hits the internal RDS endpoint, no public exposure needed
- Monorepo teams running many concurrent builds — CodeBuild parallelizes instead of queueing like a fixed-size build server would
Commonly confused with
Verified against AWS documentation · 2026-08-28
AWS CodeDeploy
Managed deployment service that automates rolling out application code to EC2, on-premises servers, Lambda, and ECS.
- Deploys to four targets: EC2, on-premises instances, Lambda, and ECS — EC2/on-prem need the CodeDeploy agent installed, Lambda/ECS don't
- Two deployment types: in-place (update instances where they run, EC2/on-prem only) and blue/green (spin up new environment, shift traffic, keep old one for rollback)
- The appspec file (appspec.yml) defines what to copy where and which lifecycle hook scripts to run — no appspec, no deployment
- Deployment configs control rollout speed: AllAtOnce, HalfAtATime, OneAtATime for EC2; canary and linear traffic shifting for Lambda/ECS
- Automatic rollback triggers on deployment failure or a CloudWatch alarm going off mid-deployment
Exam triggers
Phrases and scenarios that point here.
- "Automate deployments", "eliminate manual deployment steps", "deploy to a fleet of EC2 instances"
- "Zero-downtime deployment" or "gradually shift traffic" → blue/green or canary via CodeDeploy
- "Roll back automatically if the new version fails" → CodeDeploy with rollback on alarm
- Deploying to on-premises servers alongside EC2 with one tool → CodeDeploy (agent + AWS endpoint access is all it needs)
- "Gradually shift a percentage of Lambda traffic to a new version" → CodeDeploy canary/linear deployment config
Not this service
- Full end-to-end pipeline orchestration (source → build → test → deploy) → CodePipeline (CodeDeploy is just the deploy stage)
- Upload code and let AWS manage the whole environment → Elastic Beanstalk
- Provisioning infrastructure itself → CloudFormation (CodeDeploy ships code onto infra that already exists)
Use cases
- Replacing the "SSH in and copy files" ritual — a 50-instance web fleet gets the new release rolled out OneAtATime, so a bad build takes down one box, not fifty
- Blue/green for a payments API: new version gets full production traffic only after health checks pass, and rollback is a traffic switch, not a redeploy
- Canary-releasing a Lambda function — send 10% of traffic to the new version for 10 minutes, auto-rollback if error alarms fire, then shift the rest
- Hybrid shops deploying the same release to EC2 and their own data center servers with one deployment group and one appspec
- Lifecycle hooks that drain an instance from the load balancer, run DB migrations, then re-register it — deployment choreography as code instead of a runbook
Commonly confused with
Verified against AWS documentation · 2026-08-28
AWS CodePipeline
Fully managed CI/CD orchestration service that automates release pipelines from source to deploy.
- Pipeline = stages (Source → Build → Test → Deploy), each stage = one or more actions; artifacts pass between stages via an S3 bucket
- Orchestrates, doesn't execute — build work goes to CodeBuild, deploys go to CodeDeploy / ECS / Lambda / CloudFormation / Elastic Beanstalk
- Sources: GitHub / GitLab / Bitbucket (via connections), S3, ECR — a push or change triggers the pipeline automatically
- Manual approval actions gate a stage until a human clicks approve (e.g., before prod deploy)
- V1 pipelines: flat structure; V2 pipelines: adds triggers (Git tags, branch filters), pipeline variables, and stage conditions
Exam triggers
Phrases and scenarios that point here.
- "Automate the release process", "CI/CD pipeline", "deploy on every commit" → CodePipeline
- "Require human sign-off before production" → manual approval action
- Pipeline that builds → CodePipeline + CodeBuild; pipeline that deploys to EC2/on-prem → + CodeDeploy
- Cross-account or cross-region deployments in one release flow → CodePipeline supports both natively
Not this service
- Actually compiling/testing code → CodeBuild (CodePipeline just calls it)
- Deploying to instances with rolling/blue-green strategies → CodeDeploy
- Simple GitHub-native workflows with no AWS orchestration → GitHub Actions
Use cases
- Push to main → build in CodeBuild → deploy to staging → manual approval → deploy to prod, all hands-off after the commit
- Assembly-line mental model: each station (stage) does one job and passes the part (artifact) down the belt; a failed station stops the belt so bad parts never reach the end
- Infrastructure delivery: pipeline picks up a CloudFormation template change and rolls it through dev → prod with a change-set review step
- Multi-region rollout: one pipeline deploying the same build artifact to us-east-1 and eu-west-1 in sequence, stopping if the first region fails
- Container flow: new image lands in ECR → pipeline triggers → ECS service updated, no one ever SSHes anywhere
Commonly confused with
Verified against AWS documentation · 2026-08-28
AWS X-Ray
Distributed tracing service that follows a single request across every service it touches.
- Traces a request end-to-end: segments (per service) and subsegments (per downstream call) stitched into one trace
- Service map auto-draws your architecture from trace data — latency, errors, and throttles per node
- Sampling by default: first request each second + 5% of the rest, so you're not paying to trace everything
- Limits: 500 KB max trace size, 30-day trace retention, annotations are indexed/searchable but metadata is not
Exam triggers
Phrases and scenarios that point here.
- "Trace requests across microservices", "find the bottleneck", "end-to-end latency" → X-Ray
- "Which service in the chain is causing errors" → service map
- Debugging Lambda or API Gateway latency across multiple hops → enable active tracing
- Filter traces by business attribute (user ID, order ID) → annotations
Not this service
- Metrics, alarms, or dashboards → CloudWatch
- API call audit history (who did what) → CloudTrail
- Application logs → CloudWatch Logs
Use cases
- A checkout request passes through API Gateway → Lambda → DynamoDB → SQS and takes 4 seconds; X-Ray shows the 3.5s is one throttled DynamoDB call, not the Lambda code
- New microservice deployed Friday; the service map lights up a node red Monday morning — you see the failing dependency without grepping a single log
- Tagging traces with an annotation like orderId so support can pull the exact trace for one customer's failed order
- Comparing p50 vs p99 latency per downstream hop to prove which team's service is dragging the SLA
Commonly confused with
Verified against AWS documentation · 2026-08-27