Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company is planning to migrate to the AWS Cloud. The company needs to understand the existing on-premises usage and configuration. The company does not want to replicate its w...
To determine which AWS service or tool will best meet the company's requirements, let's break down the problem and analyze the options:
Requirements:
1. Understand existing on-premises usage and configuration.
2. Do not replicate workloads to AWS yet.
Options Analysis:
A) AWS Application Discovery Service:
- This service is designed to help companies gather information about their on-premises environments, such as resource utilization, server configurations, and dependencies. It collects data about the infrastructure, without migrating workloads. It can provide a detailed view of on-premises usage and configurations, which aligns with the company's need to understand the current setup.
- This is a cost-effective and time-efficient solution for the company, as it doesn't require any workload replication.
B) AWS Application Migration Service:
- This service is primarily used for migrating workloads from on-premises to AWS, replicating and converting applications to run on AWS infrastructure. However, in this scenario, the company does not want to replicate workloads yet.
- Therefore, this service is not appropriate for the company's needs, as its focus is on migration, which is n...
Author: Krishna · Last updated Jul 11, 2026
A company wants to allow its employees to work remotely from home. The company's employees use Windows or Linux desktops. The company's employees need access from anywhere and at anytim...
To determine which AWS service best meets the company's requirements, let's break down the problem and evaluate each option carefully.
Requirements:
1. Allow employees to work remotely from home.
2. Employees use Windows or Linux desktops.
3. Access from anywhere, at any time, on any supported device.
Options Analysis:
A) Amazon Workspaces:
- Amazon WorkSpaces is a fully managed Desktop-as-a-Service (DaaS) solution that allows companies to provide secure, persistent desktops to employees. Employees can use Windows or Linux-based virtual desktops and access them from anywhere using various devices (e.g., laptops, tablets, mobile phones).
- Key benefits include centralized management, easy scaling, and security features. The service offers full desktop experiences to users with access from any location, which aligns perfectly with the company's need for remote work.
- Cost considerations are based on the number of WorkSpaces and their configurations, which is flexible to meet the company's needs.
B) Amazon AppStream 2.0:
- Amazon AppStream 2.0 is a fully managed application streaming service, not a full desktop service. It is designed to allow users to access specific applications from anywhere, without requiring them to have the full desktop environment.
- While AppStream 2.0 can provide access to applications on supported devices, it does not offer ful...
Author: Aarav · Last updated Jul 11, 2026
A company wants to test a new application.Which AWS principle will help the company test the applica...
To determine the best AWS principle to help the company test a new application, let’s evaluate the options based on the need for testing flexibility, cost efficiency, and minimal operational overhead.
1. Make long-term commitments in exchange for a cost discount:
- This principle is associated with Reserved Instances (e.g., for EC2) or savings plans that provide a discount in exchange for a long-term commitment (1-3 years). While this is beneficial for stable, predictable workloads, testing a new application generally requires flexibility, as the company may not yet know the app’s resource demands. Committing to a long-term contract before testing the application could lead to unnecessary costs if the application’s requirements change or if it is discontinued after testing.
- Not suitable for testing: Long-term commitments are unnecessary for testing purposes when the focus should be on flexibility and low upfront cost.
2. Scale up and down when needed without any long-term commitments:
- This principle refers to the ability to use AWS services like EC2, Lambda, or others in a pay-as-you-go model, scaling resources based on demand without committing to long-term contracts. It is highly cost-effective for testing scenarios because the company only pays for the resources it uses. During testing, the application might require fluctuating resources, so the ability to scale dynamically is essential. This principle aligns well with the goal of testing without committing to unused resources or long-term costs.
- Ideal for testing: It provides the flexibility and cost control that are critical for running temporary workloads like testing new applications.
3. Have total control over the application infrastructure:
- While having full control over the infrastructure (e.g., via EC2 instances or on-premises solutions) might be important for certain use cases, it is often not required for testing. In fact, maintaining ...
Author: Aria · Last updated Jul 11, 2026
A company plans to launch an ecommerce website that contains many images for a product catalog. The company wants to keep the cost of running the website within a specific budget.Which AWS s...
To determine which AWS service or tool best meets the company's requirement for monitoring the ongoing costs of the ecommerce website, let's carefully analyze each option in the context of the given needs:
Requirements:
1. Monitor ongoing costs of the website.
2. Ensure costs are within a specific budget.
Options Analysis:
A) AWS Cost Explorer:
- AWS Cost Explorer is a service designed specifically to visualize, analyze, and monitor AWS costs and usage. It provides detailed insights into spending patterns, and allows users to track their costs over time. It also offers budgeting features where the company can set cost thresholds and receive alerts if spending exceeds those thresholds.
- Key benefits: This tool is cost-effective for monitoring costs and staying within a budget. It provides detailed cost reports, usage analysis, and allows forecasting based on current and historical usage, making it the most relevant service for this use case.
- Effort and Time: AWS Cost Explorer is easy to set up and requires minimal effort for ongoing use, allowing the company to focus on the business while keeping track of costs automatically.
B) AWS SDKs:
- AWS SDKs (Software Development Kits) are libraries that developers use to interact with AWS services programmatically. While they are essential for building and integrating applications with AWS services, they are not ...
Author: FrostFalcon88 · Last updated Jul 11, 2026
A company has deployed several public applications behind Application Load Balancers. The company wants to improve the performance of the ...
To determine which AWS service best meets the company's requirement for improving the performance of public applications behind Application Load Balancers (ALBs), let's break down each option based on the given needs:
Requirements:
1. Improve the performance of public applications behind Application Load Balancers (ALBs).
2. Focus on performance enhancement.
Options Analysis:
A) AWS Global Accelerator:
- AWS Global Accelerator is a service that improves the availability and performance of applications by routing user traffic through the global AWS network. It optimizes the path to the nearest AWS region, which helps reduce latency and improve performance for users worldwide.
- Key benefits: This service enhances application performance, especially for users in different geographic locations, by providing a faster, more reliable connection to the resources behind the ALBs. It is ideal when there is a need to improve the performance of applications accessed globally.
- Effort and Cost: Global Accelerator is relatively simple to configure and provides significant performance improvements with global reach. Its cost is based on data processing and the number of accelerators used, which is generally a cost-effective solution for global performance improvements.
B) Amazon Connect:
- Amazon Connect is a cloud-based contact center service, designed to manage customer service interactions. While it provides excellent tools for managing customer calls and contact center workloads, it is not related to improving the performance of web applications or services behind ALBs.
- Not relevant to the task of improving application performance. It serves a different use case focused on contact center functionality.
C) Amazon ElastiCache:...
Author: Amira99 · Last updated Jul 11, 2026
A company has an on-premises application. The application has processing times of less than 5 minutes and is invoked only a few times each day. The company wants to move the application to th...
To determine the most cost-effective AWS service for this application, let's evaluate each option based on factors such as cost, scalability, maintenance effort, and the specific requirements provided in the question:
1. Amazon Elastic Container Service (Amazon ECS):
- Amazon ECS is typically used for running containerized applications. While ECS provides a managed environment for running Docker containers, it generally involves overhead related to setting up the container orchestration and scaling configurations. It’s a good choice for microservices architectures or applications requiring high scalability, but since the application only runs a few times per day and has short processing times, this service introduces unnecessary complexity and cost for such a low-volume workload.
2. AWS Lambda:
- AWS Lambda is designed for event-driven, serverless computing. It automatically scales based on demand, with charges based on the actual compute time used, making it ideal for workloads with infrequent or unpredictable invocations and short execution durations (like the described application). The application’s processing time of less than 5 minutes and infrequent execution align well with Lambda’s strengths. Since Lambda charges are based on the time the function runs (in milliseconds) and there are no idle costs when the function is not running, it is highly cost-effective for applications with intermittent usage like this one.
3. Amazon Elastic Kubernetes Service (Amazon EKS):
- Amazon EKS is a managed Kubernetes service, which is typically used for running containerized applications that require orchestration of multiple containers and advanced scaling features. Like ECS, EKS adds operational complexity and cost. Given that the application only runs a...
Author: Zain · Last updated Jul 11, 2026
A company is learning about the perspectives of the AWS Cloud Adoption Framework (AWS CAF).Which perspective of the AW...
To determine which perspective of the AWS Cloud Adoption Framework (AWS CAF) addresses the strategy management capability, let's first look at what each perspective focuses on and analyze the role of strategy management.
A) Business perspective
- Focus: This perspective is centered on aligning business goals with IT strategy and defining how the cloud will benefit the organization in terms of business value. It covers business case creation, planning, and measuring outcomes.
- Strategy Management Capability: The business perspective directly addresses strategy management as it emphasizes creating a clear roadmap for cloud adoption, aligning the business strategy with IT capabilities, and ensuring that cloud initiatives support business goals.
- Reason for Selection: Strategy management is about defining objectives and aligning business decisions with the broader organizational strategy, which is exactly what the Business perspective focuses on. This is the perspective that provides guidance on aligning cloud adoption strategies with overall business strategies and long-term goals.
B) People perspective
- Focus: The people perspective deals with the skills, roles, and cultural changes required to adopt and leverage the cloud effectively. It focuses on training, leadership, and developing a cloud-first mindset across the organization.
- Rejection Reason: While this perspective is essential for fostering the right culture and skill set to support cloud adoption, it does not foc...
Author: ThunderBear · Last updated Jul 11, 2026
A company wants to consolidate its call centers to improve the customer voice and chat experience with call center agents.W...
To answer this question, let's consider each of the options and how they align with the goal of consolidating call centers to improve the customer voice and chat experience with call center agents. The key factors here are integration, communication, and customer experience optimization.
A) Amazon Simple Notification Service (Amazon SNS)
Amazon SNS is a fully managed messaging service that helps to send messages, alerts, and notifications to users across various channels (SMS, email, etc.). While it’s very effective for sending notifications, it does not support the call center functionalities such as handling voice calls, chat, or agent interaction. It’s primarily used for messaging but doesn't provide the needed capabilities to enhance voice or chat-based interactions within a call center.
B) AWS Support Center
AWS Support Center is a portal for managing and interacting with AWS support cases, billing inquiries, and technical assistance. It’s designed for AWS users to engage with AWS support teams, but it is not intended for managing or consolidating call center operations or improving the customer voice/chat experience with agents. Therefore, it doesn't align with the requirements of consolidating call centers or improving customer interactions in real time.
C) Amazon Cognito
Amazon Cognito is a service that provides authentication, authorization, and user management for applications. While it helps manage user identities and authentication, it doesn't o...
Author: Ravi Patel · Last updated Jul 11, 2026
A company needs to provision uninterruptible Amazon EC2 instances, when needed, and pay for compute capacity by the second.Which EC2...
To determine the appropriate EC2 instance purchasing option for the company's requirement, let's analyze each option based on the need to provision uninterruptible instances, with the flexibility to pay for compute capacity by the second:
Requirements:
1. Provision uninterruptible Amazon EC2 instances.
2. Pay for compute capacity by the second.
Options Analysis:
A) Reserved Instances:
- Reserved Instances are a purchasing option where the company commits to using specific EC2 instance types for a term (one or three years). Reserved Instances offer significant savings over On-Demand Instances by committing to a long-term usage plan.
- Not suitable: Reserved Instances provide cost savings but are not uninterruptible, and they don’t provide flexibility in terms of on-demand provisioning or per-second billing. Additionally, Reserved Instances are a commitment, which contradicts the company's need for flexibility.
B) Spot Instances:
- Spot Instances allow the company to bid for unused EC2 capacity at lower prices than On-Demand Instances. However, Spot Instances are interruptible, meaning the instance can be terminated by AWS when the capacity is needed for other purposes.
- Not suitable: The company needs uninterruptible instances, so Spot Instances do not meet this requirement, as they can be terminated with very little notice if AWS...
Author: BlazingPhoenix22 · Last updated Jul 11, 2026
Which AWS service can migrate Amazon EC2 instances from one AWS Region to another?
Let's evaluate the provided AWS services in the context of migrating Amazon EC2 instances from one AWS Region to another, considering factors like services, effort, time, cost, and key functionalities.
A) AWS Application Migration Service
- Purpose: AWS Application Migration Service helps migrate on-premises servers or virtual machines (VMs) to AWS, but it can also facilitate migration of EC2 instances between AWS Regions. It automates much of the process and allows users to replicate their entire application stack, including EC2 instances, from one region to another.
- Relevance: This service is explicitly designed for the migration of EC2 instances and application workloads from one AWS Region to another or from on-premises environments to AWS. It minimizes downtime and automates much of the migration process.
- Strengths: It's a complete migration service for EC2 instances and can work across regions. It also automates most of the heavy lifting involved in the migration process.
- Limitations: While very effective for EC2 migrations, it requires some setup and monitoring, and there may be costs associated with data transfer and replication during the migration.
- Scenario: Ideal when migrating EC2 instances, including their configurations, storage, and networking settings, between AWS Regions.
B) AWS Database Migration Service (AWS DMS)
- Purpose: AWS DMS is designed specifically for database migrations. It facilitates the migration of databases (including schema and data) to AWS, but it is not intended for migrating EC2 instances.
- Relevance: AWS DMS is focused on databases, not EC2 instances, making it unsuitable for the task of migrating EC2 instances between AWS Regions.
- Limitations: It does not migrate EC2 instances, and its primary focus is on database workloads and related data.
- Scenario: Can be used for database migrations, but not for EC2 instances. It might be used in a larger migration strat...
Author: StarryEagle42 · Last updated Jul 11, 2026
A company needs to block SQL injection attacks.Which AWS service or feature provides this functional...
To block SQL injection attacks, a company needs to implement a solution that can inspect incoming web traffic, identify malicious requests, and block them in real-time.
Evaluating each option:
A) AWS WAF (Web Application Firewall)
- Functionality: AWS WAF is a web application firewall that helps protect web applications by filtering and monitoring HTTP and HTTPS requests. It has built-in protections against common attack vectors, including SQL injection, cross-site scripting (XSS), and other OWASP Top 10 vulnerabilities.
- Effort: Configuring AWS WAF requires some effort to define rules for specific attack patterns, including SQL injection, but it provides detailed control over the filtering process.
- Time: Implementation time can vary depending on the complexity of the application and the number of rules to define.
- Cost: AWS WAF is a managed service with pricing based on the number of web requests processed and the rules you deploy. The cost can grow depending on traffic volume and the number of rule sets used.
- Other Key Factors: AWS WAF is specifically designed to protect web applications, and it is fully capable of blocking SQL injection attacks. It is the best fit for this use case.
B) Network ACLs (Access Control Lists)
- Functionality: Network ACLs are a layer of security for controlling traffic in and out of subnets within a VPC. They work at the IP level and do not inspect application-layer protocols (such as HTTP requests), meaning they cannot specifically block SQL injection attacks, which operate at the application layer.
- Effort: Setting up Network ACLs requires some effort, but their primary function is network-level traffic filtering rather than application-level threats.
- Time: The time to configure Network ACLs is typically faster, but their use in this scenario is limited to IP-based control and not application security.
- Cost: No additional cost for Network ACLs beyond general AWS VPC usage.
- Other Key Factors: Network ACLs cannot detect or blo...
Author: Abigail · Last updated Jul 11, 2026
A company wants to run its application on Amazon EC2 instances. The company needs to keep the application on-premises to meet a compliance ...
To meet the compliance requirement of running an application on-premises while leveraging AWS resources, the company needs a solution that allows for the application to run on physical hardware located on-premises, but also integrates with the AWS cloud ecosystem for management and scalability.
Evaluating each option:
A) Dedicated Instances
- Functionality: Dedicated Instances are EC2 instances that run on physical servers dedicated to a single customer, providing isolation from other AWS customers. However, these instances still run in the AWS cloud (data centers). While they provide isolation, they do not fulfill the requirement of keeping the application on-premises.
- Effort: Setting up Dedicated Instances is straightforward and integrates well with the rest of the AWS ecosystem.
- Time: Fast to deploy within the AWS environment.
- Cost: Dedicated Instances cost more than regular EC2 instances due to the isolation of physical hardware.
- Other Key Factors: While they offer physical isolation from other customers, Dedicated Instances are still hosted within AWS data centers and do not meet the requirement of being on-premises.
B) Amazon CloudFront
- Functionality: Amazon CloudFront is a Content Delivery Network (CDN) service that helps deliver content with low latency to users around the world. It is not designed to run applications on physical hardware or on-premises infrastructure.
- Effort: CloudFront is easy to configure for content delivery but does not address the need for on-premises application hosting.
- Time: Fast to deploy, but irrelevant for this use case.
- Cost: CloudFront pricing is based on data transfer and requests, but it does not fulfill the compliance requirement.
- Other Key Factors: CloudFront is a CDN and not a solution for hosting applications on-premises, so it is not suitable for this scenario.
C) AWS Fargate
- Functionality: AWS Fargate is a serverless compu...
Author: Michael · Last updated Jul 11, 2026
A company wants to connect its supported AWS services and VPCs. The company does not want to expose its internal traffic to the publi...
To connect AWS services and Virtual Private Clouds (VPCs) without exposing internal traffic to the public internet, we need a service that ensures secure, private communication between resources within AWS. Let's evaluate each option based on the requirements:
A) Amazon Inspector
Description: Amazon Inspector is a security assessment service that helps identify vulnerabilities in applications or infrastructure by performing automated security assessments.
- Why rejected: While Amazon Inspector is an excellent tool for security auditing, it is not designed to connect AWS services or VPCs. It is focused on identifying security risks and vulnerabilities, not on private communication or networking.
Scenario: Amazon Inspector is ideal for security assessments, such as vulnerability scanning or compliance checks, but does not facilitate connecting VPCs or services.
B) AWS PrivateLink
Description: AWS PrivateLink provides a private connection between VPCs and AWS services, ensuring that traffic does not traverse the public internet. It uses private IP addresses for secure communication between services and VPCs.
- Why selected: AWS PrivateLink is specifically designed to meet the requirement of connecting AWS services and VPCs securely, without exposing traffic to the public internet. It establishes private connections that route traffic internally within the AWS network, ensuring data privacy and security.
Scenario: AWS PrivateLink is ideal for securely connecting AWS services (such as Amazon S3, DynamoDB, or third-party services) to your VPC without going over the internet. It is...
Author: Ryan · Last updated Jul 11, 2026
Which AWS service can manage permissions for AWS resources by using policies?
To manage permissions for AWS resources using policies, it's crucial to choose the service that specifically handles identity and access control. Let’s evaluate each option:
A) Amazon Inspector
- Use Case: Amazon Inspector is an automated security assessment service that helps identify vulnerabilities and compliance issues in applications running on AWS.
- Reason for Rejection: While Amazon Inspector is essential for security assessments, it is not designed for managing permissions or policies for AWS resources. It focuses on identifying potential vulnerabilities, not controlling access.
- Scenario where it’s useful: When performing security assessments or vulnerability management for EC2 instances and other AWS resources.
B) Amazon Detective
- Use Case: Amazon Detective is a security investigation tool that helps analyze, visualize, and investigate potential security issues or suspicious activities in your AWS environment.
- Reason for Rejection: Amazon Detective is primarily used for security analysis and investigation after an incident occurs. It doesn’t manage permissions or access control policies.
- Scenario where it’s useful: For investigating security incidents and understanding the behavior of AWS resources to respond to potential threats, not for managing permissions.
C) AWS Identity and Access Management (IAM)
- Use Case: AWS Identity and Access Management (IAM) is the service responsible for controlling access to AWS resources by defining policies that de...
Author: Leo · Last updated Jul 11, 2026
A company needs to run some of its workload in the AWS Cloud. The company needs to keep some of the workload in its own on-site data center due to co...
To meet the requirements of running some workloads in the AWS Cloud while keeping others on-site due to compliance reasons, we need to focus on a service that provides seamless hybrid cloud capabilities, allowing workloads to span both on-premises data centers and the cloud.
Option A: AWS Config
- Description: AWS Config is a service that enables the monitoring and auditing of the configurations of AWS resources. It tracks configuration changes, compliance with policies, and security best practices.
- Pros: Provides visibility into AWS resource configurations and compliance.
- Cons: AWS Config does not provide a solution for running workloads either on-premises or in the cloud. It’s more of a governance and compliance tool for AWS resources.
- Best Use Case: Ideal for auditing and compliance management of AWS resources.
- Why Rejected: AWS Config does not address the specific requirement of running workloads both in the AWS Cloud and on-site. It is not a solution for hybrid infrastructure.
Option B: AWS Outposts
- Description: AWS Outposts is a hybrid cloud solution that allows you to run AWS infrastructure on-premises, in your own data center, while being fully integrated with AWS Cloud services.
- Pros: AWS Outposts provides a consistent hybrid experience by extending AWS services and infrastructure to on-premises environments. It allows you to run workloads on AWS hardware located on-site, which is ideal for compliance and latency-sensitive workloads.
- Cons: Outposts requires significant investment in AWS hardware and may take some time to set up. It's more complex than purely cloud-based services.
- Best Use Case: Ideal for situations where organizations need to keep some workloads on-premises due to compliance reasons while leveraging AWS Cloud services for other workloads.
- Why Selected: AWS Outposts is the best solution for running workloads both ...
Author: ShadowWolf101 · Last updated Jul 11, 2026
A company wants to deploy an application that stores data in a relational database. The company wants database tasks, such as automated backups and database snapshot...
To meet the requirement of deploying an application that stores data in a relational database with AWS-managed tasks such as automated backups and database snapshots, we need a service that specifically offers managed relational database functionality, including automated maintenance tasks.
Evaluating each option:
A) Amazon DocumentDB
- Functionality: Amazon DocumentDB is a managed NoSQL document database service, designed for workloads that require document data models, such as MongoDB-compatible applications. It is not a relational database and does not meet the requirement for relational data storage.
- Effort: Easy to use for document-based databases, but not suitable for relational database requirements.
- Time: Fast to deploy for document-based workloads, but irrelevant for relational database needs.
- Cost: Amazon DocumentDB pricing is based on the instance and storage used, but it's not a suitable solution for relational database needs.
- Other Key Factors: Since DocumentDB is not a relational database, it does not fulfill the requirement for storing relational data.
B) Amazon RDS (Relational Database Service)
- Functionality: Amazon RDS is a fully managed relational database service that supports multiple relational database engines, including MySQL, PostgreSQL, Oracle, MariaDB, and SQL Server. RDS automates tasks such as backups, patching, database snapshots, and scaling, making it ideal for this use case.
- Effort: Amazon RDS simplifies database management by automating key tasks such as backups and snapshots, reducing operational effort.
- Time: RDS can be quickly deployed, and its automated backup and snapshot features are available out of the box.
- Cost: RDS pricing is based on the database instance type, storage, and data transfer, but offers a managed service that saves effort in terms of database maintenance.
- Other Key Factors: RDS is purpose-built for relational database use cases and automates key database management tasks, making it the perfect choice to meet the company's requirements for relational data storage and management tasks like backups and snapshots.
C) Amazon...
Author: IceDragon2023 · Last updated Jul 11, 2026
A company that operates on-premises servers decides to start a new line of business. The company determines that additional servers are required for the new workloads.Which advantage of cloud computi...
To address the question of which advantage of cloud computing can help a company provision additional infrastructure as quickly as possible, we need to evaluate each option carefully in terms of services, effort, time, cost, and the key factors that affect the ability to provision new infrastructure quickly.
Option A: Benefit from massive economies of scale
- Analysis: Cloud computing providers can offer services at a lower cost due to their large scale. This enables customers to take advantage of infrastructure resources without significant capital investment. However, while economies of scale reduce costs, this benefit does not directly relate to the speed at which infrastructure can be provisioned.
- Services: Provides cost-effective access to resources, but not directly tied to provisioning speed.
- Effort and Time: Economies of scale focus more on cost and efficiency, but don’t necessarily impact the speed of provisioning.
- Cost: It helps lower costs but does not specifically speed up the process of provisioning new infrastructure.
- Best for: Reducing costs when scaling infrastructure but not necessarily for quickly provisioning new resources.
Option B: Increase speed and agility
- Analysis: This is the most relevant advantage in the context of provisioning infrastructure quickly. Cloud computing allows companies to provision new servers, storage, and other resources on demand, dramatically improving the speed and agility with which businesses can respond to new workloads or business opportunities.
- Services: Enables rapid scaling of infrastructure, allowing businesses to spin up new servers and resources as needed within minutes or hours.
- Effort and Time: Minimizes time required to provision infrastructure, supporting quick adaptation to changing business needs.
- Cost: There are costs associated with scaling up, but the ability to quickly provision resources makes this option the best choice for the company’s immediate needs.
- Best for: Scenarios where speed and the ability to quickly provision additional infrastructure are crucial, such as starting a new line of business.
Option C: Trade fixed expense for variable expense
- Analysis: Cloud computing allows companies to pay only for...
Author: Amira99 · Last updated Jul 11, 2026
A company has a mobile application that makes HTTP API calls to an Application Load Balancer (ALB). The ALB routes requests to an AWS Lambda function. Many different versions of the application are in use at any given time, including versions that are in testing by a subset of users. The version of the application is defined in the user-agent header that is sent with all requests to the API.
After a series of recent changes to the API, the company has observed issues with the application. The company needs to gather a metric for each API operation by response code for each version of the application th...
To gather the required metrics for each API operation by response code for each version of the application, the DevOps engineer should take into account how the application logs and metrics can be captured efficiently. Let's evaluate each option based on the goal:
Option A: Modify the Lambda function to write logs to CloudWatch Logs and configure a metric filter
- Explanation: The Lambda function writes log lines containing the API operation name, response code, and version number to CloudWatch Logs. A metric filter is then configured to increment metrics for each API operation, using the response code and version as dimensions.
- Why it works: CloudWatch Logs metric filters can extract specific data from log events and create custom CloudWatch metrics. This would allow precise tracking of API operations, response codes, and versions, making it easy to monitor usage.
- Why other options are rejected:
- This option is direct and clear for the given requirements, using simple log parsing with metric filtering for granularity.
- Easy to implement as CloudWatch Logs already integrates well with Lambda functions.
Option B: Modify the Lambda function to write logs to CloudWatch Logs and configure CloudWatch Logs Insights query
- Explanation: Similar to option A, the Lambda function writes logs to CloudWatch Logs. However, this option requires configuring CloudWatch Logs Insights queries to aggregate metrics, which could be more complex and less direct for real-time metrics collection.
- Why it's not optimal: While CloudWatch Logs Insights is powerful for complex querying and analysis, using it for real-time metric collection requires more effort compared to direct metric filters. The use of Insights queries can be m...
Author: IronLion88 · Last updated Jul 20, 2026
A company provides an application to customers. The application has an Amazon API Gateway REST API that invokes an AWS Lambda function. On initialization, the Lambda function loads a large amount of data from an Amazon DynamoDB table. The data load process results in long cold-start times of 8-10 seconds. The DynamoDB table has DynamoDB Accelerator (DAX) configured.
Customers report that the application intermittently takes a long time to respond to requests. The application receives thousands of requests throughout the day. In the middle of the day, the application experiences 10 times more requests than at...
To reduce the latency of the Lambda function and meet the application's requirements, let's evaluate each of the options:
Option A: Configure provisioned concurrency on the Lambda function with a concurrency value of 1. Delete the DAX cluster for the DynamoDB table.
- Explanation: Provisioned concurrency ensures that a specified number of Lambda instances are always pre-warmed and ready to handle requests, which reduces cold-start times. However, deleting the DAX cluster might worsen performance. DAX is designed to reduce the latency of DynamoDB queries, so removing it would likely increase response times, especially if the data load is large.
- Why it's not optimal: Removing DAX would lead to slower access to DynamoDB, which contradicts the goal of reducing latency. The provisioned concurrency value of 1 would only handle one request at a time and might not scale well with thousands of requests or with fluctuating demand.
Option B: Configure reserved concurrency on the Lambda function with a concurrency value of 0.
- Explanation: Reserved concurrency ensures that a specified number of Lambda instances are always available, but setting it to 0 means that no instances would be available to handle requests.
- Why it's not optimal: A concurrency value of 0 would prevent the Lambda function from handling any requests, which would cause failures or timeouts. This option does not meet the goal of reducing latency or ensuring availability.
Option C: Configure provisioned concurrency on the Lambda function. Configure AWS Application Auto Scaling on the Lambda function with provisioned concurrency values set to a minimum of 1 and a maximum of 100.
- Explanation:...
Author: Ava · Last updated Jul 20, 2026
A company is adopting AWS CodeDeploy to automate its application deployments for a Java-Apache Tomcat application with an Apache Webserver. The development team started with a proof of concept, created a deployment group for a developer environment, and performed functional tests within the application. After completion, the team will create additional deployment groups for staging and production.
The current log level is configured within the Apache settings, but the team wants to change this configuration dynamically when the deployment occurs, so that they can set different log level c...
To meet the requirement of dynamically setting the log level configuration depending on the deployment group without having a different application revision for each group, we need a solution that is simple to implement, flexible, and minimizes management overhead. Let's evaluate each option:
Option A: Tag the Amazon EC2 instances depending on the deployment group. Then place a script into the application revision that calls the metadata service and the EC2 API to identify which deployment group the instance is part of. Use this information to configure the log level settings. Reference the script as part of the AfterInstall lifecycle hook in the appspec.yml file.
- Explanation: Tagging EC2 instances based on the deployment group can be a good way to categorize and identify instances for specific environments. However, calling the metadata service and EC2 API from within the application revision can introduce unnecessary complexity. This solution would also require additional API calls and management of tags, which adds overhead.
- Why it's not optimal: Although this method could work, it adds complexity by requiring EC2 metadata queries, API calls, and managing instance tags. This isn't the most streamlined or efficient approach.
Option B: Create a script that uses the CodeDeploy environment variable `DEPLOYMENT_GROUP_NAME` to identify which deployment group the instance is part of. Use this information to configure the log level settings. Reference this script as part of the BeforeInstall lifecycle hook in the appspec.yml file.
- Explanation: CodeDeploy automatically sets environment variables such as `DEPLOYMENT_GROUP_NAME` to identify which deployment group the instance is part of. Using this environment variable in a script is a simple and straightforward way to dynamically configure the log level based on the deployment group. This approach avoids additional complexity.
- Why it works: This solution requires minimal management overhead, is dynamic (no need to modify the revision for each environment), and uses built-in CodeDeploy variables, which simplifies the setup. By referencing the script in the `BeforeInstall` lifecycle hook, you can modify configurations before the application is installed.
Option C: Create a CodeDeploy custom environment variable for each environme...
Author: Manish · Last updated Jul 20, 2026
A company requires its developers to tag all Amazon Elastic Block Store (Amazon EBS) volumes in an account to indicate a desired backup frequency. This requirement Includes EBS volumes that do not require backups. The company uses custom tags named Backup_Frequency that have values of none, dally, or weekly that correspond to the desired backup frequency. An audit finds that developers are occasionally not tagging the EBS volumes.
A DevOps engineer needs to ensu...
To ensure that all Amazon Elastic Block Store (EBS) volumes always have the `Backup_Frequency` tag, and that this tag is applied according to company requirements (i.e., with values of "none", "daily", or "weekly"), we need a solution that detects and automatically remediates missing or incorrect tags. Let's evaluate each option:
Option A: Set up AWS Config in the account. Create a custom rule that returns a compliance failure for all Amazon EC2 resources that do not have a Backup_Frequency tag applied. Configure a remediation action that uses a custom AWS Systems Manager Automation runbook to apply the Backup_Frequency tag with a value of weekly.
- Explanation: This option uses AWS Config to monitor compliance for EC2 resources, which includes EBS volumes. A custom rule can detect whether the `Backup_Frequency` tag is missing. If the rule finds a compliance failure, it triggers an AWS Systems Manager Automation runbook to apply the tag with a value of "weekly".
- Why it's not optimal: While this approach would work to ensure that EBS volumes are tagged, the custom rule would require manual configuration of the rule logic, which can introduce complexity. Additionally, a custom rule might not be the most efficient or necessary solution for this specific use case. AWS Config managed rules offer simpler and more reliable solutions in this context.
Option B: Set up AWS Config in the account. Use a managed rule that returns a compliance failure for EC2::Volume resources that do not have a Backup_Frequency tag applied. Configure a remediation action that uses a custom AWS Systems Manager Automation runbook to apply the Backup_Frequency tag with a value of weekly.
- Explanation: AWS Config offers managed rules that can be applied to monitor the state of resources, such as EBS volumes. The managed rule `ec2-volume-no-backup-frequency-tag` checks for missing `Backup_Frequency` tags on EBS volumes. If any volumes are missing the tag, AWS Config can trigger a remediation action via an AWS Systems Manager Automation runbook to automatically apply the tag with the "weekly" value.
- Why it works: This option is straightforward and leverages the power of AWS Config managed rules, which are easier to configure and maintain than custom rules. It directly addresses the issue of ensuring that EBS...
Author: Harper · Last updated Jul 20, 2026
A company is using an Amazon Aurora cluster as the data store for its application. The Aurora cluster is configured with a single DB instance. The application performs read and write operations on the database by using the cluster's instance endpoint.
The company has scheduled an update to be applied to the cluster during an upcoming maintenance window. The clu...
To ensure that the Aurora cluster remains available with the least possible interruption during the upcoming maintenance window, let's evaluate each option and its relevance to the scenario:
Option A: Add a reader instance to the Aurora cluster. Update the application to use the Aurora cluster endpoint for write operations. Update the Aurora cluster's reader endpoint for reads.
- Explanation: Adding a reader instance improves the availability of read operations by offloading them to the reader instance. The `cluster endpoint` handles write operations, and the `reader endpoint` handles read operations.
- Why it's not optimal: Although this option enhances the availability of read operations, it does not minimize downtime during the maintenance window. The application will still be dependent on a single instance for write operations, so any disruption to the single DB instance during maintenance will cause interruption.
Option B: Add a reader instance to the Aurora cluster. Create a custom ANY endpoint for the cluster. Update the application to use the Aurora cluster's custom ANY endpoint for read and write operations.
- Explanation: Adding a reader instance and using a custom `ANY` endpoint provides a unified endpoint for both read and write operations. Aurora’s custom `ANY` endpoint will route the traffic to either the writer or reader instance based on availability.
- Why it works: This option can provide better availability during maintenance, as the `ANY` endpoint automatically routes read and write traffic to the available instance (whether it's the writer or the reader instance). If the writer instance becomes unavailable during maintenance, the `ANY` endpoint can still route traffic to the reader instance. Once the maintenance is completed, the writer instance will resume, minimizing the impact of downtime.
Option C: Turn on the Multi-AZ option on the Aurora cluster. Update the application to use the Aurora cluster endpoint for write operations. Update the Aurora cluster's reader endpoint for reads.
- Explanation: Enabling Multi-AZ on Aurora provides high availability by automatically...
Author: John · Last updated Jul 20, 2026
A company must encrypt all AMIs that the company shares across accounts. A DevOps engineer has access to a source account where an unencrypted custom AMI has been built. The DevOps engineer also has access to a target account where an Amazon EC2 Auto Scaling group will launch EC2 instances from the AMI. The DevOps engineer must share the AMI with the target account.
The company has create...
Let's break down each option in the context of the scenario:
Option A: In the source account, copy the unencrypted AMI to an encrypted AMI. Specify the KMS key in the copy action.
- Explanation: This is a valid step to ensure the AMI is encrypted using the specific AWS KMS key. Since the company has already created an AWS KMS key in the source account, this step will ensure that the AMI is encrypted before sharing it with the target account.
- Why selected: It directly solves the problem of ensuring that the AMI is encrypted when shared across accounts.
- Scenario: This is the correct approach when you need to ensure that the AMI is encrypted before sharing it across accounts.
Option B: In the source account, copy the unencrypted AMI to an encrypted AMI. Specify the default Amazon Elastic Block Store (Amazon EBS) encryption key in the copy action.
- Explanation: This option uses the default EBS encryption key, which would not use the AWS KMS key that the company has specifically created. Therefore, it does not meet the requirement of using the specific KMS key that was created for encryption.
- Why rejected: This does not ensure that the correct AWS KMS key is used, which is a requirement in the scenario.
Option C: In the source account, create a KMS grant that delegates permissions to the Auto Scaling group service-linked role in the target account.
- Explanation: KMS grants allow specific permissions to be delegated to a principal, but it doesn’t directly address the requirement of ensuring that the AMI is encrypted before sharing. Creating a KMS grant is part of the process, but it's not the first step.
- Why rejected: While this is a necessary action in some cases, it doesn't address the immediate need to encrypt the AMI before sharing it.
Option D: In the source account, modify the key policy to give the target account permissions to create a grant. In the target account, create a KM...
Author: Ryan · Last updated Jul 20, 2026
A company uses AWS CodePipeline pipelines to automate releases of its application A typical pipeline consists of three stages build, test, and deployment. The company has been using a separate AWS CodeBuild project to run scripts for each stage. However, the company now wants to use AWS CodeDeploy to handle the deployment stage of the pipelines.
The company has packaged the application as an RPM package and must deploy the application to a fleet of Amazon EC2 ...
Let's break down the options and understand why each might be selected or rejected based on the given requirements:
Option A: Create a new version of the common AMI with the CodeDeploy agent installed. Update the IAM role of the EC2 instances to allow access to CodeDeploy.
- Explanation: This step ensures that the EC2 instances have the CodeDeploy agent installed and are able to communicate with the CodeDeploy service. Updating the IAM role is necessary to grant permissions to the CodeDeploy service to interact with the instances.
- Why selected: This is a required step because EC2 instances need the CodeDeploy agent to facilitate deployments, and the IAM role needs to be updated to allow the necessary permissions. However, this step alone does not complete the deployment process; further configuration is needed.
- Scenario: This is applicable when you want to ensure your EC2 instances have the required agent and permissions to interact with CodeDeploy.
Option B: Create a new version of the common AMI with the CodeDeploy agent installed. Create an AppSpec file that contains application deployment scripts and grants access to CodeDeploy.
- Explanation: The creation of the new AMI version with the CodeDeploy agent is necessary, and the AppSpec file is crucial to define the deployment steps for CodeDeploy. The AppSpec file is necessary for the deployment process but is just one part of the overall deployment configuration.
- Why selected: This is necessary for deploying the application, but only part of the overall setup. The AppSpec file defines the deployment lifecycle hooks and scripts for CodeDeploy, which is key to executing the deployment actions.
- Scenario: This option is useful when you need to include custom deployment scripts along with installing the CodeDeploy agent on instances.
Option C: Create an application in CodeDeploy. Configure an in-place deployment type. Specify the Auto Scaling group as the deployment target. Add a step to the CodePipeline pipeline to use EC2 Image Builder to create a new AMI. Configure CodeDeploy to deploy the newly created AMI.
- Explanation: EC2 Image Builder is used to automate AMI creation, which is helpful but is not a requirement for using CodeDeploy for deploying RPM packages. In this case, the goal is to deploy an RPM package to EC2 instances rather than creating new AMIs via Image Build...
Author: Ming88 · Last updated Jul 20, 2026
A company's security team requires that all external Application Load Balancers (ALBs) and Amazon API Gateway APIs are associated with AWS WAF web ACLs. The company has hundreds of AWS accounts, all of which are included in a single organization in AWS Organizations. The company has configured AWS Config for the organization. During an audit, the company finds some externall...
Let's go through each option to identify the best choices based on the scenario and the requirement for compliance with the security team's rules.
Option A: Delegate AWS Firewall Manager to a security account.
- Explanation: AWS Firewall Manager is the ideal tool for managing security rules across multiple accounts in an AWS Organization. By delegating AWS Firewall Manager to a security account, it can centrally manage the configuration and enforcement of WAF web ACLs across the entire organization.
- Why selected: AWS Firewall Manager allows centralized control over security policies such as attaching WAF web ACLs to ALBs and API Gateway APIs, which aligns with the company's security requirement. It simplifies management and enforcement across all accounts in the organization.
- Scenario: This is a good choice when you need to implement a solution that automates the attachment of WAF web ACLs for multiple accounts in an organization.
Option B: Delegate Amazon GuardDuty to a security account.
- Explanation: GuardDuty is an intelligent threat detection service that helps identify malicious activity in an AWS environment. However, GuardDuty focuses on detecting threats, not on ensuring compliance with specific security configurations like attaching WAF web ACLs.
- Why rejected: GuardDuty does not provide functionality to enforce security rules or configurations like attaching WAF web ACLs. It only alerts about security threats, so it doesn't address the company's requirement to ensure WAF web ACLs are attached to ALBs and API Gateway APIs.
- Scenario: GuardDuty is useful for threat detection but not for compliance enforcement in this specific case.
Option C: Create an AWS Firewall Manager policy to attach AWS WAF web ACLs to any newly created ALBs and API Gateway APIs.
- Explanation: This is an appropriate action to enforce the security requirement. AWS Firewall Manager policies can automatically ensure that WAF web ACLs are attached to any newly created ALBs and API Gateway APIs, which meets the requirement to prevent future violations.
- Why selected: By using Firewall Manager policies, the company can automat...
Author: Krishna · Last updated Jul 20, 2026
A company uses AWS Key Management Service (AWS KMS) keys and manual key rotation to meet regulatory compliance requirements. The security team wants to be notified when any key...
Let's go through each option to determine the best solution based on the scenario:
Option A: Configure AWS KMS to publish to an Amazon Simple Notification Service (Amazon SNS) topic when keys are more than 90 days old.
- Explanation: AWS KMS does not natively have a built-in feature that can automatically publish notifications about key rotation or age directly to an SNS topic. While KMS manages key rotations, it does not send notifications when keys haven’t been rotated after a certain time period like 90 days.
- Why rejected: AWS KMS does not support this direct integration for tracking and notifying based on the key's age or rotation status, so this option is not feasible.
- Scenario: This could be useful if KMS had built-in notifications for key rotation, but it does not.
Option B: Configure an Amazon EventBridge event to launch an AWS Lambda function to call the AWS Trusted Advisor API and publish to an Amazon Simple Notification Service (Amazon SNS) topic.
- Explanation: This option involves setting up an EventBridge event to trigger a Lambda function that calls AWS Trusted Advisor. However, AWS Trusted Advisor does not specifically monitor the rotation of KMS keys. Trusted Advisor primarily focuses on best practices and security checks, but it does not directly monitor KMS key rotation.
- Why rejected: Trusted Advisor is not the appropriate service for monitoring KMS key rotation. Additionally, setting up a Lambda function to query Trusted Advisor would add unnecessary complexity and would not solve the requirement.
- Scenario: This would work for other Trusted Advisor checks but not for the specific monitoring of KMS key rotation.
Option C: Develop an AWS Config custom rule that publishes to an Amazon Simple Notification Service (Amazon SNS) topic when keys are more than 90 days old.
- Explanation: AWS Config allows you to monitor resources and their configurations...
Author: NightmareDragon2025 · Last updated Jul 20, 2026
A security review has identified that an AWS CodeBuild project is downloading a database population script from an Amazon S3 bucket using an unauthenticated request. The security team does not allow unauthenticated reque...
Let's evaluate each option based on the goal of correcting the unauthenticated access issue to the S3 bucket, while ensuring the most secure solution.
Option A: Add the bucket name to the AllowedBuckets section of the CodeBuild project settings. Update the build spec to use the AWS CLI to download the database population script.
- Explanation: This option allows specifying allowed buckets in the CodeBuild settings, but it doesn’t directly address the issue of unauthenticated access. The security concern is that the request is currently unauthenticated, which could lead to unauthorized access.
- Why rejected: While this approach might restrict which buckets can be accessed, it still does not resolve the fundamental issue of unauthenticated access to the S3 bucket. Using the AWS CLI is a good choice, but this option is incomplete in terms of securing the bucket access properly.
- Scenario: This could help limit access to approved buckets, but the unauthenticated access problem is not fully resolved.
Option B: Modify the S3 bucket settings to enable HTTPS basic authentication and specify a token. Update the build spec to use cURL to pass the token and download the database population script.
- Explanation: Enabling HTTPS basic authentication and using a token with cURL is not an ideal approach for securing access to S3. S3 doesn't natively support basic authentication, and using tokens directly in this manner would introduce complexity and potential security risks.
- Why rejected: This method is not a recommended practice for securing S3 bucket access. AWS provides more secure, native methods such as IAM roles and policies for authentication, and using cURL for token-based authentication isn't the best option.
- Scenario: This could work for some external APIs, but it's not ideal for S3, which is designed to use IAM policies and credentials.
Option C: Remove unauthenticated access from the S3 bucket with a bucket policy. Modify the service role for the CodeBuild project to include Amazon S3 access. Use the AWS CLI to download the database population script.
- Explanat...
Author: Emma · Last updated Jul 20, 2026
An ecommerce company has chosen AWS to host its new platform. The company's DevOps team has started building an AWS Control Tower landing zone. The DevOps team has set the identity store within AWS IAM Identity Center (AWS Single Sign-On) to external identity provider (IdP) and has configured SAML 2.0.
The DevOps team wants a robust permission model that applies the principle of leas...
To meet the requirements for a robust permission model that applies the principle of least privilege and allows the DevOps team to manage only their own resources, we need to carefully consider the options based on factors such as identity federation, role-based access control (RBAC), permissions scoping, and user groups.
Let's go through the options:
A) Create IAM policies that include the required permissions. Include the aws:PrincipalTag condition key.
- Explanation: Using IAM policies with the `aws:PrincipalTag` condition key is a good approach to apply resource-level restrictions based on user-specific tags. By using tags, the DevOps team can apply the principle of least privilege, ensuring that each user can only manage resources that are tagged specifically for their use.
- Reasoning: This option is valid because it allows fine-grained control over what each user or group can do with AWS resources based on their tags. The team can enforce this by associating specific tags with their resources and restricting access based on those tags.
- Conclusion: This option is a valid choice.
B) Create permission sets. Attach an inline policy that includes the required permissions and uses the aws:PrincipalTag condition key to scope the permissions.
- Explanation: Permission sets in AWS IAM Identity Center define the permissions granted to users when they are assigned to an account or role. Attaching an inline policy that uses the `aws:PrincipalTag` condition key allows scoping access to resources based on tags, just like in Option A. This combination of using permission sets with fine-grained tagging controls aligns with least privilege.
- Reasoning: This option allows for more structured permission management than directly managing IAM policies and ensures the right set of permissions are granted to users. It scales well with larger teams and organizations.
- Conclusion: This option is a valid choice.
C) Create a group in the IdP. Place users in the group. Assign the group to accounts and the permission sets in IAM Identity Center.
- Explanation: Creating a group in the Identity Provider (IdP) and assigning users to that group is a typical approach to organize users. By assigning groups to accounts and permission sets, the DevOps team can manage permissions at a higher level of abstraction.
- Reasoning: This approach works well for role-based access control and allows the team to manage permissions effectively. However, it doesn't specifically address the fine-grained control based on resource tags, which is a key requirement in this case.
- Conclusion: This option is a valid choice but doesn't meet the fine-grained permission model for managing resources based on tags.
D) Create a group in the IdP. ...
Author: Amelia · Last updated Jul 20, 2026
An ecommerce company is receiving reports that its order history page is experiencing delays in reflecting the processing status of orders. The order processing system consists of an AWS Lambda function that uses reserved concurrency. The Lambda function processes order messages from an Amazon Simple Queue Service (Amazon SQS) queue and inserts processed orders into an Amazon Dynam...
In this scenario, the main issue is that the order history page is experiencing delays in reflecting the processing status of orders. The processing system involves an AWS Lambda function that consumes messages from an Amazon SQS queue and writes to an Amazon DynamoDB table. The issue is likely due to either Lambda's ability to process messages in a timely manner or DynamoDB’s capacity to handle the writes efficiently.
Let's break down the options:
A) Check the ApproximateAgeOfOldestMessage metric for the SQS queue. Increase the Lambda function concurrency limit.
- Explanation: The `ApproximateAgeOfOldestMessage` metric in SQS indicates how long the oldest message in the queue has been waiting. If the messages are in the queue for a long time, it could mean Lambda is not processing messages quickly enough. Increasing the Lambda concurrency limit allows more instances of the function to process messages in parallel, helping reduce the time spent waiting in the queue.
- Reasoning: If there are too many messages in the queue or the Lambda function is being throttled, increasing concurrency would help process the backlog of messages faster.
- Conclusion: This is a good option to resolve delays caused by Lambda not processing messages quickly enough.
B) Check the ApproximateAgeOfOldestMessage metric for the SQS queue. Configure a redrive policy on the SQS queue.
- Explanation: A redrive policy is used to handle messages that fail to be processed. If a message fails after several retries, it is moved to a dead-letter queue. While this can help in failure scenarios, it does not directly address the issue of delays in processing messages in the primary queue. The problem described seems to be more about processing speed, not failures.
- Reasoning: The issue here is not that messages are failing, but that they are not being processed in a timely manner. A redrive policy is not the best solution for this delay issue.
- Conclusion: This option doesn't directly solve the problem of processing delays.
C) Check the NumberOfMessagesSent metric for the SQS queue. Increase the SQS queue visibility timeout.
- Explanation: The `NumberOfMessagesSent` metric tells you how many messages are being sent to the queue. The visibility timeout determines how long a message remains hidden from other consumers once it’s being processed. If the Lambda function takes longer than expected, increasing the visibility timeout would help prevent the message from being picked up by another Lambda instan...
Author: CrimsonViperX · Last updated Jul 20, 2026
A company has a single AWS account that runs hundreds of Amazon EC2 instances in a single AWS Region. New EC2 instances are launched and terminated each hour in the account. The account also includes existing EC2 instances that have been running for longer than a week.
The company's security policy requires all running EC2 instances to use an EC2 instance profile. If an EC2 instance does not have an instance profile attached, the EC2 instance must use a default instance profile that has no IAM permissions assigned.
A DevOps engineer reviews the account and discovers EC2 instances that are running without a...
To ensure that an EC2 instance always has an instance profile attached (either a custom one or the default instance profile with no IAM permissions), we need to establish a solution that detects EC2 instances without an instance profile and applies the necessary profile in both existing and future instances.
Let's break down the options:
A) Configure an Amazon EventBridge rule that reacts to EC2 RunInstances API calls. Configure the rule to invoke an AWS Lambda function to attach the default instance profile to the EC2 instances.
- Explanation: Amazon EventBridge can capture EC2 RunInstances API calls, which are invoked when new EC2 instances are launched. By configuring a rule that triggers on these calls, we can invoke a Lambda function to attach the instance profile to newly launched instances.
- Reasoning: This solution would work for newly launched EC2 instances, but it does not address existing EC2 instances that are already running without an instance profile. This approach is incomplete because it doesn't handle the current state of instances.
- Conclusion: While this would solve the issue for new instances, it doesn't handle instances that are already running without a profile.
B) Configure the ec2-instance-profile-attached AWS Config managed rule with a trigger type of configuration changes. Configure an automatic remediation action that invokes an AWS Systems Manager Automation runbook to attach the default instance profile to the EC2 instances.
- Explanation: The `ec2-instance-profile-attached` AWS Config managed rule checks whether EC2 instances have an instance profile attached. By setting the trigger to configuration changes, this rule will detect any EC2 instances that don't have an instance profile and can trigger automatic remediation actions. The remediation action can invoke an AWS Systems Manager Automation runbook, which could attach the default instance profile to those EC2 instances.
- Reasoning: This solution handles both existing and future EC2 instances. It checks the configuration of all EC2 instances and automatically remediates any that do not have an instance profile. This approach is comprehensive and fully addresses the security requirement.
- Conclusion: This is the most complete and automated solution to ensure...
Author: Kai · Last updated Jul 20, 2026
A DevOps engineer is building a continuous deployment pipeline for a serverless application that uses AWS Lambda functions. The company wants to reduce the customer impact of an unsuccessful deployment. The company als...
To address the requirements of reducing customer impact in case of an unsuccessful deployment while monitoring for issues, the solution must ensure gradual traffic shifting during deployment to limit potential negative impacts and have robust monitoring in place to detect issues.
Let's go through the options:
A) Use an AWS Serverless Application Model (AWS SAM) template to define the serverless application. Use AWS CodeDeploy to deploy the Lambda functions with the Canary10Percent15Minutes Deployment Preference Type. Use Amazon CloudWatch alarms to monitor the health of the functions.
- Explanation: This approach uses AWS SAM to define the application and AWS CodeDeploy with a Canary deployment strategy (10% for 15 minutes) for Lambda functions. The Canary deployment type gradually shifts a small portion of traffic to the new version of the function (10% in the first stage), then waits for a defined period (15 minutes) to ensure that the function behaves as expected. If there is an issue, it only affects a small portion of the customers. CloudWatch alarms are used to monitor the health of the Lambda functions during the deployment.
- Reasoning: The Canary deployment type ensures that only a fraction of traffic is affected initially, reducing the potential customer impact in case of a failure. Monitoring with CloudWatch alarms allows early detection of issues. This solution meets the requirements well.
- Conclusion: This option is appropriate for minimizing customer impact and ensuring monitoring for issues.
B) Use AWS CloudFormation to publish a new stack update, and include Amazon CloudWatch alarms on all resources. Set up an AWS CodePipeline approval action for a developer to verify and approve the AWS CloudFormation change set.
- Explanation: This option uses AWS CloudFormation to manage the stack updates and includes an approval action in AWS CodePipeline to require developer verification before proceeding. CloudWatch alarms are included to monitor all resources.
- Reasoning: While the approval step adds a manual verification process, it does not inherently reduce customer impact during the deployment. It introduces a manual gate, which can slow down deployments and does not allow for gradual traffic shifting. The solution lacks a strategy to minimize the impact of potential failures during the deployment itself.
- Conclusion: This option introduces a manual approval step but does not directly address reducing customer impact during the deployment or minimizing failures in real-time.
C) Use AWS CloudFormation to publish a new...
Author: Chloe · Last updated Jul 20, 2026
To run an application, a DevOps engineer launches an Amazon EC2 instance with public IP addresses in a public subnet. A user data script obtains the application artifacts and installs them on the instances upon launch. A change to the security classification of the application now requires the instances to run with no access to the internet. While the instances launch successfully and...
To comply with the rule that the instances should run without internet access while still successfully installing the application, we need a solution that allows the instances to retrieve the necessary application artifacts without requiring internet access directly.
Let's analyze the options:
A) Launch the instances in a public subnet with Elastic IP addresses attached. Once the application is installed and running, run a script to disassociate the Elastic IP addresses afterwards.
- Explanation: This option suggests launching the instances in a public subnet with Elastic IP addresses (EIP) attached initially. The idea is to allow the instances to access the internet temporarily to download and install the application. Afterward, the EIP is disassociated to prevent further internet access.
- Reasoning: While this approach works, it does not fully comply with the requirement that the instances should not have internet access. The instances would still have access to the internet during the installation phase, which contradicts the rule. The solution also requires manual intervention to disassociate the EIP, which is not ideal for an automated or consistent process.
- Conclusion: This option is not suitable because it violates the rule of having no internet access.
B) Set up a NAT gateway. Deploy the EC2 instances to a private subnet. Update the private subnet's route table to use the NAT gateway as the default route.
- Explanation: This option suggests deploying the EC2 instances to a private subnet with a NAT gateway for outbound internet access. The NAT gateway provides internet access for instances in the private subnet while keeping the instances themselves inaccessible from the internet.
- Reasoning: While this solution provides a controlled way to access the internet (via the NAT gateway), it still allows internet access, which violates the requirement that instances should have no internet access. This solution allows external communication, so it is not fully compliant with the new security classification.
- Conclusion: This option doesn't meet the requirement to prevent internet access.
C) Publish the application artifacts to an Amazon S3 bucket a...
Author: Noah Williams · Last updated Jul 20, 2026
A development team is using AWS CodeCommit to version control application code and AWS CodePipeline to orchestrate software deployments. The team has decided to use a remote main branch as the trigger for the pipeline to integrate code changes. A developer has pushed code changes to the CodeCommit repository, but noti...
Let's break down each of the options based on key factors:
A) Check that an Amazon EventBridge rule has been created for the main branch to trigger the pipeline.
- Reasoning: AWS CodePipeline uses Amazon EventBridge (formerly CloudWatch Events) to detect changes in the CodeCommit repository and trigger pipeline executions. If the EventBridge rule isn’t set up correctly, it won’t trigger the pipeline upon a change to the repository. This would be a direct cause of the pipeline not reacting after code is pushed to CodeCommit.
- Why Selected: This is the most probable cause because the pipeline might not have been properly connected to the event that triggers it from the main branch in CodeCommit.
- Rejection of other options:
- This option is focused on the event rule, which is the event-driven trigger mechanism for CodePipeline.
B) Check that the CodePipeline service role has permission to access the CodeCommit repository.
- Reasoning: This is a valid consideration in case the pipeline did start but faced permission issues while interacting with CodeCommit. However, the developer is noticing that the pipeline isn’t reacting at all, indicating that the issue might lie with the trigger mechanism itself rather than permissions related to pipeline actions.
- Why Rejected: Since the issue seems to be that the pipeline isn’t triggered, the ...
Author: ElectricLionX · Last updated Jul 20, 2026
A company's developers use Amazon EC2 instances as remote workstations. The company is concerned that users can create or modify EC2 security groups to allow unrestricted inbound access.
A DevOps engineer needs to develop a solution to detect when users create unrestricted security group rules. The solution must detect changes to security group rules in near real time, remove unrestricted rules, and send email notifications to the security team. The DevOps engineer has created an AWS Lambda function that checks for...
Let's go through each of the options and analyze their suitability for detecting, removing unrestricted security group rules, and notifying the security team:
A) Configure the Lambda function to be invoked by the SNS topic. Create an AWS CloudTrail subscription for the SNS topic. Configure a subscription filter for security group modification events.
- Reasoning: AWS CloudTrail logs API activity across your AWS infrastructure, but it doesn't directly trigger actions based on events like SNS topics. While you could use CloudTrail logs to detect security group modifications, using SNS as an intermediary introduces unnecessary complexity. CloudTrail can log security group changes, but an EventBridge rule would be a more effective way to trigger Lambda functions in near real time.
- Why Rejected: This option complicates the workflow unnecessarily by introducing CloudTrail and SNS in the middle, while EventBridge can directly detect and respond to security group changes.
B) Create an Amazon EventBridge scheduled rule to invoke the Lambda function. Define a schedule pattern that runs the Lambda function every hour.
- Reasoning: This option would run the Lambda function on a schedule (e.g., hourly), which is not ideal for real-time detection of changes. Since the goal is to detect changes to security groups in near real time, a scheduled rule would introduce unnecessary delay in detection and response.
- Why Rejected: This option doesn't meet the near real-time detection requirement, as it only checks for changes periodically (every hour).
C) Create an Amazon EventBridge event rule that has the default event bus as the source. Define the rule’s event pattern to match EC2 security gr...
Author: Lucas · Last updated Jul 20, 2026
A DevOps engineer is creating an AWS CloudFormation template to deploy a web service. The web service will run on Amazon EC2 instances in a private subnet behind an Application Load Balancer (ALB). The DevOps engineer must ensure that the service can accept requests from clients that have IPv6 a...
Let's go through each option step by step, considering key factors like IPv6 support, the use of an Application Load Balancer (ALB), and the requirements to allow IPv6 clients to access the web service.
A) Add an IPv6 CIDR block to the VPC and the private subnet for the EC2 instances. Create route table entries for the IPv6 network, use EC2 instance types that support IPv6, and assign IPv6 addresses to each EC2 instance.
- Reasoning: This option focuses on adding IPv6 to the VPC and private subnet, and assigning IPv6 addresses to EC2 instances. However, this only ensures that the EC2 instances have IPv6 addresses; it does not address the ALB, which needs to be configured to handle IPv6 traffic.
- Why Rejected: The Application Load Balancer (ALB) itself needs to be configured for IPv6 support to accept requests from IPv6 clients. This option does not account for the ALB, making it incomplete for the use case of enabling IPv6 client access to the web service via the ALB.
B) Assign each EC2 instance an IPv6 Elastic IP address. Create a target group, and add the EC2 instances as targets. Create a listener on port 443 of the ALB, and associate the target group with the ALB.
- Reasoning: This option involves assigning IPv6 Elastic IPs directly to the EC2 instances. While this would allow the instances to have IPv6 addresses, it bypasses the use of the ALB entirely, meaning clients would connect directly to EC2 instances, which is not optimal for load balancing, scaling, and high availability. The ALB is meant to distribute traffic to multiple EC2 instances, so directly assigning IPs to instances would eliminate this benefit.
- Why Rejected: This approach does not take full advantage of the ALB, which is central to the requirement. It does not provide an efficient, scalable, and secure architecture as the traf...
Author: Scarlett · Last updated Jul 20, 2026
A company uses AWS Organizations and AWS Control Tower to manage all the company's AWS accounts. The company uses the Enterprise Support plan.
A DevOps engineer is using Account Factory for Terraform (AFT) to provision new accounts. When new accounts are provisioned, the DevOps engineer notices that the support plan for the new accounts is set to the Basic Support plan....
Let’s walk through each option and analyze the best solution for provisioning new accounts with the Enterprise Support plan.
A) Use an AWS Config conformance pack to deploy the account-part-of-organizations AWS Config rule and to automatically remediate any noncompliant accounts.
- Reasoning: AWS Config is a service that helps you assess, audit, and evaluate the configurations of your AWS resources. While AWS Config can help detect non-compliance, it does not directly interact with AWS Support plans or modify the support plan associated with an account. It is more geared toward configuration compliance rather than managing support plan settings.
- Why Rejected: AWS Config doesn't address the core requirement of modifying or setting the support plan for new accounts. The solution doesn’t directly align with modifying the AWS Support plan of accounts.
B) Create an AWS Lambda function to create a ticket for AWS Support to add the account to the Enterprise Support plan. Grant the Lambda function the support:ResolveCase permission.
- Reasoning: While a Lambda function could be used to create a support case to upgrade an account's support plan, this approach is reactive (requires support tickets) and introduces manual steps in an automated process. It would also require granting permissions to the Lambda function to resolve cases, which could be cumbersome and less efficient compared to an integrated solution.
- Why Rejected: This approach introduces unnecessary complexity, relying on AWS Support tickets and manual intervention, which is not ideal for automation or scalability. A more direct solution is preferred.
C) Add an additional value to the control_tower_p...
Author: Oscar · Last updated Jul 20, 2026
A company's DevOps engineer uses AWS Systems Manager to perform maintenance tasks during maintenance windows. The company has a few Amazon EC2 instances that require a restart after notifications from AWS Health. The DevOps engineer needs to implement an automated solution to remediate these notifications. The DevOp...
Let's break down the options in terms of their suitability for automating the remediation of EC2 instances after AWS Health notifications indicate maintenance requirements.
A) Configure an event source of AWS Health, a service of EC2, and an event type that indicates instance maintenance. Target a Systems Manager document to restart the EC2 instance.
- Reasoning: AWS Health provides notifications about upcoming events, including maintenance that affects AWS resources like EC2 instances. By configuring EventBridge to listen for health events related to EC2 instances, the rule can trigger a Systems Manager Automation document that restarts the affected EC2 instances. Systems Manager Automation is a powerful tool for performing predefined tasks on EC2 instances, including restarts. This solution directly matches the requirement for automation.
- Why Selected: This is the correct approach because it utilizes AWS Health to monitor maintenance notifications and Systems Manager Automation to perform the required remediation action (restarting the EC2 instance) directly.
B) Configure an event source of Systems Manager and an event type that indicates a maintenance window. Target a Systems Manager document to restart the EC2 instance.
- Reasoning: This option involves targeting a Systems Manager event, which is more related to maintenance windows already scheduled within Systems Manager rather than responding to AWS Health notifications. While you can use Systems Manager Automation documents for EC2 instance restarts, this option isn't tied to AWS Health notifications and would not respond directly to the health-related maintenance triggers.
- Why Rejected: It doesn't meet the requirement of automatically remediating based on AWS Health notifications. Instead, it is based on internal maintenance windows within Systems Manager, which is not the focus here.
C) Configure an event sourc...
Author: FlamePhoenix2025 · Last updated Jul 20, 2026
A company has containerized all of its in-house quality control applications. The company is running Jenkins on Amazon EC2 instances, which require patching and upgrading. The compliance officer has requested a DevOps engineer begin encrypting build artifacts since they contai...
To address the compliance officer's request of encrypting build artifacts in a maintainable manner, the DevOps engineer must consider a solution that streamlines both the encryption of artifacts and the ongoing maintenance of the infrastructure. Let's analyze each option carefully:
Option A: Automate patching and upgrading using AWS Systems Manager on EC2 instances and encrypt Amazon EBS volumes by default.
- Pros:
- Automating patching and upgrades using AWS Systems Manager is a good practice for maintaining EC2 instances.
- Encrypting Amazon EBS volumes ensures that data at rest on the EC2 instances is encrypted, which helps secure the data within Jenkins.
- Cons:
- This option does not directly address the encryption of build artifacts. While EBS encryption helps protect data on disk, it does not manage the build artifacts themselves, especially when they are copied off the EC2 instance (e.g., to an S3 bucket or another service).
- Jenkins itself would still require significant management (patching/upgrading) on EC2 instances, adding complexity to maintenance and scaling.
- Best for: General EC2 instance maintenance, not specifically for artifact management and encryption.
Option B: Deploy Jenkins to an Amazon ECS cluster and copy build artifacts to an Amazon S3 bucket with default encryption enabled.
- Pros:
- Deploying Jenkins to Amazon ECS (Elastic Container Service) helps automate scaling and management of Jenkins.
- S3 offers a simple and efficient solution for storing build artifacts, and enabling default encryption ensures that any file stored in S3 is automatically encrypted.
- ECS handles the container orchestration aspect well, making Jenkins easier to scale and maintain.
- Cons:
- Although this approach helps with scaling Jenkins, it still requires additional configuration for managing Jenkins containers and the encryption of build artifacts.
- The solution would still need to manually handle patching of ECS container instances, although ECS itself abstracts much of this management.
- This option requires moving build artifacts to S3, which would be efficient for encryption, but requires careful configuration to ensure security practices are followed in S3.
- Best for: Scalable Jenkins deployment with artifact storage in S3 but not ideal for replacing EC2 Jenkins entirely or handling encryption directly within the build pipeline.
Option C...
Author: Noah Williams · Last updated Jul 20, 2026
An IT team has built an AWS CloudFormation template so others in the company can quickly and reliably deploy and terminate an application. The template creates an Amazon EC2 instance with a user data script to install the application and an Amazon S3 bucket that the application uses to serve static webpages while it is running.
All resources should be removed when the CloudFormation stack is deleted. However, the team observes that CloudFormation reports an erro...
When trying to resolve the error of the S3 bucket not being deleted during CloudFormation stack deletion, it's essential to understand why CloudFormation is not deleting the S3 bucket and how to handle this efficiently.
Option A: Add a DeletionPolicy attribute to the S3 bucket resource, with the value Delete, forcing the bucket to be removed when the stack is deleted.
- Pros:
- The `DeletionPolicy` attribute with the `Delete` value is a standard way to ensure that an S3 bucket (or any other resource) is deleted when the CloudFormation stack is deleted.
- This ensures that resources like the S3 bucket are properly cleaned up without requiring additional manual intervention or complex configurations.
- Cons:
- While this solution is simple and effective, it will not work if the S3 bucket contains any objects during the deletion process. CloudFormation cannot delete a bucket that still contains data.
- Best for: This is ideal if the S3 bucket is empty or you can be sure that any objects stored in the bucket are not required to remain after stack deletion. Otherwise, it may still result in an error if the bucket is not empty.
Option B: Add a custom resource with an AWS Lambda function with the DependsOn attribute specifying the S3 bucket, and an IAM role. Write the Lambda function to delete all objects from the bucket when RequestType is Delete.
- Pros:
- This option provides a way to ensure that the S3 bucket can be deleted even if it contains objects. The Lambda function can programmatically delete the objects before the bucket itself is deleted.
- It offers a robust and customizable solution, especially if the S3 bucket is being populated with dynamic data.
- Cons:
- This solution adds complexity to the CloudFormation template by requiring the creation of a custom resource, IAM roles, and Lambda functions.
- It is not as efficient as directly using the `DeletionPolicy` with `Delete`, as it involves extra steps and components that may be overkill unless specific logic is needed to handle the contents of the S3 bucket.
- Best for: This option is useful if there is a need to ensure the buc...
Author: Liam · Last updated Jul 20, 2026
A company has an AWS CodePipeline pipeline that is configured with an Amazon S3 bucket in the eu-west-1 Region. The pipeline deploys an AWS Lambda application to the same Region. The pipeline consists of an AWS CodeBuild project build action and an AWS CloudFormation deploy action.
The CodeBuild project uses the aws cloudformation package AWS CLI command to build an artifact that contains the Lambda function code's .zip file and the CloudFormation template. The CloudFormation deploy action references the CloudFormation template from the output artifact of the CodeBuild project's build action.
The company wants to also deploy the Lambda application to the us-east-1 Region by using the...
To meet the requirement of deploying the Lambda application to both the eu-west-1 and us-east-1 Regions via AWS CodePipeline, we need to adjust the pipeline to handle artifacts for both Regions and ensure that the deployments are correctly referenced in each region. Let's go through each option to determine the best combination of steps.
Option A: Modify the CloudFormation template to include a parameter for the Lambda function codes 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.
- Pros:
- Adding a parameter for the Lambda function code location in the CloudFormation template is a flexible approach that allows the deployment to both Regions with different artifact locations.
- This makes the deployment process more dynamic and reusable by leveraging parameters.
- Cons:
- Requires modifying the CloudFormation template, which is not always the most efficient approach when dealing with separate output artifacts for each region.
- It could add complexity to managing different parameters, especially for more complicated deployments.
- Best for: Useful when you want a flexible, single template that can work across multiple regions, but it adds complexity.
Option 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 us-east-1 output artifact.
- Pros:
- This option directly solves the problem by adding a new deploy action in the pipeline for us-east-1.
- It uses the new artifact for us-east-1 (from the CodeBuild project) to deploy the Lambda function, without needing to modify the CloudFormation template.
- This is a straightforward and manageable solution that keeps each region’s deployment separate and reduces template complexity.
- Cons:
- It requires additional configuration for the pipeline, but this is not a major issue if it is a small change in the overall pipeline.
- Best for: This is the most straightforward approach to deploy Lambda applications to multiple regions while maintaining the separation of regions' resources and deployments.
Option C: Create an S3 bucket in us-east-1. Configure the S3 bucket policy to allow CodePipeline to have read and write access.
- Pros:
- This option addresses a potential need for creating a storage location in us-east-1, ensuring that CodePipeline can read and write to the bucket in the target region.
- Cons:
- Although creating an S3 bucket with the appropriate policies is necessary for Cross-Region functionality, it does no...
Author: BlazingPhoenix22 · Last updated Jul 20, 2026
A company runs an application on one Amazon EC2 instance. Application metadata is stored in Amazon S3 and must be retrieved if the instance is restarted. The instance must restart or relaunch automatica...
To meet the requirements of automatically restarting an EC2 instance when it becomes unresponsive and retrieving application metadata from Amazon S3 upon restart, let's evaluate each of the provided options.
Option A: Create an Amazon CloudWatch alarm for the StatusCheckFailed metric. Use the recover action to stop and start the instance. Use an S3 event notification to push the metadata to the instance when the instance is back up and running.
- Pros:
- The CloudWatch alarm can detect when the EC2 instance becomes unresponsive (e.g., via the StatusCheckFailed metric).
- The alarm can trigger the "recover" action, which will automatically attempt to recover the instance (i.e., stop and start).
- S3 event notifications can be used to push metadata when the instance is back up.
- Cons:
- While this solution can recover the instance, there is a dependency on S3 event notifications, which would only work for specific actions. Additionally, there may be some timing or synchronization challenges in ensuring the metadata is pushed at the correct time after the instance restarts.
- Using S3 event notifications for this scenario adds unnecessary complexity.
- Best for: This could work but isn't as efficient as other options since it introduces potential timing issues with S3 event notifications and requires extra configuration.
Option B: Configure AWS OpsWorks, and use the auto-healing feature to stop and start the instance. Use a lifecycle event in OpsWorks to pull the metadata from Amazon S3 and update it on the instance.
- Pros:
- AWS OpsWorks can manage EC2 instances and has built-in support for auto-healing, which can stop and start the instance if it becomes unresponsive.
- Using a lifecycle event in OpsWorks to pull metadata from S3 is a good solution.
- Cons:
- This solution introduces unnecessary complexity. AWS OpsWorks is generally used for more complex deployment and configuration management scenarios. It may be overkill for just needing auto-recovery of an EC2 instance and pulling data from S3.
- The solution would involve additional management overhead and complexity compared to more straightforward methods.
- Best for: OpsWorks is best for managing multi-layer applications and complex infrastructure, not for simple EC2 auto-healing and metadata retrieval.
Option C: Use EC2 Auto Recovery to automatically stop and start the instance in case of a failure. Use an S3 event notification to push the metadata to the instance when the instance is back up and running.
- Pros:
- EC2 Auto Recovery automa...
Author: FlamePhoenix2025 · Last updated Jul 20, 2026
A company has multiple AWS accounts. The company uses AWS IAM Identity Center (AWS Single Sign-On) that is integrated with AWS Toolkit for Microsoft Azure DevOps. The attributes for access control feature is enabled in IAM Identity Center.
The attribute mapping list contains two entries. The department key is mapped to ${path:enterprise.department}. The costCenter key is mapped to ${path:enterprise.costCenter}.
All existing Amazon EC2 instances have a department tag that corresponds to three company departments (d1, d2, d3). A DevOps engineer must create policies based on the matching attributes. The policies must minimi...
In this scenario, the goal is to create policies that minimize administrative effort by automatically granting Azure AD users access to only the Amazon EC2 instances tagged with their respective department name, using IAM Identity Center (AWS SSO) and attributes from Azure AD.
Key Requirements:
1. Attribute Mapping: The `department` attribute from Azure AD (`${path:enterprise.department}`) will be used to control access to the EC2 instances, based on their department tag.
2. Tagging: All EC2 instances are tagged with a department tag (e.g., `department: d1`, `department: d2`, `department: d3`).
3. Access Control: Each user should have access to EC2 instances that are tagged with their specific department.
Condition Key Analysis:
AWS allows you to apply IAM condition keys to specify rules about when and how a policy is applied. The `aws:RequestTag` and `aws:TagKeys` condition keys are used for controlling access based on tags attached to resources.
Potential options:
1. aws:RequestTag/department: This condition key applies to the tags that are attached to a request (e.g., for creating or modifying resources), but not directly to access control based on the tags of resources themselves. This key is not suitable for filtering resources already tagged with a department.
2. aws:PrincipalTag/department: This condition key checks the tag on the principal (i.e., the IAM user or role). Since the user is authenticated via IAM Identity Center and has the department attribute mapped to their Azure AD accou...
Author: Aarav2020 · Last updated Jul 20, 2026
A company hosts a security auditing application in an AWS account. The auditing application uses an IAM role to access other AWS accounts. All the accounts are in the same organization in AWS Organizations.
A recent security audit revealed that users in the audited AWS accounts could modify or delete the auditing application's IAM role. The company needs to prevent a...
To determine the best solution, let's analyze each option based on the requirements: preventing modifications to the auditing application's IAM role by anyone other than the trusted administrator IAM role, and ensuring that the auditing application's IAM role cannot be modified by users in the audited AWS accounts.
Option A: Create an SCP that includes a Deny statement for changes to the auditing application's IAM role. Include a condition that allows the trusted administrator IAM role to make changes. Attach the SCP to the root of the organization.
- Pros: This solution applies at the organization level, so it can enforce this policy across all AWS accounts in the organization.
- Cons: SCPs only control what actions can be performed on resources within an account, but they do not allow for specific permissions on a resource, such as an IAM role. SCPs don’t prevent specific principals from having permissions to modify resources; they only limit permissions granted by IAM policies. So, this approach might not provide the granularity needed for this situation.
- When to use: SCPs are suitable when you want to manage high-level permissions at the organization level, but this solution lacks the precise control needed for preventing role modification in specific AWS accounts.
Option B: Create an SCP that includes an Allow statement for changes to the auditing application's IAM role by the trusted administrator IAM role. Include a Deny statement for changes by all other IAM principals. Attach the SCP to the IAM service in each AWS account where the auditing application has an IAM role.
- Pros: This option restricts changes to the auditing role only to the trusted administrator IAM role by specifying an explicit Allow and Deny in the SCP. It provides more control than Option A by applying the policy to specific accounts.
- Cons: The limitation is that SCPs apply at the account level, so they still don’t guarantee the auditing application's IAM role will be completely protected. This can become difficult to maintain if more accounts are added or if the auditing application changes across accounts. Additionally, SCPs don’t directly target resources, so managing this might be cumbersome and prone to gaps.
- When to use: Useful in multi-account environments where you want to impose restrictions on resource manage...
Author: Ella · Last updated Jul 20, 2026
A company has an on-premises application that is written in Go. A DevOps engineer must move the application to AWS. The company's development team wants to enable blue/green deplo...
Let's go over each of the options, analyzing their suitability for the given requirements: enabling blue/green deployments and performing A/B testing.
Option A: Deploy the application on an Amazon EC2 instance, and create an AMI of the instance. Use the AMI to create an automatic scaling launch configuration that is used in an Auto Scaling group. Use Elastic Load Balancing to distribute traffic. When changes are made to the application, a new AMI will be created, which will initiate an EC2 instance refresh.
- Pros: This option uses EC2 instances with Auto Scaling and Elastic Load Balancing (ELB), which is a commonly used setup for scaling and distributing traffic. EC2 instance refresh can automate the process of replacing instances with new versions.
- Cons: While it can be used for blue/green deployments, it’s relatively complex. The management of AMIs and instance refreshes requires more manual configuration and maintenance. It also does not provide built-in support for A/B testing, as managing traffic splits between different versions requires extra setup.
- When to use: Suitable for highly customized, manual setups and advanced users familiar with managing EC2 instances and scaling manually, but lacks convenience for blue/green deployment and A/B testing out of the box.
Option B: Use Amazon Lightsail to deploy the application. Store the application in a zipped format in an Amazon S3 bucket. Use this zipped version to deploy new versions of the application to Lightsail. Use Lightsail deployment options to manage the deployment.
- Pros: Amazon Lightsail offers a simple way to deploy applications with minimal configuration. It is cost-effective and easy to set up.
- Cons: While Lightsail is simple and convenient, it does not natively support blue/green deployments or A/B testing. It’s designed for simpler, less complex use cases, and as such, it lacks the advanced traffic routing capabilities required for blue/green and A/B testing deployments.
- When to use: Best for small, straightforward applications or use cases that do not require sophisticated deployment strategies like blue/green or A/B testing.
Option C: Use AWS CodeArtifact to store the a...
Author: Julian · Last updated Jul 20, 2026
A developer is maintaining a fleet of 50 Amazon EC2 Linux servers. The servers are part of an Amazon EC2 Auto Scaling group, and also use Elastic Load Balancing for load balancing.
Occasionally, some application servers are being terminated after failing ELB HTTP health checks. The developer would like to perform a root ca...
The goal is to automate log collection before an EC2 instance is terminated due to a failed health check, while ensuring that the logs are captured before the server is removed from the Auto Scaling group. We need to assess the options and determine the most efficient way to achieve this.
Option A: Use Auto Scaling lifecycle hooks to put instances in a Pending:Wait state. Create an Amazon CloudWatch alarm for EC2 Instance Terminate Successful and trigger an AWS Lambda function that invokes an SSM Run Command script to collect logs, push them to Amazon S3, and complete the lifecycle action once logs are collected.
- Pros: This approach uses lifecycle hooks to pause the termination process, which is important for log collection. Lambda can be triggered by the CloudWatch alarm to invoke SSM Run Command, which is capable of executing commands on the EC2 instances to collect logs.
- Cons: The lifecycle hook in this option is in a `Pending:Wait` state, but the primary use case is for instances that are being terminated due to health check failures. Using the `Pending:Wait` state isn't as effective for the termination scenario where logs need to be collected before termination. Moreover, it introduces unnecessary complexity by using a CloudWatch alarm in this case, as it can be directly managed using EventBridge.
- When to use: This solution is less effective because of the misalignment of lifecycle hook states and the unnecessary complexity of the CloudWatch alarm.
Option B: Use Auto Scaling lifecycle hooks to put instances in a Terminating:Wait state. Create an AWS Config rule for EC2 Instance-terminate Lifecycle Action and trigger a step function that invokes a script to collect logs, push them to Amazon S3, and complete the lifecycle action once logs are collected.
- Pros: The use of lifecycle hooks in the `Terminating:Wait` state is correct, as it ensures that instances can be paused before termination. The combination of an AWS Config rule and Step Functions adds flexibility for orchestrating tasks like log collection.
- Cons: The overhead of AWS Config and Step Functions introduces unnecessary complexity and cost. Step Functions might be overkill for simply collecting logs and pushing them to S3. AWS Lambda can achieve this with much less complexity.
- When to use: This solution is suitable for complex workflows, but it intro...
Author: Aarav · Last updated Jul 20, 2026
A company has an organization in AWS Organizations. The organization includes workload accounts that contain enterprise applications. The company centrally manages users from an operations account. No users can be created in the workload accounts. The company recently added an operations team and must provide the operatio...
Let's break down the scenario and evaluate the options:
The company manages users centrally from the operations account and needs to give the operations team members administrator access to each workload account. The key factors to consider are:
1. Centralized management of users: The operations account is where user management occurs, and users cannot be created in the workload accounts.
2. Access control for operations team members: The operations team must have administrative access to the workload accounts.
3. No direct creation of users in workload accounts: This means user creation or direct IAM management in workload accounts is not possible.
A) Create a SysAdmin role in the operations account. Attach the AdministratorAccess policy to the role. Modify the trust relationship to allow the sts:AssumeRole action from the workload accounts.
- Analysis: The SysAdmin role is in the operations account, but modifying the trust relationship to allow the workload accounts to assume the role from the operations account doesn’t directly grant operations team members access to the workload accounts. The operation here is not quite correct because the SysAdmin role needs to be in each workload account, not the operations account, to allow users in the operations account to assume it.
- Rejected: This option is not the most effective because roles should be created in the workload accounts to be assumed from the operations account.
B) Create a SysAdmin role in each workload account. Attach the AdministratorAccess policy to the role. Modify the trust relationship to allow the sts:AssumeRole action from the operations account.
- Analysis: This option correctly involves creating a SysAdmin role in each workload account with appropriate permissions (AdministratorAccess) and modifying the trust policy to allow users from the operations account to assume the role. This ensures that operations team members can assume the role from the operations account and get administrator access in each workload account.
- Selected: This option is appropriate because it ensures that the operations team can assume a role in each workload account for administrative access.
C) Create an Amazon Cognito identity pool in the operations account. Attach the SysAdmin role as an authenticated role.
- Analysis: Using Amazon Cognito for managing identity and access is overcomplicated in this case. It’s designed for scenarios involving feder...
Author: Emily · Last updated Jul 20, 2026
A company has multiple accounts in an organization in AWS Organizations. The company's SecOps team needs to receive an Amazon Simple Notification Service (Amazon SNS) notification if any account in the organization turns off the Block Public Access feature on an Amazon S3 bucket. A DevOps engineer must implement this change without affecting the operation of any AWS accounts....
To meet the requirements of ensuring that the SecOps team receives a notification if any account turns off the Block Public Access feature on an S3 bucket, while ensuring the individual member accounts in the organization cannot disable the notification, we need to implement a centralized notification system that is also secured from tampering by member accounts.
Option A: Designate an account to be the delegated Amazon GuardDuty administrator account. Turn on GuardDuty for all accounts across the organization. In the GuardDuty administrator account, create an SNS topic. Subscribe the SecOps team's email address to the SNS topic. In the same account, create an Amazon EventBridge rule that uses an event pattern for GuardDuty findings and a target of the SNS topic.
- Pros: GuardDuty can detect security issues like public exposure of S3 buckets, and EventBridge can forward these findings to an SNS topic. This solution centralizes the alert system in the GuardDuty administrator account, preventing modification by other accounts.
- Cons: GuardDuty is primarily focused on detecting security findings rather than configuration changes like turning off Block Public Access. This solution would not specifically track the action of turning off Block Public Access, and GuardDuty might not trigger notifications in a way that is directly tied to the requirement. Furthermore, it may miss some cases of misconfigurations related to the S3 bucket public access settings.
- When to use: This could work for general security monitoring, but it isn't tailored to track the specific configuration changes for S3 buckets related to Block Public Access.
Option B: Create an AWS CloudFormation template that creates an SNS topic and subscribes the SecOps team's email address to the SNS topic. In the template, include an Amazon EventBridge rule that uses an event pattern of CloudTrail activity for `s3:PutBucketPublicAccessBlock` and a target of the SNS topic. Deploy the stack to every account in the organization by using CloudFormation StackSets.
- Pros: This solution specifically targets the activity of turning off the Block Public Access setting on S3 buckets by using CloudTrail and EventBridge. It is a precise solution for the requirement, and by using CloudFormation StackSets, it ensures that the same configuration is applied across all accounts in the organization, and no account can tamper with the setup.
- Cons: The implementation using CloudFormation StackSets requires careful management of permissions and governance to ensure it works consistently across all accounts. This is a more complex setup, but it guarantees the intended behavior.
- When to use: This is ...
Author: Zain · Last updated Jul 20, 2026
A company has migrated its container-based applications to Amazon EKS and want to establish automated email notifications. The notifications sent to each email address are for specific activities related to EKS components. The solution will include Amazon SNS topics and an AWS Lambda function to eva...
To meet the requirements for automated email notifications based on specific activities related to Amazon EKS components, let’s analyze each option:
A) Enable Amazon CloudWatch Logs to log the EKS components. Create a CloudWatch subscription filter for each component with Lambda as the subscription feed destination.
- Explanation: CloudWatch Logs can capture detailed logs from EKS components. A CloudWatch subscription filter allows the logs to be forwarded to a Lambda function for further processing, such as evaluating log events and triggering notifications.
- Key Factors:
- CloudWatch Logs natively integrates with EKS, making it a straightforward choice.
- The Lambda function can be used to evaluate the logs and then publish the appropriate messages to the correct SNS topics.
- Subscription filters are designed for real-time log processing, making it a suitable solution for automated email notifications.
Why Selected: This option is efficient and designed for real-time processing of logs with the ability to trigger Lambda functions. It directly addresses the requirements by enabling the creation of filters specific to each EKS component.
B) Enable Amazon CloudWatch Logs to log the EKS components. Create CloudWatch Logs Insights queries linked to Amazon EventBridge events that invoke Lambda.
- Explanation: CloudWatch Logs Insights allows querying logs, and EventBridge can trigger events based on queries. This combination could invoke a Lambda function.
- Key Factors:
- CloudWatch Logs Insights and EventBridge introduce an additional layer of complexity. While it's powerful for querying logs, it doesn’t offer the same immediate, filter-based log forwarding and processing as CloudWatch subscription filters.
- The EventBridge event creation process and query logic may not be the best fit for direct, real-time notifications based on individual log events from EKS components.
Why Rejected: This solution is not as straightforward as option A. The querying and EventBridge event system adds u...
Author: Liam · Last updated Jul 20, 2026
A company is implementing an Amazon Elastic Container Service (Amazon ECS) cluster to run its workload. The company architecture will run multiple ECS services on the cluster. The architecture includes an Application Load Balancer on the front end and uses multiple target groups to route traffic.
A DevOps engineer must collect application and access logs. The DevOps engineer then needs to...
To meet the requirement of collecting application and access logs from ECS services and sending them to an S3 bucket for near-real-time analysis, let's carefully evaluate each option:
A) Download the Amazon CloudWatch Logs container instance from AWS. Configure this instance as a task. Update the application service definitions to include the logging task.
- Analysis: This option involves using a specific "container instance" to collect logs, but this method is cumbersome and doesn't scale well for ECS-based applications. Container instances are more relevant to EC2-backed ECS clusters, and updating the service definitions just for logging would be more complex and inefficient.
- Rejected: This approach is not the best solution for ECS workloads because it's an unnecessary step in using ECS task definitions to configure logging properly.
B) Install the Amazon CloudWatch Logs agent on the ECS instances. Change the logging driver in the ECS task definition to `awslogs`.
- Analysis: This option involves configuring CloudWatch Logs to collect logs at the container level using the `awslogs` logging driver. It is a suitable solution because it integrates directly with Amazon ECS tasks, allowing the logs to be sent to CloudWatch Logs, where they can later be exported to an S3 bucket.
- Selected: This option is a correct and efficient way to collect logs from ECS tasks by using the `awslogs` logging driver in the ECS task definition.
C) Use Amazon EventBridge to schedule an AWS Lambda function that will run every 60 seconds and will run the Amazon CloudWatch Logs `create-export-task` command. Then point the output to the logging S3 bucket.
- Analysis: This option proposes using AWS Lambda and EventBridge to create scheduled tasks to export CloudWatch logs to S3. While feasible, it introduces unnecessary complexity and delays. Since CloudWatch Logs can be directly streamed or exported more easily, scheduling exports with a Lambda function every 60 seconds is not the most efficient or scalable approach.
- Rejected: While possible, this solution adds complexity and may not be ideal fo...
Author: Ryan · Last updated Jul 20, 2026
A company that uses electronic health records is running a fleet of Amazon EC2 instances with an Amazon Linux operating system. As part of patient privacy requirements, the company must ensure continuous compliance for patches for operating system and applications running on the EC2 instances...
To meet the requirement of automating operating system and application patching for Amazon EC2 instances running Amazon Linux while ensuring compliance with patient privacy regulations, let's evaluate the options based on key factors such as continuous patching, integration with custom and default repositories, and compliance tracking.
A) Use AWS Systems Manager to create a new patch baseline including the custom repository. Run the AWS-RunPatchBaseline document using the run command to verify and install patches.
- Explanation: AWS Systems Manager can automate patch management by using custom patch baselines. With this option, you can create a custom patch baseline that includes the company's specific repository (custom repository). By running the `AWS-RunPatchBaseline` document, you can check for missing patches and install them on EC2 instances.
- Key Factors:
- AWS Systems Manager Patch Manager integrates well with EC2 instances to ensure compliance.
- You can use a custom repository, which aligns with the need to deploy patches from both default and custom sources.
- The `AWS-RunPatchBaseline` document automates patch installation, making it a solid choice for continuous patching and compliance.
- Why Selected: This option directly addresses the requirements for automating patch deployment, supporting both default and custom repositories, and leveraging AWS Systems Manager for monitoring and compliance.
B) Use AWS Direct Connect to integrate the corporate repository and deploy the patches using Amazon CloudWatch scheduled events, then use the CloudWatch dashboard to create reports.
- Explanation: This option involves using AWS Direct Connect to integrate a corporate repository, and then using Amazon CloudWatch scheduled events for deployment. However, integrating Direct Connect for patch management is unnecessary and introduces complexity. CloudWatch is more suited for monitoring and alerting rather than patch management.
- Key Factors:
- AWS Direct Connect is typically used for establishing a dedicated network connection between on-premises infrastructure and AWS, not for patch management.
- Using CloudWatch for patch deployment is not ideal, as it's not directly integrated with patching processes for EC2 instances.
- Why Rejected: While AWS Direct Connect can integrate a corporate repository, it's overco...
