Amazon Practice Questions, Discussions & Exam Topics by our Authors

A company updates its security policy to prohibit the public exposure of any data in Amazon S3 buckets in the company's account. What...

To meet the requirement of prohibiting the public exposure of any data in Amazon S3 buckets in the company's account, the key concern is ensuring that no public access is allowed to any S3 bucket or object in the account. Let's analyze each option in detail: Key Considerations: 1. Account-level public access controls: Ensuring that no public access is allowed for any S3 buckets should be enforced at the account level, not just on individual buckets or objects. 2. Automation and consistency: A solution that is automated and ensures consistent enforcement across all buckets in the account is preferable to manual inspection or adjustments. Option Analysis: - Option A: Turn on S3 Block Public Access from the account level. - Reasoning: This is the most effective and straightforward way to ensure that no public access is allowed to any S3 bucket or object in the account. Amazon S3 Block Public Access can be enabled at the account level to block all public access to buckets and objects, regardless of the bucket’s individual permissions or ACLs. This is a global control that can be applied across the entire account, making it an efficient solution to meet the security policy. Once enabled, no S3 bucket or object in the account can have public access unless explicitly overridden, which makes this the most robust option for this use case. - Option B: Create an Amazon EventBridge (Amazon CloudWatch Events) rule to enforce that all S3 objects are private. - Reasoning: While Amazon EventBridge (CloudWatch Events) could be used to monitor S3 events, creating a rule to enforce that objects are private is not the most efficient way to meet the requirement. EventBridge rules can help notify or trigger actions based on certain conditions, but they cannot directly block publi...

Author: IronLion88 · Last updated Jul 17, 2026

A company's SysOps administrator needs to change the AWS Support plan for one of the company's AWS accounts. The account has multi-factor authentication (MFA) activated, and th...

In this scenario, the SysOps administrator needs to sign in to the AWS account where multi-factor authentication (MFA) is enabled, but the MFA device is lost. The challenge is to regain access to the account and perform the required task of changing the AWS Support plan. Key Factors to Consider: - MFA and Root User: The root user requires MFA for certain sensitive actions, including changing the AWS Support plan. If the MFA device is lost, the administrator must find a way to regain access to the root user or use another method to proceed. - Access to IAM users: An IAM user with administrative permissions cannot change settings for the root user’s MFA directly. IAM users typically can't modify MFA settings for the root user unless they have the necessary permissions to manage the root user’s account, which is not typical. - Root User Access: Regaining root user access is essential because the MFA is configured for the root user, and actions like modifying the AWS Support plan generally require root user access. Option Analysis: - Option A: Sign in as a root user by using email and phone verification. Set up a new MFA device. Change the root user password. - Reasoning: This option is valid because if the MFA device is lost, AWS allows the root user to verify the account by using email and phone verification. After verifying the identity, the root user can disable the old MFA device and set up a new one. This process does not require resetting the root user password, as the verification is done using the email and phone number associated with the account. - Why it’s the best option: This option allows the SysOps administrator to regain access to the root user account without needing to reset the password, directly addressing the issue of a lost MFA device. - Option B: Sign in as an IAM user with administrator permissions. Resynchro...

Author: Abigail · Last updated Jul 17, 2026

A company is creating a new multi-account architecture. A SysOps administrator must implement a login solution to centrally manage user access and permissions across all AWS accounts. The solution must be integrated with AWS Organizations and must be connected to a third-party Security Assert...

To meet the company's requirement of implementing a login solution for managing user access and permissions across multiple AWS accounts with integration to a third-party SAML 2.0 identity provider (IdP) and AWS Organizations, we need to evaluate the available options carefully. Key Requirements: 1. Centralized user access management: The solution should allow for centralized management of user access across all AWS accounts within the organization. 2. Integration with AWS Organizations: This implies a solution that can be applied at the organization level, not just on individual accounts. 3. Third-party SAML 2.0 IdP integration: The solution needs to be connected to an external identity provider that supports SAML 2.0. Option Analysis: - Option A: Configure an Amazon Cognito user pool. Integrate the user pool with the third-party IdP. - Reasoning: Amazon Cognito is primarily used for building and managing user authentication for mobile and web applications. While it can integrate with third-party IdPs via SAML 2.0, it is generally not used for managing AWS account access across multiple accounts. Cognito user pools are more appropriate for customer or application-specific logins, not for enterprise-level AWS account access management. - Why it’s rejected: This option is not ideal because Amazon Cognito doesn't directly integrate with AWS Organizations and isn't designed for managing user access across multiple AWS accounts within an organization. - Option B: Enable and configure AWS Single Sign-On (SSO) with the third-party IdP. - Reasoning: AWS Single Sign-On (SSO) is specifically designed to centralize user access management across multiple AWS accounts and applications. It integrates directly with AWS Organizations, allowing users to access all AWS accounts within the organization using SAML 2.0-based authentication from a third-party IdP. AWS SSO offers a centralized management interface...

Author: CrimsonViperX · Last updated Jul 17, 2026

A company is managing many accounts by using a single organization in AWS Organizations. The organization has all features enabled. The company wants to turn on AWS Config in all the accounts of the organization and in all AWS Regions. W...

To meet the company's requirement of enabling AWS Config in all accounts and all AWS regions within an AWS Organization, the solution needs to be operationally efficient and scalable. Let's evaluate each option carefully: Key Factors: 1. Operational Efficiency: The solution should be easily deployable across all accounts and regions in the organization. 2. Centralized Management: The solution should allow for centralized control, especially when managing multiple accounts in an AWS Organization. 3. Scalability: The solution should scale to support potentially hundreds of AWS accounts and multiple regions. Option Analysis: - Option A: Use AWS CloudFormation Stack Sets to deploy stack instances that turn on AWS Config in all accounts and in all Regions. - Reasoning: AWS CloudFormation StackSets is an excellent solution for deploying resources across multiple accounts and regions in an AWS Organization. StackSets allow you to deploy the same CloudFormation template to multiple accounts and regions, making it operationally efficient for large-scale environments. By using StackSets, the SysOps administrator can create a CloudFormation template that provisions AWS Config across all regions and accounts, meeting the requirement for centralized configuration management. - Why it’s selected: This is the most efficient and scalable solution because StackSets allow for centralized deployment, and the template can be customized to deploy AWS Config in all required accounts and regions. This avoids the need to manually configure each account or region individually. - Option B: Use AWS CloudFormation Stack Sets to deploy stack policies that turn on AWS Config in all accounts and in all Regions. - Reasoning: Stack policies in CloudFormation are used to protect resources during stack operations, such as preventing certain resources from being updated or deleted. Stack policies do not enable AWS Config; they are used to control the behavior of CloudFormation stacks. This option is incorrect because stack policies do not address the task of enabling...

Author: Suresh · Last updated Jul 17, 2026

A SysOps administrator needs to delete an AWS CloudFormation stack that is no longer in use. The CloudFormation stack is in the DELETE_FAILED state. The SysOps administrator has validated the permissions that are required to delete the Cloud...

To resolve the issue of a CloudFormation stack being in the DELETE_FAILED state, we need to understand the potential causes behind the failure. Let's break down each option: A) The configured timeout to delete the stack was too low for the delete operation to complete. - Reasoning: CloudFormation stacks can fail to delete if the deletion takes longer than the timeout period allows. If a resource is taking too long to delete, the operation may be terminated prematurely, resulting in a DELETE_FAILED state. - Scenario: If there is a resource that requires a longer deletion time (such as large EC2 instances, complex VPC configurations, or large databases), this could lead to a timeout. The timeout duration can be modified, but if it's not properly configured, this could be a possible cause. - Conclusion: This option could be a valid cause for DELETE_FAILED. B) The stack contains nested stacks that must be manually deleted first. - Reasoning: Nested stacks are stacks within a parent stack. When you delete the parent stack, CloudFormation must also delete all nested stacks. However, if a nested stack contains resources that prevent deletion or requires manual intervention, the deletion of the parent stack will fail. - Scenario: If nested stacks are not deleted properly, or if they depend on resources that cannot be deleted (e.g., stuck resources or insufficient permissions), the deletion of the main stack will fail. - Conclusion: This option could be a valid cause of DELETE_FAILED. C) The stack was deployed with the --disable-rollback option. - Reasoning: The `--disable-rollback` option is used during stack creation, not deletion. It prevents the rollback of a stack to its previous state if a creation operation fails. It doesn't affect the deletion process. - Scenario: Since rollback only applies to stack creation and not deletion, it ...

Author: Stella · Last updated Jul 17, 2026

A SysOps administrator needs to configure a solution that will deliver digital content to a set of authorized users through Amazon CloudFront. Unauthorized users must b...

To address the requirement of delivering digital content to authorized users only, the solution must ensure that unauthorized users are restricted from access and only authorized users can retrieve the content through CloudFront. Let’s break down the options: A) Store the digital content in an Amazon S3 bucket that does not have public access blocked. Use signed URLs to access the S3 bucket through CloudFront. - Reasoning: Storing the content in an S3 bucket with public access not blocked is not secure, as anyone could access the S3 content via CloudFront if they have the correct signed URL. The requirement specifies that unauthorized users should be restricted from access, but allowing public access to the S3 bucket violates this. - Conclusion: This solution is not secure and does not meet the requirements. B) Store the digital content in an Amazon S3 bucket that has public access blocked. Use an origin access identity (OAI) to deliver the content through CloudFront. Restrict S3 bucket access with signed URLs in CloudFront. - Reasoning: By storing the content in an S3 bucket with public access blocked, you ensure that the content cannot be accessed directly through S3 by unauthorized users. The origin access identity (OAI) allows CloudFront to access the S3 bucket, and signed URLs ensure that only authorized users with the correct signed URL can access the content through CloudFront. - Scenario: This solution is effective when controlling access to specific resources, especially when you want to restrict access to certain content but still allow authorized users access via CloudFront. It meets both the security requirement and delivery need. - Conclusion: This option meets the requirements effectively. C) Store the digital content in an Amazon S3 buc...

Author: Ming · Last updated Jul 17, 2026

A SysOps administrator must ensure that a company's Amazon EC2 instances auto scale as expected. The SysOps administrator configures an Amazon EC2 Auto Scaling lifecycle hook to send an event to Amazon EventBridge (Amazon CloudWatch Events), which then invokes an AWS Lambda function to configure the EC2 instances. When the configuration is complete, the Lambda function calls the complete-lifecycle-action event to put the EC2 instances into serv...

