Troubleshooting failed deployments and stacks: DOP-C02 study notes and practice questions
What to know about Troubleshooting failed deployments and stacks for the DOP-C02 exam, from the Incident and Event Response domain (14% of the exam guide), then 3 free questions to test it. Part of the DOP-C02 study guide.
An online retailer uses CodeDeploy to roll out its order service to a fleet of EC2 instances. The latest deployment failed on a few instances, and the console reports that the AfterInstall lifecycle event failed with a script exit code.
The release is blocked, and the team needs to find the failing command on the affected instances, fix it and get the service running the new version on every instance. The team also needs to keep the instances that succeeded in a consistent state.
The operations team wants the fix to go through the normal deployment path, not manual changes on the servers.
Which TWO actions meet these requirements? (Choose two.)
Choose two answers.
AA. Open the deployment's instance details to see which lifecycle event failed on each instance, then read the script and CodeDeploy agent logs on one affected instance.
BB. Increase the timeout of the AfterInstall hook to one hour and redeploy, on the theory that the script is only slow to finish on some instances.
CC. Remove the AfterInstall hook from the AppSpec file, so that deployments skip the failing script, and deploy the new version to every instance.
DD. Correct the failing command in the revision, publish the new revision, and deploy it to the whole deployment group through the pipeline so that every instance runs the same version.
EE. Log in to each failed instance, run the failing command by hand, and then mark the deployment as successful in the console so that the pipeline can continue.
Show the answer and explanation
Answers: A, D
A. Right: Correct. The deployment's instance records show which lifecycle event failed, and the agent and script logs on the instance show the failing command and its exit code. This points the team to the cause before it changes anything. Learn more: Troubleshooting CodeDeploy (opens in a new tab)
C. Wrong: Skipping the hook removes a step the service depends on, such as configuration setup, so the new version may not run correctly. This is a workaround, not a fix. Learn more: AppSpec file structure (opens in a new tab)
E. Wrong: Manual changes on the servers take the fix outside the deployment path and leave the instances in an inconsistent state. The console does not allow a deployment to be marked successful by hand in this way.
Explanation
The deployment's instance records and the agent and script logs on an affected instance show which lifecycle event failed and why. A corrected revision deployed to the whole group through the normal path fixes the cause and keeps every instance on one version. Longer timeouts, removing the hook and manual changes each leave the cause in place or bypass the process.
A SaaS startup runs its billing API as an Amazon ECS service on AWS Fargate. After a new task definition was registered, the service's deployment stopped at 50 percent, and new tasks show as STOPPED within seconds of starting.
The stopped tasks report a ResourceInitializationError that says the task could not retrieve a secret from AWS Secrets Manager. The secret is referenced in the container definition and was created last week by the platform team.
The team needs the service to reach its desired count again with the same task definition, without changing the application code and without reducing security.
Which action should the team take?
Choose one answer.
AA. Increase the task's CPU and memory, since a resource initialization error usually means the task does not have enough capacity to start its containers.
BB. Add the secretsmanager:GetSecretValue permission for the secret to the task execution role, which is the role ECS uses to start the task and retrieve the secret for the container.
CC. Change the deployment type to a rolling update with a minimum healthy percent of zero, so that the service replaces all tasks at once with the new definition.
DD. Delete the ECS service and create it again with the same task definition, so that the service's deployment state is reset before the next attempt.
Show the answer and explanation
Answer: B
A. Wrong: Resource initialization errors for secrets are not caused by capacity. More CPU and memory would not let the task read the secret.
B. Right: Correct. Fargate uses the task execution role to retrieve secrets for the container at startup, so that role must allow reading the secret. Adding that permission lets the new tasks start and the deployment finish. Learn more: Amazon ECS task execution IAM role (opens in a new tab)
D. Wrong: Recreating the service does not change the execution role, so the tasks would fail to start again. It also causes an outage while the service is rebuilt.
Explanation
A ResourceInitializationError for a secret on Fargate points to the task execution role, which ECS uses to fetch secrets at startup. Granting that role permission to read the secret lets the new tasks start, and the deployment finishes with the same task definition. Capacity changes, deployment settings and recreating the service do not change the permission.
A logistics company updated an AWS CloudFormation stack that contains a Lambda function and an Application Load Balancer. The update also added an Amazon S3 bucket for shipping label images, and the application wrote labels to it before a later resource failed and CloudFormation began to roll back.
The rollback is now stuck in UPDATE_ROLLBACK_FAILED. The stack events show that the new bucket could not be deleted because it still holds objects. The bucket holds only label images that the application can regenerate on demand.
The team needs the stack to return to a stable, updatable state, and it does not want to delete the stack or its other resources.
Which action meets these requirements?
Choose one answer.
AA. Delete the stack with all of its resources, and then recreate it from the last working version of the template.
BB. Empty the bucket, and then run ContinueUpdateRollback on the stack so that the rollback finishes and the stack returns to UPDATE_ROLLBACK_COMPLETE.
CC. Edit the template to remove the bucket resource, and start a new update, so that CloudFormation skips the deletion and the rollback completes.
DD. Attach a stack policy that allows the Update:Delete action on the bucket, and retry the rollback, so that CloudFormation can remove the bucket together with its objects.
Show the answer and explanation
Answer: B
A. Wrong: Deleting the stack removes the load balancer and the function as well as the bucket, which the team wanted to keep. Recreating from the template is a larger change than the situation needs.
B. Right: Correct. CloudFormation can finish a stuck rollback once the resource that blocked it is cleared, and emptying the bucket removes the objects that prevented its deletion. The stack keeps its other resources and can be updated again. Learn more: Continue rolling back an update (opens in a new tab)
C. Wrong: A new update cannot run while the stack is in UPDATE_ROLLBACK_FAILED, and a template change does not remove the blocking objects. The team would still have a stack stuck in a failed state. Learn more: Continue rolling back an update (opens in a new tab)
A stack in UPDATE_ROLLBACK_FAILED needs the resource that blocked the rollback cleared before the rollback can finish. Emptying the bucket of regenerable objects and running ContinueUpdateRollback returns the stack to a stable state while keeping its other resources. Deleting the stack, editing the template and stack policies do not clear the blocker.
Want more on Troubleshooting failed deployments and stacks? The 5 full-length practice sets have 11 more Troubleshooting failed deployments and stacks questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Troubleshooting failed deployments and stacks