All practice questions

976 questions

All types976 Multiple choice502 Multiple select450 Ordering24

A SysOps Administrator is setting up monitoring for a microservice that writes JSON-formatted application logs to an Amazon CloudWatch Logs log group. The logs contain a field named `status` indicating the outcome of each transaction. The administrator needs to create a metric filter to count how many times a transaction ends with a status of `FAILED`.

How should the administrator configure this metric filter?

Configure the log group retention setting to only retain logs matching `{ $.status = "FAILED" }`, which automatically populates a custom metric.

Enable detailed monitoring on the EC2 instance hosting the microservice, which automatically enables JSON log parsing and creates a default CloudWatch metric named `status`.

Create a metric filter with the pattern `{ $.status = "FAILED" }` to match the JSON log structure and increment a custom metric.

Create an Amazon EventBridge rule that triggers on any write to the log group, and configure a Systems Manager Automation document to parse the JSON logs and increment the metric.

Show answer & explanation

Answer: Create a metric filter with the pattern `{ $.status = "FAILED" }` to match the JSON log structure and increment a custom metric.

Answer

Create a metric filter with the pattern `{ $.status = "FAILED" }` to match the JSON log structure and increment a custom metric.

The correct action is to create a metric filter with the pattern `{ $.status = "FAILED" }`. CloudWatch Logs supports filtering JSON log events by specifying the property path prefixed by a dollar sign and dot inside curly braces. This allows CloudWatch to match events where the status field is FAILED and increment a custom metric accordingly.

Step-by-Step Solution

Define the target filter pattern for JSON logs.

The pattern `{ $.status = "FAILED" }` is selected to target the status key in the log event JSON object.

CloudWatch Logs uses curly braces and the `$.<property>` syntax to parse and evaluate JSON formatted logs.

Associate the filter pattern with a new metric in the CloudWatch Logs console or CLI.

A custom metric namespace and metric name are defined, along with a metric value (typically 1) to increment on each match.

This establishes the relationship between the parsed log event and the CloudWatch metric system.

Key Concept

CloudWatch Logs Metric Filters for JSON logs

Question 162Question →

An organization's security policy requires a SysOps Administrator to perform log file integrity validation on AWS CloudTrail logs from the previous quarter. The CloudTrail logs and digest files are delivered to an Amazon S3 bucket. An S3 Lifecycle rule is configured to transition all objects under the `AWSLogs/` prefix to the S3 Glacier Flexible Retrieval storage class after 30 days. When the administrator attempts to validate the logs using the command `aws cloudtrail verify-log-file`, the command fails with an error indicating that the operation is not valid for the object's storage class. Which action will resolve this issue and allow the administrator to successfully validate the logs?

Modify the S3 bucket policy to grant `s3:GetObject` permissions to the `cloudtrail.amazonaws.com` service principal for Glacier objects, and re-run the verification command.

Re-run the verification command with the `--digest-only` parameter to perform the integrity check using only the metadata stored under the CloudTrail-Digest prefixes.

Initiate a restore request for both the log files and the digest files in the S3 bucket, wait for the restore process to complete, and then run the verification command.

Configure an IAM policy for the administrator's role that includes `iam:PassRole` permissions for the CloudTrail service principal, and re-run the verification command with the `--restore-glacier` parameter.

Show answer & explanation

Answer: Initiate a restore request for both the log files and the digest files in the S3 bucket, wait for the restore process to complete, and then run the verification command.

Answer

Initiate a restore request for both the log files and the digest files in the S3 bucket, wait for the restore process to complete, and then run the verification command.

The correct action is to initiate a restore request for both the log files and the digest files, wait for the restore process to complete, and then run the validation command. The AWS CLI `verify-log-file` command downloads the log and digest files to compute and compare SHA-256 hashes. Because Glacier objects are archived, they cannot be read directly. Temporary restoration to S3 Standard is necessary for the command to succeed.

Step-by-Step Solution

Identify the storage class of the CloudTrail logs and digest files for the target time period.

The files are determined to be in the S3 Glacier Flexible Retrieval storage class.

Objects in Glacier cannot be accessed directly via GetObject operations required by CLI verification commands.

Initiate a temporary restore operation (e.g., using S3 Batch Operations or a script) for both the `.json.gz` log files and the `.json.gz.digest` files.

S3 begins restoring the objects to a temporarily accessible state in S3 Standard.

Both log and digest files must be readable to perform the cryptographic hash validation.

Wait for the restoration process to complete, then execute the command: `aws cloudtrail verify-log-file --s3-bucket <bucket-name> --trail-arn <trail-arn> --start-time <start-time> --end-time <end-time>`

The command successfully retrieves the files, calculates the hashes, and verifies log integrity.

Once restored, the CLI can download the files and perform the validation.

Key Concept

CloudTrail Log File Integrity Validation requires readable access to both digest and log files, meaning archived S3 Glacier objects must be restored before verification.

Question 163Question →

A SysOps administrator is managing an application running on Amazon EC2 instances inside an Auto Scaling group (ASG). The ASG uses a target tracking scaling policy based on the default `ASGAverageCPUUtilization` metric, with a target utilization of $50\%$ . The application experiences sudden, high-intensity traffic spikes that typically last for $10$ to $15$ minutes. However, during these spikes, the ASG takes $5$ to $7$ minutes to begin launching new instances, causing the existing instances to become overloaded and fail health checks. The launch template for the ASG does not explicitly configure monitoring.

Which of the following describes the root cause of this delayed scaling behavior, and the correct remediation step?

The default instance warmup period for the target tracking policy is set to the default value of

300

seconds, preventing the ASG from launching new instances until the warmup expires. The administrator should decrease the default cooldown period of the Auto Scaling group to

60

seconds.

The EC2 instances are reporting metrics at the default

