All practice questions

976 questions

All types976 Multiple choice502 Multiple select450 Ordering24

A company implements automated compliance monitoring. An AWS Config rule named restricted-ssh is configured to evaluate security groups. When a security group is flagged as non-compliant, an Amazon EventBridge rule detects the compliance change and targets a Systems Manager Automation runbook named AWS-CloseSecurityGroup to close port 22.

The configuration details are as follows:
- The EventBridge rule uses an Input Transformer to map the non-compliant security group ID to the runbook's GroupId parameter.
- A dedicated IAM role named RemediationExecutionRole exists with a trust policy for ssm.amazonaws.com and permissions to modify EC2 security groups.
- The EventBridge rule is configured with an IAM service role named EventBridgeTargetRole that trusts events.amazonaws.com and has permissions to execute ssm:StartAutomationExecution on the runbook.

When the EventBridge rule is triggered, the Systems Manager Automation execution fails to start. Which of the following is the correct configuration change to resolve this issue?

Add the iam:PassRole permission for the RemediationExecutionRole to the EventBridgeTargetRole policy, and specify the RemediationExecutionRole ARN as the AutomationAssumeRole parameter in the EventBridge target input template.

Modify the trust policy of the RemediationExecutionRole to trust events.amazonaws.com, and add the iam:PassRole permission for the EventBridgeTargetRole to the RemediationExecutionRole policy.

Add the iam:PassRole permission for the EventBridgeTargetRole to the policy attached to the RemediationExecutionRole, and modify the trust policy of the EventBridgeTargetRole to trust ssm.amazonaws.com.

Change the EventBridge rule target from Systems Manager Automation to Systems Manager Run Command, and associate the RemediationExecutionRole with the EC2 instances directly.

Show answer & explanation

Answer: Add the iam:PassRole permission for the RemediationExecutionRole to the EventBridgeTargetRole policy, and specify the RemediationExecutionRole ARN as the AutomationAssumeRole parameter in the EventBridge target input template.

Answer

The correct configuration change is to add the iam:PassRole permission to the EventBridgeTargetRole policy for the RemediationExecutionRole, and configure the AutomationAssumeRole parameter. For EventBridge to successfully initiate a Systems Manager Automation execution that utilizes a specific service role (RemediationExecutionRole), the principal calling the ssm:StartAutomationExecution API (EventBridgeTargetRole) must have authorization to pass the role. This is achieved via iam:PassRole. Additionally, specifying AutomationAssumeRole in the parameters tells Systems Manager to assume this role when executing.

Step-by-Step Solution

Verify the role that invokes the Systems Manager Automation runbook from Amazon EventBridge.

The EventBridge rule is associated with EventBridgeTargetRole, which has trust relationships for events.amazonaws.com and permission for ssm:StartAutomationExecution.

EventBridge needs these permissions to trigger the target runbook when the event pattern matches.

Configure delegation for the automation execution role.

The EventBridgeTargetRole must be granted the iam:PassRole permission for the RemediationExecutionRole.

When triggering an automation that specifies an execution role (AutomationAssumeRole), the calling entity (EventBridge) must have the authority to pass that role to the Systems Manager service.

Pass the execution role parameter in the EventBridge target configuration.

The input transformer template must include the AutomationAssumeRole parameter set to the ARN of the RemediationExecutionRole.

This tells Systems Manager which role to assume when executing the runbook steps to close the security group rules.

Key Concept

To execute automated remediation using Systems Manager Automation triggered by EventBridge, the EventBridge invocation role must have iam:PassRole permissions for the Systems Manager Automation execution role.

Question 202Question →

A SysOps Administrator is managing an Amazon EC2 Auto Scaling group and configures a dynamic scaling policy to scale out when average CPU utilization exceeds 75%. The administrator sets up a CloudWatch metric alarm to monitor the CPUUtilization metric with a period of 60 seconds and an evaluation period of 3 consecutive data points. During a load testing phase, traffic is increased, but the scaling policy fails to trigger within the expected 3-minute window, even though the actual CPU load is sustained above 80% on all instances. Which of the following is the most likely cause of this issue?

An Amazon EventBridge rule has not been configured to route the ALARM state change event from CloudWatch to the Auto Scaling dynamic scaling policy.

The SysOps Administrator failed to enable detailed monitoring within the CloudWatch console's alarm configuration settings.

The EC2 instances in the Auto Scaling group are using standard monitoring, which publishes CPU utilization metrics to CloudWatch at 5-minute intervals.

The Auto Scaling group's cooldown period is shorter than the 3-minute alarm evaluation window, which causes the scaling action to be ignored.

Show answer & explanation

Answer: The EC2 instances in the Auto Scaling group are using standard monitoring, which publishes CPU utilization metrics to CloudWatch at 5-minute intervals.

Answer

The EC2 instances in the Auto Scaling group are using standard monitoring, which publishes CPU utilization metrics to CloudWatch at 5-minute intervals.

The correct answer is that the instances are using standard monitoring. Because standard monitoring only publishes metrics to CloudWatch every 5 minutes, a CloudWatch alarm with a 1-minute period will not receive new metric values each minute. Consequently, the alarm cannot gather the 3 consecutive 1-minute data points required to transition to the ALARM state within the expected 3 minutes.

Step-by-Step Solution

Analyze the configured evaluation criteria of the CloudWatch alarm.

The alarm is configured with a period of 60 seconds and requires 3 consecutive periods, resulting in a minimum evaluation window of 3 minutes.

This establishes the minimum time window required for the alarm to change state.

Examine the default metric delivery intervals for Amazon EC2 instances.

Under standard monitoring, EC2 instances send metrics to CloudWatch at a 5-minute interval.

This determines how frequently new data points are published to the metric stream.

Determine the impact of the monitoring frequency on the alarm's evaluation window.

With standard monitoring, CloudWatch only receives new metrics every 5 minutes. The 1-minute alarm cannot collect 3 consecutive 1-minute data points in a 3-minute span because the data points do not exist yet, preventing the alarm from triggering within 3 minutes.

This explains why the alarm did not trigger within the expected 3 minutes.

Key Concept

Standard versus detailed monitoring intervals and their impact on CloudWatch metric alarm evaluations.

Question 203Question →

An Amazon EC2 Auto Scaling group (ASG) is registered with an Application Load Balancer (ALB). The ASG has a minimum size of 3, a desired capacity of 3, and a maximum size of 5. To troubleshoot a database connectivity issue, a SysOps administrator temporarily suspends the Launch process for the ASG. Shortly after, one of the three EC2 instances fails its ALB health check and is marked unhealthy.

What will happen to the unhealthy instance and the capacity of the Auto Scaling group?

The Auto Scaling group will leave the unhealthy instance running and take no action until the Launch process is resumed.

The Auto Scaling group will terminate the unhealthy instance, leaving the group with 2 running instances, and will not launch a replacement.

