Cloud Application Security practice questions

Use of bearer tokens without additional protection

Why it fails: Bearer tokens are easily reusable.

Short token expiration times

Why it fails: Short expiration reduces but does not prevent reuse during validity.

Audience restriction

Why it fails: Audience restricts which service can accept the token, not binding.

The policy does not enforce server-side encryption

Why it fails: Encryption is not specified in this policy.

The bucket is publicly accessible from any IP

Why it fails: Access is restricted to a specific IP range.

The policy does not require MFA for delete operations

Why it fails: MFA delete is a separate bucket setting, not part of this policy.

Set allowPrivilegeEscalation to true

Why it fails: Setting allowPrivilegeEscalation to true permits a process to gain more privileges than its parent, directly weakening container isolation, so it contradicts the hardening goal. It is tempting because some workloads need setuid binaries or sudo, but the secure setting is false unless a documented exception exists.

Use a more restrictive runAsUser value like 2000

Why it fails: Changing runAsUser to 2000 alters the UID but does not itself restrict capabilities, privilege escalation, or filesystem access, so the pod's excessive permissions remain. It is tempting because non-root UIDs are a hardening step, and it is correct when the exhibit shows the container running as UID 0.

Use a trusted image from a private registry

Why it fails: A trusted private-registry image addresses provenance and supply-chain integrity, but the exhibit's pod already references an image; the missing control concerns runtime privilege context, which registry choice does not alter. It is tempting because image trust is a genuine best practice, and it is correct when the pod pulls from an untrusted public source.

Use the --no-root flag when starting the container.

Why it fails: Docker has no --no-root flag; the command fails rather than dropping privileges. It is tempting because a flag-based fix mirrors real Docker options, but the actual mechanism is the USER instruction in the Dockerfile or --user at runtime, which sets the container's UID.

Set the securityContext.runAsNonRoot parameter in the container manifest.

Why it fails: This is a Kubernetes concept, not Docker.

Use the --cap-drop=ALL option when running the container.

Why it fails: This drops capabilities but does not change the user ID; the container may still run as root.

Manual penetration testing after every code commit.

Why it fails: Penetration testing after every commit cannot scale to continuous integration cadence and detects flaws only after code is written. Manual testing suits periodic release-gate assurance, whereas an SSDLC requires automated static analysis and threat modelling embedded throughout development.

Security awareness training for all developers.

Why it fails: Developer training builds awareness but is not a structural component of the SSDLC; the essential components are defined phases such as requirements, design, implementation, verification and release gates. Training is a supporting control, correctly chosen when the question asks how to sustain secure coding culture across teams.

Continue using cloud-provider-managed keys and implement additional logging to meet audit requirements.

Why it fails: Provider-managed keys leave key custody and rotation with the cloud provider, so the customer-managed key and automatic rotation requirements remain unmet. It is tempting because extra logging does improve auditability, and it would be the correct choice where compliance permits provider-managed keys and only access visibility is lacking.

Use a CMK with manual rotation to have full control over the rotation schedule and avoid any potential downtime.

Why it fails: Manual rotation cannot satisfy the mandated automatic rotation, and it does not remove downtime risk—it merely shifts rotation to an operator-driven event. It is tempting because it appears to give full control over timing, and it would be the correct choice where policy demands scheduled, human-approved rotation rather than automatic.

Implement client-side encryption with a key stored in a secure vault and disable server-side encryption.

Why it fails: Disabling server-side encryption removes the platform's at-rest encryption and its automatic rotation, and a vault-held key is not a CMK integrated with RDS or S3. It is tempting because client-side encryption gives the strongest custody, and it would be the correct choice where the provider offers no CMK support.

The policy restricts read access to a specific role, which is too permissive

Why it fails: Restricting read access to a specific role is appropriate.

The policy does not enable server-side encryption

Why it fails: Server-side encryption is not configured in the policy, but this is not a security issue with the policy itself.

The policy contains a syntax error in the JSON

