Scenario practice questions

A company is running a batch processing job on Amazon EMR that writes results to an Amazon S3 bucket. The job runs daily and takes about 2 hours. The DevOps team wants to be alerted if the job fails or takes longer than 3 hours. Which solution is the MOST cost-effective and operationally efficient?

Trap 1: Configure Amazon Simple Notification Service (SNS) directly from…

Configuring SNS directly from the EMR job means embedding AWS SDK calls in the application code itself, which couples business logic to notification logic and requires custom error handling. EMR does not provide a native, managed hook to publish to SNS on cluster completion, so if the job fails before reaching the publish statement, no notification is sent. Additionally, this approach still does not inherently calculate or compare job duration against a threshold—it only sends raw completion signals.

Trap 2: Create a CloudWatch alarm on the EMR cluster's EC2 instance…

A CloudWatch alarm on CPUUtilization is fundamentally mismatched because CPU metrics reflect resource consumption, not elapsed job time, and a job may run for over three hours with low average CPU (e.g., while waiting for external dependencies or during shuffle bottlenecks). Conversely, a short-lived but compute-intensive job could spike CPU and trigger a false positive. Furthermore, an EMR cluster has multiple EC2 instances, so you would have to decide which instance's metric to alarm on, and none of these metrics indicate whether the job has actually completed, let alone exceeded a specific duration threshold.

Trap 3: Use Amazon CloudWatch Logs to monitor the job's log stream and…

This approach requires EMR logs to be streamed to CloudWatch Logs, which is not enabled by default—you must manually install and configure the CloudWatch agent on each core and task instance, adding operational overhead. Even with logs in place, a metric filter matching 'FAILED' messages only captures explicit failure keywords; it cannot detect a successful job that ran for over three hours, nor does it provide the job's start and end times needed to compute duration. Therefore, it fails both to measure duration and to alert on jobs that exceed the time limit but complete without a FAILED log line.

A
Configure Amazon Simple Notification Service (SNS) directly from the EMR job to send notifications on completion.
Why it fails: Configuring SNS directly from the EMR job means embedding AWS SDK calls in the application code itself, which couples business logic to notification logic and requires custom error handling. EMR does not provide a native, managed hook to publish to SNS on cluster completion, so if the job fails before reaching the publish statement, no notification is sent. Additionally, this approach still does not inherently calculate or compare job duration against a threshold—it only sends raw completion signals.
B
Use Amazon CloudWatch Events to trigger an AWS Lambda function when the EMR cluster changes to 'TERMINATED' state, then check the job duration and send an alert if it exceeded 3 hours.
This is correct because Amazon EventBridge (formerly CloudWatch Events) can natively capture EMR cluster state-change events, such as the transition to TERMINATED, and invoke a Lambda function without any polling or custom code. The Lambda function can call emr:describeCluster to obtain the cluster's start and end times, compute the total runtime, and post an SNS message only when the duration exceeds three hours. This event-driven architecture is cost-effective, serverless, and decoupled, making it the recommended pattern for alerting on abnormal job completion times.
C
Create a CloudWatch alarm on the EMR cluster's EC2 instance CPUUtilization metric to detect abnormal runtime.
Why it fails: A CloudWatch alarm on CPUUtilization is fundamentally mismatched because CPU metrics reflect resource consumption, not elapsed job time, and a job may run for over three hours with low average CPU (e.g., while waiting for external dependencies or during shuffle bottlenecks). Conversely, a short-lived but compute-intensive job could spike CPU and trigger a false positive. Furthermore, an EMR cluster has multiple EC2 instances, so you would have to decide which instance's metric to alarm on, and none of these metrics indicate whether the job has actually completed, let alone exceeded a specific duration threshold.
D
Use Amazon CloudWatch Logs to monitor the job's log stream and create a metric filter for 'FAILED' messages.
Why it fails: This approach requires EMR logs to be streamed to CloudWatch Logs, which is not enabled by default—you must manually install and configure the CloudWatch agent on each core and task instance, adding operational overhead. Even with logs in place, a metric filter matching 'FAILED' messages only captures explicit failure keywords; it cannot detect a successful job that ran for over three hours, nor does it provide the job's start and end times needed to compute duration. Therefore, it fails both to measure duration and to alert on jobs that exceed the time limit but complete without a FAILED log line.

