Courseiva

CCNA Configuration Management and IaC Questions

37 questions · Configuration Management and IaC · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQhard

A company uses AWS Elastic Beanstalk to deploy a web application. The application requires environment-specific configuration values (database URL, API keys) that must be stored securely and rotated automatically. The team uses AWS Secrets Manager. Which configuration management strategy should the team implement to securely inject secrets into the Elastic Beanstalk environment?

A.Store the secrets in the Elastic Beanstalk environment configuration as plain text under 'aws:elasticbeanstalk:application:environment'.
B.Configure Secrets Manager to automatically push secrets to Elastic Beanstalk environment properties.
C.Use an Elastic Beanstalk platform hook script that retrieves secrets from Secrets Manager and sets them as environment variables.
D.Use AWS CloudFormation dynamic references to inject secrets into the Elastic Beanstalk environment.
AnswerC

An Elastic Beanstalk platform hook, such as a script in the .platform/hooks/postdeploy directory, runs on the instance during deployment and can call the AWS CLI or SDK to retrieve secrets from Secrets Manager using the instance role's IAM permissions. The script can then export the secret values as environment variables into the application runtime context (e.g., by writing to /etc/profile.d or a systemd environment file) before the app starts. This keeps secrets out of the environment configuration and source code, and it supports rotation by re-running the hook on subsequent deployments.

Why this answer

Elastic Beanstalk platform hooks allow custom scripts to run during deployment, enabling retrieval of secrets from AWS Secrets Manager and setting them as environment variables before the application starts. This approach keeps secrets out of the environment configuration and supports automatic rotation by having the script fetch the latest secret value on each deployment.

Exam trap

The trap here is that candidates often assume CloudFormation dynamic references (Option D) are the best fit for automatic rotation, but they only inject secrets at deployment time and do not handle in-place rotation without a stack update, whereas platform hooks can be used to fetch the latest secret on every instance start or deployment.

How to eliminate wrong answers

Option A is wrong because storing secrets as plain text in the Elastic Beanstalk environment configuration under 'aws:elasticbeanstalk:application:environment' exposes them in the environment properties, which can be viewed by anyone with access to the environment configuration and does not support automatic rotation. Option B is wrong because Secrets Manager does not have a native capability to automatically push secrets to Elastic Beanstalk environment properties; it requires an external mechanism (e.g., Lambda, custom script) to retrieve and set them. Option D is wrong because AWS CloudFormation dynamic references can inject secrets at stack creation or update time, but they do not handle automatic rotation of secrets within a running Elastic Beanstalk environment without additional custom logic.

Practice this question →
2
MCQeasy

A company uses AWS CodeBuild to build and test code. They need to securely store sensitive parameters, such as database passwords, and inject them into the build process. Which AWS service should they use?

A.Storing them in the CodeBuild project environment variables
B.AWS Secrets Manager
C.AWS Key Management Service (KMS)
D.AWS Systems Manager Parameter Store
AnswerD

AWS Systems Manager Parameter Store is the correct choice because it securely stores configuration data and secrets as parameters, supports typed values including SecureString using KMS encryption, and CodeBuild has native integration by allowing environment variables to reference parameter names and fetch values at build time. It is ideal for static parameters because it imposes no rotation overhead, and you only need to grant the build project's IAM role ssm:GetParameter(s) permission.

Why this answer

AWS Systems Manager Parameter Store is the correct choice because it provides secure, hierarchical storage for configuration data and secrets, such as database passwords, and integrates natively with AWS CodeBuild via the `parameter-store` environment variable type. This allows you to reference parameters without hardcoding sensitive values, and you can optionally use secure string parameters encrypted with KMS for additional protection.

Exam trap

The trap here is that candidates often confuse AWS Secrets Manager with Systems Manager Parameter Store, but the exam expects you to know that Parameter Store is the simpler, more cost-effective choice for injecting static or semi-static configuration values into CodeBuild, while Secrets Manager is intended for secrets requiring automatic rotation.

How to eliminate wrong answers

Option A is wrong because storing sensitive parameters directly in CodeBuild project environment variables exposes them in plaintext in the build configuration and logs, violating security best practices. Option B is wrong because while AWS Secrets Manager can store secrets, it is designed for automatic rotation of credentials and is more complex and costly than needed for simple parameter injection into CodeBuild; the question specifically asks for a service to 'store and inject' parameters, which Parameter Store handles with lower overhead. Option C is wrong because AWS Key Management Service (KMS) is a key management service for creating and controlling encryption keys, not a storage service for secrets or parameters; it can be used to encrypt parameters in Parameter Store or Secrets Manager, but it does not itself store or inject values into CodeBuild.

Practice this question →
3
MCQhard

A DevOps engineer is troubleshooting a CloudFormation stack that failed to update. The error message indicates a circular dependency among resources. The template includes an Auto Scaling group, a launch template, and an IAM instance profile. The launch template references the IAM instance profile, and the Auto Scaling group references the launch template. The IAM instance profile's role references the Auto Scaling group name in its trust policy. How can the engineer resolve the circular dependency?

A.Use DependsOn clauses to explicitly order the resource creation
B.Pass the Auto Scaling group name as a parameter to the IAM role's trust policy, and create the Auto Scaling group with a condition that depends on the role
C.Place the launch template and Auto Scaling group in a nested stack
D.Hardcode the Auto Scaling group name in the IAM role's trust policy
AnswerB

Using a parameter breaks the circular reference by not requiring the actual Auto Scaling group resource to exist when the role is created.

Why this answer

Resolves the circular dependency by decoupling the Auto Scaling group name from the IAM role's trust policy at template creation time. By passing the group name as a parameter and using a condition to create the Auto Scaling group only after the role exists, CloudFormation can determine the correct creation order without a circular reference. This approach allows the trust policy to reference a value that is not yet known at template parsing, breaking the dependency cycle.

Exam trap

The trap here is that candidates often assume DependsOn can override any dependency issue, but CloudFormation still validates the entire dependency graph and will reject any cycle regardless of explicit DependsOn clauses.

How to eliminate wrong answers

Option A is wrong because DependsOn clauses only specify explicit ordering but do not resolve circular dependencies; if two resources depend on each other, DependsOn cannot break the cycle. Option C is wrong because placing resources in a nested stack does not eliminate circular dependencies; the nested stack still has the same logical references, and CloudFormation would still detect the cycle across stack boundaries. Option D is wrong because hardcoding the Auto Scaling group name makes the template non-portable and brittle, and it does not solve the circular dependency if the group name is used elsewhere in a way that creates a reference loop.

Practice this question →
4
MCQmedium

A company uses AWS CloudFormation to deploy a multi-tier application. The network team manages the VPC and subnets using a separate CloudFormation stack. The application team needs to reference the VPC ID and subnet IDs from the network stack. Which approach should the application team use to obtain these values?

A.Hardcode the VPC and subnet IDs in the application template.
B.Export the VPC ID and subnet IDs from the network stack using the 'Export' field and import them in the application stack using Fn::ImportValue.
C.Create the network stack as a nested stack inside the application stack.
D.Store the VPC and subnet IDs in AWS Systems Manager Parameter Store and retrieve them using dynamic references.
AnswerB

Exporting the VPC and subnet IDs from the network stack via the 'Export' field and importing them into the application stack with Fn::ImportValue establishes a native CloudFormation cross-stack reference within the same account and region. This creates an explicit dependency between the stacks, ensuring the network stack is created before the application stack and that the latest exported values are resolved at stack operation time. It avoids hardcoding by letting CloudFormation manage the wiring, and it supports updates and reuse across multiple dependent stacks. This is the intended, first-class mechanism for sharing outputs between independent CloudFormation stacks.

Why this answer

CloudFormation's Export and Fn::ImportValue mechanism allows cross-stack references without hardcoding or duplicating values. The network stack exports the VPC ID and subnet IDs using the Export field, and the application stack imports them via Fn::ImportValue, ensuring that changes in the network stack propagate automatically to dependent stacks.

Exam trap

The trap here is that candidates may confuse cross-stack references with nested stacks or parameter stores, but the exam specifically tests the Export/ImportValue pattern for decoupled stacks managed by different teams.

How to eliminate wrong answers

Option A is wrong because hardcoding VPC and subnet IDs creates brittle templates that break if the network stack is recreated or updated, violating infrastructure-as-code best practices. Option C is wrong because nesting the network stack inside the application stack would tightly couple the two teams' responsibilities, defeating the purpose of separate management and making it harder to update the network independently. Option D is wrong because while Systems Manager Parameter Store can store values, dynamic references in CloudFormation (e.g., '{{resolve:ssm:...}}') are resolved at stack creation time and do not automatically update when the parameter changes, unlike Fn::ImportValue which tracks the exported value across stacks.

Practice this question →
5
MCQmedium

A company uses AWS CodeDeploy for application deployments to EC2 instances. The team recently noticed that deployments are failing because some instances do not have the CodeDeploy agent installed. Which configuration management approach should the team implement to ensure the CodeDeploy agent is installed and running on all instances before deployment?

A.Use an AWS Config rule to detect instances without the agent and trigger a Lambda function to install it.
B.Use the CodeDeploy deployment configuration to skip instances that do not have the agent.
C.Create a custom AMI with the CodeDeploy agent pre-installed, or use a user data script to install the agent at launch.
D.Configure the CodeDeploy deployment group to automatically install the agent on new instances.
AnswerC

