Cassandra Admin study materials
Cassandra Admin study resources

Cassandra Admin practice questions

One question at a time. Build your Cassandra Admin understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Cassandra Architecture and the Distributed Ring

Which partitioner is the default for new Cassandra clusters and hashes partition keys into a 64-bit token for even ring distribution?

  1. Murmur3Partitioner Correct answer.
  2. OrderPreservingPartitioner
  3. RandomPartitioner
  4. ByteOrderedPartitioner

Explanation

Murmur3Partitioner is the default in current Cassandra releases. It hashes partition keys with Murmur3 into a 64-bit token, which spreads data and read/write load evenly around the ring. RandomPartitioner was the older default, and ordered partitioners are discouraged because they create hotspots.

Question 2Cassandra Architecture and the Distributed Ring

What is the main function of seed nodes in a Cassandra cluster?

  1. They provide initial gossip contact points for joining nodes. Correct answer.
  2. They store system_auth and authorize all CQL statements cluster-wide.
  3. They are the only nodes permitted to coordinate client requests.
  4. They persist the commit log for every other node in the cluster.

Explanation

Seed nodes are listed in cassandra.yaml as contact points. A joining node contacts a seed to begin gossip and learn the endpoints, tokens, and states of the rest of the cluster. Seeds are not special after bootstrap; any node can coordinate requests.

Question 3Cassandra Architecture and the Distributed Ring

Which replication strategy is required for a keyspace that spans multiple datacenters and needs per-datacenter replication factors?

  1. SimpleStrategy with a per-datacenter replication factor
  2. NetworkTopologyStrategy Correct answer.
  3. EverywhereStrategy
  4. LocalStrategy

Explanation

NetworkTopologyStrategy accepts a replication factor per datacenter and places replicas on distinct racks when possible. SimpleStrategy uses one RF and ignores datacenter topology, and LocalStrategy is only for local system keyspaces.

Question 4Cassandra Architecture and the Distributed Ring

A keyspace uses RF=3. A client writes at QUORUM and later reads at QUORUM. What consistency guarantee does this provide?

  1. Every replica must acknowledge both the write and the read before returning.
  2. Their quorums overlap in at least one replica, so the read sees the latest write. Correct answer.
  3. Only one replica is consulted, so stale data can be returned.
  4. The read is guaranteed to be routed to the same coordinator node that handled the original write.

Explanation

With RF=3, QUORUM is two replicas for both reads and writes. The write quorum and read quorum must intersect in at least one replica, so that replica returns the latest acknowledged write. This assumes the intersecting replica is healthy and has received the write.

Question 5Cassandra Architecture and the Distributed Ring

A replica node is temporarily down when a write arrives. What does hinted handoff do?

  1. The coordinator writes the data to a random node and never repairs it.
  2. The coordinator rejects the write until all replicas are reachable.
  3. The coordinator stores a hint and replays the write when the replica returns. Correct answer.
  4. The coordinator immediately triggers a full Merkle-tree repair across the cluster.

Explanation

When a replica is unavailable, the coordinator can store a hint locally for that replica. After the replica recovers and gossip marks it up, the coordinator replays the hinted write. Hints expire after max_hint_window_in_ms, so long outages still need repair.

Question 6Cassandra Architecture and the Distributed Ring

What is the primary responsibility of a snitch in Cassandra?

  1. Mapping node IP addresses to datacenters and racks for topology awareness. Correct answer.
  2. Detecting disk failures and marking SSTables as corrupt.
  3. Automatically balancing token ownership by reassigning vnode ranges across nodes.
  4. Choosing the compaction strategy for each table.

Explanation

A snitch maps each node's IP address to a datacenter and rack. Cassandra uses that topology for replica placement with NetworkTopologyStrategy and for routing to avoid cross-datacenter latency. The snitch does not manage compaction, disk health, or token reassignment.

Question 7Cassandra Architecture and the Distributed Ring

Which compaction strategy is best suited for a time-series table where rows are written once with a TTL and never updated?

  1. TimeWindowCompactionStrategy Correct answer.
  2. DateTieredCompactionStrategy
  3. LeveledCompactionStrategy
  4. SizeTieredCompactionStrategy tuned for write-heavy workloads

