6.0 Troubleshooting CV0-004 Practice Quiz

• A. A resource limit issue, the database connection pool is exhausted
• B. A compatibility issue, the new application version requires a TLS version that the database server does not support, or vice versa. The application and database have incompatible security protocol configurations
• C. A regional availability issue, the database is in a different region
• D. A misconfiguration, the database hostname is incorrect in the application config

SSL handshake failure indicates a TLS protocol version mismatch, the client and server cannot agree on a common protocol version. This is a compatibility issue between application and database TLS configurations. This is the correct answer.

• A. The server needs a public IP address assigned
• B. A misconfiguration, the security group allows port 80 (HTTP) but not port 443 (HTTPS). Since the application listens on 443 and there is no security group rule permitting inbound traffic on 443, all HTTPS traffic is blocked at the security group level
• C. The application must be configured to listen on port 80 instead of 443
• D. The SSL certificate is invalid, causing connection failures

Security group rules act as stateful firewalls, only explicitly permitted traffic reaches the instance. Port 443 missing from the inbound rules means HTTPS traffic is dropped before reaching the application. This is the correct answer.

• A. Python 3.11 runs slower than Python 3.8 causing timeout failures
• B. The library version in requirements.txt was compatible with Python 3.8 but contains code that is incompatible with Python 3.11, the specific import may have been removed or renamed in newer Python versions, or the library itself has not been updated to support Python 3.11's changes
• C. The cloud provider does not support Python 3.11 functions
• D. The requirements.txt file was not deployed with the updated function

Library compatibility with Python runtime versions is a common deployment issue, libraries pinned to a working version for Python 3.8 may have internal code that breaks with Python 3.11 changes (removed stdlib features, changed C API behavior). This is the correct answer.

• A. The IAM role being attached to EC2 does not have sufficient permissions
• B. The CI/CD pipeline service account's IAM policy is missing the `iam:PassRole` permission, this specific permission is required when an IAM entity (the pipeline) associates an IAM role with a resource (the EC2 instance). Without it, the pipeline cannot assign roles to instances even if it has EC2 creation permissions
• C. EC2 instances cannot have IAM roles attached by automated pipelines
• D. The EC2 instance type does not support IAM role attachment

iam:PassRole is a specific AWS permission required when passing an IAM role to a service. Without it, entities cannot associate roles with EC2 instances, Lambda functions, or other services, even if they have all other required permissions for those services. This is the correct answer.

• A. The Ingress controller needs to be reinstalled after the cluster upgrade
• B. The `extensions/v1beta1` API group for Ingress was removed in Kubernetes 1.22, the manifest uses an outdated API version. The deployment must be updated to use `networking.k8s.io/v1` which became the stable Ingress API in Kubernetes 1.19
• C. Kubernetes 1.22 does not support Ingress resources
• D. The cluster upgrade requires all namespaces to be recreated

Kubernetes removes deprecated API versions after a deprecation window. extensions/v1beta1 was deprecated in Kubernetes 1.14 and removed in 1.22, manifests using the old API group fail after the upgrade. Updating to networking.k8s.io/v1 resolves the issue. This is the correct answer.

• A. The hypervisor-reported memory metric is accurate, and the OOM errors are caused by the operating system's memory overcommit policy preventing the application from using more than 40% of available RAM
• B. The application has a coding error causing stack overflow exceptions that are misreported as OOM errors in the logs, and the fix is to increase the thread stack size
• C. The cloud instance type does not support memory-intensive workloads and must be replaced with a memory-optimized instance family
• D. The application has a memory leak, it allocates memory for objects but never releases them, causing heap usage to grow until the process exhausts its addressable or OS-allocated memory limit. The hypervisor reports the total instance memory utilization (which includes all processes and the OS), masking the runaway growth within the single application's heap. Profiling with a heap analyzer will confirm unbounded object growth, and the fix is to identify and correct the missing deallocation or object lifecycle mismanagement in the application code

A memory leak causes the application's own heap to grow continuously regardless of total instance memory usage. The hypervisor metric reflects aggregate instance RAM usage across all processes and the OS, so the leaking application's portion can be steadily growing while the overall percentage appears moderate. Rapid object allocation without corresponding deallocation is a classic memory leak signature. This is the correct answer.

• A. Remove the new_feature argument since it is not supported in any provider version
• B. The Terraform code uses an argument introduced in provider version 4.5 but the lock file pins version 3.8, resolution: update the provider version constraint in terraform.tf to allow ≥4.5, run `terraform init -upgrade` to update the lock file to the newer provider version, then rerun the deployment
• C. Upgrade Terraform itself to the latest version
• D. Delete the terraform.lock.hcl file and run terraform apply directly

Provider version mismatch between documentation used for code authoring and the locked version causes argument compatibility errors. Updating the version constraint and running terraform init -upgrade resolves the lock file and enables the newer provider features. This is the correct answer.

• A. The container has insufficient memory in production
• B. The container image was built for ARM64 architecture on the M1 Mac but production cloud instances run x86_64, these are incompatible CPU instruction sets. Solution: build a multi-architecture image using Docker Buildx (--platform linux/amd64,linux/arm64) or build specifically for linux/amd64 to match production
• C. The application code contains syntax errors that only appear in production
• D. The container registry does not support the production cloud provider

CPU architecture incompatibility is a common issue when developers use Apple Silicon (ARM64) but production runs on x86_64 (AMD64). The container binary cannot execute on the wrong CPU architecture. Multi-arch builds or architecture-specific production builds resolve this. This is the correct answer.