Pre-installing the CodeDeploy agent in a custom AMI (or bootstrapping it via user-data at instance launch) ensures the agent is running before the instance ever joins a deployment group. Because the agent is already present, CodeDeploy's deployment workflow can immediately begin pulling the AppSpec file and application revision from Amazon S3 or GitHub without waiting for an installation step. This proactive approach also avoids the time-of-installation risk where a deployment starts before a scripted agent installation completes, and it minimizes the chance of an instance being skipped or failing due to a missing agent.

Why this answer

It ensures the CodeDeploy agent is present on every EC2 instance from the moment it is launched, either by baking the agent into a custom AMI or by installing it via a user data script. This approach aligns with immutable infrastructure and configuration management best practices, preventing deployment failures caused by missing agents. AWS CodeDeploy requires the agent to be installed and running on target instances before any deployment can proceed.

Exam trap

The trap here is that candidates may assume CodeDeploy can automatically install its own agent on instances (Option D), but AWS CodeDeploy has no such built-in capability; the agent must be provisioned independently through AMI, user data, or a configuration management tool like AWS Systems Manager or Chef.

How to eliminate wrong answers

Option A is wrong because AWS Config rules are reactive and can only detect non-compliance after an instance is launched, not proactively ensure the agent is installed before deployment; additionally, relying on a Lambda function to install the agent introduces latency and potential race conditions. Option B is wrong because CodeDeploy deployment configurations do not support skipping instances based on agent presence; if an instance lacks the agent, the deployment will fail for that instance, and the overall deployment may fail depending on the failure threshold. Option D is wrong because CodeDeploy deployment groups do not have a built-in feature to automatically install the agent on new instances; the agent must be installed separately via AMI, user data, or an external configuration management tool.

Practice this question →
6
MCQeasy

A company uses AWS OpsWorks for configuration management. The DevOps team wants to deploy a new application version to a stack of EC2 instances. What should the team use to perform the deployment?

A.AWS Elastic Beanstalk
B.AWS CloudFormation
C.AWS CodeDeploy
D.Custom Chef recipes in OpsWorks
AnswerD

OpsWorks uses Chef recipes for configuration and deployment.

Why this answer

AWS OpsWorks is a configuration management service that uses Chef. When you need to deploy a new application version to a stack of EC2 instances managed by OpsWorks, the native and recommended approach is to use custom Chef recipes. These recipes can be executed as a lifecycle event (e.g., Deploy) to update application code, restart services, or perform any deployment tasks directly on the instances, leveraging the existing OpsWorks agent and Chef infrastructure.

Exam trap

The trap here is that candidates often confuse OpsWorks with Elastic Beanstalk or think that CodeDeploy is the universal deployment tool for all EC2 instances, forgetting that OpsWorks has its own native Chef-based deployment mechanism that should be used when the stack is already managed by OpsWorks.

How to eliminate wrong answers

Option A is wrong because AWS Elastic Beanstalk is a PaaS service for deploying web applications, not a deployment tool for existing OpsWorks stacks; it manages its own EC2 instances and cannot target an OpsWorks stack. Option B is wrong because AWS CloudFormation is an Infrastructure as Code (IaC) service for provisioning and managing AWS resources, not for deploying application code to running instances; it can create the stack but not perform the application deployment within OpsWorks. Option C is wrong because AWS CodeDeploy is a separate deployment service that can deploy to EC2 instances, but it is not integrated with OpsWorks lifecycle events; using it would bypass OpsWorks' built-in Chef-based deployment mechanism and require additional setup, making it non-idiomatic for an OpsWorks-managed environment.

Practice this question →
7
MCQhard

A company uses AWS CodeDeploy to deploy applications to an Auto Scaling group. During a deployment, the new instances fail the health check and are terminated. The deployment fails. The team wants to automatically roll back to the previous working version. What should they do?

A.Set up an Auto Scaling lifecycle hook to terminate instances and trigger a rollback.
B.Configure the deployment group to automatically roll back when a deployment fails.
C.Manually redeploy the last successful deployment revision after investigating the failure.
D.Configure the deployment group to automatically redeploy the same revision on failure.
AnswerB

CodeDeploy can automatically roll back to the last known good revision.

Why this answer

AWS CodeDeploy provides a built-in rollback configuration that can be triggered automatically when a deployment fails. By enabling automatic rollback in the deployment group settings, CodeDeploy will redeploy the last successful revision when the current deployment fails health checks, without requiring manual intervention or additional infrastructure.

Exam trap

The trap here is that candidates may confuse Auto Scaling lifecycle hooks with CodeDeploy rollback mechanisms, or think that redeploying the same revision (option D) would fix the issue, when in fact it would just repeat the failure.

How to eliminate wrong answers

Option A is wrong because Auto Scaling lifecycle hooks are used to perform custom actions during instance launch or termination (e.g., draining connections or running scripts), but they do not trigger CodeDeploy rollbacks; rollback logic must be configured within CodeDeploy itself. Option C is wrong because manually redeploying the last successful revision is a valid recovery method but does not meet the requirement for automatic rollback; the team wants an automated solution, not manual steps. Option D is wrong because redeploying the same revision on failure would repeat the same failing deployment, not restore the previous working version; automatic rollback specifically redeploys the last known good revision, not the failed one.

Practice this question →
8
MCQhard

A company runs a critical web application on AWS using an Auto Scaling group of EC2 instances behind an Application Load Balancer. The application is deployed using AWS CodeDeploy with a blue/green deployment configuration. The DevOps team is responsible for configuration management using AWS Systems Manager State Manager. They have set up a State Manager association to ensure that the instances have a specific security configuration (e.g., firewall rules). Recently, after a new deployment, the team noticed that the security configuration is missing on some new instances. The old instances still have the correct configuration. The association is configured to apply the configuration only at instance launch (using the AWS-RunShellScript document). The team suspects that the new instances are not being targeted by the association. Upon investigation, they find that the association is set to target instances based on tags, and the new instances do have the required tags. However, the association status shows 'Success' for the old instances but no status for the new instances. Which of the following is the MOST likely cause of this issue?

A.The State Manager association was created before the new instances were launched, and the association is not configured to automatically apply to new instances. The association needs to be updated or scheduled to run periodically.
B.The new instances have a different tag than the one specified in the association.
C.The association is trying to download a script from an S3 bucket, but the bucket policy denies access to new instances.
D.The AWS-RunShellScript document failed to execute on the new instances due to a missing IAM role.
AnswerA

Associations only apply to instances that exist at the time of association creation unless configured otherwise.

Why this answer

State Manager associations are created at a specific time and target instances that exist at that time. New instances launched after the association creation will not automatically be targeted unless the association is configured with a schedule or the 'Apply only at next update' option. The association is set to run only at launch, but the association itself must be applied to the instance at launch time.

If the association was created before the new instances, it won't apply to them unless it is updated. Option B is wrong because the association can target instances by tags; tagging is not the issue. Option C is wrong because the problem is not about the script failing; the association is not running on new instances.

Option D is wrong because the S3 bucket policy would affect the ability to store logs, but the association status would show error, not missing status.

Practice this question →
9
MCQhard

A company uses AWS CloudFormation to manage its infrastructure. The stack creation recently failed because an IAM role resource was created before the AWS Lambda function that depends on it. The template has no DependsOn clauses. What is the most likely reason for this failure and how can it be fixed?

A.Add a DependsOn clause to the Lambda function resource referencing the IAM role
B.Use AWS Systems Manager Automation to create the resources sequentially
C.Use a ChangeSet to roll back the stack and modify the template
D.Split the template into two separate stacks and use nested stacks
AnswerA

Adding a DependsOn clause directly tells CloudFormation that the Lambda function's creation must wait until the IAM role has finished provisioning. This is the native, declarative fix because CloudFormation's parallel resource creation does not automatically infer the role dependency if the Lambda function's properties only copy the role name or ARN as a string. Explicitly ordering the resources resolves the race condition cleanly without any additional services or architectural refactoring.

Why this answer

The most likely reason for the failure is that CloudFormation, by default, parallelizes the creation of resources that do not have explicit dependencies. Since the IAM role and Lambda function have no DependsOn clause, CloudFormation may attempt to create the Lambda function before the IAM role is fully created and its permissions are propagated. Adding a DependsOn clause to the Lambda function resource referencing the IAM role ensures that CloudFormation creates the IAM role first, resolving the dependency and preventing the failure.

Exam trap

The trap here is that candidates may assume CloudFormation automatically detects all dependencies via Ref or Fn::GetAtt, but it does not infer dependencies from resource attributes like IAM role ARNs used in Lambda function configurations unless explicitly referenced in the template.

How to eliminate wrong answers

Option B is wrong because AWS Systems Manager Automation is used for operational tasks like patching or runbooks, not for managing CloudFormation resource creation order; it does not address the missing dependency in the template. Option C is wrong because a ChangeSet is used to preview changes before updating a stack, not to roll back a failed creation or modify the template to fix dependency ordering; rolling back and modifying the template would require a new stack creation, not a ChangeSet. Option D is wrong because splitting the template into two separate stacks and using nested stacks does not inherently solve the dependency ordering issue; the same parallel creation problem could occur across nested stacks unless explicit DependsOn or cross-stack references are used, making it an unnecessarily complex solution.

