Day 5 - Week 8 Integrated Scenarios: Where IaC Tools Meet Inside a Single Incident

A fintech wants to deploy the same GuardDuty/CloudTrail/Config baseline to 200 child accounts in an AWS Organizations environment, and the same baseline must be applied automatically to new accounts added every week. The security team also requires minimizing day-to-day use of the Management Account. What is the most appropriate configuration?

• ADeploy with Self-managed StackSets, with an operator manually adding the account ID and a pre-created IAM execution role for each new account — impractical with 200 accounts plus new ones every week, and it does not reduce Management Account usage
• BTrigger a Lambda from the EventBridge account-creation event to apply the baseline to each account with boto3 — idempotency, failure retries, concurrency limits, and rollback must all be implemented by hand
• CRegister the Tooling account as Delegated Administrator + Service-managed StackSets + AutoDeployment Enabled, targeting OUs
• DHave operators configure GuardDuty, CloudTrail, and Config directly in every account over SSH/console — manual operation that gives up infrastructure automation, impossible at 200-account scale

A SaaS company deployed an RDS DBInstance change to a prod CloudFormation Stack, and the database was unintentionally replaced, causing 6 hours of downtime. To strengthen the standard change procedure so the same incident does not recur, what is the most appropriate combination?

• ADeploy identically to all environments with the single line aws cloudformation deploy — the replacement executes as is, with no chance for a human to review the Change Set's Replacement=True information
• BA 3-step CodePipeline of CreateChangeSet → ManualApproval (forcing review of the Change Set's Replacement information) → ExecuteChangeSet + DeletionPolicy=Snapshot/UpdateReplacePolicy=Snapshot on prod RDS + a Stack Policy denying Replace/Delete
• COnly tighten the deployment IAM permissions to restrict RDS change permissions — IAM controls only who can make changes and cannot prevent the replacement risk of a legitimate change that passes through CFN
• DAdd only Drift Detection automation — it is a post-deployment comparison, so it detects things only after the replacement and downtime have already occurred

In a CloudFormation environment run by a game company, the network Stack's VpcId Export is used as an ImportValue by 50 other Stacks. When they tried to update the network Stack to expand the VPC, the entire deployment stopped with a "Cannot update Export" error. Which answer satisfies both an immediate fix and long-term improvement?

• AImmediately delete and recreate the network Stack — the moment the VpcId Export disappears, the 50 dependent Stacks tied by ImportValue break simultaneously, and deleting the VPC halts all workloads
• BImmediate: remove ImportValue from the 50 dependent Stacks temporarily → update the network Stack → re-add ImportValue to the dependent Stacks, in a 3-step deployment. Long term: migrate to SSM Parameter Store + dynamic references ({{resolve:ssm:/network/vpc-id:1}}) instead of Cross-Stack Exports
• CMerge the 51 Stacks into one Nested Stack tree — the Export lock disappears but everything becomes tightly coupled, and the blast radius of a small change grows to all 50 Stacks
• DMigrate everything to Terraform — it avoids the lock through tfstate references, but the migration cost is large and it does not immediately lift the current "Cannot update Export" block

A company wants to codify a newly released AWS Bedrock model in CloudFormation but found that some deep features are not yet supported by CFN. They plan to handle only that part with a Custom Resource Lambda. What is the most important design element for operational stability?

• AAllocate generous Lambda memory — it affects processing speed but has nothing to do with the core risk that if the ResponseURL response is missing, the Stack is stuck for up to 3 days
• BThe Lambda must PUT a response to the ResponseURL in every branch (Create/Update/Delete + exceptions), keep the PhysicalResourceId identity key stable (returning a new ID on Update triggers automatic resource replacement), and for long-running work use the CDK Provider framework's isComplete pattern with Step Functions polling
• COptimize Lambda invocation cost — merely a side cost item, not an operational stability factor like the Custom Resource's response protocol or PhysicalResourceId stability
• DChoose the deployment Region of the Provider Lambda — only a factor deciding resource location, with no direct relation to the failure modes where CFN halts the Stack or replaces resources

A SaaS deploys the same pattern (Lambda + DynamoDB + API Gateway + X-Ray + CloudWatch Alarm) to 200 microservices with the CDK. The security team wants to apply a new policy ("all Lambdas must have reserved concurrency of 100 or less, and all DynamoDB tables must have point-in-time recovery enabled"). How can you enforce it consistently without modifying the code of the 200 services?

• AManually modify the code of the 200 services team by team to add reserved concurrency and PITR — consistency depends on people, omissions and drift are inevitable, and every policy change means repeating the edit in 200 places
• BBuild your own L3 Construct (StandardLambdaApiPattern) that every service uses and apply policy changes in that one Construct place + simultaneously validate the whole tree with CDK Aspects (Annotations.addError) + block at synthesis time with a cdk-nag rule set + block at deployment time with CFN Hooks, a multi-layered defense
• CEnforce with IAM policies — IAM controls only who calls what and cannot enforce resource property configurations such as reserved concurrency values or DynamoDB PITR
• DSimply register as an approved product in Service Catalog — it is only a self-service provisioning catalog and cannot retroactively enforce policy on the 200 services that already exist

A game company deploys to three environments, Dev/Staging/Prod, with CDK Pipelines, but after adding the Prod account the build fails with a "KMS access denied" error. The Pipeline is in the Tooling account and Prod is a separate account. What is the most accurate cause and fix?

• AInsufficient IAM permissions on the build-stage Lambda — the error being specifically "KMS access denied" and occurring right after adding the Prod account points to a cross-account key sharing problem, not Lambda permissions
• BcrossAccountKeys: true is not set — the CodePipeline artifact S3 objects are encrypted with an AWS managed KMS key, so the other account's cfn-exec-role cannot decrypt them. Enabling crossAccountKeys: true in the CDK automatically creates an operator-defined CMK and adds permissions for all target accounts in the Key Policy
• CA Region mismatch between the Pipeline and Prod accounts — a Region mismatch produces resource-not-found type errors, not a specific KMS decryption denial
• DInsufficient timeout on the deployment Lambda — an execution time limit problem shows up as a timeout error, not as KMS access denied

A SaaS introduced CDK Aspects and applied 30 cdk-nag rules to prod all at once, including forcing encryption on all S3 buckets, multi-AZ on all RDS, a dead letter queue on all Lambdas, and WAF association on all ALBs. The build failed with 1200 violations and all deployments stopped. What is an appropriate adoption strategy?

• ADisable all 30 rules to lift the deployment block — the build passes but it gives up security governance such as encryption, multi-AZ, and WAF wholesale, the opposite of the original purpose
• BKeep all 30 rules enforced at once and try to fix the 1200 violations in bulk — forcing broad simultaneous fixes while all deployments are stopped carries a high risk of regressions and downtime
• CGraceful rollout: step 1 set all rules to warning → measure the baseline violations → enforce starting with the 5 priority rules (those with high security impact) → add 5 to 10 enforced rules each quarter → a phased expansion over 6 months. The same pattern as CFN Hooks WARN→FAIL and K8s OPA Gatekeeper dryrun→warn→deny
• DEnforce the 30 rules only in prod and exclude dev/staging — this amounts to forcing everything at once on prod, where violations are the most numerous, so prod deployments are paralyzed all the same

A fintech removed 5 child AWS accounts from Organizations because of a subsidiary sale, and the baseline Stacks deployed by StackSets were automatically deleted, so the CloudTrail Trail inside them disappeared and 90 days of audit logs from just before the sale were lost. What is the most accurate combination to prevent recurrence?

• AStop using AWS Organizations — the automatic cleanup trigger disappears, but it is an excessive response that gives up multi-account governance itself and does not solve the audit log retention problem either
• BSet RetainStacksOnAccountRemoval=true in the StackSet configuration + set DeletionPolicy: Retain on all stateful/audit resources (CloudTrail, the S3 log bucket) in the baseline template + where possible stream logs to a separate central account (Log Archive) to remove the dependency on member accounts
• CHave an operator manually back up the audit logs at the time of the account sale — a one-off procedure where logs are lost if a person forgets or misses the timing, so it does not prevent recurrence
• DDisable the baseline StackSet — it avoids the automatic deletion but stops baseline deployment to new accounts, creating a governance gap

A company adds a new environment (5 per-customer sandboxes) every week, and each time an operator edits the CodePipeline definition by hand and redeploys the pipeline with CFN. What is the most appropriate tool to automate this?

• APlain CodePipeline + an operations script to update the definition — the pipeline definition and execution are separated, so the manual step of redeploying with an external script on every new environment remains
• BCDK Pipelines selfMutation: true + generating the environment list dynamically in CDK code (reading a JSON/YAML config file or a for loop). Just commit the new environment to Git and on the next run the UpdatePipeline stage adds the new Stage to the pipeline itself
• CUpdate the pipeline definition automatically with Lambda — it works, but you must implement idempotency, failure retries, and concurrent-change conflict handling yourself, so the operational burden is large
• DManage the pipeline with Terraform — adding environments is possible with apply, but it is not a native flow where the pipeline updates itself like self-mutation

In a 500-account environment, the security team requires evaluating in real time which accounts have GuardDuty disabled and automatically re-enabling it. What is the most appropriate multi-layered configuration?

• ADetect GuardDuty being disabled with StackSets Drift Detection alone — Drift is non-periodic and manually triggered with no automatic fix, so it alone does not satisfy the requirement of real-time evaluation and automatic re-enablement across 500 accounts
• B(1) Deploy GuardDuty with StackSets Service-managed (prevention) + (2) evaluate all accounts with the AWS Config Rule guardduty-enabled-centralized through an Org Conformance Pack (detection) + (3) register an SSM Automation Document as a Config Remediation Action to re-enable automatically when a violation is found (remediation) + (4) aggregate the results in Security Hub for operator visibility
• CHave one Lambda iterate over and check all 500 accounts directly — idempotency, cross-account assume-role, scale, and failure retries must all be implemented by hand, so the operational burden is large
• DManually check all 500 accounts in the console every day — real-time evaluation is impossible and it depends on people, so the exposure window between disabling and re-enabling is long

A company injected an RDS password into a prod CloudFormation Stack with '{{resolve:secretsmanager:prod/db:SecretString:password}}'. After the security team rotated the password in Secrets Manager, they found it was not applied to RDS and was reflected only at the next Stack update. To synchronize automatically, what should be done?

• AChange the dynamic reference syntax to a different pattern — {{resolve:...}} is a fetch mechanism at deployment time, so no variant can automatically reflect a rotated secret in RDS
• BA dynamic reference is a fetch mechanism, not synchronization. Connect RDS and Secrets Manager with AWS::SecretsManager::SecretTargetAttachment + configure Secrets Manager Rotation Lambda (enable-rotation) — on rotation the Lambda updates RDS directly through the MasterUserPassword API and switches to the new secret version. CloudFormation only defines the rotation infrastructure
• CHave the security team manually synchronize the RDS password at every rotation — a procedure where people align two systems, so omissions and timing delays are inevitable and zero-downtime is not guaranteed either
• DInvoke a Lambda temporarily on rotation to update RDS — the direction is right, but without the SecretTargetAttachment connection and managed rotation configuration, a one-off invocation does not establish continuous automatic synchronization

A company wants to set an IaC operating standard that satisfies all of the following requirements: (1) a human confirmation step on every prod change, (2) blocking unintended RDS replacement, (3) automatic baseline for new member accounts, (4) pre-blocking of security policy violations in prod CFN changes, (5) quickly codifying newly released AWS services, (6) consistently enforcing the common pattern across 200 microservices. What is the most appropriate tool mapping for each requirement?

• ASolve all 6 requirements with IAM policies — IAM controls only who calls what, so it cannot express configuration and governance requirements such as blocking RDS replacement, automatic baselines for new accounts, and enforcing a common pattern
• BImplement all 6 requirements directly with Lambda — you can make it work, but idempotency, failure retries, approval flows, and multi-layer validation must all be built by hand, so the operational burden explodes
• C(1) CodePipeline ManualApproval + ChangeSet review, (2) UpdateReplacePolicy=Snapshot + Stack Policy denying Replace, (3) Service-managed StackSets + AutoDeployment, (4) CloudFormation Hooks (or Control Tower Proactive Guardrails), (5) Custom Resource Lambda Provider, (6) your own CDK L3 Construct + Aspects/cdk-nag validation
• DUnify all 6 requirements with Terraform — you gain single-tool consistency but cannot directly replace AWS-native governance features such as pre-blocking (Hooks) and OU auto-deployment (StackSets)