Security

Question 1

What are the three main pillars of Kafka security?

Answer 1

Authentication, authorization, and encryption in transit.

Question 2

What is the purpose of ACLs in Kafka?

Answer 2

ACLs define which principal may perform which operation on which resource.

Question 3

Are ACLs used for authentication or authorization?

Answer 3

Authorization.

Question 4

What is the difference between SSL/TLS and SASL in Kafka?

Answer 4

SSL/TLS provides transport encryption and optionally certificate-based auth; SASL is an authentication framework.

Question 5

What is a principal in Kafka?

Answer 5

The identity Kafka derives after successful authentication and uses internally for authorization decisions.

Question 6

Is a principal an active network component?

Answer 6

No. It is an identity, not a network actor.

Question 7

Where are authentication and authorization mainly enforced in Kafka?

Answer 7

At the broker.

Question 8

What is the usual high-level flow for a secured client request?

Answer 8

Connection established -> authentication -> principal derived -> ACL/authorization check -> request processed.

Question 9

What does PLAINTEXT mean in Kafka?

Answer 9

No TLS and no SASL security on the connection.

Question 10

What does SSL mean in Kafka?

Answer 10

TLS-encrypted transport, optionally with certificate-based client authentication.

Question 11

What does SASL_PLAINTEXT mean in Kafka?

Answer 11

SASL authentication over an unencrypted connection.

Question 12

What does SASL_SSL mean in Kafka?

Answer 12

SASL authentication over a TLS-encrypted connection.

Question 13

Does SASL itself encrypt traffic?

Answer 13

No. SASL is for authentication, not transport encryption.

Question 14

Which Kafka security protocol gives both authentication and encryption when used with SASL?

Answer 14

SASL_SSL.

Question 15

What is the difference between PLAIN and PLAINTEXT?

Answer 15

PLAIN is a SASL mechanism; PLAINTEXT is an unencrypted transport mode.

Question 16

Is PLAIN the same thing as SASL_PLAINTEXT?

Answer 16

No. PLAIN is the auth mechanism; SASL_PLAINTEXT is the connection protocol.

Question 17

What is SASL/PLAIN conceptually?

Answer 17

A simple SASL username/password authentication mechanism.

Question 18

What is SCRAM in Kafka security?

Answer 18

A SASL authentication mechanism, stronger than PLAIN.

Question 19

Is SCRAM a replacement for SASL?

Answer 19

No. SCRAM is a mechanism within SASL.

Question 20

Does SCRAM encrypt network traffic by itself?

Answer 20

No. You still need TLS for encryption in transit.

Question 21

Which is generally safer: PLAIN or SCRAM?

Answer 21

SCRAM.

Question 22

What is GSSAPI in Kafka?

Answer 22

The SASL mechanism Kafka uses for Kerberos authentication.

Question 23

What is OAUTHBEARER in Kafka?

Answer 23

A SASL authentication mechanism based on bearer tokens.

Question 24

In Kafka, is OAUTHBEARER used on the authentication or authorization side?

Answer 24

Authentication.

Question 25

Which combination is secure for username/password-style auth with encryption?

Answer 25

SASL_SSL with a SASL mechanism such as PLAIN or SCRAM.

Question 26

Why is SASL_PLAINTEXT + PLAIN usually a bad idea?

Answer 26

It authenticates, but traffic is not encrypted.

Question 27

Which main ACL resource types should you know for Kafka?

Answer 27

Topic, Group, Cluster, TransactionalId, DelegationToken.

Question 28

What ACL does a plain producer typically need?

Answer 28

Write on the Topic resource.

Question 29

What ACLs does a plain consumer typically need?

Answer 29

Read on the Topic and Read on the Group.

Question 30

Why does a consumer need permissions on Group as well as Topic?

Answer 30

Because consuming involves consumer-group operations, not just reading topic data.

Question 31

What ACL resource becomes important for transactional producers?

Answer 31

TransactionalId.

Question 32

What does a Kafka Streams application act like from a security perspective?

Answer 32

Both a producer and a consumer, plus it may need internal-topic and admin-related permissions.

Question 33

Why can a Streams app need ACLs on internal topics?

Answer 33

Because it may create and use internal repartition and changelog topics derived from application.id.

Question 34

From Kafka’s perspective, what is a source connector most like?

Answer 34

