SOC For Cloud Environments practice questions

VPC Service Controls

Why it fails: VPC Service Controls help mitigate data exfiltration, they do not collect logs.

Google Cloud Armor

Why it fails: Cloud Armor is a web application firewall, not a logging service.

Security Command Center

Why it fails: SCC is a security management platform, not the logging ingestion point for flow logs.

Update Azure Firewall rules

Why it fails: While Firewall works, NSGs are the granular, VM-level control for this scenario.

Delete the VM's public IP

Why it fails: Deleting the IP is disruptive and unnecessary if a rule can block the destination.

Disable the Virtual Network

Why it fails: Disabling the network would take the entire environment offline.

AWS Trusted Advisor S3 bucket permissions check

Why it fails: Trusted Advisor checks for overly permissive bucket policies and public access, but it does not log access events. It is a best-practice review tool, not an audit log source. It cannot tell you who accessed objects or when. For exfiltration investigation, you need access logs, not permission checks. Trusted Advisor is therefore not applicable here.

Amazon GuardDuty S3 protection findings

Why it fails: GuardDuty S3 protection generates findings for suspicious activity like unusual access patterns, but it does not provide raw logs of every object access. Findings are alerts, not detailed access records. While useful for detection, they cannot reconstruct the full sequence of exfiltration events. The analyst needs raw logs, not just findings, to trace the data access.

AWS Config configuration history

Why it fails: AWS Config records changes to resource configurations, such as bucket policies or ACLs, but it does not log object-level access or data retrieval. It can show if a bucket became public, but not who downloaded objects. For exfiltration, you need access logs, not configuration history. AWS Config is therefore not relevant to tracing data access.

VPC Flow Logs

Why it fails: VPC Flow Logs capture network traffic metadata for VM instances, which is useful for network anomaly detection, but they do not record IAM changes or resource configuration modifications. They help identify unusual traffic patterns, but for detecting IAM and configuration changes, you need audit logs that track API calls. Thus, they are not the priority for this specific scenario.

Cloud Audit Logs: System Event

Why it fails: System Event logs record actions performed by Google systems, such as live migration of VMs or automatic scaling. They are not initiated by users and do not reflect IAM or configuration changes made by administrators or attackers. They are useful for operational troubleshooting but not for detecting security incidents related to IAM or resource modifications.

Cloud Audit Logs: Data Access

Why it fails: Data Access logs record API calls that read or write user data, such as reading a Cloud Storage object. While valuable for detecting data exfiltration, they are not focused on IAM or resource configuration changes. They are often high-volume and require careful filtering. For detecting changes to IAM policies or resource configurations, Admin Activity logs are more directly relevant.

Azure Monitor activity log

Why it fails: Azure Monitor activity log is the same as the Azure Activity log; however, the term 'Azure Monitor activity log' is often used to refer to the platform logs in Azure Monitor. While it does contain the same data, the more precise and commonly used name for the log that records subscription-level events is 'Azure Activity log'. The distractor here is the naming, but the correct answer is the Azure Activity log itself. In some contexts, they are synonymous, but the exam may expect the specific term 'Azure Activity log'.

Microsoft Entra ID sign-in logs

Why it fails: Microsoft Entra ID sign-in logs record authentication events, such as user sign-ins and conditional access results. They do not record role assignments or other resource management operations. While a sign-in log might show that the user signed in before performing the action, it does not contain the details of the role assignment itself. The Activity log is required to see the actual operation and the caller's IP.

Microsoft Entra ID audit logs

Why it fails: Microsoft Entra ID audit logs track changes to Microsoft Entra ID objects such as users, groups, and applications, but role assignments for Azure resources (like subscription Owner) are recorded in the Azure Activity log, not Microsoft Entra ID audit logs. While Microsoft Entra ID audit logs may show role assignments for Microsoft Entra ID roles, they do not cover Azure RBAC role assignments for resources.

Azure Advisor

Why it fails: Azure Advisor only surfaces configuration and cost recommendations; it exposes no process-level telemetry from a VM's guest operating system. It is tempting because Advisor does flag security and reliability issues across subscriptions, which is the right tool for reviewing best-practise recommendations rather than investigating active miner processes.

Azure Network Watcher

Why it fails: Network Watcher captures traffic flows, connection monitors and packet captures at the network layer, revealing no process names or command lines inside the guest OS. It is tempting because it does help investigate suspicious outbound connections, which is the correct choice when the requirement is tracing network traffic rather than process execution.

Azure Resource Graph

Why it fails: Azure Resource Graph queries ARM resource metadata across subscriptions; it holds no guest-OS process telemetry, so it cannot show which processes ran on the VM. It is tempting because it rapidly inventories and audits Azure resources at scale, which is the right choice for questions about resource configuration, tagging or compliance posture rather than runtime activity.

VPC Flow Logs

Why it fails: GuardDuty's S3 Protection analyses CloudTrail S3 data events (GetObject, PutObject) to detect anomalous bucket access; VPC Flow Logs capture IP-level traffic metadata for EC2 and other interfaces, not S3 API calls. Flow Logs would be the right source for investigating suspicious network connections to instances.

