Cloud Security Engineer interview questions

SAML exchanges XML assertions and is common for enterprise browser SSO, while OpenID Connect adds identity to OAuth 2.0 with JSON-based tokens and modern application flows.

• SAML service providers trust assertions issued by an identity provider after browser-based authentication.
• OIDC clients validate ID tokens and use authorization flows suited to web, mobile, CLI, and workload federation.
• Both require strict issuer, audience, signature, lifetime, and claim validation rather than trust based only on a successful redirect.

IAM Identity Center centralizes workforce access to AWS accounts and applications through federated identities and temporary role sessions.

• Permission sets define reusable access that is provisioned as roles in selected accounts.
• Group-based assignments connect identity-provider lifecycle to account permissions without separate IAM users.
• Centralization improves review and revocation, but permission sets, assignments, session duration, and break-glass access still need governance.

SCIM automates provisioning, updates, and deprovisioning of users and groups from an identity source into a connected service.

• Joiner, mover, and leaver changes can propagate without manually maintaining cloud identities.
• Stable identifiers and group mappings must be designed carefully to avoid duplicate users or unintended access.
• Deprovisioning tests and monitoring matter because a failed synchronization can leave stale privileges active.

Claims should map authenticated groups and attributes to narrowly defined roles through explicit, stable rules.

• Issuer, audience, group, and assurance claims should come from a trusted identity-provider namespace.
• Broad pattern matching on mutable attributes can grant unexpected roles.
• The mapping needs a default-deny path, change review, and tests for both intended and forbidden role assignments.

An SCP defines the maximum available permissions for member accounts but grants no permissions by itself.

• Effective access still requires an allow from the relevant identity or resource policy.
• An explicit SCP deny blocks matching actions even when an administrator policy allows them.
• SCPs affect principals in member accounts according to AWS Organizations rules, while the management account is outside their restriction scope.

Deny-list SCPs preserve service flexibility by blocking selected high-risk actions, while allow-list SCPs provide tighter control by permitting only approved services and actions.

• A deny list is easier to adopt but can miss new services or risky actions that were not anticipated.
• An allow list reduces that gap but creates more operational friction and maintenance during service adoption.
• Both strategies need staged rollout, exception ownership, and testing against automation and break-glass paths.

A permission boundary limits the maximum identity-policy permissions available to a user or role created by a delegated administrator.

• The boundary does not grant access, so the identity still needs an applicable allow policy.
• Delegated teams can create roles within the boundary without gaining actions outside the approved ceiling.
• Boundary governance must prevent creators from removing the boundary or passing an unbounded role to a service.

Effective permissions are limited by every applicable guardrail and require an allow in the relevant granting policy without a matching explicit deny.

• Identity policies grant candidate permissions to the principal.
• SCPs, permission boundaries, and session policies each reduce the maximum usable set in their scope.
• Resource policies and special service rules can also participate, so troubleshooting requires evaluating the full request context rather than one document.

A secure cross-account role has narrow trust, narrow permissions, short sessions, and traceable assumption by an identified principal.

• The trust policy should name the approved account, role, organization, or federated claims instead of using a broad principal.
• Permission policies should restrict actions and resources to the integration's purpose.
• CloudTrail, source identity, session tags, and MFA or external-ID conditions improve attribution and control where applicable.

An external ID lets a customer require a third-party deputy to present a customer-specific value when assuming a role.

• The third party generates or assigns a value that distinguishes one customer's role from another customer's request.
• The trust policy checks that value in the sts:ExternalId condition.
• It is not a password and does not replace a specific trusted principal, least privilege, or monitoring.

ABAC uses principal, resource, request, and environment attributes to express reusable access rules instead of enumerating every resource.

• Matching project or environment tags can let one policy serve many teams and newly created resources.
• Tag creation and mutation become security-sensitive operations that need validation and ownership.
• ABAC works best with a controlled taxonomy, default deny, and restrictions preventing principals from assigning privilege-bearing tags to themselves.

Session tags carry attributes into temporary role sessions for authorization and audit, while source identity preserves an originating identity value across supported role assumptions.

• Session tags can drive ABAC conditions such as project or cost-center matching.
• Transitive tags can persist through role chaining when explicitly configured.
• Tag and source-identity claims must be issued from trusted mappings because callers able to choose privileged values could expand access.

A KMS architecture separates key administration, cryptographic use, service integration, and audit into distinct controlled paths.

• Administrators manage lifecycle and policy without automatically receiving decrypt access.
• Workloads call encrypt, decrypt, or data-key operations through authenticated identities.
• CloudTrail records management and cryptographic API activity, while dependent services need explicit key-policy compatibility.

KMS authorization depends on the key policy and may delegate permission management to IAM, so both layers must be evaluated.

• The key policy establishes which principals or account delegation paths the key trusts.
• IAM policies can grant operations only when the key policy enables that authorization path.
• Grants, SCPs, conditions, and explicit denies can further change the effective decision.

Envelope encryption uses KMS to protect small data keys while local symmetric cryptography handles large payloads efficiently.

• A fresh data key can limit cryptographic reuse according to the application's design.
• The encrypted data key is stored with the ciphertext and unwrapped only by authorized callers.
• This pattern reduces KMS request volume, latency, and plaintext-key exposure while retaining centralized key control.

KMS grants are useful for scoped, programmatic delegation of key operations without repeatedly expanding the key policy.

• Integrated AWS services often use grants to authorize a resource or operation lifecycle.
• Grants can constrain operations and encryption context and can be retired independently.
• They still require monitoring because accumulated or stale grants can preserve access that is no longer expected.

Encryption context binds non-secret authenticated metadata to a cryptographic operation and can be required by key-policy conditions.

• The same context must be supplied for decryption of ciphertext created with it.
• Policies can restrict decrypt use to a tenant, resource ARN, or application context.
• Because the context may appear in logs and is not encrypted, it must not contain secrets or sensitive plaintext.

Multi-Region keys support related key material across regions for portable ciphertext and disaster recovery, but they expand the key's administrative and usage surface.

• Replicas have independent policies, aliases, and operational states that require consistent governance.
• They reduce the need to re-encrypt data during regional failover for supported designs.
• Replication should be limited to required regions because every replica creates another place where permissions and monitoring can drift.

CloudHSM is chosen when an organization needs dedicated HSM control, direct cryptographic interfaces, or requirements not met by the managed KMS abstraction.

• The customer manages HSM users, availability, backups, clustering, and much more of the operational lifecycle.
• KMS provides simpler service integration, policy management, scaling, and audit for most cloud encryption needs.
• The choice should follow concrete key-custody, algorithm, compliance, or interoperability requirements because HSM ownership adds substantial complexity.

Imported key material gives the organization control over the original material and its expiration or deletion, while adding lifecycle and availability responsibilities.

• Losing the external material can prevent restoration if imported material expires or is deleted.
• Rotation and backup processes differ from fully KMS-generated material and must be documented.
• Importing material does not bypass KMS key policies, IAM controls, logging, or service compatibility constraints.