Amazon Practice Questions, Discussions & Exam Topics by our Authors

A company is building a serverless application that uses AWS Lambda functions to process data. A BeginResponse Lambda function initializes data in response to specific application events. The company needs to ensure that a large number of Lambda functions are invoked after the BeginResponse Lambda function runs. Each Lambda function must be invoked in parallel and depends on only the outputs of the BeginResponse Lambda function. Each Lam...

Let's analyze the available solutions for invoking multiple Lambda functions in parallel after the BeginResponse Lambda function runs, with a focus on operational efficiency and data integrity: Option A: Create an Amazon Simple Notification Service (Amazon SNS) topic. Modify the BeginResponse Lambda function to publish to the SNS topic before the BeginResponse Lambda function finishes running. Subscribe all Lambda functions that need to invoke after the BeginResponse Lambda function runs to the SNS topic. Subscribe any new Lambda functions to the SNS topic. - Analysis: Using an SNS topic to trigger the Lambda functions is an efficient way to broadcast the same event to multiple subscribers (in this case, Lambda functions). SNS supports parallel invocations, retries, and handles failure scenarios well. The BeginResponse function can publish to the SNS topic before it finishes, allowing other Lambda functions to start immediately after the event is published. Additionally, new Lambda functions can be easily subscribed to the SNS topic. - Why Selected: This option is operationally simple and leverages SNS's native capabilities for parallel execution and automatic retries. It also allows fine-tuning of concurrency on a per-Lambda basis, meeting the requirement for scaling without data loss. There is no need for complex setup, and it supports easy management of new Lambda functions. Option B: Create an Amazon Simple Queue Service (Amazon SQS) queue for each Lambda function that needs to run after the BeginResponse Lambda function runs. Subscribe each Lambda function to its own SQS queue. Create an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe each SQS queue to the SNS topic. Modify the BeginResponse function to publish to the SNS topic when it finishes running. - Analysis: This solution adds an extra layer of complexity by using an SQS queue for each Lambda function. The BeginResponse function would publish to an SNS topic, and each Lambda function would then pull messages from an SQS queue. While SQS is reliable and ensures messages are not lost, the added SQS queues for each Lambda function introduce additional management overhead. This setup also leads to potential delays since Lambda functions would need to poll the SQS queues to process the messages. - Why Rejected: While reliable, this approach introduces unnecessary complexity and operational overhead compared to SNS. Managing multiple SQS queues adds extra maintenance and monitoring, making this option less efficient for the required use case, especially when compared to the simplicity of direct SNS invocations. Option C: Create an A...

Author: David · Last updated Jul 20, 2026

A company operates a globally deployed product out of multiple AWS Regions. The company's DevOps team needs to use Amazon API Gateway to deploy an API to support the product. The API must be deployed redundantly. The deployment must provide independent availability from each company location. The deployment also mu...

Explanation of Each Option: A) Deploy an API Gateway edge-optimized API endpoint in the us-east-1 Region. Create an API Gateway custom domain for the API. Create an Amazon Route 53 record set with a geoproximity routing policy for the API's custom domain. Increase the geographic bias to the maximum allowed value. - Analysis: - Edge-optimized API endpoints are designed to provide low-latency access by routing traffic through AWS CloudFront globally. This can help optimize performance for users worldwide. - Geoproximity routing in Route 53 is effective for directing traffic to the region that is closest to the user. However, this does not provide redundancy across multiple regions or independent availability in each location, which is required for redundancy. - Why Rejected: While this provides performance optimization, it does not meet the need for redundancy and independent availability across regions. The routing policy is not focused on independent regional deployments. B) Deploy an API Gateway regional API endpoint in the us-east-1 Region. Integrate the API Gateway API with a public Application Load Balancer (ALB). Create an AWS Global Accelerator standard accelerator. Associate the endpoint with the ALB. Create an Amazon Route 53 alias record set that points the custom domain name to the DNS name that is assigned to the accelerator. - Analysis: - Regional API Gateway endpoints are designed for single-region deployments, but they do not support the global performance optimization required for a product with a global user base. - Global Accelerator provides global routing and low-latency access, but it is designed for improving the performance of regional resources (e.g., load balancers), not APIs. This integration introduces unnecessary complexity and does not fully meet the requirement of independent availability in each region. - Why Rejected: This solution doesn’t provide independent region-specific deployment of the API, and adding ALB with Global Accelerator complicates the setup. It doesn’t meet the redundancy and performance optimization goals. C) Deploy an API Gateway regional API endpoint in every AWS Region where the company'...

Author: Lucas · Last updated Jul 20, 2026

A DevOps engineer uses AWS CodeBuild to frequently produce software packages. The CodeBuild project builds large Docker images that the DevOps engineer can use across multiple builds. The DevOps engineer wants to ...

Let's analyze each option to determine the best solution for improving build performance and minimizing costs: Option A: Store the Docker images in an Amazon Elastic Container Registry (Amazon ECR) repository. Implement a local Docker layer cache for CodeBuild. - Why it’s selected: This solution will optimize the use of Docker layer caching. By storing the Docker images in Amazon ECR, CodeBuild can reuse these images for subsequent builds, leading to faster build times and reduced costs. Implementing a local Docker layer cache within CodeBuild allows for even more reuse of the images and layers, decreasing the need to rebuild the entire image from scratch. This solution is cost-effective because it reduces the overall build time by reusing layers. - Why others are rejected: - Option B: While storing images in Amazon S3 might be considered, it would not be optimal for Docker images as it lacks tight integration with Docker caching mechanisms. Amazon ECR, on the other hand, is specifically designed to store and manage container images efficiently. - Option C: Always using the most recent image version may result in frequent rebuilds, preventing reuse of layers. This increases build time and cost. - Option D: Using custom AMIs adds complexity and might not be as efficient or cost-effective as using ECR with layer caching. Additionally, creating and maintaining custom AMIs is overhead and not directly related to optimizing Docker builds. Option B: Cache the Docker images in an Amazon S3 bucket that is available across multiple build hosts. Expire the cache by using an S3 Lifecycle policy. - Why it’s rejected: While S3 is inexpensive for storage, it’s not optim...

Author: Henry · Last updated Jul 20, 2026

A large company recently acquired a small company. The large company invited the small company to join the large company's existing organization in AWS Organizations as a new OU. A DevOps engineer determines that the small company needs to launch t3.small Amazon EC2 instance types for the company's application workloads. The small company needs to deploy the instances only within US-based AWS Regions. The DevOps en...

To address the given requirements — ensuring the small company can only launch `t3.small` EC2 instances in US-based regions — let’s break down and evaluate each option: Option A: Configure a statement to deny the `ec2:RunInstances` action for all EC2 instance resources when the `ec2:InstanceType` condition is not equal to `t3.small`. Configure another statement to deny the `ec2:RunInstances` action for all EC2 instance resources when the `aws:RequestedRegion` condition is not equal to `us-`. - Why it’s selected: This option uses `deny` statements effectively to block any actions outside of the specific criteria, ensuring that: - Only `t3.small` instances can be launched by denying any request that does not meet the condition (`ec2:InstanceType != t3.small`). - The instances can only be launched in US-based regions by denying any request for regions not matching `us-` (the `aws:RequestedRegion` condition). - Why other options are rejected: - Option B: This option uses `allow` statements instead of `deny`....

Author: Kai99 · Last updated Jul 20, 2026

A DevOps team manages infrastructure for an application. The application uses long-running processes to process items from an Amazon Simple Queue Service (Amazon SQS) queue. The application is deployed to an Auto Scaling group. The application recently experienced an issue where items were taking significantly longer to process. The queue exceeded the expected size, which prevented various business processes from functioning properly. The application records all logs to a third-party tool. The team is currently subscribed to an Amaz...

Let's evaluate the options based on the requirement to efficiently alert the team when the SQS queue exceeds the expected size, ensuring minimal operational overhead and ensuring the right monitoring and alerting mechanism: Option A: Create an Amazon CloudWatch metric alarm with a period of 1 hour and a static threshold to alarm if the average of the ApproximateNumberOfMessagesDelayed metric is greater than the expected value. Configure the alarm to notify the SNS topic. - Why it’s rejected: The ApproximateNumberOfMessagesDelayed metric represents the number of messages in the queue that are delayed, which might not directly correlate with the queue size problem that the team is facing. While it’s useful for specific cases where delayed messages are important, it doesn’t capture the overall size of the queue (visible messages). Thus, it may not alert the team if the overall queue size exceeds expectations. Option B: Create an Amazon CloudWatch metric alarm with a period of 1 hour and a static threshold to alarm if the sum of the ApproximateNumberOfMessagesVisible metric is greater than the expected value. Configure the alarm to notify the SNS topic. - Why it’s selected: The ApproximateNumberOfMessagesVisible metric gives the current number of visible messages in the queue, which d...

Author: Amira99 · Last updated Jul 20, 2026

A large company runs critical workloads in multiple AWS accounts. The AWS accounts are managed under AWS Organizations with all features enabled. The company stores confidential customer data in an Amazon S3 bucket. Access to the S3 bucket requires multiple levels of approval. The company wants to monitor when the S3 bucket is accessed by using the AWS CLI. The company also wants insigh...

Let's evaluate each option based on the requirements: Requirements: 1. Monitor access to a specific S3 bucket (with approval levels). 2. Monitor activities on all other S3 buckets. 3. Centralized monitoring using AWS CLI. 4. Use anomaly detection for insights into activities. --- Option A: Create an AWS CloudTrail trail that is delivered to Amazon CloudWatch in each AWS account. Enable data events logs for all S3 buckets. Use Amazon GuardDuty for anomaly detection in all the AWS accounts. Use Amazon Athena to perform SQL queries on the custom metrics created from the CloudTrail logs. - Why it's rejected: - The requirement mentions using the AWS CLI for monitoring, but this solution involves using GuardDuty for anomaly detection. While GuardDuty is great for threat detection, it is not ideal for detailed insights or querying logs using AWS CLI. - Also, Athena requires more manual setup and doesn’t directly integrate with CloudWatch metrics, making it less efficient compared to other solutions. Option B: Create an AWS CloudTrail organization trail that is delivered to Amazon CloudWatch in the Organizations management account. Enable data events logs for all S3 buckets. Use Amazon CloudWatch anomaly detection in all the AWS accounts. Use Amazon Athena to perform SQL queries on the custom metrics created from the CloudTrail logs. - Why it’s selected: - This solution leverages CloudTrail organization trails, which makes centralized log collection easier across all AWS accounts within the organization. - CloudWatch anomaly detection can be used across all accounts for anomaly insights, providing the necessary monitoring. - Athena is used for querying logs, but since this solution integrates better with CloudWatch and enables centralized monitoring via the organization trail, it’s a strong solution. - This solution provides centralized and automated monitoring of S3 bucket access and activities, fulfill...

Author: Amelia · Last updated Jul 20, 2026

A DevOps team is deploying microservices for an application on an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. The cluster uses managed node groups. The DevOps team wants to enable auto scaling for the microservice Pods based on a specific CPU utilization percentage. The DevOps team has already installe...

Let's evaluate each option based on the requirements: Requirements: - The team wants to enable auto-scaling for microservice Pods based on CPU utilization. - The Kubernetes Metrics Server is already installed, so the necessary metrics for auto-scaling are available. - The solution must be operationally efficient. Option A: Edit the Auto Scaling group that is associated with the worker nodes of the EKS cluster. Configure the Auto Scaling group to use a target tracking scaling policy to scale when the average CPU utilization of the Auto Scaling group reaches a specific percentage. - Why it's rejected: - This solution applies to scaling the EKS worker nodes (EC2 instances) rather than the microservices Pods. While it does scale the infrastructure (EC2 instances) when CPU utilization is high, it doesn't address the Pod-level auto-scaling based on CPU utilization, which is specifically requested in the scenario. - This approach is more suited for scaling the EC2 instances themselves, not the application Pods within the EKS cluster. Option B: Deploy the Kubernetes Horizontal Pod Autoscaler (HPA) and the Kubernetes Vertical Pod Autoscaler (VPA) in the cluster. Configure the HPA to scale based on the target CPU utilization percentage. Configure the VPA to use the recommender mode setting. - Why it's rejected: - HPA (Horizontal Pod Autoscaler) is the correct tool for scaling Pods based on metrics such as CPU utilization. However, VPA (Vertical Pod Autoscaler) is typically used for adjusting the resource requests and limits of the Pods themselves, not for scaling the number of Pods. - The combination of HPA and VPA is not necessary for the requested goal, which is to scale Pods based on CPU utilization. The VPA may lead to resource adjustments that are not needed in this case and adds unnecessary complexity. Option C: Run the...

Author: Ryan · Last updated Jul 20, 2026