A producer.

Question 35

From Kafka’s perspective, what is a sink connector most like?

Answer 35

A consumer.

Question 36

What Kafka permissions does a source connector minimally need?

Answer 36

Typically Write on the Kafka topics it writes to.

Question 37

What Kafka permissions does a sink connector minimally need?

Answer 37

Typically Read on the Kafka topics it consumes from and Read on the Group.

Question 38

What does a literal ACL pattern mean?

Answer 38

The ACL applies only to the exact resource name.

Question 39

What does a prefixed ACL pattern mean?

Answer 39

The ACL applies to all resource names starting with the given prefix.

Question 40

What are super.users in Kafka?

Answer 40

Special privileged principals that bypass normal ACL restrictions.

Question 41

By default, what happens if no ACL matches a resource?

Answer 41

Access is denied, except for super users.

Question 42

Is successful authentication alone enough to allow an action?

Answer 42

No. The action must also be authorized.

Question 43

What kinds of Kafka clients are relevant in security questions besides producers and consumers?

Answer 43

AdminClient, Kafka Streams applications, and Kafka Connect workers.

Question 44

Can a broker act as both a server and a client?

Answer 44

Yes. It serves client requests and also acts as a client when talking to other brokers.

Question 45

Why may a broker need to authenticate to another broker?

Answer 45

Because broker-to-broker communication is also secured and authenticated.

Question 46

What is inter.broker.listener.name used for?

Answer 46

It selects the listener used exclusively for broker-to-broker communication.

Question 47

What is controller.listener.names used for?

Answer 47

It defines the listener(s) used for controller-plane communication in KRaft.

Question 48

What is the difference between broker-to-broker traffic and controller traffic?

Answer 48

Broker-to-broker traffic is internal cluster/data communication; controller traffic is control-plane/metadata communication in KRaft.

Question 49

In KRaft, can the controller listener be the same as the inter-broker listener?

Answer 49

No.

Question 50

What is the purpose of listeners?

Answer 50

It defines where the broker binds and listens for incoming connections.

Question 51

What is the purpose of advertised.listeners?

Answer 51

It defines the address(es) the broker tells clients to use.

Question 52

Why can advertised.listeners differ from listeners?

Answer 52

Because the address clients must use may differ from the local bind address, for example with Docker, Kubernetes, NAT, or load balancers.

Question 53

Why might a cluster expose multiple listeners?

Answer 53

To separate client traffic, broker traffic, controller traffic, addresses, and security settings.

Question 54

Can different listeners use different security configurations?

Answer 54

Yes.

Question 55

What is the main security advantage of separate client and internal listeners?

Answer 55

External clients and internal cluster communication can use different protocols, credentials, and network exposure.

Question 56

In KRaft, do clients normally talk directly to the controller?

Answer 56

No. They usually talk to a broker first.

Question 57

What happens to controller-owned admin requests in KRaft?

Answer 57

A broker receives them and may forward them to the active controller.

Question 58

When a broker forwards a controller-owned request, which two principals matter at the controller side?

Answer 58

The broker principal and the forwarded client principal.

Question 59

In forwarded KRaft requests, what is the broker principal used for?

Answer 59

Authorization of the outer forwarded/envelope request.

Question 60

In forwarded KRaft requests, what is the forwarded client principal used for?

Answer 60

Authorization of the inner client request.

Question 61

Which communication path do producers, consumers, Streams, Connect, and AdminClient primarily use?

Answer 61

Client <-> broker.

Question 62

Which communication path is used for replication and internal broker traffic?

Answer 62

Broker <-> broker.

Question 63

Which communication path is used for KRaft control-plane communication?

Answer 63

Broker <-> controller.

Question 64

What is the difference between a mechanism and a security protocol in Kafka?

Answer 64

A mechanism is how identity is proven within SASL; a security protocol is the overall connection mode such as SSL or SASL_SSL.

Question 65

Give examples of SASL mechanisms in Kafka.

Answer 65

PLAIN, SCRAM, GSSAPI, OAUTHBEARER.

Question 66

Give examples of Kafka security protocols.

Answer 66

PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL.

Question 67

What is the simplest exam-safe mental model for Kafka security?

Answer 67

TLS/SSL protects the channel, SASL authenticates the client, Kafka derives a principal, and ACLs authorize operations on resources.