Task 2.1: Define cloud infrastructure and reusable components to provision and manage systems throughout their lifecycle.

• AAdd the 5xx alarm as a rollback trigger in the stack's rollback configuration, with a monitoring time of 15 minutes

  Correct

  CloudFormation watches rollback triggers during the update and for the monitoring time after all resources are deployed, and rolls back the whole operation if an alarm goes into ALARM.

• BRun each update with the option to preserve successfully provisioned resources, so that a failed update keeps the healthy resources

  Incorrect

  This option changes what happens when a resource fails to provision. It does not watch an alarm, so an update that succeeds is never rolled back.

• CKeep the Mappings section and have a scheduled Lambda function rewrite the AMI IDs in the template whenever a new AMI is published

  Incorrect

  Mappings hold fixed values inside the template, so each new AMI still means a template change, now made by code the team must maintain.

• DDeclare the AMI as a parameter of type AWS::SSM::Parameter::Value<AWS::EC2::Image::Id> that defaults to the public Amazon Linux 2023 AMI parameter

  Correct

  CloudFormation reads the latest value from Parameter Store when a stack is created or updated, and the public parameter in each Region holds that Region's latest AMI ID.

• ESet the stack's monitoring time to 15 minutes in the rollback configuration, with no rollback triggers

  Incorrect

  Without rollback triggers, CloudFormation only waits for the monitoring time before it cleans up old resources. It watches no alarm and rolls nothing back on its own.

Two separate gaps need two separate features. A Systems Manager parameter type makes the template resolve the AMI ID from Parameter Store at each create or update, and the public Amazon Linux parameters always point at the latest image in their Region. Rollback triggers make the alarm part of the stack operation, and the monitoring time extends that watch past the moment the last resource is deployed.

• ACreate a pipeline in AWS CodePipeline for each stack, with a GitLab source action and a CloudFormation deploy action that updates the stack

  Incorrect

  This would deploy the changes, but it means building and operating 25 pipelines, which the team does not want.

• BSchedule drift detection on every stack each hour with Amazon EventBridge Scheduler and notify the team about stacks that drifted

  Incorrect

  Drift detection compares the live resources with the stack's current template. It does not read the repository or apply new templates.

• CSet up Git sync for each stack through an AWS CodeConnections connection, with a stack deployment file that holds its parameters and tags

  Correct

  Git sync monitors the branch and updates the stack when the template or deployment file changes, and it can comment on pull requests with a summary of the stack changes.

• DPoint each stack's TemplateURL at the raw file URL of its template in GitLab, so that CloudFormation reads the latest version from the branch

  Incorrect

  TemplateURL must point to a template in an Amazon S3 bucket or a Systems Manager document, and a stack is updated only when an update operation runs.

Git sync makes the repository the source of truth for a stack without a pipeline: CloudFormation watches one branch for the template and a stack deployment file with up to 50 parameters and 50 tags, and applies each committed change. With comments turned on, it also explains in the pull request what the change will do to the stack.

• APublish each pattern as an AWS Service Catalog product in a portfolio shared with the workload accounts, with a launch constraint

  Correct

  With a launch constraint, Service Catalog assumes the given role to launch the product, so developers need permissions only for Service Catalog, not for the underlying services.

• BRegister the patterns as CloudFormation modules in each account's registry and let developers include the modules in their own templates

  Incorrect

  Modules package resource configurations for templates, but the stack still creates the resources with the deploying user's or role's permissions.

• CPublish the patterns as an AWS CDK construct library in CodeArtifact and let developers deploy their apps with the cdk deploy command

  Incorrect

  A construct library makes the patterns reusable in code, but deployments still need permissions to create the resources the constructs contain.

• DDeploy each pattern from the central account to the workload accounts with StackSets whenever a developer opens a ticket

  Incorrect

  Developers could not provision on their own; each request would wait for the central team.

Service Catalog separates who may launch a product from what the product may create. Without a launch constraint, end users need permissions for CloudFormation and every service the product uses; with one, they need only Service Catalog permissions.

• AAWS Config, with a custom rule that evaluates the feature settings and an automatic remediation that reverts them

  Incorrect

  AWS Config records and evaluates the configuration of AWS resources. It does not deliver application settings to running code.

• BAWS AppConfig, with a validator for the schema and a deployment strategy that is monitored by the error alarm

  Correct

  AppConfig changes application behavior without redeploying code, validates configuration data before deployment, rolls it out gradually, and rolls back when a monitored alarm goes into ALARM.

• CParameter Store, with the settings in a parameter that the application reads at startup and caches until the next deployment

  Incorrect

  A value read at startup changes only when tasks or functions start again, and a parameter update has no validation, gradual rollout or automatic revert.

• DA State Manager association that writes the settings to a file on each host on a schedule, with rate controls for the rollout

  Incorrect

  State Manager keeps managed nodes in a state you define. Files written to hosts do not reach the code running in Lambda functions, and nothing validates or rolls back the change.

Feature flags are application configuration, not resource configuration. AppConfig adds the safety controls for it: validators before a deployment, linear or exponential deployment strategies, and automatic rollback driven by CloudWatch alarms.

