AWS 2: Configuration Management and IaC: 144 practice questions

12 of the 144 2: Configuration Management and IaC questions in the Certsqill AWS bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AWS? Take the free 5-min readiness check →

1. Synthesize the CDK application and create a CloudFormation: Select TWO.

Select two. More than one option is correct — every correct one is ticked below.

1. Synthesize the CDK application and create a CloudFormation change set before executing each environment update. ✓

   CDK produces CloudFormation templates, and change sets preview additions, modifications, replacements, and deletions before execution.
2. Use a service-managed CloudFormation StackSet with Organizations integration and per-account parameters. ✓

   Service-managed StackSets distribute one template across organizational accounts and Regions while supporting stack-specific parameters.
3. Use an SCP to distribute the synthesized template and block database replacement operations.

   SCPs restrict API permissions and cannot distribute templates or selectively prevent CloudFormation resource replacement.
4. Run direct CloudFormation updates from a deployment role and rely on drift detection for replacement warnings.

   Drift detection reports out-of-band differences but does not preview proposed replacements or prevent direct update execution.
5. Create an independent CDK application and stack in every tenant account for local customization.

   Independent applications duplicate template sources and undermine centralized consistency across accounts and Regions.

Use CDK synthesis with CloudFormation change sets, and service-managed StackSets for governed multi-account, multi-Region deployment.

2. Use service-managed StackSets: Which design should the platform team implement?

1. Use separate CodePipeline actions for each account and Region.

   This requires custom orchestration and does not inherently enroll future organizational accounts or provide StackSet operation controls.
2. Create a nested stack in the management account and export resources to member accounts.

   Nested stacks remain within the owning account and cannot provision resources across member accounts and Regions.
3. Use self-managed StackSets with manually created administrator and execution roles.

   Self-managed StackSets can deploy across accounts but require the manual role administration explicitly excluded by the scenario.
4. Use service-managed StackSets. ✓

   Service-managed StackSets support Organizations targeting, automatic deployments, regional ordering, failure tolerance, and AWS-managed cross-account role setup.

Use service-managed StackSets targeting organizational units.

3. Use Systems Manager for patching: Which design is most appropriate?

1. Use Systems Manager for patching, inventory, and commands; AppConfig for gradual runtime configuration; and AWS Config for resource compliance. ✓

   Systems Manager provides managed-instance operations, AppConfig supports validated staged configuration deployment and rollback, and AWS Config evaluates resource configuration compliance without performing the rollout.
2. Use Secrets Manager rotation for nonsecret settings and Systems Manager only for inventory.

   Secrets Manager rotation targets secrets, and limiting Systems Manager to inventory omits required patching and remote command operations.
3. Use CloudFormation updates for patching and runtime configuration, replacing instances when required.

   CloudFormation manages infrastructure changes but is not the appropriate routine fleet-operations or gradual runtime-configuration service.
4. Use AWS Config remediation for patch installation and AppConfig only for compliance reporting.

   Config can evaluate compliance and initiate remediation, but AppConfig is the configuration rollout service, not the compliance reporting service.

Use Systems Manager, AppConfig, and AWS Config for their distinct operational roles.

4. Publish a governed Service Catalog product and deploy: Which design best satisfies these requirements?

1. Publish approved CloudFormation templates in every account and require application teams to consume local copies under documented security review.

   Local copies are executable and reviewable, but they can drift and do not provide centralized product versioning or controlled self-service.
2. Publish a governed Service Catalog product and deploy baselines with throttled service-managed StackSets. ✓

   Service Catalog provides governed, versioned self-service, while service-managed StackSets deploy baselines across organizational accounts and Regions with operation preferences for throttling.
3. Deploy service-managed StackSets with automatic OU enrollment and regional operation preferences, then distribute templates for team-managed consumption.

   StackSets provide enrollment and throttling, but distributing templates for team management does not establish a governed product boundary that prevents security-resource edits.
4. Use nested stacks and cross-account exports from a central CloudFormation deployment, with teams importing the shared security resources.

   Nested stacks and exports are supported within CloudFormation, but they do not by themselves provide organization-wide cross-Region rollout, independent throttling, or a Service Catalog consumption boundary.

Combine Service Catalog for governed consumption with throttled service-managed StackSets for baselines.

5. Configure automatic deployment for the StackSet: Select TWO changes that address the observed design gaps.

Select two. More than one option is correct — every correct one is ticked below.

