Refer to the Exhibit Practice Questions

The user will be allowed because the condition only applies if the tag exists

Why it fails: This statement is incorrect because the condition is not optional. In IAM policy evaluation, a condition key must be satisfied for the allow to apply; if the resource lacks the aws:ResourceTag/Environment tag, the condition evaluates to false rather than being skipped. Since the condition is part of the allow statement, a false condition makes the allow inapplicable, so the request is implicitly denied.

The user will be allowed because the resource ARN includes a wildcard

Why it fails: The wildcard in the Resource ARN only determines which resources the statement can apply to; it does not relax any condition requirements. Even if the ARN pattern matches the instance, the statement still requires the condition aws:ResourceTag/Environment = 'Production' to evaluate true. Because the instance lacks that tag, the allow statement does not grant the action. Thus a resource ARN wildcard does not change the outcome.

The user will be allowed because the policy does not explicitly deny the action

Why it fails: IAM uses an explicit default-deny model, so an action is permitted only when an applicable allow statement matches the request. The absence of an explicit deny does not create permission; the allow statement in the policy must fully match, including satisfying all conditions. Here the condition fails, so no allow applies and the action is denied implicitly. Therefore the statement is wrong.

The S3 bucket has server-side encryption enabled.

Why it fails: Server-side encryption (SSE) protects data at rest in S3, but it has no effect on the IAM authorization process for uploading objects. When an EC2 instance attempts an s3:PutObject, S3 checks the caller's IAM identity (or the bucket policy) for the required permission before considering encryption settings. An encrypted bucket still accepts uploads from any principal with valid write permissions, so enabling SSE does not block the upload; it only encrypts the object after the request is authorized.

The policy does not include s3:GetObject permission.

Why it fails: The s3:GetObject permission grants read access to objects, whereas the upload operation requires s3:PutObject. The IAM policy attached to the role would need s3:PutObject (and possibly s3:ListBucket for some APIs), but the failure to upload is not due to a missing read permission. If anything, the policy might be missing s3:PutObject, but the question specifically indicates GetObject is not needed. Thus, the absence of GetObject alone would not prevent the upload; an upload would succeed with only PutObject permission.

The bucket policy denies all access.

Why it fails: The exhibit does not show any bucket policy that explicitly denies all access. An S3 bucket can have a bucket policy that overrides IAM permissions, but without evidence of such a policy, we cannot attribute the failure to that cause. Moreover, a bucket policy that denies all access would produce an AccessDenied error for any principal, but the actual cause here is that the instance has no IAM role at all. Since no bucket policy is present in the exhibit, this option is unsupported and incorrect.

The log group name in the policy does not match the agent configuration.

Why it fails: The policy's Resource ARN explicitly targets MyAppLogGroup, and the CloudWatch agent's configuration is set to stream logs to the same log group name. For a mismatch to cause the error, the agent would need to be configured with a different log group name, but the scenario does not indicate this. Therefore, this option does not explain the access issue; the names are aligned and the policy correctly matches the intended log group.

The policy does not allow the 'logs:PutLogEvents' action.

Why it fails: The attached policy explicitly includes the 'logs:PutLogEvents' action in its Statement, granting the agent permission to append log events to a log stream. Since the required action for sending log data is present, a missing PutLogEvents permission is not the cause of the failure. The real problem is that the policy omits the separate 'logs:CreateLogGroup' action needed for the agent to create the log group on first use.

The Resource ARN incorrectly specifies a wildcard after the log group name.

Why it fails: The Resource ARN 'arn:aws:logs:region:account-id:log-group:MyAppLogGroup:*' uses the wildcard to represent all log streams under the MyAppLogGroup log group. This is the correct ARN pattern for granting access to log streams, because log streams are child resources of a log group and require a wildcard after the log group name. Removing the wildcard would restrict permissions to the log group resource itself and would not cover any streams, so this is not a misconfiguration.

