All practice questions

976 questions

All types976 Multiple choice502 Multiple select450 Ordering24

A company hosts a microservices-based application on Amazon ECS (Fargate) with an Amazon Aurora MySQL database in the us-east-1 Region. The system administrator must design a disaster recovery (DR) strategy to a secondary region (us-west-2). The business requirements specify a Recovery Time Objective (RTO) of $15$ minutes and a Recovery Point Objective (RPO) of $2$ minutes. The recovery plan must minimize ongoing running costs in the secondary region while meeting these SLAs.

Which disaster recovery strategy meets these requirements?

Configure Amazon Aurora Global Database to replicate the database to the secondary region. Deploy the Application Load Balancer (ALB) and Amazon ECS Fargate services in the secondary region with the desired task count set to 0. During a disaster, promote the secondary Aurora cluster, scale up the ECS tasks, and update Amazon Route 53 to point to the secondary ALB.

Configure an Amazon RDS Multi-AZ deployment across us-east-1 and us-west-2 to handle database failover. Deploy the ECS Fargate tasks in the secondary region behind an ALB, and configure Route 53 with an active-active latency routing policy to automatically shift traffic between regions.

Configure Amazon S3 Cross-Region Replication (CRR) to replicate database backup files from the primary to the secondary region's bucket without enabling versioning on the destination bucket. Use AWS CloudFormation to rebuild the ECS infrastructure and restore the database from backups during failover.

Configure a Cross-Region Read Replica for the Aurora database. Configure Amazon Route 53 with a failover routing policy that points to the read replica's endpoint as the secondary destination, relying on Route 53 to automatically promote the read replica to a primary database.

Show answer & explanation

Answer: Configure Amazon Aurora Global Database to replicate the database to the secondary region. Deploy the Application Load Balancer (ALB) and Amazon ECS Fargate services in the secondary region with the desired task count set to 0. During a disaster, promote the secondary Aurora cluster, scale up the ECS tasks, and update Amazon Route 53 to point to the secondary ALB.

Answer

Configure Amazon Aurora Global Database to replicate the database to the secondary region, deploy the load balancer and ECS Fargate services with desired tasks set to 0, and promote the database and scale up the tasks during a disaster while updating Route 53.

The correct answer uses Amazon Aurora Global Database to replicate the database with sub-second replication latency, meeting the 2-minute RPO. Deploying the application resources (ECS Fargate and ALB) with a desired task count of 0 represents a cost-effective Pilot Light disaster recovery strategy. The tasks can be quickly spun up and Route 53 DNS updated within the 15-minute RTO.

Step-by-Step Solution

Analyze the business requirements for recovery objectives and cost constraints.

RTO is

15

minutes, RPO is

2

minutes, and costs in the secondary region must be minimized.

Determines the appropriate disaster recovery strategy (e.g., Pilot Light vs. Warm Standby) and database replication mechanism.

Evaluate database replication options that meet the 2-minute RPO.

Aurora Global Database provides sub-second replication latency, satisfying the RPO requirement.

Standard backup and restore or cross-region snapshot copies take hours and cannot meet the 2-minute RPO.

Evaluate application tier deployment strategies to meet the 15-minute RTO while minimizing costs.

Deploying ECS Fargate tasks with a desired count of 0 (Pilot Light) minimizes active resource costs and can be scaled up in minutes during a failover.

Warm standby keeps tasks running continuously, which costs more. Pilot Light deploys the infrastructure but keeps compute resources off or at zero until needed.

Key Concept

Disaster Recovery Strategies

Estimated Time:1m 30s

Question 222Question →

A company hosts a production web application on AWS Elastic Beanstalk using an Auto Scaling group behind an Application Load Balancer. A SysOps Administrator needs to deploy a critical application update. The deployment strategy must ensure zero downtime, deploy the update to brand new instances for clean isolation, and allow for a rapid rollback by terminating the new instances if the deployment fails. Furthermore, the administrator must avoid the overhead of managing a separate Elastic Beanstalk environment or performing a DNS CNAME swap. Which deployment policy should the SysOps Administrator select to meet these requirements?

Rolling deployment

Immutable deployment

All-at-once deployment

Blue/Green deployment

Show answer & explanation

Answer: Immutable deployment

Answer

The correct deployment policy is an immutable deployment.

The immutable deployment strategy satisfies all the requirements. It creates a temporary Auto Scaling group to launch a full set of new instances running the new version within the same environment. Traffic is cut over only after health checks pass, ensuring zero downtime. If the deployment fails, the rollback is rapid and simple: Elastic Beanstalk terminates the temporary Auto Scaling group, leaving the original instances untouched.

Step-by-Step Solution

Analyze the deployment constraints: zero downtime, deployment to new isolated instances, fast rollback by terminating new instances, and avoiding the creation of a separate environment.

Identified that rolling and all-at-once updates modify existing instances in-place, while blue/green requires a separate environment.

This filters out strategies that do not meet the isolation or environment management requirements.

Evaluate the capabilities of an immutable deployment in AWS Elastic Beanstalk.

An immutable deployment launches a temporary Auto Scaling group inside the same environment, deploys the new version to new instances, and serves traffic only after health checks pass.

This satisfies the isolation requirement within a single environment.

Assess the rollback speed and downtime behavior of the immutable policy.

If the deployment fails, the temporary Auto Scaling group is terminated immediately, restoring all traffic to the original instances without downtime.

This meets the rapid rollback and zero-downtime constraints.

Key Concept

AWS Elastic Beanstalk immutable deployments isolate application updates on new EC2 instances in a temporary Auto Scaling group within the same environment to ensure zero downtime and rapid rollback.

Question 223Question →

A SysOps Administrator is investigating high data transfer costs in a VPC. An application running on Amazon EC2 instances in a private subnet frequently communicates with external endpoints and AWS services. The administrator suspects that some traffic destined for Amazon S3 is being routed through a NAT Gateway instead of a configured VPC Gateway Endpoint for S3. The administrator decides to create a VPC Flow Log with a custom format to identify this traffic. Which of the following actions should the administrator take to verify whether traffic destined for Amazon S3 is traversing the NAT Gateway? (Select TWO.)

Select all that apply

Create a custom flow log format that includes the `pkt-dstaddr` field to capture the final destination IP address of the packets rather than the network interface destination IP.

Create a custom flow log format that includes the `traffic-path` field to identify whether egress traffic is routed through a NAT gateway or a gateway VPC endpoint.

Create a default VPC Flow Log and check the `dstaddr` field, which will display the Amazon S3 public IP address as the destination for traffic flowing from the EC2 instance through the NAT Gateway.

Associate the subnet's route table with a Gateway VPC Endpoint for Amazon S3, then verify that the flow log's `dstaddr` field automatically changes from the NAT Gateway IP to the VPC endpoint service name.

Create a custom flow log format that includes the `flow-direction` field, and verify that the value is set to `ingress` for the outbound traffic going from the EC2 instances to Amazon S3.

Show answer & explanation

Answer: Create a custom flow log format that includes the `pkt-dstaddr` field to capture the final destination IP address of the packets rather than the network interface destination IP.; Create a custom flow log format that includes the `traffic-path` field to identify whether egress traffic is routed through a NAT gateway or a gateway VPC endpoint.