The Auto Scaling group will automatically resume the Launch process to maintain the minimum capacity of 3 and then replace the instance.

The Auto Scaling group will wait for the scale-in cooldown period to expire before terminating the instance and launching a replacement.

Show answer & explanation

Answer: The Auto Scaling group will terminate the unhealthy instance, leaving the group with 2 running instances, and will not launch a replacement.

Answer

The Auto Scaling group will terminate the unhealthy instance, leaving the group with 2 running instances, and will not launch a replacement.

The correct answer is that the Auto Scaling group will terminate the unhealthy instance, leaving the group with 2 running instances, and will not launch a replacement. When the Launch process is suspended, the ReplaceUnhealthy process is still allowed to terminate instances that fail health checks, but it cannot launch new ones to replace them. This can temporarily reduce the capacity of the Auto Scaling group below its minimum size limit.

Step-by-Step Solution

Identify the active and suspended processes in the Auto Scaling group.

The Launch process is suspended, but other processes like Terminate and ReplaceUnhealthy remain active.

Suspending a specific process only pauses actions associated with that process; other processes continue to run normally unless they explicitly depend on the suspended process.

Determine how the ReplaceUnhealthy process behaves when an instance fails health checks.

The ReplaceUnhealthy process will proceed to terminate the unhealthy instance.

The termination phase of health check replacement does not require the Launch process to be active.

Determine how the suspended Launch process affects the replacement step.

No replacement instance is launched, resulting in a net loss of one instance.

Launching a replacement instance requires the Launch process. Because it is suspended, the Auto Scaling group cannot launch a new instance, even though the group size falls below the minimum limit of 3.

Key Concept

Auto Scaling Process Suspension Behavior

Estimated Time:1m 30s

Question 204Question →

A SysOps Administrator is managing an Amazon RDS for MySQL DB instance. To prepare for potential Availability Zone failures, the database must be configured to support automated failover to a standby instance in a different Availability Zone with minimal downtime. Which configuration change will meet these requirements?

Create an RDS Read Replica in a different Availability Zone and configure Amazon Route 53 to automatically promote it during an outage.

Configure an Amazon Route 53 active-active failover routing policy to distribute traffic between the primary database and a read replica.

Modify the RDS DB instance to a Multi-AZ DB deployment to enable automatic failover to a synchronous standby replica.

Deploy an Amazon Aurora Read Replica in a different Availability Zone and configure AWS Database Migration Service (AWS DMS) to handle the failover.

Show answer & explanation

Answer: Modify the RDS DB instance to a Multi-AZ DB deployment to enable automatic failover to a synchronous standby replica.

Answer

Modify the RDS DB instance to a Multi-AZ DB deployment to enable automatic failover to a synchronous standby replica.

Enabling Multi-AZ on an Amazon RDS instance automatically provisions and maintains a synchronous standby replica in a different Availability Zone. In the event of an AZ outage or primary instance failure, Amazon RDS automatically performs a failover by updating the DNS record of the DB instance to point to the standby instance, resulting in minimal downtime without requiring manual administrator action.

Step-by-Step Solution

Identify the high availability requirement.

The requirement specifies automated failover to a standby instance in a different Availability Zone with minimal downtime.

This establishes that the solution must provide synchronous replication and automated DNS failover within the same AWS Region.

Evaluate Amazon RDS high availability features.

Amazon RDS Multi-AZ deployments provide synchronous replication, automated failover detection, and automatic DNS endpoint redirection to the standby replica.

Multi-AZ is the native AWS mechanism designed to handle AZ outages seamlessly.

Eliminate alternative configurations that do not support automated failover.

Read replicas use asynchronous replication and require manual promotion. Route 53 cannot automate DB replica promotions, and AWS DMS is for data migration rather than native DB failover.

This confirms that Multi-AZ is the only valid option for synchronous, automated failover.

Key Concept

Amazon RDS Multi-AZ Deployments

Question 205Question →

A SysOps Administrator is managing a critical reporting application that requires high availability and multi-Region disaster recovery. The database layer consists of an Amazon RDS for MySQL DB instance in us-east-1 configured with Multi-AZ, and a cross-Region read replica in us-west-2. The administrator wants to configure Amazon Route 53 DNS Failover to automatically route write traffic to the database in us-west-2 if us-east-1 experiences a complete regional outage. Which approach will achieve this objective while ensuring the database can accept write operations after failover?

Configure a Route 53 Failover routing policy with the primary record pointing to the primary DB instance endpoint and the secondary record pointing directly to the read replica endpoint. Rely on Amazon Route 53 health checks to redirect write traffic to the replica, which will automatically begin accepting write operations.

Configure a Route 53 Failover routing policy with the primary record pointing to the primary DB instance endpoint and the secondary record pointing to the promoted DB instance endpoint. Deploy an AWS Lambda function triggered by Amazon Route 53 health check alarms to promote the read replica in the secondary Region to a standalone DB instance during an outage.

Configure Route 53 Weighted routing records with equal weights pointing to both the primary DB instance in the primary Region and the read replica in the secondary Region. Enable Route 53 health checks on both records to automatically shift write traffic to the secondary Region if the primary instance becomes unhealthy.

Modify the RDS DB instance configuration to enable Multi-AZ replication targeting a standby replica in the secondary Region. Configure Route 53 with a Latency routing policy so that client write requests are automatically routed to the active replica with the lowest network latency.

Show answer & explanation

Answer: Configure a Route 53 Failover routing policy with the primary record pointing to the primary DB instance endpoint and the secondary record pointing to the promoted DB instance endpoint. Deploy an AWS Lambda function triggered by Amazon Route 53 health check alarms to promote the read replica in the secondary Region to a standalone DB instance during an outage.

Answer

Configure a Route 53 Failover routing policy with the primary record pointing to the primary DB instance endpoint and the secondary record pointing to the promoted DB instance endpoint, and deploy an AWS Lambda function triggered by Route 53 health check alarms to promote the read replica in the secondary Region during an outage.

The correct approach involves configuring a Route 53 Failover routing policy to manage the DNS switchover and using an AWS Lambda function triggered by Route 53 health check alarms to promote the cross-Region read replica to a standalone DB instance. Because cross-Region read replicas use asynchronous replication and are read-only, Route 53 alone cannot enable write operations on the secondary DB; the database replica must be promoted to standalone status via the AWS API to begin accepting writes.

Step-by-Step Solution

Determine the capabilities of RDS cross-Region read replicas.

Confirm that cross-Region read replicas are read-only and do not support automatic failover or promotion.

This establishes that manual or automated promotion is mandatory to accept writes in the disaster recovery Region.

Select the appropriate Route 53 routing policy for disaster recovery.

Identify that a Failover (Active-Passive) routing policy is required to direct traffic to the secondary endpoint only during primary regional failure.

Active-Active configurations (such as Weighted) are inappropriate for read-only database replicas.

