Confluent Apache Flink Certificate study materials

Confluent Apache Flink Certificate practice questions

One question at a time. Build your Confluent Apache Flink Certificate 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 1Apache Flink stream processing on Confluent (domain list not enumerated in source)

In a Flink DataStream application, which abstraction must you use to process an unbounded stream of events with exactly-once state consistency?

A KeyedStream with keyed state and checkpointing enabled Correct answer.
A bounded DataSet processed with batch operators
A BroadcastStream consumed only by a ProcessFunction
A windowed stream with no time characteristic assigned

Explanation

Keyed state is scoped per key and is the foundation for scalable, fault-tolerant stateful streaming. Combined with checkpointing, Flink restores keyed state and resumes exactly-once processing after failures. Unkeyed or batch-only constructs cannot provide that guarantee.

Question 2Apache Flink stream processing on Confluent (domain list not enumerated in source)

What does Flink use a watermark to represent in an event-time stream?

A signal that no events with timestamps earlier than the watermark are expected Correct answer.
A count of records processed since the last checkpoint completed
The maximum timestamp observed across all parallel source subtasks
A marker that triggers immediate emission of all open windows

Explanation

Watermarks flow with the data and tell downstream operators that event time has advanced to a point. Operators use them to decide when event-time windows are complete. They are heuristics, not guarantees that late events will never arrive.

Question 3Apache Flink stream processing on Confluent (domain list not enumerated in source)

In the Flink Table API and SQL, what is the role of a dynamic table?

It is a table whose schema is fixed at compile time and cannot change
It is a lookup table loaded once into the task manager heap
It is a table that changes over time as the underlying stream evolves Correct answer.
It is a temporary table used only during a single SQL statement

Explanation

Flink models streams as dynamic tables that continuously change as records arrive. Queries over dynamic tables produce new dynamic tables, and converting back to a stream emits the changelog. This is the conceptual bridge between SQL and streaming.

Question 4Apache Flink stream processing on Confluent (domain list not enumerated in source)

Which checkpoint storage option makes checkpoint state durable and accessible to a restarted job on another machine?

JobManager heap memory
The Flink configuration directory on each node
TaskManager local disk only
A filesystem or object store such as S3 or HDFS Correct answer.

Explanation

Checkpoints must survive the loss of the machines that produced them, so Flink writes them to durable storage. Filesystems and object stores are the standard choices. Local-only storage cannot support recovery after a node failure.

Question 5Apache Flink stream processing on Confluent (domain list not enumerated in source)

What is the purpose of a savepoint in a Flink deployment?

To buffer late events until the watermark passes their timestamp
To take a triggered, user-owned snapshot for upgrades or rescaling Correct answer.
To compress the job graph before submission to the cluster
To cache lookup-table rows in RocksDB for faster joins

Explanation

Savepoints are manually triggered snapshots that you control and retain, typically before code changes or parallelism changes. Unlike periodic checkpoints, they are meant for operational lifecycle events. A job can be stopped and later resumed from a savepoint.

Question 6Apache Flink stream processing on Confluent (domain list not enumerated in source)

Which state backend stores working state in an embedded key-value store on local disk and keeps only metadata in the JVM heap?

RocksDB state backend Correct answer.
JobManager state backend
Network buffer state backend
Heap state backend

Explanation

RocksDB keeps keyed state on local disk in an embedded database, which allows state larger than available heap. Checkpoints copy that state to durable storage. The heap backend instead keeps working state as Java objects in memory.

Question 7Apache Flink stream processing on Confluent (domain list not enumerated in source)

In Flink SQL, which time attribute must be declared on a table before you can define an event-time tumbling window using the windowing table-valued function?

A rowtime attribute without any watermark strategy
A processing-time attribute derived from the system clock
An event-time attribute derived from a timestamp column with a watermark Correct answer.
A monotonically increasing ingestion counter

Explanation

Event-time windowing requires a rowtime attribute backed by a watermark strategy so the engine knows when windows are complete. The watermark declaration is part of the table definition. Processing time or an unwatermarked column will not drive event-time windows.

Question 8Apache Flink stream processing on Confluent (domain list not enumerated in source)

What happens to records that arrive after a window has fired when the window has no allowed lateness configured?

They are routed to a side output automatically
They are dropped and counted as late records Correct answer.
They are added to the window and cause it to fire again
They are buffered until the next checkpoint completes

Explanation