Question 2hardmulti select

A company is using AWS Elastic Beanstalk with a custom platform. The DevOps team wants to automate the creation of a new platform version whenever changes are pushed to a Git repository. The pipeline should run tests, build the platform, and then update the Elastic Beanstalk environment to use the new platform version. Which services should be used together to achieve this? (Choose THREE.)

Trap 1: AWS CloudFormation

AWS CloudFormation is an infrastructure-as-code service that declaratively provisions AWS resources; it cannot run the arbitrary bash scripts or Packer commands required to build a custom Elastic Beanstalk platform AMI. Even if you model the environment as a stack, CloudFormation would only create or update resources after an AMI already exists, leaving the actual image-building step outside its capability.

Trap 2: AWS CodeDeploy

AWS CodeDeploy is an application-deployment service that pushes your application code to running EC2 instances (or Lambda/ECS) and manages lifecycle hooks during a deployment. It has no concept of building a base machine image or platform AMI, and it cannot be used to package an Elastic Beanstalk platform. Custom platform creation happens before instances exist, so CodeDeploy, which operates on already-provisioned infrastructure, is not applicable here.

A
AWS CloudFormation
Why it fails: AWS CloudFormation is an infrastructure-as-code service that declaratively provisions AWS resources; it cannot run the arbitrary bash scripts or Packer commands required to build a custom Elastic Beanstalk platform AMI. Even if you model the environment as a stack, CloudFormation would only create or update resources after an AMI already exists, leaving the actual image-building step outside its capability.
B
AWS CodeBuild
AWS CodeBuild is a fully managed build service that can execute a custom build spec in a disposable compute environment. To create a custom Elastic Beanstalk platform, CodeBuild can run the Packer templates and platform hooks that produce the platform's AMI, making it the correct AWS service for the build itself. Its ephemeral environment, clean snapshots, and retryable builds make it well suited for repeatable platform builds.
C
AWS CodePipeline
AWS CodePipeline is an orchestration-only service that models stages and transitions in a release workflow; it does not perform build or packaging operations itself. In a custom-Elastic Beanstalk platform workflow, CodePipeline can be the outer CI/CD layer that invokes CodeBuild as a build action (which runs Packer), then deploys the resulting AMI or platform version. Thus it plays a supporting role, giving visibility, triggers, and approvals around the build, but it depends on CodeBuild or another action provider to do the actual work.
D
HashiCorp Packer (run in CodeBuild)
HashiCorp Packer is the tool that actually creates the machine image for a custom Elastic Beanstalk platform; a Packer template specifies the source AMI, provisioners (such as shell scripts or Ansible), and virtual-builder configuration. When Packer runs inside CodeBuild, the two give an end-to-end, code-defined path from base Amazon Linux AMI to a ready-to-use platform AMI. This is why the combination is a correct answer: Packer is the image builder, and CodeBuild is the AWS service that executes it.
E
AWS CodeDeploy
Why it fails: AWS CodeDeploy is an application-deployment service that pushes your application code to running EC2 instances (or Lambda/ECS) and manages lifecycle hooks during a deployment. It has no concept of building a base machine image or platform AMI, and it cannot be used to package an Elastic Beanstalk platform. Custom platform creation happens before instances exist, so CodeDeploy, which operates on already-provisioned infrastructure, is not applicable here.

Question 3hardmultiple choice

Refer to the exhibit. The deployment succeeded but the application fails. What is the MOST likely cause?

Exhibit

CodePipeline execution history:
Pipeline: MyPipeline
Date: 2024-03-01
Stage: Deploy
Action: DeployToECS

Execution ID: e-123456789
Status: Succeeded

Revision: commit SHA abc123
Deployment details:
  - ECS service: my-service
  - Task definition: my-task:12
  - Desired count: 2
  - Running count: 2
  - Pending count: 0

After deployment, application health checks fail. Rolling back to previous revision (task definition my-task:11) resolves the issue.

