🧠 DNSSEC Daily Quizzes

40 Days × 3 Questions = 120 Scenario-Based Questions from Real Support Tickets

route53.jideaws.ai

Click any day to expand the quiz. Questions are based on real DNSSEC support scenarios with all customer information removed.

📅 Day 1: KMS Key Deletion & DNSSEC Impact
Q1: A customer's DNSSEC KSK shows ACTION_NEEDED status. The backing KMS key has "pending deletion" status. What is the immediate impact?
  1. No impact — zone resolves normally for all clients
  2. Zone fails resolution for DNSSEC-validating resolvers only
  3. Zone fails resolution for all resolvers
  4. Only AAAA queries fail
Show AnswerB — Only DNSSEC-validating resolvers (like Google DNS, Cloudflare) will return SERVFAIL. Non-validating resolvers continue to work normally.
Q2: What KMS permissions must Route 53 have on the CMK backing a DNSSEC KSK?
  1. Encrypt, Decrypt, GenerateDataKey
  2. DescribeKey, GetPublicKey, Sign
  3. CreateKey, ScheduleKeyDeletion, EnableKey
  4. GenerateRandom, ReEncrypt, Verify
Show AnswerB — Route 53 needs DescribeKey, GetPublicKey, and Sign permissions on the KMS key to manage DNSSEC signing.
Q3: A customer accidentally scheduled their DNSSEC KMS key for deletion. What is the correct remediation order?
  1. Create new KMS key → Create new KSK → Update DS record
  2. Cancel key deletion → Enable key → Verify policy → Reactivate KSK
  3. Disable DNSSEC → Delete KSK → Create new setup
  4. Contact AWS to restore the key from backup
Show AnswerB — Cancel the pending deletion, enable the key, verify the key policy grants Route 53 the required permissions, then reactivate the KSK.
📅 Day 2: DNSSEC + KMS Deadlock Scenario
Q1: A customer gets this error when trying to delete a hosted zone: "The specified hosted zone contains DNSSEC Key Signing Keys and so cannot be deleted." The KMS key is permanently deleted. What is this scenario called?
  1. DNS loop
  2. DNSSEC + KMS deadlock
  3. Circular dependency failure
  4. Zone lock conflict
Show AnswerB — This is a known "DNSSEC + KMS deadlock" where DNSSEC can't be disabled (KMS key gone) and the zone can't be deleted (KSKs exist).
Q2: In the deadlock scenario, what is the resolution path?
  1. Customer can resolve it via the Console by force-deleting the zone
  2. Customer must create a new KMS key with the same key ID
  3. Requires backend intervention from the Route 53 service team
  4. Wait 30 days and the zone auto-deletes
Show AnswerC — When the KMS key is permanently deleted, only the Route 53 service team can force-detach DNSSEC from the backend.
Q3: How can customers prevent the DNSSEC + KMS deadlock?
  1. Use AWS-managed keys instead of CMKs
  2. Set up CloudWatch alarms for DNSSECKeySigningKeysNeedingAction and never delete KMS keys backing active DNSSEC
  3. Enable automatic key rotation
  4. Use multi-region KMS keys
Show AnswerB — CloudWatch alarms provide early warning, and customers should never delete KMS keys that back active DNSSEC configurations without first disabling DNSSEC.
📅 Day 3: Domain Transfer with Stale DS Records
Q1: A customer transferred a .nl domain to Route 53 but didn't disable DNSSEC before transfer. The domain now returns SERVFAIL. Why?
  1. Route 53 doesn't support .nl domains
  2. The old DS record at the TLD registry points to keys that no longer exist, breaking the chain of trust
  3. The transfer corrupted the zone file
  4. Route 53 automatically enables DNSSEC validation on transferred domains
Show AnswerB — The stale DS record from the previous registrar creates a broken chain of trust. Validating resolvers see the DS record, expect valid signatures, but find none.
Q2: Who can remove the orphaned DS record from the TLD registry?
  1. The customer via the Route 53 console
  2. Only the current registrar of record (Route 53/Amazon)
  3. The previous registrar (Gandi, GoDaddy, etc.)
  4. ICANN directly
Show AnswerB — Only the current registrar can request DS record changes at the TLD registry. Since Route 53 is now the registrar, AWS must submit the removal request.
Q3: What should customers do BEFORE transferring a DNSSEC-signed domain?
  1. Increase the TTL on all records
  2. Disable DNSSEC and remove the DS record at the current registrar
  3. Export the private keys
  4. Nothing — DNSSEC transfers automatically
Show AnswerB — Always disable DNSSEC and ensure the DS record is removed from the parent zone before initiating a domain transfer to avoid broken chain of trust.
📅 Day 4: Stale DNSSEC Records After Disabling
Q1: A customer disabled DNSSEC signing on their hosted zone 24 hours ago, but dig still returns DNSKEY and RRSIG records from Route 53 nameservers. What's happening?
  1. DNSSEC was not actually disabled
  2. The records are cached by intermediate resolvers
  3. Route 53 may still be serving stale DNSSEC records from its signing infrastructure
  4. The customer needs to manually delete RRSIG records
Show AnswerC — In some cases, Route 53's signing infrastructure may continue serving DNSSEC records briefly after disabling. If it persists beyond TTL, escalation to the service team is needed.
Q2: Stale DNSSEC records are causing email delivery failures (550 5.4.312 DNS query failed). Why?
  1. DNSSEC blocks email by design
  2. Expired RRSIG signatures cause DNSSEC-validating mail servers to reject the domain
  3. MX records are incompatible with DNSSEC
  4. The SPF record conflicts with RRSIG
Show AnswerB — When RRSIG signatures expire but are still being served, DNSSEC-validating resolvers (used by mail servers like Outlook) return SERVFAIL, causing email delivery failures.
Q3: What can a customer try to force Route 53 to stop serving stale DNSSEC records?
  1. Add and delete a dummy TXT record to trigger a zone update
  2. Change the SOA serial number
  3. Both A and B, but if they don't work, escalate to the service team
  4. Delete and recreate the hosted zone
Show AnswerC — Adding/removing a record may trigger a zone refresh. If stale records persist, the Route 53 service team needs to investigate the signing infrastructure.
📅 Day 5: Disabling DNSSEC — Correct Order
Q1: A customer tries to disable DNSSEC on their hosted zone and gets: "Disabling DNSSEC will break the authentication chain. Please remove DS records in the parent zone first." What must they do?
  1. Delete the KSK first
  2. Remove the DS record from the parent zone (registrar), then disable signing
  3. Disable DNSSEC validation on all VPCs first
  4. Wait for the RRSIG TTL to expire
Show AnswerB — The DS record in the parent zone must be removed first. Otherwise, validating resolvers would see the DS record, expect DNSSEC, but find no signatures — causing SERVFAIL.
Q2: What is the correct order to completely disable DNSSEC?
  1. Disable signing → Remove DS → Deactivate KSK → Delete KSK
  2. Remove DS from parent → Wait for TTL → Disable signing → Deactivate KSK → Delete KSK
  3. Delete KSK → Remove DS → Disable signing
  4. Deactivate KSK → Delete KSK → Remove DS → Disable signing
