AWS SysOps Administrator common mistakes
AWS SysOps Administrator · Understand the traps and how to avoid them.
Creating a CloudWatch alarm on memory utilization or disk-space-used for an EC2 instance and expecting it to fire, without ever installing the CloudWatch agent.
Candidates assume CloudWatch 'just knows' guest-OS metrics because CPU and network graphs appear automatically. The default EC2 namespace is fed by the hypervisor and only contains CPUUtilization, NetworkIn/Out, DiskReadOps/WriteOps, and status checks - nothing from inside the operating system.
What to do instead
Memorize the split: hypervisor metrics are free and automatic; memory, swap, disk-space-used, and process-level metrics require the CloudWatch agent on the instance with an IAM role attached (CloudWatchAgentServerPolicy), configured via a JSON/Parameter Store config file. On-premises servers need credentials or an IAM role via the agent's on-premises installer instead.
Configuring an alarm with a 1-minute period on EC2 CPUUtilization and expecting sub-5-minute detection, then being surprised the alarm evaluates coarsely.
Basic monitoring publishes every 5 minutes, so a 1-minute period has no data points to evaluate. Candidates conflate alarm 'period' with metric resolution and pick period values the metric cannot support.
What to do instead
Enable detailed monitoring (1-minute metrics, additional cost) whenever the scenario demands fast reaction, and match the alarm period to the metric's resolution. Remember that high-resolution custom metrics support 10- and 30-second periods, but standard AWS metrics do not; also consider CloudWatch agent metrics or composite alarms for reducing alarm noise.
Selecting an RDS read replica as the high-availability/failover answer when the requirement is automatic failover with minimal RPO for a single primary database.
Both features involve a second copy of the data, so the options look interchangeable. Candidates forget replication semantics: Multi-AZ is synchronous with an automatic DNS-based failover to a standby that serves no reads, while read replicas are asynchronous, readable, and promote only manually.
What to do instead
Map requirement to mechanism: automatic failover + same endpoint + zero data loss => Multi-AZ (standby is not readable, cannot be used for read scaling); read scaling or cross-region DR => read replicas (asynchronous, manual promotion, different endpoint). If both read scaling and HA are needed, deploy Multi-AZ plus read replicas.
Proposing S3 Cross-Region Replication as the protection against an operator or attacker deleting objects, or as the sole backup strategy.
CRR is described as a durability/DR feature, so it reads like a backup. In reality replication is ongoing and delete markers replicate to the destination bucket by default, so deletions propagate; and a bad overwrite replicates too.
What to do instead
For deletion/ransomware protection layer versioning with MFA delete, S3 Object Lock (WORM) in compliance mode, and a separate backup via AWS Backup or a replicated bucket with a different lifecycle and restricted principals. Turn on DeleteMarkerReplication: Disabled only if you deliberately want the destination to retain objects the source deleted.
Using DeletionPolicy: Retain to keep an object-stored resource when a stack update replaces it, then finding the old resource was deleted anyway.
The two policies have similar names and syntax. Candidates do not distinguish 'stack deleted' from 'resource replaced during update', so they apply the wrong attribute.
What to do instead
DeletionPolicy governs delete-stack and resource removal; UpdateReplacePolicy governs the old resource when an update requires replacement (new logical resource created). Set both to Retain when the data must survive either event, and note that Snapshot is supported only for certain resource types such as RDS, EBS, Redshift, and Neptune.
Attempting to delete or change a CloudFormation output value that another stack imports, and choosing this as the 'safe way to share resources between stacks'.
Cross-stack exports seem like clean modularization, so the operational coupling is overlooked: an exported output is locked while any stack imports it.
What to do instead
Know the constraint - you cannot delete or modify an export that is in use, and the consumer stack must remove the import first. For shared infrastructure that changes often, prefer nested stacks (parent/child) or publish values to SSM Parameter Store and resolve them with dynamic references; reserve cross-stack exports for stable, rarely changing values.
Granting kms:Decrypt to a role in an IAM identity policy and concluding an application can now use the CMK, without touching the key policy.
IAM is treated as the universal authorization layer everywhere else in AWS, so the KMS exception is missed. KMS access is controlled primarily by the key policy, and IAM policies only take effect if the key policy delegates to IAM for that account.
What to do instead
Check the key policy first: the standard pattern is a statement granting kms:* to the account principal (arn:aws:iam::ACCOUNT:root), which enables IAM policies within the account to govern access. For cross-account use, the key policy must name the external principal and that account must also grant permission; for AWS services (S3, EBS, CloudWatch Logs) use a key policy with the service principal and the required encryption context conditions.
Enabling cross-account access to an S3 bucket by adding only a bucket policy (or only an IAM policy in the other account) and declaring the task complete.
Candidates treat S3 authorization as a single switch. For cross-account requests, both the resource-based policy and the caller's identity-based policy must allow the action - unless the caller assumes a role in the bucket-owning account.
What to do instead
Verify both sides: the bucket policy must grant the external account/principal the needed actions (plus objects/* where relevant, and the bucket owner must still own objects if applicable), and the caller's IAM policy must allow s3:GetObject/PutObject. Also confirm no SCP, bucket policy explicit deny, Block Public Access setting, or VPC endpoint policy overrides the allow.
Writing a network ACL that permits inbound HTTPS (443) but omits outbound ephemeral ports, then concluding the subnet or security group is misconfigured when the client gets no response.
Security groups are stateful so return traffic is automatic; candidates carry that mental model to NACLs, which are stateless and evaluate each direction independently.
What to do instead
Remember: security groups are stateful, allow-only, and evaluated as a union; NACLs are stateless, support allow and deny, and are evaluated in rule-number order. For any NACL permitting client traffic, also permit the return path: inbound and outbound on ports 1024–65535 (plus 443/80 as needed). Test with VPC Reachability Analyzer rather than guessing.
Designing a lifecycle policy that moves active objects to S3 Standard-IA or Glacier for cost savings, ignoring minimum storage durations and retrieval pricing.
The per-GB storage price is the only number candidates compare, so the cost model of infrequent-access tiers looks strictly cheaper. The transition rules are also easy to read as free.
What to do instead
Model the full economics before transitioning: Standard-IA and One Zone-IA bill a 30-day minimum and per-GB retrieval, Glacier Flexible Retrieval a 90-day minimum plus retrieval and request costs, and transitions themselves are charged per request. Keep hot data in Standard, use lifecycle transitions with realistic day thresholds, and add Intelligent-Tiering when access patterns are unknown; check the S3 Storage Lens or Cost Explorer data to validate the assumption.