Q79 — AWS DOP-C02 Ch.2
Question 79 of 100 | ← Chapter 2
A company wants to deploy a proprietary enterprise in-memory data store using a mesh system on AWS. The system runs across multiple server nodes on any Linux distribution. Whenever nodes are added or removed, the system must reconfigure the entire cluster. Adding or removing nodes requires updating the /etc/cluster/nodes.config file to list the IP addresses of current cluster members.
- A. Use AWS OpsWorks Stacks to layer the cluster's server nodes. Create a Chef recipe that populates the /etc/cluster/nodes.config file content and restarts the service using the current layer members. Assign the recipe to configuration lifecycle events. ✓
- B. Store the nodes.config file in version control. Create an AWS CodeDeploy deployment configuration and deployment group based on Amazon EC2 tag values for cluster nodes. When adding a new node to the cluster, update the file with all tagged instances, commit to version control, then deploy the updated file and restart the service.
- C. Create an Amazon S3 bucket and upload a version of the /etc/cluster/nodes.config file. Create a crontab script that polls the S3 file and downloads it periodically. Use a process manager (e.g., Monit or systemd) to restart the cluster service when a modified file is detected. When adding a node, edit the file to include the latest member and upload the updated file to the S3 bucket.
- D. Create a user data script that lists all members of the cluster's current security group and automatically updates the /etc/cluster/nodes.config file when a new instance is added to the cluster.
Correct Answer: A. Use AWS OpsWorks Stacks to layer the cluster's server nodes. Create a Chef recipe that populates the /etc/cluster/nodes.config file content and restarts the service using the current layer members. Assign the recipe to configuration lifecycle events.
Explanation
The question requires automating node addition to a cluster while dynamically updating membership configuration. Option A uses AWS OpsWorks Stacks with Chef recipes assigned to configuration lifecycle events, enabling automatic population of /etc/cluster/nodes.config and service restart upon node changes — satisfying full automation and cluster-wide reconfiguration. Option B relies on manual commits and deployments, lacking true automation for node addition. Option C introduces unnecessary complexity with polling and external storage, failing to meet simplicity and automation requirements. Option D only handles node addition via user data but does not address cluster-wide reconfiguration or removal scenarios. Thus, Option A best fulfills the requirements.