Answer

Create a custom flow log format that includes the `pkt-dstaddr` field, and create a custom flow log format that includes the `traffic-path` field.

To determine if traffic is traversing the NAT Gateway rather than using a Gateway VPC Endpoint, custom VPC Flow Log fields are required. The `pkt-dstaddr` field captures the packet-level destination IP address, which remains the S3 public IP address even when traffic passes through the NAT Gateway. In contrast, the standard `dstaddr` field would only show the private IP address of the NAT Gateway's network interface. Additionally, the `traffic-path` field provides a direct indicator of the egress route, where a value of 2 signifies a NAT Gateway and a value of 5 signifies a gateway VPC endpoint.

Step-by-Step Solution

Identify the limitations of default VPC Flow Logs when traffic traverses an intermediate device like a NAT Gateway.

Determine that the standard `dstaddr` field only captures the next-hop ENI destination (the NAT Gateway private IP) and not the final destination.

To trace the actual destination of traffic passing through a NAT Gateway, packet-level destination details are needed.

Analyze custom VPC Flow Log fields for packet-level tracking and routing path indicators.

Identify `pkt-dstaddr` to capture the final packet destination IP and `traffic-path` to identify the egress route type (value 2 for NAT Gateway, value 5 for Gateway VPC Endpoint).

These fields allow direct correlation between the destination service and the routing path used.

Evaluate the incorrect options for flow direction, S3 service name resolution, and default log field behavior.

Eliminate options proposing default logs for S3 destination tracking, expecting service names in flow logs, or using 'ingress' direction for outbound traffic.

Ensures the selected configuration steps accurately address the diagnostic requirements.

Key Concept

Custom VPC Flow Logs allow administrators to capture advanced metadata, such as packet-level IP addresses (`pkt-dstaddr`) and routing paths (`traffic-path`), which is essential when diagnosing traffic flow through intermediate interfaces like NAT Gateways.

Question 224Question →

A SysOps Administrator is troubleshooting a connection issue where an external client cannot fully establish a connection to an Amazon EC2 instance in a public subnet. The EC2 instance's security group has an inbound rule allowing TCP port 80 from all sources, and the default outbound rule allowing all traffic. The subnet's Network Access Control List (NACL) has an inbound rule allowing TCP port 80 from all sources, but the outbound NACL rules do not allow any ephemeral port traffic (ports 1024-65535) back to the client. VPC Flow Logs are enabled for the network interface of the EC2 instance. Which pattern of ACCEPT and REJECT records will the administrator observe in the VPC Flow Logs for this connection attempt?

An ACCEPT record for the inbound traffic, and a REJECT record for the outbound traffic

A REJECT record for the inbound traffic, because the stateless Network ACL blocks the connection from being established initially

ACCEPT records for both the inbound and outbound traffic, because the stateful security group automatically allows the return traffic

An ACCEPT record for the inbound traffic, and no records for the outbound traffic because VPC Flow Logs do not log packets dropped by Network ACLs

Show answer & explanation

Answer: An ACCEPT record for the inbound traffic, and a REJECT record for the outbound traffic

Answer

An ACCEPT record for the inbound traffic, and a REJECT record for the outbound traffic

The correct answer shows an ACCEPT record for the inbound traffic and a REJECT record for the outbound traffic. Since the inbound rules of both the security group and the Network ACL permit traffic on port 80, the inbound connection request successfully reaches the network interface and is logged as an ACCEPT. However, because the Network ACL is stateless, it does not automatically allow response traffic. Without an outbound Network ACL rule allowing traffic to the client's ephemeral ports, the return packets are blocked and logged as a REJECT.

Step-by-Step Solution

Evaluate the inbound path of the connection

The inbound packet targeting port 80 is allowed by both the inbound Network ACL rule and the inbound security group rule. This results in an ACCEPT record in the VPC Flow Logs.

Both firewall layers must permit the traffic for it to reach the network interface and be logged as accepted.

Evaluate the outbound response path of the connection

The EC2 instance sends a response packet back to the client's ephemeral port. While the stateful security group automatically allows this response, the stateless Network ACL lacks a rule to permit outbound traffic to ephemeral ports. The packet is dropped at the subnet boundary, resulting in a REJECT record.

Network ACLs are stateless, meaning return traffic is not automatically tracked or allowed; it must be explicitly permitted by outbound rules.

Key Concept

Stateful vs. Stateless network filtering evaluation in VPC Flow Logs

Question 225Question →

An organization deploys an application across four microservices hosted on Amazon ECS. Each microservice writes logs to its own dedicated CloudWatch Logs log group: `/aws/ecs/frontend`, `/aws/ecs/auth-service`, `/aws/ecs/catalog`, and `/aws/ecs/payment`. To maintain service-level agreements, a SysOps administrator must establish a mechanism to alert the team when the aggregate number of `HTTP 504` gateway timeout errors across all four microservices exceeds $45$ in any $10$ -minute period.

Which configuration should the administrator implement to meet this requirement?

Enable detailed monitoring on the ECS cluster. Create a single metric filter on a new log group named `/aws/ecs/aggregated` to capture all cluster-wide events, and configure a CloudWatch alarm to trigger if the metric exceeds

45

within a

10

-minute period.

Create an Amazon EventBridge rule that matches `PutLogEvents` API calls containing `HTTP 504` error codes. Target an AWS Systems Manager Automation runbook that aggregates the event count in a custom Amazon DynamoDB table, and set up a CloudWatch alarm on the table's write capacity metrics.

Define an identical metric filter on each of the four log groups using the same filter pattern, custom namespace, and metric name. Configure a single CloudWatch alarm on the aggregated metric using the Sum statistic over a

10

-minute period with a threshold of

45

Set the CloudWatch Logs retention period to 10 days for all log groups. Configure a metric filter at the log group prefix level of `/aws/ecs/` to automatically aggregate the error count, and define an alarm threshold of

45

for the retention duration.

Show answer & explanation

Answer: Define an identical metric filter on each of the four log groups using the same filter pattern, custom namespace, and metric name. Configure a single CloudWatch alarm on the aggregated metric using the Sum statistic over a $10$ -minute period with a threshold of $45$ .

Answer

10

-minute period with a threshold of

45

To aggregate metrics across multiple log groups in CloudWatch Logs, you must create a metric filter on each individual log group. By directing each filter's metric transformation to publish to the same custom namespace and metric name, CloudWatch automatically aggregates the metrics. Setting a CloudWatch alarm on the aggregated metric using the Sum statistic evaluates the cumulative value from all log groups over the specified duration.

Step-by-Step Solution

Configure a metric filter on each of the four individual log groups: `/aws/ecs/frontend`, `/aws/ecs/auth-service`, `/aws/ecs/catalog`, and `/aws/ecs/payment`.

Four separate metric filters are created, each scanning its respective log group for the `HTTP 504` pattern.

Metric filters in CloudWatch Logs are scoped to a single log group and cannot span multiple groups directly via wildcards or prefixes.

Map all four metric filters to output to the exact same custom metric namespace (e.g., `Custom/ECS`) and metric name (e.g., `GatewayTimeouts`).