Once a window fires and its state is cleaned up, records with timestamps inside that window are late. Without allowed lateness they cannot be incorporated and are discarded. Flink exposes a metric for late records so you can observe this.

Question 9Apache Flink stream processing on Confluent (domain list not enumerated in source)

A pipeline reads from a Kafka topic with 8 partitions. What does Flink use to determine the initial parallelism of the Kafka source when parallelism is not set explicitly?

The number of partitions in the subscribed topic Correct answer.
The number of TaskManagers in the cluster
The replication factor of the topic
The number of consumer groups configured

Explanation

Flink derives source parallelism from the topic partition count when the job parallelism is not explicitly configured. Each partition is consumed by at most one source subtask to preserve ordering. Setting parallelism explicitly overrides this inference.

Question 10Apache Flink stream processing on Confluent (domain list not enumerated in source)

Which connector behavior is required for end-to-end exactly-once delivery from a Flink job into Kafka?

The sink flushes every record immediately without batching
The sink disables idempotence and relies on consumer retries
The sink writes with at-least-once semantics and deduplicates downstream
The sink uses transactional writes coordinated with Flink checkpoints Correct answer.

Explanation

Exactly-once into Kafka relies on transactions committed only when a checkpoint completes. This ties Kafka writes to Flink's checkpoint lifecycle so uncommitted data is discarded on failure. Consumers read only committed records.

Question 11Apache Flink stream processing on Confluent (domain list not enumerated in source)

You need to enrich a stream of orders with customer records stored in a relational database, and the enrichment must not block the main data path for long. Which Flink SQL construct is appropriate?

A lookup join against a table backed by a JDBC connector Correct answer.
A cross join without any time condition
A regular inner join between two unbounded streams
A tumbling window join over both inputs

Explanation

A lookup join queries an external table per incoming record, which is designed for enrichment against bounded external stores. It avoids keeping the full dimension stream in state. Regular stream-stream joins instead retain both sides in state indefinitely.

Question 12Apache Flink stream processing on Confluent (domain list not enumerated in source)

A job uses keyBy with 200 distinct keys but runs with parallelism 4. How is keyed state distributed?

A separate state backend instance is created for every key
State is stored only on the JobManager and shared by all subtasks
Keys are partitioned into 4 key groups, one per subtask Correct answer.
Each of the 4 subtasks holds state for all 200 keys

Explanation

Flink partitions the key space into key groups and assigns groups to parallel operator subtasks. This allows state to be redistributed when parallelism changes. Each subtask therefore owns a disjoint subset of keys.

Question 13Apache Flink stream processing on Confluent (domain list not enumerated in source)

Which expression in Flink SQL declares a watermark that tolerates events up to 5 seconds out of order on column ts?

WATERMARK FOR ts AS CURRENT_TIMESTAMP
WATERMARK FOR ts AS ts + INTERVAL '5' SECOND
WATERMARK FOR ts AS ts
WATERMARK FOR ts AS ts - INTERVAL '5' SECOND Correct answer.

Explanation

The watermark expression subtracts a bounded delay from the event timestamp, telling the engine to wait that long for out-of-order data. A positive offset would place the watermark ahead of event time. Omitting the delay produces a strictly monotonic watermark.

Question 14Apache Flink stream processing on Confluent (domain list not enumerated in source)

A ProcessFunction needs to emit records that are not part of the main output, for example malformed events. Which mechanism should it use?

A static field shared across subtasks
A second call to collect in the same context
A broadcast state descriptor
A side output tagged with an OutputTag Correct answer.

Explanation

Side outputs let an operator emit multiple typed streams from one function. You declare an OutputTag and emit tagged records, then retrieve the stream with getSideOutput. This keeps malformed records separate from the main flow.

Question 15Apache Flink stream processing on Confluent (domain list not enumerated in source)

What is the effect of setting the checkpoint interval much shorter than the time a checkpoint takes to complete?

The job automatically increases parallelism to keep up
New checkpoints are not triggered until the previous one completes, so the effective interval is longer Correct answer.
Checkpoints overlap and complete faster because more are in flight
The state backend switches to heap to reduce latency

Explanation

Flink does not start a new checkpoint while one is still in progress. If the configured interval is shorter than completion time, triggers are skipped and the real cadence stretches. Monitoring checkpoint duration against the interval reveals this.

Question 16Apache Flink stream processing on Confluent (domain list not enumerated in source)