A company has multiple AWS accounts. The company uses AWS IAM Identity Center that is integrated with a third-party SAML 2.0 identity provider (IdP). The attributes for access control feature is enabled in IAM Identity Center. The attribute mapping list maps the department key from the IdP to the ${path:enterprise.department} attribute. All existing Amazon EC2 instances have a d1, d2, d3 department tag that corresponds to three company's departments. A DevOps engineer must create policies based on the matching attributes. The policies...

To meet the requirement of granting users access to only EC2 instances that are tagged with their respective department names, the DevOps engineer should use the `aws:RequestTag/department` condition key in the custom permission policies. This allows the policies to enforce access based on the department tag that is dynamically matched to the user's respective department. Explanation of the condition key: - aws:RequestTag/department: This condition key uses the tag value associated with a resource (in this case, the EC2 instance) to allow or deny access based on the department tag. This will check the department tag on the EC2 instances and compare it to the user's department as mapped in the IAM Identity Center. If the department tag on the EC2 instance matches the user's department, access will be granted. - Why this is selected: This key directly addresses the need to restrict EC2 instance access based on the user's department tag. It is particularly useful because the EC2 instances are tagged by department, and this condition key will ensure that only instances tagged with the user's department will be accessible to them. Rejected Options: - aws:PrincipalTag/department: This condition key would check the department tag on the IAM user or role rather than the EC2 instances. Since the goal is to restrict access based on the tags of the EC2 i...

Author: Noah Williams · Last updated Jul 20, 2026

A security team wants to use AWS CloudTrail to monitor all actions and API calls in multiple accounts that are in the same organization in AWS Organizations. The security team needs to ensure that account users...

To meet the requirement of preventing account users from turning off CloudTrail in the accounts while monitoring actions and API calls across multiple accounts in an AWS Organization, the best solution is Option A: Apply an SCP (Service Control Policy) to all OUs (Organizational Units) to deny the `cloudtrail:StopLogging` action and the `cloudtrail:DeleteTrail` action. Explanation of the selected option (Option A): - Service Control Policies (SCPs): SCPs are a feature of AWS Organizations that allow you to control the maximum available permissions for accounts in an organization. By applying an SCP to deny `cloudtrail:StopLogging` and `cloudtrail:DeleteTrail`, the security team ensures that no user in the accounts can disable or delete CloudTrail. SCPs are the most effective way to enforce governance across multiple accounts within an AWS Organization. - Why this is selected: SCPs are applied at the organizational level and can centrally enforce security policies that affect all accounts within specific OUs. This approach is scalable and ensures that CloudTrail cannot be turned off by users in any account within the organization. Rejected options: - Option B: Create IAM policies in each account to deny the `cloudtrail:StopLogging` action and the `cloudtrail:DeleteTrail` action. - Why rejected: While IAM policies can be used to deny individual actions, they are not suitable for centrally enforcing policies across multiple accounts in an organization. You would have to apply and manage IAM policies in each account individually, which can lead to configuration drift...

Author: Ella · Last updated Jul 20, 2026

A DevOps engineer needs to configure a blue/green deployment for an existing three-tier application. The application runs on Amazon EC2 instances and uses an Amazon RDS database. The EC2 instances run behind an Application Load Balancer (ALB) and are in an Auto Scaling group. The DevOps engineer has created launch templates, Auto Scaling groups, and ALB target groups for the blue environment and the green environment. Each target group specifies which application version, blue or green, will be loaded on the EC2 ...

The correct solution is Option B: Use an AWS CLI command to update the ALB to send traffic to the green environment’s target group. Start a rolling restart of the Auto Scaling group for the green environment to deploy the new application version to the green environment’s EC2 instances. Explanation of the selected option (Option B): 1. Update ALB to switch traffic to the green environment’s target group: The blue/green deployment is focused on switching traffic between the two environments. Updating the Application Load Balancer (ALB) to direct traffic to the green environment's target group achieves this by shifting all traffic at once from the blue environment to the green environment. 2. Rolling restart of the green environment: Starting a rolling restart of the green environment's EC2 instances is part of ensuring that the green environment's EC2 instances are updated with the new application version, while maintaining traffic flow without downtime. 3. Why this is the best solution: - This option ensures the traffic is switched all at once to the green environment using the ALB, which is the requirement of a blue/green deployment. The rolling restart ensures that the green environment’s instances are updated with the new version without impacting the availability of the application. - It fully satisfies the requirement to shift traffic in a single step and ensures that the green environment is correctly updated before traffic is shifted. Rejected options: - Option A: Start a rolling restart of the Auto Scaling group for the green environment to deploy the new application version to the green environment's EC2 instances. When the rolling restart is complete, use an AWS CLI command to update the ALB to send traffic to the green environment's target group. - Why rejected: While this solution works, it is less efficient. It performs the rolling restart of the green environment's EC2 instances before updating the ALB. This means the new application version would be deployed on the green environment before t...

Author: Charlotte · Last updated Jul 20, 2026

A company has an application that runs on Amazon EC2 instances in an Auto Scaling group. The application processes a high volume of messages from an Amazon Simple Queue Service (Amazon SQS) queue. A DevOps engineer noticed that the application took several hours to process a group of messages from the SQS queue. The average CPU utilization of the Auto Scaling group did not cross the threshold of a target tracking scaling policy when processing the messages. The application that processes the S...

The best solution with the least operational overhead is Option C: Create a target tracking scaling policy for the Auto Scaling group. In the target tracking policy, use the `ApproximateNumberOfMessagesVisible` SQS queue attribute and the `GroupInServiceInstances` Auto Scaling group attribute to calculate how many messages are in the queue for each number of instances by using metric math. Use the calculated attribute to scale in and out. Explanation of the selected option (Option C): - Target Tracking Scaling Policy: The target tracking scaling policy adjusts the number of EC2 instances in the Auto Scaling group based on metrics. In this case, using the `ApproximateNumberOfMessagesVisible` attribute from SQS allows the scaling policy to respond directly to the number of messages in the queue. By combining this metric with the `GroupInServiceInstances` attribute (which represents the number of EC2 instances currently active), the scaling policy can calculate the load per instance and scale the group appropriately. This method is automatic and can scale in or out without requiring manual intervention. - Metric Math: By using metric math, you can calculate how many messages need to be processed per instance. This means the scaling policy can adjust based on the actual load (number of messages to process) rather than CPU utilization, which is not a direct indicator of message processing. - Minimal Operational Overhead: This solution requires minimal operational overhead because it leverages existing SQS metrics and Auto Scaling features. Once set up, the scaling policy operates automatically without requiring manual configuration or external triggers. It is a fully managed solution that dynamically adjusts the Auto Scaling group to meet the needs of the application. Why the other options are rejected: - Option A: Create an AWS Lambda function to publi...

Author: William · Last updated Jul 20, 2026

A company has a single AWS account that runs hundreds of Amazon EC2 instances in a single AWS Region. The company launches and terminates new EC2 instances every hour. The account includes existing EC2 instances that have been running for longer than a week. The company's security policy requires all running EC2 instances to have an EC2 instance profile attached. The company has created a default EC2...

The best solution to meet the requirements is Option B: Configure AWS Config. Deploy an AWS Config `ec2-instance-profile-attached` managed rule. Configure an automatic remediation action that invokes an AWS Systems Manager Automation runbook to attach the default instance profile to the EC2 instances. Explanation of the selected option (Option B): - AWS Config Managed Rule: The `ec2-instance-profile-attached` rule checks whether EC2 instances have an instance profile attached. AWS Config provides a managed rule for this exact scenario, ensuring compliance with the security policy. This managed rule is designed to automatically assess whether each EC2 instance has an instance profile attached, which meets the requirement that all running EC2 instances must have a profile. - Automatic Remediation with AWS Systems Manager Automation: Once the AWS Config rule identifies an EC2 instance that does not have a profile attached, the automatic remediation action can trigger an AWS Systems Manager Automation runbook. This automation can attach the default EC2 instance profile to the affected instances. The combination of AWS Config and Systems Manager allows for a hands-off, automated solution, ensuring compliance with the security policy without manual intervention. - Why this option is ideal: - Low Operational Overhead: AWS Config continuously monitors and evaluates the compliance of resources. The automatic remediation process through Systems Manager ensures that non-compliant EC2 instances are corrected without requiring manual steps, thus meeting the security requirements with minimal effort. - Scalability: Since AWS Config continuously evaluates all EC2 instances and performs remediation on demand, it is highly scalable and will automatically manage compliance for all EC2 instances, even as new instances are launched or terminated frequently. Why the other options are rejected: - Option A: Configure an Amazon EventBridge rule that matches the Amazon EC2 `RunInstances` API calls. Configure the rule to invoke an AWS Lambda function to attach the default instance profile to ...

Author: Matthew · Last updated Jul 20, 2026

A company uses AWS Organizations to manage hundreds of AWS accounts. The company has a team that is responsible for AWS Identity and Access Management (IAM). The IAM team wants to implement AWS IAM Identity Center. The IAM team must have only the minimum required permissions to manage IAM Identity Center. The IAM team must not be able to gain unnecessary access to the Organizations management account. The IAM team must be ab...

To address the requirements, we need to allow the IAM team to manage AWS IAM Identity Center without giving them excessive permissions or access to the Organizations management account. Let's go through each option and evaluate its relevance: Option A: Create a new AWS account for the IAM team. Enable IAM Identity Center in the new account. In the Organizations management account, register the new account as a delegated administrator for IAM Identity Center. - Explanation: Creating a new account for the IAM team ensures that the team works in isolation, managing IAM Identity Center without direct access to the management account. Registering this account as a delegated administrator for IAM Identity Center grants the necessary permissions for managing the service. - Why it's selected: This option ensures minimal access to the management account while enabling the IAM team to manage IAM Identity Center. The IAM team gets only the required permissions and no excess access to the Organizations management account. --- Option B: Create a new AWS account for the IAM team. Enable IAM Identity Center in the Organizations management account. In the Organizations management account, register the new account as a delegated administrator for IAM Identity Center. - Explanation: While creating a new AWS account and assigning it as a delegated administrator is appropriate, enabling IAM Identity Center in the Organizations management account might be problematic because it could lead to unnecessary permissions for the IAM team in the management account. - Why it’s rejected: This option involves enabling IAM Identity Center in the management account, which contradicts the requirement of ensuring that the IAM team cannot gain access to the management account. The management account should remain tightly controlled. --- Option C: Create an SCP in Organizations. Create a new OU for the Organizations management account, and link the new SCP to the OU. Configure the SCP to deny all access to IAM Identity Center. - Explanation: This option suggests applying a Service Control Policy (SCP) to deny access to IAM Identity Center for the management account, but that would restrict access for the IAM team as well. The IAM team still needs the ability to manage IAM Identity Center, so applying a blanket deny policy would interfere with th...

Author: ShadowWolf101 · Last updated Jul 20, 2026

A company uses an Amazon Aurora PostgreSQL global database that has two secondary AWS Regions. A DevOps engineer has configured the database parameter group to guarantee an RPO of 60 seconds. Write operations on the primary cluster are occasionally blocked because of the RPO setting. T...

Let's evaluate the options one by one and determine the most suitable solution to reduce the frequency of blocked write operations due to the RPO setting. Option A: Add an additional secondary cluster to the global database. - Explanation: Adding another secondary cluster can increase the capacity for handling read traffic and can potentially improve replication speed. However, this does not directly address the problem of blocked write operations due to the RPO (Recovery Point Objective) setting. - Why it’s rejected: While adding another secondary cluster could improve read scalability, it does not reduce the occurrence of blocked write operations because the issue stems from replication lag or the time it takes to keep the secondary clusters synchronized. The addition of more secondaries doesn’t alleviate the blockage of writes caused by replication lag. --- Option B: Enable write forwarding for the global database. - Explanation: Write forwarding allows the writes made on a secondary region to be forwarded to the primary region for eventual consistency. This can help in cases where the replication lag causes writes to be blocked on the primary cluster, as the writes can be completed on a secondary region and then forwarded to the primary region. - Why it’s selected: This option directly addresses the problem of write operations being blocked due to replication lag. Enabling write forwarding allows writes to continue even when the RPO cannot be met within 60 seconds on the primary region. By allowing the writes to be forwarded to the primary from a secondary cluster, you reduce the likelihood of write...

Author: Noah · Last updated Jul 20, 2026

A company has a web application that is hosted on an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. The EKS cluster runs on AWS Fargate that is available through an internet-facing Application Load Balancer. The application is experiencing stability issues that lead to longer response times. A DevOps engineer needs to configure observability in Amazon CloudWatch to t...