CloudWatch combines the metrics published from all four log groups under a single namespace and metric name.

Using identical namespaces and metric names aggregates the published data points into a single metric stream in CloudWatch.

Create a CloudWatch alarm for the combined metric using the Sum statistic with a evaluation period of 10 minutes and a threshold of 45.

An alarm is created that will trigger if the cumulative sum of error data points from all four services exceeds 45 within a 10-minute window.

The Sum statistic totals all data points published by the four metric filters within the specified evaluation interval.

Key Concept

Aggregating logs across multiple log groups using identical metric filter names/namespaces, and using the Sum statistic in a CloudWatch alarm.

Estimated Time:2m 30s

Question 226Question →

An organization wants to automatically copy all newly uploaded objects from a production Amazon S3 bucket to a backup S3 bucket in a different AWS Region for disaster recovery. A SysOps administrator creates a replication rule, but replication fails to start. What must the administrator configure on the S3 buckets to resolve this issue?

Attach an IAM user policy to the SysOps administrator that allows the sts:AssumeRole action.

Enable S3 Versioning only on the source bucket and keep versioning disabled on the destination bucket.

Enable S3 Versioning on both the source bucket and the destination bucket.

Add a bucket policy to the destination bucket that explicitly grants kms:Decrypt permission to the source bucket.

Show answer & explanation

Answer: Enable S3 Versioning on both the source bucket and the destination bucket.

Answer

Enable S3 Versioning on both the source bucket and the destination bucket.

The correct option is to enable S3 Versioning on both the source bucket and the destination bucket. S3 replication relies on versioning to track objects and replicate deletes and updates correctly. Without versioning enabled on both buckets, replication cannot function.

Step-by-Step Solution

Identify the basic prerequisite for Amazon S3 replication.

Amazon S3 replication requires bucket versioning to be enabled on both the source and destination buckets.

Replication relies on version IDs to copy and track objects across buckets.

Review bucket configurations to ensure they satisfy the versioning requirements.

Enabling versioning on both buckets allows the S3 replication process to start.

S3 replication fails immediately if either bucket has versioning disabled or suspended.

Key Concept

Amazon S3 replication requires both the source and destination buckets to have versioning enabled.

Question 227Question →

During a scheduled disaster recovery drill, a SysOps Administrator simulates an Availability Zone (AZ) outage for a high-priority application. The application's database tier consists of a primary Amazon RDS for MariaDB DB instance in subnet-A (AZ-1) and a Read Replica in subnet-B (AZ-2). The application connects to the primary DB instance for write operations and to the Read Replica for read operations. During the simulated outage of AZ-1, the application completely loses write access to the database, and no automated failover occurs. What is the root cause of this behavior, and how should the administrator resolve it to ensure automatic write failover?

Read Replicas use asynchronous replication and do not support automatic failover. To resolve this, the administrator must modify the primary DB instance to enable a Multi-AZ deployment, which provides synchronous replication to a standby instance and automated DNS failover.

The Read Replica was not designated as the failover target. To resolve this, the administrator must promote the Read Replica to a standalone DB instance, enable the 'Automatic Failover' option on the primary DB instance, and specify the promoted instance as the failover target.

Amazon Route 53 was not configured to monitor the primary DB instance. To resolve this, the administrator must create a Route 53 active-passive failover routing policy with a health check that automatically routes database write traffic to the Read Replica's endpoint during an outage.

The Read Replica was not configured with the 'Replication Failover' flag enabled. To resolve this, the administrator must modify the Read Replica configuration to set its replication state to synchronous and enable the automatic promotion setting in the RDS console.

Show answer & explanation

Answer: Read Replicas use asynchronous replication and do not support automatic failover. To resolve this, the administrator must modify the primary DB instance to enable a Multi-AZ deployment, which provides synchronous replication to a standby instance and automated DNS failover.

Answer

Read Replicas use asynchronous replication and do not support automatic failover. The administrator must modify the primary DB instance to enable a Multi-AZ deployment, which provides synchronous replication to a standby instance and automated DNS failover.

The correct option is correct because Amazon RDS Multi-AZ deployments provide high availability and failover support. In a Multi-AZ deployment, RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone. If the primary instance fails, RDS automatically performs a failover by updating the DNS record of the DB instance to point to the standby, requiring no changes to the application's connection string. Read Replicas use asynchronous replication and are designed for read scalability, not automatic failover.

Step-by-Step Solution

Identify the replication and failover mechanism in the current setup.

The current setup uses a primary RDS instance and an asynchronous Read Replica in a separate AZ.

Understanding the difference between Multi-AZ standbys and Read Replicas is essential to diagnose why automated failover did not occur.

Evaluate the failover capabilities of the existing components.

Read Replicas cannot serve as automatic write failover targets in Amazon RDS without manual promotion.

This explains why the simulated outage resulted in a complete loss of write access.

Select the appropriate high availability configuration that enables automatic DNS failover.

A Multi-AZ deployment must be enabled on the primary DB instance.

Multi-AZ configuration provides synchronous replication to a standby instance in another AZ and handles automatic DNS failover when the primary instance fails.

Key Concept

Multi-AZ Deployment vs. Read Replicas failover behaviors

Question 228Question →

A company runs a critical web application on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB) in the us-east-1 Region. The application uses an Amazon RDS for PostgreSQL database for stateful data and an Amazon S3 bucket to store static user uploads. A SysOps Administrator must establish a disaster recovery (DR) strategy in the us-west-2 Region. The strategy must achieve a Recovery Point Objective (RPO) of 15 minutes and a Recovery Time Objective (RTO) of 30 minutes while minimizing costs during normal operations. Which setup meets these requirements?

Configure an RDS cross-region read replica in us-west-2. Enable versioning on both the source and destination S3 buckets, and configure S3 Cross-Region Replication (CRR) to us-west-2. In us-west-2, deploy an ALB and an Auto Scaling group with the desired capacity set to 0. Create Amazon Route 53 Active-Passive failover records with health checks pointing to the us-east-1 ALB.

Configure the Amazon RDS database as a Multi-AZ deployment with the standby replica located in us-west-2. Configure S3 Cross-Region Replication (CRR) to us-west-2. In us-west-2, deploy an ALB and an Auto Scaling group with the desired capacity set to 0. Create Amazon Route 53 Active-Passive failover records.

Configure an RDS cross-region read replica in us-west-2. Configure S3 Cross-Region Replication (CRR) from the source bucket to a destination bucket in us-west-2 without enabling S3 versioning. In us-west-2, deploy an ALB and an Auto Scaling group with the desired capacity set to 0. Create Amazon Route 53 Active-Passive failover records.

Configure an RDS cross-region read replica in us-west-2. Enable versioning on both S3 buckets and configure S3 Cross-Region Replication (CRR) to us-west-2. In us-west-2, deploy an ALB and an Auto Scaling group with the desired capacity matching the primary region. Configure Amazon Route 53 active-active Weighted routing records with equal weight (50/50) to balance traffic across both regions during normal operations.

Show answer & explanation

