Task 1.2: Choose an authentication method based on use case

• AThe jwt auth method with GitHub's OIDC discovery URL and a role with bound_claims on the repository and main branch

  Correct

  A JWT role verifies the provider-signed token against the discovery keys and can require claim values, so no secret is stored and only matching jobs log in.

• BThe github auth method, with the team that owns the repository and its main branch mapped to the production read policy

  Incorrect

  The github method logs in with a personal access token, a long-lived credential the job would have to store, and it maps teams, not branches.

• CThe jwt auth method with an oidc role type, letting each job complete the provider's authorization flow

  Incorrect

  An oidc role runs the authorization code flow in a user's browser; a job has none, and a provider-signed JWT goes to a jwt role instead.

• DThe jwt auth method with GitHub's OIDC discovery URL and a role that sets only bound_audiences

  Incorrect

  The audience does not identify a repository or branch, so any workflow requesting that audience could log in.

The jwt auth method accepts a JWT that a platform signs, verifies it with keys from the platform's OIDC discovery endpoint, and binds the role to claim values such as the repository and branch. Nothing secret is stored in the pipeline.

• AThe kubernetes auth method, with one role per service that sets bound_service_account_names to * in apps

  Incorrect

  A wildcard name lets every service account in the namespace log in with any role, so services could read each other's secrets.

• BThe approle auth method, one role per service with bind_secret_id=false and CIDRs set to the pod network

  Incorrect

  All pods share the pod network, so the CIDR binding cannot tell services apart, and each RoleID must still be handed out.

• CThe kubernetes auth method, with one role per service bound to that service's account name in apps

  Correct

  Pods present their service account token, Vault validates it with the TokenReview API, and a role bound to one account maps it to one service's policy.

• DThe jwt auth method, one role bound only to the issuer of the cluster's service account tokens

  Incorrect

  Every service account token from the cluster carries that issuer, so all services would match the same role.

Kubernetes auth uses the identity the platform already gives each pod: its service account token. Binding each role to one service account name and namespace keeps every service to its own policy without any credential for the team to manage.

• AThe azure auth method, using the VM's managed identity

  Correct

  The azure method supports system-assigned and user-assigned managed identities, so nothing has to be stored on the VM.

• BThe userpass auth method, with a password kept on the Azure virtual machine

  Incorrect

  A stored password is the credential the requirement rules out.

• CThe cert auth method, with a certificate issued to the machine's managed identity

  Incorrect

  A managed identity does not come with a client certificate for the cert method to check.

• DThe github auth method, using the repository that deploys the application

  Incorrect

  The github method authenticates people with personal access tokens.

Cloud auth methods trust the cloud's own identity for a workload, so nothing needs to be stored on the machine.

• AThe kubernetes auth method, with the instance's service account as the reviewer

  Incorrect

  The kubernetes method validates Kubernetes service account tokens, not Google Cloud identities.

• BThe aws auth method with the iam type, bound to the project

  Incorrect

  The aws method verifies AWS IAM principals and EC2 instances only.

• CThe gcp auth method, with an iam or gce role bound to the service account

  Correct

  The gcp method authenticates Google Cloud IAM service accounts and Compute Engine instances.

• DThe approle auth method, with the RoleID set to the service account email

  Incorrect

  AppRole still needs a SecretID delivered to the job and does not check Google Cloud identity.

Pick the auth method that matches the platform identity the workload already has: gcp for Google Cloud, aws for AWS, azure for Azure.

• AThe jwt auth method, with the CA's public key as a validation key

  Incorrect

  The jwt method validates signed JWTs, not TLS client certificates.

• BThe cert auth method, with that CA configured as a trusted certificate

  Correct

  The cert method authenticates TLS client certificates signed by a CA that is configured on the method.

• CThe cert auth method, reading CAs from each service's trust store

  Incorrect

  Trusted certificates and CAs are configured on the method; it cannot read them from an external source.

• DThe pki secrets engine, with a role for the services

  Incorrect

  PKI issues certificates; it is not an auth method.

For mutual TLS identities, the cert auth method maps certificates signed by a trusted CA to roles and policies.

• AThe userpass auth method

  Incorrect

  userpass keeps its own users in Vault and cannot read them from a directory.

• BThe approle auth method

  Incorrect

  AppRole is meant for machines and services, not people.

• CThe token auth method

  Incorrect

  The token method is not tied to the directory, so directory groups could not map to policies.

• DThe ldap auth method

  Correct

  The ldap method authenticates users against an LDAP server such as Active Directory and maps groups to policies.

Directory users and groups map naturally to the ldap method, which delegates the password check to the directory.