Network Security, Compliance, and Governance — AWS Certified Advanced Networking ANS-C01 practice questions

A financial services workload requires that inbound traffic from a specific list of partner IP ranges bypass Network Firewall's stateful inspection for latency reasons, while ALL OTHER traffic is fully inspected.

1. Remove Network Firewall entirely for the whole VPC to allow the partner traffic through faster
2. Use security groups only, removing Network Firewall's stateful capability across the board
3. Configure a Network Firewall stateless rule group with a pass action specifically for the trusted partner CIDR ranges, before the stateful engine, while leaving the default stateful inspection for everything else
4. Network Firewall doesn't support any traffic bypass; all traffic is always fully inspected with no exceptions possible

Answer: C — Configure a Network Firewall stateless rule group with a pass action specifically for the trusted partner CIDR ranges, before the stateful engine, while leaving the default stateful inspection for everything else

Network Firewall's stateless rule groups (evaluated before the stateful engine) support explicit pass actions for specific traffic, letting trusted sources bypass deeper stateful inspection while everything else still goes through it; Network Firewall DOES support such exceptions, so claiming zero flexibility is incorrect; removing Network Firewall for the entire VPC eliminates inspection for ALL traffic, not just the intended narrow exception; replacing with security-groups-only removes stateful deep inspection entirely for everyone.

A compliance requirement mandates that all traffic leaving a VPC to the internet pass through a centralized inspection point across the entire organization, with no VPC allowed its own direct Internet Gateway route to the internet.

1. Rely on documentation alone instructing teams not to attach IGWs
2. This requirement can't be enforced technically, only through policy reminders
3. A centralized egress VPC design: spoke VPCs route 0.0.0.0/0 via Transit Gateway to a shared inspection VPC with the only IGW/NAT path, enforced via governance (e.g., SCPs restricting IGW attachment in spoke accounts)
4. Each VPC keeps its own Internet Gateway but adds a Network Firewall locally

Answer: C — A centralized egress VPC design: spoke VPCs route 0.0.0.0/0 via Transit Gateway to a shared inspection VPC with the only IGW/NAT path, enforced via governance (e.g., SCPs restricting IGW attachment in spoke accounts)

A centralized egress architecture combined with a preventive control (SCPs blocking IGW creation/attachment in spoke accounts) both routes traffic through the mandated inspection point AND technically enforces the requirement; keeping per-VPC IGWs (even with local Network Firewall) directly violates 'no VPC allowed its own direct IGW route'; relying on documentation alone is a detective control, not technical enforcement; SCPs are exactly the technical enforcement mechanism AWS provides for this.

A design must ensure Resolver query logs (which may contain sensitive internal hostnames) are encrypted at rest and access-restricted when delivered to an S3 bucket.

1. Encryption doesn't matter for DNS query logs since hostnames aren't considered sensitive data
2. Only IAM permissions matter; S3 bucket encryption configuration is irrelevant
3. Configure the destination S3 bucket with default encryption (SSE-KMS with a customer managed key for tighter access control) and a bucket policy restricting access to authorized principals only
4. Resolver query logs are automatically both encrypted and access-restricted with no bucket-level configuration needed

Answer: C — Configure the destination S3 bucket with default encryption (SSE-KMS with a customer managed key for tighter access control) and a bucket policy restricting access to authorized principals only

Achieving both encryption at rest AND access restriction requires explicitly configuring the destination S3 bucket -- these are standard, necessary S3-level configurations, not automatic; internal hostnames CAN reveal sensitive information about internal architecture and are reasonably treated as sensitive; IAM permissions control WHO can call the API, but bucket-level encryption configuration is a separate, also-necessary control for at-rest protection -- both matter together, not one exclusively.

An audit needs to validate that Direct Connect connections at a specific colocation facility meet a physical security compliance requirement (e.g., badge access controls, camera coverage).

1. Physical security isn't a relevant audit concern for Direct Connect
2. VPC Flow Logs demonstrate physical facility security compliance
3. Request the relevant AWS Direct Connect location's compliance documentation/attestations (e.g., SOC reports) from AWS, since physical security of DX facilities is an AWS-managed responsibility under the shared responsibility model
4. The customer must personally inspect the physical facility, since AWS provides no compliance documentation for DX locations

Answer: C — Request the relevant AWS Direct Connect location's compliance documentation/attestations (e.g., SOC reports) from AWS, since physical security of DX facilities is an AWS-managed responsibility under the shared responsibility model

Physical security of AWS/partner Direct Connect facilities falls under AWS's side of the shared responsibility model, and AWS provides compliance attestations that auditors can request/reference rather than requiring a customer's own physical facility inspection; AWS DOES provide this documentation through its compliance programs; physical security absolutely is a relevant audit concern for any compliance framework involving physical infrastructure; Flow Logs are a network-traffic logging feature entirely unrelated to physical facility security attestation.

A design requires encrypting data in transit between an on-premises data center and AWS over an existing Direct Connect private VIF, since DX itself doesn't encrypt data by default.

1. Encryption in transit isn't achievable over Direct Connect at all
2. Use S3 server-side encryption to encrypt the DX link's traffic
3. Layer a Site-to-Site VPN (IPsec) or MACsec (on supported DX connection types) on top of the Direct Connect connection for encryption
4. Direct Connect private VIFs encrypt all traffic by default with no additional configuration

