Network Implementation — AWS Certified Advanced Networking ANS-C01 practice questions

During DX implementation, connectivity validation shows the BGP session is up but no routes are being received from the on-premises router.

1. This always means the VIF's VLAN ID is misconfigured
2. Route tables in the VPC need to be deleted and recreated
3. Check that the on-premises router is actually advertising routes over the BGP session (prefix advertisement/redistribution configuration)
4. The DX connection's physical layer must be down

Answer: C — Check that the on-premises router is actually advertising routes over the BGP session (prefix advertisement/redistribution configuration)

A BGP session being 'up' only confirms the TCP/BGP peering itself; missing routes almost always point to the peer not actually advertising/redistributing prefixes into BGP, which is the first thing to check; if the physical layer were down, the BGP session itself wouldn't establish, contradicting 'session is up'; a VLAN misconfiguration would typically prevent the BGP session from coming up at all, not just prevent route receipt; deleting/recreating VPC route tables doesn't address a BGP advertisement problem upstream.

A design requires implementing Route 53 Application Recovery Controller-based DNS failover with sub-minute detection and control over multiple independent health-check data sources for a mission-critical application.

1. Manual DNS record updates during an incident
2. Route 53 simple routing with no health checks at all
3. Configure Route 53 ARC readiness checks and routing controls with multiple independent health check inputs feeding the failover decision
4. A single basic Route 53 health check with default settings

Answer: C — Configure Route 53 ARC readiness checks and routing controls with multiple independent health check inputs feeding the failover decision

Route 53 Application Recovery Controller is specifically designed for mission-critical, highly available failover with independent redundant health/readiness signals and fast routing control changes; a single basic health check is a much simpler mechanism without ARC's redundancy and control-plane independence; manual updates during an incident are slow and error-prone, the opposite of what's needed; simple routing with no health checks provides no failover capability whatsoever.

A DNS implementation for a hybrid environment must ensure that Resolver query logs from all VPCs are captured centrally for security review.

1. VPC Flow Logs alone capture DNS query content
2. Resolver query logs can only be viewed live in the console with no export option
3. CloudTrail management events capture individual DNS query content
4. Enable Route 53 Resolver query logging configuration, associated with the relevant VPCs, delivering logs to a centralized CloudWatch Logs group or S3 bucket

Answer: D — Enable Route 53 Resolver query logging configuration, associated with the relevant VPCs, delivering logs to a centralized CloudWatch Logs group or S3 bucket

Resolver query logging is a distinct, purpose-built feature for capturing DNS query records (query name, response, source) and can be centralized to CloudWatch Logs, S3, or Kinesis Firehose; VPC Flow Logs capture IP-layer traffic metadata, not DNS query content; Resolver query logs DO support export/centralization, they aren't console-only; CloudTrail records AWS API management events, not the content of individual DNS queries made by resources.

A network automation platform needs to programmatically create, tag, and attach dozens of Transit Gateway VPC attachments as part of a nightly batch job, with idempotent behavior if run twice.

1. Manually verifying no duplicates exist in the console after each nightly run
2. A script/Step Functions workflow using the TGW API with existence checks (e.g., describe-then-create logic) before creating each attachment, ensuring re-runs don't create duplicates
3. Running the same creation script twice always safely creates a second, harmless duplicate attachment
4. Idempotency isn't achievable with AWS APIs for networking resources

Answer: B — A script/Step Functions workflow using the TGW API with existence checks (e.g., describe-then-create logic) before creating each attachment, ensuring re-runs don't create duplicates

Idempotent automation checks for existing resources (e.g., describe/list calls) before attempting creation, so re-runs skip already-created attachments -- a standard IaC/automation design pattern; running creation calls blindly twice would attempt duplicate attachments, not 'harmlessly'; idempotency is absolutely achievable for AWS networking APIs with proper existence-check logic; manual post-run verification isn't automation and doesn't prevent the duplicate attempt from happening in the first place.

A team wants every new VPC's route tables, NACLs, and security groups created consistently via version-controlled templates rather than manual console clicks.

