CCNA Network Security, Compliance and Governance Questions

To meet PCI DSS compliance, the company needs to control and inspect outbound traffic from private subnets. Option A is correct because a central inspection VPC with AWS Network Firewall can inspect and control all outbound traffic, providing a controlled egress point. Option B is correct because VPC endpoints for S3 and DynamoDB keep traffic to these services within the AWS network, avoiding the internet.

Option E is correct because a NAT gateway allows private subnets to access the internet for necessary updates or patches, but combined with other controls (like Network Firewall) it provides a controlled egress. Option C is incorrect because security groups deny all outbound traffic by default, but that would block all necessary outbound connections, including to AWS services; it does not provide a controlled egress point. Option D is incorrect because an Internet Gateway allows direct outbound access without inspection or control, violating PCI DSS requirements for controlled egress.

AWS WAF, is the correct choice because it is a web application firewall specifically designed to filter and monitor HTTP/HTTPS requests to protect against common web exploits like cross-site scripting (XSS), SQL injection, and other OWASP Top 10 threats. Option A is incorrect because Security Groups act as a virtual firewall at the instance level, controlling inbound and outbound traffic based on IP addresses and ports, not at the application layer. Option B is incorrect because Network ACLs are stateless subnet-level firewalls that also operate at the network layer, not the application layer.

Option D is incorrect because AWS Shield Advanced provides DDoS protection, not web application filtering or monitoring of HTTP requests.

VPC endpoints (Gateway endpoints for S3 and DynamoDB) allow private subnet instances to access these AWS services without traversing the internet, and endpoint policies can restrict access to specific services and actions. Option A is incorrect because security groups cannot filter by destination service; they filter by IP address, and AWS services use dynamic IP ranges. Option B is incorrect because a NAT gateway allows all outbound traffic to the internet, not just to specific services, and would not restrict to only S3 and DynamoDB.

Option C is incorrect because an internet gateway would allow unrestricted outbound traffic to the internet, not just to specific AWS services.

