yoklainterview sim

DevOps / Cloud Security Iam Secrets Interview Questions

75 verified DevOps / Cloud Security Iam Secrets interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Security Iam SecretsDifficulty 1
What does the principle of least privilege mean in access control?
  • aEvery identity should be granted admin access by default and restricted only after an incident occurs.
  • bEvery identity should share a single common set of credentials to simplify management.
  • cEvery identity should be granted only the permissions required to perform its task, and nothing more.
  • dEvery identity should have permissions reviewed once and never changed afterward.
Explanation:Least privilege means granting only the access needed for a task, minimizing blast radius if credentials are compromised. Granting broad access by default and only restricting after an incident is the opposite approach and leaves a large attack surface most of the time. Shared credentials remove accountability and auditability. Permissions naturally need periodic review as roles change, not a one-time setup.
Security Iam SecretsDifficulty 1
What is the key difference between authentication and authorization?
  • aAuthentication verifies who an identity is; authorization determines what that identity is allowed to do.
  • bAuthentication determines what an identity is allowed to do; authorization verifies who that identity actually is.
  • cAuthentication and authorization both verify identity, just at different times in a session.
  • dAuthorization only applies to human users, while authentication applies to both humans and services.
Explanation:Authentication answers 'who are you' (identity verification), while authorization answers 'what can you do' (permission checks) — distinct steps, not two names for the same check. Authorization is not limited to human users; service accounts and machine identities are authorized too.
Security Iam SecretsDifficulty 1
Why should credentials like database passwords or API keys not be hardcoded directly into application source code?
  • aVersion control systems automatically scan every commit and instantly encrypt any string that resembles a credential before it is stored.
  • bSource code lives in version control and is shared with the team, so a hardcoded credential is exposed to anyone with repo access, even after removal.
  • cIt only matters for public repositories — private repositories are inherently safe places to hardcode any kind of credential, regardless of who has access.
  • dIt's fine as long as the credential is a "read-only" key, since a leaked read-only key can only be used to view data and can never cause any real damage.
Explanation:Credentials in source code end up wherever the code goes: version control history, forks, backups, CI logs — removing a later commit doesn't erase it from earlier history. Version control does not automatically encrypt secret-looking strings, private repos are not inherently safe (compromised laptops, ex-employees, misconfigured access), and a 'read-only' key can still expose sensitive data, which is itself damaging.
Security Iam SecretsDifficulty 1
What does multi-factor authentication (MFA) add to a login process compared to a password alone?
  • aA stricter minimum-length requirement, since MFA mainly forces users to choose passwords containing more characters than before.
  • bA backup password stored separately, which can be used to log in whenever the primary password has been forgotten.
  • cAn automatic password rotation that is triggered every single time the user successfully logs into their account.
  • dA second, independent proof of identity, such as a one-time code from a device, so a leaked password alone isn't enough.
Explanation:MFA requires a second, independent factor in addition to the password, so a leaked password alone isn't sufficient to authenticate. It has nothing to do with password length, backup passwords, or automatic rotation on each login.
Security Iam SecretsDifficulty 1
What does 'encryption in transit' (e.g., TLS) protect against?
  • aSomeone reading files directly from the server's disk after they have gained direct access to its underlying filesystem.
  • bSomeone intercepting network traffic between a client and a server and reading it as it travels across the network.
  • cSomeone repeatedly guessing a user's password by attempting many logins in a row until one succeeds.
  • dSomeone modifying the application's deployed source code well after it has already gone live in production.
Explanation:TLS protects data while it moves across the network from interception/eavesdropping. Protecting data on disk is the job of encryption at rest, a different control. Brute-force password guessing and source code integrity are unrelated concerns handled by other controls (rate limiting, code signing/access control).
Security Iam SecretsDifficulty 1
What does 'encryption at rest' mean for data stored in a database or object storage?
  • aThe data is stored on disk in encrypted form, so raw access to the storage alone doesn't expose readable data.
  • bThe data is only encrypted while it is actively being transferred between two separate services over a network.
  • cThe data is compressed to save disk space, which is what the term 'at rest' actually refers to here.
  • dThe data is automatically deleted after a fixed retention period has passed, in order to reduce exposure.
Explanation:Encryption at rest protects stored data so that raw access to disks/storage doesn't expose readable data without the decryption key. It's unrelated to network transfer (that's in-transit encryption), compression, or data retention policies.

Test yourself against the 3375-question DevOps / Cloud bank.

Start interview