Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company is rolling out a new version of its website. Management wants to deploy the new website in a limited rollout to 20% of the company's customers. The company uses Amazon Route 53 fo...
Let's evaluate the options to meet the requirement of deploying a new website version to 20% of the company's customers using Amazon Route 53:
Option A: Create a failover routing policy.
- Explanation: A failover routing policy is used for high-availability purposes, where one resource is primary (active) and the other is a secondary (backup). In this option, 80% of traffic is directed to the original resource, and 20% is directed to the failover resource.
- Why it's not the best choice: Failover routing is designed for handling primary and secondary resources, where the failover resource is only used when the primary is unavailable. It is not meant for a controlled 20% rollout. This would be operationally inefficient for a non-failover use case and doesn’t allow precise traffic distribution.
- Rejection Reason: Failover routing is not suitable for controlled traffic distribution.
Option B: Create a multivalue answer routing policy.
- Explanation: A multivalue answer routing policy allows multiple records to be returned in response to DNS queries. However, it does not allow for precise traffic distribution or weighting based on percentages like the scenario requires. The policy would return multiple IP addresses in random order, but this doesn’t guarantee that 20% of traffic would reach the new resource as required.
- Why it's not the best choice: This option does not provide the fine control needed for routing exactly 20% of traffic to the new website version. It’s more suited for high availability and distributing DNS responses without strict traffic percentage control.
- Rejection Reason: Multivalue routing does not allow precise traffic distribution percentages.
Option C: Create a latency-based routing policy.
- Explanation: Latency-based...
Author: Leo · Last updated May 8, 2026
A SysOps administrator created an AWS CloudFormation template that provisions Amazon EC2 instances, an Elastic Load Balancer (ELB), and an Amazon RDS DB instance. During stack creation, the creation of the EC2 instances and the creation of the ELB are successful. H...
Let's analyze the default behavior of AWS CloudFormation in the scenario where the creation of the DB instance fails during stack creation:
Option A: CloudFormation will roll back the stack and delete the stack.
- Explanation: When a resource fails to create during the stack creation process, CloudFormation rolls back the entire stack by default. This means CloudFormation attempts to undo any resources it successfully created, including the EC2 instances and the ELB, effectively deleting the entire stack.
- Why it’s correct: The default behavior in CloudFormation is to automatically roll back the entire stack if any resource creation fails. This ensures that the stack remains in a consistent and clean state, with no partially created resources left in place.
- Rejection Reason: This is the correct default behavior.
Option B: CloudFormation will roll back the stack but will not delete the stack.
- Explanation: CloudFormation does roll back the stack when a failure occurs, but the term "delete the stack" in this context is misleading. Rolling back means removing all the resources that were created up to the point of failure, and the stack itself is deleted in the process. CloudFormation does not leave the stack definition itself intact in the console if it fails during creation.
- Why it’s not correct: This is not the correct description because CloudFormation deletes the stack entirely during rollback if the creati...
Author: RadiantJaguar56 · Last updated May 8, 2026
A SysOps administrator needs to automate the invocation of an AWS Lambda function. The Lambda function must run at the end of each day to generate a report on data that is stored in an Amazon S3 bucke...
To determine the most operationally efficient solution for automating the invocation of an AWS Lambda function to generate a report at the end of each day based on data in an S3 bucket, let's evaluate each option:
Option A: Create an Amazon EventBridge (Amazon CloudWatch Events) rule that has an event pattern for Amazon S3 and the Lambda function as a target.
- Explanation: EventBridge (formerly CloudWatch Events) can be used to trigger Lambda functions in response to specific events. However, an event pattern for Amazon S3 typically responds to object-level changes (like `ObjectCreated` or `ObjectDeleted`). This solution would not fit the requirement of running the Lambda function at the end of each day to generate a report. It’s better suited for real-time event-driven actions based on specific S3 events.
- Why it’s not the best option: EventBridge in this case is not designed for scheduling tasks based on a time trigger, and it would not meet the requirement of running the Lambda function daily at a specific time.
Option B: Create an Amazon EventBridge (Amazon CloudWatch Events) rule that has a schedule and the Lambda function as a target.
- Explanation: EventBridge (CloudWatch Events) allows you to set up scheduled rules using cron expressions or rate expressions. A cron expression can be configured to trigger the Lambda function at the end of each day. This solution is highly operationally efficient because it fully automates the process of invoking the Lambda function on a fixed schedule, without any manual intervention.
- Why it’s the best choice: This option meets the requirement to run the Lambda function at the end of each day, and it does so in a highly automated and cost-effective way. EventBridge's scheduling capabilities are designed for this type of time-based automation.
- Rejection Reason: None. This i...
Author: Ella · Last updated May 8, 2026
A company is releasing a new static website hosted on Amazon S3. The static website hosting feature was enabled on the bucket and content was uploaded; however, upon navigating to the site, the following error message ...
In this scenario, the website is hosted on Amazon S3, and the error "403 Forbidden - Access Denied" typically indicates that there are permission issues preventing public access to the content stored in the S3 bucket. To resolve this, the correct approach would be to ensure that the correct permissions are granted to allow public access to the bucket's objects.
Let's analyze each option:
Option A: Add a bucket policy that grants everyone read access to the bucket.
- This option would grant read access to the bucket itself. However, it's important to note that access to the bucket itself isn't sufficient for website access — the individual objects within the bucket also need to be accessible. Therefore, this option is not sufficient, as it doesn’t cover the object-level access required for website content.
Option B: Add a bucket policy that grants everyone read access to the bucket objects.
- Correct choice. This option would grant public read access to the objects stored within the S3 bucket. For a static website hosted on S3, the web browser needs access to the content files (like HTML, CSS, JavaScript, images) stored in the bucket. Granting read access to the objects ensures the browser can retrieve and display these files, making the website accessible.
- This option is the most appropriate solution because it allows public access to the contents (objects) of the bucket, not just the bucket itself, ensuring the static...
Author: FlamePhoenix2025 · Last updated May 8, 2026
A company uses AWS Organizations. A SysOps administrator wants to use AWS Compute Optimizer and AWS tag policies in the management account to govern all member accounts in the billing family. The SysOps administrator navigates to the AWS Organizations conso...
Let's break down the possible causes and analyze the options:
Option A: All features have not been enabled in the organization.
- Correct choice. In AWS Organizations, there are two main feature sets: "All Features" and "Consolidated Billing". Tag policies, as well as services like AWS Compute Optimizer, require "All Features" to be enabled in the organization. If the organization is still in the "Consolidated Billing" feature set (the default), then tag policies cannot be activated, and services like Compute Optimizer might also be restricted in terms of organization-wide governance.
- If the "All Features" setting is not enabled, certain policies and services will not be available at the organization level, preventing the administrator from activating tag policies.
- Therefore, Option A is the correct answer because enabling "All Features" would allow the SysOps administrator to manage tag policies and compute optimizations across the entire organization.
Option B: Consolidated billing has not been enabled.
- Consolidated billing is part of AWS Organizations but is a separate feature from "All Features." It is not directly related to the ability to activate tag policies. You can have consolidated billing enabled while still being on the "Consolidated Billing" feature set (not the full "All Features" set).
- Even if consolidated billing is enabled, "All Features" still need to be enabled to use tag policies, and this would not solve the issue. Therefore, ...
Author: Rohan · Last updated May 8, 2026
A company is storing media content in an Amazon S3 bucket and uses Amazon CloudFront to distribute the content to its users. Due to licensing terms, the company is not authorized to distribute the content in some countries. A SysOps administrator must restrict ...
To address the requirement of restricting access to certain countries due to licensing terms, let's analyze each option in detail:
Option A: Configure the S3 bucket policy to deny the GetObject operation based on the S3:LocationConstraint condition.
- This option is not ideal because the S3:LocationConstraint condition is used to restrict access based on the AWS region in which the S3 bucket resides, not the geographic location of the user. This means that the S3 bucket policy cannot directly restrict access based on the user's country. Therefore, this option does not meet the requirement to restrict access based on country and is not appropriate for this scenario.
Option B: Create a secondary origin access identity (OAI). Configure the S3 bucket policy to prevent access from unauthorized countries.
- The OAI is useful for controlling access to the S3 bucket content through CloudFront, but the solution suggests modifying the S3 bucket policy to prevent access from certain countries. However, S3 policies alone do not have a native way to restrict access based on the country of the requester. This makes it operationally complex and less efficient, as managing geographic restrictions at the S3 bucket level is not straightforward. CloudFront geo-restrictions would be more efficient for restricting access based on geographic locations, so this approach is not ideal.
Option C: Enable the geo restriction feature in the CloudFront distribution to prevent access from unauthorized countries.
- Correct choice. CloudFront provides a geo-restriction feature that allows the distribution of content to be restricted based on the ...
Author: StarryEagle42 · Last updated May 8, 2026
A SysOps administrator created an Amazon VPC with an IPv6 CIDR block, which requires access to the internet. However, access from the internet towards the VPC is prohibited. After adding and configuring the required components to the VPC, the administrator is unable to connect to any of the do...
In this scenario, the administrator has created a VPC with an IPv6 CIDR block and needs to enable internet access for resources in that VPC. However, the current routing configuration is preventing access to the internet. Let's review each option carefully to determine the correct solution.
Option A: Route ::/0 traffic to a NAT gateway.
- Incorrect choice. A NAT Gateway is typically used for IPv4 traffic, allowing instances in a private subnet to access the internet while preventing inbound internet traffic. Since the VPC is using IPv6 and the issue relates to IPv6 traffic, a NAT Gateway would not help with IPv6 routing. Therefore, this option is not applicable in the context of IPv6 and is rejected.
Option B: Route ::/0 traffic to an internet gateway.
- Correct choice. The `::/0` route represents all IPv6 traffic (essentially, it is the IPv6 equivalent of `0.0.0.0/0` for IPv4). To allow instances in the VPC to connect to the internet, the administrator needs to route all IPv6 traffic (`::/0`) through an internet gateway. This allows outgoing traffic to reach the internet, and incoming traffic will also be routed correctly. Since the VPC is configured with an IPv6 CIDR block, the internet gateway is the correct component for allowing both incoming and outgoing IPv6 traffic.
- The internet ...
Author: Leo · Last updated May 8, 2026
A company hosts several write-intensive applications. These applications use a MySQL database that runs on a single Amazon EC2 instance. The company asks a SysOps administrator to implement a highly available database solution that is ideal for mult...
Let's analyze the available options based on the requirements of a highly available database solution that can handle multi-tenant workloads for write-intensive applications.
Option A: Create a second EC2 instance for MySQL. Configure the second instance to be a read replica.
- Incorrect choice. While this option may provide read scalability (with one instance acting as a read replica), it does not address high availability for write-intensive workloads. In case of a failure on the primary EC2 instance, the read replica cannot automatically handle write operations or become the primary instance without manual intervention. This setup does not meet the requirements for automatic failover, which is critical for high availability.
- This option is also not ideal for multi-tenant workloads since there is no inherent automatic failover mechanism, and managing the replication could become complex.
Option B: Migrate the database to an Amazon Aurora DB cluster. Add an Aurora Replica.
- Partially correct choice, but not the best fit. Amazon Aurora is a highly scalable, fully managed relational database service that can handle high throughput and offers replicas for read scaling. However, this option only specifies the addition of a read replica. Aurora replicas can help with read scalability, but they do not handle high availability or failover for write-intensive workloads on their own.
- Aurora does provide automatic failover in the event of a failure of the primary instance, but using just one primary instance and adding replicas primarily focuses on read scalability. The requirement for high availability with write capacity is not fully addressed by this setup.
Option C: Migrate the database to an Amazon Aurora multi-master DB cluster.
...
Author: Noah · Last updated May 8, 2026
A company has a memory-intensive application that runs on a fleet of Amazon EC2 instances behind an Elastic Load Balancer (ELB). The instances run in an Auto Scaling group. A SysOps administrator must ensure that the application can scale base...
To determine the most appropriate solution for ensuring the application can scale based on the number of users, we need to analyze each option, considering the factors such as resource utilization (CPU, memory), how users connect to the application, and how Auto Scaling works with Amazon EC2 instances.
Option A: Create a scaling policy that will scale the application based on the ActiveConnectionCount Amazon CloudWatch metric that is generated from the ELB.
- Reasoning: The ActiveConnectionCount metric from the Elastic Load Balancer provides the number of active connections to the application at any given time. This is a useful metric to determine the load on the application, as the number of active connections directly correlates with the number of users interacting with the app.
- Advantages: This is the most relevant metric to monitor the application’s scaling needs based on user traffic. When the number of connections increases, scaling can occur dynamically, ensuring the app handles the load.
- Why Rejected: N/A (this option is valid).
Option B: Create a scaling policy that will scale the application based on the mem_used Amazon CloudWatch metric that is generated from the ELB.
- Reasoning: The `mem_used` metric is related to memory usage on the EC2 instances. While this metric can indicate when an instance is under memory pressure, it is not directly tied to the number of users. Memory usage could increase due to a variety of reasons, not just because of users connecting to the application (e.g., memory leaks, inefficient code).
- Advantages: Helps ensure that the system has enough memory to handle the load.
- Why Rejected: It doesn’t directly correlate with the number of users. It’s better suited for monitoring resource limits on individual EC2 instances, not fo...
Author: Nathan · Last updated May 8, 2026
A SysOps administrator creates a new VPC that includes a public subnet and a private subnet. The SysOps administrator successfully launches 11 Amazon EC2 instances in the private subnet. The SysOps administrator attempts to launch one more EC2 instance in the same subnet. However, the SysOps administrator receives an error...
To address the issue of not having enough free IP addresses to launch more EC2 instances in the private subnet, we need to consider the causes and possible solutions. The error indicates that the current subnet has run out of available IP addresses.
Option A: Edit the private subnet to change the CIDR block to /27.
- Reasoning: The CIDR block size determines the number of IP addresses available in a subnet. A subnet with a `/28` CIDR block provides 16 IP addresses (with some reserved for networking purposes), and if 11 EC2 instances have already been launched, there may not be enough IP addresses remaining. By changing the subnet’s CIDR block to `/27`, the subnet would have 32 IP addresses, which is a larger pool of addresses.
- Advantages: This solution increases the available IP addresses within the existing subnet.
- Why Rejected: This option might not be possible if the subnet was initially created with a smaller CIDR block that cannot be resized. Modifying an existing subnet's CIDR block could involve significant network changes or might not be allowed in some cases.
Option B: Edit the private subnet to extend across a second Availability Zone.
- Reasoning: Subnets are confined to a single Availability Zone, and while extending to another Availability Zone can provide high availability, it doesn't directly address the issue of IP address scarcity in the current Availability Zone.
- Advantages: This can provide additional fault tolerance and availability, but it doesn’t solve the issue of running out of IP addresses in the current subnet.
- Why Rejected: Adding another Availability Zone doesn't increase the IP address space for...
Author: Ming88 · Last updated May 8, 2026
A company needs to automatically monitor an AWS account for potential unauthorized AWS Management Console logins from multiple geograph...
To monitor unauthorized AWS Management Console logins from multiple geographic locations, we need a solution that can track user logins, detect anomalies in login patterns (such as logins from multiple regions), and trigger alerts based on suspicious activities. Let's evaluate the provided options:
Option A: Configure Amazon Cognito to detect any compromised IAM credentials.
- Reasoning: Amazon Cognito is primarily used for user authentication and authorization, especially for applications and services that need user management. While it can detect compromised user credentials within its own domain, it doesn’t directly monitor AWS Management Console logins or multiple geographic logins across AWS accounts.
- Why Rejected: This solution does not provide monitoring capabilities for AWS account-wide console logins or geographic anomalies related to IAM users or AWS Management Console access.
Option B: Set up Amazon Inspector. Scan and monitor resources for unauthorized logins.
- Reasoning: Amazon Inspector is a security assessment service designed to identify vulnerabilities in EC2 instances and container workloads, but it doesn't focus on monitoring IAM users' activities, such as login attempts to the AWS Management Console.
- Why Rejected: While Amazon Inspector is great for vulnerability management and resource scanning, it does not address login monitoring or geographic anomalies related to user access in the AWS Management Console.
Option C: Set up AWS Config. Add the iam-policy-blacklisted-check managed rule to the account.
- Reasoning: AWS Config ...
Author: ElectricLionX · Last updated May 8, 2026
A company has an Amazon RDS DB instance. The company wants to implement a caching service while maintaining high availability.
Which combi...
The company wants to implement a caching service while maintaining high availability for its Amazon RDS DB instance. To meet these requirements, we need to consider both caching solutions and high availability options for the caching service.
Let's evaluate each option:
Option A: Add Auto Discovery to the data store.
- Reasoning: Auto Discovery is a feature primarily used with Amazon ElastiCache for Redis. It allows clients to automatically discover the primary and replica nodes of a Redis cluster, ensuring that the application can dynamically adjust to changes in the cluster topology.
- Advantages: Auto Discovery is useful for applications that require automatic failover handling without manual intervention when node changes occur. However, this option alone does not address the core requirement of implementing a caching service with high availability, especially since it’s a feature specific to Redis.
- Why Rejected: While Auto Discovery is useful for Redis, it doesn’t specifically address the core requirement of maintaining high availability for the caching service by itself. The high availability feature would be covered by using Multi-AZ and the right caching service.
Option B: Create an Amazon ElastiCache for Memcached data store.
- Reasoning: Amazon ElastiCache for Memcached is a managed in-memory caching service, but it doesn’t support features like persistence or replication for high availability. Memcached is more suited for simple caching scenarios where high availability and fault tolerance are not critical.
- Advantages: Memcached is fast and simple, but it lacks advanced features like automatic failover, replication, and persistence.
- Why Rejected: Memcached doesn't meet the high availability requirement, as it does not support automatic failover or replication like Redis does. For high availability, Redis is a better fit.
Option C: Create an Amazon ElastiCache for Redis data store.
- Reasoning: Amazon ElastiCache for Redis supports advanced caching features such as persistence, replication, and automatic failover. It...
Author: Charlotte · Last updated May 8, 2026
A company monitors its account activity using AWS CloudTrail, and is concerned that some log files are being tampered with after the logs have been delivered to the account's Amazon S3 bucket.
Moving forward, how can the SysOps ad...
To ensure the integrity of CloudTrail logs and confirm that they have not been tampered with after being delivered to the S3 bucket, we need a mechanism that verifies the authenticity of the log files and detects any modification.
Let's evaluate each option:
Option A: Stream the CloudTrail logs to Amazon CloudWatch Logs to store logs at a secondary location.
- Reasoning: While streaming CloudTrail logs to CloudWatch Logs provides a secondary storage option for logs, it does not offer a method to verify the integrity of the logs or prevent tampering in the original S3 bucket.
- Advantages: CloudWatch Logs can provide monitoring and alerting on log activities.
- Why Rejected: It does not address the core issue of ensuring that logs in the S3 bucket have not been tampered with. The logs could still be altered in the S3 bucket, and no validation is provided for integrity.
Option B: Enable log file integrity validation and use digest files to verify the hash value of the log file.
- Reasoning: CloudTrail's log file integrity validation feature allows you to verify that the log files have not been modified after they have been delivered to the S3 bucket. CloudTrail generates digest files (hash values) for each log file, and you can use these digest files to check the integrity of the logs by comparing the hash values of the delivered logs.
- Advantages: This feature specifically addresses the concern of log file tampering by providing a mechanism to validate that the log files have not been altered. It ensures the logs' integrity by using cryptographic hash functions.
- Why Selected: This is the most direct and secure solution for confirming that the logs have not been modified after delivery to the S3 bucket.
Opti...
Author: Ryan · Last updated May 8, 2026
A SysOps administrator is reviewing AWS Trusted Advisor warnings and encounters a warning for an S3 bucket policy that has open access permissions. While discussing the issue with the bucket owner, the administrator realizes the S3 bucket is an origin for an Amazon CloudFront web distribution....
To ensure that users access objects in Amazon S3 only through CloudFront URLs, the administrator should restrict direct access to the S3 bucket and allow access only via CloudFront. This can be achieved by using an Origin Access Identity (OAI), which is a special CloudFront feature that associates with the distribution and grants CloudFront access to the S3 bucket while blocking public access.
Let’s evaluate the options:
A) Encrypt the S3 bucket content with Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3).
- Why it’s not selected: Encrypting the S3 content with SSE-S3 provides security at the data level, ensuring that data is encrypted when stored. However, it does not control access to the objects or ensure that they are accessed only via CloudFront URLs. The focus here is on access control, not encryption.
B) Create an origin access identity and grant it permissions to read objects in the S3 bucket.
- Why it’s selected: This is the correct action. By creating an Origin Access Identity (OAI) and granting it permission to read objects in the S3 bucket, you ensure that only CloudFront can access the S3 bucket directly. This prevents direct public access to the S3 bucket, which is cr...
Author: Ahmed · Last updated May 8, 2026
A SysOps administrator is reviewing AWS Trusted Advisor recommendations. The SysOps administrator notices that all the application servers for a finance application are listed in the Low Utilization Amazon EC2 Instances check. The application runs on three instances across three Availability Zones. The SysOps administrator must reduce...
The goal is to reduce the cost of running the application without affecting its availability or design. Let’s evaluate each option:
A) Reduce the number of application servers.
- Why it’s not selected: Reducing the number of application servers would impact the availability and redundancy of the application. The application runs on three instances across three Availability Zones, which is designed for high availability. Removing instances would reduce this availability and resilience. Therefore, this option does not meet the requirement of not affecting the application's availability or design.
B) Apply rightsizing recommendations from AWS Cost Explorer to reduce the instance size.
- Why it’s selected: Rightsizing involves adjusting the instance size to match the actual usage and performance needs of the application. If the instances are underutilized, AWS Cost Explorer can recommend reducing the instance size. This solution reduces costs without compromising availability or functionality, as it ensures the instances are not oversized for the workload they handle. This is an efficient cost optimization method without any adverse effect on the design.
C) Provision an Application Load Balancer in front of the instances.
- Why it’s not selected: The application already...
Author: Sophia Clark · Last updated May 8, 2026
A company hosts its website in the us-east-1 Region. The company is preparing to deploy its website into the eu-central-1 Region. Website visitors who are located in Europe should access the website that is hosted in eu-central-1. All other visitors access the website that is hosted in us-east-1. The company uses Amazon Route 53 to man...
To meet the requirements of directing website visitors based on their location (Europe to eu-central-1 and all others to us-east-1), the SysOps administrator needs to choose the appropriate Amazon Route 53 routing policy that can ensure traffic is routed based on geographic location. Let's evaluate each option:
A) Geolocation routing policy
- Why it’s selected: The Geolocation routing policy allows Route 53 to route traffic based on the geographic location of the DNS query. This is exactly what the company needs, as it can route visitors located in Europe to the website hosted in the eu-central-1 Region, while routing all other visitors to the website hosted in us-east-1. This method directly addresses the requirement of directing traffic based on the user's geographic location.
B) Geoproximity routing policy
- Why it’s not selected: The Geoproximity routing policy is used when routing traffic based on the proximity of the user to the resources, and it allows for adjusting traffic flow based on geographic regions and resource weights. It is primarily useful for controlling traffic based on proximity to specific endpoints, but in this case, the company wants traffic routed based on the region (Europe vs. other locations). The geolocation policy is a better fi...
Author: Emma · Last updated May 8, 2026
An organization with a large IT department has decided to migrate to AWS. With different job functions in the IT department, it is not desirable to give all users access to all AWS resources. Currently the organization handles access ...
In this scenario, the organization wants to continue using its existing LDAP group membership for access control while migrating to AWS. The goal is to maintain current authentication methods and avoid giving broad access to all AWS resources for every user. Let's evaluate each option:
A) Create an AWS Directory Service Simple AD. Replicate the on-premises LDAP directory to Simple AD.
- Why it’s not selected: While AWS Directory Service with Simple AD can integrate with existing directories, it is typically used for managing users and groups in AWS-managed Active Directory environments. However, Simple AD does not natively support fine-grained access control to AWS resources in a way that integrates seamlessly with IAM roles or policies. This option doesn’t fully address the need to manage access control to AWS resources based on LDAP group membership.
B) Create a Lambda function to read LDAP groups and automate the creation of IAM users.
- Why it’s not selected: While it’s possible to use a Lambda function to automate IAM user creation based on LDAP group membership, this approach introduces complexity and requires ongoing maintenance. Additionally, it doesn’t provide a direct way to federate existing LDAP credentials for authentication, which would make the process cumbersome for the organization. A better approach is to integrate with IAM through a federated identity system rather than manually managing users and permissions via Lambda.
C) Use AWS CloudFormation to create IAM roles. Deploy Direct Connect to allow access to the on-premises LDAP server.
- ...
Author: Liam · Last updated May 8, 2026
A SysOps administrator has created an Amazon EC2 instance using an AWS CloudFormation template in the us-east-1 Region. The administrator finds that this template has failed to create ...
The issue here is related to the CloudFormation template failing to create an EC2 instance in the us-west-2 Region, while it successfully created one in the us-east-1 Region. Let's evaluate each possible cause:
A) Resource tags defined in the CloudFormation template are specific to the us-east-1 Region.
- Why it’s not selected: Resource tags are metadata attached to resources and can be created in any region where the resource exists. Tags are region-agnostic in terms of their structure—they will exist as long as the resources are created in the respective region. The failure of creating an EC2 instance in us-west-2 is not likely due to tags, as this would not prevent the creation of the instance itself.
B) The Amazon Machine Image (AMI) ID referenced in the CloudFormation template could not be found in the us-west-2 Region.
- Why it’s selected: The AMI ID used in the template might be specific to the us-east-1 Region. Each AWS region has its own set of AMI IDs, and an AMI ID from us-east-1 would not exist in us-west-2 unless it was specifically copied to that region. If the CloudFormation template refers to an AMI that is available only in us-east-1, the creation of the EC2 instance in us-west-2 would fail because the AMI cannot be found in the target region. This is a common cause of failure when launching EC2 i...
Author: Lucas Carter · Last updated May 8, 2026
A global gaming company is preparing to launch a new game on AWS. The game runs in multiple AWS Regions on a fleet of Amazon EC2 instances. The instances are in an Auto Scaling group behind an Application Load Balancer (ALB) in each Region. The company plans to use Amazon Route 53 for DNS services. The DNS configuration must direct users to the Region that is closest to them an...
To solve this scenario, we need to meet the following key requirements:
1. Direct users to the closest region: This ensures that users are routed to the region nearest to them for low latency and optimal performance.
2. Automated failover: This ensures that if one region experiences an issue, traffic is routed to a healthy region automatically.
Let's go through the options step by step:
Option A: Create Amazon CloudWatch alarms that monitor the health of the ALB in each Region. Configure Route 53 DNS failover by using a health check that monitors the alarms.
- Explanation: This option suggests creating CloudWatch alarms to monitor the Application Load Balancer (ALB), and then configuring Route 53 failover based on those alarms. Monitoring the health of the ALB is a good idea since it provides a clear picture of the health of the infrastructure for serving requests, including the underlying EC2 instances. If the ALB is healthy, it indicates that the service in that region is healthy. Using this with a DNS failover configuration ensures that Route 53 can route traffic away from unhealthy regions.
- Why it’s correct: Monitoring the ALB is a valid approach because it represents a higher-level service that includes checks on both the network layer and the application layer. By using a health check tied to ALB health, we can trigger automated failover when an entire region's infrastructure fails (i.e., the ALB stops responding).
Option B: Create Amazon CloudWatch alarms that monitor the health of the EC2 instances in each Region. Configure Route 53 DNS failover by using a health check that monitors the alarms.
- Explanation: This option focuses on monitoring individual EC2 instances in each region using CloudWatch alarms. While it could technically work, this approach may not be ideal since it’s less comprehensive than monitoring the ALB itself. If a single EC2 instance fails, this could trigger failover even if the region as a whole remains operational, leading to unnecessary failover.
- Why it’s rejected: Monitoring EC2 instances individually is not optimal because failure of a single instance might not imply a complete region failure. The ALB's health check is a better indicator for regional failure, as it tracks whether the entire load-balancing and application-serving layer is operational.
Option C: Configure Route 53 DNS failover by using a health check that monitors the private IP ...
Author: Daniel · Last updated May 8, 2026
A SysOps administrator is investigating a company's web application for performance problems. The application runs on Amazon EC2 instances that are in an Auto Scaling group. The application receives large traffic increases at random times throughout the day. During periods of rapid traffic increases, the Auto Scaling group is not adding capacity fast enough. As a result, users are experiencing poor performance.
The company wants to minimize costs without adversely affecting the user experience when web traffic surges quickly. The compa...
The goal in this scenario is to address rapid traffic increases effectively while minimizing costs and ensuring that the Auto Scaling group adds more capacity for larger traffic increases and fewer instances for smaller traffic increases.
Let's analyze the options:
Option A: Create a simple scaling policy with settings to make larger adjustments in capacity when the system is under heavy load.
- Explanation: A simple scaling policy involves defining a specific threshold (e.g., CPU usage or network traffic) and an associated action (e.g., scale up by a fixed number of instances). However, simple scaling policies are less flexible and don’t allow for fine-grained control over the scaling behavior when the load varies significantly. They will add or remove a fixed number of instances, regardless of whether the traffic increase is small or large.
- Why it’s rejected: Simple scaling policies are too basic to meet the requirement of making larger adjustments when there's a significant increase in traffic. They don’t differentiate between large and small traffic surges effectively.
Option B: Create a step scaling policy with settings to make larger adjustments in capacity when the system is under heavy load.
- Explanation: Step scaling policies allow you to define multiple thresholds and corresponding actions, where the number of instances added or removed depends on the severity of the traffic increase. This is more advanced than simple scaling policies because it allows you to scale more aggressively (i.e., add more instances) when the load is high and scale more conservatively when the load is moderate.
- Why it’s selected: Step scaling gives more control over how the Auto Scaling group responds to varying traffic levels. You can configure step scaling to add more capacity for large traffic increases and fewer instances for smaller traffic increases, meeting the company's requirement. This approach is the best fit for handling varying traffic patterns and optimizing resource al...
Author: ShadowWolf101 · Last updated May 8, 2026
A company has a compliance requirement that no security groups can allow SSH ports to be open to all IP addresses. A SysOps administrator must implement a solution that will notify the company's SysOps team when a security group rule violates this requirement. The s...
To meet the requirement of notifying the SysOps team and automatically remediating non-compliant security group rules, the solution needs to be able to:
1. Detect when a security group rule violates the compliance requirement (e.g., allowing SSH ports to be open to all IP addresses).
2. Notify the SysOps team of the violation.
3. Automatically remediate the non-compliant rule (i.e., remove the rule allowing SSH access from all IPs).
Let's evaluate the options:
Option A: Create an Amazon EventBridge (Amazon CloudWatch Events) rule that invokes an AWS Lambda function when a security group changes. Configure the Lambda function to evaluate the security group for compliance, remove all inbound security group rules on all ports, and notify the SysOps team if the security group is noncompliant.
- Explanation: This option uses Amazon EventBridge to monitor security group changes and invokes a Lambda function to evaluate compliance. The Lambda function then removes all inbound rules for all ports (which is overkill) and notifies the SysOps team.
- Why it’s rejected: Removing all inbound security group rules on all ports is too broad and could disrupt legitimate configurations of the security groups. Additionally, the Lambda function's logic seems too aggressive as it will remove all rules, not just the non-compliant SSH rule.
Option B: Create an AWS CloudTrail metric filter for security group changes. Create an Amazon CloudWatch alarm to notify the SysOps team through an Amazon Simple Notification Service (Amazon SNS) topic when the metric is greater than 0. Subscribe an AWS Lambda function to the SNS topic to remediate the security group rule by removing the rule.
- Explanation: This option uses AWS CloudTrail to capture security group changes and CloudWatch alarms to notify the team when a change occurs. The Lambda function is subscribed to the SNS topic and performs remediation by removing the violating rule.
- Why it’s rejected: While this option does use CloudTrail and CloudWatch alarms effectively, the proposed Lambda function simply removes the rule. However, it doesn't provide sufficient control or scope to ensure that only the non-compliant rule is removed (i.e., SSH access from all IP addresses) without possibly removing other necessary rules.
Option C: Activate the AWS Config restricted-ssh managed rule. Add automatic remediation to the AWS Config rule by using the AWS Systems Manager Automation AWS-DisablePublicAccessForSecurityGroup runbook. Create an Amazon EventBridge (Amazon Cl...
Author: Sam · Last updated May 8, 2026
A company has an application that runs only on Amazon EC2 Spot Instances. The instances run in an Amazon EC2 Auto Scaling group with scheduled scaling actions. However, the capacity does not always increase at the scheduled times, and instances terminate many times a day. A SysOps administr...
To ensure that EC2 instances are launched on time and experience fewer interruptions while running in an Auto Scaling group with Spot Instances, we need to consider strategies that reduce the likelihood of interruptions, particularly Spot Instance terminations, and improve the reliability of capacity scaling.
Let's evaluate each option:
Option A: Specify the capacity-optimized allocation strategy for Spot Instances. Add more instance types to the Auto Scaling group.
- Explanation: The capacity-optimized allocation strategy is designed to prioritize Spot Instances in the most stable capacity pools, which reduces the chances of interruptions due to capacity shortages. By adding more instance types to the Auto Scaling group, you increase the available capacity and flexibility, helping ensure that the instances can launch and scale even during high-demand periods.
- Why it's selected: This option addresses both issues—ensuring that Spot Instances are launched in stable capacity pools (which reduces interruptions) and providing more flexibility with multiple instance types. This combination increases the likelihood that instances will be available when needed, improving both the on-time scaling and reducing interruptions.
Option B: Specify the capacity-optimized allocation strategy for Spot Instances. Increase the size of the instances in the Auto Scaling group.
- Explanation: While the capacity-optimized allocation strategy helps with fewer Spot Instance interruptions, increasing the size of the instances does not directly address the root cause of the problem—instance terminations. Additionally, larger instances may not necessarily reduce the chance of interruptions unless more stable capacity pools are available for larger instance types.
- Why it’s rejected: Increasing the instance size does not directly mitigate interruptions. It would only change the size of the individual instances but doesn’t impact the underlying Spot Instance availability or the ...
Author: Lina Zhang · Last updated May 8, 2026
A company plans to deploy a database on an Amazon Aurora MySQL DB cluster. The database will store data for a demonstration environment. The data must be reset on a daily basis.
W...
The goal here is to find an operationally efficient solution for resetting the data in an Amazon Aurora MySQL DB cluster on a daily basis. The solution must minimize administrative overhead while ensuring that the data is reset every day for the demonstration environment.
Let’s evaluate each option:
Option A: Create a manual snapshot of the DB cluster after the data has been populated. Create an Amazon EventBridge (Amazon CloudWatch Events) rule to invoke an AWS Lambda function on a daily basis. Configure the function to restore the snapshot and then delete the previous DB cluster.
- Explanation: This option involves creating a manual snapshot and using EventBridge to trigger a Lambda function daily to restore the snapshot and delete the previous DB cluster.
- Why it’s rejected: While this approach can work, it introduces unnecessary complexity with deleting the previous DB cluster. Additionally, manual snapshots require extra management, and there’s potential for errors in the restoration or deletion process. It is not the most efficient method in terms of both operational overhead and automation.
Option B: Enable the Backtrack feature during the creation of the DB cluster. Specify a target backtrack window of 48 hours. Create an Amazon EventBridge (Amazon CloudWatch Events) rule to invoke an AWS Lambda function on a daily basis. Configure the function to perform a backtrack operation.
- Explanation: The Backtrack feature allows you to roll back the database to a previous state. In this case, it would allow you to go back to the state from the start of the previous day. However, the backtrack window would need to be set up in a way that keeps the history for 48 hours, and this may not always align with the daily reset requirement.
- Why it’s rejected: Backtrack works well for undoing changes, but it has limitations in terms of the granularity and operational efficiency for daily resets. It might not be ideal for resetting the database state to a clean state as it could involve a longer and more complex setup, especially if the backtrack window is not precisely aligned with the required time frame.
Option C: Export a manual snapshot of the DB cluster to an Amazon S3 bucke...
Author: Sophia · Last updated May 8, 2026
A SysOps administrator is setting up an automated process to recover an Amazon EC2 instance in the event of an underlying hardware failure. The recovered instance must have the same private IP address and the same Elastic IP address that the original instance had. The SysOps team m...
Let's break down each option to determine which best meets the given requirements:
Key Requirements:
- Recover the EC2 instance in the event of an underlying hardware failure.
- Maintain the same private IP address and Elastic IP address.
- Send an email notification to the SysOps team when recovery is initiated.
Option A: CloudWatch Alarm for StatusCheckFailed_Instance
- Explanation: This option uses an Amazon CloudWatch alarm with the `StatusCheckFailed_Instance` metric. If an instance fails the status check, the alarm will trigger an EC2 recovery action. Additionally, an SNS notification is sent to alert the SysOps team.
- Private IP/Elastic IP Handling: This option does not directly address the issue of maintaining the same private IP address and Elastic IP address after recovery. While CloudWatch alarms can trigger recovery, there is no guarantee the instance will be recovered with the same IPs.
- Notification: The SNS notification to the SysOps team works, which satisfies part of the notification requirement.
- Why it's not ideal: Although it helps with recovery through EC2 instance action, it doesn't explicitly address the need for the same private IP address and Elastic IP address.
Option B: CloudWatch Alarm for StatusCheckFailed_System
- Explanation: This option uses a CloudWatch alarm with the `StatusCheckFailed_System` metric. This checks for system-level failures (such as issues with underlying hardware) and can trigger an EC2 recovery action. SNS notification is also included.
- Private IP/Elastic IP Handling: Like Option A, this option does not ensure that the instance is recovered with the same private IP and Elastic IP addresses. EC2 recovery actions do not automatically guarantee that the original IP configurations will persist.
- Notification: Similar to Option A, the alarm sends an SNS notification to the SysOps team, fulfilling the notification requirement.
- Why it's not ideal: Again, it doesn’t guarantee that the instance will retain the original private IP or Elastic IP address upon recovery.
Option C: Auto S...
Author: Ming · Last updated May 8, 2026
A company has a public website that recently experienced problems. Some links led to missing webpages, and other links rendered incorrect webpages. The application infrastructure was running properly, and all the provisioned resources were healthy. Application logs and dashboards did not show any errors, and no monitoring alarms were raised. Systems administrators were not aware of any problems until end users reported the issues.
The company needs to...
Let’s break down each option based on the requirements: to proactively monitor the website for issues and minimize operational overhead.
Key Factors to Consider:
- Proactive monitoring: The solution must automatically detect website issues before end users report them.
- Low operational overhead: The solution should not require complex maintenance or manual intervention.
- Real-time alerting: Alerts should be triggered when issues occur, even if application logs and dashboards are not reporting errors.
Option A: Custom Error Logging and CloudWatch Alarm
- Explanation: This option suggests rewriting the application to log custom errors and then setting up CloudWatch to parse logs and trigger alarms when errors are detected.
- Proactive monitoring: This is more reactive because it requires the application to log errors first, which may not catch all issues (such as missing or incorrect webpages) immediately.
- Operational overhead: This requires modifying the application, adding custom error handling, and continuously parsing logs, which adds complexity and maintenance overhead.
- Why it's not ideal: It's not an ideal proactive monitoring solution, as it requires the application itself to recognize and log errors, which may not cover all types of issues (like broken links or rendering errors). It also adds development and maintenance overhead.
Option B: AWS Lambda Function to Test the Website
- Explanation: This option involves creating an AWS Lambda function to periodically test the website, emitting a CloudWatch custom metric for errors, and setting up alarms.
- Proactive monitoring: This can be a proactive monitoring solution, as the Lambda function can be configured to check for errors on the website.
- Operational overhead: While Lambda is scalable, it still requires writing and maintaining custom test scripts. This solution is more complex than necessary for simply monitoring website availability and correctness.
- Why it's not ideal: While it provides the ability to test the website, it involves more operational ov...
Author: Arjun · Last updated May 8, 2026
A SysOps administrator is responsible for a company's security groups. The company wants to maintain a documented trail of any changes that are made to the security groups. The SysOps administrator must receive noti...
Let's evaluate each option based on the requirements:
1. Maintain a documented trail of changes: We need a solution that records changes to security groups and stores those changes for auditing.
2. Notification of changes: The SysOps administrator must be notified whenever a security group change occurs.
3. Minimal operational overhead: The solution should not require excessive management or maintenance.
Option A: Amazon Detective for Security Group Changes
- Explanation: Amazon Detective is designed for security investigations, not configuration management. While it helps with analyzing security incidents or identifying potential security issues, it is not tailored for recording configuration changes like security group modifications.
- Documenting changes: Detective does not provide the ability to store a documented trail of configuration changes or security group modifications.
- Notification: While you could set up an SQS queue for notifications, Amazon Detective does not have the capability to track and notify changes to security groups.
- Why it's not ideal: This option is not designed for tracking configuration changes and does not meet the need for monitoring security group modifications.
Option B: AWS Systems Manager Change Manager for Security Group Changes
- Explanation: AWS Systems Manager Change Manager is a service for tracking and managing infrastructure changes across your AWS environment. It allows for change management workflows, but it's typically used for managing changes to EC2 instances, patches, and configuration management. It is not specifically intended for tracking changes to security groups.
- Documenting changes: While Change Manager can document changes, it's not specifically designed for monitoring security groups.
- Notification: SNS notifications can be set up for changes, but this option isn't as direct or ...
Author: Manish · Last updated May 8, 2026
An ecommerce company has built a web application that uses an Amazon Aurora DB cluster. The DB cluster includes memory optimized instance types with both a writer node and a reader node. Traffic volume changes throughout the day. During sudden traffic surges, Amazon CloudWatch metrics for the DB cluster indicate high RAM consumption and an increase in select latency.
A SysOps administrator must implement a configu...
Let’s evaluate each option in terms of the requirements: improving the performance of the Amazon Aurora DB cluster during traffic surges, minimizing downtime, and ensuring no data loss.
Key Requirements:
1. Improve performance: High RAM consumption and increased select latency need to be addressed.
2. Minimize downtime: The solution should have minimal impact on application availability.
3. No data loss: Changes should not result in data loss.
Option A: Add an Aurora Replica to the DB cluster
- Explanation: Adding an Aurora Replica can help with performance by offloading read queries to the replica, reducing the load on the writer node. Aurora Replicas are read-only copies of the database that can help improve read scalability.
- Improve performance: Adding an Aurora Replica could alleviate pressure on the writer node by handling read-heavy traffic, but it does not address the high RAM consumption on the writer node during surges.
- Minimize downtime: Adding an Aurora Replica is a non-disruptive operation, and it minimizes downtime.
- No data loss: Since this is a read-only replica, no data loss occurs.
- Why it’s not ideal: Although it helps with read scaling, this does not directly address the high RAM consumption and select latency on the writer node, which are primarily due to the write-heavy traffic or insufficient memory resources.
Option B: Modify the DB cluster to convert the DB cluster into a multi-master DB cluster
- Explanation: A multi-master DB cluster allows both nodes to handle read and write traffic, potentially improving write scalability. However, this configuration can be complex to manage and comes with trade-offs related to conflict resolution and data consistency.
- Improve performance: Multi-master clusters can improve scalability in write-heavy workloads by distributing write operations across multiple nodes.
- Minimize downtime: Converting to a multi-master DB cluster involves more complexity and could result in some downtime during the transition.
- No data loss: The change would not cause data loss, but there is an increased risk of conflicts in multi-master setups.
- Why it’s not ideal: This change introduces complexity, increased ...
Author: Ahmed97 · Last updated May 8, 2026
A company has a simple web application that runs on a set of Amazon EC2 instances behind an Elastic Load Balancer in the eu-west-2 Region. Amazon Route 53 holds a DNS record for the application with a simple routing policy. Users from all over the world access the application through their web browsers.
The company needs to create additional copies of the application in the us-east-1 Region and in the ap-south-1 Region. The ...
Let's analyze each option in detail to determine which one best meets the requirements of directing users to the Region with the fastest response times:
Key Requirements:
- Multiple Regions: The application needs to be available in three regions: eu-west-2 (existing), us-east-1, and ap-south-1.
- Fastest response times: Users should be directed to the Region that provides the fastest response times.
- Routing based on performance: The solution should direct traffic to the region with the best performance (lowest latency).
Option A: In each new Region, create a new Elastic Load Balancer and a new set of EC2 instances to run a copy of the application. Transition to a geolocation routing policy.
- Explanation: A geolocation routing policy in Amazon Route 53 routes traffic based on the user's geographic location (e.g., Europe, North America, etc.).
- How it meets requirements: The geolocation policy will route users based on where they are located, but it does not necessarily direct users to the fastest region in terms of latency. For example, users from Europe might be routed to the eu-west-2 region, even if us-east-1 is faster.
- Why it’s not ideal: Geolocation routing ensures traffic is routed to specific regions based on the user's location, not based on latency or performance. The company needs a solution that chooses the region with the fastest response time, not just the region closest to the user.
Option B: In each new Region, create a copy of the application on new EC2 instances. Add these new EC2 instances to the Elastic Load Balancer in eu-west-2. Transition to a latency routing policy.
- Explanation: This option suggests adding EC2 instances from other regions (us-east-1 and ap-south-1) to the existing Elastic Load Balancer in eu-west-2 and using latency-based routing in Route 53.
- How it meets requirements: Latency routing directs traffic to the region with the lowest network latency. However, all EC2 instances should ideally be registered with a load balancer in the region where they reside. Adding EC2 instances from different regions into the same load balancer in eu-west-2 is not supported by Elastic Load Balancing. Therefore, this solution is not technically feasible.
- Why it’s not ideal: This configuration...
Author: Aria · Last updated May 8, 2026
A company creates a new member account by using AWS Organizations. A SysOps administrator needs to add AWS Business Support to the new account.
Which combination of steps...
In order to add AWS Business Support to a new account that was created using AWS Organizations, the SysOps administrator needs to take specific actions based on AWS policies for managing support plans. Here is an analysis of the options:
Option A: Sign in to the new account by using IAM credentials. Change the support plan.
- Rejected: While signing in as an IAM user is possible, IAM users do not have the required permissions to modify the AWS Support plan. Only the root user or users with specific permissions related to billing can modify the support plan. Therefore, this option is not valid.
Option B: Sign in to the new account by using root user credentials. Change the support plan.
- Selected: The root user has full permissions in an AWS account, including the ability to modify the AWS Support plan. Therefore, signing in as the root user and changing the support plan is a valid and appropriate step to enable AWS Business Support for the new account.
Option C: Use the AWS Support API to change the support plan.
- Rejected: Changing the support plan via the AWS Support API is not the preferred or typical method to add AWS Business Suppo...
Author: Emma · Last updated May 8, 2026
A SysOps administrator creates two VPCs, VPC1 and VPC2, in a company's AWS account The SysOps administrator deploys a Linux Amazon EC2 instance in VPC1 and deploys an Amazon RDS for MySQL DB instance in VPC2. The DB instance is deployed in a private subnet. An application that runs on the EC2 instance needs t...
To allow the EC2 instance in VPC1 to connect to the Amazon RDS for MySQL DB instance in VPC2, the SysOps administrator needs to establish network connectivity between the two VPCs. Let’s analyze the options provided:
Option A: Enter the DB instance connection string into the VPC1 route table.
- Rejected: The route table does not handle connection strings; it manages network routes between subnets and VPCs. To allow traffic between VPCs, you need to establish proper routing (e.g., via peering, VPN, etc.) but entering the connection string in the route table is not the right approach. Route tables help direct traffic based on IP addresses, not connection strings.
Option B: Configure VPC peering between the two VPCs.
- Selected: VPC peering allows communication between two VPCs. When you set up VPC peering, you can configure routing between the VPCs to enable the EC2 instance in VPC1 to connect to the RDS instance in VPC2. After peering the VPCs, the SysOps administrator would also need to modify the route tables to allow traffic to flow between the two VPCs. This option i...
Author: CrimsonViperX · Last updated May 8, 2026
A company uses an Amazon S3 bucket to store data files. The S3 bucket contains hundreds of objects. The company needs to replace a tag on all the objects in the S3 bucket with another...
To replace a tag on all objects in an Amazon S3 bucket with another tag, the most operationally efficient way should minimize manual intervention, scale automatically, and use AWS native features. Let's evaluate each option:
Option A: Use S3 Batch Operations. Specify the operation to replace all object tags.
- Selected: S3 Batch Operations is designed to handle large-scale object management tasks like applying operations on multiple objects at once. You can specify a batch operation to replace tags on all objects in the S3 bucket, which is straightforward and scalable. This is the most operationally efficient option because it handles everything in a single, automated step without needing manual intervention or separate commands.
Option B: Use the AWS CLI to get the tags for each object. Save the tags in a list. Use S3 Batch Operations. Specify the operation to delete all object tags. Use the AWS CLI and the list to retag the objects.
- Rejected: This option requires multiple manual steps, including using the AWS CLI to get the tags and saving them in a list. While it involves S3 Batch Operations for deleting tags, it still requires separate steps to retag the objects manually using the CLI. This introduces unnecessary complexity and is not as efficient as Option A, which can replace the tags directly in one operation.
Option C: U...
Author: Lina Zhang · Last updated May 8, 2026
A company needs to take an inventory of applications that are running on multiple Amazon EC2 instances. The company has configured users and roles with the appropriate permissions for AWS Systems Manager. An updated version of Systems Manager Agent has been installed and is running on every instance. While configuring an inventory collection, a SysOps admini...
In this scenario, the issue is that not all Amazon EC2 instances in a single subnet are being managed by AWS Systems Manager, even though the Systems Manager Agent is installed and running on every instance. Let’s evaluate the options to understand which one is most appropriate for fixing this issue.
Option A: Ensure that all the EC2 instances have the correct tags for Systems Manager access.
- Rejected: While tags can be useful for identifying resources, they are not the core requirement for enabling Systems Manager to manage EC2 instances. The ability of Systems Manager to manage an instance is primarily determined by whether the instance has the proper IAM role (instance profile) and the necessary permissions, not by its tags. Therefore, this option does not address the root cause of the issue.
Option B: Configure AWS Identity and Access Management (IAM) Access Analyzer to determine and automatically remediate the issue.
- Rejected: IAM Access Analyzer helps identify permissions issues related to IAM roles, policies, and resource access. However, this tool is not designed to resolve connectivity or configuration issues specifically related to Systems Manager, such as the lack of required IAM instance profiles or missing networking configuration. It is not the most appropriate tool for addressing EC2 instance management by Systems Manager.
Option C: Ensure that all the EC2 instances have an instance profile with Systems M...
Author: Liam · Last updated May 8, 2026
A company stores sensitive data in an Amazon S3 bucket. The company must log all access attempts to the S3 bucket. The company's risk team must receive immediate notificati...
Let's evaluate each option based on the requirements:
- Requirement 1: Log all access attempts to the S3 bucket.
- Requirement 2: Notify the risk team immediately when a delete event occurs.
Option A: Enable S3 server access logging for audit logs. Set up an Amazon Simple Notification Service (Amazon SNS) notification for the S3 bucket. Select DeleteObject for the event type for the alert system.
- Rejected: S3 server access logging logs requests made to the bucket, but it does not provide real-time notifications for specific events like `DeleteObject`. SNS can be set up to notify on specific events, but for delete events specifically, you would need S3 Event Notifications configured, not just server access logging. This option doesn't meet the real-time notification requirement for delete events.
Option B: Enable S3 server access logging for audit logs. Launch an Amazon EC2 instance for the alert system. Run a cron job on the EC2 instance to download the access logs each day and scan for a DeleteObject event.
- Rejected: While this method could theoretically work, it’s not operationally efficient. It involves manually scanning logs on an EC2 instance, which introduces unnecessary complexity and a delay (scanning logs daily, not in real time). This approach doesn’t provide immediate notifications for delete events and would be more resource-intensive than necessary.
Option C: Use Amazon CloudWatch Logs for audit logs. Use Amazon CloudWatch alarms with an Amazon Simple Notification Servi...
Author: Victoria · Last updated May 8, 2026
A SysOps administrator receives an alert from Amazon GuardDuty about suspicious network activity on an Amazon EC2 instance. The GuardDuty finding lists a new external IP address as a traffic destination. The SysOps administrator does not recognize the external IP address. The SysOps adminis...
To address the situation where a SysOps administrator receives a suspicious alert from Amazon GuardDuty about an EC2 instance and wants to block traffic to an external IP address, let's evaluate the options:
A) Create a new security group to block traffic to the external IP address. Assign the new security group to the EC2 instance.
- Explanation: Security groups in AWS are stateful, and they act as a virtual firewall to control inbound and outbound traffic for EC2 instances. However, security groups operate based on traffic that is allowed, not specifically blocked. They cannot be used to block traffic to specific IP addresses directly. You can allow traffic from certain IPs, but a security group does not provide a direct way to deny traffic to an IP.
- Why rejected: Since security groups are based on "allow" rules and do not allow for direct "deny" rules for specific IPs, this approach is not ideal for blocking a suspicious IP address.
B) Use VPC flow logs with Amazon Athena to block traffic to the external IP address.
- Explanation: VPC Flow Logs allow you to capture information about the IP traffic going to and from network interfaces in your VPC. Amazon Athena can be used to query and analyze flow logs. However, while you can identify suspicious traffic using this approach, it does not directly block or control traffic. Athena is mainly a tool for querying data, not for taking action to block traffic.
- Why rejected: This approach involves monitoring and analyzing traffic but does not provide a way to block the traffic. Thus, it does not meet the requirement to block traf...
Author: Ava · Last updated May 8, 2026
A company's reporting job that used to run in 15 minutes is now taking an hour to run. An application generates the reports. The application runs on Amazon EC2 instances and extracts data from an Amazon RDS for MySQL database.
A SysOps administrator checks the Amazon CloudWatch dashboard for the RDS instance and notices that the Read IOPS metrics are high, even when the reports...
To address the performance issue where a reporting job has gone from 15 minutes to 1 hour and high Read IOPS metrics are noticed even when reports are not running, let's evaluate each solution:
A) Configure an Amazon ElastiCache cluster in front of the RDS instance. Update the reporting job to query the ElastiCache cluster.
- Explanation: ElastiCache is typically used for caching data, which can reduce the load on a database by serving frequently accessed data from the cache. However, the reporting job would need to be modified to query ElastiCache, which may not necessarily help if the application relies on up-to-date data from the database. While ElastiCache can speed up some queries by caching results, it doesn't directly address the high IOPS issue on the RDS instance, and it may require significant changes to the application to use cache data properly.
- Why rejected: This solution is more suited for reducing load on frequently accessed, static data rather than solving the issue of high Read IOPS in a transactional database. ElastiCache isn't a good fit for an application that requires up-to-date database queries.
B) Deploy an RDS read replica. Update the reporting job to query the reader endpoint.
- Explanation: An RDS read replica is a good solution for offloading read-heavy operations from the primary database. By creating a read replica, you can direct the reporting job to the reader endpoint, which can reduce the load on the primary RDS instance. This helps in reducing the high Read IOPS on the main RDS instance by distributing read traffic across the primary and read replica instances.
- Why accepted: This solution directly addresses the high Read IOPS issue by distributing read traffic across a read replica. It will improve the performance of the reporting job without modifying the application significantly and will also enhance the availability of the database. Read replicas are designed to handle read-heavy w...
Author: Emma · Last updated May 8, 2026
A company's SysOps administrator regularly checks the AWS Personal Health Dashboard in each of the company's accounts. The accounts are part of an organization in AWS Organizations. The company recently added 10 more accounts to the organization. The SysOps administrator must consolidate the ale...
Evaluating each option:
A) Enable organizational view in AWS Health.
- Explanation: Enabling the organizational view in AWS Health allows a consolidated view of health events across all accounts within the organization. This allows the SysOps administrator to view and monitor all the health events from multiple accounts in one place without needing to check each individual account's Personal Health Dashboard.
- Why selected: This solution directly provides the consolidated view of the Personal Health Dashboard for all accounts in the AWS organization with minimal setup and effort. Enabling this feature is very straightforward and does not require additional development or configuration. It's the easiest and most efficient way to meet the requirement.
B) Configure the Personal Health Dashboard in each account to forward events to a central AWS CloudTrail log.
- Explanation: CloudTrail logs AWS API activity, including changes to resources in your AWS environment. However, it does not provide a consolidated view of health events. Configuring CloudTrail to log Personal Health Dashboard events would be complex, as CloudTrail is not designed to capture specific health alerts. Also, aggregating and interpreting the logs would require additional processing.
- Why rejected: This option is unnecessarily complicated. It would require additional setup and would not provide a consolidated view of health events in a user-friendly way, making it less ideal compared to enabling the organizational view in AWS Health.
C) Create an AWS Lambda function to query the AWS Health API and to write al...
Author: Ravi Patel · Last updated May 8, 2026
A company runs an application on Amazon EC2 instances. The EC2 instances are in an Auto Scaling group and run behind an Application Load Balancer (ALB). The application experiences errors when total requests exceed 100 requests per second. A SysOps administrator must collect information about total requests fo...
Evaluating each option:
A) Use the ALB's RequestCount metric. Configure a time range of 2 weeks and a period of 1 minute. Examine the chart to determine peak traffic times and volumes.
- Explanation: The RequestCount metric from the Application Load Balancer (ALB) in CloudWatch provides a count of the total requests handled by the ALB. This metric can be used to monitor the total number of requests per second (or minute) over time. By setting a time range of 2 weeks and a period of 1 minute, the SysOps administrator can examine when traffic exceeded 100 requests per second and determine peak traffic times and volumes.
- Why selected: This solution is straightforward because it leverages existing CloudWatch metrics for the ALB. The ALB already tracks request counts, so there is no need for custom metrics or complex configurations. The time range and period can be configured to capture the desired 2-week window, making it an efficient way to gather the necessary data.
B) Use Amazon CloudWatch metric math to generate a sum of request counts for all the EC2 instances over a 2-week period. Sort by a 1-minute interval.
- Explanation: While using metric math to aggregate data from individual EC2 instances could be useful, this solution is more complex than necessary. The ALB already provides the RequestCount metric, which is aggregated across all instances behind the load balancer. Creating custom math formulas for EC2 instances adds unnecessary complexity without providing any additional benefit.
- Why rejected: Since the ALB already provides an aggregate request count, there's no need to calculate this manually from EC2 instances. This method introduces extra effort without improving the accuracy or utility of the data.
C...
Author: Rohan · Last updated May 8, 2026
A company recently migrated its application to a VPC on AWS. An AWS Site-to-Site VPN connection connects the company's on-premises network to the VPC. The application retrieves customer data from another system that resides on premises. The application uses an on-premises DNS server to resolve domain records. After the migration, the application is not able to c...
Evaluating each option:
A) Launch EC2 instances in the VPC. On the EC2 instances, deploy a custom DNS forwarder that forwards all DNS requests to the on-premises DNS server. Create an Amazon Route 53 private hosted zone that uses the EC2 instances for name servers.
- Explanation: In this option, EC2 instances would act as a DNS forwarder to forward DNS queries to the on-premises DNS server. You would also create a Route 53 private hosted zone to manage domain records within the VPC. While this solution could work, it requires the creation and management of EC2 instances, which introduces additional complexity and cost.
- Why rejected: This solution involves managing EC2 instances and DNS forwarding, adding complexity and operational overhead. It's more labor-intensive than needed, as there are simpler options for DNS resolution.
B) Create an Amazon Route 53 Resolver outbound endpoint. Configure the outbound endpoint to forward DNS queries against the on-premises domain to the on-premises DNS server.
- Explanation: Amazon Route 53 Resolver outbound endpoints allow you to forward DNS queries from your VPC to an on-premises DNS server. This solution is designed specifically to address DNS resolution issues when an application in AWS needs to resolve domain names from an on-premises DNS server.
- Why selected: This is the most appropriate and efficient solution. Route 53 Resolver handles DNS forwarding seamlessly, eliminating the need for custom EC2 instances or additional configurations. It's a fully managed, scalable solution with minimal operational overhead. It directly addresses the problem of name resolution for the application that depends on the on-premises DNS server.
C) Set up two AWS Direct Connect connections between the AWS environment and the on-premises network. Set up a link aggregation group (LAG) that includes the two connections. Change the VPC re...
Author: Madison · Last updated May 8, 2026
A company's web application is available through an Amazon CloudFront distribution and directly through an internet-facing Application Load Balancer (ALB). A SysOps administrator must make the application accessible only through the CloudFront distribution and not directly through the ALB. The S...
To meet the requirement of ensuring that the web application is accessible only through the Amazon CloudFront distribution and not directly through the internet-facing Application Load Balancer (ALB), let’s evaluate each option:
Option A: Modify the ALB type to internal. Set the distribution's origin to the internal ALB domain name.
- Reasoning: Changing the ALB type to internal would restrict direct access to the ALB from the internet. By setting the origin in CloudFront to the internal ALB, CloudFront will act as a proxy to the ALB. This method ensures that the application is only accessible through CloudFront.
- Pros: This is a simple and effective solution, as it prevents direct access to the ALB, and CloudFront can handle all incoming traffic.
- Cons: The primary drawback here is that this would change the ALB's public-facing nature, which may not be desirable if the ALB was originally intended to handle direct traffic for specific cases or needs.
- Suitable Scenario: This is useful if the goal is to completely hide the ALB behind CloudFront and there are no other specific needs for direct access to the ALB.
- Rejection: This option changes the ALB to internal, which may not be appropriate for all use cases if the ALB was designed to handle other traffic directly.
Option B: Create a Lambda@Edge function. Configure the function to compare a custom header value in the request with a stored password and forward the request to the origin in case of a match. Associate the function with the distribution.
- Reasoning: Using Lambda@Edge to validate a custom header and conditionally forward the request based on that header is a valid solution. The Lambda function would intercept incoming requests to CloudFront, check for the custom header, and only allow requests with the correct value to be forwarded to the ALB.
- Pros: Flexible solution, highly customizable, and adds an extra layer of security by verifying a custom header before passing the request to the ALB.
- Cons: It adds complexity because of the Lambda function and header validation logic. It also requires additional resources (Lambda@Edge) and can result in higher operational overhead.
- Suitable Scenario: This solution is suitable when you want to implement more granular control and are comfortable managing the custom logic with Lambda.
- Rejection: This adds unnecessary complexity if the goal is to simply ensure CloudFront-only access to the ALB. It introduces custom logic and requires careful management.
Option C: Replace the ALB with a new internal ALB. Set the distribution's origin to the internal ALB domain name. Add a custom HTTP header to the origin settings for the distribution. In the ALB listener, add a rule to forward requests that contain the matching custom header and the header's value. A...
Author: GlowingTiger · Last updated May 8, 2026
A company runs several workloads on AWS. The company identifies five AWS Trusted Advisor service quota metrics to monitor in a specific AWS Region. The company wants to receive email notification each time resource us...
Let's evaluate each option based on the requirement to monitor five AWS Trusted Advisor service quota metrics and receive email notifications when usage exceeds 60%:
Option A: Create five Amazon CloudWatch alarms, one for each Trusted Advisor service quota metric. Configure an Amazon Simple Notification Service (Amazon SNS) topic for email notification each time that usage exceeds 60% of one of the service quotas.
- Reasoning: Amazon CloudWatch is the correct service for monitoring AWS resources, including service quotas. By creating CloudWatch alarms for each Trusted Advisor service quota metric, you can set thresholds for when resource usage exceeds 60%. Once the alarm is triggered, it can send notifications via an Amazon SNS topic to an email address.
- Pros: This approach is direct and efficient. CloudWatch alarms are designed specifically for monitoring metrics and can easily trigger notifications to an SNS topic. SNS is a scalable and flexible service for sending notifications, and it integrates seamlessly with CloudWatch.
- Cons: None, as this is the intended solution for monitoring metrics and sending notifications.
- Suitable Scenario: This is the most suitable option as it directly addresses the requirement of monitoring service quota usage and sending email notifications when thresholds are exceeded.
- Selected Option: This is the best option.
Option B: Create five Amazon CloudWatch alarms, one for each Trusted Advisor service quota metric. Configure an Amazon Simple Queue Service (Amazon SQS) queue for email notification each time that usage exceeds 60% of one of the service quotas.
- Reasoning: While CloudWatch alarms can trigger an SQS queue, SQS is typically used for queuing and processing messages rather than sending direct notifications. SQS would require additional steps (e.g., setting up an application to read the queue and send the email), which adds unnecessary complexity compared to using SNS directly.
- Pros: SQS is reliable for message queuing and decoupling services.
- Cons: Adding SQS introduces unnecessary complexity because it requires additional components (such as a process to read the queue and send emails), making this solution more cumbersome for the task at hand.
- Suitable Scenario: This could be used in scenarios wher...
Author: Olivia · Last updated May 8, 2026
A company needs to implement a managed file system to host Windows file shares for users on premises. Resources in the AWS Cloud also need access to the data on these file shares. A SysOps administrator needs to present the user file shares on premises and make the user fil...
To meet the requirement of hosting Windows file shares for users on-premises while also making the file shares available on AWS with minimum latency, let's analyze each option:
Option A: Set up an Amazon S3 File Gateway.
- Reasoning: Amazon S3 File Gateway is part of AWS Storage Gateway, which allows on-premises applications to store data in Amazon S3 by presenting an NFS or SMB interface. While this option provides a way to access data in S3 from on-premises, it does not natively support Windows file shares (SMB) with the low latency required by the workload. It is more suited for applications that work with object storage in S3, rather than providing a Windows file system.
- Pros: S3 File Gateway is good for data backup and archival to S3 but does not meet the requirement of hosting a managed file system with Windows file shares.
- Cons: It doesn't support a fully managed Windows file system, and it introduces unnecessary complexity for just sharing files with Windows-based workloads.
- Suitable Scenario: This is better for applications needing access to S3 storage via SMB or NFS, not for a full file share service across both on-premises and AWS.
- Rejection: Does not meet the requirement of providing Windows file shares with low latency.
Option B: Set up an AWS Direct Connect connection.
- Reasoning: AWS Direct Connect provides a dedicated network connection between on-premises infrastructure and AWS. While it can improve network performance and reduce latency, it does not directly address the need for hosting and managing file shares. You would still need a separate service to manage the file shares themselves (such as Amazon FSx or an on-premises file server).
- Pros: Direct Connect offers reliable, low-latency connectivity between on-premises data centers and AWS.
- Cons: It does not provide a file system solution or a way to host and manage Windows file shares. It is purely a network connectivity solution.
- Suitable Scenario: Direct Connect is useful if you already have an appropriate file system solution and need low-latency connectivity, but it doesn't directly help with managing or sharing file systems.
- Rejection: Does not provide a file system; it’s a network solution.
Option C: Use AWS DataSync to automate data transfers between the existing file servers and AWS.
- Reasoning: AWS DataSync is a service used to automate data transfer between on...
Author: Vikram · Last updated May 8, 2026
A company is hosting applications on Amazon EC2 instances. The company is hosting a database on an Amazon RDS for PostgreSQL DB instance. The company requires all connections to the DB instance...
To meet the requirement of ensuring all connections to the Amazon RDS for PostgreSQL DB instance are encrypted, let’s analyze each option based on the requirements:
Option A: Allow SSL connections to the database by using an inbound security group rule.
- Reasoning: While security groups control the network access to the RDS instance, they do not control or enforce whether the connections are encrypted. They are simply used to allow or deny traffic based on IP addresses or ports. Enabling SSL encryption for database connections is unrelated to the security group configuration.
- Pros: Security groups are essential for controlling access to RDS instances, but they do not influence whether the connections themselves are encrypted.
- Cons: This option does not address the requirement of enforcing encrypted database connections.
- Rejection: This does not meet the need to enforce encrypted connections to the database.
Option B: Encrypt the database by using an AWS Key Management Service (AWS KMS) encryption key.
- Reasoning: While encrypting the database at rest using AWS KMS provides encryption for the data stored in the RDS instance (data-at-rest encryption), it does not affect the encryption of connections (data-in-transit). This option is related to the storage encryption, not the encryption of network traffic between the application and the database.
- Pros: This option ensures that data is encrypted at rest, which is a good security practice.
- Cons: It does not address the requirement of ensuring that database connections themselves are encrypted.
- Rejection: This option does not fulfill the requirement of encrypting database connections (data-in-transit).
Option C: Enforce SSL connections to the database by using a custom parameter group.
- Reasoning: Amazon RDS for PostgreSQL supports SSL for encrypting connections. A custom p...
Author: Madison · Last updated May 8, 2026
A company recently purchased Savings Plans. The company wants to receive email notification when the company's utilization drops below 90% f...
To meet the requirement of receiving email notifications when the company's Savings Plan utilization drops below 90% for a given day, let's evaluate each option based on the criteria.
Option A: Create an Amazon CloudWatch alarm to monitor the Savings Plan check in AWS Trusted Advisor. Configure an Amazon Simple Queue Service (Amazon SQS) queue for email notification when the utilization drops below 90% for a given day.
- Reasoning: AWS Trusted Advisor provides insights on best practices but doesn't provide direct metrics for Savings Plan utilization. It is not designed to monitor Savings Plan utilization specifically, and using Trusted Advisor for this purpose would not provide the required functionality.
- Pros: Trusted Advisor is useful for checking AWS best practices, but it doesn't directly monitor Savings Plans utilization.
- Cons: This option is not appropriate for tracking Savings Plan usage as Trusted Advisor doesn't offer specific insights into this area.
- Rejection: This option doesn't address the specific need of monitoring Savings Plan utilization.
Option B: Create an Amazon CloudWatch alarm to monitor the SavingsPlansUtilization metric under the AWS/SavingsPlans namespace in CloudWatch. Configure an Amazon Simple Queue Service (Amazon SQS) queue for email notification when the utilization drops below 90% for a given day.
- Reasoning: CloudWatch does support monitoring the SavingsPlansUtilization metric, which measures the usage of your Savings Plans. However, using SQS to send an email notification adds unnecessary complexity. SQS is a message queuing service, which would require an additional process to read from the queue and send the notification. This introduces more complexity than needed.
- Pros: CloudWatch can monitor Savings Plans utilization directly, and it offers the right metric.
- Cons: Using SQS for email notifications complicates the process. SNS would be a simpler and more direct solution for email notifications.
- Rejection: The use of SQS adds unnecessary complexity when SNS can directly handle email notifications.
Option C: Create a Savings Plans alert to monitor the daily utilization of the Savings Plans. Configure an Amazon Simple Notification Service (Amazon SNS) topic for email notification when...
Author: Noah · Last updated May 8, 2026
A company uses an Amazon Simple Queue Service (Amazon SQS) standard queue with its application. The application sends messages to the queue with unique message bodies. The company decides to switc...
When migrating from an Amazon SQS standard queue to an SQS FIFO queue, the main objective is to ensure message ordering and deduplication while preserving application functionality. Let's analyze the options and see which one fits the use case:
Option A:
- Create a new SQS FIFO queue.
- Turn on content-based deduplication on the new FIFO queue.
- Update the application to include a message group ID in the messages.
Analysis:
- This is a valid option. Content-based deduplication ensures that messages with identical content (same body) will not be delivered more than once within a 5-minute window, which aligns with the FIFO queue’s features.
- The message group ID is essential because it defines message order within a group.
- Turning on content-based deduplication is ideal when the message body is unique per message but needs deduplication in case the same message body is sent more than once.
Option B:
- Create a new SQS FIFO queue.
- Update the application to include the DelaySeconds parameter in the messages.
Analysis:
- The DelaySeconds parameter is used to delay the delivery of messages in the queue, but it is unrelated to the transition from standard to FIFO. It does not address the critical aspects of message ordering or deduplication. While this option might serve some purposes like deferring message processing, it doesn't solve the migration problem in terms of FIFO requirements.
Option C:
- ...
Author: Michael · Last updated May 8, 2026
A company's SysOps administrator must ensure that all Amazon EC2 Windows instances that are launched in an AWS account have a third-party agent installed. The third-party agent has an .msi package. The company uses AWS Systems Manager for patching, and the Windows instances are tagged appropriately. The third-party agent requires periodic updates as new versions are released. The Sys...
To meet the requirements with the least operational effort, the SysOps administrator needs a solution that ensures:
1. Automatic installation of the third-party agent on newly launched EC2 Windows instances.
2. Periodic updates of the third-party agent as new versions are released.
3. Minimal manual intervention to reduce operational overhead.
Let's analyze each option:
Option A: Create a Systems Manager Distributor package for the third-party agent.
- Analysis:
- Systems Manager Distributor is a service that helps you distribute software packages to EC2 instances. By creating a distributor package for the third-party agent, the SysOps administrator can easily deploy and update the agent on the EC2 instances.
- This is a valid option as it allows automatic deployment and updates of the third-party agent with minimal operational effort. This is one of the best ways to ensure that the agent is installed and updated on all Windows instances automatically.
Option B: Make sure that Systems Manager Inventory is configured. If Systems Manager Inventory is not configured, set up a new inventory for instances that is based on the appropriate tag value for Windows.
- Analysis:
- Systems Manager Inventory can track software configurations and installed applications, but it doesn't directly automate installation or updates.
- While useful for auditing and reporting, Inventory is not necessary for automatic installation or updates. This step would be more relevant for tracking the state of installed software, not automating deployment.
- This is not the best option for the stated requirements, as it's not focused on deployment or updates.
Option C: Create a Systems Manager State Manager association to run the AWS-RunRemoteScript document. Populate the details of the third-party agent package. Specify instance tags based on the appropriate tag value for Windows with a schedule of 1 day.
- Analysis:
- AWS-RunRemoteScript is used to run custom scripts on EC2 instances. While it can be used to install the third-party agent, this method requires cr...
Author: Sara · Last updated May 8, 2026
A company runs hundreds of Amazon EC2 instances in a single AWS Region. Each EC2 instance has two attached 1 GiB General Purpose SSD (gp2) Amazon Elastic Block Store (Amazon EBS) volumes. A critical workload is using all the available IOPS capacity on the EBS volumes.
According to company policy, the company cannot change instance types or EBS volume types without completing lengthy acceptance tests to validate that the company's applications will funct...
In this scenario, the SysOps administrator needs to increase the I/O performance of the Amazon Elastic Block Store (EBS) volumes, particularly for a critical workload that is using all the available IOPS capacity on the existing volumes. Let’s evaluate each of the proposed options to determine which one meets the requirements with minimal operational effort, without changing instance types or EBS volume types.
Option A: Increase the size of the 1 GiB EBS volumes.
- Analysis:
- EBS volume performance for gp2 volumes is determined by both the size of the volume and the baseline IOPS. For gp2 volumes, the IOPS scale with the volume size—specifically, 3 IOPS per GiB. Therefore, increasing the size of the 1 GiB EBS volume would increase the baseline IOPS of the volume.
- Increasing the volume size would be a straightforward way to get more IOPS, and this does not require any changes to instance types or EBS volume types, which aligns with the company’s policy of avoiding lengthy acceptance tests.
- This option is optimal for improving I/O performance without needing complex changes.
Option B: Add two additional elastic network interfaces on each EC2 instance.
- Analysis:
- Elastic network interfaces (ENIs) are used for network communication and do not directly affect the I/O performance of EBS volumes. While adding more ENIs can help with network traffic, it does not have any impact on the disk I/O or IOPS capabilities of EBS volumes.
- This option does not address the problem of increasing EBS volume performance and is unrelated to the need to improve disk I/O capacity.
- This option is n...
Author: Zara · Last updated May 8, 2026
A company needs to deploy a new workload on AWS. The company must encrypt all data at rest and must rotate the encryption keys once each year. The workload uses an Amazon RDS for MySQL Multi-AZ dat...
To meet the company's requirements of encrypting all data at rest and rotating encryption keys once per year, let's carefully analyze the available options.
Option A: Enable Transparent Data Encryption (TDE) in the MySQL configuration file. Manually rotate the key every 12 months.
- Analysis:
- Transparent Data Encryption (TDE) is not natively supported on Amazon RDS for MySQL. MySQL does support encryption, but it’s typically done at the storage layer via AWS services, not through MySQL's own TDE configuration.
- Manually rotating keys is also error-prone, and this approach would not meet the company’s requirement for automatic key rotation.
- This option does not meet the requirements because RDS for MySQL does not support TDE, and manual key rotation is less efficient and potentially risky.
Option B: Enable RDS encryption on the database at creation time by using the AWS managed key for Amazon RDS.
- Analysis:
- Using the AWS managed key for Amazon RDS simplifies encryption but does not fulfill the requirement to rotate keys annually. AWS-managed keys are rotated automatically by AWS, but they are rotated on a fixed schedule and not on a per-customer basis, and you do not have the option to configure the schedule (e.g., every 12 months).
- This option may be easier to set up but does not give the required control over key rotation.
- This option does not fully meet the company's needs since it doesn't provide control over the key rotation schedule.
Option C: Create a new AWS Key Management Service (AWS KMS) customer managed key. Enable automatic key rotation. Enable RDS enc...
Author: Siddharth · Last updated May 8, 2026
A company has an application that is deployed to two AWS Regions in an active-passive configuration. The application runs on Amazon EC2 instances behind an Application Load Balancer (ALB) in each Region. The instances are in an Amazon EC2 Auto Scaling group in each Region. The application uses an Amazon Route 53 hosted zone for DNS. A SysOps...
The company wants to set up automatic failover in an active-passive configuration between two AWS Regions, using Amazon Route 53 and ALBs for DNS routing. To achieve automatic failover, DNS routing needs to detect the health of the application in the primary Region and automatically switch to the secondary Region if the primary Region becomes unavailable.
Let's evaluate each option:
Option A: Configure Route 53 alias records that point to each ALB. Choose a failover routing policy. Set Evaluate Target Health to Yes.
- Analysis:
- Route 53 alias records can be used to point to the ALB in each region. Alias records are ideal in this case because they support automatic failover to a different AWS region without the need for a CNAME record, which is not allowed for the root domain.
- The failover routing policy is specifically designed for scenarios where you want to route traffic to a primary resource (ALB in the primary region) and automatically failover to a secondary resource (ALB in the secondary region) if the primary resource becomes unhealthy.
- Evaluate Target Health ensures that Route 53 checks the health of the ALB before routing traffic, allowing automatic failover if the primary region’s ALB is unhealthy.
- This option is ideal because it meets the requirement of automatic failover based on health status, and it uses Route 53’s built-in failover routing policy.
Option B: Configure CNAME records that point to each ALB. Choose a failover routing policy. Set Evaluate Target Health to Yes.
- Analysis:
- While CNAME records can be used to point to the ALB, CNAME records cannot be used at the root domain level in Route 53 (only for subdomains). This would prevent this solution from working for the root domain.
- The failover routing policy and Evaluate Target Health configuration are appropriate, but since CNAME records cannot be used at the root domain, thi...
Author: Suresh · Last updated May 8, 2026
A company is implementing a monitoring solution that is based on machine learning. The monitoring solution consumes Amazon EventBridge (Amazon CloudWatch Events) events that are generated by Amazon EC2 Auto Scaling. The monitoring solution provides detection of anomalous behavior such as unanticipated scaling events and is configured as an EventBridge (CloudWatch Events) API destination.
During initial testing, the company discovers that the monitoring solution is not receiving events. However, Amazon CloudWatch is showing that the EventBrid...
To determine the best solution for the given scenario, we need to focus on minimizing operational effort while achieving the goal of retrieving client error details to resolve the issue.
Let's evaluate each option:
Option A: Create an EventBridge (CloudWatch Events) archive for the event pattern to replay the events. Increase the logging on the monitoring solution. Use replay to invoke the monitoring solution. Examine the error details.
- Pros: This option allows replaying events to analyze the issue with the monitoring solution. The logs of the monitoring solution may give details about errors.
- Cons: Increasing the logging on the monitoring solution could introduce extra overhead in terms of both configuration and monitoring. Replay functionality requires managing event archives, which might add complexity. This option is not ideal if the goal is to quickly identify and resolve the error without additional configuration steps.
- Use case: Useful if you want to test with historical events and analyze them in the context of the application.
- Operational effort: Moderate. There is setup and management of EventBridge archives and replaying events.
Option B: Add an Amazon Simple Queue Service (Amazon SQS) standard queue as a dead-letter queue for the target. Process the messages in the dead-letter queue to retrieve error details.
- Pros: A dead-letter queue can help isolate messages that failed to be delivered, and you can process them later to investigate errors.
- Cons: This method is not immediate, as it relies on processing messages in the dead-letter queue. There's added complexity of managing the SQS queue, as well as the need for separate handling and processing of messages.
- Use case: Suitable when you need to capture undelivered events and investigate failures, especially for long-term troubleshooting.
- Operational effort: High, due to the overhead of managing SQS queues and message processing.
Option C: Create a second EventBridge (CloudWatch Events) rule for the same event pattern to target an AWS Lambda function. Configure the Lambda function to invoke t...
Author: Ahmed · Last updated May 8, 2026
A company is storing backups in an Amazon S3 bucket. The backups must not be deleted for at least 3 months after the backups are created.
W...
To meet the requirement of preventing backups from being deleted for at least 3 months, we need to implement a solution that ensures objects in the S3 bucket are protected from deletion for the specified duration, without relying on manual actions. Let's analyze each option:
Option A: Configure an IAM policy that denies the s3:DeleteObject action for all users. Three months after an object is written, remove the policy.
- Pros: This option uses an IAM policy to prevent deletions, but it relies on manually removing the policy after 3 months.
- Cons: This approach is error-prone because it requires manual intervention (removal of the policy) after 3 months. If the policy is not removed, the objects will remain undeletable, which can be problematic for future deletions or management.
- Use case: This could be used in very specific scenarios where you have strict control over who can delete objects but doesn’t scale well for long-term retention policies.
- Operational effort: High, because it requires manual action to adjust the policy after 3 months.
Option B: Enable S3 Object Lock on a new S3 bucket in compliance mode. Place all backups in the new S3 bucket with a retention period of 3 months.
- Pros: Compliance mode ensures that objects cannot be deleted or overwritten for the retention period. This guarantees that the backups are protected for at least 3 months.
- Cons: S3 Object Lock in compliance mode is irreversible—once objects are locked, they cannot be deleted or modified until the retention period expires. This is highly secure but could be too restrictive for non-compliance scenarios.
- Use case: This option is ideal for scenarios where you need to ensure strict immutability of the backups for regulatory or compliance reasons, and no deletions are allowed for the specified retention period.
- Operational effort: Low. Once configured, it is fully automated and ensures protection without further intervention.
Option C: Enable S3 Versioning on the existing S3 bucket. Configure S3 Lifecycle rules to protect the backups.
- Pros: S3 Versioning allows you to keep multiple versions of an object. Using Lifecycle rules, you could configure objects to be protected o...