CloudWatch Logs from ECS tasks:
[ERROR] Failed to connect to database: TimeoutError: connect ETIMEDOUT 10.0.0.5:5432

Trap 1: The CodePipeline deployment action uses the wrong cluster.

The deployment action references the cluster in the ECS service definition, and an incorrect cluster name or ARN would cause the CodePipeline action to fail before any tasks are placed. Since the pipeline completed successfully and tasks are running, the cluster reference is demonstrably valid. A cluster mismatch would also surface as a ResourceNotFoundException or service discovery failure, not a database timeout.

Trap 2: The ECS service is not registered with a target group.

If the ECS service had no target group registration, the ALB would be unable to route traffic to the tasks and would return HTTP 503 Service Unavailable before any application code executes. The observed database timeout proves the container received incoming traffic and attempted to make an outbound connection, so the service must be correctly wired to a target group. Moreover, a missing target group registration would cause the deployment to fail health checks, not allow a green deployment.

Trap 3: The database is not available in the same Availability Zone.

An Availability Zone mismatch between the database and the ECS tasks does not produce a connection timeout, because VPC networking permits cross-AZ traffic by default. Even if tasks and the DB are in different AZs, the TCP connection succeeds unless a security group or NACL blocks it, and any added latency would be minimal. Additionally, managed database services like RDS/Aurora replicate across AZs transparently, so an AZ mismatch is not a logical configuration error that would cause this symptom.

A
The CodePipeline deployment action uses the wrong cluster.
Why it fails: The deployment action references the cluster in the ECS service definition, and an incorrect cluster name or ARN would cause the CodePipeline action to fail before any tasks are placed. Since the pipeline completed successfully and tasks are running, the cluster reference is demonstrably valid. A cluster mismatch would also surface as a ResourceNotFoundException or service discovery failure, not a database timeout.
B
The new task definition has a misconfigured database connection string or security group.
A database connection timeout to the database IP address strongly indicates the new task definition is passing an invalid connection string or is associated with a security group that blocks the database port. The application container is starting and attempting to open a TCP connection, but the destination either rejects or silently drops it — exactly what a bad host, port, or restrictive inbound rule produces. This is an application-level configuration defect in the task definition that does not prevent the task from launching, which is why the deployment can still be marked successful.
C
The ECS service is not registered with a target group.
Why it fails: If the ECS service had no target group registration, the ALB would be unable to route traffic to the tasks and would return HTTP 503 Service Unavailable before any application code executes. The observed database timeout proves the container received incoming traffic and attempted to make an outbound connection, so the service must be correctly wired to a target group. Moreover, a missing target group registration would cause the deployment to fail health checks, not allow a green deployment.
D
The database is not available in the same Availability Zone.
Why it fails: An Availability Zone mismatch between the database and the ECS tasks does not produce a connection timeout, because VPC networking permits cross-AZ traffic by default. Even if tasks and the DB are in different AZs, the TCP connection succeeds unless a security group or NACL blocks it, and any added latency would be minimal. Additionally, managed database services like RDS/Aurora replicate across AZs transparently, so an AZ mismatch is not a logical configuration error that would cause this symptom.

Question 4hardmultiple choice

A company runs a critical application on Amazon ECS with Fargate. They use blue/green deployments via AWS CodeDeploy. During a recent deployment, the new task set failed health checks and CodeDeploy automatically rolled back. However, the old task set also became unhealthy shortly after rollback. What could explain this?

Trap 1: The CloudWatch alarm that triggered the rollback also stopped the…

CloudWatch alarms are monitoring-only; they can trigger CodeDeploy to roll back, but they do not directly stop ECS tasks or task sets. The alarm simply sends an SNS notification or event that CodeDeploy interprets as a failure signal. Stopping a task set is a deployment-lifecycle action performed by CodeDeploy or Amazon ECS, not by CloudWatch itself. Therefore, the alarm stopping the old task set is not the cause of the broken old version.

Trap 2: CodeDeploy did not drain connections from the Application Load…