Answer: Configure an RDS cross-region read replica in us-west-2. Enable versioning on both the source and destination S3 buckets, and configure S3 Cross-Region Replication (CRR) to us-west-2. In us-west-2, deploy an ALB and an Auto Scaling group with the desired capacity set to 0. Create Amazon Route 53 Active-Passive failover records with health checks pointing to the us-east-1 ALB.

Answer

The correct solution represents a classic Pilot Light disaster recovery strategy. Creating an Amazon RDS cross-region read replica provides asynchronous replication that keeps data updated within seconds, meeting the 15-minute RPO requirement. S3 Cross-Region Replication (CRR) satisfies the S3 RPO requirement, but it strictly requires versioning to be enabled on both the source and destination S3 buckets. To minimize running costs during normal operations, the Auto Scaling group in the recovery region is scaled to 0. During a disaster, the read replica is promoted to a standalone database and the Auto Scaling group is scaled up to handle traffic routed by Route 53 failover routing, all of which can be completed well within the 30-minute RTO.

Step-by-Step Solution

Address stateful database requirements for RPO and RTO.

Create an Amazon RDS cross-region read replica in us-west-2. This handles continuous asynchronous database replication (RPO in seconds) and can be promoted to a standalone primary database within minutes during failover (RTO within 30 minutes).

Restoring from backups would exceed the 30-minute RTO, whereas promoting a read replica meets it.

Address static storage requirements for RPO.

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

S3 versioning is a mandatory requirement for CRR to function.

Configure the web tier to minimize costs during normal operations (Pilot Light strategy).

Deploy an Application Load Balancer and an Auto Scaling group in us-west-2 with the desired capacity set to 0.

Keeping the desired capacity at 0 ensures that no EC2 instances are running (saving cost) until a failover is initiated.

Configure DNS routing for disaster recovery.

Configure Route 53 Active-Passive failover records with health checks monitoring the primary region.

This automates traffic redirection to the recovery region when the primary region is determined to be unhealthy.

Key Concept

Implementing a cost-effective Pilot Light Disaster Recovery strategy using RDS cross-region replication, S3 Cross-Region Replication with versioning, and zero-capacity Auto Scaling groups.

Estimated Time:3m 0s

Question 229Question →

A SysOps Administrator needs to determine if any resources in an active AWS CloudFormation stack have been modified by manual changes that were made outside of CloudFormation.

Which of the following steps should the administrator perform to identify this configuration drift? (Select TWO.)

Select all that apply

Run drift detection on the stack using the AWS CloudFormation console or the AWS CLI.

Review the stack drift status details to compare the actual resource property values with the expected values defined in the template.

Configure AWS CloudFormation to automatically rollback the stack to undo any detected out-of-band modifications.

Update the CloudFormation execution role with the iam:PassRole permission to allow CloudFormation to auto-remediate the drift.

Initiate a stack rollback operation to force the resources to synchronize with the original template parameters.

Show answer & explanation

Answer: Run drift detection on the stack using the AWS CloudFormation console or the AWS CLI.; Review the stack drift status details to compare the actual resource property values with the expected values defined in the template.

Answer

To identify configuration drift, run drift detection on the stack using either the CloudFormation console or AWS CLI, and then review the stack drift status details to compare the actual resource properties against the expected ones in the template.

Running drift detection and reviewing the drift status details are the correct steps. Drift detection compares the actual state of resources to the expected state defined in the stack template. The drift status details show the specific resource properties that have drifted.

Step-by-Step Solution

Initiate drift detection on the target CloudFormation stack.

CloudFormation evaluates the current state of each resource in the stack against its expected state defined in the template.

This starts the detection process and determines the drift status of each resource.

Examine the drift status details.

The console or CLI output shows the drift status (e.g., DRIFTED or IN_SYNC) and highlights the specific properties that differ.

This allows the administrator to pinpoint which manual changes occurred outside of CloudFormation.

Key Concept

CloudFormation drift detection allows SysOps Administrators to identify resources that have been modified outside of CloudFormation management by comparing actual resource configurations against the template.

Question 230Question →

A SysOps Administrator is configuring a monitoring solution for a microservices-based application running on Amazon EC2. The application logs are sent to Amazon CloudWatch Logs. The application outputs space-delimited log entries in the following format:

`2026-07-14T12:00:00Z WARN PaymentService 503 150`

The administrator needs to create a metric filter to monitor the frequency of HTTP 503 Service Unavailable errors generated by the PaymentService specifically, and trigger an Amazon SNS notification when this happens. What is the correct way to configure this monitoring and alerting setup?

Create a CloudWatch metric filter with the pattern `[timestamp, log_level, service_name = PaymentService, status_code = 503, execution_time]`. Configure a CloudWatch alarm based on this custom metric, and set the alarm action to send a notification to the Amazon SNS topic.

Enable detailed monitoring on the EC2 instances. Create a CloudWatch metric filter with the pattern `[timestamp, log_level, service_name = PaymentService, status_code = 503, execution_time]` to ensure that the custom metric is evaluated and published at 1-minute intervals.

Create a CloudWatch metric filter using the JSON pattern `{

.service_name = "PaymentService" &&

.status_code = 503 }`. Configure a CloudWatch alarm on the log group retention settings to notify the SNS topic when the retention period is reached.

Create an Amazon EventBridge rule that directly parses the EC2 space-delimited log stream pattern. Configure the rule to target an AWS Systems Manager Automation document that notifies the SNS topic and resets the log group.

Show answer & explanation

Answer: Create a CloudWatch metric filter with the pattern `[timestamp, log_level, service_name = PaymentService, status_code = 503, execution_time]`. Configure a CloudWatch alarm based on this custom metric, and set the alarm action to send a notification to the Amazon SNS topic.

Answer

The correct configuration uses the standard bracket syntax `[...]` to define and filter space-delimited log entries. By listing the fields in order and using equality conditions (e.g., `service_name = PaymentService` and `status_code = 503`), CloudWatch Logs successfully isolates matching events. Once the metric is generated, a standard CloudWatch alarm can be configured to notify an Amazon SNS topic when the threshold is crossed.

Step-by-Step Solution

Define the space-delimited metric filter pattern using square brackets to map and inspect log fields: `[timestamp, log_level, service_name = PaymentService, status_code = 503, execution_time]`.

CloudWatch Logs extracts a custom metric whenever it encounters a log entry matching the service name and status code.

To accurately identify and count occurrences of PaymentService returning a 503 status code in space-delimited log lines.

Create a CloudWatch alarm based on the custom metric produced by the metric filter.

An alarm is configured to transition to the ALARM state when the custom metric exceeds a specified threshold within a given period.

To evaluate the metric value over time and prepare for an automated notification trigger.

Configure the CloudWatch alarm's action to send a message to an Amazon SNS topic when the alarm transitions to the ALARM state.

Subscribers to the SNS topic receive real-time notifications when the 503 error rate exceeds the threshold.

To deliver the alert to the SysOps team or automated targets.

Key Concept

CloudWatch Logs Metric Filters and Alarms

Question 231Question →

A SysOps Administrator is configuring an Amazon CloudWatch metric filter to parse custom application log events written to an Amazon CloudWatch Logs log group named `/apps/payment-service`. The application logs events in the following JSON format:

