AWS Certified Advanced Networking — Specialty (ANS-C01) practice questions and exam guide

A design requires exporting VPC Flow Logs directly into a SIEM tool hosted outside AWS in near-real-time, rather than batched S3 delivery.

1. CloudTrail Lake export to the SIEM
2. AWS Config snapshots exported nightly
3. VPC Flow Logs delivered to Kinesis Data Firehose, streaming to the external SIEM
4. VPC Flow Logs delivered to S3 only, polled hourly by the SIEM

Answer: C — VPC Flow Logs delivered to Kinesis Data Firehose, streaming to the external SIEM

Flow Logs support Kinesis Data Firehose as a destination, enabling near-real-time streaming delivery to external tools; S3 delivery with hourly polling introduces batching delay, the opposite of near-real-time; CloudTrail Lake stores API activity, not network flow data; Config snapshots capture resource state periodically, not network traffic in near-real-time.

A design calls for serving different backend origins based on URL path (e.g., /images/* vs /api/*) at the edge, with TLS termination and WAF integration.

1. An NLB with path-based target groups
2. Route 53 routing policies by URL path
3. CloudFront with cache behaviors routing by path pattern
4. Global Accelerator listener rules by path

Answer: C — CloudFront with cache behaviors routing by path pattern

CloudFront cache behaviors match path patterns to distinct origins and integrate natively with WAF/ACM for TLS; Global Accelerator operates at the network layer without path-based HTTP routing; NLB (Layer 4) can't inspect URL paths; Route 53 resolves DNS names, not URL paths within a single hostname.

A multi-account VPC sharing design should let a central network team own subnets while application teams deploy resources into those subnets from their own accounts.

1. VPC sharing via AWS RAM, sharing subnets from the owning account to participant accounts
2. Giving application team accounts full IAM access to the network account
3. Creating a duplicate VPC per application team with peering to the central VPC
4. Cross-account S3 bucket policies for subnet configuration

Answer: A — VPC sharing via AWS RAM, sharing subnets from the owning account to participant accounts

VPC sharing (via RAM) lets a central account own and manage the VPC/subnets while other accounts deploy resources (EC2, RDS, etc.) directly into those shared subnets, reducing per-account VPC sprawl; giving full IAM access to the network account is an over-broad security risk unrelated to the actual subnet-sharing need; duplicating VPCs per team plus peering reintroduces the exact sprawl/complexity VPC sharing avoids; S3 bucket policies are unrelated to VPC/subnet resource sharing.

A team implementing multi-Region connectivity needs the SAME Transit Gateway route table logic replicated in a second Region for disaster recovery, since TGW route tables aren't automatically synced across Regions.

1. A single TGW resource can span both Regions with shared route tables
2. Only static routes work across peered TGWs; dynamic propagation doesn't work inter-Region
3. Manually (or via IaC) create and maintain equivalent route tables/associations in the second Region's separate Transit Gateway, since each Region's TGW is an independent resource
4. TGW route tables replicate automatically across peered Regions by default

Answer: C — Manually (or via IaC) create and maintain equivalent route tables/associations in the second Region's separate Transit Gateway, since each Region's TGW is an independent resource

Because each Region has its own independent TGW resource, route table configuration must be explicitly replicated (ideally via IaC for consistency) in the DR Region -- there's no automatic cross-Region sync; TGW peering enables reachability between the two TGWs but does NOT auto-replicate each TGW's internal route table configuration; there is no single TGW spanning Regions; dynamic route propagation does work across TGW peering attachments, it isn't limited to static routes only.

Automation must ensure that a Transit Gateway route table's routes stay in sync with an authoritative external source of truth (e.g., a CMDB), automatically correcting drift.

1. Route tables self-heal automatically with no automation required
2. Manual quarterly audits comparing route tables to the CMDB
3. AWS Config alone can modify route tables to fix drift
4. A scheduled Lambda (or Step Functions) function that reconciles TGW route tables against the CMDB and applies corrections via the API, combined with Config for drift detection/alerting

Answer: D — A scheduled Lambda (or Step Functions) function that reconciles TGW route tables against the CMDB and applies corrections via the API, combined with Config for drift detection/alerting

Achieving automatic reconciliation requires custom automation (Lambda/Step Functions) that reads the source of truth and calls the TGW API to correct drift, often paired with Config for detection/alerting; route tables do not self-heal on their own; manual quarterly audits are infrequent and not automated at all; AWS Config detects and reports configuration drift but does not itself remediate/modify resources -- remediation requires a paired automation action.

A multi-account implementation requires accepting a cross-account Transit Gateway attachment request from a spoke account into the hub account's Transit Gateway.

1. The spoke account approves its own attachment unilaterally
2. RAM sharing alone completes the attachment with no separate acceptance step
3. The TGW owner account explicitly accepts the pending cross-account attachment request in the TGW console/API
4. Cross-account attachments are automatically accepted with no approval step

Answer: C — The TGW owner account explicitly accepts the pending cross-account attachment request in the TGW console/API

After RAM-sharing the Transit Gateway to the spoke account, the spoke creates an attachment request that the TGW OWNER account must explicitly accept before traffic flows -- a deliberate two-step trust model; attachments are not silently auto-accepted; the spoke account cannot unilaterally approve into someone else's TGW; RAM sharing only grants permission to create the attachment request, it doesn't itself complete the acceptance.

Operations notices a VPC route table has an unused route left over from a decommissioned VPN connection, with no remaining traffic depending on it.

1. Remove the stale route from the route table as part of routine route table hygiene
2. Leave stale routes indefinitely since they cause no harm
3. Delete the entire route table including active routes
4. Disable the VPC's DNS resolution to clear the stale route

Answer: A — Remove the stale route from the route table as part of routine route table hygiene

Routine operational hygiene removes routes pointing to resources that no longer exist, reducing confusion and potential misrouting risk; leaving stale routes indefinitely is poor practice and can cause confusion or, in edge cases, unexpected behavior if the target ID is ever reused; deleting the entire route table would also remove legitimate active routes, an overcorrection; DNS resolution settings are unrelated to route table entries.

During routine operations, a VPC's private subnet route table is found routing 0.0.0.0/0 directly to an Internet Gateway instead of a NAT Gateway.

1. Remove the 0.0.0.0/0 route entirely so the subnet has no internet access at all
2. Add a second 0.0.0.0/0 route to the NAT Gateway alongside the existing IGW route
3. Correct the route to point 0.0.0.0/0 at the NAT Gateway, keeping the subnet's resources without direct public IPs from being directly internet-routable
4. This is correct behavior for private subnets by design

Answer: C — Correct the route to point 0.0.0.0/0 at the NAT Gateway, keeping the subnet's resources without direct public IPs from being directly internet-routable

A private subnet should route outbound internet traffic via a NAT Gateway (in a public subnet) so its resources aren't directly internet-routable, so the fix is correcting the route target to the NAT Gateway; routing a 'private' subnet's default route directly to an IGW effectively makes any resource with a public IP directly internet-facing, which is NOT correct private-subnet design; removing the route entirely eliminates needed outbound internet access; a route table cannot have two entries for the identical 0.0.0.0/0 destination -- only one is valid.

Two VPCs in the same Region need private connectivity for a simple, low-complexity, cost-sensitive use case with only these two VPCs ever needing to talk to each other.

1. VPC peering -- simpler and typically more cost-effective than Transit Gateway for a small, static, point-to-point relationship
2. Transit Gateway is always the more cost-effective choice regardless of scale
3. PrivateLink is required for any VPC-to-VPC connectivity
4. Direct Connect between the two VPCs

Answer: A — VPC peering -- simpler and typically more cost-effective than Transit Gateway for a small, static, point-to-point relationship

For a small number of static VPC-to-VPC relationships, VPC peering avoids Transit Gateway's per-attachment and per-GB processing charges, making it typically more cost-effective at small scale; TGW becomes more cost-effective and operationally simpler at LARGER scale, not universally cheaper regardless of scale; PrivateLink is for exposing individual services, not a requirement for general VPC-to-VPC connectivity; Direct Connect connects on-premises networks to AWS, it's not used for VPC-to-VPC connectivity within AWS.

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.

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 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.

CloudTrail vs VPC Flow Logs -- audit use case?

CloudTrail: WHO called WHAT API WHEN (management/data events) -- the audit trail for configuration changes. Flow Logs: WHAT traffic was allowed/rejected at the IP layer -- the audit trail for actual network traffic.

DNSSEC on Route 53?

Cryptographically signs DNS responses for authenticity/integrity (not encryption). Supported on PUBLIC hosted zones only, using a KMS customer managed key for the key-signing key.

Cluster vs spread vs partition placement groups?

Cluster: packs instances close together (same rack) for lowest network latency. Spread: strictly separates instances across distinct hardware for max fault isolation. Partition: groups of instances isolated from other partitions' hardware, for large distributed systems.

Route 53 Resolver query logging?

Captures DNS query records (source, query name, response) -- distinct from Flow Logs (IP traffic metadata) and CloudTrail (API calls). Exportable to CloudWatch Logs, S3, or Kinesis Firehose.

CloudFront Origin Access Control (OAC)?

Lets CloudFront serve a private S3 bucket's content without making the bucket public, restricting direct access to only the CDN.

MTU and Path MTU Discovery (PMTUD) over VPN/DX?

Mismatched MTU (e.g., jumbo frame support not consistent end-to-end) causes silent packet black-holing that manifests as TCP retransmissions or large-transfer failures, especially if ICMP fragmentation-needed messages are blocked.