CCNA Continuous Improvement Questions

Options A, C, and D are correct. A: Lambda Provisioned Concurrency reduces cold starts for predictable traffic, improving performance. C: Using DAX reduces read latency and can lower DynamoDB read costs by offloading reads from the table.

D: API Gateway caching reduces the number of requests to Lambda and DynamoDB, improving response times and reducing costs. Option B is incorrect because DynamoDB on-demand capacity mode is typically more expensive for predictable workloads compared to provisioned capacity. Option E is incorrect because increasing the Lambda function timeout does not improve performance and may increase costs due to longer execution time.

(Enable connection draining on the ALB) allows in-flight requests to complete before instances are deregistered or replaced, ensuring no disruption during scaling events. Option D (Add read replicas to the ElastiCache Redis cluster) offloads read traffic from the primary Redis node, reducing latency for session reads. Option E (Add more EC2 instances to the Auto Scaling group) horizontally scales the application, distributing load and improving response times during peak hours.

Option B (Decrease the idle timeout of the ALB) would prematurely close connections, not improve performance. Option C (Increase the EC2 instance size) is vertical scaling, which could cause downtime unless done with rolling replacement, and is not the best approach for handling increased load with zero downtime.

Using a launch template with a pre-provisioned AMI reduces instance startup time, allowing new instances to become healthy faster during traffic spikes. Option E is correct because a scheduled scaling policy can add instances before expected traffic spikes, proactively handling the load. Option A is incorrect because increasing the cooldown period would delay additional scaling actions, worsening responsiveness.

Option B is incorrect because reducing the health check interval does not speed up instance initialization; it only checks health more frequently. Option C is incorrect because decreasing the health check grace period may cause instances to be terminated prematurely before they have a chance to become healthy.

The Amazon CloudWatch agent can be installed on the EC2 instance without modifying the application code. It tails the local log file and sends the logs to Amazon CloudWatch Logs for centralized monitoring. Option A is incorrect because Amazon Kinesis Agent streaming to Kinesis Data Firehose adds unnecessary complexity for simple log ingestion.

Option C is incorrect because it requires modifying the application code. Option D is incorrect because AWS CloudTrail captures API activity, not application logs. Option E is incorrect because it requires modifying the application code to write to Amazon S3.

Amazon EFS is a regional, fully managed file system that automatically replicates data across multiple Availability Zones, providing high availability and durability. This ensures no data loss during a single AZ failure. Option A is incorrect because periodic snapshots introduce a recovery point objective (RPO) that may result in data loss.

Option C is incorrect because EBS volumes are tied to a single AZ and cannot be attached to instances in another AZ. Option D is incorrect because EBS multi-attach volumes only allow attachment within the same AZ, not across different AZs, thus cannot provide cross-AZ high availability.

Correct answers are B and C. Blue/green deployments (B) reduce risk by allowing instant rollback and minimizing downtime during production releases. CI/CD pipelines with automated testing (C) increase deployment frequency by automating build, test, and deployment steps, enabling rapid and reliable releases.

Option A is incorrect because deploying all microservices from a single codebase increases coupling and blast radius. Option D is incorrect because manual approval gates slow down frequency. Option E is incorrect because feature branches with manual merge approvals introduce delays and integration complexity.

AWS CodePipeline natively supports sending notifications to Amazon SNS topics when pipeline state changes occur, such as failure. This is the most direct and efficient method without requiring additional services. Option B is incorrect because while the build script could use the AWS CLI to send a notification, this would require modifying the build script and does not leverage CodePipeline's built-in notification capability.

Option C is incorrect because although a CloudWatch Events (EventBridge) rule can trigger a Lambda function to send email via SES, this approach is more complex and less efficient than using SNS directly from CodePipeline. Option D is incorrect because CloudWatch alarms are designed for metric-based thresholds, not for pipeline state changes; CodePipeline events are better handled via SNS or EventBridge.

Creating read replicas offloads read traffic from the primary DB instance, reducing CPU utilization and read IOPS during peak hours. This improves performance without requiring application changes. Option B (larger instance type) may help but could involve downtime and does not address the read-heavy nature as effectively.

