A company developed an AWS CloudFormation template used to create all new Amazon DynamoDB tables in its AWS account. The template configures provisioned throughput capacity using hard-coded values…

Question

Options

• AAdd values for the rcuCount and wcuCount parameters to the Mappings section of the template.
• BAdd values for two Number parameters, rcuCount and wcuCount, to the template. Replace the
• CAdd values for the rcuCount and wcuCount parameters as outputs of the template. Configure
• DAdd values for the rcuCount and wcuCount parameters to the Mappings section of the template.

• A
  7% (4)
• B
  73% (40)
• C
  4% (2)
• D
  16% (9)

Explanation

Explanation

Option B is correct because CloudFormation Parameters are specifically designed to accept input values at stack creation or update time, allowing users to provide unique values each time a template is deployed. By defining rcuCount and wcuCount as Number type parameters and replacing the hard-coded values with references (!Ref rcuCount, !Ref wcuCount), each new DynamoDB table can be independently configured with different read/write capacity units.

Why the distractors are wrong:

• Options A and D both suggest using the Mappings section, which stores static, predefined key-value pairs that cannot be changed at deployment time - this simply replaces one form of hard-coding with another, defeating the purpose.
• Option C suggests using Outputs, which are used to export values from a stack after deployment, not to receive configurable input values - Outputs cannot be used to set resource properties dynamically.

Memory Tip

Think of CloudFormation sections with this phrase: "Parameters = Input, Outputs = Export, Mappings = Lookup Table." Whenever a question asks about making a template flexible or configurable at deployment time, Parameters is almost always the answer.

No community discussion yet for this question.