Cloud Security Engineer interview questions

The shared responsibility model divides security duties between the cloud provider and the customer.

• The provider protects the physical facilities, hardware, and foundational managed infrastructure.
• The customer protects identities, data, workload configuration, and access according to the services used.
• The exact boundary changes by service model, so moving to cloud does not transfer all security responsibility to the provider.

The provider manages more of the technology stack as services move from IaaS to PaaS to SaaS, while the customer always retains responsibilities such as identity and data governance.

• In IaaS, the customer commonly secures the guest operating system, applications, and network configuration.
• In PaaS, the provider manages more runtime and operating-system layers, but the customer still secures code, data, and service settings.
• In SaaS, the customer mainly controls users, permissions, data handling, tenant configuration, and connected devices.

Authentication proves an identity, while authorization decides which actions that identity may perform on which resources.

• Passwords, MFA, certificates, and federated sign-in are authentication mechanisms.
• IAM policies, roles, and resource policies express authorization decisions.
• A valid login does not grant broad access unless the authorization configuration allows it.

An IAM user represents a long-lived identity, while a role is assumed to obtain temporary permissions for a session.

• Roles are preferred for workloads and cross-account access because they avoid embedded long-lived access keys.
• A role has a trust policy defining who may assume it and permission policies defining what it may do.
• Human access is commonly federated through an identity provider into roles rather than managed as separate cloud users.

An IAM policy states whether selected actions are allowed or denied on selected resources under optional conditions.

• Effect expresses Allow or Deny, while Action names API operations.
• Resource limits the objects to which the statement applies.
• Condition can restrict access by context such as source network, resource tags, time, or MFA state.

Least privilege means granting an identity only the actions, resources, and conditions required for its current task.

• Permissions should use specific actions and resource scopes instead of broad wildcards where the service supports them.
• Temporary elevation is safer than permanent administrative access for occasional tasks.
• Access reviews and usage data help remove permissions that are no longer needed.

An explicit deny overrides an allow, while access without an applicable allow is denied by default.

• Multiple identity, resource, organization, boundary, and session policies may participate in one decision.
• A broad allow cannot bypass a matching explicit deny.
• Permission boundaries and organization guardrails limit maximum permissions but do not grant access by themselves.

MFA requires another factor beyond a password and reduces the chance that a stolen password alone compromises an account.

• It is especially important for privileged users, billing owners, and root or break-glass identities.
• Phishing-resistant factors such as hardware security keys provide stronger protection than SMS codes.
• MFA should complement short sessions, conditional access, and least privilege rather than justify excessive permissions.

Temporary credentials expire automatically and can be issued with a narrowly scoped session, reducing the lifetime of stolen access.

• Roles and federation generate temporary credentials without storing a permanent secret in application code.
• Short duration limits persistence after a credential leak.
• Session context and role assumptions also improve auditability compared with shared static keys.

A workload should use a platform-provided service identity or role with temporary credentials instead of a hardcoded user key.

• Virtual machines, containers, and serverless functions can receive credentials from their execution identity.
• The role policy should permit only the APIs and resources the workload needs.
• Metadata and token endpoints must be protected from untrusted code and request-forgery paths.

Identity federation lets an external identity provider authenticate users and exchange that identity for temporary cloud access.

• Standards such as SAML and OpenID Connect carry identity information and claims.
• Centralized federation supports one workforce lifecycle, MFA policy, and account disablement process.
• Cloud roles map groups or claims to permissions without creating a separate long-lived user in every account.

IAM Access Analyzer helps identify resources shared with external principals and can analyze permissions for broader-than-intended access.

• It evaluates supported resource policies and trust relationships for access outside a defined zone of trust.
• Findings still require review because some cross-account or public access may be intentional.
• Policy validation and access activity can also support writing narrower permissions.

Encryption at rest protects stored data, while encryption in transit protects data moving between systems.

• Disk, database, object-storage, and backup encryption are common at-rest controls.
• TLS is the standard control for data moving over a network.
• Both controls are needed because they address different exposure points and neither replaces access control.

TLS encrypts traffic, authenticates the server through certificates, and protects messages from undetected modification in transit.

• Certificate validation confirms that the client reached the intended service identity.
• Modern configurations disable obsolete protocol versions and weak cipher suites.
• TLS protects the connection but does not determine whether the authenticated caller is authorized to access the data.

Envelope encryption encrypts data with a data key and then encrypts that data key with a separate key-encryption key.

• Data keys efficiently encrypt large payloads close to the workload.
• A KMS protects the key-encryption key and controls operations that unwrap data keys.
• The encrypted data key can be stored beside ciphertext without exposing the plaintext key.

A cloud KMS creates and protects cryptographic keys and controls audited cryptographic operations with those keys.

• IAM and key policies determine who may encrypt, decrypt, sign, or administer a key.
• Managed services can integrate with KMS for storage encryption without exposing key material to applications.
• KMS manages cryptographic keys, while passwords and API tokens belong in a secrets-management service.

Provider-managed keys favor simplicity, while customer-managed keys provide more control over policy, lifecycle, audit, and separation.

• Provider-managed keys are created and operated by the cloud service with limited customer configuration.
• Customer-managed keys can support custom permissions, cross-account use, disablement, and rotation settings.
• More control also creates responsibility for key availability, policy correctness, cost, and lifecycle management.

Key rotation limits how much new data is protected by one key version and supports organizational or regulatory cryptoperiod requirements.

• New encryption operations use the current key material after rotation.
• Old key material must remain available while data encrypted with it still needs decryption.
• Rotation does not automatically correct excessive key permissions or replace the need to revoke a compromised key deliberately.

Separating key administration from cryptographic use prevents one identity from both changing key controls and freely decrypting protected data.

• Administrators may manage aliases, rotation, or policy without receiving decrypt permission.
• Workloads may use encrypt or decrypt operations without permission to alter or delete the key.
• This separation supports least privilege, dual control, and clearer audit trails.

Encryption is reversible with the appropriate key, while a cryptographic hash is designed as a one-way digest.

• Encryption protects confidentiality when authorized users need to recover the original data.
• Hashes support integrity checks and password verification when used with an appropriate salted password-hashing function.
• A plain fast hash is not suitable password storage because attackers can test guesses efficiently.