The first statement allows CreateInternetGateway in us-east-1. The second statement denies CreateInternetGateway if the resource tag 'purpose' is not 'production'. When creating a resource without tags, the condition StringNotEquals evaluates to true (since no tag, it's not equal to 'production'), so the Deny applies.

The Deny overrides the Allow, so the action is denied. Therefore, option C is correct because the Deny statement applies. Option A is incorrect because the first statement does allow it in us-east-1, but the Deny overrides.

Option B is incorrect because the creation is denied, not permitted with a warning. Option D is incorrect because the Deny overrides the Allow.

Security groups are stateful and allow outbound responses automatically, but the unexpected connections are likely due to another instance with the Web SG attached. The DB SG inbound rule allows traffic from the Web SG, which applies to all instances with that SG, including unauthorized ones. Option A is incorrect because default NACLs allow all traffic, but inbound NACL rules could be the issue if they were modified, but they are default.

Option B is incorrect because the DB SG inbound rule is from the Web SG, not 0.0.0.0/0. Option D is incorrect because while security groups are stateful, that does not cause unexpected connections; it only ensures return traffic is allowed.

To allow instances in a private subnet to initiate outbound internet connections while preventing inbound connections, a NAT Gateway placed in a public subnet is required. The NAT Gateway translates private IPs to its own public IP. Additionally, the private subnet's route table must have a default route (0.0.0.0/0) pointing to the NAT Gateway to direct outbound traffic.

Option A (VPC Gateway Endpoint for S3) is for private access to S3, not general internet. Option B (security group allowing inbound from 0.0.0.0/0) would allow inbound connections, violating the requirement. Option D (Internet Gateway attached to private subnet) is incorrect because an Internet Gateway is attached to the VPC, not a subnet, and would allow inbound traffic if used in a route table.

The most likely cause is that the NAT gateway's security group inbound rule is too restrictive. NAT gateways are managed services and do not have security groups; if one were hypothetically attached, its inbound rule allowing only ports 443 and 80 would block return traffic on ephemeral ports. More critically, security groups are stateful—if outbound traffic is allowed, return traffic is automatically permitted regardless of inbound rules.

Therefore, option D is incorrect. Option B is incorrect because the NAT gateway has an Elastic IP, and option C is incorrect because the private subnet route table has a default route to the NAT gateway.

The VPC Flow Logs show outbound traffic from 10.0.1.5 to 203.0.113.5 on port 443 was allowed (ACCEPT), but the inbound response was rejected. Security groups are stateful, so they automatically allow return traffic for established connections. Therefore, a security group (Option C) would not cause this REJECT.

Network ACLs are stateless and require explicit inbound rules; if the inbound rule for traffic from 203.0.113.5 is missing, the response is dropped, resulting in a REJECT. Option A correctly identifies this. Option B (AWS WAF) operates at the application layer (Layer 7) and is not reflected in VPC Flow Logs, which capture Layer 3/4 traffic.

Option D (route table) would cause a lack of connectivity, not a REJECT entry in flow logs.

Service control policies (SCPs) in AWS Organizations can be used to centrally deny CloudFormation stack set modifications at the organization, OU, or account level, ensuring that only authorized IAM policies can allow such actions. Option A is wrong because AWS Config rules with remediation only detect and automatically fix noncompliant resources, not prevent modifications. Option B is wrong because CloudFormation stack policies protect resources within a stack (e.g., prevent deletion), not control who can update the stack set.

Option D is wrong because IAM permissions boundaries set the maximum permissions for an IAM user or role, but they do not provide a global deny across accounts like SCPs do.

An S3 bucket policy can use the aws:SourceVpce condition key to allow access only from a specific VPC endpoint, restricting requests to those originating from that endpoint. Option C is correct because a VPC endpoint policy controls what actions principals within the VPC can perform on the S3 bucket, providing an additional layer of access control. Option A is incorrect because security groups are not supported for gateway VPC endpoints (which are used for S3); they cannot be assigned to such endpoints.

Option D is incorrect because network ACLs operate at the subnet level and cannot enforce restrictions based on the source VPC or VPC endpoint; they control traffic entering/exiting subnets but do not apply to S3 bucket access directly. Option E is incorrect because IAM roles grant permissions to identities (users or services) but do not restrict traffic origin; they do not limit access to traffic from a specific VPC.

AWS Config rules can evaluate compliance of resources and trigger automatic remediation actions. A managed rule such as 'restricted-common-ports' or a custom rule can detect VPCs with internet gateways, and an accompanying remediation action can automatically detach them. Option A (Amazon GuardDuty) is a threat detection service, not a configuration compliance tool.

Option B (AWS CloudTrail) logs API calls but does not evaluate current resource configurations. Option C (Service control policies, SCPs) define permissions boundaries but cannot detect or remediate existing non-compliant resources. Option D is correct.

A more specific route (e.g., a /32 or /24 for the destination network) in the VPC route table will take precedence over the default route (0.0.0.0/0) that points to the firewall endpoint. This causes traffic destined for that specific network to bypass the firewall. Option A is incorrect because route propagation adds routes from VPN or Direct Connect but does not inherently cause bypass.

Option B is incorrect because if the subnet is not associated with the firewall's route table, it uses the main route table, which could bypass the firewall, but the key issue here is the existence of a more specific route. Option C is incorrect because the firewall endpoint being in a different Availability Zone does not cause traffic to bypass; it can cause increased latency or other issues but not bypass.

The correct checks to perform when troubleshooting VPC peering connectivity are to ensure the VPC peering connection is in the 'active' state (Option E) and that the security group attached to the RDS instance allows inbound traffic from the CIDR block of VPC A (Option A). Without an active peer connection, traffic cannot flow even if route tables are correct. Similarly, security group rules are stateful and must explicitly permit inbound traffic; NACLs are stateless but since the issue is within the same VPC peering, security groups are a likely culprit.

IAM roles and Internet Gateways are not required for VPC peering traffic.

The immediate action is to modify the security group inbound rule to restrict SSH access to only the company's public IP range (Option A). This reduces the attack surface by limiting exposure to trusted IPs. Option B is incorrect because adding a network ACL deny rule is not as effective since NACLs are stateless and the security group still allows inbound SSH from anywhere; also, NACLs operate at the subnet level and do not override security group rules for inbound traffic within the VPC.

Option C is incorrect because moving instances to a different subnet is disruptive and does not address the current security group rule. Option D is incorrect because deleting the security group may affect running instances and is not the simplest immediate action.

VPC endpoints for S3 (Gateway endpoint) and SQS (Interface endpoint) provide private connectivity within the AWS network, meeting the security requirement. Option D is correct because it creates the necessary endpoints and updates route tables and security groups. For the Gateway endpoint, route tables must be updated to direct S3 traffic through the endpoint.

For the Interface endpoint, security groups must allow inbound traffic from the EC2 instances. Option A is wrong because CloudFront is a content delivery service, not a private connectivity solution for S3 or SQS. Option B is wrong because a NAT gateway would route traffic over the internet, violating the requirement.

Option C is wrong because Direct Connect is an overkill and does not directly provide VPC endpoint connectivity for S3 and SQS.

Options D and E are correct statements about AWS WAF. AWS WAF is a web application firewall that can block or allow web requests based on conditions such as IP addresses, HTTP headers, and URI strings (D). It can be deployed on Application Load Balancers, Amazon CloudFront distributions, and Amazon API Gateway APIs (E).

Option A is incorrect because network-layer DDoS protection is provided by AWS Shield, not WAF. Option B is incorrect because WAF does not inspect VPC Flow Logs; it inspects HTTP/HTTPS traffic at the application layer. Option C is incorrect because while WAF can be configured to automatically respond to certain conditions, it does not automatically mitigate DDoS attacks; AWS Shield Advanced provides automatic DDoS mitigation.

The correct approach is to use security groups. The ALB security group should allow inbound from corporate IPs, and the EC2 instances' security group should allow inbound only from the ALB's security group. This ensures that traffic from the internet first passes through the ALB, which performs health checks using its private IPs (which are part of the ALB's security group).

Option B is incorrect because having multiple target groups does not control traffic filtering. Option C (WAF) can filter by IP but still requires allowing health check traffic, and it adds unnecessary complexity. Option D (NACL) is stateless and would require complex rules to allow return traffic and health checks, making it less secure and manageable.

You can reference a security group from a peered VPC as the source in a security group rule, allowing fine-grained control based on the security group ID rather than CIDR blocks. Option A is wrong because VPC peering route tables control routing, not traffic filtering. Option B is wrong because security groups can reference the CIDR of a peered VPC, but that does not allow specifying individual ports from the peered VPC's resources; it's less specific than referencing the security group ID.

Option D is wrong because Network ACLs cannot reference security groups; they only allow CIDR-based rules, and they are stateless.

The Deny statement denies the ec2:AuthorizeSecurityGroupIngress action only when the condition is satisfied—specifically, when the CIDR being added is 0.0.0.0/0. The Allow statement permits the action when the user's source IP falls within 203.0.113.0/24. Since the user's IP is 203.0.113.10, the Allow applies.

However, the Deny overrides the Allow for the specific case of 0.0.0.0/0. For other CIDRs, such as 203.0.113.10, the Deny condition is not met, so the Allow takes effect. Option A is incorrect because the condition key is valid; Option B is incorrect because the Deny does not block all ingress actions; Option C is incorrect because the Allow is not unconditional—it depends on the user's source IP.

Security groups are stateful, so allowing inbound from on-premises and outbound to 0.0.0.0/0 works. Option B is correct because security groups automatically allow return traffic. Option A is wrong because NACLs are stateless and require explicit rules for return traffic; allowing inbound from on-premises and outbound to 0.0.0.0/0 would not automatically allow return traffic, so responses from EC2 instances to on-premises would be blocked.

Option C is wrong because it would allow all inbound traffic from any source, not limiting to on-premises. Option D is wrong because it would deny all inbound traffic, blocking necessary connections from on-premises.

The endpoint policy requires the aws:SourceVpc condition to match the VPC ID, but the condition key is misspelled or the value is incorrect? Actually, the condition is correct. However, the error is likely because the route table does not have a route to the endpoint. Gateway endpoints require a route in the associated route table that points to the endpoint.

Option A is wrong because the endpoint policy already allows s3:GetObject. Option B is wrong because the endpoint is already associated with the route table. Option C is wrong because the bucket policy is not shown; but the issue is likely the route.

Option D is correct: add a route to the S3 service in route table rtb-12345678.

AWS WAF allows adding an IP address to an existing IP set and updating the associated rule to block it, which takes effect quickly and is the most efficient method. Option B is wrong because security groups are stateful and cannot explicitly deny inbound traffic; they only allow rules. Option C is wrong because Network ACLs operate at the subnet level and require updating both inbound and outbound rules, which is slower and less granular than WAF IP sets.

Option D is wrong because creating a new web ACL and associating it takes more steps than updating an existing rule, making it less immediate.

The Service Control Policy (SCP). SCPs are used in AWS Organizations to centrally control the maximum available permissions for all accounts in an organization. They can be used to prevent security groups from allowing inbound SSH from 0.0.0.0/0 by denying the ability to create or modify security group rules that permit such traffic.

Network ACLs (Option A) operate at the subnet level and are not account-wide; they control traffic entering/exiting subnets, but cannot enforce organizational policies across multiple accounts. IAM policies (Option B) apply to users, groups, or roles, and cannot directly restrict security group configurations. AWS Config rules (Option D) are detective controls that can evaluate compliance but are not preventive; they do not block the creation of non-compliant security group rules.

Therefore, SCP is the appropriate preventive policy type.

A: Correct. AWS Network Firewall supports stateful inspection using Suricata-compatible rules, allowing deep packet inspection for threat detection. B: Correct.

Network Firewall can be integrated with AWS Transit Gateway to enable centralized inspection of traffic across multiple VPCs. C: Incorrect. Network Firewall is deployed within a VPC, not as a standalone service, and it requires a VPC to inspect traffic; it cannot inspect traffic between on-premises and AWS without a VPC.

D: Incorrect. Network Firewall does not provide automatic SSL/TLS decryption; it can only inspect traffic that is not encrypted or after decryption is performed by another service. E: Incorrect.

Network Firewall is a managed service, but it is always deployed inside a VPC, not outside.

The bucket policy includes a condition 'aws:SecureTransport': 'true', which requires all requests to use HTTPS. If the AWS SDK is configured to use HTTP instead of HTTPS, the request will be denied even though the IAM role has s3:PutObject permission. Option A is incorrect because the bucket policy likely grants access to all users in the account or to the IAM role specifically, not just the root user.

Option B is incorrect because server-side encryption is not required by the policy; only HTTPS is enforced. Option C is incorrect because the policy resource typically covers both the bucket and its objects, so access to the bucket is granted.

AWS Config can evaluate whether security groups allow unrestricted SSH access using managed rules like 'restricted-ssh'. Option C is correct because Config records configuration changes to Network ACLs and security groups, enabling tracking. Option D is correct because Config can trigger custom rules or send notifications via Amazon SNS when a security group rule is modified.

Option B is incorrect because Config does not block traffic; it only evaluates and can trigger remediation actions via other services. Option E is incorrect because Config evaluates resources after creation; it cannot prevent creation, though it can trigger automated remediation via Lambda or Systems Manager.

The correct answers are C and E. Security groups (E) are stateful and can reference other security groups as a source, allowing traffic between tiers only on required ports. Network ACLs (C) are stateless and provide a secondary layer of filtering at the subnet level.

Option A is wrong because a transit gateway is used to connect multiple VPCs, not for filtering within a VPC. Option B is wrong because VPC peering connects VPCs, and security groups cannot be applied to a peering connection. Option D is wrong because a single security group cannot differentiate traffic between tiers; each tier needs its own security group.

(Use multiple Availability Zones) is correct because it provides redundancy and improves availability, which is a key security best practice by ensuring fault tolerance. Option D (Restrict inbound SSH access to specific IP ranges) is correct as it minimizes the attack surface by limiting administrative access to authorized IPs only. Option A is wrong: VPC Flow Logs capture IP traffic information but do not block traffic; they are used for monitoring and analysis, not as a security control.

Option C is wrong: placing databases in public subnets exposes them to the internet, increasing risk; they should be in private subnets with controlled access. Option E is wrong: the default VPC security group allows all inbound traffic, which is overly permissive; custom security groups should be used to implement least privilege.

A Gateway VPC Endpoint for S3 is free of charge, highly available by design (within a Region), and does not require a NAT Gateway for S3 access. Traffic to S3 remains within the AWS network. VPC Flow Logs can be enabled to capture traffic to the endpoint for logging purposes. After verifying that no other outbound internet traffic is required, the NAT Gateway can be removed to reduce costs and eliminate the single point of failure.

Option A is incorrect because setting up a VPN connection to on-premises does not provide a direct path to S3; traffic would still need to traverse the internet or a partner network, and it adds unnecessary complexity and cost. Option C is incorrect because an Interface VPC Endpoint for S3 incurs hourly charges and data processing fees, making it less cost-effective than a Gateway Endpoint. Option D is incorrect because it keeps the NAT Gateway, which the company wants to replace due to cost and single point of failure concerns; the goal is to remove the NAT Gateway if no other outbound traffic is needed.

Although the security group allows all outbound traffic to 0.0.0.0/0, this rule does not apply to traffic destined for the S3 prefix list when using a VPC gateway endpoint. Gateway endpoints require a security group rule that explicitly allows HTTPS traffic to the S3 prefix list ID. Without this rule, traffic is blocked.

Option A is correct. Option B is incorrect because the VPC endpoint is indeed associated with the route table. Option C is incorrect because a NAT gateway is not needed for S3 access via the endpoint.

Option D is incorrect because the bucket policy is not the issue; the security group rule is missing.

SCPs do not apply to the root user of a member account. The root user can perform any action, including launching EC2 instances with public IP addresses, regardless of SCP restrictions. Option A is incorrect because SCPs apply to all IAM users and roles in the target OU, not just specific OUs; the issue here is the use of root user.

Option C is incorrect because SCPs apply to IAM users and roles, not just the root user; the root user is explicitly exempt. Option D is incorrect because IAM roles are subject to SCPs; they cannot bypass SCPs. The correct reason is that the users logged in as the root user, which is not bound by SCPs.

The company wants to allow only specific on-premises IP ranges into the production VPC. Transit Gateway handles routing between attachments, but it does not filter traffic based on IP addresses. AWS Network Firewall is a managed firewall service that can be deployed in a VPC to inspect and filter traffic.

By deploying Network Firewall in the production VPC and configuring stateful rule groups, the company can allow only traffic from the specified on-premises IP ranges and deny all other traffic. This approach provides granular control and is a recommended practice. Option A is incorrect because a Direct Connect gateway only advertises routes; it does not filter traffic.

Option C is incorrect because Transit Gateway route tables control routing, not filtering; they cannot blackhole traffic based on source IP. Option D is incorrect because VPC peering is used for connecting VPCs, not for connecting on-premises networks via Direct Connect.

This option comprehensively addresses the security issues: restrict SSH access to the web tier from a trusted management CIDR, limit application tier access (port 8080) to only the web tier security group, and restrict database access (port 3306) to only the application tier security group. Additionally, it removes the overly permissive SSH rule on the application tier or restricts it to a management CIDR. Option A is insufficient because it leaves App-SG and DB-SG open to the internet on their respective ports.

Option B removes SSH entirely, which may be needed for management, and does not address application traffic restrictions between tiers. Option D suggests using network ACLs, which are stateless and more complex; security groups are stateful and more appropriate for this use case.