Opsworks

Beanstalk vs OpsWorks vs CloudFormation

~ Last updated on : ~ jayendrapatil ~ 14 Comments

⚠️ PARTIAL DEPRECATION NOTICE

AWS OpsWorks (all variants) reached End of Life (EOL) in 2024.

  • AWS OpsWorks for Puppet Enterprise – EOL March 31, 2024
  • AWS OpsWorks for Chef Automate – EOL May 5, 2024
  • AWS OpsWorks Stacks – EOL May 26, 2024

The OpsWorks services have been disabled for both new and existing customers. The comparison sections involving OpsWorks are maintained for historical reference.

Current Deployment & Management Options:

  • AWS CloudFormation – Infrastructure as Code (still actively supported and enhanced)
  • AWS Elastic Beanstalk – Simplified application deployment (still actively supported)
  • AWS CDK – Programmatic infrastructure definition using familiar languages
  • AWS Systems Manager – Configuration management and automation (OpsWorks replacement)
  • AWS CodeDeploy – Application deployment automation
  • AWS App Runner – Fully managed container application service

For OpsWorks migration guidance, refer to: AWS OpsWorks EOL Documentation

AWS Elastic Beanstalk vs CloudFormation vs CDK – Deployment & Management Services Comparison

AWS offers multiple options for provisioning IT infrastructure and application deployment and management, varying from convenience & ease of setup to low-level granular control.
Deployment and Management - Elastic Beanstalk vs CloudFormation vs CDK

AWS Elastic Beanstalk

  • AWS Elastic Beanstalk is a higher-level service which allows you to quickly deploy with minimum management effort a web or worker-based environment using EC2, Docker using ECS, Elastic Load Balancing, Auto Scaling, RDS, CloudWatch, etc.
  • Elastic Beanstalk is the fastest and simplest way to get an application up and running on AWS, perfect for developers who want to deploy code and not worry about underlying infrastructure.
  • Elastic Beanstalk provides an environment to easily deploy and run applications in the cloud. It is integrated with developer tools and provides a one-stop experience for application lifecycle management.
  • Elastic Beanstalk requires minimal configuration and will help deploy, monitor, and handle the elasticity/scalability of the application.
  • A user doesn’t need to do much more than write application code and configure some settings on Elastic Beanstalk.
  • Supports platforms including Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker on Amazon Linux 2 and Amazon Linux 2023.
  • AI-Powered Environment Analysis (2026) – Elastic Beanstalk now offers AI-powered analysis that automatically diagnoses environment health issues, identifies root causes, and provides recommended solutions when health status is Warning, Degraded, or Severe.
  • Dual-Stack IPv6 Support (2025) – Supports dual-stack configuration for Application Load Balancers and Network Load Balancers, allowing environments to serve both IPv4 and IPv6 traffic.

AWS OpsWorks (Deprecated – EOL 2024)

⚠️ All AWS OpsWorks services reached End of Life in 2024 and have been disabled for all customers.
  • AWS OpsWorks was an application management service that simplified software configuration, application deployment, scaling, and monitoring using Chef or Puppet.
  • OpsWorks was recommended for managing infrastructure with a configuration management system such as Chef.
  • OpsWorks enabled writing custom Chef recipes, utilized self-healing, and worked with layers.
  • Although OpsWorks was a deployment management service that helped deploy applications with Chef recipes, it was not primarily meant to manage scaling out of the box and needed to be handled explicitly.
  • Migration Paths:
    • AWS Systems Manager – For configuration management and automation (recommended by AWS)
    • Chef SaaS – For customers who want to continue using Chef recipes
    • Puppet Enterprise – Self-hosted Puppet for existing Puppet users
    • AWS CodeDeploy – For application deployment workflows
    • Amazon ECS/EKS – For containerized workloads