A Flink SQL query groups an unbounded stream by a non-time column and selects the count. What kind of result does this produce?

An append-only stream of one row per input record
A static table materialized only in the JobManager
A bounded table that is emitted once at the end of the stream
An updating table whose changelog contains retract or upsert messages Correct answer.

Explanation

Aggregations over unbounded input without a time window must keep updating results as new records arrive. Flink represents this as a changelog of updates, typically retract or upsert depending on the sink. Append-only output requires windowing or a non-updating query.

Question 17Apache Flink stream processing on Confluent (domain list not enumerated in source)

Which situation most strongly justifies choosing RocksDB over the heap state backend?

Keyed state is small and fits comfortably in heap
The job runs with parallelism one
Keyed state is large and would risk excessive garbage collection on the heap Correct answer.
The job uses only processing-time timers

Explanation

RocksDB keeps state on local disk with an in-memory cache, which avoids holding the full working set as heap objects. Large state on the heap causes long garbage collection pauses and out-of-memory risk. Serialization overhead is the trade-off.

Question 18Apache Flink stream processing on Confluent (domain list not enumerated in source)

What does Flink's checkpoint barrier do as it flows through an operator?

It flushes the Kafka producer transaction immediately
It aligns input channels so the snapshot reflects a consistent cut of the stream Correct answer.
It triggers a savepoint on the JobManager
It resets all timers in the operator state

Explanation

Barriers are injected into the stream and travel with records. When an operator has received a barrier on all inputs, it snapshots its state, giving a consistent global cut. This is the basis of Flink's asynchronous snapshotting.

Question 19Apache Flink stream processing on Confluent (domain list not enumerated in source)

You must ensure that a stateful job can be redeployed with a different parallelism without losing keyed state. What must be true?

The state must be stored in the heap backend only
The new parallelism must equal the maximum parallelism of the original job
The job must be restored from a savepoint or retained checkpoint with key groups reassigned Correct answer.
The job must be resubmitted without any state

Explanation

Keyed state is organized into key groups, which can be redistributed across a different number of subtasks on restore. Restoring from a savepoint or retained checkpoint performs this reassignment. The maximum parallelism bounds the number of key groups, not the new parallelism.

Question 20Apache Flink stream processing on Confluent (domain list not enumerated in source)

A job uses event-time windows and enables checkpointing, but the Kafka source starts from committed offsets after a restart. Which combination preserves correct window results?

Offsets are reset to latest and windows recompute from scratch
Offsets and window state are both restored from the checkpoint so processing resumes consistently Correct answer.
Window state is discarded and only offsets are restored
Watermarks are stored in Kafka and replayed on restart

Explanation

Checkpoints capture both source offsets and operator state atomically, so a restore replays from the checkpointed offsets with matching window contents. This avoids gaps or duplicates in window results. Restoring only one side breaks consistency.

Question 21Apache Flink stream processing on Confluent (domain list not enumerated in source)

A Flink SQL job joins two unbounded streams on a non-time equality condition with no interval. What is the practical consequence?

The join fails at compile time and cannot be submitted
The join completes immediately because Flink prunes unmatched rows
Flink converts the join into a lookup join automatically
Both sides are kept in state indefinitely, so state grows without bound Correct answer.

Explanation

A regular streaming join must retain input rows because a match may arrive at any future time. Without a time-bounded condition, state grows indefinitely. Adding an interval condition lets Flink clean up state outside the bound.

Question 22Apache Flink stream processing on Confluent (domain list not enumerated in source)

In a two-input operator, one input becomes idle and stops sending watermarks. What does Flink's watermark alignment or idleness handling address?

It switches the job to processing time automatically
It forces the idle input to emit synthetic records to keep watermarks moving
It excludes the idle input from the combined watermark so downstream event time can advance Correct answer.
It restarts the idle source to restore watermark flow

Explanation

A combined watermark is the minimum across inputs, so an idle input would otherwise stall event time. Marking a source idle or using watermark alignment lets the combined watermark advance. This prevents windows from being held open indefinitely.

Question 23Apache Flink stream processing on Confluent (domain list not enumerated in source)

A ProcessFunction registers an event-time timer for a key. When is the timer fired?

At the next checkpoint completion
Immediately when the timer is registered
When the key is removed from state
When the watermark for the operator passes the timer timestamp Correct answer.

Explanation

