Identity and network questions often look different on the surface, but many test the same idea: do not grant trust or access merely because something exists, connected successfully, or was trusted yesterday.
1. Treat identity as a lifecycle
A secure identity process follows the reason access exists.
- Create or enroll: Establish the identity and required evidence.
- Provision: Grant access that is justified by the person's or service's role.
- Use: Authenticate, authorize, record activity, and enforce policy.
- Review: Confirm that access still matches current responsibility.
- Change: Adjust access when jobs, projects, locations, risk, or systems change.
- Deprovision: Remove or disable access when the need ends.
The biggest mistake is treating provisioning as permanent. Access that was correct six months ago may be excessive after a role change.
2. Keep authentication, authorization, and accounting separate
Authentication proves or verifies an identity.
Authorization determines which actions or resources that identity may use.
Accounting records activity for review, investigation, and accountability.
Multifactor authentication strengthens authentication. It does not automatically decide what the user may do after login.
| Scenario | Primary concept |
|---|---|
| A user enters a password and approves a hardware-token prompt. | Authentication |
| A database allows the user to read one table but not modify it. | Authorization |
| A log records who changed a permission and when. | Accounting |
3. Separate least privilege from separation of duties
Principle of Least Privilege (PoLP) limits each user, service, or process to the minimum access needed for authorized work.
Separation of Duties (SoD) divides incompatible responsibilities so one person cannot complete a sensitive process alone.
Least privilege asks, "How much access does this identity need?"
Separation of duties asks, "Should one identity be allowed to complete both sides of this process?"
A person may have only the permissions needed for a finance role and still violate SoD if the same person can both create and approve a payment.
4. Match the access-control model to the decision rule
| Model | Decision rule | Clue |
|---|---|---|
| Role-Based Access Control (RBAC) | Permissions are assigned to roles, then identities receive roles. | Job function or organizational responsibility |
| Attribute-Based Access Control (ABAC) | Access depends on attributes about the subject, resource, action, or environment. | Department, device state, location, time, data sensitivity |
| Discretionary Access Control (DAC) | An owner can grant or remove access under the system's rules. | Owner-controlled sharing |
| Mandatory Access Control (MAC) | Centrally enforced labels or classifications determine access. | Security labels and centrally controlled rules |
Do not choose RBAC simply because the word "role" appears in the scenario. If access depends on several changing attributes, ABAC may fit better.
5. Use network controls to reduce unnecessary trust
Common controls solve different problems:
- Firewall: Enforces allowed and denied traffic rules between network zones, systems, or applications.
- Virtual Local Area Network (VLAN): Creates logical Layer 2 separation and separate broadcast domains.
- Virtual Private Network (VPN): Creates a protected logical tunnel across an untrusted or shared network.
- Segmentation: Separates systems or zones to limit unnecessary communication and reduce the effect of compromise.
- Microsegmentation: Applies more granular segmentation, often around workloads or applications.
A VLAN can support segmentation, but simply assigning systems to VLANs does not guarantee that all traffic between them is blocked. Enforcement still depends on routing, firewall, access-control, or policy decisions.
6. Zero trust is not the same as trusting nothing
Zero trust avoids granting implicit trust based only on network location.
A zero-trust approach asks for explicit verification and limits access according to identity, device, resource, context, and policy. It supports:
- Strong identity assurance
- Least privilege
- Resource-focused access
- Segmentation
- Continuous evaluation
- Logging and visibility
Moving a user inside the corporate network should not automatically make every resource trustworthy or reachable.
CC clue: "Inside the network" is a location. It is not proof that the identity, device, request, or resource should be trusted.
7. Know what changes across IaaS, PaaS, and SaaS
Cloud service models change how much of the technology stack the provider operates.
- Infrastructure as a Service (IaaS): The provider supplies core infrastructure. The customer manages more of the operating system, applications, configurations, identities, and data.
- Platform as a Service (PaaS): The provider manages more of the platform and runtime. The customer focuses more on application logic, identities, configuration, and data.
- Software as a Service (SaaS): The provider delivers a complete hosted application. The customer still manages appropriate use, accounts, access, configuration, and data responsibilities.
The service model changes the division of work. It does not remove the customer's security responsibilities.
8. Shared responsibility means responsibilities are divided, not erased
A cloud provider may secure physical facilities, hardware, virtualization, or managed platform components depending on the service.
The customer may still be responsible for:
- Identity and access
- Data classification and handling
- Secure configuration
- Application choices
- User behavior
- Contract and compliance requirements
- Monitoring and response for customer-controlled activity
The exact boundary depends on the service, deployment, contract, and configuration.
9. Scenario clues that narrow the answer
An employee moves from finance to marketing
Review and remove access that no longer matches the new responsibility. The identity may stay, but authorization should change.
A user needs only enough permission to restart one service
Think least privilege, not broad administrator access.
One employee can create a vendor and approve payment to that vendor
The stronger concern is separation of duties.
Access is granted only when department, managed-device status, location, and data sensitivity all match policy
That pattern fits ABAC.
A company wants to limit how far an infected workstation can communicate
Think segmentation and enforcement between trust zones.
A SaaS provider operates the application
The customer still owns important identity, configuration, data, and usage decisions.
10. Rapid review grid
| If the question asks about... | Think first about... |
|---|---|
| Proving identity | Authentication |
| Permitted actions | Authorization |
| Minimum necessary access | Least privilege |
| Dividing incompatible responsibilities | Separation of duties |
| Permissions based on job function | RBAC |
| Permissions based on several attributes | ABAC |
| Reducing lateral movement | Segmentation |
| No implicit trust from network location | Zero trust |
| Provider vs. customer cloud duties | Shared responsibility |