AWS SysOps Security and Compliance: 79 practice questions

12 of the 79 Security and Compliance questions in the Certsqill AWS SysOps bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AWS SysOps? Take the free 5-min readiness check →

1. Access is denied: What is the result when the user attempts to access the bucket?

1. Access is allowed, because identity-based policies are evaluated with precedence over the resource-based bucket policy here

   There is no precedence between identity-based and resource-based policies. An explicit Deny from any source wins regardless of policy type.
2. Access depends on whether the user had MFA active at the exact moment the object read request was made

   MFA would need to be an explicit condition key in the policy. There is no automatic MFA override of a Deny statement.
3. Access is denied, because an explicit Deny in any applicable policy always overrides an Allow from any other source ✓

   In IAM policy evaluation, an explicit Deny in any applicable policy (identity-based, resource-based, SCP, permission boundary) always overrides any Allow. The bucket policy's explicit Deny supersedes the identity policy's Allow.
4. Access is allowed, because the Allow granted in the user's identity-based policy is enough to satisfy the request

   An Allow in an identity-based policy is insufficient when a resource-based policy has an explicit Deny. The Deny is evaluated and terminates the decision.

Explicit Deny in any policy always overrides any Allow — this is the first principle of AWS IAM evaluation; no other policy can override an explicit Deny.

2. No — KMS keys need explicit authorization in the key: Can the user decrypt?

1. No — using any KMS key always requires a cross-account grant, so a same-account IAM allow can never by itself authorize the decrypt call

   This is incorrect; same-account access is possible but still requires explicit key policy authorization. Cross-account access is not required.
2. Yes — any IAM user in the same account may use any KMS key in that account once their own IAM policy allows kms:Decrypt on it

   Same-account IAM users do not automatically have access to KMS keys. Explicit authorization in the key policy, or a grant, is required.
3. Yes — the Allow in the IAM identity policy grants kms:Decrypt and supersedes whatever the key policy specifies for that key

   For KMS, the key policy is the primary control. IAM policies work only when the key policy enables IAM (by allowing the account root or delegating). IAM alone is insufficient.
4. No — KMS keys need explicit authorization in the key policy; an IAM allow alone is insufficient when the key policy does not enable IAM ✓

   Unlike most AWS resources, KMS keys use a unique model: the key policy must explicitly allow IAM to control access (via the account root principal statement). Without it, IAM identity-based policies cannot grant KMS access.

KMS key policies are resource-based policies that must explicitly authorize access; IAM policies cannot grant KMS access unless the key policy includes a statement enabling IAM delegation.

3. No — SCPs apply to every principal in the account: Can the root user terminate instances?

1. No — SCPs apply to every principal in the account, including the root user, who therefore cannot bypass an SCP ✓

   SCPs are organizational guardrails that cap the maximum permissions in an account, including the root user. Unlike IAM policies, which do not apply to root, SCPs do restrict the root user when attached to an OU or account.
2. Yes — the account root user always retains full permissions and cannot be constrained by any Service Control Policy

   This is a critical misconception. Within AWS Organizations, SCPs restrict all principals including the root user. Root's full permissions apply only when no SCP restricts the account.
3. No — but the account root user can open a case with AWS Support to have this SCP restriction overridden

   AWS Support cannot override SCPs at an account root user's request. SCPs are managed by the organization's management account and changed only by the organization administrator.
4. Yes — SCPs apply only to the IAM users and roles in the account and never to the account root user itself

   SCPs apply to all IAM entities in the account including the root user. Restricting even root access is a key feature of AWS Organizations.

SCPs restrict ALL principals in a member account including the root user — this is a key distinction from IAM policies, which cannot restrict root user actions.

4. AWS Security Hub with cross-account and cross-Region: Which service aggregates these findings?

1. AWS Config with an aggregator collecting data from all accounts

   AWS Config aggregators consolidate Config compliance data (Config rules) but do not aggregate findings from GuardDuty, Inspector, or IAM Access Analyzer.
