Securing Credentials and Data in Cloud practice questions

Rotate the access keys associated with the IAM role immediately.

Why it fails: IAM roles do not use long-term access keys. Instead, they rely on temporary security credentials generated dynamically by the Security Token Service, rendering standard access key rotation ineffective for revoking active role sessions.

Attach an explicit Deny policy with a NotAction condition to the IAM role.

Why it fails: Attaching a policy with a NotAction condition can inadvertently lock out legitimate administrative access and fails to specifically target the issuance time of active temporary security tokens already distributed to the attacker.

Disable the trust relationship policy on the IAM role to stop incoming assume-role requests.

Why it fails: Modifying the trust relationship prevents new assume-role requests from succeeding, but it does not invalidate temporary credentials that have already been successfully generated and issued to the attacker prior to the change.

Delete the IAM role and recreate it immediately with identical permissions under a new Amazon Resource Name.

Why it fails: Deleting and recreating an IAM role causes a race condition and downtime for legitimate services depending on that instance profile. Furthermore, active temporary security credentials derived from the role can sometimes remain valid until their natural expiration timestamp despite the role deletion.

Rotate the associated EC2 instance root volume keys and restart the underlying virtual machine instance.

Why it fails: Rotating root volume keys does not affect IAM role temporary security credentials retrieved via the Instance Metadata Service. Instance metadata credentials are dynamically generated and cached independently of local disk storage encryption keys or root passwords.

Enable multi-factor authentication requirements on the S3 bucket access control lists blocking the role.

Why it fails: Access control lists and bucket policies cannot natively enforce multi-factor authentication on programmatic assumed role sessions unless specifically chained with explicit MFA conditions. Relying solely on bucket-level modifications leaves the compromised credential active for other non-S3 API calls.

Disabling server-side encryption to improve performance overhead.

Why it fails: Disabling server-side encryption leaves data exposed to any actor with storage-level access. Performance impacts from modern cloud encryption are negligible compared to the extreme risk of data leakage. Security best practices mandate encryption at rest for all sensitive data stored in cloud object storage or databases.

Granting S3 bucket write permissions to the 'Everyone' group.

Why it fails: Publicly writable buckets are a catastrophic security vulnerability that allows adversaries to upload malware or exfiltrate data. Access should always follow the principle of least privilege, restricting read and write operations to specific, authenticated identities only. Public access to storage resources is a common configuration error.

Storing all encryption keys in cleartext within the application source code.

Why it fails: Hardcoding encryption keys in source code leads to catastrophic credential exposure, especially if the code is pushed to version control systems like GitHub. Secrets should be stored in managed services like Secrets Manager or Key Management Systems, which provide secure access controls and audit logging for all operations.

The resource ARN is missing the bucket name prefix.

Why it fails: The ARN 'arn:aws:s3:::company-data/*' is syntactically correct for an S3 object resource. It correctly refers to the bucket 'company-data' and all objects contained within it. The issue is not the resource format, but rather the specific actions allowed within the policy statement itself regarding object metadata.

The policy version is outdated and requires an update to 2023.

Why it fails: The '2012-10-17' version is the standard and current version for AWS IAM policies. Changing the date does not grant additional permissions or change the evaluation logic of the policy. The issue is entirely due to the missing permission for the list operation within the policy's action array.

The user must have the 's3:PutObject' permission to list files.

Why it fails: The 's3:PutObject' permission is for uploading files, not for listing them. Requiring write permissions to perform read-only tasks like listing files violates the principle of least privilege. The correct action is 's3:ListBucket', which governs metadata discovery without granting the ability to create, delete, or modify objects.

Delete the user's IAM roles in each cloud account individually.

Why it fails: Managing access by manually deleting roles in every account is inefficient, error-prone, and does not scale. It increases the likelihood of human error or missed accounts. Centralized identity management allows for immediate, organization-wide access revocation, which is essential for timely incident response and maintaining strict lifecycle control over user accounts.

Change the password of the user's local cloud account.

Why it fails: In an SSO-enabled environment, local cloud accounts should not exist or be used. Changing a password for a local account does not affect the federated sessions derived from the IdP. This approach provides a false sense of security while leaving the SSO-based access vector entirely open and fully functional.

Wait for the user's temporary security tokens to expire naturally.

Why it fails: Waiting for tokens to expire is insufficient as it leaves a window of risk where the terminated employee could potentially still perform actions. Immediate account deactivation is a standard security requirement for offboarding. Relying on expiration times is not a robust control for preventing unauthorized access by malicious insiders.

Store API keys in an environment variable on the server.

Why it fails: Environment variables can be leaked through process inspection, log files, or insecure application debug interfaces. They are not as secure as dedicated secret management services that provide encryption at rest and auditing. Using secret management services is the industry standard for protecting sensitive credentials from unauthorized exposure.