Practice this question →
10
MCQmedium

A DevOps engineer is responsible for managing infrastructure as code for multiple microservices. The team uses AWS CloudFormation and wants to reuse common resource definitions across multiple stacks. Which approach should the engineer use to promote reusability and reduce code duplication?

A.Create nested stacks that include the common resources and pass parameters as needed.
B.Store the common resource definitions in an AWS CodeCommit repository and copy them into each template.
C.Use cross-stack references by exporting outputs from a central stack and importing them in other stacks.
D.Develop CloudFormation modules that encapsulate common resource configurations and publish them in a registry.
AnswerD

CloudFormation modules are purpose-built for encapsulating and reusing common resource configurations: you package a template, a schema, and optional resource providers into a module and publish it to the CloudFormation registry. Once published, any stack can reference the module by type, version, and optional alias, enabling consistent, versioned, and shareable infrastructure components across accounts and regions. Modules support parameter and resource typing, and they can be privately shared within an organization, making them the correct way to eliminate duplicate resource definitions while keeping templates concise.

Why this answer

AWS CloudFormation modules allow you to encapsulate common resource configurations into reusable, versioned components that can be published in the CloudFormation registry. This promotes reusability and reduces code duplication across multiple stacks without the overhead of managing nested stack templates or manual copying.

Exam trap

The trap here is that candidates often confuse cross-stack references (Fn::ImportValue) with reusable resource definitions, but cross-stack references only share output values, not the underlying resource configuration, so they do not reduce code duplication.

How to eliminate wrong answers

Option A is wrong because nested stacks still require you to maintain separate template files for the common resources, and they do not inherently reduce duplication if the same nested stack template is copied across projects. Option B is wrong because copying common resource definitions from a CodeCommit repository into each template leads to code duplication and version drift, defeating the purpose of reusability. Option C is wrong because cross-stack references (using Fn::ImportValue) only allow sharing output values, not entire resource definitions, so they do not reduce duplication of the resource configuration itself.

Practice this question →
11
Multi-Selectmedium

A company uses AWS CloudFormation StackSets to deploy a common network infrastructure across multiple AWS accounts. They need to ensure that all StackSet operations are audited and any failed stack instances are automatically retried. Which THREE configurations should be implemented? (Select THREE.)

Select 3 answers
A.Enable automatic rollback on failure.
B.Configure Amazon SNS notifications for StackSet events.
C.Use AWS Config rules to monitor StackSet compliance.
D.Set the 'Retry on failure' option in StackSet operation preferences.
E.Enable AWS CloudTrail to log StackSet API calls.
AnswersB, D, E

SNS can notify administrators of failures so they can take action.

Why this answer

To audit StackSet operations, enable AWS CloudTrail to log StackSet API calls (option E). To automatically retry failed stack instances, set the 'Retry on failure' option in StackSet operation preferences (option D). To receive notifications about StackSet events, configure Amazon SNS notifications (option B).

Automatic rollback (A) is not a retry mechanism, and AWS Config rules (C) monitor compliance but do not provide audit logging or retry functionality.

Practice this question →
12
MCQhard

A DevOps engineer is troubleshooting a CloudFormation stack that fails to create. The error message indicates a 'circular dependency' between two resources: a security group and an EC2 instance. The security group contains an ingress rule that references the instance's private IP address, which is not known until the instance is created. The instance's network interface uses the security group. What change should the engineer make to resolve the circular dependency?

A.Create the EC2 instance first without a security group, then attach the security group after creation.
B.Add an AWS::EC2::SecurityGroupIngress rule that references the instance's network interface using Fn::GetAtt on the network interface resource.
C.Hardcode the instance's private IP address in the security group rule.
D.Use the Ref function on the EC2 instance to get its private IP address.
AnswerB

It breaks the circular dependency by using `Fn::GetAtt` on the `AWS::EC2::NetworkInterface` resource to reference the private IP address. This creates a dependency on the network interface, which is created before the instance, while the security group ingress rule depends on the network interface, breaking the cycle.

Why this answer

It resolves the circular dependency by creating an explicit dependency on the network interface resource rather than the EC2 instance. The `AWS::EC2::SecurityGroupIngress` rule can use `Fn::GetAtt` on the `AWS::EC2::NetworkInterface` resource to retrieve the private IP address of the instance's primary network interface, which is known after the network interface is created but before the instance is fully launched. This breaks the cycle because the security group ingress rule depends on the network interface, and the network interface depends on the security group (via association), but the instance itself is not directly referenced in the ingress rule, allowing CloudFormation to resolve the dependencies in the correct order.

Exam trap

The trap here is that candidates often assume `Ref` on an EC2 instance returns its private IP address, but `Ref` actually returns the physical instance ID (e.g., i-1234567890abcdef0), not the IP, leading them to incorrectly choose Option D or attempt hardcoding in Option C.

How to eliminate wrong answers

Option A is wrong because creating the EC2 instance without a security group and attaching it later does not resolve the circular dependency in the CloudFormation template; it merely shifts the problem to a post-creation step that still requires the private IP address, and the template itself would still fail due to the unresolved dependency during creation. Option C is wrong because hardcoding the instance's private IP address defeats the purpose of Infrastructure as Code (IaC) and is not dynamic; it would break if the instance is recreated or if the IP changes, and it does not solve the circular dependency in the template logic. Option D is wrong because using the `Ref` function on the EC2 instance returns the logical ID (e.g., the instance ID), not the private IP address; `Ref` on an EC2 instance does not expose the private IP, and even if it did, it would create the same circular dependency because the security group ingress rule would still depend on the instance's creation.

Practice this question →
13
Multi-Selectmedium

A company uses AWS CloudFormation to manage infrastructure. They have a nested stack that creates an ECS cluster. The parent stack fails with the error: 'The following resource(s) failed to create: [ECSCluster]'. Which TWO are possible causes? (Choose TWO.)

Select 2 answers
A.The parent stack is referencing an output from the nested stack that does not exist
B.The nested stack is in a different AWS region from the parent stack
C.The nested stack's name is not unique among all stacks in the account
D.The parent stack's IAM role does not have permission to create the nested stack's resources
E.The nested stack template contains an invalid resource property
AnswersD, E

Insufficient permissions would cause creation failure.

Why this answer

The parent stack's IAM role must have sufficient permissions to create all resources defined in the nested stack, including the ECS cluster. If the role lacks the necessary ECS actions (e.g., ecs:CreateCluster), CloudFormation will fail with the generic 'failed to create' error for the nested stack resource.

Exam trap

The trap here is that candidates may confuse a resource creation failure with a template validation error or cross-stack reference issue, but the specific error message 'The following resource(s) failed to create: [ECSCluster]' indicates the nested stack itself failed to create its resources, not a parent-child output dependency or naming conflict.

Practice this question →
14
MCQhard

A company uses AWS Systems Manager to manage hybrid servers. They want to automate the patching of Windows servers using Patch Manager. However, some servers are not showing up in the compliance reporting. What should the DevOps engineer check first?

A.Ensure the SSM Agent is installed and running on the servers
B.Verify that the servers have the correct patch baseline tags
C.Check that the Patch Baseline is configured to include the missing servers
D.Confirm that the servers have an IAM service role for Systems Manager
AnswerA

For a hybrid server to be managed by Systems Manager, the SSM Agent must be installed and actively running on the operating system. The agent is the on-premises component that establishes the communication channel with the Systems Manager service, handles requests for Run Command, Patch Manager, and Inventory, and reports the instance's status back to the service. If the agent is absent, stopped, or in an unhealthy state, the server will not appear in the inventory or compliance views, and no Systems Manager operation can target it. Reinstalling or restarting the agent, and periodically verifying its health, is the first-line remediation for 'missing' hybrid nodes.

Why this answer

The SSM Agent is the core component that enables a server to communicate with AWS Systems Manager. Without the agent installed and running, the server cannot register with the service, receive patch commands, or report its compliance status. Therefore, this is the most fundamental prerequisite to check first when servers are missing from compliance reporting.

Exam trap

The trap here is that candidates often jump to IAM roles or tag-based configurations first, forgetting that the SSM Agent is the absolute prerequisite for any Systems Manager functionality, including Patch Manager compliance reporting.

How to eliminate wrong answers

Option B is wrong because patch baseline tags are used to associate a server with a specific patch baseline, but they do not affect whether the server appears in compliance reporting at all; a server must first be managed by Systems Manager via the SSM Agent. Option C is wrong because the Patch Baseline configuration defines which patches to apply, not which servers are included in reporting; server visibility is determined by agent connectivity and instance registration. Option D is wrong because while an IAM instance profile (not a service role) is required for the SSM Agent to call AWS APIs, the agent must still be installed and running first; without the agent, no IAM role can make the server appear in compliance reporting.

Practice this question →
15
MCQhard

A team manages a large fleet of EC2 instances using AWS Systems Manager. They want to enforce a consistent configuration across all instances, including installed software packages, firewall rules, and user accounts. The team also needs to audit configuration changes and remediate drift automatically. Which AWS service should the team use?

