Examkin

All practice questions

24 questions

All types976Multiple choice502Multiple select450Ordering24
Question 1Question →

A SysOps Administrator is setting up automated OS patching for a fleet of Amazon EC2 instances running Ubuntu 22.04 LTS. The organization requires a custom patch baseline that automatically approves security updates with a 'Critical' or 'Important' severity 10 days after release. Patching must occur during a weekly maintenance window, and target instances must be grouped dynamically. Arrange the steps in the correct chronological order to configure this automated patch management workflow, starting with the baseline configuration.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure the automated patch management workflow: 1. Create a custom patch baseline for Ubuntu with the specified rules. 2. Tag the target EC2 instances with the case-sensitive tag key 'Patch Group'. 3. Associate the patch group with the custom patch baseline. 4. Create a Systems Manager Maintenance Window. 5. Register the target instances with the Maintenance Window. 6. Register the 'AWS-RunPatchBaseline' Run Command task with the Maintenance Window.
To automate patching with a custom baseline, the baseline must first be created with the required approval rules. Instances must then be tagged with the case-sensitive 'Patch Group' tag key to define the patch group. Next, the patch group is associated with the custom patch baseline. Then, a maintenance window is created to define the execution schedule. The target instances are registered with the maintenance window, and finally, the task executing the AWS-RunPatchBaseline document with the Install operation is registered to target those instances within the maintenance window.

Step-by-Step Solution

1
Create the custom patch baseline with the specified OS, approval rules, and auto-approval delay.
A custom patch baseline is created but not yet applied to any instances.
You must define the patching rules (e.g., auto-approving Critical patches after 10 days) first before applying them.
2
Apply the 'Patch Group' tag key (case-sensitive) with a custom value (e.g., 'Prod-Ubuntu') to the target instances.
The target instances are logically grouped under the 'Prod-Ubuntu' patch group.
SSM Patch Manager uses the 'Patch Group' tag key to map instances to specific baselines.
3
Associate the patch group name with the custom patch baseline.
Instances tagged with the patch group are now bound to the custom patch baseline instead of the default one.
This association ensures SSM Patch Manager applies the custom rules to the correct group of instances.
4
Create a Systems Manager Maintenance Window specifying the schedule (e.g., weekly) and duration.
A maintenance window is established but has no targets or tasks associated with it.
The maintenance window provides the scheduling framework for running the patching task.
5
Register the target instances with the Maintenance Window using resource tags.
The Maintenance Window now has defined targets to run tasks against.
You must register targets to the window so the task knows which instances to execute on.
6
Register the 'AWS-RunPatchBaseline' Run Command task with the Maintenance Window, specifying the registered targets and the 'Install' operation.
The configuration is complete, and patching will execute automatically on the schedule.
The task definition links the actual patch execution command ('AWS-RunPatchBaseline') to the maintenance window schedule and registered targets.

Key Concept

AWS Systems Manager Patch Manager configuration workflow involving custom baselines, case-sensitive patch groups, and maintenance window scheduling.
Estimated Time:2m 30s
Question 2Question →

An administrator is configuring a lifecycle hook (EC2_INSTANCE_TERMINATING) for an Amazon EC2 Auto Scaling group to back up application logs to an Amazon S3 bucket before instances are terminated. What is the correct chronological sequence of events starting from when the Auto Scaling group initiates the termination of an instance?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with the Auto Scaling group selecting the instance and transitioning it to the Terminating:Wait state. Next, Amazon EventBridge triggers a target function such as AWS Lambda. The target function performs the log backup to Amazon S3, and then calls the CompleteLifecycleAction API. Finally, the Auto Scaling group transitions the instance to the Terminating:Proceed state and terminates the instance.
The lifecycle hook flow requires that the Auto Scaling group first pauses termination (Terminating:Wait). This state change triggers EventBridge to invoke the cleanup script. Once the script backs up the logs to S3, it must call the CompleteLifecycleAction API with a CONTINUE result. The Auto Scaling group then changes the state to Terminating:Proceed and terminates the instance.

Step-by-Step Solution

1
Select and pause the instance.
The instance goes into the Terminating:Wait state, which pauses the termination.
This state transition allows custom actions to run before the instance is shut down.
2
Detect transition and trigger automation.
Amazon EventBridge catches the event and invokes the target Lambda function.
EventBridge orchestrates the event-driven notification of the lifecycle transition.
3
Execute cleanup scripts.
Logs are transferred to the Amazon S3 bucket.
The task must occur while the instance is still fully operational in the wait state.
4
Signal lifecycle completion.
The CompleteLifecycleAction API is called with the CONTINUE result.
This informs the Auto Scaling group that the custom action is finished.
5
Terminate the instance.
The instance moves to Terminating:Proceed and is shut down.
The Auto Scaling group resumes the termination workflow after the signal is received.

Key Concept

Auto Scaling Lifecycle Hooks
Question 3Question →

