Bootstrap succeeds but leader access fails

Understand the likely causes

• Advertised listener addresses may suit another network, certificate names may not match discovered hosts, or the authenticated principal may lack the requested topic or group operation.

Identify the exact failing stage

Keep the exact error class and a sanitized timeline showing initial connection, metadata discovery and the failing subsequent request. A transport timeout, TLS identity error, SASL failure and authorization denial indicate different layers. A single generic connection failed message loses that distinction. Confirm the client library and version because configuration names and error presentation can differ. Review existing application logs and approved configuration evidence; this guide does not run probes, read credentials or enumerate network targets. The aim is to narrow the mismatch using evidence already available from the failing application.

Compare discovered addresses with the client environment

bootstrap.servers supplies initial contacts, while metadata provides addresses for relevant brokers. An internal container hostname can be valid inside the broker network and unusable from an external client. Likewise, a listener selected through one port can advertise another address family or port requiring a different route. Compare the specific advertised listener intended for this client with the approved network design. Do not replace every broker hostname with the bootstrap host: distinct brokers still need correct routing. Managed-service endpoints may have product-specific discovery behavior that must follow their own documentation.

Check certificate identity and authentication separately

A certificate must be trusted and valid for the endpoint identity under the client's verification rules. A successful trust-chain check alone does not guarantee hostname coverage. After transport validation, SASL or mutual-TLS identity mapping must produce the principal expected by the application policy. Never publish a password or private key while collecting evidence. Disabling hostname verification or falling back to plaintext changes the security boundary and can hide the original defect. Correct the approved endpoint, certificate coverage or trust material through the deployment's normal process, then retain the before-and-after error context.

Inspect only the required resource operation

If the connection authenticates but topic access fails, compare the actual principal with the requested topic, group or transactional identifier and operation. A consumer can require both topic and group permissions; a successful metadata request does not prove all later operations are allowed. Build a small expected-operation table for this application and include a deliberate denied operation in the review. Do not grant cluster-wide administration as a generic fix. The offline fixture compares a bootstrap hostname with a discovered hostname only to illustrate that they are distinct fields, not to assert either is reachable.

metadata = {'bootstrap': 'edge.training.invalid:9093', 'leader': 'broker-2.training.invalid:9093'}
assert metadata['bootstrap'] != metadata['leader']
print('distinct address fields')

distinct address fields

Keep it from recurring

• Version listener intent, certificate-name coverage and application permission matrices together. Include external and internal client paths in planned configuration reviews, and use bounded evidence collection instead of ad hoc credential changes or broad scanning.