Sample Questions for the AWS Devops Engineer Certification

The most secure and AWS-aligned approach is to use Store the RDS database credentials in AWS Secrets Manager and attach an EC2 instance profile that can read that secret and call DynamoDB APIs. Secrets Manager provides encrypted storage and native rotation for RDS credentials, and the EC2 instance role supplies temporary credentials to retrieve the secret and access DynamoDB via IAM policies without hardcoding keys.

Put both the RDS password and supposed DynamoDB credentials in AWS Secrets Manager and grant the EC2 instance role permission to read the secrets is incorrect because DynamoDB does not rely on database-style credentials; access is granted with IAM, so there is nothing meaningful to store for DynamoDB.

Keep IAM user access keys and the RDS password in Secrets Manager and let the EC2 instance role retrieve them is not recommended because long-lived IAM user keys should not be used on EC2; instance profiles provide short-lived credentials and eliminate the need to distribute user keys.

Use AWS Systems Manager Parameter Store SecureString for both the RDS credentials and DynamoDB, and allow the instance role to read those parameters is weaker than the correct design since Parameter Store does not provide native RDS credential rotation, and DynamoDB access should be controlled with IAM rather than stored secrets.

For applications on EC2, use IAM roles to access AWS services and store database passwords in AWS Secrets Manager with rotation. Remember that DynamoDB uses IAM and does not require stored credentials.

Write the current AMI ID to SSM Parameter Store and reference it via CloudFormation SSM dynamic reference is correct because CloudFormation dynamic references (ssm or ssm-secure) fetch the current parameter value at deploy time, letting teams publish a new AMI ID centrally while stacks automatically consume the latest approved image without template changes or tight coupling.

The option Tag the latest AMI in EC2 Image Builder and have CloudFormation look it up by tag is incorrect because CloudFormation cannot natively resolve an AMI by tag. This requires a custom resource, adding complexity and operational overhead.

Store the AMI ID in S3 and read it via a cross-stack export is incorrect since S3 files and cross-stack exports are not purpose-built for parameter discovery, complicate governance, and lack built-in secure resolution semantics compared to Parameter Store dynamic references.

Use AWS Service Catalog with a Launch Template referencing $Latest is incorrect because Launch Templates require an explicit AMI ID and do not inherently track the newest AMI. Service Catalog does not solve the dynamic AMI resolution for CloudFormation and introduces additional management layers.

Prefer dynamic references to SSM Parameter Store when a template must pull the freshest configuration at deploy time. Recognize that tags are not a native CloudFormation lookup for AMIs. Avoid S3 files for configuration pointers when a parameter store exists. Look for wording emphasizing decoupling, scalability, and automatic pickup of the latest value to steer you toward SSM Parameter Store dynamic references.

Create an AWS CloudFormation service role scoped to the needed actions, associate it with the stack, and grant the engineer iam:PassRole to let CloudFormation assume that role during deployments is correct because CloudFormation can then use that role’s permissions to create and manage stack resources on the user’s behalf, while the role policy itself enforces least privilege.

Create an AWS CloudFormation service role with the necessary permissions and set it on the stack; use it for deployments is insufficient because the user must also have iam:PassRole to allow CloudFormation to assume the role during operations.

Create an AWS CloudFormation service role with full administrative permissions, attach it to the stack, and allow iam:PassRole only when a ResourceTag matches is not appropriate since it violates least-privilege and ResourceTag conditions are not supported to restrict iam:PassRole for roles.

Create an AWS CloudFormation service role with required permissions and add an aws:SourceIp condition listing developer IPs; associate it to the stack and grant iam:PassRole is ineffective because CloudFormation uses its own IP addresses for downstream calls, so SourceIp conditions won’t apply to those requests.

When a user lacks direct permissions to create stack resources, use a CloudFormation service role with least privilege and grant the user iam:PassRole so CloudFormation can assume it; avoid attempting to control PassRole with ResourceTag or using aws:SourceIp for CloudFormation calls.

