CCNA Monitoring and Troubleshooting Questions

Amazon RDS Performance Insights provides detailed database performance metrics and helps identify the specific queries contributing to high CPU utilization, enabling targeted optimization. Option A is incorrect because increasing instance size is a reactive scaling action rather than a diagnostic step; it does not identify the root cause. Option C is incorrect because Multi-AZ deployment is designed for high availability and failover, not for distributing load or improving performance.

Option D is incorrect because disabling slow query logging removes valuable diagnostic information that could help identify problematic queries.

Enabling Performance Insights for Amazon DocumentDB allows you to monitor the database load and review top wait events, which helps identify the specific causes of high write latency, such as lock contention or I/O bottlenecks. Option A is wrong because simply upgrading to a larger instance size addresses symptoms but does not identify the root cause. Option C is wrong because adding a replica does not reduce write latency on the primary instance; it only offloads read traffic.

Option D is wrong because changing to Provisioned IOPS may improve I/O performance but does not diagnose the underlying issue causing latency.

DAX uses a write-through cache, meaning that items are cached only when they are read. When an item is updated in DynamoDB, the cached copy is not automatically invalidated; instead, it remains in the cache until the TTL expires. If the TTL is set too long (e.g., 5 minutes) and the item is updated frequently, stale data will be served from the cache until the TTL forces its removal.

Option A is incorrect because cache misses would cause slower reads, not stale reads. Option B is incorrect because DAX always uses eventual consistency for reads, but stale data occurs here due to TTL, not consistency level. Option C is incorrect because DAX clusters are deployed in a single VPC and can be accessed from any AZ with proper routing; AZ placement does not cause staleness.

Auto scaling adjusts capacity based on workload, but it can lag behind sudden traffic spikes, causing write throttling. Increasing the minimum provisioned capacity ensures a baseline capacity that can accommodate predictable bursts, reducing throttling. Option A (increase min capacity) is correct.

Option B (disable auto scaling and set fixed capacity) would remove the benefit of dynamic scaling and may not handle varying loads. Option C (decrease max capacity) would limit the table's ability to scale up, potentially worsening throttling. Option D (switch to on-demand) could eliminate throttling but at higher cost, and the question asks for a resolution while keeping auto scaling enabled.

A low FreeableMemory metric consistently below 200 MB indicates memory pressure on the RDS for SQL Server DB instance. The most effective mitigation is to scale up to a larger instance class with more memory, directly addressing the resource shortage. Option D is correct because it increases available memory.

Option B is incorrect because disabling SQL Server Agent and error logging does not free significant memory and may disrupt essential operations. Option A is incorrect because changing the maintenance window does not affect memory usage. Option C is incorrect because enabling backups with a shorter retention period does not impact memory.

Native backups in RDS for SQL Server are stored in the instance's attached storage. When the allocated storage is full, the backup fails due to insufficient disk space. Increasing the allocated storage provides additional space for the backup file.

Option A is incorrect because changing to Provisioned IOPS affects performance, not storage capacity. Option C is incorrect because the error is about disk space, not permissions. Option D is incorrect because switching to automated backups would not resolve the immediate failure of the native backup process, and the question specifically addresses native backup failure.

Options B and C are correct. Increasing provisioned write capacity (B) directly addresses throttling by allowing more writes per second. Enabling DynamoDB auto scaling with adaptive capacity (C) automatically adjusts capacity based on traffic and helps handle uneven access patterns, including hot partitions.

Option A (adding a global secondary index with a different partition key) does not reduce throttling on the base table; it only provides an alternative query path. Option D (DAX) is a read cache and does not assist with write throttling. Option E (write sharding) can help distribute writes across partitions, but the question asks for two actions from the given list; B and C are the most direct and effective.

High ReadIOPS on the read replica can indicate heavy read activity, which may cause replication lag as the replica struggles to apply changes fast enough. Option D is correct because ReplicaLag directly measures the time delay between the primary and replica, confirming the presence of lag. Option A is incorrect because WriteIOPS on the primary reflects write workload, not lag cause.

