I85PREP
⌘ K
Cassandra K8s study materials
Cassandra K8s study resources

Cassandra K8s practice questions

One question at a time. Build your Cassandra K8s 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 1Kubernetes fundamentals for stateful workloads

A team wants to run an Apache Cassandra node inside Kubernetes. Which workload controller is the standard choice for a stateful database node that needs a stable network identity and its own persistent storage?

  1. A bare Pod with an emptyDir volume
  2. A Deployment with a shared ReadWriteMany volume
  3. A StatefulSet with a volumeClaimTemplates entry Correct answer.
  4. A DaemonSet with a hostPath mount

Explanation

StatefulSet is the controller designed for stateful workloads: it gives each replica a stable ordinal-based pod name, a stable DNS subdomain, and its own PersistentVolumeClaim per replica when volumeClaimTemplates is used. This satisfies the identity and per-node storage needs of a Cassandra node.

Question 2Kubernetes fundamentals for stateful workloads

In a StatefulSet named cassandra with three replicas and a headless Service named cassandra, what DNS name does Kubernetes publish for the pod with ordinal 1?

  1. cassandra-1.cassandra.default.svc.cluster.local Correct answer.
  2. cassandra.cassandra-1.svc.cluster.local
  3. cassandra.1.default.svc.cluster.local
  4. cassandra-1.default.svc.cluster.local

Explanation

StatefulSet pods receive a stable DNS entry of the form <pod-name>.<governing-service>.<namespace>.svc.cluster.local when a headless Service governs the set. Because the pod name is cassandra-1, the full name is cassandra-1.cassandra.default.svc.cluster.local.

Question 3Kubernetes fundamentals for stateful workloads

Which Service type is required for a StatefulSet to publish per-pod DNS records that allow Cassandra nodes to discover one another by stable hostname?

  1. Headless with clusterIP: None Correct answer.
  2. ExternalName
  3. LoadBalancer
  4. ClusterIP with a fixed IP

Explanation

A headless Service (clusterIP: None) does not allocate a virtual IP; instead DNS returns the individual pod addresses. This is what enables per-pod A records such as cassandra-0.cassandra and lets Cassandra seeds resolve peers by stable name.

Question 4Kubernetes fundamentals for stateful workloads

A Cassandra StatefulSet defines volumeClaimTemplates. When the pod cassandra-2 is deleted and later recreated by the controller, what happens to its storage?

  1. The existing PVC cassandra-data-cassandra-2 is reattached to the new pod Correct answer.
  2. A new empty PVC is provisioned and prior data is lost
  3. The PVC is deleted together with the pod by default
  4. The data is copied into an emptyDir for the new pod

Explanation

volumeClaimTemplates creates a PVC whose name combines the template name and the pod name, and the controller reuses that same claim when the pod is recreated. Data therefore persists across pod restarts and rescheduling as long as the PVC is retained.

Question 5Kubernetes fundamentals for stateful workloads

An operator needs each Cassandra replica scheduled on a different Kubernetes node so a single node failure cannot take out multiple replicas. Which mechanism enforces this?

  1. A podAffinity rule with topologyKey kubernetes.io/hostname
  2. A topologySpreadConstraint with whenUnsatisfiable: ScheduleAnyway
  3. A podAntiAffinity rule with topologyKey kubernetes.io/hostname Correct answer.
  4. A nodeSelector matching a single node label

Explanation

Pod anti-affinity with topologyKey kubernetes.io/hostname tells the scheduler to avoid placing pods that match the selector on the same node. That spreads StatefulSet replicas across nodes and reduces correlated failure.

Question 6Kubernetes fundamentals for stateful workloads

What is the default pod management policy for a StatefulSet, and how does it affect startup?

  1. Parallel, so all pods start at once
  2. OrderedReady, so each pod starts only after the previous ordinal is Ready Correct answer.
  3. Random, so ordinals start in arbitrary order
  4. Manual, so an operator must start each pod

Explanation

The default is OrderedReady, which creates pods in ascending ordinal order and waits for each to become Ready before starting the next. This matters for databases that bootstrap sequentially, such as a Cassandra seed node coming up before the rest.

Question 7Kubernetes fundamentals for stateful workloads

During scale-down of a Cassandra StatefulSet from five to three replicas, in what order are pods removed?

  1. Random order chosen by the scheduler
  2. Lowest ordinal first, starting with cassandra-0
  3. All removed at once, then three recreated
  4. Highest ordinal first, starting with cassandra-4 Correct answer.

