Scenario practice questions

Developers are allowed to create IAM roles for their Lambda functions. However, the security team is concerned that developers could create roles with Administrator access, granting Lambda functions more permissions than the developers themselves have. What IAM feature prevents privilege escalation in this scenario?

Trap 1: Enable IAM Access Analyzer to detect when developers create overly…

IAM Access Analyzer identifies resources accessible from outside the account (external access) or unused permissions (unused access), and generates policy recommendations. It detects after-the-fact and requires manual remediation. It does not prevent a developer from creating an overly permissive role in the first place.

Trap 2: Require MFA for all IAM API calls so developers must…

MFA verifies identity but does not restrict what actions an authenticated identity can take. A developer who has iam:CreateRole permission can still create an Administrator role after MFA verification. Permission boundaries restrict what actions are possible, not who can authenticate.

Trap 3: Enable CloudTrail logging for all IAM API calls and set up a…

CloudTrail logging detects role creation after the fact. An alarm notifies the team but does not block the action. The developer can still create an overly permissive role before any remediation occurs. Permission boundaries prevent the escalation proactively.

A
Attach a permission boundary to each developer IAM user that limits them to creating roles with only the permissions they are allowed to grant
The permission boundary on the developer prevents them from passing permissions they do not have (iam:PassRole with a role whose boundary exceeds their own). When combined with an IAM policy that requires any role they create to have the same boundary attached, privilege escalation is prevented systematically.
B
Enable IAM Access Analyzer to detect when developers create overly permissive roles
Why wrong: IAM Access Analyzer identifies resources accessible from outside the account (external access) or unused permissions (unused access), and generates policy recommendations. It detects after-the-fact and requires manual remediation. It does not prevent a developer from creating an overly permissive role in the first place.
C
Require MFA for all IAM API calls so developers must re-authenticate before creating roles
Why wrong: MFA verifies identity but does not restrict what actions an authenticated identity can take. A developer who has iam:CreateRole permission can still create an Administrator role after MFA verification. Permission boundaries restrict what actions are possible, not who can authenticate.
D
Enable CloudTrail logging for all IAM API calls and set up a CloudWatch alarm for iam:CreateRole events
Why wrong: CloudTrail logging detects role creation after the fact. An alarm notifies the team but does not block the action. The developer can still create an overly permissive role before any remediation occurs. Permission boundaries prevent the escalation proactively.

Question 2easymultiple choice

A company hosts a static website on Amazon S3. Users access the website from around the world. The SysOps administrator needs to deliver content with low latency and support HTTPS with a custom domain. Which AWS service should be used?

Trap 1: AWS Global Accelerator

Optimizes TCP/UDP traffic, not static content caching.

Trap 2: Amazon Route 53 latency-based routing

Directs traffic to region with lowest latency but does not cache content.

Trap 3: S3 Transfer Acceleration

Speeds up uploads to S3, not downloads or global delivery.

A
AWS Global Accelerator
Why wrong: Optimizes TCP/UDP traffic, not static content caching.
B
Amazon CloudFront
CDN with edge caching, HTTPS, and custom domain support.
C
Amazon Route 53 latency-based routing
Why wrong: Directs traffic to region with lowest latency but does not cache content.
D
S3 Transfer Acceleration
Why wrong: Speeds up uploads to S3, not downloads or global delivery.

Question 3easymultiple choice

Refer to the exhibit. A SysOps Administrator runs the above command and sees that an EC2 instance is unhealthy. The health check is configured to check the HTTP endpoint '/health' on port 80. The instance's security group allows inbound HTTP traffic from the ALB's security group. What is the MOST likely cause?

Network Topology

Trap 1: The instance is not associated with the target group.

Incorrect. The instance is associated with the target group; otherwise it would not be listed as unhealthy.

Trap 2: The target group is configured to use port 8080 instead of port 80.

Incorrect. The target group is configured to use port 80, not port 8080.

Trap 3: The security group on the instance does not allow inbound traffic…

Incorrect. The security group on the instance allows inbound HTTP traffic from the ALB's security group, so this is not the cause of the health check failure.

A
The instance is not associated with the target group.
Why wrong: Incorrect. The instance is associated with the target group; otherwise it would not be listed as unhealthy.
B
The application on the instance is not configured to respond to the '/health' path.
Correct. The health check endpoint '/health' is not properly handled by the application, causing the health check to fail.
C
The target group is configured to use port 8080 instead of port 80.
Why wrong: Incorrect. The target group is configured to use port 80, not port 8080.
D
The security group on the instance does not allow inbound traffic from the ALB.
Why wrong: Incorrect. The security group on the instance allows inbound HTTP traffic from the ALB's security group, so this is not the cause of the health check failure.

Question 4mediummultiple choice

A SysOps administrator is troubleshooting slow application performance. The application runs on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer. Amazon CloudWatch metrics show that the average CPU utilization across the instances is below 20%, but the application is still slow. What is the MOST likely cause of the performance issue?

