Back to AWS Certified SysOps Administrator - Associate (SOA-C02)

Deployment, Provisioning, and Automation

Provision and maintain cloud resources, automate deployments, and manage infrastructure as code (~18% of exam).

Covers provisioning and maintaining cloud resources including EC2 instances, EBS volumes, AMIs, launch templates, placement groups, and instance store. Also covers deploying resources using AWS CloudFormation including stack creation, updates, drift detection, change sets, nested stacks, and StackSets for multi-account deployments. Covers automation tools including AWS Systems Manager for patch management, State Manager, Run Command, Parameter Store, Session Manager, and Automation documents. Additionally covers CI/CD concepts with AWS CodePipeline, CodeBuild, CodeDeploy, and deployment strategies (in-place, blue/green, rolling).
5 minutes 5 Questions

Deployment, Provisioning, and Automation are core concepts for AWS SysOps Administrators that enable efficient cloud infrastructure management. **Deployment** refers to the process of releasing applications and updates to AWS environments. AWS provides several deployment services including AWS Cod…

Concepts covered: AWS CodeDeploy, CodeDeploy deployment groups, EC2 instance purchasing options, EC2 placement groups, EC2 instance store, EC2 instance metadata, Amazon Machine Images (AMIs), AMI sharing and copying, CloudFormation nested stacks, CloudFormation rollback behavior, EC2 instance types, EBS volume types, EBS volume management, EBS RAID configurations, EC2 launch templates, User data scripts, Elastic IP addresses, AWS Systems Manager overview, Systems Manager Run Command, Systems Manager State Manager, Systems Manager Patch Manager, Patch baselines, Maintenance windows, Systems Manager Session Manager, Systems Manager Parameter Store, Systems Manager Inventory, SSM Agent, Automation documents, AWS Config rules, AWS Config remediation, AWS CloudFormation basics, CloudFormation templates, CloudFormation stack creation, CloudFormation stack updates, CloudFormation change sets, CloudFormation drift detection, CloudFormation StackSets, CloudFormation intrinsic functions, CloudFormation parameters and outputs, CloudFormation resource dependencies, AWS CodePipeline, AWS CodeBuild, Blue/green deployments, Rolling deployments, In-place deployments

Test mode:
Start practice test
SOA-C02 - Deployment, Provisioning, and Automation Example Questions

Test your knowledge of Deployment, Provisioning, and Automation

Question 1

A pharmaceutical company runs clinical trial data processing on AWS. Their workload consists of two distinct components: a database tier that must run continuously and processes patient data 24/7 using r6i.2xlarge instances, and a compute tier that performs statistical analysis using c6i.4xlarge instances only when researchers submit analysis requests (approximately 60% of the time during business hours). The database tier requires 8 instances and has been stable for 2 years with confirmed continuation for another 3 years. The compute tier fluctuates between 5-15 instances based on research activity. The CFO has approved partial upfront payments and wants to optimize the overall EC2 spend. The compliance team requires that database instances never experience capacity-related interruptions. Which purchasing combination should the SysOps Administrator implement?

Correct Answer: Purchase 3-year All Upfront Reserved Instances with Capacity Reservations for the 8 database instances, and apply a Compute Savings Plan sized for the average compute tier usage

The correct answer is to purchase 3-year All Upfront Reserved Instances with Capacity Reservations for the 8 database instances, and apply a Compute Savings Plan sized for the average compute tier usage.

This solution optimally addresses all requirements:

For the Database Tier:
- 3-year Reserved Instances provide the maximum discount (up to 72% savings) for workloads with confirmed long-term usage (the scenario confirms 3 more years of operation)
- All Upfront provides the highest discount, though Partial Upfront was approved, All Upfront is acceptable and provides better savings
- Capacity Reservations guarantee that the 8 database instances will always have capacity available, meeting the compliance requirement that database instances never experience capacity-related interruptions
- The combination of RIs with Capacity Reservations ensures both cost optimization and guaranteed capacity

For the Compute Tier:
- Compute Savings Plans are ideal for fluctuating workloads (5-15 instances) as they provide flexibility across instance families, sizes, and regions
- Sizing for average usage means the company pays discounted rates for baseline consumption while paying On-Demand for peaks above the plan
- Since the compute tier only runs 60% of business hours and fluctuates, a Savings Plan provides better value than Reserved Instances

Why other options are incorrect:

Purchasing Reserved Instances for 10 compute instances is suboptimal because the compute tier fluctuates and only runs 60% of business hours. RIs for compute would result in paying for unused capacity during off-hours and when fewer than 10 instances are needed.

1-year Convertible Reserved Instances for a confirmed 3-year database workload wastes significant savings potential. Additionally, Spot Instances for clinical trial data processing is inappropriate as Spot can be interrupted, which would disrupt critical research analysis.

An EC2 Instance Savings Plan based on peak usage would result in paying for committed usage that isn't always utilized. Also, On-Demand Capacity Reservations as 'backup' for database instances is inefficient since you'd be paying for capacity reservations on top of other costs, and this doesn't provide the cost optimization of Reserved Instances.

Question 2