Explanation

StatefulSet scale-down removes pods in reverse ordinal order, so cassandra-4 is deleted first, then cassandra-3. Operators must therefore ensure data is decommissioned from the highest-ordinal node before it is terminated.

Question 8Kubernetes fundamentals for stateful workloads

Which resource object represents a request for storage that a Cassandra pod mounts, and which is typically satisfied by a CSI driver?

  1. ConfigMap
  2. PersistentVolumeClaim Correct answer.
  3. ServiceAccount
  4. StorageClass

Explanation

A PersistentVolumeClaim is the namespaced request for storage that a pod references in its volumes list. The claim is dynamically bound to a PersistentVolume provisioned through a StorageClass and CSI driver.

Question 9Kubernetes fundamentals for stateful workloads

A Cassandra pod is stuck in Pending with the event 'pod has unbound immediate PersistentVolumeClaims'. Which cause is most consistent with this message?

  1. The referenced StorageClass has no provisioner or cannot provision a volume Correct answer.
  2. The readiness probe is failing
  3. The container image tag does not exist
  4. The pod's CPU request exceeds the node capacity

Explanation

The event indicates the PVC could not be bound, which points at the storage layer rather than the container. A missing or misconfigured StorageClass, or a provisioner that cannot satisfy the claim, leaves the PVC unbound and the pod Pending.

Question 10Kubernetes fundamentals for stateful workloads

Why is a ReadWriteOnce PersistentVolume generally acceptable for a Cassandra StatefulSet with volumeClaimTemplates?

  1. Because Cassandra writes only to memory and never to disk
  2. Because RWO allows unlimited concurrent writers across nodes
  3. Because each replica mounts its own distinct claim rather than sharing one Correct answer.
  4. Because RWO volumes are always replicated across zones

Explanation

ReadWriteOnce permits the volume to be mounted read-write by a single node at a time. Since each StatefulSet replica gets its own PVC, no two nodes need to mount the same volume, so RWO is sufficient and avoids the complexity of shared filesystems.

Question 11Kubernetes fundamentals for stateful workloads

Which Kubernetes object is the recommended place to store the Cassandra cluster name and seed list so they can be injected into pods as environment variables?

  1. A NetworkPolicy
  2. A ResourceQuota
  3. A Secret with base64-encoded values
  4. A ConfigMap Correct answer.

Explanation

ConfigMaps hold non-sensitive configuration data such as cluster names and seed hostnames, and they can be consumed as environment variables or mounted files. Secrets are intended for sensitive material like passwords, not ordinary configuration.

Question 12Kubernetes fundamentals for stateful workloads

A Cassandra container needs its heap size derived from the container's CPU limit rather than the node's total memory. Which field should be set so the JVM sizing is based on the pod's limits?

  1. Set hostNetwork: true
  2. Set resources.limits.cpu and resources.limits.memory on the container Correct answer.
  3. Set spec.nodeName to a large node
  4. Set terminationGracePeriodSeconds to a large value

Explanation

Resource limits on the container are what the kubelet enforces and what container-aware JVM sizing reads. Setting memory and CPU limits lets the JVM and Cassandra size heaps and thread pools to the container rather than the whole node.

Question 13Kubernetes fundamentals for stateful workloads

What is the purpose of setting a sufficiently long terminationGracePeriodSeconds on a Cassandra pod?

  1. To give the process time to flush and shut down cleanly before SIGKILL Correct answer.
  2. To delay image pulls until the grace period ends
  3. To extend the readiness probe timeout
  4. To prevent the pod from being rescheduled to another node

Explanation

When a pod is deleted, the kubelet sends SIGTERM and waits up to terminationGracePeriodSeconds before sending SIGKILL. Cassandra needs that window to drain, flush memtables, and stop gracefully, reducing data-repair work after restarts.

Question 14Kubernetes fundamentals for stateful workloads

Which probe should be configured to check that a Cassandra node has joined the ring and can serve queries before it receives traffic?

  1. A liveness probe that restarts the pod on the first failed check
  2. A liveness probe only
  3. A startup probe that disables all other probes
  4. A readiness probe that runs a CQL or nodetool status check Correct answer.

Explanation