Explanation

TimeWindowCompactionStrategy groups SSTables into time windows and compacts within each window. That suits immutable time-series data with TTLs because expired data can be dropped with whole SSTables. SizeTiered is general-purpose and Leveled targets read-heavy update workloads.

Question 8Cassandra Architecture and the Distributed Ring

What does nodetool repair use Merkle trees for?

  1. Reassigning vnode ranges when a node leaves the ring permanently.
  2. Rebuilding the commit log and indexes after an unclean shutdown.
  3. Comparing range hashes to find and reconcile divergent replicas. Correct answer.
  4. Streaming new SSTables to a node that is bootstrapping into the ring.

Explanation

Repair builds Merkle trees over token ranges by hashing the data in each range. Replicas exchange and compare the tree hashes to identify ranges that differ. Only those divergent ranges are streamed and reconciled, which makes repair cheaper than comparing all data.

Question 9Cassandra Architecture and the Distributed Ring

A new node joins with num_tokens set to 256. How does it obtain its data?

  1. It waits for the next full repair to receive data from all peers.
  2. It claims 256 token ranges and streams each range from an existing replica. Correct answer.
  3. It uses the commit log of the previous node that owned those tokens.
  4. It copies every SSTable from the seed node's data directory into its local data directory.

Explanation

With vnodes, a joining node is assigned num_tokens random token ranges. For each range it becomes a replica, it streams the range's data from an existing replica. It does not copy whole SSTables from a seed, because ownership is per range and may be spread across many nodes.

Question 10Cassandra Architecture and the Distributed Ring

In a cluster using vnodes, what is the primary effect of adding one node with the default num_tokens?

  1. The new node takes a share of token ranges and streams that data from current replicas. Correct answer.
  2. No data moves until the next nodetool repair is run manually.
  3. Only the seed node transfers data, because seed nodes own the entire ring by design.
  4. Every key is rehashed and each node rewrites its SSTables to match the new token map.

Explanation

Vnodes split the ring into many small ranges, so a new node claims many ranges rather than one large range. Existing replicas stream only the data for those ranges, and ownership shifts gradually across all nodes. This spreads the streaming load and avoids one node rebuilding the entire ring.

Question 11Cassandra Architecture and the Distributed Ring

A single-datacenter cluster uses the Murmur3Partitioner with vnodes. A row's partition key hashes to token T. How is the owner of that row's first replica determined?

  1. The node holding the highest token in the cluster, because it always closes the ring.
  2. The node whose token value is numerically closest to T, whether its token lies above or below T.
  3. The node that owns the first token range reached when walking clockwise from T, including the wrap-around range. Correct answer.
  4. The seed node whose token value happens to be nearest to T in the cluster topology.

Explanation

Ownership is determined by range containment, not by numeric proximity: the key is hashed to a token and the owning node is the first node whose token is greater than or equal to it, with the ring wrapping so that the smallest token also covers everything beyond the largest token. When RF is greater than one, the remaining replicas are the next distinct nodes clockwise, skipping nodes in the same rack or datacenter according to the snitch when a topology-aware strategy is used.

Question 12Cassandra Architecture and the Distributed Ring

How do Cassandra nodes learn about membership changes and endpoint states such as a peer being marked down?

  1. Gossip: each node periodically exchanges endpoint state with a small random set of peers. Correct answer.
  2. The partitioner embeds endpoint liveness into the token metadata stored for every range.
  3. A shared external registry such as ZooKeeper is polled by every node on a fixed schedule.
  4. An elected controller pushes a complete membership list to every node whenever state changes.

Explanation

Cassandra has no master node; membership and endpoint state spread through gossip, an epidemic protocol in which each node contacts a small random subset of peers every second and merges the state it receives. Because state propagates transitively, a change reaches the whole cluster within a few rounds even if no node talks to every other node directly.

Question 13Cassandra Architecture and the Distributed Ring

On a replica that receives a write, which structure makes the mutation durable before the memtable contents are flushed to disk?

  1. The commit log on the replica that received the write Correct answer.
  2. The SSTable data file holding the affected partition
  3. The row cache maintained by the coordinator
  4. The partition index of the table's oldest SSTable

