Trace principals, policy decisions and temporary sessions; constrain workloads and protect emergency access with testable controls.
50 min 180 XPSkills: Policy evaluation, Federated access, Credential controls
Brief
At Halcyon Clinics, a nightly billing exporter can read invoices and delete backups. Its owner calls it a read-only service account because the script only issues reads. During an access review, an analyst discovers a wildcard policy and a static credential copied into three deployment files. The business requirement is narrower: read the current invoice export, once per night, without changing any records.
Cloud access is a decision about a principal performing an action on a resource under specific conditions. A successful login establishes identity, not permission. In this room you will distinguish users, roles and workload identities, trace conflicting policies, and replace persistent secrets with bounded sessions. Your evidence must show both what access was approved and what the platform actually allowed.
A read-only script is not a read-only identity: permissions describe what it could do, not merely what it did yesterday.
Principals and the two gates of role assumption
A principal is an identity that can make an authenticated request. A user represents a person; a workload identity represents a running service or job. A role is an assumable permission-bearing identity rather than a shared password. In systems with role sessions, the caller obtains credentials for a role and subsequent requests are evaluated as that session. Record the initiating identity as well as the session identity so a shared role does not destroy attribution.
Role assumption has two distinct gates: who is trusted to request a session, and what the resulting session may do. A trust policy admitting a reporting workload does not itself grant invoice reads. Conversely, a role permission allowing invoice reads does not make every workload eligible to assume it. Require an exact workload subject and intended audience, not merely membership in a broad identity issuer. A role with narrow data permissions can still be dangerous if an unrelated workload may assume it.
This supports separation of duties and unique accountability. Keep role trust exports, permission versions, approved owners and session issuance events. An auditor should be able to join an invoice read back to the initiating workload or human and ask whether that identity was entitled to assume the role at that time.
Evaluate a request, not a policy nickname
Use a deny-by-default model: with no applicable allow, reject the request. An applicable explicit deny overrides an allow, regardless of statement order. For this room, policies combine matching allows subject to matching denies; production systems may also require grants from resource policies or impose session and organization ceilings. A ceiling restricts permissions; it is not a grant. Check the actual platform evaluation rules before reasoning across identity and resource policy boundaries.
Consider a session requesting object.read on invoices/2026/march.csv. An allow for object.read on invoices/2026/* matches; a deny for object.delete does not. The read succeeds. A delete request matching both object.* allow and object.delete deny fails. A read on payroll/march.csv with no matching allow also fails, but by implicit/default deny rather than explicit deny. Wildcards expand action or resource scope: object.* can include future actions, while invoices/* can include future records. Least privilege narrows both dimensions and adds conditions such as environment or session assurance where supported.
Permission review evidence should include policy versions and positive and negative decision tests. Test an intended read, an unrelated resource and a destructive action; a screenshot of a policy named Viewer proves none of these. Ask which statement and condition caused each result and retain the evaluated principal, resource and timestamp without storing credentials.
A matching deny defeats a grant; an absent grant also blocks access, for a different reason.
Federation, session lifetime and secret delivery
Federation accepts identity assertions from a trusted external identity service instead of maintaining a second password for each person. SAML or OIDC can convey authenticated identity; the cloud maps validated claims to a role. For OIDC, validate signature, issuer, audience, expiry and the allowed subject before exchanging a token for a session. Authentication at the issuer does not guarantee that a broad role mapping is safe. Human administrative sessions should additionally require strong multifactor authentication and an approved entitlement.
A workload can similarly exchange its verified runtime identity for short-lived role credentials. A 15-minute session limits the useful lifetime of a stolen credential compared with an unexpired static key, but does not prevent theft or use during those 15 minutes. Stopping new sessions may not revoke sessions already issued; verify revocation behavior and incident containment controls. Refresh through the identity exchange rather than writing a replacement permanent key into a configuration file.
Some external systems still need passwords or API keys. A secret manager protects storage and delivery, not the authority carried by the secret. Authorize reads per secret, audit retrieval, rotate the destination credential and update consumers safely; avoid logging plaintext. Store session issuance, retrieval and rotation evidence with owners and expiry dates. Ask whether the credential remains usable after the purported rotation, not just whether a new secret version exists.
Federation creates bounded sessions; a secret manager handles residual secrets rather than replacing authorization.
Root authority and emergency access without silent bypass
The account root or initial owner identity may have powers ordinary role policies cannot fully constrain, such as changing recovery settings. Keep it out of routine operations, remove unnecessary programmatic credentials, protect it with strong multifactor authentication and protect recovery channels to the same standard. Do not assume that attaching a normal deny policy contains this identity. Use delegated administrative roles for ordinary changes and alert on root authentication and privileged actions.
Break-glass access is an explicitly governed emergency path, not an excuse for a shared daily administrator login. Make it resilient to the failure it addresses: a recovery account dependent on the same unavailable federation service cannot restore access. Use individually attributable activation where possible, protected offline recovery material, dual authorization when feasible, immediate use alerts and a time-bounded incident record. Test recovery quarterly in this example, then verify credential resealing or rotation and removal of temporary privileges.
Emergency access supports availability but creates an exception to normal access governance. Retain the authorized custodians, sealed-material inventory, test results and post-use reviews. Auditors should ask who could activate the path, what they actually did, and whether every use was independently reviewed. Never store recovery codes in the evidence repository merely to prove that they exist.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: The last statement myth
Scenario sim+60 XP
Read the brief and answer both questions.
Incident brief
An operator says the last policy statement wins. A role has an allow for object.* on archive/* followed by a deny for object.delete on archive/*. Its session requests object.delete on archive/old.csv. A second request reads payroll/pay.csv; no statement grants access to payroll. No other grants, conditions or policy layers apply.
1.1Which policy effect overrides the allow for the archive deletion? (two words)
1.2Which deny-by-default rule blocks the payroll read without a matching grant? (two words)
Task 2: A token is not a permanent key
Scenario sim+60 XP
Read the brief and answer both questions.
Incident brief
The payroll team labels its new design key rotation. In reality a job presents a signed runtime identity token from a trusted external issuer and exchanges it for a 15-minute role session. No persistent cloud key is created. The security lead says the issuer signature alone proves the token was intended for this exchange; the token also carries a claim identifying its intended recipient.
Term bank, not all of these are right
federationaudiencekey rotationresource wildcard
2.1What identity trust mechanism lets this external issuer supply identity for cloud access? (one word)
2.2Which claim must match the intended token recipient? (one word)
Task 3: The root automation exception
Scenario sim+60 XP
Read the brief and answer both questions.
Incident brief
A backup job uses the initial account owner identity, which this environment calls root. An engineer proposes putting its permanent credential in a vault and calling it least privilege. The job actually needs only object.read on one export prefix. An approved emergency account is separately protected and should remain available if the normal identity service fails.
Term bank, not all of these are right
rootleast privilegeencryptionavailability zone
3.1Which identity must be removed from the job's routine execution? (one word)
3.2Which access principle requires limiting the replacement role to necessary actions and resources? (two words)
Labs
80 bonus XP
Hands-on work. You edit the artefact, the server runs the checks: the expectations and the reference solution never reach your browser.
Halcyon Clinics wants the invoice exporter repaired. The operator proposes a new permanent key and a role named ReadOnly with object.* permissions. Neither the name nor key replacement satisfies the requirement.
Write a declarative control plan, not executable platform policy. Use the fixture's exact identifiers, a role session lasting between 1 and 15 minutes, and an explicit deletion guardrail. Explain how the residual external password is delivered without embedding it. All fields are mandatory.
The change board labels all six proposals identity hardening because every proposal mentions a security feature. Approve only changes meeting the stated requirements; judge each independently with no unstated compensating controls.
Routine jobs must have only necessary permissions, role trust must identify the authorized caller, sessions must expire, and emergency access must be tested and monitored. For each rejection choose the single most direct defect code.
Verdicts are accept or reject. Every rejection needs one reason code from: excess-permissions | broad-trust | persistent-key | ungoverned-recovery.
Independent proposals awaiting approval
CI-1 Invoice job needs only reads; proposal grants object.* on invoices/* because its script currently reads only.
CI-2 Role grants only invoice reads; trust accepts every subject from a shared issuer although only billing-exporter is approved.
CI-3 Job exchanges its validated runtime identity for a scoped 10-minute role session; it has no static cloud key.
CI-4 Permanent cloud key stays embedded in a deployment file; proposal renames the file encrypted-secrets without adding encryption or access restrictions.
CI-5 Emergency account avoids the normal federation dependency, has protected recovery material and strong multifactor authentication, alerts on every use, and a successful quarterly test with independent post-use review.
CI-6 Root account is reserved for emergencies but recovery instructions have never been tested and successful logins produce no alert.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Checks
Every line in the fixture carries a verdict
Accept and reject land on the right lines
Each rejection cites a valid reason code
Next on your path · Cloud Fundamentals
Cloud Data Protection
Trace encrypted data and key dependencies, then test classification, location, and destruction claims against evidence.