Show AnswerB — Remove DS first (breaks chain of trust safely), wait for DS TTL to expire from caches, then disable signing, deactivate KSK, and finally delete KSK.
Q3: A customer removed the DS record but didn't wait before disabling signing. Some users get SERVFAIL for a few hours. Why?
  1. Route 53 bug
  2. Cached DS records in resolvers still point to the now-missing signatures
  3. The registrar didn't actually remove the DS record
  4. DNSSEC validation is mandatory for all resolvers
Show AnswerB — Resolvers cache the DS record based on its TTL. Until the cache expires, they still expect valid DNSSEC signatures. Always wait for DS TTL to expire before disabling signing.
📅 Day 6: IAM Permissions for DNSSEC
Q1: A customer with AmazonRoute53FullAccess policy gets permission errors managing DNSSEC. Why?
  1. DNSSEC requires a separate service-linked role
  2. The managed policy doesn't include KMS permissions needed for DNSSEC
  3. DNSSEC management requires root account access
  4. The policy only covers Route 53 Resolver, not hosted zones
Show AnswerB — AmazonRoute53FullAccess grants route53:* but not the KMS permissions (DescribeKey, GetPublicKey, Sign, CreateGrant) required for DNSSEC key management.
Q2: What additional IAM permissions does a user need for DNSSEC management?
  1. kms:* on all keys
  2. kms:DescribeKey, kms:GetPublicKey, kms:Sign, kms:CreateGrant on the specific CMK
  3. iam:CreateServiceLinkedRole for Route 53
  4. sts:AssumeRole for the DNSSEC service role
Show AnswerB — Users need specific KMS permissions scoped to the CMK ARN used for DNSSEC. CreateGrant is needed for initial setup.
Q3: What KMS key specification is required for Route 53 DNSSEC?
  1. Symmetric AES-256
  2. Asymmetric RSA_2048 with SIGN_VERIFY usage
  3. Asymmetric ECC_NIST_P256 with SIGN_VERIFY usage
  4. HMAC_256
Show AnswerC — Route 53 DNSSEC requires an asymmetric CMK with key spec ECC_NIST_P256 and key usage SIGN_VERIFY.
📅 Day 7: Enabling DNSSEC — No DS Record
Q1: A customer enabled DNSSEC signing 3 months ago but DNSViz shows the zone as "unsigned." What's the most likely cause?
  1. The KSK expired
  2. They never added the DS record to the parent zone
  3. Route 53 automatically disabled it
  4. The ZSK was rotated incorrectly
Show AnswerB — Without the DS record in the parent zone, there's no chain of trust. Resolvers treat the zone as unsigned even though signatures exist.
Q2: Is there any risk if DNSSEC signing is enabled but no DS record exists?
  1. Yes — the zone will eventually stop resolving
  2. Yes — it doubles DNS response sizes causing timeouts
  3. No — the zone resolves normally but DNSSEC protection is not active
  4. No — DNSSEC still works without the DS record
Show AnswerC — Without the DS record, the zone works fine (no outage risk) but provides zero DNSSEC security benefit. Signatures exist but can't be validated.
Q3: What is the correct order to enable DNSSEC in Route 53?
  1. Add DS to parent → Enable signing → Create KSK
  2. Enable signing → Create KSK → Add DS record to parent zone
  3. Create KMS key → Add DS to parent → Enable signing
  4. Create KSK → Enable signing → Add DS to parent
Show AnswerB — Enable DNSSEC signing (creates ZSK), create a KSK (backed by KMS CMK), then add the DS record to the parent zone to complete the chain of trust.
📅 Day 8: DNSSEC and Domain Transfers
Q1: A customer wants to transfer their DNSSEC-signed domain to a different registrar. What are the two valid approaches?
  1. Transfer first, fix DNSSEC later OR disable DNSSEC before transfer
  2. Export private keys OR use DNSSEC key rollover
  3. Only option is to disable DNSSEC before transfer
  4. Contact ICANN to coordinate the transfer
Show AnswerA — Either disable DNSSEC before transfer (simpler, brief window without protection) or coordinate DS record migration with the new registrar (complex but no protection gap).
Q2: A customer wants to transfer domain registrar management between AWS accounts while DNSSEC is enabled. What's the safest approach?
  1. Transfer directly — DNSSEC follows automatically
  2. Disable DNSSEC → Transfer domain → Re-enable DNSSEC in new account
  3. It's impossible to transfer with DNSSEC enabled
  4. Only the KSK needs to be recreated after transfer
Show AnswerB — The safest path is to disable DNSSEC (remove DS, disable signing), transfer the domain, then set up fresh DNSSEC in the destination account.
Q3: After transferring a domain, the customer gets "DNSSEC you specified is not found on domain" when trying to remove the DS record via CLI. Why?
  1. The DS record was already removed during transfer
  2. The DS record exists at the registry but isn't visible in the Route 53 registrar console
  3. Wrong key tag ID specified
  4. The domain transfer hasn't completed yet
Show AnswerB — Sometimes the DS record exists at the TLD registry but isn't reflected in the Route 53 console. Backend removal by the service team may be required.
📅 Day 9: DNSSEC Validation on VPC
Q1: What is the difference between "enabling DNSSEC signing on a hosted zone" and "enabling DNSSEC validation on a VPC"?
  1. They are the same thing
  2. Signing adds signatures to YOUR zone's responses; Validation makes your VPC resolver VERIFY signatures on other zones
  3. Signing is for public zones; Validation is for private zones
  4. Signing requires KMS; Validation requires CloudHSM
Show AnswerB — Signing makes your zone produce DNSSEC signatures. Validation makes the VPC's .2 resolver check signatures on responses from ANY zone it queries.
Q2: A customer enabled DNSSEC validation on their VPC. Now some third-party domains return SERVFAIL. Why?
  1. Route 53 Resolver is broken
  2. Those domains have misconfigured DNSSEC (broken chain of trust) and the validating resolver correctly rejects them
  3. DNSSEC validation blocks all external domains
  4. The VPC security group is blocking DNS
Show AnswerB — DNSSEC validation correctly rejects responses from domains with broken DNSSEC. This is working as intended — it protects against spoofing but also rejects legitimately broken configurations.
Q3: Will enabling DNSSEC validation on a VPC affect resolution of VPC endpoints and interface endpoints?
  1. Yes — all endpoint resolution will fail
  2. No — AWS service endpoints have valid DNSSEC or are excluded from validation
  3. Only interface endpoints are affected
  4. Only gateway endpoints are affected
Show AnswerB — AWS service endpoints are designed to work with DNSSEC validation enabled. However, if forwarding to external resolvers, those resolvers must also support DNSSEC validation.
📅 Day 10: DS Record Cache & Key Rotation
Q1: A customer rotated their DNSSEC keys and updated the DS record, but VPC resolvers still cache the old DS record. What should they do?
  1. Restart all EC2 instances
  2. Wait for the DS record TTL to expire (typically 24-48 hours)
  3. Disable and re-enable DNSSEC validation on the VPC
  4. Request a resolver cache flush from AWS support
Show AnswerD — While waiting for TTL is the standard approach, in urgent production scenarios, AWS support can request a cache flush for specific records on the resolver fleet.
Q2: During KSK rotation, what is the risk if the old DS record is removed before the new one propagates?
  1. No risk — the zone continues to work
  2. Brief window where DNSSEC validation fails for resolvers that cached the old DS but haven't seen the new one
  3. Permanent zone outage
  4. Only affects IPv6 resolution
