A company uses several large Chef recipes to automate the configuration of virtual machines (VMs) in its data center. A SysOps administrator is migrating this workload to Amazon EC2 Instances on AWS…

Question

Options

• ACreate a Chef server that includes EC2 instances.
• BSet up AWS OpsWorks for Chef Automate.
• CUpload the existing recipes to Amazon S3.
• DUpload the existing recipes to the user data section during the creation of the EC2 instances.

• A
  4% (1)
• B
  73% (19)
• C
  15% (4)
• D
  8% (2)

Explanation

AWS OpsWorks for Chef Automate is a fully managed service that natively supports Chef recipes, eliminating the need to manage Chef server infrastructure yourself - it handles the orchestration, scaling, and compliance automation at a lower operational cost than self-managing a Chef server.

Why the distractors are wrong:

• A - Running your own Chef server on EC2 works technically, but requires you to provision, patch, and maintain that server, making it more expensive and operationally burdensome than a managed service.
• C - Uploading recipes to S3 just stores the files; S3 has no execution engine to apply those recipes to instances.
• D - EC2 user data runs shell scripts or cloud-init directives at launch, not Chef recipes directly; you'd need additional tooling, and this approach doesn't scale or manage ongoing configuration drift.

Memory tip: Think of the pattern "AWS has a managed service for that" - whenever a question mentions an existing tool (Chef, Puppet, Ansible) being migrated to AWS, look for the OpsWorks variant first. OpsWorks for Chef Automate = Chef, OpsWorks for Puppet Enterprise = Puppet.

No community discussion yet for this question.