Explanation

Every mutation is first appended to the commit log and then applied to the in-memory memtable; the commit log is what allows the write to survive a crash before the memtable is flushed to an immutable SSTable. The fsync behavior of the commit log is controlled by commitlog_sync, which decides whether the acknowledgement waits for disk or only for the page cache.

Question 14Cassandra Architecture and the Distributed Ring

A read targets one partition key on a node that holds several SSTables for the table. What does Cassandra consult first to skip SSTables that cannot possibly contain that partition?

  1. The partition index, which maps every stored key to a byte offset in the file
  2. The key cache, which records the partition keys most recently read from that SSTable
  3. The commit log segment that was active when the SSTable was written
  4. The bloom filter for each SSTable, which rules out partitions it does not hold Correct answer.

Explanation

Each SSTable carries a bloom filter, a compact probabilistic structure built from the partition keys it contains. A negative answer is definitive, so the SSTable is skipped without any disk read; a positive answer may be a false positive, in which case the partition index and then the data file are consulted.

Question 15Cassandra Architecture and the Distributed Ring

A client issues DELETE for a row in a table whose gc_grace_seconds is still at its default. What does Cassandra record at the moment of the delete?

  1. A tombstone with a deletion timestamp, written to the memtable and flushed into a new SSTable Correct answer.
  2. A hint written to the commit log for each replica that was temporarily unreachable
  3. An in-place edit of the affected cell's timestamp inside the existing SSTable file
  4. A purge of the row from the partition index followed by immediate compaction of affected SSTables

Explanation

Because SSTables are immutable, a delete becomes a new write: a tombstone marked with a deletion timestamp that shadows older cells with earlier timestamps. The tombstone and the data it covers are only reclaimed during compaction after gc_grace_seconds has elapsed, which is why that value must exceed the interval between repairs so the deletion reaches every replica first.

Question 16Cassandra Architecture and the Distributed Ring

During a digest read at QUORUM, two replicas return different digests for the same partition. What does the coordinator do next?

  1. It returns the value from whichever replica answered first and records a warning in the system log.
  2. It marks the partition inconsistent and triggers a major compaction on every replica in the datacenter.
  3. It fails the read with a read timeout and waits until nodetool repair has run on the affected range.
  4. It fetches full rows from the differing replicas, returns the newest cells, and repairs the stale replicas. Correct answer.

Explanation

A digest read first requests only hashes to avoid transferring full rows, and a mismatch tells the coordinator that replicas disagree. It then requests the actual data from the differing replicas, reconciles each cell by its timestamp, returns the newest version, and writes the winning version back to the stale replicas; at QUORUM this read repair is blocking, while at lower levels it can run in the background.

Question 17Cassandra Architecture and the Distributed Ring

A table uses the default SizeTieredCompactionStrategy with default settings. Which condition causes a compaction to be triggered?

  1. The table's SSTable count exceeds max_threshold, which defaults to 32 files.
  2. The oldest SSTable in the table reaches the age set by gc_grace_seconds.
  3. At least min_threshold SSTables of similar size have accumulated, where min_threshold defaults to 4. Correct answer.
  4. Any SSTable is found to contain tombstones older than the tombstone_threshold ratio.

Explanation

SizeTieredCompactionStrategy groups SSTables by size and starts a compaction once a bucket holds at least min_threshold SSTables, default 4. Its parameters are min_threshold, max_threshold (the largest number of SSTables merged in one compaction, default 32) and min_sstable_size, which sets the tolerance for what counts as similar size.

Question 18Cassandra Architecture and the Distributed Ring

An operator runs nodetool decommission on a node in a four-node single-datacenter cluster with RF=3. What does the node do?

  1. It streams its data to the nodes that will take over its ranges, then leaves the ring once the transfer finishes. Correct answer.
  2. It deletes its tokens and instructs clients to reconnect through the seed nodes on the next topology change.
  3. It shuts down at once and is marked DOWN, leaving the cluster under-replicated until a repair restores RF.
  4. It divides its token ranges evenly among all remaining nodes and stops without streaming any data.

Explanation

