CCNA Infrastructure Security Questions

This standard three-tier design places only the web tier in public subnets with a route to an internet gateway so it can serve external users. The app and database tiers are in private subnets with no internet gateway route, preventing direct inbound connections from the internet; the app tier receives traffic from the web tier through an internal load balancer or security group rules, and the database is isolated to app-tier-only access. This minimizes the attack surface and is the correct pattern for a public-facing web application.

End-to-end encryption requires TLS on both hops: an HTTPS listener terminates client TLS, while an HTTPS target group re-encrypts traffic to the instances. Installing certificates on the EC2 instances lets them present them, satisfying the requirement that ALB-to-instance traffic is encrypted.

Adding a security group rule to allow inbound SSH (port 22) only from the corporate IP range is the correct solution because security groups are stateful and act at the instance's network interface level. This rule denies all other inbound SSH traffic by default, since security groups have an implicit deny-all inbound rule, and because it is stateful, return traffic for allowed connections (e.g., ephemeral ports) is automatically permitted. This directly restricts SSH to the corporate range without requiring separate outbound rules, making it the appropriate mechanism for this use case.

Referencing the ALB's security group as the source is a security group-to-security group rule: it dynamically matches any IP address associated with an elastic network interface that belongs to that ALB security group. This means EC2 instances behind the ALB accept traffic only from the ALB's ENIs, even as the ALB scales and its private IPs change. The rule is stateful, so return traffic flows automatically, and no internet CIDR is ever exposed. This is the AWS-recommended pattern for placing an ALB in front of a web tier.

Private subnets lack a route to the internet, so their route tables must direct 0.0.0.0/0 to the central NAT device's elastic network interface. This satisfies the requirement that all outbound traffic traverses the NAT for logging and filtering.

A bucket policy that explicitly denies requests when aws:SecureTransport equals false is correct because aws:SecureTransport is a global IAM condition key that is true for HTTPS and false for HTTP. Using a Bool condition with a Deny effect overrides any other allow statement in the policy, so every S3 operation, including from authorized IAM principals, must arrive over TLS. This is the standard way to enforce HTTPS at the S3 API level, and it cannot be bypassed by accessing the bucket directly.

Bucket policies that deny s3:PutObject unless the request includes encryption headers block unencrypted uploads at the authorisation layer, enforcing encryption at rest for every write. This satisfies the requirement to prevent plaintext objects from being stored.

Adding a route to the private subnet's route table with destination 0.0.0.0/0 and target the NAT gateway is the precise mechanism that enables outbound internet access from private instances. The NAT gateway itself resides in a public subnet and relies on its own route to the internet gateway, but private subnets require this explicit route to direct traffic to the NAT gateway. Without this route, private instances have no path to the internet, making this the correct action to satisfy the requirement.

A NAT Gateway is a fully managed AWS service that enables instances in a private subnet to initiate outbound connections to the internet while preventing unsolicited inbound connections. It sits in a public subnet, uses an Elastic IP for source NAT, and forwards traffic through the Internet Gateway. Because it preserves the flow state, return traffic from the internet is translated back to the private instance, but no external host can directly initiate a session into the private subnet.

Transit Gateway with appliance mode enables asymmetric routing support, allowing a gateway route table to forward traffic from source VPCs to the central inspection VPC, while the firewall appliance then routes return traffic back through the same appliance, ensuring both directions are inspected. By using separate route tables associated with each VPC attachment, you can force all inter-VPC and outbound traffic through the firewall appliance, which scales horizontally and keeps security inspection centralized.

When the delivery target for VPC Flow Logs is CloudWatch Logs, the log group is the container that receives and stores the published flow log records. It must exist in the same Region as the monitored VPC, and VPC Flow Logs automatically creates a log stream for each elastic network interface. Without this log group (or permission to create it), you cannot complete CloudWatch Logs delivery.

This is the correct architecture: the internet-facing ALB resides in public subnets, where it has public IP addresses and a route through the internet gateway to accept client traffic, while the EC2 instances are placed in private subnets with no public IPs or direct internet ingress. The ALB terminates HTTP/HTTPS traffic and forwards requests to instances over private IP addresses using target groups; security groups on the instances should only allow traffic from the ALB security group. This design keeps instances isolated from direct internet access while still providing high availability across two Availability Zones.

