Diagnose MongoDB connection, authentication, SRV and TLS

Understand the likely causes

• Likely causes include wrong host or topology, unavailable SRV/TXT records, blocked egress or Atlas network admission, hostname/trust-chain mismatch, incompatible clients and incorrect database credentials or authSource. Server selection can fail because no discovered member is eligible even after one seed is reachable. Authorization errors occur after authentication and require a scoped privilege review.

Capture the stage and intended target

Record driver/runtime versions, deployment type, client location, URI scheme, database, authSource and TLS policy without copying credentials into logs or tickets. Preserve the full structured error and nested cause privately. Do not classify every selection timeout as a slow database or every rejected operation as a password failure. Atlas project access and database users are separate identities. Confirm the approved endpoint from deployment records rather than constructing a new connection to an arbitrary discovered service.

Check DNS and TLS assumptions without weakening them

mongodb+srv uses DNS discovery and enables TLS by default unless explicitly overridden. The runtime must resolve the required records from its actual network environment; a developer laptop and an application container can differ. A certificate must match the intended host and trusted chain. Diagnose time, trust store, hostname and proxy behavior through existing operations evidence rather than disabling validation. The local policy below is only an illustrative record of assumptions; authSource admin is correct only if that is where this synthetic user was provisioned.

const policy = { scheme: 'mongodb+srv', database: 'quay_lab', authSource: 'admin', tls: true };
printjson(policy);

{ scheme: "mongodb+srv", database: "quay_lab", authSource: "admin", tls: true }

Match the database identity and operation scope

For authentication failure, verify the approved database user, credential encoding, mechanism and authSource. Percent-encoding credentials belongs at the URI construction boundary; do not double-encode or log the secret while debugging. For code 13, identify the denied database/collection operation and effective role rather than granting a broad administrator role. Self-managed authentication and TLS setup differ from Atlas-managed controls. Repair provisioning through the authorized change process, keeping network admission narrow instead of opening every address.

Verify one approved read through the real client path

After the authorized remedy, use the established connection check from the intended application environment and its normal driver/pool. A read of a known synthetic identifier can verify the permitted collection path without changing data. An empty result is a data outcome, not proof of failed login, and successful access to one collection does not prove all roles are correctly scoped. No such query is executed during authoring; the example is a non-runnable pattern for an existing authorized training session.

db.getSiblingDB('quay_lab').parcels.findOne({ _id: 1 }, { _id: 1, label: 1 });

Keep it from recurring

• Store secrets in the normal secret system, reuse bounded clients and document SRV/TLS/authSource requirements. Keep Atlas project and database identities distinct. Validate driver compatibility before upgrades and include container DNS, certificate trust and narrow network-admission checks in release verification.