Show AnswerB — There's a propagation window where some resolvers have the old DS (pointing to old KSK) while the zone is signed with the new KSK. This causes validation failures until caches update.
Q3: What is the recommended approach for KSK rotation to avoid downtime?
  1. Double-DS method: add new DS alongside old DS, wait for propagation, then remove old DS
  2. Remove old DS, immediately add new DS
  3. Disable DNSSEC, rotate, re-enable
  4. KSK rotation is not supported in Route 53
Show AnswerA — The double-DS (or double-signature) method ensures both old and new DS records are valid during the transition period, preventing any validation failures.
📅 Day 11: DNSSEC and ACM Certificate Validation
Q1: A customer's ACM certificate is stuck in PENDING_VALIDATION. Their domain has DNSSEC enabled with a broken chain of trust. How are these related?
  1. ACM doesn't support DNSSEC-signed domains
  2. ACM's validation system uses DNSSEC-validating resolvers that return SERVFAIL for the broken domain
  3. The CNAME validation record conflicts with RRSIG records
  4. They are unrelated issues
Show AnswerB — ACM's backend validation uses DNSSEC-aware resolvers. If the domain's DNSSEC is broken, ACM cannot resolve the validation CNAME and the certificate stays pending.
Q2: How should the customer fix the ACM validation issue caused by broken DNSSEC?
  1. Use email validation instead of DNS
  2. Fix the DNSSEC chain of trust (repair KMS key/DS record), then re-request the certificate
  3. Create the certificate in a different region
  4. Use a wildcard certificate instead
Show AnswerB — Fix the underlying DNSSEC issue first. Once the chain of trust is restored and the domain resolves properly, ACM validation will succeed.
Q3: A domain was transferred to Route 53 without disabling DNSSEC. Now ACM validation fails AND the website is down for some users. What's the common root cause?
  1. Route 53 nameserver misconfiguration
  2. Orphaned DS record at the TLD registry causing SERVFAIL for validating resolvers
  3. ACM rate limiting
  4. The hosted zone wasn't created
Show AnswerB — The stale DS record causes SERVFAIL for any DNSSEC-validating resolver, affecting both website resolution and ACM's ability to validate the domain.
📅 Day 12: ZSK vs KSK
Q1: What does the Zone Signing Key (ZSK) sign?
  1. Only the DNSKEY records
  2. All resource record sets (RRSets) in the zone except DNSKEY
  3. Only A and AAAA records
  4. The DS record in the parent zone
Show AnswerB — The ZSK signs all RRSets in the zone (A, AAAA, MX, CNAME, etc.) except the DNSKEY RRSet itself.
Q2: What does the Key Signing Key (KSK) sign?
  1. All records in the zone
  2. Only the DNSKEY RRSet (which contains both the public ZSK and public KSK)
  3. The DS record
  4. Only MX and TXT records
Show AnswerB — The KSK signs the DNSKEY RRSet, creating an RRSIG that covers both the public ZSK and public KSK stored in DNSKEY records.
Q3: Why does DNSSEC use two separate keys (ZSK and KSK) instead of one?
  1. Regulatory requirement
  2. ZSK rotates frequently (smaller, faster); KSK rotates rarely (linked to parent DS record, harder to change)
  3. ZSK is for IPv4 and KSK is for IPv6
  4. One is for encryption and one is for signing
Show AnswerB — Separating keys allows frequent ZSK rotation (no parent zone coordination needed) while keeping KSK rotation rare (requires DS record update in parent zone).
📅 Day 13: Black-Lies & Negative Responses
Q1: How does Route 53 handle DNSSEC-signed negative responses (NXDOMAIN)?
  1. NSEC records listing all zone contents
  2. NSEC3 with hashed names
  3. "Black-lies" — synthesized minimal NSEC records on-the-fly
  4. Returns unsigned NXDOMAIN