IAM Access Analyzer is the correct tool here because it uses automated reasoning to analyze resource-based policies, including S3 bucket policies, and generates findings for any policy that grants access to principals outside your AWS account or organization. It specifically flags 'public' access when a bucket policy allows anonymous access (Principal: "*"), and it also surfaces cross-account access with detailed context about the external principal, actions, and resource. This allows you to review every bucket policy systematically and remediate unintended public exposure, making it a comprehensive policy-review solution.

An IPsec VPN creates an encrypted tunnel between the configured endpoints (here, the instances), typically using ESP in tunnel or transport mode to encrypt IP payloads and, when needed, the original IP header. It also provides mutual authentication, integrity checking, and anti-replay protection, ensuring all traffic between the instances is confidential and tamper-evident. This is the only option that actively encrypts the traffic itself.

AWS WAF evaluates rules in ascending priority order, where lower numeric priority values are evaluated first. If a higher-priority allow rule (e.g., priority 0) matches all requests and is set to 'Allow', the web ACL immediately stops evaluating remaining rules, so a lower-priority block rule (e.g., priority 1) is never reached. The presence of such a broad allow rule fully explains why requests are not blocked, even when the block rule itself is properly configured.

This option enables all four S3 Block Public Access settings: BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, and RestrictPublicBuckets. BlockPublicAcls stops new public ACLs, IgnorePublicAcls causes existing public ACLs to be disregarded, BlockPublicPolicy prevents adding new public bucket policies, and RestrictPublicBuckets limits how existing public policies are used. Together they close both ACL-based and bucket-policy-based pathways for anonymous or public access, making this the correct choice to ensure the bucket is not publicly accessible.

The on-premises network uses 10.0.0.0/8, which includes the VPC CIDR 10.0.0.0/16. This overlap creates conflicting routes: traffic destined for 10.0.0.0/16 could be routed locally within the VPC or to the VPN, causing ambiguity and failure. Overlapping CIDRs are a common cause of hybrid connectivity issues and must be resolved by re-addressing one side.

IAM roles are the native AWS mechanism for cross-account access: the role's trust policy explicitly names the external account (or its users/roles) as a principal, and the permission policy grants the specific actions the role can perform. When the external user assumes the role, AWS verifies that the trust policy allows the request and then issues temporary credentials scoped to the role's permissions, making this the correct and secure way to enable the cross-account assumption.

A bucket policy with an aws:SourceAccount condition key evaluates the account ID of the IAM principal that signs the request and is enforced by S3 when the bucket is accessed. This condition is evaluated against the requester's account number, allowing you to allow or deny access based on that account without specifying individual user ARNs. It is the recommended approach because it uses a resource-based policy that directly supports condition keys, and it ensures all requests from unintended accounts are rejected.

The outbound rule is defined as allowing all traffic to 0.0.0.0/0, meaning any instance associated with this security group can initiate connections to any IP address on any port. This violates the principle of least privilege because if an attacker compromises the instance, they could use it as a pivot to exfiltrate sensitive data or launch outbound attacks. Even though inbound HTTPS may also be overly broad, the outbound any-any rule is a critical misconfiguration because it provides no egress filtering or restrictions to required services.

AWS WAF is a web application firewall that protects at Layer 7 by inspecting HTTP(S) requests and filtering malicious traffic before it reaches your application. You can use rate-based rules to limit the number of requests from a given IP address, block known attacker IP sets, and mitigate HTTP floods, SQL injection, or cross-site scripting attempts. This directly addresses application-layer DDoS attacks, which consume application resources by sending large volumes of web requests, and it is a core component for ongoing protection of web-facing workloads.

The internet gateway provides the VPC's path to the internet and is required for the NAT gateway to reach external destinations. Without it attached to the VPC, the NAT gateway cannot forward private-subnet traffic outbound, so the stem's outbound access fails.