EventBridge rule triggers Lambda to promote the replica and update Systems Manager Parameter Store is correct because EventBridge can capture RDS and Aurora failure or failover events, invoke a Lambda function to promote the cross-Region replica to writer, and then update a Parameter Store key that applications read during reconnect. This decouples the connection string from code and enables fast, automated endpoint rotation to meet a tight RTO.

Aurora Global Database managed failover is not sufficient because while it can orchestrate a role switch between Regions, it does not automatically detect failures nor update application endpoints; you still need automation to redirect clients.

Amazon Route 53 DNS failover between writer and reader endpoints cannot promote an Aurora replica to writer, and Aurora endpoint names can change during promotion, so DNS health checks alone do not complete the recovery workflow.

Amazon RDS Proxy for multi-Region failover with a stable endpoint is incorrect because RDS Proxy is scoped to a single Region and cluster and does not perform cross-Region promotion or endpoint management. For the exam, look for solutions that combine event detection, automation, and centralized configuration. Use EventBridge for detection, Lambda for orchestration, and a configuration store like Parameter Store or Secrets Manager for indirection. DNS health checks help with routing but cannot perform database role changes. Prefer approaches that let clients fetch the current endpoint at reconnect rather than hardcoding it.

The scalable approach is to use AWS Organizations for account grouping and to enforce least privilege with cross-account IAM roles scoped by resource-level permissions. In the shared production account, create one IAM role per division with a trust policy that allows only that division’s member accounts to assume it, and attach an IAM policy that permits ec2:TerminateInstances solely on instances the division owns, typically enforced with conditions such as ec2:ResourceTag or account-scoped ARNs. This design ensures that developers can manage only their own EC2 resources while preventing other divisions from terminating them, which makes Use AWS Organizations with OUs and a per business unit IAM role in the production account that allows TerminateInstances only on resources it owns, assumed via cross-account trust the correct choice.

Use a centralized AWS Config aggregator with AWS Control Tower and Customizations for AWS Control Tower to restrict EC2 termination per division is incorrect because Config aggregators collect configuration and compliance data and Control Tower sets guardrails and baselines, but neither natively enforces per-instance termination rights at the IAM resource level.

Enable EC2 termination protection on all instances and route termination requests through AWS Systems Manager Change Manager approvals is incorrect since termination protection blocks all terminations until manually disabled and Change Manager adds process controls, but this does not implement fine-grained, owner-based authorization or scale across accounts.

Create an SCP in the production account via AWS Service Catalog that permits business-unit-specific termination actions and attach it to the appropriate OUs is incorrect because SCPs do not grant permissions and cannot be targeted to specific resources like individual EC2 instances, and AWS Service Catalog is unrelated to defining cross-account authorization boundaries.

For cross-account governance, think Organizations + OUs for grouping and IAM roles with resource-level conditions for enforcement; remember that SCPs never grant permissions and services like Config or Control Tower do not replace IAM for per-resource authorization.

The best approach for minimal downtime is to avoid an in-place major upgrade on the primary. With Amazon RDS for MySQL, you can create a read replica, upgrade the replica to the target major version, promote it, and then switch application traffic to the new endpoint. This keeps the primary serving reads/writes until the brief cutover window. Therefore, Provision a read replica, upgrade the replica to the target major version, promote it, then cut over is correct.

The option Enable AutoMinorVersionUpgrade and update the stack is incorrect because AutoMinorVersionUpgrade only applies minor versions, not major upgrades.

The option Use AWS Database Migration Service is a valid migration path that can reduce downtime, but it introduces additional moving parts and is not an in-place CloudFormation-driven upgrade of the existing RDS instance, which the question emphasizes.

The option Update EngineVersion with AllowMajorVersionUpgrade for an in-place change is incorrect for minimal downtime because in-place major upgrades restart the engine and can incur noticeable downtime even with Multi-AZ.

Remember that AutoMinorVersionUpgrade is only for minor releases. Major version upgrades require AllowMajorVersionUpgrade and generally incur downtime if performed in place. For minimal downtime, think in terms of replica–promote cutover or other blue/green style patterns. Use CloudFormation to define read replicas (SourceDBInstanceIdentifier), apply the upgrade to the replica, and then promote and redirect traffic for a fast cutover.

