CCNA Resilient Cloud Solutions Questions

To ensure resilience to Availability Zone failures, the company should spread tasks across multiple AZs (Option A) so that if one AZ fails, the tasks in other AZs continue to serve traffic. Additionally, enabling Service Auto Scaling (Option B) helps maintain the desired task count across AZs by automatically replacing tasks in failed AZs. Option C is incorrect because a single Network Load Balancer can route traffic across all AZs; placing one per AZ is unnecessary and adds complexity.

Option D is irrelevant since placement groups apply to EC2 instances, not Fargate tasks. Option E is the opposite of resilience—placing all tasks in one AZ creates a single point of failure.

When an ALB is used with Lambda, the ALB invokes a specific Lambda function version or alias. If the deployment updates the Lambda function but the ALB target group alias is not updated atomically, or if connection draining keeps old connections active, some requests may still be routed to the old version. This can cause users to see the old application for several minutes.

Option A is wrong because Lambda versions are immutable, so gradual rollout is not related. Option B is wrong because Lambda@Edge is not used in this setup (the application runs behind an ALB, not CloudFront). Option C is wrong because CloudFront is not mentioned in the architecture—the traffic goes directly from ALB to Lambda.

Switching to a load-balanced, auto-scaled environment with a minimum of 2 instances across 2 Availability Zones improves availability and resilience by distributing traffic and providing failover capacity. Option D is correct because enabling Multi-AZ for RDS provides a standby replica in a different Availability Zone, ensuring automatic failover and high availability for the database. Option E is correct because Amazon RDS Proxy manages database connections efficiently, reducing connection overhead and improving scalability during traffic spikes.

Option A (ElastiCache) is an additional cost that may not be necessary if caching is not a primary concern; the focus should be on core resilience first. Option B (dedicated instances) adds unnecessary cost and does not directly address high availability or resilience.

Reducing the batch size decreases the number of records processed per invocation, lowering the write load on DynamoDB. Note that enabling the parallelization factor per shard increases the number of concurrent invocations per shard, which could actually increase write pressure; therefore, if used, it must be accompanied by sufficient write capacity. Option C is correct because configuring the event source mapping to retry failed records ensures that records are not lost; the Lambda function can retry after throttling errors, supporting exactly-once semantics.

Option E is correct because increasing the DynamoDB table's maximum write capacity auto scaling limit allows the table to scale to higher WCUs during bursts, reducing ProvisionedThroughputExceededExceptions. Option B is incorrect because the error is due to write capacity, not read capacity; increasing RCUs does not help. Option D is incorrect because increasing reserved concurrency would increase the number of concurrent Lambda invocations, potentially increasing writes and worsening throttling.

S3 Standard storage class automatically replicates data across at least three Availability Zones within an AWS Region, ensuring resilience against the loss of an entire AZ. Option B is incorrect because cross-Region replication replicates data to a different AWS Region, which provides geographic resilience but not specifically AZ resilience within the same Region. Option C is incorrect because S3 Versioning helps protect against accidental deletion or overwrite by preserving previous versions, but it does not provide data replication across AZs.

Option D is incorrect because S3 One Zone-IA stores data in a single AZ, which would not withstand the loss of that AZ.

Options C and D are correct. D: Creating an RDS cross-Region read replica in the DR region allows the replica to be promoted to the primary database with minimal data loss, meeting the 15-minute RPO. C: Configuring Amazon Route 53 with health checks and failover routing enables automatic traffic redirection to the DR region within the 1-hour RTO.

Option A is wrong because copying AMIs and RDS snapshots every 15 minutes would require launching EC2 instances and restoring the database from snapshots, which can exceed the 1-hour RTO. Option B is wrong because manually pre-provisioning resources with CloudFormation does not provide the automated failover needed to meet the RTO. Option E is wrong because S3 cross-Region replication does not address the EC2 and RDS components of the application.

Options A and B are correct. A warm standby with RDS Multi-AZ across regions ensures a standby database is ready and can be promoted quickly, meeting the 1-hour RTO. A pilot light with RDS cross-region automated backups provides replication with a 15-minute RPO; a small environment is running, allowing faster failover than a full pilot light.

Option C is wrong because RDS read replicas do not support automatic failover; manual promotion can take longer than 1 hour. Option D is wrong because Multi-AZ in the same region does not protect against region failure. Option E is wrong because hourly snapshots meet RPO but restoring from snapshots typically exceeds the 1-hour RTO.

Deploying the application in a second AWS Region and using Route 53 with failover routing protects against a regional failure by redirecting traffic to the healthy region. Option A is incorrect because placing all instances in a single Availability Zone reduces availability and does not protect against regional failure. Option B is incorrect because EC2 Dedicated Hosts provide dedicated physical servers for licensing or compliance requirements, not regional resilience.

