CompTIA Cloud+ CV0-004: Troubleshooting

Topic snapshot

Sample questions

These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.

Question 1

Topic: Troubleshooting

A cloud team applied a compliance hardening template to an internet-facing web tier. After deployment, users report HTTPS timeouts.

Observed evidence:

• Instances are healthy, and the application is listening on TCP 443.
• CPU, memory, and storage metrics are normal.
• The instance IAM role is unchanged, and secrets retrieval succeeds.
• The security group allows inbound TCP 443.
• VPC flow logs show REJECT entries at the subnet ACL for client traffic.

Which action should the administrator take first?

Options:

• A. Correct the subnet ACL rule for HTTPS traffic

• B. Modify the object storage bucket policy

• C. Rotate the application secrets and redeploy

• D. Increase the web instances to a larger size

Best answer: A

Explanation: The evidence points to a network filtering problem, not a compute, storage, or IAM issue. Because flow logs show rejected traffic at the subnet ACL while the app and security group look healthy, the first action should be to correct the ACL rule.

Network troubleshooting should follow the evidence and isolate where traffic is blocked. In this scenario, the application is running, resource metrics are normal, IAM and secrets are working, and the security group permits TCP 443. The decisive clue is the REJECT entry at the subnet ACL, which means traffic is being blocked before it reaches the instances. The appropriate first step is to correct the subnet ACL so required HTTPS traffic is permitted, including any needed return traffic if the ACL is stateless.

Changing compute capacity, secrets, or storage policy would create unrelated risk and would not address the observed network deny.

• Compute sizing is not indicated because health and performance metrics are normal.
• Secrets rotation does not fit because secrets retrieval succeeds and no authentication failure is shown.
• Storage policy changes are unrelated to user HTTPS timeouts and the flow-log rejection.

Question 2

Topic: Troubleshooting

A cloud engineer is deploying a new IaaS application stack with versioned IaC. The plan requires 10 compute instances with 8 vCPUs each in a specific region for data residency. The pipeline fails during provisioning with Regional vCPU quota exceeded: requested 80, available 64. Which action should the engineer take to complete the deployment while preserving the requirements?

Options:

• A. Deploy the remaining instances manually outside the IaC workflow

• B. Rerun the failed pipeline during a lower-traffic maintenance window

• C. Request a regional vCPU quota increase, then rerun the IaC deployment

• D. Change the IaC template to deploy the stack in another region

Best answer: C

Explanation: The deployment failed because the requested resources exceed the current regional vCPU quota. Retrying without fixing that limit will fail again, so the engineer should raise the quota and then rerun the controlled IaC deployment.

Deployment troubleshooting should address the specific blocking condition before another deployment attempt. In this scenario, the IaC plan is valid for the business requirement, but the cloud account’s regional vCPU quota is too low for the required 80 vCPUs. The appropriate implementation is to request or obtain a quota increase for that region, wait for it to be available, and then rerun the same version-controlled deployment. This preserves data residency and repeatability. Manual changes or region changes may bypass the immediate error, but they violate stated constraints and can create configuration drift.

• Maintenance retry fails because quota limits are not normally resolved by waiting for lower traffic.
• Manual deployment fails because it bypasses versioned IaC and creates drift from the declared state.
• Region change fails because the workload must remain in the specified region for data residency.

Question 3

Topic: Troubleshooting

A cloud team uses a CI/CD service principal to deploy IaC to IaaS resources. An automated identity control quarantined the principal after API calls from an unapproved network attempted to modify security groups. Production workloads are still serving traffic, but new deployments are blocked and a release manager asks to bypass the control for a hotfix. What is the BEST next action?

Options:

• A. Re-enable the service principal with administrator permissions

• B. Disable the anomaly control until the hotfix is deployed

• C. Keep quarantine, investigate logs, rotate credentials, then restore least privilege

• D. Restore the previous IaC state from backup immediately

Best answer: C

Explanation: The safest troubleshooting action is to maintain the containment control while investigating the suspected compromise. Because production is still available, restoring access or disabling the control before validating root cause could allow the attacker to continue modifying cloud resources.