2. AWS Security Hub with cross-account and cross-Region aggregation enabled ✓

   Security Hub aggregates findings from native AWS security services (GuardDuty, Config, Inspector, IAM Access Analyzer, Macie) and third-party tools using the AWS Security Finding Format (ASFF). Cross-account aggregation (via Organizations) and cross-Region aggregation provide a unified view.
3. Amazon EventBridge event bus aggregating findings from all services to a central account

   EventBridge can route events between accounts and aggregate them, but it requires custom Lambda or automation to normalize and display findings. Security Hub provides this out-of-the-box.
4. Amazon CloudWatch Dashboards with widgets from each security service

   CloudWatch Dashboards display metrics and alarms but do not aggregate security findings in a normalized format. They lack the security finding context and prioritization that Security Hub provides.

Security Hub aggregates findings from AWS security services (GuardDuty, Config, Inspector, IAM Access Analyzer) into a unified ASFF-normalized dashboard with cross-account and cross-Region support.

5. Immediately disable the IAM user's access key and console: Which action should the SysOps administrator take F

1. Archive the GuardDuty finding right away, since geographic detections tend to produce a high number of false positives

   Archiving without investigation is irresponsible for a credential-compromise finding. Geographic anomalies can be false positives (VPN, travel) but should be verified with the user first.
2. Increase the GuardDuty detector sensitivity for this finding type so that similar geographic false positives stop appearing

   GuardDuty has no sensitivity tuning setting. Findings can be suppressed with suppression rules, but only after investigation confirms a false-positive pattern.
3. Immediately disable the IAM user's access key and console password, then investigate the activity from the flagged location ✓

   A console login from an unusual location may indicate compromised credentials. The first action is containment (disabling the credentials) to prevent damage, followed by investigation to determine whether the access was legitimate.
4. Enable GuardDuty Malware Protection to scan the EC2 instances that are associated with this IAM user's recent activity

   Malware Protection scans EC2 instance volumes and does not address compromised IAM credentials. This finding concerns IAM console access, not instance malware.

Compromised credential findings require immediate containment (disable credentials) followed by investigation — containment before investigation is the correct incident response order.

6. Associate an AWS WAF web ACL with the ALB using the AWS: Which solution provides immediate protection?

1. Configure ALB access logs plus a Lambda function that parses them to detect and block the source IPs sending malicious requests

   This reactive approach analyzes logs after requests are processed. WAF blocks attacks in real time before they reach the application; log analysis cannot block in-flight requests.
2. Enable AWS Shield Advanced on the ALB so that it inspects and then blocks the application-layer SQL injection and XSS attempts

   AWS Shield Advanced protects against DDoS attacks. SQL injection and XSS are application-layer vulnerabilities, not DDoS. WAF is the correct service.
3. Use Amazon CloudFront custom error responses to return a 403 whenever a request matches a known attack pattern

   CloudFront custom error responses return static error pages and do not inspect request content for attack patterns. WAF can attach to CloudFront to detect and block them.
4. Associate an AWS WAF web ACL with the ALB using the AWS Managed Rules Common Rule Set to block the SQL injection and XSS ✓

   AWS Managed Rules are pre-built WAF rule groups maintained by AWS that cover common threats including the OWASP Top 10. The AWSManagedRulesCommonRuleSet provides immediate SQL injection and XSS protection without custom rules.

AWS Managed Rules for Common Vulnerabilities (AWSManagedRulesCommonRuleSet) provide immediate WAF protection against OWASP Top 10 attacks including SQL injection and XSS without custom rule development.

7. Amazon Inspector v2 with continuous scanning enabled: Which service provides continuous, automated vulnerabili

1. Amazon Inspector v2 with continuous scanning enabled for both EC2 instances and ECR container images to detect CVEs ✓

   Amazon Inspector v2 provides continuous vulnerability scanning for EC2 (via SSM Agent) and ECR images (on push and re-scanned as new CVEs are published). No scheduling is required; results update automatically.
2. Amazon Macie configured to scan EC2 instance volumes for sensitive content patterns and known software vulnerabilities

   Amazon Macie scans S3 buckets for sensitive data such as PII and credentials. It does not perform CVE vulnerability scanning of EC2 instances or container images.