Rehost the Oracle RAC database on EBS-backed Amazon EC2, install the SSM agent, use AWS Systems Manager Patch Manager for OS patches, and configure Amazon Data Lifecycle Manager to schedule EBS snapshots is correct because Oracle RAC is only supported on Amazon EC2, AWS Systems Manager Patch Manager provides automated OS patching at scale, and Amazon Data Lifecycle Manager offers native, low-effort scheduling and retention for EBS snapshots.

Migrate the database to Amazon Aurora, enable automated backups, and rely on Aurora maintenance windows for patching is incorrect since Aurora does not support Oracle RAC, so it cannot host the workload.

Move the on-premises database to Amazon RDS for Oracle with Multi-AZ and let RDS handle backups and host patching is incorrect because RDS for Oracle does not support RAC, making this migration path infeasible.

Move the RAC database to Amazon EC2 and trigger CreateSnapshot with an AWS Lambda function on an Amazon EventBridge schedule, and use AWS CodeDeploy and AWS CodePipeline to manage patching is incorrect because CodeDeploy and CodePipeline are CI/CD services rather than patch automation tools, and DLM provides a simpler native mechanism for scheduled EBS snapshots than custom Lambda orchestration.

When you see Oracle RAC, think EC2, not RDS or Aurora. For OS patching at scale, use Systems Manager Patch Manager, and for scheduled EBS backups with retention, use Amazon Data Lifecycle Manager for the least operational effort.

CloudWatch agent to CloudWatch Logs, Firehose to S3, query with Athena is the best fit. The unified CloudWatch agent runs on both on-prem servers and EC2 to send OS and application logs into CloudWatch Logs. A subscription filter streams those logs via Kinesis Data Firehose into a centralized Amazon S3 bucket. S3 provides low-cost, durable storage suitable for long-term retention, and Amazon Athena enables serverless, ad hoc SQL queries over that data with virtually no infrastructure to manage. This pattern minimizes setup and ongoing operations while meeting centralized collection and audit-friendly querying.

The option CloudWatch Logs + Logs Insights is workable but is not the lowest cost for large volumes or long retention because CloudWatch Logs storage and per-GB query pricing can exceed S3 plus Athena for audit workloads.

The option CloudWatch agent to CloudWatch Logs, stream to Amazon OpenSearch Service provides powerful search and dashboards but introduces cluster management and higher ongoing costs compared to serverless S3 plus Athena, which the question emphasizes as low cost and minimal setup.

The option AWS Security Lake targets security telemetry in OCSF format and is not designed for general OS or application logs from arbitrary servers, so it does not align with the requirement.

Look for keywords such as hybrid collection, low-cost storage, and minimal setup. Prefer serverless, managed data paths. The unified CloudWatch agent covers both on-prem and EC2. For long-term audits, S3 plus Athena is typically favored over CloudWatch Logs Insights or OpenSearch due to cost and operational simplicity.

The most plausible cause is An Auto Scaling scale-out event occurred during the deployment, so the new instances launched with the last successfully deployed revision. During an in-place rollout, if the Auto Scaling group scales out mid-deployment, the newly launched instances install the most recent successful revision, not the revision currently being deployed, which can leave the fleet with mixed versions while CodeDeploy still reports success.

A CloudWatch alarm fired during the rollout is unlikely because alarms do not inherently pin subsets of instances to older revisions or cause mixed versions in a successful deployment.

Two instances lacked IAM permissions to retrieve the revision from Amazon S3 would cause those instances to fail lifecycle events, which would make the deployment fail rather than succeed.

The Auto Scaling group is using an outdated launch template or launch configuration version would influence how instances launch, but CodeDeploy targets instances in the deployment group and would attempt to update them, so this does not align with a successful deployment that leaves only a subset updated.

To prevent this, pause scale-out processes during deployments or use a blue/green strategy; afterward, redeploy the latest revision to normalize versions across the group.

