Deployment, Provisioning, and Automation practice questions

The target group deregistration delay is too long.

Why wrong: The target group deregistration delay is too long. Deregistration delay controls how long an instance that is being removed from service can continue to handle in-flight requests before it is forcibly closed; it does not affect the health check status of instances during a CodeDeploy deployment. A longer delay would only cause a slight lag before the old instance is detached, but it would not cause new instances to fail their health checks or be considered unhealthy. Therefore, this setting does not contribute to the reported "too many individual instances" failure.

The CodeDeploy agent is not installed on the instances.

Why wrong: The CodeDeploy agent is not installed on the instances. If the agent were missing, the very first instance in the deployment would fail immediately because CodeDeploy could not connect to it, usually with an error like "The overall deployment failed because too many individual instances failed deployment" right away. The scenario describes repeated failures over time, which suggests instances are being replaced and each new one briefly fails—this is more consistent with a health check timing issue rather than a missing agent. Additionally, the problem statement implies the deployments are progressing through the initial steps, which would not happen without a working agent.

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

Why wrong: The deployment group is configured to skip the ELB health check. If the ELB health check is skipped, CodeDeploy would not register instances with the target group or would not monitor their ELB health during deployment, so it would not fail deployments based on health check status. That would eliminate the very problem described (instances being marked unhealthy and replaced), meaning the deployment would likely succeed rather than repeatedly fail. Thus, skipping the ELB health check is not a plausible cause for this error; it would actually prevent the symptom from occurring.

Stack policies

Why wrong: Stack policies are JSON documents attached to a stack that define which resources can be updated or deleted. They act as a safety guardrail to block accidental changes, but they do not show what changes are planned or provide any preview functionality. A stack policy cannot help the team review the impact of a proposed template change, only prevent specific operations from occurring.

Condition functions

Why wrong: Condition functions, such as Fn::If and AWS::CloudFormation::Condition, control whether a resource or property is created based on runtime parameter values. They determine the final template structure during deployment, but they do not generate a diff or preview of the resulting stack changes. Conditions simply influence what gets deployed, not how you review the deployment beforehand.

Custom resources

Why wrong: Custom resources enable you to handle provisioning of non-AWS or custom logical resources by invoking a Lambda function or SNS topic during stack operations. They extend CloudFormation's capabilities to manage external services, but they have no inherent ability to show a preview of changes. The customization occurs at deployment time, not as a review mechanism for stack updates.

CodeDeployDefault.AllAtOnce

Why wrong: CodeDeployDefault.AllAtOnce is an in-place deployment configuration that updates every instance in the fleet simultaneously. This means all instances are taken out of service at the same time, and if the new revision fails health checks, the entire application becomes unavailable, causing downtime. It does not involve provisioning a separate fleet or using load balancer traffic shifting, so it cannot provide zero-downtime deployments.

CodeDeployDefault.OneAtATime

Why wrong: CodeDeployDefault.OneAtATime is an in-place deployment configuration that updates one instance at a time, which limits the blast radius of a failure but does not guarantee zero downtime. Without configuring ALB connection draining or health check grace periods, the load balancer may still route traffic to an instance while its deployment is in progress, causing dropped connections. Additionally, because it uses the original instances rather than a new fleet, there is no automatic rollback capability or traffic shift to a healthy set of instances.

CodeDeployDefault.EC2/OnPremises: BlueGreenDeployment

Why wrong: This is not a valid CodeDeploy deployment configuration name. CodeDeploy deployment configurations such as AllAtOnce, OneAtATime, and HalfAtATime are only used for in-place deployments. For blue/green deployments, you must select the 'blue/green' deployment style when creating the deployment group and then configure traffic shifting using an Application Load Balancer or Network Load Balancer; there is no deployment configuration named 'EC2/OnPremises: BlueGreenDeployment'.

Stack policy

Why wrong: A stack policy is an IAM-style JSON document that defines which resources can be updated or deleted during a stack update. While it provides a safeguard against accidental changes by denying updates to protected resources, it does not offer any mechanism to preview or foresee whether an update would cause replacement. In fact, if you try to update a protected resource, CloudFormation will simply fail the update unless overridden, but it never tells you in advance whether a change is safe or would recreate the resource.

