Deployment, Provisioning, and Automation practice questions

AMIs are Regional resources: to launch the same golden image in another Region you must copy the AMI there, which creates a new AMI with a new Region-local ID.

Copying the AMI to the DR Region is the only mechanism that makes the image launchable there. Referencing the original ID fails because AMI IDs are Region-scoped, S3 replication is unrelated to how EC2 stores images, and sharing is an account-level permission concept — there is no such thing as sharing an AMI with a Region.

1. Initiate an AMI copy from us-east-1 to the DR Region.
2. Wait for the copy to complete; note the new AMI ID minted in the DR Region.
3. Update DR launch templates or CloudFormation mappings to reference the new Region-local AMI ID.
4. Repeat the copy after each golden-image rebuild, or automate distribution with EC2 Image Builder.

Exam tip: Cross-Region DR with AMIs means copying the AMI into each Region — every copy gets its own local AMI ID.

Private AMI sharing works through launch permissions: the owner adds specific AWS account IDs (or shares across an organization), and those accounts can then launch instances from the image.

Adding the account IDs to the AMI's launch permissions grants exactly the required access with no public exposure. AWS RAM is the tempting distractor because it is the multi-account sharing service — but AMIs are not shared through RAM; making the image public fails the privacy requirement outright; and S3 bucket access has nothing to do with how EC2 launches from an AMI.

1. Open the AMI's permissions (or use the CLI modify-image-attribute operation).
2. Add the two target account IDs as launch permissions, keeping the image private.
3. If the AMI's snapshots are encrypted, ensure the KMS key policy also allows the target accounts.
4. Have the target accounts confirm they can see and launch the shared AMI.

Exam tip: Share an AMI with specific accounts via launch permissions — AWS RAM does not share AMIs, and public sharing is all-or-nothing.

CloudFormation template anatomy assigns each section one job: Parameters take deploy-time input, Mappings hold static lookup tables, Conditions toggle resources, Resources declare the infrastructure, and Outputs surface results.

Values that differ per environment and arrive at deploy time are the textbook definition of Parameters. Mappings fail because they are fixed inside the template, Outputs are post-deployment results rather than inputs, and Conditions only evaluate expressions (often over parameters) to include or exclude resources.

1. Declare parameters for the instance size and environment name, with types, defaults, and allowed values where sensible.
2. Reference the parameters in the Resources section instead of hard-coding values.
3. Deploy the same template three times, passing different parameter values for dev, staging, and production.
4. Optionally add Conditions keyed on the environment parameter to create production-only resources.

Exam tip: Per-environment, deploy-time values belong in Parameters — one template, many stacks.

Cross-stack references via Outputs with Export names and Fn::ImportValue create real dependencies: an exporting stack cannot be deleted, and an in-use exported value cannot be changed or removed, while any stack imports it.

The only way forward is to remove the imports — update or delete the consuming stacks first, then delete the networking stack. DeletionPolicy governs resource fate at deletion time but does nothing about export dependencies, drift detection is purely a reporting tool for out-of-band changes, and no force/skip flag exists for in-use exports.

1. List the importing stacks (the CloudFormation list-imports operation shows every stack consuming an export).
2. Update or delete those stacks so they no longer use Fn::ImportValue against the networking stack's exports.
3. Confirm the exports show no remaining imports.
4. Delete the networking stack.

Exam tip: A stack whose exports are imported elsewhere cannot be deleted — release the imports first; cross-stack deletions have an order.

Change sets preview every planned Add, Modify, and Remove before an update runs, and flag Replacement when a property change forces CloudFormation to delete the resource and create a new one.

Replacement: True on an RDS instance means the update will destroy the current database and stand up a new one — the exact scenario change-set review exists to catch. The in-place answer describes Replacement: False behavior, the approval-pause answer invents a gate that change-set execution does not have, and the parameters-only answer ignores that a replacement is a brand-new resource.

1. Create a change set for every production update and read it before executing.
2. Scan specifically for Replacement: True on stateful resources such as databases and volumes.
3. If a replacement is flagged, either rework the change to avoid the immutable property, or plan data preservation (snapshot, DeletionPolicy, migration window).
4. Only then execute the change set.

Exam tip: Replacement: True in a change set means delete-and-recreate — review stateful resources for it before every execute.

Drift detection is CloudFormation's answer to resources changed outside CloudFormation: it compares live configuration against the template and reports per-resource status.

Running drift detection is the only option that inspects live reality against the template and enumerates the divergent resources. Change sets diff templates against the stack's stored model (so out-of-band edits are invisible to them), stack events only log CloudFormation-initiated operations, and blindly re-updating neither reports differences nor reliably fixes them.

1. Run drift detection on the stack.
2. Review per-resource drift status: IN_SYNC, MODIFIED, or DELETED, with property-level differences for MODIFIED resources.
3. Decide the source of truth: update the template to adopt the change, or restore the resource to the template's configuration.
4. Re-run drift detection to confirm the stack returns to IN_SYNC.

Exam tip: A resource changed outside CloudFormation is the cue for drift detection — the one tool that diffs live configuration against the template.