Option C (Performance Insights) provides monitoring but does not directly improve performance. Option D (Multi-AZ cluster with readable standbys) is for high availability and read scaling, but the two readable standbys may not be as cost-effective as dedicated read replicas, and converting to a cluster may require application changes or downtime.

The simplest way to notify when a specific error message appears in CloudWatch Logs is to create a metric filter on the log group for the error message, then set up a CloudWatch alarm on that metric. This is native, requires no custom code, and provides real-time alerting. Option A is incorrect because S3 event notifications apply to S3 objects, not CloudWatch Logs content.

Option B is incorrect because subscribing a Lambda function is more complex than using a metric filter and alarm. Option D is incorrect because CloudWatch Logs Insights queries are not real-time and require manual or scheduled execution.

Migrating to Amazon Aurora (A) improves write performance because Aurora uses a distributed storage subsystem with better throughput and lower latency than standard RDS for MySQL. Changing the storage type to Provisioned IOPS (D) guarantees consistent low-latency I/O, directly improving write performance. Increasing allocated storage (E) increases the baseline IOPS for gp2 volumes, which can reduce write latency under high load.

Option B (read replica) offloads read traffic but does not help write performance. Option C (Multi-AZ) provides high availability but does not improve write performance.

A strangler fig pattern allows incremental migration of functionality from the monolith to microservices, with the ALB routing traffic to either the monolith or new services. This minimizes downtime because the old application remains operational while pieces are moved. Option A is wrong because a lift-and-shift of the entire application into a single container does not decompose it into microservices.

Option C is wrong because running both the monolith and new services on the same instance but on different ports does not inherently minimize downtime and complicates routing. Option D is wrong because refactoring the entire application at once introduces significant risk and downtime.

Use Systems Manager Inventory to query patch compliance details and identify non-compliant instances. This is the most efficient approach because Systems Manager Inventory provides a centralized view of patch compliance across all managed instances, allowing you to quickly identify which instances are non-compliant and investigate the reasons for patch failures. Option A is inefficient because it requires running scripts manually on each instance.

Option C is incorrect because the Patch Manager dashboard (if available) may not provide detailed failure reasons. Option D is inefficient and does not directly address compliance failure causes.

Amazon EventBridge can be configured with a rule that matches the 'CreateAccessKey' API call from CloudTrail and sends an SNS notification to alert the security team. Option A is incorrect because S3 event notifications are triggered by object-level operations (e.g., object created/deleted) in the S3 bucket, not by API calls logged by CloudTrail. Option B is incorrect because enabling log file validation on a CloudTrail trail only ensures the integrity of log files, it does not generate alerts.

Option C is incorrect because AWS Config rules evaluate the configuration state of AWS resources (e.g., whether an IAM user has a key older than 90 days), not real-time API calls.

Using an EC2 Auto Scaling group with a launch template that dynamically references the latest AMI ID from AWS Systems Manager Parameter Store ensures that new instances automatically use the most recent AMI without manual intervention. Option A is incorrect because launch configurations are immutable and cannot reference dynamic parameters like SSM Parameter Store; they require creating a new launch configuration each time the AMI changes. Option B is incorrect because CloudFormation updates require manual initiation and do not automatically track the latest AMI.

Option C is incorrect because manually updating the AMI ID in the Auto Scaling group configuration is error-prone and not automated.

The bucket policy can explicitly deny access even if the IAM role attached to the pipeline allows s3:PutObject. Since both policies are evaluated, an explicit deny in the bucket policy overrides any allow. Option A is incorrect because default encryption does not affect IAM permissions.

Option B is incorrect because the pipeline uses the service role, not Git credentials; that would affect source stage authentication, not S3 write access. Option C is incorrect because S3 VPC endpoints are for private connectivity, not required for public S3 access via the internet, and an Access Denied error points to a permissions issue, not a network issue.

Options B and D are correct. Decreasing cooldown periods (option B) allows scaling to happen more frequently, reducing lag during traffic spikes. Increasing the maximum number of tasks (option D) ensures the service can scale out to a higher capacity to handle increased load.

Option A is incorrect because decreasing subnets does not improve scalability and reduces fault tolerance. Option C is incorrect because decreasing the ALB idle timeout does not directly affect scaling behavior; it only affects connection persistence. Option E is incorrect because increasing the target value for the scaling metric (e.g., CPU utilization) makes the scaling threshold harder to reach, reducing scaling aggressiveness.