Update with drift detection

Why wrong: Drift detection compares the live configuration of your stack's resources against the expected state defined in the original CloudFormation template. It is designed for post-deployment validation—to detect manual modifications or configuration changes made outside CloudFormation—not as a planning tool. Running drift detection before an update gives you no information about how a proposed template change would affect existing resources, so it cannot help you assess whether the update would cause recreation or in-place modification.

Directly edit the stack template and use the update stack action

Why wrong: Editing the stack template directly and invoking the UpdateStack API action will apply the changes immediately, but CloudFormation executes the update without providing a high-level preview of resource-level impacts. The service will determine on its own whether each resource requires replacement based on the modified properties, but you only see the outcome after the operation starts, not in advance. To preview and avoid accidental resource recreation, you must first create a change set and review its 'Replacement' status before executing the actual update.

Mappings

Why wrong: Mappings are static lookup tables defined in the template: they use Fn::FindInMap to select a value from a fixed set of keys, such as AMI IDs per AWS region. They are evaluated at stack creation/update and cannot be changed by caller-provided input — any change requires editing the template. Therefore, mappings are a configuration lookup mechanism, not a user-input mechanism.

Conditions

Why wrong: Conditions evaluate logical expressions (e.g., using Fn::Equals or Fn::If) to decide whether a resource is created or whether a property is set. They typically test parameter values or other template values, but they do not accept data from the person launching the stack. A condition is a gate, not a parameterization channel; it cannot itself gather environment-specific values.

Outputs

Why wrong: Outputs are the opposite of inputs: they surface values like the ARN of a created resource or a load balancer URL after the stack has been created or updated. These values can be exported and imported by other stacks, but they cannot influence what a user enters during creation or what properties resources get. Thus, outputs are informational and downstream-facing.

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

Why wrong: Stopping a deployment in the CodeDeploy console only aborts the remaining deployment steps; it does not issue any commands to instances that have already received and executed the new revision. Instances that completed the deployment continue running the new, likely flawed application code with no automatic rollback to the prior version. Stopping is useful for halting further propagation, but you must then initiate a rollback or redeploy a known-good revision to repair the affected instances.

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

Why wrong: Adjusting deployment group settings to pause or abort on future failures changes the orchestration behavior, but it does not touch the current running application on instances that already updated. No automatic remediation is triggered by these settings; they only prevent subsequent deployments from proceeding under specified conditions. Manually fixing each affected instance is impractical, inconsistent, and can cause configuration drift, whereas CodeDeploy's rollback automates the redeployment of the previous revision across the entire group with full lifecycle event execution.

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

Why wrong: A deployment configuration controls parameters like traffic shifting speed and minimum healthy host count, not the actual application artifact or script contents. Redeploying the same failing revision with a different configuration merely changes the rollout pattern; it will still execute the same broken code, resulting in the same failure. To recover, the revision must change (or be reverted to the last successful one), so this option does not address the root cause.

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

Why wrong: The NoEcho attribute only masks the parameter value in CloudFormation console output and API calls; it does not encrypt the value, and the plaintext password still resides in your stack template or parameters file. CloudFormation does not provide any secret storage, so the credential is recoverable from the template itself and cannot be rotated. This leaves the database password static and exposed to anyone with read access to the template source.

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 does use AWS KMS encryption and the {{resolve:ssm-secure:password}} dynamic reference works in CloudFormation. However, Parameter Store does not offer native automatic rotation for secrets; you would have to write a custom Lambda function to rotate both the database and the parameter value on a schedule. Without that custom work, the password remains a long-lived static secret, which is why this does not satisfy the rotation requirement.

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

Why wrong: Hardcoding a password in a UserData script is insecure because the script is stored as plaintext in the EC2 instance's user data metadata and can be viewed by any user with ec2:DescribeInstanceAttribute permissions. It also ends up in the launch template or instance details and never supports automatic rotation, so the credential is static and recoverable. This violates security best practices because credentials should never be embedded in instance configuration.

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