AWS Config can continuously monitor security group configurations using the managed rule 'vpc-sg-open-only-to-authorized-ports', which flags security groups that allow unrestricted inbound access. When the rule detects a non-compliant security group, you can attach an automatic remediation action using an AWS Systems Manager Automation document such as AWS-RevokeSecurityGroupIngress. This removes the offending SSH 0.0.0.0/0 rule without requiring manual intervention, and AWS Config tracks compliance status in the dashboard.

AWS Config continuously evaluates each S3 bucket against the s3-bucket-server-side-encryption-enabled managed rule and, upon detecting non-compliance, can immediately trigger an AWS Systems Manager Automation document to apply default encryption automatically. This creates a closed-loop, serverless remediation pipeline that is real-time, fully audited (via Config compliance history and SSM Automation execution logs), and scalable across accounts through Organization-level conformance packs. It is the only option that provides both continuous detection and automatic remediation without manual effort or infrastructure management.

The policy sets Principal to '*' in a bucket policy, which means every principal—including unauthenticated anonymous users—is included in the scope of the statement. The condition on aws:SourceIp narrows the network source to a specific IP CIDR, but it does not require any AWS credentials, identity, or account relationship. As a result, any person or service whose traffic originates from that IP range can read objects in the bucket, making the bucket effectively public to that entire network.

This is correct because security groups are stateful: when the web server initiates a TCP connection to the database on port 3306, the corresponding return traffic is automatically allowed back into the web server without an explicit inbound rule. By setting the destination to the database security group ID rather than an IP range, the rule dynamically applies to every instance currently associated with that security group, which simplifies management if the database fleet scales or changes. This outbound rule scopes traffic to the specific database tier and avoids opening port 3306 to the whole VPC.

A NAT gateway deployed in a public subnet with an associated elastic IP provides outbound internet connectivity for instances in private subnets. You must add a default route (0.0.0.0/0) in the private subnet's route table pointing to the NAT gateway's interface or ID, ensuring instances can initiate outbound connections while remaining inaccessible from the internet.

A bucket policy can use the aws:SourceVpce condition key to restrict access to a specific VPC endpoint. This allows only traffic that arrives through the corresponding gateway or interface endpoint to reach the bucket, while all other sources, including the public internet, are denied. This resource-based control is the correct way to enforce VPC-only access to an S3 bucket.

These two headers are mandatory for SSE-C, where the customer supplies the raw 256-bit AES key in each request rather than letting AWS hold key material. x-amz-server-side-encryption-customer-algorithm must be set to AES256, and x-amz-server-side-encryption-customer-key must contain the base64-encoded key, typically accompanied by x-amz-server-side-encryption-customer-key-MD5 to verify integrity. AWS discards the key after encrypting the object and stores only a salted HMAC for later validation, so you must re-supply these headers on every PUT, GET, HEAD, or range read.

Security group chaining gives tier-specific, stateful filtering without hard-coding IP addresses. Define a separate security group for the web, app, and database tiers, then set inbound rules on the app SG that allow traffic from the web SG (on the app port) and on the database SG that allow traffic from the app SG. Because the source is an SG ID, any instance associated with the preceding tier automatically has access, and newly launched instances in that tier are included without updating CIDR rules. This enforces least-privilege east-west traffic isolation.

This is the correct architecture because it separates transport security into two complementary layers: the ALB listener uses a redirect action to convert any plain HTTP request to HTTPS, forcing TLS for every attempt, and the application returns the Strict-Transport-Security header in its response, which instructs browsers to automatically use HTTPS for the domain for the specified duration. ALB does not natively generate HSTS headers, so the application must supply it after a successful TLS connection. This satisfies both the immediate encryption requirement and the long-term HSTS enforcement.

A regex pattern set lets you define a regular expression that describes the structural format of valid API keys, such as a required prefix followed by a specific number of alphanumeric characters. In a WAF rule, you can use the 'not' operator to inspect the API key header and block any request whose key does not match this pattern, providing centralized pattern-based validation at the edge. This directly addresses the requirement to reject invalid API keys.

Creating an S3 VPC endpoint and attaching a bucket policy that denies all access unless the request originates from that endpoint confines S3 traffic to the AWS internal network, removing exposure to the public internet. This, combined with replacing SSH with AWS Systems Manager Session Manager, eliminates inbound SSH ports and relies on IAM-based, auditable session access instead of static keys. Together, these controls shrink the attack surface and provide preventive, policy-enforced protection against both network-level exfiltration and credential compromise.