Event-time timers fire when the operator's current watermark advances past the registered timestamp. The timer service then invokes onTimer with the key context. Processing-time timers instead fire on the system clock.

Question 24Apache Flink stream processing on Confluent (domain list not enumerated in source)

A pipeline writes to Kafka with exactly-once semantics and the checkpoint interval is 30 seconds. What is the practical visibility delay for downstream consumers reading committed data?

Records become visible only after the next checkpoint completes and commits the transaction Correct answer.
Records appear after the Kafka retention period elapses
Records appear as soon as each is produced
Records are visible only after a savepoint is taken

Explanation

Transactional Kafka sinks commit on checkpoint completion, so downstream read_committed consumers see records in checkpoint-sized batches. The interval therefore bounds visibility latency. Shorter intervals reduce latency at the cost of more frequent checkpoints.

Question 25Apache Flink stream processing on Confluent (domain list not enumerated in source)

Which statement best describes how Flink achieves exactly-once state consistency internally?

It uses distributed locks around every state access
It relies on the operating system to serialize writes to disk
It combines asynchronous state snapshots with replay from checkpointed source offsets Correct answer.
It prevents any record from being processed more than once across the whole cluster

Explanation

Flink takes consistent snapshots without stopping the stream and records source positions in the same snapshot. On failure it restores state and replays from those positions, which yields exactly-once effects on state. Records may be reprocessed, but state transitions occur once.

Question 26Apache Flink stream processing on Confluent (domain list not enumerated in source)

In Flink SQL on Confluent, which statement creates a table that reads from an existing Kafka topic using the Confluent Flink SQL dialect?

CREATE EXTERNAL STREAM orders (id INT, amount DECIMAL(10,2)) USING kafka OPTIONS (topic 'orders')
CREATE TABLE orders (id INT, amount DECIMAL(10,2)) WITH ('connector' = 'kafka', 'topic' = 'orders', 'properties.bootstrap.servers' = '...', 'format' = 'avro') Correct answer.
CREATE TABLE orders AS SELECT * FROM kafka_topic('orders')
CREATE TABLE orders (id INT, amount DECIMAL(10,2)) DISTRIBUTED BY HASH(id) INTO 6 BUCKETS

Explanation

Flink SQL declares Kafka-backed tables with a CREATE TABLE statement whose WITH clause carries connector options such as connector, topic, bootstrap servers, and format. The Confluent dialect keeps this standard Flink DDL shape. Physical distribution options like buckets belong to Kafka topics, not Flink SQL DDL.

Question 27Apache Flink stream processing on Confluent (domain list not enumerated in source)

Which Flink SQL construct continuously emits a result row each time an input row arrives, without waiting for a window to close?

A non-windowed SELECT with no aggregation, producing an append or update stream Correct answer.
A session window with a gap of one minute
A tumbling window aggregation
A CUMULATE window with a one-hour step

Explanation

A simple projection over an unbounded source is a continuous query that emits one output row per input row as soon as it is processed. Windowed aggregations buffer rows until the window fires. This is why simple SELECT statements produce streaming results immediately.

Question 28Apache Flink stream processing on Confluent (domain list not enumerated in source)

You want a Flink SQL job to write results into a Kafka topic in the Avro format. Which WITH option controls the serialization format of the sink?

'format' = 'avro' Correct answer.
'serialization' = 'avro'
'sink.format' = 'avro'
'value.format' = 'avro'

Explanation

In Flink SQL table options, the 'format' key selects the serialization format for the connector, for example 'avro', 'json', or 'csv'. Confluent's registry-backed formats additionally use options such as 'avro-confluent.url'. The other key names are not recognized table options.

Question 29Apache Flink stream processing on Confluent (domain list not enumerated in source)

Which Flink concept lets a single operator instance process records from multiple keys while keeping each key's state isolated?

Keyed state Correct answer.
Operator state
Broadcast state
Union state

Explanation

Keyed state is scoped per key within a keyed stream, so one operator instance can hold many keys while Flink partitions state by key. Operator state is scoped to a parallel operator instance instead. Broadcast state is a special operator state replicated to all instances.

Question 30Apache Flink stream processing on Confluent (domain list not enumerated in source)

Which Flink SQL function assigns each input row to a fixed-size, non-overlapping time window?

HOP
TUMBLE Correct answer.
CUMULATE
SESSION

Explanation