The CPUUtilization metric is only available for EC2 instances.

Why it fails: CPUUtilization is not exclusive to EC2; it is also published by other AWS services such as Amazon ECS, Amazon ElastiCache, and Amazon Redshift, each within their own CloudWatch namespace. In addition, custom metrics published by your own applications can use the name CPUUtilization. The exhibit shows the AWS/EC2 namespace, but that does not mean the metric is only available for EC2 instances, so the statement is false.

Both instances are actively publishing CPUUtilization metrics.

Why it fails: Although two EC2 instances appear in the list-metrics output, that command provides no indication of current publishing activity. A metric remains listed as long as it exists in CloudWatch, even if the instance has been stopped, terminated, or has not sent a recent data point. To determine whether an instance is actively publishing CPUUtilization, you would need to call GetMetricStatistics or GetMetricData for a recent time window, so the claim that both are actively publishing cannot be concluded.

An alarm has been set on both instances for CPUUtilization.

Why it fails: The list-metrics command is a metadata operation that lists metric names and dimensions; it does not return any information about CloudWatch alarms. Alarms are separate resources that reference metrics but are not themselves metrics, so their existence must be checked with DescribeAlarms or by describing the alarm resource directly. The output shown in the exhibit only confirms which metrics have been published, not that any alarm was created on those metrics.

The threshold is set too high; it should be 80%.

Why it fails: The alarm threshold is already set to 90% while the exhibited CPU utilization is above that level for consecutive periods, so the threshold is not what prevents the alarm from firing. Lowering the threshold to 80% would not help because the alarm is not actually evaluating the instance's metric at all—there is no InstanceId dimension to identify the data stream. A metric without a dimension is either an invalid reference or an aggregate that does not reflect the instance's high CPU. Therefore, changing the numeric threshold has no effect on the alarm state.

The evaluation periods are too few.

Why it fails: With a period of 1 minute and 5 evaluation periods, the alarm is correctly configured to require 5 consecutive datapoints above the threshold before it transitions to ALARM, which is a sensible way to filter out brief CPU spikes. Increasing the evaluation periods would actually make the alarm wait longer before triggering, not faster, so it would not solve the reported issue. Even with one evaluation period, the alarm would still remain in INSUFFICIENT_DATA or OK because it is not attached to the instance-specific CPUUtilization metric. The number of evaluation periods is irrelevant when the metric's InstanceId dimension is missing.

The statistic should be Maximum instead of Average.

Why it fails: Both Average and Maximum are valid CloudWatch statistics for CPUUtilization, and using Average over a 1-minute period is a perfectly reasonable choice for detecting sustained high load. The exhibit shows the average CPU above 90%, so if the alarm were correctly dimensioned, an Average statistic of 90% would trigger after enough consecutive periods. Switching to Maximum would make the alarm more sensitive to occasional spikes but would not fix the missing InstanceId dimension that prevents the alarm from evaluating the instance's data. The statistic selection is unrelated to the root cause of missing the instance dimension.

Only the IAM user with the ARN arn:aws:iam::123456789012:user/Admin

Why it fails: The Principal element in this trust policy is the account root ARN (arn:aws:iam::123456789012:root), not the ARN of a named user such as arn:aws:iam::123456789012:user/Admin. When a role trust policy uses an account root ARN, it authorizes every IAM principal in that account, not just one specific IAM user. Therefore, this policy does not single out the Admin user; the Admin user has no special status under this trust policy.

Any IAM user in any AWS account

Why it fails: Trust policies only recognize principals that are explicitly named in the Principal element. Here the Principal is an ARN scoped to account 123456789012, so only identities that belong to that account can be granted assume-role permission by this trust policy. Users or roles from any other AWS account would fail the principal match, even if they had a policy allowing sts:AssumeRole.

Only users who have MFA enabled