A readiness probe determines whether the pod is added to Service endpoints. Checking CQL connectivity or nodetool status ensures a node that has not joined the ring is kept out of traffic until it is actually serving.

Question 15Kubernetes fundamentals for stateful workloads

A Cassandra pod's liveness probe uses a short timeout and low failureThreshold, and the pod restarts repeatedly under heavy compaction load. What is the most appropriate fix?

  1. Increase failureThreshold and timeoutSeconds, or rely on readiness for traffic gating Correct answer.
  2. Remove all probes so the pod is never restarted
  3. Reduce the grace period to zero
  4. Set the liveness probe to exec a full nodetool repair

Explanation

Liveness probes should detect truly stuck processes, not transient slowness. Raising failureThreshold and timeoutSeconds, or moving load-sensitive checks to readiness, prevents restarts caused by temporary compaction pressure.

Question 16Kubernetes fundamentals for stateful workloads

Which Kubernetes construct lets you run a periodic nodetool cleanup or snapshot job outside the Cassandra pod lifecycle?

  1. A CronJob Correct answer.
  2. A LimitRange
  3. A ReplicaSet
  4. An Ingress

Explanation

A CronJob creates Jobs on a schedule, which is suitable for recurring maintenance such as snapshots or cleanup. The Job pod can run nodetool against the cluster and then terminate.

Question 17Kubernetes fundamentals for stateful workloads

A Cassandra StatefulSet uses a headless Service, but clients outside the cluster need a single stable entry point. Which approach is most appropriate?

  1. Set clusterIP: None on the client Service as well
  2. Add a separate ClusterIP or LoadBalancer Service that selects the same pods Correct answer.
  3. Convert the StatefulSet to a Deployment
  4. Change the headless Service to NodePort

Explanation

The headless Service is needed for per-pod DNS and peer discovery. A separate Service with a virtual IP or external load balancer can select the same pods to give clients a stable endpoint without disturbing StatefulSet identity.

Question 18Kubernetes fundamentals for stateful workloads

What does the spec.serviceName field on a StatefulSet reference?

  1. The ServiceAccount used by the pods
  2. The headless Service that governs the pods' network identity Correct answer.
  3. The Ingress resource for the cluster
  4. The external load balancer name

Explanation

spec.serviceName names the Service that governs the StatefulSet, normally a headless Service. Kubernetes uses it to build the stable pod DNS names and to set the pods' hostname and subdomain fields.

Question 19Kubernetes fundamentals for stateful workloads

An operator wants to change the storage size requested by volumeClaimTemplates on an existing Cassandra StatefulSet. What is the practical result?

  1. All pods are recreated with new empty volumes
  2. Existing PVCs are resized automatically to the new template value
  3. The template change does not resize existing PVCs; each PVC must be expanded individually Correct answer.
  4. The StatefulSet is rejected by the API server

Explanation

volumeClaimTemplates is effectively immutable for existing claims; editing the template only affects newly created PVCs. To grow storage you must patch each existing PVC, which also requires a StorageClass that allows volume expansion.

Question 20Kubernetes fundamentals for stateful workloads

Which setting on a StorageClass is required for a CSI-backed volume to be growable after creation?

  1. mountOptions: [noatime]
  2. volumeBindingMode: WaitForFirstConsumer
  3. allowVolumeExpansion: true Correct answer.
  4. reclaimPolicy: Delete

Explanation

The allowVolumeExpansion field on the StorageClass permits users to increase the size of PVCs created from it. Without it, expansion requests on the claim are rejected.

Question 21Kubernetes fundamentals for stateful workloads

A Cassandra pod is evicted and rescheduled to a different node, but its volume is still attached to the old node. Which component is responsible for detaching and reattaching the volume during this move?

  1. The CSI attach/detach controller and kubelet on the target node Correct answer.
  2. The CoreDNS plugin
  3. The HorizontalPodAutoscaler
  4. The kube-scheduler alone

Explanation

Volume attach and detach for CSI volumes is coordinated by the external-attacher sidecar and the attach/detach controller, while the kubelet on the target node performs the final mount. This ensures the volume is released from the old node before being attached elsewhere.

Question 22Kubernetes fundamentals for stateful workloads

Which field lets you control the order in which a pod's containers start, so an init container can run before the Cassandra container?

  1. spec.initContainers Correct answer.
  2. spec.restartPolicy
  3. spec.ephemeralContainers
  4. spec.shareProcessNamespace