Why wrong: An Amazon SNS topic is only a notification channel; it cannot pause a pipeline or serve as an approval gate by itself. In CodePipeline, manual approval requires an action with the category "Approval" added to a stage, and while you may associate an SNS topic with that approval action to alert reviewers, simply adding the SNS topic as a stage does not stop the pipeline or enforce a review. Without the actual Approval action, the pipeline will continue executing past the stage, so this approach fails to meet the requirement.

Use an AWS CloudFormation change set to require manual approval.

Why wrong: An AWS CloudFormation change set lets you review stack changes before execution, but it is not a CodePipeline approval step and does not pause the pipeline automatically. In a CodePipeline deployment, you would still need a separate Approval action before executing a change set; the change set itself merely describes the proposed resources and requires a separate CloudFormation action to execute it. Using change sets alone would require manual intervention outside the pipeline's execution and does not integrate as a built-in approval gate.

Create a separate pipeline for production and trigger it manually.

Why wrong: Creating a second pipeline for production and triggering it manually avoids adding an approval step to the existing pipeline, but it duplicates the entire pipeline configuration and requires manual operation outside of CodePipeline's automated flow. This approach adds operational overhead, increases the risk of configuration drift between pipelines, and does not provide an inline manual approval checkpoint within a single pipeline. The requirement asks for a manual approval step in the pipeline, so this is less efficient and not the correct solution.

AWS CodePipeline with cross-account deployment actions

Why wrong: AWS CodePipeline with cross-account deployment actions is incorrect because it is a CI/CD orchestration service, not a multi-account infrastructure provisioning tool. While CodePipeline can use cross-account actions (such as deploying to an S3 bucket or invoking an AWS Lambda in another account), each cross-account action requires IAM roles in both the pipeline account and the target account, and the pipeline must be explicitly configured with a role assumption per stage. It also lacks the ability to infer target accounts from AWS Organizations OUs like StackSets, so for deploying the exact same template to all member accounts, it requires significant per-account boilerplate and does not scale as cleanly.

AWS CloudFormation cross-stack references

Why wrong: AWS CloudFormation cross-stack references are incorrect because they only work within a single AWS account and a single Region. A cross-stack reference uses an Export from one stack and an Fn::ImportValue in another stack to share resource identifiers like an S3 bucket name or a VPC ID, but these exports cannot be resolved across different accounts or Regions. Therefore, this mechanism cannot deploy infrastructure to multiple member accounts in AWS Organizations.

AWS Service Catalog

Why wrong: AWS Service Catalog is incorrect because it is a governance and catalog service that lets administrators create, approve, and version products (CloudFormation templates), which end users can then provision in their own accounts. It does not automatically deploy or push portfolios and products across all member accounts; instead, it enables self-service provisioning by individual users or accounts that have been granted access. While it can enforce compliance and standardization, the deployment is user-initiated rather than an automatic organization-wide rollout, so it does not meet the requirement of ensuring a template is deployed to every member account.

Mappings

Why wrong: Mappings are static lookup tables embedded directly in the CloudFormation template. They let you define key-value pairs (often by region or environment) and select a value using the Fn::FindInMap intrinsic function, but these values are fixed at template authoring time. When the SysOps administrator needs to specify a different instance type or DB class for each deployment, mappings would require editing the template for every new combination rather than accepting user input at stack creation, making them less flexible than Parameters for reusing the template across environments.

Conditions

Why wrong: Conditions are logical expressions that evaluate to true or false, allowing you to conditionally create resources or assign property values based on parameters, mappings, or other conditions. They can control whether an EC2 instance or RDS DB instance is created at all, but they do not provide a mechanism for the user to directly input values such as the instance type or DB class. In this scenario, you still need a Parameters section to capture the actual values; Conditions alone cannot substitute for those user-supplied inputs.

Outputs

Why wrong: Outputs are used to export information about a stack after it has been successfully created or updated, such as endpoint URLs, resource IDs, or any other attribute that can be referenced by other stacks or displayed in the AWS Management Console. They are populated only after CloudFormation has finished provisioning resources, so they cannot influence or pass values into the stack during creation. Therefore Outputs are completely unsuitable for supplying instance type or DB class choices at deploy time.

Conditions