Security issue troubleshooting prioritizes containment before service restoration when suspicious activity indicates possible credential compromise. In this scenario, the quarantined CI/CD principal attempted security group changes from an unapproved network, so the team should preserve the control, review audit logs, identify the source and scope, revoke or rotate exposed credentials, and only then restore the minimum required permissions. This approach balances availability with security because the production workload is still running and only deployments are blocked. Bypassing the control would trade a release delay for a possible active compromise.

• Bypassing controls fails because it removes containment before confirming whether the principal is compromised.
• Granting admin access increases blast radius and violates least privilege during an active security investigation.
• Restoring IaC state may fix configuration drift, but it does not address the suspicious identity activity or credential risk.

Question 4

Topic: Troubleshooting

A company is performing a canary migration of a public API from an older VM-based load balancer to a managed edge gateway. Internal users succeed, but a partner application connected through the site-to-site VPN fails only against the canary endpoint. The gateway TLS log shows handshake_failure: no shared cipher; the partner client offers only CBC/3DES RSA cipher suites, and the gateway policy allows only modern TLS 1.2/1.3 AEAD suites. What should the cloud engineer do first?

Options:

• A. Increase the canary percentage to collect more failures

• B. Upgrade the partner TLS client to supported cipher suites

• C. Disable certificate validation on the partner client

• D. Add a static route for the partner VPN subnet

Best answer: B

Explanation: The decisive evidence is no shared cipher, not a routing or certificate-chain symptom. The partner client only offers deprecated CBC/3DES RSA suites, while the new gateway requires modern AEAD suites, so the client TLS stack must be updated or reconfigured.

Cipher suite deprecation commonly appears during migrations when a newer load balancer, gateway, or TLS policy enforces stronger cryptography than older clients support. A TLS handshake requires both sides to agree on protocol version and cipher suite. Here, the partner client can reach the endpoint far enough to attempt TLS, but negotiation fails because there is no overlap between its deprecated suites and the gateway’s allowed suites. The durable fix is to update the client TLS library or configuration to support currently accepted TLS 1.2/1.3 cipher suites, such as ECDHE with AEAD encryption. Re-enabling weak suites may create compliance and security risk and should not be the first corrective action.

• Canary percentage does not resolve a deterministic TLS negotiation failure and would only expose more traffic to the same issue.
• Static routing is unlikely because the TLS log proves the partner reached the gateway and began a handshake.
• Certificate validation would cause trust or name-validation errors, not a no shared cipher message.

Question 5

Topic: Troubleshooting

A cloud administrator runs an IaC deployment for a new web tier in a region where the company already hosts several test environments. The pipeline creates the VPC, subnets, and security groups, but fails when attaching public IP addresses to the new load balancers.

Status: Failed
Error: QuotaExceeded
Resource: public_ip_address
Message: Regional public IP address quota reached.
Current usage: 20
Regional quota: 20
Requested additional: 2

What is the best next fix?

Options:

• A. Add a NAT gateway to the private subnets

• B. Reduce IaC parallelism and retry the pipeline

• C. Request a regional public IP quota increase

• D. Update the load balancer health check path

Best answer: C

Explanation: The failure is caused by a regional service quota, not a network path or application health issue. The deployment needs two more public IP addresses, but the region is already at its quota of 20.

Cloud deployments can fail even when the template is valid if the target region has reached a service quota. In this case, the error explicitly identifies public_ip_address, shows current usage equals the regional quota, and states that two more addresses are requested. The appropriate fix is to increase the quota or redesign the deployment to use fewer public IP addresses. Retrying without changing the quota will fail again because the limiting condition is not transient.

• NAT gateway helps private resources reach outbound services but does not increase available public IP quota.
• Lower parallelism can help with API throttling, but this error is a hard quota limit.
• Health check changes address load balancer target status, not IP allocation failure.

Question 6

Topic: Troubleshooting

