What is a cloud administrator?¶
A cloud administrator is a user or workload identity given elevated permissions over a defined part of a cloud environment. “Admin” is not one universal power. The useful questions are which role, over which resources, during which period - and whether the system recorded the relevant action.
Priya can reset Dave's password - but did she?¶
Priya supports Northstar's Google Workspace users. Her User Management Admin role can allow her to create, rename and delete non-administrator accounts and change their passwords. It does not give her every Super Admin power.
At 09:12 Dave's password is reset. Knowing that Priya had the capability creates a line of enquiry. A Google Admin log event identifying its Actor, Event, target or affected resource, time and network context can address the separate question of what the system recorded.
The illustration is a teaching model rather than a reproduced vendor event. Use the provider's exact event name and fields from the supplied return.
Record the administrator's real scope¶
| Role or route | Example capability | What it does not automatically prove |
|---|---|---|
| Google Super Admin | Manage every aspect of the organisation's account and other administrators | That the person used those powers for this event |
| Google User Management Admin | Create, delete, rename or change passwords for non-admin users; scope can be limited | Power over administrator accounts or every service setting |
| Google Help Desk Admin | Reset passwords for non-admin users and view profiles; scope can be limited | File access or unrestricted tenant control |
| Microsoft Entra User Administrator | Create users and manage supported user operations | Every privileged role or content action |
| Service account or application | Perform authorised administrative operations through an API | A fresh human action for each resulting event |
Roles and product definitions change. Preserve the assigned role name, its scope, its start and end time, and the provider documentation that described its permissions during the relevant period.
Read the administrative event literally¶
Google Workspace Admin log events currently include attributes such as Actor, Actor application name, Event, Date, IP address, affected Resource, Target, and relevant Old value and New value. Google notes that Actor may sometimes be a service account or another non-person label, and that application details can include an OAuth client ID and whether the application impersonated a user.
Microsoft Entra audit logs show the date and time, service, activity category and name, and status. Opening an entry can reveal a correlation ID, actor or target-resource details and, where applicable, old and new property values.
Those are not interchangeable schemas. Record the exact provider field and value rather than rewriting both as “an administrator changed it”.
A worked reading of the password-reset event
Suppose the return shows:
- Actor:
priya@northstar.example - Event: the provider's password-reset action
- Target/resource:
dave@northstar.example - Date:
2026-07-10T09:12:08Z - IP address:
203.0.113.44
Recorded: the provider associated Priya's administrative account context with a password-reset event targeting Dave's account at that time and address.
Still open: whether Priya personally controlled the session, whether an application acted for her, why the reset was performed, and whether the address represents the expected device or a proxy/VPN route.
Compare the event with Priya's authentication, multi-factor authentication and device records, the support ticket or approval, Dave's subsequent sign-in and any other administrative activity in the same cloud session.
Why the administrator may also be an evidence holder
An administrator may explain the tenant, role design, retention settings and export process. Their explanation is useful, but preserve the underlying role assignment, configuration and audit export so another person can test it.
If the relevant administrator may be implicated, plan preservation through another authorised route. Do not rely on the person whose activity is in question to define or collect the only copy of the evidence.
Use the three-part test¶
For any suspected administrative action, establish separately:
- Role: did the identity hold the necessary role at the relevant time?
- Event: did the provider record that action, target and result?
- User or process: who or what controlled the administrative session or application route?
A failure at one stage changes the enquiry. No capability suggests another role or route. Capability without an event calls for the actual audit and configuration records. An event without personal attribution calls for session, application, device and surrounding evidence.
The point to remember
“Administrator” describes potential authority, not a recorded act. Fix the exact role and period, find the provider event, then establish the human or automated route that controlled it.