During a CodeDeploy blue/green deployment on ECS, the ALB's connection draining (deregistration delay) is automatically configured on the target group, so connections from the ALB to the old task set are drained before target deregistration. The rollback failure was not due to missing connection draining; rather, the old tasks were re-registered and unhealthy because the application couldn't start. Connection draining only impacts in-flight requests, not the runtime health of old application code after a database schema change. Thus, this is not the root cause.

Trap 3: The ECS service auto-scaling policy reduced the desired count of…

ECS Service Auto Scaling adjusts the service's desired count at the service level, but during a blue/green deployment, CodeDeploy owns the task sets and the traffic shift. Auto-scaling policies do not directly modify the desired count of a specific task set created for a deployment, and they are typically suspended or overridden by the deployment process. Reducing the old task set count would not cause the old application to crash or become unhealthy; it would only change capacity. Hence, auto-scaling is an unlikely contributor here.

A
The CloudWatch alarm that triggered the rollback also stopped the old task set.
Why it fails: CloudWatch alarms are monitoring-only; they can trigger CodeDeploy to roll back, but they do not directly stop ECS tasks or task sets. The alarm simply sends an SNS notification or event that CodeDeploy interprets as a failure signal. Stopping a task set is a deployment-lifecycle action performed by CodeDeploy or Amazon ECS, not by CloudWatch itself. Therefore, the alarm stopping the old task set is not the cause of the broken old version.
B
CodeDeploy did not drain connections from the Application Load Balancer before terminating the old task set.
Why it fails: During a CodeDeploy blue/green deployment on ECS, the ALB's connection draining (deregistration delay) is automatically configured on the target group, so connections from the ALB to the old task set are drained before target deregistration. The rollback failure was not due to missing connection draining; rather, the old tasks were re-registered and unhealthy because the application couldn't start. Connection draining only impacts in-flight requests, not the runtime health of old application code after a database schema change. Thus, this is not the root cause.
C
The ECS service auto-scaling policy reduced the desired count of the old task set during the deployment.
Why it fails: ECS Service Auto Scaling adjusts the service's desired count at the service level, but during a blue/green deployment, CodeDeploy owns the task sets and the traffic shift. Auto-scaling policies do not directly modify the desired count of a specific task set created for a deployment, and they are typically suspended or overridden by the deployment process. Reducing the old task set count would not cause the old application to crash or become unhealthy; it would only change capacity. Hence, auto-scaling is an unlikely contributor here.
D
The new application version changed the database schema, which broke the old version after rollback.
When the new version applied a forward-only database schema migration, the schema changed irreversibly for the running environment. CodeDeploy rolled back the ECS task set to the old code, but that old code cannot understand the new schema, causing errors, failed health checks, and a broken application. This is the recognized cause: database changes are not automatically rolled back, so they break the previous version. The fix is to implement reverse migrations or use an expansion-contraction pattern.

Question 5mediummultiple choice

A company uses AWS Elastic Beanstalk to deploy a web application. The environment is running behind an Application Load Balancer. The DevOps team notices that during deployments, the new application version fails health checks and the deployment rolls back. The team wants to reduce deployment time while maintaining safety. Which configuration change should the engineer recommend?

Trap 1: Increase the number of EC2 instances in the environment.

Increasing the number of EC2 instances only adds capacity; it does not alter the deployment method. During a rolling or all-at-once update, every instance is still replaced sequentially or simultaneously, so a faulty new version can impact the entire fleet regardless of instance count. The immutable policy, not instance count, provides the required safe deployment by launching a fresh environment before switching traffic.

Trap 2: Use the all-at-once deployment policy.

The all-at-once deployment policy terminates all existing instances and launches new ones in a single step. It performs no health checks before serving traffic, so if the new application version fails, the entire environment becomes unavailable. Immutable deployments avoid this by validating the new fleet's health before any traffic is shifted, whereas all-at-once exposes users to immediate risk.

Trap 3: Increase the rolling update batch size to 100%.

Setting the rolling update batch size to 100% causes all instances to be replaced at once, with no opportunity for health checks between batches. This effectively replicates the risk of an all-at-once deployment, meaning a faulty version will corrupt the entire environment simultaneously. Immutable deployments are preferable because they isolate the new version in a separate fleet and only route traffic after successful health verification.