If you see mixed app versions with a reported success during an in-place CodeDeploy to an Auto Scaling group, think scale-out during deployment, where new instances pull the last successful revision instead of the in-progress one.

The correct approach is to use CloudFormation dynamic reference to SSM Parameter Store for AMI ID. Publish the latest golden AMI ID to a Systems Manager Parameter in each Region and reference it in the template via a dynamic reference or the AWS::SSM::Parameter::Value<AWS::EC2::Image::Id> parameter type. CloudFormation resolves the parameter at create or update time so stacks pick up the current AMI without template edits.

The option EventBridge rule invoking Lambda to update template with newest AMI is a custom workaround that introduces brittle template rewriting and extra operational burden.

The option EC2 Image Builder pipeline automatically chosen by CloudFormation is incorrect because CloudFormation does not natively pull the latest AMI from an Image Builder pipeline; you must publish AMI IDs to SSM or use a custom resource.

The option AWS Service Catalog does not make CloudFormation auto-resolve AMIs and is unnecessary for this use case.

Watch for keywords like automatically resolve latest AMI and keep using CloudFormation. Prefer native mechanisms such as SSM Parameter Store dynamic references or the AWS::SSM::Parameter::Value<AWS::EC2::Image::Id> parameter type. For multi-Region deployments, ensure the parameter exists per Region or use public SSM AMI parameters. Avoid solutions that rewrite templates or require custom code unless explicitly asked.

Schedule a Lambda to refresh AWS Trusted Advisor service quota checks with EventBridge and add another EventBridge rule that matches Trusted Advisor limit events and publishes to an SNS topic subscribed by the operations manager is best because Trusted Advisor already includes service quota checks and integrates with EventBridge, so you only need a lightweight refresh and a rule-to-SNS pipeline.

Build a Lambda function to enumerate account resources and compare usage against published service quotas, trigger it on a schedule with EventBridge, and publish alerts to an SNS topic requires extensive custom logic to inventory resources and map them to limits, which is higher effort.

Create an AWS Config custom rule that evaluates service quota consumption and posts to an SNS topic, with a Lambda subscriber that notifies the operations manager still needs custom evaluation of quotas and usage, making it more complex than using Trusted Advisor’s native checks.

Create a Lambda function to refresh AWS Health checks on a timer and configure an EventBridge rule that matches Trusted Advisor events and sends notifications to an SNS topic is ineffective because AWS Health does not track or alert on service quota usage and the mixed configuration is inconsistent.

For near-limit alerts with the least effort, think Trusted Advisor service quota checks plus EventBridge for events and SNS for notifications; avoid building custom inventory or Config rules, and remember AWS Health is not for service quota monitoring.

The correct choice is EventBridge rule for aws.health AWS_RISK_CREDENTIALS_EXPOSED to Step Functions. AWS Health emits an event when AWS detects an exposed IAM access key on public sources such as GitHub. You can create an EventBridge rule with source aws.health and event code AWS_RISK_CREDENTIALS_EXPOSED to trigger a Step Functions state machine. That workflow can run Lambda tasks to deactivate and delete the key, query CloudTrail for recent activity tied to the access key, and publish an Amazon SNS notification to the team. This pattern is the native and scalable way to integrate AWS Health with automated remediation.

The option Amazon GuardDuty and Amazon Macie with Step Functions is incorrect because these services do not monitor public code hosting for IAM keys nor emit the AWS Health event for exposed credentials.

The option AWS Config multi-account rule invoking Step Functions is incorrect because AWS Config evaluates configuration state and does not process AWS Health events.

The option Amazon Detective with EventBridge automation is incorrect because Detective is for security investigations and graph analysis, not for detecting exposed keys or emitting the required Health event.

When you see leaked or exposed AWS access keys, associate detection with the AWS Health event AWS_RISK_CREDENTIALS_EXPOSED and routing via EventBridge source aws.health. Choose Step Functions for multi-step remediation, Lambda for discrete actions like IAM key deletion and CloudTrail lookups, and SNS for alerts. Remember that the Personal Health Dashboard is a console view; automated actions come from EventBridge rules, not a PHD rule.