Identify the mechanism required to promote the replica.

Utilize AWS Lambda triggered by Amazon Route 53 health check alarms to execute the PromoteReadReplica API call for the replica in the secondary Region.

Amazon Route 53 only handles DNS resolution and cannot perform RDS control-plane operations like promoting a DB instance.

Design the endpoint configuration for Route 53 DNS records.

Configure the secondary CNAME record to point to the endpoint of the promoted standalone database instance.

This ensures client applications resolve the correct, writeable database endpoint after the automated promotion completes.

Key Concept

Automating Multi-Region database failover requires active-passive Route 53 DNS routing and automated replica promotion using AWS SDK or Lambda, because cross-Region read replicas are read-only and do not promote automatically.

Estimated Time:3m 0s

Question 206Question →

A SysOps Administrator is troubleshooting a network connectivity issue where external clients cannot connect to a web server running on an Amazon EC2 instance. The web server's Security Group allows inbound TCP port 80 from all sources and allows all outbound traffic. The subnet's Network ACL (NACL) allows inbound TCP port 80 from all sources, but the outbound NACL rules have been modified to deny all traffic. To analyze this, the administrator enables VPC Flow Logs. Additionally, the administrator wants to configure the destination CloudWatch Logs group to minimize costs and automatically alert the operations team if the number of rejected packets exceeds a threshold. Which two of the following statements correctly describe the behavior of the flow logs or the configuration required to meet these monitoring and cost requirements? (Select TWO.)

Select all that apply

The flow logs will record an ACCEPT status for the inbound traffic on port 80, and a REJECT status for the outbound response traffic.

The CloudWatch Log Group must be configured with a retention policy to automatically expire older events, and a metric filter must be created to track REJECT records.

The flow logs will record a REJECT status for the inbound traffic on port 80 because security groups are stateless and evaluate return paths before accepting a connection.

The alerts must be configured by creating an Amazon EventBridge rule that directly monitors the VPC Flow Logs API and routes matching events to an Amazon SNS topic.

The log retention must be configured directly within the VPC Flow Log definition settings because CloudWatch Log Groups do not support individual retention configurations.

Show answer & explanation

Answer: The flow logs will record an ACCEPT status for the inbound traffic on port 80, and a REJECT status for the outbound response traffic.; The CloudWatch Log Group must be configured with a retention policy to automatically expire older events, and a metric filter must be created to track REJECT records.

Answer

The flow logs will record an ACCEPT status for the inbound traffic on port 80 and a REJECT status for the outbound response traffic, and the CloudWatch Log Group must be configured with a retention policy to automatically expire older events alongside a metric filter to track REJECT records.

The correct options identify that the inbound traffic will be marked as ACCEPT while the outbound response is marked as REJECT, and that the retention policy must be configured on the CloudWatch Log Group alongside a metric filter. Because security groups are stateful and Network ACLs are stateless, the inbound connection is allowed by the security group and the inbound NACL, but the outbound response is blocked by the modified outbound NACL. Additionally, managing storage costs is handled by the CloudWatch Log Group's retention policy, and extracting patterns for alerting requires a CloudWatch Metric Filter.

Step-by-Step Solution

Analyze the stateful behavior of the security group and the stateless behavior of the Network ACL on inbound traffic.

The inbound traffic is allowed by both the security group and the inbound NACL on port 80, resulting in an ACCEPT record.

For inbound traffic to be accepted, both the security group and the inbound NACL must explicitly permit the traffic.

Analyze the return path of the response traffic.

The stateful security group allows the response automatically, but the stateless NACL evaluates the outbound rule (deny all) and drops the packet, resulting in a REJECT record.

NACLs are stateless and evaluate traffic in each direction independently, whereas security groups track connection states.

Determine the proper configuration for retention and alarms in CloudWatch Logs.

Configure a retention policy on the target CloudWatch Log Group to control costs, and create a metric filter to monitor the REJECT pattern in log data.

Retention policies are resource-level settings in CloudWatch Logs, and metric filters extract metric data from raw log events to drive CloudWatch Alarms.

Key Concept

Stateful vs. stateless network filtering in VPC Flow Logs interpretation and target log group management.

Estimated Time:2m 0s

Question 207Question →

A SysOps administrator needs to configure a backup and disaster recovery solution for an application. The application stores static assets in an Amazon S3 bucket and uses an Amazon RDS DB instance. The strategy requires that S3 objects be replicated to another AWS Region, and RDS backups must support point-in-time recovery and automated high availability. Which TWO actions should the SysOps administrator take to meet these requirements?

Select all that apply

Enable versioning on both the source and destination Amazon S3 buckets, and configure S3 Cross-Region Replication (CRR).

Enable automated backups on the Amazon RDS DB instance and configure a Multi-AZ deployment.

Configure Amazon S3 Cross-Region Replication (CRR) on the source bucket without enabling versioning on either bucket.

Configure an RDS Read Replica in another Availability Zone and rely on it as the primary automated failover and backup mechanism.

Create an S3 Gateway Endpoint to copy the backups but do not associate it with the subnet route tables.

Show answer & explanation

Answer: Enable versioning on both the source and destination Amazon S3 buckets, and configure S3 Cross-Region Replication (CRR).; Enable automated backups on the Amazon RDS DB instance and configure a Multi-AZ deployment.

Answer

The correct actions are enabling versioning on both the source and destination Amazon S3 buckets and configuring S3 Cross-Region Replication, along with enabling automated backups on the RDS DB instance and configuring a Multi-AZ deployment.

To satisfy the backup and disaster recovery requirements, versioning must be enabled on both source and destination S3 buckets before setting up Cross-Region Replication. Additionally, enabling automated backups on the RDS DB instance enables point-in-time recovery, while configuring a Multi-AZ deployment ensures automated failover and high availability.

Step-by-Step Solution

Enable versioning on both the source and destination S3 buckets.

Both buckets are now version-controlled, which is a technical prerequisite for replication.

S3 Cross-Region Replication requires versioning to track and replicate object states accurately.

Configure S3 Cross-Region Replication (CRR) from the source bucket to the destination bucket.

Objects uploaded to the source bucket are automatically replicated to the destination bucket in the other Region.

This satisfies the requirement to replicate static assets to another AWS Region for disaster recovery.

Enable automated backups and configure Multi-AZ on the RDS DB instance.

The database has daily automated backups and transaction logs enabled for point-in-time recovery, plus a synchronous standby replica in another Availability Zone.

This satisfies the requirement for RDS backups supporting point-in-time recovery and automated high availability.

Key Concept

Configuring cross-Region replication for Amazon S3 and automated backups with high availability for Amazon RDS

Estimated Time:1m 0s

Question 208Question →