The SysOps administrator is trying to ensure that EC2 instances are auto-scaled and configured through an EC2 Auto Scaling lifecycle hook, with an EventBridge rule invoking a Lambda function. However, the Lambda function is not being invoked when instances auto scale. Let's analyze the options to resolve this issue: A) Add a permission to the Lambda function so that it can be invoked by the EventBridge (CloudWatch Events) rule. - Reasoning: For EventBridge (formerly CloudWatch Events) to invoke a Lambda function, you need to ensure that the necessary permissions are in place. The Lambda function must have an execution role that allows it to be triggered by EventBridge. If the permissions are missing, EventBridge will not be able to invoke the Lambda function. - Scenario: This is likely the issue, as permissions between EventBridge and Lambda need to be explicitly set to allow the function to be triggered. - Conclusion: This option addresses the core issue, which is the lack of proper permissions for EventBridge to invoke the Lambda function. B) Change the lifecycle hook action to CONTINUE if the lifecycle hook experiences a failure or timeout. - Reasoning: The CONTINUE action in a lifecycle hook allows the instance to transition to the "InService" state regardless of whether the hook completes successfully. This would bypass the configuration process and doesn't address the problem of the Lambda function not being invoked. - Scenario: This could be used if the issue was related to the lifecycle hook not proceeding, but it doesn't fix the core problem (the Lambda function not being invoked). - Conclusion: This option is not relevant because it does not resolve the issue of the Lambda function not being triggered. C) Configure a retry policy in the EventBridge (CloudWa...

Author: Sofia · Last updated Jul 17, 2026

A company has mandated the use of multi-factor authentication (MFA) for all IAM users, and requires users to make all API calls using the CLI. However, users are not prompted to enter MFA tokens, and are able to run CLI commands without MFA. In an attempt to enforce MFA, the company attached an IAM policy to all users that denies A...

To ensure that API calls are authenticated using multi-factor authentication (MFA), we need to focus on how MFA is integrated into the API calls made through the AWS CLI. Here's a detailed analysis of each option: A) Enable MFA on IAM roles, and require IAM users to use role credentials to sign API calls. - Reasoning: While enabling MFA on IAM roles is a good practice, it does not directly address the requirement for enforcing MFA for IAM users when making API calls via the CLI. This approach would introduce additional complexity by requiring users to assume roles, which isn't necessary for enforcing MFA directly on IAM user actions. - Scenario: This solution is more relevant in a scenario where roles need to be assumed by users for particular use cases but does not directly solve the problem of enforcing MFA for CLI calls. - Conclusion: This option is not the most effective solution for enforcing MFA for IAM users making API calls. B) Ask the IAM users to log into the AWS Management Console with MFA before making API calls using the CLI. - Reasoning: Requiring users to log into the console with MFA doesn't solve the problem for API calls made through the CLI. MFA needs to be enforced at the API call level, not at the console login level. The AWS CLI requires a separate configuration for MFA to ensure API calls are signed using temporary credentials. - Scenario: This option is not sufficient, as the company’s requirement is to enforce MFA for API calls made through the CLI, not just console login. - Conclusion: This option does not address the requirement for enforcing MFA on CLI API calls. C) Restrict the IAM users to use of the console, as MFA is not supported for CLI use. - Reasoning: MFA is supported for C...

Author: Rahul · Last updated Jul 17, 2026

A SysOps administrator has blocked public access to all company Amazon S3 buckets. The SysOps administrator wants to be notified when an S3 bucket becomes publicly readable in the fu...

To ensure that the SysOps administrator is notified when an S3 bucket becomes publicly readable, the solution needs to be operationally efficient and able to automatically monitor the bucket's access settings. Let's break down the options: A) Create an AWS Lambda function that periodically checks the public access settings for each S3 bucket. Set up Amazon Simple Notification Service (Amazon SNS) to send notifications. - Reasoning: While this option would work, it involves setting up a custom solution where a Lambda function is scheduled to periodically check the access settings of S3 buckets. This introduces complexity and maintenance overhead, such as handling the Lambda function’s execution frequency and monitoring for failures. - Scenario: This solution would be effective but requires more effort to maintain and monitor, especially when scaling with many S3 buckets. - Conclusion: This option is not the most efficient since it introduces custom monitoring and periodic checks. B) Create a cron script that uses the S3 API to check the public access settings for each S3 bucket. Set up Amazon Simple Notification Service (Amazon SNS) to send notifications. - Reasoning: This is another custom solution that requires running a cron job to check S3 bucket settings using the S3 API. This approach would also need manual management and scheduling, and it introduces complexity and operational overhead, similar to option A. - Scenario: Although it can be automated, the cron job requires regular maintenance, and setting it up would be more effort than necessary compared to managed AWS services. - Conclusion: This option is not ideal because it is more complex and requires ongoing management. C) Enable S3 Event Notifications for each S3 bucket. Subscribe S3 Event Notifications to an Amazon Simple Notification Service (Amazon SNS) topic. - Reasoning: S3 Event Notifications can ...

Author: FrostFalcon88 · Last updated Jul 17, 2026

A company plans to launch a static website on its domain example.com and subdomain www.example.com using Amazon S3. How ...

To launch a static website on a company's domain example.com and subdomain www.example.com using Amazon S3, the SysOps administrator needs to ensure that both the domain and subdomain are properly configured for static website hosting, with one of the solutions redirecting the traffic from the subdomain to the main domain if necessary. Let's go through each option: A) Create one S3 bucket named example.com for both the domain and subdomain. - Reasoning: Amazon S3 requires that each bucket name matches the DNS name of the website (i.e., the bucket name must match either the domain or the subdomain). Therefore, using a single bucket for both `example.com` and `www.example.com` is not possible because Amazon S3 does not support multi-name buckets in this context. - Rejected: This option is not feasible because it violates the bucket naming convention in S3. B) Create one S3 bucket with a wildcard named .example.com for both the domain and subdomain. - Reasoning: Amazon S3 does not support wildcard characters in bucket names (such as `.example.com`), and S3 requires a unique bucket name that exactly matches the domain or subdomain. - Rejected: This option is invalid because wildcard bucket na...

Author: Ravi Patel · Last updated Jul 17, 2026

A SysOps administrator is configuring AWS Client VPN to connect users on a corporate network to AWS resources that are running in a VPC. According to compliance requirements, only traffic that is destined for the VPC can travel across t...

To ensure that only traffic destined for the VPC travels across the AWS Client VPN tunnel, we need to restrict traffic to the VPC resources. Here's an analysis of the options provided: A) Associate the Client VPN endpoint with a private subnet that has an internet route through a NAT gateway. - Reasoning: This configuration allows traffic to flow to the internet through the NAT gateway, which contradicts the requirement to ensure that only traffic destined for the VPC should travel through the VPN tunnel. With a NAT gateway, users could access the internet, which is outside the VPC, violating the compliance requirement. - Rejected: This option is not valid because it allows traffic to go to the internet, which is not in line with the requirement. B) On the Client VPN endpoint, turn on the split-tunnel option. - Reasoning: Split tunneling allows traffic to be routed both to the VPC and to other networks, such as the internet, based on the destination. However, the compliance requirement specifies that only traffic destined for the VPC should be allowed through the VPN tunnel, so enabling split tunneling would violate this requirement. - Rejected: This option is rejected because split tunneling would allow traffic to flow outside the VPC, contradicting the stated compliance requirement. C) On the Client VPN endpoint, specify DNS server IP addresses...

Author: Aditya · Last updated Jul 17, 2026

A SysOps administrator is testing an application that is hosted on five Amazon EC2 instances. The instances run in an Auto Scaling group behind an Application Load Balancer (ALB). High CPU utilization during load testing is causing the Auto Scaling group to scale out. The SysOps administrator must troubleshoot to find the root cause of t...

To troubleshoot the high CPU utilization before the Auto Scaling group scales out, the SysOps administrator must prevent the Auto Scaling group from scaling out while investigating the issue. Let's analyze each option: A) Enable instance scale-in protection. - Reasoning: Enabling scale-in protection prevents an instance from being terminated when the Auto Scaling group scales in (reduces capacity). However, this does not address the scaling-out behavior. The issue here is preventing the Auto Scaling group from scaling out when CPU utilization is high, not preventing instances from being terminated. This option does not help troubleshoot the root cause of high CPU utilization. - Rejected: This option is not relevant to stopping the Auto Scaling group from scaling out. B) Place the instance into the Standby state. - Reasoning: Placing the instance into the Standby state temporarily removes the instance from the Auto Scaling group’s active pool without terminating it. This will prevent the Auto Scaling group from scaling out by launching new instances in response to high CPU utilization. This approach allows the administrator to focus on the instance in question and troubleshoot its CPU usage without triggering further scaling actions. - Selected: This is the best option because it allows the SysOps administrator to isolate the problematic instance and diagnose the high CPU utilization without triggering scaling actions. C) Remove the listener from the ALB. - Reasoning: Removing the listener f...

Author: Ella · Last updated Jul 17, 2026

A web application runs on Amazon EC2 instances behind an Application Load Balancer (ALB). The instances run in an Auto Scaling group across multiple Availability Zones. A SysOps administrator notices that some of these EC2 instances show up as healthy in the A...

To address the issue where EC2 instances show as healthy in the Auto Scaling group but unhealthy in the ALB target group, we need to consider the difference between the health checks performed by the Auto Scaling group and the health checks performed by the Application Load Balancer (ALB). Let's analyze each option: A) Security groups are not allowing traffic between the ALB and the failing EC2 instances. - Reasoning: If security groups are misconfigured and do not allow traffic from the ALB to the EC2 instances, the ALB will be unable to successfully perform its health checks on the instances. This would result in the instances showing as unhealthy in the ALB target group while still appearing healthy in the Auto Scaling group, as the Auto Scaling group health check may be based on EC2 instance status checks, which do not account for this specific issue. - Selected: This is a likely cause. Misconfigured security groups could block the necessary traffic for the ALB to perform its health check, leading to the mismatch between the EC2 instance health in the Auto Scaling group and the ALB target group. B) The Auto Scaling group health check is configured for EC2 status checks. - Reasoning: The Auto Scaling group health checks can be configured to monitor EC2 instance status checks (such as instance reachability), but this health check is independent of the ALB health check. If the Auto Scaling group health checks are based on EC2 status checks, the instances could still appear healthy in the Auto Scaling group, even if they are unhealthy in the ALB target group. However, this does not directly address why the ALB would report an instance as unhealthy. - Rejected: While this might explain why the Auto Scaling group still co...

Author: Elizabeth · Last updated Jul 17, 2026

A SysOps administrator notices a scale up event for an Amazon EC2 Auto Scaling group. Amazon CloudWatch shows a spike in the RequestCount metric for the associated Application Load Balancer. The administrator would like to know th...

To find the IP addresses for the source of the requests that caused the scale-up event in an Amazon EC2 Auto Scaling group, the SysOps administrator needs to focus on logs that capture the incoming traffic to the Application Load Balancer (ALB), since the spike in the RequestCount metric indicates high traffic to the ALB. Let's review each option: A) Auto Scaling logs - Reasoning: Auto Scaling logs provide information about the scaling activities, such as when instances are added or removed from the Auto Scaling group. However, they do not capture any details about incoming traffic or the source IP addresses of requests. Auto Scaling logs are useful for understanding instance scaling but not for network traffic analysis. - Rejected: This option does not provide the required information about the source IP addresses of requests. B) AWS CloudTrail logs - Reasoning: AWS CloudTrail logs provide a record of API calls made to AWS services. CloudTrail logs track actions like instance launches, changes in Auto Scaling configurations, and other management activities. However, CloudTrail does not capture details about incoming web traffic (such as HTTP requests and their source IPs) that are processed by services like ALB. - Rejected: CloudTrail logs are not suitable for capturing network traffic or the source IP addresses for incoming requests. C) EC2 instance logs - Reasoning: EC2 instance logs can include information about traffic reaching the i...