The web tier should be stateless behind Auto Scaling, and ad click events need a managed path to land in S3 for billing and be loaded into Redshift with minimal custom code. Run the site on stateless EC2 in an Auto Scaling group and move SQL Server to Amazon RDS; use Amazon Kinesis Data Firehose to deliver click events to Amazon S3 for billing and a second Firehose delivery stream to load Amazon Redshift is best because Firehose reliably buffers, batches, and delivers data to S3 and supports loading Redshift using an S3 staging bucket with minimal operations.

Run the site on stateless EC2 in an Auto Scaling group and move SQL Server to Amazon RDS; publish click data with Amazon Kinesis Data Streams directly to Amazon S3 for billing and send another stream to Amazon Redshift is incorrect since Kinesis Data Streams does not write to S3 or Redshift without consumer applications or Firehose.

Run the site on stateless EC2 in an Auto Scaling group and move SQL Server to Amazon RDS; use Amazon Athena to push click logs to Amazon S3 and also load them into Amazon Redshift is incorrect because Athena is a query service and not a data ingestion mechanism.

Run the site on stateless EC2 in an Auto Scaling group and move SQL Server to Amazon RDS; send click events to Amazon MSK and rely on an AWS Glue crawler and catalog to populate Amazon Redshift is incorrect since a Glue crawler only catalogs data and MSK would still require additional ETL to load Redshift, adding complexity and latency.

For streaming delivery with minimal code, prefer Amazon Kinesis Data Firehose to load into Amazon S3 and Amazon Redshift; remember that Kinesis Data Streams needs consumers, and Athena queries data in S3 rather than ingesting it.

The correct choices are Drift detection does not evaluate custom resources and The rule calls DetectStackDrift and treats API throttling or failures as NON_COMPLIANT. CloudFormation’s drift detection explicitly excludes custom resources, so they are not evaluated, which answers how custom resources are handled. The AWS Config managed rule cloudformation-stack-drift-detection-check invokes the DetectStackDrift API. If that API is throttled or fails, the rule defaults the evaluation to NON_COMPLIANT even when the CloudFormation console reports IN_SYNC, causing the observed mismatch. Re-running the evaluation or addressing API throttling typically resolves the discrepancy.

The option Use CloudFormation change sets to detect drift is incorrect because change sets preview proposed updates rather than detect out-of-band changes.

Provide a cloudformationRoleArn with broader permissions to fix the mismatch is incorrect because permission problems usually raise explicit access errors; they are not the cause of the rule’s default-to-NON_COMPLIANT behavior on DetectStackDrift failures.

Define all custom resource properties so drift can be detected is wrong because custom resources are unsupported for drift detection regardless of property definitions.

When you see custom resources combined with drift detection, remember that custom resources are not checked. For AWS Config managed rules that wrap service APIs, a mismatch like IN_SYNC in the console versus NON_COMPLIANT in the rule often points to API throttling or transient failures. Re-evaluate the rule, check service quotas and CloudWatch metrics for throttling, and verify recent API errors in logs.

To satisfy near-real-time delivery of container and ALB logs into S3, send container STDOUT/STDERR to CloudWatch Logs from ECS, stream those logs to S3 with a subscription and Kinesis Data Firehose, and enable ALB access logging directly to S3. This creates an automated pipeline with low latency and complete coverage of service and load balancer logs.

Enable access logging on the Application Load Balancer and configure the destination to the specified S3 bucket is correct because ALB can write detailed request logs straight to S3, covering client requests, latencies, and responses.

Use the awslogs log driver in ECS task definitions, install the CloudWatch Logs agent on the container instances, and grant the needed permissions on the instance role is correct because the awslogs driver routes container logs to CloudWatch Logs, and with appropriate IAM and the agent on EC2-backed clusters, this centralizes logs without filling instance disks.

Create a CloudWatch Logs subscription filter to an Amazon Kinesis Data Firehose delivery stream that writes continuously to the S3 bucket is correct because subscription filters provide a near-real-time stream from CloudWatch Logs to S3 via Firehose, meeting the latency target.