Decommission is a graceful removal: the node remains in the LEAVING state while it streams the data it owned to the nodes that become the new replicas for those ranges, and only then does it exit the ring. Because data is transferred first, replication is maintained; an abruptly stopped node instead requires nodetool removenode plus repair to restore the replication factor.

Question 19Cassandra Architecture and the Distributed Ring

Cassandra uses the Phi accrual failure detector to judge whether a peer is down. Which statement describes how it works?

  1. It samples heartbeat inter-arrival times and publishes a continuous suspicion value that rises as time passes since the last heartbeat, compared with phi_convict_threshold. Correct answer.
  2. It declares a peer down after a fixed count of missed gossip rounds, conventionally three consecutive rounds.
  3. It relies on operating-system TCP keepalive timeouts to decide when an endpoint should be marked down.
  4. It requires a majority of nodes to vote that the endpoint is unreachable before the peer is marked down.

Explanation

Rather than using a hard timeout, the Phi accrual detector keeps a distribution of heartbeat intervals and computes how many standard deviations the current silence is from the expected value, producing a value that grows the longer a peer stays quiet. When that value exceeds phi_convict_threshold, which defaults to 8, the node is marked down; raising the threshold makes the cluster tolerate longer pauses such as JVM garbage collection.

Question 20Cassandra Architecture and the Distributed Ring

A table enforces uniqueness with compare-and-set statements such as INSERT ... IF NOT EXISTS. Which consistency level gives the operation linearizable Paxos behaviour?

  1. ALL, because every replica in the cluster must acknowledge the proposal before it commits.
  2. SERIAL, or LOCAL_SERIAL when the operation should be confined to the local datacenter. Correct answer.
  3. ONE, because Paxos guarantees ordering once any single replica has received the proposal.
  4. QUORUM, applied to both the read phase and the write phase of the statement.

Explanation

Lightweight transactions run a Paxos consensus round, and the serial consistency level is what forces the statement through that round; ordinary levels such as QUORUM or ONE can skip consensus and therefore break the uniqueness guarantee. LOCAL_SERIAL restricts the Paxos quorum to the local datacenter, which the driver uses to avoid cross-datacenter latency when local linearizability is enough.

Question 21Cassandra Architecture and the Distributed Ring

In a Cassandra cluster that does not use virtual nodes, how is ownership of the token ring divided among nodes?

  1. Each node owns all tokens and filters writes by replication factor.
  2. Each node owns an equal-sized token range that is chosen by the snitch component.
  3. Token ranges are assigned dynamically per query by the coordinator.
  4. Each node owns the range from its token to the next node's token. Correct answer.

Explanation

Cassandra's partitioner maps each partition key to a token, and without vnodes each node owns exactly one token and the range from that token up to the next node's token. The snitch supplies topology information and does not allocate token ranges, and replication factor only controls how many copies are stored.

Question 22Cassandra Architecture and the Distributed Ring

A client opens a session to one node in a Cassandra cluster and sends a read request for a partition key whose replicas are on other nodes. What is that contacted node called, and what does it do?

  1. The repair node; it compares Merkle trees before answering the read.
  2. The snitch; it selects the closest replica by rack and forwards the read.
  3. The coordinator; it routes the read to the replicas and merges their responses. Correct answer.
  4. The seed node; it broadcasts the read to every node in the cluster.

Explanation

Any node that receives a client request can act as the coordinator. It computes the replicas for the partition key, forwards the request to them, and merges their responses before returning to the client.

Question 23Cassandra Architecture and the Distributed Ring

With virtual nodes enabled, what does the num_tokens property in cassandra.yaml control for a node?

  1. The number of seeds the node contacts during gossip.
  2. The number of concurrent client connections the node accepts.
  3. The number of token ranges the node owns. Correct answer.
  4. The number of SSTables the node compacts at once.

Explanation

When vnodes are enabled, num_tokens sets how many randomly assigned token ranges the node owns. Each range behaves like a smaller vnode, letting the node share the ring with other nodes and stream smaller ranges when topology changes.

Question 24Cassandra Architecture and the Distributed Ring

The Phi accrual failure detector judges a peer as down when the suspicion value exceeds a threshold. What is the default phi_convict_threshold?

  1. 8 Correct answer.
  2. 2
  3. 4
  4. 16

