What Does Application Default Credentials Mean?
On This Page
Quick Definition
Application Default Credentials is a smart system that lets your code log into Google Cloud services without you having to manually provide a password or API key. It automatically looks for credentials in several places like environment variables or the service account attached to your compute resource. This makes your applications more secure and easier to manage because you never store secrets in your code.
Commonly Confused With
A service account key file is a JSON file that contains a private key for a service account. You use it by setting the GOOGLE_APPLICATION_CREDENTIALS environment variable. In contrast, ADC is the system that finds credentials automatically, and one of its methods is using this key file. The key file is just one input to ADC, not the whole system.
If you manually download a key.json file and point to it via GOOGLE_APPLICATION_CREDENTIALS, you are using a key file. If you instead just make sure a service account is attached to your VM, ADC uses the metadata server, and you never touch a key file.
gcloud auth login authenticates you as a user to the gcloud command-line tool, allowing you to run gcloud commands. These user credentials are also used by ADC as a last resort when no other credentials are found. However, for production applications, you should never rely on user credentials because they are too permissive and tied to a person.
You run gcloud auth login on your laptop to manage your projects. That same laptop can run your application with ADC, and ADC will use those user credentials. But if you deploy the app to a VM, the user credentials are not present, so ADC will fail unless you have a service account set up.
An OAuth 2.0 access token is a short-lived string that proves you have permission. ADC's job is to obtain such a token automatically behind the scenes. ADC is the process, and the access token is the result of that process. You never work with the token directly when using ADC.
Think of ADC as the automated vending machine that gives you a ticket. The access token is the ticket itself. You just need to be near the machine (your compute environment), and it gives you the ticket for entry to Google APIs.
Workload Identity Federation is a feature that allows workloads running outside Google Cloud (like in AWS or on-premises) to exchange their own identity tokens for Google Cloud OAuth 2.0 access tokens. ADC can be configured to use Workload Identity Federation by setting environment variables for the external identity. The difference is that standard ADC works only within Google Cloud or with a service account key file, while Workload Identity Federation extends ADC to external platforms.
If your app runs on an AWS EC2 instance, you cannot use a Google Cloud metadata server. Instead, you configure ADC to use Workload Identity Federation by setting the AWS role ARN in an environment variable, and ADC swaps that for a Google Cloud access token.
Must Know for Exams
Application Default Credentials is a high-priority topic in the Google Associate Cloud Engineer (ACE) certification exam. It appears in multiple exam objectives, particularly those related to security, identity, and application development. The exam expects you to understand not just what ADC is, but how the credential chain works and what happens when each link in the chain is present or missing.
Typically, exam questions present a scenario where an application running on a Compute Engine VM fails to authenticate to Cloud Storage, and you need to diagnose why. The answer often involves understanding that the GOOGLE_APPLICATION_CREDENTIALS environment variable is pointing to a faulty or missing file, and that the VM's attached service account would have worked if the environment variable were not set. Alternatively, you might see a question where a developer's code works locally but fails in production.
The root cause is that the local machine uses user credentials via gcloud, but the production VM has no attached service account and no environment variable set. Questions also test your knowledge of best practices. You may be asked to choose the most secure method to provide credentials to an application.
The correct answer is always to use a user-managed service account attached to the resource, not to download a JSON key file. The exam emphasizes that service account keys are long-lived secrets and should be avoided when possible. ADC, combined with the metadata server, is the recommended pattern.
Another frequent question pattern involves updating permissions. For example, you have an application using ADC that needs to write to a specific BigQuery dataset. The exam will ask what step is required.
You must know that you need to grant the IAM role (e.g., BigQuery Data Editor) to the service account that the VM is using, not to a user or a different service account. The exam also covers the difference between ADC and using a Service Account Key file directly.
You should know that ADC is the preferred method, but if you must use a key file (e.g., for workloads outside Google Cloud), you set the GOOGLE_APPLICATION_CREDENTIALS environment variable.
Understanding the priority order is critical: environment variable first, then attached service account, then gcloud default user credentials. Mistaking this order in a question will likely lead to a wrong answer.
Simple Meaning
Imagine you work in a large office building that has many secure doors. Normally, you would need to carry a keycard to get through each door. But sometimes you forget your keycard at home, or you lose it.
Application Default Credentials (ADC) is like having a universal digital badge that the building itself gives you depending on where you are. If you are inside your own office cubicle (on a Google Compute Engine VM), the desktop computer there already knows who you are, so it just lets you through. If you are working from a coffee shop (your local machine), ADC first checks your wallet for a special printed badge (the GOOGLE_APPLICATION_CREDENTIALS environment variable).
If that is not there, it looks in the company locker room (the gcloud SDK default credentials). Failing that, it looks at your own personal ID card (your Google user account) to see if you have permission. The goal is that you never have to remember which badge works where.
The system tries every possible way to get you in, securely and automatically. This is crucial because in cloud computing, hardcoding a password or key into your code is like taping your keycard to the front door. It is very dangerous.
ADC removes that temptation by handling authentication for you, following a specific order of checks until it finds valid credentials. This keeps your code clean, portable, and secure across different environments like development, testing, and production. The system is designed so that it works without you having to write any special authentication logic.
You just call the ADC library, and it does the rest.
Full Technical Definition
Application Default Credentials (ADC) is a credential resolution strategy implemented by the Google Cloud Client Libraries and Google Cloud SDK. When you write code that requires authentication to a Google API, such as calling Cloud Storage or BigQuery, the library attempts to discover credentials using a predefined, prioritized chain of providers. The first provider checked is the GOOGLE_APPLICATION_CREDENTIALS environment variable.
If this variable is set, the system reads the file it points to, which must be a JSON key file for a Google service account, and uses that service account's identity. If that environment variable is not set, the next check is the service account attached to the resource where the code is running. This applies to Google Compute Engine (GCE) instances, Google Kubernetes Engine (GKE) node pools, Cloud Run services, Cloud Functions, and App Engine standard and flexible environments.
Each of these compute platforms has a metadata server that exposes an access token tied to the attached service account. The ADC library contacts the metadata server at the well-known IP address 169.254.
169.254 to obtain an OAuth 2.0 access token. If no attached service account is found, ADC next looks for credentials from the Google Cloud SDK (gcloud) that have been set up via gcloud auth application-default login.
This is typically used for local development. Finally, ADC attempts to use the credentials of the user who is logged into the gcloud CLI (gcloud auth login). This is the least preferred method because user credentials may have different and potentially broader permissions than a dedicated service account.
Each step in this chain is a Provider interface that implements getCredentials(). The library iterates through the providers and returns the first non-null set of credentials. This mechanism ensures that code written once can run unchanged in a developer's local environment, on a test VM, and in production.
The OAuth 2.0 tokens obtained through ADC have a limited lifetime, typically one hour, and the library automatically handles token refresh by using the stored credentials to request a new access token before expiration. All communication uses HTTPS, and tokens are scoped to the Cloud Platform scope by default.
Understanding this priority chain is critical for IT professionals because misconfiguration can lead to authentication failures, often in confusing ways, such as when a locally set environment variable overrides a valid service account in production.
Real-Life Example
Think of a university library that has multiple separate reading rooms, each with its own door lock. As a student, you could enter any room if you present an accepted form of identification. But the library is clever: it does not make you fumble through your backpack every time.
Instead, it has a smart system at each door. If you are using a computer inside the library's computer lab (which is like a Google Compute Engine VM), the lab computer already knows you are a registered student because it logged you in when you sat down. The door just opens.
That is the metadata server approach. Now imagine you are working on a project with your own laptop in the courtyard. You need to get into the rare books room. Your laptop does not have the automatic connection, so ADC checks your bag.
It first looks for a special library key fob you might have stashed in a specific pocket (the GOOGLE_APPLICATION_CREDENTIALS environment variable). If you put that fob there, the door reads it and lets you in. If not, the system then sees if you have a general student ID card that you signed in with at the front desk earlier (gcloud auth application-default login).
If you did, that card works. Finally, the library door tries to use your actual student enrollment record (your personal Google account) just to confirm you are a student, though this is the least preferred method because it might not have the specific permissions for rare books. This system is great because you never need to tape a key to the door or memorize a combination.
The door always tries the safest and most efficient method first, and you only need to worry about making sure at least one valid identification method is available for your current location.
Why This Term Matters
Application Default Credentials matters because it fundamentally changes how developers and system administrators approach security and portability in cloud applications. In traditional application development, hardcoding credentials, such as API keys or database passwords, was a common but risky practice. Developers often committed secrets to version control, left them in configuration files, or stored them in insecure locations.
ADC eliminates this entire class of security vulnerabilities by providing a systematic, automatic method for credential discovery. For IT professionals managing cloud infrastructure, ADC simplifies lifecycle management. When a service account that your application relies on needs to be rotated or revoked, you only need to update the service account attached to the compute resource, not the application code itself.
The application continues to work because ADC always fetches the current token. This is especially important in production environments where uptime is critical. ADC promotes consistency across environments.
The same application code runs correctly on a developer's workstation using their own credentials (via gcloud auth application-default login), on a test VM with a dedicated service account, and in a production Kubernetes cluster using the node's service account. There is no need to maintain separate configuration branches or environment-specific secrets files. This reduces human error and speeds up deployment pipelines.
Another critical point is that ADC integrates with Google Cloud's Identity and Access Management (IAM) system. The credentials obtained by ADC are tied to a specific identity, either a service account or a user account. This means every API call made by the application is authenticated and authorized according to the permissions of that identity.
Auditing and governance become much easier because each action can be traced back to a specific identity. For organizations that must comply with regulations like SOC 2 or HIPAA, knowing exactly which identity performed which action is mandatory. ADC helps enforce the principle of least privilege because you can grant a service account only the permissions it needs, and the application will automatically use that limited identity.
Without ADC, developers might be tempted to use a single, overly permissive API key that bypasses fine-grained access control.
How It Appears in Exam Questions
In the Google ACE exam, ADC questions are usually scenario-based and ask you to identify the cause of an authentication failure or choose the correct configuration steps. One common pattern is the 'works local, fails in production' scenario. For example, you have a Python application that uses the Cloud Client Library to list objects in a Cloud Storage bucket.
The code works when run on your laptop using gcloud auth application-default login, but when deployed on a Compute Engine VM, it fails with a 'permission denied' or 'access token not found' error. The question will ask what is missing or misconfigured. The correct answer is often that the VM does not have an appropriate service account attached, or the service account lacks the necessary permissions.
Another pattern involves the GOOGLE_APPLICATION_CREDENTIALS environment variable. A question will describe that an administrator has set this variable to point to a JSON key file for a service account, but the application still cannot authenticate. The answer is typically that the key file is expired, the file path is incorrect, or the file does not exist on the VM.
The exam also tests your understanding of the ADC priority chain. For example, you may see a scenario where a VM has both a service account attached and the GOOGLE_APPLICATION_CREDENTIALS variable set to an invalid key. The application will fail because ADC checks the environment variable first and tries to use the broken key.
The correct answer is to unset the environment variable so that the attached service account is used. Configuration-based questions appear as well. You might be given a cloud deployment architecture: an application running on Cloud Run that needs to access Cloud SQL.
The question will ask how to configure credentials securely. The correct answer is to create a service account with the appropriate Cloud SQL roles, and then attach that service account to the Cloud Run revision. You do not need to pass any environment variable or download a key file because ADC on Cloud Run automatically uses the attached service account via the metadata server.
Troubleshooting questions go deeper. For example, an application is using ADC, but a specific API call returns a 403 error. The question asks what steps to take. You must answer: first, verify which service account is being used (by checking the VM's metadata or the GOOGLE_APPLICATION_CREDENTIALS variable), then check the IAM policy to ensure that service account has the required permissions on the resource.
Some questions also test the use of ADC with workload identity federation for on-premises or multi-cloud scenarios, though this is less common. The key is to remember that ADC is always the automatic fallback, and the first step in troubleshooting is to know which identity is active.
Practise Application Default Credentials Questions
Test your understanding with exam-style practice questions.
Example Scenario
You are a cloud engineer working for a media company. Your team has built a Node.js application that uploads video thumbnails to a Google Cloud Storage bucket. You developed this application on your local Windows laptop, and it works perfectly.
You set up your local credentials using the gcloud auth application-default login command, and every time you run the app, it uploads the thumbnails successfully. Now it is time to move the application to a production environment. You create a new Compute Engine VM in Google Cloud.
You deploy the exact same code, configuring it to run as a system service. But when the application starts, it fails with an authentication error: 'Your application has authenticated using end user credentials from the Google Cloud SDK. We recommend using a service account instead.'
The thumbnails are not being uploaded. You check the VM settings and realize that the VM is using the default Compute Engine service account, which has only the 'compute viewer' role by default. This service account does not have permission to write to Cloud Storage.
You also notice that you did not set any environment variable for GOOGLE_APPLICATION_CREDENTIALS. Because of this, ADC on the VM first checked the environment variable (not set), then it successfully discovered the attached default service account via the metadata server, and it used that identity. The problem is not that ADC failed, but that the identity it found lacks the necessary permissions.
To fix this, you stop the VM, change its attached service account to a custom one that you created called 'thumbnail-uploader-sa' which has the 'Storage Object Admin' role on the thumbnails bucket. You start the VM again. This time, ADC automatically uses this new service account, and the application starts uploading thumbnails successfully.
No code changes were needed. You also set up monitoring to alert if uploads fail, and you rotate the service account's keys regularly. This scenario shows how ADC handles the credential discovery seamlessly, but you still must ensure that the service account attached to the resource is the right one with the right IAM roles.
Common Mistakes
Assuming a VM always uses the service account attached to it, even when GOOGLE_APPLICATION_CREDENTIALS is set to a different file.
ADC checks the environment variable first. If it is set, even to a wrong or expired key, ADC will use that and ignore the attached service account entirely.
Unset the GOOGLE_APPLICATION_CREDENTIALS environment variable in your code or system configuration to let ADC fall through to the attached service account.
Hardcoding the path to a service account JSON key file inside the application code instead of using ADC.
Hardcoding paths makes the application inflexible and less secure. It also bypasses the automatic ADC chain, so you must manage the key file's location manually. If the path changes or the key expires, the application breaks without updating the code.
Remove hardcoded paths and rely on ADC by initializing the client with no explicit credentials. Then configure credentials via environment variables or attached service accounts.
Thinking that ADC works the same way on Google Cloud and on-premises without any extra configuration.
On-premises, there is no metadata server. ADC cannot automatically discover an attached service account. It will only work if you set GOOGLE_APPLICATION_CREDENTIALS or have gcloud default credentials configured.
For on-premises workloads, use ADC by setting the GOOGLE_APPLICATION_CREDENTIALS environment variable to point to a valid service account key file, or use Workload Identity Federation.
Using personal user credentials (from gcloud auth login) in production applications because they work on the developer's local machine.
User credentials are tied to an individual, not an application. If the user leaves the company, the credentials are revoked, breaking the application. User accounts also often have too many permissions, violating the principle of least privilege.
Create a dedicated service account with the minimum required roles, and attach it to the production resource so ADC automatically uses it.
Forgetting that the GOOGLE_APPLICATION_CREDENTIALS environment variable must point to a file, not a directory or a raw JSON string.
ADC expects a file path to a JSON key file. If you set the variable to a directory path or copy the JSON content directly, ADC throws a 'file not found' or parse error.
Verify that the variable contains the absolute path to the JSON file (e.g., /home/user/my-key.json), and that the file exists and is readable by the application.
Exam Trap — Don't Get Fooled
{"trap":"The question describes an application running on a Compute Engine VM that is authenticated but still getting 'permission denied' errors. It asks why, and the options include using the wrong service account or having incorrect IAM permissions. But there is also a choice that says 'the VM is using the default compute service account with no roles.'
","why_learners_choose_it":"Learners think that the default service account has no permissions at all, so they blame it first without considering other possibilities like the GOOGLE_APPLICATION_CREDENTIALS variable overriding it or the VM's metadata server being unreachable.","how_to_avoid_it":"Remember that the default Compute Engine service account actually has several default IAM roles, including roles/compute.viewer and sometimes roles/storage.
objectViewer (if the project has the necessary APIs enabled). A 'permission denied' error nearly always indicates that the service account being used lacks the specific role (e.g., roles/storage.
objectAdmin) for the resource, but it could also be because the environment variable is pointing to a different service account with insufficient permissions. Always check which identity is active first by looking at the environment variable and the attached service account's scopes or IAM roles."
Step-by-Step Breakdown
Application calls a Google Cloud API
Your code, using a Google Cloud Client Library (e.g., for Storage or BigQuery), makes an API call. The library does not have any explicit credentials, so it triggers the ADC resolution process.
Check GOOGLE_APPLICATION_CREDENTIALS environment variable
ADC first looks for the GOOGLE_APPLICATION_CREDENTIALS environment variable. If this variable exists and contains a valid file path to a service account JSON key file, ADC reads that file and extracts the service account email and private key. It then uses OAuth 2.0 client credentials flow to obtain an access token. This step overrides all other methods if set, so it must be used carefully.
Check metadata server on Google Cloud resources
If the environment variable is not set, ADC contacts the metadata server at IP 169.254.169.254. This server is available on all Google Cloud compute resources (VMs, GKE nodes, Cloud Run, Cloud Functions). The metadata server returns an access token for the service account attached to the resource. If the resource has no service account attached, the server returns none, and ADC continues to the next step.
Check gcloud application default credentials
If no metadata server is available (e.g., on your local machine), ADC looks for credentials that were stored by the command gcloud auth application-default login. This command stores credentials in a well-known directory (e.g., ~/.config/gcloud/application_default_credentials.json). ADC loads these credentials and uses them to obtain a token. These are typically long-lived refresh tokens that can generate new access tokens.
Check gcloud user credentials
As a last resort, ADC checks for user credentials set by gcloud auth login. These are the same credentials used for the gcloud CLI. This method is not recommended for applications because user accounts are not meant for programmatic API access. If this step succeeds, ADC uses the user's OAuth 2.0 token, but it will likely have broad permissions and may require user interaction if the token expires.
Obtain and use OAuth 2.0 access token
Once ADC finds a credential source, it completes the OAuth 2.0 flow to get an access token. The token is then appended to the API request as a Bearer token in the Authorization header. The client library automatically caches the token and refreshes it when it nears expiration, so the application can continue to make API calls seamlessly.
Practical Mini-Lesson
Application Default Credentials is one of the most important concepts to master when building applications on Google Cloud because it directly impacts security, portability, and operational simplicity. As a professional, you must understand that ADC is not a single credential, but a strategy. It is a prioritized list of places to look for credentials.
The first match wins. The priority order is: environment variable > attached service account > gcloud application default credentials > gcloud user credentials. This chain is critical because it means you can inject a specific service account into any environment by simply setting an environment variable, regardless of what the underlying compute resource has.
However, this also introduces a common pitfall: you can accidentally override a perfectly good attached service account with a stale or misconfigured environment variable. In practice, you should always prefer using an attached service account on Google Cloud compute resources. This avoids managing long-lived secrets and makes credential rotation automatic when you update the service account.
When you create a Compute Engine VM, you can select a custom service account in the creation wizard, and that service account will be used by ADC without any code changes. For Cloud Run, you attach a service account to the Cloud Run service revision. For GKE, you configure the node pool or use Workload Identity to bind a Kubernetes service account to a Google Cloud service account.
Every managed compute option on GCP supports this pattern. For local development, use gcloud auth application-default login. This command creates a file in your home directory containing your user's refresh token.
This is fine for development, but never for production. If you need to run a production application outside Google Cloud, for example on a bare-metal server in your data center, the best practice is to create a dedicated service account, download its JSON key, and set the GOOGLE_APPLICATION_CREDENTIALS environment variable to that key file's path. Make sure to store this file securely, restrict its permissions, and rotate keys regularly.
You can also use a secret management tool like Google Cloud Secret Manager to store the key, but you still need to set the environment variable to the path where the secret is materialized. Another advanced pattern is to use Workload Identity Federation, which allows external workloads to impersonate a service account without any static keys. The key takeaway for professionals is to automate the credential selection.
Your application code should never reference a specific key file path or account. Let ADC do the heavy lifting. This makes your application deployable to any environment with zero config changes, which is a golden standard for cloud-native development.
Always test the ADC chain by starting an application on a VM without any environment variable set to ensure the attached service account works as expected. This is a typical pre-production validation step.
Memory Tip
Remember ADC priority as EV (Environment Variable), then AS (Attached Service account), then GD (gcloud Default), then GU (gcloud User). The mnemonic 'EV-AS-GD-GU' sounds like 'Evasive Good GUy', helping you recall the order from first to last.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
Related Glossary Terms
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
An A record is a type of DNS resource record that maps a domain name to an IPv4 address.
AAA (Authentication, Authorization, and Accounting) is a security framework that controls who can access a network, what they are allowed to do, and tracks what they did.
802.1X is a network access control standard that authenticates devices before they are allowed to connect to a wired or wireless network.
5G is the fifth generation of cellular network technology, designed to deliver faster speeds, lower latency, and support for many more connected devices than previous generations.
A/B testing is a controlled experiment that compares two versions of a single variable to determine which one performs better against a predefined metric.
Frequently Asked Questions
What is the GOOGLE_APPLICATION_CREDENTIALS environment variable?
It is an environment variable that you set to point to a file path containing a service account JSON key. When ADC finds this variable set, it uses that file to authenticate, overriding all other credential sources.
Does ADC work on my local Windows or Mac machine?
Yes. You need to either set the GOOGLE_APPLICATION_CREDENTIALS environment variable or run gcloud auth application-default login. Without one of these, ADC will fail because there is no metadata server on your local machine.
What happens if none of the credential sources are available?
ADC throws an exception indicating that it could not find any credentials. Your application will crash or return an authentication error. You must configure at least one source for ADC to work.
Is it safe to use ADC in production?
Yes, when used correctly. The safest production pattern is to attach a dedicated, limited-privilege service account to your compute resource (VM, Cloud Run, GKE). This eliminates the need to manage static keys. Avoid using user credentials or service account key files unless absolutely necessary.
Can I force ADC to use a specific service account when multiple are available?
Yes. You can set the GOOGLE_APPLICATION_CREDENTIALS environment variable to the key file of the desired service account. This overrides any attached service account. However, for security, it is better to only attach one service account per resource.
How does ADC handle token expiration?
ADC obtains an OAuth 2.0 access token that typically expires in one hour. The client library automatically uses the credential source (e.g., the service account private key or refresh token) to request a new token before the current one expires. This is transparent to your application.
What is the difference between ADC and using a Cloud Client Library with explicit credentials?
Explicit credentials require you to pass a credentials object to the library, which you must create from a key file or another source. ADC eliminates this by automatically finding the credentials, making the code cleaner and more portable.
Summary
Application Default Credentials (ADC) is a foundational security mechanism in Google Cloud that automatically resolves authentication for applications without requiring you to hardcode secrets. It follows a strict priority chain: first the GOOGLE_APPLICATION_CREDENTIALS environment variable, then the service account attached to the compute resource, then gcloud application default credentials, and finally gcloud user credentials. This system allows the exact same code to run securely in local development, on-premises servers, and fully managed Google Cloud environments like Compute Engine, Cloud Run, and GKE.
The primary benefit of ADC is portability and security. By removing the need to embed keys in code or configuration files, it reduces the risk of credential leaks and simplifies change management. When a service account is rotated or updated, your application continues to work because ADC automatically fetches fresh tokens.
For the Google Cloud ACE exam, ADC is a critical topic. You must know the priority order, how to diagnose authentication failures, and the best practice of using an attached service account over user credentials or static key files. Common exam traps include forgetting that the environment variable overrides the attached service account and assuming that a VM's default service account always has the needed permissions.
As a professional, adopt the habit of using ADC everywhere and only resorting to service account key files when absolutely necessary, such as for workloads running outside Google Cloud. Mastering ADC will not only help you pass your certification exam but will also make you a more effective and security-conscious cloud engineer. The mnemonic 'EV-AS-GD-GU' can help you recall the priority order quickly under exam pressure.