A
Increase the number of EC2 instances in the environment.
Why it fails: Increasing the number of EC2 instances only adds capacity; it does not alter the deployment method. During a rolling or all-at-once update, every instance is still replaced sequentially or simultaneously, so a faulty new version can impact the entire fleet regardless of instance count. The immutable policy, not instance count, provides the required safe deployment by launching a fresh environment before switching traffic.
B
Use the all-at-once deployment policy.
Why it fails: The all-at-once deployment policy terminates all existing instances and launches new ones in a single step. It performs no health checks before serving traffic, so if the new application version fails, the entire environment becomes unavailable. Immutable deployments avoid this by validating the new fleet's health before any traffic is shifted, whereas all-at-once exposes users to immediate risk.
C
Change the deployment policy to immutable.
Changing the deployment policy to immutable launches a fully new Auto Scaling group with the new application version while the old group continues serving traffic. Once the new instances pass health checks, Elastic Beanstalk swaps the environment's capacity to the new group, providing both safety and minimal downtime. This is the correct choice because it verifies the deployment before cutting over, unlike rolling or all-at-once strategies that update existing instances in place.
D
Increase the rolling update batch size to 100%.
Why it fails: Setting the rolling update batch size to 100% causes all instances to be replaced at once, with no opportunity for health checks between batches. This effectively replicates the risk of an all-at-once deployment, meaning a faulty version will corrupt the entire environment simultaneously. Immutable deployments are preferable because they isolate the new version in a separate fleet and only route traffic after successful health verification.

Question 6easymultiple choice

A company runs a web application on EC2 instances behind an Application Load Balancer. The application experiences intermittent failures due to a single Availability Zone failing. Which solution is MOST resilient and cost-effective?

Trap 1: Use a larger instance type in the same Availability Zone

Scaling vertically to a larger instance type within the same Availability Zone does nothing to eliminate the single point of failure represented by that AZ. If the AZ experiences an outage, or a hardware failure impacts that specific instance, the application becomes unavailable regardless of the instance's size. High availability requires redundancy across independent failure domains, not simply more compute capacity in the same location.

Trap 2: Use an Auto Scaling group with a single instance in each of three…

Using a Network Load Balancer introduces an unnecessary Layer 4 abstraction for an HTTP web application, and it cannot perform the URL path or host-based routing that an ALB provides. Additionally, maintaining one instance per AZ across three AZs is over-provisioned and more costly than a two-AZ ALB architecture; an ALB with healthy targets in two AZs already meets typical high-availability requirements without the extra complexity and expense of an NLB.

Trap 3: Migrate to a single larger instance in a different region

Migrating to a single larger instance in a different region simply relocates the single point of failure rather than eliminating it, and it introduces significant cross-region network latency between users and the application. This approach also incurs higher data transfer costs and complexity around regional failover, without any benefit for the web application's immediate availability. It is not a valid high-availability strategy.

A
Use a larger instance type in the same Availability Zone
Why it fails: Scaling vertically to a larger instance type within the same Availability Zone does nothing to eliminate the single point of failure represented by that AZ. If the AZ experiences an outage, or a hardware failure impacts that specific instance, the application becomes unavailable regardless of the instance's size. High availability requires redundancy across independent failure domains, not simply more compute capacity in the same location.
B
Use an Auto Scaling group with a single instance in each of three Availability Zones and a Network Load Balancer
Why it fails: Using a Network Load Balancer introduces an unnecessary Layer 4 abstraction for an HTTP web application, and it cannot perform the URL path or host-based routing that an ALB provides. Additionally, maintaining one instance per AZ across three AZs is over-provisioned and more costly than a two-AZ ALB architecture; an ALB with healthy targets in two AZs already meets typical high-availability requirements without the extra complexity and expense of an NLB.
C
Migrate to a single larger instance in a different region
Why it fails: Migrating to a single larger instance in a different region simply relocates the single point of failure rather than eliminating it, and it introduces significant cross-region network latency between users and the application. This approach also incurs higher data transfer costs and complexity around regional failover, without any benefit for the web application's immediate availability. It is not a valid high-availability strategy.
D
Deploy EC2 instances across two Availability Zones and configure the ALB to distribute traffic
Deploying EC2 instances across two Availability Zones behind an Application Load Balancer provides both fault isolation and active load balancing. The ALB performs health checks, routes traffic only to healthy instances, and can distribute requests across both AZs, so if one entire AZ becomes unavailable, the other continues to serve traffic. This is the standard architecture for achieving regional high availability with an HTTP web application.