The correct action would be to decrease the target value.

Options B and E are correct. Option B: Amazon RDS with Multi-AZ deployment provides high availability through automatic failover to a standby instance and automated backups. Option E: Amazon Aurora is a relational database engine compatible with MySQL and PostgreSQL, offering built-in high availability, automated backups, and fault tolerance.

Option A is incorrect because Amazon Redshift is a data warehouse, not a relational database for transactional workloads. Option C is incorrect because Amazon ElastiCache is an in-memory caching service, not a relational database. Option D is incorrect because Amazon DynamoDB is a NoSQL database, not relational.

Implementing a Read Replica allows offloading read traffic from the primary DB instance. This reduces the load on the primary, potentially enabling the use of a smaller instance size or lowering provisioned IOPS, thereby reducing costs without affecting performance for the read-intensive application. Option A is incorrect because Multi-AZ deployment adds a standby instance and synchronous replication, increasing costs without direct performance benefit.

Option B is incorrect; upgrading to the latest generation instance type may improve performance but generally does not reduce costs. Option D is incorrect; purchasing Reserved Instances provides a discount on hourly rates but does not address the utilization or instance size, so it does not directly reduce costs based on workload.

When tasks fail health checks and are stopped, their logs are sent to CloudWatch Logs (if configured). Viewing the stopped task logs reveals application errors that caused the health check failure. Option B is incorrect because misconfigured environment variables would likely affect the old running tasks as well; the issue is specific to new tasks, so the task definition is probably fine.

Option C is incorrect because the ECS service event stream shows deployment events (like rollback triggers) but not the detailed error logs of the failing tasks. Option D is incorrect because ECS Exec requires the task to be running; since the tasks are failing health checks and stopping, ECS Exec cannot connect to them.

The 'ResourceNotFoundException' error indicates that the DynamoDB table does not exist in the account and region where the Lambda function is running. The most common cause is a misspelled table name in the Lambda code (Option D). Cross-account permission issues (Option C) typically result in an 'AccessDeniedException' rather than 'ResourceNotFoundException', because the resource does exist but access is denied.

Option A is incorrect because Lambda uses temporary credentials from its execution role, and credential issues would cause authentication errors. Option B is incorrect because DynamoDB is accessible over the public internet or via a VPC endpoint; lack of a VPC endpoint would cause a timeout, not a resource-not-found error.

Using Lambda@Edge to route users based on their geographic location can direct European users to a closer CloudFront distribution or origin, reducing latency. This approach is cost-effective as it avoids the need for additional infrastructure. Option B is incorrect because S3 Transfer Acceleration is designed for uploads, not for accelerating content delivery to end users.

Option C is incorrect because geographic restrictions are for access control, not routing; they cannot route users to the nearest origin. Option D is incorrect because additional cache behaviors control caching policies, not which origin serves content; they do not inherently reduce latency.

Using Amazon S3 for temporary data storage improves durability because S3 offers 99.999999999% durability, far exceeding the durability of a single EBS volume or instance store. It is cost-effective as you pay only for the storage used, with no upfront investment or additional volume costs. Although S3 is object storage, it is suitable for temporary data that does not require block-level access.

Option A is incorrect because increasing IOPS does not improve durability. Option C is incorrect because adding EBS volumes and RAID 1 mirroring increases costs significantly due to additional volume charges. Option D is incorrect because moving to instance store reduces durability, as instance store is ephemeral and data is lost on instance stop/termination.

Moving session state to Amazon ElastiCache makes the application stateless, allowing EC2 instances to be added or removed without session loss, which improves both availability and scalability. Option B (Auto Scaling alone) is wrong because without external session storage, scaling out will cause new instances to lack existing session data, and terminating instances will lose sessions. Option C (sticky sessions) is wrong because it only routes a user to the same instance, but if that instance fails, the session is lost.

Option D (larger instances) is wrong because it does not address scalability; it only increases capacity of individual instances, but does not allow for horizontal scaling or improve availability beyond a single instance.

On-demand DynamoDB tables can handle traffic spikes up to double the previous peak. If write traffic exceeds that threshold, throttling occurs. The table's burst capacity is limited to the previous peak for on-demand, so a sudden spike exceeding that will cause throttling.

