Configuration Management and IaC practice questions

The parent stack was created without the '--capabilities' parameter, so it cannot roll back.

Why wrong: The '--capabilities' parameter is for acknowledging IAM capabilities, not for rollback behavior.

The nested stack failure automatically triggers a rollback of the parent stack, but the rollback also failed.

Why wrong: The default update behavior is to continue on failure, not to automatically trigger a rollback.

The parent stack is configured with 'OnFailure' set to 'DO_NOTHING'. Change it to 'DELETE'.

Why wrong: 'OnFailure' is a creation-only parameter, and 'DO_NOTHING' is not a valid setting. For update failures, the default is to continue.

Store the secret ARN in a Terraform variable and use 'var.secret_arn' in the resource.

Why wrong: Storing the ARN in a Terraform variable only provides the resource identifier, not the secret value itself, so the configuration cannot use the actual secret without an additional retrieval step. Furthermore, this approach does nothing to prevent the secret value from ending up in terraform.tfstate, because the value would still need to be placed in a resource attribute or provisioner. The ARN is non-sensitive, but the secret payload remains unaddressed, making this solution incomplete and unsafe.

Store the secret in AWS Systems Manager Parameter Store and reference it using 'data.aws_ssm_parameter'.

Why wrong: Referencing a parameter from Systems Manager Parameter Store via data.aws_ssm_parameter retrieves the value, but the returned secret is still stored in the Terraform state as plaintext when consumed by a resource. This also introduces a redundant migration of secrets from AWS Secrets Manager to Parameter Store, increasing operational complexity without solving the underlying exposure. Unlike a data source from Secrets Manager, this pattern does not inherently use sensitive output handling, so the value can appear in logs or state.

Pass the secret as an environment variable to Terraform and reference it with 'var.secret_value'.

Why wrong: Passing the secret as an environment variable and referencing it as var.secret_value causes the resolved value to be embedded in the Terraform state as an attribute of any resource that uses it, exposing the secret in the state file. Environment variables are not automatically redacted; they can also be visible in process lists, CI/CD logs, or debugging output, making this an insecure approach. The secret is not encrypted at rest in the configuration and lacks the auditability and native integration of AWS Secrets Manager.

Use the CodePipeline console to enable 'Automatic rollback' for the Deploy stage.

Why wrong: The CodePipeline console does not expose an 'Automatic rollback' toggle for a Deploy stage; pipeline stages only support manual or automatic transitions, which either pause execution or allow it to proceed, not rollback of prior actions. A failed pipeline action stops the execution and marks the stage as failed, but CodePipeline itself does not revert deployed resources—it simply halts. The only way to achieve rollback is to configure the underlying deployment action, such as the CloudFormation action, to trigger a rollback on failure.

Set the stack's 'DisableRollback' parameter to 'true' in the template.

Why wrong: Setting the CloudFormation stack's 'DisableRollback' parameter to 'true' explicitly instructs CloudFormation to leave the stack in a failed state (e.g., CREATE_FAILED or UPDATE_ROLLBACK_FAILED) instead of performing a rollback. This is the opposite of the desired behavior: it prevents automatic recovery from a failed update and can leave the stack partially updated or unusable. Rollback on failure requires the opposite setting—'DisableRollback' must be false or the parameter omitted—so this option is categorically wrong.

Add a stack policy to the CloudFormation stack that denies updates to the AMI parameter.

Why wrong: A CloudFormation stack policy is a JSON document that defines which resources or Update actions are allowed or denied during stack updates. While it can protect the AMI parameter from being changed unintentionally, it does not initiate or influence rollback behavior when a deployment fails. The policy purely acts as an access control mechanism, not a failure-handling mechanism, so it would neither trigger a rollback nor restore the stack to a prior healthy state; it only prevents certain updates from being applied.

Traffic splitting.

Why wrong: Traffic splitting is a canary deployment strategy that routes a small percentage of live traffic to the new application version while the majority remains on the old version. It is not an immutable deployment because both versions coexist within the same Elastic Beanstalk environment, and a failed rollout requires traffic re-routing rather than a clean environment swap. This offers less isolation than immutable updates and can still expose a subset of users to issues.

All at once.