1. Configure automatic deployment for the StackSet and include accounts added to the targeted OU. ✓

   Automatic deployment creates Stack instances for future accounts entering the targeted organizational unit.
2. Deploy the StackSet only to the management account, then share its IAM role with member accounts.

   Resources and associations must exist in target accounts, and IAM roles cannot substitute for account-local StackSet deployments.
3. Replace the Systems Manager association with an AWS Config rule that evaluates worker-node configuration.

   AWS Config evaluates compliance but does not install the Systems Manager agent or execute the requested node configuration.
4. Enable trusted access and use service-managed StackSets targeted at the Production OU. ✓

   Service-managed StackSets integrate with Organizations, target OUs, and support automatic deployment to accounts added later.
5. Add an SCP allowing `ssm:CreateAssociation` so the StackSet can configure worker nodes.

   SCPs limit maximum permissions and never grant permissions; IAM policies and managed-node prerequisites remain necessary.

Use service-managed StackSets with OU targeting and automatic deployment; separately ensure nodes satisfy Systems Manager managed-node prerequisites.

6. Use AWS Organizations with organizational units: Which design best meets these requirements?

1. Use a delegated administrator account to create member accounts and directly administer every workload resource.

   Delegated administration is service-specific and does not provide unrestricted administrative authority across all member-account resources.
2. Create accounts manually, attach identical SCPs, and use consolidated billing without organizational units.

   Organizations supports consolidated billing, but omitting OUs removes scalable policy grouping and controlled environment separation.
3. Place every workload in one account and use IAM permission boundaries to separate billing event consumers.

   Permission boundaries constrain identities but do not provide account-level isolation or organizational account lifecycle management.
4. Use AWS Organizations with organizational units, AWS Control Tower account provisioning, and OU-level controls and guardrails. ✓

   Organizations and Control Tower provide account hierarchy, governed provisioning, isolation boundaries, and centralized preventive and detective controls.

AWS Organizations and Control Tower provide governed account creation, OU isolation, scalable controls, and consolidated billing without routine management-account workload access.

7. Use Identity Center permission sets plus SCP denies: Which design should the architect implement?

1. Create IAM users in each account, rotate passwords quarterly, and assign resource policies for logs.

   Per-account users create long-lived credentials and decentralized administration, contrary to the Identity Center requirement.
2. Give developers AdministratorAccess and review CloudTrail for unauthorized changes.

   Detection does not prevent changes, and administrator access violates least privilege and the protected-data requirement.
3. Use Identity Center permission sets plus SCP denies that exclude the break-glass role. ✓

   Permission sets provide centralized short-term access, while SCP denies restrict protected actions in member accounts and can exclude the specifically controlled break-glass role. The permission sets still require appropriate identity policies.
4. Attach an SCP allowing security actions and omit identity policies because organization policies grant access.

   SCPs never grant permissions; the break-glass role and other identities still require identity-based or resource-based allows.

Use Identity Center permission sets for short-term access and SCP denies that preserve an explicitly excluded break-glass role.

8. Use Control Tower controls: Which design is most appropriate?

1. Deploy encrypted buckets and restrictive security groups with StackSets, then review CloudTrail after each release.

   StackSets can distribute resources and CloudTrail supplies audit evidence, but this does not aggregate GuardDuty or Security Hub findings or continuously evaluate all account resources.
2. Configure GuardDuty and Security Hub separately in every workload account, then forward findings to a central bucket.

   This is executable but creates decentralized enablement and does not reliably provide organization-wide coverage for newly provisioned accounts.
3. Use Control Tower controls, delegated GuardDuty and Security Hub administration, Config rules, and SCP guardrails. ✓

   This combines OU-level preventive and detective governance with centralized GuardDuty and Security Hub administration and supports coverage for accounts added to governed OUs.
4. Use AWS Config conformance packs with remediation and require application pipelines to publish GuardDuty findings to Security Hub.

   Config conformance packs can assess and remediate configuration, but application pipelines cannot replace organization-level GuardDuty administration and finding aggregation.

Use OU-level Control Tower governance, centralized GuardDuty and Security Hub administration, Config detection, and SCP prevention.

9. Use Patch Manager patch policies or maintenance windows: Select TWO designs that satisfy these requirements.

Select two. More than one option is correct — every correct one is ticked below.

1. Use AWS Config managed rules to install packages and restart monitoring services on noncompliant instances.

   AWS Config evaluates resource configuration; its rules do not directly install operating-system packages or manage node services.
