Courseiva

CCNA Configuration Management and IaC Questions

75 of 215 questions · Page 1/3 · Configuration Management and IaC · Answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

A DevOps engineer is designing a CI/CD pipeline for an application that runs on Amazon ECS. The pipeline should automatically build a Docker image from source code, push it to Amazon ECR, and deploy it to the ECS service. The engineer wants to use AWS CodePipeline with Amazon ECR as a source. Which action provider should be used for the deploy stage?

A.AWS CloudFormation
B.AWS CodeDeploy
C.Amazon ECS
D.AWS Elastic Beanstalk
AnswerC

The Amazon ECS deploy action provider is the native integration in CodePipeline for pushing a new container image or task definition to an existing ECS service. When this action runs, it registers the revised task definition and calls UpdateService so the service starts a deployment with the new image. This makes it the correct, minimal-action choice for an ECS-based application pipeline, as it avoids abstracting the deployment behind another compute platform.

Why this answer

Amazon ECS is the correct action provider for the deploy stage when using AWS CodePipeline because it directly integrates with ECS to update an existing ECS service with a new task definition. When Amazon ECR is configured as a source, CodePipeline detects image pushes, and the ECS deploy action automatically triggers a rolling update of the ECS service using the new image, without requiring additional deployment tools.

Exam trap

The trap here is that candidates often confuse the Amazon ECS deploy action with AWS CodeDeploy, but CodeDeploy is only required for ECS blue/green deployments, while the Amazon ECS action directly handles rolling updates and is the simplest choice for standard ECS service deployments.

How to eliminate wrong answers

Option A is wrong because AWS CloudFormation is an infrastructure-as-code service used to provision and manage AWS resources, not a direct deploy action for updating an ECS service with a new Docker image; using it would require custom scripts and adds unnecessary complexity. Option B is wrong because AWS CodeDeploy can deploy to ECS only when using the ECS blue/green deployment type, which requires an additional CodeDeploy application and deployment group setup, but the question asks for the simplest direct deploy action provider for ECS, which is Amazon ECS itself. Option D is wrong because AWS Elastic Beanstalk is a PaaS service for deploying web applications, not designed for ECS service deployments; it abstracts underlying infrastructure and does not provide a native action to update an ECS service with a new image from ECR.

Practice this question →
2
MCQhard

A DevOps engineer is troubleshooting a CloudFormation stack creation failure. The stack includes an AWS::EC2::Instance with a UserData script. The stack creation fails with the error: 'The following resource(s) failed to create: [EC2Instance]. The requested configuration is currently not supported. Please check the documentation for supported configurations.' The engineer suspects the instance type is not supported in the selected Availability Zone. Which action should the engineer take to resolve this issue and ensure successful stack creation?

A.Add an Availability Zone parameter and map it to an AZ that supports the instance type, or use the AWS::EC2::Instance AvailabilityZone property to specify an AZ that supports the instance type.
B.Use AWS OpsWorks to deploy the instance instead of CloudFormation.
C.Change the instance type to a previous generation that is supported in all AZs.
D.Modify the template to specify a different region that supports the instance type.
AnswerA

The error occurs because CloudFormation did not explicitly specify an Availability Zone, so AWS placed the instance in an AZ that does not offer the selected instance type. By adding an Availability Zone parameter that is constrained to zones where the instance type is supported—or by setting the AvailabilityZone property directly on the AWS::EC2::Instance resource—you force EC2 to launch in a compatible AZ. This addresses the root cause without changing the instance type, region, or underlying architecture.

Why this answer

The error indicates the instance type is not supported in the default Availability Zone (AZ) selected by CloudFormation. By explicitly specifying an AZ that supports the instance type via the `AvailabilityZone` property or by parameterizing the AZ, the engineer can override the default AZ selection and resolve the incompatibility. This approach directly addresses the root cause without changing the instance type or region.

Exam trap

The trap here is that candidates may assume the instance type itself is unsupported in the entire region and choose to change the region or instance type, rather than recognizing that the error is AZ-specific and can be resolved by explicitly specifying a supported Availability Zone.

How to eliminate wrong answers

Option B is wrong because AWS OpsWorks is a configuration management service that does not solve the underlying AZ compatibility issue; it would still rely on the same EC2 instance type and AZ constraints. Option C is wrong because changing to a previous generation instance type is unnecessary and may not be supported in all AZs either; the goal is to keep the desired instance type and find a compatible AZ. Option D is wrong because specifying a different region is an overreaction; the issue is AZ-specific within the current region, and changing the region may introduce other compatibility or latency issues.

Practice this question →
3
MCQeasy

A company uses AWS Systems Manager to manage configuration compliance. They want to ensure that all EC2 instances have a specific security patch installed. Which Systems Manager capability should they use?

A.Automation
B.Parameter Store
C.State Manager
D.Patch Manager
AnswerD

Patch Manager is the purpose-built Systems Manager capability that automates the process of patching managed nodes. It uses patch baselines to determine which patches are approved or rejected, and it can either scan for missing patches or install them directly on EC2 instances and on-premises servers. Patch Manager supports both Linux and Windows, integrates with maintenance windows and compliance reporting, and is the correct answer because it directly handles patch configuration and deployment.

Why this answer

Patch Manager is the correct Systems Manager capability because it is specifically designed to automate the process of patching managed instances with security updates and other types of patches. It can scan for missing patches and enforce compliance by applying patches on a schedule or on demand, directly addressing the requirement to ensure all EC2 instances have a specific security patch installed.

Exam trap

The trap here is that candidates often confuse State Manager (which manages configuration state) with Patch Manager (which specifically handles patch compliance), or they assume Automation can handle patching because it can run scripts, but Patch Manager provides the dedicated patching workflow and compliance reporting.

How to eliminate wrong answers

Option A is wrong because Automation is used to automate common maintenance and deployment tasks (e.g., creating AMIs, running scripts) but does not natively handle patch scanning or installation workflows. Option B is wrong because Parameter Store is a secure hierarchical store for configuration data and secrets, not a patching mechanism. Option C is wrong because State Manager is used to define and maintain consistent configuration of instances (e.g., ensuring a file exists or a service is running) but does not include built-in patch scanning or remediation capabilities.

Practice this question →
4
MCQeasy

A DevOps engineer needs to manage configuration files for multiple applications across several EC2 instances. The configuration values are sensitive (e.g., database passwords) and must be encrypted at rest and in transit. Which AWS service should be used to store and retrieve these configuration values?

A.AWS Systems Manager Parameter Store (SecureString)
B.AWS CloudFormation template parameters
C.Amazon DynamoDB with encryption
D.Amazon S3 with server-side encryption
AnswerA

The AWS Systems Manager Parameter Store is purpose-built for configuration management, providing a secure, hierarchical namespace for keys and values. A SecureString parameter uses AWS KMS encryption at rest and in transit, and integrates natively with EC2 via the SSM agent or SDK without exposing plaintext. It supports versioning, tagging, and IAM policies for fine-grained access, making it the right choice for dynamic runtime retrieval.

Why this answer

AWS Systems Manager Parameter Store with the SecureString parameter type uses AWS KMS to encrypt values at rest and enforces TLS for values in transit, making it purpose-built for storing sensitive configuration such as database passwords. It integrates natively with EC2 instance profiles and IAM, so applications can retrieve secrets without embedding credentials in code or AMIs. This is the canonical DOP-C02 answer for encrypted configuration management.

Exam trap

DOP-C02 often tests the distinction between a configuration store (Parameter Store) and a general-purpose data store (S3, DynamoDB), so candidates pick S3 SSE or DynamoDB encryption thinking 'encrypted at rest' is the only requirement.

How to eliminate wrong answers

Option B is wrong because CloudFormation template parameters are only input values passed at stack creation/update time; they are not a persistent, encrypted-at-rest store and are visible in stack metadata and change sets. Option C is wrong because DynamoDB is a NoSQL database, not a configuration/secret store — encryption at rest exists but there is no SecureString semantics, no native parameter versioning, and it adds unnecessary cost and operational overhead. Option D is wrong because S3 server-side encryption protects objects at rest but does not provide a configuration-management API, parameter versioning, or the IAM-scoped retrieval model that Parameter Store offers.

Practice this question →
5
MCQhard

A company uses AWS CodeBuild to build a Java application. The buildspec.yml file includes a post_build phase that runs a script to package the application and upload it to an Amazon S3 bucket. The build is failing with an error indicating that the S3 bucket is not accessible. The CodeBuild service role has the AmazonS3FullAccess managed policy attached. The S3 bucket is in a different AWS account. Which action should the DevOps engineer take to resolve the issue?

A.Add a bucket policy to the S3 bucket that grants the CodeBuild service role permissions to PutObject.
B.Configure the S3 bucket to allow public write access.
C.Enable cross-account access in the CodeBuild project settings.
D.Modify the CodeBuild service role to include the s3:PutObject permission for the specific bucket ARN.
AnswerA

When the S3 bucket is in a different account, the CodeBuild service role needs explicit permission from the bucket owner. The AmazonS3FullAccess policy grants permissions within the same account, but cross-account access requires a bucket policy that allows the role to perform actions. Adding a bucket policy that grants PutObject to the CodeBuild service role resolves the access issue.

Why this answer

Cross-account access to S3 requires a bucket policy that explicitly grants permissions to the external IAM role. The CodeBuild service role already has S3 permissions in its own account, but the bucket policy in the target account must allow the role to perform PutObject. Therefore, adding a bucket policy is the correct resolution.

Exam trap

The trap here is assuming that attaching AmazonS3FullAccess to the CodeBuild service role is sufficient for cross-account access, but it only grants permissions within the same account.

Practice this question →
6
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 →
7
MCQhard

An organization uses AWS OpsWorks for configuration management. They have a stack with multiple layers, including a PHP application layer and a MySQL database layer. The operations team needs to deploy a custom configuration file to all PHP application instances. How should this be accomplished using OpsWorks?

A.Use the OpsWorks agent to directly copy the file to each instance via SSH.
B.Add the configuration file as a stack-level custom cookbook and assign it to all layers.
C.Create a custom cookbook with a recipe that deploys the configuration file, and assign it to the Deploy lifecycle event of the PHP layer.
D.Use a custom JSON attribute in the stack settings to define the file content, and then use a built-in recipe to apply it.
AnswerC

A custom cookbook can contain a recipe with Chef resources like 'template' or 'file' that renders the configuration file content to the exact path expected by PHP on each instance. Assigning that recipe to the Deploy lifecycle event of the PHP layer ensures it runs only during a deployment operation on that layer, and only on instances that belong to the PHP layer. This approach is fully automated, idempotent, and version-controlled, and it aligns with OpsWorks best practices by using the layer-specific lifecycle hook to scope execution precisely.

Why this answer

OpsWorks uses Chef cookbooks to manage configuration. By creating a custom cookbook with a recipe that deploys the configuration file and assigning it to the Deploy lifecycle event of the PHP layer, the recipe runs on all PHP application instances during deployment, ensuring the file is placed correctly. This approach leverages OpsWorks' built-in lifecycle events and Chef's idempotent execution model.

Exam trap

The trap here is that candidates confuse stack-level custom cookbooks (which apply to all layers) with layer-specific lifecycle event assignments, leading them to choose Option B, which would incorrectly deploy the configuration file to the MySQL layer as well.

How to eliminate wrong answers

Option A is wrong because the OpsWorks agent does not support direct SSH file copying; OpsWorks uses Chef recipes to manage instances, and manual SSH operations bypass automation and are not scalable. Option B is wrong because stack-level custom cookbooks are assigned to layers, not to all layers automatically; assigning a cookbook to all layers would run its recipes on every instance, including the MySQL layer, which is not desired. Option D is wrong because custom JSON attributes can pass data to recipes but cannot directly deploy files; a custom recipe is required to interpret the JSON and write the file.

Practice this question →
8
Multi-Selecthard

A company uses AWS CodeBuild to build and test their application. They want to integrate Infrastructure as Code (IaC) scanning into their build pipeline to detect security misconfigurations in CloudFormation templates before deployment. Which TWO tools or services can be used for this purpose? (Choose TWO.)

Select 2 answers
A.AWS CloudFormation Guard
B.AWS Security Hub
C.AWS Config
D.HashiCorp Terraform
E.cfn-nag
AnswersA, E

CloudFormation Guard is a policy-as-code engine from AWS that uses a Guard-specific DSL to define rules for template properties like encryption, tags, and allowed resource types. It reads CloudFormation JSON/YAML directly and can be invoked in CodeBuild via the `cfn-guard` CLI to fail the build when a violation is found. This enables automated, pre-deployment compliance checks, which is exactly what the scenario requires.

Why this answer

AWS CloudFormation Guard (cfn-guard) is a policy-as-code tool that allows you to define rules to enforce compliance and security best practices on CloudFormation templates. It can be integrated into a CodeBuild pipeline to scan templates for misconfigurations before deployment, making it a correct choice for IaC security scanning.

Exam trap

The trap here is that candidates may confuse AWS Config (which evaluates deployed resources) with a pre-deployment scanning tool, or assume Security Hub can scan templates directly, when in fact both operate on live infrastructure, not on template files.

Practice this question →
9
MCQmedium

A company uses AWS CodeDeploy to deploy applications to an Auto Scaling group. During a deployment, the deployment fails because the target instances are not passing the health checks. The DevOps engineer notices that the CodeDeploy agent logs show 'The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems.' Which step should the engineer take to diagnose the issue?

A.Increase the size of the Auto Scaling group to ensure more instances are available.
B.Review the CodeDeploy deployment logs on a failed instance to identify script errors.
C.Create a CloudWatch alarm to monitor the deployment health.
D.Check AWS CloudTrail logs for the CodeDeploy API calls to see if permissions are missing.
AnswerB

The CodeDeploy agent on the failed instance writes execution logs that include the full stdout and stderr for every lifecycle event hook, such as BeforeInstall and ApplicationStop. These logs are available at /var/log/aws/codedeploy-agent/codedeploy-agent.log and under /opt/codedeploy-agent/deployment-root/deployment-logs, and they reveal the exact script command that failed and the error message. Reviewing these logs is the only way to directly observe the script's runtime behavior, making it the correct first step in troubleshooting.

Why this answer

The error message indicates that individual instances failed deployment, and the CodeDeploy agent logs on a failed instance contain detailed script output (e.g., AppSpec hooks like BeforeInstall, AfterInstall, ApplicationStart) that reveal the root cause, such as a missing dependency or incorrect file path. Reviewing these logs directly identifies script errors, which is the most targeted diagnostic step before considering infrastructure changes.

Exam trap

The trap here is that candidates often jump to infrastructure-level fixes (like scaling or monitoring) when the error message clearly points to per-instance script failures, which require examining the CodeDeploy agent logs on a failed instance.

How to eliminate wrong answers

Option A is wrong because increasing the Auto Scaling group size does not address the root cause of why instances are failing health checks; it only adds more instances that would likely fail with the same error. Option C is wrong because creating a CloudWatch alarm monitors deployment health over time but does not provide the granular, per-instance script execution details needed to diagnose why a specific deployment failed. Option D is wrong because CloudTrail logs record API calls (e.g., CreateDeployment, UpdateDeploymentGroup) and can show permission issues, but the error message explicitly states instances failed deployment, not an authorization failure; missing permissions would typically cause a different error (e.g., 'AccessDenied') during the deployment initiation, not during health checks.

Practice this question →
10
MCQeasy