Modifying the inbound SSH rule's source from 0.0.0.0/0 to 203.0.113.0/24 is the precise fix because security groups are stateful and support only allow rules. Every IP outside that CIDR will be implicitly denied by the security group's default-deny behavior, while the company's addresses remain permitted. This change directly aligns the security group with the requirement and requires no extra outbound rule because stateful filtering automatically allows the return traffic.

Instance-level firewall.

A Direct Connect virtual interface provides a dedicated, low-latency network path, but it does not encrypt traffic on its own. By configuring an IPsec VPN session over that virtual interface, you can encapsulate all packets in an encrypted tunnel between the on-premises edge and the AWS VPN endpoint, meeting compliance requirements while retaining Direct Connect's performance and reliability benefits.

Distributing workloads across multiple Availability Zones within a Region makes an entire data-center failure survivable because each AZ runs on independent power, cooling, and physical networking. If one AZ degrades or goes offline, healthy copies of the workload in other AZs continue to serve traffic, giving the design a failure domain with no single point of failure. This is the foundational pattern for mission-critical architecture on AWS and is more effective than any single-instance or IP-level technique.

Creating an IAM role with a narrowly scoped policy and attaching it as the instance profile lets the EC2 instance securely obtain temporary credentials from AWS STS through the instance metadata service, with no keys embedded in the AMI or stored on disk. These credentials are rotated automatically and are valid only for a short duration, reducing the blast radius of any credentials leak. The policy can restrict actions to the specific S3 bucket (for example, s3:GetObject and s3:ListBucket), and the role's trust policy allows the EC2 service to assume it, ensuring the instance operates with least privilege and a clear audit trail in CloudTrail.

aws:SourceVpce is the correct condition key because it restricts access to requests that originate from a specific VPC endpoint, identified by its endpoint ID (e.g., vpce-1a2b3c4d). In an S3 bucket policy, you can use this condition key with an explicit Allow statement and the endpoint ID as the value to ensure that only traffic flowing through that particular endpoint can access the bucket. This works for both gateway-gateway and interface VPC endpoints for S3, making it the precise mechanism to limit access to exactly one endpoint.

Security groups act as a stateful virtual firewall, evaluating inbound traffic and allowing only the rules you explicitly define. By restricting inbound traffic to only necessary ports and source IP ranges, you minimize the attack surface and block unused services from being probed. This least-privilege approach is a fundamental security control that should be applied in addition to network segmentation, not as a substitute for it.

Private subnets with a NAT Gateway in a public subnet provide a controlled outbound-only internet path. The private subnets' route table sends 0.0.0.0/0 to the NAT Gateway, which holds an Elastic IP and translates traffic, while inbound connections from the internet are still impossible. This allows instances to fetch updates and call external services without being directly exposed, making it the recommended multi-tier architecture pattern.

Cross-account access is an AND operation: the bucket policy in Account A must explicitly allow the principal (the root user or a specific IAM principal in Account B) to call s3:GetObject, and the IAM identity in Account B must have an attached identity-based policy that also permits s3:GetObject. If either policy denies or lacks the permission, the request fails, because both the resource-based policy (in the owning account) and the identity-based policy (in the accessing account) must grant the action. This pattern is the standard way to grant direct cross-account access to an S3 object while keeping the resource owner in control.

This is the correct outcome because AWS IAM uses an explicit deny override model: if any applicable policy contains a Deny statement that matches the request, access is denied even if an Allow statement also matches. Here, the request is sent over HTTP, so the Deny condition on aws:SecureTransport (e.g., "aws:SecureTransport": "false") is triggered, blocking the request. The user's IP being within the allowed range is irrelevant because the Deny statement takes unconditional precedence.

MACsec operates at layer 2, providing hop-by-hop encryption on the dedicated Direct Connect link between the customer router and the AWS device. It encrypts traffic traversing the connection itself, satisfying the requirement without overlaying an IPsec tunnel.

