Scenario practice questions

AWS CodePipeline with cross-account actions

Why it fails: AWS CodePipeline with cross-account actions can technically deploy stacks into multiple accounts, but it requires the sysops admin to build a separate pipeline stage or action per target account, configure cross-account KMS keys, S3 artifact buckets, and IAM roles, and manually maintain the account list. Unlike StackSets, it does not dynamically discover or target accounts via AWS Organizations OUs, so every account change triggers pipeline maintenance. This makes it significantly more operationally overhead than a StackSet.

AWS Service Catalog portfolio

Why it fails: AWS Service Catalog portfolio lets administrators create and share approved CloudFormation products that users can provision on demand, but it does not push deployments automatically to every account in an OU. Each target account's users would have to launch the product individually, or the admin would need separate automation to invoke provisioning, which does not guarantee uniform, consistent deployment at scale. The service is designed for governed self-service, not bulk multi-account stack orchestration.

AWS Systems Manager Automation

Why it fails: AWS Systems Manager Automation is designed to run runbooks against individual resources, such as patching an EC2 instance or configuring a single account's resource. Although an Automation runbook could invoke cross-account roles to create stacks, there is no native capability to fan out a CloudFormation template across all accounts and regions in an organization with automatic OU membership tracking. Building that would require custom scripted loops and per-account IAM trust relationships, adding operational complexity and making it a poor fit.

Metric math

Why it fails: Metric math allows you to create a new time series by applying arithmetic or conditional expressions to one or more CloudWatch metrics; however, it produces a single metric that then requires its own alarm. To emulate an AND condition, you would need to write a custom expression that encodes each threshold and yields a 1 only when all are met, but this lacks the built-in state evaluation, missing-data handling, and straightforward management that composite alarms provide. Since the requirement is to combine multiple alarm conditions, metric math alone does not offer a complete alarm solution.

Anomaly detection

Why it fails: Anomaly detection builds a statistical model of a single metric's expected range based on historical behavior, using ±n standard deviations or a custom band, and it raises an alarm when the metric falls outside that band. It does not compare two or more metrics against each other, nor does it evaluate fixed thresholds based on known business requirements. If your goal is to require that several independent thresholds are all exceeded simultaneously, anomaly detection only identifies outliers over time and cannot express that multi-metric condition.

Logs Insights

Why it fails: CloudWatch Logs Insights is an interactive query engine used to search, filter, and pattern-match log events, with the ability to compute fields and aggregates on log data. It does not produce a time series metric that CloudWatch alarms can continuously evaluate, and there is no native mechanism to create an alarm directly from a Logs Insights query. To use log data in an alarm you would first need to create a metric filter that extracts a numeric value into a custom metric, which is then managed by a standard alarm—making it an indirect, extra-step solution rather than a direct way to combine existing alarm conditions.

DeletionPolicy with Retain

Why it fails: DeletionPolicy is a CloudFormation attribute that determines what happens to a resource when its logical ID is removed from the stack template or when the entire stack is deleted. It has no effect during an update that replaces a resource, because replacement is an update operation, not a stack deletion operation. Therefore, setting DeletionPolicy: Retain on an RDS instance will not protect the old instance during an update that requires a new one; it only preserves the resource if the stack is deleted.

StackPolicy

Why it fails: A stack policy is a JSON document that specifies which update actions are allowed or denied for particular resources in a CloudFormation stack. While it can block an update that would replace an RDS instance, it cannot configure what happens to the old instance if the update is allowed to proceed. It acts as an access-control guardrail, not a data-retention mechanism, so it does not address the scenario of preserving the existing database during a replacement.

CreationPolicy

Why it fails: A CreationPolicy is used in CloudFormation to control when a resource's creation is considered complete by waiting for a specified number of success signals or a timeout period. This is relevant only during the initial creation of a resource, not during updates that replace an existing resource. As a result, a CreationPolicy cannot be used to retain the old RDS instance or its data when a stack update triggers a replacement.

The secret access key was not saved during creation

Why it fails: If the secret access key was not saved during creation, the user would be unable to sign CLI requests because the secret key value is displayed only once; however, this is a transient credential loss, not a policy-based denial. The user or administrator could simply generate a new access key pair in the IAM console and reconfigure the CLI, which would immediately resolve the issue. Moreover, a missing secret key would result in an InvalidClientTokenId error, not a targeted denial of CLI access while the console remains usable, so this does not match the scenario.

The user's access key is inactive

Why it fails: An inactive access key causes CLI calls to fail with an InvalidClientTokenId error, but it does not explain why the same user can still access the AWS Management Console, because console sign-in uses the password and MFA, not access keys. The administrator could set the key state back to Active in the IAM console, making this a simple key-state issue rather than a persistent authorization problem. Since the symptom is limited to CLI access and the user's console session works, an inactive key alone is not a sufficient explanation when the policy selectively requires MFA for programmatic calls.

The user is using the wrong password for the CLI

Why it fails: The AWS CLI does not accept the IAM user's console password as an authentication credential; CLI requests are signed with access keys or temporary credentials obtained through assume-role calls. Using the wrong console password would only prevent interactive web console login, not affect programmatic commands, and would produce a login failure rather than an AccessDenied response from the service. Therefore, this option confuses the authentication mechanisms for the console with those used by the CLI and cannot account for a CLI-specific denial.