• ARun cdk bootstrap in the new tooling account with --trust set to the production account's ID

  Incorrect

  Trust is set in the account that receives deployments. Bootstrapping the tooling account lets production deploy into tooling, the opposite direction.

• BRun cdk bootstrap in the production account with --trust set to only the new tooling account's ID and the existing execution policies

  Incorrect

  When trusted accounts are added to an existing bootstrap stack, any account left out of the list is removed, so the old pipeline would stop working.

• CCreate an IAM role in the production account that trusts the new tooling account and attach AdministratorAccess to it

  Incorrect

  CDK deployments use the roles that bootstrapping creates in the target environment, so an extra role the pipeline does not use changes nothing.

• DRun cdk bootstrap in the production account with --trust for both tooling accounts and the existing --cloudformation-execution-policies

  Correct

  --trust names the accounts that may deploy into the bootstrapped environment, it requires execution policies, and every trusted account must be listed again when the list changes.

Cross-account CDK deployments rely on the trust set when the target account is bootstrapped. The bootstrap command replaces the trusted account list, so adding an account means passing the whole list, and the execution policies are granted to every account on it.

• ARun drift detection on the stack to see how the resources would change with the new template

  Incorrect

  Drift detection compares resources with the current template, not with the proposed one.

• BCreate a change set, review its replacement details, and execute it only if acceptable

  Correct

  Change sets preview how changes affect running resources, including replacements, and apply only when executed.

• CRun validate-template on the new template to find properties that cause replacement

  Incorrect

  Template validation checks syntax; it does not compare against running resources.

• DAdd a stack policy that denies Update:Replace and run the update to see whether it fails

  Incorrect

  This uses a failed update as a test instead of previewing the changes.

A change set shows the actions CloudFormation would take, such as modify or replace, before any change is made. Creating it also runs pre-deployment validation checks.

• AA separate load balancer stack per application that exports values for the application stack to import

  Incorrect

  Exports suit stacks with independent lifecycles and lock the exported values.

• BA StackSet that deploys the load balancer template to every account where the applications run

  Incorrect

  StackSets deploy stacks to accounts and Regions; they do not reuse a pattern inside application stacks.

• CFn::ForEach in each application template to repeat the load balancer resources

  Incorrect

  ForEach repeats fragments inside one template; it does not share a definition across templates.

• DA dedicated load balancer template used as a nested stack in each application template

  Correct

  Nested stacks reuse a dedicated template from other templates and are managed as part of their root stack.

Nested stacks split common configurations into dedicated templates that other templates reference. They are created and updated with their parent stack.

• ACreate the stack with the option to preserve successfully provisioned resources

  Correct

  With this option, successful resources are kept and failed ones stay in a failed state until the next operation.

• BAdd DeletionPolicy Retain to every resource so that rollback leaves them in place

  Incorrect

  Retained resources would leave the stack and could not be resumed from the failure point.

• CSplit the template into many small stacks that each create one resource

  Incorrect

  This changes the architecture instead of using the failure options.

• DRaise the stack creation timeout so that the failing resource has more time

  Incorrect

  More time does not fix a failure that is not a timeout.

Preserving successfully provisioned resources lets engineers troubleshoot resources in a failed state and resume provisioning instead of starting over. It is available for stack and change set operations.

• ASAM connectors from each function to its table and to its secret, with Read and Write permissions

  Incorrect

  Connectors generate scoped policies for a function and a DynamoDB table, but Secrets Manager is not a supported connector destination.

• BAWS managed policies such as AmazonDynamoDBFullAccess and SecretsManagerReadWrite in each function's Policies property

  Incorrect

  The names are short and standard, but these policies allow dynamodb:* and secretsmanager:* on all resources, not on one table or secret.

• CSAM policy templates such as DynamoDBCrudPolicy and AWSSecretsManagerGetSecretValuePolicy with each function's resources

  Correct

  Policy templates are predefined, parameterized policies that scope a function to the table and the secret it names, for both services.

• DA permissions boundary on every function role that allows only DynamoDB and Secrets Manager actions on the application's resources

  Incorrect

  A boundary sets the maximum permissions a role can have; it grants nothing and does not scope a function to its own table or secret.

SAM policy templates take parameters such as a table name or a secret ARN and expand into least-privilege policies. Connectors are a simpler option where they apply, but only for the source and destination types they support.

• AA StackSet that deploys the hardened bucket to every application account

  Incorrect

  A StackSet creates separate stacks rather than a block included in application templates.

• BA CloudFormation module registered in the registry and used in the templates

  Correct

  Modules package resource configurations for inclusion across templates as reusable building blocks.

• CA shared YAML snippet that application teams copy into their templates as needed

  Incorrect

  Copied snippets drift and are not published centrally in the registry.

• DA Lambda-backed custom resource that creates the bucket and its settings

  Incorrect

  This adds custom code to maintain for what modules provide declaratively.

CloudFormation modules encapsulate common configurations and best practices as building blocks registered in the registry, which templates include like a resource.