The bucket policy includes an explicit deny statement that blocks any request where the transport protocol is HTTP, typically via a condition such as `aws:SecureTransport: false`. Since the request in question uses HTTP, that deny condition is met, and an explicit deny always overrides any allow statement in the policy. As a result, even a request from an otherwise permitted IP address is denied because of the insecure protocol.

A VPC endpoint for Amazon S3 (a gateway endpoint) allows resources in private subnets to access S3 using private IP addresses with traffic staying entirely within the AWS network, without any internet gateway, NAT device, or VPN connection. Since patches are stored in S3 buckets, the application can retrieve patch files directly over the endpoint, and an endpoint for DynamoDB can handle patch metadata or state tables. This satisfies the no-internet-route requirement while enabling secure patch downloads.

An SCP applied at the organization root in AWS Organizations is an identity-policy boundary that affects every principal, including the root user, in every member account. By explicitly denying the s3:PutBucketPublicAccessBlock action, users cannot create, change, or delete S3 Block Public Access settings, effectively preventing all accounts from removing public-access protections. This is the only option that gives a centrally manageable, organization-wide preventive control.

A NAT gateway in a public subnet is correct because it enables instances in private subnets to initiate outbound IPv4 traffic to the internet, such as software updates or API calls, while preventing unsolicited inbound connections from reaching them. The NAT gateway resides in a public subnet with an Elastic IP and uses the internet gateway to reach external networks, while private subnet route tables direct 0.0.0.0/0 traffic to the NAT gateway. It is fully managed, scales automatically, and does not require patch management—unlike a NAT instance.

The database security group should have an inbound rule that references the web server security group as its source rather than a CIDR block. This allows the web tier to reach the database service on the required port, such as 3306 or 5432, while keeping the database isolated from all other sources. Because security group references are stateful and evaluated dynamically, this rule continues to work as web instances scale or are replaced, and it does not require the database to have a public IP or an internet gateway route.

This SCP is correct because it applies at the organization level to all member accounts and uses the global IAM condition key iam:InstanceProfile to require a specific instance profile ARN. The deny rule blocks any ec2:RunInstances call from any principal—user, role, or service—that does not include the required profile in its parameters. The condition key is evaluated exactly and provides a preventive guardrail that cannot be bypassed by user-specific policy exceptions.

AWS Transit Gateway acts as a hub to connect multiple VPCs and on-premises networks, enabling you to implement a hub-and-spoke routing architecture without VPC peering complexities. By attaching a dedicated inspection VPC to the Transit Gateway and configuring route tables so that all inter-VPC traffic is sent to that inspection VPC as a next hop, security appliances (e.g., Palo Alto, Fortinet) can inspect and filter all traffic. This provides centralized visibility and control over east-west traffic while avoiding the scaling limits and meshed connections of VPC peering.

Security groups are stateful, instance-level firewalls, so modifying the security group attached to the instance to revoke all outbound rules will immediately block the compromised instance's egress traffic without affecting other instances in the subnet. Changes apply instantly to the ENI, and because security groups are scoped to the instance, this provides precise, surgical isolation. This is the fastest way to stop malicious outbound communication while preserving the instance for investigation.

AWS WAF is a web application firewall that protects web applications by inspecting HTTP(S) requests and allowing or blocking them based on rules you define. It specifically includes managed rule groups and match conditions for SQL injection and cross-site scripting (XSS), as well as rate-based rules to mitigate abusive traffic. Since the application is running in EC2 behind an Application Load Balancer or Amazon CloudFront, AWS WAF can be attached to those endpoints directly.

An SCP applied at the root or OU level with a Deny effect for ec2:RunInstances and a StringNotLike/StringNotEquals condition on ec2:InstanceType explicitly blocks noncompliant launches for all principals inside the affected accounts, including IAM users, roles, and the root user. SCPs provide an authoritative guardrail because they are evaluated as a filter on the account's effective permissions and cannot be overridden by a more permissive IAM policy within that account. This gives central governance across the entire AWS Organization, making it the correct preventive control.

