Try 10 focused AWS SOA-C03 questions on Deployment, Provisioning, and Automation, with explanations, then continue with IT Mastery.
Open the matching IT Mastery practice page for timed mocks, topic drills, progress tracking, explanations, and full practice.
| Field | Detail |
|---|---|
| Exam route | AWS SOA-C03 |
| Topic area | Deployment, Provisioning, and Automation |
| Blueprint weight | 22% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Deployment, Provisioning, and Automation for AWS SOA-C03. Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 22% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.
Topic: Deployment, Provisioning, and Automation
A fleet of 150 Amazon EC2 Linux instances in private subnets is managed by AWS Systems Manager (SSM Agent is running and instances have the required IAM instance profile). The security team asks operations to (1) immediately apply the approved SSM patch baseline to all instances tagged PatchGroup=prod-web, and (2) restart the amazon-ssm-agent service on any instances where it is not running. The team must avoid inbound SSH and must retain centrally accessible command output for auditing.
Which TWO actions should the operations engineer take? (Select TWO.)
Options:
A. Create a Systems Manager State Manager association to run the restart command every 5 minutes.
B. Use Systems Manager Session Manager to connect to each instance and restart the service manually.
C. Use Systems Manager Run Command with AWS-RunShellScript to run systemctl restart amazon-ssm-agent and systemctl is-active amazon-ssm-agent across the fleet, sending output to CloudWatch Logs.
D. Use an EC2 user data script to apply patches and restart the service, then reboot the instances.
E. Use Systems Manager Run Command with AWS-RunPatchBaseline targeting PatchGroup=prod-web and enable output to Amazon S3 or CloudWatch Logs.
F. Use a bastion host and run parallel SSH commands to patch and restart the service on the instances.
Correct answers: C and E
Explanation: Systems Manager Run Command is designed to execute operational tasks across fleets of managed instances using SSM documents and tag-based targeting. AWS-RunPatchBaseline applies the configured patch baseline, and AWS-RunShellScript can restart and validate a service. Both approaches avoid inbound SSH and can log command output centrally for auditing.
The core concept is using Systems Manager Run Command to execute actions at scale on managed instances by selecting an SSM document and targeting instances (for example, by tags). For patching, Run Command with AWS-RunPatchBaseline applies the approved patch baseline to the specified target group and produces per-instance status. For service remediation, Run Command with AWS-RunShellScript can run systemctl commands to restart the service and verify it is active.
To meet audit requirements, configure Run Command output to be delivered to Amazon S3 and/or CloudWatch Logs so results are centrally stored and reviewable. The key takeaway is that Run Command provides fleet-level, logged execution without opening inbound access to instances.
AWS-RunPatchBaseline is OK because it patches the tagged fleet immediately and can store results in S3/CloudWatch Logs; Run Command with AWS-RunShellScript is OK because it restarts/verifies the service across many instances and captures output centrally.Topic: Deployment, Provisioning, and Automation
A company uses AWS Systems Manager State Manager to enforce a baseline on 200 Amazon Linux EC2 instances (install and configure the CloudWatch agent, apply approved patch baselines, and harden SSH settings). Instances are in private subnets with no NAT/internet egress and only VPC endpoints for Systems Manager and Amazon S3. Security requires least-privilege IAM and auditable changes.
Which TWO actions should an operations engineer AVOID when using State Manager to remediate configuration drift?
Options:
A. Store scripts in a private S3 bucket and reference them in the association
B. Attach an instance profile with AdministratorAccess so associations can remediate anything
C. Use State Manager to keep the CloudWatch agent installed and configured
D. Configure the association to write output to S3 or CloudWatch Logs for audit
E. Target by tags; run patch scan daily and install during the weekly window
F. Download baseline scripts from a public GitHub URL in an association
Correct answers: B and F
Explanation: State Manager remediates drift through associations that must respect network and security constraints. Pulling content from the public internet breaks the private-subnet requirement and cannot be relied on operationally. Granting broad administrator permissions to instances violates least privilege and increases the impact of any mistake or compromise.
State Manager enforces configuration baselines by creating associations that run SSM documents on a schedule and report compliance. In this environment, instances have no internet egress, so association content (scripts, packages, configs) must come from reachable private sources such as S3 accessed via a VPC endpoint (or SSM Parameters/SSM documents). Associations should also run under tightly scoped IAM permissions (instance profile and any AutomationAssumeRole) so remediation can only perform the required actions.
Acceptable operational patterns here include targeting by tags to control scope, using schedules aligned to maintenance windows for disruptive tasks (like patch installs), limiting concurrency/errors to reduce blast radius, and exporting association output to S3/CloudWatch Logs for auditability. The key takeaway is to use State Manager for continuous, auditable enforcement without bypassing explicit network or least-privilege requirements.
Topic: Deployment, Provisioning, and Automation
A company runs a customer-facing web application on an Amazon EC2 Auto Scaling group behind an Application Load Balancer (ALB). The operations team must deploy a new application version with minimal downtime and reduced risk. The team also wants an easy rollback if errors increase after deployment.
Which actions are appropriate deployment strategies for this requirement? (Select THREE.)
Options:
A. Use AWS CodeDeploy canary traffic shifting with the ALB so a small percentage of requests goes to the new version before full cutover
B. Disable ALB health checks during deployment to prevent instances from being replaced while updating the application
C. Deregister all ALB targets, update the instances, and then re-register them after the deployment
D. Use an Auto Scaling group Instance Refresh with a minimum healthy percentage and ALB health checks to perform a rolling replacement
E. Stop all instances, create new AMIs with the updated application, and then start the instances again to complete the deployment
F. Use AWS CodeDeploy blue/green for EC2 with the ALB to shift traffic to a replacement environment and enable automatic rollback
Correct answers: A, D and F
Explanation: To minimize downtime and reduce risk, use strategies that keep healthy capacity serving traffic while introducing changes gradually. Blue/green and canary deployments provide fast rollback by retaining the previous version and shifting traffic in a controlled way. A rolling replacement (for example, Auto Scaling group Instance Refresh with health checks) updates incrementally while maintaining availability.
The goal is to deploy with minimal downtime and reduced risk by controlling how traffic and capacity move to the new version. In AWS operations, this is commonly done by (1) shifting traffic between environments (blue/green), (2) gradually shifting a percentage of requests (canary), or (3) incrementally replacing instances while keeping a minimum healthy fleet (rolling).
These approaches work because they:
Approaches that remove all targets from service, stop all instances, or bypass health checks increase downtime and risk and make rollback slower and more disruptive.
Topic: Deployment, Provisioning, and Automation
An operations team uses an IAM role AutomationDeployer to provision resources with AWS CloudFormation. Stack creation is failing with AccessDenied errors. Which statement is INCORRECT for diagnosing and remediating the permission issue while maintaining least privilege?
Options:
A. For iam:PassRole errors, allow iam:PassRole only on the specific role ARN and restrict it with an iam:PassedToService condition.
B. Use AWS CloudTrail to find the denied API call and required IAM action.
C. Attach AdministratorAccess to AutomationDeployer to unblock provisioning quickly, then leave it in place to prevent future failures.
D. Use the IAM policy simulator to validate whether AutomationDeployer is allowed to call the needed API actions before rerunning the stack.
Best answer: C
Explanation: The unsafe statement is the one that recommends granting and keeping broad administrative permissions to resolve an AccessDenied provisioning failure. Least-privilege remediation should identify the exact missing actions (for example via CloudTrail) and add narrowly scoped permissions, then re-run the automation.
To troubleshoot IAM provisioning failures, first identify the exact API call that was denied and the missing permission. CloudTrail records AccessDenied events with the action name, the principal, and the target resource context, which you can translate into a least-privilege policy update.
For common CloudFormation failures involving role delegation, iam:PassRole is frequently required. Least privilege for iam:PassRole means scoping the permission to the specific role ARN(s) that must be passed and restricting which AWS service can receive the role (for example with iam:PassedToService). The IAM policy simulator is then used to confirm the effective permissions for the principal before retrying the stack. The key takeaway is to fix the precise missing permissions rather than using broad, persistent admin access.
Topic: Deployment, Provisioning, and Automation
An operations team uses an EC2 Image Builder pipeline to produce a “golden” Amazon Linux 2023 AMI for each monthly release. A Runbook calls the AWS CLI to update the image recipe and then starts the pipeline execution.
This month, the pipeline fails immediately. The automation log shows:
CreateImageRecipe failed:
ResourceAlreadyExistsException: Image recipe version '1.4.0' already exists for name 'golden-al2023'
The team must keep previous releases available (versioned) and wants the smallest change to restore the monthly build process. What should the CloudOps engineer do?
Options:
A. Add iam:PassRole permission to the Image Builder instance profile role
B. Increase the pipeline build instance type in the infrastructure configuration
C. Create a new image recipe version and update the pipeline reference
D. Recreate the Image Builder pipeline with a new name for each release
Best answer: C
Explanation: The failure indicates the runbook is attempting to create an image recipe using a version number that already exists. EC2 Image Builder treats image recipes as immutable for a given semantic version, so changes require a new recipe version. Publishing a new version and updating the pipeline preserves prior releases and restores the build with minimal change.
Symptom: ResourceAlreadyExistsException reports that image recipe version 1.4.0 already exists.
Root cause: EC2 Image Builder image recipes are versioned artifacts; a specific semantic version for a given recipe name cannot be reused to represent new contents. The runbook is trying to “update” the recipe by creating it again with the same version.
Fix:
1.4.0 to 1.4.1).This keeps older AMIs tied to prior recipe versions while producing a new, traceable AMI for the current release.
iam:PassRole would cause an access denied error, not “version already exists.”Topic: Deployment, Provisioning, and Automation
A company uses EC2 Image Builder to create a versioned AMI for each application release (for example, 3.2.5). There are 4 Image Builder pipelines (one per application), and each pipeline produces 1 new AMI version per release.
Operations must keep the last 3 AMI versions from each pipeline for rollback and audit, and delete older versions by using the pipeline’s image retention setting. Each AMI version is backed by a single 12 GiB EBS snapshot. Snapshot storage costs USD 0.05 per GiB-month. Assume the full 12 GiB is billed for each retained snapshot.
What is the estimated monthly snapshot storage cost after the retention policy is applied? Round to the nearest cent (USD).
Options:
A. USD 28.80 per month
B. USD 7.20 per month
C. USD 14.40 per month
D. USD 21.60 per month
Best answer: B
Explanation: Image Builder retention keeps a fixed number of versioned AMIs per pipeline, and each retained AMI version has a snapshot that continues to incur storage charges. With 4 pipelines retaining 3 versions each, the total retained snapshot GiB is multiplied by the given $ per GiB-month rate to estimate monthly cost.
The operational control here is Image Builder’s image retention, which limits how many versioned AMIs (releases) are kept so you can roll back while controlling snapshot storage growth.
Calculation in words:
Key takeaway: each retained versioned AMI continues to accrue EBS snapshot storage cost until it is deleted/deregistered and its snapshot is removed.
Topic: Deployment, Provisioning, and Automation
You are troubleshooting AccessDenied errors that prevent AWS CloudFormation from provisioning resources. Which THREE statements are FALSE or unsafe remediation guidance for resolving IAM permission issues while maintaining least privilege? (Select THREE.)
Options:
A. Service control policies (SCPs) cannot block creation of AWS service-linked roles, so you can ignore SCPs during troubleshooting.
B. If a role has a permission boundary, the effective permissions are limited even when the role’s identity policy allows an action.
C. Temporarily attach an iam:* on * policy to the deployment role to unblock provisioning, then remove it later.
D. For KMS-encrypted resources, you might need both the service API permission (for example, ec2:CreateVolume) and KMS key permissions (for example, kms:CreateGrant) to succeed.
E. If you add an Allow statement to the role’s identity policy, it will be effective even when a permission boundary does not allow it.
F. If the error involves iam:PassRole, allow iam:PassRole on only the required role and restrict it with iam:PassedToService.
Correct answers: A, C and E
Explanation: Least-privilege remediation means identifying which control layer is denying the call (identity policy, permission boundary, or SCP) and granting only the missing actions on the narrowest resources. Broad wildcard permissions are unsafe, and some “fixes” don’t work because higher-level guardrails still restrict effective permissions. Correct troubleshooting focuses on the specific denied API (for example, iam:PassRole or KMS grant use) and constrains it with conditions where possible.
IAM authorization for provisioning is the intersection of multiple layers: identity-based policies, permission boundaries (which cap maximum permissions), and organizational SCPs (which can impose explicit denies). CloudFormation failures often surface the exact denied API, so remediation should add only that permission, scoped to the needed resources and optionally constrained with conditions.
Corrections for the false/unsafe statements:
iam:* on * “temporarily” is unsafe because it expands blast radius and is hard to audit/roll back correctly.AccessDenied persists.Key takeaway: reduce denials by scoping the specific missing permissions, and verify higher-level controls (boundaries/SCPs) before expanding access.
iam:PassedToService is a standard least-privilege control when the denied call is iam:PassRole.Topic: Deployment, Provisioning, and Automation
An operations engineer runs an AWS Systems Manager Automation runbook to tag EBS snapshots across the account. The runbook contains an aws:executeAwsApi step (no target instances). The execution fails.
Exhibit: Automation execution history (failed step)
Step: TagSnapshots (aws:executeAwsApi)
Status: Failed
Error: AccessDeniedException: User: arn:aws:sts::111122223333:assumed-role/SSMAutomationRole/AutomationExecution
is not authorized to perform: ec2:CreateTags on resource: arn:aws:ec2:us-east-1:111122223333:snapshot/snap-0abc...
Which action should the engineer take to most directly identify what to fix and remediate the failure?
Options:
A. Review the Automation execution details, then use IAM Policy Simulator on SSMAutomationRole for ec2:CreateTags
B. Use Session Manager to connect to a managed instance and inspect SSM Agent logs for the failed action
C. Check and update the IAM permissions of the operator who started the Automation execution
D. Check and update the EC2 instance profile role permissions for the instances that have SSM Agent installed
Best answer: A
Explanation: The discriminating factor is that aws:executeAwsApi runs AWS API calls using the Automation-assumed IAM role, not an instance profile role and not the human operator’s identity. The execution history already shows the exact assumed-role ARN and the denied API action, so IAM diagnostics on that role is the fastest path to remediation.
For Systems Manager Automation, each execution runs with the permissions of the IAM role that Automation assumes (commonly provided in the AutomationAssumeRole parameter). When a step like aws:executeAwsApi fails, the execution history identifies the failed step, the exact AWS API action, and the principal that made the call (the assumed-role session).
Use the execution history to confirm the role and denied action, then use IAM diagnostics (for example, IAM Policy Simulator and/or reviewing the role’s attached policies and permission boundaries) to verify whether ec2:CreateTags is allowed for the snapshot resources. After updating the role’s permissions, rerun the Automation execution (or resume if applicable) to validate the fix. The key takeaway is to troubleshoot the role shown in the Automation execution, not the initiating user or any instance role.
aws:executeAwsApi doesn’t use a managed instance’s IAM role.Topic: Deployment, Provisioning, and Automation
A production application runs on EC2 instances in an Auto Scaling group. When log files grow unexpectedly, disk usage can exceed 90% and the application becomes unhealthy.
Current setup:
DiskUsedPercent > 90% publishes to an SNS topic that emails the on-call engineer.The operations team wants to reduce MTTR and on-call toil by automatically remediating this specific alarm condition. The solution must be auditable and should avoid maintaining custom code.
Which change is the best optimization?
Options:
A. Invoke a custom Lambda function from SNS to run the remediation
B. Increase the alarm evaluation period to 15 minutes
C. Use EventBridge to start the SSM Automation when the alarm enters ALARM
D. Configure the alarm to terminate the instance using an EC2 alarm action
Best answer: C
Explanation: Configure an EventBridge rule for the CloudWatch alarm state change and target Systems Manager Automation to run the tested remediation automatically. This closes the loop from detection to remediation with CloudWatch/EventBridge/SSM-native auditing and without custom code. The main tradeoff is accepting automated changes, so the runbook should include safeguards (idempotency and scoped permissions).
The key concept is closing the loop by wiring CloudWatch alarm state changes to an automation target that performs the known-good remediation. CloudWatch emits alarm state change events, and EventBridge can directly target Systems Manager Automation so the response is consistent, fast, and auditable (Automation execution history, CloudTrail) without maintaining Lambda code.
A typical implementation is:
ALARM.This reduces manual effort and MTTR while keeping operations changes standardized; compared with code-based remediation, the operational overhead is lower.
Topic: Deployment, Provisioning, and Automation
Which statement about creating and managing AMIs with EC2 Image Builder pipelines and handling release versioning is INCORRECT?
Options:
A. Image recipes and components use x.y.z-style versioning for releases.
B. A pipeline can update an SSM Parameter Store parameter with the new AMI ID.
C. Image pipelines are pinned to a specific image recipe version.
D. Publishing a new recipe version automatically updates all pipelines using it.
Best answer: D
Explanation: In EC2 Image Builder, versioning is explicit and immutable: pipelines point to a specific image recipe version, and new recipe versions do not “roll forward” automatically. To move to a new AMI release, you publish a new recipe/component version and then update the pipeline (or consumers) to use it. Using SSM Parameter Store as an indirection point is a common way to manage the “current” AMI ID across deployments.
The core operational concept is that Image Builder artifacts are versioned and immutable, and consumers should be updated in a controlled way. An image pipeline is configured with an image recipe (plus infrastructure and distribution configurations) and that pipeline references a specific recipe version. When you make changes for a new release, you typically create a new component and/or image recipe version (for example, incrementing x.y.z), run the pipeline to produce a new AMI, and then promote that AMI by updating the pipeline to the new recipe version and/or updating downstream consumers (such as launch templates). A common operational pattern is configuring distribution output to write the produced AMI ID to an SSM Parameter Store parameter so workloads can resolve the “latest approved” AMI without hardcoding AMI IDs. Key takeaway: new versions require an explicit update; nothing is updated in place automatically.
Use the AWS SOA-C03 Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Try AWS SOA-C03 on Web View AWS SOA-C03 Practice Test
Read the AWS SOA-C03 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.