5

-minute interval, causing a delay in the aggregation of the `ASGAverageCPUUtilization` metric. The administrator should enable detailed monitoring in the launch template.

The Auto Scaling group metrics collection is disabled, which prevents CloudWatch from gathering metrics at a

1

-minute frequency. The administrator should enable group metrics collection in the Auto Scaling group configuration.

The service-linked role for Auto Scaling lacks the `iam:PassRole` permission to pass the execution role to the new instances, causing CloudWatch alarm action executions to time out. The administrator should attach a policy allowing `iam:PassRole` to the Auto Scaling service role.

Show answer & explanation

Answer: The EC2 instances are reporting metrics at the default $5$ -minute interval, causing a delay in the aggregation of the `ASGAverageCPUUtilization` metric. The administrator should enable detailed monitoring in the launch template.

Answer

The correct answer is that the EC2 instances are reporting metrics at the default

5

-minute interval, and detailed monitoring must be enabled in the launch template.

The correct answer is the option indicating that the instances are reporting metrics at the default

5

-minute interval, and detailed monitoring must be enabled in the launch template. By default, EC2 instances send CPU utilization metrics to CloudWatch every

5

minutes. Because target tracking scaling policies rely on the aggregated `ASGAverageCPUUtilization` metric, the underlying alarm is bound by this

5

-minute reporting interval. Consequently, a sudden load spike is not registered quickly enough, leading to a scaling delay. Enabling detailed monitoring in the launch template changes this reporting interval to

1

minute, resolving the delay.

Step-by-Step Solution

Analyze the metrics source and default monitoring settings for Amazon EC2 instances.

Identify that by default, standard monitoring is active, which sends CPU metrics to Amazon CloudWatch at

5

-minute intervals.

Target tracking scaling policies evaluate aggregated metrics like `ASGAverageCPUUtilization` that rely on individual instance metrics.

Evaluate the delay in metric updates during traffic spikes.

Determine that a traffic spike starting right after a metric push can take up to

5

minutes to be reflected in CloudWatch, delaying alarm breach.

Without detailed monitoring, CloudWatch does not receive the granular data needed to trigger scale-out actions within

1

2

minutes.

Formulate the remediation strategy.

Enable detailed monitoring in the launch template to change the metric delivery interval to

1

minute.

This ensures the `ASGAverageCPUUtilization` metric is updated every minute, allowing the target tracking policy to trigger scaling quickly.

Key Concept

The difference between Standard and Detailed Monitoring on EC2 instances and its impact on Auto Scaling responsiveness.

Estimated Time:3m 0s

Question 164Question →

An Auto Scaling group uses a target tracking scaling policy based on average CPU utilization. During sudden load increases, the Auto Scaling group launches new EC2 instances. The application on these instances requires five minutes to complete initialization and begin serving requests. During this initialization period, the Auto Scaling group continues to launch additional, unnecessary EC2 instances because the average CPU utilization remains high. Which parameter should be configured to prevent this behavior?

The default instance warmup time on the Auto Scaling group

The scale-in cooldown period on the target tracking policy

Detailed monitoring for the EC2 instances in the launch template

The EventBridge rule delay timer for Auto Scaling group events

Show answer & explanation

Answer: The default instance warmup time on the Auto Scaling group

Answer

The default instance warmup time on the Auto Scaling group

Configuring the default instance warmup time tells the Auto Scaling group to exclude newly launched instances from the group's metric averages until they have warmed up for the specified duration. This prevents the scaling policy from launching additional instances while the first set of instances is still initializing.

Step-by-Step Solution

Identify the cause of the unnecessary scaling actions.

Newly launched instances are taking 5 minutes to boot, but their high initialization CPU utilization is being immediately included in the group average calculation, triggering further scale-out.

This helps locate the phase of the lifecycle where the problem occurs.

Determine the parameter that controls how long to wait before including new instances in Auto Scaling metrics.

The default instance warmup parameter (or policy-specific warmup) defines this exclusion window.

To choose the setting that directly pauses metric aggregation for booting instances.

Key Concept

Auto Scaling target tracking and instance warmup configuration

Question 165Question →

A SysOps Administrator is managing an Amazon EC2 Auto Scaling group where the instances are launched with standard monitoring enabled by default. To react to sudden load spikes, the administrator configures an Amazon CloudWatch alarm to trigger a scale-out policy. The alarm is defined with the CPUUtilization metric, a period of 60 seconds (1 minute), and evaluation periods set to 3. During a load test, the actual CPU utilization on the instances stays at 90% for 15 minutes, but the alarm remains in the INSUFFICIENT_DATA state and fails to trigger the scaling policy. Which of the following is the root cause of this behavior?

With standard monitoring enabled, Amazon EC2 metrics are only generated and sent to CloudWatch at 5-minute intervals, meaning there are no 1-minute data points available for the alarm to evaluate.

Standard monitoring collects CPU utilization data at 1-minute intervals but only publishes the aggregated data to CloudWatch once every 5 minutes, causing a delay in the alarm evaluation.

The Auto Scaling group is currently within a scale-out cooldown period, which automatically suspends CloudWatch metric evaluation and forces associated alarms into the INSUFFICIENT_DATA state.

The CloudWatch alarm is attempting to send the state change notification directly to the Auto Scaling group via an Amazon SQS queue, which is not a supported event flow target for Auto Scaling remediation.

Show answer & explanation

Answer: With standard monitoring enabled, Amazon EC2 metrics are only generated and sent to CloudWatch at 5-minute intervals, meaning there are no 1-minute data points available for the alarm to evaluate.

Answer

With standard monitoring enabled, Amazon EC2 metrics are only generated and sent to CloudWatch at 5-minute intervals, meaning there are no 1-minute data points available for the alarm to evaluate.