Explanation

Init containers run to completion in order before any app containers start. They are commonly used to wait for peers, set permissions, or prepare configuration before the Cassandra process launches.

Question 23Kubernetes fundamentals for stateful workloads

Which NetworkPolicy design best restricts access so that only Cassandra pods can reach the CQL port 9042 on other Cassandra pods?

  1. A deny-all policy with no follow-up allow rules
  2. An egress rule allowing all traffic to 0.0.0.0/0
  3. An ingress rule allowing all ports from all namespaces
  4. An ingress rule allowing port 9042 from pods labeled app=cassandra Correct answer.

Explanation

A NetworkPolicy ingress rule that permits port 9042 only from pods with the Cassandra label limits CQL traffic to cluster peers. This is the least-privilege pattern for a database that should not expose its CQL port broadly.

Question 24Kubernetes fundamentals for stateful workloads

Why is using a StatefulSet preferred over a Deployment when each Cassandra node must retain the same persistent volume and hostname across restarts?

  1. Deployments cannot mount persistent volumes at all
  2. Deployments always run pods on the control plane
  3. Deployments do not support container images
  4. Deployments use random pod names and shared ReplicaSet semantics, so identity and volume binding are not stable Correct answer.

Explanation

Deployment pods get generated names and are managed by ReplicaSets, so a restarted pod is a different identity that may bind a different volume. StatefulSet pins ordinal identity and the matching PVC, which Cassandra needs for ring membership and data locality.

Question 25Cassandra architecture and data modeling review

In Cassandra's storage engine, which on-disk structure stores the actual cell values for a table's rows and is made immutable once flushed?

  1. The system.paxos table
  2. The commitlog segment
  3. The SSTable Correct answer.
  4. The hinted handoff queue

Explanation

SSTables are immutable sorted files written when a memtable is flushed; all row data ultimately lives in one or more SSTables. The commitlog is a durability journal replayed on restart, not the long-term data store.

Question 26Cassandra architecture and data modeling review

A table is declared with PRIMARY KEY ((region, tenant), user_id, event_time). Which component or components form the partition key?

  1. region and tenant together Correct answer.
  2. event_time only
  3. user_id only
  4. user_id and event_time together

Explanation

The first element of the primary key in parentheses is the composite partition key, so region and tenant jointly determine the partition. Columns after it are clustering columns and only order rows within a partition.

Question 27Cassandra architecture and data modeling review

Which statement about the Cassandra commitlog is accurate?

  1. It must be replayed in full on every node restart regardless of flush state
  2. It is a per-node append-only log used to recover writes not yet persisted in SSTables Correct answer.
  3. It is truncated for a table as soon as that table's memtable is flushed to disk
  4. It can be disabled on a node to improve write throughput without any durability consequence

Explanation

Each node appends mutations to its commitlog before acknowledging, and on restart only the segments covering unflushed data are replayed. Once all data referenced by a segment is in SSTables, that segment becomes eligible for deletion.

Question 28Cassandra architecture and data modeling review

What is the primary purpose of compaction in Cassandra?

  1. To replicate writes to additional nodes when a replica is down
  2. To compress the commitlog before it is replayed
  3. To merge SSTables, discard tombstones and superseded cells, and reduce read amplification Correct answer.
  4. To rebuild the partition index in memory after each read

Explanation

Compaction merges multiple SSTables into fewer, larger ones while dropping obsolete versions and expired tombstones. This keeps the number of files a read must consult bounded and reclaims disk space.

Question 29Cassandra architecture and data modeling review

A single Cassandra partition on one node grows to hundreds of thousands of rows and reads on it slow down. Which explanation best fits how Cassandra stores a partition?

  1. Each row of a partition is stored in its own separate SSTable
  2. Partition rows are kept only in the memtable and never flushed individually
  3. All rows of a partition are stored contiguously and read sequentially within a partition Correct answer.
  4. Rows of a partition are spread across all SSTables in hash order

Explanation

Cassandra stores the rows of a partition together, sorted by clustering columns, so reading a large partition means scanning many cells from one place. Very wide partitions therefore raise read latency and memory pressure during queries.

Question 30Cassandra architecture and data modeling review