A.AWS OpsWorks for Chef Automate
B.AWS Systems Manager State Manager
C.AWS Systems Manager Run Command
D.AWS Config
AnswerB

AWS Systems Manager State Manager is the correct choice because it lets you define a desired configuration state (such as specific software packages, user accounts, or agent settings) and automatically apply and maintain that state on your EC2 fleet. It uses associations that run on a schedule, detect drift from the defined state, and reapply the configuration whenever needed. Unlike ad-hoc tools, State Manager continuously enforces the desired state across instances with built-in rate controls and error handling, making it ideal for managing large fleets.

Why this answer

AWS Systems Manager State Manager is the correct choice because it is designed to enforce a consistent configuration across EC2 instances by defining and applying desired state configurations (DSCs). It can manage software packages, firewall rules, and user accounts, and it automatically remediates drift by re-applying the desired state on a schedule. This directly meets the requirement for configuration enforcement, auditing, and automated drift remediation.

Exam trap

The trap here is confusing AWS Config (which only audits and detects drift) with State Manager (which enforces and remediates drift), leading candidates to choose Config because they focus on the auditing requirement without realizing it lacks enforcement capabilities.

How to eliminate wrong answers

Option A is wrong because AWS OpsWorks for Chef Automate is a configuration management service that uses Chef cookbooks, but it requires managing a Chef server and does not natively integrate with Systems Manager for drift remediation or auditing without additional setup. Option C is wrong because AWS Systems Manager Run Command is designed for ad-hoc, one-time command execution across instances, not for enforcing ongoing desired state configurations or automatically remediating drift. Option D is wrong because AWS Config is a service for auditing resource configurations and tracking changes, but it does not enforce configurations or remediate drift; it only detects non-compliance and can trigger remediation actions via other services like Systems Manager Automation.

Practice this question →
16
MCQeasy

A company uses AWS CodeDeploy to deploy applications to an Auto Scaling group. The deployment fails because the new version of the application crashes the instances. The DevOps engineer needs the Auto Scaling group to automatically replace the unhealthy instances with the previous working version. Which deployment configuration should the engineer use?

A.In-place deployment with a deployment group that has a failure threshold of 0.
B.Blue/Green deployment with a load balancer to switch traffic only after health checks pass.
C.Canary deployment that shifts 10% of traffic to the new version, then 100% after 10 minutes.
D.Linear deployment that shifts 10% of traffic every 10 minutes.
AnswerB

Blue/Green deployment creates a completely separate green environment and reroutes traffic only after the new instances pass health checks. The load balancer is the key component: it keeps traffic anchored to the blue environment until the green is verified healthy, and if health checks fail, you simply do not cut over or you can switch back to blue instantly. This gives an automatic, low-risk rollback path because the original environment remains intact and available. Thus, it satisfies the need to revert to the original version when issues are detected.

Why this answer

A blue/green deployment with a load balancer health check ensures that the new (green) instances are validated before any traffic is routed to them. If the new version crashes, the health checks fail, the load balancer keeps traffic on the old (blue) instances, and the Auto Scaling group can automatically terminate the unhealthy green instances and replace them with the previous working version by reverting to the original launch configuration or template.

Exam trap

The trap here is that candidates often confuse deployment strategies (in-place, canary, linear) with rollback mechanisms, assuming that any traffic-shifting method automatically replaces unhealthy instances with the previous version, when in fact only blue/green deployments inherently isolate the new environment and allow a clean revert without affecting the old instances.

How to eliminate wrong answers

Option A is wrong because an in-place deployment with a failure threshold of 0 means the deployment will stop as soon as any single instance fails, but it does not automatically replace unhealthy instances with the previous working version; it simply halts the deployment, leaving the failed instances in place. Option C is wrong because a canary deployment shifts a small percentage of traffic to the new version and then fully shifts after a time window, but if the new version crashes instances, the canary instances become unhealthy and the deployment may still proceed to full rollout if the health check grace period expires, failing to automatically revert to the previous version. Option D is wrong because a linear deployment incrementally shifts traffic in steps, but like the canary, it does not inherently replace crashed instances with the previous working version; it only controls traffic shifting, not instance recovery or rollback.

Practice this question →
17
MCQhard

A DevOps engineer creates the CloudFormation template shown in the exhibit. When the stack is created, the EC2 instance is launched but the security group is not applied to the instance. What is the likely cause?

A.The security group resource is missing a VpcId property, so it is not created in the same VPC as the instance.
B.The instance does not have a SecurityGroup or SecurityGroupIds property referencing the security group.
C.The security group is created after the instance, so the instance cannot reference it.
D.The DependsOn clause should be removed because it causes a circular dependency.
AnswerB

The actual flaw is that the instance resource lacks a SecurityGroupIds or SecurityGroups property to reference the security group. DependsOn only ensures the security group is created first; it does not attach the group to the instance. Without an explicit reference in the instance properties, CloudFormation has no way to associate the security group, even though it exists and is available.

Why this answer

The CloudFormation template does not include a `SecurityGroup` or `SecurityGroupIds` property in the EC2 instance's `AWS::EC2::Instance` resource. Without this explicit reference, the instance launches with the default VPC security group, not the custom security group defined in the template. The security group resource is created successfully, but it is not attached to the instance.

Exam trap

The trap here is that candidates assume creating a security group resource in the template automatically applies it to the instance, but CloudFormation requires an explicit attachment via the instance's security group properties.

How to eliminate wrong answers

Option A is wrong because the security group resource (`AWS::EC2::SecurityGroup`) does not require a `VpcId` property if the template is deployed in a default VPC; even if missing, the security group is still created and can be referenced. Option C is wrong because CloudFormation automatically resolves dependencies based on resource references (e.g., `!Ref SecurityGroup`), and the security group is created before the instance if referenced, not after. Option D is wrong because a `DependsOn` clause does not cause a circular dependency here; it simply ensures the security group is created before the instance, which is valid and does not create a loop.

Practice this question →
18
MCQeasy

A developer wants to provision AWS resources using AWS Cloud Development Kit (CDK) and ensure that the infrastructure can be version-controlled and reviewed. Which practice should they follow?

A.Write the CDK app and deploy directly without synthesis to avoid extra steps.
B.Write the CDK app to generate Terraform configurations and store them in Git.
C.Write raw CloudFormation templates instead of CDK to simplify version control.
D.Write the CDK app in TypeScript, store it in a Git repository, and use CDK pipelines for deployment.
AnswerD

Storing an ordinary TypeScript CDK project in Git and using the `cdk pipelines` construct creates a self-mutating CI/CD pipeline that automatically builds, synthesizes, and deploys the app to one or more AWS environments. This approach lets you version the CDK source, review pull requests, run unit tests, and retain the full CloudFormation deployment model underneath. It is the recommended production pattern because pipeline updates are also managed through the same CDK code, giving you repeatable and auditable infrastructure delivery.

Why this answer

It follows the recommended practice of treating CDK application code as infrastructure source code, storing it in a version control system (Git), and using CDK Pipelines (a high-level construct that automatically synthesizes and deploys CloudFormation templates) to ensure repeatable, reviewed deployments. This approach enables infrastructure-as-code best practices: version history, peer review via pull requests, and automated deployment pipelines.

Exam trap

The trap here is that candidates may think CDK requires manual synthesis or that it can output Terraform, but the exam tests that CDK is a CloudFormation-only IaC tool that must be synthesized and version-controlled as code, not as raw templates.

How to eliminate wrong answers

Option A is wrong because deploying directly without synthesis bypasses the generation of CloudFormation templates, which are the deployable artifacts; CDK synthesis is a required step to produce the CloudFormation templates that AWS CloudFormation consumes, and skipping it would prevent deployment. Option B is wrong because CDK does not generate Terraform configurations; CDK synthesizes CloudFormation templates, not Terraform HCL, and mixing tools would introduce unnecessary complexity and break the native integration with AWS. Option C is wrong because writing raw CloudFormation templates instead of CDK would lose the benefits of CDK's higher-level abstractions, programming language features (e.g., loops, conditionals), and construct reuse, while version control is equally possible with CDK code; the question specifically asks about using CDK, so this option contradicts the premise.

Practice this question →
19
MCQeasy

A company uses AWS CloudFormation to manage its infrastructure. The operations team needs to update a stack that includes an RDS database. The update requires changing the DB instance class, which will cause a replacement of the database. The team wants to minimize downtime and ensure that data is not lost. Which CloudFormation stack update policy should they use?

A.Set the CreationPolicy attribute on the database resource.
B.Configure a Stack Policy to protect the database resource.
C.Set the UpdatePolicy to AutoScalingRollingUpdate.
D.Set the UpdatePolicy to AutoScalingReplacingUpdate with WillReplace set to true.
AnswerD

AutoScalingReplacingUpdate is only supported for AWS::AutoScaling::AutoScalingGroup and cannot be applied to an AWS::RDS::DBInstance resource.

Why this answer

The UpdatePolicy attribute with AutoScalingReplacingUpdate is only supported for AWS::AutoScaling::AutoScalingGroup resources, not for AWS::RDS::DBInstance. Therefore, option D is incorrect. Options A and C are also invalid (CreationPolicy is for signal-based creation, and AutoScalingRollingUpdate is for rolling updates on Auto Scaling groups).

