Deployment, Provisioning, and Automation practice questions

The target group deregistration delay is too long.

Why wrong: Incorrect. Deregistration delay affects how long in-flight requests are served, but it does not cause instances to fail the deployment health check.

The CodeDeploy agent is not installed on the instances.

Why wrong: Incorrect. If the agent were missing, the first instance would fail immediately, not 'too many individual instances' over time.

The deployment group is configured to skip the ELB health check.

Why wrong: Incorrect. Skipping the ELB health check would prevent health check failures from impacting the deployment, so this would not cause the error.

Stack policies

Why wrong: Incorrect. Stack policies prevent certain resources from being updated or deleted, but do not provide a preview of changes.

Condition functions

Why wrong: Incorrect. Condition functions allow you to conditionally create resources based on parameters, but do not preview changes.

Custom resources

Why wrong: Incorrect. Custom resources allow you to manage non-AWS resources in CloudFormation, not to preview stack changes.

CodeDeployDefault.AllAtOnce

Why wrong: Incorrect. AllAtOnce updates all instances simultaneously, causing downtime if the new version fails.

CodeDeployDefault.OneAtATime

Why wrong: Incorrect. While it reduces risk, it does not inherently provide zero downtime; the ALB still routes traffic to instances being updated unless connection draining is configured.

CodeDeployDefault.EC2/OnPremises: BlueGreenDeployment

Why wrong: Incorrect. This is not a standard deployment configuration name; CodeDeploy blue/green uses a separate deployment style configuration.

Stack policy

Why wrong: Stack policies are used to prevent specific resources from being updated or deleted during a stack update; they do not help in previewing or avoiding recreation.

Update with drift detection

Why wrong: Drift detection is used to identify differences between the actual resource configuration and the expected CloudFormation template, not for previewing updates.

Directly edit the stack template and use the update stack action

Why wrong: While this is a valid way to update a stack, it does not provide a preview of the changes; you would need to use change sets to see the impact before applying.

Modify the CodeDeploy deployment configuration to use an increased minimum healthy instance count

Why wrong: Increasing the minimum healthy instance count affects how many instances must remain healthy during the deployment, but it does not automatically replace instances that fail the test hook. It may cause the deployment to wait longer but does not trigger replacement.

Modify the Auto Scaling group's health check grace period to a lower value

Why wrong: The grace period defines how long after an instance launches before health checks start. Lowering it could cause earlier evaluation but does not address the fact that the test hook failure is not being detected by the current health check type.

Modify the CodeDeploy deployment to ignore the lifecycle hook failure

Why wrong: Ignoring the lifecycle hook failure would allow the instance to be marked healthy despite failing the test, which contradicts the requirement to replace failed instances. This does not solve the problem of ensuring only healthy instances remain.

Mappings

Why wrong: Mappings define static lookup tables; they do not accept user input at runtime.

Conditions

Why wrong: Conditions determine whether resources are created, not how to parameterize resource properties.

Outputs

Why wrong: Outputs return information about the stack after creation, not input parameters.

Stop the deployment immediately; the instances that have already been updated will revert automatically.

Why wrong: Stopping the deployment halts further changes but does not revert instances already updated.

Edit the deployment group settings to pause deployments after a failure, then manually fix the instances.

Why wrong: Pausing does not revert changes; it only prevents further deployments.

Redeploy the same failing revision but with a different deployment configuration.

Why wrong: Redeploying the same buggy revision will not fix the issue; it will continue to fail.

Add a manual approval action between the source and deploy stages. The development team will manually run the tests on their local machines and then approve the pipeline to proceed.

Why wrong: This approach lacks automation and relies on manual intervention. It also does not run tests in an isolated environment; tests are run locally, which may not match the production environment. It does not guarantee that failed tests will automatically block the pipeline.

Insert a test stage after the source stage with an AWS CloudFormation action that deploys a test stack and runs tests using a custom resource Lambda function.

Why wrong: CloudFormation is not the appropriate service for running code tests. This would be overly complex and not optimized for automated testing. CodeBuild is the native service for build and test actions in CodePipeline.

Add a Lambda function as an action in the pipeline that runs the unit tests. The Lambda function writes the test results to an S3 bucket, and a subsequent approval action checks the results.

Why wrong: Using Lambda for running tests is not recommended because Lambda has execution time limits (15 minutes) and is not designed for complex build/test workflows. CodeBuild is purpose-built for this scenario and provides better isolation, logging, and integration.

Create a change set to review the changes, then execute the change set.

Why wrong: While a change set can be used, it adds extra steps and does not provide any benefit over a direct update for a simple in-place change. It is not the least disruptive method.

Apply a stack policy to the EC2 instance to allow the update, then update the stack.

Why wrong: Stack policies are used to protect resources from unintentional updates, not to apply updates. The stack policy must be removed first, making this approach more complex.

Delete the existing stack and create a new stack with the updated instance type.

Why wrong: Deleting and recreating the stack would cause an outage and is unnecessary when a simple update can be applied in place.

Create a maintenance window with a rate schedule of 30 days and use an AWS-ApplyPatchBaseline document with operation 'Scan' and reboot option 'RebootIfNeeded'.

Why wrong: A rate schedule cannot specify a particular day of the week. The operation 'Scan' only checks for missing patches without installing them.

Create a maintenance window with a cron schedule of cron(0 2 14 * ? *) and use an AWS-RunPatchBaseline document with operation 'Install' and reboot option 'RebootIfNeeded'.