{
"request_id": "req-98213",
"operation": "ProcessPayment",
"response_code": 500,
"execution_time_ms": 450,
"client_details": {
"tier": "Premium",
"region": "us-east-1"
}
}

The Administrator wants to monitor when `ProcessPayment` operations for `Premium` tier clients fail with a `response_code` of 500 or higher, and record the `execution_time_ms` value as a custom metric.

Which two configurations must the Administrator apply to the metric filter and its metric transformation to accomplish this? (Select TWO.)

Select all that apply

Use `{

.operation = "ProcessPayment" &&

.client_details.tier = "Premium" && $.response_code >= 500 }` as the filter pattern.

Set the Metric Value in the metric transformation to `$.execution_time_ms`.

Use `[operation = "ProcessPayment", client_details.tier = "Premium", response_code >= 500]` as the filter pattern.

Enable detailed monitoring on the EC2 instances hosting the application to ensure that the custom metric publishes data at 1-minute intervals.

Configure an Amazon EventBridge rule to match the log patterns and invoke an AWS Systems Manager Automation document to extract the custom metric values.

Show answer & explanation

Answer: Use `{ $.operation = "ProcessPayment" &&$ .client_details.tier = "Premium" && $.response_code >= 500 }` as the filter pattern.; Set the Metric Value in the metric transformation to `$ .execution_time_ms`.

Answer

Use the JSON filter pattern with curly braces and reference the field path `$.execution_time_ms` in the Metric Value field of the metric transformation.

To filter JSON logs in CloudWatch Logs, the filter pattern must use curly braces `{}` and specify paths using the JSON path notation (such as `

.operation`). The pattern evaluates matching logs by utilizing comparison operators like `=` and `>=` joined by logical operators like `&&`. To publish a specific value from the log event (such as `execution_time_ms`) rather than a simple count of occurrences, the Metric Value in the metric transformation must reference the JSON path of that value, which is `

.execution_time_ms`.

Step-by-Step Solution

Analyze the log format to identify how to reference the target fields.

The log is in JSON format, meaning JSON path notation (starting with `$.`) must be used inside curly braces `{}` to filter events.

CloudWatch Logs requires JSON path syntax for JSON logs, and space-delimited/bracketed syntax for standard text logs.

Formulate the filter pattern to match the criteria: operation is 'ProcessPayment', client tier is 'Premium', and response code is 500 or higher.

The correct pattern is `{

.operation = "ProcessPayment" &&

.client_details.tier = "Premium" && $.response_code >= 500 }`.

This pattern uses correct logical operators and property paths (including nested property `client_details.tier`).

Configure the metric value extractor in the metric transformation.

Set the Metric Value to `$.execution_time_ms`.

Using the JSON path references the numeric value of the field to publish it as the metric measurement instead of incrementing a simple counter.

Key Concept

Filtering JSON logs and extracting metric values using CloudWatch Metric Filters

Question 232Question →

An organization hosts a multi-tier web application using an Amazon Aurora MySQL Global Database. The primary DB cluster is in the us-east-1 Region, and a secondary DB cluster is in the us-west-2 Region for disaster recovery. A SysOps Administrator is tasked with designing a failover mechanism so that if the primary Region becomes completely unavailable, application traffic is redirected to us-west-2 with minimal downtime. The database in us-west-2 must be capable of accepting write traffic. Which configuration should the SysOps Administrator implement to achieve this goal?

Configure an Amazon Route 53 failover routing policy with the primary cluster's writer endpoint as primary and the secondary cluster's reader endpoint as secondary. Aurora Global Database will automatically promote the secondary cluster to a writer and update the Route 53 record when the primary Region becomes unhealthy.

Configure an Amazon Route 53 failover routing policy pointing to the primary cluster's writer endpoint. Create a Route 53 health check that monitors the primary database. Configure an AWS Lambda function triggered by the health check failure to promote the secondary Aurora DB cluster in us-west-2 to a standalone primary cluster.

Configure Route 53 latency-based routing with active-active configuration. Configure both Aurora DB clusters in us-east-1 and us-west-2 as primary writers to allow the application to write to either Region, while Route 53 automatically stops routing to the failed Region.

Create a Route 53 CNAME record pointing to the cross-region read replica in us-west-2. During an outage in the primary Region, Aurora will automatically perform a synchronous failover to the replica, allowing it to begin accepting write traffic without manual intervention.

Show answer & explanation

Answer: Configure an Amazon Route 53 failover routing policy pointing to the primary cluster's writer endpoint. Create a Route 53 health check that monitors the primary database. Configure an AWS Lambda function triggered by the health check failure to promote the secondary Aurora DB cluster in us-west-2 to a standalone primary cluster.

Answer

To configure failover for an Amazon Aurora MySQL Global Database, you must set up a Route 53 failover routing policy to detect primary region failure, and configure an AWS Lambda function triggered by the Route 53 health check failure to promote the secondary Aurora DB cluster in the disaster recovery region to a standalone primary cluster.

The correct configuration uses a Route 53 health check to detect primary database unavailability and triggers an AWS Lambda function to promote the secondary cluster in the disaster recovery region to a standalone database. Since Aurora Global Database does not automatically promote secondary regional clusters during a disaster, this automation is required to enable write access in the secondary region.

Step-by-Step Solution

Create an Amazon Route 53 health check targeting the primary Aurora DB cluster in the us-east-1 Region.

The health status of the primary database is actively monitored.

Route 53 needs a mechanism to detect when the primary region is experiencing an outage.

Configure an AWS Lambda function that is triggered when the Route 53 health check reports an unhealthy status.

Automated invocation of the promotion workflow is established.

Because Aurora Global Database does not support automatic cross-region failover, custom automation must invoke the AWS API to promote the secondary database.

Write the Lambda function to promote the secondary Aurora DB cluster in us-west-2 using the AWS SDK.

The secondary cluster is detached from the global database and promoted to a standalone writeable DB cluster.

This allows the secondary database to begin accepting write traffic from the application.

Configure Route 53 failover routing records to point the database DNS alias to the new primary writer endpoint in us-west-2 once failover is completed.

Application write traffic is dynamically redirected to the promoted database cluster.

To ensure minimal application downtime and restore database write capabilities automatically.

Key Concept

Amazon Aurora Global Database cross-region failover is an unplanned disaster recovery event that requires manual promotion of the secondary cluster to a standalone primary cluster. This promotion can be automated via AWS Lambda triggered by Route 53 health checks. In contrast, local Multi-AZ failovers within a single Region are fully managed and automatic.

Estimated Time:2m 30s

Question 233Question →

A SysOps Administrator is setting up cross-account monitoring for containerized workloads. The administrator needs to configure Amazon CloudWatch Container Insights to visualize performance metrics from Amazon ECS clusters running in a source account (Account B) within a centralized dashboard in a monitoring account (Account A). Both accounts are in the same Region. Which of the following actions must the administrator perform to achieve this setup? (Select TWO.)

Select all that apply

In the monitoring account (Account A), create a CloudWatch observability sink and define a sink policy that permits Account B to link to it.

In the source account (Account B), create a CloudWatch observability link pointing to the Amazon Resource Name (ARN) of the sink in Account A.