During an automated scale-in event, a SysOps administrator needs to understand the exact lifecycle of an Amazon EC2 instance within an Auto Scaling group. The group is registered with an Application Load Balancer (ALB) target group and is configured with an `EC2_INSTANCE_TERMINATING` lifecycle hook. Arrange the following events in the correct chronological order from the start of the scale-in event to the final termination of the instance.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, the Auto Scaling group selects the EC2 instance for termination based on the configured termination policy. Next, the instance state transitions to `Terminating`, and the Application Load Balancer begins the deregistration delay (connection draining). Third, the `EC2_INSTANCE_TERMINATING` lifecycle hook triggers, transitioning the instance to the `Terminating:Wait` state. Fourth, a custom log-collection script runs, and the lifecycle action is completed with a `CONTINUE` status. Finally, the instance transitions to `Terminating:Proceed` and is shut down and terminated after both the lifecycle action and deregistration delay complete.
The correct chronological sequence of events during a scale-in lifecycle event begins with the Auto Scaling group selecting the instance to terminate based on the group's termination policy. Once selected, the instance transitions to the `Terminating` state, which immediately triggers the Application Load Balancer to begin the deregistration delay (connection draining). Simultaneously, the scale-in lifecycle hook is triggered, shifting the instance state to `Terminating:Wait`. In this wait state, custom scripts (such as log backup) are executed. Once finished, a `complete-lifecycle-action` command is sent with a `CONTINUE` parameter, moving the instance to `Terminating:Proceed`. Finally, once both the lifecycle hook is completed and the deregistration delay has elapsed, the instance is terminated.

Step-by-Step Solution

1
Analyze the scale-in initiation
The Auto Scaling group evaluates the termination policy to choose which instance to terminate.
Before any action is taken on an instance, the Auto Scaling group must determine which instance is the correct target for scale-in.
2
Transition to Terminating and start ALB deregistration
The instance enters the `Terminating` state, and deregistration starts on the Application Load Balancer.
Starting deregistration early ensures that no new connections are sent to the instance while it is being decommissioned.
3
Trigger scale-in lifecycle hook
The lifecycle hook puts the instance into the `Terminating:Wait` state.
This pauses the termination process so that custom cleanup tasks (like exporting logs or state) can be performed before the instance is deleted.
4
Run custom cleanup and complete lifecycle action
The cleanup script runs, and a `complete-lifecycle-action` call is made with `CONTINUE`.
This notifies Auto Scaling that the custom cleanup tasks are finished and the termination flow can proceed.
5
Transition to Terminating:Proceed and terminate instance
The instance enters `Terminating:Proceed` and is terminated after the deregistration delay expires.
Both the lifecycle hook completion and the deregistration delay must be finished before the physical instance is terminated.

Key Concept

Auto Scaling Instance Lifecycle and Integration with ELB Deregistration Delay and Lifecycle Hooks
Question 4Question →

A SysOps administrator is configuring a launching lifecycle hook (`EC2_INSTANCE_LAUNCHING`) for an Amazon EC2 Auto Scaling group (ASG) integrated with an Application Load Balancer (ALB) target group. The administrator needs to ensure that custom software setup and patching are completed before instances receive traffic. Arrange the steps of the instance startup sequence in the correct chronological order from the initiation of the scale-out event to the instance serving active load-balanced traffic.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with the Auto Scaling group allocating a new instance and placing it into the `Pending` state. The lifecycle hook then immediately triggers, shifting the instance to `Pending:Wait`. While in this state, the instance boots up and runs its user data script. Once the script finishes, a call is made to `CompleteLifecycleAction` with the `CONTINUE` outcome. The instance then moves to `Pending:Proceed` and is registered with the ALB target group. Finally, the ALB health checks pass, and the instance is transitioned to the `InService` state.
The correct sequence ensures that the instance is allocated (`Pending`), paused (`Pending:Wait`), configured (user data runs), resumed via API (`CompleteLifecycleAction`), registered with the ALB (`Pending:Proceed`), and finally validated (`InService`). This order prevents premature routing of client traffic before configuration is complete.

Step-by-Step Solution

1
Initiate instance allocation and transition to the initial pending state.
The instance enters the `Pending` state.
This is the initial step in the Auto Scaling launch workflow.
2
Trigger the configured launching lifecycle hook to pause the startup process.
The instance enters the `Pending:Wait` state.
The lifecycle hook prevents the instance from moving forward in the workflow before configuration completes.
3
Run user data scripts on the booting EC2 instance.
Post-launch software installation and patching are completed on the instance.
The operating system boots up and runs user data while the Auto Scaling group holds the instance in the wait state.
4
Signal completion of the lifecycle action.
The `CompleteLifecycleAction` API is invoked with `CONTINUE`.
This notifies Auto Scaling that the custom configuration is complete and the launch workflow can resume.
5
Transition the instance out of the wait state and register it with the load balancer.
The instance moves to `Pending:Proceed` and is registered with the ALB target group.
Auto Scaling waits until the lifecycle hook is completed before registering the instance to prevent premature traffic routing.
6
Evaluate the health check status of the registered instance.
Health checks pass, and the instance enters the `InService` state.
Once marked healthy, the instance begins receiving active load-balanced client traffic.

Key Concept

Amazon EC2 Auto Scaling instance lifecycle hooks control the state transitions of newly launched instances, ensuring they execute configuration scripts and pass load balancer health checks before transitioning to the InService state.
Question 5Question →

An Auto Scaling group is configured to scale out when CPU utilization exceeds 70%. During a traffic spike, a scale-out event is triggered. Arrange the operational steps in the correct chronological order from the initial metric alarm to the point where the new instance handles active client requests.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence starts with the CloudWatch alarm triggering the scale-out policy. Next, the Auto Scaling group provisions the new instance using the active launch template. Then, the instance is registered with the target group of the Application Load Balancer. Finally, the load balancer routes client traffic to the instance once it passes health checks.
The correct order follows the logical operational flow: an alarm triggers the policy, the instance is provisioned, registered with the load balancer target group, and finally, traffic is routed to it after passing health checks.

Step-by-Step Solution