Why it fails: The displayed trust policy has no Condition block, so no MFA-related condition key such as aws:MultiFactorAuthPresent is evaluated. Without such a condition, an IAM user in the account can assume this role with either MFA-enabled or non-MFA credentials, assuming their own permissions allow the action. The answer 'only MFA-enabled users' would require the policy to include a condition like "aws:MultiFactorAuthPresent":"true", which is absent.

The log group name is incorrect.

Why it fails: The log group name in the IAM policy resource ARN exactly matches the log group that the Lambda function is configured to write to. If it did not, CloudWatch Logs would throw a resource-not-found or a mismatch, but the actual failure is a permissions error caused by the policy's resource scope. Because the log group name is valid and correctly referenced, it is not the source of the problem.

The policy effect is Deny.

Why it fails: The exhibit clearly shows the policy statement has an Effect of 'Allow', so this is not a deny. Even if an explicit deny were present, the error would occur regardless of resource ARN, but the policy is an allow. The issue is not the effect but the resource definition, which lacks the required log-stream component for the PutLogEvents action. Thus, the effect is correct and not the cause.

The 'logs:PutLogEvents' action is not allowed.

Why it fails: The IAM policy does include 'logs:PutLogEvents' in the Action list, so the action is permitted by the policy. However, the Resource for that action is set to the log-group ARN only, and PutLogEvents requires a log-stream ARN as the resource. Simply allowing the action without targeting the correct resource type prevents the Lambda function from writing logs. Therefore, the action is allowed but ineffectively scoped.

Detailed monitoring is not enabled.

Why it fails: Detailed monitoring is not the cause because basic monitoring already delivers EC2 metrics, including CPUUtilization, to CloudWatch every 5 minutes. The CloudWatch API will return those 5-minute datapoints even when detailed monitoring (which changes the granularity to 1 minute) is never enabled. Since the command is querying the default period of 300 seconds (or any period that matches available buckets), basic monitoring alone is sufficient for data to appear.

The instance is in a different AWS region.

Why it fails: The instance is not in a different region because the command is run in us-east-1 and the exhibit shows the instance is also in us-east-1. CloudWatch metrics are per-region: if the instance were in another region, its CPUUtilization data would only appear under that region's CloudWatch namespace, not under us-east-1. Since both the CLI call and the instance are in us-east-1, a Region mismatch cannot explain the missing datapoints.

The metric name is misspelled.

Why it fails: The metric name is not misspelled because the exact metric for EC2 CPU utilization is 'CPUUtilization' with the namespace 'AWS/EC2', and the command uses that correct case-sensitive name. CloudWatch metric names are case-sensitive, and a misspelled name would return an empty dataset, but here the name is accurate. The option is therefore not the source of the problem; a typo would be an obvious API-level mismatch, not a silent condition tied to instance lifecycle.

The DesiredCapacity value must be less than MinSize.

Why it fails: DesiredCapacity is an independent setting that must fall within the MinSize and MaxSize boundaries, inclusive. If DesiredCapacity were less than MinSize, the Auto Scaling group would attempt to scale down to a value outside its minimum, which is invalid. Therefore, this is not a valid cause of the failure; the actual issue is a type mismatch.

The MinSize value exceeds the MaxSize value.

Why it fails: The MinSize value (1) is indeed less than the MaxSize value (5), so this condition is satisfied in the template. CloudFormation validates that MinSize is less than or equal to MaxSize before creating the stack, and since 1 < 5, this is not the reason for the failure. The failure occurs because MinSize is supplied as a string, not because of any range violation.

The Auto Scaling group must have a scaling policy.

Why it fails: Auto Scaling groups are fully functional without any scaling policies; policies are used only for dynamic scaling actions such as step scaling or target tracking. The only mandatory properties for an Auto Scaling group are the minimum and maximum size, and the launch configuration or template. Therefore, the absence or presence of a scaling policy is irrelevant to this stack creation failure.

The database engine does not support point-in-time recovery.