Why wrong: All at once replaces every running instance with the new application version simultaneously, with no staged rollout or minimal batch size. If the new version fails health checks, all instances are already affected, causing a full outage until a manual rollback is initiated. This offers no ability to validate a subset of instances before exposing the entire environment, resulting in the highest risk of downtime.

Rolling update based on health.

Why wrong: Rolling update based on health deploys the new version in batches across existing instances, waiting for each batch to pass health checks before proceeding. However, this approach does not launch a fully separate environment, so a bad version can incrementally replace healthy instances and progressively degrade capacity if the health checks are insufficiently sensitive. Rollback is also a slow reverse rolling process, making it less atomic and more time-consuming than an immutable update.

AllocatedStorage

Why wrong: AllocatedStorage is required for some engines, but it is not universally mandatory. For Amazon Aurora, storage automatically scales and AllocatedStorage cannot even be specified on the instance; it is managed by the cluster. Additionally, when restoring a DB instance from a snapshot, you omit this property. Thus, while often needed, it does not qualify as a required property for all DB instance resources.

DBInstanceIdentifier

Why wrong: DBInstanceIdentifier is an optional property because it is simply a user-defined name for the instance. If you omit it, CloudFormation or RDS will automatically generate a unique identifier. Whether or not you provide it has no bearing on the instance's configuration or provisioning, so it is not a required property. This eliminates it as the correct answer.

MasterUsername and MasterUserPassword

Why wrong: MasterUsername and MasterUserPassword are required only when provisioning a brand-new DB instance directly. In Aurora, master credentials belong to the preceding DBCluster resource, so the instance resource does not require them; similarly, when restoring from a snapshot, the existing user accounts carry over, making these properties unnecessary. Since the question asks for a property that is always required, this conditionally required pair is incorrect, unlike DBInstanceClass and Engine.

Configure CodeDeploy to set up the build environment before the build starts.

Why wrong: AWS CodeDeploy is a deployment automation service that orchestrates application revisions onto EC2 instances, Lambda functions, or on-premises servers through lifecycle hooks (e.g., BeforeInstall, AfterInstall). It does not provision build environments, select runtimes, or execute compilation steps—those are CodeBuild's domain. Using CodeDeploy to set up a build environment before a build starts conflates the deployment phase with the build phase, and it lacks the ability to define runtime versions or environment variables in a buildspec-like manner.

Use an Elastic Beanstalk environment to run the build.

Why wrong: Elastic Beanstalk is a PaaS for deploying web applications, automatically managing EC2 instances, load balancing, and auto scaling for long-running services. It is not a CI execution platform: its environment is persistent and optimized for serving requests, not for running ephemeral, isolated build jobs with distinct toolchain versions. Choosing it to run builds would require provisioning an always-on infrastructure and manually managing build state—something CodeBuild already handles with on-demand Docker containers.

Use an AWS CloudFormation template to specify the build environment configuration.

Why wrong: CloudFormation is an infrastructure-as-code service that instantiates AWS resources; a template can define a CodeBuild project (`AWS::CodeBuild::Project`), but it does not itself define the build environment's runtime commands or variables. Those live in the buildspec or in the project's environment configuration, which you could set via inline code in the template. Relying on CloudFormation as the build environment definition misunderstands its role—it orchestrates resource creation, not the technical contents of a build job.

Run 'aws cloudformation update-stack' again with the original template to revert the changes.

Why wrong: CloudFormation rejects any update-stack request while the stack is in the UPDATE_ROLLBACK_FAILED state, so resubmitting the original template will not be accepted. The stack must first move to a stable state such as UPDATE_ROLLBACK_COMPLETE via continue-update-rollback, or be deleted. Since the original template only reverses the parameter change, it does not address the underlying failure that caused the rollback to fail, making it an invalid recovery action.

Revert the parameter value manually in the RDS console and then resume the rollback.

Why wrong: Manually changing the RDS parameter value in the console may fix the database's runtime behavior, but CloudFormation's stack state is still marked as UPDATE_ROLLBACK_FAILED because the stack's template and record of the last update were not changed. Attempting to resume the rollback after the manual fix is unsupported and may cause the rollback to re-attempt the same failing resource. The correct approach is to use continue-update-rollback with resources-to-skip, which gives CloudFormation an explicit way to bypass the problematic resource without requiring manual, out-of-band modifications.