A cloud administrator is reviewing audit logs after an alert. A CI service account that normally pulls artifacts from a known runner IP was used from an unfamiliar country to attach an administrator policy to itself and launch a new VM. The team must stop active misuse while preserving evidence for investigation. Which actions should the administrator take next? Select TWO.

Options:

• A. Delete the service account immediately

• B. Patch the newly launched VM before taking other action

• C. Remove the unauthorized administrator policy from the service account

• D. Disable the service account access key and revoke active sessions

• E. Increase log retention and continue monitoring

• F. Rotate passwords for all human administrators

Correct answers: C and D

Explanation: The evidence indicates both credential compromise and privilege escalation. The safest next actions are to contain the compromised credential and remove the unauthorized privilege without destroying evidence needed for investigation.

Security troubleshooting should first contain active misuse while preserving logs, identities, and affected resources for analysis. Disabling or rotating the exposed service account key prevents further API calls using the compromised credential. Removing the unauthorized administrator policy reverses the privilege escalation shown in the audit logs without deleting the principal or erasing useful attribution. These actions are targeted to the evidence: abnormal source location, unauthorized policy attachment, and resource creation. The key takeaway is to contain the compromised identity and revoke improper authorization before broader remediation.

• Deleting the identity is too destructive because it can break CI workflows and remove useful investigation context.
• Patching the VM may be needed later, but it does not stop the compromised credential or privilege misuse.
• Only monitoring preserves visibility but allows the attacker to continue acting.
• Rotating all admin passwords is broad and unsupported by the evidence, which points to a service account key.

Question 7

Topic: Troubleshooting

A cloud engineer updated security groups and route tables after a failed audit found that an application tier could not reach a private database and that a web subnet had unintended database access. Requirements are:

• App subnet must connect to the database on TCP 5432.
• Web subnet must be blocked from the database.
• Average round-trip latency from app to database must stay under 10 ms.
• No other database protocols should be reachable.

Which validation result best confirms the fix?

Options:

• A. App TCP 5432 succeeds, latency is 6 ms, web subnet is denied, other DB ports fail

• B. Web subnet is denied, but app TCP 5432 times out intermittently

• C. App TCP 5432 succeeds, but TCP 3306 also succeeds from the app subnet

• D. App ping succeeds, latency is 4 ms, and web subnet routes to the database

Best answer: A

Explanation: The validation must prove all stated requirements, not just one symptom. The best result confirms the application can use the required database protocol, latency is within the limit, the web subnet remains segmented, and unintended database ports are blocked.

Network fix validation should match the original requirements and the audit finding. For this scenario, a successful fix must show positive access for the allowed path and negative access for prohibited paths. Testing only ICMP or routing is insufficient because the application depends on TCP 5432, not ping. Testing only a deny rule is also insufficient because it does not prove the application path works within the latency target. The strongest validation combines protocol-specific connectivity, latency measurement, and segmentation verification.

The key takeaway is to validate both allowed and denied flows against the requirement, not just basic reachability.

• Ping-only testing fails because ICMP reachability does not prove TCP 5432 works, and web subnet database routing violates segmentation.
• Extra DB port access fails because allowing another database protocol breaks the stated protocol restriction.
• Intermittent timeout fails because the required application-to-database path is not reliably working.

Question 8

Topic: Troubleshooting

A cloud operations team receives an alert that a service account’s API key was used from an unrecognized network to create a new administrator role assignment. The service account normally runs a production batch job and should not manage IAM. Audit logs are intact, and the batch job can use a different managed identity. Which action should the administrator take next to contain the issue while preserving evidence?

Options:

• A. Block all internet access to the production subnet

• B. Wait for the next maintenance window to rotate credentials

• C. Disable the API key and revoke active sessions

• D. Delete the service account and its audit history

Best answer: C

Explanation: The safest next action is to contain the compromised credential immediately. Disabling the API key and revoking active sessions stops further misuse while keeping logs available for investigation and allowing the workload to move to the alternate managed identity.