EBS Snapshot logs

Why it fails: EBS snapshot logs are not a GuardDuty data source; snapshot activity relates to volume backup operations, not S3 object-level access patterns. Tempting because GuardDuty does analyse EBS volume behaviour, and would be relevant if the requirement were detecting anomalous activity on EC2 instance volumes.

Route 53 Resolver query logs

Why it fails: Route 53 Resolver query logs record DNS queries from VPC resources, not S3 data-plane API calls, so they cannot surface unusual bucket access. They are tempting because GuardDuty ingests them for DNS-based findings, and would be correct if the requirement were detecting queries to malicious domains.

Cloud Trace

Why it fails: Cloud Trace captures request latency and distributed tracing data, not IAM policy evaluation. It is tempting because it gives visibility into application behaviour, and would be correct when diagnosing slow requests or pinpointing latency bottlenecks across microservices.

Deployment Manager

Why it fails: Deployment Manager provisions infrastructure from declarative templates; it does not analyse granted permissions. It is tempting because it manages resource configuration as code, and would be correct when you need repeatable, templated deployment of GCP resources across projects.

Cloud Billing

Why it fails: Cloud Billing reports cost and usage attribution, not IAM permission analysis. It is tempting because it surfaces resource-level spend anomalies, and would be correct when you need to detect unexpected charges or attribute GCP costs to projects, labels or billing accounts.

Azure Policy Compliance dashboard

Why it fails: Azure Policy Compliance dashboard shows resource configuration against governance rules, not authentication telemetry. It is tempting because it aggregates security posture findings, and would be correct when auditing whether VMs meet organisational standards, not when tracing a specific sign-in's location and device risk.

Azure Monitor Metrics

Why it fails: Azure Monitor Metrics holds numeric time-series from resources, with no sign-in identity, geography or device risk data. It is tempting because it is the general portal destination for investigating anomalies, and would be correct for CPU, network or availability spikes rather than Microsoft Entra ID sign-in log analysis.

Azure Service Health

Why it fails: Azure Service Health reports platform incidents and planned maintenance affecting your subscriptions, not individual sign-in events. It is tempting because it is the portal location for service-level outages, and would be correct when investigating whether a widespread Azure incident explains authentication failures rather than a single suspicious login.

Remove the IAM Role

Why it fails: Removing the IAM role strips API permissions but leaves the instance's network interfaces and security groups intact, so the attacker retains network reachability. It is tempting because revoking credentials limits blast radius, and it is correct when containing credential abuse rather than network isolation is the goal.

Disable the VPC

Why it fails: A VPC cannot be disabled; it spans many resources, so this neither isolates the instance nor preserves its volume, and it would disrupt unrelated workloads. It is tempting because network-level containment sounds thorough, and it is correct only when retiring an entire isolated environment.

Terminate the instance

Why it fails: Termination destroys the instance and, by default, its root EBS volume, contradicting the requirement to preserve the volume for forensics. It is tempting because termination immediately stops the workload, and it is correct when the instance is disposable and no evidence retention is needed.

Azure Front Door

Why it fails: Azure Front Door is a global layer-7 load balancer and CDN with WAF capabilities at the edge; it filters inbound HTTP traffic rather than auditing or denying non-compliant resource configurations. It would be correct for routing and accelerating web applications, not for enforcing settings on resources.

Azure Bastion

Why it fails: Azure Bastion provides RDP and SSH connectivity to virtual machines through the portal over TLS, removing public IP exposure; it brokers administrative sessions and never evaluates resource configuration. It is the right choice for secure VM access, not for automatically enforcing security settings across resources.

Azure Key Vault

Why it fails: Azure Key Vault stores and controls access to secrets, keys and certificates; it does not evaluate resource configurations or block non-compliant changes. It is the right choice when centralising secret management, but enforcement of security settings requires Azure Policy definitions and assignments.

AWS Systems Manager

Why it fails: Systems Manager manages instances, patches and automation; it holds no API audit trail of IAM role usage. It is tempting because it is an AWS operations and security-adjacent service, but CloudTrail is the service that logs the specific API call and source IP address for the investigation.

AWS Config

Why it fails: AWS Config records resource configuration changes and compliance state, not individual API calls or source IPs; CloudTrail supplies that audit detail. It is tempting because Config tracks IAM role changes over time, and it would be the right choice when you need a resource's configuration history rather than who invoked what from where.

Amazon GuardDuty

Why it fails: GuardDuty produces threat findings from logs such as CloudTrail, VPC Flow Logs and DNS, but it does not let you query the raw API call and source IP directly. It is tempting because it detects anomalous IAM activity, yet CloudTrail records the specific API call and source IP.

AWS Artifact

Why it fails: AWS Artifact supplies compliance reports and agreements such as SOC and ISO documents; it performs no configuration scanning at all. It is tempting because it is security and compliance related, and it would be correct when an auditor requests evidence of AWS's own control certifications.

AWS Shield

Why it fails: AWS Shield provides DDoS protection at the network and application layers; it does not inventory or report misconfigured resources. It is tempting because it is a security service, and it would be the right choice when defending an internet-facing workload against volumetric or application-layer denial-of-service attacks.