TUMBLE creates fixed-size, non-overlapping windows aligned to the epoch. HOP creates overlapping sliding windows, SESSION groups by inactivity gaps, and CUMULATE produces expanding windows within a step. Each has distinct semantics for how rows map to windows.

Question 31Apache Flink stream processing on Confluent (domain list not enumerated in source)

What is the role of a Flink savepoint compared with a checkpoint?

A savepoint is a temporary cache of records that have not yet been processed by a sink
A savepoint is an alternative to watermarks for tracking event time
A savepoint is a copy of the Kafka topic offsets stored in the schema registry
A savepoint is a manually triggered, portable snapshot used for upgrades and rescaling, while checkpoints are periodic automatic recovery snapshots Correct answer.

Explanation

Savepoints are user-triggered snapshots of job state that persist beyond the job and can be used to restart with a different parallelism or code version. Checkpoints are periodic and primarily for automatic failure recovery. Both capture operator and keyed state, but their lifecycle and intended use differ.

Question 32Apache Flink stream processing on Confluent (domain list not enumerated in source)

Which Flink SQL statement would you use to change a running query's parallelism without redeploying from scratch?

ALTER TABLE orders SET ('parallelism' = '8')
UPDATE orders SET parallelism = 8
RESCALE TABLE orders TO 8
SET 'parallelism.default' = '8' Correct answer.

Explanation

Flink SQL supports session-level configuration with SET, and parallelism.default controls the default parallelism for statements in that session. Table options can also carry a parallelism hint in the WITH clause, but ALTER TABLE ... SET is used for connector options. There is no UPDATE or RESCALE DDL for parallelism.

Question 33Apache Flink stream processing on Confluent (domain list not enumerated in source)

In Confluent Cloud, which component stores the schemas referenced by Flink SQL Avro or Protobuf tables?

The Flink job manager's local disk
Schema Registry Correct answer.
The Flink SQL client's catalog cache
The Kafka controller quorum

Explanation

Confluent Schema Registry stores and versions schemas, and Flink SQL uses options such as 'avro-confluent.url' to resolve them at runtime. The job manager and controller do not persist user schemas. The SQL client cache is transient and not authoritative.

Question 34Apache Flink stream processing on Confluent (domain list not enumerated in source)

A Flink SQL job reads from a Kafka topic with key-value JSON messages. Which option correctly tells the connector to parse the message key as a separate column?

'key.fields' = 'json'
'message.key' = 'json'
'value.format' = 'json'
'key.format' = 'json' Correct answer.

Explanation

The Kafka connector uses 'key.format' to deserialize the record key and 'value.format' for the value. Defining key.fields maps the key to declared columns, but the format option is what selects JSON parsing. Without key.format, the key is not exposed as typed data.

Question 35Apache Flink stream processing on Confluent (domain list not enumerated in source)

A Flink SQL query joins an unbounded orders stream to a versioned table of customer records, and each order must see the customer version valid at the order's event time. Which join type supports this?

A CROSS JOIN between the two tables
A temporal join using FOR SYSTEM_TIME AS OF the order's event-time column Correct answer.
A regular inner join with no time condition
A UNION ALL of the two tables

Explanation

A temporal table join with FOR SYSTEM_TIME AS OF looks up the version of the right-hand table that was valid at the event time of each left row. This is the standard way to enrich a stream with slowly changing dimension data in Flink SQL. Regular joins and cross joins do not provide time-versioned lookups.

Question 36Apache Flink stream processing on Confluent (domain list not enumerated in source)

You need to deduplicate events in Flink SQL by keeping only the latest row per id based on an event-time column. Which pattern accomplishes this?

SELECT id, MAX(ts) FROM events GROUP BY id
SELECT DISTINCT id FROM events
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY id ORDER BY ts DESC) AS rn FROM events) WHERE rn = 1 Correct answer.
SELECT * FROM events WHERE ts = (SELECT MAX(ts) FROM events)

Explanation

A ROW_NUMBER() window function partitioned by the deduplication key and ordered by the event-time column, filtered to rn = 1, keeps the latest row per key. This is the canonical Flink SQL deduplication idiom. DISTINCT and simple MAX aggregations do not return the full latest row.

Question 37Apache Flink stream processing on Confluent (domain list not enumerated in source)

A Flink job uses a Kafka source with the default group offset reset. After a failure with no checkpoint, where does the job resume reading?

From the offset stored in the schema registry
From the committed group offsets in Kafka, or the configured starting offset if none exist Correct answer.
From the earliest offset in each partition
From the latest offset, skipping all records produced during downtime