A DevOps team is using AWS CloudFormation to manage infrastructure. They want to reuse the same template across multiple environments (dev, test, prod) with minor parameter variations. Which CloudFormation feature should they use to pass environment-specific values without modifying the template?

A.Conditions
B.Outputs
C.Mappings
D.Parameters
AnswerD

Parameters are the designated CloudFormation feature for passing environment-specific values, such as instance types, AMI IDs, or environment names, into a template during stack creation or update. They are declared in the template and can be referenced via Ref or Fn::Sub, allowing users to supply input without editing the template, with optional constraints like AllowedValues, type validation, and NoEcho for sensitive data. This makes Parameters exactly what the DevOps team needs for dynamic per-environment configuration.

Why this answer

CloudFormation Parameters let you pass environment-specific values (like instance sizes, CIDR ranges, or environment names) into a template at stack creation or update time without modifying the template itself. This is exactly the use case described: one template, multiple environments, different values supplied at deploy time via the console, CLI, or a parameters file.

Exam trap

DOP-C02 often tests the confusion between Parameters (inputs at deploy time) and Mappings (static in-template lookups) — candidates pick Mappings thinking they allow per-environment variation, but Mappings require editing the template, which the question explicitly forbids.

How to eliminate wrong answers

Option A is wrong because Conditions control whether resources are created based on a boolean expression — they do not pass environment-specific values into the template. Option B is wrong because Outputs export values from a stack (like resource ARNs) for cross-stack references; they do not feed values in. Option C is wrong because Mappings are static lookup tables hardcoded in the template (e.g., region-to-AMI-ID), which would require editing the template to change per-environment values — the opposite of what is needed.

Practice this question →
11
MCQmedium

A team is using AWS CodeDeploy to deploy an application to EC2 instances. They want to ensure that if a deployment fails, the instances are automatically rolled back to the previous version. What should they configure?

A.Add a BeforeBlockTraffic hook to the AppSpec file to run a rollback script.
B.Set the deployment configuration to 'CodeDeployDefault.OneAtATime' for a gradual deployment.
C.Configure the deployment group to use the same Auto Scaling group for rollback.
D.Enable automatic rollback in the deployment group settings.
AnswerD

Enabling automatic rollback in the deployment group settings is the correct native mechanism for requiring CodeDeploy to redeploy the last successful revision when a deployment fails. This feature can also be configured to roll back when a deployment hits a limit or when a CloudWatch alarm triggers, making it flexible for various failure scenarios. It is precisely what the team needs to achieve automatic recovery without manual intervention.

Why this answer

CodeDeploy supports automatic rollback configuration. When enabled, if a deployment fails, CodeDeploy automatically redeploys the last successful revision. Option A is wrong because a hook is a lifecycle event, not a rollback mechanism.

Option B is wrong because a deployment group contains instances but does not have a rollback setting. Option C is wrong because a deployment configuration specifies traffic routing and failure thresholds, not automatic rollback.

Practice this question →
12
MCQhard

A company uses AWS OpsWorks for configuration management. The DevOps team wants to run a custom recipe on all instances in a layer during stack updates. Which OpsWorks lifecycle event should they hook the recipe into?

A.Deploy
B.Shutdown
C.Configure
D.Setup
AnswerD

The Setup lifecycle event is specifically designed to run on an instance after it has been booted and registered with the stack, but before it is available. This event is intended for initial configuration tasks that need to happen only once, such as installing packages, creating directories, or setting up system users. In AWS OpsWorks, the Setup event is part of the standard lifecycle (Setup -> Configure -> Deploy -> Undeploy -> Shutdown) and is the correct lifecycle event for boot-time provisioning tasks, making it the answer to this question.

Why this answer

The Setup lifecycle event runs on every instance in a layer when it first boots or during a stack update, making it the correct hook for running a custom recipe that must execute on all instances during updates. This event occurs after the instance is fully configured and before it enters service, ensuring the recipe runs consistently across the layer.

Exam trap

The trap here is that candidates confuse the Configure event (which runs on all instances during any state change) with the Setup event (which is specifically designed for initial and update-time configuration), leading them to pick Configure because it seems more broadly applicable.

How to eliminate wrong answers

Option A (Deploy) is wrong because the Deploy event is triggered only when you manually run a 'deploy' command or use the Deploy action, not automatically during stack updates. Option B (Shutdown) is wrong because the Shutdown event runs when an instance is being terminated, not during stack updates. Option C (Configure) is wrong because the Configure event runs on every instance in the stack whenever an instance enters or leaves the online state, but it is not specifically tied to stack updates and may run multiple times, whereas Setup is the intended lifecycle event for initial configuration and update scenarios.

Practice this question →
13
MCQhard

A company uses AWS CodeDeploy to deploy a web application to an Auto Scaling group. The deployment fails because the new instances cannot connect to the database. The previous deployment succeeded. The DevOps engineer checks the CodeDeploy deployment configuration and finds that the deployment uses the 'CodeDeployDefault.AllAtOnce' configuration. What is the MOST likely cause of the failure?

A.The load balancer health check is misconfigured, causing new instances to be deregistered.
B.The deployment group is not configured to handle traffic routing, causing a routing loop.
C.The security group for the Auto Scaling group was updated during deployment, blocking database access.
D.The deployment replaced all instances at once, causing a temporary loss of connectivity if the new application version has incompatible changes.
AnswerD

With an AllAtOnce deployment strategy, CodeDeploy stops every current instance at the same time, deploys the new application revision to each, and then restarts them; this creates a zero-capacity window where no instance is serving traffic. If the new revision contains incompatible changes—such as expecting a new database schema, missing environment variables, or a different API version—the restarted instances may fail to connect to the database, leaving the entire application unavailable until the issues are resolved. This is the classic failure mode of AllAtOnce deployments: every instance fails together, so a single backward-incompatibility causes a full, fleet-wide outage rather than a partial degradation.

Why this answer

The 'CodeDeployDefault.AllAtOnce' deployment configuration causes CodeDeploy to attempt to deploy the new application revision to all instances in the Auto Scaling group simultaneously. If the new application version contains incompatible changes—such as a database schema mismatch, altered connection strings, or missing environment variables—all instances will fail at the same time, resulting in a complete loss of connectivity to the database. This contrasts with a rolling or canary deployment, which would limit the blast radius by updating only a subset of instances at a time.

Exam trap

The trap here is that candidates may assume the failure is due to a misconfiguration (like security groups or health checks) rather than recognizing that the deployment strategy itself—replacing all instances at once—amplifies the impact of any application-level incompatibility.

How to eliminate wrong answers

Option A is wrong because a misconfigured load balancer health check would cause instances to be deregistered from the target group, but the failure described is that new instances cannot connect to the database—a connectivity issue, not a registration issue. Option B is wrong because CodeDeploy deployment groups do not handle traffic routing in a way that creates routing loops; traffic routing is managed by the load balancer, and a routing loop would affect all traffic, not just database connections. Option C is wrong because security groups are not updated automatically during a CodeDeploy deployment; the engineer would have to manually modify them, and the question states the previous deployment succeeded, implying no security group changes occurred.

Practice this question →
14
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 →
15
MCQeasy

A company uses AWS Systems Manager to manage a fleet of EC2 instances. The operations team needs to run a script on all instances that are missing a specific security patch. Which Systems Manager capability should be used to accomplish this?

A.Automation
B.State Manager
C.Run Command
D.Patch Manager
AnswerC

Run Command allows you to execute an SSM Document once on a target instance or fleet, on demand. It does not provide a scheduling feature or persistent association, so after the script finishes, there is no mechanism to automatically re-run it to handle future drift or new missing patches. While you could use EventBridge or other schedulers to invoke Run Command, State Manager natively supports recurring associations and compliance tracking, making Run Command insufficient for ongoing, monitored remediation.

Why this answer

Run Command lets you execute an SSM document (including an arbitrary shell/PowerShell script) once, on demand, against a targeted fleet of instances -- exactly what's needed to run a one-time remediation script across all instances missing a specific patch. It returns per-instance output/status immediately so you can confirm the script ran successfully. State Manager, by contrast, is built for enforcing a recurring/continuous desired state via scheduled associations and compliance tracking; since the requirement here is a single ad hoc script execution with no mention of an ongoing schedule or compliance reporting, State Manager would be unnecessary overhead.

Exam trap

The trap is to confuse Run Command with State Manager. Run Command is for one-time, ad-hoc execution without state tracking, whereas State Manager enforces a desired state on a schedule or continuously. Since the question only asks to 'run a script' and does not mention ongoing compliance or a schedule, Run Command is the correct capability.

How to eliminate wrong answers

Option A is wrong because Automation is used for performing complex, multi-step workflows (e.g., AMI creation, instance recovery) and is not designed for ongoing state enforcement or running scripts on a fleet based on missing patches. Option C is wrong because Run Command executes scripts or commands on instances on-demand without any state tracking or enforcement; it does not check for missing patches or ensure compliance over time. Option D is wrong because Patch Manager is specifically for scanning and applying OS patches using predefined patch baselines, not for running custom scripts; it cannot execute arbitrary scripts to address a specific missing patch.

Practice this question →
16
MCQeasy

A company uses AWS Elastic Beanstalk to deploy web applications. The DevOps team wants to implement a blue/green deployment strategy to minimize downtime. Which Elastic Beanstalk feature should be used?

A.Rolling update
B.Canary deployment
C.Environment URL swap
D.Immutable update
AnswerC

Swapping environment URLs is the canonical blue/green deployment mechanism in Elastic Beanstalk. You first provision a second environment (the 'green' one) with your new version, verify it, and then use 'Swap environment URLs' in the console or the SwapEnvironmentCNAMEs API to make the original environment's URL instantly point to the new environment. This switch is atomic at the DNS/CNAME level, providing zero downtime, and you can equally quickly swap back to the old environment to roll back. Unlike other deployment methods, this keeps two distinct environments with separate instance fleets and configurations, which is the essence of blue/green.

Why this answer

Elastic Beanstalk's environment URL swap feature enables blue/green deployment by routing traffic from the current (blue) environment to a new (green) environment via a simple DNS swap. This swap is instantaneous at the DNS level, resulting in zero downtime for users, as the green environment is fully tested before the swap occurs.

Exam trap

The trap here is that candidates confuse 'immutable update' with blue/green deployment, but immutable update still operates within a single environment and does not provide the independent, fully isolated environment that a true blue/green strategy requires.

How to eliminate wrong answers

Option A is wrong because rolling update deploys new application versions in batches across existing instances, which does not create a separate environment and can cause temporary downtime or reduced capacity. Option B is wrong because canary deployment is not a native Elastic Beanstalk feature; it requires external tools like AWS CodeDeploy or custom routing to shift a small percentage of traffic. Option D is wrong because immutable update launches a new set of instances in the same environment and then terminates the old ones, which still involves a brief traffic cutover within the same environment and does not provide a separate, fully independent environment for blue/green testing.

Practice this question →
17
MCQmedium

A company uses AWS Elastic Beanstalk to deploy a web application. They want to ensure that configuration changes (e.g., environment variables, instance type) are version-controlled and can be rolled back. Which strategy should they use?

A.Use AWS CloudFormation to manage the Beanstalk environment outside of Beanstalk.
B.Use Elastic Beanstalk saved configurations to store environment settings.
C.Store configuration in a configuration file (e.g., .ebextensions) included with the application source code.
D.Manually change environment configuration using the Elastic Beanstalk console when needed.
AnswerC

Configuration files placed in the .ebextensions directory of your application source bundle are processed by Elastic Beanstalk during environment creation and every deployment, allowing you to define option settings, environment variables, packages, and custom resources declaratively. Because these files live in source control alongside your application code, every versioned build contains its exact configuration, so rolling back to a previous application version also restores the matching configuration automatically. This versioned, source-code-integrated approach is the recommended method for environment configuration.

Why this answer

Storing configuration in .ebextensions files (YAML/JSON) within the application source bundle allows version control of environment settings (e.g., environment variables, instance type) alongside the code. When the application is deployed or updated, Elastic Beanstalk applies these configuration files automatically, enabling consistent rollback by redeploying a previous source bundle version. This approach integrates configuration management with the application lifecycle, ensuring that changes are tracked and reversible.

Exam trap

The trap here is that candidates often confuse saved configurations (Option B) with version-controlled configurations, but saved configurations are not tied to application versions and cannot be rolled back automatically with a source code deployment.

How to eliminate wrong answers

Option A is wrong because using AWS CloudFormation to manage the Beanstalk environment outside of Beanstalk introduces an external management layer that can lead to drift and does not inherently version-control configuration changes within the application source code; it also requires manual synchronization. Option B is wrong because Elastic Beanstalk saved configurations store environment settings separately from the source code, are not automatically applied during deployment, and do not provide version-controlled rollback tied to application versions. Option D is wrong because manually changing environment configuration via the Elastic Beanstalk console is not version-controlled, cannot be rolled back programmatically, and violates infrastructure-as-code principles.

Practice this question →
18
MCQhard

A company uses AWS CloudFormation to deploy a multi-tier application. The template includes an Amazon RDS DB instance. The DevOps team wants to update the DB instance class without downtime. What should they do?

A.Use a CloudFormation stack update with a 'ReplaceOnDelete' deletion policy on the DB instance.
B.Create a new DB instance with the new class, update the application to point to the new endpoint, and delete the old instance.
C.Update the DBInstanceClass property in the CloudFormation template and set 'ApplyImmediately: true'.
D.Modify the DB instance class using an RDS blue/green deployment, then update the CloudFormation stack to match the new class.
AnswerD

RDS Blue/Green Deployments let you provision a staging 'green' environment that stays synchronized with the production 'blue' environment via logical replication, allowing you to change the DB instance class in the green environment with zero impact on production. After validation, you perform a switchover that flips the endpoint with minimal downtime and no data loss. Then you update the CloudFormation stack's DBInstanceClass property to match the new instance class, ensuring your infrastructure-as-code template reflects the actual state and preventing drift.

Why this answer

RDS blue/green deployments allow you to make changes (such as modifying the DB instance class) with minimal downtime by creating a staging environment that mirrors the production environment. After the change is applied and verified, the blue/green deployment switches traffic to the new environment, ensuring zero or near-zero downtime. Subsequently, updating the CloudFormation stack to match the new class keeps the infrastructure code in sync with the actual deployed resources.

Exam trap

The trap here is that candidates often assume 'ApplyImmediately: true' is a valid zero-downtime solution, but in reality it triggers an immediate reboot for instance class changes, causing downtime, whereas blue/green deployments are the correct AWS-native method for minimizing downtime during such modifications.

How to eliminate wrong answers

Option A is wrong because 'ReplaceOnDelete' is not a valid deletion policy attribute in CloudFormation; the correct attribute is 'DeletionPolicy' with values like 'Delete', 'Retain', or 'Snapshot', and it does not control replacement behavior for updates. Option B is wrong because manually creating a new DB instance, updating the application endpoint, and deleting the old instance introduces downtime during the endpoint switch and is error-prone, lacking the automated traffic cutover and synchronization provided by blue/green deployments. Option C is wrong because setting 'ApplyImmediately: true' on a DB instance class change causes an immediate reboot of the RDS instance, resulting in downtime; the 'ApplyImmediately' parameter does not avoid downtime for instance class modifications.

Practice this question →
19
MCQhard

