How many Refer to the Exhibit Practice Questions questions are on this page?

This page has 12 Refer to the Exhibit Practice Questions scenario questions for the CV0-004 exam, each with detailed explanations and wrong-answer analysis.

How should I approach CV0-004 scenario questions?

Read the full scenario before looking at the answer options. Identify the constraint or requirement in the scenario, then eliminate options that are generally true but wrong for this specific case. Scenario questions reward careful reading over pattern matching.

← Back to CompTIA Cloud+ CV0-004 questions

Scenario-based practice

Refer to the Exhibit Practice Questions

Practise CompTIA Cloud+ CV0-004 practice questions — original exam-style scenarios covering every exam domain, with detailed explanations, wrong-answer analysis, and common exam traps.

Start full practice test Read exam guide

scenario questions

CV0-004

exam code

CompTIA

vendor

Scenario guide

How to approach refer to the exhibit practice questions

Practise exhibit-style questions that ask you to read a topology, table, command output or diagram before choosing the best answer.

Quick answer

Exhibit-style questions test whether you can read a topology, command output, diagram or table before choosing the best answer.

How to extract the relevant detail from an exhibit.

How topology, command output or routing information affects the answer.

How to avoid answering from memory before reading the evidence.

How to map the exhibit back to the exam objective.

Practice scenarios

Question 1easymultiple choice

Full question →

Refer to the exhibit. A cloud administrator runs this command on a VM. Which of the following is most likely causing the high 'wa' value?

Network Topology

A
Disk I/O bottleneck
The 'wa' column in top or vmstat measures CPU time spent waiting on I/O completion. A sustained high value indicates processes blocked on storage, so the disk subsystem is the bottleneck. Memory pressure or CPU saturation would raise different counters, such as 'si'/'so' or 'us'/'sy'.
B
Network congestion
Why it fails: Network congestion delays packets, appearing as retransmits or socket errors rather than the kernel's disk wait counter. It is tempting because remote storage traffic traverses the network, and network congestion would be correct if the exhibit showed latency on NFS or iSCSI mounts rather than local block devices.
C
High CPU load
Why it fails: CPU saturation raises user or system time, not the 'wa' percentage, which specifically measures time processes spend blocked on disk I/O. It is tempting because a busy processor often accompanies slow workloads, and high CPU load would be correct if the exhibit showed elevated user-time with low wait.
D
Insufficient memory
Why it fails: High I/O wait stems from storage subsystem latency, not memory pressure; insufficient RAM manifests as swapping, which the exhibit would show as rising swap usage alongside memory exhaustion. It is tempting because swapping does inflate wait, and insufficient memory would be correct if free memory were depleted and swap activity were climbing.

Full breakdown with real-world context →

Question 2hardmultiple choice

Full question →

A cloud administrator is troubleshooting connectivity to a web server running on a Linux VM. The web server is configured to listen on ports 80 (HTTP) and 443 (HTTPS). The administrator runs the iptables command shown in the exhibit. Based on the output, what is the MOST likely reason that external users cannot access the web server on port 443?

Exhibit

Refer to the exhibit.

# iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
 100  12000 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
  50   6000 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
  20   2400 ACCEPT     tcp  --  eth0   *       10.0.0.0/8           0.0.0.0/0            tcp dpt:443
  10   1200 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80