Author: Lucas · Last updated Jul 17, 2026

A company plans to migrate several of its high performance computing (HPC) virtual machines (VMs) to Amazon EC2 instances on AWS. A SysOps administrator must identify a placement group for this deployment. The strategy must minimize network latency and must maximize networ...

To meet the requirements of minimizing network latency and maximizing network throughput between the high-performance computing (HPC) virtual machines (VMs) on AWS, it is crucial to understand the behavior and capabilities of different EC2 placement group strategies. Below is an analysis of each option: A) Deploy the instances in a cluster placement group in one Availability Zone - Cluster Placement Group: This strategy is designed for applications that require low latency and high throughput between instances. It places instances close together within a single Availability Zone, optimizing for network performance. - Why it’s a good option: This strategy minimizes network latency and maximizes throughput because instances are located physically close to each other, benefiting from low-latency and high-bandwidth connections between them. - Why it’s the best option: Since the VMs require both minimal latency and high throughput, a Cluster Placement Group within one Availability Zone is optimal because it minimizes physical distance and maximizes network performance. - Key Factor: The ability to group VMs tightly together within a single Availability Zone leads to the lowest latency and highest network performance, ideal for HPC workloads. B) Deploy the instances in a partition placement group in two Availability Zones - Partition Placement Group: This strategy is suitable for distributed and fault-tolerant applications that can tolerate some level of latency and network partitioning. It ensures that instances are spread across different partitions (and optionally across different Availability Zones), reducing the risk of correlated failures. - Why it’s not suitable: While Partition Placement Groups can reduce risk, they are designed to be used in scenarios where fault tolerance across Availability Zones is more critical than minimizing latency or maximizing throughput. The network latency between instances in two different Availability Zo...

Author: Vikram · Last updated Jul 17, 2026

An errant process is known to use an entire processor and run at 100%. A SysOps administrator wants to automate restarting an Amazon EC2 instance when the pro...

To automate restarting an Amazon EC2 instance when a process causes the CPU to run at 100% for more than 2 minutes, the SysOps administrator needs to monitor the CPU utilization and trigger an automatic restart action based on specific conditions. Let's break down the options: A) Create an Amazon CloudWatch alarm for the EC2 instance with basic monitoring. Add an action to restart the instance. - Basic Monitoring: With basic monitoring, EC2 instances are only monitored at 5-minute intervals, which means it won't capture detailed performance information within shorter periods, such as 2 minutes. - Why it's not suitable: Since the requirement is to restart the EC2 instance after 2 minutes of high CPU usage, basic monitoring with 5-minute granularity will not meet the threshold in a timely manner. You might miss the issue in the 2-minute window. B) Create an Amazon CloudWatch alarm for the EC2 instance with detailed monitoring. Add an action to restart the instance. - Detailed Monitoring: With detailed monitoring, EC2 instances are monitored at 1-minute intervals, which allows you to capture CPU spikes at a much finer granularity. This aligns with the requirement of detecting and responding to the high CPU usage condition within 2 minutes. - Why it's suitable: This option provides the necessary granularity to monitor CPU usage closely and trigger the restart action when the CPU usage exceeds 100% for more than 2 minutes. By setting the alarm condition to 2 minutes, the EC2 instance can be automatically restarted when the problem is detected. - Key Factor: Detailed monitoring at 1-minute intervals is necessary for accurately detecting and reacting to short-duration spikes in CPU usage. C) Create an AWS Lambda function to res...

Author: Mia · Last updated Jul 17, 2026

A company maintains a large set of sensitive data in an Amazon S3 bucket. The company's security team asks a SysOps administrator to help verify that all current objects in the S3 bucket are encrypte...

To ensure that all current objects in an S3 bucket are encrypted and to verify this efficiently, the solution should allow for quick identification of the encryption status of each object. Let’s review the options based on operational efficiency and relevance to the task: A) Create a script that runs against the S3 bucket and outputs the status of each object. - Why it's not ideal: While a script could be created to iterate over all objects in the bucket and check their encryption status, this approach can be operationally inefficient, especially if there are many objects. The script would need to handle API calls to S3 for each object, which could lead to a high volume of requests, impacting performance and cost. Additionally, it requires manual maintenance of the script, making it less efficient and scalable in the long run. - Key Factor: A custom script introduces complexity and may require more time and effort to run and maintain, especially when compared to automated AWS-native solutions. B) Create an S3 Inventory configuration on the S3 bucket. Include the appropriate status fields. - Why it's ideal: Amazon S3 Inventory is a managed solution that can efficiently list and provide details about objects in the bucket, including encryption status. The inventory can be configured to include the "Encryption Status" field, which will allow the security team to verify whether each object is encrypted. Once configured, this approach automates the reporting process and is highly scalable, as it can handle large numbers of objects in an operationally efficient manner. - Key Factor: S3 Inventory is an AWS-native service designed specifically for this purpose, providin...

Author: Mia · Last updated Jul 17, 2026

Users are periodically experiencing slow response times from a relational database. The database runs on a burstable Amazon EC2 instance with a 350 GB General Purpose SSD (gp2) Amazon Elastic Block Store (Amazon EBS) volume. A SysOps administrator monitors the EC2 instance in Amazon CloudWatch and observes that the VolumeReadOps metric drops to le...

In this scenario, the issue is related to performance degradation during periods of high demand on a burstable EC2 instance and its associated EBS volume. Let’s analyze each option to determine which one best addresses the problem: A) Convert the gp2 volume to a General Purpose SSD (gp3) EBS volume. - Why it's the best option: The issue observed is that the VolumeReadOps metric drops during slow response times, which suggests that the disk is not able to handle the I/O requests efficiently. A gp2 volume provides burstable performance, but its performance is constrained by the baseline IOPS (input/output operations per second), which is tied to the size of the volume. When the instance doesn't need the full IOPS burst capacity, it can still experience slower performance if the required operations exceed its baseline performance. - gp3 volumes, on the other hand, offer more consistent performance by allowing users to provision IOPS and throughput independently of volume size, which ensures more predictable performance. In this case, gp3 would give you a more consistent level of performance, especially under load, and is often cheaper for higher performance levels. - Key Factor: This option directly addresses the problem of inconsistent I/O performance by providing more control over IOPS and throughput. B) Convert the gp2 volume to a Cold HDD (sc1) EBS volume. - Why it's not suitable: The Cold HDD (sc1) EBS volume type is designed for infrequent access and is optimized for throughput rather than IOPS. It is not suitable for workloads that require low-latency random access, such as those associated with relational databases. Converting to an sc1 volume would likely worsen the performance, as it would not support the IOPS...

Author: ThunderBear · Last updated Jul 17, 2026

A SysOps administrator is optimizing the cost of a workload. The workload is running in multiple AWS Regions and is using AWS Lambda with Amazon EC2 On-Demand Instances for the computer. The overall usage is predictable. The amount of computer that is consumed in each Region var...

To optimize the cost of the workload, which is running in multiple AWS regions using AWS Lambda and Amazon EC2 On-Demand Instances, the SysOps administrator needs to look for an approach that reduces costs by leveraging committed usage models. Since the usage is predictable but varies across regions, the solution needs to efficiently handle these variables. Let's evaluate each option: A) Purchase Compute Savings Plans based on the usage during the past 30 days. - Why it’s a good option: Compute Savings Plans provide flexibility by applying to any EC2 instance regardless of region, instance type, operating system, or tenancy. This flexibility is highly valuable for a multi-region workload. Since the usage is predictable, purchasing Compute Savings Plans based on the past 30 days would help reduce costs by committing to usage for a 1- or 3-year term at a lower rate compared to On-Demand prices. - Key Factor: The flexibility of Compute Savings Plans allows them to apply to any EC2 instance, including Lambda, and across multiple regions. This option is best suited for the scenario where workloads span multiple regions with varying usage. B) Purchase Convertible Reserved Instances by calculating the usage baseline. - Why it’s not ideal: Convertible Reserved Instances require a longer commitment (1- or 3-year terms) and can be modified to change instance types or families. However, they are less flexible than Compute Savings Plans, especially when there are variable usage patterns across regions. Additionally, they apply only to specific instance types and regions, which might not work well in this scenario with varying usage and the need for flexibility. - Key Factor: Convertible Reserved Instances lack the same level of flexibility as Compute Savings Plans, especially when workloads are spread across multiple regions with changing instance types or configurat...

Author: Akash · Last updated Jul 17, 2026

A software company runs a workload on Amazon EC2 instances behind an Application Load Balancer (ALB). A SysOps administrator needs to define a custom health check for ...

To determine the most operationally efficient solution, let's analyze each option in terms of simplicity, scalability, integration with the AWS infrastructure, and maintainability: A) Set up each EC2 instance so that it writes its healthy/unhealthy status into a shared Amazon S3 bucket for the ALB to read. - Complexity: This solution introduces a high level of complexity because the EC2 instances need to manage their health status, and the Application Load Balancer would need to read from an S3 bucket, which isn’t designed for such real-time health checks. - Scalability: Using S3 for health checks is not efficient, especially as the number of EC2 instances increases. The health check process would likely become slow due to the need for each EC2 instance to write its status and for the ALB to check S3. - Maintainability: This solution is harder to maintain and error-prone. It introduces external dependencies (S3) that aren’t needed for health checks, adding more failure points. Rejected because of high complexity and poor scalability. B) Configure the health check on the ALB and ensure that the Health Check Path setting is correct. - Simplicity: This is a very simple and built-in solution within the ALB service. ALB health checks can be configured to monitor a specific URL path or HTTP status code to determine the health of EC2 instances. - Scalability: Since ALB health checks are integrated and managed within AWS infrastructure, it scales automatically with the number of EC2 instances. - Operational efficiency: This is an efficient and automated way to perform health checks. It also reduces the operational overhead because the ALB can directly check the EC2 inst...

Author: Sam · Last updated Jul 17, 2026

A SysOps administrator is required to monitor free space on Amazon EBS volumes attached to Microsoft Windows-based Amazon EC2 instances within a company's account. The administrator must be alerted to potential issues. What should t...

To determine the most appropriate solution, let's evaluate the options based on their relevance to monitoring disk space on Amazon EC2 instances, their operational efficiency, and ease of implementation. A) Use built-in Amazon CloudWatch metrics, and configure CloudWatch alarms and an Amazon SNS topic for email notifications. - CloudWatch Metrics: Amazon CloudWatch offers built-in metrics for EC2 instances, including monitoring EC2 performance, but does not automatically include disk space monitoring for Windows-based EC2 instances. - Limitations: While CloudWatch provides useful metrics for CPU, memory, network, and disk I/O, it does not natively monitor disk space usage on Windows instances unless configured with additional tools or agents. - Efficiency: While the setup is efficient once configured, this approach doesn't provide immediate access to disk space data out-of-the-box for Windows EC2 instances. - Relevance: This option would require additional configuration (like setting up a custom metric via the CloudWatch Agent) to monitor disk space, but it's a valid approach for those who want deep customization and alerting for low storage space. Partially correct but requires additional setup for disk space monitoring. B) Use AWS CloudTrail logs and configure the trail to send notifications to an Amazon SNS topic. - CloudTrail Logs: CloudTrail is designed to monitor and log API calls made in AWS environments. It does not monitor the performance or status of EC2 instances or their resources like disk space. - Irrelevance: CloudTrail tracks management activity and API calls rather than resource performance. Using CloudTrail for disk space monitoring wouldn't be appropriate. - Operational Efficiency: This is not an effective way to monitor EC2 instance h...

