Identity, Access and Zero Trust

Introduction and Context

Cloud computing changes the security boundary. In a traditional data centre, access control was often organised around a corporate network, a small number of servers, and relatively stable user locations. Cloud environments are more distributed: users work from unmanaged networks, applications communicate through APIs, workloads are created and destroyed automatically, and data may be processed across several providers. Consequently, identity has become a principal control plane for security.

Identity and access management (IAM) determines who or what may access a resource, under which conditions, and for how long. It includes human identities, service accounts, application identities, devices, policies, authentication mechanisms, authorisation decisions, lifecycle processes, and audit evidence. Zero Trust extends this approach by rejecting implicit trust based on network location or prior access. Every request must be evaluated in context and granted only the access necessary for the requested action.

This chapter develops an IAM architecture suitable for cloud environments. It addresses least privilege, role-based and attribute-based access control, federation, single sign-on, multi-factor authentication, privileged access management, workload identities, secrets management, and Zero Trust design. It also considers governance, implementation trade-offs, operational failure modes, and regulatory responsibilities.

Learning Objectives

By the end of this chapter, a student should be able to:

1. Explain the relationship between identity, authentication, authorisation, accounting, and access governance.
2. Design IAM policies using least privilege, RBAC, ABAC, and risk-aware conditions.
3. Compare federation, SSO, MFA, passwordless authentication, and local cloud accounts.
4. Design controls for privileged users, workloads, APIs, secrets, and emergency access.
5. Apply Zero Trust principles to cloud applications and hybrid environments.
6. Evaluate IAM architectures against security, usability, resilience, privacy, and compliance requirements.
7. Propose an implementation and assurance plan for an enterprise cloud IAM programme.

1. Identity as a Cloud Security Control

An identity is a distinct, accountable subject capable of requesting an action. Subjects include employees, contractors, customers, administrators, virtual machines, containers, serverless functions, devices, and external services. A resource is an object or service to which access may be requested, such as a database, storage bucket, API, encryption key, or management console.

IAM decisions are commonly described through four related functions:

• Identification: stating who or what the subject claims to be.
• Authentication: verifying the claim using evidence such as a password, cryptographic key, possession factor, or biometric characteristic.
• Authorisation: deciding whether the authenticated subject may perform a particular action on a resource.
• Accounting and audit: recording relevant events so that activity can be investigated and controls can be demonstrated.

A useful authorisation model considers the subject, action, resource, context, and decision. For example, an employee may be permitted to read a customer record during working hours from a managed device, but denied export access from an unmanaged device. Authentication alone does not establish authorisation.

Important terminology

Cloud IAM should be treated as a lifecycle rather than a one-time configuration. Identity is created, verified, assigned access, monitored, reviewed, modified, suspended, and eventually deleted. Weakness at any stage can create exposure. For example, accurate authentication cannot compensate for an employee account that remains active after departure.

2. Least Privilege and Separation of Duties

Least privilege means granting only the permissions required for an approved task, for the shortest practical period, to the narrowest appropriate subject. It applies to people, applications, devices, administrators, and automated pipelines.

Least privilege has several dimensions:

• Scope: restrict access to particular resources, projects, accounts, or records.
• Action: distinguish read, create, update, delete, approve, administer, and export operations.
• Time: use temporary or expiring permissions where possible.
• Condition: consider device posture, location, risk, network path, data sensitivity, and business purpose.
• Identity type: prefer individual accountability or a dedicated workload identity over shared accounts.

Least privilege is not equivalent to denying everything. Excessive restriction can encourage workarounds, shared credentials, or unapproved services. A sound design establishes a justified baseline, measures actual use, and removes permissions that are unnecessary while preserving legitimate work.

Separation of duties (SoD) prevents one person from completing a sensitive process alone. For example, one employee may prepare a production change while another approves it. IAM systems can enforce conflicting-role rules, approval workflows, and dual control. SoD is especially important for financial transactions, security-policy changes, encryption-key administration, and deletion of regulated data.