A company hosts a critical customer portal on AWS. The application tier consists of Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer. The stateful database tier runs on Amazon Aurora PostgreSQL in the us-east-1 Region. Static assets are stored in an Amazon S3 bucket. The SysOps Administrator must implement a disaster recovery (DR) strategy in the us-west-2 Region that achieves a Recovery Point Objective (RPO) of less than $5$ minutes and a Recovery Time Objective (RTO) of less than $15$ minutes, while minimizing ongoing idle resource costs. Which strategy meets these requirements?

Create an Amazon Aurora PostgreSQL cross-region read replica in us-west-2. Set up Amazon S3 Cross-Region Replication (CRR) to replicate assets. Configure Amazon Route 53 DNS Failover to route traffic to us-west-2, which will automatically promote the read replica to a primary write cluster and redirect database traffic during a failover event.

Configure Amazon S3 Cross-Region Replication (CRR) from the us-east-1 bucket to a new bucket in us-west-2, ensuring versioning is enabled on the source bucket and disabled on the destination bucket to reduce storage costs. Set up hourly Aurora DB cluster snapshots with AWS Backup and copy them to us-west-2. During a disaster, restore the database from the copied snapshot and update DNS records.

Configure an Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2 containing a single Aurora Serverless v2 DB instance configured with minimum capacity. Enable Amazon S3 Cross-Region Replication (CRR) with S3 Versioning enabled on both buckets. Deploy the application tier in us-west-2 using AWS CloudFormation with the Auto Scaling group desired capacity set to

0

. During a disaster, promote the secondary DB cluster and update the CloudFormation stack to scale the application instances.

Deploy an active-active multi-region configuration with identical running Aurora DB clusters in both regions. Configure Amazon Route 53 latency-based routing with a DNS record Time to Live (TTL) of

30

minutes to manage traffic distribution and failover.

Show answer & explanation

Answer: Configure an Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2 containing a single Aurora Serverless v2 DB instance configured with minimum capacity. Enable Amazon S3 Cross-Region Replication (CRR) with S3 Versioning enabled on both buckets. Deploy the application tier in us-west-2 using AWS CloudFormation with the Auto Scaling group desired capacity set to $0$ . During a disaster, promote the secondary DB cluster and update the CloudFormation stack to scale the application instances.

Answer

The correct strategy uses an Amazon Aurora Global Database with a minimum-capacity Aurora Serverless v2 instance in the secondary region, S3 Cross-Region Replication with versioning enabled on both buckets, and an application Auto Scaling group in the secondary region with desired capacity set to

0

that is scaled up during a disaster.

The correct strategy utilizes Amazon Aurora Global Database to achieve sub-second cross-region replication, easily satisfying the

5

-minute RPO. Operating a single Aurora Serverless v2 DB instance configured at minimum capacity in the recovery region minimizes database idle cost. S3 replication is properly enabled with versioning on both source and destination buckets. The application tier's Auto Scaling group is set to a desired capacity of

0

to eliminate EC2 costs until a failover is declared. Scaling up the instances and promoting the database cluster during a disaster can be completed in a few minutes, which satisfies the

15

-minute RTO.

Step-by-Step Solution

Determine the database recovery method that meets the RPO of less than

5

minutes and the RTO of less than

15

minutes at minimum cost.

Amazon Aurora Global Database provides physical, sub-second cross-region replication lag (satisfying the

5

-minute RPO) and allows cluster promotion in under

1

minute (satisfying the database RTO). Deploying a single Serverless v2 instance with minimum capacity (0.5 ACU) minimizes idle running costs.

Restoring from backups cannot meet the

5

-minute RPO, and a cross-region read replica cannot automate failover via Route 53.

Evaluate S3 bucket replication requirements.

S3 Cross-Region Replication (CRR) must have S3 Versioning enabled on both the source bucket and the destination bucket.

Replication will fail to initiate if versioning is disabled on the destination bucket.

Identify the compute tier configuration and DNS failover timing.

Keep the standby application tier scaled down to

0

EC2 instances using CloudFormation. During disaster recovery, promote the secondary Aurora cluster and scale up the ASG. Ensure DNS failover policies do not use high TTLs (like

30

minutes) that would delay traffic redirection beyond the

15

-minute RTO.

This pilot-light/warm standby compute model ensures zero running compute costs when idle, while still allowing the system to scale and redirect traffic within the

15

-minute RTO.

Key Concept

Disaster Recovery Strategies

Estimated Time:2m 30s

Question 209Question →

An administrator manages an Amazon EC2 Auto Scaling group (ASG) configured with a target tracking scaling policy based on Average CPU Utilization. The application hosted on the instances requires $300$ seconds to fully bootstrap, configure services, and begin processing requests. During a sudden spike in traffic, the ASG launches a new instance. However, before that instance is fully initialized, the ASG launches another instance because the aggregate CPU utilization remains elevated. Which configuration adjustment will prevent the ASG from launching unnecessary instances while the newly launched instances are bootstrapping?

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

300

seconds.

Increase the default cooldown period of the Auto Scaling group to

300

seconds.

Enable detailed monitoring in the launch template used by the Auto Scaling group to transition metrics to

1

-minute intervals.

Create an Amazon EventBridge rule that triggers an AWS Systems Manager Automation runbook to temporarily suspend the AlarmNotification scaling process during scale-out.

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 the correct solution. For target tracking scaling policies, the estimated instance warmup parameter defines how long it takes for a newly launched instance to warm up. While an instance is warming up, its metrics are not included in the aggregate metric calculation for the group, and the Auto Scaling group will not trigger another scale-out action due to the elevated metrics.

Step-by-Step Solution

Analyze the scaling behavior under the current target tracking policy.

The target tracking policy does not wait long enough for the instance to bootstrap, leading to additional scale-out actions while the first instance is warming up.

By default, target tracking uses an estimated instance warmup. If the warmup is shorter than the actual bootstrap time, the ASG assumes the instance is warmed up but its CPU utilization is not yet contributing to the average, causing the ASG to scale out again.

Differentiate between the default cooldown period and estimated instance warmup.

The default cooldown period is confirmed to apply to simple scaling, whereas the target tracking scaling policy relies on estimated instance warmup.

This prevents misconfiguring the Auto Scaling group's default cooldown parameter, which has no effect on target tracking scaling behavior.

Adjust the estimated instance warmup time to match the application's bootstrap duration.

Setting the estimated instance warmup time to

300

seconds ensures the Auto Scaling group will not launch subsequent instances until the warming instance completes bootstrapping.

This direct configuration parameter natively handles the bootstrap latency of new instances in target tracking scaling policies.

Key Concept

Configuring estimated instance warmup for target tracking scaling policies to handle application initialization latency.

Estimated Time:1m 30s

Question 210Question →

A SysOps Administrator needs to monitor the latency of database write operations. The application outputs structured JSON log messages to an Amazon CloudWatch Logs log group. A typical log event looks like this:

{
"timestamp": "2026-07-14T15:30:00Z",
"operation": "db_write",
"status": "success",
"duration_ms": 420
}