Author: Aria · Last updated Jul 17, 2026

A company applies user-defined tags to resources that are associated with the company's AWS workloads. Twenty days after applying the tags, the company notices that it cannot use the tags to f...

Let's evaluate the options based on how AWS Cost Explorer works with user-defined tags and the possible causes for this issue: A) It takes at least 30 days to be able to use tags to filter views in Cost Explorer. - Timeframe for Tagging: This option is incorrect because there is no 30-day waiting period for user-defined tags to be used in AWS Cost Explorer. The time it takes to use tags depends on the specific actions taken with the tags (such as activating them for cost allocation), not a fixed waiting period. - Reasoning: If the tags are properly set up and activated for cost allocation, they should be usable immediately or shortly thereafter. Rejected because there is no mandatory 30-day waiting period for tag visibility in Cost Explorer. B) The company has not activated the user-defined tags for cost allocation. - Correct Process: AWS Cost Explorer can filter by tags only if the tags are activated for cost allocation. If the user-defined tags were not activated for cost allocation, they won't appear as filter options in Cost Explorer, even though they are applied to resources. - Operational Efficiency: This is the most likely cause of the issue. The company likely applied the tags but did not activate them for cost allocation, which is necessary for using tags in the Cost Explorer console. - Relevance: Activating tags for cost al...

Author: Sophia · Last updated Jul 17, 2026

A company has a critical serverless application that uses multiple AWS Lambda functions. Each Lambda function generates 1 GB of log data daily in its own Amazon CloudWatch Logs log group. The company's security team asks for a count of application errors, gr...

To meet the security team's requirement of getting a count of application errors grouped by type across all log groups, let's evaluate the options based on their ability to aggregate and query log data efficiently: A) Perform a CloudWatch Logs Insights query that uses the stats command and count function. - CloudWatch Logs Insights: This is a powerful and flexible tool designed specifically for querying and analyzing log data within CloudWatch Logs. It allows for complex searches, filtering, and aggregating log data across multiple log groups. - Relevance: The `stats` command in CloudWatch Logs Insights can be used to aggregate data (like counting occurrences of errors grouped by type) and is ideal for this situation. - Efficiency: CloudWatch Logs Insights can query across multiple log groups and provide real-time results. It is designed to work with large amounts of log data generated by services like Lambda. - Optimal Solution: This option is well-suited for the task because it directly supports querying logs across multiple log groups and aggregating the data in the way needed (grouped by error type). Selected because CloudWatch Logs Insights is designed for log aggregation, querying, and analysis, making it the best fit for counting errors and grouping them. B) Perform a CloudWatch Logs search that uses the groupby keyword and count function. - CloudWatch Logs Search: While CloudWatch Logs supports searching and filtering logs, it doesn't have an advanced aggregation feature like `groupby` with `count` functions. The search capabiliti...

Author: Zain · Last updated Jul 17, 2026

A company with multiple AWS accounts needs to obtain recommendations for AWS Lambda functions and identify optimal resource configurations for each Lambda functio...

To provide recommendations for AWS Lambda functions and identify optimal resource configurations for each function, let's evaluate the options based on their capabilities to provide performance and resource optimization recommendations. A) Create an AWS Serverless Application Repository and export the Lambda function recommendations. - AWS Serverless Application Repository: This service is used for sharing and deploying serverless applications, not for providing optimization or performance recommendations for Lambda functions. - Irrelevance: The Serverless Application Repository is focused on deployment and sharing pre-built applications, not on performance or resource optimization. Rejected because it does not provide optimization or resource recommendations for Lambda functions. B) Enable AWS Compute Optimizer and export the Lambda function recommendations. - AWS Compute Optimizer: AWS Compute Optimizer provides recommendations for optimizing EC2 instances, Auto Scaling groups, and Lambda functions by suggesting optimal resource configurations based on usage patterns. - Relevance: Compute Optimizer can indeed analyze Lambda functions and provide recommendations for optimal memory configurations based on their execution patterns and performance. - Efficiency: This service directly addresses the need for Lambda function resource optimization, which includes memory configuration recommendations based on real usage. Selected be...

Author: Elizabeth · Last updated Jul 17, 2026

A company uses AWS CloudFormation templates to deploy cloud infrastructure. An analysis of all the company's templates shows that the company has declared the same components in multiple templates. A SysOps administrator needs to create dedicated templates that h...

To address the scenario where a company is using AWS CloudFormation templates to deploy cloud infrastructure and wants to refactor and manage common components, the best solution is CloudFormation nested stacks. Let's go through the options, explain the reasoning behind the selected option, and discuss why other options are less suitable. A) Develop a CloudFormation change set - Explanation: A change set is a summary of the changes that AWS CloudFormation will make when you update a stack. It shows the differences between the current stack and the proposed changes, but it doesn't help with managing reusable components. - Why it's rejected: A change set is primarily used for reviewing and applying updates to CloudFormation stacks, not for reusing common components across multiple templates. It doesn't address the need for modular templates or component reuse. B) Develop CloudFormation macros - Explanation: CloudFormation macros enable you to extend CloudFormation templates with custom processing logic by using AWS Lambda functions. Macros can transform templates before they are executed, enabling dynamic and flexible template creation. - Why it's rejected: While macros can provide dynamic behavior, they are not designed specifically for modularizing reusable infrastructure components across multiple templates. They focus on transforming templates, which might introduce unnecessary complexity for this scenario. The use case described requires the reuse of infrastructure components, which can be better handled through nested stacks. C) Develop CloudFormation nested stacks - Explanation: Nested stacks allow you to create a stack within another stack. By using nested stacks, you can encapsulate common ...

Author: Leah · Last updated Jul 17, 2026

A SysOps administrator is building a process for sharing Amazon RDS database snapshots between different accounts associated with different business units within the same company. All data ...

To implement a process for sharing Amazon RDS database snapshots between different accounts associated with different business units within the same company, with the requirement that all data must remain encrypted at rest, let's evaluate each option and determine the most suitable solution. A) Write a script to download the encrypted snapshot, decrypt it using the AWS KMS encryption key used to encrypt the snapshot, then create a new volume in each account. - Explanation: This option involves decrypting the snapshot and creating a new volume in each account. However, decrypting and re-encrypting the snapshot outside the management of AWS KMS would violate the encryption-at-rest requirement. Additionally, there are potential challenges in transferring encrypted data safely across accounts. - Why it's rejected: Decrypting the snapshot using a script outside of AWS KMS management would compromise the encryption-at-rest requirement and add unnecessary complexity. It is not a practical solution within the AWS framework for sharing RDS snapshots securely. B) Update the key policy to grant permission to the AWS KMS encryption key used to encrypt the snapshot with all relevant accounts, then share the snapshot with those accounts. - Explanation: This solution involves granting the necessary permissions to the AWS KMS encryption key used to encrypt the snapshot, so other accounts can access the encrypted snapshot. By modifying the key policy to allow cross-account access, the snapshot can be shared securely while maintaining encryption at rest. - Why it's selected: This option is the most straightforward and efficient approach. AWS allows for sharing encrypted snapshots with other accounts by granting the necessary permissions to the KMS key. This ensures that the encryption-at-rest requirement is satisfied, and no data is decrypted outside of the intended control of the accounts involved. It leverages AWS-native functionality for cross-account sharing of encrypted snapshots. C) Create an Amazon EC2 instance based on the snapshot, then save the instance's Amazon EBS volume as a snapshot and share it with the other accounts. Require each account owner to create...

Author: Sofia2021 · Last updated Jul 17, 2026

A SysOps administrator configures an Amazon S3 gateway endpoint in a VPC. The private subnets inside the VPC do not have outbound internet access. User logs in to an Amazon EC2 instance in one of the private subnets and cannot upl...

To address the issue where an EC2 instance in a private subnet cannot upload a file to an Amazon S3 bucket, we need to understand the components involved and the underlying problem. Problem Recap: - The EC2 instance resides in a private subnet, meaning it does not have outbound internet access. - The S3 bucket is in the same AWS region, and there is a configured S3 gateway endpoint in the VPC. - The EC2 instance cannot upload a file to the S3 bucket. Let's evaluate each option: A) Update the EC2 instance role policy to include `s3:PutObject` access to the target S3 bucket. - Explanation: The EC2 instance requires permissions to upload to the S3 bucket, which can be granted by the instance role policy. However, this is not the core issue in this scenario, as permissions related to accessing S3 resources (like `s3:PutObject`) should already be in place to perform uploads. - Why it's rejected: The issue described is more likely related to network access, as the EC2 instance is in a private subnet with no internet access, rather than a lack of permissions to access the S3 bucket. B) Update the EC2 security group to allow outbound traffic to 0.0.0.0/0 for port 80. - Explanation: This option would allow the EC2 instance to access the internet on port 80, which is typically used for HTTP traffic. However, since the S3 gateway endpoint is used, traffic to S3 does not require internet access but instead uses the private VPC route to the S3 endpoint. - Why it's rejected: This approach is unnecessary and inefficient. The EC2 instance should not need internet access to interact with S3 if the S3 gateway endpoint is correctly configured. Enabling internet access for outbound traffic does not resolve the specific issue of using the S3 gateway endpoint. C) Update the EC2 subnet route table to include the S3 prefix list destination routes to the S3 gateway endpoint. - Explanation: T...

Author: Mia · Last updated Jul 17, 2026

A company uses Amazon S3 to aggregate raw video footage from various media teams across the US. The company recently expanded into new geographies in Europe and Australia. The technical teams located in Europe and Australia reported delays when uploading large video files into the destination S3 b...

In this scenario, the company is experiencing delays when uploading large video files into an S3 bucket located in the United States from offices in Europe and Australia. To increase upload speeds, let's evaluate the most cost-effective solutions. A) Create multiple AWS Direct Connect connections between AWS and branch offices in Europe and Australia for file uploads into the destination S3 bucket. - Explanation: AWS Direct Connect provides a dedicated network connection between your premises and AWS. This can offer higher bandwidth and lower latency than typical internet connections. However, setting up multiple Direct Connect connections involves significant costs, including the setup and ongoing charges for the physical infrastructure and bandwidth usage. - Why it's rejected: While Direct Connect can improve network performance, it's typically more expensive than other solutions, especially for smaller to medium-sized operations or for scenarios that don't require consistent, high-throughput connections. It's not the most cost-effective solution here. B) Create multiple AWS Site-to-Site VPN connections between AWS and branch offices in Europe and Australia for file uploads into the destination S3 bucket. - Explanation: A Site-to-Site VPN connects your on-premises network to AWS over an encrypted VPN connection. While this improves security and reliability over the public internet, it doesn't necessarily offer significantly higher bandwidth or lower latency compared to Direct Connect. VPN connections also rely on the public internet, which can still introduce delays. - Why it's rejected: While VPN connections can provide secure communication, they generally don't offer the level of performance and speed benefits that would help with uploading large video files efficiently. Additionally, maintaining multiple VPN connections could be complex and costly in comparison to other solutions designed specifically to improve upload speeds. C) Use Amazon S3 Transfer Acceleration for file uploads into the destination S3 bucket. - Explanation: Amazon S3 Transfer Acceleration leverages Amazon CloudFront’s globally distributed edge locations to speed up uploads to S3. This works by routing data through the closest edge location to the source and then transferring it to the S3 bucket over optimized paths. It’s ideal for uploading large files across long distances. - Why it's selected: S3 Transfer Acceleration is specifically designed to speed up uploads from geographically distant locations. It reduces latency by routing data through CloudFront’s edge locations, a...