Why it fails: Point-in-time recovery is fully supported on Amazon RDS for MySQL when automated backups are enabled, so the engine is not the blocker. PITR relies on automated backups and transaction logs, and MySQL's engine natively supports the binary logs required for this feature. Therefore, the inability to restore here must stem from the backup configuration, not from a database engine limitation.

The backup window has already passed.

Why it fails: The backup window defines the daily time frame when RDS takes its automatic backup, but it does not constrain when you can perform a restore. Restores can be initiated at any point during the retention period, regardless of the backup window start or end time. Even if the backup window has already passed, that merely means the most recent automated snapshot was already taken; it does not remove your ability to restore to an earlier point.

The database is not Multi-AZ.

Why it fails: Multi-AZ deployment is an availability feature that provides failover to a standby replica in another Availability Zone, and it has no bearing on the restore process. RDS can restore backups and perform point-in-time recovery on single-AZ instances just as easily as on Multi-AZ instances. The absence of Multi-AZ only impacts high availability, not the existence or accessibility of backup data.

The condition key 'cloudwatch:namespace' is misspelled.

Why it fails: The condition key \'cloudwatch:namespace\' is spelled correctly; CloudWatch and IAM both recognize it as a valid condition key specifically designed to restrict PutMetricData to a particular namespace. A misspelled key would cause the policy to fail validation or would simply not be evaluated, but since the key is properly formed, the problem must be the value being compared. The application is likely sending a different namespace than the literal string \'MyApp\', causing the StringEquals condition to evaluate to false and deny the request.

The policy does not specify a specific resource ARN.

Why it fails: The PutMetricData API action does not support resource-level permissions in IAM, meaning you cannot specify an ARN such as \'arn:aws:cloudwatch:region:account-id:namespace/MyApp\' because the action operates on the CloudWatch service itself, not on a specific resource. The wildcard \'*\' is the only allowed resource for this action, and using a more specific ARN would actually make the policy invalid or ineffective. Therefore, the absence of a specific resource ARN is not the cause of the failure; the condition key mismatch is the real issue.

The action 'cloudwatch:PutMetricData' is not allowed for custom metrics.

Why it fails: PutMetricData is the primary API action for publishing custom metrics to CloudWatch and is fully supported for custom namespaces. IAM policies can grant this action explicitly, as shown in the policy, and CloudWatch does not impose restrictions that would block PutMetricData for custom metrics; in fact, custom metrics are the main use case for this action. If the action were not allowed, the error would be an "AccessDenied" due to missing permissions, not a condition key failure, so this option does not explain the problem.

The instance is running and healthy.

Why it fails: The instance is running and healthy: The AWS instance state is 'running', but the EC2 status checks reveal a system status of 'impaired'. In EC2, the instance state only indicates that the instance has been started and is not stopped or terminated; it does not guarantee that the underlying infrastructure or the instance is healthy. The system status check specifically monitors AWS-side dependencies such as physical host connectivity, power, and networking. Because this check has failed, the instance cannot be considered healthy, making this option incorrect.

The instance is terminated.

Why it fails: The instance is terminated: The instance state clearly shows 'running', whereas a terminated instance would show a state of 'terminated' and would no longer consume compute resources or incur compute charges. A terminated instance cannot be started or accessed, and no status check data would be displayed for a terminated instance. Since the exhibit shows the instance state as 'running' with active status check details, the instance is definitely not terminated.

The instance is stopped.

Why it fails: The instance is stopped: A stopped instance would show a state of 'stopped', meaning the virtual machine is shut down, compute resources are released, but EBS volumes remain attached and persistent. In a stopped state, no status checks would be reported as 'impaired' because the instance is not running on a host. Since the exhibit shows the instance state as 'running', this option is incorrect.

Use Amazon CloudWatch Events to capture API calls from all regions.

Why it fails: Amazon CloudWatch Events (now part of Amazon EventBridge) is an event bus that routes events between services, but it does not capture or record API calls. It can only react to events that CloudTrail or other services emit; it lacks the ability to log the raw API activity itself. Therefore, it cannot provide a historical record of API calls from all regions, making it an incorrect solution for this requirement.