Use a NAT gateway in a public subnet

Why it fails: A NAT gateway is designed for outbound-only internet connectivity from private subnets, but it still routes S3 traffic through the public internet using the gateway's Elastic IP and its own route. That means the connection is neither private nor free from internet dependencies, and it does not establish a secure perimeter around S3 access. It also incurs hourly charges and per-GB data processing costs, making it an inferior choice to a VPC endpoint.

Set up an AWS Direct Connect connection

Why it fails: Direct Connect is a physical dedicated line from your on-premises data center to an AWS Direct Connect location; it is not a VPC component that steers instance-to-S3 traffic. Even after establishing Direct Connect, you must pair it with either a public virtual interface that uses S3's public endpoints or a VPC endpoint to get private connectivity — the Direct Connect link alone does not imply S3 is reached privately. For an EC2 instance already inside the VPC, adding Direct Connect is irrelevant, expensive, and does not meet the stated requirement.

Attach an internet gateway to the VPC and a public IP to the instance

Why it fails: This approach relies on an internet gateway and a public IPv4 address to expose the instance to the public internet, and any S3 traffic is transmitted over the internet rather than the AWS private network. It increases the attack surface because the instance is openly addressable from the internet, demanding careful security-group rules, and it still incurs data transfer costs for internet egress. A VPC endpoint avoids these exposure and cost issues while keeping the instance off the public internet.

The IAM role trust policy does not allow EC2 to assume the role.

Why it fails: If the EC2 trust policy did not allow the ec2.amazonaws.com service principal, the instance would fail to retrieve temporary credentials from the instance metadata service, causing errors such as 'Unable to locate credentials' or 'AccessDenied' from the STS API itself. However, the scenario states the trust policy is configured correctly, and the troubleshooting is occurring because the instance successfully obtained a role and made S3 requests that were explicitly rejected. Therefore, the failure lies in S3 authorization, not in role assumption.

The instance profile is not correctly attached to the EC2 instance.

Why it fails: An instance profile that is not attached, or that lacks the correct IAM role, would prevent the EC2 instance from receiving any temporary security credentials, resulting in a 'NoCredentialProviders' or 'CredentialsNotFoundError' when the AWS CLI tries to call S3. Since the instance is already using the intended role and the access failure is an S3 AccessDenied response, the instance profile attachment is not the root cause. The error occurs after authentication, meaning the credential acquisition path is functioning normally.

The S3 bucket requires a VPC endpoint.

Why it fails: A VPC endpoint for S3 is only required when you want private connectivity between an EC2 instance and S3 without traffic traversing the public internet or a NAT gateway. There is no default requirement that all S3 access must come through a VPC endpoint, and IAM-based access over the public S3 endpoint works fine when the bucket policy allows it. Here, the bucket policy contains an explicit Deny, which would still apply regardless of whether traffic arrives via a VPC endpoint, a NAT gateway, or the public internet, so the VPC endpoint is irrelevant to the authorization failure.

AWS CloudTrail

Why it fails: CloudTrail records API actions performed by users, roles, or services, capturing event history for governance and audit purposes. It does not ingest or expose infrastructure performance counters such as CPU utilization, and it lacks any alarm or threshold evaluation capability for operational metrics. Consequently, CloudTrail cannot trigger notifications when an RDS instance's CPU crosses a threshold.

AWS Config

Why it fails: AWS Config evaluates resource configurations against managed or custom rules to assess compliance and track changes over time, such as detecting when an RDS instance is publicly accessible. It does not collect performance data or store time-series utilization metrics, so it cannot see current or historical CPU utilization. Therefore Config cannot be used to create CPU-based performance alarms.

AWS Trusted Advisor

Why it fails: AWS Trusted Advisor inspects your account and delivers best-practice recommendations in categories like cost optimization, fault tolerance, and performance, including flags for underutilized RDS instances. However, its checks are periodic advisory reports, not a real-time monitoring service, and it does not allow you to define custom alarms with thresholds for specific metrics such as CPU utilization. As a result, Trusted Advisor cannot directly notify you when CPU exceeds a configured limit.

Create IAM users and assign them permissions to access the bucket.

Why it fails: Creating IAM users and granting them S3 permissions controls which identities can access the bucket, but it does not restrict the network location from which those identities make requests. A user with valid IAM credentials could still call s3:GetObject from any IP address or VPC, bypassing the intended VPC restriction entirely. To enforce the required network-level isolation, you need a bucket policy with a vpc:SourceVpce condition, which is independent of any IAM user setup.

Attach a security group to the S3 bucket.

Why it fails: Security groups are virtual firewalls that operate at the elastic network interface (ENI) level for EC2 instances and other resources like RDS or Lambda, not for S3 buckets, which are regional services without a VPC CIDR to apply a security group to. Even when using a VPC interface endpoint for S3, the security group attaches to the endpoint's ENI, not to the bucket itself. Therefore, attaching a security group to the S3 bucket is impossible and irrelevant; bucket policies or IAM policies are the correct enforcement mechanisms.