Option C is incorrect because increasing the minimum size of the Auto Scaling group only affects capacity within the current region and does not mitigate a regional outage.

S3 Select allows querying only the necessary data from S3, reducing the amount of data the Lambda function must download and process. This directly addresses the timeout issue by minimizing the data handled, requiring no major architectural changes. Option B is wrong because switching to Node.js does not remove the 15-minute Lambda timeout.

Option C is wrong because increasing memory does not extend the maximum execution time. Option D is wrong because streaming the file does not by itself reduce the total data to process; it only might start processing earlier, but the total processing time still may exceed the timeout.

Setting the deployment minimum healthy percent to 50 and maximum percent to 100 ensures that during a rolling update, at least 50% of the tasks remain healthy, and the deployment will not continue if the new tasks fail health checks, preserving service availability. Option B is incorrect because the circuit breaker can roll back on failure, but 'disable rollback' negates that; it's a misconfigured setting. Option C is not a configuration change for this issue; CodeDeploy is a separate service used for blue/green deployments, not a direct fix for health check failures during rolling updates.

Option D is incorrect because setting minimum healthy percent to 0 and maximum percent to 200 allows all old tasks to be stopped before new ones start, causing downtime if health checks fail, as there are no healthy tasks to serve traffic.

Spreading tasks across multiple Availability Zones ensures that an AZ failure does not impact all tasks, increasing resilience. Option C is correct because using a multi-AZ Amazon RDS or DynamoDB provides persistent data storage that survives AZ failures. Option D is correct because an Application Load Balancer with targets in multiple AZs distributes traffic and can route requests to healthy targets in other AZs if one fails.

Option B is wrong because disabling managed service scaling reduces the application's ability to handle load changes and may impact availability. Option E is wrong because a single service discovery namespace does not provide AZ resilience; it only provides service discovery without redundancy across AZs.

To create cross-region read replicas and promote to master during failover. Cross-region read replicas allow the database to be promoted to a primary instance in another region, enabling database resilience across regions for an active-active architecture. Option A (automated snapshots copied to secondary region) is not suitable because restoring from snapshots is a manual process that takes time and does not support active-active.

Option B is incorrect because RDS does not support synchronous cross-region replication; it only offers asynchronous replication via read replicas. Option D (Multi-AZ) is a single-region high-availability feature and does not address cross-region resilience.

Cross-zone load balancing must be enabled on the ALB so that traffic can be distributed across instances in all AZs. By default, an ALB routes requests only to targets in the same Availability Zone as the requesting client. Enabling cross-zone load balancing allows the ALB to distribute traffic evenly across all registered targets in all enabled AZs, ensuring that if one AZ fails, traffic can be routed to healthy instances in other AZs.

Option B is incorrect because health checks are already enabled by default and do not affect cross-AZ routing. Option C is incorrect because adding more AZs does not change the default AZ-affinity behavior; cross-zone load balancing must be explicitly enabled to utilize multiple AZs for failover.

When a Lambda function is configured to access a VPC, it requires permissions to describe VPC subnets and security groups to create elastic network interfaces. The provided IAM policy only allows ec2:CreateNetworkInterface and ec2:DeleteNetworkInterface, but not ec2:DescribeSubnets or ec2:DescribeSecurityGroups, causing the error. Option B is incorrect because the policy allows dynamodb:PutItem and UpdateItem, so the function can write to DynamoDB.

Option C is incorrect because the policy allows creating network interfaces, so that is not the issue. Option D is incorrect because the error is about describing subnets, not about a DynamoDB resource policy.

Route 53 calculated health checks combine multiple health checks (e.g., 3 fast health checks each checking every 10 seconds) and allow you to set a lower failure threshold (e.g., 2 out of 3) to detect failure faster than a single health check. This reduces failover detection time to under 1 minute by aggregating results. Option B is wrong: additional health checks for the same endpoint would not improve detection time because they would all experience the same delay.

Option C is wrong: the minimum health check interval for Route 53 is 10 seconds (fastest interval is 10 seconds, not 5). Option D is wrong: latency-based routing is for routing based on lowest latency, not for active/passive failover.

Blue/green deployment creates two separate environments (blue and green) and shifts traffic from the old to the new after testing. This minimizes downtime because traffic is switched instantly, and rollback is achieved by reverting traffic to the original environment. Option A (Canary) is a traffic shifting pattern used within blue/green deployments, not a standalone deployment type that offers immediate rollback.

Option B (Linear) is also a traffic shifting pattern for blue/green. Option D (In-place) updates existing instances, causing downtime during deployment and requiring a manual rollback process.