Why wrong: Conditions are logical expressions that determine whether a specific resource or property is created, based on the values of parameters, mappings, or other conditions. For example, you might create a condition that creates an RDS instance only if the environment type is 'production'. However, conditions only govern existence—they cannot supply or assign a value like an instance type or DB class to a resource. While they can evaluate parameter values, they are not the mechanism for passing variable inputs into the template.

Mappings

Why wrong: Mappings are static lookup tables embedded in the template itself, often used to resolve values like AMI IDs based on region or to map environment names to predefined instance types. Once defined, mappings are fixed and cannot be overridden or populated by the user at stack creation time—they are for hardcoded, deterministic lookups. To use a mapping you call Fn::FindInMap with a top-level key and a second-level key, but this offers no way to accept a per-deployment input value such as a DB class chosen by the caller.

Outputs

Why wrong: Outputs are used to export or display information about a stack after it has been created or updated, such as the endpoint URL of a load balancer or the ID of a resource. They are designed to return data to the caller (or to other stacks via cross-stack references), not to receive input from the caller. Outputs are irrelevant to configuring resource properties like instance types or DB classes because they are the result of a deployment, not an input to it.

Nested stacks

Why wrong: Nested stacks are useful for decomposing a large template into smaller, reusable pieces, but they do not inherently accept environment-specific inputs. Each nested stack still requires its own parameters to receive values from the parent stack, adding extra layers of complexity. For simply passing different instance types and DB classes per environment, a direct parameter on the root template is far simpler and more transparent.

Mappings

Why wrong: Mappings are static lookup tables embedded directly in the template, where keys and values are fixed at authoring time. They cannot accept user-defined input; they only return a preconfigured value based on a key like an AWS region or an environment name. To use a mapping to vary instance type per environment, you would still need a parameter to select the environment key, so mappings cannot replace parameters for accepting external values.

Conditions

Why wrong: Conditions are declarative expressions that determine whether a resource or a resource property is created or set, based on evaluation at stack creation. They act as an on/off switch, not as a value provider; they cannot supply the actual numeric or string value for an instance type or DB class. To choose different values for the same resource across environments, you need parameters, not conditions.

CodeDeployDefault.AllAtOnce

Why wrong: CodeDeployDefault.AllAtOnce is not a canary configuration because it deploys the new revision to every instance in the deployment group at the same time, with no incremental traffic shifting. This means the entire fleet and all user traffic are updated immediately, offering zero opportunity to validate the new version on a small subset. It does not meet the requirement to first shift only 10% of traffic, so it is incorrect.

CodeDeployDefault.HalfAtATime

Why wrong: This configuration updates half of the target instances at a time, then shifts traffic in 50% increments rather than the specified 10% initial canary. After the first half is deployed, 50% of traffic is routed to the new version, which is far too large a blast radius for the stated 10%/5-minute requirement. Because it does not provide a low-risk 10% shard, it fails to match the required deployment behavior.

Custom configuration with 10% and manual approval

Why wrong: While a custom deployment configuration could be created to shift 10% of traffic, that only defines the traffic-shifting pattern; it does not include a 5-minute wait or automatic approval. Adding a manual approval step would require human intervention, which is slower and error-prone, and CodeDeploy has no built-in 'manual approval' in its deployment configurations—you'd need additional automation. Since the predefined Canary10Percent5Minutes already provides the exact 10% shift and 5-minute wait without extra steps, using a custom configuration with manual approval is less efficient and unnecessary.

Use a CloudFormation mapping to map the AMI ID.

Why wrong: A mapping stores key-value pairs as static literals inside the CloudFormation template itself. Although you can select an AMI ID based on a key such as an AWS region or environment, the mapping values are fixed at template authoring time; they cannot call the Systems Manager Parameter Store or read a live parameter value. To use a new AMI ID, you would have to edit the mapping in the template and perform a stack update, which does not meet the 'automatically uses the latest' requirement.

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

Why wrong: Using a custom resource to fetch the AMI ID is insufficient because it typically executes only when the custom resource itself is created, updated, or replaced. A change to the Parameter Store value alone would not automatically trigger the custom resource to re-evaluate and provide the new AMI ID during a subsequent stack update, failing the "automatically uses the latest" requirement. Custom resources are valuable for extending CloudFormation's functionality, such as integrating with unsupported services or performing complex logic and transformations during deployment where native capabilities are lacking.

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