Let's go through each option to determine which are the best choices to configure observability in Amazon CloudWatch with the least permissions necessary: Option A: Deploy the CloudWatch agent as a Kubernetes StatefulSet to the EKS cluster. - Explanation: The CloudWatch agent collects metrics and logs from your Kubernetes pods and sends them to Amazon CloudWatch. Using a StatefulSet for deployment isn't the most suitable method for deploying this agent. A DaemonSet is typically the better choice for deploying agents on every node of the cluster, including Fargate nodes. - Why it’s rejected: A StatefulSet is not the appropriate resource to deploy the CloudWatch agent, especially because it is designed for applications that require stable, unique network identities and persistent storage. A DaemonSet is the correct method to ensure that the CloudWatch agent runs on each node in the cluster. --- Option B: Deploy the AWS Distro for OpenTelemetry Collector as a Kubernetes DaemonSet to the EKS cluster. - Explanation: The AWS Distro for OpenTelemetry Collector (ADOT) is a great tool for collecting and sending telemetry data, including metrics, logs, and traces, to CloudWatch. Deploying it as a DaemonSet ensures that the agent runs on all nodes in the cluster, including on AWS Fargate. - Why it’s selected: This is an optimal approach because the OpenTelemetry Collector can gather telemetry data from the EKS cluster efficiently and forward it to CloudWatch. It also supports observability at scale with the least permissions. --- Option C: Associate a Kubernetes service account with an IAM role by using IAM roles for service accounts in Amazon EKS. Use the CloudWatchAgentServerPolicy AWS managed policy. - Explanation: IAM roles for service accounts (IRSA) in EKS allow Kubernetes workloads to securely access AWS services like CloudWatch. The CloudWatchAgentServerPolicy is a managed policy that grants the necessary permissions for CloudWatch agent to send logs and metrics to CloudWatch. - Why it’s selected: Associating a Kubernetes service account with an IAM role is the correct and secure way to grant permissions. The CloudWatchAgentSe...

Author: Maya · Last updated Jul 20, 2026

A company stores its Python-based application code in AWS CodeCommit. The company uses AWS CodePipeline to deploy the application. The CodeCommit repository and the CodePipeline pipeline are deployed to the same AWS account. The company's security team requires all code to be scanned for vulnerabilities before the c...

Let's evaluate each option to determine the best solution that meets the requirement of scanning for vulnerabilities before deploying the code to production and stopping the deployment if any vulnerabilities are found. Option A: Create a new CodeBuild project. Configure the project to run a security scan on the code by using Amazon CodeGuru Security. Configure the CodeBuild project to raise an error if CodeGuru Security finds vulnerabilities. Create a new IAM role that has sufficient permissions to run CodeGuru Security scans. Assign the role to the CodeBuild project. In the CodePipeline pipeline, add a new stage before the deployment stage. Select AWS CodeBuild as the action provider for the new stage. Use the source artifact from the CodeCommit repository. Configure the action to use the CodeBuild project. - Explanation: This option proposes using Amazon CodeGuru Security to scan for vulnerabilities in the code. CodeGuru Security is a service designed to identify security issues in code. By configuring a new CodeBuild project and adding it to the pipeline before the deployment stage, the scan will run during the build process. If vulnerabilities are found, the CodeBuild project can raise an error, which will stop the pipeline and prevent deployment to production. - Why it's selected: This option directly meets the requirements of scanning the code for vulnerabilities before deployment and stopping the deployment if any vulnerabilities are found. CodeGuru is well-suited for identifying security vulnerabilities in Python code, and integrating it into the pipeline through CodeBuild ensures that the process is automated. --- Option B: Create a new CodeBuild project. Configure the project to run a security scan on the code by using Amazon Inspector. Configure the CodeBuild project to raise an error if Amazon Inspector finds vulnerabilities. Create a new IAM role that has sufficient permissions to run Amazon Inspector scans. Assign the role to the CodeBuild project. In the CodePipeline pipeline, add a new stage before the deployment stage. Select AWS CodeBuild as the action provider for the new stage. Use the source artifact from the CodeCommit repository. Configure the action to use the CodeBuild project. - Explanation: Amazon Inspector is primarily fo...

Author: Olivia · Last updated Jul 20, 2026

A DevOps engineer deploys an application to a fleet of Amazon Linux EC2 instances. The DevOps engineer needs to monitor system metrics across the fleet. The DevOps engineer wants to monitor the relationship between network traffic and memory utilization for the application cod...

Let's evaluate each option to determine the best solution for monitoring the system metrics (network traffic and memory utilization) on Amazon Linux EC2 instances, ensuring that the metrics are tracked at a 60-second interval: Option A: Use Amazon CloudWatch basic monitoring to collect the NetworkIn metric and the MemoryBytesUsed metric. Graph the metrics in CloudWatch. - Explanation: Amazon EC2 basic monitoring provides default metrics, including `NetworkIn`, but does not include memory metrics like `MemoryBytesUsed` by default. For memory-related metrics, you would need to install the CloudWatch agent. - Why it’s rejected: This option misses the necessary memory metric (`MemoryBytesUsed`) since basic monitoring does not collect memory utilization metrics. Therefore, it cannot meet the requirement to monitor memory usage in conjunction with network traffic. --- Option B: Use Amazon CloudWatch detailed monitoring to collect the NetworkIn metric and the MemoryBytesUsed metric. Graph the metrics in CloudWatch. - Explanation: CloudWatch detailed monitoring provides more granular data, but it only includes default metrics like `NetworkIn`, and it does not include memory utilization metrics such as `MemoryBytesUsed`. Memory metrics require the CloudWatch agent to be installed on the EC2 instances. - Why it’s rejected: While detailed monitoring offers more frequent data collection (per minute), it does not collect memory utilization metrics by default. The CloudWatch agent would still be required to track memory metrics. --- Option C: Use Amazon CloudWatch detailed monitoring to collect the Networ...

Author: NebulaEagle11 · Last updated Jul 20, 2026

A company uses AWS Systems Manager to manage a fleet of Amazon Linux EC2 instances that have SSM Agent installed. All EC2 instances are configured to use Instance Metadata Service Version 2 (IMDSv2) and are running in the same AWS account and AWS Region. Company policy requires developers to use only Amazon Linux. The company wants to ensure that all new EC2...

Let's analyze each option to determine the most operationally efficient solution for ensuring that all new EC2 instances are automatically managed by AWS Systems Manager: Option A: Create an IAM role that allows Systems Manager to assume the role, attach the `AmazonSSMManagedEC2InstanceDefaultPolicy`, and configure the SSM service setting. - Analysis: This option involves creating an IAM role that permits Systems Manager to manage EC2 instances. The `AmazonSSMManagedEC2InstanceDefaultPolicy` policy ensures the instances can be managed by Systems Manager. However, the need to manually configure the SSM service setting and the IAM role might not be as efficient for automatic management of new EC2 instances across an organization. - Challenges: This method doesn't directly ensure that every new EC2 instance gets the appropriate role automatically. It could require additional management to ensure that every EC2 instance is assigned the role during its launch. - Use case: Suitable for scenarios where manual role management is acceptable, but it lacks automation for instance launches. Option B: Use AWS Config to validate if an EC2 instance has SSM Agent installed and remediate. - Analysis: AWS Config can be used to ensure that EC2 instances are compliant with the rule (i.e., SSM Agent is installed). If any non-compliant EC2 instances are detected, the rule triggers automatic remediation by running the `AWS-InstallSSMAgent` document to install the SSM Agent. While this provides remediation, it doesn’t guarantee that new EC2 instances will be initially managed by Systems Manager upon creation. - Challenges: This solution only ensures the installation of SSM Agent after the instance is created and potentially non-compliant. It's not the most efficient for immediate and consistent management from ...

Author: Isabella · Last updated Jul 20, 2026

A company configured an Amazon S3 event source for an AWS Lambda function. The company needs the Lambda function to run when a new object is created or an existing object is modified in a specific S3 bucket. The Lambda function will use the S3 bucket name and the S3 object key of the incoming event to read the contents of the new or modified S3 object. The Lambda function will parse the contents and save the parsed contents to an Amazon DynamoDB table. The Lambda function's execution role has permissions to read from the S3 bucket and to w...

Let's analyze each option to determine the best solution for resolving the issue where the Lambda function does not trigger when an object is added or modified in the S3 bucket: Option A: Create an S3 bucket policy for the S3 bucket that grants the S3 bucket permission to invoke the Lambda function. - Analysis: S3 bucket policies define permissions on objects within an S3 bucket. However, an S3 bucket policy alone cannot trigger a Lambda function. For a Lambda function to be invoked by an S3 event, it requires permission to be invoked by Amazon S3, which is handled through a resource policy on the Lambda function, not an S3 bucket policy. - Challenges: This option is incorrect because S3 bucket policies do not handle Lambda function invocations. - Use case: Not applicable for this scenario. Option B: Create a resource policy for the Lambda function to grant Amazon S3 permission to invoke the Lambda function on the S3 bucket. - Analysis: When you set up an S3 event notification to trigger a Lambda function, you must add a permission to the Lambda function's resource policy to allow Amazon S3 to invoke it. This ensures that the Lambda function can be triggered by S3 events, such as object creation or modification. If the resource policy is missing or incorrectly configured, the Lambda function will not be invoked. - Challenges: This solution directly addresses the problem by ensuring that the Lambda function has the necessary permissions to be invoked by S3. This is a critical step when setting up an event source mapping between S3 and Lambda. - Use case: This is the correct approach for ensuring that Lambda functions are invoked by S3 events. Option C: Configure an Amazon...

Author: Olivia Johnson · Last updated Jul 20, 2026

A company's web application uses an Application Load Balancer (ALB) to direct traffic to Amazon EC2 instances across three Availability Zones. The company has deployed a newer version of the application to one Availability Zone for testing. If a problem is detected with the application, the company wants to direct traffic away from the affected Availability Zone until the deployment has been rolled bac...

Let's analyze the options to determine which one meets the requirement of maintaining application availability while directing traffic away from an affected Availability Zone during a rollback, with the least operational overhead: Option A: Disable cross-zone load balancing on the ALB's target group. Initiate a zonal shift on the ALB to direct traffic away from the affected Availability Zone. - Analysis: Zonal shifting is a feature that allows the ALB to temporarily stop sending traffic to a specific Availability Zone, which is exactly what is required in this scenario. Disabling cross-zone load balancing is not necessary for the solution, but it might be beneficial in cases where you want to control traffic distribution on a per-zone basis. By initiating a zonal shift, you can ensure that traffic is directed away from the affected Availability Zone without impacting the other zones, maintaining high availability and stability during the rollback. - Why Selected: This solution is the most operationally efficient because it directly addresses the requirement to control traffic flow at the Availability Zone level with minimal manual intervention. The rollback process can continue without impacting the entire application, ensuring that static stability is maintained. Option B: Disable cross-zone load balancing on the ALB's target group. Manually remove instances in the target group that belong to the affected Availability Zone. - Analysis: This option involves manually removing instances from the target group, which can work, but it requires manual intervention and does not offer automatic recovery if the situation repeats. This method also introduces additional operational overhead, as you would need to update the target group configuration each time there's an issue in an Availability Zone. - Why Rejected: Manual intervention and the need to update the target group can be error-prone and increase operational overhead. It's not as efficient or scalable as using zonal shifting. Option C: Configure cross-zone load balancing on the ALB's target group to inherit settings from the ALB. Initiate a zonal shift on the ALB to direct tra...

Author: Ming88 · Last updated Jul 20, 2026

A company has several AWS accounts. An Amazon Connect instance runs in each account. The company uses an Amazon EventBridge default event bus in each account for event handling. A DevOps team needs to receive all the...

To address the problem of receiving all Amazon Connect events from multiple AWS accounts in a single DevOps account, let's go over the options one by one and evaluate the strengths and weaknesses based on the requirements. A) Update the resource-based policy of the default event bus in each account to allow the DevOps account to replay events. Configure an EventBridge rule in the DevOps account that matches Amazon Connect events and has a target of the default event bus in the other accounts. - Rejection Reason: The requirement is to receive events, not to replay them. The term "replay" here implies that events would be triggered again, which is unnecessary and could lead to confusion or redundancy. This approach would not fulfill the requirement of simply collecting real-time events. B) Update the resource-based policy of the default event bus in each account to allow the DevOps account to receive events. Configure an EventBridge rule in the DevOps account that matches Amazon Connect events and has a target of the default event bus in the other accounts. - Strength: This approach ensures that the DevOps account is able to receive Amazon Connect events from other accounts directly. - Key Factor: The resource-based policy allows the DevOps account to directly receive events. Configuring an EventBridge rule in the DevOps account ensures that it listens to the events from the other accounts, making this a valid solution. - Selected Option: This is the most appropriate approach because it allows events to flow into the DevOps account without any unnecessary complexity. It is designed to receive...

Author: Victoria · Last updated Jul 20, 2026