A company uses AWS CloudFormation to deploy infrastructure across multiple accounts. They want to reuse a set of resource definitions for a standard VPC configuration. Which approach minimizes duplication and maintains centralized control?

A.Create a CloudFormation module for the VPC resources and reference it in each stack.
B.Define the VPC resources in a CloudFormation macro and call the macro from each stack.
C.Publish the VPC template in AWS Service Catalog and have each account provision from it.
D.Use nested stacks by creating a separate template for the VPC and including it in each account's stack.
AnswerA

CloudFormation modules encapsulate a group of resources—such as a VPC with subnets, route tables, and gateways—so they can be referenced as a single reusable component in multiple stacks. Modules support parameters, outputs, and semantic versions, enabling centralized management and consistent configuration across accounts and regions without duplicating resource definitions. When a module is included in a stack, its resources become part of that stack's resource graph, so you can access their outputs directly in the same template, simplifying stack-level operations like changes and rollbacks.

Why this answer

CloudFormation modules allow you to encapsulate a set of resource definitions into a reusable component that can be referenced across multiple stacks. This approach minimizes duplication because the module is defined once in a central registry (e.g., the CloudFormation public or private module registry) and each stack simply includes a `Module` declaration. It also maintains centralized control because updates to the module are automatically propagated to all stacks that reference it, without requiring manual template copying or stack updates.

Exam trap

The trap here is that candidates often confuse CloudFormation macros with modules, thinking macros can encapsulate reusable resources, but macros only transform template code at deploy time and do not provide a reusable resource definition mechanism.

How to eliminate wrong answers

Option B is wrong because CloudFormation macros are designed for template preprocessing (e.g., transforming JSON/YAML at deploy time), not for encapsulating reusable resource definitions; they cannot be used to define and share a standard set of resources like a VPC. Option C is wrong because AWS Service Catalog is a governance tool for provisioning pre-approved products, but it does not inherently minimize duplication or maintain centralized control over the IaC template itself—each account still deploys a separate copy of the template, and updates require re-provisioning or version management. Option D is wrong because nested stacks require the child template to be stored in an S3 bucket and referenced by URL; while this allows reuse, it does not provide centralized version control or automatic propagation of updates to all consuming stacks, and it introduces additional complexity in managing S3 permissions and template versioning.

Practice this question →
20
Multi-Selectmedium

A company uses AWS CloudFormation to deploy infrastructure. They want to implement a change management process that requires approval before any stack update is executed. Which TWO approaches can achieve this? (Choose TWO.)

Select 2 answers
A.Use AWS CodePipeline with a manual approval stage before the CloudFormation deployment action.
B.Use CloudFormation StackSets with approval tokens.
C.Use CloudFormation Change Sets and require a separate user to execute them.
D.Use AWS Service Catalog to manage CloudFormation templates and require approval for product launches.
E.Implement a custom AWS Lambda function that checks a ticketing system before allowing the update to proceed.
AnswersA, E

CodePipeline's manual approval action is a first-class gate that pauses execution between stages; a configured principal (often a manager or lead) must explicitly approve via console, CLI, or API before the pipeline proceeds to the CloudFormation deployment stage. This enforces separation of duties, because the engineer who initiated the pipeline cannot be the sole approver unless policies allow it. It works natively with the pipeline state machine and keeps an audit trail of who approved and when.

Why this answer

AWS CodePipeline can include a manual approval action that pauses the pipeline until an authorized user approves the change, after which the CloudFormation deployment action executes the stack update. This enforces a formal approval gate before any infrastructure change is applied.

Exam trap

The trap here is that candidates often confuse Change Sets (which allow review but not approval enforcement) with a true approval workflow, or they incorrectly assume StackSets or Service Catalog can be repurposed for stack update approvals.

Practice this question →
21
MCQmedium

A company uses AWS Systems Manager Parameter Store to manage configuration data for its applications. The DevOps team wants to ensure that sensitive parameters, such as database passwords, are automatically rotated every 30 days. The parameters are currently stored as `SecureString` and are referenced by AWS Lambda functions. Which solution will meet these requirements with the LEAST development effort?

A.Store the parameters in AWS Key Management Service (KMS) encrypted S3 buckets and use S3 Lifecycle policies to rotate the encryption keys every 30 days.
B.Use AWS Secrets Manager to store the sensitive parameters and configure automatic rotation using a Lambda rotation function.
C.Create a custom AWS Lambda function that generates new passwords and updates the Parameter Store parameters on a schedule using Amazon EventBridge.
D.Use AWS Systems Manager Automation to run a document that rotates the parameters and updates the Lambda functions' environment variables.
AnswerB

AWS Secrets Manager natively supports automatic rotation of secrets using Lambda functions. It provides built-in rotation templates for databases like Amazon RDS, and you can schedule rotation every 30 days. This requires minimal development effort because the rotation logic is managed by Secrets Manager. The Lambda functions can retrieve secrets directly from Secrets Manager, and rotation is transparent. This is the most efficient solution.

Why this answer

AWS Secrets Manager is designed for secret rotation and integrates with Lambda for automatic rotation. It supports scheduled rotation, reducing development effort compared to custom solutions. Storing secrets in Secrets Manager and enabling rotation every 30 days meets the requirement efficiently, while Parameter Store would require custom rotation logic.

Exam trap

The trap here is assuming that Parameter Store SecureString parameters can be automatically rotated natively, when they cannot; rotation requires custom logic or migration to Secrets Manager.

Practice this question →
22
MCQmedium

A company is using AWS Systems Manager to manage configuration drift on EC2 instances. They want to automatically apply a baseline configuration to instances that have drifted from the desired state. Which Systems Manager capability should they use?

A.AWS Systems Manager Patch Manager
B.AWS Systems Manager Parameter Store
C.AWS Systems Manager Run Command
D.AWS Systems Manager State Manager
AnswerD

AWS Systems Manager State Manager creates associations that define a desired configuration state using SSM documents, and it automatically applies that state on a schedule or when an instance is launched. When a configured resource drifts from the desired state, State Manager detects and remediates it during the next association execution, and it provides compliance status for every managed instance. It is the correct service for ongoing, agent-managed configuration enforcement and drift correction.

Why this answer

AWS Systems Manager State Manager is the correct capability because it is specifically designed to define and maintain consistent configuration states for EC2 instances and other AWS resources. It uses associations to automatically apply a baseline configuration and remediate drift on a schedule or when triggered, ensuring instances remain in the desired state without manual intervention.

Exam trap

The trap here is that candidates often confuse Run Command with State Manager because both can execute commands, but Run Command is for one-time execution while State Manager is for ongoing, automated enforcement of a desired configuration state.

How to eliminate wrong answers

Option A is wrong because AWS Systems Manager Patch Manager is focused solely on automating the patching of operating systems and applications, not on applying a full baseline configuration or remediating configuration drift. Option B is wrong because AWS Systems Manager Parameter Store is a secure hierarchical store for configuration data and secrets, but it does not have the ability to automatically apply configurations to instances or enforce desired states. Option C is wrong because AWS Systems Manager Run Command allows you to execute scripts or commands on instances remotely, but it is a one-time, ad-hoc execution tool and does not provide ongoing, automated drift detection or remediation.

Practice this question →
23
MCQmedium

A company uses AWS CloudFormation StackSets to deploy a VPC with subnets across multiple accounts and regions. Recently, a new account was added to the organization, and the DevOps team wants to deploy the stack set to this new account without affecting existing stacks. The stack set has self-managed permissions. The engineer creates a new stack instance for the account and region, but the operation fails with an 'Access Denied' error when CloudFormation tries to create resources in the new account. The engineer has verified that the stack set's IAM roles exist in the new account. What is the most likely cause?

A.The stack set template contains a resource that is not supported in the target region.
B.The trust policy of the IAM role in the target account does not grant permissions to the administrator account.
C.The target account has reached a service limit for VPCs.
D.The IAM roles in the target account are not named correctly.
AnswerB

This is the correct cause because StackSets with self-managed permissions require the administrator account to assume an IAM execution role in each target account using the sts:AssumeRole API. The target account execution role must include a trust policy that explicitly grants the administrator account (or the StackSets administration role) permission to assume it. If that trust relationship is missing or misconfigured, the administrator account receives an AccessDenied response even though the role exists and the execution role's permissions policy may be correct. Therefore, verifying the role exists is not sufficient; you must verify its trust policy.

Why this answer

With self-managed permissions in CloudFormation StackSets, the administrator account assumes an IAM role in each target account to deploy stacks. The trust policy of that target-account role must explicitly grant sts:AssumeRole to the administrator account (or its role). If the trust policy does not list the administrator account, CloudFormation's attempt to assume the role fails with Access Denied, even though the role exists and has the right permissions policy.

Exam trap

DOP-C02 often tests the distinction between the permissions policy (what the role can do) and the trust policy (who can assume it) — candidates see the role exists and has permissions, and miss that the trust policy must name the administrator account.

How to eliminate wrong answers

Option A is wrong because an unsupported resource in the target region would produce a different error (e.g., 'Resource type not supported in region') during stack creation, not an Access Denied error when assuming the role. Option C is wrong because a VPC service limit would produce a limit-exceeded error (e.g., 'VpcLimitExceeded'), not Access Denied, and the scenario does not indicate the account is at its VPC limit. Option D is wrong because the scenario states the IAM roles exist in the new account; role naming is not the issue — the trust policy is what governs whether the administrator account can assume the role.

Practice this question →
24
Multi-Selecthard

A company is using AWS Elastic Beanstalk with a custom platform. The DevOps team wants to automate the creation of a new platform version whenever changes are pushed to a Git repository. The pipeline should run tests, build the platform, and then update the Elastic Beanstalk environment to use the new platform version. Which services should be used together to achieve this? (Choose THREE.)

Select 3 answers
A.AWS CloudFormation
B.AWS CodeBuild
C.AWS CodePipeline
D.HashiCorp Packer (run in CodeBuild)
E.AWS CodeDeploy
AnswersB, C, D

AWS CodeBuild is a fully managed build service that can execute a custom build spec in a disposable compute environment. To create a custom Elastic Beanstalk platform, CodeBuild can run the Packer templates and platform hooks that produce the platform's AMI, making it the correct AWS service for the build itself. Its ephemeral environment, clean snapshots, and retryable builds make it well suited for repeatable platform builds.

Why this answer

AWS CodeBuild is correct because it can run the tests and build the custom platform artifact. In this scenario, CodeBuild executes the buildspec to compile code, run unit tests, and produce the platform version (e.g., an AMI or Packer image). It integrates directly with CodePipeline to receive source changes and pass artifacts downstream for environment updates.

Exam trap

The trap here is that candidates often confuse AWS CodeDeploy with Elastic Beanstalk platform updates, but CodeDeploy cannot create or manage custom platform versions; only CodeBuild with Packer can build the platform artifact, and CodePipeline orchestrates the full CI/CD pipeline.

Practice this question →
25
MCQeasy

A company uses AWS CodePipeline with a GitHub source action. The pipeline triggers on changes to the master branch. However, the pipeline does not trigger when changes are pushed to the master branch. What is the MOST likely cause?

A.The pipeline uses a different branch name.
B.The GitHub repository is not in the same AWS region as the pipeline.
C.The webhook in GitHub is not properly configured or has been removed.
D.The pipeline does not have permission to access the GitHub repository.
AnswerC

Automatic triggering in CodePipeline with a GitHub source action depends on an active webhook that GitHub uses to notify the CodePipeline API whenever commits are pushed to the repository. If that webhook has been deleted, or if its payload URL or secret token no longer matches what CodePipeline expects, GitHub's push events will never reach CodePipeline and no new pipeline execution will be started. This is the classic cause of 'commits pushed but pipeline doesn't run,' and it is precisely why this is the correct answer.

Why this answer

The most likely cause is that the webhook in GitHub is not properly configured or has been removed. CodePipeline relies on a webhook to automatically detect changes in the GitHub repository. If the webhook is missing or misconfigured, the pipeline will not trigger on pushes.

Option A is incorrect because the pipeline uses the master branch as specified. Option B is incorrect because AWS regions are independent of GitHub; the webhook is not region-specific. Option D is incorrect because pipeline permissions are not required for the webhook to function; the webhook itself is the key mechanism for triggering.

Practice this question →
26
MCQhard

An IAM policy is attached to a user who needs to create a CloudFormation stack that provisions an EC2 instance and an S3 bucket. The user receives an 'Access Denied' error when running the 'aws cloudformation create-stack' command. Which additional permission is required?

A.ec2:RunInstances and s3:CreateBucket
B.s3:PutObject
C.cloudformation:DescribeStacks
D.iam:PassRole
AnswerA

CloudFormation assumes the IAM permissions of the calling user when provisioning resources from a template. To launch an EC2 instance, ec2:RunInstances is required, and to create an S3 bucket, s3:CreateBucket is required, because those are the specific API calls CloudFormation makes on your behalf. Without these actions, stack creation will fail even if other permissions are present.

Why this answer

To successfully create a CloudFormation stack that provisions an EC2 instance and an S3 bucket, the IAM user must have permissions for the actions that CloudFormation will perform on their behalf. Specifically, ec2:RunInstances and s3:CreateBucket are required in addition to cloudformation:CreateStack. The 'Access Denied' error occurs because the user lacks these resource-level permissions.

Notably, the DeletionPolicy attribute (e.g., Retain) only controls behavior when resources are deleted, not during stack creation or updates; it does not affect the permissions required for provisioning.

Exam trap

The trap here is that candidates assume the cloudformation:CreateStack permission alone suffices, but the DOP-C02 exam tests the understanding that CloudFormation acts as a proxy, requiring the caller to have permissions for every resource it provisions.

How to eliminate wrong answers

Option B is wrong because s3:PutObject is used to upload objects to an existing S3 bucket, not to create the bucket itself; creating a bucket requires s3:CreateBucket. Option C is wrong because cloudformation:DescribeStacks is a read-only permission that allows viewing stack details, not creating resources; it does not grant the ability to provision EC2 or S3. Option D is wrong because iam:PassRole is used to pass an IAM role to a service (e.g., for EC2 instance profiles), but the question does not mention any role being passed in the template; the error stems from missing resource creation permissions, not role passing.

Practice this question →
27
MCQeasy

A company uses AWS OpsWorks for configuration management. They need to automate the installation of a custom package on all instances in a layer. Which OpsWorks feature should they use?

A.AWS CodeDeploy AppSpec file
B.AWS CloudFormation custom resources
C.Custom Chef recipes associated with lifecycle events
D.AWS Systems Manager Run Command
AnswerC

Custom Chef recipes associated with lifecycle events are the correct mechanism for configuration management in AWS OpsWorks. OpsWorks defines five lifecycle events—Setup, Configure, Deploy, Undeploy, and Shutdown—and you can assign custom Chef recipes to run at each stage. For example, a Setup recipe can install packages and configure software, while a Deploy recipe can deploy application code. This is the native, fully integrated way to manage configurations in OpsWorks.

Why this answer

Custom Chef recipes associated with lifecycle events in AWS OpsWorks allow running Chef recipes automatically on instance lifecycle events such as Setup, Configure, Deploy, Undeploy, and Shutdown. This is the correct feature for automating package installation on all instances in a layer. Option A is incorrect because AWS CodeDeploy AppSpec file is used for CodeDeploy deployments, not OpsWorks.

Option B is incorrect because AWS CloudFormation custom resources are used to extend CloudFormation templates, not for OpsWorks automation. Option D is incorrect because AWS Systems Manager Run Command is a separate service for managing instances, not OpsWorks.