The administrator wants to create a metric filter to publish a custom metric named `WriteDuration` to track the `duration_ms` values, but only for events where the `operation` is `"db_write"` and the `status` is `"success"`. Which configuration should the administrator use to meet these requirements?

Create a CloudWatch Logs metric filter on the log group with the filter pattern `{

.operation = "db_write" &&

.status = "success" }` and set the Metric Value to `$.duration_ms`.

Enable Detailed Monitoring on the Amazon EC2 instances hosting the application to expose the internal JSON logs, and configure a metric filter with the pattern `[operation = db_write, status = success]` and the Metric Value set to `$duration_ms`.

Configure an Amazon EventBridge rule that detects log ingestion events, target an AWS Systems Manager Automation document to parse the log lines, and publish the metric using the PutMetricData API operation.

Create a CloudWatch Logs metric filter with the filter pattern `{

.operation = "db_write" &&

.status = "success" }`, set the Metric Value to `$.duration_ms`, and change the log group retention setting to Never Expire to prevent the metric data points from being deleted.

Show answer & explanation

Answer: Create a CloudWatch Logs metric filter on the log group with the filter pattern `{ $.operation = "db_write" &&$ .status = "success" }` and set the Metric Value to `$.duration_ms`.

Answer

Create a CloudWatch Logs metric filter on the log group with the filter pattern `{

.operation = "db_write" &&

.status = "success" }` and set the Metric Value to `$.duration_ms`.

The correct configuration uses the CloudWatch Logs metric filter with the JSON filter pattern `{

.operation = "db_write" &&

.status = "success" }` and sets the Metric Value to `$.duration_ms`. In CloudWatch Logs, JSON log entries are natively queried using JSONPath notation, where the dollar sign followed by a dot represents the root of the JSON object. This allows the administrator to filter for specific field values and extract the value of the duration field to publish as a metric.

Step-by-Step Solution

Identify the log format.

The log format is structured JSON, meaning that fields must be referenced using the `$.fieldName` notation.

Correct syntax selection is required to parse the JSON properties.

Formulate the filter pattern to match the criteria.

The filter pattern `{

.operation = "db_write" &&

.status = "success" }` is defined.

This filter pattern matches only log events where the operation is db_write and the status is success.

Define the Metric Value to extract the target value.

The Metric Value is set to `$.duration_ms`.

This extracts the numeric value of the duration_ms field from the matching JSON log events to publish to CloudWatch Metrics.

Key Concept

CloudWatch Logs Metric Filters allow you to extract metrics from log groups using filter patterns. For JSON logs, properties are accessed using the `$.property` notation for both matching and value extraction.

Estimated Time:1m 30s

Question 211Question →

A SysOps Administrator needs to restore an Amazon RDS DB instance to its state 30 minutes ago before a critical database table was accidentally deleted. Which action will successfully restore the database?

Promote a Read Replica to the primary role, as replicas maintain historical states for point-in-time recovery.

Trigger a Multi-AZ failover to automatically rollback the active primary database to the state prior to the deletion.

Perform a point-in-time recovery (PITR), which launches a new DB instance with a new endpoint using automated backups and transaction logs.

Replicate the database backup to another AWS Region using S3 Cross-Region Replication without enabling S3 versioning.

Show answer & explanation

Answer: Perform a point-in-time recovery (PITR), which launches a new DB instance with a new endpoint using automated backups and transaction logs.

Answer

Perform a point-in-time recovery (PITR), which launches a new DB instance with a new endpoint using automated backups and transaction logs.

Point-in-time recovery (PITR) allows an administrator to restore a database to any point within its backup retention period. RDS implements this by launching a completely new DB instance and using transaction logs to roll forward the database to the specified minute before the deletion occurred.

Step-by-Step Solution

Determine the precise timestamp prior to the accidental deletion to use as the target recovery time.

The recovery target is set to 30 minutes ago.

This target avoids restoring the database to a point where the user error has already occurred.

Launch the Point-in-Time Recovery operation via the AWS Management Console, AWS CLI, or RDS API.

Amazon RDS begins provisioning a new DB instance.

RDS restores the database using the latest daily automated snapshot and applies transaction logs (write-ahead logs) up to the specified time.

Configure client applications to point to the new DB instance endpoint once the restoration completes.

Client connections are routed to the recovered database.

Point-in-time recovery always creates a new database instance with a new DNS endpoint to prevent accidental data overwrites on the active instance.

Key Concept

Point-in-Time Recovery (PITR) for Amazon RDS

Question 212Question →

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

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.

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.

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.

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.

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

A SysOps Administrator is setting up automated remediation for an Amazon EC2 instance. The administrator configures an Amazon CloudWatch alarm to monitor the `CPUUtilization` metric. The alarm has a period of $1\text{ minute}$ ( $60\text{ seconds}$ ) and is set to transition to the `ALARM` state if the CPU utilization exceeds $90\%$ for $3$ consecutive evaluation periods. An Amazon EventBridge rule is configured to detect this alarm state transition and trigger an AWS Systems Manager (SSM) Automation runbook to restart the instance. During testing, the CPU utilization remains at $95\%$ for over $10\text{ minutes}$ , but the alarm stays in the `INSUFFICIENT_DATA` state and the remediation runbook is never executed. What is the most likely cause of this issue, and how should it be resolved?

The EC2 instance has standard monitoring enabled, which sends metrics to CloudWatch every

5\text{ minutes}

. The administrator must enable detailed monitoring on the instance to send metrics at

1\text{ minute}

intervals.

The EC2 instance is utilizing standard monitoring. The administrator must change the CloudWatch alarm period to

10\text{ seconds}

to force CloudWatch to pull CPU metrics from the instance at a higher rate.

The EventBridge rule is unable to receive triggers from CloudWatch. The administrator must configure the CloudWatch alarm to directly execute the Systems Manager Automation runbook as an alarm action without using EventBridge.

The Auto Scaling group cooldown period is preventing the instance state change from being evaluated. The administrator must decrease the cooldown period to allow the alarm to transition states within the

3\text{ minute}

evaluation window.

Show answer & explanation

Answer: The EC2 instance has standard monitoring enabled, which sends metrics to CloudWatch every $5\text{ minutes}$ . The administrator must enable detailed monitoring on the instance to send metrics at $1\text{ minute}$ intervals.

Answer

The EC2 instance is using standard monitoring, which sends metrics to CloudWatch every 5 minutes. Enabling detailed monitoring on the instance will publish metrics at 1-minute intervals, providing the necessary data for the 1-minute alarm to evaluate properly.

The correct option correctly identifies that standard monitoring publishes CPU metrics at

5\text{ minute}

intervals, which is insufficient for a

1\text{ minute}

period alarm. Enabling detailed monitoring changes the reporting interval to

1\text{ minute}