A company has deployed an Amazon Elastic Kubernetes Service (Amazon EKS) cluster with Amazon EC2 node groups. The company's DevOps team uses the Kubernetes Horizontal Pod Autoscaler and recently installed a supported EKS cluster Autoscaler. The DevOps team needs to implement a solution to collect metrics and logs of the EKS cluster to establish a baseline for performance. The DevOps team will create an initial set of thresholds for specific metrics and will update the thresholds over time as the cluster is used. The DevOps team must receive an Amazon Simple Notification Service (Amazon SNS) email notification if the initial set of thresholds is exceed...

Reasoning for Selection: A) Deploy the CloudWatch agent and Fluent Bit to the cluster. Ensure that the EKS cluster has appropriate permissions to send metrics and logs to CloudWatch. This option is ideal because deploying the CloudWatch agent allows you to collect node-level metrics (such as CPU, memory, disk, and network utilization) that are important for monitoring the health and performance of the EC2 instances in the node group. Fluent Bit is commonly used for log forwarding, helping to send application logs, including Kubernetes logs, to CloudWatch. Both agents work together to ensure that you capture both metrics and logs from the EKS cluster. Furthermore, CloudWatch enables easy visualization and alerting capabilities. This option satisfies the requirement for collecting cluster, node, and pod metrics and capturing logs in CloudWatch. B) Deploy AWS Distro for OpenTelemetry to the cluster. Ensure that the EKS cluster has appropriate permissions to send metrics and logs to CloudWatch. AWS Distro for OpenTelemetry is an open-source solution for monitoring and observing application behavior through metrics, traces, and logs. It can integrate well with CloudWatch, but it is more oriented towards distributed tracing and application performance monitoring rather than standard metrics (CPU, memory) and logs at the node and pod level. While OpenTelemetry is a great choice for advanced observability, in this context, CloudWatch agent and Fluent Bit provide a more direct and specialized solution for capturing metrics and logs for the EKS cluster. Hence, this option is not the most straightforward for the specific requirements. C) Create CloudWatch alarms to monitor the CPU, memory, and node failure metrics of the cluster. Configure the alarms to send an SNS email notification to the DevOps team if thresholds are exceeded. This option is essential because it addresses the requirement to monitor the cluster’s CPU, memory, and node metrics, and it also configures SNS notifications for when the thresholds are exceeded. The alarms allow the DevOps team to monitor the health and performance of the cluster and automatically get notified if the cluster’s resources are under pressure. This meets the need for threshold-based notifications and gives the team actionable alerts. D) Create a CloudWatch composite alarm to monito...

Author: SolarFalcon11 · Last updated Jul 20, 2026

A company discovers that its production environment and disaster recovery (DR) environment are deployed to the same AWS Region. All the production applications run on Amazon EC2 instances and are deployed by AWS CloudFormation. The applications use an Amazon FSx for NetApp ONTAP volume for application storage. No application data resides on the EC2 instances. A DevOps engineer copies the required AMIs to a new DR Region. The DevOps eng...

Let's break down the available options to determine which solution meets the requirements of having a 10-minute RPO for disaster recovery while maintaining application storage in the DR Region with minimal operational complexity. Option A: Create an Amazon S3 bucket in both Regions. Configure S3 Cross-Region Replication (CRR) for the S3 buckets. Create a scheduled AWS Lambda function to copy any new content from the FSx for ONTAP volume to the S3 bucket in the production Region. - Analysis: Amazon S3 Cross-Region Replication (CRR) is typically used to replicate objects between S3 buckets, not to replicate FSx for ONTAP volumes. FSx is a managed file system, not an object store, so the replication method here isn't directly applicable to FSx. Additionally, creating a Lambda function to copy data from FSx to S3 would introduce unnecessary complexity and does not directly address the requirement for a low-latency, volume-level replication strategy. - Why Rejected: This solution is not applicable for replicating FSx for ONTAP volumes. FSx volumes cannot be directly replicated to S3, and using Lambda introduces extra overhead without directly meeting the RPO requirement. Option B: Use AWS Backup to create a backup vault and a custom backup plan that has a 10-minute frequency. Specify the DR Region as the target Region. Assign the EC2 instances in the production Region to the backup plan. - Analysis: AWS Backup is a great service for creating backups of resources like EC2 instances, but it is not designed to provide near real-time replication with the required RPO for application storage like FSx for ONTAP. Backup solutions typically have longer intervals between backups (usually hours or more) and may not meet the 10-minute RPO required for the DR setup. - Why Rejected: While AWS Backup is useful for disaster recovery, it does not provide real-time replication and cannot meet the required 10-minute RPO, making it less ideal for this use case. Option C: Create an AWS Lambda function to create snapshots of the instance store volumes that are attached to the EC2 instances. Configure the Lambda function to copy ...

Author: ShadowWolf101 · Last updated Jul 20, 2026

During a security audit, a company discovered that some security groups allow SSH traffic from 0.0.0.0/0. A security team must implement a solution to detect and remediate this issue as soon as possible. The company uses one organization in AW...

Reasoning for Selection: A) Enable AWS Config for all AWS accounts. Use a periodic trigger to activate the vpe-sg-port-restriction-check AWS Config rule. Create an AWS Lambda function to remediate any noncompliant rules. - AWS Config is a powerful service to track and audit configuration changes across AWS resources. Enabling it for all accounts ensures that security groups are continuously monitored. - The vpe-sg-port-restriction-check rule is a built-in AWS Config rule that can check for open ports on security groups, specifically for things like SSH (port 22). - Combining this with an AWS Lambda function to remediate noncompliant security groups (by automatically removing SSH access from 0.0.0.0/0) is a proactive and automated approach to remediation. The periodic trigger ensures ongoing monitoring and remediation. This solution fits the requirement well because it: - Continuously monitors security group configurations in all AWS accounts. - Takes corrective action as soon as noncompliant rules are detected, ensuring prompt remediation. B) Create an AWS Lambda function in each AWS account to delete all the security group rules. Create an Amazon EventBridge rule to match security group update events or creation events. Set the Lambda function in each account as a target for the rule. - This solution is overly aggressive because deleting all security group rules would disrupt valid configurations and access. The company likely has many other security group rules necessary for proper network access (for example, HTTP, HTTPS, RDP, etc.). - This approach does not distinguish between valid and invalid configurations, leading to potential disruptions, which is a significant risk. C)...

Author: CrystalWolfX · Last updated Jul 20, 2026

A company's DevOps engineer must install a software package on 30 on-premises VMs and 15 Amazon EC2 instances. The DevOps engineer needs to ensure that all VMs receive the package in a process that is auditable and that any configuration drift on the VMs is automatically identified and alerted on. The company uses AWS Direc...

Reasoning for Selection: A) Write a script that iterates through the list of VMs once a week. Configure the script to check for the package and install the package if the package is not found. Configure the script to send an email message notification to the system administrator if the package is not found. - This approach involves creating a custom script to check each VM and install the package weekly. Although it provides some level of automation, it is manual and error-prone. It requires regular updates to the script and is not scalable. - The process of checking every VM each week is not efficient for detecting drift or ensuring that the package is consistently maintained across the infrastructure. - Auditing and monitoring are not fully automated, and the process lacks integration with cloud-native tools for operational efficiency. B) Install the AWS Systems Manager Agent (SSM Agent) on all VMs. Use the SSM Agent to install the package. Use AWS Config to monitor for configuration drift. Use Amazon Simple Notification Service (Amazon SNS) to notify the system administrator if any drift is found. - AWS Systems Manager (SSM) is a cloud-native service that enables automation across both EC2 instances and on-premises VMs, especially when the SSM Agent is installed. This solution provides the most operational efficiency because: - SSM allows remote execution of tasks (like installing software packages) on both EC2 and on-premises VMs, eliminating the need for manual interaction with the systems. - AWS Config integrates well to monitor for configuration drift, tracking changes in the configuration state of resources and ensuring that deviations are detected and alerted. - Amazon SNS can trigger notifications automatically, ensuring the system administrator is alerted when any drift is detected, enabling quick action to rectify any discrepancies. - The solution is auditable, automated, and scalable, as it works across both on-premises VMs and EC2 instances, ensuring consiste...

Author: Liam · Last updated Jul 20, 2026

A company has an AWS CodePipeline pipeline in the eu-west-1 Region. The pipeline stores the build artifacts in an Amazon S3 bucket. The pipeline builds and deploys an AWS Lambda function by using an AWS CloudFormation deploy action. A DevOps engineer needs to update the existing pipeline to also deploy the Lambda function to the us-east-1 Region. The pipeline has already been upd...

Reasoning for Selection: A) Modify the CloudFormation template to include a parameter for the Lambda function code's .zip file location. Create a new CloudFormation deploy action for us-east-1 in the pipeline. Configure the new deploy action to pass in the us-east-1 artifact location as a parameter override. - Option A is a valid approach to deploy the Lambda function in the us-east-1 region using the same CloudFormation template. By including a parameter in the template for the Lambda code's `.zip` file location, you can pass in the artifact location from the new artifact created for us-east-1. This allows the Lambda function to be deployed in us-east-1 with the appropriate function code. - This approach utilizes parameter overrides to deploy the same template across different regions without having to modify the template significantly, making it a flexible and scalable solution. B) Create a new CloudFormation deploy action for us-east-1 in the pipeline. Configure the new deploy action to use the CloudFormation template from the additional artifact that was created for us-east-1. - Option B is another valid approach. This option suggests creating a new CloudFormation deploy action specifically for us-east-1, and configuring it to use the CloudFormation template from the us-east-1 artifact created earlier. - If the artifact in us-east-1 contains the updated CloudFormation template or is region-specific (i.e., referencing resources in the us-east-1 region), this would allow the deployment to occur in us-east-1. - However, this method might not scale well if the Lambda deployment code is shared between regions because it suggests modifying the artifact or template for the region-specific deploy action. This could be a less flexible approach compared to passing parameters. C) Create an S3 bucket in us-east-1. Configure the S3 bucket policy to allow CodePipeline to have read and write access. - This option involves creating an S3 bucket in us-east-1 and modifying its policy to grant CodePipeline access. While this is necessary for storing artifacts, it does not directly address how to deploy the Lambda function in us-east-1. - The S3 bucket ...

Author: IceDragon2023 · Last updated Jul 20, 2026

A company uses an AWS Cloud Development Kit (AWS CDK) application for its infrastructure. The AWS CDK application creates AWS Lambda functions and the IAM roles that are attached to the functions. The company also uses AWS Organizations. The company's developers can assume the AWS CDK application deployment role. The company's security team discovered that the developers and the role used to deploy the AWS CDK application have more permissions than necessary. The security team also discovered that the roles attached to the Lambda func...

Let's evaluate each of the options and discuss which one best fits the requirements, keeping in mind the need to reduce permissions for the developers, ensure they cannot grant extra permissions, and minimize operational overhead. Option A: Create an SCP that denies the `iam:CreateRole` action and the `iam:UpdateRole` action for the developer role and the AWS CDK application deployment role. Centrally create new IAM roles to attach to the Lambda functions for the developers to use to provision Lambda functions. - Analysis: - Pros: An SCP (Service Control Policy) can be effective in restricting actions across the organization by denying certain IAM actions, preventing the developers from creating or updating roles. - Cons: The requirement for centrally creating IAM roles for Lambda functions introduces additional operational overhead because it would require the security or admin team to manage the roles manually and ensure they're attached to the Lambda functions. - Operational Overhead: This approach requires manual intervention from security or admin teams to create IAM roles for Lambda functions, which adds overhead. Option B: Create an IAM permission boundary policy. Define the maximum actions that the AWS CDK application requires in the policy. Update the account's AWS CDK bootstrapping to use the permission boundary. Update the configuration in the AWS CDK application for the default permissions boundary to use the policy. - Analysis: - Pros: A permission boundary allows defining the maximum actions that the CDK application can take, which limits the permissions granted to the Lambda function roles automatically. - Cons: The CDK bootstrapping and application code must be updated to ensure the permission boundary is correctly applied. This might add complexity but not too much operational overhead in terms of day-to-day operations. - Operational Overhead: Minimal operational overhead after the initial setup. Developers would not have the ability to create roles with more permissions than necessary. - Simplicity: This option centralizes permission management and aligns with the principle of least privilege. Option C: Create an IAM permission boundary policy. Define the maximum actions that the AWS CDK application requires in the polic...

Author: GlowingTiger · Last updated Jul 20, 2026

A company uses Amazon Elastic Container Registry (Amazon ECR) private registries to store container images. A DevOps team needs to ensure that the container images are regularly scanned f...

