ClickHouse Certified study materials
ClickHouse Certified study resources

ClickHouse Certified: Operations, Security, and ClickHouse Cloud

ClickHouse Certified · Work through your exam, one topic at a time.

All guide sections

Operations, Security, and ClickHouse Cloud

This domain covers running ClickHouse safely: SQL-driven access control, network and encryption posture, replication and backup mechanics, mutation semantics, monitoring surfaces, and how Cloud differs from self-managed. Questions often describe an operational requirement - isolate a tenant's rows, restore a table, wait for a mutation - and ask for the correct construct or the caveat.

Access control

  • SQL RBAC: CREATE USER, CREATE ROLE, CREATE SETTINGS PROFILE, CREATE QUOTA, CREATE ROW POLICY, then GRANT SELECT ON db.* TO role.
  • Row policies filter rows per user; column restriction is GRANT SELECT(col1, col2).
  • Profiles carry limits such as readonly = 1, max_memory_usage, max_execution_time; attach per user or role.
  • The shipped default user has no password and full rights - lock it down or remove it.

Network and encryption

  • Ports: 9000 native, 9440 native over TLS, 8123 HTTP, 8443 HTTPS, 9363 for Prometheus metrics.
  • Cloud enforces TLS, offers IP access lists, and encrypts data at rest; customer-managed keys are an Enterprise capability.

Replication, backups, mutations

  • ReplicatedMergeTree coordinates replicas through ClickHouse Keeper (Raft). Inspect system.replicas.absolute_delay and system.replication_queue for lag.
  • Backup with BACKUP TABLE ... TO S3(...) and restore with RESTORE; Cloud takes automatic backups and can write them to your own bucket.
  • ALTER TABLE ... UPDATE/DELETE are asynchronous mutations that rewrite whole parts; mutations_sync = 1 makes the statement wait. Lightweight DELETE FROM only marks rows deleted.

Cloud specifics

  • Compute and object storage are separated (SharedMergeTree): storage grows without resizing compute, and compute scales vertically and horizontally.
  • Idle services suspend compute after a timeout, so the first query after idling is slower.
  • No direct Keeper access and no Kafka table engine - use ClickPipes for Kafka and object storage.
  • Monitoring combines system.metrics, system.events, system.asynchronous_metrics with a Prometheus integration.

Worked example

An EU analyst must see only EU rows: CREATE ROW POLICY p_eu ON db.orders FOR SELECT USING region = 'eu' TO analyst_eu; then GRANT SELECT ON db.orders TO analyst_eu. Multiple policies attached to the same user combine with OR (permissive) by default, so a user holding two regional policies sees both - a frequent exam trap.

Traps that cost marks

  • Leaving default passwordless, or granting on *.* instead of schema scope.
  • Expecting ALTER DELETE to take effect immediately.
  • Confusing replication (same data, availability) with sharding (Distributed, horizontal scale).
  • Assuming Cloud supports every open-source engine.