The correct answer is that with standard monitoring enabled, Amazon EC2 metrics are only generated and sent to CloudWatch at 5-minute intervals, meaning there are no 1-minute data points available for the alarm to evaluate. In standard monitoring, metric data is sent to CloudWatch at 5-minute intervals. If an alarm is configured with a 1-minute period, it expects metric data every 1 minute. Without detailed monitoring enabled, the lack of 1-minute data points causes the alarm to remain in the INSUFFICIENT_DATA state.

Step-by-Step Solution

Analyze the monitoring configuration of the EC2 instances.

The instances have standard monitoring enabled, which collects and reports metrics at 5-minute intervals.

To understand the frequency at which CloudWatch receives data points for the CPUUtilization metric.

Review the alarm configuration parameters.

The alarm is configured with a period of 60 seconds (1 minute) and requires 3 evaluation periods.

To determine what data points the alarm expects in order to perform an evaluation.

Evaluate the state transition logic under the current metric frequency.

Because CloudWatch only receives data points every 5 minutes, there are no consecutive 1-minute data points to satisfy the 3-minute evaluation window, keeping the alarm in the INSUFFICIENT_DATA state.

To identify why the alarm failed to transition to the ALARM state despite the actual CPU utilization being high.

Key Concept

CloudWatch Standard vs Detailed Monitoring Intervals

Estimated Time:2m 0s

Question 166Question →

A company runs a web application on Amazon EC2 instances managed by an Auto Scaling group. The group is configured with a target tracking scaling policy based on the `ASGAverageCPUUtilization` metric with a target value of $60\%$ . During sudden traffic spikes, the Auto Scaling group launches new instances to handle the load. However, the newly launched instances require approximately $5$ minutes to download application packages, run bootstrapping scripts, and begin processing requests. During this startup period, the Auto Scaling group continues to launch additional instances, resulting in significant overprovisioning and high costs. Which action should the SysOps administrator take to prevent this overprovisioning?

Increase the default cooldown period of the Auto Scaling group to

300

seconds.

Enable detailed monitoring on the Amazon EC2 launch template to increase the CloudWatch metric granularity to

1

-minute intervals.

Increase the estimated instance warmup time in the target tracking scaling policy to

300

seconds.

Configure an Amazon EC2 Auto Scaling lifecycle hook to keep the new instances in the `Pending:Wait` state for

5

minutes.

Show answer & explanation

Answer: Increase the estimated instance warmup time in the target tracking scaling policy to $300$ seconds.

Answer

Increase the estimated instance warmup time in the target tracking scaling policy to

300

seconds.

Increasing the estimated instance warmup time to

300

seconds is correct because target tracking scaling policies ignore the default cooldown period of the Auto Scaling group and rely entirely on the estimated instance warmup. Setting this warmup period to match the

5

-minute bootstrapping time ensures that the group waits for new instances to start processing traffic and contributing to metrics before evaluating whether to scale out again.

Step-by-Step Solution

Identify the type of scaling policy in use and how it handles new instance metrics.

The Auto Scaling group uses a target tracking scaling policy, which relies on the estimated instance warmup parameter.

Target tracking policies ignore the default cooldown period of the Auto Scaling group and rely on instance warmup to determine when new instances should contribute to metric calculations.

Analyze the impact of the bootstrapping delay on the scaling metrics.

The newly launched instances take

5

minutes (

300

seconds) to become ready. During this time, average CPU utilization remains high because the new instances are not yet handling load.

If the estimated instance warmup is shorter than

5

minutes, the policy assumes the new instances are fully warmed up and incorrectly concludes that more capacity is needed, leading to overscaling.

Adjust the scaling configuration to match the bootstrapping time.

Setting the estimated instance warmup to

300

seconds (

5

minutes) prevents the policy from triggering additional launches until the newly launched instances have finished bootstrapping.

This aligns the scaling policy's metric evaluation delay with the actual initialization time of the instances.

Key Concept

Instance warmup configuration in EC2 Auto Scaling target tracking policies

Estimated Time:1m 30s

Question 167Question →

A SysOps administrator is configuring an Auto Scaling group (ASG) to deploy EC2 instances using a new launch template. The launch template specifies an IAM instance profile associated with the IAM role 'AppExecutionRole'. During a scale-out event, the ASG fails to launch new instances. The ASG activity history shows the following error:

'Launching a new EC2 instance failed. Status Reason: User: arn:aws:iam::123456789012:user/SysOpsAdmin is not authorized to perform: iam:PassRole on resource: arn:aws:iam::123456789012:role/AppExecutionRole'

Which action must the administrator take to successfully launch the instances?

Attach an IAM policy to the SysOpsAdmin user that grants the iam:PassRole permission for the AppExecutionRole resource.

Modify the trust policy of the AppExecutionRole to allow the autoscaling.amazonaws.com service principal to perform sts:AssumeRole.

Increase the default cooldown period of the Auto Scaling group to allow the IAM role propagation to complete before the next launch attempt.

Enable detailed monitoring in the launch template to reduce the time required for CloudWatch to verify the authorization status of the instance profile.

Show answer & explanation

Answer: Attach an IAM policy to the SysOpsAdmin user that grants the iam:PassRole permission for the AppExecutionRole resource.

Answer

Attach an IAM policy to the SysOpsAdmin user that grants the iam:PassRole permission for the AppExecutionRole resource.

The correct action is to attach an IAM policy to the SysOpsAdmin user that grants the iam:PassRole permission for the AppExecutionRole resource. This permission is required when a user creates or updates an Auto Scaling group with a launch template containing an IAM instance profile, ensuring the user is authorized to pass the role to the EC2 instances being launched.

Step-by-Step Solution

Identify the cause of the failure from the activity history error message.