A financial services company has an AWS CodePipeline that deploys their trading platform with stages: Source (CodeCommit), Build (CodeBuild), Test (CodeBuild), and Deploy (ECS). The pipeline is configured with PARALLEL execution mode to maximize deployment throughput. During a busy trading day, the development team pushed three commits within a 10-minute window: Commit A at 10:00 AM, Commit B at 10:05 AM, and Commit C at 10:10 AM. Each commit triggered a separate pipeline execution. The operations team noticed that all three executions were running simultaneously through different stages. At 10:25 AM, a production incident occurred, and the team needs to determine which code version is currently deployed. They observe that Execution #1 (Commit A) is in Deploy stage, Execution #2 (Commit B) just completed Test stage, and Execution #3 (Commit C) is in Build stage. The team lead is concerned about potential deployment conflicts and artifact consistency. What is a key operational consideration when using PARALLEL execution mode that the team should understand for incident response?

Correct Answer: Each execution operates independently with its own artifacts, so multiple versions may deploy to production in rapid succession based on which execution reaches Deploy first, requiring careful monitoring of which version is actually running

When using PARALLEL execution mode in AWS CodePipeline, each pipeline execution operates completely independently with its own set of artifacts. This means that multiple executions can progress through different stages simultaneously without any coordination between them.

The key operational consideration is that executions do NOT necessarily complete in the order they started. In PARALLEL mode, whichever execution reaches the Deploy stage first will deploy first, regardless of which commit triggered it. This means a newer commit could potentially deploy before an older one if it progresses through the Build and Test stages faster.

In the scenario described, while Execution #1 (Commit A) is currently in the Deploy stage, if it fails or takes longer, Execution #2 (Commit B) could complete its deployment before Execution #1 finishes. This creates a situation where the team must carefully track which specific version is actually running in production, as the deployment order may not match the commit order.

The other answers are incorrect because:

  • PARALLEL mode does NOT ensure executions complete in order. There is no internal queuing mechanism that preserves commit order. The whole point of PARALLEL mode is to allow concurrent, independent execution.

  • PARALLEL mode does NOT merge artifacts from concurrent executions. Each execution maintains its own isolated artifact set throughout the entire pipeline. There is no automatic merging of code changes between executions.

  • PARALLEL mode does NOT lock stages. Stage locking is a characteristic of SUPERSEDED execution mode, not PARALLEL mode. In PARALLEL mode, multiple executions can be in the same stage type simultaneously (though in different action runs).

For incident response with PARALLEL execution mode, teams should implement proper tagging, versioning, and monitoring to track exactly which deployment succeeded and which version is currently serving production traffic.

Question 3

A DevOps team at a media company has configured an AWS CodePipeline for their video streaming application. The pipeline includes Source (GitHub), Build (CodeBuild), Test (CodeBuild), and Deploy (Lambda) stages. The team has configured Amazon EventBridge rules to monitor pipeline state changes and send notifications to an SNS topic when deployments complete or fail. During a recent incident investigation, the team discovered that they were not receiving notifications for failed actions within stages—only for overall pipeline state changes. The operations manager wants granular visibility into individual action failures within each stage to improve incident response times. The team needs to modify their monitoring approach to capture action-level execution details. What EventBridge event detail-type should the team configure to receive notifications specifically when individual actions within pipeline stages fail?

Correct Answer: Configure EventBridge rules using the 'CodePipeline Action Execution State Change' detail-type to capture action-level failures

The correct answer is to configure EventBridge rules using the 'CodePipeline Action Execution State Change' detail-type to capture action-level failures.

AWS CodePipeline emits three distinct types of events to Amazon EventBridge:

  1. CodePipeline Pipeline Execution State Change - Monitors the overall pipeline execution status (STARTED, SUCCEEDED, FAILED, etc.)

  2. CodePipeline Stage Execution State Change - Monitors stage-level execution status changes

  3. CodePipeline Action Execution State Change - Monitors individual action execution status changes within stages

Since the team needs granular visibility into individual action failures within each stage, the 'CodePipeline Action Execution State Change' detail-type is the appropriate choice. This event type is specifically designed to emit events when individual actions (like a specific CodeBuild build action or Lambda deploy action) change state, including when they fail.

The other options are incorrect for the following reasons:

  • Using 'CodePipeline Pipeline Execution State Change' with filters for action-level FAILED status will not work because this event type only contains pipeline-level execution information, not action-level details. You cannot filter for action-level failures within pipeline execution events.

  • Using 'CodePipeline Stage Execution State Change' and attempting to parse nested action status from the event payload is incorrect because stage execution events do not contain detailed nested action status information. Stage events only indicate when a stage as a whole starts, succeeds, fails, or is canceled.

  • Combining 'CodePipeline Action Execution State Change' with CloudWatch Logs Insights queries is unnecessarily complex. The Action Execution State Change events already contain all the necessary action metadata directly in the event payload, including action name, stage name, execution ID, and failure details. There is no need to query CloudWatch Logs to extract action metadata.

More Deployment, Provisioning, and Automation questions
896 questions (total)
Start 100 question test