Configuration Management and IaC practice questions

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

Why it fails: 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 it fails: 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 it fails: '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 it fails: 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 it fails: 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 it fails: 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.

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

Why it fails: 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 it fails: 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 it fails: 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.

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 it fails: 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 it fails: 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 it fails: 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.

UpdatePolicy attribute with AutoScalingRollingUpdate

Why it fails: Correct. The `UpdatePolicy` with `AutoScalingRollingUpdate` allows you to specify parameters that ensure new instances are created and healthy before old ones are terminated, providing create-before-destroy behavior for Auto Scaling groups.

DeletionPolicy attribute set to Retain

Why it fails: Incorrect. The `DeletionPolicy` attribute set to `Retain` preserves the resource when the stack is deleted, not during an update. It does not ensure create-before-destroy.

DependsOn attribute to specify creation order

Why it fails: DependsOn only sequences resource creation; it cannot defer a replacement until the new resource is created and tested. Creation policies and update policies govern replacement timing. DependsOn suits enforcing explicit ordering between independent resources, not validating a replacement before the old one is deleted.

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

Why it fails: 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 it fails: 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 it fails: 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.

Store artifacts in an AWS CodeCommit repository.

Why it fails: Storing artifacts in CodeCommit fails because the stem requires S3 retention of build outputs, and CodeCommit is a Git source-control service, not an artifact store. It is tempting as a repository for source code and version history, which would suit hosting the pipeline's input, not its compiled output.

Enable versioning on the S3 bucket to keep all versions.

Why it fails: Versioning retains every object version indefinitely, so old successful artifacts accumulate rather than only the latest being kept. It is tempting because versioning protects against overwrites and accidental deletion, and would be correct where rollback to prior artifact revisions is required.

Use CloudWatch Logs to store build logs.

Why it fails: CloudWatch Logs captures build output for troubleshooting; it stores no artifacts, so it cannot control which builds are retained in S3. It is tempting because CodeBuild streams build logs there by default, and it would be correct where the requirement is centralised visibility into build failures.

Add a CloudFormation custom resource to each template that enables versioning and attaches a Lambda function to re-enable it if disabled.

Why it fails: Add a CloudFormation custom resource to each template that enables versioning and attaches a Lambda function to re-enable it if disabled. This approach requires modifying every template and introduces custom logic, making it less operationally efficient and harder to maintain across multiple accounts.

Create a Service Catalog portfolio with a product that enforces versioning and require all users to launch stacks from it.

Why it fails: Create a Service Catalog portfolio with a product that enforces versioning and require all users to launch stacks from it. This approach does not enforce the policy on existing or externally created stacks and requires users to use a specific portal, adding overhead.

Use AWS Config with a managed rule 's3-bucket-versioning-enabled' and an automatic remediation action that enables versioning.

Why it fails: AWS Config with a managed rule and automatic remediation is a detective and reactive approach. It detects non-compliant buckets after creation and then enables versioning, but it does not prevent the violation from occurring. This is less operationally efficient than a preventive SCP.

Use Fn::Select on a predefined list of CIDR blocks passed as a parameter.

Why it fails: While Fn::Select can pick a CIDR from a list passed as a parameter, that approach requires the caller to manually maintain and rotate the list to avoid reuse across stacks. It becomes a static, predetermined selection rather than a dynamic allocation from a pool, so it does not scale or guarantee non-overlap if used independently. Furthermore, CloudFormation parameters have size limits, and managing many CIDR strings as a parameter increases template complexity and operational overhead compared to intrinsic CIDR generation.

Use Fn::GetAtt to retrieve the VPC's CidrBlock from another VPC resource.

Why it fails: Fn::GetAtt retrieves an attribute of another resource, but the VPC's CidrBlock is assigned at creation and cannot be used to generate a new unique CIDR from a pool; this would reference an existing VPC's CIDR, not create a new one.

Use the Ref function to assign the VPC ID as the CIDR block.

Why it fails: Ref on an AWS::EC2::VPC resource returns its physical resource ID, which looks like 'vpc-0123456789abcdef0', not a CIDR range. The CidrBlock property of the VPC must be a valid IPv4 CIDR expression such as '10.0.0.0/16', so using Ref here would cause a template validation or stack creation failure. Additionally, the VPC ID does not exist until after the VPC is created, but the CIDR block is a creation-time input, creating a circular dependency.

Session Manager