Author: Henry · Last updated Jul 17, 2026

A SysOps administrator is helping a development team deploy an application to AWS. The AWS CloudFormation template includes an Amazon Linux EC2 instance, an Amazon Aurora DB cluster, and a hardcoded database password that...

When managing sensitive data like a database password, security best practices should be followed to minimize the risk of exposure and simplify management tasks such as rotation. Let's evaluate each of the provided options and determine the most secure solution. A) Use the AWS::SecretsManager::Secret resource with the `GenerateSecretString` property to automatically generate a password. Use the AWS::SecretsManager::RotationSchedule resource to define a rotation schedule for the password. Configure the application to retrieve the secret from AWS Secrets Manager to access the database. - Explanation: This option leverages AWS Secrets Manager, which is specifically designed for managing sensitive data like passwords. The `GenerateSecretString` property can automatically create a secure password, and the `RotationSchedule` resource ensures the password is rotated every 90 days (or on a schedule that fits the requirement). Additionally, AWS Secrets Manager integrates with various services to help retrieve secrets securely at runtime. - Why it's selected: This is the most secure option because AWS Secrets Manager is designed for secure storage and management of credentials. It supports automatic password generation, rotation, and retrieval. Using this service ensures that the database password is rotated according to the defined schedule, and there is minimal human intervention required, reducing the risk of mismanagement or exposure. B) Use the AWS::SecretsManager::Secret resource with the `SecretString` property. Accept a password as a CloudFormation parameter. Use the `AllowedPattern` property of the CloudFormation parameter to require a minimum length, uppercase and lowercase letters, and special characters. Configure the application to retrieve the secret from AWS Secrets Manager to access the database. - Explanation: This option uses AWS Secrets Manager but manually accepts a password as an input parameter, and you can enforce certain password policies (e.g., length, complexity) via the `AllowedPattern` property. While this can ensure some level of password complexity, it doesn't automate the rotation of the password. - Why it's rejected: Although this option is secure in terms of storing the password in AWS Secrets Manager, it does not address the requirement for automatic password rotation. The password would need to be manually rotated every 90 days, which increases the risk of human error and oversight. C) Use the AWS::SSM::Parameter resource. Accept input as a CloudFormation parameter to store the parameter as a secure stri...

Author: Mia · Last updated Jul 17, 2026

Application A runs on Amazon EC2 instances behind a Network Load Balancer (NLB). The EC2 instances are in an Auto Scaling group and are in the same subnet that is associated with the NLB. Other applications from an on-premises environment cannot communicate with Application A on port 8080. To troubleshoot the issue, a S...

To troubleshoot the rejected traffic to Application A, we need to carefully examine each option and its relevance to the flow logs and network configuration. Option A: The security group of the EC2 instances has no Allow rule for the traffic from the NLB - Reasoning: Security groups act as virtual firewalls for EC2 instances and control inbound and outbound traffic. If the EC2 instances' security group doesn't allow traffic from the NLB, then the instances won't be able to receive traffic, even if the Network Load Balancer is routing it. This could easily result in traffic being rejected. - Why it’s relevant: The NLB sends traffic to EC2 instances, but if the security group of the instances doesn’t allow traffic from the NLB (or the proper source IP range or protocol), the traffic will be rejected. Option B: The security group of the NLB has no Allow rule for the traffic from the on-premises environment - Reasoning: The NLB itself does not have security groups. Instead, it uses security groups associated with its target EC2 instances, which are responsible for filtering traffic. Since the NLB doesn't use security groups directly (it operates at the network layer), this option is irrelevant in this context. - Why it’s rejected: NLB doesn’t have security groups, only the EC2 instances do. Option C: The ACL of the on-premises environment does not allow traffic to the AWS environment - Reasoning: The ACL of the on-premises environment is outside AWS and governs traffic from on-pre...

Author: Deepak · Last updated Jul 17, 2026

A company's SysOps administrator maintains a highly available environment. The environment includes Amazon EC2 instances and an Amazon RDS Multi-AZ database. The EC2 instances are in an Auto Scaling group behind an Application Load Balancer. Recently, the company conducted a failover test. The SysOps ...

To decrease the failover time of an Amazon RDS Multi-AZ database by at least 10%, we need to evaluate the given options based on their ability to optimize failover behavior, specifically improving the time it takes for RDS to switch to the standby instance in case of a failure. Let’s go through each option. Option A: Increase the RDS instance size - Reasoning: Increasing the instance size of the RDS database could improve performance and scalability under load, but it doesn’t directly affect the failover time. The failover time in RDS is influenced by the time it takes to promote the standby instance and reroute connections. Changing the instance size may help with performance but won't have a significant impact on failover times. - Why it’s rejected: This option may enhance performance, but it does not address the core issue of reducing failover time. Option B: Modify the RDS cluster to run in a single Availability Zone - Reasoning: RDS Multi-AZ deployments are designed for high availability and automatic failover. If you switch to a single Availability Zone, you eliminate the failover process altogether because there would be no second availability zone to fail over to. This would actually make your environment less fault-tolerant, not more available. - Why it’s rejected: This solution would compromise availability and eliminate the very mechanism that you’re trying to improve (failover). It's not a good choice for improving failover time. Option C: Create a read replica in another AWS Region. Promote the read replica in case of failure - Reasonin...

Author: Emma · Last updated Jul 17, 2026

A company's VPC has connectivity to an on-premises data center through an AWS Site-to-Site VPN. The company needs Amazon EC2 instances in the VPC to send DNS queries for example.com to th...

To meet the requirement of having Amazon EC2 instances in the VPC send DNS queries for `example.com` to the DNS servers in the on-premises data center, we need to carefully consider the options and how Amazon Route 53 Resolver works in conjunction with Site-to-Site VPN and DNS forwarding. Option A: Create an Amazon Route 53 Resolver inbound endpoint. Create a conditional forwarding rule on the on-premises DNS servers to forward DNS requests for example.com to the inbound endpoints. - Reasoning: An inbound endpoint in Route 53 Resolver allows DNS queries from on-premises networks (or other external sources) to be routed into your VPC. However, the on-premises DNS server would need to forward queries to this inbound endpoint, which is typically used for queries originating from outside the VPC (not for queries originating inside the VPC). This approach is not suited for sending queries from EC2 instances within the VPC. - Why it’s rejected: This solution is designed for allowing external sources to send DNS queries into the VPC. It doesn’t meet the requirement of having EC2 instances in the VPC send DNS queries to the on-premises DNS servers. Option B: Create an Amazon Route 53 Resolver inbound endpoint. Create a forwarding rule on the resolver that sends all queries for example.com to the on-premises DNS servers. Associate this rule with the VPC. - Reasoning: This option uses an inbound endpoint in Route 53 Resolver, but it’s designed to handle DNS queries coming into the VPC, not leaving it. A forwarding rule on the resolver would send queries to the on-premises DNS servers, but this is not the right configuration for queries originating within the VPC. - Why it’s rejected: This approach is not suitable because it deals with traffic coming into the VPC rather than forwarding queries from the VPC to on-premises DNS servers. Option C: Create an Amazon Route 53 Resolver outbound endpoint. Create a condi...

Author: Victoria · Last updated Jul 17, 2026

A SysOps administrator is tasked with analyzing database performance. The database runs on a single Amazon RDS DB instance. The SysOps administrator finds that, during times of peak traffic, resources on the database are overutilized due to the amount of...

To improve the performance of the Amazon RDS database, particularly due to overutilization during peak read traffic, we need to focus on scaling the database's ability to handle more read requests while ensuring reliability. Let's review each option and select the best solutions based on the requirements. Option A: Add a read replica - Reasoning: A read replica in Amazon RDS helps offload read traffic from the primary database instance. Since the issue described is that read traffic is overutilizing resources on the database, adding one or more read replicas can help distribute the read load, improving performance during peak times. - Why it's selected: This solution addresses the specific problem of overutilized resources due to read traffic. The read replica can handle the read queries, allowing the primary instance to focus on write operations, thus improving overall performance. Option B: Modify the application to use Amazon ElastiCache for Memcached - Reasoning: Amazon ElastiCache can help by caching frequently accessed data, reducing the load on the database for repeated queries. However, this is a caching solution, not directly related to read replicas. It can certainly improve performance, but its effectiveness depends on the application's caching strategy and the type of queries. - Why it's selected: This could be a helpful optimization for reducing database load, particularly for read-heavy applications. However, adding a read replica specifically addresses the problem of overutilized database resources more directly by offloading read traffic to separate instances. Option C: Migrate the database from RDS to Amazon DynamoDB - Reasoning: Amazon DynamoDB is a NoSQL database designed for high scalability and low-latency access. However, migrating from a relational database (RDS) to a NoSQL solution like DynamoDB is a significant architectural change. This might not be a suitable option if the current application depends on relational features (e.g., joins, com...

Author: Suresh · Last updated Jul 17, 2026

A company's SysOps administrator has created an Amazon EC2 instance with custom software that will be used as a template for all new EC2 instances across multiple AWS accounts. The Amazon Elastic Block Store (Amazon EBS) volumes that are attached to the EC2 instance are encrypted with AWS managed keys. The SysOps administrator creates an Amazon Machine Image (AMI) of the custom EC2 instance and plans to share the AMI with the company's other AWS accounts. The company requires that ...

To securely share the Amazon Machine Image (AMI) with other AWS accounts while ensuring encryption with AWS Key Management Service (KMS) keys and proper access control, let’s analyze each option carefully: Option A: In the account where the AMI was created, create a customer managed KMS key. Modify the key policy to provide kms:DescribeKey, kms:ReEncrypt, kms:CreateGrant, and kms:Decrypt permissions to the AWS accounts that the AMI will be shared with. Modify the AMI permissions to specify the AWS account numbers that the AMI will be shared with. - Reasoning: This option involves creating a customer-managed KMS key, which allows more granular control over encryption and permissions. By modifying the key policy to provide access to specific AWS accounts, the administrator ensures that only authorized accounts can use the AMI. The AMI permissions are also updated to specify which accounts can access it. This approach works well with encrypted AMIs because it ensures that only the authorized accounts can decrypt the associated volumes. - Why it’s selected: This solution allows for encrypted AMIs using a customer-managed KMS key and ensures access control is restricted to specific AWS accounts. The key policy ensures that only authorized accounts can use the key to decrypt the AMI, making it secure. Option B: In the account where the AMI was created, create a customer managed KMS key. Modify the key policy to provide kms:DescribeKey, kms:ReEncrypt, kms:CreateGrant, and kms:Decrypt permissions to the AWS accounts that the AMI will be shared with. Create a copy of the AMI, and specify the KMS key. Modify the permissions on the copied AMI to specify the AWS account numbers that the AMI will be shared with. - Reasoning: This option adds the step of creating a copy of the original AMI and specifying the customer-managed KMS key during the copy process. After copying, the permissions are modified to specify the target AWS accounts. This solution is correct as it uses a customer-managed KMS key and restricts access to specific accounts. However, it adds an extra copy step, which is unnecessary if the original AMI can already be shared securely...