Answer: C — Layer a Site-to-Site VPN (IPsec) or MACsec (on supported DX connection types) on top of the Direct Connect connection for encryption

DX private VIFs do NOT encrypt traffic by default, so achieving encryption requires layering IPsec VPN over DX, or using MACsec (supported on certain dedicated connection speeds) for line-rate encryption; the fix is one of these two layered options, not assuming default encryption exists; encryption over DX IS achievable via these documented methods; S3 server-side encryption protects data AT REST in S3, entirely unrelated to encrypting a DX network link's in-transit traffic.

A multi-account audit strategy needs to verify Flow Logs are enabled and correctly configured across all 300 VPCs in an Organization, flagging any that are missing or misconfigured.

1. This requires logging into each of the 300 accounts individually with no centralized tooling
2. CloudTrail alone verifies Flow Log configuration status
3. An AWS Config aggregator with a managed/custom rule checking Flow Log presence and configuration, evaluated across all member accounts
4. A quarterly manual spreadsheet cross-check per account

Answer: C — An AWS Config aggregator with a managed/custom rule checking Flow Log presence and configuration, evaluated across all member accounts

A Config aggregator combined with a Flow-Log-presence rule provides centralized, automated, continuous verification across all member accounts at once; a quarterly manual spreadsheet is infrequent, labor-intensive, and error-prone at 300-account scale; AWS DOES provide centralized multi-account tooling for exactly this kind of check; CloudTrail records API calls, it doesn't itself evaluate/report Flow Log configuration compliance status the way a Config rule does.

A design must issue and manage TLS certificates for INTERNAL services communicating over a private VPC network, where public Certificate Transparency logging of internal hostnames is undesirable.

1. Let's Encrypt public certificates for all internal services
2. Skip TLS entirely for internal services since they're already in a private VPC
3. AWS Certificate Manager Private Certificate Authority (ACM PCA), issuing private certificates not subject to public CT log requirements
4. A standard public ACM certificate for the internal hostname

Answer: C — AWS Certificate Manager Private Certificate Authority (ACM PCA), issuing private certificates not subject to public CT log requirements

ACM PCA issues private certificates from a private CA hierarchy specifically for internal use, avoiding the public Certificate Transparency logging that public CAs are required to perform; standard public ACM certificates ARE subject to CT logging, which the requirement wants to avoid; Let's Encrypt issues public certificates with the same CT logging requirement; being on a private VPC network doesn't eliminate the value of encryption in transit, so skipping TLS entirely isn't the correct security posture.

A security team needs to validate, on a recurring automated basis, that no security group in any of 300 VPCs allows unrestricted inbound access (0.0.0.0/0) to a database port like 3306 or 5432.

1. This can only be checked by AWS Support upon request
2. Security groups can't be evaluated for compliance; only NACLs support automated compliance checks
3. An AWS Config managed rule (or custom rule) checking security group ingress rules against a restricted-port list, evaluated continuously/periodically across the Organization via a Config aggregator
4. Manually export every security group's rules to a spreadsheet monthly for a human to review

Answer: C — An AWS Config managed rule (or custom rule) checking security group ingress rules against a restricted-port list, evaluated continuously/periodically across the Organization via a Config aggregator

Config rules evaluated across an aggregated multi-account view provide the recurring, automated compliance check requested; manual spreadsheet review monthly is labor-intensive and error-prone at 300-VPC scale; this is a standard native AWS governance capability, not something requiring an AWS Support request; security groups are absolutely evaluable via Config, so claiming only NACLs can be checked is incorrect.

A public-facing web application needs protection against common web exploits (SQLi, XSS) at the edge, with managed rule sets requiring minimal custom maintenance.

1. AWS Shield Standard alone with no WAF
2. Network ACLs with custom regex-based rules
3. AWS WAF with AWS Managed Rules attached to the CloudFront distribution or ALB
4. Security groups alone with port 443 restrictions

Answer: C — AWS WAF with AWS Managed Rules attached to the CloudFront distribution or ALB

WAF with AWS Managed Rules specifically targets Layer 7 web exploits with AWS-maintained rule sets requiring minimal custom upkeep; security groups filter by port/protocol/IP, not HTTP payload content; Shield Standard protects against network/transport-layer DDoS, not application-layer exploit patterns; NACLs are stateless IP/port filters with no HTTP-aware rule engine and no regex-based content inspection.

S3 Object Lock (compliance mode)?

Prevents deletion/modification of objects (e.g., centralized Flow Logs) for a set retention period, even by the root user -- satisfies immutable-logging compliance requirements like PCI-DSS.

DNS-over-HTTPS (DoH) / DNS-over-TLS (DoT) vs DNSSEC?

DoH/DoT encrypt the DNS query/response transport (confidentiality). DNSSEC authenticates/signs responses (integrity), but does NOT encrypt them. Two different protections, often confused.

AWS WAF vs Shield vs Shield Advanced vs Network Firewall?

WAF: Layer 7 HTTP rule-based filtering (SQLi/XSS). Shield Standard: automatic, free, network/transport-layer DDoS protection. Shield Advanced: paid, enhanced DDoS protection + SRT + cost protection. Network Firewall: stateful, domain-aware VPC-level traffic inspection.

Security groups vs NACLs?

Security groups: STATEFUL, instance/ENI-level, allow rules only. NACLs: STATELESS, subnet-level, support allow AND deny rules, evaluated in rule-number order.