Show AnswerC — Route 53 uses "black-lies" which synthesize a minimal NSEC record claiming the queried name exists but has no records of the requested type, avoiding zone enumeration.
Q2: What is the main advantage of "black-lies" over traditional NSEC?
  1. Faster response times
  2. Prevents zone walking/enumeration (doesn't reveal adjacent domain names)
  3. Smaller DNS response size
  4. Compatible with more resolvers
Show AnswerB — Traditional NSEC reveals the next existing name in the zone, allowing attackers to enumerate all names. Black-lies prevent this by not exposing zone contents.
Q3: Which NSEC-related record types are NOT used by Route 53 DNSSEC?
  1. NSEC
  2. NSEC3, NSEC3PARAM, NSEC5
  3. RRSIG
  4. DNSKEY
Show AnswerB — Route 53 does not use NSEC3, NSEC3PARAM, or NSEC5. It uses its own "black-lies" implementation with synthesized NSEC records.
📅 Day 14: CloudWatch Monitoring for DNSSEC
Q1: Which CloudWatch metrics should be alarmed for DNSSEC health?
  1. DNSQueries and Latency
  2. DNSSECKeySigningKeysNeedingAction and DNSSECInternalFailure
  3. HealthCheckStatus and ConnectionTime
  4. ResolverQueryVolume and FirewallBlockedQueries
Show AnswerB — These two metrics detect KSK issues (broken KMS key, expired signatures) and internal DNSSEC failures before they cause outages.
Q2: A SEV-2 is triggered because multiple customers have KSKs in ACTION_NEEDED state. What typically caused this?
  1. Route 53 service issue
  2. Customers deleted or modified their KMS keys without realizing the DNSSEC dependency
  3. Automatic key rotation failed
  4. AWS KMS had an outage
Show AnswerB — Most ACTION_NEEDED states are caused by customer actions: deleting KMS keys, modifying key policies, or disabling keys without understanding the DNSSEC dependency.
Q3: What is the standard support response when a customer's KSK is in ACTION_NEEDED?
  1. Disable DNSSEC on their behalf
  2. Proactive outreach with pre-approved message explaining the issue and remediation steps
  3. Wait for the customer to contact support
  4. Automatically create a new KMS key
Show AnswerB — The Route 53 team proactively reaches out to affected customers with a standard message explaining the issue and linking to documentation for KMS key policy fixes.
📅 Day 15: DNSSEC Validation vs Signing
Q1: A customer has private VPCs and public VPCs connected via Transit Gateway. Where should DNSSEC validation be enabled?
  1. Only on public VPCs
  2. Only on private VPCs
  3. On all VPCs that need protection from DNS spoofing, considering that broken third-party DNSSEC may cause SERVFAIL
  4. On the Transit Gateway itself
Show AnswerC — Enable validation on VPCs where DNS integrity matters, but understand the trade-off: domains with broken DNSSEC will return SERVFAIL instead of potentially spoofed answers.
Q2: If DNSSEC validation is enabled on a VPC and the resolver forwards to another DNS resolver, what requirement exists?
  1. The forwarding resolver must also perform DNSSEC validation
  2. No additional requirements
  3. The forwarding resolver must support EDNS0
  4. The forwarding resolver must be in the same region
Show AnswerA — Per AWS documentation, if Route 53 Resolver forwards to another resolver performing recursive resolution, that resolver must also apply DNSSEC validation for end-to-end security.
Q3: Enabling DNSSEC validation on a VPC can take how long to propagate?
  1. Instantly
  2. Several minutes
  3. 24 hours
  4. Up to 48 hours
Show AnswerB — AWS documentation states that enabling or disabling DNSSEC validation can take several minutes to propagate across the VPC's resolver infrastructure.
📅 Day 16: DNSSEC and Email Delivery
Q1: A customer reports email bounces with "550 5.4.312 DNS query failed" from Outlook/Microsoft. Their domain has DNSSEC enabled. What's likely wrong?
  1. SPF record is misconfigured
  2. Microsoft's mail servers use DNSSEC-validating resolvers and the domain's chain of trust is broken
  3. DKIM conflicts with DNSSEC
  4. MX record TTL is too low
Show AnswerB — Microsoft and other major email providers use DNSSEC-validating resolvers. A broken chain of trust causes SERVFAIL, which mail servers interpret as a DNS failure and bounce the email.
Q2: Which email providers are known to use DNSSEC-validating resolvers?
  1. Only Gmail
  2. Microsoft (Outlook/365), Google, Cloudflare-based providers, and many corporate networks
  3. None — email doesn't use DNSSEC
  4. Only government email systems
Show AnswerB — Major providers including Microsoft, Google, and Cloudflare validate DNSSEC. Corporate networks with security policies often enable validation too.
Q3: A customer's email was working fine until they rotated their DNSSEC keys incorrectly. What's the fastest fix to restore email delivery?
  1. Wait for DNS propagation
  2. Fix the chain of trust (correct DS record) or temporarily disable DNSSEC (remove DS first)
  3. Change MX records to a different provider
  4. Contact Microsoft to whitelist the domain
Show AnswerB — Either fix the chain of trust by correcting the DS record, or safely disable DNSSEC by removing the DS record first. Email will resume once resolvers can successfully query the domain.
📅 Day 17: DNSSEC Fundamentals Review
Q1: DNSSEC provides which of the following? (Select the best answer)
  1. Data confidentiality and integrity
  2. Data origin authentication, integrity, and authenticated denial of existence
  3. DDoS protection and rate limiting
  4. Encryption of DNS queries and responses
Show AnswerB — DNSSEC provides authentication (data came from the right source), integrity (data wasn't modified), and authenticated denial (proof a name doesn't exist). It does NOT provide confidentiality.
Q2: What attack does DNSSEC primarily prevent?
  1. DDoS attacks on DNS servers
  2. DNS cache poisoning and man-in-the-middle attacks
  3. Zone transfer attacks
  4. DNS amplification attacks
Show AnswerB — DNSSEC prevents attackers from injecting false records into resolver caches (cache poisoning) and intercepting/modifying DNS responses in transit (MITM).
Q3: Why doesn't DNSSEC provide confidentiality?
  1. It's too computationally expensive
  2. DNS responses are signed but not encrypted — anyone can still see the queries and responses
  3. Confidentiality would break caching
  4. It was designed before encryption was common
Show AnswerB — DNSSEC only signs responses (proving authenticity and integrity). The actual DNS data remains visible to anyone observing the traffic. DNS-over-HTTPS/TLS provides confidentiality.
📅 Day 18: Chain of Trust Deep Dive
Q1: What is the "trust anchor" in the DNSSEC chain of trust?
  1. The domain's KSK
  2. The root zone's public KSK, embedded in resolvers
  3. The TLD's DS record
  4. The registrar's certificate
Show AnswerB — The root zone's public KSK is the trust anchor. It's pre-configured in DNSSEC-validating resolvers and serves as the starting point for validating the entire chain.
Q2: In the chain: Root → .com → example.com, what links .com to example.com?
  1. An NS record in the .com zone
  2. A DS record in the .com zone containing a hash of example.com's KSK
  3. A DNSKEY record in example.com pointing to .com
  4. A CNAME record
Show AnswerB — The DS record in the parent zone (.com) contains a hash of the child zone's (example.com) KSK DNSKEY, establishing the trust link between zones.
Q3: A customer's domain shows green in DNSViz for their zone but red at the parent level. What does this indicate?
  1. The zone's signatures are valid but the DS record in the parent doesn't match the KSK
  2. The zone has too many records
  3. DNSViz is showing a false positive
  4. The nameservers are misconfigured
Show AnswerA — Green at the zone level means signatures are valid. Red at the parent level means the DS record doesn't match the KSK hash — the chain of trust is broken at that link.
📅 Day 19: RRSIG Expiration
Q1: What happens when RRSIG signatures expire?
  1. Nothing — expired signatures are ignored
  2. DNSSEC-validating resolvers treat the zone as unsigned
  3. DNSSEC-validating resolvers return SERVFAIL (signatures exist but are invalid)
  4. The zone is automatically re-signed
Show AnswerC — Expired signatures are treated as invalid. Since the DS record still exists (indicating DNSSEC should work), validating resolvers return SERVFAIL rather than falling back to unsigned.
Q2: In Route 53, who is responsible for re-signing records before RRSIG expiration?
  1. The customer must manually re-sign
  2. Route 53 automatically re-signs records (managed service)
  3. The KMS key auto-rotates and re-signs
  4. A Lambda function must be configured
Show AnswerB — Route 53 is a managed DNSSEC service. It automatically re-signs records before expiration, as long as the KMS key backing the KSK remains accessible.
Q3: If Route 53 cannot access the KMS key, what happens to signature renewal?
  1. Signatures continue to be renewed using cached keys
  2. Route 53 creates a new KMS key automatically
  3. Signatures eventually expire, causing SERVFAIL for validating resolvers
  4. The zone is automatically converted to unsigned
Show AnswerC — Without KMS access, Route 53 cannot re-sign records. When existing signatures expire, validating resolvers will return SERVFAIL. This is why KMS key health is critical.
📅 Day 20: Multi-Domain DNSSEC Failures
Q1: A customer transferred 5 domains from another registrar without disabling DNSSEC on any of them. All 5 now have "bogus DNSSEC configuration." What's the fastest bulk fix?
  1. Re-enable DNSSEC on all 5 domains in Route 53
  2. Request the Route 53 registrar team to remove orphaned DS records at the respective TLD registries for all 5 domains
  3. Wait 7 days for automatic cleanup
  4. Transfer the domains back to the original registrar
Show AnswerB — Since Route 53 is now the registrar, they must submit DS record removal requests to each TLD registry. This is a backend operation requiring service team involvement.
Q2: For .nl domains specifically, which registry manages DS records?
  1. ICANN
  2. SIDN (Stichting Internet Domeinregistratie Nederland)
  3. Verisign
  4. RIPE NCC
Show AnswerB — SIDN is the .nl TLD registry. Only the current registrar (Route 53/Amazon) can request DS record changes at SIDN on behalf of the domain holder.
Q3: What is the recommended pre-transfer checklist for DNSSEC-signed domains?
  1. Export zone file → Transfer → Import zone file
  2. Lower TTLs → Remove DS record → Wait for propagation → Disable DNSSEC → Transfer
  3. Just transfer — DNSSEC migrates automatically
  4. Contact the new registrar to prepare DS records in advance
Show AnswerB — Lower TTLs for faster propagation, remove DS from parent zone, wait for DS TTL to expire from caches, disable DNSSEC signing, then initiate the transfer.
📅 Day 21: DNSSEC and IPv6 Glue Records
Q1: A customer runs DNSViz and sees: "Authoritative AAAA records exist for ns-208.awsdns-26.com, but there are no corresponding AAAA glue records." Is this a problem?
  1. Yes — it will cause resolution failures
  2. No — this is a known informational warning for .com TLD AWS nameservers; resolution works fine
  3. Yes — IPv6 clients cannot resolve the domain
  4. It depends on whether DNSSEC is enabled
Show AnswerB — This is a known informational warning. AWS nameservers have AAAA records but the .com TLD may not have corresponding IPv6 glue records. Resolution is not affected.
Q2: Glue records are needed when:
  1. DNSSEC is enabled on any domain
  2. A nameserver's hostname is within the zone it serves (circular dependency)
  3. The domain uses IPv6
  4. The domain has more than 4 nameservers
Show AnswerB — Glue records (A/AAAA records in the parent zone) are needed when a nameserver's name is under the zone it's authoritative for, to break the circular lookup dependency.
Q3: Does the IPv6 glue record warning affect DNSSEC chain of trust validation?
  1. Yes — it breaks the chain
  2. No — glue records are for nameserver reachability, not DNSSEC validation
  3. Only for .com domains
  4. Only when DNSSEC validation is enabled on the VPC
Show AnswerB — Glue records help resolvers find nameservers. DNSSEC chain of trust is validated through DS → DNSKEY → RRSIG, which is independent of how the nameserver was reached.
📅 Day 22: SEV-2 Incidents & Bulk KMS Failures
Q1: A SEV-2 ticket is raised because 9 customers simultaneously have KSKs in ACTION_NEEDED. What's the most likely common cause?
  1. AWS KMS regional outage
  2. Each customer independently broke their own KMS key (coincidental timing of detection)
  3. Route 53 DNSSEC service bug
  4. Automatic key rotation failed for all customers
Show AnswerB — These are typically detected in batches during periodic health checks. Each customer independently caused their own issue (deleted key, modified policy) at different times.
Q2: What is the standard operational response to bulk KSK ACTION_NEEDED detections?
  1. Disable DNSSEC for all affected customers
  2. Proactive customer outreach with pre-approved messaging and remediation links
  3. Escalate to KMS team
  4. Wait for customers to notice and contact support
Show AnswerB — The Route 53 DNSSEC runbook specifies proactive outreach using pre-approved text that explains the issue and provides links to fix KMS key policies and reactivate KSKs.
Q3: Which oncall team handles DNSSEC-specific escalations?
  1. route53-primary
  2. route53-dnssec-primary
  3. kms-oncall
  4. dns-operations
Show AnswerB — The route53-dnssec-primary oncall handles DNSSEC-specific escalations including KMS deadlocks, backend signing issues, and bulk ACTION_NEEDED incidents.
📅 Day 23: DNSSEC with CloudFormation
Q1: When automating DNSSEC setup via CloudFormation, what resource creates the KSK?
  1. AWS::Route53::HostedZone with DNSSECConfig
  2. AWS::Route53::KeySigningKey
  3. AWS::KMS::Key with DNSSEC policy
  4. AWS::Route53::DNSSEC
Show AnswerB — AWS::Route53::KeySigningKey creates the KSK and links it to both the hosted zone and the KMS CMK.
Q2: What must be created BEFORE the KeySigningKey resource in a CloudFormation template?
  1. The hosted zone and the KMS key with correct policy
  2. Only the hosted zone
  3. The DS record
  4. A service-linked role
Show AnswerA — Both the hosted zone (to attach the KSK to) and the KMS key (with Route 53 permissions in its policy) must exist before creating the KeySigningKey resource.
Q3: Can CloudFormation automatically add the DS record to the parent zone?
  1. Yes — it's part of the KeySigningKey resource
  2. No — the DS record must be added manually or via a separate automation to the registrar
  3. Only if the domain is registered in Route 53
  4. Yes — using AWS::Route53::DSRecord
Show AnswerB — CloudFormation can enable signing and create KSKs, but adding the DS record to the parent zone requires registrar-level action that's outside CloudFormation's scope.
📅 Day 24: Troubleshooting with dig and DNSViz
Q1: What dig command shows DNSSEC records for a domain?
  1. dig example.com +trace
  2. dig example.com +dnssec
  3. dig example.com DNSKEY
  4. Both B and C provide useful DNSSEC information
Show AnswerD — `dig +dnssec` shows RRSIG records alongside regular answers. `dig DNSKEY` shows the zone's public keys. Both are useful for DNSSEC troubleshooting.
Q2: In DNSViz output, what does a red "X" between the parent zone and child zone indicate?
  1. The nameservers are unreachable
  2. The DS record in the parent doesn't match the KSK hash in the child zone
  3. The zone has no records
  4. DNSSEC is not enabled
Show AnswerB — A red X at the DS-to-DNSKEY link means the DS record hash doesn't match any DNSKEY in the child zone, indicating a broken chain of trust.
Q3: How do you check if a domain's DS record exists at the TLD level?
  1. dig example.com DS @8.8.8.8
  2. dig example.com DS @a.gtld-servers.net (querying TLD nameserver directly)
  3. whois example.com
  4. nslookup -type=DS example.com
Show AnswerB — Querying the TLD nameserver directly (e.g., a.gtld-servers.net for .com) shows the actual DS record at the registry level, bypassing any caching.
📅 Day 25: DNSSEC and Resolver Cache Flush
Q1: A customer rotated their DS record but the VPC resolver still returns the old DS. Public resolvers (8.8.8.8, 1.1.1.1) show the new DS. Why?
  1. VPC resolver is broken
  2. The VPC resolver has the old DS cached and the TTL hasn't expired yet
  3. VPC resolvers don't support DNSSEC
  4. The customer needs to restart their EC2 instances
Show AnswerB — The VPC .2 resolver caches records based on TTL. DS records often have 24-hour TTLs. The resolver will serve the cached version until TTL expires.
Q2: In an urgent production scenario where stale DS cache is causing outages, what can AWS support do?
  1. Nothing — must wait for TTL
  2. Request a cache flush for the specific record on the resolver fleet in affected AZs
  3. Restart the VPC resolver service
  4. Increase the resolver's cache size
Show AnswerB — AWS support can request a targeted cache flush for specific records on the resolver fleet. This is done in urgent production-impacting scenarios.
Q3: What is the standard DS record TTL, and why does it matter for DNSSEC operations?
  1. 5 minutes — allows fast key rotation
  2. Typically 24-48 hours — means DNSSEC changes take time to propagate globally
  3. 1 week — for maximum stability
  4. It varies per resolver and can't be controlled
Show AnswerB — DS records typically have 24-48 hour TTLs set by the TLD registry. This means after any DS record change, you must wait for this TTL to expire before all resolvers see the update.
📅 Day 26: DNSSEC Record Types Review
Q1: Match the record type to its purpose: RRSIG
  1. Contains the public key for signature verification
  2. Contains the cryptographic signature for a resource record set
  3. Links child zone to parent zone
  4. Proves non-existence of a record
Show AnswerB — RRSIG (Resource Record Signature) contains the digital signature that covers a specific RRSet, allowing resolvers to verify data integrity.
Q2: Match the record type to its purpose: DS
  1. Contains the public key for signature verification
  2. Contains the cryptographic signature for a resource record set
  3. A hash of the child zone's KSK, published in the parent zone
  4. Proves non-existence of a record
Show AnswerC — DS (Delegation Signer) is a hash of the child zone's KSK DNSKEY record, placed in the parent zone to establish the chain of trust.
Q3: A dig query returns both DNSKEY records with flags 256 and 257. What do these flags mean?
  1. 256 = ZSK (Zone Signing Key), 257 = KSK (Key Signing Key)
  2. 256 = primary key, 257 = backup key
  3. 256 = RSA key, 257 = ECDSA key
  4. 256 = active key, 257 = inactive key
Show AnswerA — Flag 256 indicates a Zone Signing Key (signs RRSets), flag 257 indicates a Key Signing Key (signs the DNSKEY RRSet and is referenced by the parent's DS record).
📅 Day 27: DNSSEC Operational Scenarios
Q1: A customer's domain resolves fine from most locations but fails from specific corporate networks. DNSSEC is enabled. What's the likely explanation?
  1. Geographic routing issue
  2. Those corporate networks use DNSSEC-validating resolvers and the domain's DNSSEC has an issue
  3. Firewall blocking DNS on those networks
  4. TTL differences between resolvers
Show AnswerB — Corporate networks often enable DNSSEC validation for security compliance. If the domain's DNSSEC is misconfigured, only these validating networks will see failures.
Q2: A customer has a hosted zone with DNSSEC enabled and the zone is on the FREE pricing plan (50 record limit). They want to delete the zone. What's the issue?
  1. Free plan zones can't be deleted
  2. DNSSEC KSKs must be removed before zone deletion, but the KMS key may be inaccessible
  3. The 50 record limit prevents deletion
  4. Free plan zones auto-delete after 30 days
Show AnswerB — Even on free-tier zones, DNSSEC KSKs block deletion. If the backing KMS key is gone, this creates the deadlock scenario requiring backend intervention.
Q3: A customer enabled DNSSEC but their domain registrar is external (not Route 53). Where do they add the DS record?
  1. In the Route 53 hosted zone
  2. At their external domain registrar's DNS management panel
  3. In the Route 53 Registered Domains section
  4. They can't use DNSSEC with an external registrar
Show AnswerB — The DS record must be added at the registrar that manages the domain's parent zone delegation. If the registrar is external, the customer adds it there.
📅 Day 28: DNSSEC Best Practices
Q1: What is the single most important monitoring setup for DNSSEC in Route 53?
  1. Health checks on the domain
  2. CloudWatch alarms for DNSSECKeySigningKeysNeedingAction and DNSSECInternalFailure
  3. Route 53 query logging
  4. AWS Config rules for KMS keys
Show AnswerB — These CloudWatch metrics provide early warning before DNSSEC issues cause outages. They detect KMS key problems and internal signing failures.
Q2: Before making any DNSSEC changes in production, what should you always verify first?
  1. The zone's record count
  2. The current chain of trust status using DNSViz or dig +dnssec
  3. The billing status of the account
  4. The VPC DNSSEC validation setting
Show AnswerB — Always verify the current state of the chain of trust before making changes. This establishes a baseline and helps identify if changes break something.
Q3: A customer asks: "Should I enable DNSSEC on my domain?" What factors should they consider?
  1. Always enable it — there's no downside
  2. Compliance requirements, KMS key management overhead, risk of outage from misconfiguration, and whether their users' resolvers validate DNSSEC
  3. Only if they have more than 100 DNS records
  4. Only if they use Route 53 as their registrar
Show AnswerB — DNSSEC adds security but also operational complexity. Customers should weigh compliance needs, their ability to manage KMS keys properly, and the risk that misconfiguration can cause outages.
📅 Day 29: Edge Cases & Gotchas
Q1: A customer has DNSSEC enabled on their hosted zone but the Route 53 Registered Domains page shows "DNSSEC: Not configured." Is this a problem?
  1. Yes — DNSSEC isn't actually working
  2. No — these are two different things: hosted zone signing vs registrar DS record configuration
  3. It's a console bug
  4. The customer needs to re-enable DNSSEC
Show AnswerB — "DNSSEC signing" on the hosted zone and "DNSSEC keys" at the registrar level are separate configurations. The registrar page shows DS record status, not signing status.
Q2: A customer's domain shows "DNSSEC: signedDelegation" in WHOIS but they never enabled DNSSEC in Route 53. How is this possible?
  1. Route 53 auto-enabled DNSSEC
  2. The domain was transferred from a registrar that had DNSSEC enabled, and the DS record persists at the registry
  3. WHOIS data is incorrect
  4. Another AWS account enabled it
Show AnswerB — When domains are transferred without disabling DNSSEC first, the old DS record can persist at the TLD registry even though the new setup doesn't have DNSSEC configured.
Q3: Can you have DNSSEC enabled on a private hosted zone?
  1. Yes — it works the same as public zones
  2. No — DNSSEC signing is only supported on public hosted zones
  3. Only with Route 53 Resolver endpoints
  4. Only in us-east-1
Show AnswerB — DNSSEC signing is only available for public hosted zones in Route 53. Private hosted zones do not support DNSSEC signing.
📅 Day 30: Comprehensive Scenario Challenge ⭐
Q1: A customer reports: "My website works from my phone (mobile data) but not from my office network." They have DNSSEC enabled. The office uses a corporate DNS resolver with DNSSEC validation. What's your first troubleshooting step?
  1. Check if the office firewall blocks port 53
  2. Verify the DNSSEC chain of trust using DNSViz or dig +dnssec +cd (checking disabled) to see if the domain resolves without validation
  3. Check the website's SSL certificate
  4. Verify the A record TTL
Show AnswerB — Use `dig +cd` (checking disabled) to bypass DNSSEC validation. If it resolves with +cd but fails without, the issue is DNSSEC validation failure. Then check DNSViz for the specific break.
Q2: You find the chain of trust is broken because the KMS key policy was modified by a different team member. The KSK shows ACTION_NEEDED. Put these remediation steps in order: (1) Verify chain of trust (2) Fix KMS key policy (3) Reactivate KSK (4) Set up CloudWatch alarm
  1. 2 → 3 → 1 → 4
  2. 3 → 2 → 1 → 4
  3. 1 → 2 → 3 → 4
  4. 4 → 2 → 3 → 1
Show AnswerA — Fix the KMS key policy first (restore Route 53 permissions), reactivate the KSK, verify the chain of trust is restored, then set up monitoring to prevent recurrence.
Q3: A customer wants to implement DNSSEC for the first time on a production domain with zero downtime. What is the safest implementation plan?
  1. Enable signing → Add DS → Done
  2. Enable signing → Create KSK → Verify signatures are valid → Add DS to parent → Verify chain of trust → Set up CloudWatch alarms
  3. Add DS first → Then enable signing
  4. Test in a staging zone → Copy configuration to production
Show AnswerB — Enable signing first (no impact since no DS exists), verify everything works, then add the DS record to activate the chain of trust. This ensures signing is correct before validators start checking.

🔥 Days 31-60: Advanced Scenarios from 1,206 Tickets

📅 Day 31: Domain clientHold & DNSSEC
Q1: A customer's domain shows "clientHold" status in WHOIS. What does this mean for DNS resolution?
  1. DNS works but HTTPS is blocked
  2. The TLD registry stops publishing NS records — domain returns NXDOMAIN globally
  3. Only affects email delivery
  4. The domain is locked but still resolves
Show AnswerB — clientHold tells the registry to remove the domain from the zone file. Without NS delegation at the TLD, all resolvers return NXDOMAIN.
Q2: A domain is on clientHold AND has DNSSEC enabled. After the hold is lifted, what additional step is needed?
  1. Nothing — DNSSEC resumes automatically when the hold is lifted
  2. Verify the DS record still exists at the registry and the KSK/KMS key is still accessible
  3. Re-register the domain
  4. Create a new hosted zone
Show AnswerB — After a hold is lifted, verify the DNSSEC chain of trust is intact. The DS record should persist, but confirm the KMS key backing the KSK hasn't been deleted during the hold period.
Q3: What commonly causes a Route 53 registered domain to go into clientHold?
  1. DNSSEC misconfiguration
  2. Email reachability verification failure (registrant email not confirmed)
  3. Too many DNS queries
  4. Hosted zone has too many records
Show AnswerB — Route 53 places domains on clientHold when the registrant email address fails ICANN-required reachability verification (not confirmed within the required timeframe).
📅 Day 32: Hosted Zone Limit Increases
Q1: A customer hits "Exceeded limit MAX_RRSETS_BY_ZONE" with a limit of 50. The default limit is 10,000. Why is theirs only 50?
  1. They're in a new AWS region
  2. Their hosted zone is on the FREE pricing plan which has a hard limit of 50 records
  3. They haven't verified their domain
  4. It's a private hosted zone limitation
Show AnswerB — Hosted zones on the FREE pricing plan have a hard limit of 50 records. This cannot be increased — the customer must upgrade to the standard pricing plan.
Q2: A customer requests MAX_RRSETS_BY_ZONE increase from 10,000 to 100,000. What should be verified before approving?
  1. Nothing — auto-approve all limit increases
  2. The use case justification, billing/fraud status, and inform customer of billing implications
  3. Only check if the account is Enterprise support
  4. Verify DNSSEC is not enabled
Show AnswerB — Per the runbook, verify the use case is legitimate, check billing/fraud status, and ensure the customer understands the cost implications of additional records.
Q3: The Route 53 limit increase tool returns HTTP 500: "The limit for MAX_RRSETS_BY_ZONE must be equal to 50 for pricing plan FREE." What does this mean?
  1. The tool is broken
  2. The hosted zone is on the FREE plan and the 50-record limit cannot be overridden — customer needs to change pricing plans
  3. The limit was already increased
  4. The zone needs to be recreated
Show AnswerB — FREE plan zones have a hard-coded 50-record limit enforced at the platform level. The only solution is for the customer to move to the standard pricing plan.
📅 Day 33: DNS Propagation After Domain Transfer
Q1: A customer transferred their domain to Route 53 but the domain still doesn't resolve 48 hours later. WHOIS shows correct Route 53 nameservers. What should you check?
  1. Whether the hosted zone was created with matching records
  2. Whether the domain's reachability status is "DONE" vs "PENDING"
  3. Both A and B
  4. Whether DNSSEC is enabled
Show AnswerC — Both are important. The hosted zone must exist with the correct records, AND the domain's reachability verification must be complete (PENDING status can block resolution).
Q2: After a domain transfer, the nameservers in WHOIS are correct but dig +trace stops at the TLD level with NXDOMAIN. What's the likely cause?
  1. DNS propagation delay
  2. The TLD registry hasn't updated the NS delegation yet, or the domain is on clientHold
  3. The hosted zone doesn't exist
  4. Route 53 nameservers are down
Show AnswerB — If dig +trace shows NXDOMAIN at the TLD level despite correct WHOIS nameservers, the registry delegation hasn't propagated or the domain has a hold status preventing publication.
Q3: A customer transferred a domain but forgot to create a hosted zone. What happens?
  1. Route 53 auto-creates a hosted zone
  2. The domain resolves using the previous registrar's records
  3. The nameservers respond with SERVFAIL or REFUSED since no zone data exists
  4. The transfer fails
Show AnswerC — Route 53 nameservers are delegated but have no zone data to serve. They'll return REFUSED or empty responses, effectively making the domain unreachable.
📅 Day 34: SERVFAIL vs NXDOMAIN
Q1: What's the difference between SERVFAIL and NXDOMAIN in the context of DNSSEC?
  1. They mean the same thing
  2. NXDOMAIN = domain doesn't exist; SERVFAIL = server error (often DNSSEC validation failure)
  3. SERVFAIL = domain doesn't exist; NXDOMAIN = server error
  4. Both indicate DNSSEC problems
Show AnswerB — NXDOMAIN means the name genuinely doesn't exist. SERVFAIL means the resolver encountered an error — in DNSSEC context, this usually means signature validation failed.
Q2: A domain returns SERVFAIL from Google DNS (8.8.8.8) but NOERROR from a non-validating resolver. What does this confirm?
  1. Google DNS is blocking the domain
  2. The domain has a DNSSEC validation issue (broken chain of trust or expired signatures)
  3. The domain's TTL is too low
  4. There's a network issue between the client and Google
Show AnswerB — Google DNS validates DNSSEC. If it returns SERVFAIL while non-validating resolvers work fine, the domain has a DNSSEC configuration problem.
Q3: How can you bypass DNSSEC validation in dig to confirm it's a DNSSEC issue?
  1. dig example.com +norecurse
  2. dig example.com +cd (checking disabled)
  3. dig example.com +short
  4. dig example.com +tcp
Show AnswerB — The +cd flag tells the resolver to disable DNSSEC checking. If the query succeeds with +cd but fails without it, DNSSEC validation is the problem.
📅 Day 35: Route 53 API Throttling
Q1: A customer reports heavy throttling on Route 53 API calls. What is the default API rate limit?
  1. 1 request per second
  2. 5 requests per second for changes, with a higher read limit
  3. 100 requests per second
  4. Unlimited
Show AnswerB — Route 53 has a default limit of 5 ChangeResourceRecordSets requests per second per account. Read operations have higher limits.
Q2: A customer requests API quota increase from 5/sec to 20 writes/sec. What information is needed to evaluate?
  1. Just the account ID
  2. Use case justification, current throttling evidence, and business impact
  3. The number of hosted zones
  4. Their support plan level
Show AnswerB — Quota increases require understanding why the customer needs higher limits, evidence of current throttling, and the business impact of the limitation.
Q3: What's the recommended approach for customers making bulk DNS changes instead of requesting higher API limits?
  1. Use larger batch sizes in ChangeResourceRecordSets (up to 1000 changes per batch)
  2. Create multiple hosted zones
  3. Use a different AWS account
  4. Switch to a third-party DNS provider
Show AnswerA — ChangeResourceRecordSets supports up to 1000 changes per API call. Batching changes reduces the number of API calls needed and is more efficient than individual requests.
📅 Day 36: Resolver Query Logging
Q1: A customer hits "max-resolver-query-log-configs" limit of 20. What is this quota?
  1. Maximum DNS queries per second
  2. Maximum number of Route 53 Resolver query logging configurations per account per region
  3. Maximum log retention days
  4. Maximum VPCs per logging config
Show AnswerB — This is the account-level limit on how many Resolver query logging configurations can exist in a single region. Default is 20.
Q2: The customer manages many EKS stacks, each provisioning its own ResolverQueryLogConfig via Terraform. What's a better architecture?
  1. Request unlimited quota increase
  2. Share a single query logging configuration across multiple VPCs instead of creating one per stack
  3. Disable query logging
  4. Use CloudWatch Logs directly
Show AnswerB — A single ResolverQueryLogConfig can be associated with multiple VPCs. Sharing configs across stacks is more efficient than creating one per stack.
Q3: What error does the customer see when exceeding this quota?
  1. AccessDeniedException
  2. LimitExceededException: Account has exceeded 'max-resolver-query-log-configs'
  3. ThrottlingException
  4. ValidationException
Show AnswerB — The error explicitly states LimitExceededException with the quota name, making it clear which limit was hit.
📅 Day 37: Unwanted Health Checks
Q1: A customer reports seeing Route 53 health check requests hitting their server but they never configured any. The User-Agent shows "Amazon-Route53-Health-Check-Service." What happened?
  1. AWS is monitoring all domains automatically
  2. Someone (possibly in a different AWS account) created a health check pointing to their server's IP
  3. It's a DDoS attack spoofing the User-Agent
  4. Route 53 health checks are enabled by default
Show AnswerB — Anyone can create a Route 53 health check pointing to any IP address. The customer's server is being checked by a health check in someone else's account.
Q2: The health check requests come from IPs in the 15.177.x.x range. How can the customer verify these are legitimate Route 53 health checkers?
  1. They can't verify this
  2. Check against the published Route 53 health checker IP ranges in the AWS IP ranges JSON file
  3. Do a reverse DNS lookup
  4. Contact AWS support
Show AnswerB — AWS publishes all Route 53 health checker IP ranges in the public ip-ranges.json file. Customers can verify the source IPs against this list.
Q3: What can the customer do to stop unwanted health check traffic?
  1. Block the Route 53 health checker IPs at their firewall
  2. Report it via the URL in the User-Agent (http://amzn.to/1vsZADi) which links to the abuse form
  3. Both A and B are valid options
  4. Nothing — they must accept the traffic
Show AnswerC — They can block the IPs if they don't use Route 53 health checks themselves, AND report the unwanted health check via the abuse reporting URL included in the User-Agent string.
📅 Day 38: DNS Resolution Intermittent Failures
Q1: Some EC2 instances in a specific AZ get SERVFAIL for a domain while instances in other AZs resolve fine. The domain is external (not hosted in Route 53). What could cause this?
  1. Security group blocking DNS in that AZ
  2. Per-ENI DNS query rate limiting (1024 pps to the VPC resolver) or AZ-specific resolver shard issue
  3. The domain's nameserver is in the same AZ
  4. Route table misconfiguration
Show AnswerB — The VPC .2 resolver has per-ENI packet-per-second limits. High-traffic instances can hit this limit. Also, resolver infrastructure is sharded by AZ, so issues can be AZ-specific.
Q2: A customer sees ~1.5 second DNS latency for specific queries while other clients in the same VPC get 1ms responses. Packet captures show no retransmits. What's the likely cause?
  1. Network congestion
  2. The instance's ENI hit the DNS PPS limit, causing queries to be queued and released in a batch
  3. The domain's nameserver is slow
  4. TCP fallback for large responses
Show AnswerB — When an ENI exceeds the 1024 pps DNS limit, queries are held and released in a burst once the rate window clears, causing consistent ~1.5s delays with no retransmits.
Q3: How can a customer mitigate DNS PPS throttling on high-traffic instances?
  1. Use a larger instance type (higher PPS limits)
  2. Implement local DNS caching (e.g., dnsmasq, systemd-resolved) to reduce queries to the VPC resolver
  3. Both A and B
  4. Request a PPS limit increase from AWS
Show AnswerC — Larger instances have higher network limits, and local DNS caching reduces the number of queries hitting the VPC resolver, both helping to stay under PPS limits.
📅 Day 39: Domain Registration Failures
Q1: A .au domain registration is stuck in "PENDING" state at the registrar for 14 days. What's the typical cause?
  1. AWS processing delay
  2. The .au registry (auDA) requires additional verification (eligibility, ABN/ACN validation) that hasn't completed
  3. Payment processing issue
  4. The domain is premium-priced
Show AnswerB — Australian (.au) domains require eligibility verification including valid ABN/ACN numbers and matching registrant details. Mismatches cause the registration to stay pending.
Q2: A domain registration fails with error: "Required parameter missing: registernumber." What does this mean?
  1. The AWS account number is wrong
  2. The TLD registry requires a specific identification number (e.g., trademark number, business registration) that wasn't provided
  3. The hosted zone ID is missing
  4. The nameserver count is wrong
Show AnswerB — Some TLDs (like .fi) require specific registrant identification numbers. The error means a required registry-specific field was not populated during registration.
Q3: A customer's domain shows "Reachability: PENDING" in internal tools. What is this and why does it matter?
  1. It's checking if the nameservers are reachable
  2. ICANN requires registrant email verification — PENDING means the email hasn't been confirmed, which can lead to clientHold
  3. It's checking DNS propagation
  4. It's verifying DNSSEC configuration
Show AnswerB — ICANN's WHOIS accuracy program requires registrant email verification. If not completed, the domain can be placed on clientHold, making it unreachable.
📅 Day 40: NLB Traffic Imbalance & DNS
Q1: During a deployment, NLB traffic splits 64%/36% between two cells despite identical healthy target counts. This is consistent across ALL callers. What level is the imbalance occurring at?
  1. Client-side connection affinity
  2. NLB-level traffic distribution behavior
  3. DNS round-robin imbalance
  4. Target group health check timing
Show AnswerB — Since the imbalance is consistent across all callers, it's NLB-level behavior rather than client-specific. NLB distribution can be uneven even with equal healthy targets.
Q2: The traffic imbalance causes per-host TPS to exceed rated capacity (3,649 vs 3,500 limit), triggering auto-rollback. What's the operational impact?
  1. Minor — just retry the deployment
  2. Significant — requires ~709 extra hosts across regions to handle worst-case cell imbalances
  3. None — auto-rollback protects the service
  4. Only affects the specific deployment
Show AnswerB — If NLB imbalance is unpredictable, teams must over-provision to handle worst-case scenarios, significantly increasing infrastructure costs across all regions.
Q3: What DNS-level solution could provide more deterministic traffic distribution across NLBs?
  1. Lower the DNS TTL
  2. Use weighted round-robin DNS records across multiple NLBs instead of a single 100%-weight record
  3. Enable DNSSEC
  4. Use geolocation routing
Show AnswerB — Weighted round-robin across multiple NLBs gives DNS-level control over traffic distribution, providing more predictable splitting than relying on a single NLB's internal distribution.