← CCNP Security: SCOR core and operations
19 / 25 · 55 MIN

Cloud: identity and control boundaries

Build a responsibility matrix and validate permissions, segmentation and operational handover for a migration.

1. Assign responsibilities by component

A fictional reporting application uses a VM, object storage and a managed service. The plan merely says “cloud handles security”, leaving tasks without owners. Replace that phrase with a matrix: for each component identify configuration, patching, identity, data, logs and recovery, with an executor and acceptance evidence. On EC2, the customer still manages the guest system and application. In a more abstracted service, the provider operates more layers, but permissions and data classification do not disappear. The matrix must reflect the selected service and contract; an inherited responsibility does not establish validation of the customer’s particular configuration.

2. Separate human and workload identity

The batch only needs to read one object prefix and write results to another. An administrative key inside the image allows far more and complicates rotation. AWS guidance calls for workload roles and temporary credentials; people should use federated access and MFA under the approved design. Short duration reduces exposure but does not correct excessive permissions during a session. Define required actions, resources and conditions, and test denied operations too. For external CI/CD, validate the trust relationship and relevant issuer, repository or environment attributes. Obtaining a token is insufficient: who can request it and what it permits are separate questions.

3. Translate flows into policy with context

Flow discovery observes web to application and application to database. The worksheet also includes a monthly batch missing from the sample. Before converting observation into authorization, compare dependencies, environment, owner and purpose. Production and test labels help define groups, but a wrong label can place a workload in the wrong scope. Validate metadata origin and updates. Secure Workload/Secure Firewall integration supports policy enforcement on hosts and in the network; choose the point the traffic actually traverses, with support for the system and release. Visibility at one point establishes neither enforcement elsewhere nor automatic coverage of alternate paths.

4. Promote, observe and recover

The worksheet proposes six unexecuted tests: business flow, out-of-scope access, monthly batch, usable logs, rollback and recovery with sufficient capacity. Use observation or simulation where available, limited initial scope and explicit stop criteria. IPS can be a compensating control while patching is scheduled, but it does not remove the software vulnerability. Effectiveness depends on path, signature, action and covered traffic. Retain an owner and deadline for the definitive fix. If a flow fails, collect identity, effective policy, enforcement point and time rather than opening the whole network to restore one transaction quickly.

5. Hand operational autonomy to RUN

Before handover, demonstrate who can query logs, renew access, apply authorized changes and recover service. Measure gaps against full inventory; a green dashboard of active agents does not automatically cover agentless workloads or missing recent telemetry. Include controlled, tested emergency access, cost owners and criteria for retiring old resources. Recovery tests need usable data and application outcomes rather than merely running instances. The worksheet is a tabletop exercise with no AWS resources or Cisco equipment created. Summary: associate each security commitment with a component, identity, control point and verifiable operational evidence.

IN PRACTICE

The batch has temporary but broad access to every object. Expiry does not replace scoping resources and testing denial outside the approved prefix.

Common pitfalls

Cloud as total transfer; temporary token as least privilege; observed flow as authorization; IPS as an applied patch.

Related topics: IAM and roles · Microsegmentation · Handover and recovery

Take this idea with you

Shared responsibility becomes operational when each control has an owner, scope and evidence.

Create account

Reference: Shared Responsibility Model · 350-701 SCOR v2.0, effective 2026-08-27; core component of CCNP Security

CCNP® and Cisco® are registered trademarks of Cisco Systems, Inc. and/or its affiliates. bigsavant.com is an independent preparation platform and is not affiliated with, associated with, sponsored, authorised or endorsed by Cisco. Content and questions are original, are not official exam questions, and completing our tests does not award or guarantee any certification. Names are used only to identify the subject. All other trademarks belong to their respective owners.