Practice this question →
28
MCQhard

A company is using AWS CodePipeline for CI/CD with CloudFormation as the deployment action. The pipeline fails intermittently with the error 'Rate exceeded' when creating or updating stacks. What is the most likely cause and solution?

A.The stack has a stack policy that prevents updates; modify the stack policy.
B.The IAM role used by CloudFormation does not have sufficient permissions; update the role policy.
C.The CloudFormation API rate limit is being hit; request a limit increase from AWS Support.
D.The pipeline is exceeding the CodePipeline execution frequency limit; reduce the number of pipeline executions.
AnswerC

The 'Rate exceeded' error is the exact textual representation of AWS API throttling, meaning the CloudFormation service is rejecting requests because the account's API request rate for that region has exceeded its allowed quota. This often occurs during CodePipeline deployments when multiple stages run large numbers of changeset creation, update, and describe calls concurrently, or when other automation is hammering the same CloudFormation API. The correct fix is to request a service quota increase for the CloudFormation API via Service Quotas or AWS Support, and also implement exponential backoff in the calling code to handle transient throttle responses while the increase is pending.

Why this answer

The 'Rate exceeded' error is a standard AWS API throttling error, indicating that CloudFormation API requests are being made faster than the account-level or region-level rate limit allows. CodePipeline can trigger multiple concurrent stack operations, especially during parallel stage executions or frequent commits, which can exceed the default CloudFormation API rate limit (e.g., 0.5 requests per second per account per region for CreateStack/UpdateStack). Requesting a limit increase from AWS Support is the correct solution to accommodate higher throughput.

Exam trap

The trap here is that candidates confuse API throttling errors with permission or policy issues, and they may incorrectly attribute the 'Rate exceeded' error to IAM roles or stack policies, rather than recognizing it as a classic AWS API rate limit error that requires a service quota increase.

How to eliminate wrong answers

Option A is wrong because a stack policy controls updates to stack resources (e.g., preventing modifications to specific resources), but it does not produce a 'Rate exceeded' error; it would produce an 'Update denied' or 'Stack policy violation' error. Option B is wrong because insufficient IAM permissions would result in an 'AccessDenied' or 'AuthorizationError', not a 'Rate exceeded' error; the error message explicitly indicates throttling, not authorization. Option D is wrong because CodePipeline execution frequency limits (e.g., 100 concurrent pipelines per account) are separate from CloudFormation API rate limits; exceeding pipeline frequency would cause pipeline execution failures, not CloudFormation-specific 'Rate exceeded' errors.

Practice this question →
29
MCQmedium

A company uses AWS OpsWorks for Chef Automate. They have a stack that includes a PHP application layer. The application requires a custom PHP configuration file. The DevOps engineer creates a custom Chef cookbook with a recipe that deploys the configuration file. The recipe is assigned to the layer's Setup lifecycle event. The engineer notices that the configuration file is not being created on new instances when they are added to the layer. The cookbook is stored in a private S3 bucket. The engineer has verified that the cookbook is correctly associated with the stack. What should the engineer do to fix the issue?

A.Assign the recipe to the Configure lifecycle event instead of Setup
B.Verify that the recipe is included in the cookbook's default.rb file
C.Update the cookbook version to the latest
D.Ensure that the instance profile has permissions to read from the S3 bucket where the cookbook is stored
AnswerD

AWS OpsWorks for Chef Automate instances assume an IAM instance profile, and the chef-client uses those temporary credentials to fetch cookbooks and other artifacts from the configured S3 bucket. Without s3:GetObject (and often s3:ListBucket) permissions scoped to that bucket's path, the cookbook download fails, which prevents the recipe from executing. Granting the instance profile the necessary S3 read permissions directly resolves the issue, making this the correct remediation.

Why this answer

The issue is that the custom cookbook is stored in a private S3 bucket. For new instances to access the cookbook during the Setup lifecycle event, the instance must have the necessary IAM permissions to read from that S3 bucket. The instance profile attached to the OpsWorks stack's instances must include a policy that grants s3:GetObject for the cookbook's S3 bucket.

Without these permissions, the instance cannot download the cookbook, so the recipe never runs. Therefore, the engineer should ensure that the instance profile has permissions to read from the S3 bucket. Option A is incorrect because the Setup lifecycle event is appropriate for deploying configuration files when the instance is being set up; moving to Configure would run later and might not achieve the same result.

Option B is incorrect because the issue is not about the recipe being in default.rb; the cookbook is correctly associated, and the recipe is assigned to the layer lifecycle event directly, not necessarily via default.rb. Option C is incorrect because updating the cookbook version would not address the access permissions issue.

Practice this question →
30
MCQhard

A company uses Terraform to manage AWS infrastructure. They have a state file stored in an S3 bucket with DynamoDB locking. After a failed 'terraform apply', the state file is locked. The DevOps engineer tries to run 'terraform plan' but gets an error: 'Error acquiring the state lock'. What should the engineer do to resolve this issue?

A.Manually delete the lock item from the DynamoDB table
B.Wait for the lock to expire automatically
C.Run 'terraform force-unlock' with the lock ID
D.Delete the state file from S3 and re-run terraform init
AnswerC

`terraform force-unlock <LOCK_ID>` is the designed recovery mechanism for stale or stuck locks, and it directly interacts with the backend's locking system to remove the lock item while preserving the integrity of the state file. This command requires the exact lock ID from the error message and is safe when the previous operation is truly no longer running; it is the recommended alternative to manual DynamoDB edits or destructive state file actions.

Why this answer

Terraform uses DynamoDB to implement state locking, and after a failed apply, the lock entry remains in the table. The `terraform force-unlock` command with the specific lock ID (obtained from the error message or via `terraform lock` commands) is the designed mechanism to manually release a stuck lock without corrupting the state file. This approach preserves the existing state and avoids data loss.

Exam trap

The trap here is that candidates assume DynamoDB locks have a TTL or that manual deletion is safe, but AWS DynamoDB does not enforce TTL on lock items by default, and Terraform's locking protocol requires the lock ID to be explicitly provided to prevent accidental release of another process's lock.

How to eliminate wrong answers

Option A is wrong because manually deleting the lock item from the DynamoDB table bypasses Terraform's safety checks and can lead to state corruption if the lock was legitimately held by another process; it also does not provide the lock ID validation that Terraform requires. Option B is wrong because DynamoDB locks do not have a built-in expiry mechanism; they persist until explicitly released, so waiting will not resolve the issue. Option D is wrong because deleting the state file from S3 destroys the entire infrastructure state, causing Terraform to lose track of all managed resources, and re-running `terraform init` would create a blank state, leading to potential resource duplication or deletion.

Practice this question →
31
Multi-Selecthard

Which THREE actions are best practices for managing secrets in AWS CloudFormation templates? (Choose three.)

Select 3 answers
A.Use AWS CloudFormation parameters with the NoEcho property set to true.
B.Use AWS Systems Manager Parameter Store secure string parameters with dynamic references.
C.Use AWS Secrets Manager dynamic references to retrieve secrets at deployment time.
D.Encrypt the CloudFormation template file with AWS KMS.
E.Store secrets as plaintext in the template parameters.
AnswersA, B, C

Using the NoEcho property on a CloudFormation parameter is a valid best practice because it masks the parameter's value from the AWS Management Console, API responses, and stack outputs, preventing casual exposure during template operations. However, it does not encrypt the value or prevent the resource that receives the parameter from exposing it, so it should be combined with external secret stores. NoEcho is appropriate when a secret must be passed as a stack parameter, but the secret itself should never be embedded in the template or committed to version control.

Why this answer

Setting the NoEcho property to true on a CloudFormation parameter prevents the parameter value from being returned in API calls or displayed in the console, which is a basic mechanism for masking secrets. However, this alone does not encrypt the value at rest or in transit, and the value is still passed as plaintext in the template, so it is considered a best practice only when combined with other secure methods like dynamic references.

Exam trap

The trap here is that candidates often think encrypting the template file (Option D) is sufficient for secret protection, but they overlook that secrets remain exposed during stack operations unless dynamic references or NoEcho are used.

Practice this question →
32
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 →
33
MCQmedium

A company manages a large AWS CloudFormation template that defines a VPC, subnets, an Application Load Balancer, and an Auto Scaling group. The template has grown to over 2,000 lines and is difficult to maintain. The DevOps team wants to break the template into smaller, reusable components that can be versioned and shared across multiple teams. The components must be able to be included in other templates and must support parameters to customize values. Which CloudFormation feature should the team use?

A.CloudFormation nested stacks
B.CloudFormation modules
C.CloudFormation change sets
D.CloudFormation stack policies
AnswerB

CloudFormation modules are reusable building blocks that encapsulate resource definitions and can be included in templates via the AWS::CloudFormation::Module resource type. They support parameters and can be versioned and shared across teams, exactly matching the requirement. Modules simplify template maintenance by abstracting complexity and promoting consistency.

Why this answer

CloudFormation modules allow teams to package resource configurations into reusable, versioned components that can be included in multiple templates. They support parameters, enabling customization, and are ideal for breaking down monolithic templates. Unlike nested stacks, modules are lightweight and designed for sharing, making them the best fit for this scenario.

Exam trap

The trap here is confusing nested stacks with modules, because both enable reuse but nested stacks require deploying separate stacks and are not as easily shared across teams.

Practice this question →
34
Multi-Selectmedium

Which TWO options are valid approaches for managing configuration drift in an AWS environment? (Choose two.)

Select 2 answers
A.Use AWS Config rules to evaluate resource configurations against desired policies.
B.Use AWS CodePipeline to automatically redeploy infrastructure when changes are detected.
C.Use AWS Systems Manager Patch Manager to keep instances patched.
D.Use AWS CloudTrail to monitor API calls that modify resources.
E.Use AWS CloudFormation drift detection to identify resources that have been modified outside of CloudFormation.
AnswersA, E

AWS Config rules evaluate the recorded configuration of AWS resources against the desired policy logic you define in a rule. A rule can be AWS-managed (e.g., requiring S3 buckets to be encrypted) or custom (via Lambda), and it runs on a change-triggered or periodic schedule to identify noncompliant resources. When a resource deviates from the policy, AWS Config flags it as noncompliant and can trigger remediation actions, making it a continuous drift-detection and compliance-audit service.

Why this answer

AWS Config rules continuously evaluate your resource configurations against desired policies defined in managed or custom rules. When a resource configuration changes and violates a rule, AWS Config can trigger remediation actions or notify you, directly addressing configuration drift by detecting non-compliant resources in near real-time.

Exam trap

The trap here is that candidates confuse monitoring API calls (CloudTrail) with evaluating configurations against policies (AWS Config), or assume that redeploying via CodePipeline automatically corrects drift without a detection mechanism.

Practice this question →
35
MCQmedium

A DevOps team is troubleshooting a CloudFormation stack creation failure. The error message states: 'CREATE_FAILED: Resource handler returned message: "You have attempted to create more resources than the current AWS account limit"'. Which step should the team take to resolve this issue?

A.Delete the failed stack and recreate it with the same template.
B.Review the IAM permissions for the CloudFormation service role.
C.Modify the CloudFormation template to use a different resource type.
D.Check the current service limits for the resource type and request a limit increase from AWS Support.
AnswerD

When CloudFormation returns an error that an account limit has been reached, it means the AWS resource API rejected the creation request due to service quota exhaustion for that resource type in the current region. You should use the Service Quotas console or AWS Support to check the current limit and request an increase, then wait for approval before retrying the stack creation. This directly resolves the root cause without modifying the template or IAM role.

Why this answer

The error message explicitly indicates that the CloudFormation stack creation failed because the AWS account has reached a service limit for a specific resource type. Option D is correct because the team must first identify which resource type exceeded its limit (e.g., EC2 instances, VPCs, or IAM roles) by checking the AWS Service Quotas console or using the Trusted Advisor dashboard, then request a limit increase from AWS Support. Simply retrying the stack creation or modifying IAM permissions will not resolve a hard service quota violation.

Exam trap

The trap here is that candidates may confuse a service limit error with an IAM permissions issue or a template syntax error, leading them to choose options B or C instead of recognizing the need to check and increase AWS service quotas.

How to eliminate wrong answers

Option A is wrong because deleting and recreating the stack with the same template will not change the account-level service limit; the same resource count will be attempted, causing the same failure. Option B is wrong because IAM permissions control who can create resources, but the error is about exceeding a service quota, not about authorization—CloudFormation already had permission to attempt the creation. Option C is wrong because changing the resource type in the template does not address the underlying limit issue; the new resource type may have its own separate quota, but the error is about exceeding a limit for a specific resource type, not about the type itself being invalid.

Practice this question →
36
MCQmedium

A company uses AWS CloudFormation to manage infrastructure. The team wants to ensure that all stack updates are reviewed and approved before execution. Which mechanism should the team implement?

A.Create a stack policy that denies all updates unless approved.
B.Use AWS CloudFormation drift detection to identify changes before updating.
C.Enable termination protection on the stack to prevent accidental updates.
D.Use AWS CloudFormation change sets to review the proposed changes before executing the update.
AnswerD

A change set is a read-only summary of the exact modifications CloudFormation will make to the stack when you execute it, including resource type add/remove/replace and whether the change is dynamically applied or requires no interruption. You can create and inspect multiple change sets from different template versions without touching live infrastructure, then deliberately execute the approved one—only execution applies the update. This gives you the review-before-apply gate that the requirement asks for, as the change set is the proposed changes themselves rather than a policy or detection signal.

Why this answer

AWS CloudFormation change sets allow you to preview how proposed changes to a stack will be applied before you execute them. This includes a summary of additions, modifications, and deletions of resources, enabling you to review and approve the changes in a controlled manner. By generating a change set, the team can ensure that no update is executed without prior review and approval, meeting the requirement for a gated deployment process.

Exam trap

The trap here is that candidates confuse stack policies (which control resource-level permissions) with change sets (which provide a preview of changes), or they mistakenly think termination protection or drift detection can gate updates, when neither is designed for that purpose.

How to eliminate wrong answers

Option A is wrong because a stack policy controls permissions for stack resources (e.g., preventing updates to specific resources) but does not provide a review-and-approve workflow for the entire stack update; it cannot block the update itself. Option B is wrong because drift detection identifies whether the stack's actual resources have deviated from the template, but it does not preview or gate proposed updates; it is a detective, not a preventive, control. Option C is wrong because termination protection prevents accidental deletion of the entire stack, not updates; it has no effect on stack updates or change review.

Practice this question →
37
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 →
38
MCQhard

A company uses AWS Elastic Beanstalk for application deployments. They want to integrate infrastructure-as-code practices using AWS CloudFormation. Which approach allows them to manage the Elastic Beanstalk environment and underlying resources as part of a CloudFormation stack?

A.Use a custom resource backed by a Lambda function to create the Elastic Beanstalk environment.
B.Use the CloudFormation import feature to bring the existing Elastic Beanstalk environment into the stack.
C.Export the Elastic Beanstalk environment configuration as a CloudFormation template from the console.
D.Define the Elastic Beanstalk environment in the CloudFormation template using the AWS::ElasticBeanstalk::Environment resource.
AnswerD

The correct approach is to declare the Elastic Beanstalk environment directly in your CloudFormation template with the AWS::ElasticBeanstalk::Environment resource. This native resource supports properties such as ApplicationName, SolutionStackName or PlatformArn, OptionSettings, and Tags, allowing CloudFormation to create and manage the environment as part of the stack. It integrates cleanly with other stack resources and avoids custom code or workarounds.