Delete the stack and recreate it with the updated template.

Why wrong: Deleting the stack and recreating it is a highly disruptive action that can result in data loss for the Multi-AZ DB instance, especially if you haven't configured DeletionPolicy or a final DB snapshot; CloudFormation's default deletion behavior removes the database. It also ignores the stack's existing state and forces a full rebuild, increasing downtime significantly. Even in a production incident, this is a last resort, not a recommended recovery from UPDATE_ROLLBACK_FAILED, because CloudFormation provides a non-destructive recovery path.

Define a separate 'AWS::RDS::DBSubnetGroup' resource with subnets from at least two Availability Zones.

Why wrong: While a DB subnet group spanning at least two AZs is a prerequisite for RDS Multi-AZ, simply creating the subnet group does not make the DB instance highly available. The instance will remain single-AZ unless the DBInstance's MultiAZ property is set to true (or the engine defaults to Multi-AZ). This option confuses a networking prerequisite with the actual failover configuration.

Deploy the database with multiple read replicas in different Availability Zones.

Why wrong: Read replicas are asynchronous copies used to offload read traffic; they do not provide automatic failover for the primary DB instance. If the primary fails, a read replica must be manually promoted, which incurs downtime and data loss risk. Multi-AZ uses synchronous physical replication to a standby in another AZ, enabling automatic failover without application changes. Thus replicas alone do not satisfy the Multi-AZ requirement.

Configure the database to use a DB subnet group with subnets in a single Availability Zone.

Why wrong: A subnet group confined to a single Availability Zone cannot host a standby in a different AZ, so RDS Multi-AZ cannot be enabled. The DBInstance would be single-AZ and vulnerable to AZ-level failures. Multi-AZ requires a subnet group with subnets in at least two AZs; a single-AZ subnet group is fundamentally incompatible with the failover architecture.

The subnet ID in the template is already used by another stack in the same account.

Why wrong: The subnet ID already being in use by another stack is not a valid cause for this error. AWS allows multiple stacks to reference the same subnet ID; there is no global uniqueness constraint that would block a CloudFormation update. The error message clearly refers to an authorization failure (ec2:DescribeSubnets), not a resource conflict like 'Subnet already used'.

The subnet specified in the template does not exist in the selected AWS region.

Why wrong: If a subnet did not exist, CloudFormation would return a validation error such as 'Subnet ID not found' or a resource-not-found message, not an authorization error. The error shown is an explicit AccessDenied, indicating the configuration exists but the caller lacks permission to describe it. This points to an IAM policy issue rather than a nonexistent resource.

The CloudFormation template has a syntax error in the subnet definition.

Why wrong: A syntax error in the template would be detected during template parsing before any IAM authorization checks occur. CloudFormation would respond with a validation error describing the syntax line, not an AccessDenied from ec2:DescribeSubnets. Since the error is a permission failure from the IAM role, the template syntax is not the cause.

Create pipeline, then create S3 bucket, then create CodeCommit repository and push code, then configure source, then configure deploy.

Why wrong: Creating the pipeline before the S3 artifact bucket is invalid because AWS CodePipeline requires an artifact store to be specified and verified at pipeline creation time; without an existing S3 bucket, creation fails. Additionally, the CodeCommit repository must exist and contain code before you configure the source stage, so placing repository creation after pipeline creation is acceptable only if done before source configuration, but the order shown delays it incorrectly. The pipeline creation step itself will error out, making the rest of the sequence unreachable.

Configure source, then configure deploy, then create S3 bucket, then create CodeCommit repository and push code, then create pipeline.

Why wrong: You cannot configure source or deploy stages before a pipeline exists because stage definitions are properties of an existing CodePipeline resource; attempting to configure them first is impossible. Furthermore, creating the pipeline requires the S3 artifact bucket to already be in place, and the CodeCommit repository must be available as a source provider, so both prerequisites must precede pipeline creation. Reversing the order ignores these hard dependencies, and the deploy stage would have no artifact to deploy from a non-existent source.

