Organizing AWS CloudFormation Resources
Question
The project you are working on currently uses a single AWS CloudFormation template to deploy its AWS infrastructure, which supports a multi-tier web application.
You have been tasked with organizing the AWS CloudFormation resources so that they can be maintained in the future and different departments such as Networking and Security can review the architecture before it goes to Production.
How should you do this in a way that accommodates each department, using their existing workflows?
Answers
Explanations
Click on the arrows to vote for the correct answer
A. B. C. D.Answer - B.
As your infrastructure grows, common patterns can emerge in which you declare the same components in each of your templates.
You can separate out these common components and create dedicated templates for them.
That way, you can mix and match different templates but use nested stacks to create a single, unified stack.
Nested stacks are stacks that create other stacks.
To create nested stacks, use the AWS::CloudFormation::Stackresource in your template to reference other templates.
For more information on best practices for Cloudformation, please refer to the below link:
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.htmlThe correct answer is B: Separate the AWS CloudFormation template into a nested structure with individual templates for the resources that are to be governed by different departments, and use the outputs from the networking and security stacks for the application template that you control.
Explanation:
Organizing AWS CloudFormation resources can help maintain infrastructure efficiently and enable different departments to review architecture before deployment. Here are the explanations for each answer:
Option A: Organizing the AWS CloudFormation template so that related resources are next to each other in the template is a good practice but may not be sufficient to meet the requirements of different departments. It doesn't allow for the separation of resources to be governed by different departments and doesn't facilitate reviewing the architecture by different teams.
Option B: This option is the best approach because it allows you to create a nested structure for different departments with individual templates for the resources they will govern. It also helps you maintain and update resources independently, which can improve your infrastructure's maintainability. In this scenario, you could create templates for networking and security teams, and they would review and approve the resources they govern before you deploy the entire infrastructure. You could then use outputs from the networking and security stacks for the application template you control. The advantage of this approach is that it reduces the risk of unauthorized access and minimizes the risk of errors during deployment.
Option C: Organizing the AWS CloudFormation template so that related resources are next to each other in the template for each department's use and leveraging your existing continuous integration tool is a good practice, but it can be complex and error-prone. It requires that you have separate deployment processes for each department, which can increase the risk of conflicts and failures during deployment.
Option D: Using a custom application and the AWS SDK to replicate the resources defined in the current AWS CloudFormation template is a valid option, but it can be complex and requires additional resources to maintain the custom application. It also increases the risk of errors during deployment and may not meet the requirement of different departments' review before deploying changes.
Therefore, option B is the best approach as it allows different departments to review the resources they govern before deploying the entire infrastructure and reduces the risk of unauthorized access and errors during deployment.