Author: Ethan · Last updated Jul 17, 2026

A company is migrating its production file server to AWS. All data that is stored on the file server must remain accessible if an Availability Zone becomes unavailable or when system maintenance is performed. Users must be able to interact with the file server through the SMB protocol. User...

Let's break down each option and analyze it based on the key requirements: - Availability (ensuring data is accessible if an Availability Zone becomes unavailable). - SMB protocol (users must interact with the file server through the SMB protocol). - Windows ACLs (users must be able to manage file permissions using Windows ACLs). Option A: Create a single AWS Storage Gateway file gateway. - Reasoning: AWS Storage Gateway provides hybrid cloud storage by enabling on-premises applications to use cloud storage via standard protocols like SMB, NFS, and iSCSI. However, a single file gateway lacks Availability Zone redundancy. If the Availability Zone where the gateway resides becomes unavailable, users would lose access to the data. - Why rejected: Does not provide multi-AZ high availability, which is critical for this scenario where Availability Zone failure is a concern. Option B: Create an Amazon FSx for Windows File Server Multi-AZ file system. - Reasoning: Amazon FSx for Windows File Server provides fully managed Windows file storage, supporting SMB and Windows ACLs. A Multi-AZ FSx deployment ensures high availability as it replicates data across multiple Availability Zones. This means that if one Availability Zone fails, users can still access their data through the other Availability Zone. - Why selected: This option satisfies all the requirements—providing high availability, supporting SMB protocol, and allowing management of Windows ACLs. It is also fully managed, reducing operational overhead. Option C: Deploy two AWS Storage Gateway file gateways across two Availability Zones. Configure an Application Load Balancer in front of the file gate...

Author: Victoria · Last updated Jul 17, 2026

A SysOps administrator needs to create alerts that are based on the read and write metrics of Amazon Elastic Block Store (Amazon EBS) volumes that are attached to an Amazon EC2 instance. The SysOps administrator creates and enables Amazon CloudWatch alarms for the DiskReadBytes metric and the DiskWriteBytes metric. A custom monitoring tool that is installed on the EC2 instance with the same alarm configuration indicates ...

Let's break down each option and analyze it based on the requirements: - The need to create alarms based on the read and write metrics of Amazon Elastic Block Store (Amazon EBS) volumes attached to an EC2 instance. - The alarm is not triggering when the DiskReadBytes and DiskWriteBytes metrics are used. Option A: Install and configure the CloudWatch agent on the EC2 instance to capture the desired metrics. - Reasoning: The CloudWatch agent can collect additional system-level metrics, including disk I/O, CPU usage, memory usage, and other metrics that are not natively available through the default EC2 instance metrics. However, CloudWatch alarms on the EC2 instance disk metrics might not be the correct approach here because DiskReadBytes and DiskWriteBytes are specific to EBS volumes, not EC2 instance-level metrics. - Why rejected: This option might help with collecting custom metrics but would not resolve the problem of using the appropriate EBS metrics for CloudWatch alarms. The issue is that the wrong metric types (DiskReadBytes and DiskWriteBytes for EC2) are being used instead of EBS-specific metrics. Option B: Install and configure AWS Systems Manager Agent on the EC2 instance to capture the desired metrics. - Reasoning: AWS Systems Manager Agent (SSM Agent) is used primarily for systems management tasks such as patching, configuration management, and automation, rather than monitoring EBS volume metrics. - Why rejected: The SSM Agent doesn't directly address the problem of CloudWatch alarms not triggering because it is not designed for collecting EBS volume-specific metrics like `VolumeReadBytes` and `VolumeWriteBytes`. This solution doesn't address the specific need for the correct EBS metrics. Option C: Rec...

Author: Isabella1 · Last updated Jul 17, 2026

A company recently moved its server infrastructure to Amazon EC2 instances. The company wants to use Amazon CloudWatch metrics to track instance memory utilization and available di...

Let's break down each option and analyze it based on the need to track instance memory utilization and available disk space using Amazon CloudWatch. Option A: Configure CloudWatch from the AWS Management Console for all the instances that require monitoring by CloudWatch. AWS automatically installs and configures the agents for the specified instances. - Reasoning: This option implies automatic configuration of CloudWatch metrics for monitoring, but CloudWatch does not automatically install or configure agents for instance-level memory utilization and disk space. By default, CloudWatch only provides EC2 instance-level metrics such as CPU utilization, network traffic, and disk I/O, but not memory or disk space. - Why rejected: CloudWatch cannot automatically install the agent and configure it for memory or disk space metrics; manual installation of the CloudWatch agent is necessary for monitoring memory and disk metrics. Option B: Install and configure the CloudWatch agent on all the instances. Attach an IAM role to allow the instances to write logs to CloudWatch. - Reasoning: To monitor memory utilization and available disk space on EC2 instances, you need to install and configure the CloudWatch agent on the instances. The IAM role is required to allow EC2 instances to send the collected metrics and logs to CloudWatch. - Why selected: This is the correct approach. The CloudWatch agent needs to be installed on each EC2 instance to collect custom metrics (like memory utilization and disk space), and the IAM role allows ...

Author: Kai · Last updated Jul 17, 2026

A company recently deployed MySQL on an Amazon EC2 instance with a default boot volume. The company intends to restore a 1.75 TB database. A SysOps administrator needs to provision the correct Amazon Elastic Block Store (Amazon EBS) volume. The database will require read performance of up t...

Let's break down each option to determine which one will meet the required performance for the MySQL database while also being the lowest cost solution. Option A: Deploy a 2 TB Cold HDD (sc1) volume. - Reasoning: Cold HDD (sc1) is designed for low-cost, infrequently accessed data. It provides low throughput and low IOPS and is not suited for high-performance applications like MySQL databases that require high read performance. - Why rejected: This option will not meet the required read performance of 10,000 IOPS. The sc1 volume is designed for cold storage with much lower performance, making it unsuitable for this scenario. Option B: Deploy a 2 TB Throughput Optimized HDD (st1) volume. - Reasoning: Throughput Optimized HDD (st1) is designed for large, sequential workloads, such as data warehouses, that require high throughput but not low-latency random IOPS. It can provide high throughput, but it doesn't provide the high IOPS needed for a MySQL database, which requires low-latency, random read/write access. - Why rejected: This option is not designed to handle the random read/write operations that MySQL databases require. It offers good throughput for sequential workloads but doesn't meet the high IOPS requirement. Option C: Deploy a 2 TB General Purpose SSD (gp3) volume. Set the IOPS to 10,000. - Reasoning: General Purpose SSD (gp3) volumes provide balanced performance and allow users to provision both IOPS and throughput independently. A gp3 volume can be configured with up to 16,000 IOPS and up to 1,000 MB/s throughput. By setting the IOPS to 10,000, you will meet the performance requirements for this workload, and this is a...

Author: IronLion88 · Last updated Jul 17, 2026

A SysOps administrator is setting up a fleet of Amazon EC2 instances in an Auto Scaling group for an application. The fleet should have 50% CPU available at all times to accommodate bursts of traffic. The load will increase significantly between the hours of 09:00 and 17:00, 7 da...

Let's evaluate each option based on the requirements: Requirements: - 50% CPU utilization should be maintained at all times to accommodate bursts of traffic. - Significant load increase between 09:00 and 17:00. - The Auto Scaling group needs to scale dynamically to handle varying load during the day, maintaining adequate capacity for the increased traffic. Option A: Create a target tracking scaling policy that runs when the CPU utilization is higher than 90%. - Reasoning: This scaling policy would only trigger when CPU utilization is higher than 90%. However, this is not ideal since the goal is to ensure 50% CPU utilization is available at all times to accommodate bursts, and scaling only at 90% will likely result in delayed responses and insufficient resources during traffic spikes. - Why rejected: The scaling action would be too delayed, as it triggers only when CPU utilization is very high (90%). The system would not be prepared to handle bursts of traffic at 50% CPU in advance. Option B: Create a target tracking scaling policy that runs when the CPU utilization is higher than 50%. Create a scheduled scaling policy that ensures that the fleet is available at 09:00. Create a second scheduled scaling policy that scales in the fleet at 17:00. - Reasoning: - Target tracking scaling policy: This policy will ensure that the system maintains 50% CPU utilization at all times, dynamically scaling the fleet as needed based on CPU usage. This addresses the primary goal of having enough resources to handle traffic bursts while keeping the CPU usage at the target level. - Scheduled scaling policies: These policies ensure that the fleet is scaled up at 09:00 to meet the increased demand and scales down at 17:00 to reduce costs after the peak traffic time. - Why selected: This solution effectively combines both dynamic scaling (target tracking) and scheduled scaling to address both the daily variation in load and the need to maintain 50% CPU utilization, ensuring that resources are available for traffic bursts dur...

Author: Leah · Last updated Jul 17, 2026

A company has turned on server access logging for all of its existing Amazon S3 buckets. The company wants to implement a solution to monitor the logging settings for new and existing S3 buckets. The solution must remediate any S3 buckets that do not have logging turn...

To address the company's requirement of monitoring and remediating S3 bucket logging settings in an operationally efficient manner, let's evaluate each of the options: Option A: Track the logging information by using AWS CloudTrail. Launch an AWS Lambda function for remediation. - Why it's not ideal: AWS CloudTrail tracks API calls made to AWS services, including S3, but it is not specifically designed to monitor S3 logging configurations. CloudTrail does not directly evaluate whether logging is enabled or not on S3 buckets. Although you can create a Lambda function to remediate non-compliant buckets based on CloudTrail logs, this approach is not as straightforward and could lead to unnecessary complexity because it doesn't provide a built-in way to evaluate S3 logging configurations automatically. - Operational efficiency concern: Manually creating Lambda functions and using CloudTrail logs to identify non-compliant buckets can increase operational overhead, making it less efficient. Option B: Configure automatic remediation in AWS Config by using the s3-bucket-logging-enabled rule. - Why it's ideal: AWS Config is a service specifically designed to assess, audit, and evaluate the configurations of AWS resources, including S3 buckets. The `s3-bucket-logging-enabled` rule is built to evaluate whether S3 buckets have logging enabled, which exactly matches the company’s requirement. Additionally, AWS Config allows automatic remediation via integration with AWS Systems Manager Automation or AWS Lambda when non-compliant resources are found. This option is operationally efficient because it directly addresses the requirement and has built-in automation features...

Author: Elijah · Last updated Jul 17, 2026