Credential compromise should be contained before broader cleanup. In this case, the evidence points to an API key being abused for unauthorized IAM activity. The administrator should revoke or disable the suspect credential and terminate active sessions so the attacker cannot continue using it. Because audit logs are intact, they should be preserved for investigation rather than deleted. Since the batch job can use another managed identity, containment does not require taking the whole subnet or production environment offline.

The key takeaway is to isolate the compromised access path first, then investigate and remediate permissions, roles, and credential hygiene.

• Deleting evidence is unsafe because audit history is needed to determine scope and support incident response.
• Subnet blocking is overly disruptive and does not directly address the abused API key.
• Delayed rotation allows continued unauthorized use after compromise indicators are already present.

Question 9

Topic: Troubleshooting

A cloud administrator deploys a Linux VM in a private application subnet. The VM receives IP address 10.20.3.45, resolves repo.example.net to a public IP, and can connect to an internal database. However, curl https://repo.example.net times out. The subnet route table sends 0.0.0.0/0 to an internet gateway, and the VM has no public IP. What is the best next fix?

Options:

• A. Update the DNS resolver configuration

• B. Change the VLAN tag on the VM interface

• C. Renew the VM DHCP lease

• D. Route outbound traffic through a NAT gateway

Best answer: D

Explanation: The symptoms point to a NAT or default-route design issue, not DNS, DHCP, HTTP, or VLAN. The VM has an IP address, resolves the hostname, and reaches internal resources, but cannot initiate outbound internet connections from a private subnet without NAT.

For a VM in a private subnet, outbound internet access typically requires a default route to a NAT gateway or similar egress device. DNS is working because the hostname resolves, and DHCP is working because the VM has a valid private address. Internal connectivity also suggests the subnet and local routes are functioning. The timeout occurs when traffic must leave the private network for a public destination, and the VM lacks a public IP. Sending the default route directly to an internet gateway is not sufficient for a private-only VM; the traffic needs source NAT so return traffic can reach it.

• DNS change fails because name resolution already returns a public IP.
• DHCP renewal fails because the VM already has a valid address and internal connectivity.
• VLAN tag change fails because the symptoms do not indicate Layer 2 segmentation or tagging errors.

Question 10

Topic: Troubleshooting

A monitoring alert shows one VM in a load-balanced web tier has sustained CPU spikes and unexpected outbound connections. Host logs show an unapproved binary installed after the last approved deployment. The application tier is stateless, and an approved image is available for redeployment. Which action best addresses the issue while maintaining service?

Options:

• A. Restore the database from the latest backup.

• B. Increase autoscaling capacity for the web tier.

• C. Quarantine and replace the VM from the approved image.

• D. Add the new process to the monitoring baseline.

Best answer: C

Explanation: Unauthorized software on a cloud workload should be treated as a security incident, not as a normal performance problem. Because the web tier is stateless and has an approved image, quarantining the affected VM and replacing it restores trust while preserving availability.

The core concept is secure remediation of a compromised or noncompliant workload. When unauthorized software is discovered, the affected instance should be isolated to prevent further activity and preserve evidence. For a stateless, load-balanced tier, replacing the VM from a known-good image is usually safer and faster than trying to clean the system in place. This also keeps the service available because healthy instances can continue serving traffic behind the load balancer. Scaling, baselining, or database recovery does not address the root issue: the workload is no longer trusted.

• Scaling capacity treats the CPU symptom but leaves the unauthorized software running.
• Updating the baseline normalizes suspicious behavior instead of investigating and removing it.
• Restoring the database targets persistent data, but the evidence points to a compromised stateless VM.

Continue with full practice

Use the CompTIA Cloud+ CV0-004 Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try CompTIA Cloud+ CV0-004 on Web View CompTIA Cloud+ CV0-004 Practice Test

Related focused pages

• Free CompTIA Cloud+ CV0-004 Full-Length Practice Exam
• Cloud Architecture
• Deployment
• Operations
• Security
• Devops Fundamentals

Free review resource

Read the CompTIA Cloud+ CV0-004 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.