Create CodeCommit repository and push code, then create S3 bucket, then create pipeline, then configure deploy, then configure source.

Why wrong: This is incorrect because the source stage should be configured before the deploy stage, as the deploy stage depends on artifacts from the source stage. Additionally, the pipeline must be created before configuring its stages.

Create the Lambda function, then create the S3 bucket, then add an S3 trigger to the Lambda function, then configure the S3 bucket event notification, then test.

Why wrong: This is incorrect because the S3 bucket must be created before the Lambda function can be triggered by it. While the function can be created first, the bucket and trigger order is reversed; the trigger cannot be added until the bucket exists.

Create the S3 bucket, then create the Lambda function, then configure the S3 bucket event notification, then add an S3 trigger to the Lambda function, then test.

Why wrong: This is incorrect because if you configure the S3 bucket event notification before adding the trigger to the Lambda function, the notification will have no target Lambda function to invoke. The trigger must be added first to create the permissions and association.

Create the S3 bucket, then add an S3 trigger to the Lambda function (but the function doesn't exist yet), then create the Lambda function, then configure the S3 bucket event notification, then test.

Why wrong: Placing the S3 trigger creation before the Lambda function exists is invalid because the Lambda service cannot attach an event source mapping or S3 bucket notification to a function that has no ARN. The 'Add trigger' API call (e.g., AddPermission and the S3 PutBucketNotificationConfiguration operation) requires the target function to already exist, or it fails with a ResourceNotFoundException. Moreover, the S3 bucket itself must also exist before the trigger can be configured, but in this sequence the bucket is created first, so the fatal flaw is specifically the nonexistent Lambda function.

Hardcode a different stack name for each branch in the pipeline.

Why wrong: Hardcoding a different stack name for each branch in the pipeline definition requires manual code changes whenever a branch is added or renamed, making the process unscalable and error-prone. It also defeats the purpose of a multi-branch strategy because the pipeline cannot dynamically adapt to branch creation without human intervention, increasing the risk of misconfiguration and inconsistent deployments.

Delete the existing stack before each deployment.

Why wrong: Deleting the existing CloudFormation stack before every deployment creates a window of downtime and, if the stack deletion fails (e.g., due to non-empty S3 buckets or retained resources) or the subsequent creation fails, you are left with no running infrastructure. CloudFormation updates are designed to apply changes in-place, preserving the stack and its outputs; a delete-before-create approach also loses stack history and makes rollback impossible.

Use the CloudFormation 'Override' parameter to reuse the same stack.

Why wrong: CloudFormation does not support an 'Override' parameter for stack names—the stack name is a fixed identifier set when the stack is created, and the CodePipeline CloudFormation 'Override' action only overrides template parameter values, not the stack name itself. Even if you could override parameters, reusing the same stack for multiple branches would cause them to overwrite each other's resources, leading to unintended shared state and deployment conflicts.

Store the state file locally and commit it to version control.

Why wrong: Storing state locally couples the state file to a single developer's machine and provides no locking, so concurrent `terraform apply` commands can overwrite the same state file and produce corruption or lost updates. Committing the state file to version control also leaks sensitive data such as resource attributes, connection strings, and outputs, and it bypasses Terraform's remote state locking mechanisms. This is therefore a recognized anti-pattern for team-based infrastructure.

Use S3 server-side encryption to protect the state file.

Why wrong: S3 server-side encryption (SSE-S3, SSE-KMS, or SSE-C) only encrypts the state file at rest and in transit, protecting the confidentiality of any secrets stored in the state. It does not add any integrity validation, atomicity, or concurrency control; a corrupted or partially written state file is still indistinguishable from a valid one, and encryption provides no defense against concurrent writers.

Enable S3 versioning on the state bucket to recover previous versions.

Why wrong: Versioning stores previous versions of the state object after overwrites, allowing operators to manually roll back if corruption is discovered. However, it does not prevent the corruption itself—concurrent Terraform runs can still interleave writes, and versioning does not enforce locking. In fact, versioning can hide the problem by silently preserving multiple divergent states, making it harder to determine which version is authoritative.

Use a Lambda function alias and point the custom resource to the alias.

Why wrong: AWS CloudFormation custom resources (including Lambda-backed) invoke a provider via the `ServiceToken` property, which must be a Lambda function ARN or version ARN; CloudFormation does not support pointing this token to an alias. Aliases are only used to manage versioned invocations, but the custom resource will still call the original function code captured at creation/update time. Therefore changing your Lambda code via an alias does not trigger a CloudFormation update of the custom resource, so existing stack instances would remain unchanged.

Create a new stack set for the updated Lambda and delete the old one.

Why wrong: Creating a brand-new StackSet for the updated Lambda and deleting the old StackSet would force you to create and then remove stack instances across every target account and Region, causing downtime and breaking the CloudFormation-managed identity of the stacks. StackSets natively support in-place template updates, so the old StackSet can be updated directly to the new template version, which lets CloudFormation perform rolling updates and rollback across all member stacks. The delete-and-recreate approach also risks orphaned resources and is an anti-pattern compared to a simple template update.

Manually update the Lambda function in each account, then update the stack set.

Why wrong: Manually updating Lambda functions account-by-account and then updating the StackSet is incorrect because CloudFormation treats the registered template as the source of truth, and the StackSet update will overwrite any manual changes to the Lambda resource in the stack instances. This manual approach is not scalable across a large multi-account environment and is highly error-prone, with no drift detection or rollback safety. The proper fix is to edit the StackSet template once and let CloudFormation automatically push the new Lambda code to all managed stacks.

AWS CodeStar

Why wrong: AWS CodeStar is not an execution service for CI/CD but rather a project management and development dashboard that aggregates issues, code, team collaboration, and a unified view of your software project. Although CodeStar can scaffold an entire pipeline for you by creating CodeCommit, CodeBuild, and CodeDeploy resources behind the scenes, it itself does not run builds or tests and cannot be inserted as a stage or action inside CodePipeline. The pipeline itself operates through the underlying CodePipeline service, not through CodeStar. Therefore, it cannot serve as the component that runs unit tests or fails the pipeline based on test results.

AWS Lambda

Why wrong: Lambda lacks native integration with CodePipeline’s stage-level failure and success branching logic; it cannot directly halt the pipeline or conditionally trigger a deployment based on test results without custom orchestration code. It is tempting because Lambda can execute arbitrary code for testing or notifications, and would be correct for a custom post-pipeline action, such as invoking a third-party notification service after a pipeline stage completes, but not for controlling pipeline flow itself.

AWS CodeDeploy

Why wrong: AWS CodeDeploy is a deployment automation service that handles rolling out application revisions to targets such as EC2 instances, Lambda functions, or Amazon ECS services. It has no mechanism for running unit tests, evaluating test failures, or acting as a pre-deployment quality gate. In a typical CodePipeline, CodeDeploy is used as a deploy action in a later stage, after the build and test stage has completed successfully. Trying to use CodeDeploy for unit testing would require offloading test execution to a separate service or script, which is neither its design nor a native pipeline action, making it an incorrect choice for this requirement.

Use AWS Config rules to detect non-compliance and send notifications.

Why wrong: AWS Config rules are fundamentally a detection mechanism: they evaluate resource configurations against rules and record compliance state, but without a configured remediation action (like an SSM Automation document) they only emit SNS notifications. They do not actively fix non-compliant settings on the client, so drift persists until some other process intervenes. Chef, by contrast, makes remediation a first-class operation during every convergence run.

Use AWS CloudWatch Events to trigger a Lambda function that runs remediation scripts.

Why wrong: A CloudWatch Events-triggered Lambda remediation loop is an external, event-driven workaround: it forces you to author and maintain custom Lambda code, IAM permissions, and error handling, and it only fires when a matching event occurs, leaving gaps between evaluations. It is also asynchronous, so there is no guarantee that remediation completes before the next audit. Chef's agent on each client continuously checks and enforces the desired state, making periodic drift correction unnecessary.

Use AWS Systems Manager Patch Manager to apply patches.

Why wrong: AWS Systems Manager Patch Manager only addresses OS patch compliance against a defined patch baseline; it does not manage configuration compliance for settings such as file permissions, cryptographic settings, user accounts, or CIS benchmarks. Patch compliance is a narrow subset of overall security compliance. Chef recipes, on the other hand, declare the full desired system state, so patching and every other compliance control are handled consistently during each client run.

Manually update the environment configuration through the Elastic Beanstalk console.

Why wrong: Making changes directly through the Elastic Beanstalk console is quick and convenient, but the console does not create a versioned snapshot of the configuration. The previous settings are overwritten and cannot be recovered from the environment itself, so a rollback requires manually reconstructing the old values from memory or external notes. This approach is error-prone, lacks auditability, and does not support repeatable or traceable configuration management.

Use the AWS CLI to apply configuration changes from a script.

Why wrong: The AWS CLI can apply configuration changes via commands like `eb setenv` or `aws elasticbeanstalk update-environment`, and you could store those commands in a script. However, the script is not automatically version-controlled unless you actively manage it with Git or similar, and running the commands mutates the live environment configuration without creating a restore point. To roll back, you must write and maintain custom logic to reapply a previous set of values, unlike saved configurations which are native, first-class versionable artifacts.

Use AWS CloudFormation to manage the Elastic Beanstalk environment.

Why wrong: CloudFormation manages the provisioning and lifecycle of the Elastic Beanstalk environment *itself* as an infrastructure stack, not the rapid, granular versioning and rollback of *runtime environment configuration changes* within an existing Beanstalk environment. Updating minor settings via CloudFormation involves a stack update, which is less agile for quick configuration rollbacks than Elastic Beanstalk's native mechanisms. CloudFormation is ideal for defining the initial environment infrastructure consistently and managing its overall lifecycle as code.

Use CloudFormation StackSets with approval tokens.

Why wrong: StackSets are designed to deploy and update identical CloudFormation templates across multiple AWS accounts and Regions, not to gate an individual stack update in a single workflow. They have no concept of approval tokens; operation execution is authorized through standard IAM roles and optional SCPs, with no manual-approval hook in the StackSets execution model. Therefore, StackSets cannot provide the required pre-update human sign-off.

Use CloudFormation Change Sets and require a separate user to execute them.

Why wrong: Change Sets give a read-only preview of the resources that will be added, modified, or deleted before you execute the change set, but CloudFormation does not require—or even track—who executes it. Any IAM principal with the cloudformation:ExecuteChangeSet permission can run it, and there is no native mechanism to mandate that the executing user differ from the change set creator. To enforce a 'separate user' you would need to augment Change Sets with a custom workflow, such as SCPs, Lambda-backed policy checks, or an external approval step.

Use AWS Service Catalog to manage CloudFormation templates and require approval for product launches.

Why wrong: Service Catalog is aimed at end-user self-service provisioning of approved CloudFormation products, typically with an approval workflow for portfolio launches. However, it does not manage updates to an existing stack that was created outside Service Catalog, nor does it gate the execution of an arbitrary CloudFormation template in a CI/CD pipeline. Although you could wrap a template as a product, Service Catalog cannot act as an approval stop for an ongoing stack update triggered by a infrastructure deployment.

Use AWS Config rules to detect non-compliance.

Why wrong: AWS Config rules are detective, not corrective: they continuously evaluate resources against compliance policies and report whether a resource is non-compliant, but they do not modify the instance. To actually enforce a firewall rule, you would need to pair Config with remediation actions or Systems Manager automation, which is indirect and not the primary desired-state enforcement tool. Therefore, Config alone is insufficient for the stated requirement of ensuring the firewall rule stays applied.

Use Run Command to execute the configuration once.

Why wrong: Run Command executes a document or command once on target instances, making it ideal for immediate, one-off tasks like rebooting or ad-hoc patching. After the execution finishes, Systems Manager keeps no ongoing state guarantee, so if the firewall rule is later disabled or altered, nothing will reapply it. Even scheduling Run Command through CloudWatch Events or Maintenance Windows still results in independent fire-and-forget executions rather than a stateful association that tracks and enforces desired state.

Store artifacts in an AWS CodeCommit repository.

Why wrong: CodeCommit is for source code, not artifacts.

Enable versioning on the S3 bucket to keep all versions.

Why wrong: Versioning retains all versions, not just the latest.

Use CloudWatch Logs to store build logs.

Why wrong: Logs are not artifacts.