A mature access review asks four questions: Is the identity still valid? Is the business relationship still active? Is each entitlement still needed? Has the access been used in a manner consistent with the approved purpose? Periodic review should be supplemented by event-driven review after role changes, transfers, incidents, or changes in data classification.

3. Authorisation Models

3.1 Role-Based Access Control

Role-based access control (RBAC) assigns permissions to roles and assigns users or workloads to roles. A role might be Cloud Network Operator, Billing Analyst, Application Deployer, or Read-Only Auditor. RBAC simplifies administration because a role can be reviewed and changed centrally.

RBAC works particularly well where responsibilities are stable and organisational duties are clearly defined. It supports role hierarchies, in which a senior role inherits permissions from a less privileged role. However, poorly designed RBAC can produce role explosion, where many combinations of department, project, location, and temporary duty result in a large number of roles. Broad roles can also create privilege accumulation when users retain old roles after moving jobs.

Good RBAC practice includes:

1. Define roles from job responsibilities rather than from existing users.
2. Separate read, change, approval, and administration privileges.
3. Use narrowly scoped resource permissions.
4. Establish role owners and review schedules.
5. Remove unused or duplicate roles.
6. Prohibit direct, unmanaged permissions where practical.

3.2 Attribute-Based Access Control

Attribute-based access control (ABAC) evaluates attributes of the subject, resource, action, and environment. Subject attributes may include department, employment status, clearance, or project membership. Resource attributes may include owner, classification, region, or retention category. Environmental attributes may include time, device compliance, authentication strength, and network risk.

An illustrative policy is: permit a subject to read a record when the subject’s department matches the record’s department, the device is compliant, the record is not restricted to another region, and strong authentication has occurred. This approach can express context-sensitive decisions without creating a separate role for every combination.

ABAC requires reliable, current attributes. If an HR system fails to update a department attribute, a technically correct policy may produce an incorrect decision. Attribute provenance, quality, privacy, and availability therefore become security concerns.

3.3 Policy-Based and Risk-Adaptive Access

Modern cloud services frequently combine RBAC or ABAC with policy conditions. A policy engine evaluates a request against explicit rules, and a risk engine may increase requirements when signals indicate unusual behaviour. For example, a normal low-risk read may be allowed, while a large export requires step-up authentication, manager approval, or a secure workstation.

Risk-adaptive access should not become an opaque substitute for governance. Organisations should document decision factors, establish fail-safe behaviour, monitor false positives, and provide a recovery path for legitimate users. High-impact denials should be reviewable and explainable.

3.4 Deny Precedence and Policy Analysis

Cloud policy systems often combine identity policies, resource policies, organisation-level controls, network restrictions, and service-specific rules. The precise evaluation logic differs by platform, but an explicit deny commonly overrides an allow. Architects must therefore test effective permissions rather than assuming that a single policy describes the final result.

Policy analysis should include unused permissions, privilege escalation paths, wildcard actions, cross-account trust, public exposure, and changes that would allow an administrator to bypass logging or approval. Policy-as-code and automated testing can identify dangerous changes before deployment.

4. Federation, SSO and Authentication Assurance

Federation

Federation allows one identity provider (IdP) to authenticate a subject for a relying party or service provider. The cloud service trusts assertions or tokens issued by the IdP rather than maintaining an independent password database for every user. Common technologies include SAML, OpenID Connect, and OAuth 2.0. Their purposes differ: SAML is widely used for browser-based enterprise SSO; OpenID Connect provides an identity layer over OAuth 2.0; OAuth 2.0 primarily defines delegated authorisation for clients accessing resources.

Federation reduces password duplication and centralises lifecycle controls. It also creates dependency on the IdP, federation metadata, signing keys, network connectivity, clock accuracy, and correct claims mapping. Trust relationships must be limited to approved services, and token audiences, issuers, expiry, nonce or state protections, and signing-key rotation must be validated.