AWS CloudFormation

  • AWS CloudFormation enables modeling, provisioning, and version-controlling of a wide range of AWS resources ranging from a single EC2 instance to a complex multi-tier, multi-region application.
  • CloudFormation is a low-level service and provides granular control to provision and manage stacks of AWS resources based on templates (JSON or YAML).
  • CloudFormation templates enable version control of the infrastructure and make deployment of environments easy and repeatable.
  • CloudFormation supports infrastructure needs of many different types of applications such as existing enterprise applications, legacy applications, applications built using a variety of AWS resources, and container-based solutions (including those built using AWS Elastic Beanstalk).
  • CloudFormation is not just an application deployment tool but can provision any kind of AWS resource.
  • CloudFormation is designed to complement Elastic Beanstalk and other AWS services.
  • CloudFormation with Elastic Beanstalk
    • CloudFormation supports Elastic Beanstalk application environments as one of the AWS resource types.
    • This allows you, for example, to create and manage an AWS Elastic Beanstalk–hosted application along with an RDS database to store the application data. In addition to RDS instances, any other supported AWS resource can be added to the group as well.
  • Key Updates (2024-2025):
    • Stack Refactoring (2025) – Move resources between stacks, rename logical IDs, and decompose monolithic templates into focused components without disrupting running infrastructure.
    • 40% Faster Deployments (2024) – Optimistic stabilization with CONFIGURATION_COMPLETE event enables parallel creation of dependent resources.
    • IaC Generator – Generate CloudFormation templates from existing AWS resources (reverse-engineer existing infrastructure into IaC).
    • Configuration Drift Management – Improved drift detection and remediation capabilities.
    • AI Integration – IaC context integrated with AI-powered development tools.