Why it fails: Session Manager is incorrect because it provides interactive shell access to instances, not configuration management.

Run Command

Why it fails: Run Command is incorrect because it is used for ad-hoc execution, not persistent state management.

The Deny statement's condition uses StringNotEquals, which does not match the 't2.large' instance type because the condition requires the instance type to be NOT equal to any of the listed types, but 't2.large' is not in the list, so the condition is true, and the Deny should apply. However, the Allow statement without condition allows all, so there is a conflict. Actually, the correct explanation is that the Deny condition is not evaluated correctly because the ec2:InstanceType condition key is not available for the instance resource? I'm not sure. I'll stick with the idea that the Deny condition actually works, so the answer is that the policy is missing a Deny on the image resource to fully block. But since the question says users can launch, I'll choose A.

Why it fails: The Deny condition does correctly match t2.large (since it is not in the list, StringNotEquals is true), so the Deny should apply to the instance resource. However, the issue is that the Deny is not applied to the image resource, not that it is missing or incorrectly evaluated.

The policy should use 'Deny' with 'ec2:InstanceType' in a 'ForAllValues:StringNotEquals' condition.

Why it fails: The condition operator used (StringNotEquals) is appropriate for matching a single value like an instance type. ForAllValues:StringNotEquals is used when the condition key is a set that is compared against a list, but here the ec2:InstanceType is a single value. The issue is not the condition operator but missing resource coverage.

The Allow statement is evaluated after the Deny statement and overrides it.

Why it fails: The Allow statement is evaluated after the Deny statement and overrides it. This is incorrect because IAM evaluates all applicable policies in a single decision: an explicit Deny always overrides every Allow, regardless of the order in which statements appear. AWS IAM uses a hierarchy where an explicit deny is an absolute block, and no Allow statement can supersede it. The evaluation process checks for any explicit Deny first, and if one matches, the request is denied without considering Allow statements.

The IAM role for the Lambda function is missing required permissions.

Why it fails: Missing Lambda permissions would surface as an AccessDenied error during invocation, not as the stack-event failure shown. The exhibit points to the actual resource-level cause. IAM role gaps are the classic culprit when a function cannot call another AWS service, so this is the usual first suspect.

The Lambda function code exceeds the maximum size limit.

Why it fails: Lambda function code exceeding the maximum size limit would produce a different error (e.g., 'Code storage limit exceeded'), not a runtime validation error. The exhibit shows a runtime-related failure.

The S3 bucket containing the template is not accessible.

Why it fails: If the S3 bucket containing the template were inaccessible, the stack update would fail during template retrieval, not during Lambda resource creation. The error here is about the Lambda runtime, not template access.

AWS Lambda traffic shifting using aliases

Why it fails: Lambda aliases inherently support canary deployments through a routing configuration that assigns a percentage of invocation traffic to a new version while keeping the majority on the current version. Updating an alias's routing config via the UpdateAlias API lets you shift traffic gradually—for example, start at 10% new version, then 50%, then 100%—without changing the function's event source or altering any client. This traffic-shifting is a native feature of the Lambda service itself, requiring no additional AWS software, and is the underlying mechanism that more complex tools like CodeDeploy and SAM simply automate.

AWS CloudFormation with UpdatePolicy attribute

Why it fails: The CloudFormation UpdatePolicy attribute applies only to AWS::AutoScaling::AutoScalingGroup resources, enabling rolling updates across EC2 instances; it has no effect on AWS Lambda functions because Lambda invocations are managed by the service itself. Lambda has no native UpdatePolicy equivalent in CloudFormation, so canary traffic shifting for a Lambda function can only be achieved through alias routing configuration (or a tool that creates it, such as CodeDeploy or SAM). The UpdatePolicy attribute cannot reference a Lambda function, making this option fundamentally inapplicable rather than merely unsupported.

AWS SAM with AutoPublishAlias and DeploymentPreference

Why it fails: AWS SAM is a CloudFormation extension—not a standalone service—and its AutoPublishAlias and DeploymentPreference properties are a declarative shorthand that instructs CloudFormation to create an underlying Lambda alias and a CodeDeploy deployment configuration. This introduces an additional orchestration layer and requires the SAM CLI or a transformed template, whereas the question asks for a feature that is natively part of Lambda itself. The actual canary logic still comes from the Lambda alias routing configuration that SAM generates, so SAM is a packaging of the core solution rather than the fundamental mechanism.