Why wrong: A parameter with a default value is baked into the template, and CloudFormation treats that default as a fixed value unless a different value is supplied at stack creation or update time. Changing the default in the template does not affect an existing stack until you explicitly update the stack with the new parameter value. Because the Parameter Store value is never consulted, the stack will continue using the old AMI ID even after the parameter changes.

AWS CloudFormation and AWS CodeDeploy.

Why wrong: AWS CloudFormation is designed for infrastructure as code—declaratively defining and provisioning AWS resources—not for orchestrating an application build and deployment workflow triggered by source control events. While CodeDeploy handles the actual application deployment, it requires an upstream mechanism like CodePipeline to be invoked on a push; pairing CloudFormation with CodeDeploy omits the build stage and the event-driven source-to-deploy pipeline, so you would still need separate automation to initiate the process.

Amazon EventBridge and AWS Systems Manager.

Why wrong: Amazon EventBridge can capture CodeCommit repository events, but AWS Systems Manager (SSM) is an operational management service for tasks like patching, running commands, and managing parameters; it does not provide a built-in build or application deployment workflow. Even if EventBridge triggered an SSM Automation document, you would have to write custom logic to compile code, create artifacts, and coordinate deployment groups—functionality that CodePipeline and CodeDeploy natively offer, so this combination is neither purpose-built nor efficient for continuous delivery.

AWS CloudTrail and AWS Lambda.

Why wrong: AWS CloudTrail is strictly an API auditing and governance service that logs all actions taken by users and services; it does not deliver or deploy anything, and merely detecting a repository push via CloudTrail would require writing a Lambda function that manually invokes SDK calls to build and deploy. Relying on Lambda for the entire orchestration forces you to reinvent complex CI/CD features such as build caching, deployment group health checks, and automatic rollback—omitting the integrated, maintainable components that CodePipeline, CodeBuild, and CodeDeploy provide out of the box.

Use AWS Secrets Manager and reference the secret using a static reference in the template

Why wrong: While AWS Secrets Manager is a valid service for storing credentials, CloudFormation does not support referencing a secret via a 'static reference' — a static reference would require the literal secret value to be embedded in the template or parameter file, defeating the purpose of a secret store. CloudFormation's native integration requires a dynamic reference in the format {{resolve:secretsmanager:secret-id:SecretString:password}} for Secrets Manager, just as it does for Parameter Store, so specifying a 'static reference' is technically incorrect and insecure.

Define plaintext parameters in the template and mark them as NoEcho

Why wrong: NoEcho only masks the value in CloudFormation console and API responses (such as DescribeStackEvents), but the plaintext parameter value remains literally defined in the template body and is not encrypted at rest. The template may be stored in S3, versioned in a code repository, or shared with others who need access to the template, exposing the secret to anyone who can read that template. NoEcho is not a security boundary and does not use any AWS KMS encryption, unlike dynamic references that resolve secure strings from Parameter Store.

Store the secrets in an encrypted S3 object and reference it via a URL in the template

Why wrong: Referencing an S3 URL provides a path to the data but does not integrate with CloudFormation's native dynamic referencing mechanism for automated secret retrieval. This method requires manual logic within the template to fetch and decrypt the object, whereas AWS Secrets Manager or Parameter Store allow direct integration through intrinsic functions. Storing files in S3 is appropriate for managing large configuration datasets or static assets that require versioned access rather than secure, programmatic credential injection.

All at once

Why wrong: All at once terminates and replaces every existing instance concurrently, leaving the Auto Scaling group with zero in-service instances during the deployment window. This causes complete downtime for the web application, and if the new version fails health checks, you cannot roll back without launching a fresh batch of old-version instances. It is only acceptable for dev/test environments that can tolerate an outage.

Rolling

Why wrong: Rolling updates instances in batches, such as one at a time or a fixed percentage, while leaving old instances serving traffic until each batch is replaced. During each batch, the fleet temporarily runs below desired capacity until the new instances pass health checks, causing a transient reduction in available capacity. Rollback is also difficult because the old configuration is not preserved separately; you must run a reverse rolling deployment to restore the previous version.