Option C is incorrect because DatabaseConnections do not directly affect replication lag. Option E is incorrect because NetworkThroughput is not a metric that directly indicates replication lag; it could be a factor but is not a standard RDS metric for diagnosing lag.

The IAM policy includes 'cloudwatch:GetMetricStatistics' and 'cloudwatch:ListMetrics', which should allow retrieving metric data via API. However, the AWS Management Console for CloudWatch Metrics also requires 'cloudwatch:DescribeAlarms' to display alarm overlays on the metrics graph. Without this action, the console may fail to load the metrics page entirely.

Option A is correct because the missing permission is 'cloudwatch:DescribeAlarms'. Option B is incorrect because 'rds:DescribeDBInstances' is not needed to view metrics; the policy already includes it. Option C is incorrect because using a Resource of '*' is allowed for CloudWatch actions; it does not prevent viewing metrics.

Option D is incorrect because 'cloudwatch:GetMetricStatistics' is already present in the policy.

The cache hit ratio is calculated as CacheHits / (CacheHits + CacheMisses). Monitoring the 'CacheHits' and 'CacheMisses' CloudWatch metrics allows the specialist to compute the hit ratio and confirm whether it has decreased, which would explain increased latency. Option A is incorrect because CurrConnections shows the number of connections, not the cache hit ratio.

Option B is incorrect because Evictions indicates keys being evicted, which can affect the cache but does not directly measure the hit ratio. Option D is incorrect because ReplicationLag measures replication delay, not cache performance.

Enabling eviction with the volatile-LRU policy automatically removes the least recently used keys that have a TTL set, freeing memory without manual intervention. Option B (scaling up) reduces memory pressure but at higher cost; it is not the most effective change since eviction addresses the root cause by discarding stale data. Option C (AOF persistence) writes data to disk, not freeing memory; it can actually increase memory usage during writes.

Option D (disabling replication) may free some memory used for replica buffers but does not address the high memory utilization caused by cached data, and it impacts availability.

DAX acts as an in-memory cache for DynamoDB, reducing the number of read requests that consume provisioned throughput, thus mitigating throttling without increasing capacity. Option B is correct because adaptive capacity enables DynamoDB to automatically use unused throughput from other partitions to absorb traffic spikes, reducing ProvisionedThroughputExceededException errors. Option C is wrong because while eventually consistent reads consume half the read capacity, the application uses strong consistent reads, which may be required for data consistency, and this switch may not be acceptable.

Option D is wrong because disabling auto scaling and manually setting higher capacity would lead to over-provisioning and increased cost, contrary to the goal of mitigating throttling without over-provisioning. Option E is wrong because burst capacity is limited and not guaranteed; it can handle short spikes but is not a reliable mitigation for sudden spikes.

To troubleshoot an unresponsive Amazon RDS for PostgreSQL instance, the standard initial steps are: C) Verify that the security group allows inbound traffic on the database port – connectivity issues are a common cause of unresponsiveness. D) Check the database error logs in CloudWatch Logs – logs may reveal database-specific errors like out-of-memory or corruption. E) Review CloudWatch metrics for CPU, memory, and disk I/O – high utilization can indicate resource exhaustion.

Option A (reboot immediately) is wrong because it may destroy diagnostic evidence. Option B (modify instance class) is premature without first assessing the problem.

Increasing the instance size of the read replica provides more CPU and memory resources, allowing it to apply changes from the binary log faster, thereby reducing replica lag. Option A is incorrect because increasing 'max_connections' on the primary does not affect the replica's ability to apply changes; it only allows more connections to the primary. Option C is incorrect because disabling binary logging on the primary would break replication entirely, as the replica relies on the binary log to receive changes.

Option D is incorrect because converting the primary to Multi-AZ improves availability and failover but does not directly reduce replication lag on the read replica.

The correct metric is 'FreeStorageSpace' which is reported in bytes by CloudWatch for Amazon RDS. 50 GB equals 50 × 1024³ = 53,687,091,200 bytes. Therefore, setting a threshold of 53687091200 bytes triggers the alarm when free space drops below 50 GB. Option A is incorrect because 'FreeStorageSpace' is not available in percent; you must use bytes.