The message indicates that the user 'SysOpsAdmin' lacks the 'iam:PassRole' permission for the 'AppExecutionRole'.

When creating or updating an Auto Scaling group with a launch template that uses an IAM instance profile, AWS requires the calling user to have permission to pass that role to the EC2 service.

Create or modify an IAM policy for the SysOpsAdmin user.

An IAM policy is created containing the 'iam:PassRole' action targeted at the Amazon Resource Name (ARN) of the AppExecutionRole.

This policy explicitly authorizes the SysOpsAdmin user to delegate the role to EC2 instances launched under their configuration.

Apply the policy to the SysOpsAdmin IAM user or group.

The permission is applied, allowing subsequent scale-out actions by the Auto Scaling group to succeed.

Applying the policy resolves the unauthorized status reason, enabling the Auto Scaling service to successfully launch instances with the defined profile.

Key Concept

IAM PassRole Permission in Auto Scaling Launch Templates

Estimated Time:2m 0s

Question 168Question →

A SysOps Administrator is designing an automated remediation workflow to restart a legacy service running on an Amazon EC2 instance. The restart must occur when a custom CloudWatch metric, FailureCount, exceeds a threshold of 5 failures within a 5-minute period. The administrator has already created a CloudWatch alarm that transitions to the ALARM state when this threshold is met. What is the correct and most efficient method to automatically trigger the service restart when the alarm enters the ALARM state?

Configure an Amazon EventBridge rule that detects CloudWatch Alarm State Change events for the specific alarm, and set the rule's target to an AWS Systems Manager Automation document that runs the restart command on the instance.

Configure the CloudWatch alarm's actions directly to invoke an AWS Systems Manager Automation document by specifying the document's ARN in the alarm notification settings.

Enable detailed monitoring on the EC2 instance and configure an AWS Config rule to monitor the FailureCount metric, setting its remediation target to the restart command.

Configure an Auto Scaling group lifecycle hook that triggers an SNS notification to restart the service, and set the scaling cooldown period to 0 seconds to ensure immediate execution.

Show answer & explanation

Answer: Configure an Amazon EventBridge rule that detects CloudWatch Alarm State Change events for the specific alarm, and set the rule's target to an AWS Systems Manager Automation document that runs the restart command on the instance.

Answer

The correct answer utilizes Amazon EventBridge to bridge the CloudWatch alarm state change event and the Systems Manager Automation document. Because CloudWatch alarms cannot directly invoke Systems Manager Automation or run scripts on EC2 instances, EventBridge is the standard and recommended service to route these operational state changes to SSM for automated remediation.

Step-by-Step Solution

Identify the capabilities and limitations of direct CloudWatch alarm actions.

Confirm that CloudWatch alarms cannot directly target SSM Automation or Run Commands.

This rules out direct configuration of SSM actions inside the CloudWatch alarm console.

Determine the integration path between CloudWatch alarms and Systems Manager remediation.

Use Amazon EventBridge to capture the 'CloudWatch Alarm State Change' event.

EventBridge acts as the event bus that routes state transitions to external targets like SSM.

Configure the EventBridge rule target to execute the reboot or restart task.

Select the target as the Systems Manager Automation document and pass the EC2 instance ID.

This executes the necessary operational task automatically on the target instance when the event triggers.

Key Concept

CloudWatch alarms cannot directly trigger Systems Manager Automation documents or Run Commands; an event-driven router like Amazon EventBridge is required to capture the Alarm State Change event and trigger the remediation document.

Estimated Time:1m 30s

Question 169Question →

A SysOps administrator wants to automatically stop any Amazon EC2 instance that is launched without a 'Project' tag. The administrator has created an Amazon EventBridge rule that detects when a new EC2 instance state changes to 'running'. Which target configuration and IAM permissions are required to successfully perform this remediation?

Configure the rule to target AWS Systems Manager Automation using the AWS-StopEC2Instance runbook, and associate the rule with an IAM service role that allows EventBridge to execute ssm:StartAutomationExecution.

Configure the rule to target AWS Systems Manager Run Command using the AWS-StopEC2Instance runbook, and associate the rule with an IAM service role that allows EventBridge to execute ssm:SendCommand.

Configure the rule to target AWS Systems Manager Automation using the AWS-StopEC2Instance runbook, but omit the IAM execution role since EventBridge has implicit permissions to run Systems Manager Automation.

Configure the rule to target AWS Systems Manager State Manager, and associate the rule with an IAM service role that allows EventBridge to execute ssm:CreateAssociation.

Show answer & explanation

Answer: Configure the rule to target AWS Systems Manager Automation using the AWS-StopEC2Instance runbook, and associate the rule with an IAM service role that allows EventBridge to execute ssm:StartAutomationExecution.

Answer

The correct option is configuring the rule to target AWS Systems Manager Automation using the AWS-StopEC2Instance runbook, and associating the rule with an IAM service role that allows EventBridge to execute ssm:StartAutomationExecution. Systems Manager Automation is designed for control-plane remediation tasks, such as stopping EC2 instances, and EventBridge requires an explicit IAM role with ssm:StartAutomationExecution permissions to invoke the target runbook.

Step-by-Step Solution

Identify the correct AWS Systems Manager feature for orchestrating remediation workflows.

AWS Systems Manager Automation is selected because it supports runbooks (like AWS-StopEC2Instance) designed for control-plane remediation.

Automation runbooks are used for multi-step workflows and AWS API tasks, whereas Run Command is for in-guest OS scripts.

Determine the required IAM authorization for EventBridge to invoke Systems Manager.

An IAM service role assumed by EventBridge with permissions to execute ssm:StartAutomationExecution is required.

EventBridge does not have implicit permissions to trigger targets and requires an explicit role to interact with other AWS services.

Key Concept

