IAM practice questions

Port forwarding rule, because it allows applications to reach the encryption system.

Why wrong: Port forwarding rule maps an external IP address and port to an internal service, altering network traffic paths to let clients reach an encryption system. It has no mechanism for storing cryptographic keys, enforcing key access policies, or automating key rotation. While it might expose a key management endpoint to the network, it is a connectivity control, not a key-lifecycle control, and therefore cannot satisfy the requirement for centralized key storage and rotation.

Load balancer, because it distributes encryption requests across servers.

Why wrong: A load balancer distributes incoming requests across multiple backend servers based on algorithms such as round-robin or least connections, improving scalability and fault tolerance. Even if it performs TLS termination and handles certificates, it does not provide a centralized repository for application encryption keys or scheduled, policy-driven rotation of those keys. It may front-end a KMS, but it remains a traffic distribution mechanism, not a key management service.

Web application firewall, because it protects the keys from injection attacks.

Why wrong: A web application firewall inspects HTTP/S traffic and filters requests using signatures and rules to block injection attempts, such as SQL injection or cross-site scripting. It cannot store, manage, or rotate cryptographic keys because keys reside in a security module or key management service, not in request payloads, and WAF rules are not key-lifecycle policies. Protecting web traffic is complementary to, but fundamentally different from, centralized key management.

Host-based antivirus on each virtual machine.

Why wrong: Host-based antivirus (AV) on each VM detects and remediates malware within the guest OS by scanning file signatures and monitoring process behavior, but it has no visibility into the cloud provider's control plane. It cannot record management actions such as VM power-state changes, security-group modifications, or IAM role updates, because those events occur in the cloud API layer outside the guest. Therefore, AV is a data-plane safeguard and does not satisfy the requirement for an administrative audit trail.

A guest operating system screen saver policy.

Why wrong: A guest OS screen saver policy—such as locking the console after a timeout—is a local endpoint control designed to prevent unauthorized interactive access to the VM's desktop. It does not generate logs of cloud management operations like instance launches, VPC peering, or identity policy changes, and it operates entirely within the guest session. Since the team's objective is to track who performed cloud-level changes, this policy provides no relevant audit data and cannot support security investigations.

A static public IP address for every virtual machine.

Why wrong: Assigning a static public IP address to every VM gives each instance a fixed, externally reachable address, but it creates no record of administrative actions or configuration changes. It also enlarges the attack surface by ensuring the VMs remain continuously exposed to the internet, which may require additional perimeter controls. Static IPs are a network addressing choice, not a logging mechanism, and thus they fail to provide the required visibility into management-plane activity.

Encryption: Manages user access to resources.

Why wrong: This description is incorrect because managing user access to resources is the function of Identity and Access Management (IAM), not encryption. Encryption focuses on transforming data to maintain confidentiality, whereas access management controls who can perform actions on resources. Confusing these two controls undermines the understanding of defense-in-depth, as encryption and IAM address different security objectives.

IAM: Protects data by encoding it.

Why wrong: This description is incorrect because encoding data to prevent unauthorized reading is the role of encryption, not Identity and Access Management. IAM governs user identities, their authentication, and the permissions they hold, but it does not alter the data itself. The error likely stems from mixing up the confidentiality mechanism (encryption) with the access governance framework (IAM).

Install a rootkit detector on each workload and ignore management-plane activity.

Why wrong: Host-based rootkit detectors inspect the operating system's memory, kernel modules, and file system for signs of infection on a single instance, but they are blind to cloud control-plane events such as IAM role modifications, security group rule changes, or storage bucket permission updates that occur through provider APIs. Ignoring management-plane activity means losing the authoritative record of who changed infrastructure and when, leaving investigators with only fragmented endpoint artifacts rather than a complete audit trail.

Capture only DNS traffic, because it reveals all admin changes indirectly.

Why wrong: DNS logs can reveal which hostnames workloads query, but they contain no correlation with the cloud provider's administrative API calls. An attacker who alters a policy or deletes a network ACL often performs the action over HTTPS to an endpoint whose DNS resolution is cached, unrelated to the change, or bypassed entirely. Thus, DNS traffic is far too indirect to identify the identity, action, or exact time of control-plane modifications, which is exactly what an audit log must capture.

Rely on manual change tickets in a spreadsheet because cloud platforms do not record useful logs.

Why wrong: Spreadsheet-based change tickets are a procedural control, not a security audit log; they rely on humans to remember and correctly record every change and lack any tamper-evident linkage to actual cloud API requests. Cloud platforms such as AWS CloudTrail generate authoritative, immutable records of all management events, including the principal ARN, source IP, and request parameters in near real time. Relying on manual tickets would leave the organization without the deterministic, automated evidence required for incident response and compliance reporting.

Use one shared contractor account and rotate the password when people leave.

Why wrong: Using one shared contractor account with periodic password rotation does not address individual accountability or identity lifecycle. Because every contractor authenticates as the same account, it is impossible to attribute commands, file modifications, or resource access to a specific person, undermining auditing and non-repudiation. Password rotation only invalidates tokens after the fact and does not remove the need for unique, time-boxed accounts; additionally, anyone who knew the previous password may still have other established credentials (e.g., cached or remembered browser sessions). This violates least privilege and separation of duties.

Disable the account after the contract ends but keep all group memberships unchanged.

Why wrong: Disabling a contractor's account at the end of the engagement while leaving all group memberships intact does not actually remove the underlying permissions. If that account is later re-enabled—whether accidentally, through password reset, or by a service account—it instantly regains every resource access it had before, with no new review or approval. The account object remains a dormant identity with high entitlements, creating a dangerous attack surface for privilege escalation and a classic "orphaned account" scenario. Proper deprovisioning requires deleting or removing the account from all groups, and preferably applying an expiration date to enforce automatic cleanup.

Create a local workstation account so the contractor does not need centralized identity services.

Why wrong: Creating a local workstation account for a contractor avoids centralized directory services and leaves the organization with no single point of control for the account's lifecycle. Local accounts are stored independently on each computer, so password policies, multifactor authentication, and account expiration settings cannot be centrally enforced or audited. If the contractor needs access to multiple systems, you must manage separate local accounts per machine, multiplying administrative overhead and security gaps. This also makes it impossible to automatically tie termination or contract end dates to access revocation, directly impairing compliance with audit and data protection requirements.

Applying security patches to the provider's mail servers.

Why wrong: Applying security patches to the provider's mail servers is a task reserved for the SaaS vendor, not the customer. The patching lifecycle of the underlying mail application, operating systems, and supporting infrastructure is entirely managed by the provider to protect all tenants. Customers have no administrative or shell access to those servers and instead focus on client-side security, like configuring Outlook or securing the browser.

Replacing failed provider storage disks.

Why wrong: Replacing failed storage disks in the provider's infrastructure is part of the provider's operational duty, not the customer's. SaaS customers consume the service at the application level and have no physical or logical access to the underlying storage array, making hardware maintenance impossible and contractually prohibited. Hardware reliability is guaranteed via the provider's SLAs, and any failure is transparently handled by the vendor without customer involvement.

Hardening the provider's hypervisor.

Why wrong: Hardening the provider's hypervisor is a core security function performed by the cloud or SaaS provider, since the hypervisor is the virtualization layer that isolates tenants from one another. Customers are never granted access to the hypervisor console or its configuration, and attempting to alter it would require breaching the provider's trusted boundary. In practice, the customer's security efforts should be directed toward application-level settings, such as message encryption, malware filtering, and user behavior, rather than the hypervisor.