Grant the API key broad access to all cloud resources.

Why it fails: Granting broad access violates the principle of least privilege. If a key with excessive permissions is compromised, the attacker gains full control over the environment. Keys should always be restricted to only the specific resources and actions required for the third-party service to function as intended.

The user can still list buckets but not read objects.

Why it fails: The policy uses 's3:*', which includes 's3:ListBucket'. Because it is an explicit 'Deny', no S3 actions are permitted. The user is effectively blocked from all S3 interaction, including listing, reading, and writing, until they authenticate with MFA. Partial access is not possible under this strict policy enforcement.

The user is allowed all S3 actions by default.

Why it fails: AWS follows a 'Deny-by-default' logic, but this policy explicitly creates a 'Deny' condition. It is not possible to be allowed all actions when an explicit deny is present in the policy evaluation. The user will be blocked until the MFA requirement is satisfied, confirming the policy's intended restrictive nature.

The user is prompted to provide an MFA code on every request.

Why it fails: This policy does not prompt for MFA; it simply denies access if MFA is missing. The user must have already authenticated with MFA to pass the condition. If they haven't, they are simply rejected. The policy is an authorization gate, not an interactive authentication prompt for the user interface.

Storing the database password in an encrypted configuration file.

Why it fails: Encrypted configuration files still require the decryption key to be available on the instance. If the instance is compromised, the key and the configuration file are both accessible. IAM-based authentication is superior because it uses temporary, dynamic tokens that eliminate the need for persistent secrets on the server entirely.

Hardcoding the database credentials in the application code.

Why it fails: Hardcoding credentials is a major security flaw. It exposes the password to anyone with access to the source code, version control, or compiled binaries. It is extremely difficult to rotate credentials without redeploying the application, and it creates a permanent risk if the code is accidentally shared or leaked.

Using an environment variable to store the database password.

Why it fails: Environment variables are often exposed in logs, process lists, or debugging tools, making them an insecure way to store sensitive secrets. They provide no rotation capabilities and are not an appropriate substitute for secure, identity-based authentication mechanisms like IAM roles or dedicated secret management services that provide robust encryption.

Terminate the compromised EC2 instance immediately to stop all active network connections and API requests.

Why it fails: Terminating the instance abruptly destroys volatile memory forensics, process lists, and local log artifacts that incident handlers require to reconstruct the full scope of the server-side request forgery compromise and follow-on attacker activity.

Delete the underlying IAM role entirely from the AWS Identity and Access Management console.

Why it fails: Deleting the IAM role entirely is often prohibited if associated policies are still referenced, and it causes widespread operational outages for any other legitimate services or applications sharing that specific role configuration.

Modify the instance security group to block outbound traffic on port 80 and 443 to the metadata service IP address 169.254.169.254.

Why it fails: Blocking outbound traffic to the metadata IP prevents future token theft via SSRF, but it does nothing to invalidate the temporary security credentials that the attacker has already exfiltrated and stored externally.

The policy explicitly denies access to administrative actions, preventing incident handlers from troubleshooting the compromised resource during an active forensic investigation.

Why it fails: The policy does not contain an explicit deny statement. It utilizes an allow effect for specific S3 data plane actions, meaning it grants access rather than blocking administrative troubleshooting efforts required by responders.

The JSON syntax contains structural errors that will cause the AWS Identity and Access Management parser to reject the policy entirely.

Why it fails: The JSON syntax is completely valid according to AWS IAM policy grammar standards. The brackets, braces, keys, and array structures conform to expected formatting rules and would successfully apply to an IAM identity.

The policy enables cross-account assumption vulnerabilities by omitting the Principal element within the main statement block.

Why it fails: IAM identity-based policies do not require a Principal element because the principal is implicitly defined by the user, group, or role to which the policy is directly attached in the AWS environment.

Delete the exposed access key immediately from the IAM user profile to terminate all processing.

Why it fails: Deleting the access key stops new calls from being signed, but any active temporary security token sessions already generated prior to the deletion will continue to function until their natural expiration time. This leaves a critical window open for continued unauthorized data access.

Rotate the access key by generating a new secondary key pair in the IAM console.

Why it fails: Rotating a key simply creates an additional active key alongside the compromised one, effectively doubling the attack surface rather than mitigating the active breach. The compromised key remains completely valid and fully operational until it is explicitly deactivated or deleted.

Enable multi-factor authentication enforcement on the compromised IAM user account.

Why it fails: Enforcing MFA has no impact on programmatic access keys because API requests authenticate using cryptographic signatures rather than interactive multi-factor authentication challenges. The exposed secret key will continue to grant full programmatic access regardless of the MFA requirement.