Option B is incorrect because 'DiskSpaceUtilization' is not a standard CloudWatch metric for RDS (it is used for EC2). Option D is incorrect because although 'FreeStorageSpace' is the right metric, the threshold must be specified in bytes, not gigabytes; CloudWatch does not accept a unit other than bytes for this metric.

(ThrottledRequests). ThrottledRequests is a CloudWatch metric that directly indicates the number of requests that were throttled due to exceeding provisioned throughput limits or the instantaneous capacity of on-demand mode. For on-demand capacity, while DynamoDB scales automatically, sudden spikes can still cause throttling.

Examining ThrottledRequests first provides the most direct indication of throttling issues. Option B (SuccessfulRequestLatency) is incorrect because it measures latency of successful requests, not throttling. Option C (ReadThrottleEvents) is incorrect because it only counts throttled read events, whereas ThrottledRequests includes both reads and writes.

Option D (ConsumedWriteCapacityUnits) is incorrect because it shows the amount of write capacity consumed, not throttled requests.

A is correct: Amazon RDS Performance Insights provides a visualization of database performance, including metrics like average active sessions, which helps identify query performance issues. C is correct: Amazon RDS Enhanced Monitoring provides OS-level metrics such as CPU, memory, and disk I/O, which can help correlate with query performance. B is incorrect: AWS Config is a service for configuration audit and compliance, not for real-time performance monitoring.

D is incorrect: VPC Flow Logs capture network traffic metadata and are not specific to query performance. E is incorrect: AWS CloudTrail logs API calls for governance and compliance, not database query performance.

ThrottledRequests is a CloudWatch metric that directly counts the number of requests that were throttled due to exceeding provisioned throughput. For troubleshooting throttling issues, this metric provides immediate visibility into when throttling occurs. ConsumedWriteCapacityUnits (option D) shows capacity usage but does not directly indicate throttling; high consumption may lead to throttling but is not a direct measure.

SuccessfulRequestLatency (option B) measures latency, not throttling, and UserErrors (option C) tracks client-side errors like invalid parameters, not capacity-related throttling.

Scale up to a larger node type, such as cache.m5.large. The current node (cache.t3.micro) is overloaded, as indicated by high CPU utilization (90%) and frequent evictions (100/min). Scaling up provides more CPU and memory resources, reducing evictions and lowering latency.

Option B (add a read replica) does not help because the issue is on the primary node; read replicas are for scaling read-heavy workloads on a primary, but here the primary is overloaded. Option C (enable cluster mode) is not suitable for a single-node setup and adds complexity; it is intended for partitioning data across multiple shards. Option D (decrease TTL) would reduce memory usage but may increase cache misses and does not address the CPU bottleneck; it could actually worsen performance by requiring more database reads.

Reducing write-heavy DML on the primary (Option B) decreases the volume of changes to be replicated, directly reducing lag. Increasing the instance size of the read replica (Option D) provides more CPU and memory resources for applying changes from the binary log. Option A is incorrect because increasing allocated storage does not improve the replica's ability to apply changes; it only increases storage capacity.

Option C is incorrect because enabling Multi-AZ on the primary provides high availability but does not reduce replication lag. Option E is incorrect because binary logging is required for replication; disabling it would break replication.

T3 instances are burstable and use CPU credits. When credits are exhausted, they can use surplus credits, which incur charges. If the workload is consistently high, the instance may run out of credits and become throttled, causing unresponsiveness.

The fix is to switch to T3 unlimited mode (but that incurs charges) or use a non-burstable instance (e.g., M5). Option B is wrong because Enhanced Monitoring provides detailed OS-level metrics but does not prevent CPU credit exhaustion. Option C is wrong because increasing allocated storage does not affect CPU credits; it improves I/O performance.

Option D is wrong because enabling Multi-AZ provides high availability and failover but does not resolve CPU credit issues.

(ACUUtilization) is correct because high ACU utilization can indicate resource exhaustion (CPU/memory pressure) that may trigger a failover in Aurora. Option D (DatabaseConnections) is correct because a sudden spike or drop in connections could signal issues like connection exhaustion or application failures that lead to failover. Option E (FailoverCount) is correct because this metric directly tracks the number of failover events; examining the timestamp of the last increment helps correlate with the incident.