AWS Systems Manager Automation and Amazon EventBridge integration for automated remediation

Estimated Time:1m 0s

Question 170Question →

A SysOps Administrator needs to enable Amazon CloudWatch Container Insights to collect performance metrics from an existing Amazon Elastic Container Service (Amazon ECS) cluster. Which TWO actions can the SysOps Administrator take to enable Container Insights for this cluster? (Select TWO.)

Select all that apply

Run the AWS CLI command: aws ecs update-cluster-settings --cluster <cluster-name> --settings name=containerInsights,value=enabled

Update the cluster settings in the Amazon ECS console by modifying the cluster properties to turn on Container Insights.

Enable detailed 1-minute monitoring on all Amazon EC2 launch templates used by the ECS cluster Auto Scaling group.

Create an Amazon EventBridge rule that triggers an AWS Systems Manager Automation document to install the CloudWatch agent on each ECS container instance.

Configure a CloudWatch Logs log group for the ECS cluster and set the retention period to never expire.

Show answer & explanation

Answer: Run the AWS CLI command: aws ecs update-cluster-settings --cluster <cluster-name> --settings name=containerInsights,value=enabled; Update the cluster settings in the Amazon ECS console by modifying the cluster properties to turn on Container Insights.

Answer

To enable Amazon CloudWatch Container Insights on an existing Amazon ECS cluster, you can either execute the AWS CLI command `aws ecs update-cluster-settings` with the `containerInsights` setting enabled, or modify the cluster's settings directly within the Amazon ECS console.

To collect performance metrics at the container and task level for an existing ECS cluster, Container Insights must be enabled at the cluster level. This can be configured either visually by modifying the cluster properties within the Amazon ECS console, or programmatically by running the AWS CLI command `aws ecs update-cluster-settings` with the `name=containerInsights,value=enabled` settings parameter.

Step-by-Step Solution

Determine the correct AWS management tool (CLI or Console) to modify ECS cluster configurations.

Identify that ECS cluster properties can be updated via the `aws ecs update-cluster-settings` CLI command or through the Amazon ECS console.

Container Insights is a cluster-level setting that must be activated on the target ECS cluster.

Select the correct settings configuration for the chosen interface.

For CLI, use `--settings name=containerInsights,value=enabled`. For Console, select the cluster and toggle the Container Insights setting to enabled.

This updates the cluster metadata and instructs the Amazon ECS container agent to begin streaming container-level metrics to CloudWatch.

Key Concept

Configuring Container Insights for Amazon ECS clusters

Question 171Question →

An organization needs to automatically stop any Amazon EC2 instance that fails an AWS Config security compliance check. A SysOps administrator wants to route these compliance changes to a Systems Manager Automation document named AWS-StopEC2Instance to remediate the issue. Which two configuration actions are required to set up this automation pipeline?

Select all that apply

Configure an Amazon EventBridge rule with an event pattern matching AWS Config Compliance Change events, and set the target to the Systems Manager Automation document.

Create an IAM role with a trust policy for the EventBridge service principal (events.amazonaws.com) and a policy allowing the ssm:StartAutomationExecution action, then assign it to the EventBridge rule.

Configure an AWS Config remediation action directly within the AWS Config rule using the EventBridge event pattern as the target.

Create an IAM policy with sts:AssumeRole for the EC2 instance profile, and attach it to the EventBridge rule without configuring Systems Manager permissions.

Create a Systems Manager Event Rule within the Systems Manager console to poll AWS Config compliance logs stored in Amazon S3.

Show answer & explanation

Answer: Configure an Amazon EventBridge rule with an event pattern matching AWS Config Compliance Change events, and set the target to the Systems Manager Automation document.; Create an IAM role with a trust policy for the EventBridge service principal (events.amazonaws.com) and a policy allowing the ssm:StartAutomationExecution action, then assign it to the EventBridge rule.

Answer

To establish the automated remediation pipeline, you must configure an Amazon EventBridge rule matching AWS Config compliance changes targeting the Systems Manager Automation document, and assign an IAM role to the EventBridge rule allowing the ssm:StartAutomationExecution action.

Establishing this remediation pipeline requires two primary parts: defining the event routing and establishing the correct permissions. The event pattern matching AWS Config Compliance Change events correctly filters for non-compliant resources to trigger the target Automation document. The IAM role containing the trust relationship for the EventBridge service principal and the permission to start automation executions satisfies the access requirements.

Step-by-Step Solution

Configure the EventBridge Rule event pattern to capture compliance changes from AWS Config and set the target to the AWS-StopEC2Instance Automation document.

The EventBridge rule is set to trigger when an AWS Config compliance change event occurs.

This establishes the event detection and trigger pathway.

Create and assign an IAM execution role to the EventBridge rule that trusts events.amazonaws.com and permits ssm:StartAutomationExecution.

EventBridge has the authorization to call Systems Manager and start the remediation workflow.

EventBridge must have the security permissions to launch the target Automation document.

Key Concept

Automated remediation using Amazon EventBridge rules to trigger AWS Systems Manager Automation documents, requiring appropriate IAM execution permissions.

Question 172Question →

A SysOps Administrator is configuring a new organizational trail in AWS CloudTrail. The trail is configured to send logs to a central Amazon S3 bucket located in a dedicated logging account. The S3 bucket is encrypted using a customer managed key (CMK) in AWS Key Management Service (AWS KMS). After enabling the trail, the administrator notices that API activity is not being recorded in the S3 bucket, and CloudTrail reports log delivery errors. Which actions must the SysOps Administrator take to resolve this log delivery issue? (Select TWO.)

Select all that apply

Update the S3 bucket policy in the logging account to grant s3:PutObject permissions to the CloudTrail service principal (cloudtrail.amazonaws.com).