In the source account (Account B), modify the CloudWatch agent configuration to specify the regional endpoint of Account A as the primary metric destination.

In the monitoring account (Account A), configure a cross-account IAM role with the CloudWatchAgentServerPolicy policy and configure the ECS tasks in Account B to assume this role.

In the source account (Account B), create a CloudWatch Logs metric filter for the /aws/containerinsights log group that publishes metrics directly to an Amazon Simple Queue Service (Amazon SQS) queue in Account A.

Show answer & explanation

Answer: In the monitoring account (Account A), create a CloudWatch observability sink and define a sink policy that permits Account B to link to it.; In the source account (Account B), create a CloudWatch observability link pointing to the Amazon Resource Name (ARN) of the sink in Account A.

Answer

To configure cross-account monitoring for Container Insights, you must create a CloudWatch observability sink in the monitoring account (Account A) with a policy permitting Account B, and then create a CloudWatch observability link in the source account (Account B) pointing to the sink in Account A.

To view CloudWatch metrics, logs, and traces from other AWS accounts, CloudWatch cross-account observability uses a sink-and-link model. The monitoring account (receiver) must have a sink and a policy allowing the source account to link to it. The source account (sender) then creates a link referencing the sink. This is the correct, native way to share Container Insights data across accounts.

Step-by-Step Solution

Configure the monitoring account (Account A) as the receiver.

A CloudWatch observability sink is created, and its policy is defined to allow Account B to link to it.

This establishes the monitoring account as a central dashboarding destination that accepts metrics from source accounts.

Configure the source account (Account B) as the sender.

A CloudWatch observability link is created in Account B pointing to the ARN of the sink in Account A.

This links Account B's CloudWatch telemetry (including Container Insights) directly to the central monitoring account.

Verify and build the dashboard in Account A.

Container Insights metrics from Account B can now be selected and visualized in dashboards within Account A.

Once the link is created, cross-account query capabilities are automatically enabled for the monitoring account.

Key Concept

CloudWatch Cross-Account Observability using Sinks and Links

Estimated Time:2m 0s

Question 234Question →

A SysOps Administrator needs to determine whether application traffic between Amazon EC2 instances in a VPC and an Amazon S3 bucket is routing through an AWS Transit Gateway, an Amazon S3 Gateway Endpoint, or over the public internet. The administrator decides to create a custom VPC Flow Log to capture this information. Which custom log format field must the administrator include in the VPC Flow Log configuration to directly identify the routing path used by the traffic?

traffic-path

flow-direction

pkt-dstaddr

action

Show answer & explanation

Answer: traffic-path

Answer

traffic-path

The traffic-path custom field indicates the path taken by egress/ingress traffic (such as through an Internet Gateway, NAT Gateway, Transit Gateway, or VPC Endpoint) using specific integer codes, allowing the SysOps Administrator to directly verify the routing path.

Step-by-Step Solution

Analyze the requirements for identifying the routing mechanism (Transit Gateway, S3 Gateway Endpoint, or Internet Gateway) of the VPC traffic.

Identify that the default VPC Flow Logs format does not include specific routing metadata.

Default fields such as source/destination IP address and action do not explicitly indicate the path or gateway traversed by the packets.

Review the available custom VPC Flow Log fields that record routing metadata.

Identify the traffic-path field as the one that captures the egress or ingress transit path.

The traffic-path field records a single-digit integer representing the routing path (e.g., 1 for Internet Gateway, 5 for Transit Gateway, 7 for VPC Endpoint).

Select the correct field to configure in the custom log format.

The traffic-path field must be selected.

Including traffic-path directly resolves the administrator's requirement without needing complex reverse IP-to-resource lookups.

Key Concept

VPC Flow Logs Custom Format and Routing Paths

Estimated Time:1m 30s

Question 235Question →

A SysOps Administrator needs to deploy an application update to an AWS Elastic Beanstalk environment. The update must be completed as quickly as possible, and the application can tolerate a brief period of downtime during the deployment. Which deployment policy should the administrator choose?

All at once

Immutable

Rolling

Rolling with additional batch

Show answer & explanation

Answer: All at once

Answer

The All at once deployment policy is the correct choice because it deploys the new version to all instances at the same time, making it the fastest deployment option, despite causing service downtime.

The All at once deployment policy is the fastest deployment method in Elastic Beanstalk because it applies the update to all instances simultaneously. Since the application can tolerate downtime, this is the optimal choice to minimize deployment duration.

Step-by-Step Solution

Analyze the deployment requirements.

The requirements are: minimize deployment time (fastest speed) and tolerate temporary downtime.

This establishes the constraints that will be used to evaluate the deployment policies.

Evaluate the Elastic Beanstalk deployment policies against the constraints.

The All at once policy updates all instances at the same time, resulting in service interruption but the fastest possible deployment. Other policies (Immutable, Rolling, Rolling with additional batch) focus on maintaining service availability, which increases deployment time.

Matching the policy characteristics with the stated requirements identifies the correct strategy.

Key Concept

AWS Elastic Beanstalk Deployment Policies

Estimated Time:45s

Question 236Question →

An application runs on EC2 instances and streams its access logs to an Amazon CloudWatch Logs group. The logs are formatted as space-delimited text lines representing the timestamp, client IP address, request path, HTTP status code, and latency in milliseconds. Below is an example log event:

`1719264000 192.0.2.10 /orders/create 504 3500`

A SysOps administrator needs to set up an alarm to alert the operations team when requests to `/orders/create` experience a gateway timeout ( $504$ ) and take more than $3000\text{ ms}$ to complete. Which two actions should the administrator perform to configure this monitoring and alarm solution? (Select two.)

Select all that apply

Create a CloudWatch metric filter on the log group using the filter pattern `[timestamp, client_ip, request_path = "/orders/create", status_code = 504, latency > 3000]`, and set the metric value to

1

Create a CloudWatch alarm associated with the custom metric generated by the metric filter, defining the threshold to trigger when the count exceeds the acceptable limit.

Enable Detailed Monitoring on the EC2 instances hosting the application to ensure that the log-derived custom metric is evaluated at

1\text{-minute}

intervals.

Configure the log group retention period to

1

day to ensure that log events are processed by the custom metric filter at a faster ingestion rate.

Create an Amazon EventBridge rule that directly parses the space-delimited log patterns from the log stream and triggers an AWS Systems Manager Automation runbook to increment the custom metric.

Show answer & explanation

Answer: Create a CloudWatch metric filter on the log group using the filter pattern `[timestamp, client_ip, request_path = "/orders/create", status_code = 504, latency > 3000]`, and set the metric value to $1$ .; Create a CloudWatch alarm associated with the custom metric generated by the metric filter, defining the threshold to trigger when the count exceeds the acceptable limit.

Answer

To implement the monitoring and alarm solution, the administrator must create a CloudWatch metric filter using the space-delimited positional pattern `[timestamp, client_ip, request_path = "/orders/create", status_code = 504, latency > 3000]` with a metric value of

1

, and then create a CloudWatch alarm that monitors this custom metric and triggers when the threshold is exceeded.

The correct approach requires first extracting the relevant metric from the space-delimited log events using a CloudWatch Logs metric filter with the correct positional syntax and a metric value of