Which replication strategy should be used for a keyspace whose nodes span multiple data centers?

  1. EverywhereStrategy with replication_factor 1
  2. SimpleStrategy with replication_factor 3
  3. LocalStrategy on every node
  4. NetworkTopologyStrategy with a replication factor per data center Correct answer.

Explanation

NetworkTopologyStrategy lets you set a separate replica count for each data center and places replicas on distinct racks, so a rack or DC failure does not take out all copies. SimpleStrategy ignores topology and is intended only for single-DC clusters.

Question 31Cassandra architecture and data modeling review

A query filters on a non-primary-key column with WHERE status = 'OPEN'. What must be true for this query to be efficient without ALLOW FILTERING?

  1. The column must be indexed or part of a materialized view designed for that access pattern Correct answer.
  2. The table must use SimpleStrategy with replication_factor 1
  3. The column must be the first clustering column of the table
  4. The column must be declared with the counter type

Explanation

Cassandra can only locate rows by partition key and clustering columns directly; filtering on other columns requires scanning partitions unless a secondary index or a purpose-built view exists. ALLOW FILTERING merely permits the scan rather than making it efficient.

Question 32Cassandra architecture and data modeling review

Which write pattern produces the most even distribution of data across a cluster?

  1. A partition key that is a monotonically increasing timestamp
  2. A partition key derived from a high-cardinality identifier such as a user UUID Correct answer.
  3. A partition key that is always the same constant string
  4. A partition key that is a low-cardinality status value with a handful of distinct values

Explanation

Cassandra hashes the partition key to place data, so a high-cardinality key spreads rows across many partitions and nodes. Low-cardinality or monotonic keys concentrate data into few partitions or hot spots.

Question 33Cassandra architecture and data modeling review

A table stores sensor readings keyed by ((sensor_id), reading_time) and the application must fetch the latest reading for a sensor. Which query best matches the data model?

  1. SELECT * FROM readings WHERE sensor_id = ? AND reading_time = ?
  2. SELECT * FROM readings WHERE reading_time = ?
  3. SELECT * FROM readings WHERE sensor_id = ? ORDER BY reading_time DESC LIMIT 1 Correct answer.
  4. SELECT * FROM readings WHERE reading_time > ? ALLOW FILTERING

Explanation

Because sensor_id is the partition key and reading_time is the clustering column, rows are stored in clustering order and can be read in reverse with LIMIT 1 to get the newest reading from a single partition. The other forms either filter on a non-key column or require an exact clustering value.

Question 34Cassandra architecture and data modeling review

Why does Cassandra discourage very large partitions in a Kubernetes-hosted cluster with limited pod memory?

  1. Reading or repairing a large partition loads many cells into memory on the handling node at once Correct answer.
  2. Large partitions are automatically split across nodes by the coordinator
  3. Large partitions force NetworkTopologyStrategy to reduce replication factor
  4. Large partitions prevent the commitlog from being written

Explanation

A partition is the unit of storage and routing, so a query or repair touching a huge partition pulls a large amount of data into memory on one node. With constrained container memory this can cause GC pressure or OOM kills.

Question 35Cassandra architecture and data modeling review

A team needs to read the same data by user_id and by email. Which Cassandra-native approach best supports both access patterns?

  1. Model two tables, one keyed by user_id and one keyed by email, and write to both Correct answer.
  2. Store email as a static column and query it without a WHERE clause
  3. Use ALLOW FILTERING on email queries against the user_id table
  4. Add a secondary index on email and rely on it for all email lookups at scale

Explanation

Query-first modeling creates one table per access pattern, each with the appropriate partition key, and the application writes to each. This keeps reads single-partition and avoids cluster-wide scans.

Question 36Cassandra architecture and data modeling review

What does a tombstone represent in Cassandra, and why can many tombstones hurt read performance?

  1. A compressed block header that must be decompressed on every read
  2. A deleted cell or row marker that must be scanned and reconciled until compaction purges it Correct answer.
  3. A commitlog record that is replayed before serving reads
  4. A replica that has fallen behind and is excluded from reads

Explanation

Deletes write tombstones rather than removing data immediately, because the deletion must propagate to replicas holding older versions. Until compaction drops them past gc_grace_seconds, reads must scan and discard tombstoned cells, which adds latency.

Question 37Cassandra architecture and data modeling review

A write is sent with consistency level QUORUM to a keyspace with replication_factor 3 in one data center. How many replica acknowledgements are required before the coordinator responds with success?

  1. Two Correct answer.
  2. Three
  3. All replicas in every data center
  4. One