Why wrong: This cron schedule triggers on the 14th day of every month, not the second Tuesday.

Create a maintenance window with a cron schedule of cron(0 2 2 * 2 *) and use an AWS-InstallPatchBaseline document with operation 'Install' and reboot option 'NoReboot'.

Why wrong: The cron expression is invalid; the correct format uses ? for day-of-week and * for month. Also, AWS-InstallPatchBaseline is not a valid SSM document.

Store the password as a plaintext parameter in the CloudFormation template and mark it as NoEcho.

Why wrong: NoEcho hides the password from outputs but does not securely store it; the password is still in the template and not rotated.

Use AWS Systems Manager Parameter Store to store the password as a SecureString and reference it using the dynamic reference {{resolve:ssm-secure:password}} in the template.

Why wrong: Parameter Store SecureString can store the password securely, but it does not support automatic rotation without custom Lambda functions.

Hardcode the password in a userdata script that is passed to the EC2 instances.

Why wrong: Hardcoding passwords is insecure and violates best practices.

Add an approval stage in the pipeline using the Amazon SNS topic as a notification method.

Why wrong: SNS is used for notifications within the approval action, but the approval action itself must be of type 'Approval' in CodePipeline, not just an SNS topic. The action is not an SNS topic.

Use an AWS CloudFormation change set to require manual approval.

Why wrong: CloudFormation change sets allow you to review changes before execution, but they are not integrated into CodePipeline stages as a simple approval step. They require manual execution outside the pipeline.

Create a separate pipeline for production and trigger it manually.

Why wrong: This approach adds complexity and does not implement a manual approval step within the existing pipeline, which is less efficient.

AWS CodePipeline with cross-account deployment actions

Why wrong: CodePipeline can deploy to multiple accounts using cross-account actions, but this requires additional configuration for each account and is not as straightforward or purpose-built as StackSets for deploying the same template to all accounts.

AWS CloudFormation cross-stack references

Why wrong: Cross-stack references allow stacks to share resources within the same account, not across accounts.

AWS Service Catalog

Why wrong: Service Catalog enables organizations to create and manage IT service catalogs and approve products for use, but it does not automatically deploy templates across multiple accounts.

Mappings

Why wrong: Mappings are static; they are good for pre-defined values but require editing the template for new values, which is less flexible than parameters.

Conditions

Why wrong: Conditions allow conditional resource creation but do not provide a way to input different values for instance type or DB class.

Outputs

Why wrong: Outputs are used to retrieve information about the stack after creation; they cannot be used to pass values into the stack.

In-place deployment

Why wrong: In-place updates instances without traffic shifting; it does not allow a gradual traffic shift percentage.

Blue/green deployment with Linear10PercentEvery10Minutes configuration

Why wrong: Linear shifts traffic in equal increments over time, not a single two-step shift with manual approval.

Blue/green deployment with AllAtOnce configuration

Why wrong: This shifts all traffic to the new environment immediately, which does not match the gradual approach required.

Conditions

Why wrong: Conditions control whether resources are created based on conditions (e.g., environment type) but do not allow passing variable values like instance type.

Mappings

Why wrong: Mappings provide static lookup tables (e.g., mapping region to AMI ID). They cannot be used to pass values at stack creation time; they are hardcoded in the template.

Outputs

Why wrong: Outputs are used to return values from a stack (e.g., endpoint URL). They are not inputs.

Nested stacks

Why wrong: Nested stacks allow you to compose templates, but they are not the simplest way to pass environment-specific values; parameters are more direct.

Mappings

Why wrong: Mappings are static lookup tables and cannot be used to accept user-defined values for each environment.

Conditions

Why wrong: Conditions control whether resources are created or not, not the values assigned to resources.

Use AWS Systems Manager Automation to run a PowerShell script on an existing EC2 instance, then manually create an AMI each week.

Why wrong: While Systems Manager Automation can execute scripts, it does not automate the AMI creation process on a schedule; manual steps increase overhead and risk.

Use AWS CodePipeline with CodeBuild to run the PowerShell scripts and create an AMI using the AWS CLI, triggered by a weekly CloudWatch Events schedule.

Why wrong: This approach works but requires building custom CI/CD logic for AMI creation. EC2 Image Builder provides a more integrated and simpler solution with built-in testing and distribution.

Use Amazon EC2 Auto Scaling with a lifecycle hook to run the PowerShell script on instance launch, and schedule a weekly instance refresh.

Why wrong: This does not create a reusable AMI; it installs software each time an instance launches, increasing launch times and not providing a pre-baked AMI for use in other environments.

CodeDeployDefault.AllAtOnce

Why wrong: Deploys to all instances at once, no canary shift.

CodeDeployDefault.HalfAtATime

Why wrong: Deploys to half of the instances at a time, not 10%.

Custom configuration with 10% and manual approval

Why wrong: While possible, a predefined configuration exists, making this less efficient.

Use a CloudFormation mapping to map the AMI ID.

Why wrong: Mappings are static and defined in the template; they cannot reference live parameter store values dynamically.

Use a custom resource to call Systems Manager to retrieve the AMI ID.

Why wrong: While possible, custom resources add complexity and are unnecessary when dynamic references provide a simpler solution.

Use a CloudFormation parameter with a default value that matches the AMI ID.

Why wrong: Parameters are static at stack creation; updates to the default value are not automatically applied unless the stack is updated with the new value.