Question 7hardmultiple choice

An incident response team is analyzing an IAM policy attached to a role used by a forensic tool. The tool needs to create snapshots of EBS volumes during an incident. However, when the tool runs from an IP address in the 203.0.113.0/24 range, the CreateSnapshot API call fails with an access denied error. What is the MOST likely cause?

Exhibit

Refer to the exhibit.
```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeVolumes",
        "ec2:CreateSnapshot",
        "ec2:CreateTags"
      ],
      "Resource": "*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "203.0.113.0/24",
            "198.51.100.0/24"
          ]
        },
        "Bool": {
          "aws:ViaAWSService": "false"
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": "ec2:DeleteSnapshot",
      "Resource": "arn:aws:ec2:*:*:snapshot/*",
      "Condition": {
        "StringNotEquals": {
          "aws:SourceIdentity": "admin"
        }
      }
    }
  ]
}
```

Trap 1: The policy does not grant ec2:CreateSnapshot on specific resource…

Resource ARNs are not the issue because the policy's Allow statement grants ec2:CreateSnapshot on '*', which matches the snapshot ARN the request targets. In IAM, Resource '*' covers all possible resource-specific ARNs, so if the call were denied solely on resource scope, the Allow would be sufficient. The request fails instead because the condition key aws:ViaAWSService does not evaluate to the required value, making the Allow statement itself inapplicable.

Trap 2: The Deny statement explicitly denies ec2:DeleteSnapshot, but the…

IAM policy evaluation is action-specific: a Deny statement that names ec2:DeleteSnapshot is only considered when the requested API action is exactly ec2:DeleteSnapshot. It cannot affect an ec2:CreateSnapshot call, so it is not part of the evaluation path for the reported error. The failure must be caused by a statement that actually targets CreateSnapshot or by missing applicable allows.

Trap 3: The source IP address 203.0.113.0/24 is not included in the…

The condition block with IpAddress includes 203.0.113.0/24, so the request's source IP satisfies that part of the statement; there is no implicit deny coming from the IP condition. An implicit deny only occurs when no statement both allows the action and has all of its conditions satisfied, and here the IP is not the failing condition. The real mismatch is that aws:ViaAWSService evaluates to true, not false.

A
The policy does not grant ec2:CreateSnapshot on specific resource ARNs, only on all resources.
Why it fails: Resource ARNs are not the issue because the policy's Allow statement grants ec2:CreateSnapshot on '*', which matches the snapshot ARN the request targets. In IAM, Resource '*' covers all possible resource-specific ARNs, so if the call were denied solely on resource scope, the Allow would be sufficient. The request fails instead because the condition key aws:ViaAWSService does not evaluate to the required value, making the Allow statement itself inapplicable.
B
The aws:ViaAWSService condition is set to false, but the tool is invoked by an AWS service such as Systems Manager, making the condition evaluate to true and denying access.
The aws:ViaAWSService global condition key is true when an AWS service, such as Systems Manager, makes the API call on the principal's behalf rather than the principal making a direct call. The policy's condition requires this key to be false, so when the tool is invoked via Systems Manager the actual value is true and the Allow statement does not match. With no other matching Allow, the request is implicitly denied, which is exactly the error observed.
C
The Deny statement explicitly denies ec2:DeleteSnapshot, but the error is for CreateSnapshot, so it is unrelated.
Why it fails: IAM policy evaluation is action-specific: a Deny statement that names ec2:DeleteSnapshot is only considered when the requested API action is exactly ec2:DeleteSnapshot. It cannot affect an ec2:CreateSnapshot call, so it is not part of the evaluation path for the reported error. The failure must be caused by a statement that actually targets CreateSnapshot or by missing applicable allows.
D
The source IP address 203.0.113.0/24 is not included in the Condition block, so access is implicitly denied.
Why it fails: The condition block with IpAddress includes 203.0.113.0/24, so the request's source IP satisfies that part of the statement; there is no implicit deny coming from the IP condition. An implicit deny only occurs when no statement both allows the action and has all of its conditions satisfied, and here the IP is not the failing condition. The real mismatch is that aws:ViaAWSService evaluates to true, not false.