, allowing the alarm to evaluate properly and transition states.

Step-by-Step Solution

Analyze the reporting frequency of default EC2 metrics under standard monitoring.

Standard monitoring reports metrics every

5\text{ minutes}

This explains why a CloudWatch alarm with a

1\text{ minute}

period lacks the data points needed to evaluate the metric, resulting in the `INSUFFICIENT_DATA` state.

Identify the configuration change required to increase metric granularity for EC2.

Detailed monitoring must be enabled on the target EC2 instance.

Enabling detailed monitoring changes the metric reporting frequency from

5\text{ minutes}

1\text{ minute}

intervals, which matches the alarm period.

Verify the automated remediation trigger flow.

Confirm that the alarm transitions to `ALARM` state and successfully fires the EventBridge rule targeting the Systems Manager Automation runbook.

With data points arriving every minute, the alarm will now evaluate successfully and execute the configured remediation.

Key Concept

CloudWatch Standard vs. Detailed Monitoring Granularity

Question 214Question →

A SysOps administrator is tasked with establishing a cross-account, cross-Region backup solution for a production Amazon RDS for PostgreSQL database. The database resides in $Account\ A$ (source) in the $\text{us-east-1}$ Region. The compliance team requires that weekly backups of this database be copied to $Account\ B$ (destination) in the $\text{us-west-2}$ Region, and that all backups remain encrypted.

The administrator configures an AWS Backup plan in $Account\ A$ to perform weekly backups and copy them to a destination backup vault in $Account\ B$ in $\text{us-west-2}$ . The copy jobs fail immediately with an access denied error. Both the source and destination backup vaults are currently encrypted using default AWS managed KMS keys.

What is the correct configuration change required to resolve this issue and successfully copy the backups?

Export the RDS snapshots to an Amazon S3 bucket, configure Amazon S3 Cross-Region Replication (CRR) to sync the files to a bucket in Account B in us-west-2, and disable S3 Versioning on both buckets to minimize storage costs.

Modify the default AWS-managed KMS key policy in Account A to grant cross-account access to Account B, and associate an IAM policy with the AWS Backup service role in Account A to delegate the decryption rights.

Create a customer managed KMS key in Account A to encrypt the source backup vault. Update the backup vault access policy in the destination vault in Account B to allow the backup:CopyIntoBackupVault action for the AWS Backup service role from Account A.

Configure a cross-Region Read Replica of the RDS PostgreSQL database in Account B in us-west-2, disable automated backups on the primary instance in Account A, and enable automated backups on the Read Replica to handle local recovery.

Show answer & explanation

Answer: Create a customer managed KMS key in Account A to encrypt the source backup vault. Update the backup vault access policy in the destination vault in Account B to allow the backup:CopyIntoBackupVault action for the AWS Backup service role from Account A.

Answer

Create a customer managed KMS key in the source account to encrypt the source backup vault, and update the vault access policy in the destination account's backup vault to permit copy operations from the source service role.

AWS Backup cross-account copying cannot proceed when the source backup vault is encrypted with the default AWS-managed KMS key (aws/backup) because these keys cannot be shared across accounts. A customer managed KMS key must be created and configured in the source account to encrypt the source vault. Furthermore, backup vaults are private by default; the destination vault in the destination account must have a vault access policy attached that explicitly permits the `backup:CopyIntoBackupVault` action for the AWS Backup service role in the source account.

Step-by-Step Solution

Evaluate the encryption limitations of AWS Backup cross-account copy operations.

Determine that AWS-managed KMS keys (e.g., default vault encryption keys) cannot be shared across accounts, meaning copy jobs will fail with Access Denied if the source vault uses one.

KMS key policies on default AWS-managed keys are immutable and restricted to the local account, forcing the use of a customer managed KMS key.

Re-encrypt the source backup vault in the source account using a customer managed KMS key.

The source vault is now encrypted with a key that can have its policy modified to allow cross-account access or delegated access via IAM roles.

A customer managed KMS key allows the AWS Backup service role to access the key during the copy and re-encryption phase.

Modify the destination backup vault's access policy in the destination account.

A policy is attached allowing the source account's AWS Backup service role permissions to execute `backup:CopyIntoBackupVault` on the destination vault.

By default, destination backup vaults reject external write attempts. An explicit vault access policy is required to allow incoming cross-account copies.

Key Concept

AWS Backup cross-account copy operations require customer managed KMS keys on the source vault and explicit cross-account write permissions in the destination vault access policy.

Estimated Time:3m 0s

Question 215Question →

A SysOps Administrator is configuring VPC Flow Logs to deliver network traffic logs to an Amazon S3 bucket. The target S3 bucket is encrypted using SSE-KMS with a customer managed KMS key. After creating the flow log, the administrator notes that the log status is 'Active', but no log files are being delivered to the bucket. Which action should the administrator take to resolve this log delivery issue?

Update the customer managed KMS key policy to grant the 'delivery.logs.amazonaws.com' service principal permissions for the 'kms:GenerateDataKey*' action.

Create an IAM service role with the 's3:PutObject' permission, configure the role's trust policy to trust the 'vpc-flow-logs.amazonaws.com' service, and assign this role when creating the flow log.

Modify the S3 bucket policy to grant the 'vpc-flow-logs.amazonaws.com' service principal write permissions, and disable KMS encryption on the bucket to bypass key policy checks.

Configure the flow logs to write to an intermediate Amazon CloudWatch Logs group with a 'Never Expire' retention policy, then configure an export task to copy the logs to the S3 bucket.

Show answer & explanation

Answer: Update the customer managed KMS key policy to grant the 'delivery.logs.amazonaws.com' service principal permissions for the 'kms:GenerateDataKey*' action.

Answer

Update the customer managed KMS key policy to grant the 'delivery.logs.amazonaws.com' service principal permissions for the 'kms:GenerateDataKey*' action.

For S3 delivery of VPC Flow Logs where the bucket is encrypted with SSE-KMS, the Log Delivery service principal ('delivery.logs.amazonaws.com') requires 'kms:GenerateDataKey*' permissions on the KMS key. This allows the delivery service to generate a data key to encrypt the log objects before writing them to S3.

Step-by-Step Solution

Identify the delivery destination type and encryption method used for the VPC Flow Logs.

The destination is an S3 bucket encrypted with SSE-KMS using a customer managed key.

This determines which AWS service permissions and policies govern the log delivery path.

Determine the service principal responsible for log delivery to S3.

The service principal is 'delivery.logs.amazonaws.com'.

VPC Flow Logs delivered to S3 use the native Log Delivery service instead of the flow logs service principal or a custom IAM role.

Check KMS key policy permissions for the service principal.

The policy must grant 'kms:GenerateDataKey*' permissions.

The Log Delivery service needs to generate a data key to encrypt the log objects before writing them to the S3 bucket.

Apply the policy update to the customer managed key to allow successful log delivery.