Single Sign-On

SSO enables a user to authenticate once to an identity provider and access multiple approved applications without repeated logins. Its benefits include improved usability, centralised MFA, faster deprovisioning, and better audit consistency. SSO is not itself a security guarantee. A compromised IdP account can provide access to many services, and poorly configured applications may accept excessive claims or fail to enforce session controls.

A robust SSO design includes short-lived tokens, secure redirect handling, strong session termination, application-specific scopes, conditional access, and an emergency recovery plan. Applications should not receive identity attributes they do not need.

Multi-Factor Authentication and Passwordless Access

MFA combines independent factor categories:

• Knowledge: something the user knows, such as a password.
• Possession: something the user has, such as a hardware security key.
• Inherence: something the user is, such as a biometric characteristic.

Two passwords are not two independent factors. Phishing-resistant methods, including FIDO2/WebAuthn security keys and platform authenticators, provide stronger protection than passwords and many forms of one-time code. SMS may be useful as a constrained recovery mechanism, but it is vulnerable to interception and number-porting attacks and should not be treated as the strongest factor.

MFA policy should be risk-sensitive but not ambiguous. Require strong authentication for administrators, sensitive data, policy changes, and unusual access. Define recovery procedures that do not undermine the original control. Lost devices, inaccessible administrators, and identity-provider outages require tested break-glass arrangements.

5. Privileged Access Management

Privileged identities can alter security controls, access sensitive data, create identities, disable logging, or change infrastructure. Privileged access management (PAM) reduces the probability and impact of misuse through technical and procedural controls.

A PAM architecture commonly includes:

• Separate standard and administrative accounts.
• Just-in-time elevation rather than permanent administrator access.
• Approval and business justification for sensitive actions.
• Time-limited credentials or certificates.
• Session recording and command auditing where lawful and proportionate.
• Secure storage and rotation of privileged secrets.
• Restrictions on administrative access from unmanaged devices.
• Independent monitoring of changes to IAM, logging, and security tools.

Emergency or break-glass accounts are necessary when the normal identity provider is unavailable. They should be few, strongly protected, excluded from routine use, monitored continuously, and tested periodically. Their credentials should be stored under dual control or equivalent safeguards, with post-use investigation and rotation.

PAM must also cover cloud control planes, database administration, CI/CD systems, hypervisors, Kubernetes clusters, and third-party support access. A person who cannot alter a cloud console but can modify an infrastructure pipeline may still possess effective administrative power.

6. Workload Identities and Secrets Management

Workload identities

Applications and automated processes need identities to call APIs, access storage, retrieve configuration, and communicate with other services. Assigning a distinct identity to each meaningful workload enables attribution and precise authorisation. Shared service accounts obscure responsibility and increase blast radius.

Prefer short-lived, automatically issued credentials based on workload attestation, platform identity, or mutual TLS. Examples include cloud-native workload identity mechanisms, service-account tokens, SPIFFE/SPIRE-style identities, and certificates. The exact technology is less important than the properties: unique identity, limited scope, automatic rotation, verifiable provenance, and auditable use.

Workload permissions should reflect the application’s actual functions. A web front end that reads product data should not also have permission to delete backups or administer the database. Separate deployment, runtime, migration, and monitoring identities where their duties differ.

Secrets management

Secrets include passwords, API keys, private keys, signing keys, database connection strings, and tokens. They should not be placed in source code, container images, chat messages, tickets, or unencrypted configuration files. A secrets manager should provide encryption at rest, controlled retrieval, access logging, versioning, rotation, and recovery procedures.

Secret protection is a lifecycle:

1. Generate secrets using an appropriate cryptographic mechanism.
2. Store them in an approved vault or platform service.
3. Grant retrieval access only to the required identity and operation.
4. Deliver secrets at runtime rather than embedding them in artefacts.
5. Rotate them before compromise or expiry.
6. Revoke and replace them after suspected exposure.
7. Scan repositories, images, logs, and pipelines for accidental disclosure.

Secrets management does not eliminate the need for authorisation. A workload that can retrieve a database password may still be too broadly trusted. Where possible, use short-lived tokens, keyless signing, managed identities, and dynamic database credentials.

7. Zero Trust Architecture

Zero Trust is a security approach in which no user, device, workload, network, or application is automatically trusted merely because it is inside a corporate network or has previously authenticated. Access is evaluated continuously and granted according to explicit policy, least privilege, and observable context.

The central principles are:

• Verify explicitly using available identity, device, application, and environmental signals.
• Use least-privilege access and minimise standing permissions.
• Assume breach and design for containment, detection, and rapid recovery.
• Protect resources rather than relying on a trusted network perimeter.
• Segment systems and limit lateral movement.
• Collect telemetry and continuously improve policy decisions.

Zero Trust is not a single product and does not mean repeatedly challenging users without regard to context. It is an architectural and governance model. A practical implementation may include an identity provider, device-management platform, policy engine, secure access proxy, workload identity system, microsegmentation, data-loss controls, endpoint detection, and centralised logging.

Figure: A conceptual Zero Trust access decision flow.

Zero Trust implementation should begin with protect surfaces: critical applications, data stores, administrative interfaces, and high-value APIs. Map communication flows, identify identities, classify data, and define policy outcomes. Then introduce controls incrementally, beginning with visibility and strong authentication before applying restrictive segmentation. A sudden organisation-wide deny policy can disrupt operations and cause unsafe exceptions.

8. Designing an Enterprise IAM Architecture

A defensible architecture usually contains the following layers:

1. Authoritative identity sources: HR, student, customer, supplier, and asset systems.
2. Identity governance: joiner, mover, leaver processes; access requests; approvals; reviews; and segregation-of-duties checks.
3. Identity provider: authentication, federation, SSO, MFA, lifecycle status, and session management.
4. Policy and entitlement layer: roles, attributes, resource policies, conditional access, and temporary elevation.
5. Enforcement points: cloud consoles, APIs, applications, gateways, databases, operating systems, and service meshes.
6. Secrets and key services: protected storage, issuance, rotation, revocation, and cryptographic governance.
7. Monitoring and assurance: audit logs, anomaly detection, access analytics, incident response, and compliance reporting.

The architecture should define trust boundaries and failure behaviour. If the IdP is unavailable, should existing sessions continue for a limited time? Which emergency actions remain possible? If an attribute source is stale, should access be denied, reduced, or routed for review? Such decisions must be explicit.

A practical implementation sequence is:

• Inventory identities, accounts, entitlements, applications, and privileged paths.
• Remove abandoned accounts and shared credentials.
• Establish authoritative joiner–mover–leaver processes.
• Federate major applications and enforce MFA, beginning with privileged access.
• Replace broad roles with scoped roles and conditions.
• Introduce workload identities and secrets management into delivery pipelines.
• Add just-in-time privilege, policy testing, and continuous monitoring.
• Measure outcomes and refine controls through exercises and access reviews.

Useful measures include percentage of applications federated, percentage of privileged accounts protected by phishing-resistant MFA, number of standing administrative entitlements, time to remove leaver access, age of unrotated secrets, percentage of workloads using managed identities, and number of unexplained policy exceptions. Metrics should indicate risk reduction rather than merely count tool deployments.

9. Illustrative Case: Meridian Health Analytics

Background

Meridian Health Analytics is an illustrative cloud-based organisation that processes de-identified and identifiable health information for hospitals. It operates a multi-account cloud environment, a data lake, customer-facing APIs, and a continuous delivery platform. Employees authenticate through a central directory, but several teams also use local cloud accounts and long-lived service keys.