Why it fails: The JSON is syntactically correct.

Create the CMK, then set IAM permissions and key policies, then enable automatic key rotation, then configure application integration, then monitor usage and audit logs.

Why it fails: This order is incorrect because enabling rotation earlier ensures the key is already rotating before applications start using it; delaying rotation could require manual updates later.

Set IAM permissions and key policies, then create the CMK, then enable automatic key rotation, then configure application integration, then monitor usage and audit logs.

Why it fails: This order is incorrect because permissions cannot be set for a key that does not yet exist; the CMK must be created first before attaching policies.

Create the CMK, then enable automatic key rotation, then configure application integration, then set IAM permissions and key policies, then monitor usage and audit logs.

Why it fails: This order is incorrect because application integration would fail without proper permissions; permissions must be set before applications attempt to use the key.

SaaS: Provider manages only physical security; customer manages all other aspects including applications and data.

Why it fails: Incorrect — SaaS providers manage most of the stack; customers are not responsible for applications or infrastructure.

IaaS: Provider manages operating system, applications, and data; customer manages physical servers.

Why it fails: Incorrect — IaaS providers manage physical hardware, not the OS or applications; that is the customer's responsibility.

ISO 27001: European Union

Why it fails: Incorrect — ISO 27001 is an international standard for information security management, not specific to the EU.

SOC 2: US healthcare

Why it fails: Incorrect — SOC 2 is for service organizations (e.g., data centers) and is not specific to US healthcare.

Store the cloud provider access key and secret key in environment variables in the function

Why it fails: Long-lived static access keys stored in environment variables are broadly scoped, leak through logs and code, and are not rotated automatically; a scoped IAM role or service account assumed by the function is required. It is tempting because it works quickly, but it suits legacy workloads without identity federation.

Use the root user credentials of the cloud account

Why it fails: Root credentials grant unrestricted account-wide access, violating least privilege and exposing the entire cloud account if the function is compromised. It is tempting because root access guarantees the read succeeds without IAM configuration, and it would be the correct choice only for initial account setup tasks that genuinely require root.

Set the bucket policy to allow public read access

Why it fails: Public read access grants the entire internet access to the bucket, violating least privilege; the function should assume a scoped IAM role or service account permitting only reads on that bucket. It is tempting because it is quick and unauthenticated, but it suits deliberately public static content, not private data.

Use a secrets manager to store credentials and retrieve them at runtime

Why it fails: Using a secrets manager to store credentials and retrieve them at runtime introduces long-lived secrets that require management and rotation, which is less secure than using a service-linked role.

Store the database credentials as ciphertext in the function's environment variables

Why it fails: Storing the database credentials as ciphertext in environment variables still relies on long-lived secrets and key management, which is not as secure as using a service-linked role.

Create a service account with access keys and pass them to the function via encrypted environment variables

Why it fails: Creating a service account with access keys and passing them via encrypted environment variables still involves long-lived secrets, which is less secure than a service-linked role.

Implement IPsec tunnels between components

Why it fails: IPsec operates at the network layer and encrypts host-to-host or gateway-to-gateway traffic, requiring key management and endpoint configuration; it does not secure application-layer sessions exposed to arbitrary clients. It is tempting for site-to-site links, but a baseline for user-facing data in transit is TLS.

Use HTTPS without additional controls

Why it fails: HTTPS alone encrypts the channel but omits controls such as HSTS, certificate validation and modern cipher suites, leaving downgrade and interception risks. It is tempting because TLS is the baseline mechanism, yet the question asks for the enforced baseline requirement, which is properly configured TLS rather than bare HTTPS.

Require SSH for all connections

Why it fails: SSH is for remote shell access, not for application data in transit.

Cloud Hardware Security Module (CloudHSM)

Why it fails: CloudHSM provides dedicated, single-tenant hardware key storage, but the requirement is keys held outside application memory, which a managed key store satisfies. CloudHSM suits regulatory mandates for exclusive hardware control and custom key operations, not the general separation this design needs.

