Validates skills in AWS cloud operations, monitoring, deployment automation, and networking. Ideal for CloudOps and DevOps engineers.
Amazon CloudWatch Metrics, Alarms & Dashboards, AWS CloudTrail, Amazon EventBridge, AWS Systems Manager Automation, Amazon EBS, S3 & EFS Performance Optimization, Amazon RDS Performance Insights, EC2 Placement Groups
Auto Scaling Groups & Scaling Policies, Elastic Load Balancing & Health Checks, Amazon CloudFront & ElastiCache Caching, Multi-AZ Fault-Tolerant Design, AWS Backup & Snapshot Automation, RTO & RPO Recovery Strategies, Amazon S3 & FSx Versioning
AWS CloudFormation & StackSets, AWS CDK, Amazon EC2 Image Builder, AWS Systems Manager, AWS RAM Cross-Account Resource Sharing, AWS Lambda Event-Driven Automation, Terraform & Git
IAM Policies, MFA & Federation, AWS CloudTrail & IAM Access Analyzer, AWS KMS Encryption at Rest, AWS Certificate Manager Encryption in Transit, AWS Security Hub & Amazon GuardDuty, AWS Config & Amazon Inspector, AWS Trusted Advisor Security Checks
VPC Subnets, Routing, Security Groups & ACLs, Amazon Route 53 Routing Policies & DNS, Amazon CloudFront & AWS Global Accelerator, AWS WAF, Shield & Network Firewall, VPC Flow Logs & ELB Access Logs, Transit Gateway & VPC Peering, NAT Gateway & Internet Gateway
Try real exam-style questions from the free sample set. Each answer comes with a full explanation.
A research institution wants to run HPC (High-Performance Computing) workloads on AWS that require ultra-low latency communication between thousands of nodes.
What EC2 instance placement strategy is most appropriate to minimize network latency?
Answer: B. Cluster Placement Group
A research institution needs to run HPC workloads on AWS requiring ultra-low latency communication between thousands of nodes while minimizing network latency. Cluster Placement Group is a strategy that concentrates instances in physically the closest locations within a single Availability Zone, achieving network bandwidth of 10 Gbps or more and microsecond-level latency between instances. Since inter-node communication speed is the key factor determining overall workload performance in HPC, Cluster Placement Group, which guarantees physical proximity, precisely meets the requirements of this scenario.
EC2 placement groups come in three types: Cluster, Spread, and Partition. Cluster targets ultra-low latency and high bandwidth through physical proximity placement, Spread targets high availability and fault tolerance through distributed physical hardware placement, and Partition targets fault domain isolation for large-scale distributed databases through logical partition isolation. Cluster Placement Group combined with EFA (Elastic Fabric Adapter) bypasses the OS network stack to provide optimal performance for MPI-based HPC workloads.
In exam questions where 'ultra-low latency', 'HPC', 'MPI', or 'minimize inter-node communication' are conditions, Cluster Placement Group is the correct answer. Linking Spread with 'high availability' and 'hardware fault isolation' keywords, and Partition with 'Hadoop', 'Kafka', and 'large-scale distributed DB' keywords can help avoid confusion.
A SysOps engineer at a company is inspecting infrastructure deployed with CloudFormation and suspects that some resources have been manually changed in the console.
Which is the MOST appropriate way to identify differences between the state defined in the IaC template and the current state of the resources actually running?
Answer: C. CloudFormation Drift Detection
A SysOps engineer needs to verify whether some resources in CloudFormation-deployed infrastructure have been manually changed through the console. CloudFormation Drift Detection directly compares the expected configuration declared in the IaC template with the actual configuration of currently running resources, precisely matching the core requirement of this scenario. When drift detection runs, it provides a detailed report showing the differences between expected and actual values for each resource property.
CloudFormation Drift Detection can be run at the stack level or individual resource level, classifying each resource's drift status into four categories: IN_SYNC, MODIFIED, DELETED, and NOT_CHECKED. For MODIFIED resources, expected and actual property values are displayed side by side, making it possible to identify exactly which properties were changed and how. This feature is available at no additional cost through the CloudFormation console or API.
For exam questions about CloudFormation change detection, you need to distinguish tools by purpose. Template-defined state vs actual resource state comparison → Drift Detection, checking who changed what and when → CloudTrail, continuously evaluating whether resource configurations comply with internal policies → AWS Config.
A company application sends historical performance data to CloudWatch as custom metrics through batch processing.
However, some data containing past timestamps is not being properly reflected in CloudWatch. When the CloudOps engineer analyzes the cause of this issue, which is the MOST likely cause related to the timestamp acceptance range of CloudWatch Custom Metrics?
Which option BEST explains the cause of this issue?
Answer: B. Timestamp Exceeds Past 2 Weeks
The MOST important condition in this scenario is the selective omission pattern — 'only some past timestamp data is not being reflected.' CloudWatch Custom Metrics process data with timestamps older than 2 weeks (14 days) from the current time using a silent drop approach: PutMetricData API calls return a success response, but the data is not actually stored. When batch processing retroactively registers old historical data and hits this limit, data is silently dropped without any API error, making it difficult to immediately identify the issue.
The timestamp acceptance range for CloudWatch Custom Metrics is past 2 weeks (14 days) to future 2 hours. Timestamps outside this range result in successful API calls but data that is not reflected in the metrics. This limitation stems from CloudWatch's internal data aggregation and rollup structure and retention policy. When you need to retroactively register data older than 2 weeks, it is recommended to use separate analysis tools such as CloudWatch Logs Insights or S3+Athena.
On the exam, CloudWatch timestamp questions test your ability to distinguish root causes by the difference between 'partial omission' and 'total failure.' If only some data is selectively missing, the cause is exceeding the timestamp acceptance range; if all calls consistently fail, the cause is insufficient IAM permissions (PutMetricData not granted). You must memorize the specific numbers: past 2 weeks and future 2 hours.
A startup is hosting a static website on S3 and distributing content through CloudFront. When users access the CloudFront URL, they receive a 403 error.
What is the most likely cause of this issue?
Answer: A. S3 Bucket Policy (OAC not configured)
In a scenario where a startup connected CloudFront to an S3 static website but receives a 403 error, 403 indicates access permission denial. If S3 has public access blocked and CloudFront has no Origin Access Control (OAC) configured, CloudFront has no permission to read S3 objects and returns 403. The missing OAC permission entry in the S3 bucket policy is the direct cause of the 403 error.
To correctly configure OAC, the S3 bucket policy needs an s3:GetObject allow statement specifying the service principal (cloudfront.amazonaws.com) as the Principal and the specific CloudFront distribution ARN in aws:SourceArn as the Condition. Without this policy, even when CloudFront forwards requests to S3, S3 treats them as unauthorized and responds with 403.
Cache expiry policies relate to stale content display or cache misses, while Route 53 errors cause DNS resolution failures preventing connection altogether. CloudFront Distribution being disabled means the distribution itself doesn't respond, which is different from the permission denial indicated by 403.
A security team is reviewing a specific IAM policy. The policy contains a Statement that Allows GetObject on all S3 buckets, and another Statement that Denies GetObject on a specific bucket.
If a user with this policy attempts to access an object in that specific bucket, what will be the result?
Answer: B. Deny (explicit Deny takes priority)
In AWS IAM policy evaluation, an explicit Deny always takes priority over any Allow within the same scope. In this question, a GetObject Allow Statement for all S3 buckets and a GetObject Deny Statement for a specific bucket coexist in the same policy, so access to that specific bucket is blocked by the Deny taking priority.
The IAM policy evaluation order first collects all applicable policies (identity-based, resource-based, SCPs, etc.), and if any explicit Deny exists among them, the request is immediately denied. If there is an explicit Allow and no Deny, access is permitted; if neither exists, an implicit deny is applied by default. This hierarchical evaluation logic applies equally within the same policy.
On the exam, when Allow and Deny conflict on the same resource, Deny unconditionally takes priority. SCPs and Permission Boundaries apply the same explicit Deny priority principle, so this rule is consistently applied across all of IAM.
The AWS CloudOps Engineer - Associate (SOA-C03) exam consists of 65 questions with a 130-minute time limit.
The passing score for the SOA-C03 exam is 720 out of 1000.
The SOA-C03 sample set (20 questions with full explanations) is free. The full bank of 340+ questions is available with a CloudMasterIT subscription.
The SOA-C03 certification is valid for 3 years after passing. Recertification is required after that.