2. Use Patch Manager patch policies or maintenance windows with custom baselines, concurrency, and error thresholds. ✓

   Patch Manager installs approved updates and supports baselines, scheduling, rate controls, and compliance reporting.
3. Use State Manager associations to enforce the monitoring agent state on tagged managed nodes. ✓

   State Manager maintains desired software configuration through scheduled associations targeted by tags or resource groups.
4. Use Systems Manager Inventory alone to install missing agents and remediate noncompliant instances.

   Inventory collects observations and software data but does not independently perform configuration remediation or patch installation.
5. Use a daily Run Command document without concurrency or error controls to install patches fleet-wide.

   Run Command executes commands but lacks the required patch-baseline compliance model and explicit bounded failure controls here.

Patch Manager handles governed patch compliance, while State Manager continuously enforces the monitoring agent’s desired state.

10. Use AWS Step Functions to orchestrate idempotent Lambda: Which design is best?

1. Send events directly to Amazon SNS and let subscribers independently create roles and send completion notifications.

   Independent subscribers cannot guarantee ordered completion, centralized retries, idempotency, or approval-controlled recovery.
2. Use AWS Step Functions to orchestrate idempotent Lambda tasks, retries, waits, approval callbacks, and failure handling. ✓

   Step Functions coordinates long-running workflows, retries, waits, human callbacks, and Lambda tasks beyond one invocation.
3. Store each request in Amazon DynamoDB and use a scheduled Lambda to poll until all steps finish.

   Polling can work, but it requires custom state management and does not natively provide workflow retries, waits, or approval callbacks.
4. Use one Lambda function triggered by EventBridge and extend its timeout until the workflow completes.

   A single invocation cannot reliably model approval waits, durable orchestration, or bounded multi-step retry behavior.

Step Functions provides durable orchestration for retries, waits, approvals, idempotency-aware tasks, and workflows exceeding Lambda invocation duration.

11. Use AppConfig deployments with Secrets Manager references: Which design should be selected?

1. Use AppConfig deployment strategies with secrets stored directly in hosted configuration profiles.

   AppConfig supports staged rollout and rollback, but placing secrets directly in configuration profiles violates the secret-handling requirement.
2. Bake configuration and secrets into an AMI, then distribute the image through CloudFormation StackSets.

   This exposes secrets in image artifacts and provides infrastructure distribution rather than staged configuration rollout, health-based rollback, and scheduled desired-state enforcement.
3. Use Parameter Store values with State Manager associations and apply each release directly to all nodes.

   This supports protected values and scheduled enforcement but lacks staged application rollout and automatic rollback based on health checks.
4. Use AppConfig deployments with Secrets Manager references, cross-account publishing roles, and scheduled State Manager associations. ✓

   AppConfig provides staged deployment and rollback, Secrets Manager keeps secrets out of artifacts, narrowly scoped cross-account roles avoid broad security-account access, and State Manager enforces the node baseline on a schedule.

Use AppConfig for staged rollback-capable releases, Secrets Manager for secrets, controlled cross-account roles, and State Manager for scheduled enforcement.

12. Use Patch Manager policies with custom baselines: Which design is most appropriate?

1. Use Systems Manager Inventory to report missing packages and manually approve each remediation.

   Inventory provides observations, but manual approval does not deliver scalable automated remediation or bounded maintenance-window execution.
2. Use Patch Manager policies with custom baselines, maintenance-window installation, compliance reporting, and bounded concurrency. ✓

   Patch Manager defines approved patches for Linux and Windows, schedules installation, reports compliance, and supports rate controls. The baselines can exclude major-version upgrades.
3. Use State Manager associations to run patch commands on every node and treat association status as patch compliance evidence.

   State Manager can schedule configuration actions, but association status is not the specialized Patch Manager compliance evidence required for approved baselines.
4. Use AWS Config rules to identify missing patches and invoke remediation actions during each maintenance window.

   Config can assess supported configuration state and trigger workflows, but it is not the specialized patch-baseline and patch-installation service.

Use Patch Manager policies for approved baselines, scheduled remediation, compliance evidence, and controlled concurrency.

Other AWS domains

• 1: SDLC Automation — 187 questions →
• 6: Security and Compliance — 144 questions →
• 3: Resilient Cloud Solutions — 128 questions →
• 4: Monitoring and Logging — 127 questions →
• 5: Incident and Event Response — 119 questions →
• All 849 AWS questions →
• AWS certification: requirements, cost and exam format →