A company is running Amazon EC2 On-Demand Instances in an Auto Scaling group. The instances process messages from an Amazon Simple Queue Service (Amazon SQS) queue. The Auto Scaling group is set to scale based on the number of messages in the queue. Messages can take up to 12 hours to process completely. A SysOps administrator mu...

To meet the requirement of ensuring that instances are not interrupted during message processing while using an Auto Scaling group to scale based on the number of messages in an Amazon SQS queue, let's evaluate the options: Option A: Enable instance scale-in protection for the specific instance in the Auto Scaling group at the start of message processing by calling the Amazon EC2 Auto Scaling API from the processing script. Disable instance scale-in protection after message processing is complete by calling the Amazon EC2 Auto Scaling API from the processing script. - Why it's ideal: Enabling instance scale-in protection prevents Auto Scaling from terminating the instance during scaling down actions (i.e., when the number of messages in the queue decreases). This ensures that the instance will not be interrupted until it has finished processing the messages. The scale-in protection can be dynamically managed via the EC2 Auto Scaling API, ensuring that the instance remains protected while processing and is only removed from protection after message processing is complete. - Operational efficiency: This solution specifically addresses the requirement of not interrupting the instance during message processing while allowing it to scale back in afterward. It requires minimal effort and ensures that the instance is protected as needed. Option B: Set the Auto Scaling group's termination policy to OldestInstance. - Why it's not ideal: The "OldestInstance" termination policy ensures that the oldest instance in the Auto Scaling group is terminated first when scaling down. While this could potentially prevent the interruption of an instance that is processing messages, it does not provide a guarantee that the instance currently processing a message will be the one that is not terminated. The Auto Scaling group might still terminate an instance that is processing messages if it's the oldest instance, which does not meet the ...

Author: Isabella · Last updated Jul 17, 2026

A company manages a set of accounts on AWS by using AWS Organizations. The company's security team wants to use a native AWS service to regularly scan all AWS accounts against the Center for Internet Security (CIS) AWS Fo...

To determine the most operationally efficient way to regularly scan all AWS accounts against the Center for Internet Security (CIS) AWS Foundations Benchmark, let's evaluate each of the options: Option A: Designate a central security account as the AWS Security Hub administrator account. Create a script that sends an invitation from the Security Hub administrator account and accepts the invitation from the member account. Run the script every time a new account is created. Configure Security Hub to run the CIS AWS Foundations Benchmark scans. - Why it's not ideal: Although AWS Security Hub can be used to run the CIS AWS Foundations Benchmark, this option introduces a manual and repetitive task of creating and running a script every time a new account is created. This adds complexity and overhead to the operational process, which diminishes operational efficiency. - Operational efficiency concern: The manual steps required for each new account make this approach less efficient compared to a more automated solution. Option B: Run the CIS AWS Foundations Benchmark across all accounts by using Amazon Inspector. - Why it's not ideal: Amazon Inspector is primarily designed for automated security assessments, focusing on vulnerabilities and compliance checks for EC2 instances and other resources, rather than for comprehensive CIS AWS Foundations Benchmark scans across AWS accounts. It is not specifically tailored for running the CIS AWS Foundations Benchmark at the account level. - Operational efficiency concern: While Amazon Inspector provides great security assessments for workloads, it doesn't directly support the CIS AWS Foundations Benchmark for accounts in a way that meets the company's needs. Option C: Designate a central security account as the Amazon Guar...

Author: Olivia · Last updated Jul 17, 2026

A company currently runs its infrastructure within a VPC in a single Availability Zone. The VPC is connected to the company's on-premises data center through an AWS Site-to-Site VPN connection attached to a virtual private gateway. The on-premises route tables route all VPC networks to the VPN connection. Communication between the two environments is working correctly. A SysOps administrator created new VPC subnets within a new Availability Zone, and deployed new reso...

To address the issue where communication cannot be established between the new resources in the new subnets and the on-premises environment, we need to evaluate each option based on the current setup. Option A: Add a route to the route tables of the new subnets that send on-premises traffic to the virtual private gateway. - Why it's ideal: When a new subnet is created within a VPC, the route tables associated with that subnet may not automatically include routes to the on-premises network through the Site-to-Site VPN connection. Therefore, the SysOps administrator needs to manually add a route in the new subnet's route table, directing traffic destined for the on-premises network to the virtual private gateway. This ensures that traffic from the new subnets can reach the on-premises environment. - Operational efficiency: This is a straightforward fix. It involves updating the route table for the new subnets to ensure they have a route to the virtual private gateway, which resolves the communication issue without making significant changes to the architecture. Option B: Create a ticket with AWS Support to request adding Availability Zones to the Site-to-Site VPN route configuration. - Why it's not ideal: The Site-to-Site VPN connection and the virtual private gateway are already in place, and the issue is related to the route tables in the VPC, not a limitation with the VPN configuration itself. There is no need to contact AWS Support for adding Availability Zones to the Site-to-Site VPN route configuration, as the problem is with...

Author: SilverBear · Last updated Jul 17, 2026

A SysOps administrator needs to collect the content of log files from a custom application that is deployed across hundreds of Amazon EC2 instances running Ubuntu. The log files need to be stored in Amazon CloudWatch Logs. How sho...

To collect the content of log files from custom applications deployed across hundreds of Amazon EC2 instances with the lowest operational overhead, let's evaluate each option: Option A: Configure the syslogd service on each EC2 instance to collect and send the application log files to CloudWatch Logs. - Why it's not ideal: This option requires manual configuration of `syslogd` on each EC2 instance, which could involve scripting or other complex configurations to ensure each instance sends logs to CloudWatch Logs. While `syslogd` can be used to send logs, this setup requires significant ongoing maintenance and manual configuration across hundreds of instances. - Operational efficiency concern: This approach introduces additional complexity in terms of configuration and maintenance, especially if log formats or applications change. It lacks the automation benefits that other options provide. Option B: Install the CloudWatch agent by using the Amazon Linux package manager on each EC2 instance. Configure each agent to collect the application log files. - Why it's not ideal: While this option is feasible, it still requires manual installation and configuration of the CloudWatch agent on each instance, especially since the EC2 instances are running Ubuntu, not Amazon Linux. Additionally, manual installation on hundreds of EC2 instances can be operationally burdensome without automation. - Operational efficiency concern: This method would involve additional manual work for installation and configuration, leading to higher overhead compared to fully automated options like AWS Systems Manager. Option C: Install the CloudWatch agent on each EC2 instance by using AWS Systems M...

Author: Leo · Last updated Jul 17, 2026

A SysOps administrator needs to design a disaster recovery (DR) plan for an application on AWS. The application runs on Amazon EC2 instances behind an Application Load Balancer (ALB). The instances are in an Auto Scaling group. The application uses an Amazon Aurora PostgreSQL database. The recovery time objective (RTO) and recovery point objective (RPO...

To design a cost-effective disaster recovery (DR) plan for an application hosted on AWS, we need to consider the application's architecture, RTO (Recovery Time Objective), RPO (Recovery Point Objective), and cost implications. Let's break down each of the options: A) Configure Aurora backups to be exported to the DR Region. - Reasoning: This option is not optimal for achieving a 15-minute RTO and RPO. Aurora backups, while useful for disaster recovery, do not allow for real-time replication of data across regions. This approach could result in longer recovery times and might not meet the RPO since data in the DR Region would only be as recent as the last backup. - Rejected: It doesn't provide the continuous, low-latency data replication needed to meet both RTO and RPO of 15 minutes. B) Configure the Aurora cluster to replicate data to the DR Region by using the Aurora global database option. - Reasoning: The Aurora global database option enables cross-region replication with low-latency and near-real-time data replication. This approach would meet both the RTO and RPO requirements, as the data is continuously replicated to the DR Region. In case of a failover, you can quickly promote the DR Region to be the primary region without data loss, thus meeting both RTO and RPO of 15 minutes. - Selected: This is the most cost-effective option that meets the RTO and RPO requirements, as it enables real-time replication with minimal downtime. C) Configure the DR Region with an ALB and an Auto Scaling group. Use the same configuration as in the primary Region. - Reasoning: This option is valid for ensuring the same infrastructure is ready in the DR Region, but it doesn't take into account cost efficiency. Keeping an ALB and Auto Scaling group running continuously in the DR Region would incur unnecessary cos...

Author: Ethan Smith · Last updated Jul 17, 2026

A SysOps administrator is creating a simple, public-facing website running on Amazon EC2. The SysOps administrator created the EC2 instance in an existing public subnet and assigned an Elastic IP address to the instance. Next, the SysOps administrator created and applied a new security group to the instance to allow incoming HTTP traffic from 0.0.0.0/0. Finally, the SysOps administrator created a new netwo...

To diagnose the issue, we need to evaluate the different network components involved in making a public-facing website accessible. The components in this case include the EC2 instance, security group, network ACL, and the Elastic IP address. Let's analyze each option: A) The SysOps administrator did not create an outbound rule that allows ephemeral port return traffic in the new network ACL. - Reasoning: When a user accesses a website, the initial request goes to port 80, but the server responds back through an ephemeral port (a random high-numbered port). However, outbound rules for the network ACL are typically required for outbound traffic that originates from the instance, such as HTTP response traffic. In this case, the issue is that the website cannot be reached from the internet (i.e., inbound HTTP traffic is being blocked), so the issue is not related to outbound rules. - Rejected: This does not explain the failure to access the website, as the problem lies in inbound HTTP traffic rather than outbound traffic. B) The SysOps administrator did not create an outbound rule in the security group that allows HTTP traffic from port 80. - Reasoning: Security groups are stateful, meaning that if inbound traffic is allowed, the return traffic (outbound) is automatically allowed without needing to specify outbound rules. Since the administrator already allowed inbound HTTP traffic (port 80) in the security group, the issue is not related to outbound rules in the security group. - Rejected: Security groups automatically handle outbound traffic in response to inbound connections. This doesn't explain the ...

Author: Amira99 · Last updated Jul 17, 2026

A company has an application that uses an Amazon Elastic File System (Amazon EFS) file system. A recent incident that involved an application logic error corrupted several files. The company wants to improve its ability to back up and recover the EFS file system. The compa...

Let's break down each option based on the company’s needs: recovering individual files rapidly and ensuring cost-effective backup for Amazon Elastic File System (Amazon EFS). A) Configure Amazon Data Lifecycle Manager (Amazon DLM) to archive a copy of the data to an Amazon S3 Glacier vault. Use S3 Glacier retrieval requests to retrieve individual files. - Reasoning: S3 Glacier is a low-cost storage solution suitable for long-term archival. However, it has long retrieval times, often taking hours to retrieve files. This would not meet the requirement for rapid file recovery, as S3 Glacier retrieval is not designed for quick access. - Rejected: While it may be cost-effective for long-term storage, the slow retrieval times make it unsuitable for rapid recovery of individual files. B) Create a second EFS file system in another AWS Region. Configure AWS DataSync to copy the data to the backup file system. Recover files by copying them from the backup EFS file system. - Reasoning: Creating a second EFS file system in a different AWS region using AWS DataSync ensures redundancy, but the backup is still a full copy of the file system. While AWS DataSync provides fast and efficient transfer, recovering individual files from a second file system would still require copying the entire file system or significant manual intervention. - Rejected: This solution is more complex and costly compared to other solutions that directly address individual file recovery. It doesn't meet the need for rapid file recovery as effective...