1
Triggering the policy
The CloudWatch alarm alerts the Auto Scaling group that CPU utilization has exceeded the threshold, starting the scale-out process.
Monitoring metrics must detect the load breach before any scaling action is initiated.
2
Provisioning the instance
Auto Scaling calls the EC2 API to boot up a new instance based on the launch template.
An active virtual machine must exist before it can be registered to receive network traffic.
3
Registering with the target group
The instance is registered with the load balancer target group in an initial state.
Registration is required so the load balancer is aware of the new resource's existence and IP address.
4
Passing health checks and serving traffic
The load balancer sends health probes to the instance, marks it healthy, and starts routing client requests.
Traffic routing must be delayed until the application on the instance is fully initialized and passing health checks to avoid routing requests to a broken node.

Key Concept

Auto Scaling instance launch and registration lifecycle with Elastic Load Balancing.
Question 6Question →

A SysOps administrator needs to update the Amazon Machine Image (AMI) for all Amazon EC2 instances in an Auto Scaling group (ASG) with minimal downtime. The administrator decides to use the ASG Instance Refresh feature.

Arrange the steps in the correct chronological order to successfully execute this rolling update.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of operations is: First, update the Auto Scaling group configuration to reference the new launch template version. Second, start the instance refresh process. Third, terminate a batch of instances running the old version while keeping the active count above the minimum healthy percentage. Fourth, launch replacement instances using the new version and verify their health. Fifth, repeat the process for the remaining old instances. Finally, transition the refresh status to Successful.
The correct order of steps ensures that the Auto Scaling group is updated with the new configuration first, so that the subsequent instance refresh knows the target state. The refresh then terminates and replaces instances in batches to maintain application availability, verifying the health of each batch before proceeding, and finally completing the process.

Step-by-Step Solution

1
Update the Auto Scaling group configuration to point to the new launch template version.
The target configuration for the group is set to the new template containing the updated AMI.
The instance refresh uses the group's currently associated launch template version to determine which instances need to be replaced.
2
Start the instance refresh process.
The rolling replacement workflow is initialized on the Auto Scaling group.
Starting the refresh tells Auto Scaling to begin the rolling update to match the newly associated launch template version.
3
Terminate a subset of instances running the old launch template version.
A batch of old instances is terminated while maintaining the minimum healthy percentage.
This ensures that the application retains enough active capacity to handle traffic during the update.
4
Launch replacement instances using the new launch template version and verify their health.
New instances are brought online and registered as healthy.
The rolling update cannot proceed to the next batch until the current replacement batch is verified healthy.
5
Repeat the termination and replacement steps for the remaining old instances.
The remaining old instances are replaced in subsequent batches.
This completes the rolling update across the entire Auto Scaling group.
6
Verify all instances are running the new launch template version and transition status.
The instance refresh status becomes Successful.
This marks the successful completion of the rolling update.

Key Concept

Auto Scaling Group Instance Refresh
Question 7Question →

A SysOps administrator is configuring a custom launch lifecycle hook for an Amazon EC2 Auto Scaling group (ASG) that is registered with an Application Load Balancer (ALB) target group. The lifecycle hook is designed to run an AWS Systems Manager (SSM) Run Command script to perform configuration tasks before the instance starts serving traffic. What is the correct chronological sequence of events for a successful instance scale-out process?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with launching the instance into the Pending state, followed by pausing it in the Pending:Wait state via the lifecycle hook. Next, EventBridge detects the state change and triggers SSM Run Command. The SSM script runs and completes the lifecycle action using the CONTINUE result. Finally, the instance transitions to InService and registers with the ALB target group.
The correct sequence ensures that the EC2 instance is fully configured via Systems Manager Run Command before it is marked InService and registered with the ALB target group. This prevents the load balancer from forwarding user requests to an unconfigured instance. The flow is: Launch (Pending) -> Pause (Pending:Wait) -> Event Notification (EventBridge to SSM) -> Execution & Completion (SSM script calling complete-lifecycle-action) -> Finalization (InService and ALB registration).

Step-by-Step Solution

1
Identify the initial state change when an ASG scale-out is triggered.
The Auto Scaling group launches a new EC2 instance, which enters the Pending state.
All instances launched by an ASG start in the Pending state before lifecycle hooks are evaluated.
2
Determine where the launch lifecycle hook intercepts the lifecycle.
The instance transitions to the Pending:Wait state.
Launch lifecycle hooks pause the launch sequence specifically at the Pending:Wait transition.
3
Identify the mechanism that initiates the SSM Run Command.
Amazon EventBridge intercepts the Pending:Wait transition and invokes SSM Run Command.
EventBridge handles events indicating the instance is waiting in a lifecycle hook and routes them to automation targets.
4
Determine how the ASG is notified to resume the launch sequence.
The SSM agent runs the script, which calls the complete-lifecycle-action API.
The callback with the CONTINUE result tells the ASG that the custom launch configuration has completed successfully.
5
Identify the final status transition and registration.
The instance moves to the InService state and registers with the ALB target group.
Once the lifecycle hook is completed, the instance enters the InService state and begins registration to receive traffic.

Key Concept

Auto Scaling lifecycle hooks and event-driven automation workflow
Question 8Question →