Option B, Stack Policy, can protect resources from being updated but does not control how a replacement occurs to minimize downtime or prevent data loss. Thus, none of the provided options are correct for ensuring minimal downtime and data safety during an RDS instance class change that requires replacement.

Exam trap

Candidates might assume that AutoScalingReplacingUpdate can be applied to any resource supporting replacement, but CloudFormation limits UpdatePolicy to specific resources like Auto Scaling groups, ElastiCache replication groups, and Elasticsearch domains. RDS DB instances do not support UpdatePolicy.

How to eliminate wrong answers

Option A is wrong because the `CreationPolicy` attribute controls how CloudFormation waits for signals (e.g., from cfn-init) before marking a resource as created; it does not affect update behavior or minimize downtime during a replacement. Option B is wrong because a Stack Policy is used to prevent accidental updates or deletions of specific resources by denying update/delete actions, but it does not control the order or method of updates to minimize downtime. Option C is wrong because `AutoScalingRollingUpdate` is designed for Auto Scaling groups to update instances in batches, not for RDS instances; applying it to an RDS resource would have no effect and would not handle the replacement of a database.

Practice this question →
20
MCQmedium

A DevOps team uses AWS CodePipeline to automate deployments. The pipeline has a Deploy stage that uses AWS CloudFormation to create or update a stack. Recently, a stack update failed because the template referenced an AMI that was deprecated. The team wants to automatically roll back the stack to the last known good state if a deployment fails. What should they do?

A.Configure the CloudFormation deployment action in CodePipeline with 'ActionMode' set to 'CREATE_UPDATE' and check the 'Rollback on failure' option.
B.Use the CodePipeline console to enable 'Automatic rollback' for the Deploy stage.
C.Set the stack's 'DisableRollback' parameter to 'true' in the template.
D.Add a stack policy to the CloudFormation stack that denies updates to the AMI parameter.
AnswerA

In CodePipeline, the CloudFormation deployment action requires an explicit ActionMode such as CREATE_UPDATE to create a new stack or update an existing one. When 'Rollback on failure' is selected, CloudFormation automatically rolls back the stack to its last known good state if the deployment fails, restoring both resources and stack outputs. This is the correct mechanism because it leverages CloudFormation's native rollback capability within the pipeline execution, preserving the integrity of the deployed infrastructure.

Why this answer

The CloudFormation deployment action in CodePipeline supports a 'Rollback on failure' option when 'ActionMode' is set to 'CREATE_UPDATE'. When enabled, if the stack update fails, CloudFormation automatically rolls back the stack to the last known good state (the previously deployed stack). This directly addresses the team's requirement to revert to a stable state after a failed deployment due to a deprecated AMI.

Exam trap

The trap here is that candidates confuse the CloudFormation stack-level 'DisableRollback' parameter (which controls rollback during stack creation) with the CodePipeline action-level 'Rollback on failure' option, leading them to incorrectly select Option C.

How to eliminate wrong answers

Option B is wrong because CodePipeline does not have an 'Automatic rollback' toggle at the stage level; rollback behavior is configured within the CloudFormation action itself, not via a generic stage setting. Option C is wrong because setting 'DisableRollback' to 'true' actually prevents rollback on failure, which is the opposite of what the team wants. Option D is wrong because a stack policy controls permissions for stack updates (e.g., preventing updates to specific resources), but it does not trigger an automatic rollback after a failed deployment.

Practice this question →
21
MCQeasy

A DevOps engineer is writing an AWS CloudFormation template that creates an Amazon S3 bucket with versioning enabled. The engineer wants to ensure that the bucket cannot be deleted accidentally. What should the engineer add to the template?

A.Set the DeletionPolicy attribute to Retain on the S3 bucket resource
B.Enable termination protection on the S3 bucket
C.Add a DependsOn clause to the bucket referencing the stack itself
D.A bucket policy that denies s3:DeleteBucket
AnswerA

DeletionPolicy: Retain prevents the bucket from being deleted when the stack is deleted.

Why this answer

Setting the DeletionPolicy attribute to Retain on the S3 bucket resource ensures that when the CloudFormation stack is deleted, the bucket is preserved and not removed. This is the correct AWS CloudFormation mechanism to prevent accidental deletion of a resource, as it overrides the default behavior of deleting all resources when a stack is deleted.

Exam trap

The trap here is that candidates confuse termination protection (an EC2 feature) with CloudFormation's DeletionPolicy, or mistakenly believe a bucket policy can override CloudFormation's resource deletion behavior during stack teardown.

How to eliminate wrong answers

Option B is wrong because termination protection is a feature for EC2 instances, not for S3 buckets; S3 buckets do not have a termination protection attribute. Option C is wrong because a DependsOn clause only establishes resource creation order within a stack and does not prevent deletion of the bucket. Option D is wrong because a bucket policy that denies s3:DeleteBucket would prevent any IAM user or role from deleting the bucket, but it does not protect against the bucket being deleted when the CloudFormation stack is deleted, as CloudFormation uses the underlying AWS API with sufficient permissions to delete resources regardless of bucket policies.

Practice this question →
22
MCQmedium

A DevOps team wants to enforce that all EC2 instances launched in an AWS account have a specific tag 'Environment' with value 'Production' or 'Development'. The team uses AWS CloudFormation to provision resources. Which approach should the team use to enforce tagging compliance at launch?

A.Configure a CloudFormation stack policy that denies stack updates if the tag is missing.
B.Add an IAM policy that denies ec2:RunInstances unless the request includes the required tag.
C.Create an AWS Service Catalog portfolio with a tag option constraint that requires the tag.
D.Use an AWS Config rule with an auto-remediation action that applies the required tag to non-compliant resources.
AnswerD

AWS Config can evaluate resources against rules and trigger auto-remediation to apply missing tags.

Why this answer

AWS Config rules can evaluate EC2 instances for the presence of the 'Environment' tag with allowed values and, when combined with an auto-remediation action (e.g., using AWS Systems Manager Automation), can automatically apply the missing tag to non-compliant resources. This enforces tagging compliance at launch and throughout the resource lifecycle, even if the instance was launched without the tag. The auto-remediation action can be triggered as soon as the Config rule detects non-compliance, ensuring the tag is applied shortly after launch.

Exam trap

The trap here is that candidates often confuse 'enforcement at launch' with 'prevention at launch' and incorrectly choose an IAM policy (Option B) or a Service Catalog constraint (Option C), not realizing that AWS Config with auto-remediation provides a more flexible and comprehensive enforcement mechanism that works across all launch methods and can correct non-compliance after the fact.

How to eliminate wrong answers

Option A is wrong because CloudFormation stack policies control updates to existing stacks, not enforcement of tags on resources at launch; they cannot deny resource creation based on missing tags. Option B is wrong because IAM policies that deny ec2:RunInstances unless the request includes the required tag would block all launches that don't explicitly specify the tag in the API call, but this approach is brittle and does not cover resources launched by services like Auto Scaling or CloudFormation that may not pass tags in the same way; also, it does not remediate non-compliant resources after launch. Option C is wrong because AWS Service Catalog tag option constraints only enforce tags on products provisioned through Service Catalog, not on EC2 instances launched directly via CloudFormation or other means outside of Service Catalog.

Practice this question →
23
MCQmedium

A company uses AWS CloudFormation to deploy a web application across multiple AWS accounts using StackSets. The DevOps team notices that stack instance updates are failing in some accounts with the error: 'Insufficient IAM permissions to perform the action'. The team has already verified that the StackSet IAM role has the necessary permissions. What is the most likely cause of this issue?

A.The target accounts have reached the limit of 200 stacks per region.
B.The target accounts do not have the necessary trust policy to allow the StackSet IAM role to assume the execution role.
C.AWS Organizations has a service control policy (SCP) that denies the required action, but the StackSet IAM role has full admin permissions.
D.The StackSet name contains invalid characters that are not allowed in some accounts.
AnswerB

AWS CloudFormation StackSets require a trust relationship between the IAM role used to administer the StackSet (in the management account) and an execution role in each target account. If the execution role’s trust policy does not include the StackSet IAM role (or the appropriate account) as a trusted principal, the sts:AssumeRole call fails with an access-denied error. This trust policy is what authorizes the management account’s role to assume the target execution role, so its absence directly produces the reported failure.

Why this answer

StackSets require a trust relationship between the StackSet IAM role (in the management account) and an execution role in each target account. Even if the StackSet IAM role has full permissions, the target accounts must have a trust policy that allows the StackSet IAM role to assume the execution role. Without this trust policy, the assumption fails, resulting in the 'Insufficient IAM permissions' error.

Exam trap

The trap here is that candidates often assume the error is due to missing permissions on the StackSet IAM role itself, but the DOP-C02 exam tests the understanding that StackSets require a trust chain where the target account's execution role must explicitly trust the management account's StackSet IAM role.

How to eliminate wrong answers