Problem

An engineer who transferred teams retained access to two production databases. A shared deployment account had administrator permissions, and a leaked API key was discovered in a public code repository. The organisation also relied on VPN location as an implicit trust signal. Auditors could not demonstrate timely access reviews or reliable attribution of changes.

Analysis

The principal weaknesses were lifecycle failure, excessive standing privilege, weak workload identity, poor secret hygiene, and perimeter-based assumptions. The problem was not solved merely by changing the leaked key. The organisation needed a coherent identity architecture and evidence that controls operated over time.

Approach and solution

Meridian established its HR system as the authoritative source for workforce status and automated joiner–mover–leaver events. All workforce applications were federated through the enterprise IdP, and phishing-resistant MFA was required for administrators and data-access operations. Local cloud users were removed except for tightly controlled emergency accounts.

The cloud estate was reorganised into separate administrative and workload accounts. Engineers received read access by default and obtained time-limited production privileges through an approval workflow. Deployment permissions were divided between build, release approval, and runtime identities. The shared deployment account was retired.

Workloads received platform-issued identities. Database access was changed from embedded passwords to short-lived credentials retrieved through a secrets manager. Repository and image scanning was enabled, and the exposed key was revoked, replaced, and investigated. Resource policies restricted data access by environment, application identity, classification, and approved region.

A Zero Trust access proxy evaluated user identity, MFA strength, device compliance, requested application, and risk signals. High-volume exports required step-up authentication and approval. Central logging recorded authentication, entitlement changes, privileged sessions, secret retrieval, and data access, with logs protected from alteration by ordinary administrators.

Outcome

Meridian reduced permanent administrator access, improved attribution, and shortened leaver deprovisioning. It could demonstrate access reviews and produce evidence for investigations. The organisation did not eliminate all risk: outages in the identity provider remained a resilience concern, and policy complexity required continuing review.

Learning points

1. IAM risk is systemic; isolated credential rotation is insufficient.
2. Human and workload identities require related but distinct controls.
3. Zero Trust depends on enforcement and telemetry, not slogans.
4. Strong controls must include recovery, availability, and operational usability.
5. Governance evidence is an outcome of well-designed processes, not a substitute for them.

10. Challenges, Ethics and Governance

IAM systems process sensitive personal information, including employment status, device data, location signals, authentication events, and behavioural indicators. Collection must be proportionate, access to identity data must itself be controlled, and retention periods should be justified. Risk scoring can produce discriminatory outcomes if signals are incomplete or correlated with protected characteristics. Organisations should test models, provide review mechanisms, and avoid treating automated risk decisions as unquestionable.

Regulatory obligations vary by jurisdiction and sector, but commonly include access limitation, accountability, auditability, protection of personal data, breach response, and retention controls. Frameworks such as NIST guidance, ISO/IEC 27001 control systems, cloud security alliance practices, and sector-specific requirements can structure governance, but they do not replace legal advice or risk assessment.

Availability is an ethical and operational concern. If MFA recovery is inaccessible, legitimate users may be unable to obtain healthcare, perform safety-critical work, or respond to incidents. Recovery mechanisms must be secure, accessible, tested, and monitored. Accessibility should be considered in authenticator selection so that security does not unfairly exclude users with disabilities or limited connectivity.

Third-party and supply-chain identities deserve equal attention. Suppliers should receive named, time-limited, monitored access through approved federation or access gateways. Contracts should define responsibilities for authentication, incident notification, logging, offboarding, and evidence. Machine identities in software dependencies and CI/CD systems should be inventoried and scoped.

11. Contemporary Developments and Best Practices

Cloud-native platforms increasingly support managed identities, workload federation, short-lived tokens, policy-as-code, confidential computing, and phishing-resistant authentication. Artificial intelligence is also used for anomaly detection and access recommendations. These capabilities can reduce manual effort, but AI-generated recommendations must be validated because unusual activity is not necessarily malicious and historical permissions may encode past mistakes. Human accountability remains necessary for high-impact access decisions.