Let's evaluate each of the options in the context of regularly scanning container images for software vulnerabilities in Amazon ECR. Option A: Enable enhanced scanning for private registries in Amazon ECR. - Analysis: - Pros: Amazon ECR provides an enhanced scanning feature powered by Amazon Inspector, which scans container images for vulnerabilities. This is a built-in feature of ECR and can be enabled easily for private registries. Enhanced scanning is designed to provide in-depth analysis, including known CVEs (Common Vulnerabilities and Exposures) and compliance checks. - Cons: None. This is the most straightforward solution as it is fully integrated into ECR, does not require additional configurations, and runs automatically whenever a new image is pushed. - Operational Overhead: Minimal. ECR handles the scanning automatically without the need for external configuration or ongoing manual maintenance. Option B: Enable basic continuous scanning for private registries in Amazon ECR. - Analysis: - Pros: Basic scanning also checks for vulnerabilities in container images, but the feature does not provide as detailed a vulnerability assessment as enhanced scanning. It is still a valuable option for detecting vulnerabilities at a basic level. - Cons: Basic scanning offers less thorough analysis and fewer features compared to enhanced scanning. It may not detect as many vulnerabilities or provide as detailed insights as the enhanced version. - Operational Overhead: Like enhanced scanning, it’s automated, but it lacks the depth needed for more comprehensive vulnerability management. - When to use: This option could be used in situations where basic scanning suffices, but for teams needing more thorough results, enhanced scanning is the better choice. Option C: Create an AWS Systems Manager Automation document to scan images by using the AWS SDK. Configure the Automation document to run when a new image is pushed to an ECR registry. - Analysis: - Pros: This solution provides flexib...

Author: Charlotte · Last updated Jul 20, 2026

A security team sets up a workflow that invokes an AWS Step Functions workflow when Amazon EventBridge matches specific events. The events can be generated by several AWS services. AWS CloudTrail records user activities. The security team notices that some important events do not invoke the workflow as expected. The CloudTrail logs do not indicate any ...

To identify the root cause of the missing event invocations, we need to focus on the integration points between Amazon EventBridge and AWS Step Functions, and also ensure that no permissions or event pattern mismatches are causing the issue. Let's review each option and select the appropriate steps. Option A: Enable EventBridge schema discovery on the event bus to determine whether the event patterns match the expected schema. - Analysis: EventBridge schema discovery helps identify whether events match the expected structure and format. If the event pattern is not correctly matching the events, it would explain why some events do not trigger the workflow. Enabling schema discovery can provide insights into any mismatch or missing attributes in the event patterns. - Why Selected: This step is crucial to ensure that the events from various AWS services are structured correctly and match the expected event patterns in the EventBridge rule. If there’s a mismatch in the schema, the event will not trigger the workflow, which is exactly the root cause the security team is facing. Option B: Configure Amazon CloudWatch to monitor EventBridge metrics and Step Functions metrics. Set up alerts for anomalies in event patterns and workflow invocations. - Analysis: Monitoring CloudWatch metrics for both EventBridge and Step Functions provides visibility into whether events are being matched and successfully processed. Alerts for anomalies could highlight missing invocations, delays, or processing issues, but this approach alone does not directly address potential mismatches in event patterns or permission issues. - Why Rejected: While helpful for general monitoring, this option does not provide direct visibility into the cause of the missing event invocations. It is more about detecting and alerting anomalies rather than directly troubleshooting event matching or permission issues. Option C: Configure an AWS Lambda logging function to monitor and log events from EventBridge to provide more details about the processed events. - Analysis: Using a Lambda function to log incoming events from EventBridge can help track which events are being processed and if any events are missed or filtered out by the rule. This could provide more visibility into the event flow and help identify why specific events are missing from the Step Functions invocation. - Why Selected: This option provides direct insights into the events that are being processed by EventBridge and whether they are being properly passed to Step Functions. By logging the events, the team can see if certain events are not being handled or processed due to missing...

Author: Ishaan · Last updated Jul 20, 2026

A company's DevOps engineer uses AWS Systems Manager to perform maintenance tasks. The company has a few Amazon EC2 instances that require a restart after notifications from AWS Health. The DevOps engineer must implement an automated solution that uses Amazon EventBridge to remediate the notifications during t...

Let's evaluate each option in detail to determine the most appropriate solution for automating EC2 instance restarts in response to notifications from AWS Health during scheduled maintenance windows. Option A: Configure an event source of AWS Health. Configure event types that indicate scheduled instance termination and retirement. Target the AWS-RestartEC2Instance Systems Manager Automation runbook to restart the EC2 instances. - Analysis: - Pros: AWS Health provides event notifications related to scheduled instance maintenance (e.g., instance retirement, termination). Using this as an event source is appropriate because it directly ties into the notifications you want to act on. The AWS-RestartEC2Instance Systems Manager Automation runbook is specifically designed to restart EC2 instances. - Cons: This option does not explicitly mention utilizing the company's maintenance windows, which is a key requirement. While it automatically triggers the restart, there is no mention of making the task contingent on the maintenance window's schedule. - When to use: This option would be ideal if you wanted the restart to occur immediately upon receiving the notification, but it doesn't factor in the need for scheduled maintenance windows. Option B: Configure an event source of Systems Manager. Configure an event type that indicates a maintenance window. Target the AWS-RestartEC2Instance Systems Manager Automation runbook to restart the EC2 instances. - Analysis: - Pros: This option allows you to use Systems Manager to trigger the restart, which aligns with the requirement to perform tasks within scheduled maintenance windows. It directly uses the Systems Manager runbook (`AWS-RestartEC2Instance`) to restart EC2 instances. - Cons: Systems Manager events related to maintenance windows do not specifically address the notifications from AWS Health related to instance maintenance, such as termination or retirement. The event source being Systems Manager makes this option somewhat disconnected from AWS Health notifications, potentially leading to missed events that AWS Health would provide. - When to use: This option could work if you're primarily focused on ensuring the task happens during a maintenance window, but it may not align directly with the AWS Health notifications. Option C: Configure an event source of AWS Health. Configure event types that indicate scheduled instance termination and retirement. Target a newly created AWS Lambda function that registers a Systems Manager maintenance window task to restart the EC2 instances. - Analysis: - Pros: This solution...

Author: Michael · Last updated Jul 20, 2026

A DevOps engineer manages an AWS CodePipeline pipeline that builds and deploys a web application on AWS. The pipeline has a source stage, a build stage, and a deploy stage. When deployed properly, the web application responds with a 200 OK HTTP response code when the URL of the home page is requested. The home page recently returned a 503 HTTP response code after CodePipeline deployed the application. The DevOps engineer needs to add an automated test into the pipeline. The automated test must ensure that the application returns a 200 OK HTTP response code after the application...

To implement the automated test that verifies whether the application responds with a 200 OK HTTP response code after deployment, the DevOps engineer needs a solution that checks the status of the application and integrates with AWS CodePipeline. Option A: Configure the CheckURL stage to use an Amazon CloudWatch action. Configure the action to use a canary synthetic monitoring check on the application URL and to report a success or failure to CodePipeline. - Analysis: Amazon CloudWatch can perform synthetic monitoring using canaries to test the application URL. While this option is a valid way to monitor the availability of the application, it is typically used for long-term monitoring rather than for short-lived checks that need to be part of the pipeline process. The canary would run periodically, but its integration into CodePipeline as an immediate step for testing post-deployment may not be straightforward. - Why Rejected: While CloudWatch can handle HTTP response checks, it is more suited for ongoing monitoring rather than an immediate test within a pipeline workflow. It does not directly integrate with the pipeline's failure criteria in the way the pipeline needs. Option B: Create an AWS Lambda function to check the response code status of the URL and to report a success or failure to CodePipeline. Configure an action in the CheckURL stage to invoke the Lambda function. - Analysis: Using a Lambda function to check the HTTP response code status of the application URL is a suitable and lightweight approach. The Lambda function can make an HTTP request to the URL, check if the response code is 200 OK, and return a success or failure. This integrates directly into CodePipeline, and if the test fails (i.e., if the response code is not 200), the pipeline can be configured to fail accordingly. - Why Selected: This solution meets the requirements by allowing the DevOps engineer to implement a test that can immediately check the application’s response and fail the pipeline if the test does not pass. Lambda functions are flexible and can...

Author: FrostFalcon88 · Last updated Jul 20, 2026

A company has an application that uploads access logs to an Amazon CloudWatch Logs log group. The fields in the log lines include the response code and the application name. The company wants to create a CloudWatch metric to track the number of requests by respo...

Let's analyze each of the provided options based on the company's need to track the number of requests by response code in a specific range and with a specific application name. Option A: Create a CloudWatch Logs log event filter on the CloudWatch Logs log stream to match the response code range. Configure the log event filter to increment a metric. Set the response code and application name as dimensions. - Reasoning: This option involves using a log event filter at the log stream level. A log event filter is used to match specific patterns in the logs, but it works on individual log events, and filtering at the log stream level can be too broad, as CloudWatch Logs log streams generally represent a collection of log events over a period. It does not fit the requirement to specifically track metrics based on a set of logs over time with a particular range of response codes and application names. - Rejected: This approach is less efficient because log streams can be large and diverse, and filtering by log stream may not provide the desired granularity for the required tracking. Option B: Create a CloudWatch Logs metric filter on the CloudWatch Logs log group to match the response code range. Configure the metric filter to increment a metric. Set the response code and application name as dimensions. - Reasoning: This option directly matches the requirement by setting up a metric filter at the log group level, which is where logs are typically grouped and analyzed in CloudWatch. The metric filter allows you to define patterns for specific fields, such as the response code range, and to create custom metrics based on these patterns. You can also set dimensions like the response code and application name to track metrics more specifically. - Selected: This is the best option because it offers the correct granularity, flexibility, and functionality for monitoring logs with specific fields such as the response code range and application name. Option C: Create a CloudWatch Contributor Insights...

Author: Aria · Last updated Jul 20, 2026

A DevOps engineer provisioned an Amazon Elastic Kubernetes Service (Amazon EKS) cluster with managed node groups. The DevOps engineer associated an OpenID Connect (OIDC) issuer with the cluster. The DevOps engineer is configuring Amazon Elastic Block Store (Amazon EBS) General Purpose SSD (gp3) volumes for the cluster. The DevOps engineer attempts to initiate a PersistentVolumeClaim (PVC) request but is unable to provision a volume. To troubleshoot the issue, the DevOps engineer runs the kubect...

Let's analyze each option and determine the most appropriate solution to resolve the error when provisioning an Amazon EBS volume for the PersistentVolumeClaim (PVC) in an Amazon EKS cluster. Option A: Create a Kubernetes cluster role that allows the persistent volumes to perform get, list, watch, create, and delete operations. Configure the cluster role to allow get, list, and watch operations for storage in the cluster. - Analysis: - Pros: This option deals with Kubernetes RBAC (Role-Based Access Control) and might resolve some permissions issues within the cluster. - Cons: The error message (`could not create volume in EC2: UnauthorizedOperation`) points to an IAM permission issue, not a Kubernetes RBAC permission issue. The error indicates that the EKS cluster cannot perform actions in EC2 due to insufficient IAM permissions, not Kubernetes role permissions. Creating a Kubernetes role would not address the IAM permissions needed for the Amazon EBS CSI driver to provision volumes. - When to use: This option might be used if Kubernetes RBAC was the issue, but it is not the correct solution for resolving IAM permission problems related to EC2. Option B: Create an Amazon EBS Container Storage Interface (CSI) driver IAM role that has the required permissions and trust relationships. Attach the IAM role to the Amazon EBS CSI driver add-on in the cluster. - Analysis: - Pros: The error message (`UnauthorizedOperation`) suggests that the issue lies in permissions when trying to create the volume in EC2. The Amazon EBS CSI driver requires specific IAM permissions to interact with EC2 to provision volumes. This option proposes creating an IAM role for the EBS CSI driver and attaching it to the cluster, which would ensure that the necessary EC2 permissions are granted. - Cons: None. This solution directly addresses the issue by ensuring that the EBS CSI driver has the necessary IAM permissions and trust relationships to create volumes in EC2. - When to use: This is the correct solution as it resolves the IAM permissions issue directly, allowing the EBS CSI driver to provision volumes successfully. Option C: Add the `ebs.csi.aws.com/volumeType:gp3` annotation to the PersistentVolumeClaim objec...

Author: Sofia · Last updated Jul 20, 2026

A company runs a fleet of Amazon EC2 instances in a VPC. The company's employees remotely access the EC2 instances by using the Remote Desktop Protocol (RDP). The company wants to collect metrics about how many RDP sessions the em...

