Infrastructure Security practice questions

Install the CloudWatch Logs agent on all instances to capture local kernel network logs.

Why wrong: Installing and managing agents on every EC2 instance increases operational overhead significantly. While kernel logs provide detailed internal information, they do not capture traffic blocked by security groups at the infrastructure level, as those packets never reach the operating system's networking stack for the agent to see.

Enable Amazon GuardDuty and review the 'UnauthorizedAccess:EC2/SSHBruteForce' findings.

Why wrong: GuardDuty is a threat detection service that analyzes logs to find malicious activity, but it does not provide a complete record of every rejected connection. Using findings alone would miss legitimate traffic patterns or non-malicious failures that are required for a comprehensive three-year regulatory compliance audit.

Configure an AWS Config rule to monitor the state of all Security Group rules daily.

Why wrong: AWS Config monitors the configuration of resources rather than the actual traffic flows. While it can alert a security engineer if a security group rule is changed, it cannot provide any visibility into the actual packets being accepted or rejected by the network interfaces based on those rules.

Add the CloudFront IP ranges to the ALB's Security Group inbound rules.

Why wrong: CloudFront IP ranges are public and can change frequently, requiring constant manual updates or automation. Furthermore, allowing all CloudFront IPs would still permit traffic from distributions owned by other AWS customers, failing to isolate the ALB to only the company's specific distribution and its associated security policies.

Configure CloudFront to use an Origin Access Control (OAC) with the ALB as the target.

Why wrong: Origin Access Control is specifically designed for securing access to Amazon S3 buckets, not for Application Load Balancers. For ALBs, the recommended security mechanism involves header verification or AWS WAF, as OAC does not support the protocol handshakes required for load balancer origins in the same manner as S3.

Configure the ALB to only accept traffic containing a custom header set by CloudFront.

Why wrong: By adding a secret custom header in the CloudFront origin settings and creating an ALB listener rule that checks for this header, you ensure only requests through your distribution are processed. This effectively hides the origin from direct internet access even if the ALB has a public IP.

AWS Global Accelerator

Why wrong: Global Accelerator improves application performance and availability by routing traffic over the AWS global network, but it is not a primary DDoS mitigation service. While it can be protected by Shield, it does not inherently provide the deep packet inspection or rate-limiting features found in WAF or Shield.

Amazon Inspector

Why wrong: Amazon Inspector is an automated vulnerability management service that scans EC2 instances and container images for software vulnerabilities and unintended network exposure. It does not provide real-time protection or mitigation against active DDoS attacks, as its primary function is proactive security assessment and compliance reporting.

VPC Reachability Analyzer

Why wrong: VPC Reachability Analyzer is a configuration testing tool that helps troubleshoot connectivity issues between resources in your VPC. It performs static analysis of the network path but does not monitor live traffic or offer any defensive capabilities against external threats or distributed denial of service attempts.

Interface Endpoint for Amazon DynamoDB

Why wrong: Amazon DynamoDB does not currently support Interface VPC Endpoints (AWS PrivateLink). Interface endpoints use Elastic Network Interfaces (ENIs) with private IPs, but since DynamoDB only supports the Gateway type, attempting to create an interface endpoint for it would not be possible through the AWS Management Console or CLI.

Interface Endpoint for Amazon S3

Why wrong: While S3 does support Interface Endpoints, they are typically used for access from on-premises networks via Direct Connect or from other VPCs. For internal VPC traffic, Gateway Endpoints are usually preferred as they are free of charge and do not require the management of private IP addresses or ENIs.

Service Endpoint for Amazon Route 53

Why wrong: Route 53 is a global service and does not use VPC endpoints in the same way as S3 or DynamoDB. While Route 53 Resolver provides endpoints for DNS queries between on-premises and VPCs, it is not a 'Service Endpoint' for data access and is irrelevant to the requirement of securing S3/DynamoDB traffic.

AWS Trusted Advisor

