1Z0-1104-25 Syllabus — Learning Objectives by Topic

Use this syllabus as your checklist for 1Z0‑1104‑25.

What’s covered

• Topic 1: Security Governance & IAM at Scale
• Topic 2: Network Security Architecture
• Topic 3: Key Management, Encryption, and Secrets
• Topic 4: Security Posture Management & Detection
• Topic 5: Audit, Logging, and Monitoring for Security
• Topic 6: Incident Response and Secure Operations

Topic 1: Security Governance & IAM at Scale

Practice this topic →

1.1 Compartment strategy for security and governance

• Design a compartment strategy that separates environments and sensitive workloads to reduce blast radius.
• Given a scenario, choose compartment boundaries that support least privilege and compliance reporting.
• Explain how compartment scope affects policy enforcement and access visibility.
• Identify governance anti-patterns (everything in root, inconsistent ownership, uncontrolled privileges).
• Use tagging/naming standards to support governance, cost attribution, and investigations.
• Given a scenario, choose governance controls (quotas/budgets) to reduce risk of resource sprawl.

1.2 IAM policy design: least privilege and separation of duties

• Interpret policy statements and identify subject, verb, resource-family, and compartment scope.
• Choose minimal verbs (read/use/manage) required to meet requirements.
• Given a scenario, implement separation of duties between builders, deployers, and security administrators (concept-level).
• Recognize the risk of broad "manage all-resources" policies and how to tighten scope safely.
• Given a scenario, design access for cross-team operations without granting excessive permissions.
• Recognize audit/logging as requirements for accountability and compliance.

1.3 Workload identity: dynamic groups and principals

• Explain dynamic groups and why they are used for workload identities without long-lived credentials.
• Given a scenario, choose instance/resource principals rather than embedding user keys in workloads.
• Design policies for dynamic groups with least privilege and appropriate compartment scope.
• Recognize the risk of over-broad dynamic group matching rules and how to constrain them (concept-level).
• Given a scenario, choose an approach that supports key rotation and minimizes secret distribution.
• Identify common auth/permission failure causes (missing policy, wrong compartment) conceptually.

Topic 2: Network Security Architecture

Practice this topic →

2.1 Segmentation and tier isolation (VCN, subnets, routing intent)

• Design VCN and subnet layouts that isolate public edge from private application/data tiers.
• Given a scenario, choose routing and gateway placement that minimizes exposure (private subnets, controlled egress).
• Recognize that route tables provide reachability while security controls restrict traffic (separate concerns).
• Identify the role of NAT/service gateways in reducing public internet exposure (concept-level).
• Given a scenario, choose a segmentation strategy that reduces lateral movement risk.
• Recognize common network anti-patterns: public databases, wide-open egress, flat networks.

2.2 Security lists vs NSGs and least-privilege rules

• Differentiate security lists (subnet-level) and NSGs (resource-level) and choose appropriately.
• Design least-privilege ingress/egress rules for common tiers (web/app/db).
• Recognize stateful vs stateless rules at a conceptual level and when behavior matters.
• Given a scenario, use NSGs to isolate applications sharing a subnet.
• Identify why inbound controls must be paired with controlled outbound (egress) in secure designs.
• Recognize that overly permissive rules are a common exam trap and tighten them safely.

2.3 Edge security controls (concept-level)

• Recognize WAF as a web-layer protection and identify its role (OWASP, bot mitigation) conceptually.
• Given a scenario, choose TLS termination and certificate management at the edge (concept-level).
• Identify why bastion-style access patterns reduce direct exposure of management endpoints (concept-level).
• Recognize that edge controls complement, but do not replace, IAM and network segmentation.
• Given a scenario, choose controls that reduce attack surface while meeting usability needs.
• Recognize the importance of edge logging for incident investigations.

Topic 3: Key Management, Encryption, and Secrets

Practice this topic →

3.1 Vault/KMS concepts and customer-managed keys

• Explain the purpose of key management services (Vault/KMS) at a conceptual level.
• Given a scenario, choose customer-managed keys when compliance requires control and rotation.
• Recognize key rotation and access control as core key management requirements (concept-level).
• Identify the difference between encryption at rest and encryption in transit conceptually.
• Given a scenario, choose an approach that supports auditability of key usage.
• Recognize the risks of unmanaged key sprawl and how to standardize key usage (concept-level).

3.2 Secrets management for applications and pipelines

• Choose Vault secrets to avoid storing credentials in code or build logs.
• Given a scenario, design secret distribution that supports rotation without downtime (concept-level).
• Recognize the risk of shared credentials and why per-workload identities are safer (concept-level).
• Identify safe patterns: least privilege to secrets, audit access, minimize secret exposure in logs.
• Given a scenario, choose a design that prevents accidental secret leakage in CI/CD.
• Recognize that incident response includes credential rotation and invalidation procedures.

3.3 Data protection rules of thumb

