3.3 - Deployment strategies, AMIs and launch templates
AWS SysOps Administrator objective 3.3 covers deployment and configuration management. You bake golden images as AMIs, copy and share them across Regions, and automate hardened image pipelines with EC2 Image Builder. Launch templates capture instance settings and versions for Auto Scaling and are preferred over launch configurations. Deployment strategies trade downtime, cost and rollback speed: all-at-once is fast but risky, rolling and rolling with an additional batch replace instances in waves, immutable and blue-green stand up fresh instances and switch over for a clean rollback. Elastic Beanstalk exposes these policies and .ebextensions, and CodeDeploy shifts traffic with canary or linear steps for Lambda and ECS. Expect scenario questions about a zero-downtime rollout, a clean rollback, or standardizing images, and ask which deployment strategy or provisioning feature fits.
Standardize hardened images = EC2 Image Builder. Cleanest rollback = immutable or blue-green (fresh instances, switch over). Auto Scaling needs a launch template, not a launch configuration.
Practice questions
1. In CloudFormation, which resource type defines a CloudWatch alarm on a metric?
- AWS::CloudWatch::Alarm (correct answer)
- AWS::CloudWatch::CompositeMetricThresholdRule
- AWS::Logs::MetricAlarm
- AWS::AutoScaling::AlarmPolicy
AWS::CloudWatch::Alarm is the resource type for both metric and composite alarms in CloudFormation. The other names are not real resource types.
2. You want an alarm state change to trigger a Lambda function for custom processing. Which service routes the alarm's state-change event to Lambda?
- Amazon EventBridge (correct answer)
- Amazon SNS delivering directly into the Lambda code editor console
- AWS Config recording the state as a compliance change over time
- CloudTrail replaying the alarm event straight into the function
CloudWatch alarm state changes are emitted as events that EventBridge can match with a rule and route to a Lambda target. SNS can also invoke Lambda, but the console editor is not a delivery target; Config and CloudTrail do not route these events.
3. In CloudFormation you create an AWS::Logs::LogGroup. Which property sets how long events are kept?
- ExpireEventsAfter, which accepts a duration string such as 30d
- The DeletionPolicy attribute set to a whole number of days
- RetentionInDays, set to an allowed value like 14, 30, or 90 (correct answer)
- A KmsKeyId reference that also silently controls how long logs last
RetentionInDays on AWS::Logs::LogGroup accepts only allowed values (1..3653) and controls expiry. ExpireEventsAfter is not a property, DeletionPolicy governs stack deletion behavior, and KmsKeyId only sets encryption.
4. On-premises servers must push logs to CloudWatch Logs. What credential approach does the agent use there?
- A dedicated IAM user's access keys placed in an agent credentials file (correct answer)
- The EC2 instance profile automatically attached to on-prem machines
- No credentials, because on-prem traffic to CloudWatch is always trusted
- The root account access keys copied onto each on-premises server manually
Outside EC2 there is no instance profile, so the on-prem agent uses a dedicated least-privilege IAM user's keys in a credentials file (or better, SSM hybrid activation roles). Instance profiles are EC2-only, credentials are always required, and root keys must never be used.
5. When a canary alarm fires you want an automatic runbook to restart the unhealthy service. What executes the runbook?
- A Systems Manager Automation document (correct answer)
- A CloudWatch dashboard text widget with steps
- An IAM policy attached to the canary role
- A metric filter converting logs into a metric
A Systems Manager Automation document defines runbook steps (like restarting a service) and can be triggered by the alarm through EventBridge for auto-remediation. A text widget only shows instructions, an IAM policy grants permissions, and a metric filter produces metrics, none of which executes actions.
6. EventBridge Scheduler offers a 'flexible time window'. What does it do?
- Spreads invocations within a window to avoid spikes (correct answer)
- Guarantees the target runs at the exact configured second, always
- Extends the schedule retention so stored events can be replayed later
- Blocks the schedule from firing outside normal business hours
A flexible time window lets Scheduler start an invocation at a random moment within the window, smoothing load spikes across many schedules. It does not guarantee exact-second timing, extend retention, or enforce business hours.