3. AWS Systems Manager Patch Manager running a daily scan operation to find software CVE vulnerabilities on the instances

   Patch Manager checks for missing OS patches against an approved baseline. It does not scan applications, container images, or libraries for software CVEs.
4. AWS Trusted Advisor Security category checks that flag CVE-level software vulnerabilities across the EC2 fleet

   Trusted Advisor provides high-level security best-practice checks (open security groups, root MFA) but not CVE-level scanning of software packages.

Inspector v2 provides continuous, automated CVE scanning for EC2 instances (via SSM Agent) and ECR images (on push + re-scan on new CVEs) — no scheduling required.

8. Customer managed keys offering manual or automatic: Which KMS key type satisfies all three requirements?

1. External key store (XKS) keys held in an on-premises HSM, which on their own provide the rotation, audit, and disable controls

   XKS uses keys from an external HSM but adds significant complexity. The standard KMS answer is a customer managed key, which meets all requirements without XKS.
2. Customer managed keys (CMKs) offering manual or automatic rotation, CloudTrail logging of usage, and instant key disable ✓

   Customer managed keys give full control: a configurable automatic (annual) or on-demand manual rotation schedule, all key operations logged in CloudTrail, and the ability to disable the key instantly to block all use.
3. AWS managed keys such as aws/s3 and aws/rds, relying on their built-in annual rotation, logging, and disable options

   AWS managed keys rotate annually and cannot be configured, disabled, or have their policies modified by the customer, so they do not meet the rotation-control or disable requirements.
4. AWS owned keys used for default service encryption, which expose their rotation schedule, usage logs, and a disable control

   AWS owned keys are fully managed by AWS; customers cannot view, audit, rotate, or disable them, providing no control or audit capability.

Customer managed keys (CMKs) provide configurable rotation, CloudTrail auditing of all key usage, and the ability to immediately disable the key — satisfying all three compliance requirements.

9. Require developers to attach a permission boundary when: Which IAM mechanism prevents privilege escalation in

1. Grant developers an IAM policy that permits iam:CreateRole only for a set of approved role name prefixes, controlling escalation through naming conventions

   Restricting role name patterns prevents creating roles with specific names but does not prevent attaching overly permissive policies to allowed role names. The developer could still create a role with the AdministratorAccess policy attached, so naming controls do not stop privilege escalation.
2. Use AWS Organizations SCPs to restrict iam:CreateRole so that only the Organizations management account is allowed to create IAM roles

   Restricting iam:CreateRole to the management account would prevent developers from creating roles at all, breaking their workflow. Permission boundaries allow role creation while still preventing privilege escalation, which is what the scenario needs.
3. Require developers to attach a permission boundary when creating IAM roles, limiting the role's effective permissions to the boundary's scope ✓

   Permission boundaries set the maximum permissions an IAM entity can have. By requiring developers to attach a permission boundary when creating roles, the company ensures that the created roles cannot have permissions exceeding the boundary — preventing privilege escalation even if the developer creates a very permissive role.
4. Enable the AWS Config managed rule iam-no-inline-policies to block inline policy attachment and force the use of vetted managed policies only

   Preventing inline policies doesn't stop privilege escalation — managed policies can still be attached with excessive permissions such as AdministratorAccess. Permission boundaries are the correct mechanism because they cap effective permissions regardless of policy type.

Permission boundaries cap the maximum permissions of IAM roles/users; requiring developers to attach a predefined boundary when creating roles prevents them from granting permissions beyond what the boundary allows.

10. Amazon Macie — performs automated sensitive data discovery: Which AWS service provides automated PII detection

1. Amazon Comprehend with S3 Event Notifications triggering content analysis

   Amazon Comprehend can detect PII in text content, but it requires custom pipeline development (Lambda + S3 events + Comprehend API calls). Macie provides this natively as a managed service with S3 integration.
2. Amazon GuardDuty — detects unusual data access patterns in S3 indicating potential PII exfiltration

   GuardDuty detects unusual behavior (anomalous API calls, account compromise) but does not classify the content of S3 objects as PII. Macie classifies S3 object content.