A public subnet is defined by having a route table entry with a destination of 0.0.0.0/0 pointing to an Internet Gateway (IGW). This default route enables resources with public IPs to directly send and receive traffic from the internet. While the IGW is the actual gateway, the route in the public subnet is the configuration that makes the subnet public. Therefore, public subnets with routes to the IGW are a critical part of the architecture for internet-facing components.

Gateway Load Balancer sits inline at Layers 3 and 4 by encapsulating traffic in GENEVE tunnels, forwarding packets to a fleet of firewall appliances while preserving flow symmetry. A Gateway Load Balancer endpoint is created in each subnet and becomes the next-hop target in VPC route tables, so all traffic entering or leaving those subnets is transparently steered through the firewall fleet. This design also provides health checks and autoscaling for the security appliances.

This approach centralizes secret storage, enables automatic rotation, and uses caching to reduce API calls and latency. The Lambda function retrieves the secret at runtime; caching ensures that frequent invocations do not overwhelm Secrets Manager and that rotated credentials are picked up after cache expiry. This minimizes operational overhead and improves security.

Referencing the ALB's security group ID as the source makes the EC2 rule follow the load balancer automatically, so only traffic from that ALB is permitted. This is more precise than CIDR ranges, which would also admit any host in the ALB's subnets.

This is the correct and most restrictive inbound rule for a public HTTPS endpoint because HTTPS is implemented with TLS over TCP and defaults to destination port 443. Allowing TCP 443 from 0.0.0.0/0 enables any internet client to initiate a TCP connection and perform a TLS handshake with the web server. Because NACLs are stateless, you must also configure a separate outbound rule allowing the ephemeral port range (1024–65535) so the server's return traffic can reach that client. Restricting the inbound rule to TCP 443 avoids exposing other ports while still meeting the functional requirement.

AWS Shield Advanced provides cost protection to help offset charges incurred when protected resources automatically scale in response to a DDoS attack. For example, if a DDoS attack causes an Application Load Balancer to scale out or CloudFront to serve more requests, AWS can issue billing credits for those additional resource usage charges, as long as the resources are protected by Shield Advanced and the attack is detected. This ensures customers are not financially penalized for the very elasticity that keeps their applications resilient during an attack.

AWS Key Management Service (AWS KMS) is a fully managed service that centralizes the creation, storage, rotation, and deletion of customer master keys (CMKs). S3 integrates with KMS through server-side encryption (SSE-KMS), where S3 uses a KMS key to encrypt each object's data key automatically and enforces IAM policies on key usage. This gives you centralized control, auditability through CloudTrail, and seamless S3 encryption, making KMS the correct and standard service for encrypting data at rest in S3.

The policy contains separate Action and Resource elements, and IAM permits an action only when an explicit Allow statement matches that action. Because ec2:TerminateInstances appears nowhere in the first statement's Action list (which grants Start and Stop) or in the second statement's Describe-only list, the action is implicitly denied by IAM's default-deny evaluation. Without an explicit Allow, no other statement or wildcard can rescue it; the request fails with an UnauthorizedOperation error.

Security groups are stateful and are attached to elastic network interfaces (ENIs), automatically permitting return traffic without requiring separate outbound rules for responses. They can be applied consistently across all instances within a subnet to provide effective subnet-wide filtering with connection tracking, which aligns with the security team's need for granular, connection-aware traffic control. Because they operate per-interface and maintain state, they are the correct choice in this scenario.

For instances in a private subnet to reach the internet through a NAT gateway, the subnet's route table must have a default route (0.0.0.0/0) with the NAT gateway as the target. If this route is missing, any outbound internet-bound traffic has no valid next hop and is dropped, causing the connectivity failure. After adding this route, ensure the NAT gateway itself is in a public subnet with an associated Elastic IP and that the public subnet's route table points 0.0.0.0/0 to an internet gateway. This is the most direct and common cause when private instances cannot access the internet.

The aws:SourceVpce condition key is the standard and most direct way to restrict S3 bucket access to a single VPC endpoint. By including this condition in a bucket policy statement, you can match the VPC endpoint ID that appears in the request context, ensuring only requests that come through that endpoint are allowed. For example, you can pair an Allow effect for the endpoint's traffic with Principal '*' and the condition 'StringEquals' on aws:SourceVpce, providing fine-grained control.