Attach an explicit deny policy to the IAM role for the S3 actions.

Why it fails: While an explicit deny would block future API calls, it does not immediately invalidate temporary credentials already issued to the instance. The attacker could continue using the existing session until it expires. Additionally, modifying the role's policies may alert the attacker and does not address the root cause of the SSRF vulnerability or preserve the session state for forensics.

Delete the S3 bucket policy that grants access to the role.

Why it fails: Deleting the bucket policy may not revoke access if the role's identity-based policy already grants permissions, and it removes a valuable forensic artifact. The attacker could still use the stolen credentials to access the bucket if the IAM policy allows it. This action does not directly invalidate the compromised session and can complicate later analysis of the original access controls.

Revoke the role's temporary credentials by adding the role to the AWSRevokeOlderSessions inline policy.

Why it fails: The AWSRevokeOlderSessions policy is used to revoke all sessions that started before a specified time, but it requires careful configuration and does not immediately terminate active sessions. It is a valid approach for revoking long-lived sessions, but in an active exfiltration scenario, a more direct and immediate action is needed to stop the data loss without waiting for policy evaluation.

Service control policies (SCPs) attached to the production account

Why it fails: SCPs restrict the maximum permissions for principals within an account but do not control which external principals can assume a role. They apply to IAM users and roles in the account where they are attached, not to the trust policy of a role. While SCPs could deny the sts:AssumeRole action for principals in the development account, they are not the primary mechanism for controlling cross-account role assumption.

IAM permissions boundaries on the development account IAM user

Why it fails: Permissions boundaries limit the maximum permissions that an IAM user or role can have, but they do not affect the trust policy of a role in another account. They would not prevent the user from assuming a role if the role's trust policy allows it. The boundary is applied to the user's identity, not to the target role's access control, so it would not restrict cross-account assumption in this scenario.

AWS Config rules that monitor IAM policy changes in the production account

Why it fails: AWS Config rules evaluate resource configurations and can alert on changes, but they do not enforce access control. They would detect that the trust policy is overly permissive after the fact, but they would not prevent the cross-account assumption. Config is a detective control, not a preventive one, so it would not stop the privilege escalation from occurring.

Enable AWS CloudTrail to log all API activity and monitor for suspicious behavior.

Why it fails: CloudTrail is a detective control that logs API activity, which is useful for incident response and auditing, but it does not prevent the exposure or misuse of long-term access keys. It can help detect unauthorized use after the fact, but it does not eliminate the risk of stolen keys being used. The goal is to prevent the incident, not just detect it, so this is not the most effective control.

Enforce multi-factor authentication (MFA) for all IAM users.

Why it fails: While MFA adds a layer of protection, it does not prevent the initial exposure of long-term access keys. An attacker who obtains the keys can still use them if MFA is not required for programmatic access. MFA is typically enforced for console access, but API calls using access keys bypass MFA unless specifically configured with conditions. Thus, it does not address the root cause of embedded credentials.

Use AWS Secrets Manager to store and automatically rotate database credentials.

Why it fails: AWS Secrets Manager is designed for managing and rotating secrets such as database credentials, not for IAM user access keys. While it can store other secrets, it does not automatically rotate IAM user access keys. The scenario involves IAM access keys, so this control is not directly applicable. It is a good practice for database credentials but not for the specific issue of hardcoded IAM keys.

Disable the S3 bucket's public access block to allow faster investigation

Why it fails: Disabling the S3 bucket's public access block would increase exposure and is counterproductive to containment. It does not revoke the compromised credentials and could allow further unauthorized access if the bucket becomes public. The public access block should remain enabled to prevent accidental exposure while the incident is being investigated.

Delete the Lambda function to prevent further invocations

Why it fails: Deleting the Lambda function is a drastic action that destroys forensic evidence and may disrupt legitimate operations. It also does not immediately invalidate the credentials if they have already been exfiltrated; the attacker could still use them until they expire. Containment should focus on revoking access, not destroying the resource, which could hinder the investigation and recovery.

Rotate the AWS access keys of the IAM user associated with the Lambda function

Why it fails: Lambda execution roles use temporary credentials, not long-term access keys. There are no access keys to rotate. Rotating keys would be ineffective and would not address the compromised temporary credentials. The correct action is to revoke the role's permissions or wait for the temporary credentials to expire, while monitoring for misuse.

Revoke all active refresh tokens for the service principal.

Why it fails: Revoking refresh tokens is relevant for user accounts, but service principals use client secrets or certificates for authentication, not refresh tokens. The attacker likely used the client secret directly. Revoking refresh tokens would not invalidate the compromised secret. The correct containment is to rotate the secret or certificate. This option is a distractor because it confuses user authentication flows with service principal authentication.