• Given a scenario, ensure sensitive data is stored in private tiers with restricted access controls.
• Recognize retention and deletion policies as part of data protection (concept-level).
• Identify backup/restore as a control for corruption and ransomware-style recovery needs (concept-level).
• Given a scenario, choose encryption and key management approaches that meet regulatory requirements.
• Recognize that data classification drives control selection (concept-level).
• Given a scenario, choose a data protection plan that includes monitoring and auditability.

Topic 4: Security Posture Management & Detection

Practice this topic →

4.1 Cloud Guard concepts: detectors, problems, responders

• Explain Cloud Guard’s purpose as a posture/detection service (concept-level).
• Differentiate detectors (signals) and problems (findings) conceptually.
• Given a scenario, choose responders to automate remediation for known-safe actions (concept-level).
• Recognize the need for notification and ownership in alert handling (concept-level).
• Identify common posture issues: public exposure, broad permissions, missing logging (concept-level).
• Given a scenario, choose a detection approach that balances false positives and operational overhead.

4.2 Security zones and preventive guardrails (concept-level)

• Explain preventive guardrails intent and why they reduce misconfiguration risk (concept-level).
• Given a scenario, choose guardrails that prevent public exposure of sensitive resources.
• Recognize the difference between preventive controls and detective controls (concept-level).
• Identify trade-offs: strict guardrails may increase friction; choose based on risk tolerance.
• Given a scenario, choose an approach that supports compliance requirements and reduces drift.
• Recognize that guardrails require governance processes and exception handling (concept-level).

4.3 Vulnerability and configuration hygiene (concept-level)

• Recognize the need for patch management and configuration hygiene for compute workloads (concept-level).
• Given a scenario, choose processes that reduce exposure (timely updates, minimal open ports).
• Identify why golden images and standard baselines reduce configuration drift (concept-level).
• Recognize that vulnerability management includes detection, prioritization, and remediation workflows.
• Given a scenario, choose controls that are practical to operate continuously.
• Recognize that logging and monitoring validate whether hygiene controls are effective.

Topic 5: Audit, Logging, and Monitoring for Security

Practice this topic →

5.1 Audit logs and accountability

• Explain Audit as the record of API calls for investigations and compliance (concept-level).
• Given a scenario, use audit logs to answer who changed what and when.
• Recognize that auditability supports separation of duties and change control.
• Identify common audit needs: IAM changes, network changes, key access, policy updates (concept-level).
• Given a scenario, choose retention strategies that support compliance requirements.
• Recognize that audit logs must be protected from tampering and unauthorized access (concept-level).

5.2 Logging and centralized visibility

• Design centralized logging to support detection, investigations, and troubleshooting (concept-level).
• Given a scenario, differentiate service logs vs application logs vs audit logs.
• Recognize the need to avoid logging sensitive values (secrets, PII) and apply redaction (concept-level).
• Identify the importance of correlation IDs for tracing actions across services (concept-level).
• Given a scenario, choose a logging approach that supports security monitoring and alerting.
• Recognize that log retention and access control are part of governance.

5.3 Monitoring and alerting for security signals

• Choose key security signals to alert on (unexpected access patterns, public exposure, key usage anomalies) conceptually.
• Given a scenario, design alert routes and escalation to ensure ownership and response.
• Recognize the trade-off between alert sensitivity and false positives (concept-level).
• Identify that monitoring must include both control plane events (audit) and data plane signals (logs/metrics) conceptually.
• Given a scenario, choose an approach that reduces mean time to detection and response.
• Recognize that monitoring should validate that security controls remain effective over time.

Topic 6: Incident Response and Secure Operations

Practice this topic →

6.1 Response workflows, automation, and containment

• Given a scenario, define containment steps: block access, rotate keys, isolate resources (concept-level).
• Recognize responder automation as a way to reduce response time for known-safe remediations (concept-level).
• Identify the importance of runbooks and clear ownership for incidents.
• Given a scenario, choose the safest first actions to reduce blast radius.
• Recognize that remediation should be auditable and reversible when possible (concept-level).
• Identify when to use break-glass access and how to control it (concept-level).

6.2 Post-incident actions: lessons learned and hardening

• Explain postmortems as a way to prevent recurrence (concept-level).
• Given a scenario, choose corrective actions that address root causes (policy tightening, guardrails, monitoring).
• Recognize that key/credential rotation may be required after incidents involving access.
• Identify the value of testing detection and response flows regularly (concept-level).
• Given a scenario, choose improvements that reduce future detection and response time.
• Recognize that governance includes verifying controls remain in place (continuous compliance).

6.3 Secure change management and continuous compliance

• Given a scenario, implement approval gates for high-risk changes (IAM, networking, keys).
• Recognize IaC and standard baselines as tools to reduce drift and increase auditability (concept-level).
• Identify why separation of duties reduces insider risk and accidental misconfiguration.
• Given a scenario, choose controls that balance security with operational practicality.
• Recognize that continuous compliance requires monitoring, reporting, and remediation workflows.
• Given a scenario, choose a sustainable operating model for security controls in production.