Recommended practices include:

• Make identity the primary control plane, not network location.
• Use phishing-resistant MFA for privileged and sensitive access.
• Prefer federation and central lifecycle management to isolated accounts.
• Use RBAC for stable duties and ABAC or conditions for context-sensitive decisions.
• Eliminate standing privilege where feasible through just-in-time access.
• Give every workload a distinct, short-lived identity.
• Store secrets in managed services and rotate or revoke them automatically.
• Test effective permissions, not only intended policy text.
• Protect audit logs and monitor identity-provider, policy, and key-management changes.
• Design and test break-glass and identity-provider outage procedures.
• Review access after role changes and regularly for high-risk resources.
• Treat exceptions as temporary, owned, justified, and measurable.

Chapter Summary

Cloud IAM is the control system through which human and machine identities access cloud resources. Effective architecture separates identification, authentication, authorisation, and audit; applies least privilege and separation of duties; and manages access throughout the identity lifecycle. RBAC provides manageable role structures for stable responsibilities, while ABAC and policy conditions support context-sensitive decisions. Federation and SSO centralise authentication and lifecycle management, and MFA—especially phishing-resistant authentication—reduces account-compromise risk.

Privileged access management limits administrative exposure through separate accounts, just-in-time elevation, approval, monitoring, and carefully governed emergency access. Workload identities and secrets management prevent applications from depending on shared accounts and long-lived credentials. Zero Trust builds on these controls by continuously evaluating requests, protecting resources rather than trusting networks, limiting lateral movement, and assuming that compromise is possible.

A professional IAM programme is technical and organisational. It requires authoritative identity data, policy governance, secure enforcement points, telemetry, privacy safeguards, resilience planning, and measurable continuous improvement. The strongest design is one that reduces unnecessary access while remaining usable, explainable, auditable, and recoverable.

Key Terms

Identity: A distinct subject that can be authenticated and authorised.

Authentication: Verification of an identity claim.

Authorisation: A decision about whether an identity may perform an action.

Least privilege: Granting only the minimum necessary access for the required time.

RBAC: Access control based on assignment of permissions to roles.

ABAC: Access control based on subject, resource, action, and environmental attributes.

Federation: Trust that allows one identity system to authenticate users for another service.

SSO: Single sign-on that enables access to multiple services through a central authentication event.

MFA: Authentication using two or more independent factor categories.

Phishing-resistant authentication: Authentication designed to resist credential replay and deceptive login sites.

Privileged access management: Controls that govern powerful administrative identities and sessions.

Workload identity: An identity assigned to software, services, or automated processes.

Secrets management: Secure generation, storage, delivery, rotation, and revocation of sensitive credentials.

Zero Trust: A security model that verifies explicitly, applies least privilege, and assumes breach.

Break-glass account: A tightly controlled emergency identity used when normal access mechanisms fail.

Separation of duties: Dividing sensitive responsibilities among multiple people or identities.

Policy engine: A component that evaluates access requests against rules and context.

Entitlement: A specific access right granted to a subject.

Just-in-time access: Temporary privilege granted only when an approved task requires it.

Identity lifecycle: The creation, maintenance, review, suspension, and deletion of an identity and its access.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorisation.
2. State three dimensions of least privilege.
3. What is the main difference between RBAC and ABAC?
4. Why are shared workload accounts undesirable?
5. Identify two principles of Zero Trust.

Long Answer Questions

1. Explain how federation and SSO can improve both security and usability, and discuss their principal dependencies and failure modes.
2. Describe a complete PAM design for a cloud engineering team, including ordinary administration, just-in-time elevation, monitoring, and emergency access.
3. Compare RBAC, ABAC, and risk-adaptive policy approaches. Recommend where each should be used in a large enterprise.
4. Explain how workload identities and secrets management should be integrated into a CI/CD pipeline.
5. Design an IAM governance process covering joiners, movers, leavers, access reviews, exceptions, and audit evidence.