Why this answer

CloudFormation natively supports Elastic Beanstalk through the AWS::ElasticBeanstalk::Environment and AWS::ElasticBeanstalk::Application resource types. Defining the environment in the template lets CloudFormation create, update, and delete the environment and its underlying resources (EC2, ASG, ELB, security groups) as part of the stack, giving full IaC lifecycle management.

Exam trap

DOP-C02 often tests whether candidates know that Elastic Beanstalk has first-class CloudFormation resource types — many assume a custom resource or import is needed because Beanstalk 'manages its own resources.'

How to eliminate wrong answers

Option A is wrong because a custom resource backed by Lambda is a workaround that only creates the environment imperatively — CloudFormation cannot track or manage the underlying resources, so drift and rollback are not handled. Option B is wrong because CloudFormation import only supports a limited set of resource types and cannot import an existing Elastic Beanstalk environment into a stack. Option C is wrong because the Elastic Beanstalk console does not export a CloudFormation template; that capability does not exist.

Practice this question →
39
Multi-Selectmedium

A company uses AWS CloudFormation to deploy infrastructure. They want to enforce mandatory tags on all resources created by CloudFormation. Which TWO approaches can achieve this? (Choose TWO.)

Select 2 answers
A.Use CloudFormation stack tags that propagate to all resources in the stack.
B.Create an AWS Config rule to automatically tag resources after creation.
C.Use an AWS Organizations service control policy (SCP) to deny creation of resources that are not tagged.
D.Add an IAM policy that denies cloudformation:CreateStack unless the template includes the required tags.
E.Enable AWS CloudTrail to log all API calls and monitor for untagged resources.
AnswersA, C

CloudFormation stack tags are specified on the stack and automatically propagated to every resource in the stack that supports tagging. Because CloudFormation applies these tags to resources during the CREATE or UPDATE operation, resources are born with the required tags, eliminating the need for a post-creation remediation step. This provides a native, preventive control that works without requiring any custom Lambda functions or additional configuration.

Why this answer

CloudFormation stack tags propagate to all resources that support tagging within the stack. When you specify tags at the stack level, CloudFormation automatically applies them to each resource it creates, ensuring mandatory tags are enforced without additional configuration.

Exam trap

The trap here is that candidates often confuse reactive detection (AWS Config) with proactive prevention (SCPs or stack tags), or mistakenly believe IAM policies can parse template content to enforce tagging rules.

Practice this question →
40
MCQhard

A DevOps team is designing a configuration management solution for a microservices architecture running on Amazon ECS. The team wants to ensure that container configurations are automatically updated when a new version of a parameter is stored in AWS Systems Manager Parameter Store. Which approach best meets this requirement with minimal operational overhead?

A.Use AWS AppConfig to create a configuration profile that references the parameter. Configure a Lambda function as a validator and deploy strategy. When the parameter changes, AppConfig triggers a deployment that updates the ECS service.
B.Use an AWS CloudFormation custom resource that updates the ECS service when the parameter changes.
C.Use a CI/CD pipeline that monitors the parameter store and triggers a new build and deploy of the container image with the updated parameter.
D.Use Amazon EventBridge to detect changes to the parameter and invoke a Lambda function that updates the ECS task definition and forces a new deployment.
AnswerA

AWS AppConfig is purpose-built for this exact scenario because it separates configuration from code and provides a managed deployment lifecycle. By creating a configuration profile that references the SSM parameter, AppConfig treats each change as a new configuration version, runs your Lambda validator to catch malformed or unsafe values, and then rolls out the update using the specified deploy strategy (e.g., linear or canary with bake time). The ECS service is updated through AppConfig's integration with ECS—either via the AppConfig agent that supplies the new configuration or by triggering a task definition update—so the application receives the new value without a container rebuild. This gives you controlled rollout, automatic rollback on alarms, and auditability, which is exactly what a configuration management solution should provide.

Why this answer

AWS AppConfig is purpose-built for managing application configuration and supports automatic deployment of configuration changes to ECS services when a parameter in Systems Manager Parameter Store is updated. By creating a configuration profile that references the parameter, AppConfig can trigger a deployment that updates the ECS service without requiring custom code or manual intervention, minimizing operational overhead.

Exam trap

The trap here is that candidates may assume EventBridge with Lambda (Option D) is the simplest solution, but they overlook that AppConfig provides a managed, lower-overhead alternative specifically designed for configuration management and automatic deployment to ECS.

How to eliminate wrong answers

Option B is wrong because AWS CloudFormation custom resources require manual invocation or a separate trigger to execute the update logic; they do not automatically detect parameter changes and would add operational overhead for polling or event handling. Option C is wrong because using a CI/CD pipeline to rebuild and redeploy container images for every parameter change is inefficient and introduces unnecessary overhead, as the container image itself does not change—only the runtime configuration does. Option D is wrong because while EventBridge can detect parameter changes and invoke a Lambda function, this approach requires custom code to update the ECS task definition and force a new deployment, increasing operational complexity compared to AppConfig's managed deployment strategy.

Practice this question →
41
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

Automatic rollback in the deployment group triggers CodeDeploy to redeploy the last known-good revision once the health check failures terminate instances and the deployment fails, satisfying the requirement to restore the previous working version without manual intervention.

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 →
42
MCQmedium

A company manages its AWS infrastructure using AWS CloudFormation templates stored in an Amazon S3 bucket. The DevOps team needs to enforce that all new CloudFormation stacks are created only from templates that have been validated by AWS CloudFormation Guard. The team wants to integrate this validation into their existing CI/CD pipeline built with AWS CodePipeline. Which approach will meet these requirements with the LEAST operational overhead?

A.Add a CodeBuild action to the pipeline that runs `cfn-guard validate` against the template and fails the build if validation fails.
B.Use AWS CloudFormation change sets to preview changes and require manual approval before execution.
C.Enable AWS CloudFormation drift detection on all stacks and automatically remediate any drift using AWS Systems Manager Automation.
D.Configure an AWS Lambda function that downloads the template and runs `cfn-guard validate`, then triggers the pipeline only if validation succeeds.
AnswerA

AWS CloudFormation Guard is a policy-as-code tool that can be run in CodeBuild. Integrating `cfn-guard validate` as a build step ensures templates are validated before deployment, and the pipeline stops on failure. This requires minimal setup: install Guard in the build environment, run the command, and check the exit code. It is a native, serverless approach with no infrastructure to manage.

Why this answer

Running AWS CloudFormation Guard in CodeBuild is the most efficient way to enforce template validation. Guard integrates seamlessly with CodePipeline, and CodeBuild provides a managed environment where you can install and execute `cfn-guard validate`. This ensures that only validated templates proceed to deployment, with minimal operational effort compared to custom Lambda functions or post-deployment checks.

Exam trap

The trap here is assuming that CloudFormation change sets or drift detection can enforce template policy validation, when they actually only show differences or detect drift after deployment.

Practice this question →
43
Multi-Selecteasy

A company is adopting Infrastructure as Code (IaC) using AWS CloudFormation. They want to ensure that stack updates are safe and minimize the risk of resource replacement. Which TWO of the following strategies should they use?

Select 2 answers
A.Always create a change set before executing a stack update.
B.Use a stack policy to prevent updates to critical resources.
C.Perform updates directly from the AWS Management Console to see immediate results.
D.Delete the stack and create a new one with the updated template.
E.Use the --disable-rollback flag to avoid unnecessary rollbacks.
AnswersA, B

A change set is a read-only preview of the exact modifications CloudFormation will make to a running stack, including whether each resource is created, updated, replaced, or deleted. By generating a change set before executing, you can inspect the action on every resource and confirm that the update does not introduce unintended destructive changes or interruption. Execution is a separate, explicit step, which gives engineers a checkpoint in the IaC workflow.

Why this answer

Creating a change set before executing a stack update allows you to review the proposed changes, including whether any resources will be replaced or interrupted. This provides a safety net by letting you validate the impact of the update before committing, reducing the risk of unintended resource replacement.

Exam trap

The trap here is that candidates often confuse the --disable-rollback flag with a safety mechanism, but it actually prevents recovery from failures and does nothing to mitigate resource replacement risks.

Practice this question →
44
Multi-Selecthard

Which TWO are correct about using AWS CloudFormation to manage infrastructure across multiple AWS accounts? (Select TWO.)

Select 2 answers
A.You can use AWS Organizations to centrally manage accounts and use StackSets with trusted access.
B.CloudFormation can automatically create new AWS accounts using a template.
C.Nested stacks can be used to deploy resources in different accounts from a single template.
D.AWS CloudFormation StackSets can deploy stacks across multiple accounts.
E.You can use cross-stack references to share resources between accounts.
AnswersA, D

Enabling trusted access for AWS CloudFormation in AWS Organizations allows StackSets to use the organization's structure (accounts and OUs) to automatically determine the set of target accounts. With service-managed permissions, any account added to the organization or an OU is automatically included in deployments, removing the need to manually maintain account lists. This centralization is a best practice for multi-account infrastructure management.

Why this answer

AWS Organizations can centrally manage accounts, and StackSets can be enabled with trusted access to deploy stacks across accounts. Option D is correct because AWS CloudFormation StackSets allow deploying stacks across multiple accounts. Option B is incorrect because CloudFormation cannot automatically create new AWS accounts.

Option C is incorrect because nested stacks operate within a single stack and cannot deploy resources across different accounts from a single template. Option E is incorrect because cross-stack references only work within the same account and region.

Practice this question →
45
MCQhard

An organization wants to ensure that all objects stored in the S3 bucket are encrypted at rest using server-side encryption with S3 managed keys (SSE-S3). The bucket policy above is intended to enforce this. However, a user reported that they can still upload unencrypted objects. What is the MOST likely reason?

A.The condition is applied to the GetObject action, not the PutObject action.
B.The bucket policy is not attached to the bucket because of a circular dependency.
C.The bucket policy does not apply to objects uploaded by the root user.
D.The condition should use 's3:x-amz-server-side-encryption-aws-kms-key-id' instead.
AnswerA

The bucket policy's condition key is tied to the s3:GetObject action, which only governs read requests. To enforce encryption during uploads, the policy must target s3:PutObject, because that is the action that accepts the x-amz-server-side-encryption header and where a missing encryption header should be denied. Placing the condition on GetObject only denies reading unencrypted objects, leaving uploads allowed without encryption.

Why this answer

The bucket policy condition `s3:x-amz-server-side-encryption` is applied to the `s3:GetObject` action instead of `s3:PutObject`. This means the policy only checks encryption headers when reading objects, not when uploading them. To enforce encryption at upload time, the condition must be attached to the `s3:PutObject` action, which is the operation that accepts the `x-amz-server-side-encryption` header.

Exam trap

The trap here is that candidates often focus on the condition key or value syntax and overlook the action to which the condition is attached, assuming any encryption-related condition will automatically apply to uploads.

How to eliminate wrong answers

Option B is wrong because a circular dependency would prevent the bucket policy from being attached at all, but the user can still upload objects, so the policy is attached and functional. Option C is wrong because bucket policies apply to all principals, including the root user, unless explicitly excluded; the root user is not exempt from policy conditions. Option D is wrong because `s3:x-amz-server-side-encryption-aws-kms-key-id` is used for SSE-KMS, not SSE-S3; the question specifies SSE-S3, which uses the `AES256` value with the `s3:x-amz-server-side-encryption` condition key.

Practice this question →
46
MCQeasy

A company uses Ansible for configuration management on EC2 instances. They want to ensure that only instances with a specific tag (Environment: Production) are targeted by their playbooks. What is the best way to achieve this?

A.Add a 'when' condition in the playbook to check the instance tag at runtime.
B.Maintain a static inventory file listing only Production instances.
C.Use the AWS EC2 dynamic inventory plugin to filter instances based on tags.
D.Use the ec2_tag module to assign the tag to instances.
AnswerC

The EC2 dynamic inventory plugin queries the AWS API and groups hosts by their tags, so `Environment: Production` becomes a selectable group or filterable host pattern. This satisfies the requirement to target only tagged production instances without maintaining a static inventory file that would drift as instances launch or terminate.

Why this answer

The best approach because the AWS EC2 dynamic inventory plugin allows filtering instances by tags (e.g., 'Environment: Production') at runtime, ensuring only tagged instances are targeted. Option A (adding a 'when' condition) is less efficient as it connects to all instances first. Option B (static inventory) requires manual updates and is not dynamic.

Option D (ec2_tag module) is for assigning tags, not selecting instances.

Practice this question →
47
Multi-Selectmedium

A DevOps team is using AWS Elastic Beanstalk to deploy a web application. They need to customize the software configuration on the EC2 instances that are part of the Elastic Beanstalk environment. Which THREE methods can they use? (Choose THREE.)

Select 3 answers
A.Use saved configurations to create reusable environment templates
B.Create a custom AMI with the desired configuration
C.Use OpsWorks to manage the instances
D.Use .ebextensions configuration files
E.Use platform hooks to run custom scripts during deployment
AnswersA, D, E

Saved configurations serialize an environment's settings—such as instance type, autoscaling limits, environment variables, and security group rules—into a reusable template. A DevOps team can save a tuned production environment's configuration and then apply that exact template when creating a new environment, either through the Elastic Beanstalk console or the eb config save command. This ensures consistency across environments, but it should not be used for deploying code; it only captures environment-level options.

Why this answer

Saved configurations in Elastic Beanstalk allow you to capture the environment's settings, including custom software configurations, and reuse them as templates for future environments. This enables consistent deployment without manual reconfiguration, directly addressing the need to customize software on EC2 instances.

Exam trap

The trap here is that candidates may confuse saved configurations (option A) with a method for runtime customization, when in fact they are for environment template reuse, not direct software configuration on instances.

Practice this question →
48
MCQmedium

A DevOps engineer is troubleshooting a CloudFormation stack creation failure. The stack includes an EC2 instance with a UserData script that installs software. The stack creation fails with the error: 'The following resource(s) failed: EC2Instance (AWS::EC2::Instance) – Resource creation cancelled'. What is the most likely cause?

A.The EC2 instance type is not supported in the region
B.The IAM role attached to the instance lacks permissions
C.The stack creation timed out or was manually cancelled
D.The UserData script failed due to a syntax error
AnswerC

When a CloudFormation stack has a TimeoutInMinutes value and that timeout is exceeded, or when a user calls CancelUpdateStack or moves to cancel the operation in the console, all resources that are still in a CREATE_IN_PROGRESS state are marked with status 'Resource creation cancelled'. This is an orchestration-level interruption: CloudFormation abandons the pending resource creation and begins rolling back the stack. Because the EC2 instance creation was still in progress when the stack operation was aborted, the event correctly indicates this is the most plausible explanation.

Why this answer

The error message 'Resource creation cancelled' indicates that the CloudFormation stack creation was either timed out or manually cancelled, not that the EC2 instance itself failed. CloudFormation has a default timeout of 60 minutes for stack creation, and if the UserData script takes longer than this or the user manually cancels the operation, CloudFormation will mark the resource as cancelled. This is distinct from a resource-specific failure like an invalid instance type or IAM permissions issue, which would produce a different error message such as 'Resource failed to stabilize' or 'API error'.

Exam trap