AWS Trusted Advisor

Why it fails: Trusted Advisor inspects cost, performance, and service limits alongside some security checks, but it is not the centralised organisation-wide misconfiguration dashboard. It is tempting because it does surface security recommendations, and it would be the right choice when seeking broad best-practise guidance across an account.

Automatic patching of guest OS kernels

Why it fails: Kernel patching is performed by the guest OS update mechanism or the platform's patching service, not by log ingestion. A SIEM ingests and correlates events; it cannot reach into virtual machines to apply patches. It would be correct for alerting on missing-patch findings reported by a vulnerability scanner.

Automated creation of new cloud accounts

Why it fails: SIEM correlation and alerting consume cloud-native logs; they do not provision identities or subscriptions. Account creation belongs to cloud provisioning tooling or Microsoft Entra ID lifecycle workflows. A SIEM would be the right choice for detecting suspicious account-creation events, not performing the creation itself.

Cloud Asset Inventory

Why it fails: Cloud Asset Inventory records resource configuration and metadata history, not per-object access events, so it cannot name the files read from the bucket. It is the right tool for auditing resource inventory changes or policy drift, not for reconstructing which objects a principal accessed during an exfiltration event.

Cloud Monitoring metrics

Why it fails: Cloud Monitoring metrics are numeric time series such as request counts and bytes, carrying no object names, so they cannot identify which files were accessed. Metrics suit alerting on anomalous egress volume; reconstructing specific object reads requires Data Access audit logs for Cloud Storage.

Cloud Load Balancing logs

Why it fails: Cloud Load Balancing logs capture HTTP(S) requests handled by proxies and backends, not direct Cloud Storage object operations, so bucket file names never appear. They are the correct source for diagnosing frontend latency or backend health, not for tracing object-level access during exfiltration.

Disable SNS notifications

Why it fails: Notifications are critical for timely incident response.

Limit logs to one region

Why it fails: Limiting to one region ignores threats in other regions.

Encrypt logs with a public key

Why it fails: Logs should be encrypted with KMS, not a public key.

Resource Provisioning

Why it fails: Resource provisioning is a deployment and scaling activity, not an incident response component; cloud-native response instead relies on identity isolation, snapshotting and log preservation. It is tempting because provisioning is central to cloud operations, and would be correct when designing auto-scaling or infrastructure-as-code pipelines rather than a response plan.

Budget Optimization

Why it fails: Budget optimisation addresses cost governance, not containment, eradication or recovery of a cloud incident. It is tempting because cloud-native plans do reference cost controls, and would be correct when the scenario asks about FinOps or spend management rather than incident response components.

Hardware Refresh

Why it fails: Hardware refresh concerns physical infrastructure, which cloud-native response plans do not manage; the cloud provider handles host replacement. It is tempting because on-premises incident response often includes hardware replacement after compromise, making it the correct choice only for traditional data-centre environments, not cloud-native plans.

Increased usage of free-tier services

Why it fails: Free-tier consumption is normal baseline behaviour and generates heavy false positives, so it is not a reliable compromise indicator. It tempts because attackers do spin up resources, but monitoring should target anomalous API calls, new credentials, and disabled logging instead.

Standard scheduled system reboots

Why it fails: Scheduled reboots are routine maintenance activity and reveal nothing about account compromise. It tempts because unexpected restarts can accompany intrusion, but SOC monitoring should focus on anomalous API activity, credential creation, and configuration changes, not planned reboot windows.

Upgrade the VM's OS image

Why it fails: Upgrading the OS image patches the guest but leaves the rogue instance running, reachable and still under attacker control. Image upgrades address vulnerability remediation on sanctioned systems; containment of an unauthorised VM demands isolation or termination, not a version change.

Increase the VM's CPU quota

Why it fails: Raising CPU quota grants the rogue VM more compute resources, worsening the exposure rather than containing it. Quota adjustments belong to legitimate capacity planning for approved workloads, so this would only be the right action when a sanctioned instance is genuinely starved of vCPU.

Delete the VM immediately

Why it fails: Deleting destroys evidence before it can be analyzed.

Microsoft Defender for Cloud Apps activity log

Why it fails: Defender for Cloud Apps logs SaaS app activities but does not capture Exchange Online mailbox rule creation events; those are recorded in the Unified Audit Log. The activity log focuses on file sharing, admin actions within connected apps, and session policies, so it would not surface the New-InboxRule operation needed here.

Microsoft 365 Defender incidents queue

Why it fails: The incidents queue aggregates correlated alerts from multiple Defender workloads, but it is not a raw evidence store for mailbox rule operations. It may show a related alert, yet it will not provide the specific New-InboxRule audit record with its parameters that the analyst needs to confirm the forwarding rule.

Microsoft Entra ID sign-in logs

Why it fails: Microsoft Entra ID sign-in logs capture authentication events such as successful logins, MFA challenges, and risky sign-ins. They do not contain mailbox rule creation or forwarding configuration details, so they cannot show whether an inbox rule was added to forward mail externally after the account compromise.