Why wrong: Trusted Advisor provides recommendations for cost optimization, performance, and security based on AWS best practices. While it has some security checks, it is not a continuous configuration monitoring tool and does not allow for the creation of custom rules or automated remediation in the same way that Config does.

Amazon Inspector

Why wrong: Amazon Inspector focuses on vulnerability scanning within the operating system and network reachability of EC2 instances. It does not monitor the AWS-level configuration of the EBS volumes or the AMI properties themselves, which are part of the resource metadata managed by the AWS control plane.

AWS Security Hub

Why wrong: Security Hub aggregates findings from other services and performs its own security checks, but it relies heavily on AWS Config to perform the underlying resource evaluations. While Security Hub provides a high-level dashboard, AWS Config is the primary service responsible for the detailed configuration tracking and rule evaluation.

Use TLS/SSL for all application-level communication over the link.

Why wrong: TLS/SSL provides encryption at the application layer (Layer 7), not the network layer. While this secures individual application sessions, it does not encrypt the entire network tunnel or other non-TLS traffic. The requirement specifically asked for encryption at the network layer to cover all data in transit.

Configure a Transit Gateway with VPC Peering and enable default encryption.

Why wrong: Transit Gateway and VPC Peering manage routing and connectivity but do not automatically encrypt traffic across a Direct Connect link. While traffic between VPCs within the same region is encrypted by the AWS infrastructure, this does not extend to the hybrid connection between on-premises and the cloud.

Enable transparent data encryption on the RDS instance and configure security groups to restrict traffic exclusively to application server IP addresses.

Why wrong: Transparent data encryption secures data at rest on disk rather than traffic traversing the network in transit. While security groups restrict network paths, they do not provide cryptographic protection or encryption for packets moving across network wires.

Implement AWS Shield Advanced on the database subnet to automatically encrypt all database packets traversing the internal VPC network interfaces.

Why wrong: AWS Shield Advanced is a managed DDoS protection service designed to safeguard applications against volumetric and application-layer attacks. It does not provide cryptographic encryption for database connections or manage transport-layer security protocols.

Deploy a Network Load Balancer in front of the database and configure TLS termination listeners with self-signed cryptographic certificates.

Why wrong: Amazon RDS does not natively support placing a Network Load Balancer directly in front of managed database engines for TLS termination in this manner. Furthermore, self-signed certificates introduce trust risks and fail enterprise validation controls.

Apply an IAM policy to all users that denies access to the bucket if the source IP is outside the VPC range.

Why wrong: IAM policies are identity-based and difficult to maintain when managing hundreds of users. IP-based filtering is also unreliable as public IPs can change or be spoofed. Bucket policies are resource-based and provide a centralized, immutable enforcement point that is not dependent on individual user permissions or dynamic IP addresses.

Enable S3 Block Public Access at the bucket level and attach an ACL that restricts access to the VPC.

Why wrong: S3 ACLs are deprecated in favor of bucket policies and do not support granular VPC-level conditions. While Block Public Access is a security best practice, it does not provide the specific logic required to filter traffic by VPC. ACLs lack the expressive power to define complex network-based access control requirements.

Configure a Security Group on the S3 bucket to allow traffic only from the VPC CIDR block.

Why wrong: Amazon S3 does not support attaching Security Groups directly to bucket resources. Security Groups are designed for stateful inspection of traffic at the network interface level for EC2 instances or RDS databases. S3 access control must be managed via policies and endpoint configurations rather than traditional firewall-style security group rules.

Use VPC Flow Logs to monitor and encrypt traffic between instances.

Why wrong: VPC Flow Logs are for network observability and monitoring, not for data encryption. Flow logs capture metadata about IP traffic but do not provide any mechanisms to encrypt the actual payload of the packets moving between EC2 instances. They are an audit tool, not a data security or encryption tool.

Implement TLS/SSL at the application layer for all inter-instance communication.

Why wrong: Application-layer encryption using TLS is the standard for securing data in transit. By enforcing mutual TLS (mTLS), the organization ensures both encryption and identity verification between instances. This approach is highly scalable and works independently of the underlying network configuration, providing a robust security posture across diverse infrastructure components.