The trap here is that candidates often confuse a UserData script failure with a resource creation failure, but CloudFormation does not monitor UserData execution; it only tracks the EC2 instance's state transition to 'running', so a script error would not cause a cancellation error.

How to eliminate wrong answers

Option A is wrong because an unsupported instance type would cause a specific API error like 'InvalidParameterValue: Instance type not supported in this region', not a 'Resource creation cancelled' message. Option B is wrong because insufficient IAM permissions would result in an 'AccessDenied' or 'UnauthorizedOperation' error during resource creation, not a cancellation error. Option D is wrong because a UserData script syntax error would not cause the EC2 instance creation to be cancelled; the instance would still be created successfully, and the script failure would be logged in the instance's system logs, but CloudFormation would not cancel the resource creation due to a script error.

Practice this question →
49
MCQeasy

A company uses AWS OpsWorks for configuration management. The DevOps team wants to automate the patching of operating system updates on a set of EC2 instances managed by OpsWorks. Which OpsWorks feature should be used?

A.Weekly Auto Update
B.Auto Scaling
C.Chef Automate
D.Lifecycle events (Setup, Configure, Deploy, etc.)
AnswerA

Weekly Auto Update is a built-in OpsWorks Stacks feature that schedules automatic installation of operating system updates on a weekly basis. You configure a maintenance window per layer, and OpsWorks applies patches to existing instances using the OS package manager during that window. This directly addresses the company's requirement for automated patch management without the need for custom Chef recipes.

Why this answer

AWS OpsWorks Stacks provides a built-in 'Weekly Auto Update' feature that automatically installs operating system updates on managed EC2 instances. This feature is specifically designed to automate OS patching without requiring custom recipes or manual intervention, making it the correct choice for the DevOps team's requirement.

Exam trap

The trap here is that candidates may confuse lifecycle events (which are powerful for custom automation) with the built-in patching feature, overlooking the simpler Weekly Auto Update option that directly addresses the patching requirement without custom recipes.

How to eliminate wrong answers

Option B (Auto Scaling) is wrong because Auto Scaling manages instance capacity and scaling policies, not OS patching or configuration management. Option C (Chef Automate) is wrong because Chef Automate is a separate Chef product for continuous automation workflows, not a feature of AWS OpsWorks Stacks. Option D (Lifecycle events) is wrong because while lifecycle events like Setup, Configure, and Deploy can trigger custom Chef recipes, they are not a dedicated feature for automated OS patching; using them for patching would require writing and maintaining custom recipes, whereas the Weekly Auto Update feature provides a built-in, simpler solution.

Practice this question →
50
MCQhard

A company uses AWS CloudFormation to manage a production environment. The DevOps team wants to implement a change management process where any changes to the stack must be reviewed before execution. Which feature should the team use?

A.CloudFormation StackSets
B.CloudFormation Stack Policies
C.CloudFormation Change Sets
D.CloudFormation Drift Detection
AnswerC

CloudFormation Change Sets allow you to preview the complete impact of proposed stack changes—including resource additions, modifications, and deletions—without applying them. This enables you to review the exact changes, identify potential replacements or unintended side effects, and then execute the change set to safely update your production stack with confidence.

Why this answer

CloudFormation Change Sets allow the DevOps team to preview how proposed changes to a stack will impact running resources before they are executed. This enables a review-and-approval workflow because the change set can be created, reviewed, and then executed only after approval, satisfying the requirement for a change management process.

Exam trap

The trap here is that candidates often confuse Stack Policies (which control update permissions) with Change Sets (which provide a preview), or they assume Drift Detection can be used to review proposed changes when it only detects unmanaged changes after they occur.

How to eliminate wrong answers

Option A is wrong because CloudFormation StackSets are used to deploy stacks across multiple accounts and regions, not to review or approve changes to a single stack. Option B is wrong because Stack Policies define resource-level update protections (e.g., prevent replacement of a database) but do not provide a preview or review step before changes are applied. Option D is wrong because Drift Detection identifies whether a stack's actual resources have diverged from the template, but it does not control or review proposed changes before execution.

Practice this question →
51
MCQhard

A DevOps team is troubleshooting a CloudFormation stack creation failure. The stack uses a service role with the trust policy shown in the exhibit. The error message states: 'Insufficient permissions to create the resource'. Which action should the team take to resolve this issue?

A.Modify the CloudFormation template to use the user's IAM role instead of a service role.
B.Create a new stack policy that allows the required actions.
C.Add the user's IAM role to the trust policy.
D.Attach IAM policies to the service role that grant permissions to create the resources.
AnswerD

To resolve the stack creation failure, you must attach IAM policies to the service role that explicitly allow the actions needed to create the resources declared in the template, such as ec2:CreateSecurityGroup on the appropriate resource ARN. CloudFormation assumes the service role at the start of the stack operation and uses the role's permissions to make the resource API calls; without a policy granting those actions, the API calls will be denied even if the user's own credentials have broad access. Use managed policies or an inline policy that grants only the required resource types to follow least privilege, and verify the role's trust policy still allows CloudFormation to assume it.

Why this answer

The error 'Insufficient permissions to create the resource' indicates that the service role used by CloudFormation lacks the necessary IAM permissions to perform the resource creation actions. The trust policy shown in the exhibit allows CloudFormation to assume the role, but the role itself must have IAM policies attached that grant the required permissions (e.g., ec2:*, s3:*). Option D is correct because attaching the appropriate IAM policies to the service role resolves the permission issue.

Exam trap

The trap here is that candidates confuse a stack policy (which controls update protection) with IAM permissions, or they think modifying the trust policy (who can assume the role) fixes a missing permissions issue, when in reality the role's attached policies must grant the actual resource creation actions.

How to eliminate wrong answers

Option A is wrong because modifying the template to use the user's IAM role instead of a service role would bypass the service role but does not address the underlying permission issue; the user's role may also lack permissions, and this approach violates least privilege by mixing user and service identities. Option B is wrong because a stack policy controls updates to existing stack resources (e.g., preventing accidental deletion), not the permissions required to create resources during stack creation; stack policies do not grant IAM permissions. Option C is wrong because adding the user's IAM role to the trust policy would allow the user's role to be assumed by CloudFormation, but the error is about the service role's lack of permissions, not about who can assume it; the trust policy already allows CloudFormation to assume the service role.

Practice this question →
52
MCQmedium

A company uses AWS OpsWorks for configuration management. They have a stack with a layer that includes several EC2 instances. The DevOps engineer needs to deploy a custom configuration file to all instances in the layer. What is the recommended approach?

A.Use custom JSON in the stack settings to specify the file content
B.Create a custom Chef recipe and assign it to the layer's lifecycle events
C.Use AWS Systems Manager Run Command to copy the file
D.Add the file to the instance's user data script
AnswerB

Create a custom Chef recipe that uses a 'file' or 'template' resource to generate the configuration content, then assign that recipe to the layer's lifecycle events, typically Setup or Configure. OpsWorks runs the recipe on every instance in the layer at the appropriate stage, making it the standard, lifecycle-aware mechanism for delivering managed configuration files. The recipe is idempotent and runs with full Chef knowledge of the stack, which is why this approach is the correct answer.

Why this answer

AWS OpsWorks is a configuration management service that uses Chef. The recommended approach to deploy custom configuration files to all instances in a layer is to create a custom Chef recipe and assign it to the layer's lifecycle events (e.g., Setup, Configure, Deploy, or Shutdown). This ensures the recipe runs automatically on every instance in the layer at the appropriate stage of the instance lifecycle, providing a consistent and idempotent deployment method.

Exam trap

The trap here is that candidates often confuse OpsWorks custom JSON with a mechanism to directly inject file content, when in reality it only provides attribute data to Chef recipes, and the actual file deployment must be handled by a recipe's file or template resource.

How to eliminate wrong answers

Option A is wrong because custom JSON in stack settings is used to pass data to Chef recipes (e.g., as node attributes), not to directly define file content; it cannot replace a recipe's file resource. Option C is wrong because AWS Systems Manager Run Command is an external ad-hoc execution tool that does not integrate with OpsWorks lifecycle events, and it would require manual targeting and lack the automated, layer-wide consistency that OpsWorks provides. Option D is wrong because user data scripts run only once at instance launch and are not tied to OpsWorks lifecycle events; they cannot be used to update or manage configuration files on running instances or across lifecycle stages like Setup or Configure.

Practice this question →
53
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 →
54
MCQmedium

A company uses Chef for configuration management of their EC2 instances. They want to use AWS OpsWorks for Chef Automate to manage the Chef server. What is the primary benefit of using OpsWorks for Chef Automate compared to running a self-managed Chef server?

A.It provides a graphical user interface to author cookbooks.
B.It creates cookbooks based on the instance configuration.
C.It reduces operational overhead by managing the Chef server's infrastructure.
D.It automatically applies cookbooks to all instances in the account.
AnswerC

AWS OpsWorks for Chef Automate is a fully managed Chef server: AWS provisions, patches, backs up, and scales the Chef server components (including the PostgreSQL backend, bookshelf, nginx, and Chef Automate services). This removes the operational overhead of running and maintaining your own Chef infrastructure, such as handling backups, failover, and version upgrades. Using the managed service lets engineers focus on authoring cookbooks and managing node lifecycle rather than babysitting the Chef server itself.

Why this answer

The primary benefit of AWS OpsWorks for Chef Automate is that it reduces operational overhead by managing the Chef server's infrastructure, including patching, backups, scaling, and high availability. This allows teams to focus on authoring cookbooks and managing node configurations rather than maintaining the Chef server itself.

Exam trap

The trap here is that candidates may confuse OpsWorks for Chef Automate with AWS OpsWorks Stacks, which does provide a GUI for lifecycle events and automatic cookbook application, leading them to incorrectly select options A or D.

How to eliminate wrong answers

Option A is wrong because OpsWorks for Chef Automate does not provide a graphical user interface to author cookbooks; cookbooks are authored locally using tools like Chef Workstation or a text editor and then uploaded to the Chef server. Option B is wrong because OpsWorks for Chef Automate does not create cookbooks based on instance configuration; cookbooks are written by users to define desired state, and the service only manages the Chef server, not the cookbook creation process. Option D is wrong because OpsWorks for Chef Automate does not automatically apply cookbooks to all instances in the account; nodes must be registered with the Chef server and assigned run-lists, and the service does not enforce automatic application across all instances.

Practice this question →
55
MCQeasy

A DevOps engineer runs the command shown in the exhibit. The output shows the stack status as ROLLBACK_COMPLETE. Which statement best describes the current state of the stack?

A.The stack was created successfully and is in a steady state.
B.The stack update failed and has been rolled back to the previous state.
C.The stack is currently in the process of rolling back after a failed creation.
D.The stack creation failed and has been rolled back. No resources remain.
AnswerD

The status ROLLBACK_COMPLETE after a stack creation failure means CloudFormation has finished cleaning up all resources that were created during the failed creation attempt. This terminal state indicates that the stack creation failed, the automatic rollback has completed, and no resources remain from that stack. The stack itself may still appear in the console with this status, but it is not active and holds no provisioned resources.

Why this answer

The ROLLBACK_COMPLETE status in AWS CloudFormation indicates that a stack creation or update operation failed and the stack has been fully rolled back. When a stack creation fails and rolls back, CloudFormation deletes all resources that were created during the failed creation attempt, leaving no resources remaining. This is the correct interpretation for a stack that was being created (not updated) and ended in ROLLBACK_COMPLETE.

Exam trap

The trap here is that candidates confuse ROLLBACK_COMPLETE with a successful rollback that preserves resources, but for a creation failure, all resources are deleted, whereas for an update failure, the previous resources are restored.

How to eliminate wrong answers

Option A is wrong because ROLLBACK_COMPLETE is not a steady state; it indicates a failure occurred and resources were rolled back, not a successful creation. Option B is wrong because ROLLBACK_COMPLETE can occur during a stack creation or update, but the question states the stack was created (not updated), and the output shows no prior stack state; if it were an update rollback, the stack would revert to the previous successful state, but the status still indicates failure, not a steady state. Option C is wrong because ROLLBACK_COMPLETE means the rollback has finished, not that it is in progress; the in-progress status would be ROLLBACK_IN_PROGRESS.

Practice this question →
56
MCQhard

A DevOps engineer uses AWS CloudFormation to manage infrastructure. The stack creation fails with the error: 'Circular dependency between resources'. The template includes an EC2 instance, an Elastic IP, and an internet gateway. The instance is associated with the Elastic IP, and the Elastic IP uses the internet gateway for the VPC. Which resource relationship is MOST likely causing the circular dependency?

A.The security group depends on the EC2 instance, and the EC2 instance depends on the security group.
B.The Elastic IP depends on the internet gateway, and the internet gateway depends on the Elastic IP.
C.The EC2 instance depends on the Elastic IP, and the Elastic IP depends on the EC2 instance.
D.The internet gateway depends on the VPC, and the VPC depends on the internet gateway.
AnswerC

This is the correct circular dependency: if the EC2 instance declares DependsOn the Elastic IP (e.g., to ensure the IP exists before the instance starts) and the Elastic IP itself has a dependency on the instance (typically through an AWS::EC2::EIPAssociation resource, which requires the instance ID), CloudFormation cannot determine which resource to create first. The two resources form a closed loop, causing stack creation to fail with a circular dependency error. In practice you should let only the EIP association depend on the instance, or only the instance depend on the EIP, not both.

Why this answer

The circular dependency arises when the EC2 instance depends on the Elastic IP (via an Association resource) and the Elastic IP depends on the EC2 instance (via the InstanceId property). CloudFormation cannot resolve the creation order when two resources each require the other to exist first. This is a classic circular dependency in CloudFormation templates when using an AWS::EC2::EIP with an InstanceId that references the EC2 instance, while the instance itself has a DependsOn or a reference to the Elastic IP.

Exam trap

The trap here is that candidates confuse the Elastic IP's dependency on the internet gateway (which is not direct) with the mutual dependency between the EC2 instance and the Elastic IP when the EIP uses the InstanceId property.

How to eliminate wrong answers

Option A is wrong because a security group does not depend on an EC2 instance; the instance depends on the security group, and CloudFormation handles this as a one-way dependency. Option B is wrong because an Elastic IP does not depend on an internet gateway; the Elastic IP is associated with a VPC or instance, and the internet gateway is attached to the VPC independently. Option D is wrong because an internet gateway depends on the VPC (via VpcId), but the VPC does not depend on the internet gateway; the VPC is created first, and the gateway is attached to it.

Practice this question →
57
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 →
58
Multi-Selecthard

A company is using AWS Elastic Beanstalk for a production environment. They have observed that during deployments, the environment's health status intermittently becomes 'Severe' even though the application is functioning correctly. The deployment uses rolling updates with a batch size of 50%. Which TWO configuration changes would improve deployment stability without completely redesigning the deployment process? (Select TWO.)

Select 2 answers
A.Switch from rolling to immutable updates.
B.Increase the health check interval to allow more time for the application to stabilize.
C.Increase the batch size to 75%.
D.Decrease the deployment cooldown time.
E.Decrease the batch size to 25%.
AnswersB, E

Elastic Beanstalk uses Elastic Load Balancing health checks to assess instance readiness during a deployment. If an application takes longer to initialize than the configured health check interval, it can be prematurely marked OutOfService, triggering unnecessary instance replacement and deployment failure. Increasing the health check interval directly gives each instance more time to respond successfully before a health check is performed, preventing false negatives during the startup window. This is the most targeted fix for an application that is healthy but simply needs more time to stabilize.