A SysOps Administrator needs to execute a script on a newly launched Amazon EC2 instance using AWS Systems Manager Run Command. Arrange the following steps in the correct sequential order to configure the instance and run the script.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: Attach the IAM instance profile to the EC2 instance, verify the instance appears under Managed Nodes, navigate to Run Command to choose the AWS-RunShellScript document, specify the targets and parameters, and then execute the command while monitoring the output.
The correct sequence begins with setting up permissions (attaching the IAM role) so that the instance can register with the Systems Manager service. Once verified in the Managed Nodes list, you select the Run Command interface and choose the execution document (AWS-RunShellScript). You then configure the targets and parameters, and finally execute the script and observe the logs.

Step-by-Step Solution

1
Attach an IAM instance profile with AmazonSSMManagedInstanceCore to the EC2 instance.
The EC2 instance is authorized to interact with Systems Manager APIs.
SSM Agent requires these permissions to authenticate and register the instance.
2
Verify the instance is listed as a Managed Node in the console.
Confirms the instance has successfully established communication with AWS Systems Manager.
An instance must be online and managed before commands can be targeted to it.
3
Open Run Command and select the AWS-RunShellScript document.
The console loads the interface for shell script execution.
SSM documents define the actions and capabilities for the Systems Manager execution.
4
Select the target instance and input the script parameters.
Specifies the payload and destination node configuration.
Run Command must map the script payload to the appropriate managed node target.
5
Execute the command and review the console logs.
Runs the script on the target instance and returns execution metrics.
Allows checking the output and verifying if the script executed successfully.

Key Concept

Configuring EC2 instances for Systems Manager management and executing commands via Run Command.
Question 9Question →

A SysOps Administrator needs to execute a shell script on a group of Amazon EC2 instances using AWS Systems Manager Run Command and archive the command output in an Amazon S3 bucket. The instances are currently running, but they do not have the required IAM permissions to associate with Systems Manager.

What is the correct sequence of steps to configure, execute, and capture the output of the Run Command operation?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with attaching the IAM instance profile to the EC2 instances, followed by executing the Run Command request with the S3 bucket configuration. The Systems Manager service then processes the request and sends the payload to the SSM Agent on the instances. The SSM Agent executes the script locally on each instance, and finally, the SSM Agent uploads the output logs to the S3 bucket.
The correct sequence mirrors the lifecycle of an AWS Systems Manager Run Command execution. First, the instances must become managed nodes, which is achieved by attaching the necessary IAM instance profile. Second, the Administrator initiates the Run Command execution, specifying the Amazon S3 bucket for logs. Third, the service routes this command to the agent running on the target instances. Fourth, the agent runs the script locally. Finally, the agent uploads the command output directly to the specified S3 bucket.

Step-by-Step Solution

1
Attach the IAM instance profile containing the AmazonSSMManagedInstanceCore policy to the target EC2 instances.
The EC2 instances register with AWS Systems Manager and appear as managed nodes.
Systems Manager cannot communicate with or manage EC2 instances that lack the necessary IAM permissions.
2
Call the Run Command API specifying target tags, the execution document, and the output S3 bucket.
The Systems Manager service receives the execution request.
The administrator must specify the execution parameters, including where execution logs should be delivered.
3
The Systems Manager service delivers the command payload to the SSM Agent on the managed nodes.
The SSM Agent on each target instance receives the command instructions.
The service acts as the controller and pushes the execution instructions to the registered agents.
4
The SSM Agent executes the command script locally on the instances.
The administrative script runs within the instance OS.
The SSM Agent acts as the local executor of the command within the host environment.
5
The SSM Agent uploads the stdout and stderr outputs to the specified Amazon S3 bucket.
Logs are securely stored in the S3 bucket for auditing and analysis.
The local agent handles copying the execution outputs back to the configured AWS storage endpoint.

Key Concept

The correct sequence of operations for AWS Systems Manager Run Command requires instances to first be managed nodes via proper IAM permissions, after which command requests are processed by the service, executed by the local agent, and logs are uploaded by the agent directly.
Estimated Time:1m 30s
Question 10Question →

A SysOps Administrator needs to automate a weekly security compliance script on a fleet of Amazon EC2 instances. The administrator wants to use AWS Systems Manager State Manager to execute a custom SSM document. The execution logs must be saved to a centralized, encrypted Amazon S3 bucket. The administrator needs to configure the required IAM permissions, Systems Manager components, and verify the setup.

What is the correct sequence of steps to configure, automate, and verify this setup?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: first, attach the IAM instance profile with AmazonSSMManagedInstanceCore to the EC2 instances; second, create the custom SSM Command document containing the compliance script; third, create the IAM service role for Systems Manager with S3 write permissions; fourth, create the State Manager association targeting the instances and configuring S3 logging; fifth, verify the execution status and output logs in the S3 bucket.
To automate a compliance script with Systems Manager, the instances must first be registered as managed nodes, which requires the AmazonSSMManagedInstanceCore IAM role and the SSM Agent. Next, the script must be defined in an SSM Command document. To write logs to an S3 bucket, an IAM service role for Systems Manager with S3 write permissions is required. Once these prerequisites are met, a State Manager association can be created to bind the document to the targets on a schedule with the logging configuration. Finally, the execution and logs can be verified.

Step-by-Step Solution