Key Management Service (KMS)

Why it fails: KMS manages keys but may still expose them to the application unless using an HSM backing.

Trusted Platform Module (TPM)

Why it fails: A TPM is a discrete chip bound to one host, providing sealed storage and attestation for that machine. It cannot serve a distributed cloud application spanning multiple instances. TPMs are the right choice for platform integrity and BitLocker-style disk sealing on a single physical server.

Regularly update base images

Why it fails: Updating is important but does not prevent use of out-of-date or vulnerable images if not enforced.

Use network segmentation to isolate production containers

Why it fails: Network isolation limits blast radius but does not prevent vulnerable images from being deployed.

Run all containers as non-root users

Why it fails: This is a defense-in-depth measure but does not prevent deployment of vulnerable images.

Use TLS for all network connections

Why it fails: TLS protects data in transit, not at rest.

Implement a key management system

Why it fails: KMS is part of encryption but not a standalone control; encryption already implies key management.

Change the endpoint type to private

Why it fails: Endpoint type is unrelated to route key uniqueness.

Add an authentication mechanism to the API

Why it fails: Authentication does not resolve route key conflicts.

Verify that the API is deployed to the correct stage

Why it fails: Deployment stage does not cause route key conflicts.

The resource identifier should not include a wildcard

Why it fails: A wildcard in the resource identifier is normal and often required to scope a policy to a bucket and its objects; the actual flaw lies in the principal or action granted. Restricting resource ARNs is tempting because least privilege does favour narrow resources, and it would be correct if the policy granted access to unrelated buckets.

The policy should use a condition with source VPC instead of IP

Why it fails: A source VPC condition restricts access based on the originating virtual network, not the client’s IP address. This policy fails because the scenario involves a specific IP range restriction, which a VPC condition cannot enforce; the correct mechanism is an IP address condition using the `aws:SourceIp` key. It is tempting because source VPC conditions are the standard way to limit access to resources from within a trusted network boundary, and would be correct if the requirement were to allow only traffic originating from a particular VPC rather than from a specific set of client IP addresses.

The IP address range is too broad

Why it fails: An overly broad IP range is a weakness, but the primary issue is the permission granted to that range, such as public or anonymous read access to sensitive data. Narrowing CIDR blocks is tempting because network scoping is a genuine control, and it would be the answer if the range exposed the bucket to unintended networks.

Verify that the instance is not assigned a public IP address

Why it fails: A public IP concerns network exposure, not the patch state or vulnerability of the machine image the analyst suspects. Verifying public IP assignment is the right action when investigating unintended internet reachability of an instance, not image currency.

Check the security groups associated with the instance

Why it fails: Security groups control inbound and outbound traffic, revealing nothing about whether the image's installed packages are outdated. Checking security group rules is correct when the concern is network access paths, not the vulnerability posture of the launched image itself.

Check the image ID for known vulnerabilities using the cloud provider's patch management service

Why it fails: Using patch management tools applies updates to running instances, but does not provide historical vulnerability information about the machine image used.

Tokenization of sensitive fields with a separate token vault

Why it fails: Tokenisation replaces values with vault-held tokens, so a dumped database yields no plaintext, but the question asks for encryption configuration and the vault becomes the confidentiality boundary. It is tempting because tokenisation genuinely protects against dumps, and it would be correct where format-preserving substitution suits the data model.

Entire database encryption at rest using cloud provider managed keys

Why it fails: Provider-managed keys leave the cloud provider able to decrypt, so a stolen dump can still be read by anyone who obtains those keys or provider access. It is tempting because it is encryption at rest, and it would be correct where operational simplicity outweighs the need for customer-controlled key custody.

Transport layer security for all connections

Why it fails: TLS secures data on the wire between client and database, but a database dump is data at rest, so TLS provides no confidentiality once the file is exfiltrated. It is tempting because TLS is a fundamental control, and it would be correct when the threat is interception of connections rather than stolen storage.