1

. After the custom metric is published, a CloudWatch alarm must be configured to monitor the custom metric and trigger notifications when the threshold is exceeded.

Step-by-Step Solution

Define the CloudWatch Logs metric filter pattern for space-delimited logs.

A pattern `[timestamp, client_ip, request_path = "/orders/create", status_code = 504, latency > 3000]` is constructed matching the fields in the log events.

The space-delimited syntax uses square brackets to list fields sequentially and filter them based on exact values or numeric comparisons.

Assign a metric value and publish the metric to a custom namespace.

The metric filter is configured with a metric value of

1

, which increments the metric for each matching log line.

Setting the metric value to

1

counts the occurrences of the matching pattern in the log stream.

Create a CloudWatch alarm based on the custom metric.

A CloudWatch alarm is created to evaluate the custom metric over a specified period and trigger when it exceeds

0

An alarm is needed to alert the operations team when the count of failed/slow requests exceeds the acceptable threshold.

Key Concept

Creating metric filters on space-delimited CloudWatch Logs and configuring alarms based on the resulting custom metrics.

Estimated Time:2m 0s

Question 237Question →

A SysOps Administrator is configuring automatic remediation for the AWS Config managed rule rds-instance-public-access-check. The remediation configuration is set to use the AWS-defined Systems Manager (SSM) Automation document AWS-DisablePublicAccessForRDSInstance. The administrator has created an IAM role named RDSRemediationRole with a trust policy that allows ssm.amazonaws.com to assume it. When attempting to save the remediation configuration in the AWS Config console, the operation fails with an authorization error. Which action should the SysOps Administrator take to resolve this issue?

Add an IAM policy containing the iam:PassRole permission for the RDSRemediationRole to the administrator's IAM identity.

Update the trust relationship of the RDSRemediationRole to allow the config.amazonaws.com service principal to assume the role.

Create an Amazon EventBridge rule that triggers on AWS Config compliance status changes to invoke the Systems Manager Automation document.

Attach the AWSServiceRoleForConfig service-linked role to the RDSRemediationRole trust policy to authorize the delegation.

Show answer & explanation

Answer: Add an IAM policy containing the iam:PassRole permission for the RDSRemediationRole to the administrator's IAM identity.

Answer

Add an IAM policy containing the iam:PassRole permission for the RDSRemediationRole to the administrator's IAM identity.

The correct answer is to add an IAM policy containing the iam:PassRole permission for the RDSRemediationRole to the administrator's IAM identity. When configuring an AWS service like AWS Config to pass an IAM role to another service like Systems Manager Automation, AWS validates that the user or role making the configuration has the iam:PassRole permission. Without this permission, the console or API returns an authorization error.

Step-by-Step Solution

Identify the service executing the remediation and the role being passed.

The AWS Config service uses the RDSRemediationRole to execute the Systems Manager Automation document AWS-DisablePublicAccessForRDSInstance.

Systems Manager needs to assume this role to execute the remediation actions on RDS.

Determine the permission required by the administrator to configure the role delegation.

The administrator must have the iam:PassRole permission for the RDSRemediationRole resource.

AWS prevents unauthorized users from passing powerful IAM roles to services by enforcing the iam:PassRole policy checks on the configuring identity.

Attach the appropriate IAM policy to the administrator's identity.

The administrator can successfully save the AWS Config remediation configuration.

Providing iam:PassRole satisfies the authorization check during remediation setup.

Key Concept

Configuring automatic remediation in AWS Config requires the configuring identity to have the iam:PassRole permission to delegate the remediation execution role to Systems Manager.

Estimated Time:2m 0s

Question 238Question →

An application logs HTTP requests to an Amazon CloudWatch Log Group in a space-delimited format:

`timestamp request_id client_ip api_endpoint status_code latency_ms`

Example log event:
`1783987200 req-98765 203.0.113.55 /checkout 503 1240`

A SysOps Administrator must monitor checkout transaction failures. The requirements are:
- A CloudWatch alarm must trigger if there are more than 5 failures (where `status_code` is 500 or greater) on the `/checkout` endpoint within a 5-minute period.
- The custom metric must record a value of 0 when checkout transactions are processed but do not result in a 5XX error, preventing the alarm from entering an `INSUFFICIENT_DATA` state.
- If there is no traffic to the `/checkout` endpoint at all (no logs written), the alarm must remain in an `OK` state.
- Log data must not be stored indefinitely to control AWS costs, with a maximum retention of 30 days.

Which configuration strategy should the SysOps Administrator implement to meet these requirements?

Configure the CloudWatch Log Group retention period to 30 days. Create a metric filter with the pattern `[timestamp, request_id, client_ip, api_endpoint = "/checkout", status_code >= 500, latency_ms]`, setting the metric value to 1 and the default value to 0. Create a CloudWatch alarm based on this metric with a threshold of 5, and set its TreatMissingData behavior to notBreaching.

Create a metric filter with the pattern `[timestamp, request_id, client_ip, api_endpoint = "/checkout", status_code >= 500, latency_ms]`, setting the metric value to 1 and the default value to 0. Leave the CloudWatch Log Group retention period at its default setting. Create a CloudWatch alarm on this metric with a threshold of 5, and configure its TreatMissingData behavior to missing.

Enable detailed monitoring on the EC2 instances hosting the application to support log-based custom metric publication. Create a metric filter with the pattern `[timestamp, request_id, client_ip, api_endpoint = "/checkout", status_code >= 500, latency_ms]`, setting the metric value to 1 and leaving the default value empty. Set the log group retention to 30 days. Create a CloudWatch alarm with a threshold of 5, and set its TreatMissingData behavior to notBreaching.

Create an Amazon EventBridge rule that triggers whenever any log event is written to the log group. Use an EventBridge input transformer to parse the log line for "/checkout" and status codes >= 500, then publish a custom metric to CloudWatch with a value of 1. Set the log group retention to 30 days. Create a CloudWatch alarm with a threshold of 5, and configure its TreatMissingData behavior to ignore.

Show answer & explanation

Answer: Configure the CloudWatch Log Group retention period to 30 days. Create a metric filter with the pattern `[timestamp, request_id, client_ip, api_endpoint = "/checkout", status_code >= 500, latency_ms]`, setting the metric value to 1 and the default value to 0. Create a CloudWatch alarm based on this metric with a threshold of 5, and set its TreatMissingData behavior to notBreaching.

Answer

The correct strategy involves setting the log group retention to 30 days to optimize storage costs, setting up a metric filter with the pattern `[timestamp, request_id, client_ip, api_endpoint = "/checkout", status_code >= 500, latency_ms]` to filter space-delimited log messages, setting the default value to 0 to keep the metric active with 0 values for healthy checkout requests (or non-matching logs), and configuring the alarm to treat missing data as notBreaching to handle zero-traffic periods safely.

Step-by-Step Solution

Set the log group retention period to 30 days.

Limits log storage duration, preventing indefinite retention costs in compliance with the cost requirement.

By default, log groups have an infinite retention period ('Never Expire'), which incurs ongoing storage charges unless explicitly configured.

Define the metric filter pattern for space-delimited logs and specify the metric transformation parameters.