Deploying EC2 instances across multiple Availability Zones (B) ensures that the application remains available even if one AZ fails. Using an Application Load Balancer (E) distributes incoming traffic across these instances and performs health checks, automatically routing traffic away from unhealthy instances. Option A is incorrect because storing session state on an EBS volume attached to each instance tightly couples state to a single instance, making it unavailable if the instance fails; instead, use a shared session store like ElastiCache or DynamoDB.

Option C is incorrect because a single NAT instance is a single point of failure; for high availability, use a NAT Gateway or deploy NAT instances across multiple AZs. Option D is incorrect because instance type selection (M5) does not contribute to high availability; availability is achieved through architectural redundancy, not hardware specifications.

To achieve high availability and fault tolerance for a stateless web application, you should deploy EC2 instances in at least two Availability Zones (C) to eliminate a single point of failure, and use an Auto Scaling group (E) to automatically replace failed instances and maintain desired capacity. Option A is incorrect because a single large instance is a single point of failure and does not provide fault tolerance. Option B is incorrect because multiple Application Load Balancers per AZ are unnecessary; a single ALB can route traffic across multiple AZs.

Option D is incorrect because RDS Multi-AZ is a database feature, not for the web server fleet.

An ECS service configured with a task definition, desired count across multiple Availability Zones, and Service Auto Scaling ensures resilience. The ECS service scheduler automatically restarts failed tasks, and distributing tasks across AZs provides high availability. Option A is wrong because placing all tasks in a single AZ creates a single point of failure.

Option B is wrong because a standalone Fargate task does not have automatic restart; a CloudWatch alarm can restart it but lacks the built-in resilience of an ECS service. Option C is wrong because using a single EC2 instance is a single point of failure and does not provide multi-AZ resilience.

A blue/green deployment strategy in CodeDeploy keeps the old instances running until the new instances pass health checks, preventing the rollback failure due to terminated instances. Option A is incorrect: increasing the health check grace period only delays health checks but does not solve the root cause of unhealthy instances. Option B is incorrect: a manual approval step before deployment does not affect the rollback mechanism.

Option C is incorrect: deploying to a new Auto Scaling group does not inherently keep old instances alive; without blue/green, the old instances would still be terminated during the deployment.

Amazon Route 53 latency-based routing with health checks routes users to the region with the lowest latency and only to healthy endpoints. Option A is wrong because AWS Global Accelerator uses anycast IP to route to the nearest edge location and can distribute traffic across regions, but it does not provide direct latency-based routing to the nearest healthy region; Route 53 is more straightforward for this use case. Option B is wrong because Application Load Balancer cross-zone load balancing only distributes traffic across availability zones within a single region, not across regions.

Option D is wrong because Amazon CloudFront with multiple origins is a content delivery network that caches content at edge locations; it can route to multiple origins, but it is not primarily designed for routing users to the nearest healthy region based on latency—Route 53 provides more precise latency-based routing.

Changing the HealthCheckType to ELB makes the Auto Scaling group use the ALB's health checks, which can be configured with a health check path and threshold to verify that the application is actually responding before marking the instance healthy. Option A is incorrect because step scaling policies only adjust the desired capacity based on CloudWatch alarms; they do not affect how instances are marked healthy. Option B is incorrect because HealthCheckGracePeriod delays the start of health checks but does not ensure the application is ready; it merely postpones the health check decision.

Option C is incorrect because increasing MaxSize does not impact the health check mechanism or readiness verification.

The SQS queue's redrive policy with maxReceiveCount: 3 and a dead-letter queue ensures that after three receive attempts (including those from Lambda's automatic retries), the message is moved to the DLQ. Lambda's integration with SQS does not require configuring retries on the function itself; the event source mapping controls the retries based on the SQS queue's configuration. Option A is wrong because Lambda's retry policy (Maximum retries) applies only to asynchronous invocations, not to SQS-triggered invocations.

Option B is wrong because Lambda functions do not have a DLQ configuration for SQS; the DLQ must be configured on the SQS queue. Option D is wrong because Step Functions add unnecessary complexity when the SQS queue's built-in redrive policy can handle the retry logic directly.

Correct answers: C and D. Deploying resources across multiple Availability Zones (C) ensures high availability by tolerating an AZ failure. Using loosely coupled components like queues (D) improves resilience by decoupling components, preventing cascading failures and allowing independent scaling.

Option A is wrong because running in a single AZ creates a single point of failure. Option B is wrong because storing session data on EC2 instances is not recommended for high availability; session data should be stored externally (e.g., ElastiCache or DynamoDB). Option E is wrong because tightly coupled components increase dependency and reduce fault tolerance.

Increasing the health check interval and increasing the unhealthy threshold makes the health check less sensitive to transient errors, such as occasional 503 responses under heavy load. This prevents unnecessary instance replacements while maintaining availability. Option A is incorrect because implementing a custom Lambda health check that ignores 503 responses would not leverage the built-in ALB health check tuning and adds complexity.