Enabling TLS/SSL on the database connections encrypts the entire session between the application and the database, protecting the data from eavesdropping or tampering while it traverses the network. This is a direct, protocol-level mitigation for the lack of encryption between the application and the database, and it can be enforced at the database server (e.g., requiring SSL/TLS for all client connections) and supported by the client driver. It does not change network routing or access control, but it specifically ensures confidentiality and integrity of the data in transit.

By using the ALB's security group as the source in the instance's inbound rule, the rule matches traffic from any ENI that has that security group attached. As the ALB scales, its new ENIs are automatically covered because they inherit the same security group, so the rule remains current without manual updates. This creates a precise, security-group-to-security-group boundary that ensures only the ALB can initiate traffic to the instances, which is the recommended pattern.

A Direct Connect public virtual interface links to AWS public services over the dedicated connection, but the traffic on the link itself is unencrypted. By overlaying an IPsec VPN tunnel on that public VIF, you encrypt all traffic while still using the Direct Connect physical link, satisfying both the Direct Connect and encryption-in-transit mandates. This approach is the standard way to add encryption to a Direct Connect connection that also needs access to public AWS endpoints.

Route tables in the VPC control where each destination CIDR is sent. If the private subnet route table contains a route for the on-premises CIDR pointing to the NAT Gateway, traffic destined for on-premises is sent to the NAT Gateway, which is designed only for internet-bound traffic and cannot forward it across the Direct Connect or virtual private gateway. Because the route to the NAT Gateway overrides the propagated Direct Connect route, the instances cannot reach on-premises resources. This is the correct root cause.

AWS Network Firewall is the correct choice because it is a managed, stateful firewall that can inspect all traffic crossing subnet boundaries within the VPC, including traffic routed between application tiers or from a transit gateway. It combines stateless rule groups with stateful inspection engines (Suricata-compatible) to detect and block malicious payloads, protocol anomalies, and known threat signatures at wire speed. By forcing traffic through firewall endpoints in each Availability Zone and using route tables, you can enforce intrusion prevention and traffic filtering across the VPC, which aligns directly with the requirement for network-level threat detection and blocking.

An Origin Access Identity (OAI) is a dedicated CloudFront user identity that CloudFront uses to authenticate to S3 when fetching objects. By granting the OAI read permission (e.g., s3:GetObject) in the bucket policy and removing public access, the bucket becomes private and only requests authenticated as that OAI can succeed. This ensures direct S3 access by anonymous users is denied while CloudFront can still retrieve and distribute the content.

AWS Service Catalog acts as a governed provisioning layer for CloudFormation templates, allowing administrators to create portfolios of approved products and attach tag options, stack constraints, and IAM roles to those products. When a user provisions a product, Service Catalog automatically applies the configured tag options to the stack and all resources within it, and can reject deployment if required tags are missing. This makes it the only option here that prevents non-compliant infrastructure from being created while still allowing users to deploy via CloudFormation.

A transit gateway with carefully designed route tables is the standard way to enforce centralized inspection: attach all VPCs to the transit gateway, then configure a route in each spoke VPC's propagation that sends inter-VPC destination CIDRs to the firewall appliance's elastic network interface in the shared services VPC. The firewall inspects and forwards the traffic back to the transit gateway, which delivers it to the destination VPC. This enables deterministic, high-availability routing through the security appliance.

Security groups are stateful, instance-level firewalls that allow you to reference another security group as a source. By creating a web server security group that allows inbound TCP/443 and TCP/80 from 0.0.0.0/0, and an application server security group with an inbound rule whose source is the web server security group ID, traffic is permitted only from the specific EC2 instances associated with that web security group. This precisely satisfies the requirement without exposing the application tier directly to the internet, and it automatically accounts for new web instances that join the group.

The Client VPN endpoint is the central AWS server component that clients connect to; it is configured with a server certificate, authentication methods (such as mutual TLS, SAML, or Active Directory), and connection parameters like client CIDR ranges and DNS settings. It serves as the termination point for TLS-based VPN sessions and is a required component because without it, there is nothing for remote clients to establish a tunnel with. All other components (like target network associations and authorization rules) are configured on this endpoint.