Option A is wrong because the error message specifically mentions IAM permissions, not stack limits; reaching the 200-stack limit would produce a limit exceeded error, not an IAM permissions error. Option C is wrong because SCPs can deny actions even if the IAM role has full admin permissions, but the question states the team verified the StackSet IAM role has necessary permissions, and the error is about IAM permissions, not SCP denials; however, SCPs would cause a different error (e.g., 'Action denied by service control policy'), and the scenario points to a trust policy issue. Option D is wrong because StackSet names have character restrictions that are validated at creation time, not during updates, and invalid characters would cause a creation failure, not an update permission error.

Practice this question →
24
MCQeasy

A company uses AWS CodeBuild to compile and test code. The buildspec.yml file includes commands that require access to a private S3 bucket. The DevOps engineer wants to securely provide AWS credentials to the build project. What is the recommended approach?

A.Use a service role for CodeBuild with appropriate permissions
B.Store the AWS access key ID and secret access key in the buildspec.yml file
C.Use an EC2 instance profile attached to the build environment
D.Pass the credentials as environment variables in the build project configuration
AnswerA

Using a service role for CodeBuild is the secure approach because CodeBuild assumes the role via the `codebuild.amazonaws.com` service principal to obtain temporary credentials for API calls such as pulling source from S3 or publishing artifacts. The role is configured with an IAM trust policy and a permissions policy that grants only the needed actions, adhering to least privilege. Temporary session credentials are automatically rotated and never written to disk, logs, or build scripts.

Why this answer

The recommended approach is to use a service role for CodeBuild with appropriate permissions. CodeBuild can assume an IAM role that grants the build project access to the private S3 bucket, eliminating the need to manage long-term credentials. This follows AWS best practices for secure credential management by using temporary, automatically rotated credentials via the AWS Security Token Service (STS).

Exam trap

The trap here is that candidates may confuse CodeBuild with EC2-based build environments and incorrectly assume an instance profile can be used, or they may think environment variables are a secure way to pass credentials, overlooking that the values must still be stored in the project configuration.

How to eliminate wrong answers

Option B is wrong because storing AWS access key ID and secret access key in the buildspec.yml file exposes long-term credentials in plaintext, which violates security best practices and risks credential leakage in version control. Option C is wrong because CodeBuild does not run on EC2 instances; it uses a managed, ephemeral build environment, so an EC2 instance profile cannot be attached to it. Option D is wrong because passing credentials as environment variables in the build project configuration still requires storing the secret values in the project, which is insecure and not recommended; instead, CodeBuild should assume a service role to obtain temporary credentials.

Practice this question →
25
MCQmedium

A DevOps engineer is designing a configuration management strategy for a fleet of EC2 instances running Amazon Linux 2. The instances must be bootstrapped with custom software and continuously managed to ensure desired state compliance. Which combination of services should the engineer use?

A.AWS CloudFormation for bootstrapping and Amazon CloudWatch Events to enforce desired state
B.AWS OpsWorks for Chef Automate for configuration management and AWS CodeDeploy for deployments
C.AWS Systems Manager State Manager for desired state configuration and AWS Systems Manager Run Command for initial bootstrapping
D.AWS Config for configuration management and Amazon CloudWatch Events for remediation
AnswerC

AWS Systems Manager State Manager uses associations to define and continuously enforce a desired configuration state, automatically reapplying or remediating drift for managed instances. AWS Systems Manager Run Command can execute one-time bootstrap scripts on instances via the SSM Agent, enabling initial setup like installing packages or joining domains. Because both services share the same agent and console, this combination provides a unified, serverless approach to bootstrap and ongoing configuration management.

Why this answer

AWS Systems Manager State Manager provides a policy-driven mechanism to define and maintain desired state configuration for EC2 instances, while AWS Systems Manager Run Command enables ad-hoc or initial bootstrapping by executing scripts or commands (e.g., installing custom software) without requiring SSH. Together, they cover both the initial setup and ongoing compliance enforcement for Amazon Linux 2 instances, aligning with the requirement for continuous management.

Exam trap

The trap here is that candidates often confuse AWS Config (a compliance auditing service) with a configuration management tool, or assume CloudWatch Events can enforce state, when in fact Systems Manager State Manager is the native AWS service for desired state configuration.

How to eliminate wrong answers

Option A is wrong because Amazon CloudWatch Events (now Amazon EventBridge) is an event bus service for routing events, not a tool for enforcing desired state; it cannot apply or remediate configuration drift on EC2 instances. Option B is wrong because AWS OpsWorks for Chef Automate is a managed Chef server, but it is not the recommended approach for Amazon Linux 2 instances that are better served by native AWS Systems Manager capabilities, and AWS CodeDeploy handles application deployments, not configuration management or desired state enforcement. Option D is wrong because AWS Config is a service for evaluating resource compliance against rules and recording configuration history, but it does not perform remediation actions itself; while it can trigger remediation via Systems Manager Automation, it is not a configuration management tool for bootstrapping or continuous desired state enforcement.

Practice this question →
26
MCQeasy

A DevOps team is using AWS CloudFormation to manage a multi-tier application. They want to ensure that when an update to the stack causes a resource replacement, the replacement occurs only after the new resource is fully created and tested. Which CloudFormation feature should they use?

A.UpdatePolicy attribute with AutoScalingRollingUpdate
B.CreationPolicy attribute
C.DeletionPolicy attribute set to Retain
D.DependsOn attribute to specify creation order
AnswerB

Incorrect. The `CreationPolicy` attribute does not have a `CreateBeforeDestroy` property. It is used to wait for a signal from the resource after creation, not to control the order of replacement during updates.

Why this answer

The CreationPolicy attribute can be added to a resource to ensure that CloudFormation waits for a specified number of success signals before considering the resource created. When a stack update causes a resource replacement, CloudFormation creates the new resource, waits for the creation signals (if a CreationPolicy is defined), and only then deletes the old resource. This ensures the new resource is fully operational and tested before replacement.

The other options are incorrect: UpdatePolicy with AutoScalingRollingUpdate is for updating instances in an Auto Scaling group without full replacement; DeletionPolicy Retain keeps the old resource but does not manage creation; DependsOn controls creation order but does not wait for testing signals.

Exam trap

Candidates often confuse the UpdatePolicy (used for rolling updates in Auto Scaling) with CreationPolicy (used to wait for resource creation signals). The trap is to think that only Auto Scaling resources can be tested during replacement; many resources support CreationPolicy for signal-based testing during replacement.

How to eliminate wrong answers

Option A is wrong because `UpdatePolicy` with `AutoScalingRollingUpdate` is specific to Auto Scaling groups and controls how instances are updated during rolling updates, not how resource replacements are sequenced for arbitrary resources. Option C is wrong because `DeletionPolicy` set to `Retain` only preserves a resource when the stack is deleted, not during an update replacement; it does not control creation order or testing. Option D is wrong because `DependsOn` only specifies the creation order of resources during initial stack creation, not the replacement behavior during updates; it cannot enforce that a new resource is created and tested before the old one is removed.

Practice this question →
27
MCQeasy

A developer wants to use AWS CloudFormation to create an Amazon RDS DB instance. The template includes a DB instance resource. Which property is required for the DB instance to be created successfully?

A.DBInstanceClass and Engine
B.AllocatedStorage
C.DBInstanceIdentifier
D.MasterUsername and MasterUserPassword
AnswerA

In CloudFormation's AWS::RDS::DBInstance resource, DBInstanceClass and Engine are mandatory properties for every instance. DBInstanceClass defines the instance's compute and memory capacity, while Engine specifies the database engine (e.g., mysql, postgres). Without these, the resource automatically fails validation because CloudFormation can't provision a database without a compute class and an engine type. This makes this pair the correct answer for the property required universally.

Why this answer

In AWS CloudFormation, when creating an Amazon RDS DB instance using the AWS::RDS::DBInstance resource, the only truly required properties are DBInstanceClass (the compute and memory capacity) and Engine (the database engine, e.g., MySQL, PostgreSQL). These two properties are mandatory in the CloudFormation resource specification; without them, the template will fail validation. All other properties, such as AllocatedStorage, DBInstanceIdentifier, MasterUsername, and MasterUserPassword, have default behaviors or can be omitted under certain conditions (e.g., AllocatedStorage defaults to 20 GB for some engines, and MasterUsername/MasterUserPassword are not required if you use a snapshot or a source DB instance).

Exam trap

The trap here is that candidates often assume MasterUsername and MasterUserPassword are always required because they are mandatory in the AWS Management Console wizard, but CloudFormation allows omitting them when the DB instance is created from a snapshot or as a read replica, making DBInstanceClass and Engine the only universally required properties.

How to eliminate wrong answers

Option B is wrong because AllocatedStorage is not required; CloudFormation will use a default value (typically 20 GB) if not specified, and the DB instance can still be created successfully. Option C is wrong because DBInstanceIdentifier is optional; if omitted, CloudFormation automatically generates a unique identifier for the DB instance. Option D is wrong because MasterUsername and MasterUserPassword are not required when creating a DB instance from a snapshot or when specifying a source DB instance identifier; they are only required for a fresh, empty DB instance creation.

Practice this question →
28
MCQmedium

A DevOps team is using AWS CodePipeline to automate deployments. The pipeline has a source stage (CodeCommit), a build stage (CodeBuild), and a deploy stage (CodeDeploy). The team wants to add a manual approval step before the deploy stage to ensure that only authorized personnel can approve production deployments. Which action should be taken to implement this requirement?