Update the KMS key policy to grant the CloudTrail service principal (cloudtrail.amazonaws.com) permissions to call kms:GenerateDataKey* and kms:DescribeKey on the CMK.

Attach an IAM policy to the CloudTrail service-linked role in the member accounts allowing s3:PutObject and kms:GenerateDataKey*.

Create an IAM policy for the SysOps Administrator role that allows kms:GenerateDataKey* and kms:Decrypt on the CMK.

Configure an Amazon EventBridge rule that triggers an AWS Systems Manager Automation runbook to replicate logs from the source accounts to the central S3 bucket.

Show answer & explanation

Answer: Update the S3 bucket policy in the logging account to grant s3:PutObject permissions to the CloudTrail service principal (cloudtrail.amazonaws.com).; Update the KMS key policy to grant the CloudTrail service principal (cloudtrail.amazonaws.com) permissions to call kms:GenerateDataKey* and kms:DescribeKey on the CMK.

Answer

Update the S3 bucket policy in the logging account to grant s3:PutObject permissions to the CloudTrail service principal, and update the KMS key policy to grant the CloudTrail service principal permissions to call kms:GenerateDataKey* and kms:DescribeKey on the CMK.

For CloudTrail to deliver logs successfully to a cross-account S3 bucket encrypted with a customer managed key, permissions must be granted to the CloudTrail service principal (cloudtrail.amazonaws.com) on both resource policies. The S3 bucket policy must allow the s3:PutObject action, and the KMS key policy must allow the kms:GenerateDataKey* and kms:DescribeKey actions so CloudTrail can encrypt the objects as they are delivered.

Step-by-Step Solution

Inspect the S3 bucket policy of the destination bucket in the logging account.

Ensure that the policy permits 'cloudtrail.amazonaws.com' to perform 's3:PutObject' for the correct resource path.

CloudTrail requires explicit bucket policy permissions to deliver logs across accounts to a central S3 bucket.

Inspect the KMS key policy for the customer managed key used to encrypt the S3 bucket.

Modify the key policy to allow the CloudTrail service principal ('cloudtrail.amazonaws.com') to call 'kms:GenerateDataKey*' and 'kms:DescribeKey'.

Since the bucket is encrypted with a customer managed key, CloudTrail needs permissions to generate the encryption keys needed to write the encrypted logs.

Key Concept

AWS CloudTrail requires permissions to write to destination S3 buckets and use associated KMS keys via resource-based policies (S3 bucket policy and KMS key policy) targeting its service principal.

Question 173Question →

A SysOps Administrator needs to create a single Amazon CloudWatch dashboard that displays CPU utilization metrics from Amazon EC2 instances running in both the us-east-1 and us-west-2 Regions. Which action should the administrator take to achieve this?

Select the desired Region from the Region selector when adding the CPU utilization metrics to the dashboard widgets.

Enable detailed monitoring on all EC2 instances to allow CloudWatch to aggregate metrics across different AWS Regions.

Configure an Amazon EventBridge rule in the us-west-2 Region to route the CPU utilization metrics to the us-east-1 Region.

Create a CloudWatch metric filter in us-west-2 to stream the metric logs to an Amazon Kinesis Data Firehose delivery stream in us-east-1.

Show answer & explanation

Answer: Select the desired Region from the Region selector when adding the CPU utilization metrics to the dashboard widgets.

Answer

Select the desired Region from the Region selector when adding the CPU utilization metrics to the dashboard widgets.

The correct option is to select the desired Region from the Region selector when configuring the metrics in the dashboard. CloudWatch dashboards support multi-region metric visualization natively, allowing administrators to combine metrics from different Regions on a single screen without complex configurations.

Step-by-Step Solution

Open the Amazon CloudWatch console and create or open a dashboard.

The dashboard workspace is loaded.

To begin configuring widgets that will display the metrics.

Add a new widget (such as a line chart) and select the EC2 namespace.

The metric selection interface appears.

To browse and choose the specific CPU utilization metrics.

Use the Region drop-down selector within the metric selection screen to switch between us-east-1 and us-west-2, selecting the metrics from both Regions.

Metrics from both Regions are added to the single widget.

CloudWatch dashboards natively support displaying metrics from multiple AWS Regions in the same widget or dashboard by selecting the appropriate Region during metric configuration.

Key Concept

CloudWatch dashboards are global resources that can display metrics from multiple AWS Regions. You can select different Regions directly from the Region selector when adding metrics to dashboard widgets.

Question 174Question →

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

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.

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.

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.

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.

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 175Question →

An Amazon EC2 Auto Scaling group (ASG) is experiencing delayed scaling responses during sudden spikes in application traffic. A SysOps administrator notices that it takes up to 5 minutes for the ASG to trigger a scale-out action based on the average CPU utilization metric. Which two configuration updates should the administrator perform to reduce this scaling delay? (Select TWO.)

Select all that apply

Enable detailed monitoring in the launch template used by the Auto Scaling group.

Decrease the period of the CloudWatch alarm that triggers the scaling policy to 1 minute.

Increase the default instance cooldown period in the Auto Scaling group configuration.

Enable Auto Scaling group group-level metrics collection with 1-minute granularity in the group settings.

Attach an IAM policy with the iam:PassRole permission to the Auto Scaling group's IAM role.

Show answer & explanation

Answer: Enable detailed monitoring in the launch template used by the Auto Scaling group.; Decrease the period of the CloudWatch alarm that triggers the scaling policy to 1 minute.

Answer

To reduce the scaling delay, enable detailed monitoring in the launch template used by the Auto Scaling group and decrease the period of the CloudWatch alarm that triggers the scaling policy to 1 minute.