Enable Amazon S3 bucket encryption using a KMS customer-managed key.

Why wrong: S3 bucket encryption protects data at rest within S3 storage, not data moving between EC2 instances over the network. This solution is irrelevant to the requirement of encrypting traffic in transit between two compute instances, as it does not address network-level data movement or inter-process communication security protocols.

AWS WAF

Why wrong: AWS WAF is the correct tool for inspecting HTTP/HTTPS requests at the application layer. It allows for the creation of rules that inspect web requests for common vulnerabilities such as SQL injection, cross-site scripting (XSS), and malicious bots, directly addressing the requirement for Layer 7 protection on the load balancer.

Network ACLs

Why wrong: Network ACLs operate at Layer 4 (ports and protocols) and are stateless. They can block traffic based on IP address ranges but are incapable of inspecting the content of HTTP requests. Therefore, they cannot detect or block application-layer attacks like SQL injection, which require deep packet inspection of the request body.

Security Groups

Why wrong: Security Groups act as virtual firewalls for instances, operating at the network level. They are stateful but provide no Layer 7 inspection capabilities. Security groups cannot read HTTP headers or query parameters to block SQL injection or XSS, making them insufficient for protecting against sophisticated application-layer web exploits.

Attach an IAM policy to all users to deny 'ec2:CreateVolume' without an encryption key.

Why wrong: Managing individual IAM policies for every user in an organization is administratively intensive and error-prone. Policies can be modified or removed by users with sufficient privileges. Using SCPs or account-level settings is far more secure and reliable for enforcing infrastructure-wide compliance than attempting to rely on individual user-based IAM policies.

Deploy a Lambda function that monitors for unencrypted volumes and deletes them automatically.

Why wrong: Automated remediation is a best practice for infrastructure security. A Lambda function triggered by EventBridge can detect non-compliant resources and either encrypt them or delete them. This provides a safety net for existing resources that might have been created before account-level policies were fully enforced, ensuring continuous compliance across the account.

Require users to manually select an AWS KMS key for every volume they create.

Why wrong: Relying on manual user intervention is not a secure strategy. Users may forget or choose to bypass the requirement if they have permission to do so. Infrastructure security should be enforced through automated guardrails and account-level settings, not by expecting users to remember security configurations for every single resource provisioned.

Apply a Security Group to the VPC endpoint that restricts inbound traffic to the local VPC CIDR.

Why wrong: While Security Groups control network access to the endpoint, they do not manage identity-based access. An attacker with a foothold in the VPC could still use the endpoint if it is not restricted via an endpoint policy. Security groups provide network-level filtering, but endpoint policies provide the necessary identity-based service governance.

Modify the route table to deny traffic from outside the VPC to the endpoint.

Why wrong: Route tables dictate traffic flow at the network level; they cannot enforce identity-based restrictions or block specific principals from using an endpoint. Once traffic enters the VPC, the route table doesn't have the granular capability to distinguish between authorized and unauthorized requests destined for the VPC endpoint resource itself.

Use a Network ACL to block all traffic to the VPC endpoint subnet except for the local VPC.

Why wrong: Network ACLs are stateless and operate on subnets, not individual endpoints. They lack the intelligence to enforce policies based on identity or service-level access requirements. Using ACLs for this purpose would be overly broad and fail to address the core security requirement of restricting service usage based on principal identity.

Use AWS WAF on the ALB to enforce a header check for a secret value passed by CloudFront.

Why wrong: Configuring CloudFront to inject a custom header (configured in the origin request policy) and using AWS WAF to inspect that header at the ALB provides a robust, cryptographically sound way to restrict traffic. This ensures only requests originating from the intended distribution are processed, preventing direct access and improving overall security.

Set up a Network ACL to permit only traffic arriving from CloudFront's edge locations.

Why wrong: Network ACLs are not suitable for identifying CloudFront traffic because they operate at the IP layer. CloudFront uses a vast, global range of IP addresses that change frequently. Attempting to maintain an ACL with these ranges is operationally impossible and provides a weak security posture compared to layer-7 header validation.