1
Configure IAM permissions and SSM agent on the target EC2 instances.
EC2 instances become managed nodes in Systems Manager.
Systems Manager cannot run command documents on instances unless they are registered as managed nodes with the SSM Agent active and the AmazonSSMManagedInstanceCore policy attached.
2
Define the compliance script in a custom SSM Command document.
The SSM Command document is available for execution.
An SSM document must be defined to encapsulate the script execution logic before it can be referenced in any association.
3
Create an IAM service role for Systems Manager with S3 bucket permissions.
An IAM role with ssm.amazonaws.com trust relationship and s3:PutObject permission is created.
Systems Manager requires an IAM service role to gain authorization to write execution logs directly to the target S3 bucket.
4
Create a State Manager association linking the document, targets, schedule, and S3 role.
State Manager automates the execution of the compliance script.
The association binds the SSM document to the target instances (using resource tags) and specifies the execution parameters including scheduling and logging configuration.
5
Verify execution logs and status.
The status is shown as Success in State Manager, and log files are present in the S3 bucket.
Verifying the console status and checking the S3 bucket ensures the script executed successfully and the logs were written correctly.

Key Concept

AWS Systems Manager Configuration and Run Command Automation
Question 11Question →

A SysOps Administrator needs to automate a multi-step patching and reboot sequence across a fleet of Amazon EC2 instances using a custom AWS Systems Manager Automation runbook. The SSM Agent is already installed and running on all target instances. The administrator wants to follow security best practices by using a service role to perform these actions.

Arrange the steps in the correct order to configure, authorize, and run this Automation workflow.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence requires first configuring the IAM service role for Systems Manager, followed by granting the administrator the iam:PassRole permission. Next, the custom Automation runbook document must be created. Once these prerequisites are met, the administrator can execute the Automation runbook referencing the service role and targets, and finally monitor the execution progress in the console.
The correct sequence begins with setting up the necessary IAM permissions: first, the service role itself must exist, and second, the executing identity must have permission to pass it. Next, the Automation runbook must be defined. Finally, the execution is initiated using the runbook and service role, and its progress is monitored.

Step-by-Step Solution

1
Configure the IAM service role
An IAM service role with a trust relationship for ssm.amazonaws.com is created, allowing SSM to interact with EC2 resources.
Systems Manager needs permissions to perform actions on target resources on your behalf.
2
Assign PassRole permissions
The administrator's IAM user or role is authorized to pass the service role to Systems Manager.
Without iam:PassRole, AWS prevents users from delegating roles to services to avoid privilege escalation.
3
Author the custom Automation runbook
An SSM Document of type Automation is saved in the AWS account.
The runbook contains the declaration of execution steps, inputs, and outputs for the patching process.
4
Initiate the execution
The Systems Manager Automation workflow begins executing on the target instances.
This step triggers the runbook using the specified parameters, target instances, and service role.
5
Monitor execution
Visual progress and outputs for each step are visible in the Systems Manager console.
SysOps administrators must verify that each step (patching, rebooting, verifying) succeeds without errors.

Key Concept

Authorizing and executing Systems Manager Automation runbooks using service roles and PassRole permissions.
Estimated Time:2m 0s
Question 12Question →

A SysOps Administrator is tasked with setting up automated patch management for a fleet of Amazon Linux 2 EC2 instances. The organization requires that a custom patch baseline be applied to these instances during a specific weekly maintenance window. The patching process must target only the instances configured with the patch group 'Prod-Linux'. Arrange the following steps in the correct chronological sequence to configure this automated workflow.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with creating the custom patch baseline, followed by tagging the instances with the case-sensitive 'Patch Group' tag, associating that patch group with the baseline, creating the Maintenance Window with registered targets, and registering the Run Command task to execute the AWS-RunPatchBaseline document.
The correct sequence begins with creating the custom patch baseline first to define approval rules. Next, target EC2 instances are tagged with the case-sensitive 'Patch Group' tag. The patch group is then registered with the custom baseline so Patch Manager maps the instances to this baseline instead of the default. After that, a Maintenance Window is defined, and the instances are registered as targets using their patch group tags. Finally, the task is registered in the Maintenance Window to run the 'AWS-RunPatchBaseline' SSM document on the registered targets.

Step-by-Step Solution

1
Create a custom patch baseline.
A custom patch baseline exists with defined rules for Amazon Linux 2.
Custom baselines must be defined before they can be configured with specific patch groups.
2
Tag EC2 instances with the key 'Patch Group' and value 'Prod-Linux'.
Instances are categorized into the patch group.
Systems Manager relies on the case-sensitive 'Patch Group' tag to map instances to baselines.
3
Associate the 'Prod-Linux' patch group with the custom baseline.
The custom baseline is mapped to the 'Prod-Linux' group.
This mapping overrides the default patch baseline for these instances.
4
Create a Maintenance Window and register targets using the 'Patch Group' tag.
A defined maintenance schedule and its target instances are configured.
Targets must be registered with the window before a task can execute on them.
5
Register a task running 'AWS-RunPatchBaseline' within the Maintenance Window.
A task is configured to execute during the window.
This schedules the patching command to execute on the registered targets during the specified schedule.

Key Concept

Automated operating system patching using Systems Manager Patch Manager, custom baselines, patch groups, and maintenance windows.
Estimated Time:2m 0s
Question 13Question →

A SysOps Administrator needs to execute a custom bash script on several on-premises servers using AWS Systems Manager Run Command. The on-premises servers are not yet registered with AWS. An IAM service role for Systems Manager hybrid activation has already been created.

What is the correct sequence of steps to register these on-premises servers and execute the script?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, create a hybrid activation to get the Activation ID and Activation Code. Second, install the SSM Agent on the on-premises servers and register them using the activation details. Third, verify that the servers appear as managed nodes in the Systems Manager console. Fourth, execute the command using AWS-RunShellScript targeting the managed nodes.
The registration process must begin with creating the activation credentials, then applying them locally to the hybrid servers. Only after confirming they are registered as managed nodes can commands be executed on them.