Question 8easymultiple choice

A company's DevOps team uses AWS Config to monitor resource compliance. They have created a custom AWS Config rule that triggers an AWS Lambda function to evaluate whether EC2 instances have the 'Environment' tag with value 'Production' or 'Staging'. The rule is set to evaluate resources on configuration changes. However, the team notices that the rule does not trigger when an EC2 instance is launched. The Lambda function's IAM role has the necessary permissions to describe EC2 instances. The CloudWatch Logs for the Lambda function show that it is not being invoked. What is the MOST likely reason?

Trap 1: The Lambda function's IAM role does not have permission to write to…

The Lambda function's IAM role lacking CloudWatch Logs permissions would only matter once the function is executed. Since the function is not being invoked at all (the rule is not triggering evaluation for newly launched EC2 instances), no log writes are attempted. Therefore, missing log permissions cannot cause the reported failure; the root cause lies upstream in the rule's trigger and scope configuration. If the function were invoked but failed, then log permission issues could be relevant, but that is not the case here.

Trap 2: The AWS Config rule is set to evaluate resources periodically, not…

The prompt states the rule is configured to evaluate on configuration changes, meaning it should react to EC2 instance launches via CloudTrail or Config notifications. A periodic trigger, by contrast, runs only on a fixed schedule (e.g., every 6 hours) and would not detect a launch until the next scheduled evaluation. Because the question explicitly indicates the rule uses configuration-change triggers, this option contradicts the given scenario. Thus, this is not the cause; the real problem is that the rule's scope excludes AWS::EC2::Instance resources.

Trap 3: The custom rule must be deployed using AWS CloudFormation to be…

AWS Config custom rules can be created through the AWS Management Console, AWS CLI, AWS SDK, or AWS CloudFormation; there is no requirement to use CloudFormation. Once a custom rule is created and associated with a Lambda function, the rule is active and will be evaluated based on its trigger configuration, regardless of the deployment method. CloudFormation simply automates the deployment of the rule and its associated Lambda function, but omitting it does not leave the rule inactive. Therefore, this option is incorrect; the rule's activation is not tied to CloudFormation.

A
The Lambda function's IAM role does not have permission to write to CloudWatch Logs.
Why it fails: The Lambda function's IAM role lacking CloudWatch Logs permissions would only matter once the function is executed. Since the function is not being invoked at all (the rule is not triggering evaluation for newly launched EC2 instances), no log writes are attempted. Therefore, missing log permissions cannot cause the reported failure; the root cause lies upstream in the rule's trigger and scope configuration. If the function were invoked but failed, then log permission issues could be relevant, but that is not the case here.
B
The AWS Config rule is set to evaluate resources periodically, not on configuration changes.
Why it fails: The prompt states the rule is configured to evaluate on configuration changes, meaning it should react to EC2 instance launches via CloudTrail or Config notifications. A periodic trigger, by contrast, runs only on a fixed schedule (e.g., every 6 hours) and would not detect a launch until the next scheduled evaluation. Because the question explicitly indicates the rule uses configuration-change triggers, this option contradicts the given scenario. Thus, this is not the cause; the real problem is that the rule's scope excludes AWS::EC2::Instance resources.
C
The AWS Config rule is not configured to trigger on AWS::EC2::Instance resources.
For a custom AWS Config rule to evaluate a resource on configuration changes, the rule's scope must include that resource type. If the rule is defined without AWS::EC2::Instance in its 'Resource types' scope (or if it is scoped to a specific tag/resource ID that does not match), AWS Config will not send evaluation events to the Lambda function for EC2 instances. In this scenario, the rule has the correct trigger type (change) but its scope does not cover EC2 instances, so Config never invokes the Lambda function on instance launch. This is the exact cause of the DevOps team's issue.
D
The custom rule must be deployed using AWS CloudFormation to be active.
Why it fails: AWS Config custom rules can be created through the AWS Management Console, AWS CLI, AWS SDK, or AWS CloudFormation; there is no requirement to use CloudFormation. Once a custom rule is created and associated with a Lambda function, the rule is active and will be evaluated based on its trigger configuration, regardless of the deployment method. CloudFormation simply automates the deployment of the rule and its associated Lambda function, but omitting it does not leave the rule inactive. Therefore, this option is incorrect; the rule's activation is not tied to CloudFormation.