To resolve the 5-minute scaling delay, both the metric reporting frequency and the alarm evaluation window must be updated. Enabling detailed monitoring in the launch template changes the EC2 metric reporting interval from 5 minutes to 1 minute. Decreasing the CloudWatch alarm period to 1 minute ensures that the alarm evaluates these high-frequency metrics promptly to trigger the scale-out policy.

Step-by-Step Solution

Enable detailed monitoring for instances.

EC2 instance CPU utilization metrics are sent to CloudWatch every 1 minute instead of the standard 5 minutes.

This provides high-resolution data points required to detect rapid load spikes quickly.

Adjust the triggering CloudWatch alarm period.

The alarm evaluates the metrics at 1-minute intervals.

This allows the alarm to trigger the scale-out policy immediately upon detecting the threshold breach, rather than waiting for 5 minutes.

Key Concept

Auto Scaling responsiveness depends on both the metric reporting frequency (detailed monitoring) and the alarm evaluation period.

Question 176Question →

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

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.

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.

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.

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.

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.

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 177Question →

A SysOps administrator wants to automate the remediation of Amazon S3 buckets that are accidentally configured with public write permissions. The administrator creates an Amazon EventBridge rule that triggers when a PutBucketPolicy API call is logged in AWS CloudTrail. The target of this rule is the AWS Systems Manager Automation document AWS-DisableS3BucketPublicWrite. When testing the setup by making a bucket public, the remediation fails to execute. Which configuration action is required to resolve this issue?

Attach the iam:PassRole permission to the EventBridge IAM role to allow it to pass the Systems Manager execution role to the Systems Manager service.

Modify the trust relationship of the EventBridge execution role to allow sts:AssumeRole to the S3 service, which removes the need for any role-passing permissions.

Reconfigure the EventBridge rule to send the CloudTrail event to an Amazon SNS topic, which can directly trigger the Systems Manager Automation document.

Enable detailed monitoring on the S3 bucket to increase the CloudTrail event logging frequency so that EventBridge can detect the changes.

Show answer & explanation

Answer: Attach the iam:PassRole permission to the EventBridge IAM role to allow it to pass the Systems Manager execution role to the Systems Manager service.

Answer

Attach the iam:PassRole permission to the EventBridge IAM role to allow it to pass the Systems Manager execution role to the Systems Manager service.

The correct action is to attach the iam:PassRole permission to the EventBridge IAM role. When EventBridge initiates a Systems Manager Automation document that runs with an execution role, it must pass that role to Systems Manager. Without the iam:PassRole permission, the operation fails authorization and the automation fails to start.

Step-by-Step Solution

Identify the authorization requirements between services.

EventBridge requires permissions to start the Systems Manager Automation and to pass the execution role to Systems Manager.

When configuring AWS services to perform actions on your behalf using specific roles, the calling service must be granted the permission to pass the role.

Update the IAM policy for the EventBridge execution role.

The iam:PassRole permission is added to the EventBridge service role targeting the Systems Manager automation role.

This allows the EventBridge service to delegate execution rights to Systems Manager, enabling the remediation workflow to start successfully.

Key Concept

IAM PassRole requirement for service-to-service automation triggering

Question 178Question →

A SysOps Administrator is using the AWS CLI to configure an existing AWS CloudTrail trail to send log events to an Amazon CloudWatch Logs log group. The administrator has already created the target log group and an IAM role named CloudTrail-Delivery-Role that includes the required permissions for CloudWatch Logs. However, when running the aws cloudtrail update-trail command to associate the role and log group with the trail, the CLI returns an AccessDeniedException error.

Which action should the administrator take to resolve this error?

Modify the trust policy of the CloudTrail-Delivery-Role to trust the cloudtrail.amazonaws.com service principal and allow the sts:AssumeRole action.

Attach an IAM policy to the administrator's IAM user that grants the iam:PassRole permission for the CloudTrail-Delivery-Role resource.

Add a statement to the S3 bucket policy of the logging bucket to allow cloudtrail.amazonaws.com to perform the sts:AssumeRole action.

Configure an Amazon EventBridge rule that triggers an AWS Systems Manager Automation runbook to automatically grant CloudTrail access to the log group.

Show answer & explanation

Answer: Attach an IAM policy to the administrator's IAM user that grants the iam:PassRole permission for the CloudTrail-Delivery-Role resource.

Answer

Attach an IAM policy to the administrator's IAM user that grants the iam:PassRole permission for the CloudTrail-Delivery-Role resource.

To associate an IAM role with an AWS service (such as CloudTrail) via the AWS CLI or API, the IAM entity executing the configuration command must have the iam:PassRole permission for that specific role. If this permission is missing, the AWS API returns an AccessDeniedException during the setup configuration.

Step-by-Step Solution

Analyze the error context: The AccessDeniedException occurs during the execution of the update-trail command, which is a configuration-time operation rather than a runtime log delivery failure.

The error must be resolved by granting permissions to the IAM identity executing the CLI command.

The CLI user must have authority to assign the IAM role to CloudTrail.

Identify the required IAM permission for role delegation: When configuring an AWS service to act on behalf of a user, the user must have the iam:PassRole permission.

Confirming that iam:PassRole is required for the role ARN.

This security measure prevents users from passing highly privileged roles to services to escalate their own permissions.

Formulate the correct IAM policy statement: Create an IAM policy allowing iam:PassRole on the CloudTrail-Delivery-Role ARN and attach it to the administrator's user or group.

The CLI command succeeds after the policy is applied.

Providing the necessary delegation permission allows the configuration call to be authorized.

Key Concept

IAM role delegation via iam:PassRole during CloudTrail CloudWatch Logs configuration

Estimated Time:1m 30s

Question 179Question →

A company is designing a pilot light disaster recovery (DR) strategy for a critical application. The business requires a Recovery Time Objective (RTO) of 15 minutes and a Recovery Point Objective (RPO) of 5 minutes. The application database runs on Amazon RDS, and static assets are stored in Amazon S3. Which configuration should a SysOps administrator implement to meet these DR requirements?