Step-by-Step Solution

1
Create a hybrid activation in Systems Manager.
Activation ID and Activation Code are generated.
These credentials allow the hybrid instances to securely register with AWS Systems Manager.
2
Install SSM Agent and register on-premises servers.
The SSM Agent registers with Systems Manager.
The on-premises servers require the agent and registration credentials to join the AWS account's managed fleet.
3
Verify instances appear as managed nodes.
Instances appear with the 'mi-' prefix.
Ensures that the agent is properly communicating and ready to receive commands.
4
Execute Run Command.
Run Command successfully targets the instances and runs the script.
Once the target nodes are managed, standard SSM Run Command documents can be targeted to them.

Key Concept

AWS Systems Manager hybrid activations and Run Command execution sequence
Question 14Question →

A SysOps Administrator is tasked with executing a custom configuration script on a new fleet of Amazon EC2 instances using AWS Systems Manager Run Command. The script needs to retrieve files from a private Amazon S3 bucket, and all command execution outputs must be streamed to an Amazon CloudWatch Logs group for auditing.

Arrange the steps in the correct sequence to configure the prerequisites and successfully execute the script.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with creating the IAM role and CloudWatch Logs group, followed by attaching the IAM role to the EC2 instances and running the SSM Agent. Next, the administrator verifies that the instances are registered as managed nodes, and finally, executes the Run Command using the custom script and enabling CloudWatch Logs output.
The correct sequence begins with provisioning the necessary IAM policies and the target log group. The IAM role must then be attached to the instances to grant them an identity. Only after the instances are recognized as managed nodes by Systems Manager can the Run Command be executed to run the configuration script and stream the logs.

Step-by-Step Solution

1
Set up IAM permissions and the CloudWatch Logs group.
The destination log group exists and the IAM policy is ready with the required S3 and CloudWatch permissions.
Resources and permission policies must be established before they can be attached to instances or used as destinations.
2
Attach the IAM instance profile and verify the SSM Agent.
The EC2 instances run with the necessary IAM identity and the SSM Agent process is active.
The SSM Agent needs the IAM role permissions to successfully communicate with the Systems Manager service endpoints.
3
Verify managed node status in Systems Manager.
The instances appear in the SSM Fleet Manager console as online managed nodes.
Systems Manager cannot execute Run Command documents on instances that have not successfully completed the registration handshake.
4
Execute the Run Command targeting the managed nodes.
The shell script is executed on the target instances, and logs are successfully sent to CloudWatch.
Run Command execution is the final operational step once all IAM, agent, and network prerequisites are satisfied.

Key Concept

Configuring the necessary IAM instance profile permissions, SSM Agent registration, and executing commands using Systems Manager Run Command with logging.
Question 15Question →

A financial company needs to enforce OS patch compliance across its fleet of production Windows Server 2022 EC2 instances. The system requires that only critical security updates be installed, bypassing the default AWS-managed baseline. A SysOps Administrator is tasked with establishing a weekly automated patch deployment workflow using AWS Systems Manager.

Order the steps below to reflect the correct sequence for configuring and executing this patching workflow.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Create a custom patch baseline for Windows Server, 2) Apply a tag to the target Windows Server EC2 instances with the case-sensitive key 'Patch Group' and a value like 'Win-Prod', 3) Register the 'Win-Prod' patch group with the custom patch baseline, 4) Create a Maintenance Window and register the target instances using the patch group, and 5) Register a Run Command task under the Maintenance Window executing the AWS-RunPatchBaseline document.
To successfully automate patching with a custom baseline, the administrator must first create the custom baseline containing the required rules. Next, the target instances must be tagged with the case-sensitive tag key 'Patch Group' to assign them to a patch group. The patch group must then be registered with the custom baseline to override the default baseline. Finally, a maintenance window is created, targets are registered using the patch group, and the AWS-RunPatchBaseline document task is registered to perform the installation during the window.

Step-by-Step Solution

1
Create a custom patch baseline.
A baseline exists specifying the approval rules for critical security updates.
AWS Systems Manager Patch Manager requires a baseline to know which updates to approve. By default, it uses a generic AWS-managed baseline. A custom baseline is required to enforce specific patch rules.
2
Tag the instances with the case-sensitive 'Patch Group' key.
Instances are logically grouped together in Patch Manager.
Patch groups allow you to target specific sets of instances for baseline association and maintenance window tasks. The tag key must be exactly 'Patch Group' (case-sensitive).
3
Associate the patch group with the custom baseline.
The 'Win-Prod' patch group is registered to the custom patch baseline.
This step overrides the default baseline. Systems Manager will now apply the custom baseline rules to any instance tagged with that patch group.
4
Configure the maintenance window and targets.
A scheduled window is defined with registered EC2 targets.
The maintenance window defines when patching occurs. Registering the targets using the patch group simplifies management.
5
Register the AWS-RunPatchBaseline task to the maintenance window.
The patching task is scheduled to run on the targets during the maintenance window.
The task executes the actual patching process using the AWS-RunPatchBaseline document, which references the baseline associated with the patch group.

Key Concept

AWS Systems Manager Patch Manager operational setup sequence using custom baselines, patch groups, and maintenance windows.
Question 16Question →

