Operational Excellence and Automation practice questions

CloudFormation does not deploy service-managed StackSet instances to the organization's management account.

The behaviour is by design: with service-managed permissions, CloudFormation doesn't deploy stacks to the management account even if it belongs to a targeted OU or the root. The management account therefore needs its own stacks (or a self-managed StackSet whose roles you create). Account filters, re-enabling trusted access or delegated administration do not change that exclusion.

1. Note what succeeded: every member account received the stack.
2. Recall that service-managed StackSets exclude the management account by design.
3. Deploy the template to the management account through a mechanism that does not rely on service-managed targeting.
4. Reject options that only change targeting filters or administration rights.

Exam tip: Service-managed StackSets skip the management account; deploy to it separately.

Account removal behaviour and delegated administration are both StackSet-level settings of the service-managed model.

Two separate needs are stated. Retaining resources when an account leaves a target OU is controlled by the automatic deployment setting RetainStacksOnAccountRemoval (Retain stacks); without it the move triggers a delete. Running operations from a member account requires registering it as a StackSets delegated administrator and calling with DELEGATED_ADMIN. Turning off automatic deployment breaks the requirement for new accounts, self-managed roles belong to the other permission model, and account filters do not govern what happens to stacks in accounts that leave.

1. Map requirement 1 (keep resources on OU move) to the account removal behaviour: retain stacks.
2. Map requirement 2 (new accounts still covered) to keeping automatic deployment on.
3. Map requirement 3 (operate from a member account) to a delegated administrator using CallAs DELEGATED_ADMIN.
4. Reject options that belong to the self-managed model or that misuse account filters.

Exam tip: Service-managed StackSet knobs: auto-deployment on + RetainStacksOnAccountRemoval for safe moves; delegated admin + CallAs DELEGATED_ADMIN to operate from a member account.

StackSet operation preferences separate how many accounts run at once, how many failures each Region tolerates and how Regions are sequenced.

Three facts combine. Failure tolerance is counted per Region, so FailureToleranceCount 2 stops a Region once a third account fails. In the default strict mode the actual concurrency is limited to failure tolerance + 1 (three accounts), which makes a 400-account Region slow; soft failure tolerance keeps the configured concurrency of 40 and only lets in-flight deployments finish after the threshold, which the stem accepts. Sequential Region concurrency with a Region order processes us-east-1 completely before the next Region, while parallel does all Regions at once.

1. Translate 'stop after more than two failures per Region' into FailureToleranceCount 2.
2. Recognise that strict concurrency mode caps concurrency at tolerance + 1, which conflicts with 'as quickly as possible'.
3. Choose soft failure tolerance because extra in-flight failures are explicitly acceptable.
4. Use sequential Region concurrency with us-east-1 first in the Region order.

Exam tip: Speed with a low failure tolerance needs SOFT_FAILURE_TOLERANCE; one Region at a time needs SEQUENTIAL with a RegionOrder.

Failure tolerance is counted per Region; exceeding it fails the operation and stops further Regions.

With a tolerance of one, a second failure in us-east-1 exceeds the threshold for that Region. CloudFormation sets the Region and the operation to FAILED and cancels the operation in the remaining Regions, so eu-west-1 and ap-southeast-2 keep the old template. Stacks that already updated keep their new state; nothing is rolled back at the StackSet level.

1. Note the tolerance: one failure per Region is allowed.
2. Count the failures in the first Region: two, which exceeds it.
3. Recall that exceeding the tolerance fails the whole operation and cancels the remaining Regions.
4. Remember that successful stack instances are not rolled back by the StackSet.

Exam tip: StackSet failure tolerance is per Region; breach it and the operation stops before the next Region.

The AWS CDK is an imperative way to author infrastructure that still deploys through declarative CloudFormation.

The deciding facts are that CDK apps synthesize ordinary CloudFormation templates and deploy them as stacks, and that CDK constructs give programming-language features (loops, tests, classes) plus higher-level L2/L3 components with defaults. Plain YAML with nested stacks or modules stays declarative, SDK scripts bypass CloudFormation entirely, and SAM is another template format.

1. Identify the platform constraint: deployment must be CloudFormation stacks.
2. Identify the developer need: general-purpose code, tests and reusable abstractions.
3. Pick the tool that is imperative to write but declarative to deploy: the AWS CDK.
4. Reject SDK scripts (no stacks) and template-only formats (no code).

Exam tip: CDK = write in code, deploy as CloudFormation: you keep change sets and drift detection.

In the AWS CDK, a resource's logical ID is derived from its construct path, and CloudFormation treats a changed logical ID as a different resource.

Two facts combine. First, CDK computes logical IDs from the construct ID path, so moving a construct changes the logical ID even though the code describes the same table. Second, CloudFormation treats a new logical ID as a new resource and the old one as removed, so it creates and deletes. Overriding the logical ID back to the original keeps the resource identity stable. RETAIN only orphans the old table, hotswap does not apply to DynamoDB tables, and a backup restore is data movement. (CloudFormation stack refactoring, exposed as cdk refactor, is another way to move a resource to a new logical ID without replacement; it is not among the options.)

1. Explain the diff: the construct path changed, so the logical ID changed.
2. Recall that CloudFormation identifies resources by logical ID within a stack.
3. Keep the identity stable by restoring the original logical ID on the L1 resource.
4. Reject options that leave a new empty table or rely on a restore.

Exam tip: Moving a CDK construct changes its logical ID; pin the old ID (overrideLogicalId) to avoid replacing stateful resources.