Enable versioning on both the source and destination S3 buckets to configure S3 Cross-Region Replication (CRR) for static assets, and deploy a cross-region RDS Read Replica for database replication.

Configure Amazon RDS Multi-AZ across regions to automatically failover the database to the secondary region within the 15-minute RTO, and enable S3 Cross-Region Replication (CRR) with versioning.

Configure S3 Cross-Region Replication (CRR) for the static asset bucket to meet the RPO, keeping versioning disabled on both buckets to minimize storage costs.

Deploy a cross-region RDS Read Replica for database replication, and use Amazon Route 53 with a simple routing policy to automatically route user traffic to the secondary region when health checks fail.

Show answer & explanation

Answer: Enable versioning on both the source and destination S3 buckets to configure S3 Cross-Region Replication (CRR) for static assets, and deploy a cross-region RDS Read Replica for database replication.

Answer

Enable versioning on both the source and destination S3 buckets to configure S3 Cross-Region Replication (CRR) for static assets, and deploy a cross-region RDS Read Replica for database replication.

The correct configuration combines S3 Cross-Region Replication (CRR) for static assets and an RDS Read Replica for database replication. S3 CRR requires versioning to be enabled on both the source and destination buckets. An RDS Read Replica provides asynchronous replication to a secondary region and can be promoted to a standalone database during a disaster, meeting the low RTO and RPO requirements.

Step-by-Step Solution

Identify the requirements for replicating database transactions across regions within the RPO and RTO.

Determine that a cross-region RDS Read Replica is suitable, as replication lag is minimal and it can be promoted quickly.

RDS Multi-AZ is restricted to a single region and cannot be used for cross-region disaster recovery.

Identify the requirements for replicating static assets in S3 to a secondary region.

Determine that S3 Cross-Region Replication (CRR) is required, which mandates enabling bucket versioning on both the source and destination buckets.

S3 replication fails to configure if versioning is disabled on either the source or destination bucket.

Select the configuration that correctly combines these two valid mechanisms.

The configuration using versioned S3 CRR and a cross-region RDS Read Replica satisfies both the RTO/RPO targets and service requirements.

This combination avoids invalid configurations like cross-region Multi-AZ or non-versioned S3 replication.

Key Concept

Implementing cross-region disaster recovery using S3 Cross-Region Replication (requiring versioning) and RDS Read Replicas.

Estimated Time:1m 0s

Question 180Question →

A SysOps Administrator is configuring automatic remediation for a custom AWS Config rule that checks whether Amazon EBS volumes are encrypted. The remediation is configured to use the AWS-EncryptVolume Systems Manager (SSM) Automation document. The administrator has created an IAM role named EbsRemediationRole to perform the remediation. However, when AWS Config detects a non-compliant volume, the automatic remediation fails to execute, and a permissions error is displayed in the AWS Config console. Which of the following configuration changes must the administrator make to resolve this issue and allow the remediation to run successfully? (Select TWO.)

Select all that apply

Add the iam:PassRole permission to the administrator's IAM identity policy, specifying EbsRemediationRole as the resource.

Configure the trust policy of EbsRemediationRole to allow the ssm.amazonaws.com service principal to perform the sts:AssumeRole action.

Add the sts:AssumeRole permission to the administrator's IAM policy, and configure the trust policy of EbsRemediationRole to trust the administrator's IAM identity.

Modify the trust policy of EbsRemediationRole to allow the config.amazonaws.com service principal to perform the sts:AssumeRole action.

Create an Amazon EventBridge rule that triggers on AWS Config non-compliant evaluation events and set the target of the rule directly to the EBS volume.

Configure an Amazon EventBridge rule to intercept AWS Config compliance changes and trigger a Systems Manager Run Command execution to run the encryption script on the target volume.

Show answer & explanation

Answer: Add the iam:PassRole permission to the administrator's IAM identity policy, specifying EbsRemediationRole as the resource.; Configure the trust policy of EbsRemediationRole to allow the ssm.amazonaws.com service principal to perform the sts:AssumeRole action.

Answer

To resolve the permissions error and successfully run the automatic remediation, the administrator must add the iam:PassRole permission to their own IAM policy for the EbsRemediationRole, and configure the trust policy of EbsRemediationRole to allow the ssm.amazonaws.com service principal to assume the role.

The correct actions require ensuring the correct service principal (ssm.amazonaws.com) can assume the remediation role, and the administrator has the iam:PassRole permission to pass that role to the service. When AWS Config triggers remediation via SSM Automation, it passes the specified role to the Systems Manager service. This operation requires the configuring user to have the iam:PassRole permission for the role. The SSM service must then assume this role to perform actions on the resources, which requires a trust relationship allowing ssm.amazonaws.com to perform sts:AssumeRole.

Step-by-Step Solution

Analyze the execution path of the AWS Config remediation.

AWS Config triggers Systems Manager Automation to run the AWS-EncryptVolume document, passing the EbsRemediationRole as the execution role.

Understanding the path helps identify which service is assuming the role and which identity is passing it.

Verify user/administrator permissions for configuration.

The identity configuring the remediation requires the iam:PassRole permission for the EbsRemediationRole.

AWS Config requires the configuring user to have iam:PassRole to delegate authority to Systems Manager.

Verify the trust policy of the remediation role.

The EbsRemediationRole must trust ssm.amazonaws.com.

Since Systems Manager Automation executes the document, it must be allowed to assume the role using sts:AssumeRole.

Key Concept

AWS Config remediation requires proper iam:PassRole permissions for the administrator to delegate the execution role, and the execution role must trust the ssm.amazonaws.com service principal.

PreviousPage 9 / 49Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept