VPC practice questions

Launch the database instance in a public subnet.

Why it fails: A public subnet exposes the RDS instance to internet routing, contradicting the requirement that the database be unreachable from the internet. Public subnets are tempting because they suit internet-facing load balancers and bastion hosts, but RDS belongs in private subnets reachable only from the web tier's security group.

Store database credentials in AWS Systems Manager Parameter Store.

Why it fails: Parameter Store secures credential storage and rotation, but it neither restricts database access to a specific port nor removes internet reachability, so it fails the stated security objectives. It is tempting because it is a genuine best practise for secrets management, and would be correct if the question asked how to avoid hard-coded credentials.

Amazon Inspector.

Why it fails: Amazon Inspector scans EC2 instances and container images for software vulnerabilities and unintended network exposure; it does not trace packet paths or reachability between instances. It is tempting because it reports network-related findings, and would be correct for vulnerability assessment, not for diagnosing connectivity failures.

AWS CloudTrail.

Why it fails: CloudTrail records API activity and management events in the account; it captures no packet-level or flow-level data between EC2 instances, so it cannot show where connectivity breaks. It is tempting because it is a core monitoring service, and would be correct for auditing who changed security groups or routes, not for tracing live traffic.

AWS Config.

Why it fails: AWS Config records resource configuration changes and evaluates compliance against rules; it does not capture packet-level flow logs or reachability paths between instances. It is tempting because it inventories network resources such as security groups, which is useful for auditing drift, but connectivity troubleshooting requires VPC Flow Logs and Reachability Analyzer.

The internet gateway is not attached to the VPC

Why it fails: The stem states the internet gateway is already attached to the VPC, so this contradicts the given facts. An unattached gateway would indeed block internet access, making this the right diagnosis only when the attachment is genuinely absent.

The subnet needs a NAT gateway for internet access

Why it fails: A NAT gateway is required for instances in private subnets to reach the internet, but the route table here points directly at an internet gateway, indicating a public subnet. NAT gateways are correct when instances must initiate outbound traffic without inbound exposure.

The subnet's route table does not have a route to the internet gateway

Why it fails: The stem explicitly states the route table already contains a 0.0.0.0/0 route to the internet gateway, so this contradicts the given facts. A missing default route would block access, making this correct only when no such route exists.

Use AWS CloudFormation StackSets with a stack that creates the VPC and Config rules, and trigger it via an SCP.

Why it fails: SCPs cannot trigger StackSets; this requires custom automation.

Create an SCP that denies creation of resources unless they comply with the baseline.

Why it fails: SCPs can only deny actions, not proactively create resources.

Use AWS Config conformance packs with YAML templates deployed to all accounts via an SCP.

Why it fails: Conformance packs can deploy Config rules but cannot create VPCs.

Create a Transit Gateway and attach all accounts.

Why it fails: A Transit Gateway is a routing hub connecting VPCs and on-premises networks; it forwards traffic between networks but does not let other accounts launch resources inside the owner's subnet. It is tempting because it centralises connectivity at scale, and would be correct for hub-and-spoke routing rather than subnet sharing.

Set up a VPN connection between accounts.

Why it fails: A VPN connection encrypts traffic between networks but provides no mechanism for another account to place resources within the owner's subnet. It is tempting because encryption sounds secure, and would be correct for connecting remote networks or on-premises sites, not for sharing subnet address space across accounts.

Create a VPC peering connection between each account and the VPC owner.

Why it fails: VPC peering connects networks but does not share a subnet's address space with other accounts, so participants cannot launch resources into the owner's subnet. It is tempting because peering is private and avoids public exposure, and would be correct for routing traffic between separate VPCs rather than shared-subnet participation.

Use AWS Config rules to automatically delete non-compliant VPCs.

Why it fails: Config cannot prevent creation; it can only detect and remediate after.

Use IAM policies with conditions on the ec2:CreateVpc action in each account.

Why it fails: IAM policies are account-specific; SCPs are needed for organization-wide enforcement.

Use AWS CloudTrail to monitor VPC creation and alert the security team.

Why it fails: Monitoring is not enforcement.

The function is experiencing cold starts due to high concurrency.

Why it fails: Cold starts add latency at invocation, not the sustained 30-second timeouts described, and high concurrency does not itself cause them. It tempts because cold-start latency is a well-known Lambda performance issue, and would fit if the symptom were sporadic slow first invocations rather than timeouts.

The function is hitting the maximum concurrent execution limit.

Why it fails: Concurrency limits cause throttling with 429 TooManyRequestsException errors, not invocation timeouts, since Lambda rejects excess requests rather than letting them run. It tempts because concurrency is a common Lambda scaling concern, and would be correct if the symptom were throttled invocations under burst load.

The function needs to be attached to a public subnet.

Why it fails: Lambda functions in a VPC never require a public subnet; they need NAT or endpoints for outbound internet, and a public subnet does not fix timeouts. It tempts because public subnets are associated with internet reachability, and would be relevant if the function needed direct inbound internet access.

Allow each team to create their own VPCs and use VPC Peering to connect them.

Why it fails: Team-created VPCs with peering leave administration distributed and security rules duplicated per VPC, contradicting centralised control. Peering suits connecting a small number of specific VPCs for direct traffic, not enforcing uniform rules across a multi-account estate.

Use AWS CloudFormation StackSets to deploy identical VPCs to each account.

Why it fails: StackSets replicate resources but do not centralise network administration; each account still owns and edits its own VPC and security groups, so common rules drift. StackSets suit deploying identical baseline templates across many accounts, not sharing centrally governed networks.

Manually create VPC flow logs in each account and point to the central S3 bucket

Why it fails: Manual creation across 50 accounts is error-prone and does not scale, and each account's flow log role must still be granted access to the security account's KMS key and bucket policy. Manual setup is tempting for small account counts, but it is correct only where centralised, policy-driven provisioning is unavailable.

Use AWS Config rules to enforce flow log creation across accounts

Why it fails: AWS Config rules detect and flag non-compliant accounts; they do not themselves create flow logs, deliver them to the central bucket, or use the security account's KMS key. Config is tempting for organisation-wide governance, but it is the correct choice for auditing compliance, not for provisioning the logging configuration.

Use AWS Systems Manager Automation to create flow logs in each account

Why it fails: Systems Manager Automation runs per-account scripts, so it cannot create flow logs across 50 accounts or apply the security account's KMS key centrally. It suits one-off remediation tasks inside a single account. AWS Organizations integration with CloudWatch Logs delivers organisation-wide flow logs to the central bucket directly.

Check the RDS console for any database events.

Why it fails: RDS console events may show database-level activity, but a DBInstance that never provisioned typically produces no events there; the failure reason appears in the CloudFormation stack events for that resource. Console event review is appropriate when investigating an existing running database's operational incidents, not a failed creation.

Delete the stack and deploy again with the same parameters.

Why it fails: Redeploying with identical parameters reproduces the same failure and discards the stack's event history, which records the underlying resource error. It is tempting as a quick reset, but the RDS events or CloudFormation stack events already identify the cause. Redeployment is appropriate only after the fault has been corrected.

Use AWS CloudTrail to view the CreateStack API call.

Why it fails: CloudTrail records the CreateStack API call and who made it, not the RDS-side reason the DBInstance failed, such as an invalid parameter or unavailable engine version. CloudTrail is the correct choice when the requirement is auditing API activity or attributing changes to an identity, not diagnosing resource provisioning errors.

Attach an Internet Gateway to the VPC

Why it fails: An Internet Gateway enables inbound and outbound internet traffic for a VPC, which is irrelevant to reaching an internal VPC resource. It is tempting because Lambda needs network pathing, but the function must instead be attached to private subnets within the VPC.

Set up a VPC peering connection

Why it fails: VPC peering connects two VPCs to each other, so it cannot place a Lambda function inside the VPC containing the resource. It is tempting because peering links networks, but the function must be configured with VPC subnet and security group settings.

Configure a NAT Gateway in the public subnet

Why it fails: A NAT Gateway provides outbound internet access for private subnets; it does not give Lambda access to a VPC resource. It is tempting because Lambda needs subnet routing, but the requirement is attaching the function to private subnets with appropriate security groups.

Place the application behind a public Application Load Balancer

Why it fails: A public Application Load Balancer requires internet-facing subnets and an internet gateway, which directly violates the no-public-internet-access requirement. Sending logs to CloudWatch Logs and storing objects in S3 from an isolated VPC is achieved with VPC endpoints (interface endpoints for CloudWatch Logs and a gateway endpoint for S3), keeping traffic on the AWS network.

Set up a NAT gateway in a public subnet and route traffic through it

Why it fails: A NAT gateway provides outbound internet access, which the scenario explicitly forbids; it also cannot reach CloudWatch Logs or S3 privately. NAT gateways suit private subnets needing software updates or public API calls, not fully isolated VPCs requiring VPC endpoints.

Use AWS PrivateLink to connect to CloudWatch Logs and S3

Why it fails: S3 gateway endpoints, not PrivateLink interface endpoints, are the mechanism for private S3 access from a VPC; PrivateLink does support S3 but requires interface endpoints with per-GB charges and does not cover all S3 features. PrivateLink is correct for privately reaching services lacking gateway endpoints, such as Kinesis or EC2 APIs.

Use AWS Config to detect VPCs without flow logs and trigger a Lambda function to enable them.

Why it fails: AWS Config rules are detective and evaluate after the fact, so remediation lags and Lambda must be deployed per account and region. It is tempting because Config conformance packs genuinely audit resource state, and would be correct for detecting non-compliant resources rather than provisioning logging centrally.

Write a script that uses the AWS API to enable VPC flow logs in each account and region, triggered by AWS Config rules.

Why it fails: A custom script still requires credentials and execution in every account and region, so operational overhead scales with account count. It is tempting because API automation removes manual console work, and would be correct for one-off or small-scale deployments outside AWS Organizations.

Set up a VPN connection from each account to the security account and configure flow logs to use a S3 endpoint in the security account.

Why it fails: Flow logs are delivered by the VPC service to S3 directly; a per-account VPN adds tunnels, routing and cost without carrying log data, and an S3 endpoint in another account is not reachable over that VPN. VPNs suit encrypted connectivity between on-premises networks and AWS, not log aggregation.

Amazon Route 53 Resolver

Why it fails: Route 53 Resolver handles DNS resolution between on-premises and AWS, but carries no data traffic, so it cannot provide private connectivity. It tempts because hybrid designs need name resolution, yet that is a supporting component; the transport itself requires a VPN or Direct Connect attachment.

VPC peering

Why it fails: VPC peering connects VPCs privately but provides no path to on-premises networks, and it does not transitively route across accounts, so it cannot satisfy the hybrid requirement alone. It tempts for inter-VPC connectivity, which is correct only when no on-premises link is needed.

AWS Client VPN

Why it fails: AWS Client VPN connects individual remote users to a VPC; it does not provide site-to-site connectivity between an on-premises data centre and multiple VPCs. It tempts as remote access, which is correct for roaming employees, not for persistent private network-to-network links.

Accept VPC peering connection request, Initiate VPC peering connection request, Add routes to route tables, Update security groups, Update network ACLs

Why it fails: This is incorrect because the acceptance must happen after the initiation request; the order of initiation and acceptance cannot be reversed.

Initiate VPC peering connection request, Accept VPC peering connection request, Update security groups, Add routes to route tables, Update network ACLs

Why it fails: This is incorrect because routes must be added before updating security groups; otherwise, the route to the peered VPC does not exist, making security group updates ineffective for cross-VPC traffic.

Initiate VPC peering connection request, Accept VPC peering connection request, Update network ACLs, Update security groups, Add routes to route tables

Why it fails: This is incorrect because routes must be added before both security groups and network ACLs, and network ACLs are typically updated after security groups as a final step.

Use AWS PrivateLink to create an interface VPC endpoint for RDS in each workload VPC, and enforce SSL/TLS on the RDS instance.

Why it fails: AWS PrivateLink does not support Amazon RDS directly; RDS is not a supported endpoint service for interface VPC endpoints. You cannot create a PrivateLink endpoint for RDS. Therefore, this solution is technically invalid. While PrivateLink is useful for many services, it cannot be used to access RDS in this manner, making this option incorrect.

Deploy an Application Load Balancer in the shared services VPC, register the RDS instance as a target, and have workload accounts connect through the ALB using SSL/TLS.

Why it fails: Application Load Balancers operate at the application layer and do not support TCP passthrough for database protocols like MySQL. You cannot register an RDS instance as a target for an ALB. This approach is technically infeasible. Additionally, it would introduce unnecessary complexity and potential security risks, and it does not meet the requirement for direct, secure database connectivity.

Create a VPC peering connection between each workload VPC and the shared services VPC, and configure the RDS instance to require SSL/TLS connections.

Why it fails: VPC peering provides private connectivity, but it requires a full mesh of peering connections if workload VPCs need to communicate with each other, increasing complexity. More importantly, VPC peering does not scale well for many accounts and does not centralize management. While SSL/TLS can be enforced on RDS, the peering approach adds administrative overhead as accounts grow, contradicting the requirement to minimize overhead.

Store static assets in a public S3 bucket.

Why it fails: A public S3 bucket exposes static assets to anonymous internet access, removing an access-control layer rather than adding one, which contradicts defence in depth. It is tempting because S3 and CloudFront commonly serve static content, and a public bucket would be the right choice for a deliberately public website hosting openly distributable assets.

Place EC2 instances in public subnets for easier management.

Why it fails: Public subnets give instances routable addresses and a path to the internet gateway, exposing them directly and bypassing the ALB as the sole ingress point. It is tempting because public subnets simplify SSH administration and outbound patching, and they would be correct for bastion hosts or NAT instances that genuinely require public addressing.

Allow direct internet access to the EC2 instances.

Why it fails: Allowing direct internet access to the EC2 instances creates a second ingress path that circumvents the ALB's listener rules, TLS termination and WAF integration. It is tempting because direct access simplifies troubleshooting and deployment, and it would be correct for instances that must receive traffic independently of a load balancer.

Place the EC2 instances in a private subnet with a NAT gateway. Use VPC peering to on-premises.

Why it fails: A NAT gateway provides outbound internet access only and cannot route to on-premises; VPC peering does not connect to on-premises networks, which requires a virtual private gateway or Transit Gateway over the Direct Connect link. It is tempting as a private-connectivity pattern, and would be correct for VPC-to-VPC peering.

Place the EC2 instances in a public subnet. Use an internet gateway and configure security groups to allow inbound traffic from on-premises IPs.

Why it fails: A public subnet with an internet gateway routes traffic over the public internet, ignoring the Direct Connect connection and exposing database and file-share traffic. It is tempting because it is quick to configure, and would be correct for publicly accessible web servers, not private hybrid access to on-premises SQL Server.

Use Amazon EC2-Classic and link the instances to on-premises via ClassicLink.

Why it fails: EC2-Classic is retired and ClassicLink only linked classic instances to a VPC, not to on-premises networks; neither supports the Direct Connect path required here. It is tempting as a legacy hybrid-connectivity term, and would have been correct for connecting EC2-Classic instances to a VPC in older accounts.

AWS PrivateLink

Why it fails: AWS PrivateLink exposes a service endpoint to consumers within a VPC, not a transit gateway attachment across accounts. It is tempting because PrivateLink privately connects services between VPCs and accounts, which suits publishing an internal application endpoint, but it cannot share a transit gateway for inter-VPC routing.

VPC peering connection

Why it fails: VPC peering connects two VPCs directly and does not share a transit gateway with member accounts. It is tempting because peering links VPCs across accounts, which suits simple point-to-point connectivity between a handful of VPCs, but it cannot attach member VPCs to a central transit gateway.

AWS Direct Connect

Why it fails: AWS Direct Connect provides dedicated private connectivity from on-premises networks into AWS and does not share a transit gateway between accounts. It is tempting because Direct Connect integrates with transit gateways for hybrid routing, which suits linking a data centre to many VPCs, but it is not an account-sharing mechanism.

AWS Elastic Beanstalk

Why it fails: Elastic Beanstalk provisions application environments but abstracts the network layer, so it does not give explicit declarative control over VPC subnets, security groups and an Application Load Balancer as required. Tempting for quick web app hosting, and correct when a developer wants platform-managed capacity without authoring infrastructure templates.

AWS CodeDeploy

Why it fails: AWS CodeDeploy orchestrates application revisions onto existing compute such as EC2 or Lambda; it does not provision VPCs, subnets, security groups or an Application Load Balancer. It is tempting because it automates deployments, and would be correct when the infrastructure already exists and only code rollout with lifecycle hooks is required.

AWS OpsWorks

Why it fails: AWS OpsWorks manages configuration through Chef and Puppet stacks, targeting instance-level automation rather than declaring VPC subnets, security groups, load balancers and instances as one template. It is tempting as a legacy deployment tool, and would be correct for Chef-driven configuration management of existing EC2 fleets.