Explanation

The default phi_convict_threshold is 8. The Phi accrual failure detector marks a peer down when the accumulated suspicion exceeds that value; raising it makes the detector less sensitive, and lowering it makes it more sensitive.

Question 25Cassandra Architecture and the Distributed Ring

A node crashes before its memtables are flushed to SSTables. When the node restarts, how does Cassandra recover the mutations that were only in memory?

  1. It reads the SSTable index and applies the largest timestamps.
  2. It asks the coordinator to resend every write from the past hour.
  3. It streams the missing rows from the nearest seed node.
  4. It rebuilds the memtables by replaying commit log segments from disk. Correct answer.

Explanation

The commit log is the durable write-ahead log on each replica. On restart, Cassandra replays commit log segments into the memtables so mutations that were not yet flushed to SSTables are not lost.

Question 26Cassandra Architecture and the Distributed Ring

What happens when a Cassandra memtable exceeds its configured memory threshold?

  1. The node compacts all SSTables for the table into one merged file.
  2. It flushes the memtable to an SSTable and starts a fresh one. Correct answer.
  3. The node blocks all writes until the commit log is deleted.
  4. The node drops the oldest mutations to free memory.

Explanation

A memtable is flushed to a new immutable SSTable when it reaches its threshold, and a fresh memtable accepts subsequent writes. The commit log is then used to protect the new memtable, not deleted to unblock writes.

Question 27Cassandra Architecture and the Distributed Ring

A coordinator receives a write for a partition key. How does it determine which nodes should store the mutation?

  1. It asks the snitch to rank all nodes by latency and chooses the fastest ones.
  2. It uses the partitioner to compute the token and the keyspace replication strategy to identify replicas. Correct answer.
  3. It writes to every node in the datacenter and relies on compaction to discard extra copies.
  4. It consults the gossip digest to find nodes with the least data.

Explanation

The coordinator hashes the partition key with the table's partitioner to get a token, then applies the keyspace's replication strategy to map that token to replica endpoints. The snitch supplies topology, but it does not choose replicas for a write.

Question 28Cassandra Architecture and the Distributed Ring

A row is updated in a Cassandra table that already has several SSTables. How does Cassandra apply the update?

  1. It deletes all SSTables for the table before writing the new value.
  2. It writes the new mutation to a memtable, later flushed to a new SSTable. Correct answer.
  3. It locates the existing row in the SSTable and overwrites those bytes in place.
  4. It modifies the SSTable index only and leaves the data file unchanged.

Explanation

SSTables are immutable, so an update cannot overwrite bytes in place. Cassandra writes the new mutation to the memtable with a newer timestamp, and a later flush creates a new SSTable; reads and compaction reconcile the versions.

Question 29Cassandra Architecture and the Distributed Ring

A single-datacenter cluster uses Murmur3Partitioner without vnodes. A node's token is the largest possible token value. Which range does that node own?

  1. From its own token to the next larger token, which is outside the ring.
  2. From the smallest token to its own token.
  3. Only the exact token value it was assigned.
  4. From its token to the smallest token, wrapping around the ring. Correct answer.

Explanation

Tokens form a ring, so the node holding the largest token owns the range from that token forward, wrapping around to the smallest token. The next node clockwise owns the range from the smallest token onward, not this node.

Question 30Cassandra Architecture and the Distributed Ring

What distinguishes incremental repair from a full repair in Cassandra?

  1. Incremental repair replaces Merkle tree comparison with hinted handoff.
  2. It processes only SSTables not yet repaired, using repair history. Correct answer.
  3. Incremental repair transfers all data to a new node during bootstrap.
  4. Incremental repair repairs only the primary token range of each node.

Explanation

Incremental repair uses repair history to distinguish repaired from unrepaired SSTables and processes only the unrepaired ones. Full repair compares all data for the ranges being repaired, regardless of prior repair state.

Question 31Installation, Configuration, and Cluster Provisioning

You are preparing cassandra.yaml for a new node that will join an existing cluster. Which setting must hold the IP addresses of existing nodes so the joining node can perform the gossip handshake and learn the ring?

  1. seed_provider → parameters → seeds Correct answer.
  2. broadcast_address
  3. listen_address
  4. native_transport_port