Delete the service principal from Microsoft Entra ID.

Why it fails: Deleting the service principal would immediately revoke all access and prevent further use, but it could disrupt legitimate applications that rely on it. While it is a drastic containment step, it may not be appropriate if the service principal is still needed. Rotating the secret and removing the role assignment are more surgical and allow the service to continue with reduced risk. Deletion is often a last resort and may cause outages.

Enable Microsoft Entra ID Protection for all users.

Why it fails: Microsoft Entra ID Protection is a monitoring and risk detection service for user identities, not for service principals. It can help detect compromised user accounts but does not directly contain a compromised service principal. Enabling it is a good long-term security measure, but it does not address the immediate incident. It is not a containment action for the specific scenario.

Use a Cloud Storage bucket lock to prevent changes to encryption settings.

Why it fails: Bucket lock is a feature that prevents the deletion or modification of objects for a specified retention period, but it does not enforce encryption settings. It is used for data retention and compliance with regulations like SEC Rule 17a-4(f). It does not ensure that CMEK is used. This option is a distractor because it confuses data retention with encryption enforcement.

Set a default CMEK key on the project using the gcloud command.

Why it fails: There is no project-level default CMEK setting in GCP. CMEK must be specified at the bucket level or via organization policy. While you can set a default KMS key for a bucket, it is not a project-wide setting. This option is incorrect because it misrepresents GCP's capabilities. The engineer must use an organization policy to enforce CMEK across all buckets.

Enable default encryption with Google-managed keys and rotate them regularly.

Why it fails: Google-managed keys are the default encryption for Cloud Storage, but they do not meet the requirement for customer-managed keys. The compliance requirement explicitly states CMEK, which gives the customer control over key management. Google-managed keys are managed by Google and do not provide the same level of control or auditability. This option fails to meet the compliance requirement.

Generate unique access keys for every developer stored in an encrypted S3 bucket.

Why it fails: Storing static access keys in S3, even when encrypted, creates a centralized point of failure. If an attacker gains permissions to decrypt the bucket or access the keys, the impact is significant. Static keys do not expire, making them a persistent target for adversaries seeking long-term persistence.

Rotate IAM user access keys every 90 days via an automated script.

Why it fails: Periodic rotation is a compensating control but does not address the fundamental flaw of long-term credentials. If a key is exfiltrated, rotation only limits the duration of the compromise. Roles with temporary credentials provide a much stronger security architecture by eliminating static secrets entirely from the ecosystem.

Use an IAM group policy to enforce Multi-Factor Authentication on all API requests.

Why it fails: Enforcing MFA on API calls is technically challenging and often requires complex workflows for automated systems. While MFA protects the console, it is not a direct substitute for using temporary credentials through IAM roles for programmatic access. It does not address the risk of compromised long-term access keys.

Setting a complex root password for the database.

Why it fails: A complex password does not prevent unauthorized network access. If the database is accessible from the internet, an attacker could potentially brute force the password or exploit vulnerabilities in the database service itself. Network-level controls are necessary to prevent the exposure from being reachable in the first place.

Enabling database logging for every query.

Why it fails: Logging is an excellent detective control for forensic analysis but does not prevent unauthorized access. An attacker could potentially delete logs or exfiltrate data before an incident response team detects the breach. Prevention, such as network isolation, must take precedence over detective measures in a hardened cloud architecture.

Using a public IP address for faster data synchronization.

Why it fails: Using a public IP address exposes the database to the internet, creating a massive security risk. Even if synchronization is faster, the potential for unauthorized access far outweighs the benefit. Secure alternatives like VPC peering or private links provide high-performance connectivity without exposing the database to public network traffic.

A user is assigned two different roles with conflicting permissions.

Why it fails: Conflicting permissions result in access denied errors or unexpected behavior, but this is a standard policy evaluation issue. The Confused Deputy problem specifically involves a third-party entity exploiting a service's higher authority to manipulate resources, rather than a simple misconfiguration of a single user's assigned set of policies.

Two cloud administrators inadvertently delete each other's work.

Why it fails: This is a conflict of operations or a lack of administrative coordination, not a security vulnerability involving the abuse of service privileges. The Confused Deputy problem is fundamentally about authorization logic bypasses, whereas administrative error is a process or management failure that does not involve privilege escalation through services.

A service fails to refresh its temporary tokens, causing a lockout.

Why it fails: This describes a service availability issue or a misconfigured token renewal process. It does not relate to privilege escalation or the manipulation of a privileged service to act improperly. The Confused Deputy problem is specifically about security and authorization abuse rather than system performance or operational uptime.