Use S3 event notifications to trigger a Lambda function that logs API calls.

Why it fails: S3 event notifications are specifically triggered by object-level events within an S3 bucket, such as object creation, deletion, or restoration, not by API calls across AWS services. They are designed to enable real-time processing of S3 data changes, not to serve as a logging mechanism for CloudTrail or API activity. Even if a Lambda function is invoked, it would only see S3 events, so this approach fails to capture the comprehensive API call trail needed for the scenario.

Create a new CloudTrail trail in each region.

Why it fails: Creating a new CloudTrail trail in each region is redundant and operationally burdensome because CloudTrail already supports multi-region trails that automatically capture events from all AWS regions. This approach requires duplicating configuration, increasing management overhead, and potentially incurring additional costs. It is not a recommended practice when a single multi-region trail can achieve the same coverage more efficiently and with centralized log delivery.

The S3 bucket policy does not grant read access to CloudFront.

Why it fails: Even if a bucket policy grants read access to CloudFront, CloudFront cannot authenticate as CloudFront unless the distribution uses an Origin Access Identity (OAI). Without an OAI, CloudFront forwards requests to S3 as an anonymous principal, so the bucket policy has no way to map the request to the distribution. Consequently, a private bucket will return 403 Access Denied regardless of how permissive the policy is; the missing OAI is the root cause.

The distribution is not enabled.

Why it fails: The exhibit indicates that the distribution is in the Enabled state, which means it is active and serving requests. A disabled distribution would return an error such as 'Distribution Not Found' or a 403 from CloudFront itself, not an Access Denied from the S3 origin. Since the configuration clearly shows Enabled: true and presumably a Deployed status, this cannot be the source of the problem.

The viewer protocol policy is set to 'redirect-to-https', but users are using HTTP.

Why it fails: The `redirect-to-https` viewer protocol policy makes CloudFront return an HTTP 301 redirect to the HTTPS version of any requested URL. This redirection is handled entirely by CloudFront's edge servers before any origin request is made, so it has no bearing on whether S3 issues an Access Denied. If users are accessing over HTTP, they would be redirected to HTTPS and the request would proceed; the Access Denied indicates an origin authentication failure, not a protocol mismatch.

The target instance’s security group is blocking the health check traffic.

Why it fails: If the target instance's security group blocks the ALB's health check traffic, the connection attempt from the ALB would either time out (if the packet is silently dropped) or receive a TCP RST (if a deny rule sends a reset). This would appear as a connection failure or 'health check failed with timeout' in the ALB's CloudWatch logs, not as an HTTP 502 response. Since a 502 is an actual HTTP status code sent by the target, a network-layer block cannot produce that code. Therefore, this option does not explain the observed 502 status.

The target instance is not allowing outbound traffic to the ALB.

Why it fails: Application Load Balancer health checks are inbound requests initiated from the ALB's node to the target instance's health check port. Once the TCP connection is established, the target sends its HTTP response over that same connection; it never needs to open a new outbound connection toward the ALB. Even if the target's outbound rules are restrictive, security groups are stateful, so the response traffic for an allowed inbound health check is automatically permitted to flow back out. Thus, a lack of outbound connectivity would not cause the target to return an HTTP 502 status, making this explanation incorrect.

The ALB health check is misconfigured with an incorrect path.

Why it fails: A health check misconfiguration with an incorrect path would cause the target's web server to return a 404 Not Found, or sometimes a 403 if directory listing is forbidden, because the default object at that path does not exist. The ALB would then log the health check failure as a 404, not a 502. A 503 Service Unavailable could appear if the path exists but the server is overloaded, but a 502 specifically means the server received a bad response from an upstream component, which is not the result of a wrong health check path. Thus, while a wrong path would make the target unhealthy, it would not produce the observed 502 status.