Let's evaluate each option to determine the best combination of steps to collect metrics about the number of RDP sessions employees initiate every day: Option A: Create an Amazon EventBridge rule that reacts to EC2 Instance State-change Notification events. - Analysis: - Pros: EventBridge rules can be used to monitor changes in EC2 instance states, such as when instances are started or stopped. However, RDP sessions do not trigger EC2 instance state changes, so this would not directly capture RDP session information. - Cons: EC2 Instance state-change notifications do not provide information about RDP sessions themselves (i.e., who initiated them or when). This option would not be useful for tracking RDP sessions. - When to use: This is more relevant to tracking EC2 lifecycle events, such as instance starts or stops, not for tracking RDP sessions. Option B: Create an Amazon CloudWatch Logs log group. Specify the log group as a target for the EventBridge rule. - Analysis: - Pros: CloudWatch Logs can be used to store logs from various sources, such as EC2 instances. You can specify a log group as a target for EventBridge, allowing you to collect logs from EC2 instances that could contain information about RDP sessions (e.g., Windows event logs). - Cons: This option only sets up the log group and target without specifying where the actual RDP session information will come from. You still need to configure logging at the instance level (e.g., enabling Windows Event Logging or similar methods) for it to capture the RDP data. - When to use: This is part of the solution but requires further steps to actually collect RDP session data. Option C: Create a flow log in VPC Flow Logs. - Analysis: - Pros: VPC Flow Logs can capture network traffic information, which could include RDP connections. RDP traffic typically uses TCP port 3389, so you could analyze VPC Flow Logs for incoming traffic on that port to infer RDP sessions. - Cons: VPC Flow Logs only provide network-level data, such as whether traffic on port 3389 was initiated. It won't provide detailed session information such as user identities or the actual count of RDP sessions. It also wouldn't directly capture login events or session terminations. - When to use: This can be part of the solution to capture RDP traffic, but it doesn't provide full session-level details such as who initiated the session. Option D: Create an Amazon CloudWatch Logs log group. Specify the log group as a destination for the flow log. - Analysis: - Pros: This option ensures that the VPC Flow Logs are sent to CloudWatch Logs, which can be used to analyze the traffic, including RDP traffic (on port 3389). Once in CloudWatch Logs, you can create filters and metrics to track the RDP s...

Author: Ava · Last updated Jul 20, 2026

A company is using Amazon Elastic Kubernetes Service (Amazon EKS) to run its applications. The EKS cluster is successfully running multiple pods. The company stores the pod images in Amazon Elastic Container Registry (Amazon ECR). The company needs to configure Pod Identity access for the EKS cluster. The company...

Let’s analyze each option based on the requirement to configure Pod Identity access for an Amazon EKS cluster, ensuring that the solution is effective for pod access to AWS resources with IAM roles. Option A: Create an IAM OpenID Connect (OIDC) provider for the EKS cluster. - Analysis: - Pros: EKS supports the use of OIDC to allow pods to assume IAM roles, which is a key component of Pod Identity. By creating an OIDC provider, you can link the Kubernetes service account to IAM roles and enable secure access to AWS resources from the pods. - Cons: This is just one part of the solution. Creating the OIDC provider is necessary but not sufficient on its own. You also need to assign roles to Kubernetes service accounts, which is not covered by this option. - When to use: This step is essential in the overall process, but it's incomplete by itself. It should be part of a broader configuration. Option B: Ensure that the nodes can reach the EKS Auth API. Add and configure the EKS Pod Identity Agent add-on for the EKS cluster. - Analysis: - Pros: This option describes a key step for enabling Pod Identity. The EKS Pod Identity Agent is a component that works with the OIDC provider to allow Kubernetes service accounts to assume IAM roles on behalf of the pods. It configures the communication and identity management necessary for Pod Identity to function properly. - Cons: Ensuring that nodes can reach the EKS Auth API is required, but the key action here is installing and configuring the EKS Pod Identity Agent, which ties the IAM roles to the service accounts and manages role assumption. - When to use: This is the most complete solution, as it integrates the Pod Identity Agent to manage the service account-to-IAM role mapping and ensure pods can assume the appropriate IAM roles. Option C: Create an EKS access entry that uses the API_AND-CONFIG_MAP cluster authentication mode. - Analysis: - Pros: This option configures authentication modes for the EKS cluster, which is part of setting ...

Author: SilverBear · Last updated Jul 20, 2026

A company has multiple AWS accounts in an organization in AWS Organizations that has all features enabled. The company's DevOps administrator needs to improve security across all the company's AWS accounts. The administrator needs to identify the top users and role...

Let's analyze each of the options in detail to determine which solution will provide the most operational efficiency to identify the top users and roles across multiple AWS accounts in an organization: Option A: Create a new organization trail in AWS CloudTrail. Configure the trail to send log events to Amazon CloudWatch Logs. Create a CloudWatch Contributor Insights rule for the userIdentity.arn log field. View the results in CloudWatch Contributor Insights. - Analysis: - Pros: CloudTrail logs provide detailed event information about the actions taken by users and roles across AWS accounts, and CloudWatch Contributor Insights allows you to analyze logs and create custom visualizations. - Cons: This option involves setting up a CloudTrail trail and then configuring CloudWatch Contributor Insights. While effective, it may require significant setup effort, especially when trying to correlate logs from multiple accounts in AWS Organizations. Managing and querying logs for top users across multiple accounts can become operationally complex and require custom parsing and insights logic. - When to use: This option could be useful for real-time analysis and visualization, but it can become more complex to maintain over time due to the volume of log data and custom configurations required. Option B: Create an unused access analysis for the organization by using AWS Identity and Access Management Access Analyzer. Review the analyzer results and determine if each finding has the intended level of permissions required for the workload. - Analysis: - Pros: IAM Access Analyzer helps identify unused access and potential security risks. It’s great for auditing permissions and access levels for users and roles. - Cons: However, IAM Access Analyzer primarily focuses on unused access (i.e., access that is granted but not used) and does not directly provide a way to identify the top users and roles in active use across accounts. It is more focused on finding unused or over-permissive access, which is a different requirement than identifying the most active users and roles. - When to use: This is better suited for identifying unused permissions rather than active users or roles. Option C: Create a new organization trail in AWS CloudTrail. Create a table in Amazon Athena that uses partition projection. Load the Athena table with CloudTrail data. Query the Athena table to find the top users and roles. - Analysis: - Pros: CloudTrail provides detailed logs of user and role activities across all AWS accounts, and Athena can be used to run queries on this data. By creating a partitioned Athena table, the administrator can query the CloudTrail data efficiently and identify the most active users and roles in each account. This approach is highly scalable and can be automated to generate reports. - Cons: This opti...

Author: Mia · Last updated Jul 20, 2026

A company has an organization in AWS Organizations with many Oils that contain many AWS accounts. The organization has a dedicated delegated administrator AWS account. The company needs the accounts in one OU to have server-side encryption enforced for all Amazon Elastic Block Store (Amazon EBS) volumes and Amazon Simple Queue Service (Amazon SQS) queues that are cr...

To solve the problem of enforcing server-side encryption for Amazon EBS volumes and Amazon SQS queues during CloudFormation stack operations, let's evaluate the provided options: Option A: Activate trusted access to CloudFormation StackSets. Create a CloudFormation Hook that enforces server-side encryption on EBS volumes and SQS queues. Deploy the Hook across the accounts in the OU by using StackSets. - Explanation: StackSets allow the deployment of CloudFormation templates across multiple AWS accounts and regions. By creating a CloudFormation Hook, we can enforce encryption requirements (such as server-side encryption for EBS volumes and SQS queues) at the time of stack creation or update. The Hook would run checks and prevent any resource that doesn't meet the encryption requirement. - Why Selected: This is the most suitable option because the enforcement is directly tied to CloudFormation stack operations. It integrates seamlessly with CloudFormation, providing a proactive approach to enforce encryption during stack operations. - Why Rejected: Other options don't directly tie into CloudFormation stack operations, which is a key requirement. Option B: Set up AWS Config in all the accounts in the OU. Use AWS Systems Manager to deploy AWS Config rules that enforce server-side encryption for EBS volumes and SQS queues across the accounts in the OU. - Explanation: AWS Config is useful for continuous monitoring of resources and ensuring compliance with desired configurations, such as encryption. However, it works after the fact (i.e., after the resource is created or modified) and doesn't prevent stack creation or modification. - Why Rejected: While AWS Config can be used for compliance and remediation, it does not stop a CloudFormation stack operation from proceeding if it doesn't meet the encryption policy. Option C: Write an SCP to deny the creation...

Author: ShadowWolf101 · Last updated Jul 20, 2026

A company is running an internal application in an Amazon Elastic Container Service (Amazon ECS) cluster on Amazon EC2. The ECS cluster instances can connect to the public internet. The ECS tasks that run on the cluster instances are configured to use images from both private Amazon Elastic Container Registry (Amazon ECR) repositories and a public ECR registry repository. A new security policy requires the company to remove the ECS cluster's direct access to the internet. The company must remove any NAT gateways and internet gateways from the VPC that hosts the cluster. A DevOps engineer needs to ensure the ECS cluster can still download images from both the public ECR registry and...

Let's evaluate the provided options to meet the requirements of allowing the ECS cluster to download images from both the private and public Amazon ECR repositories without direct internet access, while also ensuring that public ECR images remain up-to-date and available within 24 hours. Key Considerations: 1. No direct internet access: The ECS cluster should not have access to the internet, so we need to avoid NAT gateways or internet gateways. 2. Download public ECR images: The ECS cluster must continue to pull images from the public ECR registry, and these images must be updated within 24 hours. 3. Private ECR repository access: The ECS cluster should still have access to private ECR repositories within the VPC. 4. Minimal operational overhead: The solution must automate as much as possible and minimize manual intervention. Option A: Create an AWS CodeBuild project and a new private ECR repository for each image that is downloaded from the public ECR registry. Configure each project to pull the image from the public ECR repository and push the image to the new private ECR repository. Create an Amazon EventBridge rule that invokes the CodeBuild project once every 24 hours. Update each task definition in the ECS cluster to refer to the new private ECR repository. - Explanation: This option involves creating a new private ECR repository for each public image and using AWS CodeBuild to periodically pull the images from the public registry and push them to the private registry. While it meets the requirement to keep images updated, it introduces additional complexity, requiring multiple repositories and automated workflows with CodeBuild and EventBridge. - Why Rejected: This option increases operational overhead due to the need to manage multiple private repositories, CodeBuild projects, and EventBridge rules. The process of manually setting up each image is more labor-intensive compared to other solutions. Option B: Create a new Amazon ECR pull-through cache rule for each image that is downloaded from the public ECR registry. Create an AWS Lambda function that invokes each pull-through cache rule. Create an Amazon EventBridge rule that invokes the Lambda function once every 24 hours. Update each task definition in the ECS cluster to refer to the image from the pull-through cache. - Explanation: This option involves creating a pull-through cache rule in Amazon ECR, which allows ECS to pull images from the public ECR registry through the cache. The Lambda function and EventBridge rule trigger updates for the images every 24 hours. While this ensures up-to-date images, the operational overhead of managing Lambda functions and EventBridge rules adds complexity. - Why Rejected: Like Option A, this involves extra steps with Lambda and EventBridge that introduce more complexity. Additionally, the Lambda function is unnecessary as ECR's pull-through cache inherently supports the process without additional function calls. ...

Author: Ethan Smith · Last updated Jul 20, 2026

A company has a continuous integration pipeline where the company creates container images by using AWS CodeBuild. The created images are stored in Amazon Elastic Container Registry (Amazon ECR). Checking for and fixing the vulnerabilities in the images takes the company too much time. The company wants to identify the image vulnerabilities quickly and not...

Let's evaluate the options provided to identify vulnerabilities in container images and notify the security team quickly with the least operational overhead. Key Considerations: - Quick identification of vulnerabilities: The process should automatically detect vulnerabilities as soon as the container images are pushed to Amazon ECR. - Notification to the security team: Once vulnerabilities are detected, an automated notification system must alert the security team. - Least operational overhead: The solution must be easy to configure and manage, with minimal manual intervention. Option A: Activate Amazon Inspector enhanced scanning for Amazon ECR. Configure the enhanced scanning to use continuous scanning. Set up a topic in Amazon Simple Notification Service (Amazon SNS). - Explanation: Amazon Inspector enhanced scanning provides deeper vulnerability analysis for container images. Enabling continuous scanning ensures that any new or updated container images are automatically scanned for vulnerabilities as soon as they are pushed to Amazon ECR. Configuring Amazon SNS ensures that notifications are sent to the security team when vulnerabilities are detected. - Why Selected: This is an automated, efficient solution for identifying vulnerabilities as soon as the image is pushed to ECR. SNS integration ensures the security team is notified without manual effort. It meets both the speed of identification and ease of notification. - Why Rejected: This option doesn't have any significant drawbacks. It's a straightforward, integrated solution. Option B: Create an Amazon EventBridge rule for Amazon Inspector findings. Set an Amazon Simple Notification Service (SNS) topic as the rule target. - Explanation: This option involves using Amazon EventBridge to listen for findings from Amazon Inspector, then using SNS to notify the security team. While this can be a valid solution, it's slightly more indirect compared to Option A, as EventBridge is being used to route findings to SNS, which adds an extra layer of configuration. - Why Selected: This option also works well for automating notifications, but it adds a bit more complexity than Option A. EventBridge is a useful service, but it may introduce additional operational overhead when the direct SNS integration (from Option A) is available. - Why Rejected: While it works, it’s not the most streamlined approach because it introduces an extra component (EventBridge) that isn’t strictl...