Analytical / Application Questions

1. An organisation has central SSO but 40% of its cloud workloads use long-lived API keys. Analyse the risks and propose a phased remediation plan.
2. A data analyst can access records from a compliant device but attempts a large export from an unfamiliar country. Design a Zero Trust decision process, including signals, policy outcomes, logging, and review.
3. A cloud outage prevents normal federation, while a critical security incident requires administrative action. Evaluate how break-glass access should be designed, tested, monitored, and governed.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorisation?

A. Authentication grants permissions, while authorisation verifies identity.

B. Authentication verifies an identity claim, while authorisation determines permitted actions.

C. Authentication records events, while authorisation encrypts data.

D. Authentication applies only to workloads, while authorisation applies only to people.

Correct Answer: B. Authentication verifies an identity claim, while authorisation determines permitted actions.

Question 2

Which control most directly supports least privilege for a temporary production task?

A. A permanent global administrator role

B. A shared team password

C. Just-in-time, time-limited elevation with approval

D. A VPN connection without identity checks

Correct Answer: C. Just-in-time, time-limited elevation with approval

Question 3

What is a principal advantage of ABAC over a simple RBAC design?

A. It eliminates the need for authentication.

B. It can evaluate contextual attributes such as device status and data classification.

C. It requires every user to have administrator access.

D. It prevents all policy complexity.

Correct Answer: B. It can evaluate contextual attributes such as device status and data classification.

Question 4

Which authentication method is generally designed to provide strong phishing resistance?

A. A password reused across services

B. An SMS code as the sole factor

C. A FIDO2/WebAuthn security key

D. A security question based on public information

Correct Answer: C. A FIDO2/WebAuthn security key

Question 5

What is the primary purpose of federation?

A. To allow one identity provider to authenticate users for a trusted service.

B. To replace all authorisation policies with network addresses.

C. To store application secrets in source code.

D. To make every cloud account independent of organisational identity.

Correct Answer: A. To allow one identity provider to authenticate users for a trusted service.

Question 6

Which practice is most appropriate for a cloud workload?

A. Use one administrator account for every service.

B. Embed a permanent database password in the container image.

C. Assign a distinct identity and use short-lived credentials where possible.

D. Disable logging to improve performance.

Correct Answer: C. Assign a distinct identity and use short-lived credentials where possible.

Question 7

Which statement best represents Zero Trust?

A. Internal network traffic is trusted after a user connects to the VPN.

B. Every request is evaluated using relevant identity, context, and policy signals.

C. All access is permanently denied regardless of business need.

D. Only physical data-centre access requires verification.

Correct Answer: B. Every request is evaluated using relevant identity, context, and policy signals.

Question 8

Why are break-glass accounts needed?

A. They provide routine administrator access to all employees.

B. They allow controlled emergency access when normal identity mechanisms are unavailable.

C. They eliminate the need for MFA.

D. They bypass all monitoring requirements.

Correct Answer: B. They allow controlled emergency access when normal identity mechanisms are unavailable.

Question 9

Which action best reduces the risk of secrets being exposed through software repositories?

A. Store secrets in comments instead of code.

B. Use a managed secrets vault with scanning, rotation, and restricted runtime retrieval.

C. Rename the secret variable without revoking it.

D. Give every developer read access to all production secrets.

Correct Answer: B. Use a managed secrets vault with scanning, rotation, and restricted runtime retrieval.

Question 10

What is the main purpose of separation of duties?

A. To ensure one person can complete every sensitive process alone.

B. To prevent a sensitive process from being controlled by a single individual or identity.

C. To remove the need for access reviews.

D. To make all users members of the same role.

Correct Answer: B. To prevent a sensitive process from being controlled by a single individual or identity.