Configure the ELB to only accept connections using an SSL certificate issued by CloudFront.

Why wrong: The ALB and CloudFront use independent SSL/TLS configurations. You cannot force an ALB to check for a specific certificate associated with a CloudFront distribution. The ALB validates the certificate presented to it based on its own trusted CA store, meaning this proposed mechanism is technically impossible to implement as described.

Enable Transit Gateway peering for all VPCs to ensure full connectivity.

Why wrong: Enabling full connectivity creates a flat network, which is a major security risk. In a multi-VPC environment, you should follow the principle of least privilege by restricting inter-VPC communication to only what is strictly necessary. Full mesh connectivity increases the blast radius if any single VPC is compromised by an attacker.

Disable the default route table and rely on Network ACLs for isolation.

Why wrong: Network ACLs are stateless and difficult to manage across multiple VPCs. They provide insufficient protection against complex routing threats. Transit Gateway route tables are designed specifically for this purpose and provide a more scalable, centralized, and manageable solution for controlling traffic flow between VPCs compared to relying solely on ACLs.

Attach all VPCs to the same route table and use Security Groups for filtering.

Why wrong: Relying solely on security groups for cross-VPC isolation is problematic because security groups are localized to their respective VPCs. They cannot be used to manage traffic flow at the Transit Gateway level. Using a single route table exposes all connected VPCs to each other, which contradicts the goal of network isolation.

Place the API Gateway in a private subnet and attach an Internet Gateway for internal traffic.

Why wrong: API Gateway is a managed service and cannot be placed directly into a VPC subnet in the traditional sense. Furthermore, attaching an Internet Gateway creates a path to the public internet, which violates the requirement for private-only access. The correct approach involves using PrivateLink to bridge the VPC to the service.

Use a Network ACL to block all IP addresses from the public internet to the API Gateway.

Why wrong: API Gateway is a regional or global managed service with a public endpoint by default. You cannot use Network ACLs to block traffic to a managed service because you do not have control over the underlying network interfaces in the same way you do for an EC2 instance. Resource policies are the correct tool.

Set up a CloudFront distribution and point it to the API Gateway's public IP address.

Why wrong: Using CloudFront exposes the API to the public internet and adds an unnecessary layer of complexity. If the requirement is to restrict traffic to a specific VPC, you must keep the traffic off the public internet entirely. Using PrivateLink is the only way to achieve this level of network isolation for API Gateway.

The bucket has an ACL allowing the 'Everyone' group, which should be replaced by a private bucket policy.

Why wrong: S3 ACLs can grant access to the 'Everyone' group (which includes anonymous internet users). This is a common misconfiguration. Removing the ACL and replacing it with a focused bucket policy that adheres to the principle of least privilege is the correct way to secure the bucket while maintaining necessary functionality.

The bucket has an IAM policy attached directly to the bucket resource.

Why wrong: IAM policies cannot be attached to S3 buckets; only bucket policies (resource-based policies) can be attached to buckets. The confusion between IAM policies and bucket policies is a common error. Remediation involves checking the bucket policy for broad 'Allow' statements and ensuring Block Public Access is enabled to prevent future accidental exposure.

The VPC endpoint for S3 is allowing cross-account access by default.

Why wrong: VPC endpoints for S3 do not grant cross-account access by default; they only provide a pathway for traffic to travel internally. Access to the bucket itself is still controlled by the bucket policy. If the bucket is accessible, it is because of its own policy or ACL, not the VPC endpoint configuration.

Configure S3 bucket policies to allow access only from the IP ranges of the permitted countries and use Origin Access Identity.

Why wrong: Maintaining a manual list of IP ranges within an S3 bucket policy is administratively burdensome and prone to errors. S3 does not natively support geographic location filtering based on IP intelligence. Additionally, Origin Access Identity is a legacy feature that lacks the security enhancements and regional support provided by the newer OAC.