Set up Amazon Macie to scan the S3 bucket and provide near-real-time analysis of the access logs is incorrect because Macie focuses on sensitive data discovery and classification rather than streaming log ingestion or real-time analytics.

Turn on Detailed Monitoring in CloudWatch for the load balancer to store access logs in S3 is incorrect because Detailed Monitoring increases metric resolution but does not produce or store access logs.

Use an AWS Lambda function triggered by an Amazon EventBridge schedule every 2 minutes to call CreateLogGroup and CreateExportTask to move logs to S3 is incorrect because CloudWatch Logs export tasks are batch, not continuous, and are unsuitable for near-real-time delivery.

For near-real-time log delivery from CloudWatch Logs to S3, think subscription filter + Kinesis Data Firehose; for ALB requests, enable ALB access logging; and remember that CloudWatch Detailed Monitoring is metrics-only while ExportTask is batch.

EventBridge rule and Lambda to refresh Trusted Advisor via Support API every 10 minutes and publish to SNS delivers near real-time alerts by programmatically refreshing Trusted Advisor checks and forwarding results to Amazon SNS. AWS Config rule flagging SGs with port 22 open to 0.0.0.0/0 and notifying via SNS continuously evaluates security groups for the risky SSH rule and alerts on noncompliance. AWS Config auto-remediation using Systems Manager Automation to restrict SG port 22 to a specified IP enforces the desired state by automatically updating noncompliant security groups to allow SSH only from the approved source.

The option Custom AWS Config remediation that invokes Lambda to edit security groups is incorrect because native Config remediation uses AWS Systems Manager Automation documents, not direct Lambda calls.

The option Amazon GuardDuty to detect open security groups and auto-remediate is incorrect since GuardDuty focuses on threat detection, not configuration compliance or Trusted Advisor findings.

The option AWS Security Hub with Foundational Security Best Practices to auto-remediate Trusted Advisor findings is incorrect because Security Hub does not ingest Trusted Advisor findings and cannot directly remediate them. On the exam, tie Trusted Advisor near real-time alerts to scheduling a refresh via the AWS Support API using EventBridge and Lambda. Map configuration compliance to AWS Config managed rules (for SSH, look for INCOMING_SSH_DISABLED) and map automatic fixes to Config remediation with SSM Automation, not direct Lambda. Watch for distractors that mix Security Hub or GuardDuty with Trusted Advisor-specific requirements.

The heartbeat timeout during a lifecycle action indicates the instance did not complete the hook processing in time, which often happens when related automation is throttled or deployment concurrency limits are hit.

Use Configure an Auto Scaling lifecycle hook on instance termination and use an Amazon EventBridge rule to trigger an AWS Lambda function that runs AWS Systems Manager Run Command to pull application logs and upload them to Amazon S3 to reliably retrieve logs before the instance is terminated. This provides a deterministic path to gather app logs from every affected instance.

When CodeDeploy reaches account or deployment group concurrency limits, hooks may stall and lead to abandoned lifecycle actions. Selecting Adjust the AWS CodeDeploy deployment group to resolve account deployment concurrency limits that have been reached addresses this systemic cause so the log-collection workflow can complete consistently during bursts.

Once logs are in S3, Use Amazon Athena to query the logs directly from the Amazon S3 bucket enables quick, serverless analysis using SQL without additional data movement.

Enable VPC Flow Logs for the subnets hosting the Auto Scaling group and export them to Amazon S3 is not suitable because flow logs capture network metadata, not application logs.

Update the Auto Scaling group health check to point to the correct application port and protocol does not collect or store logs and there is no evidence of a health check misconfiguration.

Turn on access logging at the target group and send logs to an Amazon S3 bucket is not applicable for application log capture; even load balancer access logs would not include the instance-level application logs needed for troubleshooting.

For ephemeral instances, use lifecycle hooks to run last-mile tasks such as log export before termination, store logs in S3, and analyze at scale with Athena; do not confuse network or access logs with application logs.