Add lifecycle event hooks to stop the deployment if a script fails.

Why it fails: Lifecycle event hooks such as BeforeInstall and AfterInstall execute scripts at defined points during a deployment, and a non-zero exit code will fail that deployment. However, merely adding these hooks does not instruct CodeDeploy to roll back; you would have to embed your own rollback logic within the scripts, such as invoking the CodeDeploy API to redeploy a prior revision. Thus, hooks alone are not a rollback configuration.

Configure a CloudWatch Events rule to trigger a rollback on deployment failure.

Why it fails: A CloudWatch Events (or Amazon EventBridge) rule can match CodeDeploy deployment state-change events, such as DEPLOYMENT_FAILED, and target a Lambda function or Amazon SNS topic. That automation can then programmatically initiate a rollback by calling CodeDeploy APIs, for example creating a new deployment from the last known good revision. This is a supported custom rollback mechanism, because the triggered action is what performs the rollback rather than the event itself.

Configure Amazon CloudWatch alarms on the deployment group.

Why it fails: CodeDeploy deployment groups natively support CloudWatch alarms: you specify one or more alarms in the group, and if an alarm enters the ALARM state during a deployment, CodeDeploy can automatically roll back that deployment to the previous revision. This option is correct because the alarm integration is built into CodeDeploy and directly triggers a rollback, without requiring external scripting. It is a native, declarative rollback trigger.

Associate an Application Load Balancer with the deployment group.

Why it fails: An Application Load Balancer is used in CodeDeploy for traffic shifting and to route traffic to healthy targets; it can be part of a blue/green deployment and can deregister unhealthy instances. However, associating an ALB with the deployment group does not, by itself, create any rollback behavior — it neither triggers a rollback on failure nor redeploys a previous revision. The ALB would only indirectly influence deployment success through health check failures.

The user is denied from launching instances in eu-west-1.

Why it fails: eu-west-1 is in the exception list.

The user is allowed because the policy does not explicitly deny.

Why it fails: The policy denies under condition.

The user is allowed only if they also have an explicit allow policy.

Why it fails: Default allow applies.

The engineer did not have permission to modify the instance type.

Why it fails: The error message explicitly states a validation rule for the InstanceType property, listing the allowed values; a permissions failure would instead produce an IAM error such as 'You are not authorized to perform this operation' and would not detail the set of permitted instance types. CloudFormation checks IAM permissions before attempting to modify resources, so the absence of an access denied response means the engineer's credentials were sufficient for the update.

The AMI ID specified does not support the new instance type.

Why it fails: An AMI-to-instance-type incompatibility is only assessed by EC2 when a launch or modify action is attempted, whereas this error occurs during CloudFormation's template validation, before any API call. The message 'value must be one of' is a schema validation on the literal string in the template, not a runtime compatibility check on the AMI's architecture or virtualization type. Even if the AMI were incompatible, the failure would surface later as an EC2-specific error like 'InvalidParameterValue: The requested instance type is not supported by the AMI.'

The VPC configuration does not support the new instance type.

Why it fails: VPC configuration issues, such as insufficient IP addresses or target group subnet mismatches, would be reported as distinct errors like 'Insufficient IP addresses' or 'Elastic network interface prerequisites,' not as a simple attribute-value enumeration. The InstanceType property is independent of the VPC settings; the stack update failed at the template validation stage, meaning CloudFormation never even attempted to call EC2 to reconsider networking. The allowed-values error proves the value itself was rejected, not that the network stack cannot accommodate the instance.

The bucket name is not unique.

Why it fails: CloudFormation only requires a globally unique S3 bucket name when you explicitly set the BucketName property. Because this template omits BucketName, the service automatically generates a name with a random suffix, guaranteeing global uniqueness. Therefore, the claim that the bucket name is not unique is factually incorrect and is not the security concern.

The bucket does not have server-side encryption enabled.

Why it fails: The absence of an explicit BucketEncryption property does not mean the bucket is unprotected; Amazon S3 now applies SSE-S3 by default to all new buckets and objects. Even if encryption were disabled, that is a data-at-rest issue, whereas the bucket policy that grants public read access exposes data to anyone—encrypted or not. Thus, missing encryption is a hardening opportunity, not the root cause of the vulnerability.

The bucket is not versioned.