A.Add an AWS Lambda function as a transition action between the build and deploy stages that sends an email to the approver and waits for a response.
B.Create a CodeDeploy deployment group with a manual approval step in the deployment configuration.
C.Configure an Amazon SNS topic to send an approval request email to the approver, and use a Lambda function to resume the pipeline upon approval.
D.Add a manual approval action to the pipeline between the build and deploy stages, and configure the SNS topic to notify the approvers.
AnswerD

Adding a manual approval action between the build and deploy stages creates a required gate that pauses pipeline execution, satisfying the constraint that only authorised personnel can approve production deployments. Configuring the SNS topic enables the pipeline to send email or SMS notifications to the designated approvers, ensuring they are alerted to review and approve the change before CodeDeploy proceeds.

Why this answer

AWS CodePipeline natively supports a manual approval action that can be inserted as a stage between build and deploy. This action pauses the pipeline and sends a notification via an SNS topic to the configured approvers. The pipeline only resumes when an authorized user clicks the 'Approve' button in the CodePipeline console or API, ensuring that only authorized personnel can approve production deployments.

Exam trap

The trap here is that candidates often confuse CodeDeploy's deployment configuration options (like traffic shifting or validation hooks) with pipeline-level approval actions, or they assume a custom Lambda function can replace the native approval action, missing the fact that CodePipeline provides a fully managed, auditable approval workflow.

How to eliminate wrong answers

Option A is wrong because AWS Lambda cannot act as a transition action in CodePipeline; transitions are automatic and cannot be replaced by custom functions. Option B is wrong because CodeDeploy deployment groups do not have a manual approval step in their deployment configuration; manual approvals are a pipeline-level feature, not a CodeDeploy feature. Option C is wrong because while an SNS topic can send approval emails, using a Lambda function to resume the pipeline bypasses the built-in approval workflow and security controls of CodePipeline, and the pipeline would not properly wait for the approval response.

Practice this question →
29
MCQhard

A DevOps engineer is troubleshooting an AWS OpsWorks for Chef Automate deployment. The Chef server is configured with a custom run list that includes a recipe to install and configure an application. The test environment works correctly, but in the production environment, the application fails to start. The Chef client logs show that the recipe executed successfully, but the application process is not running. What is the most likely cause of this issue?

A.The OpsWorks stack is configured to use 'auto-healing' which automatically terminates and replaces instances that fail to start the application.
B.The Chef server in production is running a different version of Chef than the test environment, causing the recipe to behave differently.
C.The IAM instance profile attached to the production EC2 instance does not have the necessary permissions to start the application service.
D.The Chef recipe does not include a 'service' resource to start the application; it only installs the package.
AnswerC

The instance profile must allow actions like ec2:StartInstances or ssm:StartAutomationExecution if the recipe uses those, or the application may need permissions to access resources.

Why this answer

The IAM instance profile determines the AWS API permissions available to the EC2 instance. If the profile lacks permissions to call the service startup API (e.g., `ec2:StartInstances` or `autoscaling:CompleteLifecycleAction`), or to access required resources like an EFS mount target or Secrets Manager secret, the Chef recipe's service resource may execute without error but the underlying systemd or init daemon cannot actually start the application process. The Chef client logs only show recipe execution success, not the outcome of the service start, so the application fails silently.

Exam trap

The trap here is that candidates assume a successful Chef client run guarantees the application is running, but the exam tests the distinction between recipe execution success and the actual outcome of system commands that depend on IAM permissions.

How to eliminate wrong answers

Option A is wrong because auto-healing in OpsWorks replaces instances that fail health checks, not instances where an application fails to start after successful recipe execution; the scenario describes a post-deployment failure, not an instance-level health failure. Option B is wrong because Chef server version differences would typically cause syntax or resource errors during recipe compilation, not a silent failure where the recipe executes successfully but the application does not run; the logs confirm successful execution. Option D is wrong because the question states the recipe includes a custom run list to install and configure the application, and the logs show successful execution; if the recipe lacked a service resource, the application would never be started, but the logs would not show a successful start attempt—the issue is that the start attempt fails due to permissions.

Practice this question →
30
MCQeasy

A DevOps engineer wants to ensure that all EC2 instances launched in an AWS account automatically have a specific set of tags applied for cost allocation. Which AWS service should they use to enforce this?

A.AWS Service Catalog
B.AWS Config
C.Amazon EC2 Auto Scaling
D.AWS CloudFormation
AnswerB

AWS Config is the correct choice because it provides a continuous, account-wide compliance evaluation of resource configurations. You can use the managed AWS Config rule 'required-tags' (or a custom Lambda-backed rule) to check that every EC2 instance has the mandatory tags, and the rule can be paired with an auto-remediation action, such as an SSM Automation document, to automatically add missing tags. Since AWS Config records every EC2 instance as a configuration item and re-evaluates on configuration changes, it can both detect and enforce tag compliance for all existing and newly launched instances, regardless of how they were created.

Why this answer

AWS Config is correct because it can enforce tagging rules through managed rules like `required-tags` or custom AWS Config rules using AWS Lambda. When an EC2 instance is launched without the required tags, AWS Config can evaluate the resource against the rule and trigger remediation actions (e.g., via AWS Systems Manager Automation) to automatically apply the tags or flag non-compliance. This ensures consistent cost allocation tagging across all instances without manual intervention.

Exam trap

The trap here is that candidates confuse AWS Config's evaluation and remediation capabilities with the tagging features of EC2 Auto Scaling or CloudFormation, mistakenly thinking those services can enforce tags on all instances account-wide, when they only apply to resources they directly manage.

How to eliminate wrong answers

Option A is wrong because AWS Service Catalog is used to create and manage a catalog of approved IT services (e.g., pre-configured EC2 instances), but it does not enforce tagging on instances launched outside its portfolio or retroactively. Option C is wrong because Amazon EC2 Auto Scaling can apply tags to instances it launches via launch templates or configurations, but it cannot enforce tags on instances launched directly via the EC2 console, API, or other services. Option D is wrong because AWS CloudFormation can apply tags to resources it creates, but it cannot enforce tagging on resources created outside of a CloudFormation stack, such as manually launched EC2 instances.

Practice this question →
31
MCQhard

A company uses AWS CloudFormation StackSets to deploy a VPC across multiple AWS accounts in AWS Organizations. The StackSet is created with self-managed permissions. The deployment fails in some accounts with the error: 'Insufficient IAM permissions to create resources'. What is the most likely cause of this failure?

A.The StackSet does not support deploying to more than one account
B.The execution IAM role is not created in the target accounts
C.The administrator account does not have a service-linked role for StackSets
D.The target accounts have reached their resource service quotas
AnswerB

Self-managed permissions require an execution role in each target account.

Why this answer

With self-managed permissions in AWS CloudFormation StackSets, the administrator account does not automatically create the necessary IAM roles in target accounts. The execution IAM role must be manually created in each target account to grant StackSets the permissions required to create resources. The error 'Insufficient IAM permissions to create resources' directly indicates that this execution role is missing or lacks the required policies.

Exam trap

The trap here is that candidates often confuse self-managed and service-managed permissions, assuming that StackSets automatically handle IAM roles in target accounts, when in fact self-managed requires manual role creation in each target account.

How to eliminate wrong answers

Option A is wrong because StackSets are specifically designed to deploy stacks across multiple accounts and regions, so deploying to more than one account is a core feature, not a limitation. Option C is wrong because service-linked roles are not required for StackSets with self-managed permissions; they are used with service-managed permissions when StackSets integrates with AWS Organizations. Option D is wrong because resource service quotas would produce a different error message (e.g., 'Resource limit exceeded'), not an IAM permissions error.

Practice this question →
32
Multi-Selectmedium

A company uses AWS Config to evaluate resource compliance. They have a custom AWS Config rule that checks whether EC2 instances have a specific tag. The rule is triggered by configuration changes. The DevOps engineer notices that the rule evaluation results show 'NON_COMPLIANT' for some instances that actually have the tag. Which TWO could be causes? (Choose TWO.)

Select 2 answers
A.The rule's maximum execution frequency is set to 24 hours
B.The Lambda function that evaluates the rule has a logic error
C.The rule is not being triggered by CloudTrail events
D.The rule is configured to evaluate only for a specific resource type that does not include EC2
E.The AWS Config service role does not have permission to invoke the Lambda function
AnswersB, E

Correct. A logic error in the Lambda function can cause false NON_COMPLIANT results despite the tag being present.

Why this answer

A logic error in the Lambda function evaluating the custom rule can cause it to incorrectly mark compliant resources as NON_COMPLIANT, such as misinterpreting the tag key/value or case sensitivity. Option E is correct because if the AWS Config service role lacks permission to invoke the Lambda function, the evaluation fails. If the custom rule has a default compliance value of NON_COMPLIANT for evaluation failures, the resource will be marked NON_COMPLIANT even though the tag is present.

Exam trap

The trap is that candidates may focus on evaluation failures (like permission issues) causing 'Failed' status, but if the custom rule's default compliance is set to NON_COMPLIANT, a permission error results in NON_COMPLIANT. Also, resource type scoping errors lead to 'Not evaluated', not NON_COMPLIANT.

Practice this question →
33
Multi-Selecthard

