All jobs / Solutions / cloud architect
Identity & Security interview questions
Identity & Security questions a Solutions / cloud architect can be asked, from first job to senior. Open one to see the strongest answer and why it works.
Why do companies insist on single sign-on for every internal tool instead of separate logins?
The strongest answer: One identity per person means one place to enforce MFA and password policy, one switch to revoke access when someone leaves, and an audit trail of who used what
Why it works: Exactly — SSO is an access-control and offboarding tool first; convenience is the side effect.
- One identity, one switch.
- Central MFA and policy.
- Revoke once when someone leaves.
- Audit who used what.
Authentication versus authorisation — and where do OIDC and OAuth fit?
The strongest answer: Authentication proves who you are, authorisation decides what you may do; OIDC handles the first, OAuth issues delegated access for the second — the app still decides its own permissions
Why it works: Exactly. Who you are, what you may do, and the protocols that carry each — with permissions still owned by the application.
- Authentication: who.
- Authorisation: what.
- OIDC for identity, OAuth for delegated access.
- Valid token is not permission.
A developer asks where to put the new payment provider’s API key so the staging service can use it.
Where should database passwords and API keys live, and how do services get them?
The strongest answer: In a secrets manager or vault, injected at runtime by identity; never in the repository, the image or a shared document
Why it works: Exactly. A managed secret store, access by identity, rotation possible. The repo never sees them.
- Secrets manager, not files.
- Inject at runtime by identity.
- Rotation must be possible.
- Encoding is not protection.
The database disks are encrypted at rest. What does that protect against, and what does it not?
The strongest answer: It protects data on lost, stolen or badly decommissioned storage and against raw access to the volumes; it does nothing against anyone with valid database credentials, because the database decrypts transparently
Why it works: Right — at-rest encryption is a storage-layer control; application access is governed by credentials and authorisation.
- Protects the storage, not the app path.
- Lost media, raw volume access.
- Credentials still read plaintext.
- Sensitive fields: encrypt in the app.
A single-page app, a mobile app and a nightly batch job all need to call your API. Which OAuth flows fit?
The strongest answer: Authorisation code with PKCE for the browser and mobile apps, client credentials for the batch job; no long-lived secrets in anything a user can download
Why it works: Exactly. Public clients use code plus PKCE; machines use client credentials; secrets stay server-side.
- Public clients: code + PKCE.
- Machines: client credentials.
- No secrets in downloadable apps.
- Password and implicit are legacy.
How do you design the roles for a product’s permission system so it does not end up as one role per user?
The strongest answer: Derive a small set of roles from real job functions, express permissions as fine-grained actions grouped into roles, handle exceptions with scopes or attributes rather than new roles, and review the roles periodically
Why it works: Exactly — roles model the organisation, permissions model the system, and attributes absorb the exceptions.
- Roles from job functions.
- Fine-grained actions, grouped.
- Exceptions via scopes or attributes.
- Review roles regularly.
How should cloud permissions be granted to a new service?
The strongest answer: A dedicated identity per service with only the actions and resources it needs, granted through reviewed infrastructure code — no shared admin keys
Why it works: Exactly. One identity, minimal scope, reviewed as code.
- One identity per service.
- Only the actions and resources needed.
- Granted as reviewed code.
- No shared admin credentials.
What does zero trust change about how services talk to each other inside the network?
The strongest answer: Being on the network grants nothing: every call authenticates the caller, is authorised for the action, and is encrypted, so a compromised host cannot reach everything else
Why it works: Exactly. Identity per call, authorisation per action, encryption in transit — inside as well as outside.
- Network location grants nothing.
- Authenticate every caller.
- Authorise every action.
- Encrypt inside as well as outside.
Design the key management for a platform that encrypts customer data at rest.
The strongest answer: Envelope encryption with data keys wrapped by keys in a managed KMS, per-tenant keys where isolation demands it, rotation without re-encrypting everything, and access logged and reviewed
Why it works: Exactly. Envelope, KMS-backed, tenant-aware, rotatable, audited.
- Envelope encryption.
- Keys in a managed KMS.
- Per-tenant keys where required.
- Rotation and audit designed in.
How do you run a threat-modelling session on a new design?
The strongest answer: Draw the data flows and trust boundaries, ask what can go wrong at each crossing using a framework, rank by impact and likelihood, and leave with owned mitigations in the backlog
Why it works: Exactly. Flows, boundaries, structured questions, ranked risks, owned actions.
- Data flows and trust boundaries.
- Structured “what can go wrong” per crossing.
- Rank by impact and likelihood.
- Owned mitigations in the backlog.
Enterprise customers ask to sign in with their own identity provider. What do you build?
The strongest answer: Federation per tenant over SAML or OIDC, group-to-role mapping, automated provisioning and deprovisioning, per-tenant enforcement of the customer’s login policy, and your own login kept as a break-glass path
Why it works: Right — enterprise SSO means the customer controls identity and lifecycle while you map it to authorisation.
- Federate; the customer owns identity.
- SAML or OIDC per tenant.
- Map groups to roles.
- Provision and deprovision automatically.
The certificate was issued by hand two years ago by an engineer who has since left.
An internal certificate expired on a Sunday and took down service-to-service traffic. What do you change in the design?
The strongest answer: Treat certificates as an automated lifecycle: an inventory with owners, issuance and renewal by an internal CA or ACME with short lifetimes, expiry monitoring that pages before it hurts, and a tested rotation path
Why it works: Exactly — the fix is automation and visibility, not longer lifetimes.
- Certificates are a lifecycle.
- Inventory with owners.
- Automate issuance and renewal.
- Monitor expiry; test rotation.
Design identity for a company with acquired subsidiaries, contractors and customers all needing access.
The strongest answer: One identity provider as the authority with federation to subsidiary and partner directories, customers in a separate tenant, role and attribute-based access defined centrally, and joiner-mover-leaver flows automated
Why it works: Exactly. One authority, federation for the edges, workforce and customer separated, lifecycle automated.
- One identity authority.
- Federate subsidiaries and partners.
- Separate workforce from customer identity.
- Automate joiner-mover-leaver.