A SysOps Administrator is tasked with automating the deployment of OS patches for a fleet of Amazon Linux 2023 EC2 instances. The administrator wants to use a custom patch baseline to enforce security compliance. The instances are divided into a 'Production' environment, and patches must only be applied during a weekly Saturday night maintenance window. The setup must ensure that the custom baseline is applied rather than the default AWS-managed baseline. Arrange the steps in the correct order to configure this automated patch management workflow.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps is: 1) Create a custom patch baseline for Amazon Linux 2023. 2) Associate the patch group named 'Production' with the custom patch baseline. 3) Apply the case-sensitive tag key 'Patch Group' with value 'Production' to the EC2 instances. 4) Create a Systems Manager Maintenance Window. 5) Register targets and the AWS-RunPatchBaseline task to the Maintenance Window.
The correct order follows the logical dependencies of Systems Manager resources. First, the custom patch baseline is created to define rules. Second, the patch group name is associated with the baseline so that when instances register to the group, Systems Manager knows which baseline to apply. Third, the 'Patch Group' tag is applied to instances. Fourth, a Maintenance Window is defined to control the schedule. Finally, targets and the 'AWS-RunPatchBaseline' task are registered within the Maintenance Window.

Step-by-Step Solution

1
Create the custom patch baseline.
A custom baseline with custom approval rules is created.
This establishes the compliance rules for Amazon Linux 2023 before any association can occur.
2
Associate the 'Production' patch group string with the custom patch baseline.
The patch group is bound to the custom baseline.
This ensures any instance belonging to the 'Production' patch group uses the custom baseline rather than the default baseline.
3
Tag the EC2 instances with the case-sensitive tag key 'Patch Group' and value 'Production'.
The instances are grouped under the 'Production' patch group.
This assigns the instances to the correct baseline and allows them to be targeted together.
4
Create a Systems Manager Maintenance Window.
A scheduled window is defined.
A Maintenance Window must exist before targets and tasks can be registered under it.
5
Register the target instances and the 'AWS-RunPatchBaseline' task in the Maintenance Window.
The automated patching workflow is fully configured.
This links the schedule, the target instances, and the patching command to execute the updates.

Key Concept

Orchestrating automated patching using Systems Manager Patch Manager custom baselines, patch groups, and maintenance windows.
Estimated Time:2m 0s
Question 17Question →

An organization hosting a web application on AWS uses an Amazon EC2 Auto Scaling group (ASG). A SysOps administrator is configuring a scale-in lifecycle hook to back up application logs to an Amazon S3 bucket before any instance is terminated. A target tracking policy has just triggered a scale-in event.

Order the steps to show the sequence of events that occurs when an instance is terminated using this lifecycle hook, from the start of the scale-in process to the final termination.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins when the Auto Scaling group selects the instance and transitions it to the Terminating:Wait state. Next, an EventBridge rule detects this transition and triggers the Systems Manager Run Command script. The script runs on the instance and uploads the logs to Amazon S3. Once complete, the script invokes the CompleteLifecycleAction API with the CONTINUE result, which allows the Auto Scaling group to transition the instance to Terminating:Proceed and terminate the instance.
The correct order follows the logical flow of the Amazon EC2 Auto Scaling scale-in lifecycle hook. First, the ASG identifies the instance to terminate and pauses termination by putting the instance into the 'Terminating:Wait' state. This state transition generates an EventBridge event, which triggers the Systems Manager Run Command. The Run Command script then executes on the instance to back up the logs to Amazon S3. Once the backup is complete, the script calls the CompleteLifecycleAction API with a CONTINUE result. Finally, the ASG transitions the instance to 'Terminating:Proceed' and terminates the instance.

Step-by-Step Solution

1
Identify the initial event that pauses the scale-in process.
The Auto Scaling group selects the instance and transitions it to the Terminating:Wait state.
Lifecycle hooks intercept termination to run custom tasks, starting with placing the instance in a wait state.
2
Determine how the backup orchestration is triggered.
Amazon EventBridge detects the Terminating:Wait transition and triggers Systems Manager Run Command.
EventBridge rules are used to capture lifecycle state changes and trigger automation targets.
3
Perform the custom log backup task on the instance.
The Systems Manager Run Command script successfully uploads the application logs to the S3 bucket.
The instance must remain running in the wait state while the files are being transferred.
4
Signal completion to the Auto Scaling group.
The script invokes the CompleteLifecycleAction API call with the CONTINUE result.
An explicit API call is required to tell the ASG that the custom action has finished and it can proceed.
5
Complete the lifecycle transition and terminate the instance.
The Auto Scaling group transitions the instance to Terminating:Proceed and terminates the EC2 instance.
Receiving the CONTINUE result allows the Auto Scaling group to resume and complete the termination workflow.

Key Concept

Auto Scaling lifecycle hooks suspend instance state changes, allowing custom workflows (such as log archiving via Systems Manager and EventBridge) to execute before the instance proceeds to the next state.
Estimated Time:2m 0s
Question 18Question →

A SysOps administrator notices that an Amazon EC2 Auto Scaling group is routing client traffic to new instances before the application's configuration script has finished installing required dependencies. To resolve this issue, the administrator configures an EC2_INSTANCE_LAUNCHING lifecycle hook. What is the correct sequence of events required to ensure the instances are properly configured before they start receiving traffic?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with the Auto Scaling group initiating the launch of a new EC2 instance, followed by the instance pausing in the Pending:Wait state. Next, the configuration script completes the setup and calls the CompleteLifecycleAction API, and finally, the instance transitions to the InService state to serve traffic.
The sequence starts with the launch initiation. The lifecycle hook then immediately pauses the launch by putting the instance into the Pending:Wait state. The configuration script runs and calls the CompleteLifecycleAction API, allowing the instance to transition to the InService state and accept traffic.

