11.2 Operate & Maintain Infrastructure (Domain 5.2)
Key Takeaways
- Domain 5.2 covers operating and maintaining physical and logical cloud infrastructure: access control, network configuration and security controls, OS hardening, patching, availability, monitoring, backup/restore, and management-plane operations.
- Remote and local admin access should use jump hosts/bastions, SSO/MFA, secure protocols (SSH, TLS-protected consoles), and avoid direct internet exposure of RDP/SSH to production fleets.
- Network security combines correct configuration (VLAN/VPC segmentation, TLS, DNSSEC, VPN) with active controls (firewalls, IDS/IPS, security groups, bastions, vulnerability assessment, optional honeypots).
- OS hardening is baseline-driven (apply, monitor, remediate) for hosts and guests; patch management and configuration drift control keep the baseline alive after day one.
- Availability, capacity, hardware health, clustered-host operations, and tested backup/restore of host and guest systems are security-relevant because integrity and recovery depend on them—not only “performance tuning.”
Operate & Maintain Infrastructure
Domain 5.2 asks you to operate and maintain physical and logical infrastructure for the cloud environment. If 5.1 is construction, 5.2 is the daily shift: who can access systems, how networks stay secure, how OSes remain hardened and patched, how clusters stay available, how capacity and hardware health are watched, how backups work, and how the management plane schedules and orchestrates work without becoming chaos.
Access Controls for Local and Remote Access
Administrative access is a privileged pathway. Outline examples include RDP, secure terminal access / SSH, console-based access, jumpboxes, virtual clients, and SSO.
| Access method | Security expectations |
|---|---|
| SSH | Key-based or strong MFA; disable password-only where policy requires; limit users; log sessions |
| RDP | Do not expose to the open internet; NLA; MFA via gateway; restrict source IPs |
| Console / out-of-band | Physical or CSP console access tightly controlled; break-glass procedures; monitored |
| Jumpbox / bastion | Single controlled ingress for admin protocols; hardened; session recording where required |
| Virtual client / VDI | Admin tools run in managed desktops; data does not land on unmanaged endpoints |
| SSO | Central AuthN policy, MFA, rapid disable on termination; map groups to least-privilege roles |
Design Patterns
- No direct admin from untrusted networks — force path through VPN or zero-trust access + bastion.
- Named accounts — ban shared “root/admin” for routine work; use privilege elevation with audit.
- Just-in-time access — temporary elevation beats standing domain admin on every host.
- Session controls — timeouts, recording for highly sensitive planes, anomaly detection on admin geography/time.
- Local vs remote — local console in a data center still needs physical access control; remote multiplies exposure via networks and credentials.
Exam trap: “We have SSH” is not a complete answer. Prefer mediated, authenticated, authorized, and logged access with least privilege.
Secure Network Configuration
Configuration quality is the substrate for network security products.
| Technology | Secure operational use |
|---|---|
| VLAN / VPC segmentation | Separate tenants, environments, and tiers; control inter-VLAN routing |
| TLS | Encrypt management and application traffic in transit; modern cipher suites; certificate lifecycle |
| DHCP | Authorized DHCP services only; rogue DHCP is a classic LAN attack; in cloud, understand who controls addressing |
| DNSSEC | Integrity and authenticity of DNS responses where deployed; protect resolvers from cache poisoning |
| VPN | Site-to-site or client VPN with strong crypto, MFA for users, split-tunnel policy risk awareness |
Operational Hygiene
- Document allowed flows; reject “any-any” security group rules that accumulate over years.
- Prefer private connectivity to storage and databases over public endpoints.
- Rotate VPN and certificate materials; monitor for TLS downgrade and expired certs that force emergency insecure exceptions.
- Align cloud routing (route tables, peering, transit) with the same least-privilege mindset as firewalls.
Network Security Controls
Beyond configuration, Domain 5.2 lists active and structural controls: firewalls, IDS, IPS, honeypots, vulnerability assessments, network security groups, bastion hosts, and segmentation.
| Control | Role in operations |
|---|---|
| Firewall / security groups / NACLs | Enforce allow/deny policy at perimeter and instance/subnet layers |
| IDS | Detect suspicious traffic patterns and known attack signatures |
| IPS | Detect and block/inline prevent (tune carefully to avoid availability harm) |
| Bastion host | Controlled administrative entry point |
| Segmentation | Limit blast radius; isolate crown-jewel systems |
| Vulnerability assessment | Find missing patches, weak configs, exposed services—schedule and remediate |
| Honeypots | Deception sensors; alert on interaction; isolate so they do not become pivot points |
Layering example: Segmentation reduces who can talk to a database tier; security groups allow only app-tier ports; IDS/IPS watch remaining paths; vulnerability scans find forgotten open management ports; bastions are the only admin ingress. No single control replaces the set.
Honeypot caution: On the exam, honeypots are detection/deception tools, not primary preventive controls for production data. Do not place real credentials or production connectivity on a honeypot.
OS Hardening: Baselines, Monitoring, and Remediation
Hardening reduces attack surface by configuring systems to a known-secure state. The outline stresses baselines, monitoring, and remediation for guests and hosts (examples: Windows, Linux, VMware environments).
| Hardening lifecycle step | Activities |
|---|---|
| Define baseline | CIS benchmarks, vendor security guides, org standards; document exceptions |
| Apply | Golden images, configuration management, admission policies for clusters |
| Monitor | Configuration assessment, drift detection, vulnerability scanning, FIM where used |
| Remediate | Automated revert or ticketed fix; re-image when drift is severe |
Representative Hardening Content
- Disable unused services and accounts; rename/disable well-known admin accounts per policy.
- Enforce password/MFA policy for interactive access; restrict local admin membership.
- Enable host firewalls consistent with network policy.
- Configure secure audit logging; forward logs off-box.
- Apply disk encryption where required; protect swap and crash dumps for sensitive data.
- Remove development tools from production images.
- For hypervisors and virtualization hosts: lock down management APIs, time sync, and patch levels (ties to 5.1).
Immutable infrastructure complements hardening: instead of endless in-place drift repair, replace instances from a patched image. Hybrid estates still need in-place remediation for long-lived systems.
Patch Management
Patch management is the operational process to identify, evaluate, test, deploy, and verify fixes for OS, hypervisor, firmware, middleware, and often agents/toolsets.
| Process element | Good practice |
|---|---|
| Inventory | Know what exists (CMDB/asset inventory) before patching |
| Prioritization | Severity, exploitability, exposure, asset criticality |
| Testing | Stage rings: lab → pilot → broad production |
| Change control | Align with change management (Domain 5.3) for risk of outage |
| Deployment | Orchestrated rollout; maintenance windows; canary hosts |
| Verification | Confirm patch level; rescanning |
| Emergency patches | Fast path for actively exploited CVEs with post-implementation review |
| Firmware / BMC | Include out-of-band management devices—often forgotten |
Cloud nuance: On IaaS, customers patch guest OS and apps; CSPs patch underlying fabric. On PaaS/SaaS, customer focus shifts to platform configuration, client libraries, and application dependencies. Never assume “cloud means no patching.”
Availability of Clustered Hosts and Guest OS
Clustered Hosts
Outline topics include distributed resource scheduling, dynamic optimization, storage clusters, maintenance mode, and High Availability (HA).
| Capability | Security/operations meaning |
|---|---|
| HA / failover clustering | VMs or services restart on surviving hosts after host failure |
| Maintenance mode | Evacuate workloads before host patching/firmware work |
| DRS / dynamic optimization | Balance load; misconfiguration can move sensitive VMs onto less-trusted hosts—respect affinity/anti-affinity and dedicated host policies |
| Storage clusters | Resilient datastores; protect replication channels and management of storage fabric |
Security angle: Cluster admin rights are highly privileged. Unauthorized vMotion/live migration capabilities can relocate workloads for data theft or place them on compromised hosts. Control who can change affinity rules and maintenance operations.
Guest OS Availability
- Multiple instances behind load balancers across failure domains (AZs).
- Health checks that remove failed instances.
- Avoid single points of failure in licensing servers, domain controllers, or jump hosts that gate recovery.
- Guest clustering (application-aware) where the app requires it—test failover, not only install it.
Performance, Capacity, and Hardware Monitoring
Monitoring is not only an SRE concern; capacity exhaustion and hardware failure are availability and sometimes integrity events (failed disks, overheating, throttling that disables security agents).
| Domain | What to watch |
|---|---|
| Network | Throughput, errors, latency, drops, unusual egress volumes |
| Compute | CPU steal/ready time, saturation, runaway processes |
| Storage | IOPS, latency, queue depth, free space, snapshot growth |
| Response time | User/API SLOs that signal degradation before total outage |
| Hardware | Disk SMART failures, CPU errors, fan speed, temperature, PSU status |
Tie to security: Sudden CPU/network spikes may indicate crypto-mining malware or exfiltration. Disk growth may indicate ransomware encryption noise or log flooding. Alerts should route to operations and security triage when indicators match threat patterns.
Host and Guest Backup and Restore
Configure and test backup and restore for hosts (configuration, hypervisor state where applicable) and guest OS / workload data.
| Practice | Why |
|---|---|
| Policy by criticality | RPO/RTO-driven schedules |
| Isolation | Backups not freely deletable by the same ransomware identity that admin’s production |
| Encryption | Protect backup confidentiality |
| Integrity verification | Checksums; periodic restore tests |
| Image vs data-level | VM image backups vs application-consistent database backups—know both |
| Documentation | Who can restore, to where, and how to avoid restoring malware-infected images blindly |
Exam tip: Untested backups are not a control; restore tests prove capability.
Management Plane: Scheduling, Orchestration, Maintenance
Operations continue to run through the management plane:
| Function | Operational security concern |
|---|---|
| Scheduling | Who can schedule privileged jobs; prevent unauthorized batch crypto mining or data exports |
| Orchestration | Pipelines and orchestrators that can redeploy entire estates—protect credentials and approval gates |
| Maintenance | Coordinated patch windows, maintenance mode, capacity headroom so HA works during updates |
Keep management-plane software patched (5.1 build hygiene becomes 5.2 ongoing ops). Monitor orchestration API calls as high-value audit events.
Putting Domain 5.2 Together for the Exam
- Classify the stem: access, network config, network control, hardening, patching, availability, monitoring, backup, or management plane.
- Prefer defense in depth over a single gadget (for example, bastion + MFA + no public RDP).
- Link availability features to controlled admin rights and tested recovery.
- Apply shared responsibility: who patches the guest vs the fabric?
Common Traps
- Internet-exposed RDP/SSH “temporarily.”
- Security groups with allow-all and reliance only on a perimeter firewall.
- Baselines defined once and never monitored for drift.
- Patching hypervisors without maintenance mode / capacity planning.
- Backups stored in the same account with the same full-admin role as production.
Which administrative access design best aligns with Domain 5.2 for production cloud hosts?
A platform team must patch hypervisor hosts without dropping HA-protected VMs. Which operational practice is most appropriate?
Which pairing best describes OS hardening as used in Domain 5.2?
Network security groups, bastion hosts, IDS/IPS, and segmentation are present, but no one scans for missing patches or open services. Which outline control is most clearly missing?