Explanation

The seeds list under seed_provider gives a joining node the contact points used for the initial gossip handshake; from those endpoints it learns every other node in the cluster. All nodes should carry the same short list of stable addresses, ideally at least one per data center, rather than every node in the ring.

Question 32Installation, Configuration, and Cluster Provisioning

A firewall change requires you to open only the port used by the Cassandra native transport for CQL clients. Which default port must be opened?

  1. 7000
  2. 9042 Correct answer.
  3. 9160
  4. 7199

Explanation

The native transport (CQL binary protocol) listens on 9042 by default, controlled by native_transport_port. Port 7000 carries internode gossip and streaming traffic (7001 when internode encryption is enabled), 7199 serves JMX, and 9160 was the legacy Thrift port that was removed in Cassandra 4.0.

Question 33Installation, Configuration, and Cluster Provisioning

You want each node in a Cassandra 4.0 cluster to own many small, roughly equal token ranges instead of one large range. Which cassandra.yaml parameter controls the number of ranges per node?

  1. initial_token
  2. num_tokens Correct answer.
  3. auto_bootstrap
  4. partitioner

Explanation

num_tokens sets how many random token ranges each node owns when using virtual nodes; it defaults to 16 in Cassandra 3.x and 4.x. Setting it to 1 reverts to the single-token model, in which initial_token must be computed and assigned manually for every node.

Question 34Installation, Configuration, and Cluster Provisioning

You are provisioning a two-data-center cluster with multiple racks per data center, and you want each node to read its own data center and rack from cassandra-rackdc.properties and share that information through gossip. Which endpoint_snitch should you set?

  1. SimpleSnitch
  2. GossipingPropertyFileSnitch Correct answer.
  3. PropertyFileSnitch
  4. Ec2Snitch

Explanation

GossipingPropertyFileSnitch reads the dc and rack values from cassandra-rackdc.properties on each node and propagates them through gossip, so you do not maintain a full topology file on every host. This is the standard choice for multi-DC, multi-rack deployments that are not running on EC2 with region/AZ-derived topology.

Question 35Installation, Configuration, and Cluster Provisioning

A cluster has three nodes in dc1 and three nodes in dc2, both registered by a rack-aware snitch. Which statement creates a keyspace that keeps exactly two replicas in each data center?

  1. CREATE KEYSPACE app WITH replication = {'class':'NetworkTopologyStrategy','replication_factor':2};
  2. CREATE KEYSPACE app WITH replication = {'class':'NetworkTopologyStrategy','dc1':2,'dc2':2}; Correct answer.
  3. CREATE KEYSPACE app WITH replication = {'class':'LocalStrategy','dc1':2,'dc2':2};
  4. CREATE KEYSPACE app WITH replication = {'class':'SimpleStrategy','replication_factor':2};

Explanation

NetworkTopologyStrategy takes an explicit replica count per data center, keyed by the data center names the snitch reports, so dc1 and dc2 each get two replicas. The names are case-sensitive and must match the values configured in cassandra-rackdc.properties or the equivalent snitch source.

Question 36Installation, Configuration, and Cluster Provisioning

You are enabling password authentication on a five-node cluster. Which change should you make to the system_auth keyspace before relying on roles in production?

  1. Drop and recreate the keyspace so it inherits the replication settings of the application keyspace.
  2. Set its replication factor to 0 so each node stores role data only in local memory.
  3. Alter it to NetworkTopologyStrategy with replication factor 3, then run nodetool repair on it. Correct answer.
  4. Leave it on SimpleStrategy with replication factor 1, because system keyspaces are replicated automatically.

Explanation

system_auth defaults to SimpleStrategy with replication factor 1, so if the single replica is down, authentication and authorization lookups can fail cluster-wide. Raise the replication factor with NetworkTopologyStrategy, then run repair so every existing node receives the role data for the ranges it now owns.

Question 37Installation, Configuration, and Cluster Provisioning

You are installing Apache Cassandra 4.0 from the binary tarball on a new host. Which Java runtime versions does this release support?

  1. Java 17 or Java 21
  2. Java 11 only
  3. Java 8 or Java 11 Correct answer.
  4. Java 8 only