Trap 1: The Auto Scaling group is scaling too aggressively, causing…

Auto Scaling thrashing occurs when scaling policies overreact to short-lived spikes, causing frequent launch and termination cycles. This would show up as volatile CPU utilization, repeated CloudWatch Alarm state flapping, and a constantly changing instance count, rather than a steady sub-20% average CPU. Since the problem describes consistently low CPU, a thrashing Auto Scaling group is not the cause, and the symptom would instead be tied to a resource the application is waiting on.

Trap 2: The Application Load Balancer has a sticky session configuration…

Sticky sessions (session affinity) pin a client to a specific target for the life of a session, which can cause uneven load distribution if session durations are long or clients are concentrated. However, such imbalance would typically produce a mix of instances with high CPU utilization and others with near-idle CPU, so the fleet-wide average would not uniformly sit below 20%. The scenario gives no indication of skewed per-instance metrics or hot spots, so this configuration is unlikely to explain the persistent slow performance across all application nodes.

Trap 3: The EC2 instances are using burstable performance and have…

Incorrect. If burstable instances exhaust CPU credits, they are throttled to baseline performance, which would still result in low CPU utilization but might explain slow performance. However, the most likely cause given common scenarios is a database bottleneck, not CPU credit exhaustion, because low CPU is more typically associated with waiting on external resources.

A
The Auto Scaling group is scaling too aggressively, causing thrashing.
Why wrong: Auto Scaling thrashing occurs when scaling policies overreact to short-lived spikes, causing frequent launch and termination cycles. This would show up as volatile CPU utilization, repeated CloudWatch Alarm state flapping, and a constantly changing instance count, rather than a steady sub-20% average CPU. Since the problem describes consistently low CPU, a thrashing Auto Scaling group is not the cause, and the symptom would instead be tied to a resource the application is waiting on.
B
The Application Load Balancer has a sticky session configuration that is not distributing traffic evenly.
Why wrong: Sticky sessions (session affinity) pin a client to a specific target for the life of a session, which can cause uneven load distribution if session durations are long or clients are concentrated. However, such imbalance would typically produce a mix of instances with high CPU utilization and others with near-idle CPU, so the fleet-wide average would not uniformly sit below 20%. The scenario gives no indication of skewed per-instance metrics or hot spots, so this configuration is unlikely to explain the persistent slow performance across all application nodes.
C
The application database is under-provisioned and is causing slow query responses.
An under-provisioned database can directly cause slow application responses while keeping EC2 CPU low because the application nodes spend most of their time blocked on database queries. Inadequate IOPS, insufficient memory for the buffer cache, or a suboptimal schema can lead to high query latency and connection queueing, which is not reflected in the web-tier CloudWatch CPU metric. The low average CPU is a classic sign of an external dependency bottleneck, making the database the most plausible root cause for the degraded user experience.
D
The EC2 instances are using burstable performance and have exhausted their CPU credits.
Why wrong: Incorrect. If burstable instances exhaust CPU credits, they are throttled to baseline performance, which would still result in low CPU utilization but might explain slow performance. However, the most likely cause given common scenarios is a database bottleneck, not CPU credit exhaustion, because low CPU is more typically associated with waiting on external resources.

Read the full NAT/PAT explanation →

Question 5mediummultiple choice

A SysOps administrator is configuring a VPC with a public subnet and a private subnet. The private subnet needs to access the internet to download patches. The administrator creates a NAT Gateway in the public subnet and updates the private subnet route table. However, instances in the private subnet cannot reach the internet. What is the most likely cause?

Trap 1: The network ACL for the private subnet blocks outbound traffic.

While a network ACL could block traffic, the most likely cause is missing Internet Gateway route, not NACL configuration.

Trap 2: The NAT Gateway does not have an Elastic IP address attached.

A NAT Gateway does need an Elastic IP, but the problem states the administrator created the NAT Gateway; the missing IGW route is the more common oversight.

Trap 3: The security group associated with the NAT Gateway blocks outbound…

Security groups do not apply to NAT Gateways; they apply to instances. This is not the cause.

A
The network ACL for the private subnet blocks outbound traffic.
Why wrong: While a network ACL could block traffic, the most likely cause is missing Internet Gateway route, not NACL configuration.
B
The route table for the public subnet does not have a route to an Internet Gateway.
This is correct: the public subnet's route table must have a route to an Internet Gateway for the NAT Gateway to send traffic to the internet.
C
The NAT Gateway does not have an Elastic IP address attached.
Why wrong: A NAT Gateway does need an Elastic IP, but the problem states the administrator created the NAT Gateway; the missing IGW route is the more common oversight.
D
The security group associated with the NAT Gateway blocks outbound traffic.
Why wrong: Security groups do not apply to NAT Gateways; they apply to instances. This is not the cause.