Author: Harper · Last updated Jul 17, 2026

A company migrates a write-once, ready-many (WORM) drive to an Amazon S3 bucket that has S3 Object Lock configured in governance mode. During the migration, the company copies unneeded data to the S3 bucket. A SysOps administrator attempts to delete the unneeded data from the S3 bucket by using the AWS CLI. However, the SysOps administ...

To address the issue where the SysOps administrator cannot delete unneeded data from an S3 bucket with S3 Object Lock in Governance mode, let's analyze each option carefully. Understanding the situation: - S3 Object Lock in Governance mode: This allows for retention of objects but gives some flexibility. In this mode, users with the appropriate permissions can delete objects or alter their retention settings. - The SysOps administrator faces an error when trying to delete objects, which suggests that the Governance mode lock is preventing the deletion. A) Increase the Retain Until Date. - Reasoning: Increasing the Retain Until Date would make the retention period longer, which would not help in deleting the data. The problem is that the objects are locked, and the administrator needs to bypass the retention lock. - Rejected: This would not help in deleting the objects and only prolongs the lock. B) Assume a role that has the s3:BypassLegalRetention permission. - Reasoning: The s3:BypassLegalRetention permission is relevant when working with objects under Legal Hold or under retention due to compliance reasons. It does not specifically bypass the governance lock in Governance mode. - Rejected: This permission is not applicable in this scenario where the lock is in Governance mode. C) Assume a role that has the s3:BypassGoverceRetention permission. - Reasoning: The s3:BypassGoverceRetention permission is specific to Governance mode and allows users to bypass the retention lock set in this mode. The permission would allow ...

Author: SilverBear · Last updated Jul 17, 2026

A company needs to view a list of security groups that are open to the internet on port 3389. What should a S...

To meet the requirement of viewing a list of security groups that are open to the internet on port 3389, let's analyze the options provided: A) Configure Amazon GuardDuty to scan security groups and report unrestricted access on port 3389. - Reasoning: Amazon GuardDuty is a threat detection service that analyzes AWS CloudTrail logs, VPC flow logs, and DNS logs to identify suspicious activity. While GuardDuty can detect malicious or unauthorized activities, it is not designed to provide direct visibility into security group configurations. GuardDuty does not specifically report on security group rules. - Rejected: GuardDuty focuses on threat detection, not configuration auditing. It cannot directly report on security groups that are open on port 3389. B) Configure a service control policy (SCP) to identify security groups that allow unrestricted access on port 3389. - Reasoning: Service Control Policies (SCPs) are used in AWS Organizations to define what actions are allowed or denied for accounts within an organization. SCPs do not audit or report on specific configurations of resources like security groups. They are primarily focused on controlling access to AWS services and actions rather than inspecting resource configurations. - Rejected: SCPs are not designed for auditing security group settings or network configurations, so this option does not apply to the requirement. C) Use AWS Identity and Access Management (IAM) Access Analyzer to find any instances that have...

Author: Emily · Last updated Jul 17, 2026

A company website contains a web tier and a database tier on AWS. The web tier consists of Amazon EC2 instances that run in an Auto Scaling group across two Availability Zones. The database tier runs on an Amazon RDS for MySQL Multi-AZ DB instance. The database subnet network ACLs are restricted to only the web subnets that need access to the database. The web subnets use the default network ACL with the default rules. The company's operations team has added a third subnet to the Auto Scaling group configuration. After an Auto Scaling event occurs, some users report that they intermittently receive an error message. The error message states that the server cannot conn...

To address the issue of web servers intermittently failing to connect to the database after an Auto Scaling event, we need to ensure that the network traffic between the web tier and the database tier is properly managed by both the network ACLs and the web servers' route tables. Key Points to Consider: - The web servers are in an Auto Scaling group across multiple Availability Zones and a new subnet has been added. - The database is using Amazon RDS for MySQL with a Multi-AZ deployment. - The issue could arise from network ACLs not being configured to allow traffic from the newly added subnet to the database tier. Let's break down each option: A) On the default ACL, create inbound Allow rules of type TCP with the ephemeral port range and the source as the database subnets. - Rejected: This would not solve the issue. The default ACL applies to the traffic coming into the web subnets, not the database subnets. Since the error occurs when the web servers cannot connect to the database, the inbound rules on the web subnet's network ACL are irrelevant. The database side's rules are more critical here. B) On the default ACL, create outbound Allow rules of type MySQL/Aurora (3306). Specify the destinations as the database subnets. - Rejected: This rule would allow the web servers to initiate connections to the database, but it focuses on the default ACL for the web subnets. While it seems relevant, the problem likely stems from the network ACLs on the database subnets preventing access from the newly added web subnet. C) On the network ACLs for the database subnets, create an inbound A...

Author: Julian · Last updated Jul 17, 2026

What Our Friends Say

What Our Friends Say

Amazon Practice Questions, Discussions & Exam Topics by our Authors

A company updates its security policy to prohibit the public exposure of any data in Amazon S3 buckets in the company's account. What...

A company's SysOps administrator needs to change the AWS Support plan for one of the company's AWS accounts. The account has multi-factor authentication (MFA) activated, and th...

A company is creating a new multi-account architecture. A SysOps administrator must implement a login solution to centrally manage user access and permissions across all AWS accounts. The solution must be integrated with AWS Organizations and must be connected to a third-party Security Assert...

A company is managing many accounts by using a single organization in AWS Organizations. The organization has all features enabled. The company wants to turn on AWS Config in all the accounts of the organization and in all AWS Regions. W...

A SysOps administrator needs to delete an AWS CloudFormation stack that is no longer in use. The CloudFormation stack is in the DELETE_FAILED state. The SysOps administrator has validated the permissions that are required to delete the Cloud...

A SysOps administrator needs to configure a solution that will deliver digital content to a set of authorized users through Amazon CloudFront. Unauthorized users must b...

A SysOps administrator has blocked public access to all company Amazon S3 buckets. The SysOps administrator wants to be notified when an S3 bucket becomes publicly readable in the fu...

A company plans to launch a static website on its domain example.com and subdomain www.example.com using Amazon S3. How ...

A SysOps administrator is configuring AWS Client VPN to connect users on a corporate network to AWS resources that are running in a VPC. According to compliance requirements, only traffic that is destined for the VPC can travel across t...

A web application runs on Amazon EC2 instances behind an Application Load Balancer (ALB). The instances run in an Auto Scaling group across multiple Availability Zones. A SysOps administrator notices that some of these EC2 instances show up as healthy in the A...

A SysOps administrator notices a scale up event for an Amazon EC2 Auto Scaling group. Amazon CloudWatch shows a spike in the RequestCount metric for the associated Application Load Balancer. The administrator would like to know th...

A company plans to migrate several of its high performance computing (HPC) virtual machines (VMs) to Amazon EC2 instances on AWS. A SysOps administrator must identify a placement group for this deployment. The strategy must minimize network latency and must maximize networ...

An errant process is known to use an entire processor and run at 100%. A SysOps administrator wants to automate restarting an Amazon EC2 instance when the pro...

A company maintains a large set of sensitive data in an Amazon S3 bucket. The company's security team asks a SysOps administrator to help verify that all current objects in the S3 bucket are encrypte...

A SysOps administrator is optimizing the cost of a workload. The workload is running in multiple AWS Regions and is using AWS Lambda with Amazon EC2 On-Demand Instances for the computer. The overall usage is predictable. The amount of computer that is consumed in each Region var...

A software company runs a workload on Amazon EC2 instances behind an Application Load Balancer (ALB). A SysOps administrator needs to define a custom health check for ...

A SysOps administrator is required to monitor free space on Amazon EBS volumes attached to Microsoft Windows-based Amazon EC2 instances within a company's account. The administrator must be alerted to potential issues. What should t...

A company applies user-defined tags to resources that are associated with the company's AWS workloads. Twenty days after applying the tags, the company notices that it cannot use the tags to f...

A company has a critical serverless application that uses multiple AWS Lambda functions. Each Lambda function generates 1 GB of log data daily in its own Amazon CloudWatch Logs log group. The company's security team asks for a count of application errors, gr...

A company with multiple AWS accounts needs to obtain recommendations for AWS Lambda functions and identify optimal resource configurations for each Lambda functio...

A company uses AWS CloudFormation templates to deploy cloud infrastructure. An analysis of all the company's templates shows that the company has declared the same components in multiple templates. A SysOps administrator needs to create dedicated templates that h...

A SysOps administrator is building a process for sharing Amazon RDS database snapshots between different accounts associated with different business units within the same company. All data ...

A SysOps administrator configures an Amazon S3 gateway endpoint in a VPC. The private subnets inside the VPC do not have outbound internet access. User logs in to an Amazon EC2 instance in one of the private subnets and cannot upl...

A SysOps administrator is helping a development team deploy an application to AWS. The AWS CloudFormation template includes an Amazon Linux EC2 instance, an Amazon Aurora DB cluster, and a hardcoded database password that...

A company's VPC has connectivity to an on-premises data center through an AWS Site-to-Site VPN. The company needs Amazon EC2 instances in the VPC to send DNS queries for example.com to th...

A SysOps administrator is tasked with analyzing database performance. The database runs on a single Amazon RDS DB instance. The SysOps administrator finds that, during times of peak traffic, resources on the database are overutilized due to the amount of...

A company is migrating its production file server to AWS. All data that is stored on the file server must remain accessible if an Availability Zone becomes unavailable or when system maintenance is performed. Users must be able to interact with the file server through the SMB protocol. User...

A company recently moved its server infrastructure to Amazon EC2 instances. The company wants to use Amazon CloudWatch metrics to track instance memory utilization and available di...

A company recently deployed MySQL on an Amazon EC2 instance with a default boot volume. The company intends to restore a 1.75 TB database. A SysOps administrator needs to provision the correct Amazon Elastic Block Store (Amazon EBS) volume. The database will require read performance of up t...

A SysOps administrator is setting up a fleet of Amazon EC2 instances in an Auto Scaling group for an application. The fleet should have 50% CPU available at all times to accommodate bursts of traffic. The load will increase significantly between the hours of 09:00 and 17:00, 7 da...

A company has turned on server access logging for all of its existing Amazon S3 buckets. The company wants to implement a solution to monitor the logging settings for new and existing S3 buckets. The solution must remediate any S3 buckets that do not have logging turn...

A company manages a set of accounts on AWS by using AWS Organizations. The company's security team wants to use a native AWS service to regularly scan all AWS accounts against the Center for Internet Security (CIS) AWS Fo...

A SysOps administrator needs to collect the content of log files from a custom application that is deployed across hundreds of Amazon EC2 instances running Ubuntu. The log files need to be stored in Amazon CloudWatch Logs. How sho...

A company has an application that uses an Amazon Elastic File System (Amazon EFS) file system. A recent incident that involved an application logic error corrupted several files. The company wants to improve its ability to back up and recover the EFS file system. The compa...

A company needs to view a list of security groups that are open to the internet on port 3389. What should a S...