Option B is incorrect because decreasing the unhealthy threshold would make instances more easily marked unhealthy, worsening the problem. Option D is incorrect because decreasing the health check interval increases the frequency of checks, which might cause more frequent detections of transient errors, and decreasing the healthy threshold does not address the issue of avoiding unnecessary replacements.

To implement a global application resilient to an entire AWS Region failure, you need DNS failover, multi-region data replication, and edge caching with origin failover. Amazon Route 53 with health checks and failover routing policy (E) detects region outages and directs traffic to healthy regions. Amazon CloudFront with multiple origins and origin failover (B) provides edge caching and can switch to a secondary origin if the primary fails.

Amazon DynamoDB Global Tables (C) replicates data across regions for multi-region writes and reads. Option A (ALB in primary region) is regional and cannot handle cross-region failover. Option D (RDS Single-AZ) lacks multi-region replication and is not resilient.

Deploying instances in multiple Availability Zones (AZs) ensures that if one AZ fails, instances in other AZs continue to run. Using an Auto Scaling group with multiple AZs automatically distributes instances across AZs and replaces failed instances, further enhancing resilience. Options B and C are both correct because they achieve multi-AZ deployment.

Option A is incorrect because a single AZ is a single point of failure. Option D is incorrect because instance type does not provide AZ resilience. Option E is incorrect because CloudWatch alarms can detect issues but do not distribute instances across AZs.

AWS Database Migration Service (DMS) with ongoing replication continuously replicates database changes to AWS, achieving an RPO of 15 minutes. AWS Backup with cross-Region backup copy automates backups and enables recovery in another Region within 2 hours, meeting the RTO. Together, they satisfy the DR requirements.

Option B (S3 with versioning) is for object storage, not database replication, and cannot achieve the RPO. Option A (Snowball Edge) is for offline data transfer, not real-time replication. Option E (Storage Gateway cached volumes) provides file/volume storage, not database replication.

The Aurora cluster endpoint always points to the current primary instance (writer). After a failover, the cluster endpoint automatically updates to point to the new writer, so the application reconnects without any code changes. Option B is incorrect because the reader endpoint is for read-only queries and does not direct to the writer.

Option C is incorrect because a cross-Region read replica is read-only and cannot become the writer automatically; it does not solve failover resilience. Option D is incorrect because RDS Proxy provides connection pooling and IAM authentication but does not change the underlying endpoint behavior; you would still need to use the cluster endpoint to ensure automatic failover routing.

The correct actions are to enable AWS Backup for daily backups (Option B) and recreate the EFS file system as a Regional (Standard) file system (Option D). AWS Backup provides additional durability and point-in-time recovery, while Regional EFS automatically replicates data across multiple Availability Zones, ensuring availability even if one AZ fails. Option A (increasing throughput) does not address durability.

Option C (copying to S3) is possible but not a primary solution and changes architecture. Option E (mounting from multiple AZs) is only possible with Regional EFS, but with One Zone it's not supported.

Amazon RDS Proxy reduces failover time by pooling and reusing connections, allowing the application to resume quickly after failover without waiting for new connections to be established. Option E is correct because setting the DNS TTL for the RDS endpoint to 1 second ensures that the client DNS cache expires quickly, so the application can reconnect to the new primary IP address promptly after failover. Option A (Performance Insights) is for monitoring, not failover.

Option C (synchronous replication) is already used by Multi-AZ and does not affect failover time. Option D (increasing instance size) improves performance but does not reduce failover duration.

Configuring the ECS service to place tasks in multiple Availability Zones distributes the application across physically separate data centers, so if one AZ fails, the tasks in other AZs continue to run. Option D is correct because implementing a circuit breaker pattern for downstream dependencies prevents cascading failures by detecting faults and failing fast, allowing the system to recover gracefully. Option A is incorrect; using a single subnet for all tasks typically places them in a single Availability Zone, reducing fault tolerance.

Option C is incorrect; increasing task memory reservation helps handle peak load but does not improve resilience against failures. Option E is incorrect; scheduled scaling adjusts capacity based on historical patterns and does not handle unexpected spikes or failures.

To make the application stateless, the company should disable sticky sessions on the ALB (option B) and store session data in Amazon ElastiCache for Redis (option D). Disabling sticky sessions ensures that requests can be routed to any instance, and storing session data externally removes the dependency on in-memory state on individual instances, improving resilience. Option A is incorrect because increasing instance memory does not solve the statefulness issue.

Option C is incorrect because enabling sticky sessions would maintain state on instances. Option E is incorrect because using an NLB does not address session state management.