Author: Alexander · Last updated Jul 20, 2026

A company uses Amazon Redshift as its data warehouse solution. The company wants to create a dashboard to view changes to the Redshift users and the queries the users perfo...

Let's break down the options and evaluate them based on the company's requirement of creating a dashboard to view changes to the Redshift users and the queries those users perform. Key Considerations: - Monitoring Redshift user activity: The company wants to track user activity, including changes to users and queries they run. - Dashboard creation: A dashboard should be created that aggregates and displays the information about user activity, which will be updated automatically with the latest data. - Audit logs: Redshift provides auditing capabilities, and the data needs to be collected and analyzed in real-time or with minimal delay. Option A: Create an Amazon CloudWatch log group. Create an AWS CloudTrail trail that writes to the CloudWatch log group. - Explanation: AWS CloudTrail logs API activity, including actions like creating or modifying Redshift users. However, CloudTrail does not log Redshift query execution details or track specific user activity within queries. - Why Rejected: While CloudTrail is useful for capturing administrative actions like user creation or deletion, it doesn't provide detailed query logs. This option alone wouldn't capture the full scope of user query activities, making it insufficient for this requirement. Option B: Create a new Amazon S3 bucket. Configure default audit logging on the Redshift cluster. Configure the S3 bucket as the target. - Explanation: Enabling audit logging in Redshift can record user activity and SQL queries, and storing these logs in an S3 bucket is a common approach. This will provide the detailed user activity and queries that need to be tracked. - Why Selected: This approach allows for comprehensive logging of user activity and queries, which can be later queried and analyzed. Using S3 to store the logs is efficient, but additional steps are needed to visualize this data in a dashboard. - Why Rejected: While logging to S3 works, it doesn’t directly integrate with CloudWatch, which would be more effective for creating a real-time dashboard. The S3 approach is a storage solution, but not a direct one for monitoring and dashboarding purposes. Option C: Configure the Redshift cluster database audit logging to include user activity logs. Configure Amazon CloudWatch as the target. - Explanation: Redshift’s database audit logging captures details about the queries that users run, and it can be configured to send these logs to Amazon CloudWatch....

Author: Nia · Last updated Jul 20, 2026

A company uses an organization in AWS Organizations to manage its 500 AWS accounts. The organization has all features enabled. The AWS accounts are in a single OU. The developers need to use the CostCenter tag key for all resources in the organization's member accounts. Some teams do not use the CostCenter tag key to tag their Amazon EC2 instances. The cloud team wrote a script that scans all EC2 instances in the organization's member accounts. If the EC2 instances do not have a CostCenter tag key, the script will notify AWS account administrators. To avoid this notification, some developers ...

Let's evaluate each option based on the requirements and key factors like enforceability, scalability, and efficiency. A) Create an SCP that prevents the creation of EC2 instances without the CostCenter tag key. Create a tag policy that requires the CostCenter tag to be values from a known list of cost centers for all EC2 instances. Attach the policy to the OU. Update the script to scan the tag keys and tag values. Modify the script to update noncompliant resources with a default approved tag value for the CostCenter tag key. - SCP for EC2 Creation Without CostCenter Tag: This will prevent EC2 instances from being created without a CostCenter tag. It's a strong enforcement mechanism for new resources but doesn't solve the problem for existing EC2 instances. - Tag Policy: It ensures that all EC2 instances will have the CostCenter tag, and only approved values are allowed, but it's not directly enforced in an automated fashion for existing resources. - Script Updates: The script will notify and potentially update non-compliant instances. However, this is a reactive approach, which may not scale well as the environment grows and may lead to administrative overhead. While this option provides robust enforcement, it requires constant script monitoring and manual intervention for existing instances, making it less ideal for larger environments. B) Create an SCP that prevents the creation of EC2 instances without the CostCenter tag key. Attach the policy to the OU. Update the script to scan the tag keys and tag values and notify the administrators when the tag values are not valid. - SCP for EC2 Creation Without CostCenter Tag: Prevents EC2 instances without a CostCenter tag key, which is helpful for new EC2 instances. - Tag Value Notification: The script can notify administrators when the tag value is invalid, but this is a manual process requiring intervention. It doesn't enforce correction. This option has good enforcement for new instances but lacks proactive remediation for existing instances. It also introduces manual monitoring, which is not scalable. C) Create an SCP that prevents the creation of EC2 instances without the CostCenter tag key. Attach the policy ...

Author: FrozenWolf2022 · Last updated Jul 20, 2026

A DevOps engineer uses a pipeline in AWS CodePipeline. The pipeline has a build action and a deploy action for a single-page web application that is delivered to an Amazon S3 bucket. Amazon CloudFront serves the web application. The build action creates an artifact for the web application. The DevOps engineer has created an AWS CloudFormation template that defines the S3 bucket and configures the S3 bucket to host the application. The DevOps engineer has configured a CloudFormation deploy action before the S3 action. The CloudForm...

Let's analyze the options to meet the requirements of configuring the S3 deploy action to use the S3 bucket created by the CloudFormation deploy action. Key Requirements: - Use the S3 bucket from the CloudFormation template in the S3 deploy action after the CloudFormation deploy action has created the bucket. - CloudFormation action should output the bucket name, which is then passed to the S3 deploy action. A) Add an output named BucketName to the CloudFormation template. Set the output's value to refer to the S3 bucket from the CloudFormation template. Configure the output value to export to an AWS::SSM::Parameter resource named Stackvariables. - Analysis: The CloudFormation template output could indeed be used to export values like the S3 bucket name. However, AWS CodePipeline does not directly reference SSM parameters in the way described here. Exporting the output to a Systems Manager (SSM) parameter is not the best way to pass variables between actions in CodePipeline. Instead, outputs should be used in CodePipeline with specific reference methods. - Rejection Reason: The export to SSM parameter isn’t how CodePipeline natively passes outputs from CloudFormation to subsequent actions. B) Add an output named BucketName to the CloudFormation template. Set the output's value to refer to the S3 bucket from the CloudFormation template. Set the CloudFormation action's namespace to StackVariables in the pipeline. - Analysis: This is a good approach. The output value in CloudFormation, when given an appropriate name (like BucketName), can be referenced in subsequent pipeline actions. Setting the namespace in the CloudFormation action ensures that the output value is made available in the pipeline for other actions to use. - Why Selected: This allows the S3 deploy action to use the CloudFormation output correctly as input, as the output will be made available in the pipeline context with the correct namespace. C) Configure the output artifacts of the CloudFormation action in the pipeline to be an AWS Systems Manager Parameter Store parameter named StackVariables. Name the artifact BucketName. - Analysis: Output artifacts in CodePipeline are typically used to pass build artifacts or results between actions. This option tries to use SSM Parameter Store directly, which is not the appropriat...

Author: Aria · Last updated Jul 20, 2026

A company used a lift and shift strategy to migrate a workload to AWS. The company has an Auto Scaling group of Amazon EC2 instances. Each EC2 instance runs a web application, a database, and a Redis cache. Users are experiencing large variations in the web application's response times. Requests to the web application go to a single EC2 instance that is under sign...

Let's evaluate each option based on the need to separate the application components to improve availability and performance, with an emphasis on proper load balancing, database migration, and cache optimization. Option A: Create a Network Load Balancer and an Auto Scaling group for the web application. Migrate the database to an Amazon Aurora Serverless database. Create an Application Load Balancer and an Auto Scaling group for the Redis cache. - Reasoning: This option is not ideal for several reasons. First, the Network Load Balancer (NLB) is typically used for TCP traffic and is more appropriate for low-level protocol load balancing, whereas the Application Load Balancer (ALB) is designed to route HTTP/HTTPS traffic and is more suitable for a web application. Additionally, Redis caching is more efficiently managed with Amazon ElastiCache, not with an Auto Scaling group behind an Application Load Balancer. The Redis Auto Scaling is unnecessary in this context, and it's not the best practice to use an ALB for Redis. - Rejected: The improper usage of the ALB for Redis and the misplacement of components makes this option unsuitable for separating the application components. Option B: Create an Application Load Balancer and an Auto Scaling group for the web application. Migrate the database to an Amazon Aurora database that has a Multi-AZ deployment. Create a Network Load Balancer and an Auto Scaling group in a single Availability Zone for the Redis cache. - Reasoning: The Application Load Balancer is the correct choice for distributing HTTP/S traffic to the web application across multiple EC2 instances. Migrating the database to Amazon Aurora with a Multi-AZ deployment ensures high availability and automatic failover. However, creating a Network Load Balancer for Redis is not optimal. Redis should ideally be managed with ElastiCache, which is a fully managed caching solution optimized for Redis and Memcached workloads. Auto Scaling groups are not needed for Redis as ElastiCache handles scaling automatically. - Rejected: The use of a Network Load Balancer for Redis and the creation of an Auto Scaling group for it is not the most effective solution. Amazon ElastiCache would be a better choice for Redis. ...

Author: Layla · Last updated Jul 20, 2026

A company is using AWS Organizations and wants to implement a governance strategy with the following requirements: * AWS resource access is restricted to the same two Regions for all accounts. * AWS services are limited to a specific group of authorized services for all accounts. * Authentication is provided by Active Dire...

To meet the company's requirements, we need to focus on enforcing access restrictions and ensuring standardized roles and permissions across all accounts, while leveraging Active Directory for authentication. Key Requirements: 1. Region Restrictions: AWS resources should only be accessed in specific Regions. 2. Service Restrictions: Only specific AWS services should be allowed. 3. Authentication via Active Directory: Access permissions must be controlled via an external identity provider (Active Directory). 4. Standardized Access Control by Job Function: The same access permissions should be applied across all accounts, with job function-based roles. Option Analysis: A) Establish an organizational unit (OU) with group policies in the management account to restrict Regions and authorized services. Use AWS CloudFormation StackSets to provision roles with permissions for each job function, including an IAM trust policy for IAM identity provider authentication in each account. - Pros: - Organizational Unit (OU): Using an OU in AWS Organizations is a good approach to group accounts together and apply governance policies at the organizational level. - CloudFormation StackSets: StackSets can be used to deploy consistent roles and permissions across multiple accounts, which is a good fit for the requirement of standardized job function access. - IAM trust policy: By using IAM trust policies, you can allow authentication via an external identity provider like Active Directory. - Cons: - Group policies typically refer to AWS Directory Service or Active Directory, but specific group policies (like GPOs) aren't typically used in AWS for access control. - This solution could be better integrated with AWS Identity and Access Management (IAM) for authentication management. B) Establish a permission boundary in the management account to restrict Regions and authorized services. Use AWS CloudFormation StackSets to provision roles with permissions for each job function, including an IAM trust policy for IAM identity provider authentication in each account. - Pros: - Permission boundaries are useful to ensure that roles and permissions are restricted within defined boundaries. This can enforce the restriction of access to specific services and Regions. - CloudFormation StackSets is again appropriate for consistent deployment across accounts. - IAM trust policy can be configured for Active Directory authentication, which aligns with the authentication requirement. - Cons: - Permission boundary primarily restricts IAM roles and policies, but ...

Author: Zara · Last updated Jul 20, 2026

A company detects unusual login attempts in many of its AWS accounts. A DevOps engineer must implement a solution that sends a notification to the company's security team when multiple failed login attempts occur. The DevOps engineer has already created an Amazon Simple Notification Service (Amazon SNS) topic an...

Key Requirements: - Detect failed login attempts across AWS accounts. - Send notifications to the security team with minimal operational effort. - The solution should be scalable, reliable, and easy to set up and maintain. Option Analysis: A) Configure AWS CloudTrail to send management events to an Amazon CloudWatch Logs log group. Create a CloudWatch Logs metric filter to match failed ConsoleLogin events. Create a CloudWatch alarm that is based on the metric filter. Configure an alarm action to send messages to the SNS topic. - Pros: - CloudTrail captures all management events (including logins) and sending them to CloudWatch Logs allows easy filtering and monitoring. - CloudWatch Logs metric filters can identify failed ConsoleLogin events and trigger alarms when thresholds are exceeded. - CloudWatch alarms are native to AWS and can trigger SNS notifications directly, making this an efficient notification mechanism. - This option requires minimal operational effort once set up, with straightforward monitoring and notification configuration. - Cons: - The approach requires understanding CloudWatch Logs and metric filters but this is a typical AWS pattern and is relatively simple. B) Configure AWS CloudTrail to send management events to an Amazon S3 bucket. Create an Amazon Athena query that returns a failure if the query finds failed logins in the logs in the S3 bucket. Create an Amazon EventBridge rule to periodically run the query. Create a second EventBridge rule to detect when the query fails and to send a message to the SNS topic. - Pros: - Amazon Athena can query logs in S3, and EventBridge rules can trigger actions based on specific conditions. - Cons: - Increased operational effort: This solution requires you to set up Athena queries, EventBridge rules, and periodic execution. It involves more complexity compared to Option A, with potentially higher maintenance and operational overhead. - Querying logs periodically can introduce delays and complexity, as well as the need to manage additional services (Athena, EventBridge, S3) instead of leveraging built-in CloudWatch capabilities. C) Configure AWS CloudTrail to send data events to an Amazon CloudWatch Logs log group. Create a CloudWatch logs ...