Option B is incorrect because DAX is a caching layer for reads, not writes, and does not affect write throughput. Option C is incorrect because the table is using on-demand capacity, not provisioned; on-demand does not have provisioned write capacity. Option D is incorrect because auto scaling is not applicable for on-demand tables; on-demand automatically scales, but still has a limit based on previous peak.

An Auto Scaling group with a scaling policy based on average CPU utilization dynamically adds or removes EC2 instances to handle load spikes, reducing 503 errors. Option A is wrong because increasing the idle timeout on the ALB does not address high CPU utilization on the instances. Option B is wrong because decreasing the health check interval may cause premature instance replacement without resolving the underlying capacity issue.

Option D is wrong because using larger instance types may help but does not provide dynamic scaling and may be less cost-effective; it does not automatically adjust to fluctuating demand.

The correct answers are B, C, D. Option B: Apply a stack policy to protect critical resources. A stack policy is an IAM resource-based policy that controls which stack resources can be updated or deleted.

By setting a stack policy with a Deny for updates on critical resources, you prevent accidental modification during stack updates, thus reducing downtime risk. Option C: Use a rolling update strategy with an appropriate batch size. When updating an Auto Scaling group or other resources that support rolling updates, you can configure the update policy to update instances in batches.

This minimizes downtime by ensuring that only a portion of the instances are replaced at a time, keeping the application available. Option D: Use Change Sets to preview stack updates. Change sets allow you to review the changes that will be made to your stack before executing them.

This helps identify potential issues or unintended modifications that could cause downtime, giving you a chance to reject the changes. Option A is incorrect because the DeletionPolicy attribute is used to preserve or back up resources when a stack is deleted, not during updates. It does not prevent downtime during updates.

Option E is incorrect because nested stacks help organize resources into reusable components but do not inherently prevent downtime during updates; they are a management and modularity tool, not a downtime prevention strategy.

Using the --disable-rollback flag when rerunning the update prevents the stack from rolling back on failure, allowing the team to describe stack events and investigate the specific error without losing the failed state. Option B is incorrect because deleting the stack would remove the failure logs and prevent investigation. Option C is incorrect because a change set is used to preview updates before execution, not to troubleshoot a failure that has already occurred.

Option D is incorrect because describe-stack-resources only shows resource status (e.g., CREATE_FAILED) but does not provide the detailed error reason; you need stack events to see the specific error message.

Scheduled scaling can proactively add capacity before known peak times, preventing slow response times during traffic spikes. Option A is incorrect because decreasing the CPU utilization threshold would cause the Auto Scaling group to scale out sooner, which could help with responsiveness but may lead to over-provisioning and increased costs; however, it does not address the slow response times during a spike that has already started. Option B is incorrect because increasing the cooldown period delays subsequent scaling actions, making the system less responsive during a spike.

Option D is incorrect because step scaling with a higher step adjustment is still a reactive measure; it does not add capacity before the spike and may cause abrupt scaling that could overshoot.

The most likely cause because during a failover, any pending modifications (e.g., scaling, instance type changes) that were scheduled are applied to the new primary, which can cause a brief performance impact. This is a known behavior in AWS RDS. Option A is incorrect because read replicas in a different region do not affect latency of the primary after failover; Multi-AZ does not use read replicas.

Option B is incorrect because Multi-AZ configuration is not disabled during failover; it remains enabled. Option D is incorrect because DB parameter group changes require a manual reboot, not a failover event.

Options C and E are correct. The error indicates that the IAM role used by CloudFormation to create the EC2 instance lacks the ec2:RunInstances permission. Therefore, updating the IAM role to include this permission (C) and then executing a stack update (E) will resolve the issue.

Option A is incorrect because the instance type is not related to the IAM permissions error. Option B is incorrect because creating a new role is unnecessary; updating the existing role suffices. Option D is incorrect because granting permissions to the user does not affect the CloudFormation service role's permissions.

Exactly-once processing is achieved by using an SQS FIFO queue with content-based deduplication. FIFO queues guarantee that a message is delivered exactly once and consumers receive messages in order. Lambda supports SQS FIFO as an event source, though it has lower throughput limits.