AWS Cloud Development Kit (AWS CDK)

  • AWS CDK is an open-source software development framework that allows you to define cloud infrastructure using familiar programming languages (TypeScript, JavaScript, Python, Java, C#/.NET, Go).
  • CDK synthesizes into CloudFormation templates, providing the reliability of CloudFormation with the expressiveness of general-purpose programming languages.
  • CDK provides high-level constructs (L2/L3) that encapsulate AWS best practices and reduce the amount of boilerplate code needed.
  • CDK is ideal for teams who prefer imperative programming over declarative YAML/JSON templates.
  • Same infrastructure that takes 500+ lines of CloudFormation YAML can be expressed in ~15 lines of CDK TypeScript.
  • CDK Refactoring (2025) – Refactor CDK code (rename constructs, move resources between stacks) while preserving deployed resources.
  • CDK Mixins (2026) – Add composable, reusable abstractions to any construct (L1, L2, or custom) without rebuilding existing infrastructure code.
  • CDK Aspects – Apply organization-wide policies (security rules, tagging standards, compliance requirements) across entire infrastructure.

AWS Serverless Application Model (AWS SAM)

  • AWS SAM is an open-source framework specifically designed for building serverless applications using infrastructure as code.
  • SAM extends CloudFormation with shorthand syntax to express Lambda functions, APIs, databases, and event source mappings with fewer lines of code.
  • During deployment, SAM transforms the SAM syntax into CloudFormation syntax, then CloudFormation provisions the resources.
  • SAM CLI provides local testing, debugging, packaging, and deployment capabilities.
  • SAM Accelerate – Speeds up local development and cloud testing.
  • WebSocket API Support (2026) – Define complete WebSocket APIs for API Gateway with minimal configuration.
  • SAM CLI integrates with AWS CDK and Terraform.

AWS App Runner

  • AWS App Runner is a fully managed container application service that lets you build, deploy, and run containerized web applications and API services without prior infrastructure or container experience.
  • App Runner connects directly to your code or image repository and provides an automatic CI/CD pipeline with fully managed operations, high performance, scalability, and security.
  • App Runner automatically handles load balancing, auto-scaling (including scale to zero), encryption, and health monitoring.
  • Ideal for web applications and APIs that need to deploy quickly from source code or container images without managing infrastructure.
  • Supports deployment from GitHub, Bitbucket, or Amazon ECR.

AWS Proton (Deprecated – EOL October 7, 2026)

⚠️ AWS Proton will reach End of Life on October 7, 2026. Plan migration accordingly.
  • AWS Proton was a fully managed deployment service that standardized how organizations deploy microservices and infrastructure from approved templates.
  • Proton sat on top of CloudFormation (or Terraform) and added self-service deployment, versioning, parameter validation, and standardization.
  • Designed for platform teams to provide standardized templates while giving developers self-service deployment speed.
  • After EOL, the Proton console, API, and pipeline management will be permanently unavailable, though deployed infrastructure will remain intact.

Comparison Summary

Service Level Best For Status
Elastic Beanstalk High-level PaaS Developers who want to deploy code without managing infrastructure ✅ Active
CloudFormation Low-level IaC Granular control over all AWS resources via declarative templates ✅ Active
AWS CDK High-level IaC Teams who prefer defining infrastructure in programming languages ✅ Active
AWS SAM Serverless IaC Serverless applications (Lambda, API Gateway, DynamoDB) ✅ Active
App Runner Fully Managed Container web apps/APIs without any infrastructure management ✅ Active
OpsWorks Configuration Mgmt Chef/Puppet based configuration management ❌ EOL (2024)
AWS Proton Template Orchestration Standardized microservice deployment templates ⚠️ EOL Oct 2026

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your team is excited about the use of AWS because now they have access to programmable infrastructure. You have been asked to manage your AWS infrastructure in a manner similar to the way you might manage application code. You want to be able to deploy exact copies of different versions of your infrastructure, stage changes into different environments, revert back to previous versions, and identify what versions are running at any particular time (development, test, QA, production). Which approach addresses this requirement?
    1. Use cost allocation reports and AWS OpsWorks to deploy and manage your infrastructure.
    2. Use AWS CloudWatch metrics and alerts along with resource tagging to deploy and manage your infrastructure.
    3. Use AWS Elastic Beanstalk and a version control system like GIT to deploy and manage your infrastructure.
    4. Use AWS CloudFormation and a version control system like GIT to deploy and manage your infrastructure.
  2. An organization is planning to use AWS for their production roll out. The organization wants to implement automation for deployment such that it will automatically create a LAMP stack, download the latest PHP installable from S3 and setup the ELB. Which of the below mentioned AWS services meets the requirement for making an orderly deployment of the software?
    1. AWS Elastic Beanstalk
    2. AWS CloudFront
    3. AWS CloudFormation
    4. AWS DevOps
  3. You are working with a customer who is using Chef configuration management in their data center. Which service is designed to let the customer leverage existing Chef recipes in AWS?
    Note: AWS OpsWorks reached EOL in 2024. For Chef-based configuration management on AWS, customers should now use Chef SaaS or AWS Systems Manager with Chef recipes via Application Manager.
    1. Amazon Simple Workflow Service
    2. AWS Elastic Beanstalk
    3. AWS CloudFormation
    4. AWS OpsWorks (Historical answer – service now deprecated)
  4. A company wants to define their infrastructure using a programming language like TypeScript instead of writing YAML templates. They want the same reliability as CloudFormation but with less boilerplate code. Which AWS service should they use?
    1. AWS Elastic Beanstalk
    2. AWS Cloud Development Kit (CDK)
    3. AWS SAM
    4. AWS App Runner
  5. A startup wants to deploy a containerized web application with minimal infrastructure management. They want automatic scaling, load balancing, and a CI/CD pipeline connected to their GitHub repository. Which AWS service provides the simplest solution?
    1. Amazon ECS with Fargate
    2. AWS Elastic Beanstalk
    3. AWS App Runner
    4. AWS CloudFormation
  6. A team is building a serverless application using Lambda functions, API Gateway, and DynamoDB. They want to define their infrastructure using a simplified template syntax with built-in local testing capabilities. Which tool is most appropriate?
    1. AWS CloudFormation
    2. AWS CDK
    3. AWS SAM
    4. AWS Elastic Beanstalk
  7. An organization has a large monolithic CloudFormation stack that they want to split into smaller, focused stacks without recreating their existing infrastructure. Which CloudFormation feature enables this?
    1. CloudFormation StackSets
    2. CloudFormation Change Sets
    3. CloudFormation Stack Refactoring
    4. CloudFormation Nested Stacks

References

AWS OpsWorks

~ Last updated on : ~ jayendrapatil ~ 3 Comments

⚠️ AWS OpsWorks — ALL VARIANTS DEPRECATED (End of Life 2024)

All AWS OpsWorks services have reached End of Life and are fully disabled:

  • OpsWorks for Puppet Enterprise — EOL March 31, 2024
  • OpsWorks for Chef Automate — EOL May 5, 2024
  • OpsWorks Stacks — EOL May 26, 2024

The OpsWorks console, API, CLI, and CloudFormation resources have been discontinued in all AWS Regions for both new and existing customers.

Migration Options:

This content is maintained for historical reference and AWS certification exam preparation.

AWS OpsWorks

  • AWS OpsWorks was a configuration management service that helped configure and operate applications in a cloud enterprise by using Chef or Puppet
  • OpsWorks offered three variants: OpsWorks Stacks, OpsWorks for Chef Automate, and OpsWorks for Puppet Enterprise
  • All OpsWorks services reached End of Life in 2024 and have been replaced by AWS Systems Manager Application Manager

OpsWorks Variants (Historical)

  • OpsWorks Stacks — Used Chef cookbooks for configuration management with a simplified layer-based architecture (EOL May 26, 2024)
  • OpsWorks for Chef Automate — Fully managed Chef Automate server for running Chef cookbooks and compliance automation (EOL May 5, 2024)
  • OpsWorks for Puppet Enterprise — Fully managed Puppet Enterprise server for Puppet-based configuration management (EOL March 31, 2024)

Migration to AWS Systems Manager

  • AWS recommends migrating OpsWorks workloads to AWS Systems Manager Application Manager
  • Systems Manager provides equivalent or superior functionality for all OpsWorks Stacks features:
OpsWorks Feature Systems Manager Equivalent
Chef Runs Systems Manager Run Command (AWS-ApplyChefRecipes)
Chef Parameters SSM Parameter Store
EC2 Instance Configuration EC2 Launch Templates
Auto Scaling (load/time-based) EC2 Auto Scaling Groups
Instance Life Cycle Events Auto Scaling Groups Life Cycle Events
Load Balancing Application Load Balancer / Classic Load Balancer
Infrastructure Provisioning AWS CloudFormation
Chef Client Logs Amazon S3 / CloudWatch Logs

OpsWorks Stacks (Historical Reference)

AWS OpsWorks Stacks

  • OpsWorks Stacks provided a simple and flexible way to create and manage stacks, groups of AWS resources like load balancers, web, application and database servers, and application deployed on them
  • OpsWorks Stacks helped deploy and monitor applications in the stacks.
  • Unlike OpsWorks for Chef Automate, OpsWorks Stacks did not require or create Chef servers; and performed some of the work of a Chef server itself
  • OpsWorks Stacks monitored instance health, and provisioned new instances, when necessary, by using Auto Healing and Auto Scaling
  • OpsWorks Stacks integrated with IAM to control how users can interact with stacks, what stacks can do on the users behalf, what AWS resources an app can access etc
  • OpsWorks Stacks integrated with CloudWatch and CloudTrail to enable monitoring and logging
  • OpsWorks Stacks could be accessed globally and used to create and manage instances globally

Stacks

  • Stack was the core AWS OpsWorks Stacks component.
  • Stack was a container for AWS resources like EC2, RDS instances etc that had a common purpose and should be logically managed together
  • Stack helped manage the resources as a group and also defined some default configuration settings, such as the instances’ OS and AWS region
  • Stacks could also be run in VPC to be isolated from direct user interaction
  • Separate Stacks could be created for different environments like Dev, QA etc

Layers

  • Stacks helped manage cloud resources in specialized groups called layers.
  • A layer represented a set of EC2 instances that served a particular purpose, such as serving applications or hosting a database server.
  • Layers depended on Chef recipes to handle tasks such as installing packages on instances, deploying apps, and running scripts
  • Custom recipes and related files were packaged in one or more cookbooks and stored in a cookbook repository such S3 or Git

Recipes and LifeCycle Events

  • Layers depended on Chef recipes to handle tasks such as installing packages on instances, deploying apps, running scripts, and so on.
  • OpsWorks Stacks ran the recipes for each layer, even if the instance belonged to multiple layers for e.g. instance hosting both the application and the mysql server
  • AWS OpsWorks Stacks featured a set of lifecycle events – Setup, Configure, Deploy, Undeploy, and Shutdown – which automatically ran specified set of recipes at the appropriate time on each instance
    • Setup
      • Once a new instance had booted, OpsWorks triggered the Setup event, which ran recipes to set up the instance according to the layer configuration for e.g. installation of apache, PHP packages
      • Once setup was complete, AWS OpsWorks triggered a Deploy event, which ran recipes to deploy the application to the new instance.
    • Configure
      • Whenever an instance entered or left the online state, AWS OpsWorks triggered a Configure event on all instances in the stack.
      • Event ran each layer’s configure recipes to update configuration to reflect the current set of online instances for e.g. the HAProxy layer’s Configure recipes can modify the load balancer configuration to reflect any added or removed application server instances.
    • Deploy
      • OpsWorks triggered a Deploy event when the Deploy command was executed, to deploy the application to a set of application servers.
      • Event ran recipes on the application servers to deploy application and any related files from its repository to the layer’s instances.
    • Undeploy
      • OpsWorks triggered an Undeploy event when an app was deleted or Undeploy command was executed to remove an app from a set of application servers.
      • Event ran recipes to remove all application versions and perform any additional cleanup tasks.
    • Shutdown
      • OpsWorks triggered a Shutdown event when an instance was being shut down, but before the underlying EC2 instance was actually terminated.
      • Event ran recipes to perform cleanup tasks such as shutting down services.
      • OpsWorks allowed Shutdown recipes a configurable amount of time to perform their tasks, and then terminated the instance.

Instance

  • An instance represented a single computing resource for e.g. EC2 instance and defined the resource’s basic configuration, such as OS and size
  • OpsWorks Stacks created instances and added them to a layer.
  • When the instance was started, OpsWorks Stacks launched an EC2 instance using the configuration settings specified by the instance and its layer.
  • After the EC2 instance finished booting, OpsWorks Stacks installed an agent that handled communication between the instance and the service and ran the appropriate recipes in response to lifecycle events
  • OpsWorks Stacks supported instance auto-healing, whereby if an agent stopped communicating with the service, OpsWorks Stacks automatically stopped and restarted the instance
  • OpsWorks Stacks supported the following instance types
    • 24/7 instances – launched and stopped manually
    • Time based instances – run on scheduled time
    • Load based instances – automatically started and stopped based on configurable load metrics
  • Linux based computing resources created outside of the OpsWorks stacks for e.g. console or CLI could be added, incorporated and controlled through OpsWorks

Apps

  • An AWS OpsWorks Stacks app represented code to run on an application server residing in the app repository like S3
  • App contained the information required to deploy the code to the appropriate application server instances.
  • When an app was deployed, AWS OpsWorks Stacks triggered a Deploy event, which ran the Deploy recipes on the stack’s instances.
  • OpsWorks supported the ability to deploy multiple apps per stack and per layer

OpsWorks Deployment Strategies

Refer to OpsWorks Deployment Strategies blog post for details

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  • NOTE: AWS OpsWorks reached End of Life in 2024. These questions are maintained for historical reference. Current AWS exams may still reference OpsWorks concepts in the context of migration scenarios.
  1. You are working with a customer who is using Chef configuration management in their data center. Which service is designed to let the customer leverage existing Chef recipes in AWS?
    1. Amazon Simple Workflow Service
    2. AWS Elastic Beanstalk
    3. AWS CloudFormation
    4. AWS OpsWorks (NOTE: OpsWorks reached EOL in 2024. The current alternative is AWS Systems Manager with the AWS-ApplyChefRecipes Run Command document.)
  2. Your mission is to create a lights-out datacenter environment, and you plan to use AWS OpsWorks to accomplish this. First you created a stack and added an App Server layer with an instance running in it. Next you added an application to the instance, and now you need to deploy a MySQL RDS database instance. Which of the following answers accurately describe how to add a backend database server to an OpsWorks stack? Choose 3 answers
    1. Add a new database layer and then add recipes to the deploy actions of the database and App Server layers. (Refer link)
    2. Use OpsWorks’ “Clone Stack” feature to create a second RDS stack in another Availability Zone for redundancy in the event of a failure in the Primary AZ. To switch to the secondary RDS instance, set the [:database] attributes to values that are appropriate for your server which you can do by using custom JSON.
    3. The variables that characterize the RDS database connection—host, user, and so on—are set using the corresponding values from the deploy JSON’s [:deploy][:app_name][:database] attributes. (Refer link)
    4. Cookbook attributes are stored in a repository, so OpsWorks requires that the “password”: “your_password” attribute for the RDS instance must be encrypted using at least a 256-bit key.
    5. Set up the connection between the app server and the RDS layer by using a custom recipe. The recipe configures the app server as required, typically by creating a configuration file. The recipe gets the connection data such as the host and database name from a set of attributes in the stack configuration and deployment JSON that AWS OpsWorks installs on every instance. (Refer link)
  3. You are tasked with the migration of a highly trafficked node.js application to AWS. In order to comply with organizational standards Chef recipes must be used to configure the application servers that host this application and to support application lifecycle events. Which deployment option meets these requirements while minimizing administrative burden?
    1. Create a new stack within Opsworks add the appropriate layers to the stack and deploy the application (NOTE: With OpsWorks EOL, the current equivalent would be using AWS Systems Manager Application Manager with Chef recipes via Run Command.)
    2. Create a new application within Elastic Beanstalk and deploy this application to a new environment (need to comply with chef recipes)
    3. Launch a Node JS server from a community AMI and manually deploy the application to the launched EC2 instance
    4. Launch and configure Chef Server on an EC2 instance and leverage the AWS CLI to launch application servers and configure those instances using Chef.
  4. A web-startup runs its very successful social news application on Amazon EC2 with an Elastic Load Balancer, an Auto-Scaling group of Java/Tomcat application-servers, and DynamoDB as data store. The main web application best runs on m2.xlarge instances since it is highly memory- bound. Each new deployment requires semi-automated creation and testing of a new AMI for the application servers which takes quite a while and is therefore only done once per week. Recently, a new chat feature has been implemented in node.js and waits to be integrated in the architecture. First tests show that the new component is CPU bound Because the company has some experience with using Chef, they decided to streamline the deployment process and use AWS OpsWorks as an application life cycle tool to simplify management of the application and reduce the deployment cycles. What configuration in AWS OpsWorks is necessary to integrate the new chat module in the most cost-efficient and flexible way?
    1. Create one AWS Ops Works stack, create one AWS Ops Works layer, create one custom recipe
    2. Create one AWS Ops Works stack, create two AWS Ops Works layers create one custom recipe (Single environment stack, two layers for java and node.js application using built-in recipes and custom recipe for DynamoDB connectivity only as other configuration. Refer link)
    3. Create two AWS Ops Works stacks, create two AWS Ops Works layers create one custom recipe
    4. Create two AWS Ops Works stacks, create two AWS Ops Works layers create two custom recipe
  5. You company runs a complex customer relations management system that consists of around 10 different software components all backed by the same Amazon Relational Database (RDS) database. You adopted AWS OpsWorks to simplify management and deployment of that application and created an AWS OpsWorks stack with layers for each of the individual components. An internal security policy requires that all instances should run on the latest Amazon Linux AMI and that instances must be replaced within one month after the latest Amazon Linux AMI has been released. AMI replacements should be done without incurring application downtime or capacity problems. You decide to write a script to be run as soon as a new Amazon Linux AMI is released. Which solutions support the security policy and meet your requirements? Choose 2 answers
    1. Assign a custom recipe to each layer, which replaces the underlying AMI. Use AWS OpsWorks life-cycle events to incrementally execute this custom recipe and update the instances with the new AMI.
    2. Create a new stack and layers with identical configuration, add instances with the latest Amazon Linux AMI specified as a custom AMI to the new layer, switch DNS to the new stack, and tear down the old stack. (Blue-Green Deployment)
    3. Identify all Amazon Elastic Compute Cloud (EC2) instances of your AWS OpsWorks stack, stop each instance, replace the AMI ID property with the ID of the latest Amazon Linux AMI ID, and restart the instance. To avoid downtime, make sure not more than one instance is stopped at the same time.
    4. Specify the latest Amazon Linux AMI as a custom AMI at the stack level, terminate instances of the stack and let AWS OpsWorks launch new instances with the new AMI. (Will lead to downtime)
    5. Add new instances with the latest Amazon Linux AMI specified as a custom AMI to all AWS OpsWorks layers of your stack, and terminate the old ones.
  6. When thinking of AWS OpsWorks, which of the following is not an instance type you can allocate in a stack layer?
    1. 24/7 instances (24/7 instances are supported and started manually and run until you stop them)
    2. Spot instances (OpsWorks did not support spot instances directly but they could be used with auto scaling)
    3. Time-based instances (Time-based instances are run by AWS OpsWorks on a specified daily and weekly schedule)
    4. Load-based instances (Load-based instances are automatically started and stopped by AWS OpsWorks, based on specified load metrics, such as CPU utilization)
  7. Which of the following tools does not directly support AWS OpsWorks, for monitoring your stacks?
    1. AWS Config (Refer link)
    2. Amazon CloudWatch Metrics (AWS OpsWorks used CloudWatch to provide thirteen custom metrics with detailed monitoring for each instance in the stack)
    3. AWS CloudTrail (AWS OpsWorks integrated with CloudTrail to log every AWS OpsWorks API call and store the data in an S3 bucket)
    4. Amazon CloudWatch Logs (Amazon CloudWatch Logs could be used to monitor stack’s system, application, and custom logs.)
  8. When thinking of AWS OpsWorks, which of the following is true?
    1. Stacks have many layers, layers have many instances.
    2. Instances have many stacks, stacks have many layers.
    3. Layers have many stacks, stacks have many instances.
    4. Layers have many instances, instances have many stacks.

References