A metric filter with the pattern `[timestamp, request_id, client_ip, api_endpoint = "/checkout", status_code >= 500, latency_ms]`, a metric value of 1, and a default value of 0 is created.

The pattern extracts status codes of 500 or greater for the '/checkout' endpoint. Setting the default value to 0 ensures that whenever any log event is written to the log group but does not match this failure pattern (i.e., healthy checkout requests or other endpoint requests), CloudWatch publishes a 0, keeping the metric populated and preventing false alarms.

Configure the CloudWatch alarm based on the custom metric.

An alarm is created with a threshold of 5 and TreatMissingData set to notBreaching.

If there is zero traffic and no logs are written at all, the metric filter is not executed, resulting in no data points. Setting TreatMissingData to notBreaching ensures the alarm remains in the OK state rather than transitioning to INSUFFICIENT_DATA or triggering falsely.

Key Concept

Configuring CloudWatch Logs metric filters for space-delimited log formats, utilizing metric default values to maintain continuous reporting, and setting alarm missing data behaviors to handle periods of zero traffic.

Question 239Question →

A SysOps Administrator is configuring VPC Flow Logs to capture traffic for a production VPC and deliver the logs to an Amazon S3 bucket. The S3 bucket is encrypted using an AWS Key Management Service (AWS KMS) customer managed key. After creating the flow log, the administrator notes that no log files are being written to the S3 bucket, and the flow log status shows delivery errors. Which two configurations must the administrator apply to resolve this issue?

Select all that apply

Update the Amazon S3 bucket policy to allow the delivery.logs.amazonaws.com service principal to perform the s3:PutObject and s3:GetBucketAcl actions.

Update the AWS KMS key policy to allow the delivery.logs.amazonaws.com service principal to perform the kms:GenerateDataKey action.

Associate an IAM service role with the flow log that has a trust policy for vpc-flow-logs.amazonaws.com and ensure the administrator has iam:PassRole permission.

Modify the Amazon S3 bucket lifecycle configuration to adjust log retention settings to prevent premature deletion of flow log files.

Create an Amazon EventBridge rule that detects flow log status changes and triggers an AWS Systems Manager Automation runbook to repair the log group stream.

Show answer & explanation

Answer: Update the Amazon S3 bucket policy to allow the delivery.logs.amazonaws.com service principal to perform the s3:PutObject and s3:GetBucketAcl actions.; Update the AWS KMS key policy to allow the delivery.logs.amazonaws.com service principal to perform the kms:GenerateDataKey action.

Answer

Update the Amazon S3 bucket policy to allow the delivery.logs.amazonaws.com service principal to perform the s3:PutObject and s3:GetBucketAcl actions, and update the AWS KMS key policy to allow the delivery.logs.amazonaws.com service principal to perform the kms:GenerateDataKey action.

When VPC Flow Logs are delivered to an Amazon S3 bucket, they use the AWS Log Delivery service principal (delivery.logs.amazonaws.com). The target S3 bucket policy must allow this principal to perform s3:PutObject and s3:GetBucketAcl. Additionally, if the bucket is encrypted with a customer managed AWS KMS key, the KMS key policy must allow the delivery.logs.amazonaws.com principal to use the key via kms:GenerateDataKey to encrypt the uploaded log files.

Step-by-Step Solution

Determine the destination and encryption requirements for VPC Flow Logs.

The destination is an Amazon S3 bucket encrypted with an AWS KMS customer managed key (SSE-KMS).

Identifying the log destination and encryption status dictates which resource-based policies must be modified.

Verify bucket policy requirements for the Log Delivery service principal.

The S3 bucket policy must explicitly grant s3:PutObject and s3:GetBucketAcl to the service principal delivery.logs.amazonaws.com.

AWS services write logs via the Log Delivery service principal, which needs write and permission-check rights on the target bucket.

Verify KMS key policy requirements for the Log Delivery service principal.

The KMS key policy for the customer managed key must grant the delivery.logs.amazonaws.com service principal permissions to perform kms:GenerateDataKey.

Since the target bucket uses SSE-KMS, the Log Delivery service needs permissions to generate data keys using that customer managed key to encrypt the logs before writing them to the bucket.

Key Concept

VPC Flow Logs S3 delivery with KMS encryption requires both bucket policy write permissions and KMS key policy generate data key permissions for the Log Delivery service principal.

Question 240Question →

An AWS CloudFormation stack update fails, and the stack becomes stuck in the `UPDATE_ROLLBACK_FAILED` state because a Security Group resource cannot be deleted. Which of the following actions can a SysOps Administrator take to successfully complete the rollback of the stack? (Select TWO.)

Select all that apply

Manually resolve the dependency that prevents the Security Group from being deleted, then choose Continue update rollback in the AWS CloudFormation console.

Run the `continue-update-rollback` command using the AWS CLI and specify the logical ID of the Security Group in the resources to skip parameter.

Change the stack policy to allow all updates, then use the `aws cloudformation rollback-stack` command to force the rollback to complete.

Delete the stack template from the local workspace and deploy it as a new nested stack using the `aws cloudformation deploy` command.

Modify the stack's service role to grant the `iam:PassRole` permission to the Security Group, then run drift detection on the stack.

Show answer & explanation

Answer: Manually resolve the dependency that prevents the Security Group from being deleted, then choose Continue update rollback in the AWS CloudFormation console.; Run the `continue-update-rollback` command using the AWS CLI and specify the logical ID of the Security Group in the resources to skip parameter.

Answer

To resolve the failed rollback, the administrator must either manually remove the dependency that blocks the Security Group from being deleted and then continue the rollback, or execute the continue-update-rollback action and specify the Security Group to be skipped.

The correct options describe the two supported methods for resolving a stack rollback failure in AWS CloudFormation. The administrator can manually resolve the dependency blocking the resource deletion (such as detaching the Security Group from an EC2 instance launched outside the stack) and then select the 'Continue update rollback' option. Alternatively, the administrator can bypass the blocker by using the AWS CLI `continue-update-rollback` command with the `--resources-to-skip` parameter to omit the blocked Security Group.

Step-by-Step Solution

Inspect the CloudFormation stack events to find the resource causing the rollback failure.

Identify that the Security Group cannot be deleted, placing the stack in the UPDATE_ROLLBACK_FAILED state.

This determines which specific resource is blocking the stack rollback operation.

Choose whether to fix the dependency manually (e.g., disassociating the Security Group from any active network interfaces) or skip the resource during the rollback.

Decide on a path to either satisfy the deletion constraint or bypass it.

CloudFormation requires either the underlying issue to be resolved or explicit permission to skip the failed resource.

Trigger the 'Continue update rollback' process via the AWS Console or the AWS CLI.

The stack completes the rollback and returns to a stable UPDATE_ROLLBACK_COMPLETE or ROLLBACK_COMPLETE state.

This resumes the rollback operation and brings the stack back to a manageable state.

Key Concept

When an AWS CloudFormation stack enters the UPDATE_ROLLBACK_FAILED state, it cannot be updated or modified until the rollback is resolved. This state is resolved by using the Continue Update Rollback action, either after fixing the blocking dependency manually or by skipping the blocked resources.

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