Use AWS WAF on the S3 bucket to block non-European traffic and implement a VPC Endpoint for S3 to restrict access to CloudFront nodes.

Why wrong: AWS WAF cannot be directly attached to an Amazon S3 bucket; it must be associated with CloudFront, an Application Load Balancer, or an API Gateway. Furthermore, CloudFront is a global service that does not reside within a specific VPC, making a VPC Endpoint ineffective for restricting access to CloudFront.

Implement a Lambda@Edge function to check the viewer's IP address against a geo-database and use a signed URL strategy for all S3 objects.

Why wrong: While Lambda@Edge can perform geographic filtering, it introduces unnecessary latency and management overhead compared to native CloudFront geographic restrictions. Signed URLs protect individual objects from unauthorized sharing but do not inherently prevent direct S3 access unless combined with OAC, making this solution overly complex for the stated requirement.

Automatic mitigation of common infrastructure Layer 3 and Layer 4 DDoS attacks.

Why wrong: This feature is included in AWS Shield Standard, which is automatically enabled for all AWS customers. It protects against the most common network and transport layer attacks, such as SYN floods or UDP reflection attacks, to maintain the availability of AWS services without requiring any manual configuration or additional cost.

Inline mitigation using AWS global edge locations to reduce latency for legitimate users.

Why wrong: Both Shield Standard and Shield Advanced utilize the global AWS edge network to provide inline mitigation. This architecture allows AWS to absorb and scrub malicious traffic closer to the source, minimizing the impact on legitimate traffic and reducing the overall latency for users accessing protected resources globally.

Real-time visibility into DDoS events via the AWS Management Console and CloudWatch metrics.

Why wrong: While Shield Advanced provides more granular metrics and detailed reports, basic real-time visibility and CloudWatch metrics for DDoS events are available to all customers. Standard users can see event summaries, though they lack the deep forensic insights and post-event summaries provided by the Advanced tier's specialized dashboard.

All inbound and outbound TCP traffic on port 443 for the specified network interface.

Why wrong: The filter explicitly specifies 'ingress' as the TrafficDirection, meaning only inbound traffic is captured. To mirror outbound traffic, a separate rule with the TrafficDirection set to 'egress' would be required. This configuration is unidirectional and will ignore any response traffic leaving the network interface.

All inbound traffic regardless of protocol, as long as it originates from 0.0.0.0/0.

Why wrong: The filter is restricted by the 'Protocol' field set to 6 (TCP) and the 'DestinationPortRange' set to 443. Traffic using other protocols, such as UDP (17) or ICMP (1), or traffic on different TCP ports, will not match this rule and will not be mirrored to the target appliance.

Outbound traffic from the 10.0.1.0/24 subnet to any destination on TCP port 443.

Why wrong: This interpretation reverses the TrafficDirection and the roles of source and destination CIDR blocks. The 'ingress' direction refers to traffic flowing into the ENI. For outbound traffic, the Rule would need to specify 'egress' and typically use the subnet as the SourceCidrBlock instead.

VPC Peering between all 50 VPCs and a centralized shared services VPC.

Why wrong: VPC Peering does not support transitive routing, meaning you cannot route through one VPC to get to another. To connect 50 VPCs in a full mesh or even a hub-and-spoke for internet egress, you would need hundreds of peering connections, which is complex to manage and difficult to scale.

A separate Virtual Private Gateway (VGW) for each of the 50 VPCs.

Why wrong: Using 50 separate VGWs would require 50 individual VPN tunnels from the on-premises firewall, which is a significant management burden and may exceed the hardware limits of on-premises devices. This approach lacks the centralized management and routing efficiency provided by a Transit Gateway solution.

AWS Direct Connect with a Public Virtual Interface for encrypted data transfer.

Why wrong: A Public Virtual Interface is used to access public AWS services over Direct Connect, not for private VPC connectivity. While Direct Connect provides a dedicated path, it does not inherently provide encryption like a VPN. For encrypted transit, a VPN over Direct Connect or a Transit VIF would be required.