Security practice questions

The user's VM is isolated from the subnet due to a misconfigured VLAN.

Why wrong: The user can access other applications in the same subnet, so VLAN misconfiguration is unlikely.

The user's account has been disabled due to a failed login attempt.

Why wrong: The user can still access other applications, so the account is active.

The hypervisor is denying access to the application due to a resource quota violation.

Why wrong: Resource quota violations would affect all applications or VMs, not just one application.

Implement strong password policies with complex passwords.

Why wrong: Complex passwords can still be compromised; MFA is more secure.

Disable the web console and require API access only.

Why wrong: This would not prevent unauthorized access if API keys are compromised.

Restrict console access to a specific IP address range.

Why wrong: IP whitelisting can be circumvented by IP spoofing or using a whitelisted location.

Assign an elastic IP and use NAT.

Why wrong: NAT changes the source IP, which could break the licensing requirement.

Use TLS certificates on the web server.

Why wrong: TLS protects web traffic, not the database connection.

Deploy a site-to-site VPN from the cloud to the on-premises data center.

Why wrong: This does not address internal traffic encryption.

Use HTTP with a custom header.

Why wrong: HTTP is not encrypted.

Allow FTP but restrict to specific IPs.

Why wrong: FTP is unencrypted and insecure.

Enable SFTP access to the bucket.

Why wrong: SFTP is not a standard protocol for cloud storage buckets.

Physical access logs from the data center.

Why wrong: Physical logs are not relevant for cloud SIEM.

Firewall configuration backup files.

Why wrong: Config backups are not real-time logs.

Employee vacation schedule.

Why wrong: Not a security data source.

Use a single virtual switch for all tenants.

Why wrong: A shared vSwitch can allow sniffing.

Place all tenants on the same storage array for efficiency.

Why wrong: Shared storage can lead to data leakage.

The bucket had versioning enabled, which reverted to a previous public state.

Why wrong: Versioning does not revert access policies.

Access logs were not enabled, so the change was not recorded.

Why wrong: Lack of logging does not cause the bucket to become public.

Server-side encryption was disabled, causing the bucket to become public.

Why wrong: Encryption settings do not affect public access.

Generate a self-signed certificate and configure the web server to use it.

Why wrong: Self-signed certificates are not trusted by browsers and would cause security warnings.

Disable HTTPS and rely on network-level encryption provided by the cloud provider.

Why wrong: Disabling HTTPS eliminates end-to-end encryption, leaving data vulnerable.

Create a certificate signing request (CSR) and submit it to a public CA, then install the certificate and private key on the VM.

Why wrong: Storing the private key on the VM increases the risk of exposure; managed services handle key storage securely.

The web server is not configured to listen on port 443, so iptables rules are irrelevant.

Why wrong: The question states the web server is configured to listen on both ports; the issue is firewall-related.

The iptables default policy is ACCEPT, but the rule for port 443 explicitly drops traffic from external sources.

Why wrong: The rule for port 443 does not drop traffic; it accepts from a specific subnet. Traffic from other sources is subject to the default policy.

The rule for port 80 is placed before the rule for port 443, causing all HTTPS traffic to be evaluated as HTTP and dropped.

Why wrong: The rules are evaluated in order, but the port numbers are different; HTTPS traffic matches the port 443 rule, not port 80.

Use a single security group for all instances and define rules to allow traffic between tiers.

Why wrong: A single security group allows all instances to communicate, defeating segmentation.

Place web servers in a public subnet and application and database servers in the same private subnet with a common security group.

Why wrong: Combining app and db in one subnet with same security group does not segment them.

Place all instances in the same subnet and use network ACLs to restrict traffic between tiers.

Why wrong: A single subnet does not provide network segmentation; ACLs alone are insufficient for isolation.

Attach an internet gateway to the VPC and use public IP addresses.

Why wrong: An internet gateway does not encrypt traffic; it exposes resources to the internet.

Use a NAT gateway to translate private IPs to public IPs.

Why wrong: NAT gateway does not provide encryption or dedicated bandwidth.

Set up a direct connection between the on-premises router and the cloud VPC.

Why wrong: A direct connection provides dedicated bandwidth but does not encrypt traffic by default.

Review the user's recent access logs to see which actions were allowed.

Why wrong: Access logs show historical actions, not all effective permissions.

Check the resource-based policies on each resource the user might access.

Why wrong: Resource-based policies control access from a resource perspective, not the user's effective permissions.

Log in as the root user and run a permissions report.

Why wrong: The root user has full access and cannot be used to simulate another user's permissions.

The upload succeeds but the object is stored without server-side encryption.

Why wrong: The condition requires encryption, so the request would be denied.

The upload succeeds because the request uses HTTPS and the role is allowed.

Why wrong: The Allow statement has a condition that is not met.

The upload fails because the Deny statement blocks all requests that are not using HTTPS.

Why wrong: The Deny only blocks requests that are NOT using HTTPS; this request uses HTTPS.

Enable VPC flow logs to detect and block malicious traffic.

Why wrong: VPC flow logs capture IP traffic information for analysis but do not actively block or filter traffic.

Configure a security group with inbound rules for the web tier and outbound rules for the database tier.

Why wrong: Security groups are stateful and cannot filter traffic between subnets; they are attached to instances and apply to all traffic to that instance.

Create an IAM policy to restrict access between subnets.

Why wrong: IAM policies control permissions for users and services, not network traffic routing or filtering.

Suspend the auto scaling group to prevent additional instances from being launched.

Why wrong: Suspending the group does not stop the current instance from communicating; the malicious traffic continues.

Use a routing table blackhole to drop traffic from the instance.

Why wrong: Blackholing traffic via routing is complex and could be disruptive; also, routing tables affect all traffic in the VPC.

Modify the network ACL for the subnet to deny traffic to the malicious IP.

Why wrong: Network ACL changes affect all instances in the subnet, potentially causing collateral damage to other instances.

Server-side encryption with cloud-managed keys (SSE).

Why wrong: Cloud-managed keys are controlled by the cloud provider, not the customer's on-premises HSM.

Disable encryption at rest to rely on network encryption.

Why wrong: This does not protect data at rest in the storage bucket.

Server-side encryption with customer-provided keys (SSE-C).

Why wrong: SSE-C requires sending the keys to the cloud provider for each operation, which may not meet the on-premises management requirement.