Why this answer

Increasing the health check interval gives the application more time to stabilize after an update, reducing false 'Severe' health statuses. Option E is correct because decreasing the batch size to 25% reduces the number of instances updated at once, limiting the blast radius of any issues. Option A (switching to immutable updates) changes the deployment strategy, which may not be desired.

Option C (increasing batch size to 75%) increases the number of instances updated simultaneously, worsening stability. Option D (decreasing deployment cooldown time) would shorten the wait between batches, not allowing enough time for the application to stabilize, potentially increasing instability.

Practice this question →
59
MCQhard

A company runs a production e-commerce platform on AWS. The architecture includes an Application Load Balancer (ALB) distributing traffic across EC2 instances in an Auto Scaling group. The application uses a custom configuration stored in an S3 bucket. The DevOps team uses AWS CodeDeploy to deploy application updates. Recently, a deployment failed because new instances launched by the Auto Scaling group did not have the latest configuration from S3. The team had manually updated the configuration in S3 but the deployment did not pull the new version. The team wants to ensure that all instances always have the latest configuration at launch. Current setup: The Auto Scaling group uses a launch template that specifies an IAM instance profile with permissions to read from S3. The user data script runs at launch to download configuration from S3. However, the user data script is static and does not account for configuration updates. The team wants a solution that automatically applies configuration changes to both existing and new instances without manual intervention.

A.Use AWS Config with a custom rule to detect instances that do not have the latest configuration and trigger a Lambda function to update them.
B.Update the launch template with a new user data script that always fetches the latest configuration from S3. Then, update the Auto Scaling group to use the new launch template version.
C.Configure AWS CodeDeploy to deploy the configuration to all instances whenever the S3 object is updated, using an S3 event notification.
D.Use AWS Systems Manager State Manager to associate a document that runs on all instances to fetch the latest configuration from S3 on a schedule and at instance startup.
AnswerD

State Manager is AWS Systems Manager's configuration management feature that lets you create associations between documents and EC2 instances, selected via tags or resource groups. Because the association targets are evaluated dynamically, new instances that match the tag get the association automatically, and existing instances are handled on the next scheduled run or at startup. You can schedule the association with a rate or cron expression, and also trigger it on instance startup, ensuring the S3 configuration is fetched on a regular basis and after each boot, making it proactive and fully automated.

Why this answer

AWS Systems Manager State Manager can associate a document with instances to run on a schedule and at instance startup, ensuring they fetch the latest configuration from S3. This automatically applies configuration changes to both existing and new instances without manual intervention.

Exam trap

The trap is choosing solutions that only address new instances or require manual intervention. Candidates might think updating the launch template is sufficient, but it does not update existing instances or automatically apply changes when the S3 object is updated.

How to eliminate wrong answers

Option A is wrong because AWS Config is for compliance auditing, not for applying configuration changes; using a Lambda function would require custom code and may not trigger at instance launch. Option B is wrong because updating the launch template only affects new instances, not existing ones, and still requires a new version and manual update of the Auto Scaling group. Option C is wrong because CodeDeploy is for application deployments, not for configuration management from S3; S3 event notifications can trigger CodeDeploy but it would not automatically apply to new instances at launch.

Practice this question →
60
MCQhard

A company uses AWS CloudFormation to manage its infrastructure. The CloudFormation template includes a custom resource backed by an AWS Lambda function that validates a condition and returns a value. During a stack update, the custom resource fails, and the stack rolls back. The DevOps engineer needs to debug the issue. Which steps should be taken to troubleshoot the custom resource failure?

A.View the Amazon CloudWatch Logs log group for the Lambda function to see the function's output and error messages.
B.Update the Lambda function code to include additional logging and then re-execute the stack update.
C.Check the Amazon S3 bucket where the Lambda function code is stored for any access denied errors.
D.Review the CloudFormation stack events in the AWS Management Console for detailed error messages from the Lambda function.
AnswerA

Custom resource Lambda functions emit all stdout, stderr, and unhandled exceptions to their CloudWatch Logs log group, typically named /aws/lambda/<function-name>. Inspecting that log stream gives you the exact Python/Node.js stack trace and any print statements from the function, which is the definitive first diagnostic step for a CloudFormation custom resource failure. The CloudFormation event itself will only tell you that the Lambda failed, so this is where the actual error message lives.

Why this answer

AWS Lambda functions invoked by CloudFormation custom resources automatically send their logs to Amazon CloudWatch Logs. By examining the log group named `/aws/lambda/<function-name>`, the DevOps engineer can view the function's `stdout`, `stderr`, and any `print()` or `console.log()` statements, which will contain the exact error messages or return values that caused the custom resource to fail. This is the most direct and reliable method to debug the failure without modifying the stack or waiting for a new update.

Exam trap

Candidates may expect CloudFormation stack events to provide Lambda function logs, but stack events only show the failure status and, if the custom resource provider returns a reason, that reason; they do not contain the function's stdout/stderr. CloudWatch Logs is the source for the actual execution output.

How to eliminate wrong answers

Option B is wrong because updating the Lambda function code and re-executing the stack update does not help debug the original failure; it changes the code and may mask the root cause, and the stack update would still need to be triggered again. Option C is wrong because the Lambda function code is stored in Amazon S3 only for deployment; access denied errors on the S3 bucket would prevent the function from being created or updated, but they would not cause a custom resource failure during a stack update — the function is already deployed and running. Option D is wrong because CloudFormation stack events only show high-level status messages like 'CREATE_FAILED' or 'UPDATE_FAILED' for the custom resource, but they do not include the detailed error messages or return values from the Lambda function itself; those details are only available in CloudWatch Logs.

Practice this question →
61
MCQeasy

A DevOps team uses Ansible for configuration management of EC2 instances. They want to ensure that the Ansible control node can connect to managed nodes securely without storing SSH keys in plaintext. Which AWS service should they integrate with Ansible to securely manage SSH keys?

A.AWS KMS to encrypt the SSH keys at rest.
B.AWS Secrets Manager to store the SSH private keys and retrieve them dynamically.
C.AWS IAM roles to grant Ansible access to the instances.
D.AWS Systems Manager Parameter Store to store the keys.
AnswerB

AWS Secrets Manager is the correct choice because it is purpose-built for storing sensitive credentials such as SSH private keys and exposing them to applications through a controlled API. Ansible can call GetSecretValue at runtime to retrieve the key, eliminating hardcoded keys in playbooks or source control, and you can enforce IAM policies to restrict which roles and users can access the secret. Secrets Manager also supports automatic secret rotation, which lets you periodically rotate SSH keys without changing Ansible configuration, and it can be integrated directly with Ansible modules or AWS CLI calls.

Why this answer

AWS Secrets Manager is designed to store, rotate, and retrieve secrets such as SSH private keys programmatically, and Ansible can integrate with it via lookup plugins or dynamic inventory to fetch keys at runtime without persisting them in plaintext on the control node. This satisfies the requirement of secure, dynamic key management with rotation support.

Exam trap

DOP-C02 often tests the distinction between services that store secrets (Secrets Manager, Parameter Store) and services that encrypt or authorize (KMS, IAM), so candidates who pick KMS or IAM miss the requirement for dynamic secret retrieval.

How to eliminate wrong answers

Option A is wrong because AWS KMS encrypts data at rest but does not provide a mechanism for Ansible to dynamically retrieve SSH private keys during playbook execution — it is an encryption service, not a secrets store. Option C is wrong because IAM roles grant AWS API permissions but do not store or deliver SSH keys; they are an authorization mechanism, not a secret repository. Option D is wrong because Systems Manager Parameter Store can store SecureString parameters, but it lacks native rotation and is generally used for configuration values rather than SSH key lifecycle management, making Secrets Manager the more appropriate choice for this scenario.

Practice this question →
62
MCQhard

A DevOps engineer is designing a CI/CD pipeline for a microservices architecture on AWS. They want to use AWS CodeDeploy to deploy applications to an Auto Scaling group. The pipeline must ensure that only a small percentage of instances are updated at a time, and if health checks fail, the deployment is automatically rolled back. Which deployment configuration should be used?

A.Blue/green deployment with a fixed number of instances.
B.In-place deployment with 'CodeDeployDefault.AllAtOnce' configuration.
C.In-place deployment with 'CodeDeployDefault.HalfAtATime' configuration.
D.In-place deployment with 'CodeDeployDefault.OneAtATime' configuration and automatic rollback enabled.
AnswerD

In-place deployment with 'CodeDeployDefault.OneAtATime' configuration is the built-in CodeDeploy strategy that stages the deployment to a single instance at a time, waiting for the instance to pass health checks before proceeding to the next. When the fleet size is reasonably large, one instance represents a small percentage of total traffic, satisfying the gradual rollout requirement. Enabling automatic rollback ensures that if any instance fails its health check or a deployment hook returns a non-zero exit code, CodeDeploy immediately redeploys the previous revision and stops the deployment, minimizing impact.

Why this answer

`CodeDeployDefault.OneAtATime` deploys to one instance at a time, which is the smallest possible batch and satisfies the 'small percentage of instances' requirement. Enabling automatic rollback ensures that if health checks fail, CodeDeploy reverts to the last known good revision, meeting the rollback requirement.

Exam trap

The trap is equating 'small percentage' with HalfAtATime (50% is not small) or assuming blue/green is always safer — but blue/green does not meet the explicit 'small percentage of instances updated at a time' wording in the question.

How to eliminate wrong answers

Option A is wrong because blue/green deployment shifts traffic between two environments and does not inherently limit updates to a small percentage of instances in an Auto Scaling group — it replaces the whole fleet, and 'fixed number of instances' is not a standard CodeDeploy configuration name. Option B is wrong because `AllAtOnce` updates every instance simultaneously, maximizing blast radius and violating the small-percentage requirement. Option C is wrong because `HalfAtATime` updates 50% of instances at once, which is not a 'small percentage' and would cause significant capacity loss during deployment.

Practice this question →
63
MCQhard

A DevOps engineer is troubleshooting a CloudFormation stack that is in UPDATE_ROLLBACK_FAILED state. The stack attempted to update an Auto Scaling group but failed due to insufficient capacity in the Availability Zone. What is the recommended next step?

A.Execute a new stack update with the same template
B.Manually increase the Auto Scaling group capacity in the affected AZ
C.Use the ContinueUpdateRollback operation to skip the resources that failed
D.Delete the Auto Scaling group and recreate it
AnswerC

The ContinueUpdateRollback operation is the correct remediation because it explicitly resumes the failed rollback, allowing CloudFormation to finish reverting the stack to its last known good state. By specifying ResourcesToSkip, you can instruct CloudFormation to skip the specific resources that caused the rollback to fail, such as resources with external dependencies that cannot be rolled back automatically. This is the documented, supported approach to recover a stack stuck in UPDATE_ROLLBACK_FAILED. Once the rollback completes, the stack returns to a usable state, and you can then address the skipped resource manually.

Why this answer

When a CloudFormation stack is in UPDATE_ROLLBACK_FAILED state, the recommended next step is to use the ContinueUpdateRollback operation with the 'ResourcesToSkip' parameter to skip the resources that failed during rollback. This allows CloudFormation to complete the rollback of the remaining resources and move the stack to a stable state, after which you can investigate and fix the underlying issue (e.g., insufficient capacity in the AZ) before attempting the update again. Option C directly aligns with AWS documentation for handling this specific stack state.

Exam trap

The trap here is that candidates may think manually fixing the underlying issue (e.g., increasing capacity) is sufficient to resolve the rollback failure, but they overlook that CloudFormation requires an explicit ContinueUpdateRollback API call to exit the UPDATE_ROLLBACK_FAILED state, even after the root cause is addressed.

How to eliminate wrong answers

Option A is wrong because executing a new stack update with the same template will likely fail again due to the same insufficient capacity issue in the AZ, and CloudFormation will not bypass the failed resource without explicit skip instructions. Option B is wrong because manually increasing the Auto Scaling group capacity in the affected AZ does not resolve the rollback failure; the stack remains in UPDATE_ROLLBACK_FAILED state and requires the ContinueUpdateRollback operation to proceed. Option D is wrong because deleting the Auto Scaling group and recreating it is an overly destructive action that does not address the stack's rollback state and may cause data loss or service disruption; CloudFormation provides the ContinueUpdateRollback operation specifically to handle such scenarios without manual resource deletion.

Practice this question →
64
MCQhard

A company uses AWS Config to evaluate compliance of their AWS resources. They have a custom rule that checks whether EC2 instances have a specific tag. They notice that the rule is not triggering on existing instances. What is a possible reason?

A.The rule is not configured with a trigger type of 'Configuration changes' or 'Periodic'
B.AWS Config does not support custom rules
C.The Lambda function does not have permission to describe EC2 instances
D.The EC2 instances are not in the resource types being recorded by AWS Config
AnswerA

An AWS Config rule, whether managed or custom, must be associated with at least one trigger type — `Configuration changes` or `Periodic` — to initiate evaluations. Without such a trigger, the rule never runs, leaving all resources in a `Not evaluated` state because AWS Config has no basis to invoke the rule's evaluation logic. In the AWS Management Console, the rule would show no compliance results, which exactly matches the described symptom. Adding a configuration-change trigger (for EC2 instances) or a periodic schedule (e.g., every 24 hours) is the necessary fix.

Why this answer

AWS Config custom rules require a trigger type to evaluate resources. If a rule is not configured with either 'Configuration changes' (triggered when a resource changes) or 'Periodic' (triggered on a schedule), it will never evaluate resources, including existing instances. Without a trigger, the rule remains inactive and cannot perform compliance checks.

Exam trap

The trap here is that candidates often assume a custom rule automatically evaluates all resources upon creation, but AWS Config requires an explicit trigger type to initiate evaluation, and without it, the rule remains dormant.

How to eliminate wrong answers

Option B is wrong because AWS Config fully supports custom rules via AWS Lambda functions, which can evaluate resources against custom logic. Option C is wrong because insufficient Lambda permissions would cause evaluation failures or errors, not prevent the rule from triggering on existing instances; the rule would still attempt to run but fail. Option D is wrong because if EC2 instances are not in the resource types being recorded, AWS Config would not track them at all, but the question states the rule is not triggering on existing instances, implying they are recorded; the core issue is the missing trigger type.

Practice this question →
65
MCQmedium

A company manages its infrastructure using AWS CloudFormation. They have a production stack that includes an Amazon RDS Multi-AZ DB instance. The stack was created using the 'aws cloudformation create-stack' command with default settings. The DB instance uses a custom DB parameter group. A DevOps engineer needs to modify a parameter in the DB parameter group and update the stack. The engineer updates the template to change the parameter value and runs 'aws cloudformation update-stack'. The update fails with a 'ROLLBACK_IN_PROGRESS' status. The engineer checks the CloudFormation console and sees that the DB instance was successfully modified, but the stack is rolling back. The rollback fails because the DB instance cannot be reverted to the original parameter value. The stack is now in 'UPDATE_ROLLBACK_FAILED' state. What should the engineer do to resolve this situation and apply the desired parameter change?

A.Run 'aws cloudformation update-stack' again with the original template to revert the changes.
B.Use the 'aws cloudformation continue-update-rollback' command with the '--resources-to-skip' parameter to skip the DB instance, allowing the stack to reach 'UPDATE_ROLLBACK_COMPLETE'. Then apply a change set with the desired parameter change.
C.Revert the parameter value manually in the RDS console and then resume the rollback.
D.Delete the stack and recreate it with the updated template.
AnswerB