1. Creating resources once, then using 'Save as template' from the console with no ongoing pipeline
2. AWS CloudFormation (or AWS CDK) templates defining the networking resources, deployed via a CI/CD pipeline
3. Manually documenting the steps in a wiki page for engineers to follow
4. AWS Config rules enforcing the desired state after manual creation

Answer: B — AWS CloudFormation (or AWS CDK) templates defining the networking resources, deployed via a CI/CD pipeline

CloudFormation/CDK provide version-controlled, repeatable infrastructure-as-code that a CI/CD pipeline can deploy consistently; a wiki page relies on humans following steps manually and doesn't guarantee consistency; Config rules can detect drift AFTER manual creation, but don't create the resources consistently in the first place; a one-time 'save as template' export doesn't establish an ongoing repeatable deployment process.

Implementing PrivateLink for a service provider requires creating which resource so consumer accounts can connect via an interface endpoint?

1. An S3 bucket policy granting cross-account access
2. A VPC endpoint service, fronted by an NLB or GWLB in the provider's VPC
3. A VPC peering connection to every consumer account
4. A public Route 53 record pointing at the service

Answer: B — A VPC endpoint service, fronted by an NLB or GWLB in the provider's VPC

The endpoint service construct (backed by an NLB/GWLB) is exactly what consumers connect to via interface VPC endpoints; VPC peering is a different (broader, non-scalable-to-many-consumers) connectivity model; a public Route 53 record exposes the service over the internet, the opposite of PrivateLink's private model; S3 bucket policies are unrelated to exposing a network service via PrivateLink.

A private hosted zone implementation must be associated with a VPC in a DIFFERENT AWS account than the zone owner.

1. Copy the hosted zone's records into a new zone created in the target account
2. The zone-owning account creates a VPC association authorization for the target VPC/account; the target account then performs the association
3. Private hosted zones can only ever be used within their owning account
4. The target account associates the zone with no authorization step required

Answer: B — The zone-owning account creates a VPC association authorization for the target VPC/account; the target account then performs the association

Cross-account private hosted zone association is a supported, two-step process: an authorization from the owner, followed by the association action performed in the consuming account; private hosted zones DO support cross-account association via this mechanism, so restricting them to single-account use is inaccurate; the target account cannot associate without the owner's authorization first; duplicating the zone's records into a separate zone creates drift and management overhead instead of using the supported sharing mechanism.

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.

Implementing DNSSEC on a Route 53 public hosted zone requires which additional AWS resource to manage the cryptographic signing key?

1. A KMS customer managed key (CMK) referenced by the DNSSEC key-signing key (KSK) configuration
2. An ACM certificate for the domain
3. A Secrets Manager secret storing the private key
4. No additional resource; Route 53 generates and stores keys internally with no KMS involvement

Answer: A — A KMS customer managed key (CMK) referenced by the DNSSEC key-signing key (KSK) configuration

Route 53 DNSSEC uses a KMS customer managed key for the key-signing key material, giving the customer visibility/control over key policy and rotation; ACM issues TLS certificates for HTTPS, unrelated to DNSSEC's DNS-response-signing keys; Secrets Manager stores generic secrets, not the specific KMS-backed DNSSEC signing key construct Route 53 requires; DNSSEC explicitly requires this KMS integration, it isn't handled with zero customer-visible key material.

Implementing a public hosted zone for a new domain requires which step to make the zone authoritative on the internet?

1. Enable DNSSEC signing (this alone makes the zone authoritative)
2. Create an A record in the hosted zone
3. Nothing further; creating the hosted zone alone makes it authoritative
4. Update the domain's NS records at the domain registrar to point to the hosted zone's four assigned name servers

Answer: D — Update the domain's NS records at the domain registrar to point to the hosted zone's four assigned name servers

A hosted zone only becomes authoritative on the public internet once the registrar's NS records are updated to delegate to Route 53's assigned name servers; DNSSEC adds response authentication but doesn't establish delegation; creating an A record adds a resource record but doesn't establish the zone as the answer source for the domain; simply creating the zone in Route 53, without registrar delegation, leaves the domain's actual authoritative servers unchanged.

TGW route table association vs propagation?

Association: which route table an attachment's traffic is evaluated against. Propagation: whether an attachment's routes are automatically added to a given route table. Both are configured per attachment/route-table pair.