3. AWS Config with a custom rule that scans S3 bucket metadata for PII indicators

   Config tracks resource configuration changes but does not inspect the content of S3 objects for sensitive data patterns. Macie inspects actual object content.
4. Amazon Macie — performs automated sensitive data discovery across S3 buckets ✓

   Amazon Macie uses machine learning to automatically discover and classify sensitive data in S3, including PII (names, email, phone, SSN), financial data (credit cards, bank accounts), and credentials. It provides findings with location details and severity.

Amazon Macie uses ML to automatically classify S3 object content and identify PII, financial data, and credentials — it's the purpose-built managed service for S3 sensitive data discovery.

11. Create an organization trail in the management account: Which approach achieves this?

1. Create an organization trail in the management account that logs to an S3 bucket in the security account, using a bucket policy to stop member accounts modifying it ✓

   Organization trails created in the management account automatically apply to all current and future member accounts. The S3 bucket policy in the security account grants only the CloudTrail service write access, preventing member accounts from modifying the logs or trail configuration.
2. Create a separate CloudTrail trail in every member account, each configured to point at the same central S3 bucket in the security account for fully consolidated logging

   Member accounts could modify or delete their own trails, breaking the tamper-resistance requirement. Organization trails created in the management account cannot be modified by member accounts — providing the guarantee this design needs.
3. Configure individual CloudTrail trails in each member account and use S3 cross-region replication to copy all of their log files into the security account bucket

   Individual trails require creating and maintaining 50 separate trails, and S3 replication adds operational complexity. Organization trails handle multi-account logging automatically, and member accounts cannot disable them, making this option unnecessarily fragile.
4. Use AWS Config aggregators in the security account to collect and centralize the CloudTrail API activity data gathered from all fifty organization member accounts

   Config aggregators collect AWS Config data (configuration and compliance state), not CloudTrail API activity logs. Organization trails are the CloudTrail-native mechanism for centralized, tamper-resistant multi-account API logging.

Organization trails created in the management account apply to all member accounts automatically and cannot be modified by those accounts — S3 bucket policy prevents member accounts from accessing the log bucket.

12. Attach an IAM role to the EC2 instance through an instance: What is the recommended replacement?

1. Move the access keys into AWS Systems Manager Parameter Store as a SecureString and have the application retrieve and decrypt them at container runtime

   Storing access keys in Parameter Store is better than plaintext config files but still relies on long-lived credentials. IAM instance roles provide automatically rotating temporary credentials — a fundamentally better approach that removes the static keys entirely.
2. Attach an IAM role to the EC2 instance through an instance profile so the application obtains temporary rotating credentials from the metadata service ✓

   IAM roles attached via instance profiles provide temporary, automatically rotating credentials through the EC2 metadata service (IMDS). The application does not need stored credentials — the AWS SDK automatically retrieves temporary credentials from the metadata service.
3. Create a new IAM user with minimal least-privilege permissions and store that user's long-lived access keys in the instance config file

   Replacing with a new IAM user still uses long-lived static credentials stored on the instance — the same security anti-pattern the security team flagged. IAM roles are the correct replacement because they avoid stored long-term keys.
4. Encrypt the access keys with an AWS KMS customer managed key and store the encrypted ciphertext in the application's config file

   Encrypting stored access keys improves security slightly but still requires the keys to reside on the instance. They can be compromised if the instance is breached or the config file is accidentally exposed, whereas IAM roles avoid stored secrets entirely.

IAM instance roles provide auto-rotating temporary credentials via the metadata service — no stored credentials, automatically replaced every ~6 hours, no credential exposure risk.

Other AWS SysOps domains

• Monitoring, Logging, and Remediation — 100 questions →
• Networking and Content Delivery — 90 questions →
• Deployment, Provisioning, and Automation — 89 questions →
• Reliability and Business Continuity — 80 questions →
• Cost and Performance Optimization — 60 questions →
• All 498 AWS SysOps questions →