Option A (DynamoDB-based idempotency) also works but adds complexity and cost. Option B (increasing reserved concurrency) only helps with scaling but does not prevent duplicates if a message is processed but the function fails after processing. Option C (increasing visibility timeout) delays reprocessing but does not guarantee exactly-once if the function is throttled or fails.

RDS Proxy is a database proxy that manages connection pooling, reducing the CPU overhead associated with opening and closing many database connections. It requires only a change in the database endpoint configuration, not application code changes, making it the most effective solution that satisfies the requirement of no code changes. Option A (read replica) would require application changes to direct read traffic to the replica.

Option B (upgrading instance type) vertically scales the database but does not reduce the load; it only provides more capacity to handle the same load. Option C (ElastiCache for Redis) reduces database read load by caching frequent queries, but implementing it typically requires application code modifications to integrate the caching logic, which conflicts with the stem's requirement.

Amazon SQS can buffer write requests to DynamoDB, smoothing out traffic spikes and reducing throttling on hot partitions. The SQS queue decouples the application from DynamoDB, allowing writes to be processed at a manageable pace. Option A is incorrect because adding a GSI does not reduce write load on the base table's partitions.

Option B is incorrect because DAX is a read cache and does not help with write throttling. Option C is incorrect because switching to provisioned capacity does not resolve per-partition throttling limits; hot partitions still have a maximum throughput regardless of table-level capacity.

(rolling update with a batch size of 50% and pause time) is correct because it gradually replaces instances, allowing the application to remain available during patching. Option D (lifecycle hook for custom action before termination) is correct because it can drain connections gracefully before an instance is terminated. Option A is wrong because increasing desired capacity does not guarantee no dropped requests during patching and may cause additional cost.

Option B is wrong because stopping all instances simultaneously causes downtime. Option E is wrong because Amazon Inspector only identifies vulnerabilities but does not apply patches.

A NAT Gateway in a public subnet enables instances in a private subnet to initiate outbound internet traffic for tasks like downloading patches, while preventing inbound connections from the internet. Option A is incorrect because a VPC endpoint is used for private connectivity to AWS services, not for general internet access. Option B is incorrect because a NAT instance is less managed and secure than a NAT Gateway, and it must be placed in a public subnet.

Option C is incorrect because an Internet Gateway is attached to the VPC, not directly to a subnet, and attaching it to a private subnet would not function correctly and could expose the instance to inbound traffic.

AWS X-Ray provides end-to-end tracing of requests from the ALB to the EC2 instances and downstream services, allowing the team to identify the specific component causing latency spikes. Option A is wrong because detailed ALB metrics only provide aggregate data, not per-request traces. Option B is wrong because migrating to Lambda would not necessarily resolve latency and adds significant architectural change.

Option C is wrong because a Network Load Balancer operates at Layer 4 and does not provide application-level tracing or visibility. Option E is wrong because while adding instances might reduce load, it does not help identify the root cause of intermittent latency spikes.

Implementing an in-memory cache like Amazon ElastiCache can offload frequent read queries from the database, reducing CPU utilization and the number of connections. This can be achieved with minimal code changes if the application uses caching libraries or can be configured to use a caching layer for session data or frequently accessed data. Option A is incorrect: increasing the RDS instance size might temporarily alleviate CPU pressure but does not reduce the number of connections and is not a scalable solution; it also requires downtime for resizing.

Option B is incorrect: creating an RDS read replica offloads read traffic but does not reduce write load or the connection count on the primary instance; session data typically involves both reads and writes, so a read replica would not significantly help with the primary's CPU or connection limit. Option D is incorrect: migrating to Amazon Aurora Multi-AZ provides better performance and high availability, but the migration process is not minimal and does not directly reduce the load on the database; it also does not address the connection limit issue.

To achieve message ordering and exactly-once processing with Lambda and SQS, you must use a FIFO queue (option B) because FIFO queues preserve the order of messages. Additionally, enable the queue's content-based deduplication or provide a deduplication ID (option E) to prevent duplicate messages from being processed. Finally, set the Lambda function's reserved concurrency to 1 (option D) to ensure that only one instance of the function processes messages at a time, maintaining the order.

Option A (batch window 0) is incorrect because it would cause Lambda to wait longer, but does not help with ordering. Option C (standard queue) does not guarantee ordering or deduplication.