The continue-update-rollback command is the designed mechanism to recover from a failed rollback. By specifying --resources-to-skip, you tell CloudFormation to ignore the RDS DB instance that is blocking the rollback, allowing the stack to transition to UPDATE_ROLLBACK_COMPLETE. Once stable, you can use a change set to reapply the desired parameter change in a controlled, reversible way, ensuring the stack's template and live resources are aligned.

Why this answer

When a CloudFormation stack is in UPDATE_ROLLBACK_FAILED state, the `continue-update-rollback` command with `--resources-to-skip` allows you to skip the resource that cannot be rolled back (the RDS DB instance with the custom parameter group). This moves the stack to UPDATE_ROLLBACK_COMPLETE, after which you can apply a change set with the desired parameter change. This approach avoids manual intervention or stack deletion while preserving the modified DB instance.

Exam trap

The trap here is that candidates may think manual reversion or stack deletion is required, but CloudFormation provides a built-in recovery mechanism (`continue-update-rollback`) that avoids downtime and data loss.

How to eliminate wrong answers

Option A is wrong because running `update-stack` with the original template would attempt to revert the DB parameter group, which already failed to roll back, and would likely fail again or cause further issues. Option C is wrong because manually reverting the parameter value in the RDS console does not resolve the CloudFormation stack's failed rollback state; the stack remains in UPDATE_ROLLBACK_FAILED and cannot resume rollback without CloudFormation's `continue-update-rollback` command. Option D is wrong because deleting and recreating the stack would cause downtime and data loss for the production RDS DB instance, and is unnecessarily destructive when a non-disruptive recovery path exists.

Practice this question →
66
Multi-Selectmedium

A company is using AWS CloudFormation to deploy a multi-tier application. The DevOps team wants to ensure that the database password is not exposed in the template or the console. Which two methods should they use to securely manage the password? (Choose TWO.)

Select 2 answers
A.Hardcode the password in the template and use a condition to only apply it in production.
B.Use a CloudFormation parameter with the NoEcho property set to true.
C.Store the password in AWS Systems Manager Parameter Store and reference it with {{resolve:ssm:...}}
D.Use a dynamic reference to AWS Secrets Manager secret in the CloudFormation template.
E.Pass the password as user data to the EC2 instance and encrypt the user data.
AnswersB, D

A CloudFormation parameter with the NoEcho property set to true is a valid way to pass a password because the value is supplied at stack creation or update time—either via the console, CLI, or API—and is never displayed in the AWS Management Console, returned by DescribeStackResources, or emitted in CloudFormation event logs. However, you must still reference the parameter in the template resource properties so that the actual secret value is used during provisioning, and the secret remains visible to anyone with permission to view the resulting resource configurations (e.g., EC2 instance metadata if you pass it to user data). NoEcho only prevents the value from being echoed back in API responses; it does not encrypt the template or the secret at rest, so you must also ensure IAM policies restrict access to the stack's parameters. This is the simplest built-in mechanism for basic secret handling, but for more robust secret rotation and management, a dynamic reference or service like Secrets Manager is preferred.

Why this answer

Setting the `NoEcho` property to `true` on a CloudFormation parameter masks the password from console outputs and `DescribeStack` calls, preventing exposure in logs or the AWS Management Console. This is a straightforward way to handle sensitive input without external services, though it does not encrypt the value at rest in the template.

Exam trap

The trap here is that candidates often confuse `NoEcho` with encryption, thinking it secures the value at rest, when it only masks output; or they incorrectly assume that Systems Manager Parameter Store's `{{resolve:ssm:...}}` syntax works universally in CloudFormation, when it requires the `ssm-secure` variant and has property-specific limitations.

Practice this question →
67
MCQeasy

A CloudFormation template snippet is shown. An engineer attempts to create a stack with this template and receives an error: 'Bucket my-unique-bucket-name already exists'. What is the most likely cause?

A.The bucket policy has a syntax error that prevents the bucket from being created.
B.The S3 bucket name 'my-unique-bucket-name' is already taken by another AWS account.
C.The versioning configuration is incompatible with the bucket policy.
D.The bucket policy references the bucket name incorrectly, causing a circular dependency.
AnswerB

S3 bucket names exist in a single global namespace shared by every AWS account and region. Once any account has registered 'my-unique-bucket-name', a CloudFormation CreateBucket call in your account fails with HTTP 409 BucketAlreadyExists, matching the symptom described. Because the error is explicitly tied to the bucket name, the most probable root cause is that another AWS account has already claimed that globally unique string, not a template configuration issue.

Why this answer

S3 bucket names must be globally unique across all AWS accounts and regions. The error 'Bucket my-unique-bucket-name already exists' indicates that the name is already taken by another AWS account, not that the bucket already exists in the current account. CloudFormation cannot create the bucket because the name is not available in the global S3 namespace.

Exam trap

The trap here is that candidates may assume the error refers to a bucket already existing in their own account, but AWS S3 enforces global uniqueness, so the error always means the name is taken by any account in the entire AWS ecosystem.

How to eliminate wrong answers

Option A is wrong because a syntax error in the bucket policy would cause a different validation error (e.g., 'Malformed policy') during stack creation, not a 'Bucket already exists' error. Option C is wrong because versioning configuration and bucket policy are independent settings; incompatibility between them would not produce a 'Bucket already exists' error—it would cause a separate validation or update failure. Option D is wrong because a circular dependency would cause a stack creation failure with a 'Circular dependency' error message, not a 'Bucket already exists' error.

Practice this question →
68
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 →
69
MCQhard

A financial services company uses Chef for configuration management. They need to enforce security compliance across thousands of EC2 instances. The compliance requirements include specific file permissions, firewall rules, and user account settings. They want to automatically remediate non-compliant instances. Which approach is MOST effective?

A.Use AWS Config rules to detect non-compliance and send notifications.
B.Use AWS CloudWatch Events to trigger a Lambda function that runs remediation scripts.
C.Use AWS Systems Manager Patch Manager to apply patches.
D.Use Chef recipes to define desired state and enforce compliance on each client run.
AnswerD

Chef recipes define a declarative desired state for system resources, and the chef-client runs on a schedule (typically every 30 minutes) to converge each node to that state. During each run, the client queries current system state, compares it to the recipe definitions, and automatically remediates any drift—this is true continuous enforcement, not just reporting. Because chef-client is idempotent, repeated runs are safe, which is essential in a regulated financial environment where config drift must be corrected promptly and consistently.

Why this answer

Chef is already in use for configuration management, and its core strength is enforcing desired state through recipes. By running Chef client on each EC2 instance (via cron or Systems Manager), non-compliant instances are automatically remediated on each convergence cycle without needing separate detection or notification tools. This approach directly addresses the requirement for automated remediation using the existing toolchain.

Exam trap

The trap here is that candidates often overcomplicate the solution by adding AWS services (Config, Lambda) when the existing Chef tool already provides built-in, continuous compliance enforcement through its converge cycle.

How to eliminate wrong answers

Option A is wrong because AWS Config rules only detect and evaluate compliance but do not automatically remediate; they require additional services like Systems Manager Automation or Lambda for remediation. Option B is wrong because CloudWatch Events (now Amazon EventBridge) can trigger Lambda, but this is an event-driven, reactive approach that adds complexity and latency compared to Chef's built-in continuous enforcement. Option C is wrong because Patch Manager is specifically for OS patch management, not for enforcing file permissions, firewall rules, or user account settings.

Practice this question →
70
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 →
71
Multi-Selecteasy

Which TWO AWS services can be used to automate the configuration of EC2 instances at launch? (Choose two.)

Select 2 answers
A.Amazon CloudWatch
B.EC2 user data
C.AWS CloudFormation
D.Amazon Inspector
E.AWS Config
AnswersB, C

EC2 user data is a feature that lets you pass a script or cloud-init directives to an instance at launch; the script runs automatically the first time the instance boots, enabling package installation, file creation, and service configuration. This provides imperative, instance-level configuration automation for initial setup, though it does not manage ongoing changes or coordinate multiple resources. It is a direct and valid way to automate EC2 configuration.

Why this answer

EC2 user data allows you to specify scripts or cloud-init directives that run automatically during the first boot cycle of an EC2 instance. This enables automated software installation, configuration, and post-launch tasks without manual intervention, making it a core tool for instance configuration at launch.

Exam trap

The trap here is that candidates often confuse AWS Config (which audits existing configurations) or CloudWatch (which monitors) with services that can actively configure instances at launch, when in fact only user data and infrastructure-as-code tools like CloudFormation can perform that initial automation.

Practice this question →
72
Multi-Selecteasy

A DevOps engineer is writing an AWS CloudFormation template to create a VPC with public and private subnets. The engineer wants to ensure that the private subnets can access the internet through a NAT gateway. Which resources must be included in the template? (Choose TWO.)

Select 2 answers
A.AWS::EC2::RouteTable
B.AWS::EC2::VPNGateway
C.AWS::EC2::InternetGateway
D.AWS::EC2::NatGateway
E.AWS::EC2::VPCEndpoint
AnswersA, D

An AWS::EC2::RouteTable is correct because a private subnet cannot reach the internet on its own; you must create a route table and explicitly associate it with the private subnet. Within that route table, a route with destination 0.0.0.0/0 pointing to the NAT gateway is required, and the association between the route table and the subnet is what makes the NAT gateway the effective next hop for all outbound internet traffic.

Why this answer

A is correct because an AWS::EC2::RouteTable resource is required to define the routing rules for the private subnets. Specifically, you must create a route table for the private subnets and add a default route (0.0.0.0/0) that points to the NAT gateway, enabling outbound internet traffic from instances in the private subnets while blocking inbound traffic from the internet.

Exam trap

The trap here is that candidates often think an Internet Gateway is required for private subnet internet access, but the NAT gateway itself uses the internet gateway; the template only needs the NAT gateway and a route table for the private subnets, not the internet gateway resource directly.

Practice this question →
73
MCQeasy

A company uses AWS Systems Manager to manage its EC2 instances at scale. The DevOps team wants to ensure that all instances are patched with the latest security updates. Which Systems Manager capability should they use to automate patching?

A.Run Command
B.Patch Manager
C.Automation
D.State Manager
AnswerB

Patch Manager is the dedicated Systems Manager capability for automating the entire patching workflow, including scan and install operations using patch baselines, and it integrates with maintenance windows for controlled deployments. It also generates patch compliance data that can be queried across your fleet, which is exactly what is required when you need to keep EC2 instances patched automatically.

Why this answer

Patch Manager is the correct choice because it is the dedicated AWS Systems Manager capability designed to automate the process of patching managed instances with security updates and other types of updates. It uses patch baselines to define which patches should be installed and can schedule patching on a recurring basis, ensuring compliance across the EC2 fleet.

Exam trap

The trap here is that candidates often confuse Patch Manager with State Manager because both can enforce desired states, but State Manager lacks the patching-specific logic and patch baseline integration that Patch Manager provides.

How to eliminate wrong answers

Option A is wrong because Run Command is used to execute ad-hoc scripts or commands on instances, not to manage or schedule recurring patching operations. Option C is wrong because Automation is a general-purpose capability for automating common maintenance and deployment tasks, but it does not provide the built-in patch baseline management and compliance reporting that Patch Manager offers. Option D is wrong because State Manager is used to define and maintain consistent configuration state of instances (e.g., ensuring a specific software is installed or a service is running), but it lacks the native patching workflows and patch-specific features like approval rules and auto-approval delays.

Practice this question →
74
MCQhard

A company uses AWS CloudFormation StackSets to deploy a common security baseline across multiple AWS accounts. They have a new account that needs to be added to the StackSet. The StackSet is configured with self-service permissions and uses a service-managed IAM role. What must be done to include the new account?

A.Create an IAM role in the new account that trusts the StackSet.
B.Create a new StackSet that includes the new account.
C.Manually create a stack instance for the new account in the StackSet.
D.Add the new account to the AWS Organization.
AnswerD

Service-managed StackSets are tightly integrated with AWS Organizations, so adding the new account to the organization makes it a recognized target account for the StackSet. Once the account is part of the organization, CloudFormation automatically creates and manages stack instances in every configured region for that account, without requiring manual role setup or stack creation. This approach preserves the existing StackSet's configuration and operational tracking, and it is the intended mechanism for onboarding a new account to a service-managed StackSet.

Why this answer

When a StackSet uses service-managed permissions, it relies on AWS Organizations to manage accounts. To include a new account, you must add it to the AWS Organization; the StackSet will automatically deploy stack instances to that account based on the specified organizational units (OUs) or accounts. This is because service-managed permissions use a service-linked role created and managed by CloudFormation, not a manually created IAM role in the target account.

Exam trap

The trap here is that candidates often confuse self-service permissions (which require manual IAM role creation and stack instance management) with service-managed permissions (which rely on AWS Organizations for automatic account and stack instance management), leading them to choose Option A or C incorrectly.

How to eliminate wrong answers

Option A is wrong because with service-managed permissions, CloudFormation automatically creates and manages the necessary IAM role in the target account via a service-linked role; you do not need to manually create an IAM role. Option B is wrong because creating a new StackSet is unnecessary; you can add the new account to the existing StackSet by adding it to the Organization or updating the StackSet's target accounts/OUs. Option C is wrong because manually creating a stack instance is not possible with service-managed permissions; the StackSet automatically manages stack instances based on the Organization structure, and manual creation is only available with self-service permissions.

Practice this question →
75
MCQhard

A DevOps engineer receives the error shown in the exhibit when attempting to update an existing CloudFormation stack that deploys a VPC with subnets. The stack was created successfully earlier using the same template. What is the most likely cause of this error?

A.The subnet ID in the template is already used by another stack in the same account.
B.The IAM role used for the stack update lacks the 'ec2:DescribeSubnets' permission.
C.The subnet specified in the template does not exist in the selected AWS region.
D.The CloudFormation template has a syntax error in the subnet definition.
AnswerB

CloudFormation uses the IAM service role's permissions when performing stack updates. If the role lacks ec2:DescribeSubnets, the update fails with an access denied error, exactly as shown in the exhibit. This permission is required for CloudFormation to validate the subnet and retrieve its attributes during the update. Adding ec2:DescribeSubnets to the role's policy resolves the issue.

Why this answer

When updating a CloudFormation stack that deploys a VPC with subnets, the update operation must be able to read the current state of the subnet resources to determine if changes are needed. The IAM role used for the stack update must have the 'ec2:DescribeSubnets' permission to query the existing subnet configuration. Without this permission, CloudFormation cannot verify the subnet's current properties, leading to the error shown in the exhibit.

Exam trap

The trap here is that candidates often assume the error is due to a template syntax issue or resource conflict, but the real cause is insufficient IAM permissions for the update operation, which is a subtle but critical distinction in CloudFormation stack management.

How to eliminate wrong answers

Option A is wrong because subnet IDs are unique within an AWS account per region, and CloudFormation does not reuse subnet IDs across stacks; the error is not about ID conflicts. Option C is wrong because the stack was created successfully earlier using the same template, so the subnet does exist in the region; the error occurs during the update, not the initial creation. Option D is wrong because a syntax error in the template would have been caught during the initial stack creation, not during an update of an existing stack that was previously created successfully.

Practice this question →
Page 1 of 3 · 215 questions totalNext →

Ready to test yourself?

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

Start 20-question session