Explanation

When no checkpoint or savepoint is available, a Kafka source falls back to the consumer group's committed offsets. If the group has no committed offsets, the configured starting offset strategy applies. This is why exactly-once guarantees depend on checkpointing, not on Kafka offsets alone.

Question 38Apache Flink stream processing on Confluent (domain list not enumerated in source)

Which Flink SQL statement creates a temporary view over an existing table so that multiple queries can reuse the same transformation?

CREATE TABLE enriched AS SELECT * FROM orders
CREATE INDEX enriched ON orders(amount)
CREATE TEMPORARY VIEW enriched AS SELECT * FROM orders WHERE amount > 0 Correct answer.
CREATE FUNCTION enriched AS 'com.example.Enrich'

Explanation

CREATE TEMPORARY VIEW defines a named query that exists for the duration of the session and can be reused by later statements. CREATE TABLE AS SELECT creates a persistent table backed by a connector. CREATE INDEX and CREATE FUNCTION serve different purposes.

Question 39Apache Flink stream processing on Confluent (domain list not enumerated in source)

A Flink SQL aggregation on an unbounded stream produces retract messages. Which sink property must the downstream connector support?

It must handle updates or upserts, such as a Kafka sink with a primary key and upsert semantics Correct answer.
It must accept only append-only streams
It must use the print connector
It must be a filesystem sink with rolling policy

Explanation

Aggregations over unbounded input can emit updates, represented as retract or upsert changelog messages. A sink must therefore support updating results, for example a Kafka sink configured with a primary key and upsert-kafka format. Append-only sinks reject such changelogs.

Question 40Apache Flink stream processing on Confluent (domain list not enumerated in source)

Which Flink SQL option enables the Kafka sink to write records with keys derived from a primary key column?

'value.fields-include' = 'ALL'
'transactional-id-prefix' = 'id'
'sink.partitioner' = 'fixed'
'key.fields' = 'id' with 'key.format' = 'json' Correct answer.

Explanation

The Kafka sink serializes the key from the columns named in 'key.fields' using the format in 'key.format'. This controls partitioning and supports upsert semantics when the sink is configured for upserts. Partitioner and transactional settings affect distribution and delivery guarantees, not key extraction.

Question 41Apache Flink stream processing on Confluent (domain list not enumerated in source)

A job uses two-input operators with watermark alignment enabled. One source partition stops producing records and its watermark stalls. What does watermark alignment do?

It pauses the faster inputs so their watermarks do not advance beyond the slowest input by more than the configured maximum drift Correct answer.
It switches the job to processing time
It advances watermarks for the stalled input anyway
It drops the stalled input from the job

Explanation

Watermark alignment prevents fast inputs from racing ahead by pausing them when they exceed the configured maximum drift relative to the slowest input. This avoids excessive buffering in downstream operators. It does not fabricate watermarks or change the time characteristic.

Question 42Apache Flink stream processing on Confluent (domain list not enumerated in source)

Which Flink SQL statement defines a processing-time attribute on a table column named proc_ts?

proc_ts TIMESTAMP(3) METADATA FROM 'timestamp'
proc_ts AS PROCTIME() Correct answer.
proc_ts AS WATERMARK FOR event_ts AS event_ts - INTERVAL '5' SECOND
proc_ts AS CURRENT_TIMESTAMP

Explanation

PROCTIME() declares a computed column that yields the processing-time attribute used by processing-time windows and temporal joins. A WATERMARK clause defines event time instead. Metadata columns map Kafka record metadata and do not define a time attribute.

Question 43Apache Flink stream processing on Confluent (domain list not enumerated in source)

You need to call a Java method that is not available as a built-in Flink SQL function. Which mechanism should you use?

A watermark strategy on the source table
A connector option in the WITH clause
A user-defined function registered with CREATE FUNCTION Correct answer.
A view created with CREATE TEMPORARY VIEW

Explanation

User-defined functions extend Flink SQL with custom scalar, table, or aggregate logic and are registered with CREATE FUNCTION or the function DDL. Views, watermarks, and connector options do not add callable logic. UDFs are the standard extension point for custom Java or Python code.

Question 44Apache Flink stream processing on Confluent (domain list not enumerated in source)

A Flink SQL job uses a regular join between two unbounded streams with an equality condition on a non-time column and no state TTL. What is the main operational risk?

