AWS DevOps Engineer – Professional (DOP-C02): 5 Practice Questions on Security and Compliance
How well do you know Security and Compliance? This AWS DevOps Engineer – Professional (DOP-C02) set has 5 questions to find out. It makes up about 17% of the exam. Answers and full explanations sit under each question.
AWS DevOps Engineer – Professional (DOP-C02) · Security and Compliance · 5 questions with answers and explanations
🧭 What these questions look for
Security items test how controls behave at organization scale: SCPs, Control Tower guardrails, StackSets, GuardDuty findings and network ACLs. Many questions describe something unexpected (a deny that does not apply, a deployment that fails, traffic that is blocked) and ask why. The answer usually lies in a precise evaluation rule, so knowing exactly how each control applies matters more than knowing many services.
Keep in mind
• Classify controls by when they act: preventive ones stop an action, detective ones report it, and proactive checks run before resources are created.
• Check scope and order before assuming a policy failed. SCPs do not affect the management account, and NACL rules are evaluated by rule number.
• To silence expected findings but keep a record, look at suppression features rather than settings that stop findings from being generated.
📊 About this set
Exam: DOP-C02 · 75 questions · 180 minutes · passing score 750
This set: 4 advanced, 1 applied · 3 troubleshooting, 1 comparison, 1 trade-off
Topics: AWS CloudFormation, AWS Organizations, Control Tower, Organizations, Config, CloudTrail, Amazon GuardDuty, Amazon VPC, IAM, EC2
Question 1 of 5
A DevOps engineer creates a CloudFormation StackSet with service-managed permissions from the management account. The template creates IAM roles with explicit RoleName values. Every create-stack-instances operation fails immediately with an InsufficientCapabilitiesException, and no stack instance is created in any account. The engineer confirms that trusted access for StackSets is enabled in Organizations. What is the cause and the fix?
Show answer
✅ Answer: C
Difficulty: advanced · Topic: AWS CloudFormation, AWS Organizations
Why CloudFormation demands capabilities
Templates that create or modify IAM resources can change who has access to an account. CloudFormation therefore refuses to run them unless the caller explicitly acknowledges it.
• CAPABILITY_IAM acknowledges IAM resources that CloudFormation names itself.
• CAPABILITY_NAMED_IAM is required when the template sets custom names such as RoleName.
• CAPABILITY_AUTO_EXPAND is for macros and nested stacks with transforms.
The acknowledgement is part of the request. It applies to StackSets exactly as it applies to a regular stack.
Service-managed versus self-managed
With service-managed permissions, StackSets uses trusted access with Organizations and creates the execution roles in target accounts on its own. With self-managed permissions you create the administration and execution roles yourself.
Why each option works or fails
• ✗ A. Delegated administrator needed: the management account can deploy service-managed StackSets, including IAM resources. A delegated administrator is an option for separating duties, not a requirement to create IAM roles.
• ✗ B. Missing execution roles: those roles are only needed for self-managed permissions. With service-managed permissions, StackSets creates them, and a missing role would produce a failure per stack instance rather than an error about capabilities.
• ✓ C. (correct): An InsufficientCapabilitiesException that appears before any instance is created means the request did not acknowledge the IAM capability. Custom role names require CAPABILITY_NAMED_IAM, so passing it when creating or updating the StackSet resolves the failure.
• ✗ D. Named roles are not allowed: StackSets can deploy roles with custom names. The only difference is the capability that must be acknowledged, and a fixed name also has to be unique per account.
🎯 Key idea: IAM resources with custom names need CAPABILITY_NAMED_IAM, also for StackSets; an InsufficientCapabilitiesException means the capability was not acknowledged.
Question 2 of 5
A Control Tower administrator enables a guardrail that uses an SCP to block disabling CloudTrail in member accounts, and separately enables a guardrail that uses an AWS Config rule to flag accounts where CloudTrail is disabled. How should these two guardrail types be characterized?
Show answer
✅ Answer: B
Difficulty: applied · Topic: Control Tower, Organizations, Config, CloudTrail
Control Tower control behaviors
AWS Control Tower groups its controls (formerly called guardrails) by how they act:
• Preventive controls stop an action before it happens. They are implemented as SCPs (and, for some controls, RCPs or declarative policies), so a denied API call such as cloudtrail:StopLogging simply fails.
• Detective controls find resources that are already non-compliant. They are implemented as AWS Config rules, which evaluate recorded configuration and report compliance.
• Proactive controls check resources before provisioning, using CloudFormation hooks.
Using both together
Here, the SCP makes it impossible for member accounts to disable CloudTrail, and the Config rule flags any account where CloudTrail is still found disabled, for example an account enrolled before the control was applied. Preventive stops new problems; detective proves the state and catches what prevention missed.
Why each option works or fails
• ✗ A. Both preventive: a Config rule cannot block an API call; it only evaluates configuration after changes are recorded.
• ✓ B. SCP preventive, Config detective (correct): an SCP denies the API call up front, while a Config rule evaluates resources after the fact and reports non-compliance.
• ✗ C. Roles reversed: an SCP acts at request time and blocks the call, which is prevention, while a Config rule only reports, which is detection.
• ✗ D. Only detective supported: Control Tower offers preventive, detective and proactive controls.
🎯 Key idea: SCP-based controls prevent, Config-rule controls detect, and CloudFormation hooks check proactively.
Question 3 of 5
The security team has contracted a penetration-testing firm whose scanner runs from known IP addresses in a workload account for the next two weeks. GuardDuty generates many port probe findings caused by this scanning. The team wants these expected findings out of the active list, but wants to keep a record of them for the audit and continue to receive findings for all other activity. Which action should be taken?
Show answer
✅ Answer: B
Difficulty: advanced · Topic: Amazon GuardDuty
Suppression rules versus trusted IP lists
Both mechanisms reduce noise from expected activity, but they behave differently.
• A suppression rule applies filter criteria (for example finding type and remote IP address) to new findings and automatically archives the matches. The findings are still generated, stay searchable and exportable, and do not appear in the active list.
• A trusted IP list tells GuardDuty to treat certain IP addresses as safe, so it does not generate findings for activity that involves them. There is no record of what was suppressed.
Choosing for an audit
When a record of the suppressed activity has to exist, archive with a rule rather than stop generating findings.
Why each option works or fails
• ✗ A. Manual archiving: it works for a handful of findings, but at scanner volume the process is slow and error-prone, and a spreadsheet is a weak audit trail compared with automatic rules.
• ✓ B. (correct): The suppression rule limits the archive to the scanner and the finding types it causes. The findings still exist for the audit, and all other findings stay active.
• ✗ C. Trusted IP list: activity involving those IPs is not reported at all, so the audit record would be missing and any real attack from a listed address would be hidden as well.
• ✗ D. Disable GuardDuty: this creates a two-week blind spot for the entire account and loses detection of real threats, far more than the scanner traffic.
🎯 Key idea: To hide expected findings but keep an audit record, use GuardDuty suppression rules (auto-archive); trusted IP lists stop findings from being generated.
Question 4 of 5
An SG allows TCP 443 from 203.0.113.0/24, but connections still fail. The subnet NACL has rule 90 DENY 203.0.113.0/24 all traffic and rule 100 ALLOW 443 from 0.0.0.0/0. What is happening?
Show answer
✅ Answer: B
Difficulty: advanced · Topic: Amazon VPC
How network ACLs are evaluated
A network ACL is a stateless filter on a subnet boundary. Its rules are numbered and evaluated in ascending order; the first rule whose protocol, port range and CIDR match the packet decides the outcome, and later rules are ignored.
Example inbound NACL:
• 90 DENY all 203.0.113.0/24
• 100 ALLOW TCP 443 0.0.0.0/0
• * DENY all 0.0.0.0/0
A packet from 203.0.113.25 to port 443 matches rule 90 first and is dropped, even though rule 100 would also match.
Security groups and NACLs together
Traffic must pass both layers. The NACL is checked at the subnet edge, and the security group at the instance's network interface. A security group allow cannot rescue traffic the NACL has already dropped. Because NACLs are stateless, return traffic also needs an outbound rule, usually for ephemeral ports 1024-65535.
Why each option works or fails
• ✗ A. Security groups override NACLs: neither layer overrides the other; traffic must be allowed by both, and the NACL decision happens first at the subnet boundary.
• ✓ B. Rule 90 matches first (correct): NACL rules are evaluated from lowest number up and stop at the first match, so the DENY for 203.0.113.0/24 blocks the traffic before the ALLOW 443 rule is considered.
• ✗ C. Outbound only: NACLs have separate inbound and outbound rule sets and filter both directions.
• ✗ D. Most specific rule wins: NACLs do not use longest-prefix or specificity logic; the rule number alone sets the evaluation order.
🎯 Key idea: NACL rules are first-match by rule number, and both the NACL and the security group must allow a flow.
Question 5 of 5
An account in an OU has an SCP that explicitly denies ec2:TerminateInstances, but a developer in that account still successfully terminates an EC2 instance. The IAM policy simulator shows the developer's identity policy allows the action, and no other SCP in the OU hierarchy grants it. What is the most likely explanation?
Show answer
✅ Answer: C
Difficulty: advanced · Topic: Organizations, IAM, EC2
How SCPs fit into permission evaluation
Service control policies (SCPs) in AWS Organizations set the maximum permissions for IAM users and roles in member accounts. An explicit Deny in any SCP that applies to an account blocks the action, no matter what the identity policy allows.
The exception: the management account
SCPs do not affect any user or role in the management account, including its root user. Even if the management account sits under a policy path with a deny, its principals are not restricted by SCPs.
• This is one reason AWS recommends running no workloads in the management account.
• Workloads belong in member accounts, where SCPs do apply to every principal, including the member account's root user.
Example: an SCP denying ec2:TerminateInstances blocks a developer in a member account, but a developer in the management account can still terminate instances if their IAM policy allows it.
Why each option works or fails
• ✗ A. Explicit Allow overrides Deny: in IAM evaluation an explicit Deny always wins, and an SCP Deny cannot be overridden by any Allow in an identity policy.
• ✗ B. SCPs affect only the root user: it is the other way around; SCPs apply to all IAM users and roles in member accounts, including the root user of those accounts.
• ✓ C. It is the management account (correct): SCPs never restrict principals in the organization's management account, so the identity policy's Allow is enough there even though a Deny SCP is in the hierarchy.
• ✗ D. Attached to the wrong OU: the scenario says the account is in the OU that has the SCP, so it applies to member accounts there; misattachment does not fit the facts given.
🎯 Key idea: SCP denies apply to every principal in member accounts, but never to the management account, so keep workloads out of it.
🔗 Related practice sets
• DOP-C02 Practice Set: Resilient Cloud Solutions
• Monitoring and Logging: 5 DOP-C02 Questions with Full Explanations
• 5 Questions to Test Your Incident and Event Response Knowledge (DOP-C02)
• All DOP-C02 practice sets
• Every exam on this blog
📚 Beyond this set
More DOP-C02 questions: https://hyunhp.github.io/cert-bank/#exam=DOP-C02
Study guide: https://hyunhp.github.io/cert-bank/study.html#exam=DOP-C02
These are original practice questions, not real exam questions, and cert-bank is not affiliated with any certification vendor.
Original practice questions written for this blog, not exam dumps.
Comments
Post a Comment