CodeDeploy on EC2 and on-premises (agent, AppSpec, hooks): DOP-C02 study notes and practice questions
What to know about CodeDeploy on EC2 and on-premises (agent, AppSpec, hooks) for the DOP-C02 exam, from the SDLC Automation domain (22% of the exam guide), then 2 free questions to test it. Part of the DOP-C02 study guide.
CodeDeploy questions ask how to release to servers with health checks and rollback, or why a deployment failed.
Setup
The CodeDeploy agent runs on each instance and polls outbound, so on-premises servers need no inbound access. Register them as on-premises instances with an IAM user or role.
A deployment group targets instances by tag or Auto Scaling group, optionally behind a load balancer.
The AppSpec file (appspec.yml) maps files and lists hook scripts.
With a load balancer, BeforeBlockTraffic, BlockTraffic, AfterBlockTraffic come first and BeforeAllowTraffic, AllowTraffic, AfterAllowTraffic come last. ValidateService is the place for health checks; a failing script fails the deployment.
Deployment types
Type
How
In-place
Stop, update and restart on existing instances, a batch at a time
Blue/green
Build a replacement fleet (copying the Auto Scaling group), shift load balancer traffic, keep or terminate the original
Deployment configurations:OneAtATime, HalfAtATime, AllAtOnce, or custom minimum healthy hosts.
Rollback
Automatic rollback when a deployment fails or a CloudWatch alarm fires; it redeploys the last good revision as a new deployment.
Blue/green keeps the original fleet for fast rollback.
Troubleshooting
Check the deployment’s instance events to see which hook failed.
Read the agent logs and script output on the instance.
Common causes: agent not running, missing S3 or KMS permissions on the instance profile, scripts that aren’t executable, or hooks that time out.
Common traps
Opening inbound ports for on-premises servers; the agent polls out.
Health checks in ApplicationStart instead of ValidateService.
Logging into servers to fix them instead of deploying a corrected revision.
A hospital network runs its patient-scheduling web application on 60 Linux servers in its own data centers, not on AWS. The servers are not in an Auto Scaling group and cannot be replaced by new instances.
Releases are copied to each server with scripts that stop the web service for several minutes. An error on one server has left the application half-upgraded in the past. The operations team wants releases to roll out in batches, with each server checked after its install and a failed release rolled back automatically.
The servers have outbound HTTPS access to AWS but no inbound access from the internet, and the team wants deployment records kept in AWS.
Which TWO actions meet these requirements? (Choose two.)
Choose two answers.
AA. Register each server with AWS CodeDeploy as an on-premises instance by using an IAM user or session ARN, and install the CodeDeploy agent on each server so that it polls the service over HTTPS.
BB. Deploy the application with AWS Systems Manager Run Command to all 60 servers at once, running the same install script, and check the results with a command status query afterward.
CC. Move the scheduling application onto Amazon EC2 instances in an Auto Scaling group behind a load balancer, and replace the data-center servers with rolling instance refreshes.
DD. Add a ValidateService hook to the AppSpec file that calls the application's health endpoint, and set a deployment configuration that updates the fleet in batches and rolls back automatically when a deployment fails.
EE. Keep the scripts, but run them as a cron job on each server every night, with a script that restarts the service and writes its log to a central file share.
B. Wrong: Run Command runs scripts across many servers at once, but it has no rolling batches and no automatic rollback. A failed install would still leave some servers upgraded and others not. Learn more: AWS Systems Manager Run Command (opens in a new tab)
D. Right: Correct. AppSpec lifecycle hooks such as ValidateService run checks after each install, and a deployment configuration sets how many servers update at once. Automatic rollback on failure stops a bad release from spreading across the batches. Learn more: AppSpec 'hooks' section (opens in a new tab)
E. Wrong: A nightly cron job does not provide batched rollouts or health gating, and the file share would be the only deployment record. It keeps the same risks that left servers half-upgraded.
Explanation
CodeDeploy can deploy to servers outside AWS once they are registered as on-premises instances and run the agent, which polls outbound only. AppSpec hooks run health checks after each install, and a deployment configuration limits how many servers update at a time and rolls back on failure. Run Command, cron jobs and an Auto Scaling migration do not give the same gating.
A regional bank runs its online banking web tier on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer. Releases currently use CodeDeploy in-place deployments, and a failed release has left some instances serving the old and new code at once.
The release manager wants each release to build a complete replacement fleet, check it before any customer traffic reaches it, and keep the original fleet running for an hour so that a rollback is only a traffic change. After that hour, the original instances must be terminated without anyone doing it by hand.
The team wants to keep using CodeDeploy for the application package and lifecycle hooks.
Which approach meets these requirements?
Choose one answer.
AA. Change the deployment group to use an in-place deployment with the OneAtATime configuration and a longer ValidateService hook, so that each instance is checked before the next one is updated.
BB. Create a second Auto Scaling group by hand for each release, copy the application package onto its instances with a Run Command document, and point the load balancer at the new group after the health checks pass.
CC. Configure a CodeDeploy blue/green deployment for the group, with CodeDeploy provisioning a replacement fleet, shifting load balancer traffic after the checks pass, and terminating the old instances after a wait.
DD. Replace the CodeDeploy deployment with a rolling instance refresh of the Auto Scaling group, using a launch template that points at the new application package in Amazon S3.
B. Wrong: This keeps two fleets, but the team would coordinate the copy, the health checks and the traffic change by hand. It also gives up the CodeDeploy deployment record and its automatic rollback. Learn more: AWS Systems Manager Run Command (opens in a new tab)
CodeDeploy blue/green deployments for EC2 Auto Scaling groups build a separate replacement fleet and move traffic to it only after the deployment succeeds. The original fleet stays available for a rollback window before it is terminated, which turns a rollback into a traffic change. In-place updates, hand-built fleets and instance refreshes each miss part of this.
Want more on CodeDeploy on EC2 and on-premises (agent, AppSpec, hooks)? The 5 full-length practice sets have 9 more CodeDeploy on EC2 and on-premises (agent, AppSpec, hooks) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study CodeDeploy on EC2 and on-premises (agent, AppSpec, hooks)