Explanation

Cassandra 4.0 supports Java 8 and Java 11; support for Java 17 arrived in later releases, and Cassandra 5.0 requires Java 11 or 17. Installing an unsupported JDK typically produces startup failures or obscure errors in the JVM options files rather than a clean message.

Question 38Installation, Configuration, and Cluster Provisioning

Each node in a cluster binds internode traffic to a private 10.x address, but peers outside the network must reach it through a NAT public address. Which configuration pair is correct?

  1. listen_address set to the private address; broadcast_address set to the public address Correct answer.
  2. listen_address set to the private address; broadcast_address set to 0.0.0.0
  3. listen_address set to the public address; broadcast_address set to the private address
  4. listen_address set to 0.0.0.0; broadcast_address set to the private address

Explanation

listen_address is the local interface the node binds, while broadcast_address is what the node tells other nodes to use when connecting to it. Binding to the private interface and advertising the NAT address lets local traffic stay private while remote peers reach the correct endpoint. The same pattern applies to client traffic via rpc_address or native_transport_address paired with broadcast_rpc_address.

Question 39Installation, Configuration, and Cluster Provisioning

One node in dc2 was provisioned with dc=DC2 in cassandra-rackdc.properties while every other node in that data center uses dc=dc2. The node starts and joins gossip without error. What is the operational result?

  1. Cassandra normalizes data center names to lowercase at startup, so the node behaves exactly like the other dc2 nodes.
  2. The node is refused at bootstrap because gossip rejects any node whose data center name differs from the cluster's configured name.
  3. The node is treated as a separate data center, so NetworkTopologyStrategy places no replicas there and LOCAL_QUORUM queries on it cannot reach consistency. Correct answer.
  4. Replicas still land in dc2, but the node is skipped for local reads until the value is corrected.

Explanation

Data center names reported by the snitch are case-sensitive, so DC2 is a distinct data center from dc2 as far as replica placement is concerned. Because the keyspace's NetworkTopologyStrategy options name dc2 only, that node receives no replicas, and LOCAL_QUORUM reads sent to it fail with insufficient live replicas. Correcting cassandra-rackdc.properties and restarting the node resolves the mismatch.

Question 40Installation, Configuration, and Cluster Provisioning

You raise a keyspace's replication factor from 2 to 3 and run nodetool repair. Some original nodes still store data for token ranges they no longer own. Which command should you run on each affected node to reclaim that disk space?

  1. nodetool cleanup Correct answer.
  2. nodetool rebuild
  3. nodetool scrub
  4. nodetool compact

Explanation

nodetool cleanup removes the SSTable data a node holds for token ranges it no longer owns, which is exactly what happens after a replication factor increase or a topology change such as adding nodes. Run it one node at a time and monitor disk usage, since cleanup rewrites SSTables and temporarily needs extra headroom.

Question 41Installation, Configuration, and Cluster Provisioning

You install Cassandra 4.0 from the Debian package on a new host. Where does the package place the node's data files by default?

  1. /etc/cassandra
  2. /opt/cassandra/data
  3. /var/log/cassandra
  4. /var/lib/cassandra Correct answer.

Explanation

Debian and RPM packages follow the filesystem hierarchy: configuration lives under /etc/cassandra, logs under /var/log/cassandra, and the data, commitlog, hints, and saved caches directories default under /var/lib/cassandra. The tarball layout is different, but the packaged service expects these paths.

Question 42Installation, Configuration, and Cluster Provisioning

A new node repeatedly logs a ClusterName mismatch error and never joins the existing cluster. Which cassandra.yaml value should you correct on the new node?

  1. cluster_name Correct answer.
  2. storage_port
  3. num_tokens
  4. partitioner

Explanation

Cassandra compares cluster_name during the gossip handshake; a node whose value differs from the cluster's will not join. Set cluster_name to the exact same string used by the existing nodes and restart the node.

Question 43Installation, Configuration, and Cluster Provisioning

You are defining security-group rules for a new Cassandra 4.0 cluster and need to allow internode gossip and data streaming. Which TCP port is used by default for internode communication?

  1. 7000 Correct answer.
  2. 7199
  3. 9160
  4. 9042