Step-by-Step Solution

1
Identify the scale-out initiation trigger.
The Auto Scaling group starts launching the instance.
Before any state transitions or lifecycle hooks can occur, the instance launch must be initiated by the Auto Scaling group.
2
Trace the effect of the lifecycle hook on the state transition.
The instance enters the Pending:Wait state.
The EC2_INSTANCE_LAUNCHING lifecycle hook pauses the default flow and prevents the instance from immediately transitioning to the InService state.
3
Determine how the script signals completion.
The configuration script runs and sends a CompleteLifecycleAction API call.
An explicit signal is required to notify the Auto Scaling group that the custom initialization tasks have finished.
4
Identify the final operational state of the instance.
The instance state transitions to InService.
Once the API call is processed successfully, the instance completes its launch flow and begins receiving traffic.

Key Concept

Auto Scaling lifecycle hooks allow you to pause instance state transitions (such as Pending:Wait during scale-out) to run custom configuration tasks, which must be completed via the CompleteLifecycleAction API before the instance is marked InService.
Question 19Question →

A company has an Amazon EC2 Auto Scaling group (ASG) configured with a scale-in lifecycle hook. When a scale-in event occurs, application log files on the instance must be backed up to an Amazon S3 bucket before the instance is terminated. A SysOps administrator is configuring this flow using Amazon EventBridge and AWS Systems Manager Run Command.

Arrange the sequence of events in the correct chronological order from the initiation of the scale-in event to the final termination of the instance.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with Auto Scaling selecting the instance for termination. Next, the instance enters the Terminating:Wait state, which triggers an Amazon EventBridge rule to invoke the Systems Manager Run Command. The SSM Run Command runs the backup script on the instance, which uploads logs to S3. Once completed, the script signals Auto Scaling via the complete-lifecycle-action CLI command with a CONTINUE result. Finally, Auto Scaling moves the instance to Terminating:Proceed and terminates it.
The correct order follows the chronological flow of an Auto Scaling lifecycle hook from the initial scale-in determination, pausing in Terminating:Wait, triggering remediation via EventBridge, executing SSM Run Command to copy logs, signaling completion using the AWS CLI, and finally terminating the instance in Terminating:Proceed.

Step-by-Step Solution

1
Select instance for termination
The target instance is chosen according to the ASG's termination policies.
Before any lifecycle action occurs, the scale-in trigger must run and identify which instance will be terminated.
2
Pause instance termination
The instance enters the Terminating:Wait state.
The lifecycle hook intercepts the termination flow to allow custom tasks like log exporting to run first.
3
Trigger automation via EventBridge
EventBridge receives the event pattern and targets SSM Run Command.
EventBridge serves as the event bus that detects the state change and initiates the remediation action.
4
Run logs export on the instance
Logs are transferred to the Amazon S3 bucket.
The SSM Agent running on the instance runs the script locally to retrieve and store the application logs.
5
Complete lifecycle hook action
Auto Scaling receives the API call to complete the lifecycle hook.
The script must signal Auto Scaling that the logs are successfully archived so it knows it is safe to proceed.
6
Proceed with termination
The instance moves to Terminating:Proceed and is shut down.
With the lifecycle hook resolved, Auto Scaling resumes the normal termination process.

Key Concept

Auto Scaling Lifecycle Hooks and AWS Integration
Question 20Question →

A SysOps administrator is troubleshooting an issue where an Amazon EC2 Auto Scaling group behind an Application Load Balancer (ALB) is registering new instances with the ALB before they are fully configured, leading to temporary HTTP 502 Bad Gateway errors. The administrator implements an `EC2_INSTANCE_LAUNCHING` lifecycle hook to pause the instance state during initialization. Arrange the sequence of operational steps and state transitions that must occur for a new instance to be successfully configured and start receiving healthy traffic from the ALB.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps starts with Auto Scaling launching the instance, transitioning it to the Pending state, pausing it via the launch lifecycle hook (Pending:Wait), executing the bootstrap scripts, completing the lifecycle action with a CONTINUE signal, and finally registering the instance with the Application Load Balancer target group to transition to the InService state.
The correct sequence ensures that the instance remains in a paused state (Pending:Wait) while configuration scripts run, preventing the load balancer from routing traffic to an unconfigured instance. The lifecycle hook must be completed using the API before Auto Scaling proceeds with load balancer registration and transitioning the instance to the InService state.

Step-by-Step Solution

1
Auto Scaling responds to a scale-out alarm.
A new EC2 instance is launched.
To scale out capacity as defined by the scaling policy.
2
The instance boots up.
State transitions to Pending.
This is the default initial state for launching Auto Scaling instances.
3
The configured EC2_INSTANCE_LAUNCHING lifecycle hook triggers.
State transitions to Pending:Wait.
To pause the launch process and prevent early registration with the ALB.
4
The instance executes the bootstrap scripts specified in its User Data.
Software dependencies are installed and the application starts.
To configure the instance for production traffic while paused.
5
The configuration script invokes the complete-lifecycle-action CLI command.
State transitions to Pending:Proceed.
To signal to Auto Scaling that bootstrapping is complete.
6
Auto Scaling registers the instance with the ALB target group and monitors target health.
State transitions to InService once health checks pass.
To allow healthy traffic to be routed to the newly configured instance.

Key Concept

Auto Scaling Lifecycle Hooks and State Transitions
Estimated Time:2m 0s
Page 1 / 2Next
All practice questions — AWS Certified SysOps Administrator - Associate | Examkin