If you give someone unlimited access to your most sensitive systems and that account gets hacked, your entire company can be destroyed in minutes. That is the problem Privileged Access Management (PAM) and Just-in-Time (JIT) access solve: they limit who can do what, when, and for how long, drastically reducing the chance of catastrophic damage. For the Google Professional Cloud Security Engineer exam, you must understand how to design and enforce these guardrails because nearly every question about identity or permissions revolves around the principle of least privilege.
Jump to a section
A simple way to picture Privileged Access Management and Just-in-Time Access
A bustling nightclub with a main dance floor, a VIP section, and a secure backstage area where the DJ is setting up. The club has a strict rule: no one enters the backstage area without a verified pass. The club manager, Sam, uses a system that grants temporary backstage passes only when a stagehand actually needs to swap a piece of equipment. This is just-in-time access.
Normally, only the sound engineer, Tina, has a permanent backstage pass because she monitors the equipment all night. But tonight, a fuse blows. Sam gets a request on his tablet: “Sound engineer needs temporary access to the fuse box.” Sam approves it from his phone. The system immediately issues a digital pass that expires in ten minutes. Tina scans her phone at the backstage door, fixes the fuse, and the pass expires before she leaves the area. If the pass were permanent, a lost phone or a dishonest employee could lead to stolen gear or a tampered soundboard.
This analogy maps precisely to Privileged Access Management (PAM) in cloud computing. The club is the company’s cloud environment. The backstage area is a critical server or database. The permanent pass is a standing administrative “superuser” account — dangerous if compromised. The temporary, approved, time-limited pass is Just-in-Time (JIT) access. The manager’s approval from his phone is the access approval workflow. Every action is logged, and the pass auto-revokes, just like a cloud platform revokes a JIT elevation after a set window.
Privileged Access Management (PAM) is the set of policies, processes, and technologies used to control and monitor access to an organisation’s most critical systems — the “keys to the kingdom.” A privileged user is anyone with elevated permissions, such as an administrator who can delete databases, change firewall rules, or modify user accounts. Traditional IT gave these users permanent, always-on privileged access, like giving every manager a master key to every room in the building forever. This is extremely risky because if one of those accounts is compromised — say an attacker steals the password — they inherit all that power.
Just-in-Time (JIT) access is a core component of modern PAM. Instead of granting permanent privileges, JIT provisions privileged access only when a user needs it to perform a specific task, for a limited duration, and often after an approval. The Google Cloud implementation of this is called “Privileged Access Manager” (PAM) — yes, the product name shares the acronym. It lets you define “entitlements” (a set of permissions and a target resource) that a user can request. The request goes through an approval workflow. If approved, the user gets a time-bound role assignment, typically for minutes or hours, and it auto-expires.
Here is why this matters. In Google Cloud, every action is governed by Identity and Access Management (IAM) roles. An IAM role is a collection of permissions. For example, the “Compute Admin” role gives full control over virtual machines. In a permanent model, you might assign that role to a junior engineer who only occasionally needs to restart a server. That engineer’s account, if compromised, gives an attacker total control over your compute resources. With JIT, the engineer has no such role by default. When they need to restart a server, they go to a portal, select the “Compute Admin” entitlement, provide a reason, and request approval. Their manager approves via email or chat. Google Cloud temporarily adds the role to the engineer’s identity for, say, two hours. The engineer performs the restart. After two hours, the role is automatically removed. If the engineer’s account were stolen during those two hours, the attacker would have access only for the remaining time window — not indefinitely.
Access approval is the second pillar. Many security frameworks and regulations (like SOC 2 and PCI DSS) require that privileged actions be approved by someone other than the person performing them — this is called “separation of duties.” JIT access enforces that naturally because the requestor cannot approve their own request. In Google Cloud’s PAM product, you can define multiple approval tiers: for example, a low-risk entitlement might need one approval, while deleting a production database might require two approvals from different managers.
The old approach — permanent privileged accounts — created problems like “privilege creep,” where people accumulated permissions over years and kept them even after changing roles. It also made auditing difficult: who actually used which permission when? With JIT, every elevation is logged: who requested it, who approved it, when it started, when it ended, and what actions were taken during that window. This creates a clear audit trail.
For the exam, understand these key terms:
Privileged Access Management (PAM): The overarching strategy.
Just-in-Time (JIT) Access: A specific technique within PAM.
Entitlement: In Google Cloud PAM, a pre-defined bundle of roles, target resources, and approval rules.
Approval Workflow: The sequence of authorisations required before access is granted.
Session Duration: The maximum time limit for the JIT elevation — once it expires, the role is revoked.
Standing Privileges: The opposite of JIT — permanent, always-on elevated access. The bad old way.
Google Cloud’s PAM product works on top of IAM. It does not replace IAM; it adds a layer of temporary, approved, time-bound provisioning on top of IAM roles. You must also know that PAM integrates with Cloud Audit Logs, so every elevation generates an audit log entry. This is essential for compliance and forensics.
Identify Privileged Roles and Resources
The organisation first determines which IAM roles are considered privileged (e.g., roles that can delete resources, modify security policies, or access sensitive data) and which resources they apply to. This step is critical because it defines the scope of what will be protected by JIT. In Google Cloud, you can use Security Command Center to discover all current IAM bindings that grant these roles.
Create an Entitlement in Privileged Access Manager
A security engineer defines an entitlement by specifying the target resource (e.g., a specific Cloud Storage bucket or a project), the IAM role(s) to grant (e.g., ‘Storage Admin’), the maximum allowed session duration (e.g., 2 hours), and the approval configuration (e.g., one approval from the project owner). An entitlement does not include which users can request it — that is specified separately by assigning the entitlement to a group or user.
Grant IAM Permissions to Request the Entitlement
Users need the IAM permission ‘privilegedaccessmanager.entitlements.request’ on the entitlement to be able to submit a request. This is granted by assigning the user (or a group containing the user) a role like ‘roles/privilegedaccessmanager.requestAccessor’. Without this, the user cannot even see the entitlement in the UI or API.
User Requests JIT Access
When an authorised user needs to perform a privileged action, they navigate to the Google Cloud console, select the appropriate entitlement, provide a justification (e.g., ticket number and reason), and submit the request. The PAM system records this request in Cloud Audit Logs.
Approval Workflow Executes
The approver(s) configured in the entitlement receive a notification (e.g., via email or Google Chat). They review the request, including the justification and the user’s identity. If approved, PAM immediately grants the specified IAM role to the user’s identity for the session duration. If rejected, no access is granted, and the user is notified. If multiple approvals are required, the request remains pending until all required approvals are obtained.
User Performs the Task While Access Is Active
The user now has the elevated IAM role for the session duration. They can perform the needed actions (e.g., delete a table, modify a firewall rule). Any actions taken are logged in Cloud Audit Logs under the user’s identity and the IAM role they temporarily hold.
Automatic Revocation After Session Duration
Once the session duration expires (e.g., after 2 hours), Google Cloud automatically removes the IAM role from the user’s identity. The user reverts to their baseline permissions. No manual revocation is needed. The audit trail captures both the start and end times of the elevation.
Consider a healthcare company, MediSecure, that stores patient records in Google Cloud BigQuery and runs a web application on Compute Engine. The company must comply with HIPAA, which requires strict access controls and logging of all privileged actions. The security team has decided to implement Google Cloud’s Privileged Access Manager.
Here is what an IT security engineer, Alex, actually does day-to-day:
Alex first identifies which roles are considered “privileged.” These include “BigQuery Admin,” “Compute Admin,” “Project Owner,” and “Security Admin.” Alex uses the Security Command Center to find all IAM bindings that grant these roles.
For each privileged role, Alex creates an “entitlement” in Google Cloud PAM. For example, one entitlement might be called “BigQuery-Admin-JIT” and allow the “BigQuery Admin” role on the “production-healthcare-data” dataset. The entitlement specifies that the maximum duration is one hour, and it requires approval from the data engineering manager.
Alex then removes the permanent “BigQuery Admin” role from all user accounts. Instead, Alex assigns the “BigQuery User” role (which only allows reading and querying non-sensitive data) to everyone as their baseline. Users now have no standing privileges to modify schemas or delete tables.
When a data engineer, Priya, needs to add a new column to a production table, she goes to the Google Cloud console, navigates to the PAM section, selects the “BigQuery-Admin-JIT” entitlement, types a justification (“Adding column for new lab results schema — ticket INC-54321”), and submits the request.
Alex, as a secondary approver (the data engineering manager), receives a notification via Google Chat. He reviews the reason and the linked ticket, confirms it is legitimate, and clicks “Approve.”
Within seconds, Priya receives a notification that her access is active. She now has the “BigQuery Admin” role on that specific dataset for one hour. She runs her SQL ALTER TABLE command, verifies it works, and submits the change for code review.
Meanwhile, Cloud Audit Logs automatically record: Priya requested entitlement X, Alex approved it at timestamp Y, the role was active from Y to Y+1 hour, and during that hour Priya ran exactly three ALTER TABLE statements.
After one hour, Google Cloud automatically removes the “BigQuery Admin” role from Priya’s identity. She is back to her base “BigQuery User” permissions. If an attacker compromises Priya’s account eight hours later, they cannot delete tables because the privileged role is gone.
Alex also periodically reviews the PAM logs using Cloud Logging to generate compliance reports for auditors. Alex sets up alerts using Cloud Monitoring so that if someone requests access outside of business hours or for an unusual resource, an alert fires. This proactive monitoring is a key part of the operational routine.
The result: MediSecure passes its HIPAA audit with flying colours because every privileged action has a documented approval, a time limit, and an audit trail.
The PCSE exam tests 2.4 “Implement privileged access management, including just-in-time access and access approval” quite directly. Expect multiple-choice questions, scenario-based questions, and possibly a case study that requires you to choose the correct configuration. Here is what the exam focuses on:
Distinguishing between PAM (strategy) and JIT (implementation): A typical question describes a company wanting to “reduce standing privileges” and asks which Google Cloud product to use. The answer is “Privileged Access Manager” (PAM). A trap answer is “use IAM conditions” because IAM conditions alone do not provide time-limited, approval-based elevation — they are for attribute-based restrictions, not proactive JIT.
Knowing the components of an entitlement: The exam will ask what you must define when creating an entitlement. The correct components are: target resource (or set of resources), the IAM role(s) to grant, the maximum allowed duration, and the approval configuration (who can approve, how many approvals needed). Traps include “user email” (that is not part of the entitlement definition; you assign users separately) or “budget cap” (irrelevant).
Understanding the approval workflow: Questions will test whether you know that the person requesting access cannot also be an approver for the same request. Another trap: they might ask what happens if no approver is configured — the correct answer is that the request is automatically denied, not that it is bypassed.
JIT vs. IAM Conditions: IAM Conditions can restrict access based on attributes like “source IP is inside the corporate VPN” or “request time is during business hours.” These operate passively — if the condition is met, access is allowed. JIT is active — the user must explicitly request, get approval, and then use the access within a window. The exam loves comparing these two.
Logging and auditing: Every JIT elevation is logged in Cloud Audit Logs. You will get a question asking which log contains the record of a privileged access request. Answer: Admin Activity audit logs (specifically the “PrivilegedAccessManager” service). Do not confuse with Data Access logs.
Security Command Center integration: The exam may mention that SCC can detect standing privileged accounts. You should know that SCC findings can trigger a recommendation to enable PAM for those accounts.
Access approval vs. access review: Access approval happens before access is granted (preventive). Access review (e.g., periodic review of IAM policies) happens after (detective). The exam may present a scenario where a company needs both. Know the difference.
Common trap: A question describes a user who needs to occasionally run a script that requires admin privileges overnight. They ask for “the most secure configuration.” The expected answer is to configure a JIT entitlement with a session duration that covers the expected window and require approval — not to grant a permanent role with a condition that limits to overnight hours (though that is also better than permanent, JIT is more secure because it requires explicit approval and auto-revokes).
Memorise this: “JIT = request + approval + time bound + auto revoke.” If a choice is missing any of those four elements, it is not JIT. - Key definitions to memorise: - “Privileged access” – access that allows modification of security settings, infrastructure, or data. - “Standing privileges” – permanent elevated access, the thing JIT aims to eliminate. - “Entitlement” – the bundle of roles, resources, and rules in PAM. - “Approval workflow” – the defined path for authorisation before access is granted. - “Session duration” – the maximum lifetime of a JIT role assignment.
Privileged Access Management (PAM) is the strategy of controlling elevated access; Just-in-Time (JIT) access is a method that grants privileges only when needed, for a limited duration, and often after an approval workflow.
Google Cloud’s Privileged Access Manager (PAM) product is the primary tool to implement JIT access and replaces the older pattern of permanent ‘superuser’ accounts.
An entitlement in PAM bundles together a target resource, one or more IAM roles, a maximum session duration, and an approval policy — it does not include specific user identities.
JIT access automatically revokes the elevated role after the session duration expires, reducing the window of risk if an account is compromised.
Every JIT access request, approval, and elevation is recorded in Cloud Audit Logs (Admin Activity logs), which is essential for compliance with frameworks like SOC 2 and PCI DSS.
JIT access and IAM conditions are complementary: IAM conditions passively restrict access based on attributes, while JIT actively requires a request and approval to activate temporary privileges.
Removing standing privileges and replacing them with JIT access directly enforces the principle of least privilege.
The person requesting a JIT elevation cannot also be an approver for that same request, ensuring separation of duties.
These come up on the exam all the time. Here's how to tell them apart.
Just-in-Time (JIT) Access
Grants elevated access only when requested and approved
Auto-revokes after a configurable session duration
Requires an explicit workflow (request, approval, justification)
Standing Privileges
Grants permanent, always-on elevated access
Does not auto-revoke — remains until manually removed
No workflow needed — user has access immediately at all times
Privileged Access Manager (PAM) JIT
User must actively request access and await approval
Temporarily adds an IAM role to the user identity
Creates a full audit trail of request, approval, and role assignment
IAM Conditions
User always has the role but it is conditionally effective
Role is permanently bound to the user, but filtered by attributes
Only the condition evaluation is logged, not the 'intent' to use access
Separation of Duties (via JIT Approval)
Requires pre-defined approval from another person
Used for planned or routine privileged tasks
Access is time-bound and auto-revokes
Break-Glass Access (Emergency Bypass)
Allows overriding normal approval in emergency
Used for critical incidents when approval chain would cause delay
Typically requires immediate post-event review and justification
Mistake
Privileged Access Management and Just-in-Time access are the same thing.
Correct
PAM is the overall framework for controlling privileged access; JIT is one specific technique within PAM. You can have PAM without JIT (e.g., using password vaults with manual checkout), but JIT is a modern, automated implementation of PAM.
The acronyms sound similar and are often used interchangeably in marketing materials, leading beginners to think they are synonyms.
Mistake
Once I set up JIT access, I no longer need IAM roles or policies.
Correct
JIT does not replace IAM. JIT works on top of IAM — it temporarily assigns IAM roles. The roles themselves, and the base policies, still exist. If you remove all base IAM roles, users cannot even request JIT access because they may lack permission to use the PAM API.
It is easy to think JIT magically handles all permissions, but it is just an overlay on top of Google Cloud’s existing IAM system.
Mistake
The Google Cloud product called ‘Privileged Access Manager’ (PAM) only exists for Compute Engine instances.
Correct
Google Cloud’s PAM supports any IAM-gated resource, including BigQuery datasets, Cloud SQL instances, Cloud Storage buckets, and project-level roles. It is not limited to compute.
Beginners often associate ‘privileged access’ with server admins, so they incorrectly assume the tool only applies to virtual machines.
Mistake
If a user requests JIT access and it is approved, they get a new account or password.
Correct
JIT does not create a new user account. It temporarily adds an IAM role to the user’s existing identity (their Google account or service account). The user logs in as normal and then gains the elevated permissions for the session duration.
People often think of ‘privileged access’ as a separate ‘admin’ account, which is a legacy model. JIT elevates your existing account temporarily.
Mistake
JIT access approval always requires a human manager to approve every request.
Correct
While human approval is common, JIT entitlement configurations can also be set to auto-approved (e.g., for low-risk roles) or require multiple approvals. The flexibility exists to balance security and operational speed.
Security resources often emphasise ‘just-in-time with approval’, so beginners assume approval always means a human click, when it can be automated or bypassed for certain cases.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
IAM conditions allow you to attach rules to a role binding that restrict when that role is effective (e.g., only from 9 AM to 5 PM). PAM (the JIT product) requires a user to explicitly request access, get approval, and then receive a temporary role assignment that auto-expires. IAM conditions are passive; PAM is active and requires an explicit workflow.
No. Service accounts are non-human identities used by applications and VMs. JIT access applies to human users. Service accounts should be managed with their own best practices (e.g., using short-lived credentials). PAM does not manage service account permissions.
No. The system enforces separation of duties: the requestor cannot be listed as an approver for the same entitlement. This ensures the user cannot grant themselves access without an independent review.
All events — requests, approvals, rejections, and role grants/revocations — are recorded in Cloud Audit Logs under the service name ‘privilegedaccessmanager.googleapis.com’. These are Admin Activity audit logs, not Data Access logs.
No. In fact, the whole point is to remove the permanent assignment. The user should only have the base permissions needed for their daily work. The JIT entitlement will temporarily grant the elevated role when needed and then revoke it.
Yes. You can combine PAM with IAM conditions on the entitlement. For example, you can add an IAM condition on the entitlement itself or on the role that grants the user permission to request access, so that requests are only allowed from a corporate VPN IP range.
You've finished Privileged Access Management and Just-in-Time Access. Continue through the PCSE study guide to build a complete picture of the exam.
Done with this chapter?