AWS Advanced Networking – Specialty (ANS-C01) — Free Sample Questions
Test your networking expertise with 30 free sample questions for the most network-intensive AWS certification. ANS-C01 demands deep knowledge of VPC internals, hybrid connectivity, DNS, and network security.
Exam Domains
- Network Design (30%) — multi-VPC architectures, Transit Gateway topologies, IP address planning, IPv6 migration
- Network Implementation (26%) — Direct Connect (dedicated and hosted), Site-to-Site VPN, peering, PrivateLink endpoints
- Network Management and Operations (20%) — Route 53 resolver rules, Flow Logs analysis, Network Manager, CloudWatch network metrics
- Network Security, Compliance, and Governance (24%) — Network Firewall, WAF, Shield Advanced, DNS firewall, TLS termination
What Makes ANS-C01 Unique
This is the only AWS certification that tests networking at the packet level. Scenarios involve:
- Calculating CIDR blocks that avoid overlap across merged corporate networks
- Choosing between Direct Connect LAG, multiple connections, and VPN as backup
- Designing Transit Gateway route tables for complex hub-and-spoke and shared-services models
- Troubleshooting asymmetric routing, MTU issues, and BGP route propagation
- Implementing DNS resolution across hybrid environments with Route 53 Resolver endpoints
Critical Study Topics
- Transit Gateway: route tables, attachments, peering, multicast, Connect (SD-WAN)
- Direct Connect: LAGs, VIFs (public, private, transit), MACsec encryption, resiliency models
- VPC: secondary CIDRs, subnet delegation, prefix lists, Managed Prefix Lists for firewalls
- Route 53: resolver rules, DNS Firewall, health checks with failover, geolocation routing
Full Practice Exams
Continue with 600 ANS-C01 questions — 30 quizzes and 2 full-length exams — each covering specific networking scenarios with detailed explanations.
All 30 Free Sample Questions
Question 1 — Network Design (30%)
An e-commerce company uses CloudFront to distribute static assets and API Gateway for its REST API. During flash sales, the API experiences high latency from international users. The API is regional and deployed in us-west-2. Which design change would BEST reduce API latency for global users?
- Deploy API Gateway in multiple regions and use Route 53 geoproximity routing
- Place CloudFront in front of the regional API Gateway endpoint
- Use AWS Global Accelerator with the API Gateway as the endpoint
- Convert the API Gateway to edge-optimized endpoint type — Correct answer
Explanation:
- Why correct: Edge-optimized API Gateway automatically uses CloudFront edge locations to route API requests through the AWS network to the regional API in us-west-2. This is the native, purpose-built solution for reducing API latency globally with minimal configuration changes.
- Why A is wrong: Deploying API Gateway in multiple regions requires significant re-architecture, increases operational complexity, and introduces data consistency challenges across regions. It is over-engineered when edge-optimized API Gateway solves the latency problem natively with a single configuration change.
- Why B is wrong: Placing a self-managed CloudFront distribution in front of a regional API Gateway can reduce latency, but it duplicates what edge-optimized mode already provides automatically. For simply reducing global latency with minimal effort, converting to edge-optimized is simpler and avoids managing a separate CloudFront distribution. A self-managed distribution is justified only when you need custom caching policies, WAF, or other controls beyond what edge-optimized mode exposes.
- Why C is wrong: Global Accelerator does not support API Gateway as a direct endpoint. It works with ALB, NLB, EC2, and Elastic IP addresses, but not with API Gateway.
Question 2 — Network Design (30%)
A company has a private hosted zone for db.internal associated with VPC-A. The company creates a VPC endpoint for RDS in VPC-A. The endpoint has a private DNS name rds.us-east-1.amazonaws.com. Resources in VPC-A need to resolve both db.internal names and the VPC endpoint DNS name. What configuration is required?
- Create a CNAME record in the private hosted zone pointing db.internal to the VPC endpoint DNS name
- No additional configuration is required; both resolutions work automatically — Correct answer
- Create an alias record in the private hosted zone pointing to the VPC endpoint
- Associate the VPC endpoint's private hosted zone with VPC-A
Explanation:
- Why correct: VPC endpoints with private DNS enabled automatically create private hosted zones that are associated with the VPC. The existing private hosted zone for db.internal works independently. Route 53 Resolver handles queries for both zones automatically.
- Why A is wrong: While you could create a CNAME for convenience, it's not required for resolution to work. The VPC endpoint's DNS name resolves automatically when private DNS is enabled.
- Why C is wrong: Alias records point to AWS resources but are not required for VPC endpoint DNS resolution. The endpoint's private DNS works automatically.
- Why D is wrong: VPC endpoints automatically manage their private hosted zone associations when private DNS is enabled. Manual association is not required or possible.
Question 3 — Network Design (30%)
A company uses an ALB to serve a web application. The application requires that user sessions persist to the same backend instance. The application uses a custom session cookie named APP_SESSION. How should sticky sessions be configured?
- Enable application-based cookie stickiness and specify APP_SESSION as the cookie name — Correct answer
- Enable duration-based cookie stickiness and set the duration to match session timeout
- Configure the ALB to generate a new cookie named AWSALB for stickiness
- Use NLB instead of ALB for better session persistence
Explanation:
- Why correct: Application-based cookie stickiness allows the ALB to use an existing application cookie (APP_SESSION) to maintain session persistence. The ALB reads the cookie and routes requests to the same target.
- Why B is wrong: Duration-based stickiness uses an ALB-generated cookie (AWSALB) with a specified duration, not the application's existing session cookie. This doesn't leverage the existing APP_SESSION cookie.
- Why C is wrong: AWSALB is the cookie name for duration-based stickiness, not application-based stickiness. The requirement is to use the existing APP_SESSION cookie.
- Why D is wrong: NLB provides flow-based stickiness but doesn't understand HTTP cookies. ALB with application-based cookie stickiness is the correct solution for HTTP cookie-based session persistence.
Question 4 — Network Design (30%)
A company wants to monitor the performance of an Application Load Balancer including request count, target response time, and HTTP error rates. The company needs to create a dashboard showing these metrics. Where are these metrics available?
- CloudWatch metrics for the ALB — Correct answer
- CloudTrail logs
- VPC Flow Logs
- ALB access logs in S3
Explanation:
- Why correct: ALB automatically publishes metrics to CloudWatch including RequestCount, TargetResponseTime, HTTPCode_Target_4XX_Count, HTTPCode_Target_5XX_Count, and many others. These can be visualized in CloudWatch dashboards without additional configuration.
- Why B is wrong: CloudTrail logs API calls to manage the ALB (e.g., CreateTargetGroup, RegisterTargets) but does not publish operational metrics like request counts or response times.
- Why C is wrong: VPC Flow Logs capture network traffic metadata (IPs, ports, bytes) but do not include ALB-specific metrics like TargetResponseTime or HTTP error code counts.
- Why D is wrong: ALB access logs in S3 provide detailed per-request data but require processing (e.g., via Athena) to generate aggregate metrics. CloudWatch metrics provide ready-to-use aggregate statistics natively.
Question 5 — Network Design (30%)
A company uses Transit Gateway with multiple VPN connections from different on-premises sites. The company wants to prevent VPN sites from communicating with each other through Transit Gateway while allowing all sites to access VPC resources. How should Transit Gateway be configured?
- Use security groups to block traffic between VPN sites
- Create separate Transit Gateways for each VPN connection
- Configure BGP route filters on VPN connections
- Create separate Transit Gateway route tables for each VPN attachment with routes only to VPC attachments — Correct answer
Explanation:
- Why correct: Transit Gateway route tables control routing between attachments. Creating separate route tables for VPN attachments with routes only to VPC attachments (not to other VPN attachments) prevents inter-VPN communication while allowing VPC access.
- Why A is wrong: Security groups apply to ENIs in VPCs, not to Transit Gateway attachments or VPN connections. They can't control Transit Gateway routing.
- Why B is wrong: Separate Transit Gateways would prevent VPN sites from accessing the same VPCs efficiently. Route table segmentation on a single Transit Gateway is more appropriate.
- Why C is wrong: BGP route filters control which routes are advertised/accepted but don't prevent Transit Gateway from routing between attachments if routes exist in the route table.
Question 6 — Network Design (30%)
A company has 10 VPCs in the same region that need full mesh connectivity. The company wants to minimize management overhead and support transitive routing. Which solution is MOST appropriate?
- Deploy a Transit Gateway and attach all VPCs — Correct answer
- Create VPC peering connections between all VPCs (45 peering connections)
- Deploy VPN connections between all VPCs
- Use a hub-and-spoke architecture with one central VPC and VPC peering
Explanation:
- Why correct: Transit Gateway provides a centralized connectivity hub with transitive routing. All 10 VPCs attach to Transit Gateway, which handles routing between them, eliminating the need for mesh peering and reducing management overhead to just 10 attachments.
- Why B is wrong: Full-mesh VPC peering requires n(n-1)/2 connections — 45 for 10 VPCs — each requiring route table entries in both VPCs. This creates significant management overhead and doesn't support transitive routing.
- Why C is wrong: VPN connections between VPCs add encryption overhead, are limited to ~1.25 Gbps per tunnel, and are complex to manage. Transit Gateway provides native VPC-to-VPC connectivity without these limitations.
- Why D is wrong: Hub-and-spoke with VPC peering doesn't support transitive routing. Spoke VPCs can only communicate with the hub, not with each other through it, unless the hub VPC runs routing software — adding operational complexity and a single point of failure.
Question 7 — Network Design (30%)
A company has two Direct Connect connections for redundancy. The company wants to use both connections simultaneously for increased bandwidth while ensuring automatic failover if one connection fails. The company also needs to monitor connection health and receive alerts. Which combination provides this solution? (Select TWO)
- Use MED to prefer one connection over the other
- Use AS-PATH prepending on one connection for active/passive failover
- Configure CloudWatch alarms on Direct Connect connection state metrics — Correct answer
- Advertise routes with equal AS-PATH length from both connections for ECMP — Correct answer
- Enable cross-zone load balancing on Direct Connect
Explanation:
- Why correct: Equal AS-PATH length enables ECMP for active/active load balancing across both connections. CloudWatch alarms on connection state metrics provide health monitoring and alerting.
- Why C is correct: Advertising routes with equal AS-PATH length from both connections causes AWS to use ECMP, load-balancing traffic across both connections for increased bandwidth.
- Why A is wrong: AS-PATH prepending creates active/passive failover, not active/active load balancing. This doesn't meet the requirement to use both connections simultaneously.
- Why D is correct: CloudWatch metrics for Direct Connect include connection state. Alarms on these metrics provide automated monitoring and alerting for connection health.
- Why B is wrong: Cross-zone load balancing is an ELB feature, not a Direct Connect feature. It doesn't apply to Direct Connect connections.
- Why E is wrong: MED (Multi-Exit Discriminator) is used to suggest a preferred path to an external AS, creating active/passive preference rather than active/active load balancing. It does not enable ECMP or simultaneous use of both connections for increased bandwidth.
Question 8 — Network Implementation (26%)
A company has multiple AWS accounts and wants to centralize hybrid connectivity. The company wants one account to own the Direct Connect connection and Transit Gateway, with other accounts attaching their VPCs. How should this be implemented? (Select TWO)
- Use VPC peering from application VPCs to the owner VPC
- Share the Transit Gateway using AWS RAM — Correct answer
- Create a Direct Connect Gateway in the owner account
- Application accounts create transit VIFs to the shared Transit Gateway
- Application accounts accept the RAM share and create Transit Gateway attachments — Correct answer
Explanation:
- Why B and E are correct: Transit Gateway can be shared via RAM. Application accounts accept the share and create VPC attachments to the shared Transit Gateway, enabling centralized hybrid connectivity.
- Why A is wrong: VPC peering does not enable centralized hybrid connectivity through Transit Gateway. Each VPC must be directly attached to the Transit Gateway, not peered to the owner VPC.
- Why B is correct: AWS RAM enables sharing of Transit Gateway across accounts, allowing centralized management in the networking account while enabling distributed VPC attachments from application accounts.
- Why C is wrong: Direct Connect Gateway connects Direct Connect to VPCs or Transit Gateway but does not provide multi-account Transit Gateway sharing. RAM is the mechanism for sharing Transit Gateway.
- Why D is wrong: Transit VIFs are created by the Direct Connect connection owner to connect Direct Connect to Transit Gateway. Application accounts do not create transit VIFs — they create VPC attachments to the shared Transit Gateway.
- Why E is correct: Application accounts must accept the RAM share, then create Transit Gateway VPC attachments from their VPCs to the shared Transit Gateway.
Question 9 — Network Implementation (26%)
A company deploys stateful firewall appliances across two Availability Zones in an inspection VPC attached to a Transit Gateway. Some TCP connections through the firewalls fail intermittently. Investigation reveals that for affected flows, the outbound packet traverses AZ-A but the return packet is routed through AZ-B, where the firewall has no existing session state. The network engineer enables appliance mode on the inspection VPC's Transit Gateway attachment. What behavior does appliance mode provide to resolve this issue?
- Traffic is encrypted between VPCs
- Bidirectional traffic flows traverse the same Availability Zone — Correct answer
- Traffic is load-balanced across multiple appliances
- Traffic is logged to CloudWatch
Explanation:
- Why correct (B): Appliance mode ensures that both directions of a traffic flow (request and response) traverse the same Availability Zone through the Transit Gateway. Without appliance mode, Transit Gateway may route the return path through a different AZ, causing stateful firewalls to drop packets because they have no session state for that flow. Enabling appliance mode on the VPC attachment forces flow symmetry, which is essential for stateful inspection appliances.
- Why A is wrong: Appliance mode does not provide encryption between VPCs. Encryption would require a VPN overlay or services like AWS CloudWAN with IPsec. Appliance mode solely addresses AZ-level flow symmetry.
- Why C is wrong: Appliance mode does not load-balance traffic across appliances. Load balancing to multiple appliance instances is handled separately, typically using a Gateway Load Balancer or route table entries. Appliance mode only guarantees that both directions of a given flow stay in the same AZ.
- Why D is wrong: Appliance mode has no effect on logging. CloudWatch logging is configured independently through VPC Flow Logs or firewall-specific logging. Appliance mode is strictly about routing symmetry for stateful traffic inspection.
Question 10 — Network Implementation (26%)
A company uses AWS Direct Connect to connect its on-premises data center to AWS. The on-premises applications need to resolve names in an AWS private hosted zone (aws.corp.internal), and AWS workloads need to resolve names hosted by the on-premises Microsoft DNS servers (ad.corp.internal). The company creates Route 53 Resolver inbound and outbound endpoints in the VPC. What additional configuration is required on the ON-PREMISES side to complete the hybrid DNS setup?
- Create a secondary DNS zone for aws.corp.internal on the on-premises DNS servers
- Add the inbound endpoint IP addresses to the on-premises DHCP scope options as additional DNS servers
- Configure conditional forwarders on the on-premises DNS servers to forward aws.corp.internal queries to the inbound endpoint IP addresses — Correct answer
- Configure the on-premises DNS servers to forward all queries to the inbound endpoint IP addresses
Explanation:
- Why correct: Conditional forwarding on the on-premises DNS servers ensures that only queries for the specific AWS domain (aws.corp.internal) are sent to the Route 53 Resolver inbound endpoint IP addresses. This is the standard pattern for hybrid DNS — on-premises DNS servers retain authority for on-premises domains and selectively forward AWS-specific queries to Route 53 via the inbound endpoints.
- Why A is wrong: Creating a secondary zone would attempt to replicate zone data from AWS, but Route 53 private hosted zones do not support zone transfers (AXFR/IXFR). Conditional forwarding is the correct mechanism.
- Why B is wrong: Adding inbound endpoint IPs to DHCP scope would cause ALL DNS queries from on-premises clients to be sent to Route 53, not just AWS-specific queries. This breaks resolution for on-premises domains and creates unnecessary load on the inbound endpoints. Conditional forwarding targets only the relevant domains.
- Why D is wrong: Forwarding ALL queries to the inbound endpoints would route on-premises domain queries (ad.corp.internal) to Route 53, which cannot resolve them. Only AWS-specific domain queries should be forwarded using conditional forwarders.
Question 11 — Network Implementation (26%)
A company wants to automatically update Transit Gateway route tables when new VPCs are attached. Which approach provides this automation?
- Enable automatic route propagation on Transit Gateway
- Create an EventBridge rule that triggers on CreateTransitGatewayVpcAttachment and invokes Lambda to update route tables — Correct answer
- Use CloudFormation to create attachments and route table entries together
- Manually update route tables after each attachment
Explanation:
- Why correct (B): EventBridge detects CreateTransitGatewayVpcAttachment API calls (via CloudTrail) and triggers a Lambda function to automatically update route tables. This works regardless of how the attachment was created (console, CLI, SDK, or CloudFormation), providing universal event-driven automation.
- Why A is wrong: Transit Gateway route propagation can propagate VPC CIDRs to TGW route tables, but propagation must be explicitly enabled for each new attachment. It does not auto-enable when a new VPC is attached — someone or something must still configure it per attachment. EventBridge + Lambda can both enable propagation and add any required custom static routes automatically for every new attachment without manual steps.
- Why C is wrong: CloudFormation can create attachments and route table entries together within a stack, but it does not handle attachments created outside CloudFormation (e.g., via console or CLI). EventBridge provides automation for any creation method.
- Why D is wrong: Manual updates do not provide automation. The requirement is for automatic route table updates whenever a new VPC is attached, without human intervention.
Question 12 — Network Implementation (26%)
A company wants to implement GitOps for network infrastructure where all changes are made through Git commits and automatically deployed. Which combination enables this? (Select TWO)
- Store CloudFormation templates in Git repository — Correct answer
- Store templates in S3
- Manually deploy from Git
- Use CodePipeline to detect commits and deploy CloudFormation stacks — Correct answer
- Use Lambda to deploy infrastructure
Explanation:
- Why correct: GitOps requires two pillars — a version-controlled source of truth and an automated delivery pipeline. Storing CloudFormation templates in a Git repository (A) provides version control, peer review via pull requests, and an audit trail. AWS CodePipeline (D) watches the repository for commits and automatically deploys or updates CloudFormation stacks, completing the automated feedback loop.
- Why A (Store templates in Git) is correct: Git serves as the single source of truth for all network infrastructure definitions, enabling code reviews and rollback through commit history.
- Why D (CodePipeline) is correct: CodePipeline natively integrates with Git-based sources (CodeCommit, GitHub, Bitbucket) and can trigger CloudFormation stack create/update actions on each commit, fulfilling the GitOps requirement of automatic deployment from Git.
- Why B (Store templates in S3) is wrong: S3 is an object store without built-in branching, pull requests, or merge workflows. It can host templates for CloudFormation to reference, but it does not provide the version control and collaboration features central to GitOps.
- Why C (Manually deploy from Git) is wrong: Manual deployment breaks the core GitOps principle that deployments are triggered automatically by commits, not by human intervention.
- Why E (Lambda to deploy) is wrong: While a Lambda function could invoke CloudFormation APIs, CodePipeline is the purpose-built AWS service for CI/CD pipelines with built-in stage management, approvals, and rollback capabilities.
Question 13 — Network Management and Operation (20%)
A company uses BGP over Direct Connect. The company wants to influence inbound traffic from AWS to prefer one Direct Connect connection over another. Which BGP attribute should be modified on the on-premises router?
- AS-PATH (prepend on the less-preferred connection) — Correct answer
- MED (set higher on the less-preferred connection)
- Local Preference
- Weight
Explanation:
- Why correct: AS-PATH prepending adds extra AS hops to routes advertised on the less-preferred connection. AWS evaluates AS-PATH length when selecting the outbound path, so it prefers the connection with the shorter AS-PATH. This is the recommended method for influencing inbound traffic over Direct Connect.
- Why B is wrong: MED (Multi-Exit Discriminator) does influence AWS outbound path selection, but it is evaluated at the lowest priority in the BGP decision process for private and transit VIFs. AS-PATH prepending is more reliable and is the AWS-recommended approach.
- Why C is wrong: Local Preference on Direct Connect is controlled via BGP community tags (7224:7100, 7224:7200, 7224:7300) set when advertising routes to AWS. However, the question asks which attribute to modify on the on-premises router to influence preference between two connections, and AS-PATH prepending is the standard method.
- Why D is wrong: Weight is Cisco-proprietary and local to a single router. It is not advertised to BGP peers and cannot influence AWS routing decisions.
Question 14 — Network Management and Operation (20%)
A security audit requires a network team to identify and remove unused security group rules across 50 VPCs. The team needs to determine which rules are actively matched by real traffic before deleting any rules. Which approach provides this analysis?
- Review CloudTrail for security group changes
- Use AWS Config to list security group rules
- Use Trusted Advisor
- Analyze VPC Flow Logs to correlate traffic with security group rules — Correct answer
Explanation:
- Why correct: VPC Flow Logs record actual traffic flows (source/destination IPs, ports, protocol, accept/reject action) at the ENI level. By aggregating Flow Log data and comparing the observed traffic patterns against the existing security group rules, the team can determine which rules are actively matched by real traffic and which rules have never been triggered, enabling safe cleanup of unused rules.
- Why A is wrong: CloudTrail records API calls such as AuthorizeSecurityGroupIngress or RevokeSecurityGroupEgress, showing when rules were created or modified, but it does not reveal whether those rules are actually matched by live traffic.
- Why B is wrong: AWS Config can enumerate the current security group rule configurations and detect configuration drift, but it does not track whether any traffic is actually hitting those rules.
- Why C is wrong: Trusted Advisor checks for overly permissive rules (e.g., 0.0.0.0/0 on sensitive ports) but does not correlate rules against actual traffic to determine usage.
Question 15 — Network Management and Operation (20%)
A company has a 1 Gbps Direct Connect connection with a private VIF to its VPC. On-premises applications frequently access large datasets in Amazon S3. Currently, traffic flows from on-premises through the private VIF into the VPC, then through a NAT Gateway to reach S3 over the internet. The network team wants to reduce data transfer costs. What is the MOST cost-effective approach?
- Create S3 Gateway Endpoints in the VPC and route on-premises traffic through the VPC to S3
- Route S3 traffic from the VPC through an internet gateway instead of the NAT Gateway
- Create S3 interface endpoints (AWS PrivateLink) in the VPC and advertise endpoint IPs to on-premises via BGP
- Create a public VIF on the Direct Connect connection to access S3 public endpoints directly, bypassing the VPC and NAT Gateway — Correct answer
Explanation:
- Why correct: A public VIF allows on-premises hosts to access S3 public endpoints directly over the Direct Connect connection, bypassing the VPC entirely. This eliminates NAT Gateway hourly charges (~$0.045/hr per AZ) and NAT Gateway data processing charges (~$0.045/GB). Data transfer over Direct Connect is charged at lower DX rates compared to internet rates, making this the most cost-effective option.
- Why A is wrong: S3 Gateway Endpoints are route-table entries that only apply to traffic originating from within the VPC. On-premises traffic entering the VPC via a private VIF cannot use Gateway Endpoints because the traffic source is outside the VPC. Gateway Endpoints do not have IP addresses that can be routed to from on-premises.
- Why B is wrong: Routing through an internet gateway removes the NAT Gateway processing charges, but the EC2/VPC resources would need public IPs, and S3 data transfer would be charged at standard internet rates, which are higher than Direct Connect rates. This also doesn't address the root problem of on-premises-originated traffic.
- Why C is wrong: S3 interface endpoints (PrivateLink) do have IP addresses and can technically be reached from on-premises via the private VIF. However, interface endpoints incur hourly charges (~$0.01/hr per AZ) plus data processing charges (~$0.01/GB). A public VIF has no per-hour or per-GB processing charge, making it more cost-effective for large data volumes.
Question 16 — Network Management and Operation (20%)
A company publishes VPC Flow Logs to Amazon S3 and wants to identify security threats and optimize network performance. Which combination of actions meets these requirements? (Select TWO)
- Use Amazon CloudWatch Contributor Insights to rank top talkers and set alarms on anomalous traffic spikes
- Use Amazon Athena to run SQL queries on Flow Logs for traffic pattern analysis and bandwidth optimization — Correct answer
- Use AWS CloudTrail to analyze data-plane packet payloads for performance bottlenecks
- Use Amazon GuardDuty for automated threat detection that analyzes VPC Flow Logs with machine learning — Correct answer
- Use VPC Traffic Mirroring to capture full packet headers and replay them in Amazon Redshift for cost analysis
Explanation:
- Why B (Athena) is correct: Athena can query Flow Logs stored in S3 using SQL, enabling ad-hoc analysis of traffic patterns such as top talkers, rejected connections, and cross-AZ transfer volumes. This directly supports network performance optimization.
- Why D (GuardDuty) is correct: GuardDuty automatically ingests VPC Flow Logs and uses machine-learning models plus threat intelligence feeds to detect anomalies like cryptocurrency mining, port scanning, and data exfiltration.
- Why A is wrong: CloudWatch Contributor Insights can analyze CloudWatch Logs groups but does not natively integrate with Flow Logs stored in S3. It also provides traffic ranking, not security threat detection.
- Why C is wrong: CloudTrail records API management-plane events (e.g., CreateVpc, AuthorizeSecurityGroupIngress), not data-plane packet flows. It cannot analyze network traffic patterns or performance.
- Why E is wrong: VPC Traffic Mirroring captures actual packet content and sends it to appliances or tools like Zeek or Suricata for deep packet inspection. It is not designed for cost analysis, and Redshift is not a standard target for mirrored traffic.
Question 17 — Network Security, Compliance, and Governance (24%)
An e-commerce company runs its storefront on Amazon CloudFront backed by an Application Load Balancer. During a recent promotional event, the site experienced a multi-vector DDoS attack combining a volumetric SYN flood with an HTTP POST flood targeting the checkout API. The company wants proactive engagement from AWS during future attacks, cost protection for scaling charges caused by DDoS, and the ability to block malicious HTTP patterns. Which TWO services should the company deploy together? (Select TWO)
- AWS Shield Advanced on the CloudFront distribution and ALB — Correct answer
- Security groups configured to allow only port 443 inbound
- Amazon GuardDuty with threat intelligence feeds
- AWS WAF with rate-based rules and custom request-pattern rules on the ALB — Correct answer
- VPC Flow Logs published to Amazon S3 for post-incident analysis
Explanation:
- Why A is correct: Shield Advanced provides enhanced network/transport-layer DDoS protection, access to the AWS Shield Response Team (SRT) for proactive engagement during attacks, and DDoS cost protection that credits scaling charges caused by DDoS events. This directly addresses the volumetric SYN flood and the company's requirement for proactive AWS support.
- Why D is correct: AWS WAF operates at Layer 7 and can create rate-based rules to throttle excessive POST requests to the checkout API, plus custom rules matching malicious HTTP patterns. This directly addresses the HTTP POST flood component of the attack.
- Why B is wrong: Security groups filter at Layer 3/4 (IP/port) and can restrict to port 443, but they cannot detect or mitigate volumetric DDoS floods, do not offer DDoS cost protection, and cannot inspect HTTP request patterns.
- Why C is wrong: GuardDuty is a threat detection service that analyzes VPC Flow Logs, DNS logs, and CloudTrail for suspicious activity. It generates findings but does not actively block DDoS traffic or provide DDoS cost protection.
- Why E is wrong: VPC Flow Logs capture network metadata for forensic analysis after an incident, but they do not actively mitigate DDoS attacks in progress and provide no cost protection.
Question 18 — Network Security, Compliance, and Governance (24%)
A company's compliance policy requires that no EC2 instance security group allows unrestricted SSH access (0.0.0.0/0 on port 22). The security team needs automated detection and remediation of violations across all VPCs. Which combination provides this automated validation? (Select TWO)
- AWS Config managed rule for restricted-ssh — Correct answer
- VPC Flow Logs analysis
- Lambda function for automated remediation when violations detected — Correct answer
- GuardDuty finding analysis
- CloudWatch custom metrics on SSH connections
Explanation:
- Why correct: AWS Config's restricted-ssh managed rule continuously evaluates all security groups and flags any that allow inbound SSH (port 22) from 0.0.0.0/0 or ::/0. When Config detects a non-compliant resource, a Lambda remediation function can automatically remove the offending inbound rule, closing the compliance gap without manual intervention.
- Why A is correct (AWS Config managed rule for restricted-ssh): This managed rule specifically checks whether security groups allow unrestricted inbound SSH access. It provides continuous evaluation — every time a security group is created or modified, Config re-evaluates compliance status and marks the resource as compliant or non-compliant.
- Why C is correct (Lambda function for automated remediation when violations detected): Config can trigger a Lambda function via automatic remediation actions when a rule violation is detected. The Lambda function calls the EC2 RevokeSecurityGroupIngress API to remove the non-compliant inbound rule, providing closed-loop automated validation and remediation.
- Why B is wrong (VPC Flow Logs analysis): Flow Logs capture traffic metadata (accepted/rejected packets), but they do not evaluate security group configurations. You could see SSH traffic in Flow Logs, but you cannot determine from Flow Logs alone whether a security group rule allows 0.0.0.0/0 on port 22 — only that traffic was or was not permitted.
- Why D is wrong (GuardDuty finding analysis): GuardDuty detects threats like brute-force SSH attempts (UnauthorizedAccess:EC2/SSHBruteForce), but it does not validate security group configurations against compliance policies. It is reactive to threats, not proactive about configuration compliance.
- Why E is wrong (CloudWatch custom metrics on SSH connections): CloudWatch metrics could track SSH connection counts, but this monitors traffic volume, not whether the security group configuration itself violates policy. A security group could allow 0.0.0.0/0 on port 22 with zero current connections and still be non-compliant.
Question 19 — Network Security, Compliance, and Governance (24%)
A healthcare company uses a 1 Gbps AWS Direct Connect dedicated connection to access resources in a VPC. A new compliance requirement mandates that all traffic between the on-premises data center and the VPC must be encrypted in transit using IPsec. The company wants to maintain the low-latency benefits of Direct Connect. What should a network engineer do?
- Create a Site-to-Site VPN over a Direct Connect public virtual interface to encrypt traffic with IPsec while benefiting from Direct Connect's consistent latency — Correct answer
- Enable MACsec on the Direct Connect connection, which also encrypts traffic across the AWS backbone to the destination VPC
- Create a private virtual interface and rely on Direct Connect's built-in encryption for data in transit
- Create a Site-to-Site VPN over the internet and use the Direct Connect connection only for non-sensitive traffic
Explanation:
- Why correct: A Site-to-Site VPN can be established over a Direct Connect public virtual interface. This creates an IPsec-encrypted tunnel that traverses the Direct Connect link rather than the public internet. The traffic benefits from Direct Connect's consistent latency and bandwidth while meeting the IPsec encryption requirement. The public VIF is needed because the VPN endpoint uses AWS public IP addresses.
- Why B is wrong: MACsec provides Layer 2 encryption only on the Direct Connect link between the customer router and the AWS Direct Connect device. It does NOT encrypt traffic across the AWS backbone network to the VPC. Additionally, MACsec is only available on 10 Gbps and 100 Gbps connections, not 1 Gbps.
- Why C is wrong: Direct Connect does NOT provide built-in encryption for data in transit. Traffic over a private virtual interface travels unencrypted by default. Encryption must be implemented separately using IPsec VPN, MACsec, or application-layer TLS.
- Why D is wrong: Routing VPN traffic over the internet sacrifices the low-latency and consistent-bandwidth benefits of Direct Connect. The requirement is to encrypt traffic while maintaining Direct Connect's performance advantages, which is achieved by running the VPN over the Direct Connect link itself.
Question 20 — Network Security, Compliance, and Governance (24%)
A company must enforce that all Direct Connect connections use encryption with governance policies. Which combination provides this?
- Site-to-Site VPN over Direct Connect for encryption and Service Control Policy to enforce VPN usage — Correct answer
- Direct Connect without encryption
- Manual encryption verification
- No encryption policies
Explanation:
- Why correct: VPN over Direct Connect provides IPsec encryption. SCP enforces VPN usage for Direct Connect traffic, providing both technical control and governance.
- Why B is wrong: Direct Connect without encryption violates encryption requirements.
- Why C is wrong: Manual verification doesn't provide continuous enforcement or governance.
- Why D is wrong: No encryption policies violate compliance requirements for data protection.
Question 21 — Cross-Domain Integration
A SaaS provider runs a customer-facing portal backed by Amazon Aurora Global Database with a primary cluster in us-east-1 and a secondary cluster in eu-west-1. The RPO requirement is under 1 second and the RTO must be under 2 minutes. DNS TTL must be as low as possible. Which TWO components must be configured in Route 53 to provide automated cross-region failover that meets these requirements? (Select TWO)
- Route 53 health checks monitoring the primary Aurora cluster endpoint — Correct answer
- Route 53 failover routing policy with primary and secondary records — Correct answer
- Route 53 latency-based routing pointing to both Aurora cluster endpoints
- Amazon CloudWatch alarm on Aurora replication lag triggering DNS update
- Route 53 weighted routing with equal weights across both regions
Explanation:
- Why A is correct: Route 53 health checks continuously monitor the primary database endpoint (e.g., via TCP or HTTP health check against the application layer). When the health check detects the primary is unhealthy, it triggers the failover routing policy to redirect DNS queries to the secondary endpoint. Health checks evaluate every 10 or 30 seconds, enabling detection well within the 2-minute RTO.
- Why B is correct: Route 53 failover routing policy designates a primary and secondary record. When the primary record's associated health check fails, Route 53 automatically returns the secondary record's IP. Combined with Aurora Global Database's sub-second replication, this meets both the RPO (<1s) and RTO (<2 min) requirements.
- Why C is wrong: Route 53 latency-based routing directs users to the lowest-latency endpoint, but it does not enforce a primary/secondary relationship. If both endpoints are healthy, traffic splits unpredictably. Failover routing is the correct policy for active-passive failover with a designated primary.
- Why D is wrong: An Amazon CloudWatch alarm can detect database issues, but CloudWatch alarms alone cannot update DNS records. Route 53 health checks integrate natively with Route 53 routing policies to trigger failover—CloudWatch alarms would require additional automation (e.g., Lambda) to achieve the same result, adding complexity and latency to the failover process.
- Why E is wrong: Weighted routing distributes traffic across endpoints based on assigned weights. It is designed for load distribution (active-active), not for automated failover with a strict primary/secondary designation. It does not automatically shift 100% of traffic when the primary fails unless combined with health checks and zero-weight configuration, which is more complex than failover routing.
Question 22 — Cross-Domain Integration
A company operates a hub-and-spoke architecture with 25 spoke accounts and a shared services account. The shared services account hosts a Route 53 private hosted zone (services.internal) for centralized microservices. Spoke VPCs in different accounts need to resolve names in this private hosted zone. The network team wants to minimize the number of hosted zone copies and administrative effort.
What is the MOST operationally efficient way to enable DNS resolution of services.internal from all spoke VPCs?
- Recreate the services.internal private hosted zone in each of the 25 spoke accounts and manually synchronize DNS records
- In the shared services account, use CreateVPCAssociationAuthorization to authorize each spoke VPC, then in each spoke account call AssociateVPCWithHostedZone to associate the spoke VPC with the centralized private hosted zone — Correct answer
- Create VPC peering connections between each spoke VPC and the shared services VPC to enable DNS resolution
- Convert services.internal to a public hosted zone so all VPCs can resolve it without cross-account configuration
Explanation:
- Why correct: Route 53 private hosted zones support cross-account VPC association through a two-step authorization process. The owner account (shared services) calls CreateVPCAssociationAuthorization to grant permission for a specific spoke VPC to associate with the hosted zone. Then the spoke account calls AssociateVPCWithHostedZone to complete the association. Once associated, the spoke VPC's DNS resolver can resolve records in services.internal. This keeps a single authoritative zone in the shared services account — record updates are made once and are immediately available to all associated VPCs. Note: AWS RAM is used to share Route 53 Resolver rules, not private hosted zones; hosted zone sharing uses this dedicated authorization API.
- Why A is wrong: Recreating the hosted zone in each of the 25 accounts creates 25 independent copies that must be kept in sync. Any record change must be replicated to all accounts, creating significant operational overhead and risk of drift. There is no built-in mechanism to synchronize records across independent hosted zones.
- Why C is wrong: VPC peering provides network-layer connectivity between VPCs but does not enable DNS resolution of private hosted zones across accounts. A VPC can only resolve records in a private hosted zone if that VPC is explicitly associated with the zone. Peering does not create this association.
- Why D is wrong: Converting to a public hosted zone would expose internal service names to the internet, violating the principle of keeping internal DNS private. Public hosted zones are queryable by anyone on the internet, making internal architecture discoverable and creating a security risk.
Question 23 — Cross-Domain Integration
A company has a primary 10 Gbps Direct Connect connection and a backup Site-to-Site VPN through a Transit Gateway. Before a planned maintenance event, the network team must validate that traffic fails over correctly to the VPN path. The validation must minimize impact on production traffic. Which approach should the team use?
- Use Transit Gateway Route Analyzer to verify that the VPN route exists in the Transit Gateway route table, and confirm failover readiness based on the route analysis
- Disable the BGP session on the Direct Connect virtual interface during a scheduled maintenance window, verify traffic shifts to the VPN path, and monitor latency and packet loss before re-enabling — Correct answer
- Update the Transit Gateway route table to add a static route pointing to the VPN attachment with a higher priority than the Direct Connect route
- Configure a Route 53 health check against an on-premises endpoint and use failover routing to redirect traffic through the VPN path
Explanation:
- Why B is correct: Disabling the BGP session on the Direct Connect virtual interface during a scheduled maintenance window simulates a real Direct Connect failure. This causes the Transit Gateway to withdraw the DX-learned routes and converge on the VPN-learned routes via BGP. Monitoring latency and packet loss during the test validates that the backup path handles production traffic acceptably. This is the AWS-recommended approach for failover testing.
- Why A is wrong: Transit Gateway Route Analyzer performs static analysis of routes and can confirm a VPN route exists, but it does not validate actual traffic failover behavior, BGP convergence time, or whether the VPN path can handle production throughput. It is a useful supplementary tool but not sufficient as the sole validation method.
- Why C is wrong: Transit Gateway route tables do not support priority values for routes. When routes to the same CIDR exist from multiple attachments, the Transit Gateway uses BGP attributes (AS-PATH length, MED) to select the preferred path. Adding a static route would override dynamic routing rather than testing the BGP failover mechanism.
- Why D is wrong: Route 53 health checks with failover routing operate at the DNS layer for application endpoint resolution. They do not control or test the underlying network path failover between Direct Connect and VPN at the Transit Gateway level.
Question 24 — Cross-Domain Integration
A company is building a microservices platform on Amazon ECS across multiple VPCs. The architecture must keep all traffic private — microservices must discover each other dynamically, consumer VPCs in other accounts must access specific services without broad network connectivity, and workloads must reach AWS services like S3 and KMS without internet access. Which THREE components should the network architect include? (Select THREE)
- Create gateway endpoints for S3 and DynamoDB, and interface endpoints for other AWS services such as STS and KMS — Correct answer
- Remove all service discovery mechanisms and rely on static IP addressing
- Place a public Application Load Balancer in front of each microservice for cross-VPC access
- Use AWS Cloud Map with a private DNS namespace for service discovery across microservices — Correct answer
- Create VPC endpoint services backed by NLBs to expose internal microservices to consumer VPCs via PrivateLink — Correct answer
- Attach an internet gateway and route all AWS service traffic through the public internet
Explanation:
- Why A is correct: Gateway endpoints provide free, private access to S3 and DynamoDB via route table entries. Interface endpoints provide private access to other AWS services (STS, KMS, CloudWatch, etc.) through ENIs with private IPs, eliminating the need for NAT gateways or internet access.
- Why D is correct: AWS Cloud Map with a private DNS namespace creates Route 53 private hosted zones that allow microservices to discover each other by DNS name. Combined with ECS or EKS integration, services register and deregister automatically with health checking.
- Why E is correct: VPC endpoint services (PrivateLink) backed by NLBs allow internal microservices to be exposed privately to consumer VPCs without granting broad network access. This is the standard pattern for cross-account or cross-VPC service exposure.
- Why B is wrong: Removing service discovery forces static IP addressing, which does not scale in dynamic microservices environments where tasks start and stop frequently.
- Why C is wrong: Public ALBs expose services to the internet. The requirement is private connectivity, which PrivateLink provides without public exposure.
- Why F is wrong: Routing AWS service traffic through the internet introduces latency, data transfer costs, and security risk. VPC endpoints keep this traffic private within the AWS network.
Question 25 — Cross-Domain Integration
A financial services company runs microservices on Amazon EKS and must encrypt all pod-to-pod traffic to satisfy PCI-DSS requirements. The solution must provide automatic certificate rotation and work transparently without application code changes. Which approach meets these requirements?
- Deploy AWS App Mesh with mutual TLS (mTLS) enabled between Envoy sidecar proxies — Correct answer
- Enable VPC flow log encryption and attach security groups for pods to enforce TLS
- Configure Kubernetes NetworkPolicy resources to encrypt traffic between selected pods
- Enable node-to-node encryption on the EKS cluster ENIs using VPC encryption in transit
Explanation:
- Why correct (A): AWS App Mesh uses Envoy sidecar proxies injected alongside each pod. When mTLS is enabled, Envoy automatically handles certificate provisioning, rotation, and encryption of all service-to-service traffic. This is transparent to the application code — the app communicates over plain HTTP/gRPC to localhost, and the sidecar encrypts it before sending. This satisfies PCI-DSS encryption-in-transit requirements with automatic certificate lifecycle management.
- Why B is wrong: VPC flow logs are an observability feature that records metadata about network flows — they do not encrypt traffic. Security groups for pods control which traffic is allowed or denied at Layer 4 but do not provide encryption.
- Why C is wrong: Kubernetes NetworkPolicy resources control which pods can communicate with each other (allow/deny rules). They are a firewall mechanism, not an encryption mechanism. NetworkPolicy does not encrypt any traffic.
- Why D is wrong: There is no native 'VPC encryption in transit' toggle for ENI-to-ENI traffic within a VPC. Some instance types support encryption between instances in the same AZ automatically at the Nitro card level, but this is not configurable per-cluster, does not handle certificate rotation, and does not provide mTLS authentication between services.
Question 26 — Cross-Domain Integration
A network operations team notices periodic bandwidth saturation on a NAT Gateway. They need to continuously identify which source IP addresses and destination ports are generating the most traffic through the NAT Gateway. VPC Flow Logs are already published to CloudWatch Logs. Which approach provides the MOST operationally efficient continuous analysis?
- Create a CloudWatch Logs Insights query that aggregates bytes transferred per source IP address and schedule it to run every 5 minutes using EventBridge
- Enable VPC Flow Logs with Traffic Mirroring to capture full packet payloads and analyze source IP frequency in Wireshark
- Create CloudWatch Contributor Insights rules on the VPC Flow Logs log group to automatically identify and rank top contributing source IP addresses and ports — Correct answer
- Export VPC Flow Logs to S3, create an Athena table, and run a scheduled query to identify the highest-volume source IPs
Explanation:
- Why correct: CloudWatch Contributor Insights is purpose-built for this use case. It continuously analyzes log data in near real time and automatically identifies the top-N contributors by any field (source IP, destination port, action, etc.) from VPC Flow Logs. It requires minimal setup — just a rule definition pointing to the log group — and produces a continuously updated ranked view without managing any query infrastructure.
- Why A is wrong: CloudWatch Logs Insights is a query tool, not a continuous analysis engine. Running scheduled queries via EventBridge can approximate this, but it requires building and maintaining the scheduling logic, handling query results, and lacks the built-in top-N ranking dashboard that Contributor Insights provides natively.
- Why B is wrong: Traffic Mirroring captures full packet payloads for deep packet inspection and is unrelated to identifying top traffic contributors. It also adds cost and complexity by requiring a mirror target (NLB or ENI) and analysis tools. VPC Flow Logs metadata is sufficient for identifying top talkers.
- Why D is wrong: Exporting to S3 and querying with Athena is a valid analytical approach, but it introduces latency (Flow Logs export to S3 can take minutes to hours), requires managing S3 bucket organization, Athena table schemas, and scheduled queries. For continuous, near-real-time identification of top contributors, Contributor Insights is more operationally efficient.
Question 27 — Cross-Domain Integration
A company transfers 20 TB of data per month from its on-premises data center to AWS. The current Site-to-Site VPN connection over a 1 Gbps internet link provides adequate bandwidth but costs are high due to data transfer charges. The company needs consistent low-latency connectivity for a real-time analytics workload and wants to reduce monthly networking costs. The workload will remain stable for at least 3 years. Which solution meets these requirements?
- Add a second Site-to-Site VPN connection for redundancy and use ECMP to distribute traffic across both tunnels
- Migrate to AWS VPN with an accelerated Site-to-Site VPN connection using AWS Global Accelerator
- Provision a 1 Gbps AWS Direct Connect dedicated connection with a 1-year or 3-year reserved port pricing commitment — Correct answer
- Use AWS DataSync over the existing VPN to schedule transfers during off-peak hours
Explanation:
- Why correct (C): For 20 TB/month of consistent, long-term data transfer requiring low latency, Direct Connect is the most cost-effective option. Direct Connect data transfer out rates are significantly lower than internet-based transfer (approximately $0.02/GB vs $0.09/GB for internet). A reserved port pricing commitment (1-year or 3-year) further reduces the port hour charges, and the dedicated connection provides consistent low-latency performance for real-time analytics.
- Why A is wrong: Adding a second VPN does not reduce data transfer costs — VPN data transfer pricing is tied to internet data transfer rates. ECMP across VPN tunnels improves throughput but not cost. The real-time analytics latency requirement also isn't addressed since VPN traverses the public internet.
- Why B is wrong: Accelerated Site-to-Site VPN uses Global Accelerator to improve VPN performance by routing traffic through the AWS global network, but it adds Global Accelerator charges on top of existing VPN costs and does not reduce data transfer pricing.
- Why D is wrong: DataSync is a data transfer service, not a networking optimization. Scheduling transfers off-peak does not reduce per-GB charges, and it doesn't address the low-latency requirement for real-time analytics.
Question 28 — Domain 4 - Network Security, Compliance, and Governance
An enterprise operates 50 AWS accounts in AWS Organizations. A compliance regulation requires that workload accounts in a specific organizational unit (OU) must never have direct internet connectivity. A network engineer must implement a preventive control that blocks any attempt to create or attach an internet gateway in those accounts, regardless of the IAM permissions granted to individual users. Which solution meets this requirement?
- Use AWS Config rules to detect and automatically remediate any VPC with an internet gateway, removing the gateway via an AWS Systems Manager Automation runbook
- Apply a Service Control Policy (SCP) to the OU that denies the ec2:CreateInternetGateway and ec2:AttachInternetGateway actions, preventing internet gateways from being created in those accounts — Correct answer
- Configure AWS Firewall Manager to deploy a Network Firewall policy that blocks all outbound internet traffic in the restricted accounts
- Create IAM policies in each member account that deny internet gateway creation and attach the policies to all IAM roles and users
Explanation:
- Why correct (B): Service Control Policies (SCPs) act as preventive guardrails at the AWS Organizations level. An SCP denying ec2:CreateInternetGateway and ec2:AttachInternetGateway on the target OU blocks these API calls before they execute, regardless of what IAM permissions any principal in those accounts has. SCPs define the maximum available permissions — they cannot be overridden by account-level IAM policies.
- Why A is wrong: AWS Config with auto-remediation is a detective-then-corrective approach, not preventive. There is a window between when the internet gateway is created and when remediation fires, during which the non-compliant resource exists. For strict compliance requirements, preventive controls that block the action entirely are preferred over detect-and-fix.
- Why C is wrong: AWS Firewall Manager with Network Firewall can block outbound traffic at the network layer, but it does not prevent the creation of internet gateways. An internet gateway could still be created and attached to a VPC — even if Network Firewall blocks its traffic, the non-compliant resource exists, which may violate the compliance requirement.
- Why D is wrong: IAM policies in each account can deny these actions, but they must be attached to every IAM principal (users, roles, groups) in every account. This approach does not scale, is error-prone (a new role could miss the policy), and can be overridden by account administrators who have permission to modify IAM policies. SCPs cannot be overridden from within the member account.
Question 29 — Cross-Domain Integration
A networking team manages VPCs, transit gateways, and Network Firewall resources using CloudFormation stacks across 15 AWS accounts. Operations engineers occasionally make manual changes to security groups and route tables through the console during incidents, but these changes are not reflected back into the templates. The team needs an automated mechanism to detect when stack resources have drifted from their template definitions. Which solution meets this requirement?
- Schedule a weekly Lambda function that calls the DescribeStacks API and compares stack outputs to expected values stored in DynamoDB
- Enable AWS Config rule cloudformation-stack-notification-check to detect when stack resources are modified outside CloudFormation
- Run CloudFormation drift detection on network stacks on a schedule using EventBridge and Lambda, then publish drift results to an SNS topic for the networking team — Correct answer
- Use VPC Flow Logs to identify unauthorized changes to network resources and correlate them with CloudTrail events
Explanation:
- Why correct: CloudFormation drift detection compares actual resource configurations against the template definition and reports resources as MODIFIED, DELETED, or NOT_CHECKED. By using EventBridge scheduled rules to trigger a Lambda function that calls DetectStackDrift and then GetStackDriftDetectionStatus, the team can automate periodic drift checks. Publishing results to SNS ensures the networking team is notified promptly when drift is detected on network resources like security groups or route tables.
- Why A is wrong: Comparing stack outputs to expected values in DynamoDB only checks output values, not the actual configuration of individual resources within the stack.
- Why B is wrong: The cloudformation-stack-notification-check Config rule only verifies that a stack has an SNS notification configured — it does not detect whether resources have drifted from their CloudFormation template definitions. Drift detection examines each resource's properties against the template, which is far more comprehensive.
- Why D is wrong: VPC Flow Logs capture network traffic metadata (source, destination, ports, action), not resource configuration changes. While CloudTrail can log API calls that modify resources, this approach requires building custom correlation logic and does not directly compare resources against CloudFormation template definitions like native drift detection does.
Question 30 — Domain 1: Network Design
A company operates 15 VPCs across three AWS accounts connected via AWS Transit Gateway. An on-premises data center connects to AWS over AWS Direct Connect. The company needs all VPCs and the on-premises data center to resolve internal hostnames under corp.example.com. Records must not be publicly accessible. Which solution provides the required hybrid DNS resolution with the least operational overhead?
- Create a Route 53 private hosted zone for corp.example.com, associate it with all VPCs, and configure Route 53 Resolver inbound endpoints so on-premises servers can forward queries to the VPC DNS — Correct answer
- Deploy BIND DNS servers in the shared-services VPC, configure all VPCs to use the BIND servers via DHCP option sets, and set up conditional forwarders on the on-premises DNS for corp.example.com
- Create a Route 53 public hosted zone for corp.example.com with all internal records, restrict access using IAM policies, and point on-premises DNS to Route 53 public resolvers
- Configure each VPC with its own private hosted zone and use VPC peering DNS resolution to allow cross-VPC name resolution, then set up a VPN-based DNS proxy for on-premises access
Explanation:
- Why correct (A): A Route 53 private hosted zone associated with all VPCs provides internal DNS resolution for corp.example.com across all VPCs without exposing records publicly. Route 53 Resolver inbound endpoints provide an IP address that on-premises DNS servers can forward queries to, enabling the on-premises data center to resolve AWS private DNS names over the existing VPN or Direct Connect connection. This is the AWS-recommended architecture for hybrid DNS.
- Why B is wrong: Running self-managed BIND servers adds operational overhead for patching, scaling, and high availability that Route 53 handles natively. DHCP option sets that override the default VPC DNS resolver also break Route 53 private hosted zone resolution and interface endpoint private DNS, causing unintended side effects.
- Why C is wrong: Placing internal hostnames in a public hosted zone exposes them to the internet, violating the private resolution requirement. IAM policies control who can manage DNS records via the API, not who can resolve them—public hosted zone records are queryable by anyone on the internet.
- Why D is wrong: Creating separate private hosted zones per VPC does not enable cross-VPC resolution by default. VPC peering DNS resolution only works for the VPC-provided DNS (the .2 resolver), not for private hosted zones associated with other VPCs. This architecture would require duplicating records across zones and adds a custom DNS proxy, increasing complexity.
JavaScript is required to use this application.
Please enable JavaScript in your browser to access the full NestedCerts platform.
Contact: support@nestedcerts.com