Explanation

QUORUM means a majority of the replicas in the queried data center, which for RF 3 is two. This gives overlap with a read at QUORUM so the read set intersects the write set.

Question 38Cassandra architecture and data modeling review

Which consistency combination guarantees that a read always sees the most recent acknowledged write for a single partition?

  1. Write at QUORUM, read at QUORUM Correct answer.
  2. Write at QUORUM, read at ONE
  3. Write at ANY, read at QUORUM
  4. Write at ONE, read at ONE

Explanation

When write and read quorums overlap (W + R > RF), the read set includes at least one replica that acknowledged the write, and timestamps resolve the newest value. Write QUORUM plus read QUORUM with RF 3 satisfies this.

Question 39Cassandra architecture and data modeling review

What is the role of a Cassandra node acting as coordinator for a client request?

  1. It routes the request to the replicas that own the partition and assembles the response Correct answer.
  2. It permanently stores all data for the keyspace it coordinates
  3. It rewrites the client's CQL into an SSTable before execution
  4. It owns the commitlog for every other node in the cluster

Explanation

Any node can act as coordinator: it determines the replicas for the partition key, forwards the request, and merges results according to the consistency level. The coordinator need not hold the data itself.

Question 40Cassandra architecture and data modeling review

A table uses a counter column. Which statement about modeling counters in Cassandra is correct?

  1. Counter columns must be part of the partition key
  2. Counter updates are not idempotent and are not safe to retry blindly Correct answer.
  3. Counter columns can be mixed freely with non-counter columns in the same table
  4. Counters can be read with a consistency level of ANY

Explanation

Counter increments are applied as deltas, so retrying a timed-out increment may apply it twice. Applications should design counters to tolerate this or avoid blind retries.

Question 41Cassandra architecture and data modeling review

A developer stores a growing set of tags in a collection column and then queries the table by tag value. Why is this a poor data model?

  1. Collections require ALLOW FILTERING on every read
  2. Collections are always stored in the commitlog instead of SSTables
  3. Collections cannot be stored in Cassandra tables at all
  4. Collections cannot be filtered by element efficiently and grow the partition's row size Correct answer.

Explanation

Collection elements are stored inside the owning row, so querying by element forces a scan and large collections inflate row size and read cost. A separate table keyed by tag is the scalable pattern.

Question 42Cassandra architecture and data modeling review

A node in a Kubernetes StatefulSet is replaced and rejoins with an empty data directory. Which action best restores it without overloading the cluster?

  1. Run nodetool rebuild against a source data center after the node is up and streaming is configured Correct answer.
  2. Delete the keyspace and recreate it so all nodes re-replicate from scratch
  3. Set the replication factor to 1 temporarily so the new node receives all writes
  4. Disable compaction on the new node until it catches up

Explanation

A replaced node with no data must stream the ranges it owns from existing replicas; nodetool rebuild pulls those ranges from a specified source. This restores the node without disturbing the rest of the cluster's data.

Question 43Cassandra architecture and data modeling review

A table is written with LOCAL_QUORUM in a two-DC keyspace, RF 3 per DC. A read is issued with LOCAL_QUORUM from the same DC. Which guarantee holds?

  1. The read is guaranteed to see writes acknowledged in the remote DC
  2. The read and write quorums overlap within the local DC, so the latest locally acknowledged write is visible Correct answer.
  3. The read sees the latest write only if the remote DC also acknowledged at ALL
  4. The read may return stale data whenever the local DC has fewer than three live replicas

Explanation

LOCAL_QUORUM requires a majority of replicas in the local DC for both reads and writes, so the two sets intersect there and timestamps resolve the newest value. Writes acknowledged only in the remote DC are not covered by this guarantee.

Question 44Cassandra architecture and data modeling review

An application issues a lightweight transaction (IF NOT EXISTS) on a partition. Which statement describes the cost and coordination involved?

  1. It is a purely local check performed by the coordinator without replica coordination
  2. It uses Paxos rounds among replicas, adding latency compared with a normal write Correct answer.
  3. It is equivalent to a normal write plus a read at ONE
  4. It requires the table to have no clustering columns

Explanation

Lightweight transactions run a Paxos consensus protocol across the partition's replicas to agree on the condition and the resulting mutation. This involves multiple round trips, so LWT writes are significantly slower than ordinary writes.