Flow logs are successfully written and encrypted in the S3 bucket.

Updating the key policy resolves the access denied error and allows the delivery service to write objects.

Key Concept

VPC Flow Logs Delivery Permissions to SSE-KMS Encrypted S3 Buckets

Question 216Question →

An organization runs a multi-tier transaction reporting application. The application's database is hosted on an Amazon RDS for PostgreSQL DB instance. The SysOps team needs to implement a disaster recovery (DR) strategy in a secondary AWS Region. The business requires a Recovery Point Objective (RPO) of 5 minutes and a Recovery Time Objective (RTO) of 15 minutes. The strategy must minimize ongoing running costs. Which two actions should the SysOps Administrator take to meet these requirements?

Select all that apply

Create a cross-region read replica of the RDS DB instance in the secondary Region, and promote it during a failover.

Pre-deploy the application infrastructure using AWS CloudFormation in the secondary Region, configuring the Auto Scaling group capacity to zero.

Configure Amazon RDS Multi-AZ replication to the secondary Region to enable automated, synchronous database failover.

Configure a Route 53 weighted routing policy with equal weights and without health checks to automatically route all traffic to the secondary Region during an outage.

Enable S3 Cross-Region Replication (CRR) to copy database transaction logs to the secondary Region's S3 bucket, while keeping versioning disabled on both buckets to minimize costs.

Show answer & explanation

Answer: Create a cross-region read replica of the RDS DB instance in the secondary Region, and promote it during a failover.; Pre-deploy the application infrastructure using AWS CloudFormation in the secondary Region, configuring the Auto Scaling group capacity to zero.

Answer

The correct strategy involves creating a cross-region read replica of the RDS DB instance in the secondary Region (which is promoted during failover) and pre-deploying the application infrastructure using AWS CloudFormation in the secondary Region with the Auto Scaling group capacity set to zero.

The correct strategy combines a cross-region read replica of the RDS DB instance with an idle (min/desired capacity of zero) Auto Scaling group pre-deployed in the secondary Region. The cross-region read replica meets the 5-minute RPO because replication lag is typically sub-second. Promoting the replica during failover takes a few minutes, meeting the 15-minute RTO. Keeping the Auto Scaling group capacity at zero satisfies the requirement to minimize ongoing costs, while deploying via CloudFormation ensures the infrastructure can be quickly scaled up in the secondary Region during a failover event.

Step-by-Step Solution

Select a database replication mechanism that supports cross-region replication and meets the 5-minute RPO and 15-minute RTO.

Identify that a cross-region RDS read replica replicates asynchronously with minimal lag (meeting the RPO) and can be promoted to a standalone instance in minutes (meeting the RTO).

This configuration provides the necessary data replication across regions while keeping database promotion time well within the 15-minute recovery limit.

Select a cost-effective application deployment strategy that can be brought online within the 15-minute RTO.

Choose to pre-deploy the application infrastructure using AWS CloudFormation but keep the Auto Scaling group desired and minimum capacity set to zero to avoid running costs during normal operations.

In the event of a disaster, the SysOps team can quickly update the Auto Scaling group capacity to launch instances, satisfying the RTO while minimizing running costs during non-disaster times.

Key Concept

Disaster Recovery strategies (Pilot Light / Warm Standby) utilize cross-region asynchronous data replication and low-cost standby infrastructure deployment to meet specific RTO and RPO requirements.

Question 217Question →

A SysOps Administrator is configuring Amazon S3 Cross-Region Replication (CRR) to replicate backup archives from a source bucket in the us-east-1 Region to a destination bucket in the us-west-2 Region. Which actions are required to successfully enable this configuration? (Select TWO.)

Select all that apply

Enable versioning on the source S3 bucket

Enable versioning on the destination S3 bucket

Enable RDS Multi-AZ failover on the source bucket to automate cross-Region failover

Configure an Amazon RDS Read Replica in the destination Region to synchronize the bucket contents

Configure the S3 Cross-Region Replication rules without enabling versioning on either bucket to minimize storage costs

Show answer & explanation

Answer: Enable versioning on the source S3 bucket; Enable versioning on the destination S3 bucket

Answer

Enabling versioning on both the source S3 bucket and the destination S3 bucket is required to configure Amazon S3 Cross-Region Replication.

To configure S3 Cross-Region Replication (CRR), Amazon S3 requires bucket versioning to be explicitly enabled on both the source bucket and the destination bucket. This allows S3 to preserve historical versions of the objects during replication and prevent accidental data loss.

Step-by-Step Solution

Identify the source and destination Amazon S3 buckets for Cross-Region Replication.

Source and destination buckets are selected in us-east-1 and us-west-2.

Replication requires a clearly defined source and destination.

Enable Bucket Versioning on the source S3 bucket.

Versioning is active on the source bucket.

Amazon S3 replication requires versioning to keep track of object versions.

Enable Bucket Versioning on the destination S3 bucket.

Versioning is active on the destination bucket.

The destination bucket must match the versioning state of the source bucket for replication to succeed.

Key Concept

Amazon S3 Cross-Region Replication Requirements

Question 218Question →

An online retail platform's transaction processing system must be migrated to a multi-region disaster recovery (DR) architecture. The database layer uses a multi-AZ Amazon Aurora PostgreSQL cluster, and the application tier runs on Amazon EC2 instances in an Auto Scaling group. The compliance team mandates a Recovery Time Objective (RTO) of less than 15 minutes and a Recovery Point Objective (RPO) of less than 5 minutes. The solution must be highly cost-effective, keeping the secondary Region's compute footprint minimal during normal operations.

Which combination of actions should a SysOps Administrator take to meet these requirements? (Select TWO.)

Select all that apply

Configure an Amazon Aurora Global Database with the primary cluster in the active Region and a secondary cluster in the recovery Region, deploying a single low-spec DB instance in the secondary cluster to serve as a pilot light.

Deploy the application tier in the recovery Region using an Auto Scaling group with the desired capacity set to 0, and configure an AWS CloudFormation template to deploy the application resources and scale up the group during failover.

Configure a cross-region Aurora Read Replica in the recovery Region, and rely on RDS Multi-AZ automatic failover to redirect database write traffic to the replica in the secondary Region during a disaster.

Configure Route 53 with an active-active latency routing policy to distribute traffic across both Regions, ensuring that client requests are routed to the recovery Region only when the primary Region's latency increases.

Configure Amazon S3 Cross-Region Replication (CRR) to replicate application configuration backups to the recovery Region, without enabling versioning on either the source or destination buckets to minimize storage costs.

Show answer & explanation

Answer: Configure an Amazon Aurora Global Database with the primary cluster in the active Region and a secondary cluster in the recovery Region, deploying a single low-spec DB instance in the secondary cluster to serve as a pilot light.; Deploy the application tier in the recovery Region using an Auto Scaling group with the desired capacity set to 0, and configure an AWS CloudFormation template to deploy the application resources and scale up the group during failover.