Question 9hardmultiple choice

A company runs a stateful web application on EC2 instances in an Auto Scaling group. The application uses an Application Load Balancer (ALB) and an Amazon ElastiCache Redis cluster. Users report that after a scaling event, they are logged out and lose session data. What is the most likely cause?

Trap 1: The ALB health check interval is too short, causing healthy…

Even if the ALB health check interval is set too aggressively and temporarily marks an instance as unhealthy, that only affects the load balancer's routing decisions for new requests. It does not delete or invalidate session data, which is stored in the shared ElastiCache layer. The next request is simply sent to a healthy instance, which retrieves the same session from ElastiCache, so user experience is unaffected.

Trap 2: The ElastiCache cluster is configured with in-transit encryption,…

In-transit encryption on ElastiCache uses TLS to protect data moving between the application and the cache cluster. It does not modify, corrupt, or invalidate any stored session tokens; those tokens remain readable once the TLS connection is established. A session token would only become invalid if the application fails to connect or if the token expires, not because encryption is enabled. Therefore, this configuration cannot explain a sudden loss of all sessions.

Trap 3: The Auto Scaling group is using a termination policy that…

An Auto Scaling termination policy that selects the oldest instance would remove that EC2 instance, but the active sessions are not held in the instance's local memory—they are persisted in ElastiCache. When the instance is terminated, the ALB routes new requests to a different instance, which loads the same session key from ElastiCache. Since ElastiCache is independent of the EC2 instance lifecycle, terminating any instance, regardless of age, does not destroy session data.

A
The ALB health check interval is too short, causing healthy instances to be marked unhealthy
Why it fails: Even if the ALB health check interval is set too aggressively and temporarily marks an instance as unhealthy, that only affects the load balancer's routing decisions for new requests. It does not delete or invalidate session data, which is stored in the shared ElastiCache layer. The next request is simply sent to a healthy instance, which retrieves the same session from ElastiCache, so user experience is unaffected.
B
The ElastiCache cluster is configured with in-transit encryption, causing session tokens to be invalidated
Why it fails: In-transit encryption on ElastiCache uses TLS to protect data moving between the application and the cache cluster. It does not modify, corrupt, or invalidate any stored session tokens; those tokens remain readable once the TLS connection is established. A session token would only become invalid if the application fails to connect or if the token expires, not because encryption is enabled. Therefore, this configuration cannot explain a sudden loss of all sessions.
C
The Auto Scaling group is using a termination policy that terminates the oldest instance first, which holds active sessions
Why it fails: An Auto Scaling termination policy that selects the oldest instance would remove that EC2 instance, but the active sessions are not held in the instance's local memory—they are persisted in ElastiCache. When the instance is terminated, the ALB routes new requests to a different instance, which loads the same session key from ElastiCache. Since ElastiCache is independent of the EC2 instance lifecycle, terminating any instance, regardless of age, does not destroy session data.
D
The ElastiCache cluster is not configured for Multi-AZ and a node failure caused all sessions to be lost
An ElastiCache cluster without Multi-AZ deployment means there is only a single primary node with no replica in another Availability Zone. If that node fails, any in-memory session data is lost because there is no replication or automatic failover to a secondary node. Even if ElastiCache replaces the node, the replacement starts empty unless persistence/backups were configured. This exactly matches the symptom of all users being logged out simultaneously.