A
The web server is not configured to listen on port 443, so iptables rules are irrelevant.
Why it fails: The stem states the web server is configured to listen on both 80 and 443, so a missing listener contradicts the given facts; iptables filtering remains the relevant layer. It is tempting because a service not bound to a port is a common cause of connection refusals, and would be correct if netstat showed no listener on 443.
B
The iptables default policy is ACCEPT, but the rule for port 443 explicitly drops traffic from external sources.
Why it fails: A default ACCEPT policy applies only when no rule matches; it does not override an explicit DROP or REJECT rule for port 443, which would still block HTTPS. It is tempting because a permissive default suggests traffic should flow, and would be correct if the exhibit showed no matching rule for port 443.
C
The rule for port 80 is placed before the rule for port 443, causing all HTTPS traffic to be evaluated as HTTP and dropped.
Why it fails: Iptables evaluates rules sequentially, but a port 80 rule matches only destination port 80 traffic; packets to port 443 never match it, so no reclassification as HTTP occurs. It is tempting because rule order genuinely matters in iptables, and would be correct if an earlier broad DROP or REJECT rule shadowed the port 443 rule.
D
The iptables rule for port 443 only allows traffic from the 10.0.0.0/8 subnet, which does not include external IP addresses.
The INPUT chain rule for port 443 specifies source 10.0.0.0/8, a private range covering only internal addresses. External users' public source IPs never match this criterion, so the packet is dropped before reaching the web server. Port 80 lacks this restriction, explaining why only HTTPS fails.

Full breakdown with real-world context →

Question 3hardmultiple choice

Full question →

A cloud administrator is troubleshooting why a newly launched VM did not complete its initialization. According to the exhibit, what is the most likely cause?

Network Topology

A
Cloud-init is not installed on the VM
Why it fails: Cloud-init ships in most cloud images and its absence would not explain the exhibit's specific failure. It is tempting because a missing cloud-init package does prevent user-data execution entirely, which is the correct diagnosis only when the image genuinely lacks the agent and no initialisation logs exist.
B
The package repository is not configured correctly
A misconfigured package repository prevents the cloud-init script from installing required packages, so initialisation halts before completion. This directly satisfies the stem's constraint: the VM launched but never finished bootstrapping, indicating a dependency fetch failure rather than a provisioning or networking fault.
C
The cloud-init user data script contains a syntax error
Why it fails: A syntax error would still produce cloud-init log entries showing the script starting and failing, whereas the exhibit indicates initialisation never ran. It is tempting because malformed user data is a common cause of failed bootstrapping, and it would be correct if logs showed execution beginning then erroring.
D
The VM does not have internet access
Why it fails: Internet access is not required for cloud-init to fetch and run user data, since metadata is served from the local link-local endpoint. It is tempting because missing internet access does break package installs and API calls inside scripts, but that would surface as script errors, not absent initialisation.

Full breakdown with real-world context →

Question 4mediummultiple choice

Full question →

A security engineer is reviewing a cloud storage bucket policy. Which of the following best describes the security issue present in the exhibit?

Exhibit