The most operationally efficient approach is Use the Cognito Post Authentication trigger to invoke Lambda that emails via Amazon SES. This leverages a native Cognito User Pool trigger that fires immediately after a successful sign-in, requires no changes to the client application flow, and avoids introducing extra services or pipelines. A small Lambda function can send the email through Amazon SES directly.

The option Use Amazon EventBridge with CloudTrail sign-in events to trigger Lambda and send via Amazon SES is incorrect because Cognito User Pool end-user sign-ins are not recorded in CloudTrail. CloudTrail captures management events for Cognito, not user authentication events, so this path is unreliable for sign-in notifications.

The option Call an Amazon API Gateway endpoint after login that invokes Lambda to send an SES email works but is less efficient. It requires client changes and adds extra managed services when Cognito can natively invoke Lambda via a trigger.

The option Use the Cognito Custom Message trigger with Lambda and Amazon SES for the login email is incorrect because the Custom Message trigger is designed for verification codes, MFA, and password reset messages. It does not run after a successful authentication.

Look for native Amazon Cognito triggers to keep solutions simple and event-driven. For events that occur immediately after authentication, think Post Authentication trigger. Be cautious with answers that route through CloudTrail or streaming pipelines for user sign-in events; Cognito User Pool sign-ins are not CloudTrail management events.

The best way to eliminate cold-start latency for predictable spikes is Enable provisioned concurrency for the function and configure Application Auto Scaling with a minimum of 2 and a maximum of 120 provisioned instances. Provisioned concurrency keeps a pool of pre-initialized environments ready to serve requests immediately, and scaling it with predictable traffic windows ensures consistently low latency.

Configure reserved concurrency for the function and use Application Auto Scaling to set reserved concurrency to roughly half of observed peak traffic controls maximum concurrency and isolates capacity, but it does not pre-initialize runtimes, so cold starts can still occur.

Increase the Lambda memory size to 8,192 MB to reduce initialization and execution time can reduce duration, but memory alone cannot consistently remove cold-start penalties during bursts.

Set the function’s ephemeral storage to 10,240 MB to cache data in /tmp between invocations affects temporary storage capacity, not initialization, so it will not address cold-start latency.

When you see predictable traffic spikes and complaints about cold starts, think provisioned concurrency; reserved concurrency caps throughput, memory tuning speeds execution, and ephemeral storage helps with caching, but none of these eliminate cold starts.

The best approach is AWS Trusted Advisor Low Utilization EC2 check via EventBridge with a Lambda remediation filtered by tags. Trusted Advisor provides a native, organization-wide check for consistently underutilized EC2 instances when using a Business or Enterprise Support plan. Integrating Trusted Advisor with EventBridge allows you to react to check item changes, and a Lambda function can evaluate resource tags (for shared environments or cost centers) before stopping or terminating instances. This delivers automated, tag-aware, cross-account remediation using managed services without building custom data pipelines.

The option Amazon CloudWatch metrics with EventBridge and Lambda to stop or terminate by tag is not ideal because it relies on manual metric alarms and dashboards rather than the built-in cost-optimization signal provided by Trusted Advisor. While possible, it is more operationally heavy and less purpose-built for cross-account EC2 cost optimization.

The option AWS Cost Anomaly Detection with EventBridge and Lambda to remove idle instances is incorrect because it detects spend anomalies, not sustained low utilization of specific instances. It will not reliably identify which EC2 instances are persistently underutilized.

The option Enroll in AWS Compute Optimizer and auto shutdown via EventBridge and Lambda is not correct for automatic remediation. Compute Optimizer offers rightsizing recommendations but does not natively emit events for automatic shutdown and is intended for informed human decision-making rather than immediate termination workflows.

Look for services that directly surface low-utilization EC2 signals across accounts. Trusted Advisor plus EventBridge is a common remediation pattern on this exam. Watch for distractors that focus on cost anomalies or general monitoring dashboards, which do not inherently target persistent low utilization. When you see tag-based actions across many accounts, think about centralized checks and event-driven remediation with EventBridge and Lambda.