The job silently switches to batch mode
Checkpoints are disabled automatically
Watermarks stop advancing
Join state grows without bound because both sides must be retained for future matches Correct answer.

Explanation

A regular streaming join must retain input rows indefinitely to match future rows from the other side, so state grows with input volume. Configuring state TTL or using an interval or temporal join bounds this growth. The join does not disable checkpoints or change execution mode.

Question 45Apache Flink stream processing on Confluent (domain list not enumerated in source)

Which Flink SQL clause restricts a join to rows whose event times fall within a fixed interval of each other?

MATCH_RECOGNIZE
OVER (PARTITION BY ... ORDER BY ...)
WHERE r BETWEEN t1 - INTERVAL '1' HOUR AND t1 + INTERVAL '1' HOUR, combined with an equi-join condition Correct answer.
FOR SYSTEM_TIME AS OF

Explanation

An interval join in Flink SQL is expressed as an equi-join plus a WHERE predicate that bounds the difference between the two event-time columns. This lets Flink keep only a bounded range of state. Temporal joins, window functions, and pattern matching serve different purposes.

Question 46Apache Flink stream processing on Confluent (domain list not enumerated in source)

A Flink SQL statement uses MATCH_RECOGNIZE to detect a pattern of two consecutive failed logins followed by a success. Which clause defines the order in which rows are evaluated?

PATTERN
PARTITION BY
MEASURES
ORDER BY Correct answer.

Explanation

Within MATCH_RECOGNIZE, ORDER BY establishes the event-time ordering of rows so the pattern is evaluated in the correct sequence. PARTITION BY groups rows, MEASURES defines output columns, and PATTERN describes the sequence of row variables. Time ordering is essential for correct pattern detection.

Question 47Apache Flink stream processing on Confluent (domain list not enumerated in source)

A Flink job uses the RocksDB state backend with incremental checkpoints enabled. Which statement best describes the benefit?

Checkpoints are written to the job manager heap instead of object storage
Only the SST files changed since the last checkpoint are uploaded, reducing checkpoint size and duration Correct answer.
State is kept entirely in memory to avoid disk I/O
The full state is uploaded on every checkpoint to guarantee consistency

Explanation

Incremental checkpoints with RocksDB upload only new or changed SST files since the previous checkpoint, which greatly reduces checkpoint size and time for large state. The tradeoff is that restoring requires replaying the chain of prior checkpoints. It does not move state into heap memory.

Question 48Apache Flink stream processing on Confluent (domain list not enumerated in source)

A Flink job writes to Kafka with exactly-once semantics. A downstream consumer using read_committed isolation reads the topic. What do consumers see before the Flink checkpoint that commits the transaction completes?

Only the records whose keys are null
The records, because Kafka ignores transactions for read_committed consumers
The records but with duplicate keys removed
Nothing from that transaction, because its records remain uncommitted and are invisible to read_committed consumers Correct answer.

Explanation

The Kafka sink writes records inside transactions and commits them only when the corresponding Flink checkpoint completes. A read_committed consumer does not see uncommitted records, so output becomes visible at checkpoint boundaries. Consumers using read_uncommitted would see records earlier but risk duplicates.

Question 49Apache Flink stream processing on Confluent (domain list not enumerated in source)

A Flink SQL job uses TUMBLE windows with event time and enables checkpointing. After a restart from a checkpoint, what happens to windows whose state was captured in the checkpoint?

Watermarks are reset to the earliest timestamp in the topic
All windows are recomputed from the beginning of the topic
Windows are discarded and only new events are processed
Window state and watermark progress are restored, so windows continue from where the checkpoint was taken Correct answer.

Explanation

Checkpoints capture operator state, including window contents and watermark progress, so a restart resumes window processing from the checkpointed position. This is what makes event-time results consistent across failures. Recomputing from the topic start would break the at-least-once or exactly-once guarantees.

Question 50Apache Flink stream processing on Confluent (domain list not enumerated in source)

A Flink SQL query uses a HOP window of one hour with a thirty-minute slide. How many windows does a single event typically belong to?

Exactly one
Two, because the window size is twice the slide Correct answer.
Three, because the slide is half the size
Four, because the window overlaps by default

Explanation

In a HOP window, an event belongs to size divided by slide windows, which is 60 / 30 = 2. Each event is therefore counted in two overlapping windows. This duplication is intentional and explains why sliding window results can sum to more than the raw event count.