Operating Cloud Infrastructure
Remote access: brokered entry, never an open port
Picture the finding an auditor circles first: an administrator's instance with RDP (TCP 3389) or SSH (TCP 22) open to 0.0.0.0/0. That one rule is what brute-force bots and ransomware crews scan for, so the entire operate-and-maintain discipline starts by removing it. The principle is constant across providers: an administrator reaches the host through one hardened, logged choke point, and the workload host is never directly reachable from the internet.
The bastion (jump box) pattern
A bastion host, also called a jump box, is a dedicated, minimally-configured VM that sits in a public subnet and is the only machine permitted to accept inbound administrative traffic. Workload instances live in private subnets, and their security group allows SSH or RDP only from the bastion's security group, not from any IP range. An operator connects to the bastion, then hops from the bastion to the target. Because the bastion is the single entry point, you concentrate your controls there: multi-factor authentication, tight allow-lists, and session recording. The bastion runs nothing but the access tooling, so its own attack surface stays small.
Other remote-access channels
- VPN gives an operator an encrypted tunnel onto the private network so they can reach many hosts as if local, rather than one host through a jump box. It suits broad operational reach; it does not by itself give per-host session recording.
- Console / out-of-band access (the provider's serial or hypervisor console) is the recovery path when the network or SSH daemon itself is broken. It bypasses the normal network path, so it must be guarded as tightly as the bastion.
- Virtual client / terminal access brokers a desktop session to the guest without exposing the guest's RDP port to the network.
The cloud-native answer: a managed session broker
Each major provider now offers a brokered service that removes the inbound port entirely. AWS Systems Manager Session Manager[1] opens a shell to an instance through an outbound agent connection and the SSM API, so the instance needs no inbound rule and no bastion; access is scoped by IAM and every session is logged to CloudWatch or S3. Azure Bastion[2] is a managed jump-host that brokers RDP/SSH over TLS from the portal so the VM keeps no public IP. Google Cloud's Identity-Aware Proxy (IAP) for TCP forwarding[3] tunnels SSH/RDP through Google's edge with no external IP on the VM. For the exam, the recognition is: when a scenario wants administrative access with no open management port and centralized, identity-bound logging, the answer is a managed broker, not a hand-built jump box.
Secure network configuration inside the cloud
Once access is brokered, the next operate-and-maintain task is keeping the traffic between hosts segmented, encrypted, and trustworthy. Five controls do most of the work, and the exam tests which one solves which problem.
Segmentation with VLANs and security groups. A VLAN partitions one physical network into isolated broadcast domains so tenants or tiers cannot see each other's traffic at layer 2. In the cloud you layer security groups on top: a security group is a stateful virtual firewall attached to an instance, where allowing an inbound flow automatically permits its return traffic. Keep groups scoped to other groups ("the web tier may talk to the app-tier group") rather than to wide IP ranges.
Encryption in transit with TLS and VPN. TLS protects an individual service connection (an API call, a management session); a VPN protects everything that crosses an untrusted link by tunneling it. Use TLS for application and management endpoints, and a VPN (or the provider's private backbone) when an entire site or operator must reach the private network.
Trustworthy addressing with DHCP and DNSSEC. DHCP hands out IP configuration; left unguarded it lets a rogue server feed clients a malicious gateway or DNS resolver, so it is locked down to authorized servers. DNSSEC signs DNS responses so a resolver can verify a record was not forged in transit. The classic exam pairing: DNSSEC provides authenticity and integrity of DNS answers, not confidentiality; it does not encrypt the query.
| Control | Layer / scope | What it protects | Common exam trap |
|---|---|---|---|
| VLAN | L2 segmentation | Tenant/tier isolation | Confusing it with a security group (L3/4 stateful filter) |
| Security group | Stateful host firewall | Per-instance allowed flows | Thinking it is stateless and adding return rules |
| TLS | Single connection | Confidentiality + integrity of one session | Assuming it segments the network |
| VPN | Whole link/tunnel | All traffic over an untrusted path | Using it where per-host logging is the real need |
| DNSSEC | DNS responses | Authenticity + integrity of records | Believing it encrypts DNS (it does not) |
Network security controls: firewalls, IDS/IPS, honeypots
Segmentation decides who may talk; the next layer inspects what actually crosses the wire. These controls are easy to confuse on the exam because their names overlap, so anchor each to its exact job.
Filtering vs. detection vs. prevention
A firewall allows or denies traffic against a ruleset; in the cloud the per-instance form is the security group (stateful) and the subnet form is the network ACL (stateless, so it needs an explicit rule in each direction). An IDS (intrusion detection system) watches a copy of the traffic and raises an alert when it matches a signature or anomaly, but it does not block. An IPS (intrusion prevention system) sits inline and can drop or reset the offending flow in real time. The single sharpest distinction the exam tests: IDS detects and alerts, IPS detects and blocks, and an IPS must be inline to do so.
Honeypots
A honeypot is a deliberately exposed decoy system with no production value, so any interaction with it is by definition suspicious and worth investigating. It buys early warning and threat intelligence about an attacker's methods. The operate-and-maintain caution is containment: a honeypot must be isolated so a compromise of the decoy cannot pivot into real systems, and many organizations weigh the legal and entrapment questions before deploying one.
Vulnerability assessment
Routine, authenticated vulnerability scanning finds missing patches and weak configurations before an attacker does, and it feeds the patch and hardening cycle. It is not a penetration test: a scan enumerates known weaknesses, while a pen test actively exploits them to prove impact. In the cloud, confirm the provider's testing policy before scanning shared infrastructure.
How the pieces stack
Think of it as concentric layers an attacker must cross: the security group and network ACL filter at the edge of the subnet and the host; the IDS/IPS inspects the payload of whatever the filters let through; the honeypot catches whatever reaches a place it never should; and the vulnerability scanner runs continuously behind all of it to shrink what any of them must catch.
OS hardening and patch management
A host is hardened when it has been reduced to a documented, measurable baseline and then audited against it. The baseline is not invented per server; it comes from a published standard, most often a CIS Benchmark[4] or, in government contexts, a DISA STIG, with NIST SP 800-123[5] giving the general server-hardening guidance behind both. The recurring principle is least functionality: run only the services and accounts the host's role requires.
What hardening actually changes
- Remove or disable default and unused accounts; rename or lock the built-in administrator/root where the baseline calls for it.
- Close every network port and stop every service the role does not need.
- Enforce the baseline's password, lockout, and audit-logging policy.
- Apply vendor security configuration for the platform: Windows Group Policy / security baselines, Linux SELinux/AppArmor and minimal package sets, and the VMware hardening guide for ESXi hosts.
- Record the result against the benchmark so drift can be detected later.
Patch management on immutable infrastructure
The cloud-native model treats servers as cattle, not pets, so patching is usually re-imaging rather than in-place updating. You rebuild the golden image with the patched packages, bake the hardened baseline back in, and roll the fleet to the new image; the old, unpatched instances are terminated. This guarantees every host is identical and erases the configuration drift that accumulates on hand-patched servers.
The loop has a fixed order, and an exam scenario about a botched patch is usually testing whether you skipped a step:
- Identify missing patches (vulnerability scan, vendor advisory).
- Test the patch in a non-production environment.
- Schedule the rollout through change management.
- Deploy to a canary or a subset, then the rest of the fleet.
- Verify the patch took and the service is healthy; keep the previous image so you can roll back instantly if it did not.
In-place patching is reserved for genuinely stateful hosts that cannot be replaced; everywhere else, replacement is both safer and faster to audit.
Availability: clustered hosts, HA, and backup/restore
Hardening keeps a host safe; clustering keeps the service alive when a host is not. Operating cloud infrastructure pools physical hosts into a cluster and lets the platform place, move, and restart guests across them, so a single hardware failure or a planned maintenance window does not take the workload down.
The cluster mechanisms
- High availability (HA) restarts a failed VM's guests on a surviving host in the cluster automatically. It accepts a brief outage (the restart time) in exchange for recovery without human intervention. It is not fault tolerance, which would run a lockstep shadow VM for zero downtime.
- Resource scheduling / DRS. A distributed resource scheduler (VMware DRS is the canonical name) live-migrates running guests between hosts to balance CPU and memory load and to honor placement rules. It is the same machinery that evacuates a host on demand.
- Maintenance mode uses that migration to drain every guest off a host before you patch or reboot it, so the host can be serviced with no guest downtime. This is how immutable patching and HA fit together: maintenance mode empties the host, you replace or patch it, HA and DRS keep the guests running elsewhere meanwhile.
- Storage clusters replicate the underlying datastore so a guest can restart on another host and still find its disk.
Performance, capacity, and hardware monitoring
Availability also depends on seeing trouble early. Operators monitor two things: performance and capacity (network throughput, compute utilization, storage I/O, response time) to catch saturation before it degrades service, and hardware health (disk SMART status, CPU, fan speed, temperature) to catch a failing component before it fails. In a managed cloud the provider owns the physical sensors, but the tenant still monitors guest-level capacity and the cluster's headroom.
Backup and restore
Clustering protects against host failure; backup protects against data loss, corruption, ransomware, and fat-fingered deletion, which clustering cannot. Configure host- and guest-level backups, store copies off the primary cluster (ideally in another region or account), and protect at least one immutable copy against tampering. The decisive operate-and-maintain rule: a backup you have never restored is a hope, not a control — schedule restore tests, because backups silently fail and only a test proves recoverability. The recovery objectives those backups must meet (RTO, RPO) are set in the BC/DR plan, not chosen here.
IaC, the management plane, and exam-pattern recognition
Two cross-cutting ideas tie the operate-and-maintain domain together, and both show up as the "right answer" in scenario questions.
Infrastructure as Code
Infrastructure as Code (IaC) defines servers, networks, and policies in versioned text (Terraform, CloudFormation, ARM/Bicep) that the platform provisions automatically. Three security properties make it the operate-and-maintain default: every change is reviewed and recorded like source code (the audit trail), the same template produces identical environments every time (no drift), and a bad change is rolled back by redeploying the prior version. IaC is what makes immutable patching and consistent hardening practical at fleet scale, so a scenario asking how to keep hundreds of hosts configured identically and auditably is pointing at IaC.
The management plane
The management plane is the control layer (the cloud console, APIs, and orchestration tooling) used to schedule, provision, and maintain everything else. Because it can create, destroy, and reconfigure the entire estate, it is the highest-value target in the environment: an attacker who owns the management plane owns the cloud. Protect it accordingly — MFA on every administrative identity, least-privilege roles, no standing root/owner access, and complete logging of every control-plane action. The exam frames a management-plane compromise as catastrophic precisely because no host-level control can contain it.
Recognizing the question
- "Administrative access with no open management port and centralized logging" → a managed session broker (Session Manager / Azure Bastion / IAP), not a public RDP rule.
- "Keep a large fleet identical and changes auditable" → Infrastructure as Code with immutable rebuilds.
- "Patch a host running production guests with no downtime" → maintenance mode to drain guests, then HA/DRS keeps them running while you service the host.
- "Detect vs. block malicious traffic" → IDS detects and alerts; IPS is inline and blocks.
- "DNSSEC protects which property?" → integrity and authenticity of DNS records, not confidentiality.
- "We have backups but can't recover" → the missing control is a tested restore, not more backups.
- "Most damaging single compromise" → the management plane, because it controls every other resource.
Remote-access patterns for administering cloud hosts
| Pattern | Inbound port exposed | Where it runs | Native session logging | Best fit |
|---|---|---|---|---|
| Direct public RDP/SSH | Yes, to the internet | On the target host | Host logs only | Never for production; the classic finding to flag |
| Bastion / jump box | Only to the bastion | Dedicated hardened VM in a public subnet | On the bastion if configured | VM-based fleets needing a single audited entry point |
| VPN to private network | VPN endpoint only | Gateway plus client tunnel | Gateway/connection logs | Operators who need broad network reach, not one host |
| Managed session broker | None (provider API) | Provider control plane (Session Manager, Azure Bastion, IAP) | Yes, centrally, by default | Cloud-native fleets wanting no open port and IAM-scoped, recorded access |
Decision tree
Sharp facts the exam loves — give these one last read before exam day.
Cheat sheet
Sharp facts the exam loves — scan these before test day.
- Reach hosts through a bastion, never an open management port
A bastion host, also called a jump box, is a hardened VM in a public subnet that is the only machine allowed to accept inbound RDP or SSH; workload hosts in private subnets accept admin traffic only from the bastion's security group, never from the internet. Concentrating access at one logged choke point lets you enforce MFA, tight allow-lists, and session recording in a single place, instead of securing every host's exposed port. An internet-facing RDP (3389) or SSH (22) rule open to 0.0.0.0/0 is the classic exposure these patterns exist to remove.
Trap Putting the bastion in the same security group rules as the workload but still leaving the workload's RDP/SSH open to the internet, which defeats the single-entry-point design.
- Use a managed session broker for admin access with no inbound port
When a scenario wants administrative access with no open management port and centralized, identity-bound logging, the answer is a managed broker rather than a hand-built bastion. AWS Systems Manager Session Manager, Azure Bastion, and GCP Identity-Aware Proxy all reach the host through the provider's control plane over an outbound or TLS-brokered connection, so the instance needs no inbound rule and often no public IP, and every session is scoped by IAM and logged centrally by default.
Trap Choosing a public RDP/SSH rule plus a network ACL allow-list when the requirement is no inbound port at all; only a brokered service removes the port.
- VPN gives broad network reach; a jump box gives one audited host entry
A VPN establishes an encrypted tunnel onto the private network so an operator can reach many hosts as if local, which suits broad operational reach. A bastion brokers access to one target through a single recorded hop, which suits a clean per-host audit trail. Pick the VPN when the operator legitimately needs to touch many systems, and the jump box when the requirement is a single controlled, logged entry point.
Trap Reaching for a VPN when the real requirement is per-session recording of who touched which host; a plain VPN logs the tunnel, not each host session.
- Out-of-band console access is the recovery path, so guard it like the bastion
The provider's serial or hypervisor console reaches a guest even when its network stack or SSH daemon is broken, which makes it the recovery channel of last resort. Because it bypasses the normal network controls, it must be protected as tightly as the primary admin path, with MFA and tight authorization, or it becomes an unmonitored back door.
- Security groups are stateful; network ACLs are stateless
A security group is a stateful per-instance firewall: allow an inbound flow and its return traffic is permitted automatically, so you do not write a matching outbound rule. A network ACL is a stateless subnet-level filter, so return traffic needs its own explicit rule in the opposite direction, including the ephemeral-port range. Knowing which is stateful decides how many rules a given scenario actually requires.
Trap Treating a network ACL as stateful and forgetting the return-direction rule, so the response traffic is silently dropped even though the request was allowed.
- VLANs segment at layer 2; security groups filter at layer 3/4
A VLAN partitions one physical network into isolated broadcast domains so tenants or tiers cannot see each other's traffic at the link layer. A security group, by contrast, filters allowed flows per instance higher up the stack. They are complementary: VLANs isolate the network, security groups govern which allowed flows cross between hosts; neither replaces the other.
- DNSSEC protects integrity and authenticity, not confidentiality
DNSSEC signs DNS records so a resolver can verify an answer was not forged or tampered with in transit. It does not encrypt the query or response, so it provides no confidentiality; an observer still sees which names are looked up. The exam pairing to lock in: DNSSEC defends against spoofing and cache poisoning, while encryption of the lookup itself is a separate concern.
Trap Assuming DNSSEC encrypts DNS traffic; it only signs records for integrity, so confidentiality requires a different control.
- Lock DHCP to authorized servers to stop rogue configuration
DHCP hands clients their IP address, gateway, and DNS resolver, so an unguarded segment lets a rogue DHCP server feed clients a malicious gateway or resolver and silently intercept traffic. Restricting DHCP to authorized servers (and enabling DHCP snooping where the platform supports it) keeps an attacker from redirecting hosts through their own machine.
- TLS secures one session; a VPN secures the whole link
TLS protects an individual connection such as an API call or a management session, giving that session confidentiality and integrity. A VPN tunnels everything crossing an untrusted path between two endpoints. Use TLS for application and management endpoints, and a VPN when an entire site or operator must reach the private network over hostile transit.
- IDS detects and alerts; IPS is inline and blocks
An intrusion detection system inspects a copy of the traffic and raises an alert on a match, but it does not stop the flow. An intrusion prevention system sits inline in the traffic path and can drop or reset the offending connection in real time. The distinction the exam turns on is action plus placement: detection-only and out-of-band for IDS, blocking and inline for IPS.
Trap Selecting an IDS when the requirement is to actively stop malicious traffic; an IDS only alerts, so blocking needs an inline IPS.
- A honeypot is a decoy, so any interaction with it is suspicious
A honeypot is a deliberately exposed system with no production value, so any connection to it signals reconnaissance or attack and yields early warning and threat intelligence. It must be isolated from real systems so a compromise of the decoy cannot pivot into production, and organizations often weigh legal and entrapment concerns before deploying one.
Trap Placing a honeypot with network reach into production so a compromised decoy becomes a foothold rather than a contained sensor.
- A vulnerability scan enumerates weaknesses; a pen test exploits them
Routine authenticated vulnerability scanning finds missing patches and weak configurations and feeds the patch and hardening cycle, but it only reports known weaknesses. A penetration test goes further and actively exploits them to prove real-world impact. In the cloud, confirm the provider's testing policy before scanning shared infrastructure.
Trap Calling a vulnerability scan a penetration test; the scan lists potential issues, while the pen test demonstrates exploitability.
- Harden hosts to a published baseline like a CIS Benchmark or STIG
Hardening reduces a host to a documented, measurable configuration standard, most often a CIS Benchmark or a DISA STIG in government contexts, then audits the host against it. NIST SP 800-123 frames the goal as least functionality: run only the accounts, ports, and services the role requires, and turn on audit logging. Building from a named baseline gives you a repeatable target and a way to detect drift, rather than ad hoc per-server tweaks.
- Bake the baseline into the golden image, not into a live server
Because cloud hosts are short-lived, the hardened baseline is applied to the golden image and re-applied on every rebuild, instead of being hand-configured on a running instance. This keeps every host in the fleet identical to the audited standard and removes the configuration drift that accumulates when operators patch live servers by hand.
- Patch immutable infrastructure by re-imaging, not in-place updates
The cloud-native patch model treats servers as cattle: rebuild the golden image with the fixed packages, roll the fleet to the new image, and terminate the old instances, rather than updating each running host. This guarantees every host is identical, erases drift, and lets you roll back instantly by redeploying the prior image. In-place patching is reserved for genuinely stateful hosts that cannot be replaced.
Trap Hand-patching a fraction of a fleet in place, which leaves the rest unpatched and reintroduces the drift immutable rebuilds exist to prevent.
3 questions test this
- An organization follows an immutable infrastructure model using Infrastructure as Code for cloud workloads. A critical vulnerability is…
- An organization is migrating its workloads to the cloud and wants to implement a patching strategy that increases reliability, consistency,…
- An organization uses an immutable infrastructure model for its containerized workloads in the cloud. When a vulnerability scanner…
- Follow the patch loop in order: identify, test, schedule, deploy, verify
Patch management runs a fixed sequence: identify missing patches from scans and advisories, test the patch in non-production, schedule it through change management, deploy to a canary subset before the full fleet, then verify the patch took and the service is healthy while keeping the previous image for rollback. A scenario about a patch that broke production is usually testing whether the test or canary step was skipped.
Trap Deploying a patch fleet-wide without a canary or a tested rollback image, so a bad patch takes the whole service down at once.
5 questions test this
- An organization discovers a zero-day vulnerability affecting critical production systems in their cloud environment. Their standard patch…
- A vulnerability scanner identifies a critical vulnerability across multiple production virtual machines in a cloud environment. The vendor…
- Your organization is designing an automated patching workflow for cloud workloads that integrates vulnerability scanning with patch…
- According to NIST SP 800-40, which phase of enterprise patch management involves confirming that patches have been successfully applied and…
- A cloud operations team is preparing to deploy a non-emergency security patch to ESXi hypervisor hosts in their production cluster. Before…
- HA restarts failed guests; fault tolerance runs a zero-downtime shadow
High availability automatically restarts a failed host's guests on a surviving cluster member, accepting a brief restart outage in exchange for recovery without human action. Fault tolerance instead runs a lockstep shadow VM so a host failure causes no downtime at all, at much higher cost. Match the mechanism to how much interruption the workload can absorb.
Trap Assuming HA gives zero-downtime failover; HA tolerates a short restart gap, and only fault tolerance avoids the outage entirely.
- Use maintenance mode to drain a host before patching it
Maintenance mode tells the cluster to evacuate every guest off a host, using live migration (a resource scheduler such as VMware DRS), so the host can be patched or rebooted with no guest downtime. It is how immutable patching and HA fit together: the scheduler empties the host, you service it, and the guests keep running on other cluster members meanwhile.
- DRS live-migrates running guests to balance load and drain hosts
A distributed resource scheduler, with VMware DRS as the canonical example, live-migrates running guests between cluster hosts to balance CPU and memory load and to honor placement rules. The same migration machinery powers maintenance-mode evacuation, so the scheduler is doing double duty for both performance balancing and planned maintenance.
- Monitor hardware health and capacity to catch failure before outage
Availability depends on seeing trouble early, so operators track two signals: performance and capacity (network throughput, compute utilization, storage I/O, response time) to catch saturation before it degrades service, and hardware health (disk SMART status, CPU, fan speed, temperature) to catch a failing component before it dies. In managed cloud the provider owns the physical sensors, but the tenant still watches guest-level capacity and cluster headroom.
- Clustering survives host failure; backups survive data loss and corruption
Cluster HA protects against a host dying, but it cannot recover from data corruption, ransomware, or accidental deletion because it keeps running the same bad data. Backups cover exactly those cases. Store backup copies off the primary cluster, ideally in another region or account, and keep at least one immutable copy that cannot be altered or deleted by a compromised admin.
Trap Relying on cluster HA or replication as the backup; replication faithfully copies corruption and ransomware to the replica, so it is not a recovery control.
- An untested backup is not a control; schedule restore tests
Backups fail silently, so a backup you have never restored is a hope rather than a control. Schedule periodic restore tests to prove the data is recoverable and that the process meets the recovery objectives. The recovery targets themselves (RTO and RPO) are set in the BC/DR plan, not chosen during day-to-day operations; backup operations exist to meet them.
Trap Treating successful backup jobs as proof of recoverability; only a tested restore confirms the backup can actually be brought back.
- Define infrastructure as code for identical, auditable, rollback-able fleets
Infrastructure as Code defines servers, networks, and policies in versioned templates (Terraform, CloudFormation, ARM/Bicep) that the platform provisions automatically. Three properties make it the operate-and-maintain default: every change is reviewed and recorded like source code, the same template yields identical environments with no drift, and a bad change is rolled back by redeploying the prior version. A scenario about keeping hundreds of hosts configured identically and auditably is pointing at IaC.
- The management plane is the highest-value target, so guard it hardest
The management plane is the control layer (console, APIs, orchestration) that can create, destroy, and reconfigure every resource, so an attacker who owns it owns the whole cloud. No host-level control can contain a management-plane compromise, which is why the exam frames it as catastrophic. Protect it with MFA on every admin identity, least-privilege roles, no standing root or owner access, and complete logging of every control-plane action.
Trap Assuming host hardening or network controls limit the blast radius of a management-plane compromise; control of the plane overrides controls beneath it.
- Patching responsibility shifts with the service model: IaaS customer patches the guest OS
Under shared responsibility the customer's patching burden grows as you move down the stack: in IaaS the customer patches the guest operating system and applications, in PaaS the CSP patches the platform and OS while the customer patches their code, and in SaaS the CSP patches everything. The provider always owns the underlying infrastructure and hypervisor.
Trap Assuming the CSP patches the guest OS on IaaS VMs — that responsibility stays with the customer.
5 questions test this
- A cloud security professional reviews vulnerability scan results showing missing operating system patches across the organization's cloud…
- An organization uses SaaS for email, PaaS for application development, and IaaS for hosting legacy systems. The security team is defining…
- An organization deployed virtual machines in a public cloud IaaS environment to host critical applications. The security team needs to…
- Your organization deploys virtual machines using an IaaS cloud service model and also consumes a PaaS-based database service from the same…
- A company operates a hybrid cloud environment with workloads distributed across IaaS virtual machines and PaaS-hosted applications. The…
- Virtual patching shields a zero-day until the real patch ships
When a vendor patch is unavailable or systems cannot be taken offline, virtual patching applies a security-policy enforcement layer (such as IPS or WAF signatures) that blocks exploitation attempts without modifying the underlying code. It is an interim compensating control, paired with an expedited emergency-patching process once the fix is released.
Trap Waiting out the normal multi-week test cycle for a live zero-day instead of deploying virtual patching as an interim shield.
- ESXi lockdown mode forces administration through vCenter, not direct host login
Enabling lockdown mode on an ESXi host restricts direct local logins and forces administrative operations through vCenter Server, which enforces centralized authentication, role-based access control, and audit logging. Effective hypervisor hardening layers this with MFA, application allowlisting, regular patching, and behavioral anomaly monitoring.
Trap Leaving direct local ESXi access open for convenience, bypassing the centralized authentication and audit trail vCenter provides.
- Credentialed scans see far more than unauthenticated scans
An authenticated (credentialed) vulnerability scan logs into the target with valid credentials and enumerates installed software, patch levels, and configuration from the inside, revealing weaknesses invisible to an external unauthenticated scan. For ephemeral auto-scaling fleets, baking scanning agents into the base image gives every new instance coverage on launch.
Trap Trusting a thin unauthenticated scan result as complete when a credentialed scan would expose far more internal findings.
3 questions test this
- An organization's cloud environment uses auto-scaling groups that dynamically provision and terminate virtual machine instances based on…
- An organization deploys virtual machines in an IaaS cloud environment and wants to obtain the most comprehensive view of vulnerabilities…
- An organization deploys a vulnerability scanner to assess its cloud-hosted IaaS virtual machines. The initial non-credentialed scan returns…
- Encryption at rest does not cover the wire; add in-transit encryption
Server-side encryption at rest protects stored data but leaves it exposed as it crosses the network over file or block protocols, so NAS (NFS/SMB) and iSCSI SAN traffic needs TLS or IPsec for confidentiality and integrity in transit. The at-rest encryption should also be transparent to standard protocol clients so operations are unaffected.
Trap Assuming at-rest encryption alone secures NAS or iSCSI data, leaving the protocol traffic open to interception on the network.
3 questions test this
- An organization is migrating shared file storage to a cloud-based NAS solution using NFS and SMB protocols. When implementing encryption at…
- An organization deploys a cloud-based NAS solution with AES-256 server-side encryption at rest for shared file storage. Users access file…
- An organization is deploying an iSCSI-based SAN in a cloud IaaS environment to host database workloads. The security team must protect data…