Why it fails: The template explicitly sets VersioningConfiguration with Status: Enabled, so the bucket is versioned, making this statement factually wrong. Versioning protects against accidental deletion and overwrite, but it does not control access permissions. A public-read bucket policy still grants anonymous users access to every version of every object, so versioning cannot mitigate the exposure.

Add the recipe to the 'Setup' lifecycle event

Why it fails: The Setup lifecycle event runs only once when an instance is first booted or when it is added to a layer, not on a recurring schedule. It is designed for initial configuration such as installing packages, creating user accounts, or setting up directories. Because it fires only as a one-time event per instance start, it cannot serve as a scheduler for periodic maintenance, and any attempt to use it for such would not repeat at later times.

Add the recipe to the 'Deploy' lifecycle event

Why it fails: The Deploy lifecycle event is triggered exclusively when you deploy an application, for example via an OpsWorks console 'Deploy' action or the `create-deployment` CLI with a `deploy` command. Its recipes are intended for application-specific tasks like syncing code, running migrations, or restarting app services. Since it does not fire on a regular interval, adding a recipe here will only run during actual deployment operations, making it unsuitable for a scheduled maintenance job.

Add the recipe to the 'Configure' lifecycle event

Why it fails: The Configure lifecycle event fires in response to stack topology changes, such as instances being added or removed, load balancer attachments, or layer membership updates. It helps instances update their knowledge of other resources and is often triggered multiple times in bursts during a scaling or update event. This event is not time-based and cannot replicate a cron schedule; a recipe attached here would run unpredictably and only when the environment changes, not at expected periodic intervals.

Manually modify the security group in the EC2 console and then import the resource into CloudFormation.

Why it fails: Manually editing the security group from the EC2 console changes the live configuration without updating the CloudFormation template, which immediately puts the stack into a drift state. Importing the resource into CloudFormation afterwards only brings the resource under management—it does not retroactively modify the template to match the manual change, and the drift persists until you perform a stack update. This approach also violates the infrastructure-as-code principle that all changes should be declared in the template, and it introduces an extra step compared to simply updating the stack directly.

Delete the stack and create a new stack with the updated template.

Why it fails: Deleting the stack removes every resource in the stack—such as the EC2 instance and the security group—and then creating a new stack provisions completely new resources, resulting in significant downtime and potential loss of data or state that is not captured in the template. CloudFormation does not guarantee that the new resources will have the same physical IDs, so any external references (like Elastic IPs or load balancer endpoints) may change. This is a destructive, last-resort option for recovery from corruption, not a routine update path; a direct template update provides a controlled, minimal-difference change without recreation.

Use a change set to review the changes and then execute it.

Why it fails: A change set is a preview mechanism that lists the exact modifications a stack update would make, but it requires two steps: you must first create the change set and then execute it to apply the changes. While this is a recommended best practice for reviewing complex or risky updates before applying them, the question asks for a direct update—meaning submitting the template to CloudFormation and letting it update immediately. In that sense, using a change set is an indirect method because it does not apply the change by itself; the execution step is needed. However, if the requirement is only to update the stack with minimal disruption, both approaches achieve that, but a direct stack update is the simpler action.

Define the agent installation in the layer's built-in configuration.

Why it fails: The built-in configuration of an OpsWorks layer only controls which AWS-managed packages and system services are installed for that layer's type (e.g., Apache for a PHP web layer). It does not provide a hook to run arbitrary commands or install third-party agents, because those built-in parameters map to recognized Chef attributes used by OpsWorks' own setup recipes. Custom actions like installing a monitoring agent require a custom recipe assigned to a lifecycle event.

Use custom JSON to pass the installation commands.

Why it fails: Custom JSON in OpsWorks supplies Chef node attributes to the stack's cookbooks; it is data consumed by recipes, not an execution engine. Passing commands as JSON would only make those strings available as attributes, and unless a recipe explicitly reads them and runs them via `execute`, they have no effect. This option conflates configuration data with imperative action, so it cannot trigger an installation by itself.

Create a cookbook repository and upload the agent installation script.

Why it fails: Creating a cookbook repository and uploading an installation script is only the first step; cookbooks in that repository must be associated with the stack and their recipes must be explicitly assigned to lifecycle events on a layer. Without that assignment, the script remains inert source code—the Chef client never runs it. A repository alone never executes anything; you need a recipe with an `execute` resource and a lifecycle hook to invoke that recipe on instance setup.