Question 45Cassandra operator installation and lifecycle management

In the k8ssandra/cass-operator model, which custom resource represents a single Cassandra data center that the operator reconciles into StatefulSets, Services and ConfigMaps?

  1. CassandraBackup
  2. CassandraDatacenter Correct answer.
  3. CassandraCluster
  4. CassandraNode

Explanation

The cass-operator watches the CassandraDatacenter (CDC) custom resource, which describes one data center: server version, size, racks, storage and resources. From that spec the operator generates the StatefulSets, headless and seed Services, and configuration resources for that data center. A multi-DC cluster is expressed as several CassandraDatacenter objects, often with a shared superuser secret.

Question 46Cassandra operator installation and lifecycle management

You want to install cass-operator with Helm so that it manages CassandraDatacenter resources in a single namespace only. Which installation scope should you choose?

  1. Cluster-wide scope with a ClusterRole and ClusterRoleBinding
  2. Host scope using static manifests applied by kubeadm
  3. Node scope using a DaemonSet on every worker
  4. Namespace-scoped installation with a Role and RoleBinding limited to that namespace Correct answer.

Explanation

The cass-operator Helm chart and kustomize manifests support a namespace-scoped deployment that uses a Role and RoleBinding, so the operator only reconciles resources in its own namespace. Cluster-wide installation instead grants a ClusterRole and watches all namespaces. Choose namespace scope when tenants must be isolated and you do not want one operator able to touch every namespace.

Question 47Cassandra operator installation and lifecycle management

When installing cass-operator, why must cert-manager (or pre-provisioned certificates) typically be available before the operator reconciles CassandraDatacenter resources?

  1. Because cert-manager is required to issue the Kubernetes API server's serving certificate
  2. Because the operator stores its reconciliation state inside cert-manager Certificate objects
  3. Because the operator relies on TLS certificates for internal endpoints such as the admission webhook and metric service Correct answer.
  4. Because Cassandra internals cannot start without a cert-manager-issued client certificate in every pod

Explanation

Recent cass-operator releases ship a validating admission webhook and metrics endpoints secured with TLS, and the chart can request those certificates through cert-manager. If the certificate issuer is missing, the webhook cannot become ready and installation stalls. Cassandra's own internode and client encryption are configured separately and do not depend on cert-manager.

Question 48Cassandra operator installation and lifecycle management

A CassandraDatacenter spec sets serverType to 'cassandra' with serverVersion '4.1.3'. What does the operator do with these fields during reconciliation?

  1. It downloads and compiles the requested Cassandra version inside an init container at startup
  2. It selects a matching container image and passes the version to configuration generation for that Cassandra release Correct answer.
  3. It maps them to a Kubernetes API version for the CassandraDatacenter CRD
  4. It ignores them and always runs the newest image tagged latest

Explanation

serverType and serverVersion drive image selection and the configuration defaults the operator generates for that Cassandra line. The operator also uses the version to decide which management API paths and settings apply. They do not control the CRD's API version or trigger in-cluster builds.

Question 49Cassandra operator installation and lifecycle management

Which condition on a CassandraDatacenter status indicates that all pods have started and the data center is ready for normal use?

  1. Updating
  2. Reconciling
  3. Ready Correct answer.
  4. Stopped

Explanation

The operator reports conditions such as Ready, Updating, Stopped and RollingRestart on the CassandraDatacenter status. Ready means the data center has reached its desired size with all nodes up and joined. Updating and Reconciling indicate in-progress work, while Stopped reflects an intentionally scaled-down data center.

Question 50Cassandra operator installation and lifecycle management

You need to shut down a CassandraDatacenter so no pods run, while keeping the custom resource and its persistent volume claims for a later restart. Which change accomplishes this?

  1. Delete the CassandraDatacenter resource and recreate it later
  2. Set spec.stopped to true on the CassandraDatacenter Correct answer.
  3. Set spec.size to 0 and let the operator scale the StatefulSets down
  4. Remove the operator Deployment so it stops reconciling

Explanation

The CassandraDatacenter spec exposes a stopped flag that tells the operator to shut down the data center's pods in an orderly way while preserving the resource and its PVCs. Clearing the flag later brings the nodes back. Deleting the resource or the operator is a destructive or disruptive workaround, not a supported stop.