A DevOps engineer is designing an infrastructure as code solution for a microservices application that runs on Amazon ECS with Fargate. The application requires a shared Application Load Balancer (ALB) and multiple ECS services. Which CloudFormation resources are required to expose each service behind the ALB? (Choose THREE.)

Select 3 answers
A.AWS::ElasticLoadBalancingV2::Listener
B.AWS::ElasticLoadBalancingV2::LoadBalancer
C.AWS::ECS::Service
D.AWS::ElasticLoadBalancingV2::ListenerRule
E.AWS::AutoScaling::AutoScalingGroup
AnswersA, C, D

The listener receives incoming traffic on a specific port.

Why this answer

AWS::ElasticLoadBalancingV2::Listener is correct because it defines the protocol and port (e.g., HTTP:80) on which the ALB accepts traffic. Without a listener, the ALB cannot receive incoming requests. This resource is essential for routing traffic to target groups that are associated with ECS services.

Exam trap

The trap here is that candidates often select the LoadBalancer resource (Option B) thinking it is required for each service, but the LoadBalancer is a shared resource created once, while the Listener, ListenerRules, and ECS Service are the per-service components that enable routing.

Practice this question →
34
Multi-Selecteasy

A DevOps team wants to manage EC2 instance configurations using AWS Systems Manager. Which THREE capabilities of Systems Manager can be used to ensure instances are in a desired state? (Choose THREE.)

Select 3 answers
A.Run Command
B.OpsCenter
C.Parameter Store
D.Patch Manager
E.State Manager
AnswersA, D, E

Run Command is a Systems Manager capability that lets you execute shell scripts or PowerShell commands on one or more EC2 instances via the SSM Agent, without the need for SSH/RDP or opening inbound ports. By invoking documents like AWS-RunShellScript or AWS-RunPowerShellScript, you can directly enforce configuration settings, install software, or remediate configuration drift on demand. It supports rate control, error thresholds, and IAM-based permission scoping, making it a direct and flexible mechanism for enforcing instance configuration.

Why this answer

Run Command (A) is correct because it allows you to remotely and securely execute scripts or commands across EC2 instances without needing SSH or RDP, using an SSM document (SSM Document) that defines the desired configuration actions. This capability directly enforces a desired state by running idempotent scripts on demand or on a schedule.

Exam trap

The trap here is confusing Parameter Store (a data store) with a configuration management tool, or thinking OpsCenter (an operations dashboard) can enforce state, when only Run Command, State Manager, and Patch Manager directly execute actions to achieve and maintain a desired configuration.

Practice this question →
35
MCQhard

Refer to the exhibit. A DevOps engineer is troubleshooting an issue where an IAM user is unable to stop an EC2 instance with the tag 'Environment: Development'. The attached IAM policy is shown. Which statement explains the failure?

A.The Deny statement condition incorrectly uses StringNotEquals, which denies all instances except those with the Production tag.
B.The Deny statement includes ec2:StopInstances implicitly because stop is a termination action.
C.The Allow statement only grants ec2:DescribeInstances, not start/stop.
D.The policy does not prevent stopping instances with the Development tag; the failure must be caused by another policy or service control policy.
AnswerC

The policy's only explicit Allow is ec2:DescribeInstances; because ec2:StopInstances is a separate action in the IAM action namespace, no permission is granted to perform a stop. When the user calls StopInstances, IAM finds no allow and defaults to an implicit deny, so the API request fails. The Deny statement on RunInstances does not counteract this, so the missing start/stop Allow is precisely the cause.

Why this answer

The IAM policy in the exhibit only grants ec2:DescribeInstances and explicitly denies ec2:RunInstances with a condition. It does not include an Allow for ec2:StopInstances. By default, IAM denies any action that is not explicitly allowed.

Therefore, the user lacks permission to stop instances, including the Development-tagged instance. Option C correctly identifies this as the reason for the failure. Option D is incorrect because the policy itself denies stop implicitly due to the missing Allow; it is not necessary to invoke another policy or SCP.

Exam trap

The trap here is that candidates misread the Deny statement's action (ec2:RunInstances) and condition (StringNotEquals) as applying to stopping instances, when in fact it only affects launching instances, leading them to incorrectly select Option A or B without noticing the action mismatch.

How to eliminate wrong answers

Option A is wrong because the Deny statement uses ec2:RunInstances, not ec2:StopInstances, and the StringNotEquals condition applies to launching instances, not stopping them; it does not deny stopping Development instances. Option B is wrong because the Deny statement explicitly lists ec2:RunInstances, and AWS IAM does not implicitly include ec2:StopInstances under termination actions; stop and terminate are separate actions. Option C is wrong because while the Allow statement only grants ec2:DescribeInstances, the question asks why the user cannot stop the instance; the lack of an explicit allow for ec2:StopInstances would cause a default implicit deny, but the policy itself does not prevent stopping—the failure must be from another policy or SCP, as the provided policy does not deny stop actions.

Practice this question →
36
MCQmedium

A company uses AWS CodePipeline to deploy a Node.js application to AWS Elastic Beanstalk. The pipeline includes a build stage using AWS CodeBuild. Developers notice that the deployed application occasionally crashes due to missing environment variables that were configured in the Elastic Beanstalk environment but not passed from CodeBuild. What is the MOST efficient way to ensure the environment variables are consistently applied?

A.Define environment variables in the source code using .ebextensions configuration files.
B.Update the environment variables manually in the Elastic Beanstalk console after each deployment.
C.Use the aws elasticbeanstalk update-environment CLI command after the pipeline completes.
D.Store environment variables in AWS Systems Manager Parameter Store and have the application retrieve them at runtime.
AnswerA

Commit the variables in a .ebextensions/*.config file (e.g., option_settings for namespace aws:elasticbeanstalk:application:environment). CodePipeline packages the entire source into the application version, and the Elastic Beanstalk deployment agent processes this file automatically, injecting the values into the Node.js process's environment. This makes environment configuration declarative, versioned, and reproducible for every pipeline run, eliminating manual or post-deployment steps.

Why this answer

Ebextensions configuration files allow you to define environment variables declaratively in the source code, ensuring they are consistently applied during every deployment via CodePipeline. This approach eliminates the dependency on runtime or manual steps, as the Elastic Beanstalk environment automatically reads these files during environment creation and updates. It integrates seamlessly with CodeBuild and CodePipeline, making it the most efficient and reliable method for maintaining environment variable consistency.

Exam trap

The trap here is that candidates often assume runtime parameter retrieval (e.g., from Parameter Store or Secrets Manager) is the best practice for all scenarios, but for environment variables required at process startup in Elastic Beanstalk, .ebextensions provide a more reliable and simpler solution that avoids application code changes and ensures variables are set before the application runs.

How to eliminate wrong answers

Option B is wrong because manually updating environment variables in the Elastic Beanstalk console after each deployment is error-prone, not scalable, and violates the principle of infrastructure as code, leading to configuration drift. Option C is wrong because using the aws elasticbeanstalk update-environment CLI command after the pipeline completes introduces an extra post-deployment step that can fail or be forgotten, and it does not tie the variables to the source code version, making rollbacks inconsistent. Option D is wrong because while Parameter Store can be used for runtime retrieval, it requires application code changes to fetch variables at startup, adds latency, and does not guarantee the variables are present during the Elastic Beanstalk environment initialization, potentially causing crashes before the application code runs.

Practice this question →
37
MCQmedium

A company uses AWS CloudFormation to manage its infrastructure. The DevOps team wants to ensure that critical resources, such as an RDS database, are not accidentally deleted when a stack is updated or deleted. Which CloudFormation feature should be used to prevent this?

A.DeletionPolicy attribute with Retain
B.Stack policy
C.Termination protection
D.DependsOn attribute
AnswerA

DeletionPolicy: Retain on a resource instructs AWS CloudFormation to preserve that physical resource when the stack is deleted. Without it, DeleteStack removes every resource in the template; with Retain, the resource is simply left in place and becomes orphaned, allowing you to keep critical data such as databases or S3 buckets. This is the standard way to prevent accidental data loss during stack deletion.

Why this answer

The DeletionPolicy attribute with the Retain value is the correct choice because it explicitly instructs CloudFormation to preserve the physical resource (e.g., an RDS database) when its corresponding logical resource is deleted from the stack template during an update or when the entire stack is deleted. This prevents accidental deletion of critical stateful resources by ensuring the resource remains in the AWS account even after the stack operation completes.

Exam trap

The trap here is that candidates confuse termination protection (an EC2-specific feature) with CloudFormation's DeletionPolicy, or mistakenly think a stack policy can prevent deletion during a full stack deletion, when it only restricts update operations.

How to eliminate wrong answers

Option B is wrong because a stack policy is an IAM-like resource-level policy that controls which stack resources can be updated or deleted during a stack update, but it does not prevent deletion when the entire stack is deleted; it only restricts update/delete actions during an update operation. Option C is wrong because termination protection is an EC2 instance-level feature that prevents accidental termination of an EC2 instance, not a CloudFormation feature and not applicable to RDS databases. Option D is wrong because the DependsOn attribute only specifies resource creation order within a stack template; it has no effect on preventing deletion of resources during stack updates or deletions.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Configuration Management and IaC questions.

Start 20-question session