Answer

The correct combination is to configure an Amazon Aurora Global Database with a low-spec DB instance as a pilot light in the secondary cluster, and deploy the application tier using an Auto Scaling group with a desired capacity of 0 in the recovery Region, using AWS CloudFormation templates to scale it during failover.

The correct strategy combines Amazon Aurora Global Database for sub-second database replication (meeting the 5-minute RPO) with a pilot light (single low-spec instance) to minimize database compute costs. For the application tier, deploying an Auto Scaling group with a desired capacity of 0 in the secondary Region avoids active compute costs, and using AWS CloudFormation ensures the infrastructure can be scaled up quickly during a disaster to meet the 15-minute RTO.

Step-by-Step Solution

Analyze database replication and RPO requirements.

Since the RPO is less than 5 minutes, backup/restore via daily snapshots is insufficient. Aurora Global Database provides storage-level replication with sub-second lag, satisfying the RPO while allowing a single low-spec instance to serve as a pilot light to reduce cost.

Ensures the database recovery point matches compliance targets at minimal cost.

Analyze application tier provisioning and RTO requirements.

To keep the secondary Region's compute footprint minimal, set the secondary Auto Scaling group desired capacity to 0. Using CloudFormation allows programmatic deployment and rapid scaling to meet the 15-minute RTO during failover.

Eliminates operational EC2 costs in the secondary region while guaranteeing rapid recovery capabilities.

Key Concept

Disaster Recovery Strategies

Estimated Time:2m 30s

Question 219Question →

A SysOps Administrator is configuring VPC Flow Logs to publish network traffic logs from a VPC to an Amazon CloudWatch Logs log group. The administrator has already created the target log group but receives access errors when attempting to create the flow logs using their IAM user. Which of the following configuration actions are required to successfully establish log delivery? (Select TWO.)

Select all that apply

Configure the trust policy of the IAM delivery role to allow the VPC Flow Logs service principal (vpc-flow-logs.amazonaws.com) to assume the role.

Attach a policy to the SysOps Administrator's IAM identity that grants the iam:PassRole permission for the flow log delivery role.

Add the iam:PassRole permission to the trust policy of the flow log delivery role itself to authorize user delegation.

Configure the CloudWatch Logs log group's retention period to Never Expire before creating the flow log to prevent initialization timeouts.

Configure an Amazon EventBridge rule that triggers an AWS Systems Manager Automation document to dynamically authorize VPC flow log writes.

Show answer & explanation

Answer: Configure the trust policy of the IAM delivery role to allow the VPC Flow Logs service principal (vpc-flow-logs.amazonaws.com) to assume the role.; Attach a policy to the SysOps Administrator's IAM identity that grants the iam:PassRole permission for the flow log delivery role.

Answer

Configure the trust policy of the IAM delivery role to allow the VPC Flow Logs service principal to assume the role, and attach a policy to the SysOps Administrator's IAM identity that grants the iam:PassRole permission for the flow log delivery role.

To publish VPC Flow Logs to CloudWatch Logs, the flow log service requires a role that trusts 'vpc-flow-logs.amazonaws.com' via an assume role policy. Additionally, the administrator who creates the flow log must be granted the 'iam:PassRole' permission on that delivery role to ensure they are authorized to delegate it to the service.

Step-by-Step Solution

Configure the IAM delivery role trust policy

The VPC Flow Logs service principal is allowed to assume the role (sts:AssumeRole) to publish log streams.

VPC Flow Logs needs permissions to write to the CloudWatch Logs log group on your behalf.

Assign the PassRole permission to the administrator's IAM identity

The administrator can associate the delivery role with the VPC Flow Log service when creating the flow log.

Security best practices require users to have explicit permission to pass an IAM role to a service.

Key Concept

To stream VPC Flow Logs to CloudWatch Logs, the service requires an IAM role with a trust policy allowing vpc-flow-logs.amazonaws.com to assume it, and the administrator creating the flow log must possess iam:PassRole permissions for that role.

Question 220Question →

A SysOps Administrator is configuring a monitoring solution for a batch-processing application. The application logs are published to an Amazon CloudWatch Logs log group. The logs are formatted as space-delimited text, with each line containing the following fields in order: date, time, transaction ID, status code, and processing time in milliseconds.

An example log line is:
`2026-07-14 17:30:56 TXN-99482 502 120`

The Administrator needs to create a CloudWatch metric filter to extract the processing time as a metric, but only for transactions that resulted in a server error (status codes 500 through 599). The metric must report a value of 0 when no matching log events are found during a reporting period.

Which TWO configurations should the Administrator apply to meet these requirements? (Select TWO.)

Select all that apply

Use `[date, time, txn_id, status_code >= 500 && status_code <= 599, processing_time]` as the filter pattern.

In the metric transformation, set the metric value to `$processing_time` and set the default value to `0`.

In the metric transformation settings, set the log group retention period to 0 days to delete non-matching log events and reduce storage costs.

Enable detailed monitoring on the metric filter to ensure the custom metric reports data at 1-minute intervals instead of the default 5-minute intervals.

Configure an Amazon EventBridge rule triggered by a Systems Manager Automation document to reset the custom metric value to 0 when no log events are ingested.

Show answer & explanation

Answer: Use `[date, time, txn_id, status_code >= 500 && status_code <= 599, processing_time]` as the filter pattern.; In the metric transformation, set the metric value to `$processing_time` and set the default value to `0`.

Answer

Use a space-delimited filter pattern of `[date, time, txn_id, status_code >= 500 && status_code <= 599, processing_time]` and configure the metric transformation with a metric value of `$processing_time` and a default value of `0`.

The correct configurations involve using bracket syntax for space-delimited text logs to isolate the status code using numerical operators (`status_code >= 500 && status_code <= 599`), and setting up the metric transformation with `$processing_time` as the metric value along with `0` as the default value to guarantee metric publishing during quiet periods.

Step-by-Step Solution

Define the space-delimited log filter pattern.

The pattern `[date, time, txn_id, status_code >= 500 && status_code <= 599, processing_time]` correctly identifies the columns in order and applies a numerical range comparison on the status_code field.

This filters the log streams to target only those events where the status code is a 5xx server error.

Configure the metric value and default value in the metric transformation.

Setting the metric value to `$processing_time` extracts the numerical value of that field, and setting the default value to `0` ensures the metric is published even when there are no matching events.

This meets the requirement of capturing the processing duration as the metric value and handling periods of zero matching traffic.

Key Concept

CloudWatch Logs Metric Filters allow developers and SysOps administrators to extract custom metrics from log data using filters and transformations. For space-delimited logs, bracket syntax is used to name columns and perform conditional matches. Metric transformations map these matched fields to custom metrics and handle missing data with default values.

PreviousPage 11 / 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