Rolling with additional batch

Why wrong: Rolling with additional batch first launches an extra batch of new instances before removing any old instances, so capacity is temporarily increased rather than reduced during the deployment. However, updates are still performed in-place on existing instances in waves, meaning the old and new versions coexist on the same Auto Scaling group with no clean traffic-level separation. If the new version is defective, you still need a multi-step in-place rollback, and the extra capacity can trigger scaling or cost concerns.

AWS CodePipeline with cross-account actions

Why wrong: AWS CodePipeline with cross-account actions can technically deploy stacks into multiple accounts, but it requires the sysops admin to build a separate pipeline stage or action per target account, configure cross-account KMS keys, S3 artifact buckets, and IAM roles, and manually maintain the account list. Unlike StackSets, it does not dynamically discover or target accounts via AWS Organizations OUs, so every account change triggers pipeline maintenance. This makes it significantly more operationally overhead than a StackSet.

AWS Service Catalog portfolio

Why wrong: AWS Service Catalog portfolio lets administrators create and share approved CloudFormation products that users can provision on demand, but it does not push deployments automatically to every account in an OU. Each target account's users would have to launch the product individually, or the admin would need separate automation to invoke provisioning, which does not guarantee uniform, consistent deployment at scale. The service is designed for governed self-service, not bulk multi-account stack orchestration.

AWS Systems Manager Automation

Why wrong: AWS Systems Manager Automation is designed to run runbooks against individual resources, such as patching an EC2 instance or configuring a single account's resource. Although an Automation runbook could invoke cross-account roles to create stacks, there is no native capability to fan out a CloudFormation template across all accounts and regions in an organization with automatic OU membership tracking. Building that would require custom scripted loops and per-account IAM trust relationships, adding operational complexity and making it a poor fit.

CodeDeployDefault.AllAtOnce

Why wrong: This configuration deploys the new application revision to all instances at once, causing every instance to shift traffic simultaneously with no staged intervals. Since it provides zero incremental canary progression, it cannot satisfy the requirement of shifting 25% of traffic every 10 minutes, nor would it allow a safe rollback before a larger portion of the fleet is exposed.

CodeDeployDefault.OneAtATime

Why wrong: This configuration shifts traffic one instance at a time, but the interval between each shift is fixed at 5 minutes rather than the required 10 minutes. It also defines shifts by instance count rather than percentage, so the actual traffic increment varies based on fleet size (e.g., one out of five is 20%, not 25%), making it impossible to guarantee a 25% step every 10 minutes.

CodeDeployDefault.HalfAtATime

Why wrong: This configuration shifts traffic in only two large increments of 50% each, using a default interval of 5 minutes between them. A 50% step is far too aggressive for the desired 25% gradual rollout, and the 5-minute interval does not match the stipulated 10-minute waiting period, so the health-check feedback and rollback window would be insufficient.

Stack Policies

Why wrong: A stack policy is an IAM-style JSON document attached to a stack that specifies which resources are protected from update or deletion attempts. It enforces write-time authorization by preventing unintentional changes, but it does not generate a list or diff of proposed modifications. Rather than offering a preview, a stack policy simply blocks certain operations on designated resources, so it cannot be used to review changes before they occur.

Resource Signals

Why wrong: Resource signals, typically implemented via cfn-signal and a WaitCondition or CreationPolicy, are used to coordinate the creation or update of resources by indicating whether a given action completed successfully. The stack waits for a specified number of signals before continuing, which helps detect provisioning failures but does not forecast or describe what changes are coming. Their sole purpose is synchronization and validation during execution, not advance preview of proposed actions.

Nested Stacks

Why wrong: Nested stacks let you abstract and reuse common infrastructure patterns by declaring AWS::CloudFormation::Stack resources within a root template, enabling modular template composition. They help manage complexity and avoid duplicated code, but they do not include any inherent capability to preview updates at the parent stack level. While you could manually create change sets on a nested stack, nested stacks themselves provide no mechanism to review proposed changes across the entire stack.