Refer to the exhibit.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::mycompany-data/*"
    }
  ]
}

A
The bucket policy correctly limits access to read-only operations, which is secure by default.
Why it fails: Read-only permissions do not make a policy secure; the exhibit's actual flaw is likely an overly permissive principal or wildcard resource, which read-only access does not remedy. It is tempting because least privilege is a genuine principle, and read-only would be correct if the flaw were excessive write permissions, but the stated issue is broader exposure.
B
The bucket policy should be modified to allow write access for full functionality.
Why it fails: Granting write access widens exposure rather than fixing the flaw; the exhibit's issue concerns excessive or misconfigured permissions, not insufficient functionality. It is tempting when an application genuinely needs to upload objects, and write access would be correct for that workload, but the question asks to identify the existing security problem.
C
The bucket policy should include an IP address restriction to limit access to corporate IPs.
Why it fails: Adding an IP restriction is a hardening improvement, not the security issue present in the exhibit; the policy's existing flaw remains unaddressed. It is tempting because source-IP conditions are a legitimate control, and they would be correct where access must be limited to known networks, but the question asks what is wrong with the policy as shown.
D
The bucket policy allows public read access to all objects, creating a data exposure risk.
Public read access on a bucket policy grants anonymous principals the `s3:GetObject` permission, so anyone on the internet can retrieve every stored object without authentication. This directly satisfies the stem's data exposure risk, since confidentiality is lost for all objects rather than a scoped subset.

Full breakdown with real-world context →

Question 5mediummultiple choice

Full question →

Refer to the exhibit. A cloud load balancer is returning 502 Bad Gateway errors to clients. What is the most likely cause?

Exhibit

[2025-01-20 14:23:45] ERROR Backend "web-svr-01" health check failed (HTTP 502)
[2025-01-20 14:23:46] ERROR Backend "web-svr-02" health check failed (HTTP 502)
[2025-01-20 14:23:47] ERROR Backend "web-svr-03" health check failed (HTTP 502)

A
The load balancer's SSL certificate is invalid.
Why it fails: An invalid certificate causes TLS handshake failures and browser warnings before any HTTP response, so clients never see 502. Certificate errors fit HTTPS listener misconfiguration; 502 instead indicates the load balancer reached a backend that returned an unparseable or empty response.
B
The security group allows inbound traffic from the load balancer.
Why it fails: Permitting inbound traffic from the load balancer is required for healthy backends and cannot itself cause 502; blocking it would yield timeouts. Security group rules are the culprit when connections are refused, whereas 502 means the backend responded invalidly or the health check failed.
C
The DNS record points to the wrong IP.
Why it fails: A wrong DNS target produces connection timeouts or 404s, not 502, because the load balancer never reaches a backend to receive a malformed response. It would be the cause when clients cannot resolve or connect at all, rather than the gateway receiving an invalid upstream reply.
D
The backend web servers are not responding correctly.
A 502 Bad Gateway means the load balancer received an invalid or incomplete response from an upstream backend. Since the balancer itself and client connectivity are functioning, the fault lies with the backend web servers failing to respond correctly, matching this option.

Full breakdown with real-world context →

Question 6hardmultiple choice

Full question →

Refer to the exhibit. A cloud administrator sees this log after a nightly backup job. Which of the following is the most likely cause of the timeout?

Exhibit

Refer to the exhibit.

```
[ERROR] Backup job failed at 2024-08-21 02:00:00.
Reason: Volume snapshot creation timed out.
Volume ID: vol-0a12345
Snapshot ID: snap-0b67890
```

A
The volume has a high I/O load during the snapshot.
Snapshot creation contends with concurrent writes, so sustained I/O pressure delays completion until the job exceeds its timeout window. The log timing aligns with the backup overlapping peak disk activity rather than a network or credential fault.
B
The volume is attached to an instance that is powered off.
Why it fails: A powered-off instance still presents its attached volume, and backup agents can often read it; the timeout stems from the agent failing to reach the backup service, not the instance state. Powered-off instances are relevant when troubleshooting snapshot consistency, not agent connectivity timeouts.
C
The snapshot target region is unreachable.
Why it fails: Snapshot target region reachability affects replication, not the nightly backup job's agent communication. It tempts because cross-region operations are common failure points, but the timeout occurs before any snapshot transfer, pointing to the backup service endpoint being unreachable from the instance.
D
The backup agent is not installed.
Why it fails: A missing agent would produce an installation or connection-refused error, not a timeout after the job starts. It tempts because agent problems are common, but the log shows the job initiating, so the agent is present; the timeout instead reflects a network or endpoint reachability failure.

Full breakdown with real-world context →

Question 7easymultiple choice

Full question →

A company hosts its critical applications on a cloud provider's virtual machines within a virtual private cloud. The security team receives an alert from the intrusion detection system indicating that one of the VMs is exhibiting signs of a ransomware infection. The administrator connects to the VM via a bastion host and observes that several important files have been encrypted and a ransom note has been left. The incident response plan is still being developed, but the administrator knows the immediate priority is to contain the threat and prevent it from spreading to other VMs and storage resources. The company has daily backups stored in a separate cloud storage service that is not directly accessible from the production network. Which of the following actions should the administrator take FIRST to contain the incident and minimize further damage?

A
Restore the VM from the most recent backup.
Why it fails: Restoring rebuilds data but leaves the compromised VM live and spreading, and the encrypted instance may simply be re-infected. Backup restoration is the recovery step taken after containment, appropriate once the threat is isolated and the clean source verified.
B
Notify law enforcement about the ransomware attack.
Why it fails: Notification is an administrative and legal step that removes no attacker access; encryption and lateral movement continue meanwhile. Involving law enforcement belongs later in the response, once the threat is contained and evidence preserved, not as the first containment action.
C
Run a full antivirus scan on the infected VM.
Why it fails: Scanning leaves the VM running and connected, so ransomware can keep encrypting files and reach mounted storage or peer VMs. Antivirus scanning suits routine malware triage on a suspected but unconfirmed host; here the ransom note confirms active encryption, demanding network isolation first.
D
Immediately disconnect the network interface of the infected VM.
Disconnecting the network interface severs all inbound and outbound traffic at the virtual NIC level, immediately halting lateral movement to other VMs and mounted storage. This satisfies the stem's containment priority, isolating the ransomware before it can encrypt shared resources, while preserving the VM's disk state for later forensic analysis.

Full breakdown with real-world context →

Question 8mediummultiple choice

Full question →

Refer to the exhibit. The auto scaling group is fluctuating between 2 and 3 instances every few minutes. What is the most likely cause?

Exhibit

[admin@controller ~]$ cldctl log asg-web --type scaling
2025-01-20 14:20:00 INFO Scaling event: Desired capacity changed from 2 to 3
2025-01-20 14:25:00 INFO Scaling event: Desired capacity changed from 3 to 2
2025-01-20 14:40:00 INFO Scaling event: Desired capacity changed from 2 to 3
2025-01-20 14:45:00 INFO Scaling event: Desired capacity changed from 3 to 2

A
The instances are taking too long to become healthy.
Why it fails: Slow instance health checks can cause scaling churn, but the described 2-to-3 oscillation every few minutes points to a cooldown or health-check grace period mismatch rather than slow boot alone. This option is tempting because unhealthy instances do trigger replacement, which is the correct diagnosis when instances fail checks outright rather than oscillating.
B
The launch configuration has incorrect user data.
Why it fails: Incorrect user data causes instances to fail health checks and be replaced, producing repeated termination and launch rather than a stable two-to-three oscillation. It is tempting because user data errors do break instances, and would be correct if instances never reached a healthy state.
C
The load balancer is not properly distributing traffic.
Why it fails: A load balancer distributing traffic unevenly changes per-instance load, not group capacity; scaling decisions follow aggregate metrics. It is tempting because load balancers influence scaling, and would be correct if one instance were saturated while others sat idle.
D
The scaling policies are based on metrics that are too sensitive.
Scaling policies react to metric thresholds; if those metrics fluctuate naturally around the target, the group adds and removes instances repeatedly. Overly sensitive thresholds or short cooldowns cause this rapid oscillation between two and three instances, matching the exhibit.

Full breakdown with real-world context →

Question 9hardmultiple choice

Full question →

A cloud engineer runs the commands shown in the exhibit. Based on the output, which security issue is present?

Exhibit

Refer to the exhibit.

```
[user@bastion ~]$ gcloud compute instances list --format="value(name,zone,status)"
web-server-1 us-central1-a RUNNING
web-server-2 us-central1-b RUNNING
db-server us-central1-a RUNNING
[user@bastion ~]$ gcloud compute ssh web-server-1 --command="sudo systemctl status nginx"
● nginx.service - A high performance web server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2024-03-14 10:23:45 UTC; 1h 30min ago
[user@bastion ~]$ gcloud compute firewall-rules list --filter="allowed=('tcp:22')"
NAME        NETWORK  DIRECTION  PRIORITY  ALLOW    DENY  DISABLED
allow-ssh   default  INGRESS    1000      tcp:22                False
[user@bastion ~]$ gcloud compute firewall-rules describe allow-ssh
allowed:
- IPProtocol: tcp
  ports:
  - '22'
sourceRanges:
- 0.0.0.0/0
```

A
The bastion host is not used for SSH access.
Why it fails: The exhibit's output concerns listening ports and exposed services, not which jump host brokers SSH, so bastion usage is irrelevant to the finding. A bastion host is tempting because it centralises SSH entry and reduces public exposure, and it would be the answer if the output showed SSH reachable directly from the internet.
B
The web servers are not running.
Why it fails: The exhibit shows listening sockets and connection states, which indicate services are bound and accepting traffic; stopped web servers would show no listener on ports 80/443. Verifying service availability is tempting because it is a common troubleshooting step, and it would be correct if the output showed failed units or refused connections.
C
The firewall rule allows SSH access from any source IP.
The exhibit shows an inbound rule permitting TCP port 22 with a source of 0.0.0.0/0, meaning any internet host can reach SSH. That violates the least-privilege constraint in the stem, since administrative access should be restricted to known management addresses rather than exposed globally.
D
There are too many firewall rules allowing SSH.
Why it fails: Rule count alone is not a security issue; overly permissive source ranges or ports are. Many SSH rules can be legitimate, so volume does not evidence exposure. The actual issue is the breadth of access permitted — for example 0.0.0.0/0 on port 22 — which the exhibit's specific rules would reveal.

Full breakdown with real-world context →

Question 10easymultiple choice

Review the full subnetting walkthrough →

Refer to the exhibit. A cloud administrator runs the command to inspect an instance and notices that it is running, but the web application hosted on it is unreachable from the internet. The instance is in a public subnet with an internet gateway attached to the VPC. Which of the following is the most likely cause?

Exhibit

Refer to the exhibit.
```
$ cloud-cli compute instances describe --instance-id i-12345
{
  "instanceId": "i-12345",
  "state": "running",
  "instanceType": "t2.medium",
  "networkInterfaces": [
    {
      "ip": "10.0.1.25",
      "subnetId": "subnet-abc",
      "vpcId": "vpc-xyz",
      "securityGroups": ["sg-web"]
    }
  ],
  "blockDeviceMappings": [
    {
      "deviceName": "/dev/sda1",
      "volumeId": "vol-111",
      "status": "attached"
    }
  ]
}
```

A
The instance type t2.medium does not support public IP addresses.
Why it fails: Instance type does not govern public IP assignment; that is determined by the subnet's auto-assign public IPv4 setting or an attached elastic IP. It is tempting because instance families do differ in networking capability, but t2.medium supports public addressing, so this cannot explain the unreachable web application.
B
The instance's security group does not allow inbound HTTP/HTTPS traffic from 0.0.0.0/0.
A public subnet and internet gateway only provide a route; the security group acts as a stateful virtual firewall at the instance's elastic network interface. With no inbound rule permitting HTTP/HTTPS from 0.0.0.0/0, the web application stays unreachable despite the instance running.
C
The subnet subnet-abc is not associated with a route table that has a route to the internet gateway.
Why it fails: The stem states the internet gateway is attached to the VPC, but the subnet route table may still be misconfigured; however, security group is a more common first check.
D
The volume vol-111 is not encrypted.
Why it fails: Volume encryption at rest has no bearing on inbound network reachability; an unencrypted vol-111 would still serve traffic normally. Encryption is tempting because it is a genuine security control, and it would be the right answer for a compliance or data-at-rest question, not for an unreachable web application.

Full breakdown with real-world context →

Question 11hardmultiple choice

Full question →

A cloud administrator runs the `iostat` command on a Linux VM experiencing slow performance. Based on the exhibit, what is the most likely bottleneck?

Exhibit

Refer to the exhibit.
```
$ iostat -x 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.2     0.0    2.1   45.3      0.0   47.4

Device:   rrqm/s   wrqm/s   r/s   w/s   rkB/s   wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvda       0.00     0.00  85.0  15.0  3400.0  600.0    80.0     4.5    45.0   40.0   70.0   10.0  90.0%
```

A
Disk I/O is saturated.
High %util with elevated await and queue depth on the device confirms the disk subsystem is saturated, so requests queue faster than they complete. This matches the slow VM symptom, since CPU and memory metrics remain normal while I/O wait dominates.
B
Network bandwidth is limited.
Why it fails: iostat reports CPU utilisation and disk I/O statistics; it exposes no network counters such as throughput, retransmits or interface saturation. Network bandwidth would be the answer when tools like iftop, sar -n DEV or CloudWatch network metrics show the interface saturated, not when iostat output is the sole exhibit provided.
C
CPU is overloaded.
Why it fails: CPU %user + %system = 7.3%, not high.
D
Memory is insufficient.
Why it fails: iostat does not report memory consumption, swap usage or page-fault rates; those come from free, vmstat and sar -r. Insufficient memory would be indicated by heavy swapping and high si/so values in vmstat, which iostat output cannot show. The exhibit's disk and CPU columns point elsewhere.

Full breakdown with real-world context →

Question 12mediummultiple choice

Full question →

A cloud engineer deploys the Kubernetes manifest shown in the exhibit. After deployment, the frontend pods are in CrashLoopBackOff state. The engineer checks the logs and finds 'OOMKilled' errors. Which of the following changes would resolve the issue?

Exhibit

Refer to the exhibit.

```yaml
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
---
apiVersion: v1
kind: Service
metadata:
  name: frontend-service
spec:
  type: LoadBalancer
  selector:
    app: frontend
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
```

A
Increase the memory limit to 1Gi.
OOMKilled means the container exceeded its memory limit and the kernel terminated it. Raising the limit to 1Gi gives the frontend pods sufficient headroom, preventing the kubelet from killing them and ending the CrashLoopBackOff cycle.
B
Increase the number of replicas to 5.
Why it fails: Adding replicas multiplies the number of pods but each replica still exceeds its memory limit, so OOMKilled persists. It is tempting because CrashLoopBackOff suggests insufficient capacity, and scaling replicas would be correct for handling increased traffic when resources per pod are adequate.
C
Reduce the CPU limit to 250m.
Why it fails: OOMKilled means the container exceeded its memory limit, so lowering the CPU limit addresses a different resource and leaves the memory ceiling unchanged. It is tempting because CPU and memory limits sit together in the manifest, and reducing CPU would be correct when pods are throttled rather than killed.
D
Change the service type to ClusterIP.
Why it fails: Changing the service type to ClusterIP alters how traffic reaches the pods, not the container memory limit that triggers OOMKilled. It is tempting because service misconfiguration also causes pod failures, and ClusterIP would be correct when pods must be reachable only inside the cluster.

Full breakdown with real-world context →

These CV0-004 practice questions are part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style CV0-004 questions with detailed explanations, topic-based practice, mock exams, readiness tracking, and study analytics.

Refer to the Exhibit Practice Questions

How to approach refer to the exhibit practice questions

Quick answer

Related CV0-004 topic practice pages

Deployment practice questions

Cloud Architecture and Design practice questions

Security practice questions

Operations and Support practice questions

Troubleshooting practice questions

CV0-004 fundamentals practice questions

CV0-004 scenario practice questions

CV0-004 troubleshooting practice questions

Practice scenarios

Refer to the exhibit. A cloud administrator runs this command on a VM. Which of the following is most likely causing the high 'wa' value?

Exhibit

A cloud administrator is troubleshooting why a newly launched VM did not complete its initialization. According to the exhibit, what is the most likely cause?

A security engineer is reviewing a cloud storage bucket policy. Which of the following best describes the security issue present in the exhibit?

Exhibit

Refer to the exhibit. A cloud load balancer is returning 502 Bad Gateway errors to clients. What is the most likely cause?

Exhibit

Refer to the exhibit. A cloud administrator sees this log after a nightly backup job. Which of the following is the most likely cause of the timeout?

Exhibit

Refer to the exhibit. The auto scaling group is fluctuating between 2 and 3 instances every few minutes. What is the most likely cause?

Exhibit

A cloud engineer runs the commands shown in the exhibit. Based on the output, which security issue is present?

Exhibit

Exhibit

A cloud administrator runs the `iostat` command on a Linux VM experiencing slow performance. Based on the exhibit, what is the most likely bottleneck?

Exhibit

A cloud engineer deploys the Kubernetes manifest shown in the exhibit. After deployment, the frontend pods are in CrashLoopBackOff state. The engineer checks the logs and finds 'OOMKilled' errors. Which of the following changes would resolve the issue?

Exhibit