Option B (ReadLatency) is wrong because while high read latency can be a symptom, it is not a direct cause of failover; Aurora uses different mechanisms for read scaling. Option C (BinLogDiskUsage) is wrong because it relates to binary log storage for replication, not a direct trigger for failover.

The DatabaseConnections metric in Amazon CloudWatch tracks the number of active database connections. During a Multi-AZ failover, existing connections are dropped and new connections are blocked until the standby becomes the primary. By monitoring the time period when DatabaseConnections drops to zero or a low value, you can estimate the failover duration.

Options A (FailoverTime) is not a valid CloudWatch metric for RDS; the actual metric is 'Failover' which is a count, not a duration. WriteLatency may increase during failover but does not directly measure downtime. ReplicaLag applies to read replicas, not Multi-AZ failover.

Intermittent write latency spikes with high WriteIOPS and normal CPU utilization indicate storage performance issues. For RDS MySQL using gp2 or io1 storage, exceeding the provisioned IOPS burst balance (for gp2) or provisioned IOPS (for io1) causes throttling and increased latency. Option A is incorrect because parameter group changes require a reboot and affect all operations, not just intermittent writes.

Option C is incorrect because read replicas are read-only and cannot be used for write operations. Option D is incorrect because Multi-AZ replication uses synchronous standby replication, which typically does not cause noticeable write latency spikes; latency from replication is usually minimal.

High ReadLatency indicates that read operations are taking longer than expected. This is most directly caused by insufficient I/O throughput, i.e., not enough provisioned IOPS for the workload. When the database requests more IOPS than are provisioned, I/O operations queue up, increasing latency.

Option D is correct because insufficient provisioned IOPS is a primary cause of increased ReadLatency. Option A is incorrect: high CPU utilization can affect overall performance but does not directly cause read latency unless it leads to I/O contention. Option B is incorrect: running out of memory can cause disk swapping, which may increase latency, but it is less direct than I/O throttling.

Option C is incorrect: burstable instance classes (like T-series) use CPU credits; exhaustion affects CPU performance, not storage I/O latency.

Scaling up the DB instance to db.r5.xlarge provides more compute capacity, directly addressing high CPU utilization. Additionally, reviewing slow query logs helps identify and optimize inefficient queries that may be causing CPU spikes. Option A is incorrect because increasing storage does not improve CPU performance; it only addresses storage capacity or I/O issues.

Option C is incorrect because enabling Multi-AZ provides high availability but does not increase compute capacity, and increasing storage does not help with CPU. Option D is incorrect because Performance Insights helps diagnose performance issues but does not resolve them, and CloudWatch alarms only provide notifications without fixing the underlying problem.

Replica lag in Amazon DocumentDB occurs when readers are unable to apply writes from the writer's oplog quickly enough. Increasing the instance size of the readers provides more CPU and memory resources, improving their apply throughput and reducing lag without affecting the writer's batch performance. Option A is incorrect because changing the storage type to Provisioned IOPS may improve I/O but does not directly address the reader's apply capacity.

Option C is incorrect because reducing batch size would lower the write rate and degrade batch performance, which the team wants to avoid. Option D is incorrect because increasing the writer's instance size may help the writer handle more writes, but it does not help readers apply those writes faster; it could even increase the write rate and worsen replica lag.

The io1 volume is provisioned at 3000 IOPS, but the workload bursts to 3500 IOPS, causing queue depth to spike. Increasing the provisioned IOPS to 4000 ensures that the volume can handle the peak without queuing. Option A is incorrect because changing to gp3 with 3000 baseline IOPS does not address the peak IOPS requirement; gp3 can burst but the consistent peak above baseline may still cause throttling.

Option B is incorrect because moving the log volume to the same io1 volume would mix I/O streams and could increase contention, not reduce it. Option D is incorrect because enabling Multi-AZ provides high availability and fails over to a standby, but does not increase IOPS capacity or resolve write latency.