Explanation

Cassandra uses TCP 7000 for internode communication, including gossip and streaming, by default. Port 9042 is the native transport for CQL clients, 7199 is JMX, and 9160 was the legacy Thrift port removed in 4.0.

Question 44Installation, Configuration, and Cluster Provisioning

You are configuring seed_provider for a 12-node cluster spread across two data centers. Which seeding practice is recommended?

  1. List a small, stable set of nodes, ideally one to three per data center. Correct answer.
  2. List the broadcast_address of every node so seeds follow IP changes.
  3. List all 12 nodes as seeds so any node can bootstrap from any peer.
  4. List only the first node in each rack as a seed to keep the list short.

Explanation

Seeds are contact points for gossip, not a full membership list, so a small stable set is best. Including one to three seeds per data center helps new nodes in each DC find the cluster without making every node a seed.

Question 45Installation, Configuration, and Cluster Provisioning

You want each write to be fsynced to the commitlog individually before the coordinator acknowledges it, accepting lower throughput for maximum durability. Which commitlog_sync value should you set?

  1. group
  2. batch Correct answer.
  3. none
  4. periodic

Explanation

commitlog_sync: batch blocks each write until its commitlog entry is fsynced, giving the strongest per-write durability at a throughput cost. periodic fsyncs on a timer, and group batches fsyncs across writes before acknowledging them.

Question 46Installation, Configuration, and Cluster Provisioning

Which cassandra.yaml setting must be identical on every node and cannot be changed later without rewriting all existing data?

  1. partitioner Correct answer.
  2. num_tokens
  3. endpoint_snitch
  4. cluster_name

Explanation

All nodes in a cluster must use the same partitioner, which determines how data maps to tokens. Changing the partitioner would invalidate existing token assignments and require a full data rewrite, so it is chosen at cluster creation.

Question 47Installation, Configuration, and Cluster Provisioning

You need nodetool on an administration host to connect to a remote Cassandra node's JMX interface. Which file should you edit to enable remote JMX access?

  1. jvm.options
  2. cassandra-env.sh Correct answer.
  3. cassandra.yaml
  4. logback.xml

Explanation

JMX-related JVM options, including remote JMX and authentication settings, are configured in cassandra-env.sh. cassandra.yaml covers node and cluster settings such as ports, snitches, and directories, not the JMX listener.

Question 48Installation, Configuration, and Cluster Provisioning

In Cassandra 4.0, which cassandra.yaml setting allocates tokens using the local data center's replication factor to reduce token imbalance?

  1. partitioner
  2. num_tokens
  3. allocate_tokens_for_local_replication_factor Correct answer.
  4. initial_token

Explanation

allocate_tokens_for_local_replication_factor tells Cassandra to compute token assignments that account for the replication factor of the local data center, improving balance. It is used with vnodes and replaces the older keyspace-based allocation approach.

Question 49Installation, Configuration, and Cluster Provisioning

A node in a three-node cluster is permanently lost, and you will reuse its IP address for the replacement. Which startup option should you use on the replacement node's first boot to take over the dead node's data without duplicating it?

  1. -Dcassandra.auto_bootstrap=false
  2. -Dcassandra.skip_warmup=true
  3. -Dcassandra.replace_address_first_boot=<dead_ip> Correct answer.
  4. -Dcassandra.join_ring=false

Explanation

replace_address_first_boot tells the replacement node to take over the token ranges of the dead node and stream only the data it is missing, avoiding a duplicate copy. It must be used on the first boot with the dead node's IP and only while the original node is permanently gone.

Question 50Installation, Configuration, and Cluster Provisioning

You must encrypt all traffic between Cassandra nodes, including gossip and streaming, while leaving CQL client connections unchanged. Which cassandra.yaml configuration should you apply?

  1. client_encryption_options with enabled: true
  2. server_encryption_options with internode_encryption: dc
  3. server_encryption_options with internode_encryption: all Correct answer.
  4. server_encryption_options with internode_encryption: rack

Explanation

server_encryption_options controls internode encryption, and internode_encryption: all encrypts all node-to-node traffic, including gossip and streaming. client_encryption_options is separate and applies to CQL clients.