Author: NebulaEagle11 · Last updated Jul 20, 2026

A company has deployed a new REST API by using Amazon API Gateway. The company uses the API to access confidential data. The API must be accessed from only specifi...

To meet the requirement of allowing the API to be accessed only from specific VPCs, let's evaluate each option in detail. A) Create and attach a resource policy to the API Gateway API. Configure the resource policy to allow only the specific VPC IDs. - Reasoning: The correct solution in this case is creating and attaching a resource policy to the API Gateway. The API Gateway resource policy allows you to control access based on various factors, including VPCs. You can restrict access by VPC IDs, which effectively ensures that only requests originating from the specified VPCs can access the API. This approach is directly relevant to the problem and provides fine-grained control over API access. - Why Rejected: This is the ideal solution for controlling access based on VPC, and there is no better alternative among the other options provided. B) Add a security group to the API Gateway API. Configure the inbound rules to allow only the specific VPC IP address ranges. - Reasoning: Security groups control access to resources based on IP addresses and protocols. However, API Gateway doesn't use security groups. Security groups are designed for Amazon EC2 instances or other networked resources, not for API Gateway, so this approach cannot be used. - Why Rejected: API Gateway does not directly support the association of security groups, so this op...

Author: StarryEagle42 · Last updated Jul 20, 2026

A company runs a website by using an Amazon Elastic Container Service (Amazon ECS) service that is connected to an Application Load Balancer (ALB). The service was in a steady state with tasks responding to requests successfully. A DevOps engineer updated the task definition with a new container image and deployed the new task definition to the service. The DevOps engineer noticed that the ser...

To troubleshoot the issue where the ECS service is frequently stopping and starting new tasks due to ALB health check failures after updating the task definition, let's analyze each option: A) Ensure that a security group associated with the service allows traffic from the ALB. - Reasoning: If the security group associated with the ECS tasks does not allow traffic from the ALB, then the tasks would fail to receive traffic, which could cause health check failures. However, this typically leads to issues where the tasks are unable to respond to requests at all. Given that the tasks were responding successfully before the update, this option seems unlikely to be the cause, assuming that the security group settings were already correct before the deployment. - Why Rejected: If the tasks were functioning properly before the update, it is less likely that a security group misconfiguration is the cause of the health check failures after a deployment, especially since the issue started after the new task definition was deployed. B) Increase the ALB health check grace period for the service. - Reasoning: The health check grace period is the amount of time that ECS allows a new task to be started before it begins health checks. If the new containerized task takes longer than expected to start (due to resource provisioning, the time needed for the container to fully initialize, or dependencies that need to be ready), then the health checks might fail prematurely. Increasing the grace period allows more time for the new tasks to be considered healthy, especially if they are taking longer than expected to start. - Why Selected: This option addresses a common scenario where newly deployed tasks may need additional time to start up and become healthy, especially after an image update or deployment. By increasing the grace period, ECS will allow tasks more time to become ready before health checks start, reducing the chances of failure due to premature health check failure...

Author: Maya · Last updated Jul 20, 2026

A company that uses electronic patient health records runs a fleet of Amazon EC2 instances with an Amazon Linux operating system. The company must continuously ensure that the EC2 instances are running operating system patches and application patches that are in compliance with current privacy regulations. The company uses a custom repository to store application patches. A DevOps engineer needs to automate the deployment of operating system patches and applic...

Let's evaluate each option for automating the deployment of both operating system and application patches with the least effort: A) Use AWS Systems Manager to create a new custom patch baseline that includes the default operating system repository and the custom repository. Run the AWS-RunPatchBaseline document by using the Run command to verify and install patches. Use the BaselineOverride API to configure the new custom patch baseline. - Reasoning: This approach allows you to automate the process of patching the operating system and custom applications in a single, unified patch baseline. AWS Systems Manager provides built-in capabilities for patch management, and creating a custom patch baseline can be done through its console or APIs. By integrating both the default repository and the custom repository into a single baseline, the process becomes more streamlined, and patches can be deployed with minimal intervention. - Why Selected: This solution makes use of AWS Systems Manager, which is specifically designed for managing patches across EC2 instances. It leverages the least effort by automating both OS and custom application patch management through one system, reducing manual configuration and complexity. The BaselineOverride API allows the flexibility needed to configure the custom baseline, making this a clean and efficient solution. B) Use AWS Direct Connect to integrate the custom repository with the EC2 instances. Use Amazon EventBridge events to deploy the patches. - Reasoning: AWS Direct Connect is a service that facilitates dedicated network connections between on-premises environments and AWS. While it could be used for integrating on-premises systems or custom repositories with EC2, it is not the most appropriate solution for patch management. Additionally, EventBridge is generally used for event-driven architectures, and while it could trigger patching processes, it doesn’t directly address patch deployment or simplify the integration of OS and custom patches in the way Systems Manager does. - Why Rejected: This solution involves more complex setup and infrastructure (Direct Connect), and does not provide an out-of-the-box, simple patch management solution like Systems Manager. It would also require more configuration effort for patching and wouldn't meet the "least effort" requirement. C) Use the yum-config-manager command t...

Author: Manish · Last updated Jul 20, 2026

A company use an organization in AWS Organizations to manage multiple AWS accounts. The company has enabled all features enabled for the organization. The company configured the organization as a hierarchy of OUs under the root OU. The company recently registered all its OUs and enrolled all its AWS accounts in AWS Control Tower. The company needs to customize the AWS Control Tower managed AWS Config configuration recorder in each of the company's AWS accounts. The company needs to apply the...

Let’s evaluate the options step by step to ensure the solution aligns with the requirement of customizing the AWS Config configuration recorder in all AWS accounts, including future accounts, that are managed by AWS Control Tower. A) Create a new AWS account. Create an AWS Lambda function in the new account to apply the customizations to the AWS Config configuration recorder in each AWS account in the organization. - Reasoning: Creating a new AWS account and deploying a Lambda function within it is unnecessary and inefficient. Since AWS Control Tower already manages multiple AWS accounts in the organization, creating an entirely new account for this specific task adds unnecessary complexity. The goal is to apply changes across all accounts, not to create another management layer. - Why Rejected: This option adds extra complexity and overhead by introducing a new AWS account without addressing the requirement of applying customizations to all existing and future accounts centrally. B) Create a new AWS account as an AWS Config delegated administrator. Create an AWS Lambda function in the delegated administrator account to apply the customizations to the AWS Config configuration recorder in the delegated administrator account. - Reasoning: An AWS Config delegated administrator can be used to manage AWS Config across multiple accounts in an organization. However, this solution doesn’t fully address the need to apply customizations across all accounts, including future ones, in a centralized and automated way. While it could work for the delegated administrator account, it doesn't extend to all accounts unless extended manually to each one. - Why Rejected: This option only applies to the delegated administrator account, and would require further actions to apply to other accounts, making it less efficient than the ideal solution. C) Configure an Amazon EventBridge rule in the AWS Control Tower management account to invoke an AWS Lambda function when the Organizations OU is registered or reregistered. Re-register the root Organizations OU. - Reasoning: Using EventBridge to trigger a Lambda function when an OU is registered or reregistered in AWS Organizations is a good approach for automation. This can ensure that any changes in the organization (e.g., adding new OUs or registering new accounts) automatically trigger the required Lambda function to apply the customizations. Re-registering the root OU will make sure the changes are applied to new accounts. - Why Selected: This approach makes use of EventBridge to trigger automation whenever there are changes to the organization’s structure, ensuring that both existing and future AWS accounts receive the necessary customizations for the AWS Config configuration recorder. D) Configure the AWSControlTowerExecution IAM r...

Author: Charlotte · Last updated Jul 20, 2026

A company runs an application in an Auto Scaling group of Amazon EC2 instances behind an Application Load Balancer (ALB). The EC2 instances run Docker containers that make requests to a MySQL database that runs on separate EC2 instances. A DevOps engineer needs to update ...

Let's evaluate each option based on the goal of converting the existing application to a serverless architecture with the least changes: A) Replace the containers that run on EC2 instances and the ALB with AWS Lambda functions. Replace the MySQL database with an Amazon Aurora Serverless v2 database that is compatible with MySQL. - Reasoning: This option replaces the EC2 instances, containers, and ALB with AWS Lambda functions. Additionally, it switches the MySQL database to Aurora Serverless v2, which is compatible with MySQL. Lambda is serverless and would provide automatic scaling. Aurora Serverless v2 would also auto-scale based on the demand and is a good fit for MySQL workloads. - Why Rejected: While this approach does reduce management overhead by using serverless technologies, it requires significant changes. The entire application code would need to be refactored to run as Lambda functions. This would be a bigger change than just modifying the infrastructure slightly. Additionally, transitioning from EC2 instances running containers to Lambda functions introduces complexity in managing long-running or stateful processes that might have been managed more easily in containers. B) Replace the containers that run on EC2 instances with AWS Fargate. Replace the MySQL database with an Amazon Aurora Serverless v2 database that is compatible with MySQL. - Reasoning: This option replaces the EC2 instances running containers with AWS Fargate, which allows containers to run in a serverless environment without needing to manage EC2 instances. It also replaces the MySQL database with Aurora Serverless v2, which can scale automatically and is compatible with MySQL. - Why Selected: This is the best option because it meets the serverless requirement with the fewest changes. Fargate allows the existing Docker containers to run without modification in a serverless way, and Aurora Serverless v2 is a good fit to replace MySQL with minimal changes to the application. The overall architecture remains largely unchanged except for the infrastr...

Author: Zain · Last updated Jul 20, 2026

What Our Friends Say

What Our Friends Say

Amazon Practice Questions, Discussions & Exam Topics by our Authors

A DevOps engineer uses AWS CodeBuild to frequently produce software packages. The CodeBuild project builds large Docker images that the DevOps engineer can use across multiple builds. The DevOps engineer wants to ...

A security team wants to use AWS CloudTrail to monitor all actions and API calls in multiple accounts that are in the same organization in AWS Organizations. The security team needs to ensure that account users...

A company uses an Amazon Aurora PostgreSQL global database that has two secondary AWS Regions. A DevOps engineer has configured the database parameter group to guarantee an RPO of 60 seconds. Write operations on the primary cluster are occasionally blocked because of the RPO setting. T...

A DevOps engineer deploys an application to a fleet of Amazon Linux EC2 instances. The DevOps engineer needs to monitor system metrics across the fleet. The DevOps engineer wants to monitor the relationship between network traffic and memory utilization for the application cod...

A company has several AWS accounts. An Amazon Connect instance runs in each account. The company uses an Amazon EventBridge default event bus in each account for event handling. A DevOps team needs to receive all the...

During a security audit, a company discovered that some security groups allow SSH traffic from 0.0.0.0/0. A security team must implement a solution to detect and remediate this issue as soon as possible. The company uses one organization in AW...

A company uses Amazon Elastic Container Registry (Amazon ECR) private registries to store container images. A DevOps team needs to ensure that the container images are regularly scanned f...

A company has an application that uploads access logs to an Amazon CloudWatch Logs log group. The fields in the log lines include the response code and the application name. The company wants to create a CloudWatch metric to track the number of requests by respo...

A company runs a fleet of Amazon EC2 instances in a VPC. The company's employees remotely access the EC2 instances by using the Remote Desktop Protocol (RDP). The company wants to collect metrics about how many RDP sessions the em...

A company has multiple AWS accounts in an organization in AWS Organizations that has all features enabled. The company's DevOps administrator needs to improve security across all the company's AWS accounts. The administrator needs to identify the top users and role...

A company uses Amazon Redshift as its data warehouse solution. The company wants to create a dashboard to view changes to the Redshift users and the queries the users perfo...

A company has deployed a new REST API by using Amazon API Gateway. The company uses the API to access confidential data. The API must be accessed from only specifi...

A company runs an application in an Auto Scaling group of Amazon EC2 instances behind an Application Load Balancer (ALB). The EC2 instances run Docker containers that make requests to a MySQL database that runs on separate EC2 instances. A DevOps engineer needs to update ...